The timeout in this command is extremely large, because there are some
modules like the EGS5 that build the response based on the current
network registration, and that implies the module needs to be
registered. If for any reason there is no serving network where to
register, the response comes after a very long time, up to 100s.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/408
There are modems out there, that reuse the same vid:pid for multiple
USB layouts, so there may be port type hints that are not really
applicable in all layouts.
E.g. the EM7565 in MBIM layout uses interface #0 for the MBIM port,
while in QMI layout it uses interface #0 for the QCDM port (which is
what the port type hint included in MM states). With these rules, if
we don't bind the port type hint to TTY ports only, we would be
wrongly flagging the MBIM port as possible QCDM port:
<debug> [plugin/sierra] probes required for port cdc-wdm0: 'mbim'
<debug> [cdc-wdm0/probe] no AT/QMI/MBIM probing in possible QCDM port
<debug> [cdc-wdm0/probe] port is not AT-capable
<debug> [cdc-wdm0/probe] port is not QMI-capable
<debug> [cdc-wdm0/probe] port is not MBIM-capable
<debug> [cdc-wdm0/probe] port probing finished: no more probings needed
Avoid this, by making sure all port type hints are added exclusively
to TTY ports. It's not a perfect solution, but it's enough for the
known cases.
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.
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.
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);
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.
Each different plugin or protocol had a different connection attempt
value. E.g. QMI and MBIM both used 60s max for the connection attempt,
while the u-blox plugin had up to 180s for ECM based connection
setups.
This commit consolidates all plugins and protocols to use the same
timeout values for commands that may take long to respond, e.g. a
connection atempt under low signal quality conditions.
A value of 180s for the connection attempt steps and 120s for a
disconnection attempt step is considered. Note, though, that in some
cases (like a IPv4v6 setup attempt using QMI) we may have more than
one such long step, so this doesn't mean that a connection attempt
will always take less than 180s.
Users of the connection/disconnection APIs should be able to handle
the case where the attempt times out in their side (e.g. with a lower
DBus request timeout), and which would not mean the actual request
they did really failed. E.g. a connection attempt with a DBus timeout
of 30s may fail in the user with a timeout error, but the attempt
would still go on for as much as the plugin/protocol needs.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/270
Back in Linux < 3.6 days, the cdc-wdm ports exposed by the QMI driver
were flagged as owned by the 'usb' subsystem. That changed in 3.6 when
the subsystem was renamed to 'usbmisc':
https://mail.gnome.org/archives/networkmanager-list/2012-June/msg00125.html
This patch removes all monitoring of the 'usb' subsystem completely,
which is anyway a valid subsystem but for which we shouldn't need any
special handling. Right now, with newer kernels, we were using that
monitoring exclusively to get notified of full USB device remove
events, which is really not required as we already process the port
removals one by one.
We simplify the logic everywhere that attempted to match either the
'usb' or 'usbmisc' subsystems, and we no longer require the explicit
checks for the port name being named 'cdc-wdm[0-9]*' in the code, as
that is already taken care of by the ID_MM_CANDIDATE udev tag rule.
The mm_base_modem_get_port_*() returns a full reference, we should use
the mm_base_modem_peek_port_*() methods instead. Also, refactor a bit
the logic because both ports are really configured in the same way, so
just apply the same setup to both.
The class object definition should always be last in the file,
following the interface definitions. The actual method implementations
should be given before any other type system method (i.e. before even
the _new() method).
There is no need to reload it on every settings update attempt; just
load it once when the 3GPP interface is initialized, and re-use the
loaded value on every new update attempt.
Attempting to change the initial EPS bearer settings while in full
functionality mode shouldn't happen, so make sure we don't attempt to
do that if going into low power mode fails.
Multiple changes that shouldn't affect behavior:
* Avoid reusing the same context and state machine for the set and
the load operations, because they truly have different behaviors.
* Setup the common load operation in a separate async method, and
reuse the common operation for both the runtime state loading and
the settings configuration loading.
* Avoid having a "generic step ready" method, and instead provide
proper ready methods for each step, so that we can give
comprehensive warning logs when things fail.
* Use the common CFUN? response parser instead of a custom
implementation.
The PLS8 and PLAS9 modems (and likely many others modems supported by
this driver) have two AT capable serial ports: The 'MODEM' AT port
(default for PPP) and the 'APPLICATION' AT port (used for general
control).
The PLS8 modem sends URCs to the APPLICATION port by default, while he
PLAS9 defaults sending URCs to the MODEM port. To get URCs to behave
on both modems, it is necessary to explicitly set the URC reporting
port to APPLICATION.
There was a limitation in the past in the plugin, because one of the steps
during the dial (CONNECT_3GPP_CONTEXT_STEP_PDP_CTX) was to reconfigure a
specific CID hardcoding the IP type to IPv4.
That logic was removed in commit af2d6c1c4b,
but we didn't remove the IPv4 limitation at that point.
some ITM family modems require full parameters:
AT^SGAUTH=cid,type,user,pwd
even when type is AUTH_NONE.
Fortunately, all modules of the IMT family tolerate this syntax,
so it can be adopted for the entire family.
the AT^SCFG="Radio/Band" command does not return a different answer
for different charsets.
This code was working previously because the charset was left to default (GSM)
at the time of this operation, and therefore the string was unchanged anyway.
CHAP is almost universal nowadays, and so it is a better default
than PAP
Not changed for uBlox, that prefers an error if not specified,
and for Huawei, which uses NONE with user/pwd and has 2 CHAP choices
The ELS61 doesn't like authentication given without quotes:
[modem3/ttyACM1/at] --> 'AT^SGAUTH=8,1,tm,t-mobile<CR>'
[modem3/ttyACM1/at] <-- '<CR><LF>+CME ERROR: 4<CR><LF>'
Only when user/pass strings are quoted it works:
[modem6/ttyACM1/at] --> 'AT^SGAUTH=8,1,"t-mobile","tm"<CR>'
[modem6/ttyACM1/at] <-- '<CR><LF>OK<CR><LF>'
