Hey! On Sat, Dec 17, 2016 at 5:19 PM, matthew stanger <stange...@gmail.com> 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 'ac.vodafone.es' 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","ac.vodafone.es"<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. > 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='proxy.trimble.com'] > 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='apn.trimble.com'] > ModemManager[1164]: <debug> [1481990310.650152] [mm-broadband-bearer.c:876] > parse_pdp_list(): PDP context [cid=6] [type='ipv4'] > [apn='apn.trimble.com'] > ModemManager[1164]: <debug> [1481990310.650158] [mm-broadband-bearer.c:876] > parse_pdp_list(): PDP context [cid=7] [type='ipv6'] > [apn='apn.trimble.com'] > 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? > 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 https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel