This won't work directly as it is using udev on a Linux desktop system, but describes the basic idea:
I have a similar issue with the pl2303 usb ttl adapters I use for console. I have 3 such connected to the same host, and they look identical in every aspect. Here even the serial number is useless. But I need to know which OpenWrt device each one is connected to for the conserver config. So what I do is:
- look at the usb bus topology and which ports the adapters are connected to (simple here with only one bus in use):
bjorn@canardo:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M
|__ Port 2: Dev 7, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M
|__ Port 5: Dev 4, If 1, Class=Vendor Specific Class, Driver=, 480M
|__ Port 5: Dev 4, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M
|__ Port 11: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 11: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 12: Dev 6, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M
- configure udev rules to set up device specific symlinks based on the significant differences:
ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", ATTRS{devpath}=="1" SYMLINK+="p8702n"
ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", ATTRS{devpath}=="2" SYMLINK+="wrt1900ac"
ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", ATTRS{devpath}=="12" SYMLINK+="wap6805"
- Then I simply use these symlinks in my config instead of the arbitrary ttyUSBx names:
bjorn@canardo:~$ ls -l /dev/{p8702n,wrt1900ac,wap6805}
lrwxrwxrwx 1 root root 7 Aug 20 20:07 /dev/p8702n -> ttyUSB0
lrwxrwxrwx 1 root root 7 Aug 20 20:07 /dev/wap6805 -> ttyUSB2
lrwxrwxrwx 1 root root 7 Sep 16 14:18 /dev/wrt1900ac -> ttyUSB1
EDIT: Just to avoid misunderstandings - I meant this only as an example of the bus topology rule matching. Symlinks will of course not work for netdevs. You need to rename those instead. With udev you would do that with a NAME="foo" action.
No, it shouldn't. I meant changes like adding new USB devices or some other hardware which might cause variable probing delays.