> > No idea what else to do to solve this I'm afraid... :/ Maybe we could > > extend the logic and add some automatic recovery mechanism to reset > > the modem using the secondary port if we end up seeing that the > > primary port is stuck like that? That wouldn't be ideal, but I assume > > it's better to have one modem reset than having MM flag the modem as > > failed. > > I am afraid I cannot give a suggestion here. I am just an MM user. Could you > offer some advice for me how to work around the issue? > We are dealing with a fleet of edge devices with a GSM only connection. So it > is crucial for them to recover after such an issue. > I could implement a watchdog service that detects the issue and resolves it. > The question is how to detect and how to resolve. > Without any further knowledge I could: > > Detect the issue by frequently executing mmcli -L to see if the modem has > disappeared > Resolve it by restarting the ModemManager service. > > Does that sound reasonable? If there is a more elegant way to do it please > let me know. >
I assume the issue is "solved" by restarting ModemManager just because we end up using the previously secondary TTY as primary, but if that gets also stuck, you may end up with the device completely stuck. A better approach would be to detect that the primary control port is stuck, and if there is a valid secondary port, try to run a modem reset automatically using that secondary port. Would you be able to draft a MM patch doing that? -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
