Commit 7ff57f9808 introduced a change to try to
use ATTRS{bInterfaceNumber} as a common way to match by interface number, but
this logic is broken because all the rules that we use to match by interface
number (attribute in the interface device) also require matching by idVendor
and idProduct (attributes in the physdev device), and udev rules forbid matches
from more than one parent device at a time.
We could use ATTR{bInterfaceNumber} (instead of ATTRS) to tag the actual USB
interface device, but that would require a change in all the plugins to look for
the tag not in the TTY device, but in its parent.
So, recover the original behavior, where a hidden property is created containing
the first bInterfaceNumber found in the list of parent devices, and then run
the matches against idVendor and idProduct only if the hidden property is found
with the expected value.
Rules with a single condition where a parent property is checked with != don't
work properly. E.g.:
SUBSYSTEMS!="usb", GOTO="end"
or:
ATTRS{idVendor}!="abcd", GOTO="end"
Instead, we can mix both those previous parent rules and match them:
SUBSYSTEMS=="usb",ATTRS{idVendor}=="abcd", GOTO="next"
GOTO="end"
LABEL="next"
# Apply rules here
LABEL="end"
In this case both SUBSYSTEMS and ATTRS conditions apply to the parent usb_device
(idVendor attribute is only available in the usb_device), so they apply to all
ports of the same device.
This patch makes declarations bind to definitions within the same module
to prevent the potential ambiguity if referenced directly.
AddressSanitizer think they violated one definition rule, although
those symbols are accessed by address through their modules and do
not depend on the order of the libararies loaded.
Otherwise we may leave a bearer connected when ModemManager doesn't
think it's connected. Prevents a CME ERROR 277 loop on connect when
the bearer hasn't been torn down correctly.
Wait for either an E2NAP unsolicited disconnect status or (for older
devices) an ENAP poll response before completing the disconnect.
Otherwise the client may start connecting again (such as
NetworkManager autoconnect retry) and the unsolicited E2NAP may
abort it, or the modem may return CME ERROR 277 ("not disconnected
yet") for the next connection attempt.
https://bugs.freedesktop.org/attachment.cgi?id=123525
There are a few key parts to this patch:
1) move the poll id into the Dial3gppContext structure as it is
conceptually part of the connection context data. This simplifies
context cleanup by keeping the poll id cleanup in one place.
2) move unsolicited connection status (E2NAP) handling into the
normal connection codepath, instead of completing the connection
context from the report_connection_status() E2NAP handler. This
simplifies connect code by not requiring checks for a NULL context
everywhere, and allows us to pass the Dial3gppContext structure
around instead of the Bearer object, since the Dial3gppContext
will never be comleted/freed outside the normal connection flow
codepaths like GLib idles and AT command requests.
3) use the connect context cancellable for all AT command requests
in the connect path. This lets us use the error return from
mm_base_modem_at_command_full_finish() to handle cancellation and
also not bother listening to the 'cancelled' signal of the
cancellable, since we can just check for cancellation the next time
the ENAP poll function runs.
https://bugs.freedesktop.org/show_bug.cgi?id=95304
We were trying to load the generic modes supported reported by either *CNTI=2 or
AT+WS46=?, so that then we could filter out the MBM-specific modes unsupported.
But, this may not be ideal, as both these two commands may fail:
[mm-broadband-modem.c:1612] modem_load_supported_modes(): loading supported modes...
[mm-port-serial.c:1237] mm_port_serial_open(): (ttyACM1) device open count is 3 (open)
[mm-port-serial.c:1294] _close_internal(): (ttyACM1) device open count is 2 (close)
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): --> 'AT*CNTI=2<CR>'
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): <-- '<CR><LF>ERROR<CR><LF>'
[mm-serial-parsers.c:364] mm_serial_parser_v1_parse(): Got failure code 100: Unknown error
[mm-broadband-modem.c:1546] supported_modes_cnti_ready(): Generic query of supported 3GPP networks with *CNTI failed: 'Unknown error'
[mm-port-serial.c:1237] mm_port_serial_open(): (ttyACM1) device open count is 3 (open)
[mm-port-serial.c:1294] _close_internal(): (ttyACM1) device open count is 2 (close)
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): --> 'AT+WS46=?<CR>'
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): <-- '<CR><LF>ERROR<CR><LF>'
[mm-serial-parsers.c:364] mm_serial_parser_v1_parse(): Got failure code 100: Unknown error
[mm-broadband-modem.c:1494] supported_modes_ws46_test_ready(): Generic query of supported 3GPP networks with WS46=? failed: 'Unknown error'
[mm-iface-modem.c:3974] load_supported_modes_ready(): couldn't load Supported Modes: 'Couldn't retrieve supported modes'
Instead, we'll ask the modem for the list of modes supported, and return that
directly.
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().
We now have a single 'CurrentModes' property which contains both values in a
tuple with signature "(uu)".
Also, rename 'SetAllowedModes()' to 'SetCurrentModes()', and update the list of
arguments expected to have a single "(uu)" tuple.
MBM modems will lie about the unlock status just after having sent a
correct PIN or PUK. So, explicitly wait to get in READY state after having
sent the PIN or PUK, before keeping on.
https://bugzilla.gnome.org/show_bug.cgi?id=696702
We can just tag the ttys instead of the parent usb device, so that the core
logic which looks in the plugin-specified port tags works properly. There is no
need to explicitly tag the net port, as the probing for this port ends when a
plugin suggestion comes from another port probing on the same device.
We need to handle modems which appear in low-power mode (e.g. CFUN=4), so
implement a custom check of the power state. We cannot use the default check
as MBM modems use CFUN also for allowed mode handling.
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.
Instead of a custom modem_init() step in the 'Modem' interface, just add a
sequence of port initialization commands in each port.
While enabling for the first time a non-hotplugged modem, we will issue the
port initialization commands only after having run the enabling_modem_init()
step (i.e. after ATZ usually).
We previously had the modem initialization command merged with some other port
setup commands in the 'modem_init' step of the 'Modem' interface. Instead of
doing this, we now split the logic into two separate steps:
A first 'enabling_modem_init' modem initialization step is to be run just after
the ports have been opened, but only during the first enabling operation, and
only if the modem was not hotplugged. A hotplugged modem is assumed to be
properly initialized already, so no need to ATZ-it. Also, we will now wait 500ms
by default after the modem initialization command has been sent, to let it
settle down.
The second 'modem_init' step will be run during the 'Modem' interface
initialization, and it currently only holds specific setup of the primary and
secondary serial ports. We'll be modifying this logic a bit in the next commits,
so no big deal to have that step name unchanged.
HSUPA/HSPA capable devices (ex F5521gw) can report '3' here, which
we'll decide to interpret as HSPA. It might actually be HSDPA + HSUPA,
but whatever...
When both load_power_state() and modem_power_down() are not implemented, the
logic will launch the power-up command during (only the first) enabling of the
modem.
In this kind of modems, CFUN is directly related to allowed/preferred modes, so
during the initial power-up we'll just assume we want ANY mode.
