<div dir="auto">Makes sense (origin of the behavior). <div dir="auto"><br></div><div dir="auto">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. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 29, 2020, 1:30 AM Aleksander Morgado <<a href="mailto:aleksander@aleksander.es">aleksander@aleksander.es</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey,<br>
<br>
><br>
> 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.<br>
><br>
<br>
The original implementation was done to support RS232 modems, as<br>
looking at the AT command timeouts was the only way to detect that a<br>
modem was gone. But it really has shown to be useful also for USB<br>
modems as the "stale AT port" issue is something we've seen multiple<br>
times in the past years.<br>
<br>
> I will try to get a device in this failed state and diagnose why it is not being released.<br>
><br>
<br>
I believe it's easy to "force" this situation; just run a minicom<br>
session on the TTY you want to break while ModemManager is already<br>
using the port. Running minicom on a TTY that MM is already using will<br>
"hijack" all the responses for the commands sent by MM (i.e. MM sends<br>
command, minicom gets the response), which is kind of similar of what<br>
would happen if the AT port goes silent by itself.<br>
<br>
-- <br>
Aleksander<br>
<a href="https://aleksander.es" rel="noreferrer noreferrer" target="_blank">https://aleksander.es</a><br>
</blockquote></div>