The DW5821E module is managed in MBIM mode by default, and exposes a
NMEA capable tty in USB interface #4.
Enabling/disabling the NMEA output via the TTY is done with AT
commands, so this implementation requires also a valid AT port in the
system.
Given that the AT commands used to enable/disable this feature are
based on modifying non-volatile memory through AT^NV, this
implementation is very specific to the DW5821E. If we're able to do
the same on other Dell modules in the future, we'll just rename the
new object to a more generic one.
This patch fixes the following compiler warning:
xmm/mm-modem-helpers-xmm.c:388:38: error: implicitly declaring library function 'strlen' with type 'unsigned long (const char *)' [-Werror,-Wimplicit-function-declaration]
g_regex_match_full (r, response, strlen (response), 0, 0, &match_info, &inner_error);
^
Implement a new interface to keep the code shared between the QMI and
non-QMI modem implementations.
While doing that, also fix the parent interface pointer handling, so
that it isn't a static pointer applicable to all modems, and make it a
per-modem specific pointer. Without this fix, ModemManager would crash
if e.g. running with both a QMI and non-QMI Cinterion modem at the
same time.
The new shared Cinterion logic will be in charge of managing all GPS
sources not already managed by the parent interface. E.g. if the
parent implementation already supports QMI-based GPS location (using
the LOC service for example) prefer that to the custom AT-based
logic.
We keep the pflags input in mm_base_modem_grab_port() so that plugins
can use other methods to gather port type hints (e.g. querying with AT
commands as in Huawei/Telit or looking at sysfs properties as in HSO).
For standard udev tag port type hints, it will be the base modem
looking them up.
Note that there is no longer any need to ignore non-flagged ports for
those modems that require primary/secondary flags. They will be
implicitly ignored when mm_base_modem_organize_ports() decides which
ports to use, as the flagged ones are preferred over the non-flagged
ones.
We define 3 common udev tag ids to be used by all plugins:
* ID_MM_PORT_TYPE_AT_PRIMARY: the primary modem port. It will be used
for AT control and also as PPP if there is no other port flagged
explicitly to do PPP.
* ID_MM_PORT_TYPE_AT_SECONDARY: the secondary modem port. It will be
used when/if the primary port gets connected to do PPP.
* ID_MM_PORT_TYPE_PPP: the port to be used to do PPP only. This tag
makes sense only when the primary port shouldn't be used for PPP,
i.e. when there is a port dedicated to do PPP and one port
dedicated for control.
When we detect that the modem is QMI-capable or MBIM-capable, we still
want to be able to use TTYs, for features unsupported by the main
protocols.
So, don't flag all the TTYs as non-AT non-QCDM, let them probe as
usual instead.
The sort_band() method used in the tester was totally wrong, it was
comparing the addresses of the variables instead of the MMModemBand
values.
Use the common mm_common_bands_garray_sort() instead, which works as
expected.
The default AT^SCFG="Radio/Band" value for Cinterion PLS8-J devices is
"16819472". Add UMTS band 19 and LTE band 19 entries based on the
information given in the PLS8 datasheet.
This info comes from PLS8-X/E/J/V/US, HC25 & PHS8 references, the
last two can be found publicly via Google search.
Swapped bit-mask locations for G850 & PCS bands as they may have
changed with FW or where accidently put in the wrong place.
Updated many 3G & 4G bit-mask fields.
The TOBY-L2 allowed to skup the user/pass string fields when no
authentication was requested, but according to the AT command
reference, all the remaining u-blox modules do require these two
fields given always (e.g. just as empty strings).
As per this sequence in a TOBY-L4:
(ttyACM2): --> 'AT+UAUTHREQ=?<CR>'
(ttyACM2): <-- '<CR><LF>+UAUTHREQ: (1-4),(0-2),,<CR><LF><CR><LF>OK<CR><LF>'
(ttyACM2): --> 'AT+UAUTHREQ=1,0<CR>'
(ttyACM2): <-- '<CR><LF>+CME ERROR: 4<CR><LF>'
It should have been: AT+UAUTHREQ=1,0,"",""
When a new USB device is hotplugged, e.g. a USB<->RS232 converter that
exposes a single ttyUSB0, these udev events happen:
add /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb/usb-device)
add /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb/usb-interface)
add /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0 (usb-serial)
add /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0/tty/ttyUSB0 (tty)
bind /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0 (usb-serial)
bind /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb/usb-interface)
bind /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb/usb-device)
Our udev rules in MM only added tags in the 'add' events, and it looks
like the only ones 'persistent' after this sequence are those of the
last event happening on the specific path.
This meant that all TTY subsystem rules (e.g. ID_MM_CANDIDATE) would
be stored for later check (e.g. if ModemManager is started after these
rules have been applied), which was ok. "udevadm info -p ..." would
show these tags correctly always.
But this also meant that the 'bind' udev event happening for the USB
device didn't get any of our device-specific tags, and so we would be
missing them (e.g. ID_MM_DEVICE_MANUAL_SCAN_ONLY) if MM is started
after the last event has happened. "udevadm info -p ..." would
not show these tags.
Modify all our rules to also run at the 'bind' events.
See, for context:
https://github.com/systemd/systemd/issues/8221
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.
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]
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.
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'
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 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.
When in low-power mode, some modems will not dispatch unsolicited
notifications, such as for SIM hot swapping. There is code in
MMBroadbandModemTelit to handle this by checking the SIM identifier
during modem power up against the identifier cached in the SIM
D-Bus object. If they're different, the SIM has likely been
swapped while we were powered down.
We can move this code out to MMBroadbandModem because it doesn't
actually rely on any Telit-specific details, and invoke it from
MMIfaceModem via a new method.
