The quick AT probe procedure is only meaningful to avoid waiting the
+READY URC delay. If there is no such delay configured, we shouldn't
run the quick AT probe (as a failure in the AT probe may also
trigger a +READY URC delay).
Just read the udev tag value early and complete the task if the delay
is not configured.
Added reading the ID_MM_UBLOX_PORT_READY_DELAY udev flag value and using
it as an init delay when a value is set.
The 20 second delay for the TOBY-L4 +READ URC has been reimplemented
using the new ID_MM_UBLOX_PORT_READY_DELAY udev value.
For the TOBY-R2, LISA-R2, and LARA-R2, the only valid AT ports are
ttyACM0, ttyACM1, and ttyACM2. All other ttyACM ports cause MM to
wait 20-30 seconds probing the port on startup.
Ignoring the non-AT ttyACM ports allows MM to not wait 20-30 seconds
probing and therefore startup much faster with these modems.
The PDP contexts that are found with an empty APN configured are right
now used as placeholders that can be overwritten with the user
provided APN if no direct match is found.
We want to keep that logic in place, but for the case where we do get
an empty APN requested by the user, we need to perform the full
context match, so that the first PDP context matching the empty APN is
used.
Right now we're overwriting with the empty APN again the last PDP
context found with an empty APN, which doesn't make much sense:
Apr 27 08:15:21 ModemManager[4251]: <debug> Found '3' PDP contexts
Apr 27 08:15:21 ModemManager[4251]: <debug> PDP context [cid=1] [type='ipv4'] [apn='']
Apr 27 08:15:21 ModemManager[4251]: <debug> PDP context [cid=2] [type='ipv4'] [apn='broadband']
Apr 27 08:15:21 ModemManager[4251]: <debug> PDP context [cid=15] [type='ipv4'] [apn='']
Apr 27 08:15:21 ModemManager[4251]: <debug> Found PDP context with CID 1 and no APN
Apr 27 08:15:21 ModemManager[4251]: <debug> Found PDP context with CID 15 and no APN
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3) device open count is 3 (open)
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3) device open count is 2 (close)
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3): --> 'AT+CGDCONT=15,"IP",""<CR>'
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3): <-- '<CR><LF>OK<CR><LF>'
If the serial port timeout detection logic is enabled, warn whenever
more than one consecutive command timeout happens, not just when the
limit is reached.
Commit 708b00ae3 "modem: allow periodic signal check to be disabled"
added a "iface-modem-periodic-signal-check-disabled" property in
MMIfaceModem/MMBroadbandModem to indicate if the periodic signal check
should be disabled. If the property is set to TRUE, the
signal_quality_polling_supported field of SignalCheckContext is set to
FALSE, which is sticky across modem disable/enable operations. However,
that is undesirable as we would like to issue an initial signal check to
refresh the signal quality value after the modem is re-enabled from a
state when the RF may have been previously turned off.
ModemManager currently relies on unsolicited MBIM_CID_SIGNAL_STATE
notifications to obtain signal quality updates, and it doesn't query the
initial signal quality. It's been observed that some MBIM modems issue a
MBIM_CID_SIGNAL_STATE notification only when there is a notable change
in RSSI. The signal quality may remain at 0 for quite some time. It's
more noticeable when simply restarting ModemManager after the modem has
been initialized and enabled once.
We could simply enable periodic signal check on an MBIM modem, but
that's less ideal as it may unnecessarily wake the modem up from USB
selective suspend (unless we use a much longer polling period).
To address the issue, this patch adds the implementation of
load_signal_quality to MMBroadbandModemMbim so that the signal quality
is initially polled via a solicited MBIM_CID_SIGNAL_STATE query. To
avoid the periodic signal check, we set the
MM_IFACE_MODEM_PERIODIC_SIGNAL_CHECK_DISABLED property to TRUE for
MMBroadbandModemMbim.
ModemManager decides to disable periodic signal check if either
load_signal_quality is not implemented or load_signal_quality returns an
unsupported error. However, in some cases, we want to use
load_signal_quality to query the initial signal quality but rely on
unsolicited signal quality updates from the modem afterwards without
periodically polling for signal quality. To support that, this patch
introduces a property in MMIfaceModem/MMBroadbandModem to indicate if
the periodic signal check should be disabled.
Keeps build with GCC 8 happy.
mm-base-call.c:758:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
mm-base-call.c:822:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
mm-base-sms.c:908:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
mm-sms-list.c:331:25: warning: variable 'ctx' set but not used [-Wunused-but-set-variable]
mm-iface-modem-messaging.c:1210:21: warning: variable 'storage_ctx' set but not used [-Wunused-but-set-variable]
huawei/mm-plugin-huawei.c:183:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
ublox/mm-plugin-ublox.c:161:24: warning: variable 'response' set but not used [-Wunused-but-set-variable]
ublox/mm-plugin-ublox.c:159:24: warning: variable 'ctx' set but not used [-Wunused-but-set-variable]
icera/mm-modem-helpers-icera.c:218:25: warning: variable 'first_free' set but not used [-Wunused-but-set-variable]
novatel/mm-common-novatel.c:50:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
It's annoying for distributors to build with -Werror, since it means
that compiler upgrades can break the build. Let's let them disable it,
but keep it enabled by default.
The 'any' mode refers to the mode which includes most access
technologies and where none of them is preferred.
Fix the logic so that all combinations with one technology preferred
over the others are ignored, instead of the other way around.
Fixes assertion with the 4G-only LARA R204.
ModemManager[424]: <debug> [-192499452.090358] (ttyACM0): --> 'AT+URAT=?<CR>'
ModemManager[424]: <debug> [-192499452.092150] (ttyACM0): <-- '<CR><LF>+URAT: (3)<CR><LF><CR><LF>OK<CR><LF>'
**
ERROR:ublox/mm-modem-helpers-ublox.c:817:mm_ublox_get_modem_mode_any: assertion failed: (any != MM_MODEM_MODE_NONE)
Reported-by: Matthew Starr <mstarr@hedonline.com>
We used ttyACM0 as secondary port until now, just because we had an
extra AT capable TTY around in addition to the main control ttyACM2
port.
Turns out, using this ttyACM0 may actually break the connection setup
in the wwan interface in a bad way (e.g. not allowing DHCP setup).
The suggestion from u-blox and Intel is to fully ignore ttyACM0; and
given that we no longer need any primary/secondary port logic, we just
remove all the associated udev tags.
Releasing the port on the device looks benign but because it emits
a signal, it could call device_context_port_released and unref the
MMDevice in port_context_unref. This means the MMDevice might be
disposed before we get to the g_object_ref and the subsequent call
to g_hash_table_remove will try to hash a null string, which makes
MM crash.
The hashtable is keyed on the UID of the MMDevice, and its hash
function is g_str_hash. We shouldn't be passing a GObject into
g_hash_table_remove because calling g_str_hash on an MMDevice is
wrong.
MM was not updating the EPS registration status for qmi modems. This
led to LTE-only modems never having 'registered' status. This was
happening for Quectel EC21-V modem.
In mm_iface_modem_3gpp_register_in_network() when deciding whether to
force automatic registration or not, check whether the modem is already
registered in a network. Just checking whether we have a valid operator
code is not sufficient, as some modems (ublox Toby R2xx) don't always
return an operator name/code even when registered.
We should not cache the AT command response otherwise we will never
re-run the same command again. The cache is needed only for AT test
commands (e.g. AT+CESQ=?).
We don't want them to get in the way of our initialization phase:
/org/freedesktop/ModemManager1/Modem/0 (device id 'c49ed59c4a411e923307330d3e1d82582cbfac37')
-------------------------
Hardware | manufacturer: 'u-blox'
| model: 'unknown'
| revision: 'TOBY-L4906
| +PBREADY
| 40.19_ENG0003'
| H/W revision: 'unknown'
| supported: 'gsm-umts, lte'
| current: 'gsm-umts, lte'
We should only depend on GLib on the libmm-glib headers. Otherwise,
packages using just the core headers (e.g. ModemManagerQt) would also
need to build-depend on GLib and we don't want to enforce that.
cd ~/buildroot/output/build/kde-modemmanager-qt-v5.36.0/src && ~/buildroot/output/host/usr/bin/arm-cortexa9_neon-linux-gnueabihf-g++ .... -fPIC -o CMakeFiles/KF5ModemManagerQt_static.dir/bearer.cpp.o -c ~/buildroot/output/build/kde-modemmanager-qt-v5.36.0/src/bearer.cpp
In file included from ~/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/include/ModemManager/ModemManager.h:41:0,
from ~/buildroot/output/build/kde-modemmanager-qt-v5.36.0/src/generictypes.h:27,
from ~/buildroot/output/build/kde-modemmanager-qt-v5.36.0/src/generictypes.cpp:23:
~/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/include/ModemManager/ModemManager-compat.h:23:18: fatal error: glib.h: No such file or directory
compilation terminated.
It may be undesirable to issue a MBIM_CID_CONNECT
(MBIMActivationCommandDeactivate) command to deactivate an IP session
when the session isn't activated. For instance, it's been observed on
Huawei ME936 that it takes more than 30s for the modem to deactivate a
not-yet-activated session. This patch modifies MMBearerMbim to query if
a session is activated before trying to deactivate the session during a
connection attempt.
Since commit 0c7f3380a ("bearer-mbim: ensure session is disconnected
before trying to connect"), MMBearerMbim always issues a
MBIM_CID_CONNECT (MBIMActivationCommandDeactivate) command before a
MBIM_CID_CONNECT (MBIMActivationCommandActivate) command during a
connection attempt. That is to ensure that an IP session is actually
deactivated before we try to activate a new IP session.
Unfortunately, it's been observed on Huawei ME936 that it takes more
than 30s for the modem to respond to a MBIM_CID_CONNECT
(MBIMActivationCommandDeactivate) command when trying to deactivate a
session that hasn't been activated.
When the signal is weak, it's also possible that a modem takes more than
30s to deactivate an IP session during a disconnection attempt.
This patch increases the timeout for deactivating an IP session from 30s
to 60s in both connection and disconnection attempt.
On Huawei ME936, the hex numbers in the response to AT^DHCP contain the 0x prefix, e.g.
AT^DHCP?
^DHCP: 0xda7d0e0a,0xff000000,0xdb7d0e0a,0xdb7d0e0a,0x01261aac,0x00000000,100000000,50000000
This patch updates mm_huawei_parse_dhcp_response() to handle the
optional 0x prefix.
The +CEMODE command is defined in 3GPP TS 27.007 (e.g. in section
10.1.28 in v11.0.0). This command allows querying or updating the
current UE mode, as well as checking the supported modes.
We implement support for loading the current mode and updating it. It
is assumed that the device does any additional operation needed by the
setting update, e.g. un-registering from CS when selecting an EPS-only
mode.
The UE modes of operation for LTE are defined in 3GPP TS 24.301 (e.g.
section 4.3 in v10.3.0):
* PS mode 1: EPS only, 'voice centric'
* PS mode 2: EPS only, 'data centric'
* CS/PS mode 1: EPS and non-EPS, 'voice centric'
* CS/PS mode 2: EPS and non-EPS, 'data centric'
The mode specifies, among other things, how the UE should behave w.r.t
CS fallback depending on the capabilities reported by the network.
When a modem is being enabled, an initial registration check is
scheduled to determine the current registration state and access
technology. The initial registration check is performed asynchronously
and may not complete before the modem state is transitioned to
'enabled'. When the modem is disabled shortly afterwards, the
registration state is transitioned to 'unknown' and the modem state is
transitioned to 'disabled'. But the completion of the initial
registration check after that can transition the registration state and
modem state to a wrong state. This patch addresses the issue by ignoring
a registration state update if the modem isn't already enabled or being
enabled.
The generic broadband modem provides a common method to load unlock
retries based on CSIM queries. We modify the Telit plugin to use the
generic method but keeping the CSIM locking/unlocking logic in place.
The AT control TTYs in the u-blox modems may take some time to be
usable. In order to handle this issue, we configured some longer
timeouts during AT probing, but that may not be always enough.
The u-blox TTYs will report readiness via a "+AT: READY" URC, which
we can use during custom initialization to decide right away that the
port is AT. We use up to 20s as that is close to the worst case seen
during experimentation, happening after the module undergoes a full
NVM reset. If the timeout is reached without receiving the URC, we
still run standard AT probing afterwards. This new logic just tries
to make it sure we don't do any probing before the module is ready to
accept it.
If the module hasn't been hotplugged (i.e. it was already there when
ModemManager started) we do a quick first AT probing and if that fails
we run the "+AT: READY" URC wait as if it was hotplugged.
