Consistently interpret the modem's reported custom data class when
loading current mode, supported mode, supported capabilities,
setting current mode, and current access technology.
Normalize the data class to include any custom data class immediately
after reading it from any MBIM message. De-normalize it when sending
back to the modem when setting current modes so the modem receives
MBIM_DATA_CLASS_CUSTOM for the custom mode.
Fixes: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/937
Signed-off-by: Dan Williams <dan@ioncontrol.co>
This enables the usage with busybox and strict environments.
This is related to #483 and the previous commit 91ed72aa, 02baf283.
Signed-off-by: Jongmin Kim <jmkim@debian.org>
`CSCB` has the form
```
CSCB: [0|1],"<channel-list>","<data-coding-scheme>"
```
If the first parameter is `0` this specifies the accepted types if `1`
it specifies rejected.
So far seen in the wild were CSCB strings with accepted types only and a
coding scheme of "" so this is what we handle for the moment.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
For modems that need more time to respond to AT port probes (like some Telit devices,
and Cinterion-based Telit MV31/MV32) allow a custom number of AT probe tries on a
per-port basis for generic probing, or plugins that opt into this functionality.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
If the old IMSI was unavailable because the SIM was locked, but now
is available because the SIM was unlocked, don't treat the SIM
properties change as a hotswap that may trigger dropping and re-probing
the modem.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
The libmm-glib library, as well as the ModemManager headers installed
as part of the D-Bus service API, have always been LGPLv2+ licensed,
because we want users of the service to rely on them in their own
programs, even if they are proprietary.
Some files had an incorrect GPLv2+ header instead of the LGPLv2+ and
that was confusing. All public headers in the MM API have the correct
license text now.
Signed-off-by: Aleksander Morgado <aleksandermj@chromium.org>
If multiple plugins are selected for probing a modem with AT probes,
earlier plugins may only request some probes but not all. When
those probes complete successfully, subsequent plugins won't re-do
the probes that were already completed, but jump to ones that
haven't yet been done.
For example, plugin A may request only AT probes but plugin B
may request AT, AT_PRODUCT, and AT_VENDOR. Plugin B will start
with AT_PRODUCT probes because plugin A already completed the AT
probe.
The code in probe_step() only opened the serial port for the
AT probe, I guess assuming that all AT-type probes would be
done in sequence. But in the above scenario they are not.
Instead, make sure the port is opened for all AT style probes
that have not yet been executed.
Fixes: 7937a89a37 port-probe: rework and consolidate port probe flow for AT/QCDM/QMI/MBIM
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Add some mmcli D-Bus timeout slack, making them slightly higher than the
ModemManager internal timeout, to ensure the cli doesn't time out the
D-Bus call when MM succeeds.
For 3GPP scan, some modems appear to have internal 5 minute timeouts,
so ensure MM doesn't time out right before the modem returns results:
ModemManager[282578]: <dbg> [1741054422.321400] [ttyUSB2/at] --> 'AT+COPS=?<CR>'
ModemManager[282578]: <wrn> [1741054722.247806] [modem1] failed scanning networks: Serial command timed out
ModemManager[282578]: <dbg> [1741054724.119770] [ttyUSB2/at] <-- '<CR><LF>+COPS: (1,"T-Mobile","T-Mobile","310260",0),,(0,1,2,3,4),(0,1,2)<CR><LF><CR><LF>OK<CR><LF>'
Signed-off-by: Dan Williams <dan@ioncontrol.co>
For a ModemManager simple connect using mmcli, added the bearer
path on which call is connected. This helps in determining the
bearer path to directly retrieve bearer information easily
of this particular call.
Signed-off-by: Anagh G <quic_anaghg@quicinc.com>
Dan Williams
Guido Günther
Jongmin Kim
Aleksander Morgado
Anagh G