2:37 p.m.
The following issue is causing us some grief and I really need some
guidance on how to approach this. This is being sent to both the ofono
and connman mailing lists because it's not really clear to me who's
doing the right/wrong thing here...
The connman ofono plugin does the following:
i) It powers up (enables) the modem
ii) If cellular tech is enabled, it brings the modem online
For an LTE-modem, this second step results in a default bearer being
attached and thereby the modem is 'connected'. The third connman step,
setting the ofono context to Active, is not required for LTE; the
context becomes 'Active=true' right away.
The above effectively means that it's not possible to have an LTE modem
that does not auto-connect (in connman terms).
Now the APN that ofono sets on the LTE context is 'automatic'; that was
selected because connman _requires_ some APN or else it ignores the
context altogther.
If the modem roams away from LTE connectivity and wants to fallback to
UMTS/GSM, it needs another context with a valid APN. So now the modem
has two 'internet' contexts ('automatic' and APN) which connman presents
as two distinct services.
These two services, as far as I can tell, end up competing with each
other when connecting and a mess ensues... if the lower numbered context
is the 3G context, connman goes into an endless loop attempting to set
it Active and continuously failing when the tech switches to LTE.
The question is, what are the expectations here:
i) What does it mean for connman to see two 'internet' contexts since
it sets up two services for them?
ii) How is a modem supposed to roam between LTE and UMTS/GSM networks
when one requires an APN and the other does not.
iii) Not auto-connecting an LTE modem means not bringing it online; what
implications does this have for connman?
The above is currently a bit of a confusing mess and both ofono and
connman get themselves tied in a knot when the modem switches between
LTE and non-LTE techs. Any guidance on how to approach this would be
appreciated.
Thanks,
Jonas
4:12 p.m.
Hi Jonas,
On 02/26/2018 08:37 AM, Jonas Bonn wrote:
The following issue is causing us some grief and I really need some
guidance on how to approach this. This is being sent to both the ofono
and connman mailing lists because it's not really clear to me who's
doing the right/wrong thing here...
The connman ofono plugin does the following:
i) It powers up (enables) the modem
ii) If cellular tech is enabled, it brings the modem online
For an LTE-modem, this second step results in a default bearer being
attached and thereby the modem is 'connected'. The third connman step,
setting the ofono context to Active, is not required for LTE; the
context becomes 'Active=true' right away.
The above effectively means that it's not possible to have an LTE modem
that does not auto-connect (in connman terms).
There are multiple possible scenarios here, the two most common ones are:
1. Default attach APN is an internet context
2. Default attach APN is an IMS context
The network provider usually behaves in way 1 or 2 above. We can
control the default attach context to some degree by using
org.ofono.LongTermEvolution.DefaultAccessPointName
For this to work nicely you really need automatic context provisioning
to work so that the various APN types are known ahead of time.
Either way, when the context is auto activated by the modem it should
tell what APN ended up being used. Ideally that APN _should_ match one
of the provisioned contexts.
Now the APN that ofono sets on the LTE context is
'automatic'; that was
selected because connman _requires_ some APN or else it ignores the
context altogther.
That would seem to be a driver issue. drivers/qmimodem/gprs-context.c
even has a TODO entry in there...
If the modem roams away from LTE connectivity and wants to fallback to
UMTS/GSM, it needs another context with a valid APN. So now the modem
has two 'internet' contexts ('automatic' and APN) which connman presents
as two distinct services.
This is obviously wrong. If the modem roams onto 3G then the contexts
should be preserved. There should still be a single internet context...
These two services, as far as I can tell, end up competing with each
other when connecting and a mess ensues... if the lower numbered context
is the 3G context, connman goes into an endless loop attempting to set
it Active and continuously failing when the tech switches to LTE.
Yeah, no wonder...
The question is, what are the expectations here:
i) What does it mean for connman to see two 'internet' contexts since
it sets up two services for them?
ii) How is a modem supposed to roam between LTE and UMTS/GSM networks
when one requires an APN and the other does not.
iii) Not auto-connecting an LTE modem means not bringing it online; what
implications does this have for connman?
The above is currently a bit of a confusing mess and both ofono and
connman get themselves tied in a knot when the modem switches between
LTE and non-LTE techs. Any guidance on how to approach this would be
appreciated.
The answer is to just fix your oFono driver.
Regards,
-Denis
4:30 p.m.
Hi Jonas,
On 02/26/2018 05:12 PM, Denis Kenzior wrote:
Hi Jonas,
On 02/26/2018 08:37 AM, Jonas Bonn wrote:
> The following issue is causing us some grief and I really need some
> guidance on how to approach this. This is being sent to both the
> ofono and connman mailing lists because it's not really clear to me
> who's doing the right/wrong thing here...
>
> The connman ofono plugin does the following:
> i) It powers up (enables) the modem
> ii) If cellular tech is enabled, it brings the modem online
>
> For an LTE-modem, this second step results in a default bearer being
> attached and thereby the modem is 'connected'. The third connman
> step, setting the ofono context to Active, is not required for LTE;
> the context becomes 'Active=true' right away.
>
> The above effectively means that it's not possible to have an LTE
> modem that does not auto-connect (in connman terms).
>
There are multiple possible scenarios here, the two most common ones are:
1. Default attach APN is an internet context
2. Default attach APN is an IMS context
The network provider usually behaves in way 1 or 2 above. We can
control the default attach context to some degree by using
org.ofono.LongTermEvolution.DefaultAccessPointName
For this to work nicely you really need automatic context provisioning
to work so that the various APN types are known ahead of time.
Either way, when the context is auto activated by the modem it should
tell what APN ended up being used. Ideally that APN _should_ match
one of the provisioned contexts.
> Now the APN that ofono sets on the LTE context is 'automatic'; that
> was selected because connman _requires_ some APN or else it ignores
> the context altogther.
That would seem to be a driver issue. drivers/qmimodem/gprs-context.c
even has a TODO entry in there...
>
> If the modem roams away from LTE connectivity and wants to fallback
> to UMTS/GSM, it needs another context with a valid APN. So now the
> modem has two 'internet' contexts ('automatic' and APN) which connman
> presents as two distinct services.
>
This is obviously wrong. If the modem roams onto 3G then the contexts
should be preserved. There should still be a single internet context...
> These two services, as far as I can tell, end up competing with each
> other when connecting and a mess ensues... if the lower numbered
> context is the 3G context, connman goes into an endless loop
> attempting to set it Active and continuously failing when the tech
> switches to LTE.
>
Yeah, no wonder...
> The question is, what are the expectations here:
> i) What does it mean for connman to see two 'internet' contexts
> since it sets up two services for them?
> ii) How is a modem supposed to roam between LTE and UMTS/GSM
> networks when one requires an APN and the other does not.
> iii) Not auto-connecting an LTE modem means not bringing it online;
> what implications does this have for connman?
>
> The above is currently a bit of a confusing mess and both ofono and
> connman get themselves tied in a knot when the modem switches between
> LTE and non-LTE techs. Any guidance on how to approach this would be
> appreciated.
>
The answer is to just fix your oFono driver.
I had this issue with QMI modems. As a
workaround, I have disabled
auto-activation. This is just a workaround but here is my local patch:
From aaee53f19adbf7a4dca00366f6f7ae2ddfd4b580 Mon Sep 17 00:00:00 2001
From: Christophe Ronco <c.ronco(a)kerlink.fr>
Date: Tue, 9 May 2017 17:02:45 +0200
Subject: [PATCH] qmimodem: no automatic activation in LTE
If a SIM connects in LTE and if an APN is provisionned for
this SIM, we end with 2 contexts, one automatically activated
and the other ready to be activated.
That's confusing for connman. To avoid that, simply avoid
automatic connection if techno is LTE.
That's only a workaround because LTE should work without any APN
provisioned.
diff --git a/drivers/qmimodem/gprs.c b/drivers/qmimodem/gprs.c
index a80d55f..51909cd 100644
--- a/drivers/qmimodem/gprs.c
+++ b/drivers/qmimodem/gprs.c
@@ -74,17 +74,17 @@ static int handle_ss_info(struct qmi_result *result,
struct ofono_gprs *gprs)
if (!extract_ss_info(result, &status, &tech))
return -1;
- if (status == NETWORK_REGISTRATION_STATUS_REGISTERED)
- if (tech == ACCESS_TECHNOLOGY_EUTRAN) {
- /* On LTE we are effectively always attached; and
- * the default bearer is established as soon as the
- * network is joined.
- */
- /* FIXME: query default profile number and APN
- * instead of assuming profile 1 and ""
- */
- ofono_gprs_cid_activated(gprs, 1 , "automatic");
- }
+ //if (status == NETWORK_REGISTRATION_STATUS_REGISTERED)
+ //if (tech == ACCESS_TECHNOLOGY_EUTRAN) {
+ ///* On LTE we are effectively always attached; and
+ //* the default bearer is established as soon as the
+ //* network is joined.
+ //*/
+ ///* FIXME: query default profile number and APN
+ //* instead of assuming profile 1 and ""
+ //*/
+ //ofono_gprs_cid_activated(gprs, 1 , "automatic");
+ //}
return status;
}
--
2.7.4
11:27 a.m.
On 02/26/2018 05:12 PM, Denis Kenzior wrote:
Hi Jonas,
On 02/26/2018 08:37 AM, Jonas Bonn wrote:
> The question is, what are the expectations here:
> i) What does it mean for connman to see two 'internet' contexts
> since it sets up two services for them?
> ii) How is a modem supposed to roam between LTE and UMTS/GSM networks
> when one requires an APN and the other does not.
> iii) Not auto-connecting an LTE modem means not bringing it online;
> what implications does this have for connman?
>
> The above is currently a bit of a confusing mess and both ofono and
> connman get themselves tied in a knot when the modem switches between
> LTE and non-LTE techs. Any guidance on how to approach this would be
> appreciated.
>
The answer is to just fix your oFono driver.
OK... I fixed my driver. :) I sent the patches a couple of minutes ago.
With that, things work much better. connman doesn't choke on network
tech transitions anymore.
There are still issues with connman related to this though:
Ofono does something like this on a tech transition to LTE:
Active: false
Attached: false
...
Attached: true
Active: true
When ofono does Attached: true, connman starts trying to set the context
active which seems to result in InProgress. connman doesn't seem to
like the InProgress response and tries again, which ends up pounding the
modem hard with "set active" messages until read_settings() returns (on
the modem side) and the modem becomes Active (automatically) for real.
Similarly, on a transition from LTE to 3G, connman also tries to
activate the context hundreds of times before it settles. This
behaviour is harder to understand: connman has explicitly requested the
activation here and should know that it's in progress...
What I think might be an issue here is the interplay between Attached
and Active. For LTE, Attached and Active are synonymous...(???)
connman should not be setting Active for these at all.
Could ofono have Active set to true before Attached gets set true for
the LTE context case so that connman never sees the context as
Active:false? Or is there a better way to handle this?
/Jonas
3:11 p.m.
Hi Jonas,
Ofono does something like this on a tech transition to LTE:
Active: false
Attached: false
...
Attached: true
Active: true
This is from 3G to LTE or the initial registration to LTE? Do you have
an ofono-monitor log handy?
When ofono does Attached: true, connman starts trying to set the
context
active which seems to result in InProgress. connman doesn't seem to
like the InProgress response and tries again, which ends up pounding the
modem hard with "set active" messages until read_settings() returns (on
the modem side) and the modem becomes Active (automatically) for real.
That sounds like connman isn't taking InProgress into consideration
properly.
Similarly, on a transition from LTE to 3G, connman also tries to
activate the context hundreds of times before it settles. This
behaviour is harder to understand: connman has explicitly requested the
activation here and should know that it's in progress...
ofono-monitor log by any chance? I'm not sure why a switch from LTE to
3G would cause any changes to Active/Attached states. It should simply
twiddle the NetworkRegistration state and that's it, unless the modem is
reporting things it shouldn't.
What I think might be an issue here is the interplay between Attached
and Active. For LTE, Attached and Active are synonymous...(???) connman
should not be setting Active for these at all.
ConnMan doesn't keep track of the NetworkRegistration state, so it
doesn't really know about LTE...
Could ofono have Active set to true before Attached gets set true for
the LTE context case so that connman never sees the context as
Active:false? Or is there a better way to handle this?
I don't think that would make sense from an API consistency perspective.
Regards,
-Denis
3:48 p.m.
On 03/01/2018 04:11 PM, Denis Kenzior wrote:
Hi Jonas,
> Ofono does something like this on a tech transition to LTE:
>
> Active: false
> Attached: false
> ...
> Attached: true
> Active: true
>
This is from 3G to LTE or the initial registration to LTE? Do you have
an ofono-monitor log handy?
This is an explicit UMTS to LTE transition:
{RadioSettings} [/quectelqmi_0] TechnologyPreference = lte
{ConnectionManager} [/quectelqmi_0] Attached = False
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
{NetworkRegistration} [/quectelqmi_0] Status = searching
{NetworkRegistration} [/quectelqmi_0] Technology = lte
{NetworkOperator} [/quectelqmi_0/operator/24001] Status = available
{NetworkRegistration} [/quectelqmi_0] Name =
{ConnectionManager} [/quectelqmi_0] Attached = True
{NetworkRegistration} [/quectelqmi_0] Status = roaming
{NetworkRegistration} [/quectelqmi_0] LocationAreaCode = 65534
{NetworkRegistration} [/quectelqmi_0] CellId = 26710796
{NetworkOperator} [/quectelqmi_0/operator/24001] Status = current
{NetworkRegistration} [/quectelqmi_0] Name = 24001
{NetworkRegistration} [/quectelqmi_0] MobileCountryCode = 240
{NetworkRegistration} [/quectelqmi_0] MobileNetworkCode = 01
{NetworkRegistration} [/quectelqmi_0] Status = registered
{NetworkRegistration} [/quectelqmi_0] Name = Orange F
{NetworkOperator} [/quectelqmi_0/operator/24001] Name = TELIA
{NetworkRegistration} [/quectelqmi_0] Strength = 20
{NetworkRegistration} [/quectelqmi_0] Name = Orange F
{NetworkOperator} [/quectelqmi_0/operator/24001] Name = 24001
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
wwp0s20u1i4, Method = static, Address = 10.172.219.235, Netmask =
255.255.255.248, Gateway = 10.172.219.236, DomainNameServers =
194.51.3.56 194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
Here's what connman does effects on the LTE to UMTS transition:
{RadioSettings} [/quectelqmi_0] TechnologyPreference = umts
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
{ConnectionManager} [/quectelqmi_0] Attached = False
{NetworkRegistration} [/quectelqmi_0] LocationAreaCode = 11
{NetworkRegistration} [/quectelqmi_0] CellId = 752047
{NetworkRegistration} [/quectelqmi_0] Technology = umts
{ConnectionManager} [/quectelqmi_0] Attached = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
wwp0s20u1i4, Method = static, Address = 10.160.218.173, Netmask =
255.255.255.252, Gateway = 10.160.218.174, DomainNameServers =
194.51.3.56 194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
^[[F{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface
= wwp0s20u1i4, Method = static, Address = 10.167.137.164, Netmask =
255.255.255.248, Gateway = 10.167.137.165, DomainNameServers =
194.51.3.56 194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
wwp0s20u1i4, Method = static, Address = 10.173.100.170, Netmask =
255.255.255.252, Gateway = 10.173.100.169, DomainNameServers =
194.51.3.56 194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
wwp0s20u1i4, Method = static, Address = 10.160.115.172, Netmask =
255.255.255.248, Gateway = 10.160.115.173, DomainNameServers =
194.51.3.56 194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
wwp0s20u1i4, Method = static, Address = 10.167.11.161, Netmask =
255.255.255.252, Gateway = 10.167.11.162, DomainNameServers =
194.51.3.56 194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
wwp0s20u1i4, Method = static, Address = 10.173.65.6, Netmask =
255.255.255.252, Gateway = 10.173.65.5, DomainNameServers = 194.51.3.56
194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
....eventually that settles down and the connection is established.
> When ofono does Attached: true, connman starts trying to set the
> context active which seems to result in InProgress. connman doesn't
> seem to like the InProgress response and tries again, which ends up
> pounding the modem hard with "set active" messages until
> read_settings() returns (on the modem side) and the modem becomes
> Active (automatically) for real.
That sounds like connman isn't taking InProgress into consideration
properly.
>
> Similarly, on a transition from LTE to 3G, connman also tries to
> activate the context hundreds of times before it settles. This
> behaviour is harder to understand: connman has explicitly requested
> the activation here and should know that it's in progress...
ofono-monitor log by any chance? I'm not sure why a switch from LTE to
3G would cause any changes to Active/Attached states. It should simply
twiddle the NetworkRegistration state and that's it, unless the modem is
reporting things it shouldn't.
Maybe... take at look at the first ofono log above and see what the
network registration state is doing... that's what's causing the
unattached state, I think.
/Jonas
>
> What I think might be an issue here is the interplay between Attached
> and Active. For LTE, Attached and Active are synonymous...(???)
> connman should not be setting Active for these at all.
ConnMan doesn't keep track of the NetworkRegistration state, so it
doesn't really know about LTE...
>
> Could ofono have Active set to true before Attached gets set true for
> the LTE context case so that connman never sees the context as
> Active:false? Or is there a better way to handle this?
I don't think that would make sense from an API consistency perspective.
Regards,
-Denis
4:11 p.m.
Hi Jonas,
This is an explicit UMTS to LTE transition:
{RadioSettings} [/quectelqmi_0] TechnologyPreference = lte
Okay, so you set the Technology preference and the modem goes into
disconnect and search mode
{ConnectionManager} [/quectelqmi_0] Attached = False
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
{NetworkRegistration} [/quectelqmi_0] Status = searching
So far so good
{NetworkRegistration} [/quectelqmi_0] Technology = lte
{NetworkOperator} [/quectelqmi_0/operator/24001] Status = available
{NetworkRegistration} [/quectelqmi_0] Name =
{ConnectionManager} [/quectelqmi_0] Attached = True
{NetworkRegistration} [/quectelqmi_0] Status = roaming
{NetworkRegistration} [/quectelqmi_0] LocationAreaCode = 65534
{NetworkRegistration} [/quectelqmi_0] CellId = 26710796
{NetworkOperator} [/quectelqmi_0/operator/24001] Status = current
{NetworkRegistration} [/quectelqmi_0] Name = 24001
{NetworkRegistration} [/quectelqmi_0] MobileCountryCode = 240
{NetworkRegistration} [/quectelqmi_0] MobileNetworkCode = 01
{NetworkRegistration} [/quectelqmi_0] Status = registered
{NetworkRegistration} [/quectelqmi_0] Name = Orange F
{NetworkOperator} [/quectelqmi_0/operator/24001] Name = TELIA
{NetworkRegistration} [/quectelqmi_0] Strength = 20
{NetworkRegistration} [/quectelqmi_0] Name = Orange F
{NetworkOperator} [/quectelqmi_0/operator/24001] Name = 24001
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
wwp0s20u1i4, Method = static, Address = 10.172.219.235, Netmask =
255.255.255.248, Gateway = 10.172.219.236, DomainNameServers =
194.51.3.56 194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
This actually looks fine. I do wonder what an actual modem roam looks
like, without the technology preference interference.
Here's what connman does effects on the LTE to UMTS transition:
{RadioSettings} [/quectelqmi_0] TechnologyPreference = umts
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
{ConnectionManager} [/quectelqmi_0] Attached = False
So we get detached, okay...
{NetworkRegistration} [/quectelqmi_0] LocationAreaCode = 11
{NetworkRegistration} [/quectelqmi_0] CellId = 752047
{NetworkRegistration} [/quectelqmi_0] Technology = umts
Switch technology
{ConnectionManager} [/quectelqmi_0] Attached = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
wwp0s20u1i4, Method = static, Address = 10.160.218.173, Netmask =
255.255.255.252, Gateway = 10.160.218.174, DomainNameServers =
194.51.3.56 194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
Reattach and get our settings back, so far so good...
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
This part looks bizarre, is the modem deactivating the context for some
reason?
^[[F{ConnectionContext} [/quectelqmi_0/context1] Settings = {
Interface
= wwp0s20u1i4, Method = static, Address = 10.167.137.164, Netmask =
255.255.255.248, Gateway = 10.167.137.165, DomainNameServers =
194.51.3.56 194.51.3.56
{ConnectionContext} [/quectelqmi_0/context1] Active = True
And back to active
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
Back to inactive
> {ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
> wwp0s20u1i4, Method = static, Address = 10.173.100.170, Netmask =
> 255.255.255.252, Gateway = 10.173.100.169, DomainNameServers =
> 194.51.3.56 194.51.3.56 }
> {ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
>
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
> wwp0s20u1i4, Method = static, Address = 10.160.115.172, Netmask =
> 255.255.255.248, Gateway = 10.160.115.173, DomainNameServers =
> 194.51.3.56 194.51.3.56 }
> {ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
>
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
> wwp0s20u1i4, Method = static, Address = 10.167.11.161, Netmask =
> 255.255.255.252, Gateway = 10.167.11.162, DomainNameServers =
> 194.51.3.56 194.51.3.56 }
> {ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
>
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
> wwp0s20u1i4, Method = static, Address = 10.173.65.6, Netmask =
> 255.255.255.252, Gateway = 10.173.65.5, DomainNameServers = 194.51.3.56
> 194.51.3.56 }
> {ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
>
> ....eventually that settles down and the connection is established.
>
I don't get this part actually. ConnMan is only activating the context
right? What is deactivating it?
Regards,
-Denis
3:29 p.m.
On 03/01/2018 05:11 PM, Denis Kenzior wrote:
Hi Jonas,
Hi Denis,
I've spent most of the day trying to make sense of this. I'll send some
new logs when I get a chance but I thought I'd just ask a couple of
questions that popped up during the day:
i) For LTE, does it really make sense for the Attached property to be
set before the context is Active? The two are intricately linked.
ii) For LTE, I'm not sure we should call ofono_gprs_status_notify()
when we are registered to the network. Instead, I suspect we should
just wait until cid_activated() gets called. Is that sufficient? It
looks to be, mostly, in my eyes and didn't break terribly when I tried it.
iii) Looking at src/gprs, couldn't we just set gprs->attached and
gprs->driver_attached right away if we are registered on an LTE network.
It seems that conceptually that would be true...??? If we do that, I
think we can drop most of the _ATTACHING flags which might make the code
easier to understand.
iv) Even if we do iii), I'm inclined to not set the Attached DBUS
property until _cid_activated() returns, and then _after_ context Active
instead of before.
v) If we detach from the network, do things break conceptually if we
set Attached=false before setting context Active=false?
A lot of the above comes from my understanding of what connman is trying
to do: if it sees the state as Attached and has no Active contexts then
it starts trying to activate the first context. Ideally, it would never
see an inactive context for LTE, at least not in the Attached state.
However, I may be missing something in my understanding of how this is
intended to work, so any clarification would be appreciated.
/Jonas
>
> This is an explicit UMTS to LTE transition:
>
> {RadioSettings} [/quectelqmi_0] TechnologyPreference = lte
Okay, so you set the Technology preference and the modem goes into
disconnect and search mode
> {ConnectionManager} [/quectelqmi_0] Attached = False
> {ConnectionContext} [/quectelqmi_0/context1] Settings = {}
> {ConnectionContext} [/quectelqmi_0/context1] Active = False
> {NetworkRegistration} [/quectelqmi_0] Status = searching
So far so good
> {NetworkRegistration} [/quectelqmi_0] Technology = lte
> {NetworkOperator} [/quectelqmi_0/operator/24001] Status = available
> {NetworkRegistration} [/quectelqmi_0] Name =
> {ConnectionManager} [/quectelqmi_0] Attached = True
> {NetworkRegistration} [/quectelqmi_0] Status = roaming
> {NetworkRegistration} [/quectelqmi_0] LocationAreaCode = 65534
> {NetworkRegistration} [/quectelqmi_0] CellId = 26710796
> {NetworkOperator} [/quectelqmi_0/operator/24001] Status = current
> {NetworkRegistration} [/quectelqmi_0] Name = 24001
> {NetworkRegistration} [/quectelqmi_0] MobileCountryCode = 240
> {NetworkRegistration} [/quectelqmi_0] MobileNetworkCode = 01
> {NetworkRegistration} [/quectelqmi_0] Status = registered
> {NetworkRegistration} [/quectelqmi_0] Name = Orange F
> {NetworkOperator} [/quectelqmi_0/operator/24001] Name = TELIA
> {NetworkRegistration} [/quectelqmi_0] Strength = 20
> {NetworkRegistration} [/quectelqmi_0] Name = Orange F
> {NetworkOperator} [/quectelqmi_0/operator/24001] Name = 24001
> {ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
> wwp0s20u1i4, Method = static, Address = 10.172.219.235, Netmask =
> 255.255.255.248, Gateway = 10.172.219.236, DomainNameServers =
> 194.51.3.56 194.51.3.56 }
> {ConnectionContext} [/quectelqmi_0/context1] Active = True
>
This actually looks fine. I do wonder what an actual modem roam looks
like, without the technology preference interference.
>
> Here's what connman does effects on the LTE to UMTS transition:
>
> {RadioSettings} [/quectelqmi_0] TechnologyPreference = umts
> {ConnectionContext} [/quectelqmi_0/context1] Settings = {}
> {ConnectionContext} [/quectelqmi_0/context1] Active = False
> {ConnectionManager} [/quectelqmi_0] Attached = False
So we get detached, okay...
> {NetworkRegistration} [/quectelqmi_0] LocationAreaCode = 11
> {NetworkRegistration} [/quectelqmi_0] CellId = 752047
> {NetworkRegistration} [/quectelqmi_0] Technology = umts
Switch technology
> {ConnectionManager} [/quectelqmi_0] Attached = True
> {ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
> wwp0s20u1i4, Method = static, Address = 10.160.218.173, Netmask =
> 255.255.255.252, Gateway = 10.160.218.174, DomainNameServers =
> 194.51.3.56 194.51.3.56 }
> {ConnectionContext} [/quectelqmi_0/context1] Active = True
Reattach and get our settings back, so far so good...
> {ConnectionContext} [/quectelqmi_0/context1] Settings = {}
> {ConnectionContext} [/quectelqmi_0/context1] Active = False
This part looks bizarre, is the modem deactivating the context for some
reason?
> ^[[F{ConnectionContext} [/quectelqmi_0/context1] Settings = {
> Interface = wwp0s20u1i4, Method = static, Address = 10.167.137.164,
> Netmask = 255.255.255.248, Gateway = 10.167.137.165, DomainNameServers
> = 194.51.3.56 194.51.3.56
> {ConnectionContext} [/quectelqmi_0/context1] Active = True
And back to active
> {ConnectionContext} [/quectelqmi_0/context1] Settings = {}
> {ConnectionContext} [/quectelqmi_0/context1] Active = False
Back to inactive
> {ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
> wwp0s20u1i4, Method = static, Address = 10.173.100.170, Netmask =
> 255.255.255.252, Gateway = 10.173.100.169, DomainNameServers =
> 194.51.3.56 194.51.3.56 }
> {ConnectionContext} [/quectelqmi_0/context1] Active = True
> {ConnectionContext} [/quectelqmi_0/context1] Settings = {}
> {ConnectionContext} [/quectelqmi_0/context1] Active = False
> {ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
> wwp0s20u1i4, Method = static, Address = 10.160.115.172, Netmask =
> 255.255.255.248, Gateway = 10.160.115.173, DomainNameServers =
> 194.51.3.56 194.51.3.56 }
> {ConnectionContext} [/quectelqmi_0/context1] Active = True
> {ConnectionContext} [/quectelqmi_0/context1] Settings = {}
> {ConnectionContext} [/quectelqmi_0/context1] Active = False
> {ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
> wwp0s20u1i4, Method = static, Address = 10.167.11.161, Netmask =
> 255.255.255.252, Gateway = 10.167.11.162, DomainNameServers =
> 194.51.3.56 194.51.3.56 }
> {ConnectionContext} [/quectelqmi_0/context1] Active = True
> {ConnectionContext} [/quectelqmi_0/context1] Settings = {}
> {ConnectionContext} [/quectelqmi_0/context1] Active = False
> {ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
> wwp0s20u1i4, Method = static, Address = 10.173.65.6, Netmask =
> 255.255.255.252, Gateway = 10.173.65.5, DomainNameServers =
> 194.51.3.56 194.51.3.56 }
> {ConnectionContext} [/quectelqmi_0/context1] Active = True
> {ConnectionContext} [/quectelqmi_0/context1] Settings = {}
> {ConnectionContext} [/quectelqmi_0/context1] Active = False
>
> ....eventually that settles down and the connection is established.
>
I don't get this part actually. ConnMan is only activating the context
right? What is deactivating it?
Regards,
-Denis
5:15 p.m.
Hi Jonas,
On 03/02/2018 09:29 AM, Jonas Bonn wrote:
On 03/01/2018 05:11 PM, Denis Kenzior wrote:
> Hi Jonas,
Hi Denis,
I've spent most of the day trying to make sense of this. I'll send some
new logs when I get a chance but I thought I'd just ask a couple of
questions that popped up during the day:
i) For LTE, does it really make sense for the Attached property to be
set before the context is Active? The two are intricately linked.
So in general the API does not guarantee any particular ordering of
messages, and the client should be able to handle any message order. We
make exceptions to this where a particular order makes implementation
easy. For example, ConnectionContext.Settings is signaled prior to
ConnectionContext.Active.
We set Attached mostly not to confuse ConnMan. Since ConnMan doesn't
know about LTE, we tried to preserve the overall behavior.
From an API consistency perspective & conceptually, I think setting
Attached before ConnectionContext.Active makes sense. Having said that,
if there's consensus from the connman guys that signaling Active then
Attached for this particular case, we can make the change...
ii) For LTE, I'm not sure we should call ofono_gprs_status_notify()
when we are registered to the network. Instead, I suspect we should
just wait until cid_activated() gets called. Is that sufficient? It
looks to be, mostly, in my eyes and didn't break terribly when I tried it.
There might be some weirdness in the core around this area actually.
Looking at src/gprs.c it seems like we expect ofono_gprs_cid_activated
to be called prior to ofono_gprs_status_notify. We probably need to
introduce some checks in ofono_gprs_status_notify in case the call order
is switched.
When in LTE this status should be largely ignored anyhow. We can't
'detach' in case we're roaming, so much of the logic doesn't apply.
iii) Looking at src/gprs, couldn't we just set gprs->attached and
gprs->driver_attached right away if we are registered on an LTE network.
It seems that conceptually that would be true...??? If we do that, I
think we can drop most of the _ATTACHING flags which might make the code
easier to understand.
Possibly, though you may be a bit optimistic that any of this can be
made simpler :)
Right now we always set the _ATTACHING flag inside
ofono_gprs_cid_activated. This isn't really correct, we should only do
so on EUTRAN and if this is the default bearer activation (e.g. we think
we're not attached yet). The network can automatically activate
contexts on 3G or even LTE beyond the initial one.
This logic then proceeds to signal Attached=True when .read_settings
returns. There are probably some extra checks we need to put into
pri_read_settings_callback to make sure we only signal Attached on the
initial default bearer activation.
iv) Even if we do iii), I'm inclined to not set the Attached DBUS
property until _cid_activated() returns, and then _after_ context Active
instead of before.
The code already tries to do the first part, e.g. querying the default
bearer settings and then signaling Attached & Active in that order.
v) If we detach from the network, do things break conceptually if we
set Attached=false before setting context Active=false?
Again, conceptually I would say Active=false then Attached=false makes
the most sense.
A lot of the above comes from my understanding of what connman is trying
to do: if it sees the state as Attached and has no Active contexts then
it starts trying to activate the first context. Ideally, it would never
see an inactive context for LTE, at least not in the Attached state.
However, I may be missing something in my understanding of how this is
intended to work, so any clarification would be appreciated.
Or it should give up if it sees the InProgress error, but yes it might
be that re-ordering messages is the right approach. Daniel, Marcel?
Regards,
-Denis
5:49 a.m.
Hi,
On 03/02/2018 06:15 PM, Denis Kenzior wrote:
> A lot of the above comes from my understanding of what connman is
trying
> to do: if it sees the state as Attached and has no Active contexts then
> it starts trying to activate the first context. Ideally, it would never
> see an inactive context for LTE, at least not in the Attached state.
> However, I may be missing something in my understanding of how this is
> intended to work, so any clarification would be appreciated.
Or it should give up if it sees the InProgress error, but yes it might
be that re-ordering messages is the right approach. Daniel, Marcel?
I must admit, I am slightly confused. So we have a different behavior
pattern between UMTS/GSM and LTE networks which expresses itself in the
non ordering of Active and Attached?
Anyway, I don't have anything against ordering the events. Shouldn't be
to hard to update the plugin.
Thanks,
Daniel
1572
days inactive
1582
days old
9 comments
4 participants
participants (4)
-
Christophe Ronco -
Daniel Wagner -
Denis Kenzior -
Jonas Bonn