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).
This fix is similar to the one in the following commit,
but fixes allocation for context ids after ap's are
read from settings.
commit c3fdf6a7c5
Author: Denis Kenzior <denkenz@gmail.com>
Date: Thu Jan 3 17:17:21 2019 -0600
gprs: Fix allocation of context id
This patch allows a driver to set the interface only once, instead of at
every context activation. The previous way was originally designed for
PPP and RAW_IP based contexts which would have a (potentially)
differently named interface after each context activation due to use of
TUN/TAP. This also worked for static high-speed interface setups as
well, since these usually had a single interface only.
For devices that support multiple high-speed interfaces it would be
advantageous to have each gprs_context get an interface assignment right
in the modem driver and skip having to setup the interface on every
activation.
After the convertion to l_uintset, the creation of new contexts fails
due to a range error being returned from l_uintset_find_unused().
The error happens because the uinset is created with a min-value of 1,
but the start-value passed to l_uintset_find_unused() is initialized as
0.
Reported-by: Martin Hundebøll <martin@geanix.com>
the following functions:
gprs_proto_to_string
gprs_proto_from_string
gprs_auth_method_to_string
gprs_auth_method_from_string
are moved from gprs.c to common.c, with related declaration in common.h
so that they can also be accessed from lte core functions
Some protocols (like MBIM) do not properly support default bearer
semantics. Instead they want everything to function like UMTS/GSM where
the context has to be explicitly attached / activated.
There are two problems with using pri_set_apn. The first issue is that
this function was built to be used by the set_property handler and
assumes the presence of a pending DBusMessage.
The second issue is that it touches the settings store.
In the case of auto-activated contexts no pending message exists. Also,
we should not be touching the settings store as the APN might
potentially be a value that has not been provisioned. Or in some cases
bogus.
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.
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.
... 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.
In some cases it is possible that a context is opened after a detach
event has been received, and right before an attach, depending on the
modem. We make sure that those contexts are removed to keep
consistency.
It works by looking for a context with the same APN and tries to use
that. Otherwise it will create it's own.
Then it assigns a gprs context driver and calls it's read_settings if
it exists.
This matches the behavior described by the documentation the signal
value returned by the code. This was causing a headache when using
stricter D-Bus wrappers like dbus-c++.
Richard Röjfors
Denis Kenzior
Alexander Couzens
Antara Borwankar
Giacinto Cifelli
Jonas Bonn
Christophe Ronco
Dragos Tatulea
Slava Monich
Caiwen Zhang
Alfonso Sanchez-Beato
John Ernberg
Tony Espy
Philip Paeps
Christopher Vogl
Guillaume Zajac
Marcel Holtmann