LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (http://www.linuxquestions.org/questions/linux-general-1/)
-   -   Udev Rules To Differentiate Between Multiple Identical Devices (http://www.linuxquestions.org/questions/linux-general-1/udev-rules-to-differentiate-between-multiple-identical-devices-822879/)

mcalautti 07-29-2010 10:16 AM

Udev Rules To Differentiate Between Multiple Identical Devices
 
I did a search and cant seem to find help on this specific issue.

how can we get udev to assign the same ttyUSBx to the same device everytime if the USB device is the same.. does that sound confusing ?
LOL

what I have is 4 USB serial cables to 4 promise storage arrays. so if you do a lsusb you get the same subsys info because all the devices are the same.

I had initially set up aliases to use minicom to get to the promise arrays but if you reboot the server they are connected to, it will reassign them in no particular order. so with that you actually may not be consoled to the machine you think your on..

server is
2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
CentOS release 5.4 (Final)

here is the lsusb



lsusb|grep PL23
Bus 001 Device 007: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 006: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

GrapefruiTgirl 07-29-2010 10:40 AM

udevadm monitor to identify unique identifiers of USB device.
 
Even though the devices are otherwise identical, you ought to see different serial numbers (hopefully) by using `udevadm` or `udevmonitor` when connecting the devices. I suspect that with the newness of your OS, you'll be wanting `udevadm` - check the manpages for `udev` and `udevadm` and also note at the bottom of those manpages, any related manpages, and check those too if necessary. You should be able to come up with a command that will monitor (like debugging) UDEV events, and which will show you all the available info from each device.

Here's some example of what I'm talking about; I turn on `udevadm monitor` first, and plug in a USB stick:

Code:

root@reactor: udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1280416896.201243] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3 (usb)
KERNEL[1280416896.201905] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0 (usb)
KERNEL[1280416896.202409] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5 (scsi)
KERNEL[1280416896.202434] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/scsi_host/host5 (scsi_host)
UDEV  [1280416896.209576] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3 (usb)
UDEV  [1280416896.210271] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0 (usb)
UDEV  [1280416896.210436] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5 (scsi)
UDEV  [1280416896.210623] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/scsi_host/host5 (scsi_host)
KERNEL[1280416897.241271] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0 (scsi)
KERNEL[1280416897.241355] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0 (scsi)
KERNEL[1280416897.241452] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0/scsi_disk/5:0:0:0 (scsi_disk)
UDEV  [1280416897.241486] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0 (scsi)
KERNEL[1280416897.241968] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0/scsi_device/5:0:0:0 (scsi_device)
KERNEL[1280416897.242103] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0/scsi_generic/sg5 (scsi_generic)
UDEV  [1280416897.242129] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0 (scsi)
UDEV  [1280416897.242480] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0/scsi_device/5:0:0:0 (scsi_device)
UDEV  [1280416897.242865] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0/scsi_disk/5:0:0:0 (scsi_disk)
UDEV  [1280416897.243647] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0/scsi_generic/sg5 (scsi_generic)
KERNEL[1280416897.243763] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0/bsg/5:0:0:0 (bsg)
UDEV  [1280416897.245042] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0/bsg/5:0:0:0 (bsg)
KERNEL[1280416897.824889] change  /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0 (scsi)
UDEV  [1280416897.825273] change  /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0 (scsi)
KERNEL[1280416898.606376] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0/block/sde (block)
KERNEL[1280416898.606409] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0/block/sde/sde1 (block)
KERNEL[1280416898.606426] add      /devices/virtual/bdi/8:64 (bdi)
UDEV  [1280416898.606747] add      /devices/virtual/bdi/8:64 (bdi)
UDEV  [1280416899.021528] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0/block/sde (block)
UDEV  [1280416899.178386] add      /devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0/block/sde/sde1 (block)
^Croot@reactor:

So, I see it is given /dev/sde1 as a block device. Now, we'll do "attribute walk" to get info about the device:

Code:

root@reactor: udevadm info --attribute-walk --name=/dev/sde1

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0/block/sde/sde1':
    KERNEL=="sde1"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{partition}=="1"
    ATTR{start}=="8064"
    ATTR{size}=="31367296"
    ATTR{alignment_offset}=="0"
    ATTR{discard_alignment}=="4290838528"
    ATTR{stat}=="    145      141    2288      483        0        0        0        0        0      483      483"

<--snip-->

 looking at parent device '/devices/pci0000:00/0000:00:0b.1/usb1/1-3':
    KERNELS=="1-3"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="80"
    ATTRS{bMaxPower}=="300mA"
    ATTRS{urbnum}=="830"
    ATTRS{idVendor}=="0930"
    ATTRS{idProduct}=="6545"
    ATTRS{bcdDevice}=="0110"
    ATTRS{bDeviceClass}=="00"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{speed}=="480"
    ATTRS{busnum}=="1"
    ATTRS{devnum}=="4"
    ATTRS{devpath}=="3"
    ATTRS{version}==" 2.00"
    ATTRS{maxchild}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{authorized}=="1"
    ATTRS{manufacturer}=="        "
    ATTRS{product}=="USB Flash Memory"
    ATTRS{serial}=="001D0F0A94F1B8B1100E03E7"

<--snip-->

There, I see the serial number of the USB key. It should be unique.

There is a lot of info provided by attribute walk, and it can be pesky selecting just the right pieces and describing them correctly per the syntax required in the udev rules - so it may take you experimentation to get the rule just right. You will want to use at least two or three attributes, including subsystem, serial number, etc., to make sure the device is uniquely identified. For testing of your rules, you'll want to restart your udevd daemon after making rule changes (and I believe there's a command you can give to udevd to tell it to re-read the rules too..) and then use `udevadm monitor` to watch what udev does when you connect the device, to see that your rule is doing what it's supposed to do.

Finally - Google for "Writing Udev Rules" - there are a few very good tutorials easily found, which should help you with syntax if need be.

Good luck!

mcalautti 07-29-2010 01:11 PM

wow thanks for all that info..

I cant find udevadm. not in RHEL repository or rpmbone for example.

apparently its not in the udev rpm cause I have that installed.

do you know what pkg its in?

thanks again
mike

GrapefruiTgirl 07-29-2010 01:14 PM

Uhh.. Hmm, I'd have thought you'd already have it as part of your udev package. Have you tried just typing udevadm (EDIT: or try udevmonitor) in a root console? Or, checking the udev or udevd manpages? Somewhere there should be a reference to it.

If not, then you'd know better than I would :) since I don't use RHEL/CentOS. Perhaps a member more familiar with that OS can tell us if it is part of the udev package.

EDIT #2: Maybe, if it isn't in your $PATH, you'll need to give a full path, like /sbin/udevadm or /usr/sbin/udevadm (though it should not be in /usr).

ncsuapex 07-29-2010 01:24 PM

I thought this thread was about how awesome udev was :D

XavierP 07-29-2010 03:36 PM

To save any confusion, I have renamed the thread

mcalautti 07-30-2010 09:18 AM

ya it would have been in my path. im in as root.. I have a udevinfo
but I assume I am using it wrong.
udevinfo -a -q name -n /dev/ttyUSB0
no record for 'ttyUSB0' in database
clearly one of the devices is plugged into USB0..
I have udevmonitor but im not at the location that the machine is at so I cant unplug and plug in the device.

Ill try to see if I can get more info from udevinfo.
so my main goal here I assume, is to get the serial # from each USB serial device.

mcalautti 07-30-2010 09:20 AM

FOUND IT.. but not sure if its everythin I would need!!!

udevinfo -a -p /sys/class/tty/ttyUSB0

Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device '/class/tty/ttyUSB0':
KERNEL=="ttyUSB0"
SUBSYSTEM=="tty"
SYSFS{dev}=="188:0"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.0/ttyUSB0':
ID=="ttyUSB0"
BUS=="usb-serial"
DRIVER=="pl2303"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.0':
ID=="1-4.2:1.0"
BUS=="usb"
DRIVER=="pl2303"
SYSFS{modalias}=="usb:v067Bp2303d0400dc00dsc00dp00icFFisc00ip00"
SYSFS{bInterfaceProtocol}=="00"
SYSFS{bInterfaceSubClass}=="00"
SYSFS{bInterfaceClass}=="ff"
SYSFS{bNumEndpoints}=="03"
SYSFS{bAlternateSetting}==" 0"
SYSFS{bInterfaceNumber}=="00"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2':
ID=="1-4.2"
BUS=="usb"
DRIVER=="usb"
SYSFS{configuration}==""
SYSFS{product}=="USB-Serial Controller D"
SYSFS{manufacturer}=="Prolific Technology Inc. "
SYSFS{maxchild}=="0"
SYSFS{version}==" 1.10"
SYSFS{devnum}=="4"
SYSFS{speed}=="12"
SYSFS{bMaxPacketSize0}=="64"
SYSFS{bNumConfigurations}=="1"
SYSFS{bDeviceProtocol}=="00"
SYSFS{bDeviceSubClass}=="00"
SYSFS{bDeviceClass}=="00"
SYSFS{bcdDevice}=="0400"
SYSFS{idProduct}=="2303"
SYSFS{idVendor}=="067b"
SYSFS{bMaxPower}=="100mA"
SYSFS{bmAttributes}=="a0"
SYSFS{bConfigurationValue}=="1"
SYSFS{bNumInterfaces}==" 1"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-4':
ID=="1-4"
BUS=="usb"
DRIVER=="usb"
SYSFS{configuration}==""
SYSFS{product}=="USB2.0 Hub"
SYSFS{maxchild}=="4"
SYSFS{version}==" 2.00"
SYSFS{devnum}=="2"
SYSFS{speed}=="480"
SYSFS{bMaxPacketSize0}=="64"
SYSFS{bNumConfigurations}=="1"
SYSFS{bDeviceProtocol}=="01"
SYSFS{bDeviceSubClass}=="00"
SYSFS{bDeviceClass}=="09"
SYSFS{bcdDevice}=="0702"
SYSFS{idProduct}=="0608"
SYSFS{idVendor}=="05e3"
SYSFS{bMaxPower}=="100mA"
SYSFS{bmAttributes}=="e0"
SYSFS{bConfigurationValue}=="1"
SYSFS{bNumInterfaces}==" 1"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1':
ID=="usb1"
BUS=="usb"
DRIVER=="usb"
SYSFS{configuration}==""
SYSFS{serial}=="0000:00:1d.7"
SYSFS{product}=="EHCI Host Controller"
SYSFS{manufacturer}=="Linux 2.6.18-164.el5 ehci_hcd"
SYSFS{maxchild}=="8"
SYSFS{version}==" 2.00"
SYSFS{devnum}=="1"
SYSFS{speed}=="480"
SYSFS{bMaxPacketSize0}=="64"
SYSFS{bNumConfigurations}=="1"
SYSFS{bDeviceProtocol}=="01"
SYSFS{bDeviceSubClass}=="00"
SYSFS{bDeviceClass}=="09"
SYSFS{bcdDevice}=="0206"
SYSFS{idProduct}=="0000"
SYSFS{idVendor}=="0000"
SYSFS{bMaxPower}==" 0mA"
SYSFS{bmAttributes}=="e0"
SYSFS{bConfigurationValue}=="1"
SYSFS{bNumInterfaces}==" 1"

looking at parent device '/devices/pci0000:00/0000:00:1d.7':
ID=="0000:00:1d.7"
BUS=="pci"
DRIVER=="ehci_hcd"
SYSFS{broken_parity_status}=="0"
SYSFS{enable}=="0"
SYSFS{modalias}=="pci:v00008086d0000268Csv0000103Csd000031FEbc0Csc03i20"
SYSFS{local_cpus}=="00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000"
SYSFS{irq}=="169"
SYSFS{class}=="0x0c0320"
SYSFS{subsystem_device}=="0x31fe"
SYSFS{subsystem_vendor}=="0x103c"
SYSFS{device}=="0x268c"
SYSFS{vendor}=="0x8086"

looking at parent device '/devices/pci0000:00':
ID=="pci0000:00"
BUS==""
DRIVER==""



Look at this,...

udevinfo -a -p /sys/class/tty/ttyUSB0|grep -i seri
BUS=="usb-serial"
SYSFS{product}=="USB-Serial Controller D"
SYSFS{serial}=="0000:00:1d.7"

udevinfo -a -p /sys/class/tty/ttyUSB1|grep -i seri
BUS=="usb-serial"
SYSFS{product}=="USB-Serial Controller D"
SYSFS{serial}=="0000:00:1d.7

GrapefruiTgirl 07-30-2010 09:37 AM

SYSFS{modalias}=="usb:v067Bp2303d0400dc00dsc00dp00icFFisc00ip00"

LOL.. Looks like "serial" is the same for more than one device.. The thing I paste above, "modalias" is another one you should examine. Is that different on each unit?

mcalautti 07-30-2010 09:45 AM

LOL
ya exactly.. thats what my problem is.. its a 7 port USB hub..
it has 4 of the same serial adaptors plugged in.. it gives me serial access to Promise storage devices in the event I lose network functionality to them..

thats why lsusb shows 4 of the same devices, just diff bus locations.

Bus 001 Device 007: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 006: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

mcalautti 07-30-2010 10:18 AM

sorry i missed your question about modalias GrapefruiTgirl

naturally its the same LOL

for l in `ls -lad /sys/class/tty/ttyUSB*|awk '{print $9}'`; do udevinfo -a -p $l|grep -i modalias; done
SYSFS{modalias}=="usb:v067Bp2303d0400dc00dsc00dp00icFFisc00ip00"
SYSFS{modalias}=="pci:v00008086d0000268Csv0000103Csd000031FEbc0Csc03i20"
SYSFS{modalias}=="usb:v067Bp2303d0400dc00dsc00dp00icFFisc00ip00"
SYSFS{modalias}=="pci:v00008086d0000268Csv0000103Csd000031FEbc0Csc03i20"
SYSFS{modalias}=="usb:v067Bp2303d0400dc00dsc00dp00icFFisc00ip00"
SYSFS{modalias}=="pci:v00008086d0000268Csv0000103Csd000031FEbc0Csc03i20"
SYSFS{modalias}=="usb:v067Bp2303d0400dc00dsc00dp00icFFisc00ip00"
SYSFS{modalias}=="pci:v00008086d0000268Csv0000103Csd000031FEbc0Csc03i20"

GrapefruiTgirl 07-30-2010 03:38 PM

Very interesting!

Ok, forgive me for asking/stating what may be obvious, but I guess you have examined ALL the attributes (serial, modalias, etc..), with ALL the devices connected, and there's not a single attribute that is unique to each individual connected device, right?

So it would seem that no attributes from the storage devices themselves, are being returned to udevinfo, correct? We're only seeing attributes from the USB subsystem (the hub ports) itself, and the storage devices may as well not be there at all, as far as udevinfo is concerned?

OK.. If that's the case, here's what I propose next, unless someone else has a better idea:

When these devices are connected and are 'online', it's as though they're connected via serial port, and the USB part of the equation becomes basically transparent, and the computer appears to talk directly to the storage devices, correct? If so, can each storage device, once it's connected, be queried via its serial connection, to identify itself or to return some information of some kind? Further, does each storage device have the ability to identify itself in a way that's unique from each other one? Even something as primitive as having a particular unique file stored on each storage device, might work.

If so, here's where I'm going: UDEV has the ability to execute some command(s)s, or to call other tools/binaries or execute a script or whatever, by using the "RUN" keyword in a rule. Read about "RUN" on the udev man page. RUN can be used, for example, to execute the `mount` command to auto-mount a partition of a USB hard disk. What I wonder is if you could use the UDEV RUN option to execute some script/tool/command/program that would serially access each drive via its tty/ttyUSB* node (the tty node passed to the script from udev), read the unique identifier file on that drive, and based on the contents of that unique file, create a NEW symlink to that tty/ttyUSB* node. Understand?

Hmm..
Now, having written that, I wonder if you might be able to do this (easier) without even using udev... After a reboot, let udev do its thing, and once bootup is all done, have a script execute (like from rc.local or comparable on that machine) that queries each tty/ttyUSB* storage device via serial, figures out which storage unit is which using the unique file idea or something like that, and then makes the new identifying symlink to that device.

Do you think any of this is possible? At this time, I have no other idea :scratch:

mcalautti 08-02-2010 09:19 AM

3 Attachment(s)
your response is awesome !!. thanks for all your help so far.

SO i tried to see if I can run commands via ssh to the promise storage to get back a serial or WWN to use.. naturally this does not work either.
not sure what type of shell and or protocol its using once in the ssh CLI but it does not seem to let you pass a command over ssh to get a value back.. :(..

here are the duevinfo outputs for all the promises's attached.. im not sure
if any of it can be used.

GrapefruiTgirl 08-02-2010 11:10 AM

Well, here's the diff output from comparing two of the files:
Code:

sasha@reactor: diff --suppress-common-lines ttyUSB0.txt  ttyUSB1.txt
1,2c1,2
<  looking at device '/class/tty/ttyUSB0':
<    KERNEL=="ttyUSB0"
---
>  looking at device '/class/tty/ttyUSB1':
>    KERNEL=="ttyUSB1"
4c4
<    SYSFS{dev}=="188:0"
---
>    SYSFS{dev}=="188:1"
6,7c6,7
<  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.0/ttyUSB0':
<    ID=="ttyUSB0"
---
>  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.3/1-4.3:1.0/ttyUSB1':
>    ID=="ttyUSB1"
11,12c11,12
<  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.0':
<    ID=="1-4.2:1.0"
---
>  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.3/1-4.3:1.0':
>    ID=="1-4.3:1.0"
23,24c23,24
<  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2':
<    ID=="1-4.2"
---
>  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.3':
>    ID=="1-4.3"
32c32
<    SYSFS{devnum}=="4"
---
>    SYSFS{devnum}=="5"
sasha@reactor:

So as we can see, the only info's that are different, are all related to the USB subsystem, and nothing at all related to the promise devices themselves. So, if you were to reboot the server, I assume based on your original post, that these tty devices would not necessarily end up on the same device node next time, as they are this time. For example:
Code:

...parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.0/ttyUSB0':
...parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.3/1-4.3:1.0/ttyUSB1':

so the underlined part, would not necessarily be matched up to the bold part, right? Next reboot, 1-4.3/1-4.3:1.0 might be ttyUSB0, which could be any one of the 4 promise devices?

If above is accurate, it appears to me that there's no way for UDEV to tell one device from the others. If you cannot figure a way to query each device after it's online, either using ssh or serial port or something, I'd say you're stuck, from a UDEV point of view.

BUT: I have another idea: rather than use USB-Serial converter/hub, what would be stopping you from installing a PCI multi-port serial card into the machine? Has it got a PCI slot empty? If you go this route, you can be sure that each serial port is still connected to the same device as last reboot :) and in my experience, these multi-port cards are not very expensive. I've got a couple of 2-port cards here that I paid less than $10.00 each for; a 4-port card shouldn't be much more costly, and FWIW if you have a used computer parts place around (like where I got mine) they'll be even cheaper.

I hope someone else can either suggest how to distinguish these via USB info, though it doesn't look good; OR, help you figure out how to query the promises via their USB tty connection, using ssh or whatever, to get them to identify themselves. Otherwise, a new serial card looks like a solution.

Good luck - keep us posted if you make any progress!

mackey 08-25-2010 09:44 PM

I had a similar problem a number of years ago with a bank of USB modems, and I ended up keying on their position on the USB bus. If you are not going to be rearranging where they're plugged in then you can do something like:

BUS="usb", ID=="1-4.2:1.0", SYMLINK+="ttyUSBport2"
BUS="usb", ID=="1-4.3:1.0", SYMLINK+="ttyUSBport3"
BUS="usb", ID=="1-4.4:1.0", SYMLINK+="ttyUSBport4"

etc. This works as no matter what order they're initialized in their place on the physical bus is not going to change (unless you unplug one and plug it in somewhere else). I think the ID means controller 1, position 4 (which is a hub), hub port 2 (or 3 or 4), device 1.

/mackey


All times are GMT -5. The time now is 03:25 PM.