PyGIWarning: ModemManager was imported without specifying a version first. Use gi.require_version('ModemManager', '1.0') before import to ensure that the right version gets loaded.
The mm_iface_modem_is_*_only() checks were validating that all the other
capabilities except for the ones being queried were unset, but the check wasn't
explicitly checking that the actual capabilities being queried were set.
This was making the check fail when capabilities == MM_MODEM_CAPABILITY_NONE.
Reported-by: Matthew Stanger <stangerm2@gmail.com>
Deciding the IP method to use based on the underlying QMI port LLP should not be
done when the bearer object is created, because the QMI port in use may not
actually be open or have been opened at that time. During the connection attempt
we do make sure the QMI port is open, so we should check the LLP to use just
after that step.
When the logic decided that we had to update the kernel data format to match the
one configured in the WWAN network interface, we were not flagging the port LLP
with the correct value, what resulted in NetworkManager trying to use dhclient
on the raw-ip interface:
dhclient[3257]: Unsupported device type 65534 for "wwan1"
dhclient[3257]:
dhclient[3257]: If you think you have received this message due to a bug rather
dhclient[3257]: than a configuration issue please read the section on submitting
dhclient[3257]: bugs on either our web page at www.isc.org or in the README file
dhclient[3257]: before submitting a bug. These pages explain the proper
dhclient[3257]: process and the information we find helpful for debugging..
dhclient[3257]:
dhclient[3257]: exiting.
Fix the internal LLP flag, so that Static IP addressing is requested for all raw-ip
based interfaces.
The "0" case wasn't being handled properly:
$ sudo mmcli -m 0 --create-bearer="apn=,allow-roaming=0"
Error parsing properties string: 'Cannot get boolean from string '0''
When we were completing tasks in idle, the logic was like this:
* Schedule task completion in idle
* self->priv->task = NULL
* (idle) Task completion callback called
This meant that the self->priv->task was always set to NULL before the
completion callback was called, which is what we wanted as a new task may be
scheduled in the callback itself.
Now, without completing in idle, we were wrongly doing:
* Task completion callback called
* self->priv->task = NULL
This commit fixes the logic by making sure self->priv->task = NULL before any
task completion.
The options that require an argument should explicitly specify so.
Before:
--log-level=INFO Log level: one of [ERR, WARN, INFO, DEBUG]
--log-file Path to log file
After:
--log-level=[LEVEL] Log level: one of ERR, WARN, INFO, DEBUG
--log-file=[PATH] Path to log file
html/MMCallProperties.html:141: warning: no link for: 'mm-modem-voice-create' -> (<code class="function">mm_modem_voice_create()</code>).
html/MMCallProperties.html:141: warning: no link for: 'mm-modem-voice-create-sync' -> (<code class="function">mm_modem_voice_create_sync()</code>).
html/MMModemVoice.html:379: warning: no link for: 'mm-modem-voice-delete-finish' -> (<code class="function">mm_modem_voice_delete_finish()</code>).
html/MMModemVoice.html:380: warning: no link for: 'mm-modem-voice-delete-sync' -> (<code class="function">mm_modem_voice_delete_sync()</code>).
We try to combine in common envvars the compiler and linker flags shared by the
different components, and where possible, also re-using the implicit AM_CFLAGS
and AM_LDFLAGS variables that automake provides, and which apply to all objects
being built in the same Makefile.am.
The plugins build rules are also updated so that whenever a plugin has some
testable 'helpers', these are compiled into a noinst library and then the new
library included by both the plugin and the tester program. This avoids multiple
recompilations of the same sources for different objects.
We try to combine in common envvars the compiler and linker flags shared by the
different components, and where possible, also re-using the implicit AM_CFLAGS
and AM_LDFLAGS variables that automake provides, and which apply to all objects
being built in the same Makefile.am.
The internal libmodem-helpers.la library is also renamed to libhelpers.la
The rule with multiple targets means that for each of the target the command
specified is run; not that a single run of the command generates all the targets
specified.
So, generate the .c file with the command, and make the .h and the .xml files
a side-effect of the .c generation.
Otherwise:
configure.ac:86: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its use is discouraged.
configure.ac:86: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead,
configure.ac:86: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your Makefile.am files.
Port serial command completions may be performed in several different places:
* When a cached response is set during command sending.
* When errors happen during command sending.
* When we process a response (i.e. common_input_available())
* When we process a timeout (i.e. port_serial_timed_out())
* When cancelled (i.e. port_serial_response_wait_cancelled())
We're currently safe with the previous logic only because the users of the
serial port explicitly complete operations in idle, which means that whenever
we're processing in a internal callback (e.g. during response or timeout
processing) the serial port object is valid for as long as the callback runs.
But, if we ever end up using the serial port with a not-in-idle completion,
it may happen that if the command is completed within a internal signal callback
the serial port object may get fully closed and unref-ed before exiting the
callback.
We could force a valid port reference to exist as long as the internal signal
is scheduled, but then we may lose the ability to automatically close the port
during a full unref(), as the internal signals are set as long as the port is
open.
So, to cope with this possibility of not-in-idle completion, we instead force
references to be valid whenever we see that a command completion may happen,
which is basically whenever port_serial_got_response() is called; but we only
do that if we're going to use the port object after that, otherwise, we ignore
the problem.
In addition to the problems with the references, we also update the
common_input_available() method so that the source isn't kept if the last
response buffer processing ended up closing the port.
The MMBroadbandModemQmi will not create a MMSimQmi until the unlock status has
been checked, and therefore this means that when the SIM object is being created
we already know whether the modem supports DMS UIM commands or not, so avoid
further fallbacks in the SIM object.
Newer modems like the MC7455 don't implement the "DMS UIM" commands in the
DMS service, and therefore these modems need to use the UIM service directly.
We include a new flag to detect whether any of the DMS UIM commands is flagged
as invalid, and if so, we'll fallback to the UIM specific implementations for
all.
libqmi version bump to 1.13.7, which includes the new required methods.
Newer modems like the MC7455 don't implement the "DMS UIM" commands in the
DMS service, and therefore these modems need to use the UIM service directly.
The port opening logic is changed completely.
Before this change, the logic would only try 802.3 setting via CTL when the
QmiDevice was being open.
With this new change, instead, we'll use WDA and the new libqmi APIs to query
the link layer protocol expected by both the device and the kernel. If the LLP
matches in both, we assume we're done; if they differ we'll try to update the
LLP expected by the kernel to the one setup in WDA. This change will allow us
to run with the modem using raw-ip if that is what WDA reports by default.
Also bumped the libqmi version to 1.13.6, which has support for the new required
APIs.
Response parsing was being done in different places for AT and QCDM subclasses;
in the case of AT it was being done early, before returning the byte array in
the mm_serial_port_command_finish() response. In the case of QCDM, it was being
done after mm_serial_port_command_finish(), and that was forcing every caller to
cleanup the response buffer once the response was processed.
With the new logic in this patch, the response is always parsed (i.e. looked for
a valid response or an error detected) before mm_serial_port_command_finish()
returns, and actually this method now returns a totally different GByteArray,
not the internal response buffer GByteArray, so there's no longer any need for
the caller to explicitly clean it up. The one doing the cleanup is the parser
method itself in every case.
This change also allows us to return serial port responses in idle, but that's
not changed for now as there's no immediate need.
When valid responses were returned to the caller of the serial command, the
caller itself was responsible for removing from the GByteArray the data that
it was successfully processed (all the data in AT, just 1 message in QCDM). But,
the same logic was missing for the case of errors; we were not explicitly
removing the response and therefore in some cases we would see it propagated
into the next command response. It was common to see this issue when the echo
removal was disabled in the serial port, as in Option/HSO modems:
<debug> (ttyHS3): --> 'AT+CNUM<CR>'
<debug> (ttyHS3): <-- '<CR><LF>+CME ERROR: 14<CR><LF>'
<debug> Got failure code 14: SIM busy
<debug> (ttyHS3) device open count is 1 (close)
<warn> couldn't load list of Own Numbers: 'Failed to parse NV MDN command result: -17'
<debug> (ttyHS3) device open count is 2 (open)
<debug> (ttyHS3): --> 'AT_OPSYS?<CR>'
<debug> (ttyHS3): <-- '<CR><LF>_OPSYS: 1,2<CR><LF><CR><LF>OK<CR><LF>'
<warn> couldn't load current allowed/preferred modes: 'Couldn't parse OPSYS response: '+CME ERROR: 14
_OPSYS: 1,2''
Since GLib 2.42, the sockets that are added to socket listeners may no longer
be closed automatically when the listener is finalized. In order to avoid that,
we will keep our own socket reference and close/unref it ourselves.
This issue was preventing adding new test cases with the same port names.
$ ./test-service-generic --verbose
GTest: random seed: R02S889153ee0f2e59c570f4edff9caa4176
GTest: run: /MM/Service/Generic/enable-disable
Activating service name='org.freedesktop.ModemManager1'
Successfully activated service 'org.freedesktop.ModemManager1'
(MSG: DEBUG: client connection closed)
(MSG: MESSAGE: Found modem at '/org/freedesktop/ModemManager1/Modem/0')
** Message: Found modem at '/org/freedesktop/ModemManager1/Modem/0'
(MSG: DEBUG: client connection closed)
GTest: result: OK
GTest: run: /MM/Service/Generic/cme-error-detected
Activating service name='org.freedesktop.ModemManager1'
Successfully activated service 'org.freedesktop.ModemManager1'
(MSG: FATAL-ERROR: Cannot bind socket: Error binding to address: Address already in use)
** (/home/aleksander/Development/foss/ModemManager/plugins/.libs/lt-test-service-generic:32043): ERROR **: Cannot bind socket: Error binding to address: Address already in use
We were wrongly using a main loop in the port context thread to manage the
global main context. That was silently making the DBus property notifications
kind of work, as they were being updated via another thread, so here we could
just sleep() and recheck the property values.
Given that having that unrelated thread updating the dbus properties of our
MMManager object is not a good thing, we'll instead totally ignore that and
fully re-create the MMManager in each iteration with the sync() method, which
has its own internal thread.
Instead of creating a new main context to be used in the thread, we were using
the global context. So, fix that, and create a totally new pair of main context
and main loop to be used within the thread.
We were trying to load the generic modes supported reported by either *CNTI=2 or
AT+WS46=?, so that then we could filter out the MBM-specific modes unsupported.
But, this may not be ideal, as both these two commands may fail:
[mm-broadband-modem.c:1612] modem_load_supported_modes(): loading supported modes...
[mm-port-serial.c:1237] mm_port_serial_open(): (ttyACM1) device open count is 3 (open)
[mm-port-serial.c:1294] _close_internal(): (ttyACM1) device open count is 2 (close)
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): --> 'AT*CNTI=2<CR>'
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): <-- '<CR><LF>ERROR<CR><LF>'
[mm-serial-parsers.c:364] mm_serial_parser_v1_parse(): Got failure code 100: Unknown error
[mm-broadband-modem.c:1546] supported_modes_cnti_ready(): Generic query of supported 3GPP networks with *CNTI failed: 'Unknown error'
[mm-port-serial.c:1237] mm_port_serial_open(): (ttyACM1) device open count is 3 (open)
[mm-port-serial.c:1294] _close_internal(): (ttyACM1) device open count is 2 (close)
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): --> 'AT+WS46=?<CR>'
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): <-- '<CR><LF>ERROR<CR><LF>'
[mm-serial-parsers.c:364] mm_serial_parser_v1_parse(): Got failure code 100: Unknown error
[mm-broadband-modem.c:1494] supported_modes_ws46_test_ready(): Generic query of supported 3GPP networks with WS46=? failed: 'Unknown error'
[mm-iface-modem.c:3974] load_supported_modes_ready(): couldn't load Supported Modes: 'Couldn't retrieve supported modes'
Instead, we'll ask the modem for the list of modes supported, and return that
directly.
Not making them '--location-enable|disable-signal' because that's the pattern
used to enable/disable location sources. Instead, use the '--location-set-*'
pattern, as that is what we're already using for the other location setup
update.
The default setup uses a refresh time of 30s, which means that even if the GPS
location updates are received at a higher frequency, the DBus interface will
still expose at most one update every 30s.
This patch includes a new "SetGpsRefreshTime()" method in the Location
interface, which takes a single 'u' parameter, specifying the refresh rate to
use, in seconds. This method also allows 0 being passed, which will make the
implementation to publish the GPS location updates are soon as ModemManager
detects them.
Along with the new method, a "GpsRefreshTime" read-only property is exposed
to specify the refresh time in effect.
The new method and property will only be applicable if the device has GPS
capabilities.
https://bugs.freedesktop.org/show_bug.cgi?id=89924
Use the "WDS Get Packet Statistics" method to query for the ongoing number
of bytes transmitted or received. The QMI implementation uses different WDS
clients for IPv4 and IPv6; the stats reported are a combination of the values
retrieved from both WDS clients.
The new property is a dictionary which may include different parameters,
depending on what is actually supported by the underlying modem. For now,
just bytes RX/TX.
Note that this object will expose the stats *as reported by the modem*. These
values may differ from e.g. what is seen in the network interface stats.
mmcli is GPLv2+; that's what --version has always said and that's what the
README in ModemManager sources specifies:
License.
The ModemManager and mmcli binaries are both GPLv2+.
The libmm-glib library is LGPLv2+.
The CPMS test parser was expecting 3 groups (parenthesis enclosed lists) of
memory IDs, e.g.:
+CPMS: ("SM","ME"),("SM","ME"),("SM","ME")
But some modems like the Huawei MU609 may just report single elements, not
groups, e.g.:
+CPMS: "SM","SM","SM"
This patch avoids using g_strsplit() to split the groups, as that is unaware
of the possible replies without groups. Instead, a new helper method is
implemented which does the group/item split itself, considering also the
possibility of a reply with mixed groups and non-groups, like e.g.:
+CPMS: ("SM","ME"),"SM","SM"
Additionally, we also now support the case where the groups are empty, e.g.:
+CPMS: (),(),()
https://bugs.freedesktop.org/show_bug.cgi?id=92243
Auth settings will be added in a QMI message only if at least one of these is
requested:
* An explicit auth preference is requested.
* User string is given and isn't empty.
* Password string is given and isn't empty.
Aleksander Morgado