I'd like to use libudev to watch for certain devices. Specifically, I want to monitor for removable storage: USB Hard Drives, USB Keys, SD cards, etc. The libudev API lets you find a device if you know that device's parent's 'subsystem' and 'devtype'. I tried the devices out on my computer and used udevadm to find that all the storage types had device subsystem of 'block'->'scsi', but I have no idea what devtype these devices have. Is there a list of devtypes and subsystems I can use as a reference somewhere, or a better method to look up devtype?
You can get list of subsystems with ls /sys/class/
I'm not sure about device types though. I guess you can get this using:
ls -l /sys/class/scsi_disk/
total 0
lrwxrwxrwx 1 root root 0 2011-12-07 21:20 0:0:0:0 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0
cat /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0/device/vendor
ATA
cat /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0/device/model
ST9500325AS
You can try other files in device directory.
Actually I think you need:
cat /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0/device/type
0
cat /usr/include/scsi/scsi.h | grep TYPE_
#define TYPE_DISK 0x00
#define TYPE_TAPE 0x01
#define TYPE_PROCESSOR 0x03 /* HP scanners use this */
#define TYPE_WORM 0x04 /* Treated as ROM by our system */
#define TYPE_ROM 0x05
#define TYPE_SCANNER 0x06
#define TYPE_MOD 0x07 /* Magneto-optical disk -
#define TYPE_MEDIUM_CHANGER 0x08
#define TYPE_ENCLOSURE 0x0d /* Enclosure Services Device */
#define TYPE_NO_LUN 0x7f
Related
I have a custom i.MX6 board, and I want to turn on a particular GPIO.
From the schematic, the GPIO pin is connected to KEY_COL2 pad, and the KEY_COL2 has the following options.
So, I have to export the following GPIO as per the calculation:
linux gpio number = (gpio_bank - 1) * 32 + gpio_bit
gpio number = ( 4 - 1 ) *32 +10 = 106
When I run the following command, i get the error:
# echo 106 > /sys/class/gpio/export
sh: write error: Device or resource busy
What can be the issue, am i missing anything...
After looking at the device tree, this particular GPIO was used by some other device, hence the error.
You can find the GPIO's in use with the following commands:
mount -t debugfs none /sys/kernel/debug
cat /sys/kernel/debug/gpio
I have a device communicates through i2c protocol. The registers addresses of the device are 16 bits but Linux i2c-tools supports only 8-bit addresses. But I have found something to handle it.
For example, to read a register at the address on 0x0006, I use the method below: (assuming the busId is 0 and the device i2c address is 0x48)
i2cset -y 0 0x48 0x00 0x06 # this command sets the register address to 0x0006
i2cget -y 0 0x48 # this command the value 0xBA which is true
When I call the i2cget -y 0 0x48 command again, it returns the value at the next address.
The writing operation works as I expect. But when I try to write into the same register, I fail. I try the below command:
i2cset -y 0 0x48 0x00 0x06 0xBA 0x0B i
This command doesn't return an error. But when I read the register again, I see the register unchanged.
The device I use is AP0100CS. The register address is writable. I don't know what is wrong with i2cset.
Hello is there any way to get the signal strength of near by bluetooth le devises in linux? Or any good libraries for nodejs, php or mono (I do know some c++ or python but would prefer to say away from them) if a tool does not exisst but would be fairly easy to write.
On Linux, the way to do this is with the hcitool command. However, you have to be connected to get the rssi of a device. If you want to achieve this from the command line, try:
#hcitool rssi AA:BB:CC:DD:EE:FF
If you want to see the actual C code to achieve this, take a look at the bluez tools/hcitool.c file, under the cmd_rssi function.
static void cmd_rssi(int dev_id, int argc, char **argv)
{
...
}
For Bluetooth Low Energy, I only know one way to do this, and that is using the #btmon command. Run btmon in the background then scan for Bluetooth Low Energy devices:
#./btmon &
# hcitool lescan
The results displayed on the monitor should be similar to this:
> HCI Event: LE Meta Event (0x3e) plen 12
LE Advertising Report (0x02)
Num reports: 1
Event type: Scan response - SCAN_RSP (0x04)
Address type: Public (0x00)
Address: AA:BB:CC:DD:EE:FF (<Vendor Name>)
Data length: 0
***RSSI: -34 dBm (0xde)***
AA:BB:CC:DD:EE:FF <Device Name>
Note that when using btmon you do not have to connect to get the rssi of a BLE device.
No need to connect when using btmgmt
$ sudo btmgmt find
Discovery started
hci0 type 7 discovering on
hci0 dev_found: 50:8C:FD:99:0A:EC type LE Random rssi -80 flags 0x0000
AD flags 0x06
eir_len 23
…
The relative signal strength indicator is rssi -80, but the list is much longer containing more information about this and other devices.
To spy on your Bluetooth neighbourhood showing only unique MAC addresses with their strongest RSSI, run the following command:
$ sudo btmgmt find |grep rssi |sort -n |uniq -w 33
hci0 dev_found: 40:43:42:B3:71:11 type LE Random rssi -53 flags 0x0000
hci0 dev_found: 44:DA:5F:EA:C6:CF type LE Random rssi -78 flags 0x0000
hci0 dev_found: 7F:7D:08:6B:E0:37 type LE Random rssi -74 flags 0x0000
hci0 dev_found: A4:58:0F:21:A1:8C type BR/EDR rssi -79 flags 0x0000
You can use a combination of:
sudo hcitool lescan --duplicates & ;
sudo hcidump --raw
that will provide you the raw dump of all the bluetooth packets which contain all relevant information you must be interested in such as : UUID, Major, Minor, RSSI, TxPower. You will have to run some kind of script to parse and filter LE packets and make them into readable form.
One of the scripts written with Bash and S editor was provided by jjnebaker here with the problem and solution discussed here
The Other option is to use PyBluez using the example code here
But you might find the solution provided by Switchdoc labs useful according to your needs as well. here
This works for c language, but has an error when casting the bytes that have the information about de rssi signal.
https://github.com/glock45/intel-edison-playground/blob/master/scan.c
this line 121:
printf("%s - RSSI %d\n", addr, (**char**)info->data[info->length]);
should be:
printf("%s - RSSI %d\n", addr, (**int8_t**)info->data[info->length]);
I found these by looking inside bluez-version/monitor/*.c, where btmon program is. You can see the data types and structs, hcidump.c is very useful and packets.c, and main.c too, but there are many to learn about the hci sockets.
I also found a program I was able to edit to do what I wanted as well
I through it up on my github account
https://github.com/tholum/bluez/blob/master/blue.py
i found several solutions, but most were too slow for my needs to use as a tracking function.
check out https://github.com/abandonware/noble containing some examples.
my standalone scanner is also based on abandonware's module and can be found here:
https://github.com/efeuentertainment/BLE-continuous-RSSI-scan
node index.js BLEMAC
continuously lists the RSSI with an update frequency of about 2 per second / depending on BLE device.
also fast updates based on bash is:
sudo hcitool lescan --duplicates &
combined with one of the following lines:
continuous updates
sudo hcidump | grep "E6:4E:57:09:74:E4" -A 4
sudo btmon | grep "E6:4E:57:09:74:E4" -A 7
only the next received update
sudo hcidump | grep -m 1 "E6:4E:57:09:74:E4" -A 4 | grep "RSSI"
sudo btmon | grep -m 1 "E6:4E:57:09:74:E4" -A 7 | grep "RSSI"
hope that helps. it's an old thread but my search engine lead me here anyway.
try :
$ bluez-test-discovery
output :
[ 18:7A:93:05:E4:B1 ]
Name = AMIYJ_E4B1
Paired = 0
LegacyPairing = 0
Alias = AMIYJ_E4B1
Broadcaster = 0
UUIDs = dbus.Array([dbus.String(u'0000fff0-0000-1000-8000-00805f9b34fb')], signature=dbus.Signature('s'), variant_level=1)
Address = 18:7A:93:05:E4:B1
RSSI = -65
Class = 0x000000
gives you : RSSI = -65
For connected devices you can use btmgmt conn-info
e.g.
$ sudo btmgmt conn-info -t 2 E4:0C:E6:59:B6:FC
Connection Information for E4:0C:E6:59:B6:FC (LE Random)
RSSI -78 TX power 0 maximum TX power 0
(You have the code for that command at https://github.com/bluez/bluez/blob/150bbff449c787f26b7de3e6006bdb2ea6365b08/tools/btmgmt.c#L3984-L4030 ).
I think you may also be able to use BlueZ's DBus RSSI property of the org.bluez.Device1 interface :
int16 RSSI [readonly, optional]
Received Signal Strength Indicator of the remote
device (inquiry or advertising).
but that didn't work for me:
$ dbus-send --print-reply=literal --system --dest=org.bluez /org/bluez/hci0/dev_E4_0C_E6_59_B6_FC org.freedesktop.DBus.Properties.Get string:"org.bluez.Device1" string:"RSSI"
Error org.freedesktop.DBus.Error.InvalidArgs: No such property 'RSSI'
Maybe because the property is optional. Some other properties did work for me:
$ dbus-send --print-reply=literal --system --dest=org.bluez /org/bluez/hci0/dev_E4_0C_E6_59_B6_FC org.freedesktop.DBus.Properties.Get string:"org.bluez.Device1" string:"Name"
variant eono BTC 01
I have a RedBee RFID Reader. Its user documentation is only for windows, and I am on ArchLinux. The only time I have ever done serial communication over a USB port was for an Arduino and that was through their GUI environment so I never was exposed to the metal. So I have this RFID reader that you interface with via serial communication across a USB port. The baud rate is 9600, the device is connected to /dev/bus/usb/004/004. The output of ls -l /dev/bus/usb/004/004 is:
crwxrwxrwx 1 root root 189, 387 Mar 8 19:14 /dev/bus/usb/004/004
The output of lsusb is
Bus 004 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-
Serial (UART) IC
Bus 004 Device 003: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth
...
The output of lsusb -s 004:004 -v is:
Bus 004 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0x6001 FT232 USB-Serial (UART) IC
bcdDevice 6.00
iManufacturer 1 FTDI
iProduct 2 FT232R USB UART
iSerial 3 A900DGX9
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 90mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 FT232R USB UART
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
Here is the output of dmsg | grep -i tty
[ 0.000000] console [tty0] enabled
[ 7.226118] systemd[1]: Starting system-getty.slice.
[ 7.226397] systemd[1]: Created slice system-getty.slice.
[ 10.535204] usb 4-1.7: FTDI USB Serial Device converter now attached to ttyUSB0
[ 6372.435916] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 7961.660760] usb 4-1.7: FTDI USB Serial Device converter now attached to ttyUSB0
[ 7964.716225] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 8282.582961] usb 4-1.7: FTDI USB Serial Device converter now attached to ttyUSB0
Things I have tried:
I have tried using putty's (compiled for linux) serial option to connect to /dev/bus/usb/004/004 but it responds with:
Unable to open connection to:
Unable to configure serial port
The solution is to use dmesg | grep -i tty to get the TTY the device has connected to. In my case I needed to connect to /dev/ttyUSB0 not /dev/bus/usb/004/004.
More Info
dmesg
This way you can automatically detect which device you should use (replace FT232R_USB_UART with model) :
#!/bin/sh
PORT=""
for i in /dev/ttyUSB* ; do
if [ "x`udevadm info $i | grep 'ID_MODEL=FT232R_USB_UART'`" != "x" ] ; then
PORT=$i
fi
done
if [ "x$PORT" = "x" ] ; then
echo "No FT232R_USB_UART port found!" 1>&2
exit 1
fi
echo "PORT = $PORT"
Is it possible to read the MAC address from the NIC directly? I have the code below but it just reads from the layer above but not the card itself.
I'm trying to figure out how to find the original MAC address of an Ethernet NIC on my Linux box. I understand how to find the current MAC address using ifconfig.
But the address can be changed, say by using
ifconfig eth0 hw ether uu:vv:ww:yy:xx:zz
or setting it "permanently" using /etc/sysconfig/network-scripts/ifcfg-eth0.
How do I find the original MAC address? There must be a way to find it, because it is still burned permanently into the card, but I can't find a tool to read the burned in address.
Is there any utility or command for that?
I suppose it should be possible to write C code for it, below code gives my current MAC but not the original MAC:
#include <stdio.h> /* Standard I/O */
#include <stdlib.h> /* Standard Library */
#include <errno.h> /* Error number and related */
#define ENUMS
#include <sys/socket.h>
#include <net/route.h>
#include <net/if.h>
#include <features.h> /* for the glibc version number */
#if __GLIBC__ >= 2 && __GLIBC_MINOR >= 1
#include <netpacket/packet.h>
#include <net/ethernet.h> /* the L2 protocols */
#else
#include <asm/types.h>
#include <linux/if_packet.h>
#include <linux/if_ether.h> /* The L2 protocols */
#endif
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/un.h>
#include <sys/ioctl.h>
#include <netdb.h>
int main( int argc, char * argv[] ){
unsigned char mac[IFHWADDRLEN];
int i;
get_local_hwaddr( argv[1], mac );
for( i = 0; i < IFHWADDRLEN; i++ ){
printf( "%02X:", (unsigned int)(mac[i]) );
}
}
int get_local_hwaddr(const char *ifname, unsigned char *mac)
{
struct ifreq ifr;
int fd;
int rv; // return value - error value from df or ioctl call
/* determine the local MAC address */
strcpy(ifr.ifr_name, ifname);
fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_IP);
if (fd < 0)
rv = fd;
else {
rv = ioctl(fd, SIOCGIFHWADDR, &ifr);
if (rv >= 0) /* worked okay */
memcpy(mac, ifr.ifr_hwaddr.sa_data, IFHWADDRLEN);
}
return rv;
}
OS: Red Hat Linux, 2.6.18.8-1
Certainly in ethtool you can just print the address:
-P --show-permaddr
Queries the specified network device for permanent hardware address.
e.g.
ethtool -P eth0
produces
Permanent address: 94:de:80:6a:21:25
Try cat /sys/class/net/eth0/address or cat /sys/class/net/em1/address if using Fedora. It should work.
The original answer is here: Notes of a Systems Admin
The only way to find the original MAC address is to use the same method the network card driver does - unfortunately, I don't believe there is a generic way to tell the driver to provide its MAC address "as provided by the hardware". Of course, there are cases where there isn't a hardware network card for that particular interface - virtual network drivers for virtualization and when using bridges and software switches for example.
And of course, the hardware may be such that you can't actually read the "original" MAC address when it has been overwritten by software, because there is only one set of registers for the MAC address itself.
I had a quick look at the pcnet32.c drivers (because it's one of the models of network card that I have a rough idea how it works and where the different registers are, etc, so I can see what it does). As far as I can see, it supports no method of actually asking "what is your PROM Ethernet address" - the MAC address is read out during the "probe1" section of the module initialization, and stored away. No further access to those hardware registers is made.
Well, the old ethernet address remains in the first bytes of the card eeprom (at least for some types of cards), so it is possible to extract it using ethtool
bash$ sudo ethtool -e eth1
Offset Values
------ ------
0x0000 tt uu ww xx yy zz 79 03
0x....
where tt:uu:ww:xx:yy:zz is old mac address
This may not be the programmatic way, but why not search dmesg. All of my machines' NICs spit out the MAC address at detection time.
Try something like this:
dmesg|grep eth0
Different NICs display the MAC address differently, but the log will always contain the kernel given name of the adapter (in most cases eth0 or wlan0).
In Ubuntu 18.4 LTS
First you need to find the network interface names on the computer by command
ls /sys/class/net
My output is
docker0 enp0s31f6 lo
Now you can use the command as discussed above, dont forget the sudo
sudo ethtool -P enp0s31f6
This command lists all the ethernet devices and original HW addresses.
dmesg | grep eth | grep IRQ | awk {'print "permanent address of " $5 " " $9'} |tr "," " "