Since commit 2d700043ab ("core: use g_unix_signal_add() for more
reliable Unix signal handling") we no longer have to stick to
signal-safe functions in the SIGTERM/SIGINT handler.
Use exit() to terminate so that the clean-up functions are ran and code
coverage data gets written into files.
Build all targets, except for CLI tools (mmcli, uml290), with special
flags needed for collecting code coverage information when the build has
been configured with --enable-code-coverage.
Three new targets are available in the top build directory:
- `check-code-coverage' runs the test suite and generates a code
coverage report,
- `code-coverage-capture' generates a code coverage report from already
collected data, which can come in handy when one wants to see code
paths touched by a particular test,
- `code-coverage-clean' removes the collected coverage data and the
generated reports.
This facility cannot be retrieved via 'DMS UIM Get CK Status' and seems
currently unimplemented for mm-broadband-modem-qmi. The SIM enabled
status is however available via 'DMS UIM Get PIN Status'.
Using this message to add the retrieval of PIN status just after the
other facilities were queried.
Succesfully tested with Gobi2000 (05c6:9205), both retrieval of 3gpp
SIM lock status and enabling/disabling the PIN.
Bluetooth serial devices are weird. They begin life being bound with
RFCOMMCREATEDEV ioctl() and then move around the sysfs tree when they are
connected and disconnected. The connection is estabilished upon the first
open() and torn down upon last close(), their first user virtually being
"owner" of the connection. We don't want to be that process, we're only
interested in actually connected modems. However, currently we have no
knowledge of that and therefore we connect and disconnect multiple times while
probing.
This patch marks unconnected RFCOMM devices as uninteresting to us.
The actual connection and disconnection will be handled by NetworkManager.
For certain devices the name changes with their status. Notably, RFCOMM
devices move from /devices/virtual/ to underneath the HCI that is used
for the connection as the session is estabilished, and return back when
it's torn down.
My modem (Samsung GI B3740) responded "IPV4" to "CGDCONT=?". This was
not handled in mm-modem-helpers.c. The obvious fix was to return
MM_BEARER_IP_FAMILY_IPV4.
When the MBIM modem unexpectedly loses connection the port state never
gets set as disconnected thus when trying to reestablish a new
connection the bearer cannot find a port in the disconnected state.
Signed-off-by: Greg Suarez <gpsuarez2512@gmail.com>
b28230411 moved up the self->priv->forced_close = TRUE, which
caused mm_port_serial_close() to just return without actually
closing the port and cleaning up.
Also, cancel the reopen separately from closing the port since
the two operations are actually independent of each other.
This patch fixes the registration reporting/checking when ModemManager is
built with --with-newest-qmi-commands. apply_cs and apply_ps were not
properly initialised and may never be true. Also fixes a CnP error for
mm_ps_registration_state.
Signed-off-by: David McCullough <david.mccullough@accelecon.com>
This patch fixes the signal strength values when using ModemManager built
with --with-newest-qmi-commands.
It was never getting a valid signal strength because the default (0) is
always greater than a valid signal strength, and the rssi_max handling
was completely wrong.
Signed-off-by: David McCullough <david.mccullough@accelecon.com>
The new 'ID_MM_PORT_IGNORE' tag will tell ModemManager to fully avoid using a
given port.
Note that it is key to not only flag the port probe as ignored, but also to
fully ignore the ports in e.g. mm_port_probe_list_has_qmi_port() as those
methods will be used to decide which kind of modem object to create. We don't
want to create a QMI-based modem which may have all QMI ports blacklisted.
E.g. this would be the result when having ModemManager compiled without QMI
support, and a modem with 2 QMI/WWAN pairs:
$ mmcli -m 2
/org/freedesktop/ModemManager1/Modem/2 (device id '417e4dcff7f232b62cfe6c972e2099701848fd7f')
-------------------------
Hardware | manufacturer: 'Sierra Wireless, Incorporated'
| model: 'MC7304'
| revision: 'SWI9X15C_05.05.02.00 r19147 carmd-fwbuild1 2013/11/15 13:54:28'
| supported: 'gsm-umts'
| current: 'gsm-umts'
| equipment id: 'unknown'
-------------------------
System | device: '/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7'
| drivers: 'qcserial, qmi_wwan'
| plugin: 'Gobi'
| primary port: 'ttyUSB8'
| ports: 'ttyUSB8 (at), wwp0s29u1u7i8 (unknown), ttyUSB6 (qcdm), wwp0s29u1u7i10 (unknown)'
The /dev/cdc-wdm ports don't even appear (as they were not even probed), but the
newly ignored WWAN ports do appear in the list, but flagged as UNKNOWN type
(instead of NET).
Modems may expose ports that are either just not used (e.g. modems exposing more
than 2 functional AT ports) or explicitly avoided (e.g. WWAN ports when we don't
know how to use them).
Those kind of ports are part of the modem, but not used by ModemManager. Still,
ModemManager should list them in the list of ports available for the modem, with
IGNORED type.
Some newer modems (Huawei E1750, Sierra 73xx) provide what looks like
legitimate static IPv4 configuration through the WDSGetCurrentSettings
call, but when configured the interface does not pass traffic. Running
DHCP on the same interface provides a slightly different IPv4
configuration but does allow traffic to pass.
Since QMI was switched to static originally for consistency with IPv6
and for speed of IP configuration (since DHCP takes a bit of time), but
not for any known problems with modems, let's switch back to DHCP until
we have time to figure out what's actually going on.
We have a report of a modem that switches access technologies frequently,
in this case almost every 10 seconds. While that's unusual, it's not
unexpected depending on the RF environment. We shouldn't spam syslog
with that info; if we need it we can get it with mmcli.
So, we may have modems with multiple /dev/cdc-wdm ports, like Ericsson modems,
where only 1 of them is MBIM. With the previous logic, we would probe all
/dev/cdc-wdm ports for MBIM as soon as one of the ports was handled by the
cdc_mbim driver. That is totally not optimal, as we are already know that they
are not MBIM (not handled by cdc_mbim).
Instead, fix the logic to just probe for MBIM or QMI if the actual driver
managing the port is MBIM or QMI.
It's been observed that some modems occasionally take a long time to
power down (which may be due to some shutdown sequence that involves
communicating with network). This patch increases the timeout for
powering modem up and down from 10s to 20s.
It's been observed that modems may take a long time to disconnect from
the network under certain network conditions. This patch increases the
timeout for the MBIM_CID_CONNECT set command in the disconnect sequence
from 10s to 30s.
VID/PID: 258d:e000
Instead of returning success and the PIN type + PIN status + Remaining attempts,
this modem returns a plain ERROR_PIN_REQUIRED error, so try to handle that...
Standard GPS setup (raw/nmea) will both enable the GPS module and take full
control of the GPS port. This prevents other processes from reading the NMEA
traces from e.g. a tty. In order to handle this, a new 'unmanaged' GPS location
source is introduced, which will just enable/disable the GPS module, without
reading anything from the GPS port. Of course, both raw/nmea and unmanaged
setups cannot be enabled at the same time.
