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.
Since commit e9d0989ed0, the MMDevice may be removed from the
tracking hash table when the support check operation fails to create a
modem object.
If this failure happens due to the port probe cancellations requested
during the udev removal event for a given device port, we would end up
using an already disposed object and triggering a segfault.
This fix just makes sure a full valid reference to the MMDevice object
is kept around until we're done using it.
[mm-base-manager.c:216] device_removed(): (usbmisc/cdc-wdm1): released by device '/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.4'
[mm-plugin-manager.c:1131] device_context_port_released(): [plugin manager] task 5: port released: cdc-wdm1
[mm-base-manager.c:216] device_removed(): (tty/ttyACM0): released by device '/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.4'
[mm-plugin-manager.c:1131] device_context_port_released(): [plugin manager] task 5: port released: ttyACM0
[mm-base-manager.c:221] device_removed(): Removing empty device '/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.4'
[mm-plugin-manager.c:1219] device_context_cancel(): [plugin manager) task 5: cancellation requested
[mm-plugin-manager.c:979] device_context_continue(): [plugin manager] task 5: no more ports to probe
[mm-plugin-manager.c:813] device_context_complete(): [plugin manager] task 5: finished in '0.090510' seconds
[mm-base-manager.c:172] device_support_check_ready(): Couldn't check support for device '/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.4': Operation was cancelled
[mm-base-manager.c:223] device_removed(): Device support check has been cancelled
Thread 1 "ModemManager" received signal SIGSEGV, Segmentation fault.
0x00007ffff6543c50 in g_str_hash () from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff6543c50 in g_str_hash () at /usr/lib/libglib-2.0.so.0
#1 0x00007ffff6542b2d in () at /usr/lib/libglib-2.0.so.0
#2 0x0000000000439675 in device_removed (self=0x770900, kernel_device=0x763e60) at mm-base-manager.c:225
#3 0x0000000000439e70 in handle_uevent (client=0x769c20, action=0x81d910 "remove", device=0x7fffe4001c40, user_data=0x770900) at mm-base-manager.c:415
#4 0x00007ffff54c61c8 in ffi_call_unix64 () at /usr/lib/libffi.so.6
#5 0x00007ffff54c5c2a in ffi_call () at /usr/lib/libffi.so.6
#6 0x00007ffff682d7ae in g_cclosure_marshal_generic ()
at /usr/lib/libgobject-2.0.so.0
#7 0x00007ffff682cf75 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#8 0x00007ffff683ef82 in () at /usr/lib/libgobject-2.0.so.0
#9 0x00007ffff6847bcc in g_signal_emit_valist ()
at /usr/lib/libgobject-2.0.so.0
#10 0x00007ffff6847faf in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#11 0x00007ffff7023c74 in () at /usr/lib/libgudev-1.0.so.0
#12 0x00007ffff655445a in g_main_context_dispatch ()
at /usr/lib/libglib-2.0.so.0
#13 0x00007ffff6554810 in () at /usr/lib/libglib-2.0.so.0
#14 0x00007ffff6554b32 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#15 0x0000000000437bf5 in main (argc=2, argv=0x7fffffffeb28) at
main.c:180
(gdb) fr 2
#2 0x0000000000439675 in device_removed (self=0x770900, kernel_device=0x763e60) at mm-base-manager.c:225
225 g_hash_table_remove (self->priv->devices, mm_device_get_uid (device));
(gdb) p mm_device_get_uid (device)
$1 = (const gchar *) 0x0
(gdb) p *device
$3 = {parent = {g_type_instance = {g_class = 0x0}, ref_count = 0, qdata = 0x0}, priv = 0x7feb20}
When calling g_list_free_full() to free a GList in dispose(), it is
necessary to reset the GList pointer to NULL as dispose() may be called
more than once.
g_free and g_object_unref are in form of `void (*)(gpointer)`, which
matches the GDestroyNotify signature. An explicit GDestroyNotify cast on
g_free and g_object_unref is thus not needed.
Aleksander Morgado
Javier Viguera
Dan Williams
Maksim Salau
Ben Chan
Thomas Voß