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: Disabling the network on Disconnect Notification
(Naveen Singh)
----------------------------------------------------------------------
Message: 1
Date: Fri, 19 Feb 2016 22:50:59 -0800
From: Naveen Singh <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: Re: Disabling the network on Disconnect Notification
Message-ID:
<CAGTDzK=NmUDw5s_Fw6aV7O5b=pebeeur82rcwtqbynuhuwz...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 18, 2016 at 11:20 PM, Patrik Flykt
<[email protected]> wrote:
>
> Hi,
>
> On Thu, 2016-02-18 at 22:52 -0800, Naveen Singh wrote:
>> Hi All
>> On the disconnect notification from wpa_supplicant (when the interface
>> state becomes G_SUPPLICANT_STATE_DISCONNECTED), connman disables the
>> network (SSID). This is done from interface_state function in
>> plugins/wifi.c:
>>
>> if
>> (g_supplicant_interface_enable_selected_network(interface,
>> FALSE) != 0)
>> DBG("Could not disable selected network");
>>
>> This severely impacts wpa_supplicant's attempt of getting device
>> connected back to WiFi. Lot of enterprise AP now have band steering
>> and/or load balancing enabled as a result of which they keep sending
>> deauth frames to client till it picks the correct BSSID for
>> connection. Now if wpa_supplicant is left alone, it would properly
>> converge to the right BSSID where the association would stick (by
>> blacklisting a BSSID if it does not allow or deny the connection and
>> trying the next one)
>>
>> But now with the very first disconnect notification, connman disables
>> the whole network which ends up disabling the whole SSID and
>> wpa_supplicant does not continue with its connection attempts.
>> Next time when this SSID gets enabled from connman (as a part of next
>> connect), the same story repeats. End result device sometimes never
>> get connected. The above piece of code is impacting L2 level roaming
>> decisions in connman. And I do not think connman has any intention or
>> desire to interfere in any BSSID level roaming decision of
>> wpa_supplicant.
>>
>> Even for the AP which sends deauth with reason code 6/7/4,
>> wpa_supplicant has internal logic to get device connected fast. This
>> also gets impacted quite a bit because of disable logic.
>>
>> Even logs look very confusing at the time of disconnection. You see a
>> successful association (because of wpa_s connection attempt) followed
>> by an internally generated disconnect.
>>
>> I did a test by removing this code and following are the events that
>> happened on receiving deauth:
>>
>> 1) Client receives deauth frame (reason code 15)
>> 2) wpa_supplicant blacklists the current AP and schedule a scan.
>> 3) It generates disconnect notification to connman
>
> At this point a properly designed API would not tell that the network
> disconnected, as it obviously is looking for another AP to connect to.
> wpa_supplicant does not have the worlds greatest API design in place as
> we've seen with other patches in the recent past...
>
I had a discussion with Jouni on this and he agreed in principle that
we need two API. Once when the initial connection is lost and second
when wpa_supplicant has tried connecting with all the known BSSID. But
the problem is that wpa_supplicant will never stop try connecting it.
If all the known BSSID are blacklisted and still device cannot get
connected, wpa_s will clear the blacklist and try again. So there is
no way we can say when to generate the second event.
One of the proposal that came out from that discussion was to not
immediately handle the disconnect notification from wpa_s. Delay it by
say 20 sec, and if the connected event happens before the timer expiry
cancel the timer and do nothing but if nothing happens for 20 sec,
make the state disconnected. But in my view it is not correct to do
first because for that 20 sec data path is still ON (as application is
not notified) even if there is no L2 level connection. Also I am not
sure what should be the proper value for timeout.
>> 4) Connman released its current IP.
>> 5) wpa_supplicant gets the scan result and finds all the AP
>> advertising the same SSID.
>> 6) It proceeds with the connection with next BSSID.
>> 7) It connects back with this BSSID
>> 8) Connman gets device the IP address
>>
>> If deauth is received with reason code 6 or 7 or 4 then there is even
>> no scan and device gets connected real fast.
>>
>> Let me know your thoughts on this. I will send my patch soon
>
> ConnMan can implement the workaround not to drop the connection when it
> is obvious that wpa_supplicant will be looking for another AP to connect
> to. Then again we don't want ConnMan to be stuck with connecting
> forever, either.
I think the only change my patch would do is to not disable the
network. Everything still would be handled the same way. As far as
connman is concerned the state is disconnected and it has even
released the IP address. On the next connection connman immediately
proceeds with DHCP REQ (asking for same IP). And I think
conservatively speaking it is probably a good thing to get a new IP
address than sitting on the old IP address (Some user may have two AP
in their house broadcasting same SSID but both of them are acting as a
DHCP server).
>
> Please propose a fix.
We are testing the fix in-house and i will post my patch soon
>
> Cheers,
>
> Patrik
>
Thanks for going through this long an email. Appreciate your input.
Regards
Naveen
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 4, Issue 25
**************************************
