<div dir="ltr"><div>Aleksander,</div><div> </div><div>I ran the code a few thousand times for connecting -> data connection -> disconnect through our CI suite. That looks good. However I did find during a better manual testing that if you remove the SIM while a data connection is up the dbus API isn't updated with the disconnect event.</div><div> </div><div>In:</div><div> swwan_check_status_ready()</div><div> ....</div><div> <pre style="margin-top:0px;margin-bottom:0px"> response = mm_base_modem_at_command_finish (modem, res, &error);</pre> <pre style="margin-top:0px;margin-bottom:0px"> if (!response) {</pre> <pre style="margin-top:0px;margin-bottom:0px"> g_task_return_error (task, error);</pre> <pre style="margin-top:0px;margin-bottom:0px"> goto out;</pre> <pre style="margin-top:0px;margin-bottom:0px"> }</pre></div><div> </div><div>We fall into this and exit without updating the status. I think it should be:</div><div> <pre style="margin-top:0px;margin-bottom:0px"> g_task_return_int (task, (gssize) MM_BEARER_CONNECTION_STATUS_DISCONNECTED);</pre> <pre style="margin-top:0px;margin-bottom:0px"> </pre></div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I have no idea how that could happen.</blockquote><div> </div><div>Test weird ways, get weird problems lol. I tracked this down to the very weird way I tested, which wasn't valid in the end so disregard. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In which step do you get the "unspecified gprs error"?</blockquote><div> </div><div>Not in a step but in a setup, using non-OEM SIMs. The guy's at Cinterion told us to try and set this value manually based on the ICCID :0, yikes. This is only really a problem for USA users using non-OEM SIMs, so it may not be a problem that needs to be solved. I.E. we will have to since we have custom SIMs for both Ver & AT&T, but the main MM user's may never run into this. I guess knowing that do you think it's important to figure out something in the MM scope or should it just be handled on it's own by users in this corner case?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We don't have API members for over-temp or voltage info </blockquote><div>It was just putting it in logs so we would know for field failures. Nothing special. </div><div> </div><div> </div><div>Other than that this looks solid. Exciting times!</div><div> </div></div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Dec 20, 2016 at 4:08 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">Hey! On Sat, Dec 17, 2016 at 5:19 PM, matthew stanger <<a href="mailto:stangerm2@gmail.com">stangerm2@gmail.com</a>> wrote: > Sorry for the slowness, > No worries. > 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. > gotos are really fine for error exits; I wouldn't be scared of them :) And if I'm not mistaken mm_broadband_bearer_cinterion_init() is actually required by the GObject system even if empty. > 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. > I have no idea how that could happen. The Cinterion bearer is created only when SWWAN is supported and there is a net port. If any of those things doesn't happen we create a generic bearer, which doesn't have any "swwan setup logic". What do you mean with "but continues into the SWWAN setup logic"? I've tested the plugin with a Cinterion EGS5 (AT+PPP only) and it worked correctly: ModemManager[26454]: <info> [1482231115.463363] [mm-iface-modem-simple.c:469] connection_step(): Simple connect state (4/8): Wait to get fully enabled ModemManager[26454]: <info> [1482231115.463384] [mm-iface-modem-simple.c:478] connection_step(): Simple connect state (5/8): Register ModemManager[26454]: <debug> [1482231115.463406] [mm-iface-modem-3gpp.c:437] mm_iface_modem_3gpp_register_in_network(): Already registered in network '21401', automatic registration not launched... ModemManager[26454]: <info> [1482231115.463429] [mm-iface-modem-simple.c:501] connection_step(): Simple connect state (6/8): Bearer ModemManager[26454]: <debug> [1482231115.463441] [mm-iface-modem-simple.c:521] connection_step(): Creating new bearer... ModemManager[26454]: <debug> [1482231115.463455] [cinterion/mm-broadband-modem-cinterion.c:1802] cinterion_modem_create_bearer(): skipping ^SWWAN check as no data port is available ModemManager[26454]: <debug> [1482231115.463464] [cinterion/mm-broadband-modem-cinterion.c:1740] common_create_bearer(): ^SWWAN not supported, creating default bearer... ModemManager[26454]: <debug> [1482231115.463586] [mm-port-serial.c:1288] mm_port_serial_open(): (ttyACM0) device open count is 2 (open) ModemManager[26454]: <debug> [1482231115.463604] [mm-port-serial.c:1345] _close_internal(): (ttyACM0) device open count is 1 (close) ModemManager[26454]: <debug> [1482231115.463641] [cinterion/mm-broadband-modem-cinterion.c:1699] cinterion_modem_create_bearer_finish(): New bearer created at DBus path '/org/freedesktop/ModemManager1/Bearer/1' ModemManager[26454]: <info> [1482231115.463725] [mm-iface-modem-simple.c:583] connection_step(): Simple connect state (7/8): Connect ModemManager[26454]: <debug> [1482231115.463741] [mm-base-bearer.c:801] mm_base_bearer_connect(): Connecting bearer '/org/freedesktop/ModemManager1/Bearer/1' ModemManager[26454]: <info> [1482231115.463758] [mm-iface-modem.c:1431] __iface_modem_update_state_internal(): Modem /org/freedesktop/ModemManager1/Modem/1: state changed (registered -> connecting) ModemManager[26454]: <debug> [1482231115.463876] [mm-broadband-bearer.c:1342] connect(): Launching 3GPP connection attempt with APN '<a href="http://ac.vodafone.es" rel="noreferrer" target="_blank">ac.vodafone.es</a>' ModemManager[26454]: <debug> [1482231115.463893] [mm-broadband-bearer.c:951] cid_selection_3gpp(): Looking for best CID... ModemManager[26454]: <debug> [1482231115.463907] [mm-port-serial.c:1288] mm_port_serial_open(): (ttyACM0) device open count is 2 (open) ModemManager[26454]: <debug> [1482231115.463931] [mm-port-serial-at.c:459] debug_log(): (ttyACM0): --> 'AT+CGDCONT?<CR>' ModemManager[26454]: <debug> [1482231115.481730] [mm-port-serial-at.c:459] debug_log(): (ttyACM0): <-- '<CR><LF>OK<CR><LF>' ModemManager[26454]: <debug> [1482231115.481798] [mm-broadband-bearer.c:859] parse_pdp_list(): No PDP contexts found ModemManager[26454]: <debug> [1482231115.481869] [mm-broadband-bearer.c:793] parse_cid_range(): Using empty CID 1 with PDP type 'ipv4' ModemManager[26454]: <debug> [1482231115.481894] [mm-port-serial.c:1288] mm_port_serial_open(): (ttyACM0) device open count is 3 (open) ModemManager[26454]: <debug> [1482231115.481916] [mm-port-serial.c:1345] _close_internal(): (ttyACM0) device open count is 2 (close) ModemManager[26454]: <debug> [1482231115.481934] [mm-port-serial-at.c:459] debug_log(): (ttyACM0): --> 'AT+CGDCONT=1,"IP","<a href="http://ac.vodafone.es" rel="noreferrer" target="_blank">ac.vodafone.es</a>"<CR>' ModemManager[26454]: <debug> [1482231115.525883] [mm-port-serial-at.c:459] debug_log(): (ttyACM0): <-- '<CR><LF>OK<CR><LF>' ModemManager[26454]: <debug> [1482231115.525988] [mm-port-serial.c:1288] mm_port_serial_open(): (ttyACM0) device open count is 3 (open) ModemManager[26454]: <debug> [1482231115.526016] [mm-broadband-bearer.c:222] common_get_at_data_port(): Connection through a plain serial AT port (ttyACM0) ModemManager[26454]: <debug> [1482231115.526051] [mm-port-serial.c:1288] mm_port_serial_open(): (ttyACM0) device open count is 4 (open) ModemManager[26454]: <debug> [1482231115.526083] [mm-port-serial.c:1345] _close_internal(): (ttyACM0) device open count is 3 (close) ModemManager[26454]: <debug> [1482231115.526112] [mm-port-serial-at.c:459] debug_log(): (ttyACM0): --> 'ATD*99***1#<CR>' ModemManager[26454]: <debug> [1482231116.994385] [mm-port-serial-at.c:459] debug_log(): (ttyACM0): <-- '<CR><LF>CONNECT<CR><LF>' ModemManager[26454]: <debug> [1482231116.994536] [mm-port-serial.c:1345] _close_internal(): (ttyACM0) device open count is 2 (close) ModemManager[26454]: <debug> [1482231116.994598] [mm-port.c:94] mm_port_set_connected(): (ttyACM0): port now connected ModemManager[26454]: <debug> [1482231116.994636] [mm-base-bearer.c:699] connect_ready(): Connected bearer '/org/freedesktop/ModemManager1/Bearer/1' ModemManager[26454]: <info> [1482231116.994821] [mm-iface-modem.c:1431] __iface_modem_update_state_internal(): Modem /org/freedesktop/ModemManager1/Modem/1: state changed (connecting -> connected) ModemManager[26454]: <info> [1482231116.995127] [mm-iface-modem-simple.c:602] connection_step(): Simple connect state (8/8): All done I've also tested it with a PHS8-P but that runs by default in QMI mode so unrelated. <div><div class="h5"> > 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"): > ModemManager[1164]: <debug> [1481990310.650108] [mm-broadband-bearer.c:867] > parse_pdp_list(): Found '8' PDP contexts > ModemManager[1164]: <debug> [1481990310.650120] [mm-broadband-bearer.c:876] > parse_pdp_list(): PDP context [cid=1] [type='ipv4'] [apn='twetwetwet'] > ModemManager[1164]: <debug> [1481990310.650126] [mm-broadband-bearer.c:876] > parse_pdp_list(): PDP context [cid=2] [type='ipv4'] [apn='internet'] > 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" rel="noreferrer" target="_blank">proxy.trimble.com</a>'] > ModemManager[1164]: <debug> [1481990310.650138] [mm-broadband-bearer.c:876] > parse_pdp_list(): PDP context [cid=4] [type='ipv4'] [apn='proxy'] > 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" rel="noreferrer" target="_blank">apn.trimble.com</a>'] > 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" rel="noreferrer" target="_blank">apn.trimble.com</a>'] > 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" rel="noreferrer" target="_blank">apn.trimble.com</a>'] > ModemManager[1164]: <debug> [1481990310.650164] [mm-broadband-bearer.c:876] > parse_pdp_list(): PDP context [cid=8] [type='ipv4'] [apn='meemememememe'] > 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' > > 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>If you're trying to connect to an APN which already exists in the list of APNs stored, then you'll re-use the CID. If you're connecting to a new APN, then we'll try to create a new PDP context on another CID. > 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: > > 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. In which step do you get the "unspecified gprs error"? Could you ask them more clarification of what each of those Cfg values does? > GPS has all new cmd's. I'm assuming this will be a different branch though. Yes, different branch please :) > 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. > We don't have API members for over-temp or voltage info; although we could add them definitely. Suggestions of API updates welcome :) > > 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 :) > Thanks for doing this :) -- Aleksander <a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a> </blockquote></div> </div>