uBlox devices present their USB interfaces well before those interfaces
are ready to respond to any commands. The documentation says to monitor
the 'greeting text' to detect readiness, but this 'greeting text' is not
actually specified for any device other than the TOBY L4.
What seems to work is to probe the device with 'AT' commands until the
device responds, and then to wait an additional second before
proceeding. The TOBY L4 reliably sends its 'greeting text' (+AT: READY)
within this interval.
It would be more rigorous to actually wait for the 'READY' indication
for the TOBY L4, but that would require knowing the device model before
the device model is actually queried. This is doable via the USB
product ID, but overkill when the above heuristic seems to work
reliably.
Before this patch, the ublox plugin was trying to achieve something like
the above with the g_at_chat_set_wakeup_command() function, but that had
some issues:
i) it did not work reliably, in particular failing badly on the TOBY L4
with responses getting out of sync with commands
ii) it was an inappropriate use of the wakeup_command which is intended
for devices that may sleep when there is no communication during some
interval
This patch adds an init sequence that probes the device for readiness
before continuing with initialization.
Just reshuffling the code a bit and the 'disable' path can use the
close_devices() helper to finish up. This also prevents a bug should
the CFUN command fail to disable the modem whereby the 'aux' device
remains open but the 'modem' device has already been closed.
The code for closing all the modem devices and flagging the modem as
unpowered is repeated several times in the driver... this patch puts
this code into a common helper for readability.
Its incorrect to fiddle with the driver attach state when
attaching. When attaching the state is transitioning,
and the correct state will now always be assigned in
the end of the attach process, regardless of result.
Currently there is an issue if the attach state changes and
there are active contexts of which the driver does not
implement the detach_shutdown.
In that case we just release the context (clears CID and
active state), but nothing is signalled on D-Bus or towards
the modem.
Ofono is then out of sync with both the connection manager
and the modem, this manifests itself later on if the modem
changes state of the context, then ofono will not find it
since the CID is cleared, and the connection manager won't
be notified.
In the same way as we consider the driver attached when the
gprs status indicates we are registered, we should consider
it deattached when the status indicates unregistration.
If we don't, then we would not always recover from the case
when deattaching the driver fails. We would just revert back
the driver attached status to true, and "ignore" if the status
indicates the opposite when we check the registration status
afterwards.
The quectel M95 and MC60 modems are picky about when the sim is properly
initialized, so the logic to detect this needs to be in the quectel
plugin.
After doing basic initialization, a CPIN query is issued to detect sim
state.
If the sim is unlocked and ready, a timer is created to wait for the
modem state (AT+QINISTAT) to complete. At this point ofono is notified
about the initialized sim.
If the sim is locked, a listener for "+CPIN: READY" is set up to
know when a pin is entered. Once the indication is received, the timer
is set up as if the sim was unlocked from the beginning.
If the sim is busy/resetting, the CPIN query is issued again.
In case a context get deactivated when a AT+CGACT=0 is
not issued, indicate that to gprs core.
This can happen if the device has an auto activated
LTE context and modem switches over to for instance UTRAN.
According to the manual, when using CMUX on the UC15, it outputs
unsolicited indications on port 2 (i.e. /dev/gsmtty2), so the quectel
plugin must use this when registering for such.
Commit 1fd419e5b4 and
0167c3339c introduced logic that
treated ofono_gprs_cid_activated as an 'attaching' state.
Since gprs_attached_update now guarantees that we
will not get attached without having a context activated
in LTE, this is not needed anymore. It also potentially
interferes in case the driver was actually attaching.
Since we have a different condition for the attach state
when running on LTE, we should consider it in gprs_attached_update.
Previously it's done in some instances. But for instance if
the driver got detached from GPRS but now running on LTE with a
context up, we would be deattached.
If the modem isn't powered on, the use of g_at_chat_set_wakeup_command()
makes ofono send out AT strings in an endless loop. Avoid this by using
g_at_chat_retry() in a timer instead.
The current API doesn't support canceling an in-progress command;
instead g_at_chat_cancel() simply removes the callback.
In cases where the modem doesn't respond at all to a command, a chat is
simply stalled without any way to write new commands to the modem.
Support that case by adding a g_at_chat_retry() function to the API. The
function does nothing if the command is not yet in-progress, or if the
command is finished. Otherwise, it resets the bytes-written counter to
re-write the command string.
There is an issue if an context gets auto activated early,
then provisioning might not have run yet for instance,
so a "new" context is created, which might be duplicated
by a provisioning context later.
So ignore the activated contexts until gprs is ready,
then it calls the driver to list active contexts.
There are cases where the gprs status might updated to for instance
"unknown" while LTE is the bearer.
In that case we should not set the attach state to FALSE,
since then running LTE the conext activation reflects the attached
state.
Previously the valid "unknown" netreg status was set
during startup, but its a bit problematic for gprs.
There might be cases where a LTE context is activated
before netreg is finished updating its status.
Resulting in gprs taking faulty actions.
Instead we set the status to -1 until we are updated
with a known value.
During the time the status is -1, gprs postpones actions until
the status is valid (>= 0).
To detect if a context gets activated before we register
for unsolicited events we need to check if any is
already activated, and flag it auto activated.
The Quectel modems issues unsolicited strings in case of power related
events. The UC15 uses +QIND: for the events, while M95 and MC60 uses
descriptive strings. (UC15 also uses a string for normal power down).
Register listeners for these strings/codes. The handler emits an
appropriate dbus signal, and closes down the modem if needed.
The gprs-context does special casing on the quectel serial modem when
probing the supported layer 2 protocols, so pass the vendor id when
setting up the atoms.
The Quectel M95 and MC60 modems respond to AT+CGDATA=? with a single
+CGDATA="PPP", but the callback in gprs-context expects a list of
protocols.
Avoid falling back to the old-style ATD*99 by not expecting a list of
protocols for serial quectel modems.
For uBlox modems, a bit of custom setup is required, but after that the
generic "atmodem" (27.007-compatible) method implementations are
sufficient. This driver, therefore, just puts the custom probe method
into place and defers remaining functionality to the recently exported
atmodem implementations.
Martin Hundebøll
Jonas Bonn
Richard Röjfors
Antara Borwankar
Pavel Machek
Marcel Holtmann