<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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()).</blockquote><div> </div><div>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.</div></div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Nov 28, 2016 at 9:29 AM, Aleksander Morgado <<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Nov 27, 2016 at 4:27 AM, matthew stanger <<a href="mailto:stangerm2@gmail.com">stangerm2@gmail.com</a>> 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. <div><div class="h5"> > 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) </div></div>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 <a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a> </blockquote></div> </div>