<div dir="ltr">Sorry for the slowness,<div><br></div><div>I'm going to be grid-locked for the next 5 weeks due to personal commitments so I'll be slow :( , very sorry. Code wise everything looks good, maybe I'd take out the goto's for if/else and remove the unused mm_bb_b_cinterion_init() function, but that's trivial opinion. A few things I found.</div><div><br></div><div>When I dropped the data ports we still still go into the SWWAN logic. I was trying to simulate another non-PLS8 modem, though this may be a little improper... In mm-bb-modem-cinterion.c, cinterion_modem_create_bearer() hit's the 'no data port is available' logic and then flag's SWWAN as 'not supported'. It then creates a MM_BROADBAND_MODEM instead of the CINTERION bearer but continues into the SWWAN setup logic. I worry this may not support other Cinterion modem correctly because of this. I'll diver deeper and provide more detailed findings, with a PXS8 when I can track it down, shortly but just wanted to flag it as something weird I saw.</div><div><br></div><div>Next I see that we don't always use cid:3. When testing a bad apn I saw (mmcli -m 0 --simple-connect="apn=meemememememe"):</div><div><div>ModemManager[1164]: <debug> [1481990310.650108] [mm-broadband-bearer.c:867] parse_pdp_list(): Found '8' PDP contexts</div><div>ModemManager[1164]: <debug> [1481990310.650120] [mm-broadband-bearer.c:876] parse_pdp_list(): PDP context [cid=1] [type='ipv4'] [apn='twetwetwet']</div><div>ModemManager[1164]: <debug> [1481990310.650126] [mm-broadband-bearer.c:876] parse_pdp_list(): PDP context [cid=2] [type='ipv4'] [apn='internet']</div><div>ModemManager[1164]: <debug> [1481990310.650132] [mm-broadband-bearer.c:876] parse_pdp_list(): PDP context [cid=3] [type='ipv4'] [apn='<a href="http://proxy.trimble.com">proxy.trimble.com</a>']</div><div>ModemManager[1164]: <debug> [1481990310.650138] [mm-broadband-bearer.c:876] parse_pdp_list(): PDP context [cid=4] [type='ipv4'] [apn='proxy']</div><div>ModemManager[1164]: <debug> [1481990310.650145] [mm-broadband-bearer.c:876] parse_pdp_list(): PDP context [cid=5] [type='ipv4v6'] [apn='<a href="http://apn.trimble.com">apn.trimble.com</a>']</div><div>ModemManager[1164]: <debug> [1481990310.650152] [mm-broadband-bearer.c:876] parse_pdp_list(): PDP context [cid=6] [type='ipv4'] [apn='<a href="http://apn.trimble.com">apn.trimble.com</a>']</div><div>ModemManager[1164]: <debug> [1481990310.650158] [mm-broadband-bearer.c:876] parse_pdp_list(): PDP context [cid=7] [type='ipv6'] [apn='<a href="http://apn.trimble.com">apn.trimble.com</a>']</div><div>ModemManager[1164]: <debug> [1481990310.650164] [mm-broadband-bearer.c:876] parse_pdp_list(): PDP context [cid=8] [type='ipv4'] [apn='meemememememe']</div><div>ModemManager[1164]: <debug> [1481990310.650171] [mm-broadband-bearer.c:901] parse_pdp_list(): Found PDP context with CID 8 and PDP type ipv4 for APN 'meemememememe'</div></div><div><br></div><div>I then hard power cycle the modem, kill and restart MM and it goes back to cid=3. I'm thinking this may be desired logic but wanted to confirm if bad APN's cause this?</div><div><br></div><div>Before merging I was wondering how you want to handle these things which I have solved in other branches but was waiting to solidify the core stuff we have here. I'm not sure if they should be part of this or wait until this is done and then add the features on. They are:</div><div><ul><li>Some SIM's flat out do not work and return 'unspecified gprs error' on the PLS8-X only. This is due to the modem supporting the Verizon carrier here and the Auto SIM detection of the modem. Cinterions's recommendation is to issue ''AT^SCFG=”MEopMode/Prov/Cfg”,”1” for non-Verizon SIMs and ''AT^SCFG=”MEopMode/Prov/Cfg”,”2” for Verizon SIMs. Icky I know, but it hit's this issue when you leave it set to '0' auto mode pretty often. Right now I think I was just init-ing it to '1' and waiting to figure out how to set it back to 2 for Verizon use cases.</li><li>GPS has all new cmd's. I'm assuming this will be a different branch though.</li><li>URC's, I had some stuff for over-temp/voltage added and also think I had made a stab at switching over the updating from using a polled SIND cmd to grabbing all the SIND/psinfo from it's URC. <br></li></ul></div><div><br></div><div>At the start of this upcoming work week I have some time to really do a through combing and run it through our automated suite. I'll report back in a few more days and self address some of this stuff above and provide any more findings. I didn't want to seem like I was ignoring this email :)</div><div><br></div><div>Cheers,</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 14, 2016 at 6:04 AM, Aleksander Morgado <span dir="ltr"><<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Dan, Matthew and others,<br> <br> I've pushed a couple of additional commits to the stanger/cinterion<br> branch; main changes w.r.t to the last branch suggestion are:<br> <br> * Avoid the predefined CIDs (and therefore use the generic CID<br> selection mechanism).<br> * Fix connection setup when auth settings required.<br> * Implemented connection status monitoring with AT^SWWAN?<br> <br> I've tested this myself with a PLS8-8 REVISION 03.017 and connection works here.<br> <br> Dan, how about merging this to master?<br> Matthew, can you do your own tests with the branch?<br> <span class="HOEnZb"><font color="#888888"><br> --<br> Aleksander<br> <a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a><br> </font></span></blockquote></div><br></div>