. A shift has undefined behaviour if the mathematical result
(lhs * 2^{rhs}) doesn't fit in the range of the resulting type.
In other words, you can't left shift into the sign bit of a
signed integer type.
The error message is:
mm-broadband-modem.c:3308:15: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
SUMMARY: AddressSanitizer: undefined-behavior mm-broadband-modem.c:3308:15 in
Auth settings will be added in a QMI message only if at least one of these is
requested:
* An explicit auth preference is requested.
* User string is given and isn't empty.
* Password string is given and isn't empty.
Given that the Location interface requires 3GPP info reported by the 3GPP
interface, we should only trigger registration checks once the Location
interface has been already enabled and ready to be used. If we don't do this,
we'll end up e.g. getting initial MCCMNC values but never reaching the Location
interface properly.
So, fix this by triggering all registration checks (CDMA and 3GPP) only after
having enabled all interfaces.
LAC/CID may only be given in the serving system indications when the values
change, and therefore we shouldn't reset the values to 0 whenever they're not
reported.
This seems to happen in newer devices; older devices like the MC7710 did always
report the values in the indications.
This check makes no sense. We're converting from a ModemManager enum to a QMI
enum, nothing else; i.e. 'caps' is *not* the current capabilities of the modem.
Variability in the response style from certain modems causes the parsing
of the +CGMR response to fail. For example, the Telit HE910 inserts an
empty string ("") in the second field of the response, causing the
sscanf implementation to fail.
This patch converts the parsing of the CGMR response to a regex that
allows for more flexibility and robustness, and adds unit tests around
the parsing call.
Signed-off-by: Nick Stevens <Nick.Stevens@digi.com>
Previously the enable unsolicited messages command (+CNMI) was only
being sent on the primary. This patch adds support for sending the
enable on the secondary as well. If the secondary doesn't exist, or if
setting the enable causes an error, a warning is logged but no error is
propagated up.
This change is needed for proper SMS operation on the Telit HE910, which
requires that +CNMI be sent to both primary and secondary. Since a
failure to send the +CNMI command on the secondary is a non-fatal error,
it is unlikely that this will cause issues with other modems.
Signed-off-by: Nick Stevens <Nick.Stevens@digi.com>
CDMA-capable modems (like a Sierra EM7355) will fail to even enable,
because the internal CDMA code tries to initialize using AT commands and
that fails because many MBIM modems don't have an AT port. We should
figure out how to support minimal MBIM + CDMA using MBIM instead of
AT-anything.
[mm-broadband-modem.c:9000] enabling_step(): Modem has CDMA capabilities, enabling the Modem CDMA interface...
[mm-iface-modem-cdma.c:946] mm_iface_modem_cdma_run_registration_checks(): Running registration checks (CDMA1x: 'yes', EV-DO: 'yes')
[mm-broadband-modem.c:7397] setup_registration_checks_context_complete_and_free(): Will skip all QCDM-based registration checks
[mm-broadband-modem.c:7418] setup_registration_checks_context_complete_and_free(): Will skip generic detailed registration check, we don't have Sprint commands
[mm-iface-modem-cdma.c:768] registration_check_step(): Starting QCDM-based registration checks
[mm-iface-modem-cdma.c:780] registration_check_step(): Skipping all QCDM-based checks and falling back to AT-based checks
[mm-iface-modem-cdma.c:823] registration_check_step(): Starting AT-based registration checks
[mm-iface-modem-cdma.c:641] get_service_status_ready(): Could not get service status: No AT port available to run command
[mm-iface-modem.c:1392] __iface_modem_update_state_internal(): Modem /org/freedesktop/ModemManager1/Modem/0: state changed (enabling -> disabled)
This response is already managed by the generic AT serial port and translates
it into a proper error. This change also avoids the Call.Start() call to report
a timeout in the serial port, instead we get a proper no-carrier error.
Before:
$ sudo mmcli -m 0 --voice-create-call="number=12345678"
Successfully created new call:
/org/freedesktop/ModemManager1/Call/1 outgoing (unknown)
$ sudo mmcli -o 1 --start
error: couldn't start the call: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Serial.ResponseTimeout: Serial command timed out'
After:
$ sudo mmcli -m 0 --voice-create-call="number=12345678"
Successfully created new call:
/org/freedesktop/ModemManager1/Call/1 outgoing (unknown)
$ sudo mmcli -o 1 --start
error: couldn't start the call: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Connection.NoCarrier: No carrier'
When passing known_lock=UNKNOWN to mm_iface_modem_update_lock_info()
we actually do want to ask the modem itself for locks instead of
checking the cache. For example, when an unknown error is returned
after performing PIN/PUK operations, the cache value may well be
NONE if that was the prior lock state, and that bypasses the modem
which might now be locked. Thus the state gets messed up.
Reproducer is to send 'ChangePin' with the wrong "old" PIN 3 times,
then send a wrong PUK. No error was returned from mmcli and
the modem's lock state was shown as 'none'.
The Pantech UML290 takes a horribly great time to initialize the SIM, and
therefore we may even be losing the 3GPP capabilities as the SIM is not
detected during the initial checks:
load_unlock_required_ready(): Couldn't check if unlock required: 'SIM failure: QMI protocol error (37): 'UimUninitialized''
current_capabilities_internal_load_unlock_required_ready(): Multimode device without SIM, no 3GPP capabilities
To avoid this, let 'UimUninitialized' be a retriable error.
QMI modems are incorrectly ignoring IMEI/ESN/MEID numbers that start with a
'0'. Fix this up. Seen on an AT&T Beam (340u)
Signed-off-by: David McCullough <david.mccullough@accelecon.com>
Instead of providing explicit dependency rules to generate the enum types
support files before they're first used, just pre-generate them before building
anything. Maintaining the explicit dependency rules is not really worth it.
This message gets printed for all netdevs and ttys, including most
machines normal ethernet/Wi-Fi interfaces. It seems a bit less critical
than 'warning' level would indicate.
ModemManager[32097]: <warn> Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:19.0': not supported by any plugin
ModemManager[32097]: <warn> Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0': not supported by any plugin
If for any reason the modem is in OFF state and still can talk to the modem,
allow running the remaining transition requests to LOW or ON. This can happen
for example for modems that use CFUN:0, i.e. which can still go online with
CFUN=1.
https://bugs.freedesktop.org/show_bug.cgi?id=89368
Yunlian Jiang
Aleksander Morgado
Dan Williams
Nick Stevens
Marco Bascetta
Riccardo Vangelisti
David McCullough
Jason Simmons
Daniele Palmas