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] p2p: 'scan p2p' causes stop autoscan even after
scan p2p finishes (Daniel Wagner)
2. Re: [Question]: Scan schedule (Daniel Wagner)
3. Re: [PATCH 2/2] connection: Check for active flag when
updating default gateway (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Mon, 3 Sep 2018 08:00:06 +0200
From: Daniel Wagner <[email protected]>
To: Vasyl Vavrychuk <[email protected]>, [email protected]
Cc: Vasyl Vavrychuk <[email protected]>
Subject: Re: [PATCH] p2p: 'scan p2p' causes stop autoscan even after
scan p2p finishes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Vasyl,
On 08/29/2018 10:52 PM, Vasyl Vavrychuk wrote:
> From: Vasyl Vavrychuk <[email protected]>
>
> When we start p2p scan we reset Wi-Fi autoscan, i.e. autoscan timer is
> stopped but Wi-Fi scanning status is not touched.
>
> This is probably due to we get Wi-Fi scanning during P2P find implicitly.
> This fact was veryfied using wpa_cli.
>
> But when p2p scan stops in p2p_find_stop function we did not reverted our
> action but did reset Wi-Fi autoscan again for some reason.
Thanks a lot for taking the time to write commit message. Much better :)
> ---
> plugins/wifi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/plugins/wifi.c b/plugins/wifi.c
> index fa8d0bf..6be23a4 100644
> --- a/plugins/wifi.c
> +++ b/plugins/wifi.c
> @@ -1782,7 +1782,7 @@ static void p2p_find_stop(struct wifi_data *wifi)
> connman_device_set_scanning(wifi->device, CONNMAN_SERVICE_TYPE_P2P,
> false);
>
> connman_device_unref(wifi->device);
> - reset_autoscan(wifi->device);
> + start_autoscan(wifi->device);
This looks like a diff against a different version. Upstream just used
'device' and not 'wifi->device'. I adapter this patch to match upstream.
Please check if I wrecked it.
Patch applied.
Thanks,
Daniel
------------------------------
Message: 2
Date: Mon, 3 Sep 2018 08:13:25 +0200
From: Daniel Wagner <[email protected]>
To: M?ns Zigher <[email protected]>
Cc: [email protected], Julien Massot <[email protected]>
Subject: Re: [Question]: Scan schedule
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
On 08/31/2018 07:00 AM, M?ns Zigher wrote:
> According to the comments for?BackgroundScanning
>
> # Enable background scanning. Default is true.
> # Background scanning will start every 5 minutes unless
> # the scan list is empty. In that case, a simple backoff
> # mechanism starting from 10s up to 5 minutes will run.
>
> I would assume that connman should detect when the list is empty and
> trigger a scan but what we are experiencing is that it will only trigger
> a scan every 5 minute no mater if the list is empty or not. Is this how
> it is intended?
This sounds like a bug.
As Julien explained, the code for stearing the scan behavior of
wpa_supplicant is ugly and really complex. It's a constant source of pain.
I see that whenever ssid_init() is called it will overwrite the
setting from setup_autoscan().
static void setup_autoscan(struct wifi_data *wifi)
{
/*
* If BackgroundScanning is enabled, setup exponential
* autoscanning if it has not been previously done.
*/
if (connman_setting_get_bool("BackgroundScanning")) {
wifi->autoscan = parse_autoscan_params(AUTOSCAN_EXPONENTIAL);
return;
}
[...]
}
static void ssid_init(GSupplicantSSID *ssid, struct connman_network
*network)
{
[...]
if (connman_setting_get_bool("BackgroundScanning"))
ssid->bgscan = BGSCAN_DEFAULT;
[...]
}
The ssid_init() was added by 631bcaaed684 ("wifi: Add support for
default background scanning parameters"). Not sure if that bit is still
relevant after many changes we had for scanning. This needs some proper
testing: Can you ssid_init() overwrites the exponential settings?
Thanks,
Daniel
------------------------------
Message: 3
Date: Mon, 3 Sep 2018 08:19:50 +0200
From: Daniel Wagner <[email protected]>
To: Jussi Laakkonen <[email protected]>, [email protected]
Subject: Re: [PATCH 2/2] connection: Check for active flag when
updating default gateway
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jussi,
On 08/31/2018 01:35 PM, Jussi Laakkonen wrote:
> Set default gateway if it has been updated or if it has not been set as
> active yet.
>
> The check for active interface is required in cases that are induced by
> a race condition caused by a change of interfaces that are either too
> fast or too slow to go down, or to get up. In such case the interface
> that should be used as default gateway may end up with no default route
> set in routing table.
>
> This is because the change happens in a situation where the old default
> service A going down is still online, when the new service B that is
> becoming the new default, is still in ready state. The new default
> service B is not detected as default gateway because of the service list
> order. The new service B has been added to gateway_hash and the routes
> other than the default route have been set into routing table.
>
> After this the routes of the old default service A are removed but
> because of the old default service A still being the default service
> according to service list, the removal of routes of the old default
> service A does not get the new default gateway B to be selected as the
> default gateway. After this the old default service A is properly
> disconnected and set to idle setting the new default service B as the
> default service.
>
> The next call to this update gateway function results in a situation where
> updated flag is not set, hence new default service B is the only one in
> the gateway_hash. By checking also the active flag of the gateway the
> new default gateway B in the scenario above will have a default route
> set also in routing table.
Both patches applied. Thanks for the really helpful commit message.
Excellent work!
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 35, Issue 1
**************************************
