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.
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
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
On Fri, Feb 20, 2015 at 1:00 AM, Krishna Chaitanya
<[email protected]> 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?
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
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
On Wed, Feb 25, 2015 at 2:17 AM, Johannes Berg
<[email protected]> 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.
On Wed, 2015-02-25 at 02:41 +0530, Krishna Chaitanya wrote:
> On Wed, Feb 25, 2015 at 2:17 AM, Johannes Berg
> <[email protected]> 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
On Tue, Feb 24, 2015 at 3:39 PM, Johannes Berg
<[email protected]> 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.
On Tue, Feb 24, 2015 at 4:05 PM, Johannes Berg
<[email protected]> 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.
On Tue, Feb 24, 2015 at 4:59 PM, Krishna Chaitanya
<[email protected]> wrote:
> On Tue, Feb 24, 2015 at 4:05 PM, Johannes Berg
> <[email protected]> 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.
On Fri, Feb 20, 2015 at 2:58 AM, Krishna Chaitanya
<[email protected]> wrote:
> On Fri, Feb 20, 2015 at 1:00 AM, Krishna Chaitanya
> <[email protected]> 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;
}
On Wed, Feb 25, 2015 at 1:32 PM, Johannes Berg
<[email protected]> wrote:
>
> On Wed, 2015-02-25 at 02:41 +0530, Krishna Chaitanya wrote:
> > On Wed, Feb 25, 2015 at 2:17 AM, Johannes Berg
> > <[email protected]> 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.
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
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
On Wed, Mar 11, 2015 at 10:05 PM, Krishna Chaitanya
<[email protected]> wrote:
> On Wed, Mar 11, 2015 at 9:50 PM, Johannes Berg
> <[email protected]> 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.
On Wed, Mar 11, 2015 at 9:50 PM, Johannes Berg
<[email protected]> 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.