<div dir="ltr"><div>Hi Carlo, Aleksander,</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2017-06-28 15:10 GMT+02:00 Carlo Lobrano <span dir="ltr"><<a href="mailto:c.lobrano@gmail.com" target="_blank">c.lobrano@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><img class="gmail-m_-3288177205887392876n1-open" style="border-width: 0px; border-style: none; border-color: currentcolor; border-image: none; width: 0px; height: 0px;" width="0" height="0"><div class="gmail_quote gmail-m_-3288177205887392876nylas-quote gmail-m_-3288177205887392876nylas-quote-id-f643acb09edd63180e2de63cf31a2b6af0c07bdc7cf02a8c5078b7a213685f49"><div>(...)<br></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote gmail-m_-3288177205887392876nylas-quote gmail-m_-3288177205887392876nylas-quote-id-f643acb09edd63180e2de63cf31a2b6af0c07bdc7cf02a8c5078b7a213685f49"><div>Not really sure what's happening here, but I do remember a similar issue where adding some new debug logs, it appeared that the reply sent to PORTCFG? parser was an empty string, the thread in this mailing list is <br>"[PATCH] Hardening PORTCFG parse reply" dated mid July 2016.<br></div></div></blockquote><div><br></div><div>Thanks for this hint, yes indeed this looks very similar. There is an interesting question from Aleksander in that thread:<br><pre>><i> A long shot maybe, but did you see this issue while you were testing the SIM hotplug thing? Remember that there's an extra port open reference in that case.
</i></pre></div><div>It looks to me that the ports are being used to support bearer disconnect, at least in this case I have logs for. The bearer object holds reference to the modem and the ports and disconnection process survives physical modem re-appearence. I.e. reopening the port in data_reopen_3gpp at 1719500205.410219 succeeds at 1719500206.509531. Despite original ports disappearing in the middle (e.g. at 1719500205.440044).<br></div><div><br></div><div>I'm now testing following patch, Aleksander, could you take a look at this? This prevents disconnect to continue (and to reopen the port) if PDP context deactivation failed. Is this acceptable way to sort this out? Or should the disconnect somehow be cancelled upon device removal? I wonder why this error wasn't fatal, is there a case where it's important for this process to continue?<br><br></div><div>So far my test is ongoing for some time without errors with this, I'll keep it running over the night.<br></div><div><br>diff --git a/plugins/telit/mm-broadband-modem-telit.c b/plugins/telit/mm-broadband-modem-telit.c<br>index 5c4a6c5..af11fa3 100644<br>--- a/plugins/telit/mm-broadband-modem-telit.c<br>+++ b/plugins/telit/mm-broadband-modem-telit.c<br>@@ -566,7 +566,7 @@ modem_reset (MMIfaceModem *self,<br> {<br>     mm_base_modem_at_command (MM_BASE_MODEM (self),<br>                               "AT#REBOOT",<br>-                              3,<br>+                              8,<br>                               FALSE,<br>                               callback,<br>                               user_data);<br>diff --git a/src/mm-broadband-bearer.c b/src/mm-broadband-bearer.c<br>index aeff2ef..db38970 100644<br>--- a/src/mm-broadband-bearer.c<br>+++ b/src/mm-broadband-bearer.c<br>@@ -1586,8 +1586,10 @@ cgact_ready (MMBaseModem *modem,<br>     if (!error)<br>         ctx->cgact_sent = TRUE;<br>     else {<br>-        mm_dbg ("PDP context deactivation failed (not fatal): %s", error->message);<br>-        g_error_free (error);<br>+        mm_dbg ("PDP context deactivation failed: %s", error->message);<br>+        g_simple_async_result_take_error (ctx->result, error);<br>+        detailed_disconnect_context_complete_and_free (ctx);<br>+        return;<br>     }<br> <br>     data_reopen_3gpp (ctx);<br><br></div></div></div></div></div></div>