Age | Commit message (Collapse) | Author |
|
|
|
mm-bearer-qmi.c:168:18: error: this statement may fall through [-Werror=implicit-fallthrough=]
168 | ctx->step++;
| ~~~~~~~~~^~
mm-bearer-qmi.c:169:5: note: here
169 | case RELOAD_STATS_CONTEXT_STEP_IPV4:
| ^~~~
...
|
|
mm-bearer-qmi.c: In function ‘reload_stats_context_step’:
mm-bearer-qmi.c:165:5: error: switch missing default case [-Werror=switch-default]
165 | switch (ctx->step) {
| ^~~~~~
mm-bearer-qmi.c: In function ‘connection_status_context_step’:
mm-bearer-qmi.c:310:5: error: switch missing default case [-Werror=switch-default]
310 | switch (ctx->step) {
| ^~~~~~
mm-bearer-qmi.c: In function ‘connect_context_step’:
mm-bearer-qmi.c:1290:5: error: switch missing default case [-Werror=switch-default]
1290 | switch (ctx->step) {
| ^~~~~~
mm-bearer-qmi.c: In function ‘disconnect_context_step’:
mm-bearer-qmi.c:1954:5: error: switch missing default case [-Werror=switch-default]
1954 | switch (ctx->step) {
| ^~~~~~
|
|
To be in sync with the qmi_device_close_async() underlying method,
given that the synchronous one is deprecated.
|
|
|
|
Also, explicitly close the QMI port if we had it open for the
connected bearer.
==991919== 6,533 (48 direct, 6,485 indirect) bytes in 1 blocks are definitely lost in loss record 5,171 of 5,177
==991919== at 0x5048291: g_type_create_instance (gtype.c:1844)
==991919== by 0x502DFC4: g_object_new_internal (gobject.c:1827)
==991919== by 0x502EFA9: g_object_new_valist (gobject.c:2152)
==991919== by 0x502DB9E: g_object_new (gobject.c:1670)
==991919== by 0x2215CA: mm_port_qmi_new (mm-port-qmi.c:615)
==991919== by 0x16C892: mm_base_modem_grab_port (mm-base-modem.c:295)
==991919== by 0x1CEEE5: mm_plugin_create_modem (mm-plugin.c:1048)
==991919== by 0x157E1E: mm_device_create_modem (mm-device.c:413)
==991919== by 0x1535A0: device_support_check_ready (mm-base-manager.c:195)
==991919== by 0x4EC9160: g_task_return_now (gtask.c:1212)
==991919== by 0x4EC92AA: g_task_return (gtask.c:1281)
==991919== by 0x4EC9E34: g_task_return_pointer (gtask.c:1689)
|
|
If for any reason getting current settings fails and we require static
IP addressing (when using raw-ip), then that must be a hard error,
otherwise we'll end up with the modem reported as connected but
without any IP settings to use:
<info> error: couldn't get current settings: QMI protocol error (15): 'OutOfCall'
<info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> connected)
<info> Simple connect state (8/8): All done
<warn> Reloading stats failed: Couldn't get packet statistics: QMI protocol error (15): 'OutOfCall'
# mmcli -b 0
Bearer '/org/freedesktop/ModemManager1/Bearer/0'
-------------------------
Status | connected: 'yes'
| suspended: 'no'
| interface: 'wwan1'
| IP timeout: '20'
-------------------------
Properties | apn: 'm2minternet'
| roaming: 'allowed'
| IP type: 'none'
| user: 'none'
| password: 'none'
| number: 'none'
| Rm protocol: 'unknown'
-------------------------
IPv4 configuration | method: 'unknown'
-------------------------
IPv6 configuration | method: 'unknown'
-------------------------
Stats | Duration: '0'
| Bytes received: 'N/A'
| Bytes transmitted: 'N/A'
# mmcli -m 0
/org/freedesktop/ModemManager1/Modem/0 (device id '48f6c35f3d0376aa261a91c0cf7e6340d5a91601')
...
Status | lock: 'sim-pin2'
| unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10)'
| state: 'connected'
| power state: 'on'
| access tech: 'lte'
| signal quality: '96' (recent)
|
|
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.
|
|
If a WDS indication is received telling us that the modem is no longer
connected, abort the ongoing connection attempt right away with an
error and cleanup all allocated clients (implicitly disconnecting them
if required)..
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/155
|
|
Refactor the logic and setup a common complete_connect() method that
helps us complete the GTask associated to the connection attempt.
|
|
If the bearer is using a QMI port that is not the primary one, we need
to explicitly open it during the connection attempt. Keep track of
that, and make sure we close it during normal disconnection or if the
connection attempt fails.
|
|
The data and qmi objects were not being correctly disposed on several
error conditions.
|
|
|
|
indication_id
If a disconnection fails (because stop_network() failed), base-bearer
flips the state back to CONNECTED. Oops. At that point something is
clearly messed up, but it seems correct to assume the bearer is
connected.
Nevertheless, we will have already have unhooked the unsolicited events
reporting. A subsequent attempt to disconnect the bearer will trip the
assertion:
#0 0x00007ffff75f2eb5 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff75dd895 in __GI_abort () at abort.c:79
#2 0x00007ffff77beb53 in g_assertion_message
(domain=<optimized out>, file=<optimized out>, line=<optimized out>, func=0x5088e0 <__FUNCTION__.56253> "cleanup_event_report_unsolicited_events", message=<optimized out>) at ../glib/gtestutils.c:2878
#3 0x00007ffff781a96f in g_assertion_message_expr
(domain=domain@entry=0x0, file=file@entry=0x507aad "mm-bearer-qmi.c", line=line@entry=1138, func=func@entry=0x5088e0 <__FUNCTION__.56253> "cleanup_event_report_unsolicited_events", expr=expr@entry=0x507ae5 "*indication_id != 0") at ../glib/gtestutils.c:2904
#4 0x00000000004a0c49 in cleanup_event_report_unsolicited_events (client=<optimized out>, indication_id=0x5bb30c, self=<optimized out>)
at mm-bearer-qmi.c:1138
#5 0x00000000004a0c49 in cleanup_event_report_unsolicited_events
(client=<optimized out>, indication_id=indication_id@entry=0x5bb30c, self=0x5bb420 [MMBearerQmi]) at mm-bearer-qmi.c:1132
#6 0x00000000004a0ee3 in disconnect_context_step (task=0x7fffe8012100 [GTask]) at mm-bearer-qmi.c:1854
#7 0x000000000046e889 in disconnect_auth_ready (self=<optimized out>, res=<optimized out>, ctx=ctx@entry=0x654630)
at mm-iface-modem-simple.c:865
#8 0x00007ffff79cfa9a in g_task_return_now (task=0x7fffe8012640 [GTask]) at ../gio/gtask.c:1209
...
Add checks for indication_id to calls to
cleanup_event_report_unsolicited_events() on
DISCONNECT_STEP_STOP_NETWORK_IPV4 or DISCONNECT_STEP_STOP_NETWORK_IPV6, as
is done elsewhere.
|
|
|
|
|
|
If we get an error when setting up the WDS event report indications,
make sure we run connect_context_step() after having set the next step
as CONNECT_STEP_LAST.
|
|
This update makes it possible to request connection status polling for
QMI modems via the ID_MM_QMI_CONNECTION_STATUS_POLLING_ENABLE tag.
If not given, the connection status polling will be disabled by
default, and the QMI modem will rely on WDS indications only.
|
|
Otherwise, they'll end up queueing up and each time we get a new
indication the signal will get called multiple times:
[/dev/cdc-wdm0] received message...
<<<<<< RAW:
<<<<<< length = 20
<<<<<< data = 01:13:00:80:01:09:04:00:00:01:00:07:00:20:04:00:05:00:00:00
[/dev/cdc-wdm0] received generic indication (translated)...
<<<<<< QMUX:
<<<<<< length = 19
<<<<<< flags = 0x80
<<<<<< service = "wds"
<<<<<< client = 9
<<<<<< QMI:
<<<<<< flags = "indication"
<<<<<< transaction = 0
<<<<<< tlv_length = 7
<<<<<< message = "Event Report" (0x0001)
<<<<<< TLV:
<<<<<< type = "Preferred Data System" (0x20)
<<<<<< length = 4
<<<<<< value = 05:00:00:00
<<<<<< translated = lte
<debug> [1504578559.592891] Got QMI WDS event report
<debug> [1504578559.598212] Got QMI WDS event report
<debug> [1504578559.601694] Got QMI WDS event report
|
|
|
|
|
|
|
|
|
|
Don't do anything with the events yet, but at least turn them on
and capture them in debug logging.
|
|
This patch fixes a bug in packet_service_status_indication_cb(), which
incorrectly treats the MMBearerStatus enum value returned by
mm_base_bearer_get_status() as a MMBearerConnectionStatus enum value.
MMBearerStatus and MMBearerConnectionStatus can't be used
interchangeably as they have different enum values for the
'disconnected' and 'disconnecting' state.
|
|
E.g. if the connection attempt fails, connect_context_complete_and_free() may
be called before the signals are connected to the QmiClients.
https://bugs.freedesktop.org/show_bug.cgi?id=99047
|
|
A default implementation to monitor the ongoing connection is provided in the
generic MMBroadbandModem, based on AT+CGACT? to check whether the PDP context
of the connection (identified by the cached cid) is active or not.
This commit also disables the connection monitoring logic in those plugins that
have custom connection methods.
|
|
Deciding the IP method to use based on the underlying QMI port LLP should not be
done when the bearer object is created, because the QMI port in use may not
actually be open or have been opened at that time. During the connection attempt
we do make sure the QMI port is open, so we should check the LLP to use just
after that step.
|
|
Hook up to the WDS Packet Service Status indication, listen for
disconnection events, and disconnect the bearer when we get one.
|
|
|
|
Use the "WDS Get Packet Statistics" method to query for the ongoing number
of bytes transmitted or received. The QMI implementation uses different WDS
clients for IPv4 and IPv6; the stats reported are a combination of the values
retrieved from both WDS clients.
|
|
Auth settings will be added in a QMI message only if at least one of these is
requested:
* An explicit auth preference is requested.
* User string is given and isn't empty.
* Password string is given and isn't empty.
|
|
|
|
When we get an array from a libqmi output or input bundle, the array is always
owned by the bundle (i.e. transfer-none).
|
|
Same as we do in IPv6. Note that NM won't use it if DHCP is requested.
|
|
|
|
Just so that we don't have same header names in src/ and /libmm-glib.
|
|
|
|
|
|
If the APN was empty (implying that the modem/network should choose
the default APN) this caused an assertion in libqmi. Just don't
set an APN if we aren't given one.
|
|
|
|
|
|
If the bearer doesn't have one of IPv4 or IPv6 configuration, then the
qmi_message_wds_get_current_settings_output_get_ip*_address() functions
will return FALSE with a filled error, which was not cleared.
This fixes a glib warning message about overwriting an already-filled
GError.
|
|
Originally developed by:
Ben Chan <benchan@chromium.org>
This patch replaces mm_bearer_report_disconnection() with a more generic
mm_bearer_report_connection_status(), which allows reporting any
connection status of a bearer. This further allows getting rid of those
custom report_connection_status functions in plugic specific bearer
subclasses.
Note that while plugin-specific implementations can receive multiple
'MMBearerConnectionStatus' values, the generic implementation is only allowed
to receive DISCONNECTED. Plugins need to make sure that they process all the
other status values, and only report DISCONNECTED to the parent when required.
MBM:
The MBM bearer implementation of report_connection_status() expects either
CONNECTED or DISCONNECTED. If any of these is received and there is an ongoing
connection attempt, the corresponding operation will be completed. If there is
no connection attempt, we will just handle the DISCONNECTED state, calling the
parent method to notify that the modem got network-disconnected.
Icera:
The Icera bearer implementation of report_connection_status() expects either
CONNECTED, CONNECT FAILED or DISCONNECTED. If any of these is received and
there is an ongoing connection or disconnection attempt, the corresponding
operation will be completed. If there is no connection or disconnection
attempt, we will just handle the CONNECT FAILED and DISCONNECTED states,
calling the parent method (always with DISCONNECTED) to notify that the modem
got network-disconnected.
Option/HSO:
The Option/HSO bearer implementation of report_connection_status() expects
either CONNECTED, CONNECTION FAILED or DISCONNECTED. If any of these is
received and there is an ongoing connection or disconnection attempt, the
corresponding operation will be completed. If there is no connection or
disconnection attempt, we will just handle the CONNECTION FAILED and
DISCONNECTED states, calling the parent method (always with DISCONNECTED) to
notify that the modem got network-disconnected.
Huawei:
The Huawei bearer implementation of report_connection_status() expects either
CONNECTED or DISCONNECTED. These messages are not used to process pending
connection or disconnection attempts; so if they are received while one of
these is on-going, it will just be ignored. CONNECTED reports are also
ignored, so we will just handle the DISCONNECTED state, calling the parent
method to notify that the modem got network-disconnected.
Altair-LTE:
The Altair-LTE bearers will only report DISCONNECTED on network-disconnected
cases. There is no custom report_connection_status().
Novatel-LTE:
The Novatel-LTE bearers will only report DISCONNECTED on network-disconnected
cases. There is no custom report_connection_status().
|
|
Old code only printed one or the other; but if we have dual-stack
connectivity, print everything we can read.
|
|
We want to expose in the Modem interface the list of supported IP families, and
the easiest way to do so is to have the IP family as flags, and provide in the
interface a single enum.
Also, a value of 0 for a MMBearerIpFamily specifies that no flags are set, so
just rename it to 'NONE'.
And add a new 'ANY' value which sets all flags to 1.
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=701333
|
|
This patch adds a 'bearer-default-ip-family' property to MMBearer, which
specifies the default IP family to use for a bearer when no explicit
value is given via the simple connect properties. The default IP family
is set to IPv4 in MMBearer but can be overridden by a MMBearer subclass,
which allows a modem plugin to specify an appropriate default value.
|
|
|
|
Instead of deciding in advance which data port to use, we let the dialling
operation gather it. For the generic dialling logic, ATD-based, always an
'AT' port will be used as data port, even if we grabbed a 'net' port. Those
plugins that can work with 'net' ports will grab the specific 'net' port
themselves.
|