trying to connect to different operators using --3gpp-register-in-operator

[Marcel]

Sorry for the spam, I just have another question which I forgot before:
Can I find all the AT-commands in the log?

Because I was reading a lot there and I was not quite sure.. to me it 
looks like if there are also some commands without an 'AT'. Sorry if 
that's a dumb question, but I haven't been working with such stuff before.


Am 14.12.2017 um 11:29 schrieb Marcel:
>
> Hey,
>
>> On Fri, Dec 8, 2017 at 6:29 PM, Marcel<mahik18 at gmx.de>  wrote:
>>> Do you think it could help if I provide you another log of an execution of
>>> my script with specific parameters? Or should I go through my logs searching
>>> for specific parts? I'm not really sure what I should look for.
>>>
>>> Is there anything I could do to stabilize the network switching? Maybe do
>>> some stuff between the connects? Or quickly restart the mm? Would it help to
>>> quickly stop the mm and then start again? Or is it even the modem which is
>>> busy, so the mm doesn't have to do anything with the error?
>>>
>> At this point I would maybe suggest to run the steps manually e.g. in
>> minicom; and try to see why the registration in that last operator
>> takes so long. But one thing I would definitely do is leave more than
>> 15s for the whole connection process, especially when registration in
>> a different network is involved.
>>
> Aah, sorry I answered to that in my last mail already(summarized: 
> already tried timeouts of 50 seconds and tried to connect up to 8 
> times with that 50 seconds timeout, I also don't really know which AT 
> commands are used for simple-connect [or even any of the mmcli 
> commands] which is why I actually used mmcli):
>
> -->
>
> Hey,
>
>> In your logs I see a connection attempt with an explicit operator id
>> (26203) at 1511990328.384995. The logic goes through the manual
>> registration process, trying to get registered in that specific
>> network. At 1511990345.704504 I see another connection attempt to the
>> same operator, that is approx 17s after the previous attempt.
>> Are you waiting some specific time between connection attempts?
> Yes, I'm using the simple-connect function with a 15 sec timeout.
> The first operator 26201 connects without any problems at all, then 
> when disconnecting and connecting to 26202, the first, maybe also the 
> second try to simple-connect fails. But then when I disconnect again 
> from 26202 and try to connect to 26203 again it just won't connect.
> It seems like the mm is still busy doing some other stuff in the 
> background.
> At the end of my script, I disconnect again and disable the modem. 
> Disconnecting works fine, but the modem doesn't disable, but seems to 
> hang on state 'disabling'. Around 1 minute after my script finished 
> the mm seems to be done with its background stuff and disables the modem.
>> Those two attempts seem too close to each other. You should leave 
>> much more
>> time for the connection attempt to go on, because re-registration in a
>> different operator, especially when doing it manually, may take some
>> time. The logs show that the registration in the operator didn't
>> happen in those 17s, and it looks like the actual COPS command used to
>> request manual registration didn't reply in that time either. Are you
>> able to manually reproduce these issues running the AT commands in
>> minicom?
> Well I just tried a script setup with 8 tries to connect each with a 
> 50 seconds timeout, same result, operators 26201 and 26202 worked 
> perfectly, 26203 didn't succeed at any of the 8 connect attempts.
> I also tried a setup with a 15 seconds timeout and a 60 second sleep 
> between each operator with the same result.
> And right now I tried a setup where I also used the 
> 3gpp-register-in-operator function, but that didn't work either.
> Weell about the reproduction with AT commands: I'm don't really know 
> which commands I would have to use, I already thought about just doing 
> the whole script with AT commands, but then I recognized that it's a 
> lot more complicated than I thought and so I just used mmcli which 
> already is very simple and efficient.
> So about that, I'm sorry, but no, I unfortunately can't reproduce the 
> issues, sorry.
>
> (PS: I'm sorry for always answering to your mails directly without 
> ccing the mm list!)
>
>
>
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20171214/f45fa4fa/attachment.html>