Change USB ttyACMx modem after reconnecting
I am connecting a Gemalto (Cinterion) modem via USB to my embedded Linux (2.6.31) by running BusyBox and mdev.
The modem creates ttyACM [0-6], where '0' is used for pppd. I get this and reconnect from time to time (1 hour, 1 day ...). The whole system is more complicated - another built-in device is connected to the modem on the RS232 interface, bla-bla-bla.
My problem:
When disconnecting and reconnecting occurs, pppd is not fast enough to die and release ttyACM0, so ttyACMs are created [1-7]. Next time it could be [0, 2-7] or [3-8], no specific algorithm for it.
I tried to update simlink (to / dev / ttyMyModem) but the same "no specific algorithm" ... all interfaces are the same - CDC-ACM (right ???).
My current approach:
A bash script, terminating pppd, with an infinite loop, waiting for pppd to exit (which remains in the foreground, "nodetach" in my options file). When pppd dies, I uninstall the driver (modprobe -r cdc_acm), remove all nodes (rm / dev / ttyACM *), reinstall the driver (modprobe cdc_acm), and start pppd. I put a 1-2 second delay between what was needed.
This solution takes 2-4 iterations to reconnect (not sure why it doesn't work at first) but seems stable.
My question is:
- Am I reinventing the wheel?
- Is this solution stable? Good for production?
- Have I missed the "buzz" in my Google search?
Please don't hesitate with me ...
source to share
I don't have enough answers to ask in the comment section, so I have to ask about it here. When you say you update a symbolic link, are you talking about udev rules? I have the same problem with printers, scanners, etc. In my program I am using "udevadm info --export-db" to read the correct devpath for my devices as soon as I get a write / read error. I close the file descriptor and reopen it on a new device. Have you tried to stop the shutdown? I couldn't do it myself, but you could try disabling AutoArt. use the usbcore.autosuspend = -1 option and:
for i in /sys/bus/usb/devices/usb*/power/control; do echo "on" > $i; done
Hope it helps. IMHO, your solution is fairly stable. I am used to such strange "solutions" that work in automation systems.
source to share