6

I have created a simple rule called "99-usb.rules" that simply names a tty port of a specific device 

KERNEL=="ttyACM*", ATTRS{idVendor}=="2341", NAME="mydevice"

This rule works fine when I run a udevadm test with the command 

udevadm test $(udevadm info -q path -n /dev/ttyACM0)

Running this command causes "/dev/mydevice" to appear, and I can communicate with my usb device through "mydevice". The problem is, I can't get this rule to be triggered outside of the test environment. I have tried "udevadm control -R" and "udevadm trigger" aswell as disconnecting and reconnecting the device and rebooting my system. Any ideas why "udevadm trigger" would fail? I am using udev version 173 on OS OpenWrt Barrier Breaker 14.07.

sourcejedi
  • 48,311
  • 17
  • 143
  • 296
Dark
  • 171
  • 1
  • 3
  • FWIW, it looks like you're _supposed_ to use SYMLINK instead, even with this old version of udev. I don't think that's the problem though. – sourcejedi May 01 '18 at 20:54
  • @sourcejedi Thanks, I'll change to SYMLINK to follow a standard, but you're right it did not solve this issue. I guess I will try using a new version of udev. – Dark May 01 '18 at 20:58
  • 1
    I... elided some context. The reason BB has a 2011 version of udev will be because it was among the last standalone versions of udev. And possibly they wanted not to depend on devtmpfs, which udev version 176 does. (In that version it stopped letting you set NAME at all). I haven't found a reason to expect that there's a problem with the specific version you're using. – sourcejedi May 01 '18 at 21:04
  • All I can think is to [enable the debug logging](https://git.kernel.org/pub/scm/linux/hotplug/udev.git/tree/udev.conf?h=173) and see what it says. AFAIK it should end up in the [openwrt system log](https://wiki.openwrt.org/doc/howto/log.essentials). You might end up wanting to increase log_size. – sourcejedi May 01 '18 at 22:02
  • @sourcejedi looks like I get a few "user.err syslog: Unkown action change" errors, so the trigger command is obviously not working – Dark May 01 '18 at 23:01
  • Gah. Wonder where that comes from. (Note "change" is the default action for `trigger`; "add" is what happens at boot time, or hardware connect). How about disconnect+reconnect? I assume that's convenient to test, at least you don't have to wait for a reboot and trawl through the debug of all that. – sourcejedi May 01 '18 at 23:55

1 Answers1

0

I had a similar issue on my linux systems. I eventually found out the NAME option is severely underpowered, as it only works with network interfaces. It has no effects on disk drives, TTYs, and other stuff, that are managed by the kernel. You should instead use SYMLINK+=... to create a symlink to that device. I think it better suits your purpose.

logan rakai
  • 103
  • 4
Enginecrafter77
  • 345
  • 3
  • 11
  • This environment is different. IIUC udev 173 still begrudgingly allowed you to set NAME, and also the comments show this answer did not solve the problem. – sourcejedi Feb 04 '19 at 16:13
  • We have at least one Q/A that covers it, so I won't ask you to open a new question to hold your answer :-). https://unix.stackexchange.com/questions/270179/udev-working-with-symlink-but-not-with-name – sourcejedi Feb 04 '19 at 16:25