[RFC] stanger/cinterion branch

[matthew stanger]

>
> What do you guys think we should do?


My two cents is that CME's in the AT doc that are the results from SWWAN
test would always equate to a disconnected modem state. That being said
would there a way the at_command_finish() could result in an error that was
not due to the AT response it's self, as an error like that I don't think
should necessarily cause a disconnect. Given the next bit below, I can
understand if others want a different direction and we can always tweak
special needs of ours in our repo.

I agree that pulling the SIM is a bad idea, but for us, we have our modems
bolted to 25 megagram heavy machines with super strong impact & g-forces.
In addition to designing for this, it's good at the software layer to know
if a card has wiggled it's way out in near real time and thus the machine
no longer as a data connection. That may not be a fair requirement to all
though x). I've been wanting to give a little more info on what we are
using MM for at Trimble and as soon as they make the formal product
announcement I will give you the scoop, if you want to add that to any MM
in industry write ups or something then you'll have that nice little bit :)

On Thu, Dec 22, 2016 at 2:10 AM, Aleksander Morgado <
aleksander at aleksander.es> wrote:

> On Wed, Dec 21, 2016 at 5:14 PM, matthew stanger <stangerm2 at gmail.com>
> wrote:
> >> What's the output of the SWWAN status check when the SIM is gone? is
> >> it saying "ERROR"?
> >
> >
> >   response = mm_base_modem_at_command_finish (modem, res, &error);
> >
> >     if (!response) {
> >
> >         mm_dbg ("response:'%s' error:'%s'", response, error->message);
> >
> >
> > Taking SIM out during connection produced:
> >
> > ModemManager[9779]: <debug> [1482336593.250840] [mm-port-serial-at.c:459]
> > debug_log(): (ttyACM1): --> 'AT^SWWAN?<CR>'
> > ModemManager[9779]: <debug> [1482336593.274427] [mm-port-serial-at.c:459]
> > debug_log(): (ttyACM1): <-- '<CR><LF>+CME ERROR: 10<CR><LF>'
> > ModemManager[9779]: <debug> [1482336593.274506] [mm-serial-parsers.c:364]
> > mm_serial_parser_v1_parse(): Got failure code 10: SIM not inserted
> > ModemManager[9779]: <debug> [1482336593.274541]
> > [cinterion/mm-broadband-bearer-cinterion.c:108]
> swwan_check_status_ready():
> > response:'(null)' error:'SIM not inserted'
> > ModemManager[9779]: <warn>  [1482336593.274563] [mm-base-bearer.c:165]
> > load_connection_status_ready(): checking if connected failed: SIM not
> > inserted
>
> Thanks.
>
> So now we have to decide how to handle this in the "connection status
> checks" we do. Right now the checks return either: connected,
> disconnected or error. In the case of error we do nothing, just log
> it, but maybe we should trigger a disconnection right away as well? Or
> just handle those errors in the checker method itself and return
> "disconnected" without error?
>
> If we decide that the generic plugin should treat some errors as fatal
> (i.e. report disconnected after the error) and some not (just log the
> error message), we'd need to decide which error is which. E.g. of
> non-fatal errors could be a modem that doesn't support the specific
> command being used to check connectivity (e.g. while other devices of
> the same vendor do), or also the errors we currently get when trying
> to check connection status on a modem with one single AT port (as
> there's no free port to run the AT command during connection).
>
> What do you guys think we should do?
>
> P.S.: or just don't take out the SIM while connected... :)
>
> --
> Aleksander
> https://aleksander.es
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20161222/a9fb3870/attachment.html>