Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: Ofono LTE modems and connman services (Jonas Bonn)
2. [PATCH] fixed Connect OperationAborted if it was issued
during some moment of autoscan (Vasyl Vavrychuk)
3. [PATCH] reduce noisy error when we try to provision hidden
service from config file (Vasyl Vavrychuk)
4. Re: Ofono LTE modems and connman services (Denis Kenzior)
----------------------------------------------------------------------
Message: 1
Date: Fri, 2 Mar 2018 16:29:25 +0100
From: Jonas Bonn <[email protected]>
To: Denis Kenzior <[email protected]>, [email protected],
"[email protected]" <[email protected]>
Subject: Re: Ofono LTE modems and connman services
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
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
------------------------------
Message: 2
Date: Fri, 2 Mar 2018 17:58:28 +0200
From: Vasyl Vavrychuk <[email protected]>
To: Daniel Wagner <[email protected]>, [email protected]
Subject: [PATCH] fixed Connect OperationAborted if it was issued
during some moment of autoscan
Message-ID: <[email protected]>
Suppose there is Wi-Fi network X that is saved in connman. Consider
the following scenario:
1. Autoscan is started by connman.
2. Network X will be marked as unavailable as result of
connman_device_set_scanning(true).
3. Application issue connect to network X.
4. Connect to X starts and
interface_state(G_SUPPLICANT_STATE_AUTHENTICATING) is received.
5. As result of this stop_autoscan >
connman_device_set_scanning(false) > __connman_device_cleanup_networks
is issued that free_network X because it was marked as unavailable.
6. It leads to network_remove > __connman_service_remove_from_network
> connman_service_unref_debug > __connman_service_disconnect > ...
reply_pending(ECONNABORTED)
---
src/device.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/device.c b/src/device.c
index 7c212c10..5d343ae8 100644
--- a/src/device.c
+++ b/src/device.c
@@ -706,7 +706,8 @@ static gboolean remove_unavailable_network(gpointer key,
gpointer value,
{
struct connman_network *network = value;
- if (connman_network_get_connected(network))
+ if (connman_network_get_connected(network) ||
+ connman_network_get_connecting(network))
return FALSE;
if (connman_network_get_available(network))
--
2.11.0
------------------------------
Message: 3
Date: Fri, 2 Mar 2018 17:58:59 +0200
From: Vasyl Vavrychuk <[email protected]>
To: Daniel Wagner <[email protected]>, [email protected]
Subject: [PATCH] reduce noisy error when we try to provision hidden
service from config file
Message-ID: <[email protected]>
Before this change upon every scan of the hidden service we got
"Network SSID not set" error in logs. This is because hidden services
have no WiFi.SSID set.
Changed function is try_provision_service from config file and of course
we can not do this for hidden services without SSID so we can report
ENOENT for them.
---
src/config.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/config.c b/src/config.c
index 1f1ba11b..4178ea86 100644
--- a/src/config.c
+++ b/src/config.c
@@ -1218,10 +1218,8 @@ static int try_provision_service(struct
connman_config_service *config,
ssid = connman_network_get_blob(network, "WiFi.SSID",
&ssid_len);
- if (!ssid) {
- connman_error("Network SSID not set");
- return -EINVAL;
- }
+ if (!ssid)
+ return -ENOENT;
if (!config->ssid || ssid_len != config->ssid_len)
return -ENOENT;
--
2.11.0
------------------------------
Message: 4
Date: Fri, 2 Mar 2018 11:15:07 -0600
From: Denis Kenzior <[email protected]>
To: Jonas Bonn <[email protected]>, [email protected],
"[email protected]" <[email protected]>, Daniel Wagner
<[email protected]>, Marcel Holtmann <[email protected]>
Subject: Re: Ofono LTE modems and connman services
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
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
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 29, Issue 3
**************************************
