Re: Connection issues with BW Tracking in mac80211
On Thu, 2015-03-12 at 14:47 +0530, Krishna Chaitanya wrote: 1. Make the directed probe mandatory: a. Check for successful probe resp without depending on proberesp_ies. b. remove the proberesp_ies from the auth_data to trigger directed probe. 2. Timestamps for proberesp and beacons and update the latest one to ies. 3. while update ies check only for beacon as its supposed to have latest information (This will trigger #1 automatically). As a quick and minimal impact solution i am thinking 1-b. Huh? No, that'd be one of the worst possible solution IMHO since it would make the system behave differently *all the time* just because of a very uncommon scenario. Is this really a real world use case? I can't really think of any way this would happen in practice. The least impact would probably have #2. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Wed, Feb 25, 2015 at 1:32 PM, Johannes Berg johan...@sipsolutions.net wrote: On Wed, 2015-02-25 at 02:41 +0530, Krishna Chaitanya wrote: On Wed, Feb 25, 2015 at 2:17 AM, Johannes Berg johan...@sipsolutions.net wrote: On Wed, 2015-02-25 at 02:03 +0530, Krishna Chaitanya wrote: Use case2: When changing from HT40-VHT80, the connection goes through but it still connected as HT40 (vht_ie from cfg80211 is returned null). Can you think of any reason why the bss_list is not updated cfg80211? Note: iwconfig and wpa_supplicant both show same behavior. Well, there's no flushing, only overwriting by new results - but if you previuosly got both beacons and probe responses each one will stick around until you get them again. We do have the scan results expiry time of 30secs, that will flush the results from bss_list right? Even the get_bss checks for aging? Yes but if you scan in the meantime the scan result is marked as recent again, even if some old data might be kept. Perhaps we should split that into timestamps for probe and beacons separately, but that'd certainly complicate the code significantly for little gain. I did some experiments on this and found the root cause. We are using 5GHz in WORLD Mode, so only passive scan is allowed. So when connecting the very first time, the mac80211 MLME sees that there are no probe_resp ies (only beacon_ies are present) and it sends a directed probe and updates the probe_resp ies. (and also the ies). But when config is changed and we get disconnected, beacon_ies are updated with the new config, but the probe_resp ies are not. cfg80211_bss_update assigns probe_resp ies to ies' and mac80211 updates its bss info based on the probe_resp ies which have old config causing the issue. Solution: 1) Make the directed probe mandatory. 2) As you suggested maintain timestamps for probe_resp_ies and beacon_ies and use the latest. Any takes? Regards, Chaitanya T K. -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Wed, 2015-02-25 at 02:41 +0530, Krishna Chaitanya wrote: On Wed, Feb 25, 2015 at 2:17 AM, Johannes Berg johan...@sipsolutions.net wrote: On Wed, 2015-02-25 at 02:03 +0530, Krishna Chaitanya wrote: Use case2: When changing from HT40-VHT80, the connection goes through but it still connected as HT40 (vht_ie from cfg80211 is returned null). Can you think of any reason why the bss_list is not updated cfg80211? Note: iwconfig and wpa_supplicant both show same behavior. Well, there's no flushing, only overwriting by new results - but if you previuosly got both beacons and probe responses each one will stick around until you get them again. We do have the scan results expiry time of 30secs, that will flush the results from bss_list right? Even the get_bss checks for aging? Yes but if you scan in the meantime the scan result is marked as recent again, even if some old data might be kept. Perhaps we should split that into timestamps for probe and beacons separately, but that'd certainly complicate the code significantly for little gain. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Wed, Feb 25, 2015 at 2:17 AM, Johannes Berg johan...@sipsolutions.net wrote: On Wed, 2015-02-25 at 02:03 +0530, Krishna Chaitanya wrote: Use case2: When changing from HT40-VHT80, the connection goes through but it still connected as HT40 (vht_ie from cfg80211 is returned null). Can you think of any reason why the bss_list is not updated cfg80211? Note: iwconfig and wpa_supplicant both show same behavior. Well, there's no flushing, only overwriting by new results - but if you previuosly got both beacons and probe responses each one will stick around until you get them again. We do have the scan results expiry time of 30secs, that will flush the results from bss_list right? Even the get_bss checks for aging? This sounds synthetic - just run your test scripts with iw wlan0 scan flush. Sure, will give it a shot. -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Tue, Feb 24, 2015 at 4:59 PM, Krishna Chaitanya chaitanya.m...@gmail.com wrote: On Tue, Feb 24, 2015 at 4:05 PM, Johannes Berg johan...@sipsolutions.net wrote: On Tue, 2015-02-24 at 15:58 +0530, Krishna Chaitanya wrote: STA (mac80211) connects to AP in VHT-80. AP is reconfigured to 11n40 (stops beaconing for about 30secs and then starts again). STA loses connection (HW_CONN_TRACK), iee80211_connection_loss is called. STA see's AP again and tries to connect, But this goes through the supplicant, right? You actually get a full connection loss (which I certainly would expect after 30 seconds) Our HW N/W lost event timeout is 5secs. but due to BW tracking in mac80211 it doesn't connect. So i guess we are not resetting the tracking after losing connection. Right, some flag is not getting reset correctly I suppose. I thought we had pretty robust code for this, but I guess not. Easiest might be to print the flags and other state for during all connection attempts, and then compare * VHT connection * subsequent HT connection * HT connection after reloading the driver Sure Johannes, will share the info. Before you spend time on this, my tests are based on older kernel 3.10.36 but the code in this ares looks pretty much same (At least the parts i am working on :-) ). If time permits, i will try the same with latest kernel as well. Usecase1: When changing from VHT80-HT40. STA disconnect but sometimes unable to reconnect. I have digged in to this issue further, and observed that whenever issue happens the bss_list in the scan list is having old information even though we are doing a new scan as BSS info is not found (even without new scan it should have been flushed). Sometimes iw wlan0 scan dump shows empty/VHT info (which is old). So while doing assoc, cfg80211 gets the bss information from bss_list (get_ie(VHT)) and passes to mac80211, which has VHT but AP's beacon/probe resp/assoc resp is HT only causing the issue. Event multiple connection attempts doesn't resolve this, but if i do repeated scan's i am able to connect. Use case2: When changing from HT40-VHT80, the connection goes through but it still connected as HT40 (vht_ie from cfg80211 is returned null). Can you think of any reason why the bss_list is not updated cfg80211? Note: iwconfig and wpa_supplicant both show same behavior. -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Tue, Feb 24, 2015 at 3:39 PM, Johannes Berg johan...@sipsolutions.net wrote: On Fri, 2015-02-20 at 02:58 +0530, Krishna Chaitanya wrote: Before that i have a basic question? Should we reset our tracking after the connection is lost, in my case above the connection was lost (Config change in A triggers a reboot), still mac80211 is tracking the BW changes? Huh?? So the AP does restart, but mac80211 tries to stay connected to it? That seems pretty unlikely. The tracking *shouldn't* have any knowledge of what happened before the association, but there could be bugs in the flags assignment I guess. Let me explain the sequences. STA (mac80211) connects to AP in VHT-80. AP is reconfigured to 11n40 (stops beaconing for about 30secs and then starts again). STA loses connection (HW_CONN_TRACK), iee80211_connection_loss is called. STA see's AP again and tries to connect, but due to BW tracking in mac80211 it doesn't connect. So i guess we are not resetting the tracking after losing connection. -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Fri, 2015-02-20 at 02:58 +0530, Krishna Chaitanya wrote: Before that i have a basic question? Should we reset our tracking after the connection is lost, in my case above the connection was lost (Config change in A triggers a reboot), still mac80211 is tracking the BW changes? Huh?? So the AP does restart, but mac80211 tries to stay connected to it? That seems pretty unlikely. The tracking *shouldn't* have any knowledge of what happened before the association, but there could be bugs in the flags assignment I guess. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Fri, 2015-02-20 at 01:00 +0530, Krishna Chaitanya wrote: Hi Johannes, The BW tracking feature in mac80211 is causing connection problems and operating mode/bw problems when switching b/w modes and bw's in AP. For Eg. Initially if AP is operating in VHT-80MHz, and then we changed in to HT-40MHz, mac80211 cannot handle it because the VHT capability is mismatched b/w stored info (ifmgd-flags). How are you doing such a change? I was assuming that the BSS would cease to exist if it was reconfigured in such a way. I have tried your DISABLE_BW_TRACK patch, that helps making the connection but it doesn't update the chipset causing issues. Well, that was clearly going to happen. Ideally we should be able to handle all the config changes right? Not sure. How does this config change work? I'd have expected the AP to stop beaconing and kick everyone out if you actually reconfigured it to no longer have VHT since then it can't do VHT rates any more either according to the new config? What exactly are you doing, and how does the AP behave, and what do you expect to happen? johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Tue, 2015-02-24 at 15:58 +0530, Krishna Chaitanya wrote: STA (mac80211) connects to AP in VHT-80. AP is reconfigured to 11n40 (stops beaconing for about 30secs and then starts again). STA loses connection (HW_CONN_TRACK), iee80211_connection_loss is called. STA see's AP again and tries to connect, But this goes through the supplicant, right? You actually get a full connection loss (which I certainly would expect after 30 seconds) but due to BW tracking in mac80211 it doesn't connect. So i guess we are not resetting the tracking after losing connection. Right, some flag is not getting reset correctly I suppose. I thought we had pretty robust code for this, but I guess not. Easiest might be to print the flags and other state for during all connection attempts, and then compare * VHT connection * subsequent HT connection * HT connection after reloading the driver johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Tue, Feb 24, 2015 at 4:05 PM, Johannes Berg johan...@sipsolutions.net wrote: On Tue, 2015-02-24 at 15:58 +0530, Krishna Chaitanya wrote: STA (mac80211) connects to AP in VHT-80. AP is reconfigured to 11n40 (stops beaconing for about 30secs and then starts again). STA loses connection (HW_CONN_TRACK), iee80211_connection_loss is called. STA see's AP again and tries to connect, But this goes through the supplicant, right? You actually get a full connection loss (which I certainly would expect after 30 seconds) Our HW N/W lost event timeout is 5secs. but due to BW tracking in mac80211 it doesn't connect. So i guess we are not resetting the tracking after losing connection. Right, some flag is not getting reset correctly I suppose. I thought we had pretty robust code for this, but I guess not. Easiest might be to print the flags and other state for during all connection attempts, and then compare * VHT connection * subsequent HT connection * HT connection after reloading the driver Sure Johannes, will share the info. -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Fri, Feb 20, 2015 at 2:58 AM, Krishna Chaitanya
chaitanya.m...@gmail.com wrote:
On Fri, Feb 20, 2015 at 1:00 AM, Krishna Chaitanya
chaitanya.m...@gmail.com wrote:
Hi Johannes,
The BW tracking feature in mac80211 is causing connection problems and
operating mode/bw problems when switching b/w modes and bw's in AP.
For Eg. Initially if AP is operating in VHT-80MHz, and then we changed
in to HT-40MHz, mac80211 cannot handle it because the VHT capability
is mismatched b/w stored info (ifmgd-flags).
I have tried your DISABLE_BW_TRACK patch, that helps making the
connection but it doesn't update the chipset causing issues.
Ideally we should be able to handle all the config changes right?
Before that i have a basic question? Should we reset our tracking after
the connection is lost, in my case above the connection was lost (Config
change in A triggers a reboot), still mac80211 is tracking the BW changes?
Any ideas johannes? Currenlty we kind-of disabled BW tracking as a work around
for this issue.
mlme.c: Removed the capability checks.
if (!cfg80211_chandef_valid(chandef)) {
sdata_info(sdata,
AP %pM chandef invalid - disconnect\n,
ifmgd-bssid);
return -EINVAL;
}
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Fri, Feb 20, 2015 at 1:00 AM, Krishna Chaitanya chaitanya.m...@gmail.com wrote: Hi Johannes, The BW tracking feature in mac80211 is causing connection problems and operating mode/bw problems when switching b/w modes and bw's in AP. For Eg. Initially if AP is operating in VHT-80MHz, and then we changed in to HT-40MHz, mac80211 cannot handle it because the VHT capability is mismatched b/w stored info (ifmgd-flags). I have tried your DISABLE_BW_TRACK patch, that helps making the connection but it doesn't update the chipset causing issues. Ideally we should be able to handle all the config changes right? Before that i have a basic question? Should we reset our tracking after the connection is lost, in my case above the connection was lost (Config change in A triggers a reboot), still mac80211 is tracking the BW changes? -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
