The ofono_gprs_cid_activated attachment machinery cannot go through
ofono_gprs_status_notify for getting the attached property set because
that would result in the automatic contexts that were just set up
being released. As such, it needs to call gprs_set_attached_property
manually. Doing so, however, means that the driver_attached property
never gets set, resulting in all contexts being released when the
network transitions between registered states (roaming/non-roaming).
ofono_gprs_status_notify is an asynchronous notification that messes
with the 'attached' state of the GPRS atom. This method is normally
prevented from running while an attach is in progress because the
attachment machinery wants to finish up and make it's own determination
of attach state.
When automatic context activation is relevant, as for LTE networks,
the ofono_gprs_cid_activated machinery replaces the usual set_attach
machinery for attaching to the network. The cid_activated variant,
however, does not guard against simulatenous invocations of
ofono_gprs_status_notify. This causes a race whereby status_notify
sets the state to 'attached' before the context is fully constructed
and set to active. If the connection manager sees the 'attached'
state before there are any 'active' contexts, it may decide to
activate a context manually which is not the correct behaviour for
this type of network.
This patch makes the *_cid_activated machinery an 'attaching' state,
introducing the same guards that set_attached has to prevent
ofono_gprs_status_notify from running concurrently.
Calling set_online(TRUE) for an AlwaysOnline modem should succeed; the
modem is, after all, in the requested state when the call returns.
Returning not_implemented is not necessarily wrong, but it's a bit ugly.
SIM card can be removed while the query is in progress. There's
still a remote possibility that SIM card is removed and inserted
back while the query is pending, that would start the second query
sequence and end up invoking sim_initialize() twice. But at least
these checks reduce the probability of something like that happening.
Valgrind was complaining about it like this:
==18099== Conditional jump or move depends on uninitialised value(s)
==18099== at 0x4C32281: strspn
==18099== by 0x41286B: cbs_decode_text (smsutil.c:4140)
==18099== by 0x40675C: test_cbs_encode_decode (test-sms.c:1417)
Otherwise the attached state gets to be set before the actual LTE
automatic context is ready. This triggers a race between connman
and ofono: connman sees status attached before the context is active
so connman will try to activate another context with same apn and will
fail over and over again.
The spec supports UCS2, but in reality UTF-16 is used, which supports
4-byte characters, which could be split into different message
fragments. Accumulate the entire UTF-16 message before converting to
UTF8.
Author: Martin Jones <martin.jones@jolla.com>
This implementation can only get/set the default APN setting. But
anything expected for this atom is there:
* D-Bus interface
* sync-ing settings to/from file
* interaction with driver
... in pri_deactivate_callback
This prevents attached state from getting stuck at 0 like this:
1. Context deactivation is initiated over D-Bus, ctx->pending is set
2. Attached becomes FALSE, context is still marked as active
3. Attached becomes TRUE, gprs_attached_update sets GPRS_FLAG_ATTACHED_UPDATE
4. Deactivation completes, attached is 0, driver_attached is 1
Futher network status updates don't call gprs_attached_update because
driver_attached is still 1, so attached is staying 0 until we lose the
data registration again which may not happen for quite a long time.
query facility during initialization is modified from back
to back invocation to chain manner to keep it inline with
RIL design. All vendor RIL does not support back to back
handling since RIL telephony framework sends the request
synchronously.
The set_band method takes two parameters for band settings, one for gsm
and one for umts. When loaded from storage, and they are not set to
defaults, the band variables can get out of sync when setting the
GsmBand and UmtsBand properties.
Jonas Bonn
Christophe Ronco
Slava Monich
Djalal Harouni
Denis Kenzior
Dragos Tatulea
Caiwen Zhang
Samrat Guha Niyogi
Antara Borwankar
John Ernberg