| Age | Commit message (Collapse) | Author |
|---|
|
On u-blox modems it has been observed that attempting to force down the
bearer when the modem had an active data connection, lost the connection
but the bearer is still up, and the modem is searching for the network,
ModemManager would timeout before the CGACT command could return. This
can put the modem in a state where the ModemManager state does not match
the modem's actual state of being connected.
When deactivating the current active bearer, the timeout has been
changed from 10 seconds to 45 seconds. u-blox modems can take up to 40
seconds to respond to deactivation requests through the AT+CGACT
command according to the u-blox AT command reference.
|
|
Several plugins define the specific device vid:pid pairs they
support. Let's use this information as a direct indication that
ModemManager can probe the devices.
|
|
Instead of blindly allowing to be probed all ttyACM ports that report
them as AT-capable, we will now instead forbid all ttyACM ports that
don't report themselves as AT-capable.
Also, require the modem to expose other additional ports (of any kind
usable by ModemManager) in addition to the AT-capable ttyACM port.
This update should avoid automatically probing Arduino devices that
wrongly report their exposed single ttyACM port as AT-capable.
https://github.com/arduino/ArduinoCore-avr/pull/92
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/140
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/127
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930264
|
|
If the reopening operation fails when attempting to recover the
previous open count, it could mean the port is already gone. We didn't
get a HUP in the TTY because the channel I/O monitoring isn't in place
during this time, so this is the best way to detect that at this
point.
And if we do see an error, we'll flag the port as forced closed so
that we do not attempt to reopen it again.
ModemManager[4219]: <debug> [1568123246.421399] Disconnecting bearer '/org/freedesktop/ModemManager1/Bearer/0'
ModemManager[4219]: <info> [1568123246.421465] Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connected -> disconnecting)
ModemManager[4219]: <debug> [1568123246.421698] Reopening data port (modemu)...
ModemManager[4219]: <debug> [1568123246.421722] (modemu) reopening port (2)
ModemManager[4219]: <debug> [1568123246.421740] (modemu) device open count is 1 (close)
ModemManager[4219]: <debug> [1568123246.421754] (modemu) device open count is 0 (close)
ModemManager[4219]: <debug> [1568123246.421770] (modemu) closing serial port...
ModemManager[4219]: <debug> [1568123246.421786] (modemu): port now disconnected
ModemManager[4219]: <debug> [1568123246.421816] (modemu) serial port closed
ModemManager[4219]: <info> [1568123248.028573] (tty/modemu): released by device '/sys/devices/pci0000:00/0000:00:00.0'
ModemManager[4219]: <debug> [1568123248.028637] Removing empty device '/sys/devices/pci0000:00/0000:00:00.0'
ModemManager[4219]: <debug> [1568123248.028866] Removing from DBus bearer at '/org/freedesktop/ModemManager1/Bearer/0'
ModemManager[4219]: <debug> [1568123248.028914] [device /sys/devices/pci0000:00/0000:00:00.0] unexported modem from path '/org/freedesktop/ModemManager1/Modem/0'
ModemManager[4219]: <debug> [1568123248.028944] Periodic signal checks disabled
ModemManager[4219]: <debug> [1568123256.401738] Connection monitoring is unsupported by the device
ModemManager[4219]: <debug> [1568123256.422939] (modemu) opening serial port...
ModemManager[4219]: <warn> [1568123256.423062] (modemu) could not open serial device (2)
ModemManager[4219]: <debug> [1568123256.423104] Couldn't disconnect bearer '/org/freedesktop/ModemManager1/Bearer/0': Couldn't reopen port (0): Could not open serial device modemu: No such file or directory
ModemManager[4219]: _close_internal: assertion 'self->priv->open_count > 0' failed
Thread 1 "ModemManager" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff77894e6 in ?? () from /usr/lib/libglib-2.0.so.0
(gdb)
(gdb) bt
#0 0x00007ffff77894e6 in () at /usr/lib/libglib-2.0.so.0
#1 0x00007ffff7789738 in g_logv () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff777ff80 in g_log () at /usr/lib/libglib-2.0.so.0
#3 0x0000555555661115 in _close_internal (self=0x555555796380, force=0) at mm-port-serial.c:1378
#4 0x0000555555661865 in mm_port_serial_close (self=0x555555796380) at mm-port-serial.c:1503
#5 0x00005555556078cc in ports_context_unref (ctx=0x5555557c4ca0) at mm-broadband-modem.c:9801
#6 0x000055555560e33a in finalize (object=0x5555557a4250) at mm-broadband-modem.c:11940
#7 0x00007ffff787b351 in g_object_unref () at /usr/lib/libgobject-2.0.so.0
#8 0x00005555555b1c71 in detailed_disconnect_context_free (ctx=0x555555785000) at mm-broadband-bearer.c:1369
#9 0x00007ffff795d62a in () at /usr/lib/libgio-2.0.so.0
#10 0x00007ffff787b351 in g_object_unref () at /usr/lib/libgobject-2.0.so.0
#11 0x00005555555b2532 in data_reopen_3gpp_ready (data=0x555555796380, res=0x55555573a580, task=0x55555573a040) at mm-broadband-bearer.c:1605
#12 0x00007ffff795d584 in () at /usr/lib/libgio-2.0.so.0
#13 0x00007ffff7962a87 in () at /usr/lib/libgio-2.0.so.0
#14 0x0000555555661bc6 in reopen_do (self=0x555555796380) at mm-port-serial.c:1607
#15 0x00007ffff778e3c4 in () at /usr/lib/libglib-2.0.so.0
#16 0x00007ffff778ebb0 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#17 0x00007ffff7790b11 in () at /usr/lib/libglib-2.0.so.0
#18 0x00007ffff7791a63 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#19 0x000055555559afb0 in main (argc=3, argv=0x7fffffffea58) at main.c:181
|
|
We cannot complete the flash task cancellation right away because this
may be called from within _close_internal() during a forced port close
after the TTY has gone, which would mean the object is fully disposed
already after the flash cancellation has been requested.
By making the task cancellation complete in idle, we're sure that
there will be at least one reference valid (the one in the task)
during the port close operation.
ModemManager[25156]: <debug> [1568121341.696563] Modem (Generic) '/sys/devices/pci0000:00/0000:00:00.0' completely disposed
**
ERROR:mm-port-serial.c:2067:finalize: assertion failed: (self->priv->iochannel == NULL)
(gdb) bt
#0 0x00007ffff757c755 in raise () at /usr/lib/libc.so.6
#1 0x00007ffff7567851 in abort () at /usr/lib/libc.so.6
#2 0x00007ffff7741062 in () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff776d99d in g_assertion_message_expr () at /usr/lib/libglib-2.0.so.0
#4 0x0000555555662f0a in finalize (object=0x55555577a380) at mm-port-serial.c:2067
#5 0x0000555555664d81 in finalize (object=0x55555577a380) at mm-port-serial-at.c:632
#6 0x00007ffff787b351 in g_object_unref () at /usr/lib/libgobject-2.0.so.0
#7 0x00007ffff795d5eb in () at /usr/lib/libgio-2.0.so.0
#8 0x00007ffff787b351 in g_object_unref () at /usr/lib/libgobject-2.0.so.0
#9 0x0000555555662126 in mm_port_serial_flash_cancel (self=0x55555577a380) at mm-port-serial.c:1747
#10 0x0000555555661224 in _close_internal (self=0x55555577a380, force=1) at mm-port-serial.c:1397
#11 0x000055555566197b in port_serial_close_force (self=0x55555577a380) at mm-port-serial.c:1526
#12 0x000055555565fbe5 in common_input_available (self=0x55555577a380, condition=(G_IO_IN | G_IO_ERR | G_IO_HUP)) at mm-port-serial.c:971
#13 0x00005555556600c0 in iochannel_input_available (iochannel=0x55555578a0a0, condition=(G_IO_IN | G_IO_ERR | G_IO_HUP), data=0x55555577a380) at mm-port-serial.c:1073
#14 0x00007ffff778ebb0 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#15 0x00007ffff7790b11 in () at /usr/lib/libglib-2.0.so.0
#16 0x00007ffff7791a63 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#17 0x000055555559afb0 in main (argc=3, argv=0x7fffffffea58) at main.c:181
|
|
Includes port type hints for the TP-Link MA260.
P: Vendor=2357 ProdID=9000 Rev=00.00
S: Manufacturer=TP-LINK, Incorporated
S: Product=TP-LINK HSPA+ Modem
S: SerialNumber=863745010845895
C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x2 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
|
|
Includes port type hints for the D-Link DWM-222.
P: Vendor=2001 ProdID=7e35 Rev=02.28
S: Manufacturer=Mobile Connect
S: Product=Mobile Connect
S: SerialNumber=0123456789ABCDEF
C: #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I: If#=0x5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
|
|
|
|
|
|
For now, including a handy method from the ublox tests that allows
comparing arrays of bands that may not be sorted.
|
|
|
|
This reverts commit ef89dd154bdeda1c727190ea8b7c66766659f919.
The PID of the ME910 is 1101, not 1011... :D
|
|
Several plugins define specific udev tags that must be available in
the device in order for the plugins to use them. Let's use these tags
as a direct indication that ModemManager can probe the devices.
In particular, this change would make all Ericsson MBM modems probed
right away also in STRICT filter mode, without needing to check the
ttyACM interface type or the available net ports.
|
|
|
|
|
|
|
|
If the signal is automatically disconnected during object disposal, we
shouldn't explicitly try to disconnect it ourselves during finalize().
Reported by: Lubomir Rintel <lkundrak@v3.sk>
|
|
This tag is completely redundant because users can whitelist the
platform TTY ports to use with the more generic ID_MM_DEVICE_PROCESS
tag, which is part of the explicit whitelist filter rule.
|
|
The udev tag that allows flagging devices that MAY be modems
(e.g. USB<->RS232 adapters) is only applicable to TTY devices, so
explicitly specify that in the tag name as well.
|
|
Until now the ID_MM_DEVICE_IGNORE udev tag was being used in the
internal blacklist of devices shipped by ModemManager when running in
either DEFAULT or PARANOID filter modes. The name of the tag is
extremely misleading because it doesn't really make the full device be
ignored, the tag only applied to TTY ports.
This commit repurposes the tag so that it applies to ANY kind of
port (e.g. TTY, NET, cdc-wdm...) and also to any kind of filter type
(i.e. also applicable in STRICT mode).
The internal blacklist shipped by ModemManager, which should NOT be
used in STRICT mode, uses a new tag name, ID_MM_TTY_BLACKLIST.
The new ID_MM_DEVICE_IGNORE tag is therefore much more usable and its
name is really meaningful. If there are users or third-party projects
adding their own udev rules with the ID_MM_DEVICE_IGNORE tag name,
they should have no problem as the new rule is more restrictive than
the old one.
|
|
The 'modem' field in _MMBaseSimPrivate is already a MMBaseModem object.
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Maxim Anisimov <maxim.anisimov.ua@gmail.com>
|
|
As suggested by Paul Bartell <paul.bartell@gmail.com>
|
|
ussd_decode() expects a non-null GByteArray while process_ussd_message()
could potentially passes a null GByteArray to ussd_decode(). This
patch fixes the issue by having process_ussd_message() always creates a
GByteArray.
|
|
For devices which do not provide feature_extended_lte_band_preference
mm_modem_bands_to_qmi_band_preference() gets called from
mm_shared_qmi_set_current_bands() with extended_qmi_lte_bands
set to NULL which may cause a SIGSEGV in the memset() call in
mm_modem_bands_to_qmi_band_preference().
Avoid this by checking whether extended_qmi_lte_bands is non-NULL
before calling memset().
Reported-by: Nick <mips171@icloud.com>
|
|
Add the missing QMI LTE bands 26 to 32 to nas_lte_bands_map to make them
usable in ModemManager.
|
|
Add the missing QMI LTE bands 26 to 32 to dms_lte_bands_map to make them
usable in ModemManager.
|
|
Never automatically flag the bearer as disconnected if it's using PPP,
because we could end up using the TTY at the same time as pppd, with
the wrong CLOCAL settings.
So, whenever we detect that the bearer requires PPP, we will ignore
all disconnection reports generated by ModemManager itself.
|
|
mm_firmware_update_settings_get_variant() checks for a null `self'
pointer when accessing `self->priv->method', but doesn't perform the
null check when accessing other members of
MMFirmwareUpdateSettingsPrivate.
This patch fixes mm_firmware_update_settings_get_variant() to fully
handle a null `self' pointer.
|
|
|
|
g_free is in form of `void (*)(gpointer)`, which matches the
GDestroyNotify signature. An explicit GDestroyNotify cast on g_free is
thus not needed.
|
|
|
|
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
|
|
|
|
mm-shared-qmi.c:358:9: error: variable 'mcc' is used uninitialized whenever '&&' condition is false [-Werror,-Wsometimes-uninitialized]
if (operator_id && !mm_3gpp_parse_operator_id (operator_id, &mcc, &mnc, &error)) {
^~~~~~~~~~~
mm-shared-qmi.c:367:9: note: uninitialized use occurs here
if (mcc) {
^~~
mm-shared-qmi.c:358:9: note: remove the '&&' if its condition is always true
if (operator_id && !mm_3gpp_parse_operator_id (operator_id, &mcc, &mnc, &error)) {
^~~~~~~~~~~~~~
mm-shared-qmi.c:339:51: note: initialize the variable 'mcc' to silence this warning
guint16 mcc;
^
= 0
|
|
The modem may take the request to set modes and reply right away with
a success before actually changing the current modes in use.
Therefore, If we reload modes right after we receive the set response,
we may still see the old modes instead of the new ones. Try to avoid
this, by reloading current modes a couple of times after we have set
them if they are not yet the expected ones.
|
|
The modem may take the request to set bands and reply right away with
a success before actually changing the current bands in use.
Therefore, If we reload bands right after we receive the set response,
we may still see the old band mask instead of the new one. Try to
avoid this, by reloading current bands a couple of times after we have
set them if the band mask is not the expected one.
|
|
|
|
These new methods allow querying and updating the status of the call
waiting network service, as per 3GPP TS 22.083.
The status of the service is not a property because we don't want to
unconditionally load it on every boot, given that the process involves
talking to the network (i.e. it is not a device setting).
|
|
Do not wait until all parts are received in order to initialize all
fields that are common to all parts in the SMS message, do it as soon
as the first part is received.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/137
|
|
The tool monitors SMS message additions and SMS state updates, e.g.:
$ sudo ./test/mmsmsmonitor
[/org/freedesktop/ModemManager1/SMS/0] sms found: received
[/org/freedesktop/ModemManager1/SMS/1] sms found: received
[/org/freedesktop/ModemManager1/SMS/2] sms found: received
[/org/freedesktop/ModemManager1/SMS/3] sms found: received
[/org/freedesktop/ModemManager1/SMS/4] sms found: received
[/org/freedesktop/ModemManager1/SMS/5] sms found: received
[/org/freedesktop/ModemManager1/SMS/6] sms found: received
[/org/freedesktop/ModemManager1/SMS/7] new sms: receiving
[/org/freedesktop/ModemManager1/SMS/7] sms updated: received
|
|
|
|
We were not logging anywhere the "concat max" field for example.
|
|
The QMI NAS Initiate Network Register command will return a successful
response when the request to register is received and accepted by the
module, but this does not mean the requested registration has been
completed yet.
This issue was making e.g. manual registration attempts to a forbidden
network report success right away, even if the actual registration
would end up failing.
In order to avoid that, the QMI based network registration relies on
receiving QMI NAS Serving System indications after QMI NAS Initiate
Network Register replies. As soon as we get a non-searching
registration state in the indication, we'll report the operation as
successful.
Note that the 3GPP interface logic is anyway in charge of checking
if the specific request was successful or not, no need to do that
explicitly in the QMI implementation.
|
|
If there is one registration state which is denied and the remaining
ones are either unknown or idle, then report denied.
|
