Makes sense (origin of the behavior). I have seen that behavior with opening the serial port (had to get the modem expert on my team to stop doing that and run commands through mmcli). I don't think I waited long enough for ten failures.
On Thu, Oct 29, 2020, 1:30 AM Aleksander Morgado <[email protected]> wrote: > Hey, > > > > > It is good to know that this has been considered in the core design. I > agree that there should be no modem specific behavior for this. > > > > The original implementation was done to support RS232 modems, as > looking at the AT command timeouts was the only way to detect that a > modem was gone. But it really has shown to be useful also for USB > modems as the "stale AT port" issue is something we've seen multiple > times in the past years. > > > I will try to get a device in this failed state and diagnose why it is > not being released. > > > > I believe it's easy to "force" this situation; just run a minicom > session on the TTY you want to break while ModemManager is already > using the port. Running minicom on a TTY that MM is already using will > "hijack" all the responses for the commands sent by MM (i.e. MM sends > command, minicom gets the response), which is kind of similar of what > would happen if the AT port goes silent by itself. > > -- > Aleksander > https://aleksander.es >
_______________________________________________ ModemManager-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
