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: HTTP GET usage for Ready to Online state transition
(Daniel Wagner)
2. Re: [RFC] wifi: make max connection retries configurable
(Daniel Wagner)
3. Re: Query regarding cellular data connection with connman via
ofono (Daniel Wagner)
4. Re: HTTP GET usage for Ready to Online state transition
(Andr? Draszik)
5. Re: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment (Shrikant Bobade)
6. Re: [RFC] wifi: make max connection retries configurable
(M?ns Rullg?rd)
7. Re: Session policy with multiple AllowedBearers (Daryl Nebrich)
----------------------------------------------------------------------
Message: 1
Date: Wed, 25 Jan 2017 07:52:21 +0100
From: Daniel Wagner <[email protected]>
To: Marcel Holtmann <[email protected]>
Cc: Lukasz Nowak <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: HTTP GET usage for Ready to Online state transition
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Marcel,
On 01/24/2017 12:00 PM, Lukasz Nowak wrote:
> On 24/01/17 10:40, Marcel Holtmann wrote:
>> what is wrong with --disable-wispr configure switch? After that everything
>> goes via the agent.
>
> I have --disable-wispr defined. That only disables tools/wispr.c.
> The src/wispr.c is always compiled and it always makes the HTTP GET call to
> the hard-coded URL to transition any service to Online state.
I agree with Lukasz and Slava here. We also allow people to define their
own NTP server. And now the mer folks need to carry around their onw
patches. I am pretty sure there a plenty of other products out there
which have the exact same patch applied.
So I am for getting the patch applied Slave pointed to.
Thanks,
Daniel
------------------------------
Message: 2
Date: Wed, 25 Jan 2017 09:30:44 +0100
From: Daniel Wagner <[email protected]>
To: Mans Rullgard <[email protected]>, [email protected]
Subject: Re: [RFC] wifi: make max connection retries configurable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Mans,
On 01/24/2017 02:28 PM, Mans Rullgard wrote:
> If when connecting to a wifi network, the authentication phase fails,
> connman draws the conclusion that the wifi password was wrong. This is a
> correct conclusion when wifi reception is good, but this can also occur
> on marginal wifi reception.
Could we teach ConnMan to behave differently depending on RSSI or any
input which indicates bad reception, e.g. the time for transaction? I
mean what helps you if you change from 2 to 10 and you got a good signal
strength?
Thanks,
Daniel
------------------------------
Message: 3
Date: Wed, 25 Jan 2017 09:33:53 +0100
From: Daniel Wagner <[email protected]>
To: Naveen Kumar Danturi <[email protected]>
Cc: Daryl Nebrich <[email protected]>, [email protected]
Subject: Re: Query regarding cellular data connection with connman via
ofono
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Naveen,
On 01/24/2017 11:52 PM, Naveen Kumar Danturi wrote:
> Actually we have just a cellular connection. So this means connman
> itself cannot update routing tables?
No, ConnMan maintains the routing table for you. It sounds like you
running into the same problem as Daryl describes. There seems to be
hickup if oFono doesn't let ConnMan know what the default gateway is.
Thanks,
Daniel
------------------------------
Message: 4
Date: Wed, 25 Jan 2017 09:06:24 +0000
From: Andr? Draszik <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: HTTP GET usage for Ready to Online state transition
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Wed, 2017-01-25 at 07:52 +0100, Daniel Wagner wrote:
> Hi Marcel,
>
> On 01/24/2017 12:00 PM, Lukasz Nowak wrote:
> > On 24/01/17 10:40, Marcel Holtmann wrote:
> > > what is wrong with --disable-wispr configure switch? After that
> > > everything goes via the agent.
> >
> > I have --disable-wispr defined. That only disables tools/wispr.c.
> > The??src/wispr.c is always compiled and it always makes the HTTP GET
> > call to
> > the hard-coded URL to transition any service to Online state.
>
> I agree with Lukasz and Slava here. We also allow people to define their?
> own NTP server. And now the mer folks need to carry around their onw?
> patches. I am pretty sure there a plenty of other products out there?
> which have the exact same patch applied.
Yes, OSMC adjusts this as well:
https://github.com/osmc/osmc/blob/master/package/connman-osmc/patches/all-001-online-connectivity-via-dolon.patch
Cheers,
Andre'
------------------------------
Message: 5
Date: Wed, 25 Jan 2017 15:15:08 +0530
From: Shrikant Bobade <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment
Message-ID:
<calwqerohb917v3w+ecv_fb6sqqp9jqclyyxvrj8g7ftqu4x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Mon, Jan 23, 2017 at 12:34 AM, Daniel Wagner <[email protected]> wrote:
>>
>> observed during regression, there was no further hang using
>> GNUTLS_NO_EXPLICIT_INIT=1,
>> using it resolves the issue.
>
>
> Excellent. Okay, now we know what happens. I'll add it to my todo list to
fix those urandom users in ConnMan and also the documentation needs to be
updated.
Great Thanks !
- Shrikant
>
> Thanks,
> Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20170125/69061f42/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 25 Jan 2017 11:19:52 +0000
From: M?ns Rullg?rd <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [RFC] wifi: make max connection retries configurable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Daniel Wagner <[email protected]> writes:
> Hi Mans,
>
> On 01/24/2017 02:28 PM, Mans Rullgard wrote:
>> If when connecting to a wifi network, the authentication phase fails,
>> connman draws the conclusion that the wifi password was wrong. This is a
>> correct conclusion when wifi reception is good, but this can also occur
>> on marginal wifi reception.
>
> Could we teach ConnMan to behave differently depending on RSSI or any
> input which indicates bad reception, e.g. the time for transaction? I
> mean what helps you if you change from 2 to 10 and you got a good signal
> strength?
The issue that prompted this was a bad signal causing it to give up
connecting and stay down for ever. Removing the retry limit makes it
work as well as can be expected in that situation, i.e. it connects
often enough to do what it's supposed to do.
Now that's my reason for adding this setting. I can certainly imagine
it being useful to someone else for different reasons. Is this somehow
a bad idea? There is no change in behaviour unless users explicitly
set a non-default value.
--
M?ns Rullg?rd
------------------------------
Message: 7
Date: Wed, 25 Jan 2017 09:27:28 -0500
From: Daryl Nebrich <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected], Lukasz Nowak <[email protected]>
Subject: Re: Session policy with multiple AllowedBearers
Message-ID:
<canmghyvdhsynrpdp9v46cdyvszjoybfejxibzrd1xkvcr1q...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
HI Daniel,
On Wed, Jan 25, 2017 at 1:45 AM, Daniel Wagner <[email protected]> wrote:
> Hi Daryl
>
> On 01/23/2017 03:09 PM, Daryl Nebrich wrote:
>>
>> I've upgraded to the tip and attached log files for before and after my
>> patches.
>>
>> Patch 1 - I'm using ofono to create a PPP data connection. There's no
>> gateway reported by ofono in this case. So extract_ipv4_settings() in
>> plugins/ofono.c leaves gateway as null. Later,
>> session.c:add_default_route() fails. The patch I did was to default
>> the gateway to "0.0.0.0" in plugins/ofono.c. Not sure if the fix
>> should be there or in add_default_route().
>>
>> Index: connman-9b07d2a/plugins/ofono.c
>> ===================================================================
>> --- connman-9b07d2a.orig/plugins/ofono.c 2017-01-22 14:58:49.000000000
>> -0500
>> +++ connman-9b07d2a/plugins/ofono.c 2017-01-22 22:11:36.127307372 -0500
>> @@ -888,6 +888,11 @@
>> goto out;
>> }
>>
>> + /* Gateway not always returned by ofono. add_default_route()
>> fails if left as null. */
>> + if (!gateway) {
>> + gateway = g_strdup("0.0.0.0");
>> + }
>> +
>> connman_ipaddress_set_ipv4(context->ipv4_address, address,
>> netmask, gateway);
>>
>>
>> I attached 2 log files showing before and after. For log 1, line 122
>> shows no gateway in ofono.c and line 192 is the add_default_route()
>> error. Log 2 has the fix with line 172 showing successful
>> add_default_route().
>
>
> This sounds quite similarto the patch from Lukasz:
>
> [PATCH v2 1/7] session: fix default route for ppp services
>
> Lukasz addressed this in the session code which is more generic.
Ok, great. I'll look at that.
>
>> Patch 2 - Reorder AllowedBearers from the policy file and add
>> session_activate() to handle_service_state_offline().
>>
>> Index: connman-9b07d2a/src/session.c
>> ===================================================================
>> --- connman-9b07d2a.orig/src/session.c 2017-01-22 19:33:18.903307372
>> -0500
>> +++ connman-9b07d2a/src/session.c 2017-01-22 19:33:18.955307372 -0500
>> @@ -685,18 +685,18 @@
>> return 0;
>> }
>>
>> -static void filter_bearer(GSList *policy_bearers,
>> - enum connman_service_type bearer,
>> +static void filter_bearer(GSList *bearers,
>> + enum connman_service_type policy,
>> GSList **list)
>> {
>> - enum connman_service_type policy;
>> + enum connman_service_type bearer;
>> GSList *it;
>>
>> - if (!policy_bearers)
>> + if (!bearers)
>> return;
>>
>> - for (it = policy_bearers; it; it = it->next) {
>> - policy = GPOINTER_TO_INT(it->data);
>> + for (it = bearers; it; it = it->next) {
>> + bearer = GPOINTER_TO_INT(it->data);
>>
>> if (policy != bearer)
>> continue;
>
>
> This is just renaming here, right?
Yes, it looks worse than it is. I just renamed the variables since
the first for loop goes through policy bearers and the 2nd one in
filter_bearer goes through available bearers.
>
>> @@ -709,15 +709,15 @@
>> static void apply_policy_on_bearers(GSList *policy_bearers, GSList
>> *bearers,
>> GSList **list)
>> {
>> - enum connman_service_type bearer;
>> + enum connman_service_type policy_bearer;
>> GSList *it;
>>
>> *list = NULL;
>>
>> - for (it = bearers; it; it = it->next) {
>> - bearer = GPOINTER_TO_INT(it->data);
>> + for (it = policy_bearers; it; it = it->next) {
>> + policy_bearer = GPOINTER_TO_INT(it->data);
>>
>> - filter_bearer(policy_bearers, bearer, list);
>> + filter_bearer(bearers, policy_bearer, list);
>> }
>> }
>>
>
> And here you swap the order of arguments to filter_bearer. Hmm, need to
> ponder on what that means. I am rather careful here because I took quite a
> while to come up with a somewhat understandable solution.
>
Ok. My intent here is just to maintain the order in the session
policy file. For my example -
Policy file has "AllowedBearers = cellular wifi" which is loaded in
that order in policy_bearers.
Available bearers has order "wifi cellular"
Before my change apply_policy_on_bearers looped through available
bearers first. First one is wifi, then filter_bearer is called which
loops through policy bearers, finds wifi, and add it to the
config->allowed_bearers first.
End result is the order in policy file isn't preserved. You get "wifi
cellular" in config->allowed_bearers instead of "cellular wifi" which
is order in session policy file.
>> @@ -1548,15 +1548,24 @@
>> {
>> enum connman_service_type bearer_type;
>> enum connman_service_type service_type;
>> + enum connman_service_type current_service_type;
>> GSList *list;
>>
>> if (policy && policy->allowed)
>> return policy->allowed(session, service);
>>
>> + /* Handle multiple bearers and priorities in session policy. */
>> + current_service_type = connman_service_get_type(session->service);
>> +
>> for (list = session->info->config.allowed_bearers; list; list =
>> list->next) {
>> bearer_type = GPOINTER_TO_INT(list->data);
>> service_type = connman_service_get_type(service);
>>
>> + /* Keep using current service if higher priority. */
>> + if (bearer_type == current_service_type) {
>> + return false;
>> + }
>> +
>
>
> This part looks good. Let me think about about the above changes and what it
> means.
>
>> if (bearer_type == service_type)
>> return true;
>> }
>> @@ -1688,6 +1697,9 @@
>>
>> session->service = NULL;
>> update_session_state(session);
>> +
>> + /* Check if another allowed bearer is available. */
>> + session_activate(session);
>> }
>
>
> This is the second bug you were talking about, right?
>
Yes, this change is to have the session check for a new service when
one goes offline. In my case, I manually disconnected cellular and
expected it to switch to wifi as both are part of AllowedBearers in
session policy file.
>> }
>>
>> One question I have with the above patch is if the connected status of
>> the current session service should be checked. Perhaps by calling
>> __connman_service_get_state to see if in online/ready state. Or if
>> it's enough for there to be a current session->service. In my
>> original patch earlier in the thread I called
>> __connman_service_is_connected_state. With that function you have to
>> specify IPV4/IPV6. Not sure of best way to handle that.
>
>
> So one standing problem is, that ConnMan does not do periodic online
> checkes. Currently, it is only a one shot thing. Patrik argues that doing it
> periodically is opening pandoras' box. Well I think we need to do that
> eventually. You are not the first running into the exact problem.
>
>> I attached 2 more log files (log 3 and 4) for before and after. Three
>> policies show up in the logs, conn1.policy is the one with
>> AllowedBearers = cellular wifi. The initial state is the session
>> using ppp0, I then disconnect cellular using connmanctl to test switch
>> to wifi. Log 3 shows handle_service_state_offline() on line 100 and
>> then wifi type busy on line 178. It doesn't switch to wifi. I then
>> add the patch above and log 4 shows successful switch. Line 164 is
>> handle_service_state_offline() and session_activate() is called on
>> line 181.
>
>
> Unfortunately, I need to run again. Overall this looks like the right
> direction.
>
>> Let me know. I've also got another patch for specifying the cell APN
>> in the config file and passing it to the ofono plugin which then uses
>> set_property to update the ofono context. But I'll start a separate
>> thread on that.
>
>
> Cool, please post your patches into a nice series with proper commit message
> etc.
>
> Thanks,
> Daniel
Thanks,
Daryl
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 15, Issue 28
***************************************
