The L850 seems to report 0xFFFFFFFF as MbimContextIpType value, which
is not a correct value.
Instead of printing "(none)" (the default used by glib when trying to
print a NULL pointer as a string), make it so that we end up printing
the actual numeric value in hex.
<dbg> [modem0] 'home' settings found at configuration index 0
<dbg> [modem0] 'non-partner' settings found at configuration index 1
<dbg> [modem0] 'partner' settings not found
<dbg> [modem0] updates in the home LTE attach configuration settings:
<dbg> [modem0] ip type: 'unknown (0xffffffff)' -> ''ipv4v6'
<dbg> [modem0] updates in the partner LTE attach configuration settings:
<dbg> [modem0] none (skipped)
<dbg> [modem0] updates in the non-partner LTE attach configuration settings:
<dbg> [modem0] none
Instead of updating the attach settings associated with the home
network, update all three to the same values, so that network attach
while roaming uses the same settings as in home.
This is a major change in behavior; if there is ever a need to roll
back to the old behavior because a given device doesn't support this,
we can provided device-specific behaviors using the
load_set_initial_eps_bearer_settings_mask() virtual method.
L850 modems running a firmware version less than 18500.5001.0.7 and
using AT&T SIM cards with MCCMNC 310280 do not support specifying
"partner" settings in the MBIM operation to set the LTE attach
configuration.
The ModemManager API provides a single method to update the attach
settings used in LTE registration, but in the MBIM protocol there are
three different distinct configurations associated with that
operation.
Until now we have exclusively updated the "home" settings, leaving the
"partner" and "non-partner" settings untouched (i.e. we loaded the
existing settings for these sections, and used the same ones when
providing our update operation).
Unfortunately, this logic does not fit all needs. Some modems will
require all 3 elements to be unconditionally updated, and some other
modems may need to fully skip one of the configuration sections.
The rework done in this commit does not change the behavior, but
provides the ability for subclasses to modify how the operation is
done, via a set of flags that is provided on each update attempt (as
sometimes the behavior is operator-specific).
We look for the home settings, but also allow to optionally lookup for
the partner and non-partner settings, logging in each case if we find
anomalies (e.g. if not found or if found duplicated entries).
This helps identify which base sms the message belongs to.
Previous
[modem0/sms-list] found existing multipart SMS object with reference
'126': adding new part
New
[modem0/sms0] found existing multipart SMS object with reference
'126': adding new part
Signed-off-by: Kyle Evans <kvans32@gmail.com>
Messages from different senders can have the same reference.
Stale messages from the same sender can also conflict.
Consider the number of the sender and also the max parts
when assigning parts to a base sms.
Ref 3gpp specification section 9.2.3.24.1
Fixes#757
Signed-off-by: Kyle Evans <kvans32@gmail.com>
The device always reports empty TX/RX values so there is no point in
periodically asking.
The logic to poll for stats is kept in place only if the device
requires the IP packet filters removal hack.
MMBroadbandModemQmi only disables signal polling once it successfully
sets the indication up. To do that, it sets the properties on
MMIfaceModem. This, however, doesn't actually disable polling, as the
property values are only checked once in get_private when Private
structure hasn't been created yet. Once that happens, only the cached
values are ever checked, and there's nothing that would update them.
Since there's only one place where these properties are checked, get
rid of cached bools in Private structure and instead read the property
values directly in periodic_signal_check_step, letting QMI modems
actually disable polling at runtime.
Fibocom L850 modems report an invalid part index (always 1) in the
response message. Because we know which message part was requested,
we can use that value instead to workaround this bug.
Not quite correct -- with the patch applied, the newly allocated GError
could potentially overwrite inner_error that was set previously.
This reverts commit d550a24ffdae4492e9f9e18fdf294adcda28fb65.
Fibocom's MBIM support needs this:
mm-port-mbim-fibocom.c: In function ‘iface_port_at_check_support’:
mm-port-mbim-fibocom.c:64:66: error: ‘MBIM_SERVICE_FIBOCOM’ undeclared (first use in this function); did you mean ‘MBIM_SERVICE_GOOGLE’?
64 | if (!mm_port_mbim_supports_command (MM_PORT_MBIM (self), MBIM_SERVICE_FIBOCOM, MBIM_CID_FIBOCOM_AT_COMMAND)) {
| ^~~~~~~~~~~~~~~~~~~~
| MBIM_SERVICE_GOOGLE
mm-port-mbim-fibocom.c:64:66: note: each undeclared identifier is reported only once for each function it appears in
mm-port-mbim-fibocom.c:64:88: error: ‘MBIM_CID_FIBOCOM_AT_COMMAND’ undeclared (first use in this function)
64 | if (!mm_port_mbim_supports_command (MM_PORT_MBIM (self), MBIM_SERVICE_FIBOCOM, MBIM_CID_FIBOCOM_AT_COMMAND)) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: c66a6b89ec ('fibocom: create custom MBIM port object with potential AT support')
GCC 14 is unhappy. Not sure why does this matter, maybe it just does
not. Let's silence the warning at the very least:
libqcdm/src/result.c: In function ‘val_new_string’:
libqcdm/src/result.c:76:25: warning: ‘calloc’ sizes specified with
‘sizeof’ in the earlier argument and not in the later argument
[-Wcalloc-transposed-args]
76 | v = calloc (sizeof (Val), 1);
| ^~~
When a modem is not able to register to the network, MBIM and QMI indications
related to registration reports network rejection cause codes if request is
rejected by the network. This information is currently logged in the ModemManager
but not exposed outside of ModemManager.
These are the changes to define interface to expose network reject cause codes
over d-bus to the above layers which could be used by above layers to present
this information in a user friendly way.
If CID parsing from the +CGDCONT response fails, the very last PDP
structure allocated is not put on the list yet and therefore
mm_3gpp_pdp_context_list_free() wouldn't free it.
Let's put it on the list first, as to not leak it on error.