Based on a patch from: Bjørn Mork <bjorn@mork.no>
Some messages provide an additional NwError cause code from
the network in case of failure. This means that we need to
parse the reply even if the status indicates failure, to be
able to return the exact failure cause.
Some Huawei modems (e.g. E220) may give an empty response for AT^SYSCFG=?, even
if they do support the command. Handle this case by prividing a default fallback
format string when this happens.
As soon as we get a match between the current interface being probed, and the
first expected interface to probe, clear the timeout. But this doesn't mean that
this interface being probed will be the correct one, so it may be the case that
we end up expecting a new first interface and probing another one.
With an example probably seen better...
Modem appears with interfaces 2, 3 and 4.
1. We first try to look for interface 0, which is not in the set:
1.1. Probing interfaces 2, 3 and 4 get deferred.
2. First-interface timeout happens because interface 0 doesn't appear, so we
switch to wait for interface 1:
2.1 Probing interfaces 2, 3 and 4 get deferred.
3. First-interface timeout happens because interface 1 doesn't appear, so we
switch to wait for interface 2:
3.1. We get a match on interface 2, which exists. We now remove the
first-interface timeout and start running the init sequence there.
3.2. Probing interfaces 3 and 4 get deferred.
4. Init sequence in interface 2 fails, because it is not an AT port, so we
switch to wait for interface 3:
3.1. We get a match on interface 3, which exists. We do *not* need to remove
now the first-interface timeout because this interface we are testing is
actually the second one which we tried.
So, just check whether the timeout exists or not, and if it exists remove it.
Yeah, this commit just fixes a warning at the end.
When running the pre-probing VID/PID filters, the ports were not filtered out if
the plugin had configured post-probing vendor/product string filters. But, these
post-probing filters are only applicable to AT ports.
From now on, this logic will not be applied to non-serial ports. In other words,
pre-probing VID/PID filters applied to non-serial ports will always result in
the port being filtered out or being allowed, regardless of any additional
vendor/product string post-probing filter configured by the plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=710437
The logic to decide whether a property is valid in a given PDU type is kind of
fuzzy for 3GPP2 as it is currently implemented; so just print whatever we have
in the interface.
Originally developed by:
Prathmesh Prabhu <pprabhu@chromium.org>
Ben Chan <benchan@chromium.org>
Huawei MU736 prematurely fires a ^NDISSTAT unsolicited message upon a
network-initiated disconnection. The modem can go into a bad state if a
reconnect attempt happens before the disconnection completes. This patch works
around the issue by delaying the reporting of the disconnection.
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().
When we get an internal error while checking the lock status, tell the upper
layers that we can retry the check. It's been observed that this internal error
may be issued not only when e.g. there is no SIM, but also when the SIM is not
yet fully ready.
The new internal_load_unlock_required() method will take care of running the
subclassed load_unlock_required(), if available, and also retry the check up
to 6 times.
This method will be used both by the standard unlock required check and by the
check within the current capabilities loading for multimode devices.
The Huawei MU736 supports CIND? but not for signal quality reporting:
AT+CIND=?
+CIND : ("call",(0,1)), ("message",(0,1)), ("roam",(0,1))
OK
AT+CIND?
+CIND:0,0,0
OK
Which ended up with the following during execution:
ModemManager[3044]: (ttyUSB1) Could not parse CIND signal quality results;
signal index (255) outside received range (0-3)
Just avoid this, and make CIND? be used for signal quality retrieval only if
(1) CIND? is actually supported and (2) CIND? reports signal quality
information.
Just add the messages with debug level, so that they don't get reported at
syslog. Having this kind of warnings in syslog is not useful, specially because
we wouldn't know which was the specific command that issued the warning. Errors
due to critical issues will anyway be reported in syslog in some way or another.
Don't query udev for the tag every time we recreate a bearer, just do it once.
For some reason, re-querying the same tag after the first time doesn't always
return the proper result.
Aleksander Morgado