On 2/22/16, 12:18 AM, "connman on behalf of Patrik Flykt"
<connman-bounces(a)lists.01.org on behalf of Patrik.Flykt(a)linux.intel.com>
On Fri, 2016-02-19 at 22:50 -0800, Naveen Singh wrote:
> On Thu, Feb 18, 2016 at 11:20 PM, Patrik Flykt
> <Patrik.Flykt(a)linux.intel.com> 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
> >> state becomes G_SUPPLICANT_STATE_DISCONNECTED), connman disables the
> >> network (SSID). This is done from interface_state function in
> >> plugins/wifi.c:
> >> if
> >> FALSE) != 0)
> >> DBG("Could not disable selected
> >> 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
> > 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.
This is fixed by having wpa_supplicant getting its act together and
informing any client of a disconnected network once the list of known
BSSIDs has been tried once. No earlier and no later. The client, in this
case ConnMan, is not supposed to know more of the network details than
A couple of concerns:
1) When trying to reconnect to a troubled ESS containing many BSS - won¹t
we be held back for a variable amount of time without being notified of a
loss of connectivity?
2) It feels like a step in the wrong direction to suppress already
existing signaling information from supplicant. More information about
what is happening gives a connection/network manager more flexibility in
deciding how to react. (though maybe this signaling needs to become even
more verbose by adding reason codes, etc)
supplicant may know more about the details of the current ESS, but Connman
has potentially more valuable information: additional configured Wi-Fi
networks, technologies, sessions, user preferences, and is ideally suited
to make service transition decisions. There may be cases where it is
better to fall back to WWAN or an alternate WLAN network at the first sign
of trouble or cases where it is better to give a service a recovery grace
period. (I¹m reminded of QCOM's Connectivity Engine/CnE work from few
years back as an example how complex the decision to transition between
WLAN and WWAN has become on some smartphones.)
> 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.
This is a solution that won't work. It leaves ConnMan without WiFi
connectivity for 20s after going out of range or loosing the connection
otherwise. So one has to wait 20s for a reconnection when going out of
range from one's home WiFi? Why was this even proposed in the first
My interpretation of the suggestion is that it gives supplicant a chance
to recover more quickly on its own given that it only knows of one
configured network at a time - the suggestion makes more sense to me if
you assume there are no other technologies to fall back on. I agree 20
seconds isn¹t ideal for a mobile device or maybe any device with a WWAN
capability, but it might be fine for an in-home/stationary device with a
few configured Wi-Fi services. A device with a single configured Wi-Fi
service might be best served by doing nothing and letting supplicant try
to connect to its Connman provided network forever.
The best answer may lie somewhere between unconditionally disabling the
service (as done today), and giving supplicant a long grace period to
recover, and may also need to factor in the device¹s capabilities and
> >> 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
> > is obvious that wpa_supplicant will be looking for another AP to
> > 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.
In addition the service is disconnected.
> 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).
At this point ConnMan has already selected another service, if
available, so there is no guarantees that the same WiFi will be
The only thing that might work here is that one or more of the reason
codes 6, 7 or 4 will not be sent in any other circumstances than doing
this unnecessary disconnect notification from wpa_supplicant and is an
indication that the notification can be ignored. Probably it does not
work out that nicely.
connman mailing list
Statement of Confidentiality
The contents of this e-mail message and any attachments are confidential and are intended
solely for the addressee. The information may also be legally privileged. This
transmission is sent in trust, and the sole purpose of delivery to the intended recipient.
If you have received this transmission in error, any use, reproduction or dissemination of
this transmission is strictly prohibited. If you are not the intended recipient, please
immediately notify the sender by reply e-mail or at 508.683.2500 and delete this message
and its attachments, if any.