As we do in the similar modem state wait operations in the modem
interface, the caller of the wait operation may ignore the state
result as it's really not required in this case. Only looking at
whether an error is set or not is enough.
This by itself fixes a crash where
mm_iface_modem_3gpp_wait_for_packet_service_state_finish() may have
returned UNKNOWN without error set.
0x000079616c2564ed (libglib-2.0.so.0 - gtestutils.c: 3256) g_assertion_message
0x000079616c25654b (libglib-2.0.so.0 - gtestutils.c: 3282) g_assertion_message_expr
0x000057ba46231150 (ModemManager - mm-iface-modem-simple.c: 344) packet_service_attach_in_3gpp_network_step
0x000079616c0efb02 (libgio-2.0.so.0 - gtask.c: 1232) g_task_return_now
0x000079616c0eeb54 (libgio-2.0.so.0 - gtask.c: 1301) g_task_return
0x000057ba4620e5bd (ModemManager - mm-iface-modem-3gpp.c: 189) wait_for_packet_service_state_context_complete
0x000057ba4620b441 (ModemManager - mm-iface-modem-3gpp.c: 261) packet_service_state_changed
With GSM7 encoding, packedlen is the length of the unpacked string
after expanding septets to octets so it will be ~14% bigger than
the original string length. This means we have to be careful not
to copy too much data into the PDU buffer.
Similar issues exist in other branches of the same function.
Thanks rhezashan@gmail.com for the report.
Kernel driver mhi-net sets a custom MTU for the netdevice: use the
same value when resetting the netdevice to its initial state.
This is important especially when rmnet is used on top of mhi-net,
since rmnet netdevices get their initial MTU from the mhi-net one.
Rely exclusively on whether a global IPv6 was given or not, regardless
of what the DNS or gateway settings are, same as we do for IPv4.
Also, assume we only get 1 single IPv6 address. No need to have a
FIXME to add support for more addresses.
This will make device probing slower unconditionally, but it should
also ensure newer more complex devices that take longer to boot are
handled properly.
The current requested downlink data aggregation protocol maximum size is
set to 32768, but this is not accordingly set as the MTU of the main
qmi_wwan interface, that is instead set to RMNET_MAX_PACKET_SIZE that is
16384.
So, the modem is able to send QMAP aggregated blocks larger than 16384,
but the driver is not able to properly collect them, since the URB size
is 16384.
It is not simply possible to set qmi_wwan main interface MTU to the
returned dl max aggregated size, since when creating the rmnet netdevice
the rmnet kernel module automatically set the mtu as the size of the
parent netdevice MTU - the qmap header size (4), but this won't work
because the rmnet kernel module does not support MTU > 16384.
As an immediate fix, set the requested dl dap max size to 16384, while
thinking about how to refactor the logic for supporting higher values.
qmi_wwan inbox qmap management is not affected by this issue.
It could happen that when MM starts the aggregation protocol is already
configured on the modem side (e.g. if MM is stopped and restarted): this
prevents the links to be properly configured, resulting in using the qmimux
multiplex implementation even if rmnet is available.
Fix the issue by always performing the first time the links reset procedure,
even if the data format on the modem side is the expected one.
When using QMAPv5 and QMAPv4 the checksum is enabled by default
at the modem level, so it should be also enabled when creating the
rmnet netdevices: add the required flags also when rmnet is used
through qmi_wwan.
FEATURE_NOT_SUPPORTED is equal 1 in the enum FeatureSupport, as a
result even if QGPS isn't supported by modem debug message printed
available support.
ctx->supl is allocated in mm_shared_qmi_location_set_supl_server
using g_strdup. g_strdup requires to free string when unneeded.
The problem could be reproduced using following commands
```
while true; do
mmcli -m any --location-set-supl-server="supl.google.com:7276";
mem=$(cat /proc/$(pgrep ModemManager)/statm | awk '{print $6}')
echo $(date +"%s"), $mem | tee -a mm-leak.log;
done;
```
NL668 doesn't correctly support more than one multiplexed PDN
connection. Limit this explicitly so that it never attempts to use
more than one.
# mmcli -m a --simple-connect="multiplex=requested,apn=internet,ip-type=ipv4v6,apn-type=default"
successfully connected the modem
# mmcli -m a --simple-connect="multiplex=requested,apn=internet2,ip-type=ipv4v6,apn-type=default"
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Unsupported: Invalid bearer properties: Maximum number of multiplexed bearers reached'
Certain QMI or MBIM devices may not be able to support multiplexing at
all, or they may support a limited amount of links.
The new ID_MM_MAX_MULTIPLEXED_LINKS udev tag allows specifying the
maximum number of supported multiplexed links; e.g. 0 to report none
supported or 1 to report that one single multiplexed link is
supported.
Both the register state indications and the register state set
response messages will be processed in the same way.
This ensures that the registration state reported during the set
response, along with the additional info provided in that
message (e.g. access technologies) are taken into account.
This change also avoids fully relying on the register state
indications sent by the modem, as the indication may not be sent after
a successful update operation (given that the operation response
already contains the last valid state).
When running the 3GPP registration checks (e.g. after reaching enabled
state, or when synchronizing state after a quick suspend/resume), we
also update the current packet service state explicitly, without
needing to fully rely on the indications.
Both the packet service indications and the packet service set
response messages will be processed in the same way.
This ensures that the packet service state reported during the set
response, along with the additional info provided in that
message (e.g. speeds) are taken into account.
This change also avoids fully relying on the packet service
indications sent by the modem, as the indication may not be sent after
a successful update operation (given that the operation response
already contains the last valid state).
==6971== 52 (16 direct, 36 indirect) bytes in 1 blocks are definitely lost in loss record 3,764 of 6,140
==6971== at 0x4842839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==6971== by 0x4A1ADE8: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==6971== by 0x4A31FF1: g_slice_alloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==6971== by 0x4A3266D: g_slice_alloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==6971== by 0x49FD397: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==6971== by 0x49FD8B4: g_error_new_valist (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==6971== by 0x49FDACE: g_set_error (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==6971== by 0x187A4C: mm_base_modem_peek_best_at_port (mm-base-modem.c:1129)
==6971== by 0x184116: _at_command (mm-base-modem-at.c:634)
==6971== by 0x1841FE: mm_base_modem_at_command (mm-base-modem-at.c:660)
==6971== by 0x18F6F1: load_sim_identifier (mm-base-sim.c:2016)
==6971== by 0x18CA03: mm_base_sim_load_sim_identifier (mm-base-sim.c:820)
