Fwd: Cinterion plugin patch

[Aleksander Morgado]

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