* Connection issues with BW Tracking in mac80211 @ 2015-02-19 19:30 Krishna Chaitanya 2015-02-19 21:28 ` Krishna Chaitanya 2015-02-24 10:08 ` Johannes Berg 0 siblings, 2 replies; 17+ messages in thread From: Krishna Chaitanya @ 2015-02-19 19:30 UTC (permalink / raw) To: linux-wireless, Johannes Berg 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? -- Thanks, Regards, Chaitanya T K. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-02-19 19:30 Connection issues with BW Tracking in mac80211 Krishna Chaitanya @ 2015-02-19 21:28 ` Krishna Chaitanya 2015-02-23 18:00 ` Krishna Chaitanya 2015-02-24 10:09 ` Johannes Berg 2015-02-24 10:08 ` Johannes Berg 1 sibling, 2 replies; 17+ messages in thread From: Krishna Chaitanya @ 2015-02-19 21:28 UTC (permalink / raw) To: linux-wireless, Johannes Berg On Fri, Feb 20, 2015 at 1:00 AM, Krishna Chaitanya <chaitanya.mgit@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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-02-19 21:28 ` Krishna Chaitanya @ 2015-02-23 18:00 ` Krishna Chaitanya 2015-02-24 10:09 ` Johannes Berg 1 sibling, 0 replies; 17+ messages in thread From: Krishna Chaitanya @ 2015-02-23 18:00 UTC (permalink / raw) To: linux-wireless, Johannes Berg On Fri, Feb 20, 2015 at 2:58 AM, Krishna Chaitanya <chaitanya.mgit@gmail.com> wrote: > On Fri, Feb 20, 2015 at 1:00 AM, Krishna Chaitanya > <chaitanya.mgit@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; } ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-02-19 21:28 ` Krishna Chaitanya 2015-02-23 18:00 ` Krishna Chaitanya @ 2015-02-24 10:09 ` Johannes Berg 2015-02-24 10:28 ` Krishna Chaitanya 1 sibling, 1 reply; 17+ messages in thread From: Johannes Berg @ 2015-02-24 10:09 UTC (permalink / raw) To: Krishna Chaitanya; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-02-24 10:09 ` Johannes Berg @ 2015-02-24 10:28 ` Krishna Chaitanya 2015-02-24 10:35 ` Johannes Berg 0 siblings, 1 reply; 17+ messages in thread From: Krishna Chaitanya @ 2015-02-24 10:28 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-wireless On Tue, Feb 24, 2015 at 3:39 PM, Johannes Berg <johannes@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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-02-24 10:28 ` Krishna Chaitanya @ 2015-02-24 10:35 ` Johannes Berg 2015-02-24 11:29 ` Krishna Chaitanya 0 siblings, 1 reply; 17+ messages in thread From: Johannes Berg @ 2015-02-24 10:35 UTC (permalink / raw) To: Krishna Chaitanya; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-02-24 10:35 ` Johannes Berg @ 2015-02-24 11:29 ` Krishna Chaitanya 2015-02-24 20:33 ` Krishna Chaitanya 0 siblings, 1 reply; 17+ messages in thread From: Krishna Chaitanya @ 2015-02-24 11:29 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-wireless On Tue, Feb 24, 2015 at 4:05 PM, Johannes Berg <johannes@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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-02-24 11:29 ` Krishna Chaitanya @ 2015-02-24 20:33 ` Krishna Chaitanya 2015-02-24 20:47 ` Johannes Berg 0 siblings, 1 reply; 17+ messages in thread From: Krishna Chaitanya @ 2015-02-24 20:33 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-wireless On Tue, Feb 24, 2015 at 4:59 PM, Krishna Chaitanya <chaitanya.mgit@gmail.com> wrote: > On Tue, Feb 24, 2015 at 4:05 PM, Johannes Berg > <johannes@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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-02-24 20:33 ` Krishna Chaitanya @ 2015-02-24 20:47 ` Johannes Berg 2015-02-24 21:11 ` Krishna Chaitanya 0 siblings, 1 reply; 17+ messages in thread From: Johannes Berg @ 2015-02-24 20:47 UTC (permalink / raw) To: Krishna Chaitanya; +Cc: linux-wireless 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. This sounds synthetic - just run your test scripts with "iw wlan0 scan flush". johannes ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-02-24 20:47 ` Johannes Berg @ 2015-02-24 21:11 ` Krishna Chaitanya 2015-02-25 8:02 ` Johannes Berg 0 siblings, 1 reply; 17+ messages in thread From: Krishna Chaitanya @ 2015-02-24 21:11 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-wireless On Wed, Feb 25, 2015 at 2:17 AM, Johannes Berg <johannes@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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-02-24 21:11 ` Krishna Chaitanya @ 2015-02-25 8:02 ` Johannes Berg 2015-03-11 16:15 ` Krishna Chaitanya 0 siblings, 1 reply; 17+ messages in thread From: Johannes Berg @ 2015-02-25 8:02 UTC (permalink / raw) To: Krishna Chaitanya; +Cc: linux-wireless On Wed, 2015-02-25 at 02:41 +0530, Krishna Chaitanya wrote: > On Wed, Feb 25, 2015 at 2:17 AM, Johannes Berg > <johannes@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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-02-25 8:02 ` Johannes Berg @ 2015-03-11 16:15 ` Krishna Chaitanya 2015-03-11 16:20 ` Johannes Berg 0 siblings, 1 reply; 17+ messages in thread From: Krishna Chaitanya @ 2015-03-11 16:15 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-wireless On Wed, Feb 25, 2015 at 1:32 PM, Johannes Berg <johannes@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 > > <johannes@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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-03-11 16:15 ` Krishna Chaitanya @ 2015-03-11 16:20 ` Johannes Berg 2015-03-11 16:35 ` Krishna Chaitanya 0 siblings, 1 reply; 17+ messages in thread From: Johannes Berg @ 2015-03-11 16:20 UTC (permalink / raw) To: Krishna Chaitanya; +Cc: linux-wireless On Wed, 2015-03-11 at 21:45 +0530, Krishna Chaitanya wrote: > 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? What's the operational problem here? I don't really see it. Are you afraid users will reconfigure their APs often enough for this to be an issue? johannes ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-03-11 16:20 ` Johannes Berg @ 2015-03-11 16:35 ` Krishna Chaitanya 2015-03-12 9:17 ` Krishna Chaitanya 0 siblings, 1 reply; 17+ messages in thread From: Krishna Chaitanya @ 2015-03-11 16:35 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-wireless On Wed, Mar 11, 2015 at 9:50 PM, Johannes Berg <johannes@sipsolutions.net> wrote: > On Wed, 2015-03-11 at 21:45 +0530, Krishna Chaitanya wrote: > >> 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? > > What's the operational problem here? I don't really see it. Are you > afraid users will reconfigure their APs often enough for this to be an > issue? Use case point of view, i understand that this doesn't happen often. But from functional point of view, it can still happen and even after disconnect mac80211 will not allow connection. Also solution: would be to flush scan results up on disconnection. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-03-11 16:35 ` Krishna Chaitanya @ 2015-03-12 9:17 ` Krishna Chaitanya 2015-03-17 9:57 ` Johannes Berg 0 siblings, 1 reply; 17+ messages in thread From: Krishna Chaitanya @ 2015-03-12 9:17 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-wireless On Wed, Mar 11, 2015 at 10:05 PM, Krishna Chaitanya <chaitanya.mgit@gmail.com> wrote: > On Wed, Mar 11, 2015 at 9:50 PM, Johannes Berg > <johannes@sipsolutions.net> wrote: >> On Wed, 2015-03-11 at 21:45 +0530, Krishna Chaitanya wrote: >> >>> 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? >> >> What's the operational problem here? I don't really see it. Are you >> afraid users will reconfigure their APs often enough for this to be an >> issue? > Use case point of view, i understand that this doesn't happen often. > But from functional point of view, it can still happen and even > after disconnect mac80211 will not allow connection. > > Also solution: would be to flush scan results up on disconnection. Johannes, Assuming that this problem needs to be solved in spite of low probability of the occurrence. What do you think is the best way, which has low impact on other features out of these? 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. Regards, Chaitanya T K. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-03-12 9:17 ` Krishna Chaitanya @ 2015-03-17 9:57 ` Johannes Berg 0 siblings, 0 replies; 17+ messages in thread From: Johannes Berg @ 2015-03-17 9:57 UTC (permalink / raw) To: Krishna Chaitanya; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Connection issues with BW Tracking in mac80211 2015-02-19 19:30 Connection issues with BW Tracking in mac80211 Krishna Chaitanya 2015-02-19 21:28 ` Krishna Chaitanya @ 2015-02-24 10:08 ` Johannes Berg 1 sibling, 0 replies; 17+ messages in thread From: Johannes Berg @ 2015-02-24 10:08 UTC (permalink / raw) To: Krishna Chaitanya; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2015-03-17 9:57 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-02-19 19:30 Connection issues with BW Tracking in mac80211 Krishna Chaitanya 2015-02-19 21:28 ` Krishna Chaitanya 2015-02-23 18:00 ` Krishna Chaitanya 2015-02-24 10:09 ` Johannes Berg 2015-02-24 10:28 ` Krishna Chaitanya 2015-02-24 10:35 ` Johannes Berg 2015-02-24 11:29 ` Krishna Chaitanya 2015-02-24 20:33 ` Krishna Chaitanya 2015-02-24 20:47 ` Johannes Berg 2015-02-24 21:11 ` Krishna Chaitanya 2015-02-25 8:02 ` Johannes Berg 2015-03-11 16:15 ` Krishna Chaitanya 2015-03-11 16:20 ` Johannes Berg 2015-03-11 16:35 ` Krishna Chaitanya 2015-03-12 9:17 ` Krishna Chaitanya 2015-03-17 9:57 ` Johannes Berg 2015-02-24 10:08 ` Johannes Berg
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.