The generic modem has several URC handlers for generic messages, like
+CIEV. But, there may be cases where the plugins themselves want to
provide their own URC handlers to be run before the generic one.
This patch enables this setup by always prepending the new URC
handlers, so that the last ones added are processed before the ones
already in the list. So if a plugin does its own unsolicited
messages setup, they can run first the parent setup and then their
own.
The only thing to consider is that the regex provided by the plugin
must be specific enough not to match the specific messages required
by the parent implementation.
We also remove the explicit refresh request from the Cinterion plugin,
as this is a generic action applicable to all modems that require
polling for signal quality and/or access technology.
Plugins have two ways to update signal quality and access technology
values: via unsolicited messages or via polling periodically.
Instead of keeping separate contexts for polling signal quality and
access technology values, we setup a common timeout to trigger
both. This allows us to simplify in which case the explicit update is
required, whenever one is needed to be explicitly updated, the other
one should also be.
The logic now also allows plugins to return an UNSUPPORTED error in
either load_signal_quality() and/or load_access_technologies() to tell
the interface logic that the polling of the specific item shouldn't be
performed (e.g. if the updates are expected via unsolicited messages).
If both signal quality and access technology polling is flagged as
disabled, we totally disable the polling logic internally.
The new SignalCheckContext is bound to the lifetime of the object so
that we can keep the value of the supported flags until the object is
destroyed.
If we ask too quick for the PDP context status after a successful
connection attempt reported by the modem, we may find it still flagged
as inactive if the modem is still busy setting up the PPP session.
Do an explicit longer initial timeout before we run the first check,
and after that one setup the additional checks at a higher rate.
Reported-by: Colin Helliwell <colin.helliwell@ln-systems.com>
Don't blindly try '+CMER=3,0,0,1' to enable and '+CMER=0' to disable
Mobile Equipment Event Reporting. We now query the device for the
supported formats and use that info to build commands that will work.
The whitelist made all platform TTYs managed by the 'atmel_usart'
kernel driver probed by ModemManager, which isn't something we want,
as most of these aren't broadband modems.
We leave the logic supporting the ID_MM_PLATFORM_DRIVER_PROBE udev tag
as there may be a case where the user does need ModemManager to probe
a given platform TTY.
The user can build the project passing custom CFLAGS to enable the
function location information, e.g.:
$ ./configure --prefix=/usr CFLAGS="-DMM_LOG_FUNC_LOC"
Group together all options that allow configuring the logging output,
and make them have the same --log-[XXX] prefix.
Also rework the --help output so that all option groups are printed by
default (i.e. there is no longer a --help-all option).
Blacklist the default VID:PID for the Linux USB Serial Gadget in ACM
mode:
{LINUX}/drivers/usb/gadget/legacy/serial.c
#define GS_VENDOR_ID 0x0525 /* NetChip */
#define GS_CDC_PRODUCT_ID 0xa4a7 /* ... as CDC-ACM */
This should never be reused for real products by hardware
manufacturers, but anyway...
Patch actually ported from downstream Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1105352
If going directly e.g. from "Searching" to "Connecting", just setup
the signal quality retrieval logic right away, don't assume we always
go through "Registered" state before starting a connection.
Reported-by: <colin.helliwell@ln-systems.com>
Commit 26ee94ec28 introduced a bug, where we would be completing
the client allocation task *before* tracking the new client allocation
info in the private tracking list.
This meant that if mm_port_qmi_peek_client() was called in the task
completion handler, the client object wouldn't be returned, as it
wasn't found in the private tracking list.
The fix is just to defer the task completion until after the private
tracking list is updated.
Reported-by: Salvador Penalva <salvador.penalva@digi.com>
When the GCancellable is added to the GTask, we can use a single
method call to check for the task being cancelled, and complete it
right away if so.
This patch also clears up the logic in the Novatel plugin, where the
code was trying to return "TRUE" when the task was cancelled, but
wouldn't work as the check-cancellable flag in the GTask is TRUE by
default (i.e. when completing the GTask, if it was cancelled, a
G_IO_ERROR_CANCELLED would be returned by default, regardless of any
other return value set).
This patch also introduces a small variation of the logic in the
Cinterion plugin: instead of running SWWAN=0 before completing the
async action, the command is now sent just after completion of the
async action. This shouldn't be an issue, as the SWWAN result itself
is ignored.
During modem initialization we detected the flow control settings
supported by the modem, and selected the best one to use from them,
notifying it to the device via AT+IFC. The device was therefore
instructed to use that flow control setting for data transmission in
the TTY (i.e. not during AT control commands).
The missing thing was to also configure ourselves our end of the
serial port with the same flow control settings when getting into data
mode. By doing it ourselves, we avoid requiring any explicit setting
in pppd for flow control; pppd can assume the flow control settings
are already the expected ones.
Worth noting that all this setup is completely ignored for TTYs
exposed directly via USB.
https://bugs.freedesktop.org/show_bug.cgi?id=100394
Instead of assuming XON/XOFF is supported, we query the supported flow
control modes, and then we set the best one based on that, preferring
hardware flow control over software flow control.
Instead of having the parser return separate list of supported flow
controls for TE and TA, we simplify it by only returning those
settings that apply to both TE and TA.
This logic isn't perfect either, though, as some settings (e.g. '3' in
TE in some modems, specifying a different XON/XOFF behavior) may not
have a corresponding setting in the other end.
The most common cases we care about (i.e. standard XON/XOFF, RTS/CTS)
should be properly reported with this logic.
This fixes the build after commit 740ce1fb26.
CC ModemManager-mm-auth-provider-polkit.o
../../src/mm-auth-provider-polkit.c: In function ‘authorize’:
../../src/mm-auth-provider-polkit.c:155:46: error: ‘AuthorizeContext’ has no member named ‘cancellable’
ctx->cancellable,
^
Makefile:1533: recipe for target 'ModemManager-mm-auth-provider-polkit.o' failed
The operator code (MCCMNC) may also be given encoded in the current
charset (e.g. UCS2).
Based on a patch from Colin Helliwell <colin.helliwell@ln-systems.com>
The method doing the operator name normalization takes as input the
current configured modem charset. If this is UCS2, we will now just
assume this is a hint: the string may or may not come in hex/UCS2.
This logic makes the custom operator name loading in Huawei unneeded,
if the modem is configured in UCS2, we still properly process operator
names coming in plain ASCII.
Aleksander Morgado
Javier Viguera
Dan Williams
Maksim Salau
Ben Chan
Thomas Voß