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: [PATCH 1/2] wifi: Fix behaviour when Background scanning
is disabled (Daniel Wagner)
2. Re: BUG: file descriptor leak in DHCPv6 (Daniel Wagner)
3. Re: [PATCH 0/3] Add options to configure Online check
(Daniel Wagner)
4. Re: Predefined hostname in dhcp requests (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Sun, 26 Nov 2017 20:35:35 +0100
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Cc: [email protected]
Subject: Re: [PATCH 1/2] wifi: Fix behaviour when Background scanning
is disabled
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jose,
On 10/09/2017 02:33 AM, [email protected] wrote:
> From: Jose Blanquicet <[email protected]>
>
> Conditions when ConnMan will perform active instead of passive scanning:
> 1. WiFi Driver support active scanning, it means "MaxScanSSID" is
> greater than 1.
> 2. User has successfully connected to at least one WiFi network in the
> past so the service information is present in
> {STOREDIR}/connman/wifi_* but none of those networks are currently in
> range. They will be called "known-services" from now.
>
> Current behaviour when BackgroundScanning is enabled:
> - D-Bus scan request or at start-up of system -> Launch an
> active/passive scan (Based on above conditions)
> - 3 seconds -> Launch passive scan
> - 9 seconds -> Launch passive scan
> - ...
> - 243 seconds -> Launch passive scan
> - 300 seconds -> Launch passive scan
> - Continue each 300 seconds unless user performs a new D-Bus scan call
> which will cause the procedure to restart from 3 seconds.
>
> This patch does not change the ConnMan's behaviour when
> BackgroundScanning is enabled. However, when it is disabled and
> conditions for active scanning are true, ConnMan could fall in the
> following situation:
> - D-Bus scan request or at start-up of system -> Launch an active scan
> - Stop scanning
>
> One single scan is done and it is an active one. It means that ConnMan
> will perform an active scan looking for those known-services in their
> specific frequencies, this kind of scanning is generally faster than a
> passive one which allows to speed up auto-connection procedure.
> However, we have seen that in case of none of these knwon-services is in
> range some drivers reply only with all the networks in the specified
> frequencies and some other does not reply any network. This could result
> in an always empty services list.
>
> Therefore, this patch looks for avoid such situation by adding a passive
> scan in such cases. The new behaviour is also based on the conditions
> mentioned at the beginning:
> 1. Active scanning:
> - D-Bus scan request or at start-up of system -> Launch an active scan
> - 3 seconds -> Launch passive scan
> - Stop scanning
> - New D-Bus scan request from user -> Launch an active scan
> - 3 seconds -> Launch passive scan
> - Stop scanning
>
> 2. Passive scanning:
> - D-Bus scan request or at start-up of system -> Launch one passive scan
> - Stop scanning
> - New D-Bus scan request from user -> Launch one passive scan
> - Stop scanning
>
> Take into account that all the behaviours described above are followed
> when wifi has not get connected. Once it is connected, ConnMan stops its
> background scanning procedure and if BackgroundScanning is enabled, it
> asks wpa_supplicant to perform the background scanning while connected
> only for wifi roaming purposes. See "wpa_supplicant configuration"
> section in README file for further details.
Both patches applied.
Thanks,
Daniel
------------------------------
Message: 2
Date: Sun, 26 Nov 2017 20:39:48 +0100
From: Daniel Wagner <[email protected]>
To: Richard Genoud <[email protected]>
Cc: [email protected]
Subject: Re: BUG: file descriptor leak in DHCPv6
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Richard,
>> Anyway, I'll send a patch which fixes at a leak in the stats file. Can
>> you check if you still see the leak?
>
> Unfortunately, I still see an FD leak with this patch applied.
I can't reproduce with my setup. So the patch is fixing the leak I see
but not the one you observe. Or did it get slightly better (less fd leaks)?
Do you have an IPv6 enable network? Currently mine setup lacks it.
Thanks,
Daniel
------------------------------
Message: 3
Date: Sun, 26 Nov 2017 20:47:35 +0100
From: Daniel Wagner <[email protected]>
To: Christophe Ronco <[email protected]>
Cc: [email protected], 'Marcel Holtmann' <[email protected]>
Subject: Re: [PATCH 0/3] Add options to configure Online check
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Christophe,
On 11/13/2017 09:24 AM, Christophe Ronco wrote:
> On 11/12/2017 10:20 AM, Daniel Wagner wrote:
>> See https://www.mail-archive.com/[email protected]/msg18104.html
> OK, sorry to have not found that before posting.
>
> I won't bother you explaining my specific case and add my patches.
Maybe I got it wrong. You wrote "The goal is to have this feature for
boards that do not have access to Internet." So I wonder why the
configure --disable-wispr and EnableOnlineCheck=false connman.conf
shouldn't do the trick.
Thanks,
Daniel
------------------------------
Message: 4
Date: Sun, 26 Nov 2017 21:02:56 +0100
From: Daniel Wagner <[email protected]>
To: Marco Gigante <[email protected]>
Cc: [email protected]
Subject: Re: Predefined hostname in dhcp requests
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Marco
On 11/17/2017 10:13 AM, Marco Gigante wrote:
>> Yes, of course. Having some patches (even though they might just be a
>> prove of concept) are usually much better to understand and to discuss.
>
> Going to send the patch.
I looked at the patch and basically is the thing I would like to avoid.
Adding random option is not going to scale.
> My need was to set the hostname to a well known value. My system boots
> with, lets say, 'host-factory' hostname and during its running time the
> hostname may become 'host-id', where id is a host identifier locally
> defined.
Right, that is something very generic so far.
> Also the end-user can manually change the hostname from system
> gui and restart the network, hence connman.
That is your approach to solve the problem. If your GUI apps updates the
hostname, ConnMan could see the change and should the right thing... If
I am not completely mistaken ConnMan would send a new DHCPREQUEST with
the new hostname to update the DNS server.
I really would like to avoid to have two places where you configure the
hostname.
> The problem is that the dhcp request can contain either 'host-factory'
> or 'host-id' depending upon who runs first between connman dhcp client
> and id negotiator component or end-user actions.
Hmm, somehow this sounds a bit racy :)
After a bit of pondering I think we should try the monitor approach
first and see if this works or not.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 25, Issue 14
***************************************
