[RFC] stanger/cinterion branch

Tue Dec 20 11:08:32 UTC 2016

Hey!

On Sat, Dec 17, 2016 at 5:19 PM, matthew stanger <stangerm2 at 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