* Issue connecting to an HT40 AP that sends a Country IE
@ 2010-01-01 9:07 Benoit PAPILLAULT
2010-01-01 23:24 ` Luis R. Rodriguez
0 siblings, 1 reply; 8+ messages in thread
From: Benoit PAPILLAULT @ 2010-01-01 9:07 UTC (permalink / raw)
To: linux-wireless
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 ...
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issue connecting to an HT40 AP that sends a Country IE
2010-01-01 9:07 Issue connecting to an HT40 AP that sends a Country IE Benoit PAPILLAULT
@ 2010-01-01 23:24 ` Luis R. Rodriguez
2010-01-02 9:21 ` Benoit PAPILLAULT
0 siblings, 1 reply; 8+ messages in thread
From: Luis R. Rodriguez @ 2010-01-01 23:24 UTC (permalink / raw)
To: Benoit PAPILLAULT; +Cc: linux-wireless
On Fri, Jan 1, 2010 at 4:07 AM, Benoit PAPILLAULT
<benoit.papillault@free.fr> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issue connecting to an HT40 AP that sends a Country IE
2010-01-01 23:24 ` Luis R. Rodriguez
@ 2010-01-02 9:21 ` Benoit PAPILLAULT
2010-01-02 18:04 ` Luis R. Rodriguez
0 siblings, 1 reply; 8+ messages in thread
From: Benoit PAPILLAULT @ 2010-01-02 9:21 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
Luis R. Rodriguez a écrit :
> On Fri, Jan 1, 2010 at 4:07 AM, Benoit PAPILLAULT
> <benoit.papillault@free.fr> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issue connecting to an HT40 AP that sends a Country IE
2010-01-02 9:21 ` Benoit PAPILLAULT
@ 2010-01-02 18:04 ` Luis R. Rodriguez
2010-01-07 1:39 ` Luis R. Rodriguez
0 siblings, 1 reply; 8+ messages in thread
From: Luis R. Rodriguez @ 2010-01-02 18:04 UTC (permalink / raw)
To: Benoit PAPILLAULT; +Cc: linux-wireless
On Sat, Jan 2, 2010 at 4:21 AM, Benoit PAPILLAULT
<benoit.papillault@free.fr> wrote:
> Luis R. Rodriguez a écrit :
>>
>> On Fri, Jan 1, 2010 at 4:07 AM, Benoit PAPILLAULT
>> <benoit.papillault@free.fr> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issue connecting to an HT40 AP that sends a Country IE
2010-01-02 18:04 ` Luis R. Rodriguez
@ 2010-01-07 1:39 ` Luis R. Rodriguez
2010-01-07 7:22 ` Benoit PAPILLAULT
0 siblings, 1 reply; 8+ messages in thread
From: Luis R. Rodriguez @ 2010-01-07 1:39 UTC (permalink / raw)
To: Benoit PAPILLAULT; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 8563 bytes --]
On Sat, Jan 2, 2010 at 10:04 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Sat, Jan 2, 2010 at 4:21 AM, Benoit PAPILLAULT
> <benoit.papillault@free.fr> wrote:
>> Luis R. Rodriguez a écrit :
>>>
>>> On Fri, Jan 1, 2010 at 4:07 AM, Benoit PAPILLAULT
>>> <benoit.papillault@free.fr> 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
[-- Attachment #2: country-IE-new.patch --]
[-- Type: text/x-patch, Size: 3064 bytes --]
From 8831fd67d70b7af2f37f830d5e0f04d14f8470aa Mon Sep 17 00:00:00 2001
From: Luis R. Rodriguez <lrodriguez@atheros.com>
Date: Wed, 6 Jan 2010 17:36:59 -0800
Subject: [PATCH] iw: add country IE parsing
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
scan.c | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++------------
1 files changed, 70 insertions(+), 17 deletions(-)
diff --git a/scan.c b/scan.c
index 308d499..f70d42c 100644
--- a/scan.c
+++ b/scan.c
@@ -35,6 +35,23 @@ struct scan_params {
enum print_ie_type type;
};
+#define IEEE80211_COUNTRY_EXTENSION_ID 201
+
+struct ieee80211_country_ie_triplet {
+ union {
+ struct {
+ __u8 first_channel;
+ __u8 num_channels;
+ __s8 max_power;
+ } __attribute__ ((packed)) chans;
+ struct {
+ __u8 reg_extension_id;
+ __u8 reg_class;
+ __u8 coverage_class;
+ } __attribute__ ((packed)) ext;
+ };
+} __attribute__ ((packed));
+
static int handle_scan(struct nl80211_state *state,
struct nl_cb *cb,
struct nl_msg *msg,
@@ -142,29 +159,65 @@ static void print_ds(const uint8_t type, uint8_t len, const uint8_t *data)
printf(" channel %d\n", data[0]);
}
-static void print_country(const uint8_t type, uint8_t len, const uint8_t *data)
+static const char *country_env_str(char environment)
{
- int i;
-
- printf(" %.*s", 2, data);
- switch (data[2]) {
+ switch (environment) {
case 'I':
- printf(" (indoor)");
- break;
+ return "Indoor only";
case 'O':
- printf(" (outdoor)");
- break;
+ return "Outdoor only";
case ' ':
- printf(" (in/outdoor)");
- break;
+ return "Indoor/Outdoor";
default:
- printf(" (invalid environment)");
- break;
+ return "bogus";
}
- printf(", data:");
- for(i=0; i<len-3; i++)
- printf(" %.02x", data[i + 3]);
- printf("\n");
+}
+
+static void print_country(const uint8_t type, uint8_t len, const uint8_t *data)
+{
+ printf(" %.*s", 2, data);
+
+ printf("\tEnvironment: %s\n", country_env_str(data[2]));
+
+ data += 3;
+ len -= 3;
+
+ if (len < 3) {
+ printf("\t\tNo country IE triplets present\n");
+ return;
+ }
+
+ printf("\tCountry IE triplets:\n");
+
+ while (len >= 3) {
+ int end_channel;
+ struct ieee80211_country_ie_triplet *triplet =
+ (struct ieee80211_country_ie_triplet *) data;
+
+ if (triplet->ext.reg_extension_id >= IEEE80211_COUNTRY_EXTENSION_ID) {
+ printf("\t\tExtension ID: %d Regulatory Class: %d Coverage class: %d\n",
+ triplet->ext.reg_extension_id,
+ triplet->ext.reg_class,
+ triplet->ext.coverage_class);
+
+ data += 3;
+ len -= 3;
+ continue;
+ }
+
+ /* 2 GHz */
+ if (triplet->chans.first_channel <= 14)
+ end_channel = triplet->chans.first_channel + (triplet->chans.num_channels - 1);
+ else
+ end_channel = triplet->chans.first_channel + (4 * (triplet->chans.num_channels - 1));
+
+ printf("\t\tChannels [%d - %d]\n", triplet->chans.first_channel, end_channel);
+
+ data += 3;
+ len -= 3;
+ }
+
+ return;
}
static void print_powerconstraint(const uint8_t type, uint8_t len, const uint8_t *data)
--
1.6.3.3
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: Issue connecting to an HT40 AP that sends a Country IE
2010-01-07 1:39 ` Luis R. Rodriguez
@ 2010-01-07 7:22 ` Benoit PAPILLAULT
2010-01-07 15:43 ` Luis R. Rodriguez
0 siblings, 1 reply; 8+ messages in thread
From: Benoit PAPILLAULT @ 2010-01-07 7:22 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 3564 bytes --]
Luis R. Rodriguez a écrit :
> On Sat, Jan 2, 2010 at 10:04 AM, Luis R. Rodriguez <mcgrof@gmail.com> 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
[-- Attachment #2: country-ie-allow-ht40.diff --]
[-- Type: text/x-patch, Size: 1488 bytes --]
commit b716fd7e8506eaff946f1429f048c258a03249ba
Author: Benoit Papillault <benoit.papillault@free.fr>
Date: Thu Dec 31 10:58:14 2009 +0100
mac80211: quick fix to allow HT40 with a country IE
This patch fixes an issue to connect to an HT40 AP sending country IE for
all channels. Doing this way, each channel is 20 MHz only and as such, current
code would disallow HT40 operation. This can be seen in ht40allow_map
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 87ea60d..bb141c8 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -999,10 +999,10 @@ static void handle_channel(struct wiphy *wiphy, enum ieee80211_band band,
power_rule = ®_rule->power_rule;
freq_range = ®_rule->freq_range;
-
+ /*
if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40))
bw_flags = IEEE80211_CHAN_NO_HT40;
-
+ */
if (last_request->initiator == NL80211_REGDOM_SET_BY_DRIVER &&
request_wiphy && request_wiphy == wiphy &&
request_wiphy->flags & WIPHY_FLAG_STRICT_REGULATORY) {
@@ -1318,10 +1318,10 @@ static void handle_channel_custom(struct wiphy *wiphy,
power_rule = ®_rule->power_rule;
freq_range = ®_rule->freq_range;
-
+ /*
if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40))
bw_flags = IEEE80211_CHAN_NO_HT40;
-
+ */
chan->flags |= map_regdom_flags(reg_rule->flags) | bw_flags;
chan->max_antenna_gain = (int) MBI_TO_DBI(power_rule->max_antenna_gain);
chan->max_power = (int) MBM_TO_DBM(power_rule->max_eirp);
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: Issue connecting to an HT40 AP that sends a Country IE
2010-01-07 7:22 ` Benoit PAPILLAULT
@ 2010-01-07 15:43 ` Luis R. Rodriguez
2010-01-07 21:08 ` Benoit PAPILLAULT
0 siblings, 1 reply; 8+ messages in thread
From: Luis R. Rodriguez @ 2010-01-07 15:43 UTC (permalink / raw)
To: Benoit PAPILLAULT; +Cc: linux-wireless
On Wed, Jan 6, 2010 at 11:22 PM, Benoit PAPILLAULT
<benoit.papillault@free.fr> wrote:
> Luis R. Rodriguez a écrit :
>>
>> On Sat, Jan 2, 2010 at 10:04 AM, Luis R. Rodriguez <mcgrof@gmail.com>
>> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issue connecting to an HT40 AP that sends a Country IE
2010-01-07 15:43 ` Luis R. Rodriguez
@ 2010-01-07 21:08 ` Benoit PAPILLAULT
0 siblings, 0 replies; 8+ messages in thread
From: Benoit PAPILLAULT @ 2010-01-07 21:08 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-01-07 21:08 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-01 9:07 Issue connecting to an HT40 AP that sends a Country IE Benoit PAPILLAULT
2010-01-01 23:24 ` Luis R. Rodriguez
2010-01-02 9:21 ` Benoit PAPILLAULT
2010-01-02 18:04 ` Luis R. Rodriguez
2010-01-07 1:39 ` Luis R. Rodriguez
2010-01-07 7:22 ` Benoit PAPILLAULT
2010-01-07 15:43 ` Luis R. Rodriguez
2010-01-07 21:08 ` Benoit PAPILLAULT
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).