Fwd: Cinterion plugin patch

[matthew stanger]

>
> Ah, yeah. If the plugin does its own logic to select which CID to use,
> it should not rely on the parent's connection status check. In our
> case, though, I think we should default back to letting the generic
> logic decide the CID to use (i.e. don't fix to use the CIDs 1 and 3).
> If we do so, we could avoid subclassing the whole connect_3gpp()
> sequence and instead subclass some of its sub-steps, like
> dial_3gpp()).


I agree I think using the default CID method would be best but we'd have to
have something in there to default to CID 3 for Verizon or none of the -X
modems will work with that carrier for LTE. Feels like some Internet
Explorer 7 style requirements but they are the largest carrier here in the
US. The documentation for this is in the AT datasheet but I can't share it
directly. I did just link you into an email with Cinterion asking for them
to provide you one so hopefully that will work out and you'll have one soon.

On Mon, Nov 28, 2016 at 9:29 AM, Aleksander Morgado <
aleksander at aleksander.es> wrote:

> On Sun, Nov 27, 2016 at 4:27 AM, matthew stanger <stangerm2 at gmail.com>
> wrote:
> > Sorry I sent that last email a little prematurely, was still targeting my
> > email client and ctrl-entered for another window. You can disregard that
> > second comment, I see what you did for IP config. Last little things:
> >
> >>     /* Get a tet port to setup the connection on */
> >>
> >>
> >
> > net*
> >
>
> Fixed in the branch.
>
> > There is also some spam warning messages in the logs every 30 secs. I
> > believe it's related to the new connection status monitory you recently
> > added. I'm guessing because we have the custom code for cgdcont/cid in
> the
> > Cinterion bearer and it's not getting populated for the mm-base-bearer?
> Not
> > an issue but just thought I'd mention it.
> >
> > <debug> [1480215431.485739] [mm-iface-modem.c:1204]
> update_signal_quality():
> > Modem /org/freedesktop/ModemManager1/Modem/0: signal quality updated
> (40)
> > <warn>  [1480215435.426725] [mm-base-bearer.c:165]
> > load_connection_status_ready(): checking if connected failed: Couldn't
> load
> > connection status: cid not defined
> > <warn>  [1480215440.428026] [mm-base-bearer.c:165]
> > load_connection_status_ready(): checking if connected failed: Couldn't
> load
> > connection status: cid not defined
> > <warn>  [1480215445.427338] [mm-base-bearer.c:165]
> > load_connection_status_ready(): checking if connected failed: Couldn't
> load
> > connection status: cid not defined
> > <warn>  [1480215450.427193] [mm-base-bearer.c:165]
> > load_connection_status_ready(): checking if connected failed: Couldn't
> load
> > connection status: cid not defined
> > <warn>  [1480215455.427746] [mm-base-bearer.c:165]
> > load_connection_status_ready(): checking if connected failed: Couldn't
> load
> > connection status: cid not defined
> > <warn>  [1480215460.426707] [mm-base-bearer.c:165]
> > load_connection_status_ready(): checking if connected failed: Couldn't
> load
> > connection status: cid not defined
> > <debug> [1480215461.423502] [mm-port-serial.c:1288]
> mm_port_serial_open():
> > (ttyACM1) device open count is 2 (open)
>
> Ah, yeah. If the plugin does its own logic to select which CID to use,
> it should not rely on the parent's connection status check. In our
> case, though, I think we should default back to letting the generic
> logic decide the CID to use (i.e. don't fix to use the CIDs 1 and 3).
> If we do so, we could avoid subclassing the whole connect_3gpp()
> sequence and instead subclass some of its sub-steps, like
> dial_3gpp()).
>
> --
> Aleksander
> https://aleksander.es
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20161128/a573b215/attachment.html>