I have searched the net for this issue but either this is too stupid or I was unable to find ist. So I ended up here.

Problem. I am using kamikaze 8.09.1 on an ASUS WL500P and I want to connect multiple serial converter by using the USB adapters. There ougth to be one single instance of a daemon prog per serial adapter that connects it to the outer world by using ethernet.
I am trying now to launch the daemon automagically when the serial device (FTDI) is plugged in. As long as I connect only one device, there is no problem as it always seem to use /dev/tts/0. But when I plug in the next, it uses /dev/tts/1 (who wonders) But now the problem.
On reboot of the box, coldplug finds e.g. two serial adapters and calls my hotplug script. Problem is: "How do I determine the device that has been assigned to the adapter just plugged in?" I tried dmesg of course but at the moment the hotplug script is called, dmesg already contains both events.

hub.c: USB hub found
hub.c: 4 ports detected
hub.c: new USB device 00:03.1-1.1.1, assigned address 4
usbserial.c: FTDI FT232BM Compatible converter detected
usbserial.c: FTDI FT232BM Compatible converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
hub.c: new USB device 00:03.1-1.1.2, assigned address 5
usbserial.c: FTDI FT232BM Compatible converter detected
usbserial.c: FTDI FT232BM Compatible converter now attached to ttyUSB1 (or usb/tts/1 for devfs)
 ---- 1. hotplug appears here ---

I also checked /proc/bus/usb/device but did not find any clue of determing the device address fram that information.

How do I then determine the assigned device address that I do need to pass to my daemon program in my hotplug script?

  Any tips are very much appreciated, really!!

  Thanks for answering on this,  Peter

You might want to check within your hotplug script if the environment variable $DEVICENAME is set, which probably contains something along the lines of ttyUSB0 or ttyUSB1 respectively, which may help you access the node under the /dev/ tree.

If it isn't set or you want to check if other interesting env variables are set, a line like the following in the hotplug script has often helped me:

logger "$(echo $(env))"

It logs all exported environment variables to syslog, ready to be viewed via logread or with your syslog server if you have one set up. (BTW, the superfluous echo in that line is not exactly superfluous, as it flattens all env variables into one line)

Regards,
Niels Böhm

Thanks Niels for your reply,

of course I do have the $DEVICE checked in my hotplug script, but how do I determine the device that has been assigend to the USB device descriptor in $DEVICE

USER=root
ACTION=add
OLDPWD=/
HOME=/
HOTPLUG_TYPE=usb
LOGNAME=root
DEVFS=/proc/bus/usb
PATH=/bin:/sbin:/usr/bin:/usr/sbin
TYPE=0/0/0
INTERFACE=255/255/255
PRODUCT=403/6001/600
PWD=/amon
DEVICE=/proc/bus/usb/002/006

As one can see, the $DEVICE contains some information about what enumerated device has been used but from that I was unable to locate the device in the devfs.

  Peter

Well, I meant $DEVICENAME (or even $DEVPATH), not $DEVICE. But they seem to be missing in your list. Also $SUBSYSTEM is missing, which I find a bit strange.

But unfortunately I cannot test it here, since my device doesn't have USB ports, sorry.

If all else fails, you could edit the /etc/hotplug2-common.rules file and create an entry that specifically reacts on a DEVICENAME matching ttyUSB and then exec a custom script directly with the %DEVICENAME% as argument to it. But there are some problems with this approach:

First, when using the squashfs+jffs2 build, modifying hotplug2-common.rules has no effect for first initialisation (coldplug) of the devices, since this is done before the writable jffs partition is mounted. So you either have to  use the jffs2 build or you have to compile your own and change the file in the sources.

Second, be very sure what you change in that file is correct, otherwise you could easily prevent your router from fully booting and thus effectively lock you out of your device. So before doing that, make sure you know how to enter failsafe and/or how to restore a working firmware.

Regards,
Niels Böhm

I guess the DEVPATH and SUBSYSTEM variables depend on uevents and sysfs, which are only available on 2.6 kernels.

Oh, I mistakenly assumed sailingsmoky is using a 2.6 kernel.

I am running 2.4 and I think I need to stick to that image until the wireless driver becomes stable. I've build a small patch for usbserial.c that modifies the kernel log message (... now attached to /dev/...) in a way that the FTDI Serial number is also displayed in the same message. That allows me to grep the kernel log for the serial number (which is availabe in my hotplug script) and by that getting the /devfs port where the hot-plugged serial device is attached to.
Will probably move to 2.6 and uci when it became stable.
Thank you all for commenting on this.

Regards, Peter

Note that there seems to be a size limit when using Niel's trick. I am running 8.09.1 and do not get all environment variables when looking at the log using logread.

However, dumping them to a file using something like

echo $(env) >> /tmp/dump.txt

works fine for me.