2010-01-01 09:07:59

by Benoit Papillault

[permalink] [raw]
Subject: Issue connecting to an HT40 AP that sends a Country IE

Hello,

I'd like to report an issue I have when trying to connect a laptop
running ath9k to a 802.11n AP in HT40 mode. What happens is that the
laptop cannot associate if the AP is running in HT40 mode. Association
is OK if the AP is running in HT20 mode. Here is an excerpt from syslog :

[ 577.166241] wlan0: associate with AP 00:15:6d:e8:88:84 (try 1)
[ 577.167448] wlan0: RX AssocResp from 00:15:6d:e8:88:84 (capab=0x411
status=10 aid=257)
[ 577.167451] wlan0: AP denied association (code=10)
[ 577.167460] wlan0: deauthenticating from 00:15:6d:e8:88:84 by local
choice (reason=3)

What's wrong is that the Associate Request (built by
ieee80211_send_assoc) does not set the bit in HT Capabilities IE saying
: "The station supports both HT20 & HT40".

Looking into the code, it appears that both (flags &
IEEE80211_CHAN_NO_HT40PLUS) and (flags & IEEE80211_CHAN_NO_HT40MINUS)
are true, thus disabling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 which is
the culprit mentioned above.

Digging further down, both flags are set in reg.c by :
if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40))
bw_flags = IEEE80211_CHAN_NO_HT40;

Indeed, at this stage, max_bandwidth_khz is 20 MHz only... Looking up in
my syslog, I found this :

[ 506.036923] cfg80211: Received country IE:
[ 506.036927] cfg80211: Regulatory domain: FR
[ 506.036928] (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 506.036931] (5170000 KHz - 5190000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036933] (5190000 KHz - 5210000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036936] (5210000 KHz - 5230000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036938] (5230000 KHz - 5250000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036940] (5250000 KHz - 5270000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036943] (5270000 KHz - 5290000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036945] (5290000 KHz - 5310000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036948] (5310000 KHz - 5330000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036950] (5490000 KHz - 5510000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036952] (5510000 KHz - 5530000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036955] (5530000 KHz - 5550000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036957] (5550000 KHz - 5570000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036959] (5570000 KHz - 5590000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036962] (5590000 KHz - 5610000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036964] (5610000 KHz - 5630000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036966] (5630000 KHz - 5650000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036969] (5650000 KHz - 5670000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036971] (5670000 KHz - 5690000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)
[ 506.036974] (5690000 KHz - 5710000 KHz @ 40000 KHz), (10000 mBi,
10000 mBm)

[ 506.036975] cfg80211: CRDA thinks this should applied:
[ 506.036976] cfg80211: Regulatory domain: FR
[ 506.036978] (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 506.036980] (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 506.036982] (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 506.036984] (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 506.036987] (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)

[ 506.036988] cfg80211: We intersect both of these and get:
[ 506.037005] cfg80211: Regulatory domain: 98
[ 506.037006] (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 506.037008] (5170000 KHz - 5190000 KHz @ 20000 KHz), (N/A, 2000 mBm)
[ 506.037011] (5190000 KHz - 5210000 KHz @ 20000 KHz), (N/A, 2000 mBm)
[ 506.037013] (5210000 KHz - 5230000 KHz @ 20000 KHz), (N/A, 2000 mBm)
[ 506.037015] (5230000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 2000 mBm)
[ 506.037017] (5250000 KHz - 5270000 KHz @ 20000 KHz), (N/A, 2000 mBm)
[ 506.037019] (5270000 KHz - 5290000 KHz @ 20000 KHz), (N/A, 2000 mBm)
[ 506.037021] (5290000 KHz - 5310000 KHz @ 20000 KHz), (N/A, 2000 mBm)
[ 506.037024] (5310000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 2000 mBm)
[ 506.037026] (5490000 KHz - 5510000 KHz @ 20000 KHz), (N/A, 2700 mBm)
[ 506.037028] (5510000 KHz - 5530000 KHz @ 20000 KHz), (N/A, 2700 mBm)
[ 506.037030] (5530000 KHz - 5550000 KHz @ 20000 KHz), (N/A, 2700 mBm)
[ 506.037032] (5550000 KHz - 5570000 KHz @ 20000 KHz), (N/A, 2700 mBm)
[ 506.037035] (5570000 KHz - 5590000 KHz @ 20000 KHz), (N/A, 2700 mBm)
[ 506.037037] (5590000 KHz - 5610000 KHz @ 20000 KHz), (N/A, 2700 mBm)
[ 506.037039] (5610000 KHz - 5630000 KHz @ 20000 KHz), (N/A, 2700 mBm)
[ 506.037041] (5630000 KHz - 5650000 KHz @ 20000 KHz), (N/A, 2700 mBm)
[ 506.037043] (5650000 KHz - 5670000 KHz @ 20000 KHz), (N/A, 2700 mBm)
[ 506.037045] (5670000 KHz - 5690000 KHz @ 20000 KHz), (N/A, 2700 mBm)
[ 506.037047] (5690000 KHz - 5710000 KHz @ 20000 KHz), (N/A, 2700 mBm)

So, at this stage, max_bandwidth_khz is indeed 20 MHz!

What's the real meaning of max_bandwidth_khz? If this is just the
difference between the upper/lower frequency of each channels, then it's
useless. If it is a capability features saying 40 MHz channel wide are
allowed, then it should be left to 40 MHz even if upper/lower
frequencies are only 20 MHz apart (since the ability to use 40 MHz
depends on the list of all frequencies, not a single frequency).

I did a quick patch commenting the lines setting IEEE80211_CHAN_NO_HT40
and it works. But it'd like to know how it is expected to work in this case.

Regards,
Benoit
PS: in Country IE, TxPower field is not parsed as well ...



2010-01-02 18:04:49

by Luis R. Rodriguez

[permalink] [raw]
Subject: Re: Issue connecting to an HT40 AP that sends a Country IE

On Sat, Jan 2, 2010 at 4:21 AM, Benoit PAPILLAULT
<[email protected]> wrote:
> Luis R. Rodriguez a écrit :
>>
>> On Fri, Jan 1, 2010 at 4:07 AM, Benoit PAPILLAULT
>> <[email protected]> wrote:
>>
>>>
>>> Hello,
>>>
>>> I'd like to report an issue I have when trying to connect a laptop
>>> running ath9k to a 802.11n AP in HT40 mode. What happens is that the
>>> laptop cannot associate if the AP is running in HT40 mode. Association
>>> is OK if the AP is running in HT20 mode. Here is an excerpt from syslog :
>>>
>>> [  577.166241] wlan0: associate with AP 00:15:6d:e8:88:84 (try 1)
>>> [  577.167448] wlan0: RX AssocResp from 00:15:6d:e8:88:84 (capab=0x411
>>> status=10 aid=257)
>>> [  577.167451] wlan0: AP denied association (code=10)
>>> [  577.167460] wlan0: deauthenticating from 00:15:6d:e8:88:84 by local
>>> choice (reason=3)
>>>
>>> What's wrong is that the Associate Request (built by
>>> ieee80211_send_assoc) does not set the bit in HT Capabilities IE saying
>>> : "The station supports both HT20 & HT40".
>>>
>>> Looking into the code, it appears that both (flags &
>>> IEEE80211_CHAN_NO_HT40PLUS) and (flags & IEEE80211_CHAN_NO_HT40MINUS)
>>> are true, thus disabling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 which is
>>> the culprit mentioned above.
>>>
>>> Digging further down, both flags are set in reg.c by :
>>>  if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40))
>>>      bw_flags = IEEE80211_CHAN_NO_HT40;
>>>
>>> Indeed, at this stage, max_bandwidth_khz is 20 MHz only... Looking up in
>>> my syslog, I found this :
>>>
>>> [  506.036923] cfg80211: Received country IE:
>>> [  506.036927] cfg80211: Regulatory domain: FR
>>> [  506.036928]     (start_freq - end_freq @ bandwidth),
>>> (max_antenna_gain, max_eirp)
>>> [  506.036931]     (5170000 KHz - 5190000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036933]     (5190000 KHz - 5210000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036936]     (5210000 KHz - 5230000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036938]     (5230000 KHz - 5250000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036940]     (5250000 KHz - 5270000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036943]     (5270000 KHz - 5290000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036945]     (5290000 KHz - 5310000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036948]     (5310000 KHz - 5330000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036950]     (5490000 KHz - 5510000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036952]     (5510000 KHz - 5530000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036955]     (5530000 KHz - 5550000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036957]     (5550000 KHz - 5570000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036959]     (5570000 KHz - 5590000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036962]     (5590000 KHz - 5610000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036964]     (5610000 KHz - 5630000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036966]     (5630000 KHz - 5650000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036969]     (5650000 KHz - 5670000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036971]     (5670000 KHz - 5690000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>> [  506.036974]     (5690000 KHz - 5710000 KHz @ 40000 KHz), (10000 mBi,
>>> 10000 mBm)
>>>
>>> [  506.036975] cfg80211: CRDA thinks this should applied:
>>> [  506.036976] cfg80211: Regulatory domain: FR
>>> [  506.036978]     (start_freq - end_freq @ bandwidth),
>>> (max_antenna_gain, max_eirp)
>>> [  506.036980]     (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000
>>> mBm)
>>> [  506.036982]     (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000
>>> mBm)
>>> [  506.036984]     (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000
>>> mBm)
>>> [  506.036987]     (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700
>>> mBm)
>>>
>>> [  506.036988] cfg80211: We intersect both of these and get:
>>> [  506.037005] cfg80211: Regulatory domain: 98
>>> [  506.037006]     (start_freq - end_freq @ bandwidth),
>>> (max_antenna_gain, max_eirp)
>>> [  506.037008]     (5170000 KHz - 5190000 KHz @ 20000 KHz), (N/A, 2000
>>> mBm)
>>> [  506.037011]     (5190000 KHz - 5210000 KHz @ 20000 KHz), (N/A, 2000
>>> mBm)
>>> [  506.037013]     (5210000 KHz - 5230000 KHz @ 20000 KHz), (N/A, 2000
>>> mBm)
>>> [  506.037015]     (5230000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 2000
>>> mBm)
>>> [  506.037017]     (5250000 KHz - 5270000 KHz @ 20000 KHz), (N/A, 2000
>>> mBm)
>>> [  506.037019]     (5270000 KHz - 5290000 KHz @ 20000 KHz), (N/A, 2000
>>> mBm)
>>> [  506.037021]     (5290000 KHz - 5310000 KHz @ 20000 KHz), (N/A, 2000
>>> mBm)
>>> [  506.037024]     (5310000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 2000
>>> mBm)
>>> [  506.037026]     (5490000 KHz - 5510000 KHz @ 20000 KHz), (N/A, 2700
>>> mBm)
>>> [  506.037028]     (5510000 KHz - 5530000 KHz @ 20000 KHz), (N/A, 2700
>>> mBm)
>>> [  506.037030]     (5530000 KHz - 5550000 KHz @ 20000 KHz), (N/A, 2700
>>> mBm)
>>> [  506.037032]     (5550000 KHz - 5570000 KHz @ 20000 KHz), (N/A, 2700
>>> mBm)
>>> [  506.037035]     (5570000 KHz - 5590000 KHz @ 20000 KHz), (N/A, 2700
>>> mBm)
>>> [  506.037037]     (5590000 KHz - 5610000 KHz @ 20000 KHz), (N/A, 2700
>>> mBm)
>>> [  506.037039]     (5610000 KHz - 5630000 KHz @ 20000 KHz), (N/A, 2700
>>> mBm)
>>> [  506.037041]     (5630000 KHz - 5650000 KHz @ 20000 KHz), (N/A, 2700
>>> mBm)
>>> [  506.037043]     (5650000 KHz - 5670000 KHz @ 20000 KHz), (N/A, 2700
>>> mBm)
>>> [  506.037045]     (5670000 KHz - 5690000 KHz @ 20000 KHz), (N/A, 2700
>>> mBm)
>>> [  506.037047]     (5690000 KHz - 5710000 KHz @ 20000 KHz), (N/A, 2700
>>> mBm)
>>>
>>> So, at this stage, max_bandwidth_khz is indeed 20 MHz!
>>>
>>> What's the real meaning of max_bandwidth_khz? If this is just the
>>> difference between the upper/lower frequency of each channels, then it's
>>> useless. If it is a capability features saying 40 MHz channel wide are
>>> allowed, then it should be left to 40 MHz even if upper/lower
>>> frequencies are only 20 MHz apart (since the ability to use 40 MHz
>>> depends on the list of all frequencies, not a single frequency).
>>>
>>
>> Your AP is sending a country IE channel triplet for each channel it
>> allows. Its the first time I see an AP do this and its good that you
>> report this. What AP do you have?
>>
>> reg.c treats each triplet as a regulatory rule though and since you
>> have a rule for each channel it will restrict this to the triplet
>> range which is just one channel and as such 20 MHz only makes sense. A
>> fix would be to expand on the ht40 checks to check connecting
>> frequency rules.
>>
>>  Luis
>>
>
> Hello,
>
> My AP is a NanoStation M5 configured with Country "FR" and 40 MHz.
>
> Could you detail the fix you are proposing?
>
> On my side, I would propose to leave max_bandwidth_khz to 40 MHz and use it
> as a capability features.

Since the country IE does not have a max bandwidth we stuff a default
40 MHz to it as part of the frequency rule it creates.

> This way we would consider valid the case where
> upper/lower frequencies are just 20 MHz apart but max_bandwidth_khz is 40
> MHz.

The issue should be that a frequency rule is being created for each
channel and although 40 MHz is being specified as max bandwidth
logistically only 20 MHz fits into that frequency rule. So what the
intersection needs to learn is how to merge rules or at least
understand them together. It may be easier to parse insaneIEs like the
ones your AP generates and re-generate one with actual ranges with
contiguity channels merged. And then use that one for the
intersection.

Luis

2010-01-01 23:24:29

by Luis R. Rodriguez

[permalink] [raw]
Subject: Re: Issue connecting to an HT40 AP that sends a Country IE

On Fri, Jan 1, 2010 at 4:07 AM, Benoit PAPILLAULT
<[email protected]> wrote:
> Hello,
>
> I'd like to report an issue I have when trying to connect a laptop
> running ath9k to a 802.11n AP in HT40 mode. What happens is that the
> laptop cannot associate if the AP is running in HT40 mode. Association
> is OK if the AP is running in HT20 mode. Here is an excerpt from syslog :
>
> [  577.166241] wlan0: associate with AP 00:15:6d:e8:88:84 (try 1)
> [  577.167448] wlan0: RX AssocResp from 00:15:6d:e8:88:84 (capab=0x411
> status=10 aid=257)
> [  577.167451] wlan0: AP denied association (code=10)
> [  577.167460] wlan0: deauthenticating from 00:15:6d:e8:88:84 by local
> choice (reason=3)
>
> What's wrong is that the Associate Request (built by
> ieee80211_send_assoc) does not set the bit in HT Capabilities IE saying
> : "The station supports both HT20 & HT40".
>
> Looking into the code, it appears that both (flags &
> IEEE80211_CHAN_NO_HT40PLUS) and (flags & IEEE80211_CHAN_NO_HT40MINUS)
> are true, thus disabling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 which is
> the culprit mentioned above.
>
> Digging further down, both flags are set in reg.c by :
>   if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40))
>       bw_flags = IEEE80211_CHAN_NO_HT40;
>
> Indeed, at this stage, max_bandwidth_khz is 20 MHz only... Looking up in
> my syslog, I found this :
>
> [  506.036923] cfg80211: Received country IE:
> [  506.036927] cfg80211: Regulatory domain: FR
> [  506.036928]     (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [  506.036931]     (5170000 KHz - 5190000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036933]     (5190000 KHz - 5210000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036936]     (5210000 KHz - 5230000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036938]     (5230000 KHz - 5250000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036940]     (5250000 KHz - 5270000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036943]     (5270000 KHz - 5290000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036945]     (5290000 KHz - 5310000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036948]     (5310000 KHz - 5330000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036950]     (5490000 KHz - 5510000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036952]     (5510000 KHz - 5530000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036955]     (5530000 KHz - 5550000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036957]     (5550000 KHz - 5570000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036959]     (5570000 KHz - 5590000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036962]     (5590000 KHz - 5610000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036964]     (5610000 KHz - 5630000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036966]     (5630000 KHz - 5650000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036969]     (5650000 KHz - 5670000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036971]     (5670000 KHz - 5690000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
> [  506.036974]     (5690000 KHz - 5710000 KHz @ 40000 KHz), (10000 mBi,
> 10000 mBm)
>
> [  506.036975] cfg80211: CRDA thinks this should applied:
> [  506.036976] cfg80211: Regulatory domain: FR
> [  506.036978]     (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [  506.036980]     (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> [  506.036982]     (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> [  506.036984]     (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> [  506.036987]     (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
>
> [  506.036988] cfg80211: We intersect both of these and get:
> [  506.037005] cfg80211: Regulatory domain: 98
> [  506.037006]     (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [  506.037008]     (5170000 KHz - 5190000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> [  506.037011]     (5190000 KHz - 5210000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> [  506.037013]     (5210000 KHz - 5230000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> [  506.037015]     (5230000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> [  506.037017]     (5250000 KHz - 5270000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> [  506.037019]     (5270000 KHz - 5290000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> [  506.037021]     (5290000 KHz - 5310000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> [  506.037024]     (5310000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> [  506.037026]     (5490000 KHz - 5510000 KHz @ 20000 KHz), (N/A, 2700 mBm)
> [  506.037028]     (5510000 KHz - 5530000 KHz @ 20000 KHz), (N/A, 2700 mBm)
> [  506.037030]     (5530000 KHz - 5550000 KHz @ 20000 KHz), (N/A, 2700 mBm)
> [  506.037032]     (5550000 KHz - 5570000 KHz @ 20000 KHz), (N/A, 2700 mBm)
> [  506.037035]     (5570000 KHz - 5590000 KHz @ 20000 KHz), (N/A, 2700 mBm)
> [  506.037037]     (5590000 KHz - 5610000 KHz @ 20000 KHz), (N/A, 2700 mBm)
> [  506.037039]     (5610000 KHz - 5630000 KHz @ 20000 KHz), (N/A, 2700 mBm)
> [  506.037041]     (5630000 KHz - 5650000 KHz @ 20000 KHz), (N/A, 2700 mBm)
> [  506.037043]     (5650000 KHz - 5670000 KHz @ 20000 KHz), (N/A, 2700 mBm)
> [  506.037045]     (5670000 KHz - 5690000 KHz @ 20000 KHz), (N/A, 2700 mBm)
> [  506.037047]     (5690000 KHz - 5710000 KHz @ 20000 KHz), (N/A, 2700 mBm)
>
> So, at this stage, max_bandwidth_khz is indeed 20 MHz!
>
> What's the real meaning of max_bandwidth_khz? If this is just the
> difference between the upper/lower frequency of each channels, then it's
> useless. If it is a capability features saying 40 MHz channel wide are
> allowed, then it should be left to 40 MHz even if upper/lower
> frequencies are only 20 MHz apart (since the ability to use 40 MHz
> depends on the list of all frequencies, not a single frequency).

Your AP is sending a country IE channel triplet for each channel it
allows. Its the first time I see an AP do this and its good that you
report this. What AP do you have?

reg.c treats each triplet as a regulatory rule though and since you
have a rule for each channel it will restrict this to the triplet
range which is just one channel and as such 20 MHz only makes sense. A
fix would be to expand on the ht40 checks to check connecting
frequency rules.

Luis

2010-01-07 07:22:41

by Benoit Papillault

[permalink] [raw]
Subject: Re: Issue connecting to an HT40 AP that sends a Country IE

Luis R. Rodriguez a écrit :
> On Sat, Jan 2, 2010 at 10:04 AM, Luis R. Rodriguez <[email protected]> wrote:
>
>> The issue should be that a frequency rule is being created for each
>> channel and although 40 MHz is being specified as max bandwidth
>> logistically only 20 MHz fits into that frequency rule. So what the
>> intersection needs to learn is how to merge rules or at least
>> understand them together. It may be easier to parse insaneIEs like the
>> ones your AP generates and re-generate one with actual ranges with
>> contiguity channels merged. And then use that one for the
>> intersection.
>>
>
> I have a patch in mind now for this, can you please apply this patch
> on iw, scan and send me the output of the scan for your AP?
>
> Luis
>
Here is the result for the said AP :

BSS 00:15:6d:e8:88:84 (on wlan0)
TSF: 627428313658 usec (7d, 06:17:08)
freq: 5180
beacon interval: 100
capability: ESS Privacy ShortSlotTime (0x0411)
signal: -76.00 dBm
last seen: 7604 ms ago
SSID: BEN_nsm5
Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
DS Parameter set: channel 36
Country: FR Environment: Indoor only
Country IE triplets:
Channels [36 - 36]
Channels [40 - 40]
Channels [44 - 44]
Channels [48 - 48]
Channels [52 - 52]
Channels [56 - 56]
Channels [60 - 60]
Channels [64 - 64]
Channels [100 - 100]
Channels [104 - 104]
Channels [108 - 108]
Channels [112 - 112]
Channels [116 - 116]
Channels [120 - 120]
Channels [124 - 124]
Channels [128 - 128]
Channels [132 - 132]
Channels [136 - 136]
Channels [140 - 140]
Power constraint: 0 dB
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSK
* Capabilities: (0x0000)
WMM: * Parameter version 1
* u-APSD
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: acm CW 3-7, AIFSN 2, TXOP 1504 usec
HT capabilities:
Capabilities: 0x4e
HT20/HT40
SM Power Save disabled
RX HT40 SGI
No RX STBC
Max AMSDU length: 7935 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 1/2 usec (0x02)
HT RX MCS rate indexes supported: 0-15
HT TX MCS rate indexes are undefined

iw version 0.9.18-11-g89ea706-dirty

As a quick patch, I have commented 2 lines "bw_flags =
IEEE80211_CHAN_NO_HT40" in net/wireless/reg.c

I'll try to do a patch for the kernel that does the following action :
- parse the max_power field
- merge rules if the max_power field is the same for both rules
- use max_bandwidth_khz as a capability feature (ie it could be larger
than end_freq - start_freq)
- when trying to enable HT40, we might obey 2 reg rules (if they have
not been merge). In this case, we should intersect rules again.

Does this logic is fine?

Regards,
Benoit


Attachments:
country-ie-allow-ht40.diff (1.45 kB)

2010-01-07 15:43:48

by Luis R. Rodriguez

[permalink] [raw]
Subject: Re: Issue connecting to an HT40 AP that sends a Country IE

On Wed, Jan 6, 2010 at 11:22 PM, Benoit PAPILLAULT
<[email protected]> wrote:
> Luis R. Rodriguez a écrit :
>>
>> On Sat, Jan 2, 2010 at 10:04 AM, Luis R. Rodriguez <[email protected]>
>> wrote:
>>
>>>
>>> The issue should  be that a frequency rule is being created for each
>>> channel and although 40 MHz is being specified as max bandwidth
>>> logistically only 20 MHz fits into that frequency rule. So what the
>>> intersection needs to learn is how to merge rules or at least
>>> understand them together. It may be easier to parse insaneIEs like the
>>> ones your AP generates and re-generate one with actual ranges with
>>> contiguity channels merged. And then use that one for the
>>> intersection.
>>>
>>
>> I have a patch in mind now for this, can you please apply this patch
>> on iw, scan and send me the output of the scan for your AP?
>>
>>  Luis
>>
>
> Here is the result for the said AP :
>
> BSS 00:15:6d:e8:88:84 (on wlan0)
>       TSF: 627428313658 usec (7d, 06:17:08)
>       freq: 5180
>       beacon interval: 100
>       capability: ESS Privacy ShortSlotTime (0x0411)
>       signal: -76.00 dBm
>       last seen: 7604 ms ago
>       SSID: BEN_nsm5
>       Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
>       DS Parameter set: channel 36
>       Country: FR     Environment: Indoor only
>       Country IE triplets:
>               Channels [36 - 36]
>               Channels [40 - 40]
>               Channels [44 - 44]
>               Channels [48 - 48]
>               Channels [52 - 52]
>               Channels [56 - 56]
>               Channels [60 - 60]
>               Channels [64 - 64]
>               Channels [100 - 100]
>               Channels [104 - 104]
>               Channels [108 - 108]
>               Channels [112 - 112]
>               Channels [116 - 116]
>               Channels [120 - 120]
>               Channels [124 - 124]
>               Channels [128 - 128]
>               Channels [132 - 132]
>               Channels [136 - 136]
>               Channels [140 - 140]
>       Power constraint: 0 dB
>       RSN:     * Version: 1
>                * Group cipher: CCMP
>                * Pairwise ciphers: CCMP
>                * Authentication suites: PSK
>                * Capabilities: (0x0000)
>       WMM:     * Parameter version 1
>                * u-APSD
>                * BE: CW 15-1023, AIFSN 3
>                * BK: CW 15-1023, AIFSN 7
>                * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
>                * VO: acm CW 3-7, AIFSN 2, TXOP 1504 usec
>       HT capabilities:
>               Capabilities: 0x4e
>                       HT20/HT40
>                       SM Power Save disabled
>                       RX HT40 SGI
>                       No RX STBC
>                       Max AMSDU length: 7935 bytes
>                       No DSSS/CCK HT40
>               Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
>               Minimum RX AMPDU time spacing: 1/2 usec (0x02)
>               HT RX MCS rate indexes supported: 0-15
>               HT TX MCS rate indexes are undefined
>
> iw version 0.9.18-11-g89ea706-dirty
>
> As a quick patch, I have commented 2 lines "bw_flags =
> IEEE80211_CHAN_NO_HT40" in net/wireless/reg.c
>
> I'll try to do a patch for the kernel that does the following action :
> - parse the max_power field

I have this already in my queue

> - merge rules if the max_power field is the same for both rules

I also have this but I wanted to test it against your AP's IE, which
is why I asked for this output.

> - use max_bandwidth_khz as a capability feature (ie it could be larger than
>  end_freq - start_freq)

Not sure I get this.

> - when trying to enable HT40, we might obey 2 reg rules (if they have not
> been merge). In this case, we should intersect rules again.

My patch merges contiguous country IE subbands. I guess I'll post as
RFC for now.

> Does this logic is fine?

Yeah you certainly found an issue, unfortunately my patch for the
subband fix is too big for it to be considered for stable and I cannot
think of a smaller way to resolve it.

Luis

2010-01-07 21:08:38

by Benoit Papillault

[permalink] [raw]
Subject: Re: Issue connecting to an HT40 AP that sends a Country IE

Luis R. Rodriguez a écrit :
>
> Yeah you certainly found an issue, unfortunately my patch for the
> subband fix is too big for it to be considered for stable and I cannot
> think of a smaller way to resolve it.
>
> Luis
>
>
OK. You could just send your current patchset to me so I could play with
it (test it, modify it, ...). I have already some ideas on the top of my
head, so it would be better if I start something based on your code.

Regards,
Benoit


2010-01-02 09:21:30

by Benoit Papillault

[permalink] [raw]
Subject: Re: Issue connecting to an HT40 AP that sends a Country IE

Luis R. Rodriguez a écrit :
> On Fri, Jan 1, 2010 at 4:07 AM, Benoit PAPILLAULT
> <[email protected]> wrote:
>
>> Hello,
>>
>> I'd like to report an issue I have when trying to connect a laptop
>> running ath9k to a 802.11n AP in HT40 mode. What happens is that the
>> laptop cannot associate if the AP is running in HT40 mode. Association
>> is OK if the AP is running in HT20 mode. Here is an excerpt from syslog :
>>
>> [ 577.166241] wlan0: associate with AP 00:15:6d:e8:88:84 (try 1)
>> [ 577.167448] wlan0: RX AssocResp from 00:15:6d:e8:88:84 (capab=0x411
>> status=10 aid=257)
>> [ 577.167451] wlan0: AP denied association (code=10)
>> [ 577.167460] wlan0: deauthenticating from 00:15:6d:e8:88:84 by local
>> choice (reason=3)
>>
>> What's wrong is that the Associate Request (built by
>> ieee80211_send_assoc) does not set the bit in HT Capabilities IE saying
>> : "The station supports both HT20 & HT40".
>>
>> Looking into the code, it appears that both (flags &
>> IEEE80211_CHAN_NO_HT40PLUS) and (flags & IEEE80211_CHAN_NO_HT40MINUS)
>> are true, thus disabling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 which is
>> the culprit mentioned above.
>>
>> Digging further down, both flags are set in reg.c by :
>> if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40))
>> bw_flags = IEEE80211_CHAN_NO_HT40;
>>
>> Indeed, at this stage, max_bandwidth_khz is 20 MHz only... Looking up in
>> my syslog, I found this :
>>
>> [ 506.036923] cfg80211: Received country IE:
>> [ 506.036927] cfg80211: Regulatory domain: FR
>> [ 506.036928] (start_freq - end_freq @ bandwidth),
>> (max_antenna_gain, max_eirp)
>> [ 506.036931] (5170000 KHz - 5190000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036933] (5190000 KHz - 5210000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036936] (5210000 KHz - 5230000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036938] (5230000 KHz - 5250000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036940] (5250000 KHz - 5270000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036943] (5270000 KHz - 5290000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036945] (5290000 KHz - 5310000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036948] (5310000 KHz - 5330000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036950] (5490000 KHz - 5510000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036952] (5510000 KHz - 5530000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036955] (5530000 KHz - 5550000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036957] (5550000 KHz - 5570000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036959] (5570000 KHz - 5590000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036962] (5590000 KHz - 5610000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036964] (5610000 KHz - 5630000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036966] (5630000 KHz - 5650000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036969] (5650000 KHz - 5670000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036971] (5670000 KHz - 5690000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>> [ 506.036974] (5690000 KHz - 5710000 KHz @ 40000 KHz), (10000 mBi,
>> 10000 mBm)
>>
>> [ 506.036975] cfg80211: CRDA thinks this should applied:
>> [ 506.036976] cfg80211: Regulatory domain: FR
>> [ 506.036978] (start_freq - end_freq @ bandwidth),
>> (max_antenna_gain, max_eirp)
>> [ 506.036980] (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>> [ 506.036982] (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>> [ 506.036984] (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>> [ 506.036987] (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
>>
>> [ 506.036988] cfg80211: We intersect both of these and get:
>> [ 506.037005] cfg80211: Regulatory domain: 98
>> [ 506.037006] (start_freq - end_freq @ bandwidth),
>> (max_antenna_gain, max_eirp)
>> [ 506.037008] (5170000 KHz - 5190000 KHz @ 20000 KHz), (N/A, 2000 mBm)
>> [ 506.037011] (5190000 KHz - 5210000 KHz @ 20000 KHz), (N/A, 2000 mBm)
>> [ 506.037013] (5210000 KHz - 5230000 KHz @ 20000 KHz), (N/A, 2000 mBm)
>> [ 506.037015] (5230000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 2000 mBm)
>> [ 506.037017] (5250000 KHz - 5270000 KHz @ 20000 KHz), (N/A, 2000 mBm)
>> [ 506.037019] (5270000 KHz - 5290000 KHz @ 20000 KHz), (N/A, 2000 mBm)
>> [ 506.037021] (5290000 KHz - 5310000 KHz @ 20000 KHz), (N/A, 2000 mBm)
>> [ 506.037024] (5310000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 2000 mBm)
>> [ 506.037026] (5490000 KHz - 5510000 KHz @ 20000 KHz), (N/A, 2700 mBm)
>> [ 506.037028] (5510000 KHz - 5530000 KHz @ 20000 KHz), (N/A, 2700 mBm)
>> [ 506.037030] (5530000 KHz - 5550000 KHz @ 20000 KHz), (N/A, 2700 mBm)
>> [ 506.037032] (5550000 KHz - 5570000 KHz @ 20000 KHz), (N/A, 2700 mBm)
>> [ 506.037035] (5570000 KHz - 5590000 KHz @ 20000 KHz), (N/A, 2700 mBm)
>> [ 506.037037] (5590000 KHz - 5610000 KHz @ 20000 KHz), (N/A, 2700 mBm)
>> [ 506.037039] (5610000 KHz - 5630000 KHz @ 20000 KHz), (N/A, 2700 mBm)
>> [ 506.037041] (5630000 KHz - 5650000 KHz @ 20000 KHz), (N/A, 2700 mBm)
>> [ 506.037043] (5650000 KHz - 5670000 KHz @ 20000 KHz), (N/A, 2700 mBm)
>> [ 506.037045] (5670000 KHz - 5690000 KHz @ 20000 KHz), (N/A, 2700 mBm)
>> [ 506.037047] (5690000 KHz - 5710000 KHz @ 20000 KHz), (N/A, 2700 mBm)
>>
>> So, at this stage, max_bandwidth_khz is indeed 20 MHz!
>>
>> What's the real meaning of max_bandwidth_khz? If this is just the
>> difference between the upper/lower frequency of each channels, then it's
>> useless. If it is a capability features saying 40 MHz channel wide are
>> allowed, then it should be left to 40 MHz even if upper/lower
>> frequencies are only 20 MHz apart (since the ability to use 40 MHz
>> depends on the list of all frequencies, not a single frequency).
>>
>
> Your AP is sending a country IE channel triplet for each channel it
> allows. Its the first time I see an AP do this and its good that you
> report this. What AP do you have?
>
> reg.c treats each triplet as a regulatory rule though and since you
> have a rule for each channel it will restrict this to the triplet
> range which is just one channel and as such 20 MHz only makes sense. A
> fix would be to expand on the ht40 checks to check connecting
> frequency rules.
>
> Luis
>
Hello,

My AP is a NanoStation M5 configured with Country "FR" and 40 MHz.

Could you detail the fix you are proposing?

On my side, I would propose to leave max_bandwidth_khz to 40 MHz and use
it as a capability features. This way we would consider valid the case
where upper/lower frequencies are just 20 MHz apart but
max_bandwidth_khz is 40 MHz.

Regards,
Benoit


2010-01-07 01:39:24

by Luis R. Rodriguez

[permalink] [raw]
Subject: Re: Issue connecting to an HT40 AP that sends a Country IE

On Sat, Jan 2, 2010 at 10:04 AM, Luis R. Rodriguez <[email protected]> wrote:
> On Sat, Jan 2, 2010 at 4:21 AM, Benoit PAPILLAULT
> <[email protected]> wrote:
>> Luis R. Rodriguez a écrit :
>>>
>>> On Fri, Jan 1, 2010 at 4:07 AM, Benoit PAPILLAULT
>>> <[email protected]> wrote:
>>>
>>>>
>>>> Hello,
>>>>
>>>> I'd like to report an issue I have when trying to connect a laptop
>>>> running ath9k to a 802.11n AP in HT40 mode. What happens is that the
>>>> laptop cannot associate if the AP is running in HT40 mode. Association
>>>> is OK if the AP is running in HT20 mode. Here is an excerpt from syslog :
>>>>
>>>> [  577.166241] wlan0: associate with AP 00:15:6d:e8:88:84 (try 1)
>>>> [  577.167448] wlan0: RX AssocResp from 00:15:6d:e8:88:84 (capab=0x411
>>>> status=10 aid=257)
>>>> [  577.167451] wlan0: AP denied association (code=10)
>>>> [  577.167460] wlan0: deauthenticating from 00:15:6d:e8:88:84 by local
>>>> choice (reason=3)
>>>>
>>>> What's wrong is that the Associate Request (built by
>>>> ieee80211_send_assoc) does not set the bit in HT Capabilities IE saying
>>>> : "The station supports both HT20 & HT40".
>>>>
>>>> Looking into the code, it appears that both (flags &
>>>> IEEE80211_CHAN_NO_HT40PLUS) and (flags & IEEE80211_CHAN_NO_HT40MINUS)
>>>> are true, thus disabling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 which is
>>>> the culprit mentioned above.
>>>>
>>>> Digging further down, both flags are set in reg.c by :
>>>>  if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40))
>>>>      bw_flags = IEEE80211_CHAN_NO_HT40;
>>>>
>>>> Indeed, at this stage, max_bandwidth_khz is 20 MHz only... Looking up in
>>>> my syslog, I found this :
>>>>
>>>> [  506.036923] cfg80211: Received country IE:
>>>> [  506.036927] cfg80211: Regulatory domain: FR
>>>> [  506.036928]     (start_freq - end_freq @ bandwidth),
>>>> (max_antenna_gain, max_eirp)
>>>> [  506.036931]     (5170000 KHz - 5190000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036933]     (5190000 KHz - 5210000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036936]     (5210000 KHz - 5230000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036938]     (5230000 KHz - 5250000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036940]     (5250000 KHz - 5270000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036943]     (5270000 KHz - 5290000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036945]     (5290000 KHz - 5310000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036948]     (5310000 KHz - 5330000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036950]     (5490000 KHz - 5510000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036952]     (5510000 KHz - 5530000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036955]     (5530000 KHz - 5550000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036957]     (5550000 KHz - 5570000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036959]     (5570000 KHz - 5590000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036962]     (5590000 KHz - 5610000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036964]     (5610000 KHz - 5630000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036966]     (5630000 KHz - 5650000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036969]     (5650000 KHz - 5670000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036971]     (5670000 KHz - 5690000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>> [  506.036974]     (5690000 KHz - 5710000 KHz @ 40000 KHz), (10000 mBi,
>>>> 10000 mBm)
>>>>
>>>> [  506.036975] cfg80211: CRDA thinks this should applied:
>>>> [  506.036976] cfg80211: Regulatory domain: FR
>>>> [  506.036978]     (start_freq - end_freq @ bandwidth),
>>>> (max_antenna_gain, max_eirp)
>>>> [  506.036980]     (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000
>>>> mBm)
>>>> [  506.036982]     (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000
>>>> mBm)
>>>> [  506.036984]     (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000
>>>> mBm)
>>>> [  506.036987]     (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700
>>>> mBm)
>>>>
>>>> [  506.036988] cfg80211: We intersect both of these and get:
>>>> [  506.037005] cfg80211: Regulatory domain: 98
>>>> [  506.037006]     (start_freq - end_freq @ bandwidth),
>>>> (max_antenna_gain, max_eirp)
>>>> [  506.037008]     (5170000 KHz - 5190000 KHz @ 20000 KHz), (N/A, 2000
>>>> mBm)
>>>> [  506.037011]     (5190000 KHz - 5210000 KHz @ 20000 KHz), (N/A, 2000
>>>> mBm)
>>>> [  506.037013]     (5210000 KHz - 5230000 KHz @ 20000 KHz), (N/A, 2000
>>>> mBm)
>>>> [  506.037015]     (5230000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 2000
>>>> mBm)
>>>> [  506.037017]     (5250000 KHz - 5270000 KHz @ 20000 KHz), (N/A, 2000
>>>> mBm)
>>>> [  506.037019]     (5270000 KHz - 5290000 KHz @ 20000 KHz), (N/A, 2000
>>>> mBm)
>>>> [  506.037021]     (5290000 KHz - 5310000 KHz @ 20000 KHz), (N/A, 2000
>>>> mBm)
>>>> [  506.037024]     (5310000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 2000
>>>> mBm)
>>>> [  506.037026]     (5490000 KHz - 5510000 KHz @ 20000 KHz), (N/A, 2700
>>>> mBm)
>>>> [  506.037028]     (5510000 KHz - 5530000 KHz @ 20000 KHz), (N/A, 2700
>>>> mBm)
>>>> [  506.037030]     (5530000 KHz - 5550000 KHz @ 20000 KHz), (N/A, 2700
>>>> mBm)
>>>> [  506.037032]     (5550000 KHz - 5570000 KHz @ 20000 KHz), (N/A, 2700
>>>> mBm)
>>>> [  506.037035]     (5570000 KHz - 5590000 KHz @ 20000 KHz), (N/A, 2700
>>>> mBm)
>>>> [  506.037037]     (5590000 KHz - 5610000 KHz @ 20000 KHz), (N/A, 2700
>>>> mBm)
>>>> [  506.037039]     (5610000 KHz - 5630000 KHz @ 20000 KHz), (N/A, 2700
>>>> mBm)
>>>> [  506.037041]     (5630000 KHz - 5650000 KHz @ 20000 KHz), (N/A, 2700
>>>> mBm)
>>>> [  506.037043]     (5650000 KHz - 5670000 KHz @ 20000 KHz), (N/A, 2700
>>>> mBm)
>>>> [  506.037045]     (5670000 KHz - 5690000 KHz @ 20000 KHz), (N/A, 2700
>>>> mBm)
>>>> [  506.037047]     (5690000 KHz - 5710000 KHz @ 20000 KHz), (N/A, 2700
>>>> mBm)
>>>>
>>>> So, at this stage, max_bandwidth_khz is indeed 20 MHz!
>>>>
>>>> What's the real meaning of max_bandwidth_khz? If this is just the
>>>> difference between the upper/lower frequency of each channels, then it's
>>>> useless. If it is a capability features saying 40 MHz channel wide are
>>>> allowed, then it should be left to 40 MHz even if upper/lower
>>>> frequencies are only 20 MHz apart (since the ability to use 40 MHz
>>>> depends on the list of all frequencies, not a single frequency).
>>>>
>>>
>>> Your AP is sending a country IE channel triplet for each channel it
>>> allows. Its the first time I see an AP do this and its good that you
>>> report this. What AP do you have?
>>>
>>> reg.c treats each triplet as a regulatory rule though and since you
>>> have a rule for each channel it will restrict this to the triplet
>>> range which is just one channel and as such 20 MHz only makes sense. A
>>> fix would be to expand on the ht40 checks to check connecting
>>> frequency rules.
>>>
>>>  Luis
>>>
>>
>> Hello,
>>
>> My AP is a NanoStation M5 configured with Country "FR" and 40 MHz.
>>
>> Could you detail the fix you are proposing?
>>
>> On my side, I would propose to leave max_bandwidth_khz to 40 MHz and use it
>> as a capability features.
>
> Since the country IE does not have a max bandwidth we stuff a default
> 40 MHz to it as part of the frequency rule it creates.
>
>> This way we would consider valid the case where
>> upper/lower frequencies are just 20 MHz apart but max_bandwidth_khz is 40
>> MHz.
>
> The issue should  be that a frequency rule is being created for each
> channel and although 40 MHz is being specified as max bandwidth
> logistically only 20 MHz fits into that frequency rule. So what the
> intersection needs to learn is how to merge rules or at least
> understand them together. It may be easier to parse insaneIEs like the
> ones your AP generates and re-generate one with actual ranges with
> contiguity channels merged. And then use that one for the
> intersection.

I have a patch in mind now for this, can you please apply this patch
on iw, scan and send me the output of the scan for your AP?

Luis


Attachments:
country-IE-new.patch (2.99 kB)