On my modem, AT!ICCID? command gives response without a preceding `!`:
```
AT!ICCID?
ICCID: 8970162010103256136
OK
```
Signed-off-by: Semyon Maryasin <simeon@maryasin.name>
Use g_steal_pointer() when passing g_autoptr(GError) to
g_task_return_error() to prevent double-free by the automatic cleanup.
GTask takes ownership of the passed GError. If we use g_autoptr(GError)
locally, it will also call g_error_free() when the function returns,
causing a double-free / heap corruption. Stealing the pointer clears the
local variable and prevents the automatic cleanup.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/work_items/1073
Signed-off-by: Aleksander Morgado <aleksandermj@google.com>
Defer the validity change (which triggers modem reprobe/removal) to an
idle callback in rdy_handler().
Calling mm_base_modem_set_valid(FALSE) synchronously from the URC
handler triggers the immediate destruction of the modem object while the
serial port is still iterating the unsolicited message handlers. Deferring
the operation to an idle callback and taking a reference to the modem
ensures the modem object is kept alive until parse_unsolicited() has
returned.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/work_items/1072
Signed-off-by: Aleksander Morgado <aleksandermj@google.com>
ME910G1 supports decimal format for 4G bands and has also an empty
tdscdma slot between 4G and 4G extended bands commands/responses.
Change shared code and helpers to deal with these differences.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
The assumption that if a modem supports a given access tech, the band
settings for that specific tech should be always given is wrong for
4g, since the 4g bands can be disabled setting the value to 0 in
multi-tech modems like ME310M1.
For example, a 3g + 4g modem could have a setting in which all
the 4g bands are unset and only 3g bands are there: this scenario is
not supported by the current code, but it's legitimate.
Remove this limitation and adapt the code to support bands setting
for multi-tech modems.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Fix LN920 current bands test configuration by setting
modem_has_hex_format_4g_bands to TRUE.
The current wrong setting does not cause the test failure since the modem
supports also extended settings and function telit_get_ext_4g_mm_bands
considers both standard and extended bands as hex without checking
the flag, since decimal format for extended bands is not supported.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
The original code for xmm7360_byte_array_read_asn_int() returned
signed integers both from the function and from the returned
Xmm7360RpcMsgArg, but didn't handle sign extension on the
value returned from the function. That would lead to different
values between the function return and the Xmm7360RpcMsgArg
value, which seems wrong.
Make those two correspond and add checks in various places that
shouldn't ever see negative ints.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
That way UNKNOWN is the zero'd value instead of BYTE; it's easier
to test for and less error-prone if not explicitly set to the right
value.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
xmm7360_byte_array_read_asn_int() would keep bit-shifting a gint into
oblivion if the int's size was > 32-bit. It also didn't handle size 0
ints at all, and while size 24 ints would get stuffed into a 32-bit
variable those probably aren't a thing and if they actually are they
should get specifically handled.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
So we can unit-test all the parsing and building code more easily
without having to link to a bunch of serial port stuff.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
If the error matches, then a `+CIMI` command is sent to the device and
processing continues. However, the current error (for the `+CPIN?` command)
is not freed or propagated, fix that.
Fixes: 5c1fcbfe4a ("mtk-legacy: read IMSI if CPIN response is an error")
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
The MTK specific modem object should be included in the 'mtk' shared
utils, so that they're available to other plugins.
Signed-off-by: Aleksander Morgado <aleksandermj@google.com>
The port type hints for the RW101-cat6 and RW101-cat12 have been
updated, with USB interface #2 now designated as both the AT primary
port and fastboot port.
Signed-off-by: Wenbin <ywbjob@163.com>
UML290 with firmware L0290VWBB12F.248 doesn't support QMI network
time and crashes when asked for AT network time too quickly after
being plugged in.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
The device would eventually be automatically probed. Add hints anyway,
as not to waste time with the generic probe.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
MV31 MBIM modem firmware revisions are not matched with carrier configs.
Different VoLTE profiles might be selected by the user causing
the carrier config revision to change.
Since fwupd uses this string for firmware updates, it gets confused and
thinks the user has an update available.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Reading the hardware revision via the mbim interface returns an incorrect
hardware revision string. The output is always set to
'h/w revision: Thales Snapdragon X55'
Hardware | manufacturer: Cinterion
...
| h/w revision: Thales Snapdragon X55
This is an incorrect value returned by the MBIM interface. The MV31 and MV32
does have a dedicated AT Command to get the correct hardware revision
via 'AT+SKUID'. If the hardware revision is read via the AT command, the
output looks as follows.
Hardware | manufacturer: Cinterion
...
| h/w revision: V065
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Reading the revsion via the mbim interface returns an incorrect firmware
revsion string. This contains a '\n' character so that the revision looks
like this in 'mmcli'.
Hardware | manufacturer: Cinterion
| model: Cinterion PID 0x00F1 USB Mobile Broadband
| firmware revision: FDE.F0.3.0.1.1.DT.005
| 062
| carrier config: DT
The correct string without '\n' is returned via the AT interface. To fix
the error, the 'mbim' revision interface is overwritten with an AT call
if a MV31 or a MV32 is detected. So we get the correct output via 'mmcli'.
Hardware | manufacturer: Cinterion
| model: Cinterion PID 0x00F1 USB Mobile Broadband
| firmware revision: FDE.F0.3.0.1.1.DT.005.062
| carrier config: DT
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Some modems (at least ELS62-E) doesn't support TDD LTE bands and their SCFG
responses doesn't contain LTE-TDD bands.
Signed-off-by: Kirill Buksha <kirbuk200@gmail.com>
Treat the following URCs as indications of possible SIM hot swap
events:
+SIM: Inserted
+SIM: Removed
+SIM DROP
Any time any of these is received, a SIM hot swap event is reported,
and the logic can then determine what to do. These should lead to
doing nothing if they happen as part of a controlled SIM slot switch.
Signed-off-by: Aleksander Morgado <aleksandermj@google.com>
It seems that the very first XMM7360 RPC init command often times out after
resuming the laptop from s2idle for unknown reasons.
This makes the modem unusable in such situation until the next sleep/resume
cycle.
Re-trying this RPC command allows the modem to initialize normally.
It's possible that this is a kernel iosm driver or modem firmware issue
but considering that the kernel driver seems orphaned by Intel and one
can't really expect much firmware support for this modem either let's do
the easiest thing and simply allow retrying (once) the very first RPC init
command if it fails or times out.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
With the recent addition of serial port scheduler it often happens that
NMEA traces are mistaken for command responses at init time if GPS was left
enabled in the modem.
For this reason, the proper NMEA packet parser needs to be enabled early
at modem init before the code ensures that GPS is stopped (if it is not
supposed to be running of course).
Since this modem disables GPS asynchronously with processing of the
+XLSRSTOP AT command the full GPS stop machinery has be used to reliably
achieve that GPS engine stop.
It's also important to flush the existing serial port data after attaching
the NMEA packet parser but before issuing that stop AT command, otherwise
command processor for the stop command can also be confused by the existing
queued data.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
XMM7360 modem NMEA trace packets are wrapped to look like AT command
responses (with "<CR><LF><CR><LF>OK<CR><LF>" at the end).
This wrapping causes problems if a genuine AT command was just sent and
ModemManager is expecting a similarly formatted response to it.
In such case the NMEA trace packet is taken as the response to the AT
command, which usually causes the command to fail due to response parsing
failure.
Fix this by implementing a custom NMEA trace packets parser for these
modems.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
With serial port interlocking just queuing serial port data does not mean
it will be immediately sent - the other serial port could be still busy.
For debugging serial port issues it is often necessary to see the exact
moment the data was sent or received.
Implement debug_log method for MMPortSerialXmmrpcXmm7360 and log raw serial
port data there (just as MMPortSerialAt does) instead of doing this in the
command queuing function.
The debug_log method is called by MMPortSerial base when the data is about
to be actually sent to the serial port.
Additionally, log command response body where it is actually returned to
higher layers rather than in the unsolicited response handler.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
We need to keep GPS port open if would not be kept open otherwise (like
it is the case with a locked/non-enabled modem).
Otherwise:
* While GPS can be enabled in that modem state the traces don't reach MM
API consumers since nothing is servicing the serial port.
* Once modem actually gets enabled the queued GPS output in the modem
serial port floods the main port and often confuses the init sequence.
We also have to make sure that we don't stop GPS during the init sequence
if it is supposed to be running, otherwise there will be the same
issue as commit d3a2aebf16 ("mbm: don't stop GPS interface on
reinitialization if it should be running") fixed for mbm.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Seems to work just fine once the port interlocking is being done
and some other fixes are made in the next commit.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Семён Марьясин
Nikolay Savchenko
Aleksander Morgado
Daniele Palmas
Lukas Voegl
Dan Williams
Barnabás Pőcze
Wenbin
xuhongxing
Lorenzo Medici
Vanillan Wang
Lubomir Rintel
Florian Eckert
Kirill Buksha
Maciej S. Szmigiero