3

I'm connecting a Gemalto (Cinterion) modem, by USB, to my Embedded Linux (2.6.31), running BusyBox and mdev.

The modem creates ttyACM [0-6], where '0' is used for the pppd. I'm getting dis and re-connections every now and then (1 hour, 1 day...). The whole system is more complex - another embedded device is connected to the modem on a RS232 interface, bla-bla-bla.

My problem:

When a disconnect and reconnect occur, the pppd isn't quick enough to die and free ttyACM0, so ttyACM [1-7] are created. Next time it may be [0, 2-7] or [3-8], no concrete algorithm to it.

I tried updating a simlink (to /dev/ttyMyModem), but the same 'no concrete algorithm' issue... all the interfaces are the same - CDC-ACM (are they not???).

My current approach:

A bash script, wrapping pppd, with an endless loop, waiting on the exit of the pppd (which stays in foreground, "nodetach" in my options file). When pppd dies I remove the driver (modprobe -r cdc_acm), delete all nodes (rm /dev/ttyACM*), reinstall the driver (modprobe cdc_acm) and run the pppd. I put 1-2 second delays between what was needed.

This solution takes 2-4 iterations to reconnect (don't know why it doesn't work on the first), but seems stable.

My question:

  • Am I inventing the wheel?
  • Is this solution stable? Good for production?
  • Have I missed a 'buzz word' on my search in Google?

Please don't be harsh with me...

Rami Rosenbaum
  • 467
  • 5
  • 18

1 Answers1

0

I don't have enough rep to ask in the comments section, so I must ask this here. When you say that you update the symlink you are talking about the udev rules? I have the same problem with printers, scanners and such. In my program I use "udevadm info --export-db" to read the correct devpath for my devices once I get a write/read error. I close the file descriptor and re-open it on the new device. Have you tried to stop the disconnection? I was unable to do it myself, but you could try to disable the autosusped. use the usbcore.autosuspend=-1 kernel option and:

for i in /sys/bus/usb/devices/usb*/power/control; do echo "on" > $i; done

Hope that helps. IMHO your solution is stable enough. I am used to this kind of weird "solutions" working in automation systems.

Gustavo da Silva Serra
  • 200
  • 2
  • 5