mm-modem-helpers.c: In function ‘mm_3gpp_get_pdp_type_from_ip_family’:
mm-modem-helpers.c:4166:5: error: enumeration value ‘MM_BEARER_IP_FAMILY_NONE’ not handled in switch [-Werror=switch-enum]
4166 | switch (family) {
| ^~~~~~
mm-modem-helpers.c:4166:5: error: enumeration value ‘MM_BEARER_IP_FAMILY_ANY’ not handled in switch [-Werror=switch-enum]
If the charset selected via CSCS is UCS2, the modem may decide to
return all the strings in the +COPS=? response in UCS2:
<debug> (ttyACM0): --> 'AT+COPS=?<CR>'
<debug> (ttyACM0): <-- '<CR><LF>+COPS: (2,"004D006F007600690073007400610072","004D006F007600690073007400610072","00320031003400300037",7)
<debug> Found network '00320031003400300037' ('004D006F007600690073007400610072','004D006F007600690073007400610072'); availability: current, access tech: lte
Rework how the broadband bearer runs CGDCONT? and CGDCONT=? and setup
a helper method to perform the CID selection logic.
Also, implement unit tests for the CID selection logic.
This CL converts a few g_regex_match_full() expressions to their
equivalent g_regex_match() in order to simplify the code, i.e.
g_regex_match_full (regex, str, strlen (str), 0, 0, &match_info, NULL)
is equivalent to:
g_regex_match_full (regex, str, -1, 0, 0, &match_info, NULL)
or simply:
g_regex_match (regex, str, 0, &match_info)
The regex was expecting empty values in several of the fields, which
is wrong. Instead of matching empty fields, just ignore all fields
that we don't require in our logic.
This patch fixes a potential memory leak in
mm_3gpp_parse_pdu_cmgl_response() where the allocated MM3gppPduInfo may
be leaked when failing to parse the +CMGL response.
The +CGEV indications allow us to get notified of packet domain
events like network-initiated or ME-initiated disconnections on
specific connected contexts, as well as full PS detach events (all
contexts disconnected). If the modem supports these indications, we
will enable them with +CGEREP and will then process them when they are
emitted by the modem.
If a full PS detach event happens, we will explicitly disconnect all
connected bearers.
If a deactivation inidication is received for a single context, we
will look for the associated bearer by CID and explicitly disconnect
it.
This patch adds a mm_bcd_to_string() helper function to convert a byte
array representing a binary-coded decimal (BCD) number to a string
representing the equivalent decimal number.
Devices like the Netgear AC313U require explicit context monitoring,
otherwise the device may end up disconnected internally and MM would
still think that the connection is ongoing.
There are operators (e.g. the Chinese CMCC operator) that abuse the
fact that 4 bits are used to store the BCD encoded numbers, and also
use the [A-F] range as valid characters for the ICCID in the operator
specific account number part. Haven't seen any documentation where
this format with [A-F] characters is explicitly allowed, but I have
seen multiple real cases where it happens. E.g.:
898602F9091830030220
898602C0123456789012
This patch also removes the 'last F' validation, used when reading
19-digit ICCIDs with +CRSM, as it no longer applies.
The mm_3gpp_parse_iccid() method does validation of the ICCID string
and was originally implemented to handle +CRSM reported values. The
implementation was looking for 20-digit strings, even for 19-digit
ICCIDs (those finished with a trailing 'F').
We now extend the logic to also validate ICCID strings reported as
19-digit values directly, and when that happens we won't allow
swapping of the digits (a +CRSM specific requirement) or trailing 'F'
characters (as that is only required when reporting 19-digit ICCIDs
with 20-digit strings).
This change allows us to e.g. use the u-blox specific AT+CCID command
and validate the returned ICCID with the same helper method, which
currently fails:
(ttyACM2): --> 'AT+CCID<CR>'
(ttyACM2): <-- '<CR><LF>+CCID: 8934077700015848638<CR><LF><CR><LF>OK<CR><LF>'
couldn't load SIM identifier: 'Invalid ICCID response size (was 19, expected 20)'
Devices will expect SUPL server given as either IP:PORT or FQDN:PORT,
so just avoid saying we require a 'URL' because it's not true.
We will use a new helper method to parse and validate user-provided
SUPL server address.
The PDP contexts that are found with an empty APN configured are right
now used as placeholders that can be overwritten with the user
provided APN if no direct match is found.
We want to keep that logic in place, but for the case where we do get
an empty APN requested by the user, we need to perform the full
context match, so that the first PDP context matching the empty APN is
used.
Right now we're overwriting with the empty APN again the last PDP
context found with an empty APN, which doesn't make much sense:
Apr 27 08:15:21 ModemManager[4251]: <debug> Found '3' PDP contexts
Apr 27 08:15:21 ModemManager[4251]: <debug> PDP context [cid=1] [type='ipv4'] [apn='']
Apr 27 08:15:21 ModemManager[4251]: <debug> PDP context [cid=2] [type='ipv4'] [apn='broadband']
Apr 27 08:15:21 ModemManager[4251]: <debug> PDP context [cid=15] [type='ipv4'] [apn='']
Apr 27 08:15:21 ModemManager[4251]: <debug> Found PDP context with CID 1 and no APN
Apr 27 08:15:21 ModemManager[4251]: <debug> Found PDP context with CID 15 and no APN
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3) device open count is 3 (open)
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3) device open count is 2 (close)
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3): --> 'AT+CGDCONT=15,"IP",""<CR>'
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3): <-- '<CR><LF>OK<CR><LF>'
The +CEMODE command is defined in 3GPP TS 27.007 (e.g. in section
10.1.28 in v11.0.0). This command allows querying or updating the
current UE mode, as well as checking the supported modes.
We implement support for loading the current mode and updating it. It
is assumed that the device does any additional operation needed by the
setting update, e.g. un-registering from CS when selecting an EPS-only
mode.
Aleksander Morgado
Ben Chan
Thomas Haller
Paul Bartell
Alfonso Sánchez-Beato
Ville Skyttä
Colin Helliwell