These methods worked in a very strict way for some encodings, and in a
very very loose way for others. E.g. when converting from hex-encoded
UCS-2, we would attempt to convert as much text as we could even if
the input string was truly not even close to UCS-2. This kind of "do
our best" could make sense when processing e.g. the operator name
reported by the modem, as that is some string to show to the user and
there may be no strict requirement to have it perfectly fine. But the
kind of loose comparison done for UCS-2 doesn't make sense e.g. when
converting USSD responses or SMS messages.
Instead of blindly assuming that we can take whatever string given as
valid UTF-8, we'll always attempt to convert from the current modem
charset into UTF-8. Before we were doing this for hex-encoded UCS2,
but not for example for GSM-7.
And due to the now applied GSM-7 conversion, the mf627a/mf627b +COPS
parsing unit tests are updated accordingly, because when converting
from an input string that contains byte 0x40 ('@' in UTF-8) as if it
were GSM-7, the 0x40 is taken as character '¡', encoded as 0xc2,0xa1
in UTF-8).
The //TRANSLIT extension is not always supported by the different
iconv() implementations that we may find out there, so let's
completely avoid using it.
For some of the charsets it actually didn't make much sense anyway,
e.g. as converting to UTF-16 or UTF-8 would always be possible without
requiring //TRANSLIT to take effect.
The //TRANSLIT extension was also being used sometimes in the source
charset identification, which was also not fully correct, as we would
only expect it in the target charset identification.
If the conversion is not fully compatible, the user of the method
needs to request transliteration enabled explicitly in order to avoid
returning errors in this method.
Until now, this method would automatically apply transliteration;
i.e. replacing characters with '?' when no direct translation was
available.
We can attempt to do that transliteration on strings that are not
critical, e.g. the operator name reported by the network. But we
should not do that on other types of strings, e.g. on SMS contents
that may really have additional purposes than just being
human-readable.
This commit makes the transliteration option to be explicitly
requested by the caller.
There's no point in adding a quoting option to this method; if the
caller needs the appended string quoted, it should quote it before
passing it to this method.
It was nowhere used anyway.
If we were requesting for IPv4v6 and we only got IPv4 reported as
activated, we would right away ignore the IPv6 bits, even if we
received IPv6 settings later on when querying for them. Change that,
so that if an IP address of a given type is received, we assume the
corresponding context was really activated even if the modem didn't
report it in the connect set response.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/320
ModemManager[115879]: <debug> [1613341789.760031] [modem3] completely disposed
(ModemManager:115879): GLib-CRITICAL **: 23:29:49.760: Source ID 2379 was not found when attempting to remove it
Thread 1 "ModemManager" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff774b343 in g_logv () from /usr/lib/libglib-2.0.so.0
(gdb)
(gdb) bt
#0 0x00007ffff774b343 in g_logv () at /usr/lib/libglib-2.0.so.0
#1 0x00007ffff774b5c0 in g_log () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff7741c9e in g_source_remove () at /usr/lib/libglib-2.0.so.0
#3 0x00005555555aad02 in dispose (object=0x555555831260) at mm-device.c:802
#4 0x00007ffff7843755 in g_object_unref () at /usr/lib/libgobject-2.0.so.0
#5 0x00005555555a5107 in glib_autoptr_clear_MMDevice (_ptr=0x555555831260) at mm-device.h:63
#6 0x00005555555a5125 in glib_autoptr_cleanup_MMDevice (_ptr=0x7fffffffe090) at mm-device.h:63
#7 0x00005555555a59ab in device_removed (self=0x555555769220, subsystem=0x55555577dc50 "tty", name=0x555555869a40 "ttyUSB3") at mm-base-manager.c:237
#8 0x00005555555a620d in handle_uevent (self=0x555555769220, action=0x5555558987b0 "remove", device=0x555555893840) at mm-base-manager.c:445
#9 0x00007ffff7381acd in () at /usr/lib/libffi.so.7
#10 0x00007ffff738103a in () at /usr/lib/libffi.so.7
#11 0x00007ffff783c8fe in g_cclosure_marshal_generic () at /usr/lib/libgobject-2.0.so.0
#12 0x00007ffff7837072 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#13 0x00007ffff785fa85 in () at /usr/lib/libgobject-2.0.so.0
#14 0x00007ffff78535dd in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#15 0x00007ffff7853b40 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#16 0x00007ffff7e792aa in () at /usr/lib/libgudev-1.0.so.0
#17 0x00007ffff7742b84 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#18 0x00007ffff7796c21 in () at /usr/lib/libglib-2.0.so.0
#19 0x00007ffff77420d3 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#20 0x00005555555a1df4 in main (argc=2, argv=0x7fffffffea88) at main.c:213
On some modem (for example SORACOM SC-QGLC4-C1) , the character set setup
step fails with "Unknown error" when the SIM card is missing or locked.
This leads to not expose Modem interface and not being able to unlocked
the SIM.
We should not consider this step as fatal but just issue a warning to let
other steps continue (which will let modem in failed state anyway).
Closes#289
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
We can rely on QMI indications when the signal quality and access tech
changes happen, instead of doing explicit polling.
The modem will run the signal quality retrieval once, and then just
rely on indications, with polling disabled:
ModemManager[278759]: <debug> [1606862198.230492] [modem1] signal strength (lte): -79 dBm
ModemManager[278759]: <debug> [1606862198.230520] [modem1] signal strength: -79 dBm --> 55%
ModemManager[278759]: <debug> [1606862198.230583] [modem1] access technology changed (unknown -> lte)
ModemManager[278759]: <debug> [1606862198.230654] [modem1] signal quality updated (55)
ModemManager[278759]: <debug> [1606862198.230675] [modem1] periodic signal quality and access technology checks not rescheduled: unneeded or unsupported
ModemManager[278759]: <debug> [1606862198.230692] [modem1] periodic signal checks disabled
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/231
When comparing bearer properties provided by the user versus loaded
from the modem, we shouldn't be very strict, e.g.:
* Password or other fields may not be readable from the device.
* Some fields may not apply at all (e.g. RM protocol for EPS bearers)
* NULL strings could be assumed equal to empty strings.
* If no explicit IP type specified, an IPv4 default may be assumed.
* If no explicit allowed auth specified, 'none' default may be
assumed.
These loose comparisons are applied when managing the initial EPS
bearer settings and status, and we keep the strict comparison only
during the connection attempt lookup of a bearer with certain
settings, as those bearer objects are all created in the same place
with the same rules.
This property (initially set to FALSE) controls whether QMI over MBIM
should never be considered. This property is set to TRUE for XMM-based
MBIM devices as they don't support QMI.
This fixes a probing delay of 15s on a Fibocom L850-GL device
(2cb7:0007) found in the Lenovo T14 Gen 1.
The establishing of a QMI connection was refused multiple time with
MBIM error OperationNotAllowed. Only the timeout of 15s for this
connection resumed the probing.
The properties in the MMBroadbandModemMbim are only installed when
WITH_QMI and QMI_MBIM_QMUX_SUPPORTED are set. Actually, this should only
disable the PROP_QMI_UNSUPPORTED but as this is the only property this
avoids the "unused variable 'self'" warnings/errors when trying to
compile set_property and get_property without QMI support. This can be
changed once other properties are needed.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/284
We had all the logic in place... but we were never actually enabling
the signal strength indications because the `enable` flag in the
context was never set.
The bug was introduced back in May 2018, and released with 1.10.0.
Fixes baefe53ab9
Do not fail to detect an error response with a call or text incoming. This happens during port probing when there's no URC parsers installed in the serial port. This probably will not happen when the serial port was managed by the modem object.w
Do not fail to detect a valid response with a call or text incoming.
This happens also during port probing when there's no URC parsers
installed in the serial port. This probably will not happen when the
serial port was managed by the modem object.
Aleksander Morgado
Dylan Van Assche
Andrew Lassalle
Frederic Martinsons
Torsten Hilbrich