I'm programming a kioks device and i want to block all usb devices expect 2 kind of usb.One is my touch screen hid usb and the other one is usb storage devices.Actually i tried write rules under udev.I tried this code :
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTR{authorized}="0"
But this one is blocking all usb devices.So i tried to add another rule to unblock specific device with product and vendor id.
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTR{idVendor}=="0eef", ATTR{idProduct}=="0005", ATTR{authorized}="1"
but this one is not working.
is there any another way to do this operation.
The problem with your approach is that it disables USB hub devices as well, and normally hub is part of the USB host controller internally. Therefore, after disabling all USB devices, you need to explicitly enable any hub devices and then the desired USB devices. This can be done as:
#By default, disable all usb devices (including hubs)
ACTION=="add", SUBSYSTEMS=="usb", RUN+="/bin/sh -c 'for host in /sys/bus/usb/devices/usb*; do echo 0 > $host/authorized_default; done'"
#Enable hub devices
ACTION=="add", ATTR{bDeviceClass}=="09", RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'"
#Enable desired USB devices by setting PID/VID
ACTION=="add", ATTR{idVendor}=="045e", ATTR{idProduct}=="07f8", RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'"
ACTION=="add", ATTR{idVendor}=="045e", ATTR{idProduct}=="0797", RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'"
For more info, follow these links :
Setting authorized by running script,
Setting authorized using ATTR
Related
I added an udev rule to generate a separate link to a special tty device. I took the vendor and product id from lsusb:
Bus 001 Device 016: ID abcd:1234 Foo Device
The dmesg output for the device is:
[ 369.384850] usb 1-1.1: new full-speed USB device number 4 using xhci_hcd
[ 369.470492] usb 1-1.1: New USB device found, idVendor=09d8, idProduct=0420
[ 369.470506] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 369.470515] usb 1-1.1: Product: TWN4/B1.06/CCL3.12/PRS1.04
[ 369.470522] usb 1-1.1: Manufacturer: OEM
[ 369.475188] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device
Normally the Debian system generates an ACM* tty for this device:
$ ls /dev/ttyACM*
/dev/ttyACM0
So I created /ect/udev/rules.d/99-bizrfid.rules:
ACTION=="add", ATTRS{idVendor}=="09d8", ATTRS{idProduct}=="0420", SYMLINK+="ttyMyDevice"
But ls /dev/tty* does not show ttyMyDevice.
What I tried so far without success:
Running udevadm trigger. This should apply the new udev rule.
I did a reboot.
I had a look to udevadm test /dev/ttyACM0. My udevrule is shown at the end. So I am sure that it had not been overridden. But I wonder about the 'unable to open' hint. Nevertheless this hint is present for other ttys, such as tty0 or ttyS0, too.
...
Reading rules file: /lib/udev/rules.d/98-systemd.rules
Reading rules file: /etc/udev/rules.d/99-bizrfid.rules
rules contain 49152 bytes tokens (4096 * 12 bytes), 12883 bytes strings
4240 strings (40079 bytes), 3515 de-duplicated (27922 bytes), 726 trie nodes used
unable to open device '/sys/dev/ttyACM0'
Unload module index
Unloaded link configuration context.
I reconnected the USB device.
I tried another udev rule. This rule is 100% correct because I use this rule already fo other devices. But it does not work for the ttyACM0:
ACTION=="add", KERNEL=="ttyACM*", MODE="0666"
I wonder why this is not working.
How to find reasons why an udev rule is not applied?
For the udev rule
/ect/udev/rules.d/99-bizrfid.rules I would add the SUBSYSTEM:
ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="09d8", ATTRS{idProduct}=="0420", SYMLINK+="ttyMyDevice"
You could add also ATTRS{manufacturer}==, but idVendor and idProduct are sufficient.
Otherwise it looks correct and the test run creates the symlink:
creating link '/dev/ttyMyDevice' to '/dev/ttyACM0'
According to the comments I the following can be tried to debug the problem:
Check the driver
Use dmesg to check the driver you are using and ensure that it is a generic one. If it is a custom compiled one, the problem could be inside your custom implementation. If it is a generic one, go on to step two. I found the driver name in the last line: cdc_acm
[ 369.384850] usb 1-1.1: new full-speed USB device number 4 using xhci_hcd
[ 369.470492] usb 1-1.1: New USB device found, idVendor=09d8, idProduct=0420
[ 369.470506] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 369.470515] usb 1-1.1: Product: TWN4/B1.06/CCL3.12/PRS1.04
[ 369.470522] usb 1-1.1: Manufacturer: OEM
[ 369.475188] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device
Check the user permissions
Ensure that the permission of your udev rule is correct:
chmod 644 99-myrule.rules
chown root:root 99-myrule.rules
Do a test run for the add-action
Check the output of udevadm test -a add $(udevadm info -q path -n /dev/ttyACM0). My output looks like this:
calling: test
version 232
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.
=== trie on-disk ===
tool version: 232
file size: 8447696 bytes
header size 80 bytes
strings 1849040 bytes
nodes 6598576 bytes
Load module index
Found container virtualization none
timestamp of '/etc/systemd/network' changed
timestamp of '/usr/lib/systemd/network' changed
timestamp of '/lib/systemd/network' changed
Parsed configuration file /lib/systemd/network/99-default.link
Created link configuration context.
timestamp of '/etc/udev/rules.d' changed
Skipping overridden file: /lib/udev/rules.d/99-bizrfid.rules.
Reading rules file: /lib/udev/rules.d/50-firmware.rules
...
Reading rules file: /lib/udev/rules.d/98-systemd.rules
Reading rules file: /etc/udev/rules.d/99-bizrfid.rules
rules contain 49152 bytes tokens (4096 * 12 bytes), 12900 bytes strings
4244 strings (40114 bytes), 3517 de-duplicated (27942 bytes), 728 trie nodes used
GROUP 20 /lib/udev/rules.d/50-udev-default.rules:26
IMPORT builtin 'hwdb' /lib/udev/rules.d/60-serial.rules:7
IMPORT builtin 'usb_id' /lib/udev/rules.d/60-serial.rules:8
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1/1-1.1:1.0: if_class 2 protocol 0
IMPORT builtin 'hwdb' /lib/udev/rules.d/60-serial.rules:8
IMPORT builtin 'path_id' /lib/udev/rules.d/60-serial.rules:15
LINK 'serial/by-path/pci-0000:00:14.0-usb-0:1.1:1.0' /lib/udev/rules.d/60-serial.rules:16
IMPORT builtin skip 'usb_id' /lib/udev/rules.d/60-serial.rules:19
LINK 'serial/by-id/usb-OEM_TWN4_B1.06_CCF3.00_PRS1.04-if00' /lib/udev/rules.d/60-serial.rules:23
LINK 'ttyMyDevice' /etc/udev/rules.d/99-bizrfid.rules:1
handling device node '/dev/ttyACM0', devnum=c166:0, mode=0660, uid=0, gid=20
preserve permissions /dev/ttyACM0, 020660, uid=0, gid=20
preserve already existing symlink '/dev/char/166:0' to '../ttyACM0'
found 'c166:0' claiming '/run/udev/links/\x2fserial\x2fby-id\x2fusb-OEM_TWN4_B1.06_CCF3.00_PRS1.04-if00'
creating link '/dev/serial/by-id/usb-OEM_TWN4_B1.06_CCF3.00_PRS1.04-if00' to '/dev/ttyACM0'
preserve already existing symlink '/dev/serial/by-id/usb-OEM_TWN4_B1.06_CCF3.00_PRS1.04-if00' to '../../ttyACM0'
found 'c166:0' claiming '/run/udev/links/\x2fserial\x2fby-path\x2fpci-0000:00:14.0-usb-0:1.1:1.0'
creating link '/dev/serial/by-path/pci-0000:00:14.0-usb-0:1.1:1.0' to '/dev/ttyACM0'
preserve already existing symlink '/dev/serial/by-path/pci-0000:00:14.0-usb-0:1.1:1.0' to '../../ttyACM0'
creating link '/dev/ttyMyDevice' to '/dev/ttyACM0'
creating symlink '/dev/ttyMyDevice' to 'ttyACM0'
created db file '/run/udev/data/c166:0' for '/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1/1-1.1:1.0/tty/ttyACM0'
ACTION=add
DEVLINKS=/dev/serial/by-path/pci-0000:00:14.0-usb-0:1.1:1.0 /dev/serial/by-id/usb-OEM_TWN4_B1.06_CCF3.00_PRS1.04-if00 /dev/ttyMyDevice
DEVNAME=/dev/ttyACM0
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1/1-1.1:1.0/tty/ttyACM0
ID_BUS=usb
ID_MODEL=TWN4_B1.06_CCF3.00_PRS1.04
ID_MODEL_ENC=TWN4\x2fB1.06\x2fCCF3.00\x2fPRS1.04
ID_MODEL_FROM_DATABASE=Atom Processor Z36xxx/Z37xxx, Celeron N2000 Series USB xHCI
ID_MODEL_ID=0420
ID_PATH=pci-0000:00:14.0-usb-0:1.1:1.0
ID_PATH_TAG=pci-0000_00_14_0-usb-0_1_1_1_0
ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
ID_PCI_INTERFACE_FROM_DATABASE=XHCI
ID_PCI_SUBCLASS_FROM_DATABASE=USB controller
ID_REVISION=0200
ID_SERIAL=OEM_TWN4_B1.06_CCF3.00_PRS1.04
ID_TYPE=generic
ID_USB_CLASS_FROM_DATABASE=Communications
ID_USB_DRIVER=cdc_acm
ID_USB_INTERFACES=:020201:0a0000:
ID_USB_INTERFACE_NUM=00
ID_VENDOR=OEM
ID_VENDOR_ENC=OEM
ID_VENDOR_FROM_DATABASE=Intel Corporation
ID_VENDOR_ID=09d8
MAJOR=166
MINOR=0
SUBSYSTEM=tty
TAGS=:systemd:
USEC_INITIALIZED=71480300178
Unload module index
Unloaded link configuration context.
I want to control a hdmi matrix switch via serial connection.
In Windows i already tried it successful by the following steps:
Decode the necessary HEX from a simple textfile to a binary:
certutil -decodehex on.txt on.bin
Then configure the mode for my comport:
MODE COM1:19,n,8,1
copy on.bin \\.\com1 /b
Now i try to do the same in linux (debian). Since the files are binary i figured i can reuse them, so i transferred them to the linux system and tried the following to configure the comport:
stty -F /dev/ttyUSB0 19200 cs8 -cstopb -parenb
And sending the binary:
cat on.bin > /dev/ttyUSB0
But that won't do anything.ยด
EDIT:
It's a different PC, but the USB2Serial Converter ist the same.
lsusb gives me:
Bus 001 Device 003: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
dmesg shows
[ 5.070075] usbserial: USB Serial support registered for generic
[ 5.072824] usbserial: USB Serial support registered for ch341-uart
[ 5.073476] usb 1-9: ch341-uart converter now attached to ttyUSB0
I'm trying to communicate with a Di245 through its Virtual COM driver (VCD) in Linux (pdf) and I'm having a strange issue. Internally, an FTDI chipset is used by this device (FT232BL).
Attaching the device by itself isn't registered as a VCD, so I do the following:
sudo modprobe usbserial vendor=0x0683 product=0x2450
which results in the following dmesg message:
usbserial: USB Serial support registered for generic
usbserial_generic 3-3:1.0: The "generic" usb-serial driver is only for testing and one-off prototypes.
usbserial_generic 3-3:1.0: Tell linux-usb#vger.kernel.org to add your device to a proper driver.
usbserial_generic 3-3:1.0: generic converter detected
usb 3-3: generic converter now attached to ttyUSB0
and I get the /dev/ttyUSB0 device as promised. So far, everything seems ok.
However, if I open the port in my code, I get a bunch of 1` from it (alternating 1 and `). Trying with screen:
screen /dev/ttyUSB0 115200
I continuously receive 1`. This is definitely not something the device is sending and oddly enough, if I put a random baudrate, I keep getting the same thing.
Is this a way some error is being reported? What could be triggering this behavior and how can I address it?
The solution was the following:
# modprobe usbserial vendor=0x0683 product=0x2450
# modprobe ftdi_sio
# echo "0683 2450" >> /sys/bus/usb-serial/drivers/ftdi_sio/new_id
This way, the ftdi_sio driver knows which vendor/product to provide VCD for. The following udev rule (say, 99-di245.rules) can automate this:
ACTION=="add", ATTRS{idVendor}=="0683", ATTRS{idProduct}=="2450", RUN+="/sbin/modprobe ftdi_sio" RUN+="/sbin/modprobe usbserial vendor=0x0683 product=0x2450" RUN+="/bin/sh -c 'echo 0683 2450 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id'"
It is installed with:
$ sudo cp 99-di245.rules /etc/udev/rules.d
$ sudo udevadm control --reload
Trying to solve this problem (ttyUSB0 that works properly than stop working after about 1hr)I'm thinking on if disconnecting and reconnecting the usb device could be a good fix.
So, it is possibile to cut down power to the USB device and repower it programmatically (bash)?
# lsusb -t
1-1:1.0: No such file or directory
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
|__ Port 1: Dev 2, If 0, Class=vend., Driver=, 12M
|__ Port 1: Dev 2, If 1, Class=vend., Driver=cp210x, 12M
On am335x, kernel 3.2.0, ubuntu core armhf.
[ 1.784332] usb 1-1: cp210x converter now attached to ttyUSB0
At the moment I need a complete power cycle to have ttyUSB0 back.
This is the solution:
Find the identity of your usb device.
# tree /sys/bus/usb/drivers/cp210x/
/sys/bus/usb/drivers/cp210x/
|-- 1-1:1.1 -> ../../../../devices/platform/omap/musb-ti81xx/musb-hdrc.1/usb1/1-1/1-1:1.1
|-- bind
|-- module -> ../../../../module/cp210x
|-- remove_id
|-- uevent
-- unbind
So 1-1:1.1 is the identifier of my ttyUSB0(it can be discovered also via dmesg).
Then, disconnect the device (as root):
# echo -n "1-1:1.1" > /sys/bus/usb/drivers/cp210x/unbind
reconnect it
# echo -n "1-1:1.1" > /sys/bus/usb/drivers/cp210x/bind
At this point I had the same device but with a different name, it was now ttyUSB1 instead of ttyUSB0.
- To avoid this I added a new rule in /etc/udev/rules.d/ by creating a new file named 99-usb-serial.rules with this line:
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea70", ATTRS{serial}=="002DCFAF", SYMLINK+="sameName", MODE:="0666"
where idVendor, idProduct and serial must be the values of your device. This rule will create a new device called sameName linked to the ttyUSB* device normally generated from the OS.
As #Robert Harvey Said,
You first need to find our driver that will help you 'unplug and plug' the usb. Type: ls /sys/bus/usb/drivers which should print something like this: btusb ftdi_sio hub usb usbfs usbhid usbserial_generic uvcvideo. These, are all the drivers for each usb device. Now, lets say mine is ftdi_sio, which is a device i use to program my arduino (atmega328p chip). I am not sure how Your/other usb devices name themselves there. Like, i dont know which of these is my mouse.
Now, you can see the driver's commands using:
ls /sys/bus/usb/drivers/ftdi_sio/, which will print something like: 1-4:1.0 bind module uevent unbind, Where 1-4:1.0 is the device's characteristic code, and the bind and unbind command, which are the 'plug' and 'unplug' command respectively.
Now, if i want to unplug programatically the ftdi usb port, i will type:
echo -n "1-4:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind
and, to plug it again:
echo -n "1-4:1.0" > /sys/bus/usb/drivers/ftdi_sio/bind
Now, we can combine all the commands together, with a ';':
echo -n "1-4:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind ; echo -n "1-4:1.0" > /sys/bus/usb/drivers/ftdi_sio/bind
I'm using CentOS 6 and I have two serial ports (two USB interfaces on two different ports), USB1 and USB2. When I connect the USB1, the OS sets her patch to "/dev/ttyACM0", and when I connect the USB2, "/dev/ttyACM1".
But when I connect first the USB2, the OS sets her patch to "/dev/ttyACM0" and no to "/dev/ttyACM1". I need that the USB1 patch be "/dev/ttyACM0" and USB2 "/dev/ttyACM1", regardless of the order that I connect the interfaces. How I do to do it?
Thank you
Create a udev rule that defines the symlink based on the attributes of the USB device (such as the serial number).
Find out information about your device-
udevadm info -n /dev/ttyACM0 -a
udevadm info -n /dev/ttyACM1 -a
Then go into /etc/udev/rules.d/ and create a udev rule. Something similar to the blurb below. Here is a good reference. For lots of examples and more discussion, do searches for udev persistent usb serial.
SUBSYSTEM=="tty", ATTRS{idVendor}=="0000", ATTRS{idProduct}=="0000", ATTRS{serial}=="000001", SYMLINK+="ACM0"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0000", ATTRS{idProduct}=="0000", ATTRS{serial}=="000002", SYMLINK+="ACM1"