I’m requesting help configuring a Sierra Wireless GL7500 so that it will hot plug. I’m working with a system for which the USB cell modem can be momentarily unplugged and plugged, and we need to recover cell service when that happens. The modem was set up according to your knowledge base article: link text I’ve attached a log file with the output of mmcli and other utilities to show the behavior through a link text disconnect/reconnect of the modem.
Basically, after the disconnect the cell modem enumerates as a different device, it is reinstantiated as a new modem object with a new bearer object. NetworkManager fails to connect the bearer. Hopefully this is a simple configuration issue that you can help me with!
Greetings @deltamike,
Just to clarify, the modem is hot-plugging, it’s just not hot-plugging consistently as the same device, correct? Hmm so I’m not quite sure yet of the exact issue off the top of my head, but I have some ideas and things to check.
First idea, it might be possible that when you remove the modem, it’s not being “cleanly” removed from the system. Then when you re-plug it it enumerates differently since “something” still remains from the initial enumeration. Though this bring up another question, when you unplug and replug the modem again does it then enumerate differently a 3rd time?
Another idea, is it might be possible to create some sort of udev rule that enumerates the modem consistently, though this might require some research on the specifics.
Finally is there and additional logs when plugging and unplugging the modem? Perhaps from dmesg?
Best Regards,
Jeremias
Jeremias,
Thanks, you’re correct it is hot plugging. It is consistently incrementing the USB Device at every drop-out.
The modem object seems to increment consistently as well. Both these number reset to 0 when the system is rebooted. The id for the bearer also increments but doesn’t seem to reset at boot. In the attached filtered dmesg logs I broke the connection twice. I filtered dmesg log from boot so you’ll see all the events repeat.
The USB Device incremented by 2, the modem incremented by 2. After a long delay, the bearer object finally showed up at id 590! At least this time it was connected. It does not seem to connect all the time though, but perhaps there just a very long delay.
We don’t have control over how long the interruption will be, but can be very short.
Here are the logs:link text
Despite the fact that the modem will sometimes reconnect after a dropout, more often than not it fails to connect.
I did some research to see if I can find any similar issues as yours with hot-plug and modem-manager.
I managed to find this: ModemManager Hotplug script: Request for review - Community Builds, Projects & Packages - OpenWrt Forum
Seems this person restarts ModemManager on hotplug event. Not quite sure if this might do anything for your case.
Best Regards,
Jeremias
Thanks! I will check this out and see if it works for us. If I can come up with a udev fix, I’ll let you know.
If you resolve I would ask if you could please share your solution. We only test a handful of modems internally. So for any niche or side-cases like this it would be helpful for us and other customers, if you share your findings/solutions.
Sounds good, I’ll considered this thread resolved for now then.
In the end, we went with PPP instead of NetworkManager/ModemManager, as pppd has options for controlling retries, as does the system service file that controls the associated ppp@provider service. This works for us as the cell modem is the primary communication device for the device. It’s not as important to manage multiple IP devices as it is to keep the primary device going. I’ll probably have new question about why we’re seeing modem drop-outs.
