Recent Linux kernel versions have introduced a generic WWAN subsystem
that provides various char devices for QMI, AT etc, similar to the
subsystem-specific char devices for USB or RPMSG.
The RPMSG char device for Qualcomm SoCs (e.g. MSM8916/MSM8974)
are particularly complicated to work with because they need to be
explicitly created from userspace with rpmsgexport and don't show up
automatically.
However, it turns out it's fairly simple to wrap the RPMSG subsystem
in a simple driver for the WWAN subsystem. This has several advantages:
- We can drop support for the special RPMSG char devices entirely
at some point.
- The WWAN char devices show up automatically, without having to export
them explicitly, making ModemManager work out of the box on these devices.
For now, just support using the WWAN subsystem alternatively for the
qcom-soc plugin. Later we can consider dropping the old RPMSG code.
See log from a SARA-R410M-02B-01 before the change:
Feb 01 05:40:01 unit ModemManager[304]: <debug> [1612158001.012330] [modem0/ttymxc4/at] --> 'AT+UBANDSEL?<CR>'
Feb 01 05:40:01 unit ModemManager[304]: <debug> [1612158001.026831] [modem0/ttymxc4/at] <-- '<CR><LF>ERROR<CR><LF>'
Feb 01 05:40:01 unit ModemManager[304]: <debug> [1612158001.027113] [modem0/ttymxc4/at] operation failure: 100 (Unknown error)
Feb 01 05:40:01 unit ModemManager[304]: <warn> [1612158001.027298] [modem0] couldn't load current bands: Unknown error
Backed by SARA-R4 series AT commands manual, no reference to +UBANDSEL
in the manual at all.
Log after the change:
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500845] [modem0] (u-blox) support configuration found for 'SARA-R410M-02B'
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500961] [modem0] (u-blox) band update requires explicit unregistration
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.501052] [modem0] (u-blox) UACT based band configuration unsupported
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.501141] [modem0] (u-blox) UBANDSEL based band configuration unsupported
Fixes: 437fb830c8 ("ublox,helpers: assume all SARA/LARA devices require COPS")
Signed-off-by: Alexander Dahl <ada@thorsis.com>
The SARA-R410M-02B-01 only supports values 7 and 8, log excerpt:
Feb 01 05:40:00 unit ModemManager[304]: <debug> [1612158000.826046] [modem0/ttymxc4/at] --> 'AT+URAT=?<CR>'
Feb 01 05:40:00 unit ModemManager[304]: <debug> [1612158000.833596] [modem0/ttymxc4/at] <-- '<CR><LF>+URAT: (7-8),(7-8)(7-8)<CR><LF><CR><LF>OK<CR><LF>'
Feb 01 05:40:00 unit ModemManager[304]: <warn> [1612158000.833992] [modem0] (u-blox) unexpected AcT value: 7
Feb 01 05:40:00 unit ModemManager[304]: <warn> [1612158000.834096] [modem0] (u-blox) unexpected AcT value: 8
Feb 01 05:40:00 unit ModemManager[304]: <warn> [1612158000.834193] [modem0] couldn't load supported modes: No combinations built from +URAT=? response
The SARA-R4 series AT commands manual (and also the SARA-R5 AT commands
manual) lists them like this:
- 7: LTE Cat M1
- 8: LTE Cat NB1
After the change, log looks like this:
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.490627] [modem0/ttymxc4/at] --> 'AT+URAT?<CR>'
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.499994] [modem0/ttymxc4/at] <-- '<CR><LF>+URAT: 7,8<CR><LF><CR><LF>OK<CR><LF>'
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500433] [modem0] (u-blox) current allowed modes retrieved: 4g
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500561] [modem0] (u-blox) current preferred modes retrieved: 4g
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Some of the AT-based connection methods don't have any way to query
connection status, or we don't have a proper implementation for those
yet. Ignore the reload operation in all those.
The load_() method is used for connection monitoring; while the
reload_() method is used to sync connection status after a
suspend/resume operation. The same method can be used for both things
in the Cinterion plugin.
The load_() method is used for connection monitoring; while the
reload_() method is used to sync connection status after a
suspend/resume operation. The same method can be used for both things
in the Sierra plugin.
The load_() method is used for connection monitoring; while the
reload_() method is used to sync connection status after a
suspend/resume operation. The same method can be used for both things
in the Novatel LTE plugin.
By default, fallback to "unknown" mobile equipment error when the
modem gets disconnected by the network and we don't have any way to
know a more detailed reason.
Update the list of mobile equipment error codes according to v17.1.0
of 3GPP TS 27.007 (March 2021).
A lot of the enum values that were prefixed with the 'GPRS_' keyword
have now been flagged as deprecated, and a new enum name given to the
corresponding value.
The deprecated symbol names are kept in the compat support to avoid
breaking API/ABI.
If ModemManager is not built with QMI support, the generic MBIM modem
object will not have any location support, so we cannot assume that
iface_modem_location_parent will be valid and that it will have all
load_location_capabilities(), enable_location_gathering() and
disable_location_gathering() implemented.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/362
Using AT%IPDPCFG for authentication related profile settings
management (querying, updating), and relying on the parent
implementation for the remaining ones.
And using AT%IPDPACT for activation status management (deactivate),
while relying on the parent implementation for the activated check.
There is no longer need to perform all the CID selection logic in the
broadband bearer connection procedure, we can rely on the new profile
management operations to do the same thing.
We can do this because we're sure that all the MMBroadbandModem
objects implement the MMModem3gppProfileManager interface.
Additionally, given that we now provide the profile ID value as part
of the MMBearerConnectResult, we no longer need a custom
mm_broadband_bearer_get_3gpp_cid() as we can use the generic
mm_base_bearer_get_profile_id() for the same purpose.
0x0489 is the vendor ID of T77W968, 0x105b is the vendor ID of T99W175.
{0x105b, 0xe0b0},{0x105b, 0xe0b1} is T99W175 PCI device, used by Dell.
{0x105b, 0xe0ab} is T99W175 PCI device, used by Lenovo.
If the modem has an mbim port, create a MbimFoxconn object, regardless
of what the product ID is.
The firmware version format in the T99W175 was selected to have
firmware version + carrier config version + apps version.
wwan is a new subsystem for WWAN devices, allowing to expose the
WWAN device and its ports in a generic way.
The sysfs hierarchy for such device is
/sys/class/wwanX
/sys/class/wwanX/wwanXpYP
Where X is the WWAN device index, Y the port index and P the
control protocol name (QMI, MBIM...). A control port is also
exposed as character device in /dev.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
There is no point in providing a configurable default IP family in the
bearer object, because we can always assume IPv4 as being the only
default expected.
Simplify the logic and also provide a new method to get the normalize
the IP family, using IPv4 as default always.
The g_regex_match_full() method may return FALSE without setting the
GError, so that case needs to be considered.
In addition to that, the following g_assert() was not doing what it
should have been, as it was comparing the address of the variable and
not the variable itself; rework the code to avoid that as well:
g_assert (access_tech != MM_MODEM_ACCESS_TECHNOLOGY_UNKNOWN);
Using CPOL? in the EM7345 (firmware FIH7160_V1.1_MODEM_01.1349.12)
ends up with the whole AT port stuck and non-responsive, which leads
to flagging the modem as unusable later on as soon as 10 consecutive
AT command timeouts happen.
In order to avoid that, we explicitly disable all CPOL based features
in this specific module.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/336
Both the Simple.Connect() and Modem.CreateBearer() are updated to
allow a new 'multiplex' setting in the properties provided by the user
in both of these methods.
The new setting expects a MMBearerMultiplexSupport enum indicating
what kind of multiplex needs the user has:
* none: if multiplex must not be used.
* requested: if multiplex should be used if available.
* required: if multiplex must be used.
The underlying implementations will take care of accepting or
rejecting the setting depending on the system and modem capabilities.
We already have methods to query for interface specific attributes
like class/subclass/protocol, so add a new one for the interface
number, and make sure we use ATTRS{bInterfaceNumber} to load it
always, instead of assuming the ID_USB_INTERFACE_NUM property is set.
Instead of blindly assuming that we can take whatever string given as
valid UTF-8, we'll always attempt to convert from the current modem
charset into UTF-8. Before we were doing this for hex-encoded UCS2,
but not for example for GSM-7.
And due to the now applied GSM-7 conversion, the mf627a/mf627b +COPS
parsing unit tests are updated accordingly, because when converting
from an input string that contains byte 0x40 ('@' in UTF-8) as if it
were GSM-7, the 0x40 is taken as character '¡', encoded as 0xc2,0xa1
in UTF-8).
