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: [RFC] wifi: make max connection retries configurable
(Daniel Wagner)
2. Re: [RFC] wifi: make max connection retries configurable
(M?ns Rullg?rd)
3. Re: Session policy with multiple AllowedBearers (Daniel Wagner)
4. Re: [RFC] wifi: make max connection retries configurable
(Daniel Wagner)
5. Re: Crash in connman_session_set_default_config when changing
session policy file (Daniel Wagner)
6. Re: [RFC] wifi: make max connection retries configurable
(M?ns Rullg?rd)
7. Re: [PATCH] conf: Allow to configure status check URLs
(Daniel Wagner)
8. Re: [RFC] wifi: make max connection retries configurable
(Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Sun, 29 Jan 2017 19:28:23 +0100
From: Daniel Wagner <[email protected]>
To: M?ns Rullg?rd <[email protected]>
Cc: [email protected]
Subject: Re: [RFC] wifi: make max connection retries configurable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
>>> 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.
IIRC, the behavior to stay down after two retries is that some AP block
the client permanently if you try two often with the wrong password. At
least that is what I remember from the retry discussion.
> 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.
If I understood you correctly in your configuration you just keep retrying?
> 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.
I think you need to find an way to address also the point I mentioned.
Having such an option in the main.conf is just too confusing in my opinion.
Thanks,
Daniel
------------------------------
Message: 2
Date: Sun, 29 Jan 2017 18:31:58 +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:
>>>> 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.
>
> IIRC, the behavior to stay down after two retries is that some AP
> block the client permanently if you try two often with the wrong
> password. At least that is what I remember from the retry discussion.
Yes, that's a valid reason for limiting the number of retries *by default*.
I a way to remove that limitation.
>> 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.
>
> If I understood you correctly in your configuration you just keep retrying?
Correct. It must do this, or it simply drops offline for ever at some point.
>> 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.
>
> I think you need to find an way to address also the point I mentioned.
The lock-out thing? Don't change the default if that's a concern.
> Having such an option in the main.conf is just too confusing in my
> opinion.
Frankly, I find all of connman too confusing. Feel free to suggest a
better way.
--
M?ns Rullg?rd
------------------------------
Message: 3
Date: Sun, 29 Jan 2017 19:32:05 +0100
From: Daniel Wagner <[email protected]>
To: Daryl Nebrich <[email protected]>
Cc: [email protected]
Subject: Re: Session policy with multiple AllowedBearers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Daryl,
On 01/25/2017 03:27 PM, Daryl Nebrich wrote:
> On Wed, Jan 25, 2017 at 1:45 AM, Daniel Wagner <[email protected]> wrote:
>> On 01/23/2017 03:09 PM, Daryl Nebrich wrote:
>>> @@ -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.
Got it. Thanks for the explanation. I agree, this makes sense. The
original code is buggy. Please make a proper patch out of these two
changes.
>>> @@ -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.
Good and this one is also a patch.
Thanks,
Daniel
------------------------------
Message: 4
Date: Sun, 29 Jan 2017 19:34:50 +0100
From: Daniel Wagner <[email protected]>
To: M?ns Rullg?rd <[email protected]>
Cc: [email protected]
Subject: Re: [RFC] wifi: make max connection retries configurable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
>>> 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.
>>
>> I think you need to find an way to address also the point I mentioned.
>
> The lock-out thing? Don't change the default if that's a concern.
That is not my point.
>> Having such an option in the main.conf is just too confusing in my
>> opinion.
>
> Frankly, I find all of connman too confusing. Feel free to suggest a
> better way.
Exactly, adding another low level option to connman.conf is not helping.
That is why I ask if you find a way to address the lock-out and the
bad-signal-stop-retry thingy without adding a configuration option.
Thanks,
Daniel
------------------------------
Message: 5
Date: Sun, 29 Jan 2017 19:37:14 +0100
From: Daniel Wagner <[email protected]>
To: Daryl Nebrich <[email protected]>, [email protected]
Subject: Re: Crash in connman_session_set_default_config when changing
session policy file
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Daryl,
On 01/25/2017 03:38 PM, Daryl Nebrich wrote:
> Using latest code, there's a crash that happens when I modify a
> session policy file after connman has already started and loaded the
> policy files. Below is the backtrace. I included a patch with a fix.
> Looks like the g_slist config->allowed_bearers needs to be set to NULL
> before it's reused.
Good work!
> Index: connman-9b07d2a/src/session.c
> ===================================================================
> --- connman-9b07d2a.orig/src/session.c 2017-01-22 14:58:49.000000000 -0500
> +++ connman-9b07d2a/src/session.c 2017-01-25 09:12:07.523856388 -0500
> @@ -600,6 +600,7 @@
> config->ecall = FALSE;
>
> g_slist_free(config->allowed_bearers);
> + config->allowed_bearers = NULL;
> add_default_bearer_types(&config->allowed_bearers);
> }
If you can send this as a proper patch (git send-email is your friend)
you would make my life a lot easier :)
Thanks,
Daniel
------------------------------
Message: 6
Date: Sun, 29 Jan 2017 18:38:03 +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:
>>>> 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.
>>>
>>> I think you need to find an way to address also the point I mentioned.
>>
>> The lock-out thing? Don't change the default if that's a concern.
>
> That is not my point.
Then what is your point?
>>> Having such an option in the main.conf is just too confusing in my
>>> opinion.
>>
>> Frankly, I find all of connman too confusing. Feel free to suggest a
>> better way.
>
> Exactly, adding another low level option to connman.conf is not
> helping. That is why I ask if you find a way to address the lock-out
> and the bad-signal-stop-retry thingy without adding a configuration
> option.
How do you propose to divine the real reason for a connection failure?
As far as I can tell, that information simply doesn't exist.
--
M?ns Rullg?rd
------------------------------
Message: 7
Date: Sun, 29 Jan 2017 19:46:55 +0100
From: Daniel Wagner <[email protected]>
To: Marcel Holtmann <[email protected]>
Cc: Slava Monich <[email protected]>, [email protected]
Subject: Re: [PATCH] conf: Allow to configure status check URLs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Marcel,
On 01/25/2017 05:17 PM, Marcel Holtmann wrote:
> Hi Slava,
>
>> The keys in main.conf are "Ipv4StatusUrl" and "Ipv6StatusUrl"
>> for IPv4 and IPv6, respectively.
>> ---
>> doc/connman.conf.5.in | 4 ++++
>> src/6to4.c | 5 ++---
>> src/main.c | 38 ++++++++++++++++++++++++++++++++++++++
>> src/wispr.c | 9 ++++-----
>> 4 files changed, 48 insertions(+), 8 deletions(-)
>>
>> diff --git a/doc/connman.conf.5.in b/doc/connman.conf.5.in
>> index 9b28aad..481e8f2 100644
>> --- a/doc/connman.conf.5.in
>> +++ b/doc/connman.conf.5.in
>> @@ -136,6 +136,10 @@ See RFC6343. Default value is false (as recommended by
>> RFC6343 section 4.1).
>> Set DHCP option 60 (Vendor Class ID) to the given string. This option can
>> be used by DHCP servers to identify specific clients without having to
>> rely on MAC address ranges, etc
>> +.BI Ipv4StatusUrl=url
>> +IPv4 status check URL. Default is http://ipv4.connman.net/online/status.html
>> +.BI Ipv6StatusUrl=url
>> +IPv6 status check URL. Default is http://ipv6.connman.net/online/status.html
>> .SH "EXAMPLE"
>> The following example configuration disables hostname updates and enables
>> ethernet tethering.
>
> my original comments about this can be still found on the mailing
> list. Maybe worth while reading up on.
Are you revering to this?
http://connman.connman.narkive.com/9UUwIG25/connman-online-test
I really don't get it why you insist, that we should not allow changing
the URL? People do it already. Using a different server to ask 'I am
online' is okay in my books. We also allow to set NTP servers.
> However any discussion here without describing what is expected from
> the URL to behave is not even worth considering. If you give the user
> the ability to change it, then they should clearly know what they are
> getting into.
And why not just adding the server code into the ConnMan repository?
What is if the connman.net domain goes down?
Thanks,
Daniel
------------------------------
Message: 8
Date: Sun, 29 Jan 2017 19:54:10 +0100
From: Daniel Wagner <[email protected]>
To: M?ns Rullg?rd <[email protected]>
Cc: [email protected]
Subject: Re: [RFC] wifi: make max connection retries configurable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 01/29/2017 07:38 PM, M?ns Rullg?rd wrote:
>>>>> 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.
>>>>
>>>> I think you need to find an way to address also the point I mentioned.
>>>
>>> The lock-out thing? Don't change the default if that's a concern.
>>
>> That is not my point.
>
> Then what is your point?
I was referring to the default settings.
>>>> Having such an option in the main.conf is just too confusing in my
>>>> opinion.
>>>
>>> Frankly, I find all of connman too confusing. Feel free to suggest a
>>> better way.
>>
>> Exactly, adding another low level option to connman.conf is not
>> helping. That is why I ask if you find a way to address the lock-out
>> and the bad-signal-stop-retry thingy without adding a configuration
>> option.
>
> How do you propose to divine the real reason for a connection failure?
> As far as I can tell, that information simply doesn't exist.
Yes you are right, but changing the default value to infinity is also
not helping. I was just wondering if it would be possible to come up
with an algorithm which tells if it is okay to retry or not using signal
strength and protocol state (e.g. frame sent, no response, timeout)... I
guess something like this doesn't exist.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 15, Issue 36
***************************************
