996544 - Device takes time (in minutes) to disconnect and reconnect wifi network, after changing Channel (frequency) or Mode(b/g/n) in AP

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Wifi, defect)

Description

[vasanth]

STR
1. Connect device to a wifi network from AP
2. Now in AP, change the mode(b/g/n) or change channel from 1 to 6 or any.
3. Now observe that AP sends Deauth frame repeatedly
4. Device does not respond to it .
5. After a minute or more, device disconnects and reconnect back to AP.

In Android kk, for same STR, device disconnects and reconnects within ~10 seconds.
From logs, it seems Android is doing active scan frequently whereas FFOS does active scan only once when wifi turned on and only does passive scan after that?

Same behavior is seen in V1.3 as well

Comment 1

[Ken Chang[:kenkai]]

(In reply to vasanth from comment #0)
> STR
> 1. Connect device to a wifi network from AP
> 2. Now in AP, change the mode(b/g/n) or change channel from 1 to 6 or any.
> 3. Now observe that AP sends Deauth frame repeatedly
> 4. Device does not respond to it .
> 5. After a minute or more, device disconnects and reconnect back to AP.
> 
> In Android kk, for same STR, device disconnects and reconnects within ~10
> seconds.
> From logs, it seems Android is doing active scan frequently whereas FFOS
> does active scan only once when wifi turned on and only does passive scan
> after that?
I would say it is a feature. Because active scan might cause more power consumption, we need to think where we should trigger this carefully. Moreover, the device connect to that AP eventually.

Comment 2

[vasanth]

(In reply to Ken Chang[:ken] from comment #1)
> I would say it is a feature. Because active scan might cause more power
> consumption, we need to think where we should trigger this carefully.
> Moreover, the device connect to that AP eventually.

Is there any way to detect AP's channel or mode change from passive scan itself?

Comment 3

[Vincent Chang[:vchang][changyihsin]]

(In reply to vasanth from comment #2)
> (In reply to Ken Chang[:ken] from comment #1)
> > I would say it is a feature. Because active scan might cause more power
> > consumption, we need to think where we should trigger this carefully.
> > Moreover, the device connect to that AP eventually.
> 
> Is there any way to detect AP's channel or mode change from passive scan
> itself?

I tried on Unagi and Hamachi, the result is different. 
For Unagi, wpa_supplicant notifies DISCONNECT event to gecko quickly (1~2 seconds) right after I modify the channel in Wifi AP, and connect to AP successfully (less than 10 seconds).  
For Hamachi, wpa_supplicant doesn't notify any event.

I am wondering if this should be handled in wpa_supplicant ?

Comment 4

[vasanth]

(In reply to Vincent Chang[:vchang] from comment #3)
> I am wondering if this should be handled in wpa_supplicant ?

Not sure about that. If you feel issue is with supplicant, you will need to come up with API used, Version from which its behaving differently, substantial proof/logs and then we can ask the supplicant team (open source) to look into that.

Comment 5

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

I think it's driver's job to detect and notify unexpected disconnect with AP.
As far as I know, some driver's monitors beacon from connecting AP and notify disconnect if beacon is lost for certain interval.

Comment 6

[vasanth]

(In reply to Chuck Lee [:chucklee] from comment #5)
> I think it's driver's job to detect and notify unexpected disconnect with AP.
> As far as I know, some driver's monitors beacon from connecting AP and
> notify disconnect if beacon is lost for certain interval.

Same drivers are used for Android kk and FFOS V1.4. With the same drivers, Android is able to detect channel/mode changes in AP and reconnects.
If you can provide info on what exact commands/responses are expected at supplicant/driver level for FFOS, we can check and update here?

Comment 7

[Preeti Raghunath(:Preeti)]

Chuck,

Do we have all the information to keep this going?

What next steps? Is anything needed from QC here?

Comment 8

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

As Vincent mentioned in comment 3, we expect a CTRL-EVENT-DISCONNECT from wpa_supplicant without any polling, so we can know it is disconnected from AP.

To do that, I think for driver level, it should has the ability to detect connection status, like detecting beacon miss as I mentioned in comment 5[1], and notify discconect(including unexpected AP lost) to wpa_supplicant through netlink. [2]
For wpa_supplicant, it should handle netlink messages from driver, then send out the DISCONNECT event. [3][4]

[1] http://lxr.free-electrons.com/source/net/mac80211/mlme.c#L2032
[2] http://lxr.free-electrons.com/source/net/wireless/nl80211.c#L10193
[3] http://hostap.epitest.fi/cgit/hostap/tree/src/drivers/driver_nl80211.c#n3025
[4] http://hostap.epitest.fi/cgit/hostap/tree/src/drivers/driver_wext.c#n456

Comment 9

[vasanth]

Thanks Chuck. I will check internally and update here.

Comment 10

[vasanth]

(In reply to Chuck Lee [:chucklee] from comment #8)
> As Vincent mentioned in comment 3, we expect a CTRL-EVENT-DISCONNECT from
> wpa_supplicant without any polling, so we can know it is disconnected from
> AP.

After analyzing logs, it seems even in our device, wpa_supplicant sends CTRL-EVENT-DISCONNECT and device scans and connects back to AP automatically in short time.
Just that UI didn't show disconnect/connect to network but supplicant/drivers were in proper state.

We can close this issue.