Aleksander,
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.
In:
swwan_check_status_ready()
....
response = mm_base_modem_at_command_finish (modem, res, &error);
if (!response) {
g_task_return_error (task, error);
goto out;
}
We fall into this and exit without updating the status. I think it should
be:
g_task_return_int (task, (gssize)
MM_BEARER_CONNECTION_STATUS_DISCONNECTED);
I have no idea how that could happen.
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.
In which step do you get the "unspecified gprs error"?
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?
We don't have API members for over-temp or voltage info
>
It was just putting it in logs so we would know for field failures. Nothing
special.
Other than that this looks solid. Exciting times!
On Tue, Dec 20, 2016 at 4:08 AM, Aleksander Morgado <
aleksan...@aleksander.es> wrote:
> 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
