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] ethernet: Fixed memory leak when adding network
to device fails (Daniel Wagner)
2. Re: When BackgroundScanning = false, connman's Scan() dbus
method is broken (Jose Blanquicet)
----------------------------------------------------------------------
Message: 1
Date: Mon, 25 Sep 2017 20:42:53 +0200
From: Daniel Wagner <[email protected]>
To: Saurav Babu <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [PATCH] ethernet: Fixed memory leak when adding network
to device fails
Message-ID: <[email protected]>
Content-Type: text/plain
Hi Saurav,
Saurav Babu <[email protected]> writes:
> ifname is allocated memory by connman_inet_ifname() but it is never
> freed when function fails to add network to device
>
> Signed-off-by: Saurav Babu <[email protected]>
Patch applied after removing the SoB.
Thanks,
Daniel
------------------------------
Message: 2
Date: Mon, 25 Sep 2017 20:58:22 +0200
From: Jose Blanquicet <[email protected]>
To: Jonah Petri <[email protected]>
Cc: Daniel Wagner <[email protected]>, [email protected]
Subject: Re: When BackgroundScanning = false, connman's Scan() dbus
method is broken
Message-ID:
<CAFC8iJK9hg0qhXmzsvbSPTQWPgf2WmScJ=0qzcsHS_WS=o_...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Jonah,
On Fri, Sep 22, 2017 at 9:17 PM, Jonah Petri <[email protected]> wrote:
> I tested the patch you provided, and it does appear to solve the problem as
> described. I'll promote that patch into my dev fleet, and let you know if I
> notice any other bad behaviors.
>
>
> I tested the patch you posted. While I never saw any dbus-requested scans
> failing, I did notice an increase in the number of my dev units falling
> offline after a reboot.
Sorry, I am not sure I got what you mean here :(. Could you please
rephrase this and give me more details?
> In each case I've tested, as soon as dbus Scan()
> was initiated, the previously associated network was seen and joined. While
> I haven't looked for exactly where, I am guessing that there is some hole in
> the connman startup logic where it needs to request a wpa_s Passive scan as
> well.
I assume you mean that at the start-up you see a D-Bus scan call from
ConnMan to wpa_s and a successive re-connection to a known WiFi
network? If so, yes, that's desired start-up procedure.
> Perhaps it would be best to always follow an active scan with a passive one?
> Or perhaps BackgroundScanning should just be forced to 'true'?
Follow an active scan with only one passive scan in case
BackgroundScanning='false' is indeed the best solution. I thought I
would be able to find time to work on that solution but it haven't
yet, it has not been an ease time. This is the idea I have in mind:
Current behaviour with BackgroundScanning='True' is:
D-Bus scan request or at start-up of system
Launch an active scan
3 seconds -> Launch passive scan
9 seconds -> Launch passive scan
27 seconds -> Launch passive scan
81 seconds -> Launch passive scan
243 seconds -> Launch passive scan
300 seconds -> Launch passive scan
300 seconds -> Launch passive scan
...
Continue each 300 seconds unless you perform a new D-Bus scan call
which will cause the procedure to restart from 3 seconds.
With BackgroundScanning='False' the idea would be:
D-Bus scan request or at start-up of system
Launch an active scan
3 seconds -> Launch passive scan
Stop. No more scanning: 3 seconds would be enough for ConnMan to
reconnect to a known service in case there is one of them in range.
New D-Bus scan request from user
Launch an active scan
3 seconds -> Launch passive scan
Stop.
> It seems that connman may be depending too much on somewhat undocumented
> behaviors of wpa_supplicant and the cfg80211 driver layers, and it's being
> exposed to these bugs.
Unfortunately, yes. wpa_s is the current way to communicate with the
WiFi chip thus we have to deal with it. There are a bunch of things
could have been implemented better in wpa_s. For example, this
scanning logic should be something completely managed by the WiFi
daemon and not by ConnMan.
Best regards,
Jose Blanquicet
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 23, Issue 16
***************************************
