Return-path: Received: from mail-iw0-f171.google.com ([209.85.223.171]:55227 "EHLO mail-iw0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751064Ab0ABSEt convert rfc822-to-8bit (ORCPT ); Sat, 2 Jan 2010 13:04:49 -0500 Received: by iwn1 with SMTP id 1so10046204iwn.33 for ; Sat, 02 Jan 2010 10:04:48 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4B3F1010.3070906@free.fr> References: <4B3DBB6B.4010107@free.fr> <43e72e891001011524r190950c8pdfc89e765afb205d@mail.gmail.com> <4B3F1010.3070906@free.fr> From: "Luis R. Rodriguez" Date: Sat, 2 Jan 2010 13:04:28 -0500 Message-ID: <43e72e891001021004r2c9cf855p52b007a88123bba7@mail.gmail.com> Subject: Re: Issue connecting to an HT40 AP that sends a Country IE To: Benoit PAPILLAULT Cc: linux-wireless@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Sat, Jan 2, 2010 at 4:21 AM, Benoit PAPILLAULT wrote: > Luis R. Rodriguez a écrit : >> >> On Fri, Jan 1, 2010 at 4:07 AM, Benoit PAPILLAULT >> 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