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.
Allocate the results instead of passing them back on the stack, which removes
the "can't complete in idle" restriction. Also always open the QCDM port
since we can't assume it will be open already at this point.
Instead of mixing the QCDM Novatel Snapshot code directly into the
access technology checking code, split it out with its own async
result. At the same time, make sure to open the QCDM port when
it's needed, instead of assuming its already open. Since it won't
always be.
Some modems do not support CSIM lock/unlock, but they do support
querying SIM unlock retries through +CSIM command.
If CSIM lock returns with "unsupported command" do not propagate
the error and continue with the other CSIM queries instead, moreover the
CSIM lock feature is signed as FEATURE_UNSUPPORTED in Telit modem
private structure to prevent being sent again (e.g. calling CSIM
unlock AT command).
The MMPortProbe object is already referenced by the GTask object for
custom init. Instead of keeping another reference of MMPortProbe in the
CustomInitContext, this patch changes the code to simply obtain it from
the source object of GTask.
See https://lists.freedesktop.org/archives/modemmanager-devel/2017-April/004420.html
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
Looks like a C&P error from the AT#PSNT codepath; all the docs
I can find indicate that AT+SERVICE returns only an integer and
no commas:
<debug> (ttyUSB2): --> 'AT+SERVICE?<CR>'
<debug> (ttyUSB2): <-- '<CR><LF>+SERVICE: 3<CR><LF><CR><LF>OK<CR><LF>'
<debug> Couldn't refresh access technologies: 'Failed to parse +SERVICE response: '+SERVICE: 3''
Commit f9c63bfa0 "build,plugins: update build rules" accidentally
changed the Novatel LTE plugin from 'libmm-plugins-novatel-lte.so' to
'libmm-plugins-novatel_lte.so'. The name becomes inconsistent with other
plugin names.
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_object_unref is in form of `void (*)(gpointer)`, which matches the
GDestroyNotify signature. An explicit GDestroyNotify cast on
g_object_unref is thus not needed.
g_object_unref is in form of `void (*)(gpointer)`, which matches the
GDestroyNotify signature. An explicit GDestroyNotify cast on
g_object_unref is thus not needed.
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.
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.
Vendor specific plugins that support QMI or MBIM based devices need to
handle the creation of these modems themselves.
https://bugs.freedesktop.org/show_bug.cgi?id=100372
Original patch by Aleksander Morgado.
