<div dir="ltr"><div class="gmail_default"><div class="gmail_default"><font face="arial, helvetica, sans-serif">> Hum... not sure this approach is the correct one. If you store the</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> GSimpleAsyncResult and not complete it the whole logic in the</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> MMIfaceModem will get stuck until it is completed afterwards.</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">Ok, the approach might still be wrong (and even more wrong :D), but I only save the GSimpleAsyncResult for later, I do not stop the call, which is completed with the usual error messages.</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> What I was thinking regarding this issue was to define a common error</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> id, like "MM_CORE_ERROR_RETRY_LATER". If the logic (e.g. MMIfaceModem</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> logic) receives such an error, it would re-schedule the execution of</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> that step later on, in X seconds, but would still continue with the</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> remaining steps in the logic it has. But this is really very specific to</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> what we're loading, as not all steps may be retried later.</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">></font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> For the specific case of loading unlock retries... does it make sense</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> for us to report e.g. that the modem is "locked" but without being able</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> to report the unlock retries left after some time later? From a user</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> point of view, I'm sure that an application that receives notification</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> that the modem is locked would expect right away to know the amount of</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> unlock retries left, if we report that several seconds later the</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> information will likely not be used at all.</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">></font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> So I'm not sure whether this makes sense; waiting for "QSS: 3"</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> guarantees that we'll be able to read unlock retries; but maybe it's</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> just cleaner to perform several retries trying to load them as that may</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> be quicker than waiting for "QSS: 3"... it really is very unfortunate</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">> that this notification takes so long to be emitted :/</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">I see. I've seen a similar approach in port probing, but I thought that retrying before #QSS:3 didn't have much sense.</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">I like the idea of the error code though, and yes you're right saying that this information should arrive as soon as possible, however, consider that this problem occurs only with a specific SIM vendor and only for PIN2 and PUK2.</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">I'm gonna develop this idea further, since I really like to have something generic and applicable also to other commands that return with SIM Busy error.</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 May 2017 at 12:23, Aleksander Morgado <span dir="ltr"><<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey hey,<br>
<span class=""><br>
On 12/05/17 16:18, Carlo Lobrano wrote:<br>
> ​> Maybe it wouldn't be a bad idea to keep track of which operations may<br>
>> fail due to SIM being busy, and perform automatic retry later if we<br>
>> get that specific error, something like that.<br>
> Hey,<br>
><br>
> I made a little proof of concept of this improvement. So far, it's<br>
</span>> restricted to *loading unlock retries again once #QSS:3* is received, but I<br>
<span class="">> can't get to have the retries values updated at a higher level. This is<br>
</span>> likely due to *mm-iface-modem.c:load_unlock_<wbr>retries_ready* callback not<br>
<span class="">> being called I guess, but I'm not really sure my approach is totally<br>
> correct.<br>
><br>
> I do the following:<br>
><br>
> A. When mm_telit_parse_csim_response fails:<br>
</span>>     1. The *GSimpleAsyncResult* instance is saved<br>
<span class="">>     2. load_unlock_retries is marked to be called again later<br>
> B. When QSS: 3 arrives:<br>
</span>>     1. a newly *LoadUnlockRetriesContext* is created using the saved<br>
> *GSimpleAsyncResult* (the idea is to re-use the original callback<br>
<span class="">> reference, but not really sure it's correct).<br>
</span>>     2. *load_unlock_retries_step* is called again with the above mentioned<br>
<span class="">> LoadUnlockRetriesContext instance<br>
><br>
> Step 2 is done in a GSourceFunc called by the mainloop, using g_add_idle.<br>
<br>
</span>Hum... not sure this approach is the correct one. If you store the<br>
GSimpleAsyncResult and not complete it the whole logic in the<br>
MMIfaceModem will get stuck until it is completed afterwards. The logic<br>
in MMIfaceModem goes step by step, if one step takes 5 minutes to<br>
complete, the next steps won't go on until that happens.<br>
<br>
What I was thinking regarding this issue was to define a common error<br>
id, like "MM_CORE_ERROR_RETRY_LATER". If the logic (e.g. MMIfaceModem<br>
logic) receives such an error, it would re-schedule the execution of<br>
that step later on, in X seconds, but would still continue with the<br>
remaining steps in the logic it has. But this is really very specific to<br>
what we're loading, as not all steps may be retried later.<br>
<br>
For the specific case of loading unlock retries... does it make sense<br>
for us to report e.g. that the modem is "locked" but without being able<br>
to report the unlock retries left after some time later? From a user<br>
point of view, I'm sure that an application that receives notification<br>
that the modem is locked would expect right away to know the amount of<br>
unlock retries left, if we report that several seconds later the<br>
information will likely not be used at all.<br>
<br>
So I'm not sure whether this makes sense; waiting for "QSS: 3"<br>
guarantees that we'll be able to read unlock retries; but maybe it's<br>
just cleaner to perform several retries trying to load them as that may<br>
be quicker than waiting for "QSS: 3"... it really is very unfortunate<br>
that this notification takes so long to be emitted :/<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Aleksander<br>
<a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a><br>
</font></span></blockquote></div><br></div>