| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
|
|
ModemManager handles suspend and resume signals sent from powerd
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/547
|
|
The modem may report the 'apn-type' field is the one to be used as
index; if that's the case, allow setting and deleting profiles based
on the given 'apn-type' field.
This change also makes the internal profile management operations use
one index field or another, based on what the protocol implements.
|
|
|
|
|
|
Using "requested" as a common default for every possible
implementation works, because it can handle setups without
multiplexing capabilities (e.g. plain AT+PPP modems) and also setups
without non-multiplexing capabilities (e.g. IPA based SoCs).
But if we don't want "requested" as default, then there will be
failing cases; e.g. we cannot use "none" as default for all as it
would break IPA, and we cannot use "required" as default for all as it
would break AT+PPP setups.
So, remove the common default, it's not flexible enough.
|
|
If the user doesn't provide a specific multiplex setting, we'll
fallback to a predefined default.
For now, the default is REQUESTED.
|
|
|
|
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 case of AT+CGACT? based modems.
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
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
|
|
|
|
|
|
|
|
mm-broadband-bearer.c: In function ‘cid_selection_3gpp_context_step’:
mm-broadband-bearer.c:871:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
871 | ctx->step++;
| ~~~~~~~~~^~
mm-broadband-bearer.c:873:5: note: here
873 | case CID_SELECTION_3GPP_STEP_FORMAT:
| ^~~~
mm-broadband-bearer.c: In function ‘interface_initialization_step’:
mm-broadband-bearer.c:2127:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
2127 | ctx->step++;
| ~~~~~~~~~^~
mm-broadband-bearer.c:2129:5: note: here
2129 | case INITIALIZATION_STEP_CDMA_RM_PROTOCOL:
| ^~~~
mm-broadband-bearer.c:2148:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
2148 | ctx->step++;
| ~~~~~~~~~^~
|
|
mm-broadband-bearer.c: In function ‘mm_broadband_bearer_new’:
mm-broadband-bearer.c:2204:46: warning: declaration of ‘properties’ shadows a global declaration [-Wshadow]
2204 | MMBearerProperties *properties,
| ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
mm-broadband-bearer.c:58:20: note: shadowed declaration is here
58 | static GParamSpec *properties[PROP_LAST];
| ^~~~~~~~~~
|
|
mm-broadband-bearer.c: In function ‘cid_selection_3gpp_context_step’:
mm-broadband-bearer.c:868:5: warning: switch missing default case [-Wswitch-default]
868 | switch (ctx->step) {
| ^~~~~~
mm-broadband-bearer.c: In function ‘disconnect’:
mm-broadband-bearer.c:1842:5: warning: switch missing default case [-Wswitch-default]
1842 | switch (MM_BROADBAND_BEARER (self)->priv->connection_type) {
| ^~~~~~
mm-broadband-bearer.c: In function ‘interface_initialization_step’:
mm-broadband-bearer.c:2124:5: warning: switch missing default case [-Wswitch-default]
2124 | switch (ctx->step) {
| ^~~~~~
|
|
When we try to disconnect a bearer and the bearer is already
disconnected (e.g. after a cancelled connection attempt), avoid reporting
that as an error:
<warn> [1575287560.433398] Error disconnecting bearer '/org/freedesktop/ModemManager1/Bearer/0': 'Couldn't disconnect QMI bearer: this bearer is not connected'. Will assume disconnected anyway.
|
|
Rework how the broadband bearer runs CGDCONT? and CGDCONT=? and setup
a helper method to perform the CID selection logic.
Also, implement unit tests for the CID selection logic.
|
|
When looking for the first unused CID, we should also consider those
contexts defined with a different PDP type, not just the ones with the
same PDP type.
|
|
There are two places where we look for unused CIDs:
* First, while processing the list of existing contexts returned by
CGDCONT?, we look for gaps in the used CIDs. E.g. if the first
context has CID=1 and the next one has CID=3, we can definitely use
the unused CID=2.
* Then, while processing the response of CGDCONT=?, we try to see
whether there is any empty CID available after the last existing
one found. E.g. if the last existing context has CID=3 and the
format tells us that the max allowed CID is 16, we can definitely
use the unused CID=4.
In both these cases, we should prefer using such an unused CID found
to overwriting other CIDs that are already defined.
This logic will now overwrite existing CIDs only if there are no
unused CIDs, and the preference to overwrite is as follows:
* If there is any existing context defined without an explicit APN,
overwrite it.
* Otherwise, overwrite the last existing CID found.
* And in the worst case, when no list of contexts was loaded
properly (e.g. some Android phones don't allow querying), fallback
to overwriting CID=1.
|
|
When a modem reported back non-sequential CIDs, MM was using the next
larger CID number after the last CID found. In cases where the last CID
found was the highest numbered CID allowed and is not a modifiable CID,
MM would give up and fail to establish a data connection.
The above issue occurs on u-blox TOBY-R200 modems as of firmware 30.33
A02.02. In this firmware version there are two default CIDs programmed
into the modem, one at CID 1 and another at CID 31. The CID at 31 is
the highest CID number that can be used and cannot be modified.
This change makes it so while parsing CIDs for a match, if a jump in CID
numbers is detected, so not sequential, the first open CID will be used
before using the max CID +1 or replacing the max CID. If an exact
match for IP type and APN is found, then that will still be used first.
|
|
On u-blox modems it has been observed that attempting to force down the
bearer when the modem had an active data connection, lost the connection
but the bearer is still up, and the modem is searching for the network,
ModemManager would timeout before the CGACT command could return. This
can put the modem in a state where the ModemManager state does not match
the modem's actual state of being connected.
When deactivating the current active bearer, the timeout has been
changed from 10 seconds to 45 seconds. u-blox modems can take up to 40
seconds to respond to deactivation requests through the AT+CGACT
command according to the u-blox AT command reference.
|
|
By default the build used -Wno-unused-but-set-variable but that's
clearly not what we want. Fix those problems.
When using clang, the compiler doesn't error on unknown compile
options, so let's add -Werror to the checking too.
CC='clang'
configure:3408: checking for gcc
configure:3435: result: clang
...
configure:17644: checking whether gcc understands -Wno-unused-but-set-variable
configure:17657: clang -c -Wall -std=gnu89 -g -O2 -Wmissing-declarations -Wmissing-prototypes -Wdeclaration-after-statement -Wstrict-prototypes -Wno-unused-parameter -Wno-sign-compare -Wno-deprecated-declarations -Wno-unused-but-set-variable conftest.c >&5
warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
1 warning generated.
configure:17657: $? = 0
configure:17666: result: yes
Reported-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
|
|
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/99
|
|
|
|
g_free() already check if the given pointer is NULL and does nothing on
a NULL pointer.
|
|
We're already configuring the flow control we expect when running
mm_port_serial_reopen(), which will keep the udev-selected flow
control or will otherwise reset to no flow control when the TTY is in
command mode.
|
|
On CDMA-only connections we won't have a CID defined, so instead of
getting in a loop of warnings reporting "cid not defined", early error
out with an UNSUPPORTED error so that the connection check isn't tried
any more.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/83
|
|
The PDP contexts that are found with an empty APN configured are right
now used as placeholders that can be overwritten with the user
provided APN if no direct match is found.
We want to keep that logic in place, but for the case where we do get
an empty APN requested by the user, we need to perform the full
context match, so that the first PDP context matching the empty APN is
used.
Right now we're overwriting with the empty APN again the last PDP
context found with an empty APN, which doesn't make much sense:
Apr 27 08:15:21 ModemManager[4251]: <debug> Found '3' PDP contexts
Apr 27 08:15:21 ModemManager[4251]: <debug> PDP context [cid=1] [type='ipv4'] [apn='']
Apr 27 08:15:21 ModemManager[4251]: <debug> PDP context [cid=2] [type='ipv4'] [apn='broadband']
Apr 27 08:15:21 ModemManager[4251]: <debug> PDP context [cid=15] [type='ipv4'] [apn='']
Apr 27 08:15:21 ModemManager[4251]: <debug> Found PDP context with CID 1 and no APN
Apr 27 08:15:21 ModemManager[4251]: <debug> Found PDP context with CID 15 and no APN
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3) device open count is 3 (open)
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3) device open count is 2 (close)
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3): --> 'AT+CGDCONT=15,"IP",""<CR>'
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3): <-- '<CR><LF>OK<CR><LF>'
|
|
All the steps in the connect_3gpp() sequence are implemented as
methods in the MMBroadbandBearer class, and therefore the objects
received in the corresponding ready() methods are all bearers, not
modems.
This issue wasn't found before because the objects received were not
really being used after all, as we were relying on the ones kept in
the context or lately in the GTask itself.
|
|
The init-sequence configured for the TTY that is being used as data
port must not be launched during the port reopen() sequence; instead
we must run it manually after the port flashing has finished.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
crm_range_ready() misses a return statement after it invokes
interface_initialization_step(), which will lead to an invalid access of
the already freed InitAsyncContext.
|
|
When returning an enum value via g_task_return_int, some code assumes
the enum value is always non-negative and thus considers that a negative
value implies an error. This assumption could be invalidated if a
negative value is later added to the enum. To make it less error prone
to future changes, this patch modifies the code to check if the GError
argument to g_task_propagate_error is populated instead.
|
|
During modem initialization we detected the flow control settings
supported by the modem, and selected the best one to use from them,
notifying it to the device via AT+IFC. The device was therefore
instructed to use that flow control setting for data transmission in
the TTY (i.e. not during AT control commands).
The missing thing was to also configure ourselves our end of the
serial port with the same flow control settings when getting into data
mode. By doing it ourselves, we avoid requiring any explicit setting
in pppd for flow control; pppd can assume the flow control settings
are already the expected ones.
Worth noting that all this setup is completely ignored for TTYs
exposed directly via USB.
https://bugs.freedesktop.org/show_bug.cgi?id=100394
|
|
g_free and g_object_unref are in form of `void (*)(gpointer)`, which
matches the GDestroyNotify signature. An explicit GDestroyNotify cast on
g_free and g_object_unref is thus not needed.
|
|
On modems with a single TTY for both control and data, we cannot use
the TTY to load connection status once we're in connected mode:
Connection through a plain serial AT port (ttyUSB2)
(ttyUSB2): --> 'ATD*99***2#<CR>'
(ttyUSB2): <-- '<CR><LF>CONNECT 100000000<CR><LF>'
(ttyUSB2): port now connected
Connected bearer '/org/freedesktop/ModemManager1/Bearer/0'
Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> connected)
Simple connect state (8/8): All done
checking if connected failed: Couldn't check current list of active PDP contexts: No AT port available to run command
checking if connected failed: Couldn't check current list of active PDP contexts: No AT port available to run command
checking if connected failed: Couldn't check current list of active PDP contexts: No AT port available to run command
...
So, disable connection monitoring right away if that situation is
detected:
Connection through a plain serial AT port (ttyUSB2)
(ttyUSB2): --> 'ATD*99***2#<CR>'
(ttyUSB2): <-- '<CR><LF>CONNECT 100000000<CR><LF>'
(ttyUSB2): port now connected
Connected bearer '/org/freedesktop/ModemManager1/Bearer/0'
Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> connected)
Simple connect state (8/8): All done
Connection monitoring is unsupported by the device
...
https://bugs.freedesktop.org/show_bug.cgi?id=100376
|
|
When the connection request is done via ATD, flag the port as
connected as soon as the successful response is received, so that we
remove our polling on the device right away.
https://bugs.freedesktop.org/show_bug.cgi?id=99541
|
|
u-blox modems will append a string showing the MCC and MNC info to the access
point name listed in AT+CGDCONT? responses. We will try to detect when that
happens, and we just accept the match.
The logic doesn't just look for a string prefix; it also looks for the special
MCC + MNC suffix, which is much more restrictive, to try to avoid false
positives.
|
|
|
