If ModemManager fails to open a QMI port with data format update, it
retries without update. It would be useful to log the reason why the
first try failed; for example on RHEL 7.6 ModemManager fails to write
to sysfs due to SELinux. With this commit, the following message would
be logged:
<debug> QMI port open operation finished
<debug> Couldn't open QMI port with data format update: Expected data
format not updated properly: Failed to open file
'/sys/class/net/wwp0s29u1u2i8/qmi/raw_ip' for R/W: Permission denied
<debug> Opening QMI device...
instead of just:
<debug> QMI port open operation finished
<debug> Opening QMI device...
While at it, also fix the GError leak.
When the MBIM port open involved transparently trying to open a QMI
device as well, we were clearing the progress flag before the full
operation had finished, and so the port could have been closed by
the time we really finish the open operation, leading to a crash:
ModemManager[28824]: <info> [1547386038.726136] (usbmisc/cdc-wdm3): released by device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <info> [1547386038.728084] (tty/ttyUSB0): released by device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <info> [1547386038.728738] (tty/ttyUSB1): released by device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <info> [1547386038.730769] (tty/ttyUSB2): released by device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <info> [1547386038.731256] (tty/ttyUSB3): released by device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <debug> [1547386038.731301] Removing empty device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <debug> [1547386038.731445] (ttyUSB0) forced to close port
ModemManager[28824]: <debug> [1547386038.731547] (ttyUSB1) forced to close port
ModemManager[28824]: <debug> [1547386038.731638] (ttyUSB2) forced to close port
ModemManager[28824]: <debug> [1547386038.731715] (ttyUSB3) forced to close port
ModemManager[28824]: <debug> [1547386039.580136] [cdc-wdm3] error: couldn't open QmiDevice: MBIM error: Transaction timed out
ModemManager[28824]: <info> [1547386039.580190] [cdc-wdm3] MBIM device is not QMI capable
**
ERROR:mm-broadband-modem-mbim.c:2119:track_mbim_device_removed: assertion failed: (device)
Thread 1 "ModemManager" received signal SIGABRT, Aborted.
0x00007ffff7390d7f in raise () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7390d7f in raise () at /usr/lib/libc.so.6
#1 0x00007ffff737b672 in abort () at /usr/lib/libc.so.6
#2 0x00007ffff7559042 in () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff75865dc in g_assertion_message_expr () at /usr/lib/libglib-2.0.so.0
#4 0x00005555556407f9 in track_mbim_device_removed (self=0x5555557a2830, mbim=0x5555557ea190) at mm-broadband-modem-mbim.c:2119
#5 0x000055555564093e in mbim_port_open_ready (mbim=0x5555557ea190, res=0x55555573fcf0, task=0x5555557d29d0) at mm-broadband-modem-mbim.c:2161
#6 0x00007ffff77742f4 in () at /usr/lib/libgio-2.0.so.0
#7 0x00007ffff7776cd7 in () at /usr/lib/libgio-2.0.so.0
#8 0x000055555565fcd5 in qmi_device_open_ready (dev=0x55555578f250, res=0x55555573fb50, task=0x55555573fcf0) at mm-port-mbim.c:191
#9 0x00007ffff77742f4 in () at /usr/lib/libgio-2.0.so.0
#10 0x00007ffff7776cd7 in () at /usr/lib/libgio-2.0.so.0
#11 0x00007ffff7c03fe6 in open_version_info_ready (client_ctl=0x7fffe8010c20, res=0x555555739e80, task=0x55555573fb50) at qmi-device.c:2050
#12 0x00007ffff77742f4 in () at /usr/lib/libgio-2.0.so.0
#13 0x00007ffff7776cd7 in () at /usr/lib/libgio-2.0.so.0
#14 0x00007ffff7c2034f in get_version_info_ready (device=0x55555578f250, res=0x5555557ea2a0, task=0x555555739e80) at qmi-ctl.c:3746
#15 0x00007ffff778ebcf in g_simple_async_result_complete () at /usr/lib/libgio-2.0.so.0
#16 0x00007ffff778ec5a in () at /usr/lib/libgio-2.0.so.0
#17 0x00007ffff75a98d1 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#18 0x00007ffff75ab5e9 in () at /usr/lib/libglib-2.0.so.0
#19 0x00007ffff75ac5c2 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#20 0x0000555555599eb0 in main (argc=2, argv=0x7fffffffe4c8) at main.c:181
This new method allows users of the ModemManager API to take full
control of a given device.
Unlike other operations in the API, the inhibition is maintained as
long as the caller exists in the bus, or until the same caller
uninhibits the device.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/98
Since the Firmware interface now contains more actions and properties
apart from List() and Select(), these two actions are now optional.
Not all modems implementing the Firmware interface must implement
these two methods.
We no longer "check for support" of this interface, it will always be
available for all modem objects.
The only implementation that used this interface was the QMI one, and
only for a very small subset of devices (those supporting the "QMI DMS
List Stored Images" operation). The logic was changed so that the list
of stored images wasn't preloaded during the support check; it will
now instead be preloaded during the first call to List().
ModemManager[2804]: <warn> [1545055222.508649] No valid firmware images listed. Assuming firmware unsupported.
ModemManager[2804]: <debug> [1545055222.508665] firmware list loading failed: unsupported
ModemManager[2804]: <debug> [1545055222.508683] Couldn't load firmware image list: firmware list unknown
ModemManager[2804]: <debug> [1545055222.508728] Couldn't load current firmware image: current firmware unknown
(ModemManager:2804): GLib-CRITICAL **: 15:00:22.508: g_variant_builder_end: assertion '!GVSB(builder)->uniform_item_types || GVSB(builder)->prev_item_type != NULL || g_variant_type_is_definite (GVSB(builder)->type)' failed
Thread 1 "ModemManager" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff75b39b6 in ?? () from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff75b39b6 in () at /usr/lib/libglib-2.0.so.0
#1 0x00007ffff75b4363 in g_logv () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff75b4560 in g_log () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff758867d in g_variant_builder_end () at /usr/lib/libglib-2.0.so.0
#4 0x00005555555e4d12 in load_current_ready (self=0x55555579c330, res=0x5555557388e0, ctx=0x5555557d6d80) at mm-iface-modem-firmware.c:84
#5 0x00007ffff778f194 in () at /usr/lib/libgio-2.0.so.0
#6 0x00007ffff778f1c9 in () at /usr/lib/libgio-2.0.so.0
#7 0x00007ffff75c4271 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#8 0x00007ffff75c5f89 in () at /usr/lib/libglib-2.0.so.0
#9 0x00007ffff75c6f62 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#10 0x0000555555597aa0 in main (argc=2, argv=0x7fffffffe488) at main.c:181
The standard says a RING or CRING should be emitted whenever the
network sends an incoming call notification, which is nation-specific:
"Interpretation of indications from the network to determine what
constitutes a "ring" is defined by national regulations. This
result code should be repeated each time the network repeats the
incoming call indication." -- ITU-T Rec. V.250, p. 42
On the giffgaff (O2) network in the UK, a SIMCom SIM7100E modem emits
RING indicators every six seconds. The current timeout is only five
seconds resulting in a stream of timed-out ModemManager call objects
whenever there is an incoming call. To fix this, we increase the
timeout to ten seconds.
The handler assumes the regex sub-expressions each have the same index
so they need to be within the same set of parentheses rather than each
individually parenthesised. Without this fix, call state changes are
missed.
So that the returned error is much more descriptive.
E.g. instead of this:
$ sudo mmcli -m 0 -e
error: couldn't enable the modem: 'GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method Enable is not implemented on interface org.freedesktop.ModemManager1.Modem'
We'll get this:
$ sudo mmcli -m 0 -e
error: couldn't enable the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.WrongState: modem in failed state'
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/96
When the MMIfaceModem initialization returns with the SIM_NOT_INSERTED
error, the base logic is already updating the modem failed reason to
SIM_MISSING. There is no need to do that explicitly for the case where
SIM hot swap is supported.
This property contains the DBus path of a Bearer object of type
MM_BEARER_TYPE_DEFAULT_ATTACH, which is automatically exposed by the
modem when registered in the LTE network.
Unlike standard bearer objects created by the user, this bearer won't
allow any connection/disconnection request, as its status is bound to
the LTE registration exclusively.
The bearer settings exposed by the object include the APN details that
have been used during the initial packet network attach, which may be
defined by modem settings (e.g. if previously configured in the
firmware which APN to use for the given SIM card operator) or by the
network itself (e.g. if none configured, or if a network override is
required as when roaming).
The bearer object will be created as soon as the LTE attach status
details are known, and only while the modem is enabled. The
implementation allows modems to update the LTE attach status details
during runtime, so the bearer object with the settings may be
recreated during runtime as well.
Until now we have only allowed to use and setup 'default bearers' (in
4G) or 'primary contexts' (in 2G/3G).
We can define a couple of additional bearer types, though:
* The 'dedicated bearers' (in 4G) or 'secondary contexts' (in 2G/3G),
which are associated to a specific default/primary one, but which
provide specific QoS settings configured via traffic flow templates.
* The 'initial default EPS bearer', which is a special case of default
bearer in LTE, which is automatically created and connected when the
modem is registered in the LTE network.
This commit introduces a new 'MMBearerType' enumeration that will be
associated to each bearer through a 'BearerType' property in the
org.freedesktop.ModemManager1.Bearer interface, showing what kind of
bearer/context this is.
By default, right now, all bearer objects created are 'default'
bearers.
The +CGEV indications allow us to get notified of packet domain
events like network-initiated or ME-initiated disconnections on
specific connected contexts, as well as full PS detach events (all
contexts disconnected). If the modem supports these indications, we
will enable them with +CGEREP and will then process them when they are
emitted by the modem.
If a full PS detach event happens, we will explicitly disconnect all
connected bearers.
If a deactivation inidication is received for a single context, we
will look for the associated bearer by CID and explicitly disconnect
it.
libmbim 1.17.4 (commit 3eeaa4248b98 "ms-basic-connect-extensions: rename
service") added a MS prefix to the Basic Connectivity Extensions
service. This patch updates the MMBroadbandModemMbim code accordingly.
If a QMI modem doesn't support the deprecated DMS_UIM_GET_IMSI command,
use the UIM_READ_TRANSPARENT command to read EFimsi on the SIM to
determine the IMSI.
If a QMI modem doesn't support the deprecated DMS_UIM_GET_ICCID command,
use the UIM_READ_TRANSPARENT command to read EFiccid on the SIM to
determine the ICCID.
This patch adds a mm_bcd_to_string() helper function to convert a byte
array representing a binary-coded decimal (BCD) number to a string
representing the equivalent decimal number.
Modems that require specific commands to setup or cleanup the audio
channel as soon as a call is ongoing can subclass these two new
methods.
The setup() method is considered part of the call start/accept
process, and so if it fails, the whole operation will fail.
The failures in the cleanup() method will be reported in the log, but
otherwise ignored, as this operation may be executed without any
user intervention (e.g. if the remote party hangs up).
Aleksander Morgado
Daniele Palmas
Beniamino Galvani
Bob Ham
Ben Chan
Dan Williams