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.
Looks like make targets for generating code coverage reports with LCOV
were copied from GLib but corresponding changes to configure.ac were not
made. Clean it up.
This patch increases the response timeout for the probe AT commands for
altair modems.
We've been noticing some altair modems taking upto 6 seconds to respond to the
initial probe command after a reset which results in modem-manager
timing out and sending a second probe command. The modem sends a response
after about 6 seconds for the initial probe command which modem-manager
treats as response to second probe command and this results in the
modem-manager and modem going out of sync because the modem's second
probe response is treated as response to the next initialization AT command
sent by modem-manager and so on.
Change-Id: Iad8b0786327b153fd95c8ee4516f352325a42cf7
Newer huawei modems, like the E3372, use the following ^GETPORTMODE response
format:
^GETPORTMODE: TYPE: WCDMA: ,pcui:1,modem:2,ncm:3,mass:4,mass_two:5,
This patch updates the parser that looks for the control TTY (pcui) and data TTY
(modem).
https://bugs.freedesktop.org/show_bug.cgi?id=86658
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.
The timeout for starting ModemManager on the test bus was 3s, which is
sufficient under normal conditions. However, when running ModemManager
tests on a build infrastructure under a heavy load, we've observed that
the timeout isn't always sufficient and that becomes the source of false
test failures. This patch increases the timeout to 30s, which shouldn't
introduce any unexpected behavior under normnal conditions while
addressing the timeout issue on heavily loaded systems.
We don't want people to use the logic enabled by this switch, so remove it from
configure to avoid confusions. Developers can still enable the related code by
defining WITH_NEWEST_QMI_COMMANDS via CFLAGS; e.g.:
$ NOCONFIGURE=1 ./autogen.sh
$ ./configure CFLAGS="-DWITH_NEWEST_QMI_COMMANDS"
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 MF60 exposes a QMI+net pair, but they are unusable as the WDS service
returns error when e.g. launching a connection.
So, fallback to AT+PPP in this device.
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.
