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 ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
