Fixes incoming SMS translation issue seen on MC7354 when translating
contents from Latin-1 encoding to UTF-8, because the encoding parameter
"ISO−8859−1" used U+2212 (MINUS SIGN) instead of U+002D (HYPHEN-MINUS).
[mm-sms-part-cdma.c:873] read_bearer_data_user_data():
text/data: ignored (latin to UTF-8 conversion error): 0:
Conversion from character set 'ISO−8859−1' to 'UTF-8' is
not supported
Fix thanks to Peter Hunt
Despite 3GPP TS 23.038 specifies that Unicode SMS messages are
encoded in UCS-2, UTF-16 encoding is commonly used instead on many
modern platforms to allow encoding code points that fall outside the
Basic Multilingual Plane (BMP), such as Emoji.
Update the logic to always use UTF-16 instead of UCS-2 when creating
or parsing PDUs (even if we always report as sending or receiving
UCS-2). For all purposes, UCS-2 is considered a subset of UTF-16
(assuming that code points out of the [U+0000,U+D7FF] and
[U+E000,U+FFFF] ranges are not applicable in UCS-2).
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/250
Only applicable when building with WITH_NEWEST_QMI_COMMANDS.
mm-broadband-modem-qmi.c:4741:1: error: ‘common_enable_disable_unsolicited_events_signal_strength’ defined but not used [-Werror=unused-function]
4741 | common_enable_disable_unsolicited_events_signal_strength (GTask *task)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm-broadband-modem-qmi.c:4528:1: error: ‘serving_system_indication_cb’ defined but not used [-Werror=unused-function]
4528 | serving_system_indication_cb (QmiClientNas *client,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm-broadband-modem-qmi.c:3468:1: error: ‘common_enable_disable_unsolicited_registration_events_serving_system’ defined but not used [-Werror=unused-function]
3468 | common_enable_disable_unsolicited_registration_events_serving_system (GTask *task)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm-broadband-modem-qmi.c:2812:1: error: ‘get_serving_system_3gpp_ready’ defined but not used [-Werror=unused-function]
2812 | get_serving_system_3gpp_ready (QmiClientNas *client,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm-broadband-modem-qmi.c:1652:1: error: ‘get_signal_strength_ready’ defined but not used [-Werror=unused-function]
1652 | get_signal_strength_ready (QmiClientNas *client,
Only applicable when building with WITH_NEWEST_QMI_COMMANDS.
mm-broadband-modem-qmi.c: In function ‘process_common_info’:
mm-broadband-modem-qmi.c:2924:20: error: comparison is always false due to limited range of data type [-Werror=type-limits]
2924 | if (mnc[2] == 0xFF) {
| ^~
If the connection attempt is aborted before finishing (either network
triggered or user triggered), we need to make sure that we run a 'Stop
Network' request for every 'Start Network' that had succeeded until
then, or otherwise we'll no longer be able to re-run a 'Start Network'
with the same settings and get a proper packet data handle.
E.g. in this sequence we attempt a IPv4v6 connection. The logic starts
setting up the IPv4 path:
Wed Jul 29 14:44:06 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> connecting)
Wed Jul 29 14:44:06 2020 daemon.debug [1567]: <debug> Launching connection with QMI port (usb/cdc-wdm0) and data port (net/wwan0)
Wed Jul 29 14:44:06 2020 daemon.debug [1567]: <debug> Defaulting to use static IP method
Wed Jul 29 14:44:06 2020 daemon.debug [1567]: <debug> Running IPv4 connection setup
...
The 'Start Network' for IPv4 succeeds and we get a proper packet data
handle:
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: [/dev/cdc-wdm0] sent generic request (translated)... <<<<<< QMUX: <<<<<< length = 23 <<<<<< flags = 0x00 <<<<<< service = "wds" <<<<<< client = 20 <<<<<< QMI: <<<<<< flags = "none" <<<<<< transaction = 3075 <<<<<< tlv_length = 11 <<<<<< message = "Start Network" (0x0020) <<<<<< TLV: <<<<<< type = "APN" (0x14) <<<<<< length = 8 <<<<<< value = 69:6E:74:65:72:6E:65:74 <<<<<< translated = internet
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: [/dev/cdc-wdm0] received generic response (translated)... <<<<<< QMUX: <<<<<< length = 26 <<<<<< flags = 0x80 <<<<<< service = "wds" <<<<<< client = 20 <<<<<< QMI: <<<<<< flags = "response" <<<<<< transaction = 3075 <<<<<< tlv_length = 14 <<<<<< message = "Start Network" (0x0020) <<<<<< TLV: <<<<<< type = "Result" (0x02) <<<<<< length = 4 <<<<<< value = 00:00:00:00 <<<<<< translated = SUCCESS <<<<<< TLV: <<<<<< type = "Packet Data Handle" (0x01) <<<<<< length = 4 <<<<<< value = 80:CD:AD:81 <<<<<< translated = 2175651200
Then, we start the IPv6 connection path:
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: <debug> Running IPv6 connection setup
...
But, because we suddenly are not registered in the network, the
connection is aborted, and we don't cleanup the IPv4 path at this
point, as this patch wasn't available.
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: <debug> Bearer not allowed to connect, not registered in 3GPP network
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: <debug> Forcing disconnection of bearer '/org/freedesktop/ModemManager1/Bearer/56'
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: transaction 0xe1 aborted, but message is not abortable
Wed Jul 29 14:44:07 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> enabled)
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: <debug> Couldn't connect bearer '/org/freedesktop/ModemManager1/Bearer/56': 'operation cancelled'
We then attempt a new connection request with the same settings:
Wed Jul 29 14:44:22 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> connecting)
Wed Jul 29 14:44:22 2020 daemon.debug [1567]: <debug> Launching connection with QMI port (usb/cdc-wdm0) and data port (net/wwan0)
Wed Jul 29 14:44:22 2020 daemon.debug [1567]: <debug> Defaulting to use static IP method
Wed Jul 29 14:44:22 2020 daemon.debug [1567]: <debug> Running IPv4 connection setup
And we see how the 'Start Network' command fails with a 'No Effect'
error, as the IPv4 was left connected earlier. Due to this, the modem
is assumed connected, but we won't have a valid packet data handle to
stop the connection cleanly:
Wed Jul 29 14:44:22 2020 daemon.debug [1567]: [/dev/cdc-wdm0] sent generic request (translated)... <<<<<< QMUX: <<<<<< length = 23 <<<<<< flags = 0x00 <<<<<< service = "wds" <<<<<< client = 20 <<<<<< QMI: <<<<<< flags = "none" <<<<<< transaction = 3080 <<<<<< tlv_length = 11 <<<<<< message = "Start Network" (0x0020) <<<<<< TLV: <<<<<< type = "APN" (0x14) <<<<<< length = 8 <<<<<< value = 69:6E:74:65:72:6E:65:74 <<<<<< translated = internet
Wed Jul 29 14:44:23 2020 daemon.debug [1567]: [/dev/cdc-wdm0] received generic response (translated)... <<<<<< QMUX: <<<<<< length = 26 <<<<<< flags = 0x80 <<<<<< service = "wds" <<<<<< client = 20 <<<<<< QMI: <<<<<< flags = "response" <<<<<< transaction = 3080 <<<<<< tlv_length = 14 <<<<<< message = "Start Network" (0x0020) <<<<<< TLV: <<<<<< type = "Result" (0x02) <<<<<< length = 4 <<<<<< value = 01:00:1A:00 <<<<<< translated = FAILURE: NoEffect <<<<<< TLV: <<<<<< type = "Packet Data Handle" (0x01) <<<<<< length = 4 <<<<<< value = 00:00:00:00 <<<<<< translated = 0
If the modem is connected and we receive indications of a quick
unregistration cycle (i.e. unregistered, then registered again) we
should not end up flagging the modem as disconnected.
We already had some logic to avoid this with the "deferred 3GPP
unregistration" logic in the base bearer object, but this logic only
took into account the status of the bearer, not the status of the
modem.
Wed Jul 29 15:35:44 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (home -> idle)
Wed Jul 29 15:35:44 2020 daemon.debug [1567]: <debug> Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP location updated (MCC: '0', MNC: '0', Location area code: '0', Tracking area code: '1CE8', Cell ID: '68F832')
Wed Jul 29 15:35:44 2020 daemon.debug [1567]: <debug> Connected bearer not registered in 3GPP network
Wed Jul 29 15:35:44 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connected -> enabled)
Wed Jul 29 15:35:44 2020 daemon.debug [1567]: <debug> Modem /org/freedesktop/ModemManager1/Modem/0: signal quality updated (0)
Wed Jul 29 15:35:44 2020 daemon.debug [1567]: <debug> Modem /org/freedesktop/ModemManager1/Modem/0: access technology changed (lte -> unknown)
Wed Jul 29 15:35:44 2020 daemon.debug [1567]: <debug> Periodic signal checks disabled
Wed Jul 29 15:35:44 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (idle -> registering)
Wed Jul 29 15:35:44 2020 daemon.debug [1567]: <debug> Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP location updated (MCC: '0', MNC: '0', Location area code: '0', Tracking area code: '1C84', Cell ID: 'A3E050')
Wed Jul 29 15:35:44 2020 daemon.debug [1567]: <debug> Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP location updated (MCC: '238', MNC: '1', Location area code: '0', Tracking area code: '1C84', Cell ID: 'A3E050')
Wed Jul 29 15:35:44 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (registering -> home)
Wed Jul 29 15:35:44 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (enabled -> registered)
We now try to improve this situation by also considering the case
where modem is supposed to get into "enabled" state (i.e. not
registered, not searching), but we still consider the amount of
connected bearers to decide the final state reported by the modem. In
other words, a modem with the 3GPP registration reported as 'idle'
will still be reported as 'connected' if there is at least one bearer
in connected state. This situation will end as soon as the 'deferred
3GPP unregistration' timeout expires, as that will force the bearer to
be disconnected.
CHAP is almost universal nowadays, and so it is a better default
than PAP
Not changed for uBlox, that prefers an error if not specified,
and for Huawei, which uses NONE with user/pwd and has 2 CHAP choices
mm-broadband-modem-qmi.c: In function 'process_common_info':
mm-broadband-modem-qmi.c:2897:30: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
/* both apply */ ;
^
Signed-off-by: Justin Standring <justin.standring@taitradio.com>
mm-broadband-modem-qmi.c: In function 'common_signal_info_get_quality':
mm-broadband-modem-qmi.c:1469:21: error: 'self' undeclared (first use in this function)
mm_obj_dbg (self, "RSSI (CDMA): %d dBm", cdma1x_rssi);
^~~~
mm-broadband-modem-qmi.c:1469:21: note: each undeclared identifier is reported only once for each function it appears in
mm_obj_dbg (self, "RSSI (CDMA): %d dBm", cdma1x_rssi);
^~~~
mm-broadband-modem-qmi.c: In function 'process_gsm_info':
mm-broadband-modem-qmi.c:2992:25: error: 'self' undeclared (first use in this function)
mm_obj_dbg (self, "no GSM service reported");
^~~~
mm-broadband-modem-qmi.c: In function 'process_wcdma_info':
mm-broadband-modem-qmi.c:3100:25: error: 'self' undeclared (first use in this function)
mm_obj_dbg (self, "no WCDMA service reported");
^~~~
mm-broadband-modem-qmi.c: In function 'process_lte_info':
mm-broadband-modem-qmi.c:3209:25: error: 'self' undeclared (first use in this function)
mm_obj_dbg (self, "no LTE service reported");
^~~~
mm-broadband-modem-qmi.c: In function 'config_signal_info_ready':
mm-broadband-modem-qmi.c:4890:21: error: 'self' undeclared (first use in this function)
mm_obj_dbg (self, "QMI operation failed: '%s'", error->message);
^~~~
Signed-off-by: Justin Standring <justin.standring@taitradio.com>
Extended the ModemManager Signal interface to include 5G signal
information for RSRP, RSRQ and SINR via libqmi. Also extended mmci
to print 5G signal info.
Instead of using the FALSE return of the method to indicate either a
fatal error (if result_error was set) or the continuation request (if
result_error wasn't set), provide a enum that has explicit states for
all three possible values (failure, success or continue).
The disabling sequence is updated so that the steps to disable the
interfaces never fail. This is done so that the modem is not left
in an "inconsistent" enabled state, if e.g. the modem is enabled and
one of the disabling steps for the interfaces ends up failing. In this
case, it is preferred to say that the modem is disabled, than having
it wrongly enabled.
The enabling sequence is updated so that if any of the steps to enable
the interfaces fail, we end up running an implicit disabling operation
to disable all the interfaces. This is to attempt to cleanup whatever
we had enabled during the enabling operation, including e.g. the open
ports context.
The QMI client version is an information provided by the QMI protocol
only when QMUX or MBIM backends are used, it won't be available when
e.g. QRTR is used. The logic in ModemManager should not rely on this
information.
This allows MMKernelDevice::cmp to compare two kernel devices
with different object types, which means that subclasses can
continue to only handle comparisons with their own type. The
order may not be stable across builds.
The cellular operator can break the interactive USSD session. In this case, it is necessary
to process this situation otherwise --3gpp-ussd-initiate or --3gpp-ussd-respond will give an error.
Signed-off-by: Maxim Anisimov <maxim.anisimov.ua@gmail.com>
Until now, the plugin whitelist rule in the filter would only handle
those plugins that require specific udev tags, and those that had
explicit full vid:pid pairs.
This update makes a new implicit automatic whitelist for all devices
that match any of the vids managed by the different plugins.
Looking at the current list of devices in the blacklist and greylist
maintained by ModemManager, there are no devices falling under the
list of supported plugin vids that would need to be blacklisted;
except for u-blox GPS modules:
huawei -> 0x12d1 -> None in blacklist/greylist
thuraya -> 0x1a26 -> None in blacklist/greylist
telit -> 0x1bc7 -> None in blacklist/greylist
dLink -> 0x2001 -> None in blacklist/greylist
wavecom -> 0x114f -> None in blacklist/greylist
x22x -> 0x1bbb,0x0b3c -> None in blacklist/greylist
anydata -> 0x16d5 -> None in blacklist/greylist
quectel -> 0x2c7c -> None in blacklist/greylist
haier -> 0x201e -> None in blacklist/greylist
novatel -> 0x1410 -> None in blacklist/greylist
dell -> 0x413c -> None in blacklist/greylist
option -> 0x0af0,0x1931 -> None in blacklist/greylist
nokia -> 0x0421 -> None in blacklist/greylist
cinterion -> 0x1e2d,0x0681 -> None in blacklist/greylist
simtech -> 0x1e0e -> None in blacklist/greylist
iridium -> 0x1edd -> None in blacklist/greylist
pantech -> 0x106c -> None in blacklist/greylist
longcheer -> 0x1c9e,0x1bbb -> None in blacklist/greylist
linktop -> 0x230d -> None in blacklist/greylist
sierra -> 0x1199 -> None in blacklist/greylist
ublox -> 0x1546 -------------> GPS chips blacklisted !!!!!
foxconn -> 0x0489 -> None in blacklist/greylist
broadmobi -> 0x2020 -> None in blacklist/greylist
fibocom -> 0x2cb7 -> None in blacklist/greylist
tplink -> 0x2357 -> None in blacklist/greylist
zte -> 0x19d2 -> None in blacklist/greylist
The rules used to blacklist the u-blox GPS chips have already been
moved to the u-blox plugin itself, and now they use the broader
ID_MM_DEVICE_IGNORE tag that applies in all filter modes.
Instead of setting up the ID_MM_TTY_BLACKLIST tag used in 'legacy'
filter mode, tag all known u-blox GPS devices with the broader
ID_MM_DEVICE_IGNORE tag that applies under all filter modes.
Also, make this rules be installed by the plugin itself, because at
the end, it is the u-blox plugin the one attempting to probe all
devices with vid 0x1546.
The 'strict' filter policy is less invasive, as it will not touch TTYs
unless there are clear indications that it may be a modem. Under this
mode, the ModemManager-provided blacklist database is not used.
==80079== 104 (40 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 4,761 of 5,232
==80079== at 0x483977F: malloc (vg_replace_malloc.c:309)
==80079== by 0x5025AE9: g_malloc (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x5006223: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x505B0F4: g_array_sized_new (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x2008A3: firmware_change_current (mm-broadband-modem-qmi.c:8426)
==80079== by 0x1AB5F3: select_auth_ready (mm-iface-modem-firmware.c:225)
==80079== by 0x4E68653: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==80079== by 0x4E6DA26: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==80079== by 0x17402E: authorize_ready (mm-base-modem.c:1363)
==80079== by 0x4E68653: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==80079== by 0x4E6DA26: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==80079== by 0x15366D: check_authorization_ready (mm-auth-provider.c:99)
==80079== 1,377 (48 direct, 1,329 indirect) bytes in 1 blocks are definitely lost in loss record 5,200 of 5,232
==80079== at 0x483977F: malloc (vg_replace_malloc.c:309)
==80079== by 0x5025AE9: g_malloc (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x5006223: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x4FEB59B: ??? (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x4FEE378: g_variant_builder_end (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x48F8314: mm_firmware_properties_get_dictionary (mm-firmware-properties.c:337)
==80079== by 0x1AAF29: load_current_ready (mm-iface-modem-firmware.c:80)
==80079== by 0x4E68653: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==80079== by 0x4E68688: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==80079== by 0x502B58E: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x502D530: ??? (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x502E542: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.6400.2)
David Leonard
Aleksander Morgado
Giacinto Cifelli
Sven Schwermer
Justin Standring
Walter Hagstrom
Adrien Plazas
Eric Caruso
Maxim Anisimov