linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benoit PAPILLAULT <benoit.papillault@free.fr>
To: "Luis R. Rodriguez" <mcgrof@gmail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: Issue connecting to an HT40 AP that sends a Country IE
Date: Thu, 07 Jan 2010 08:22:36 +0100	[thread overview]
Message-ID: <4B458BBC.6040200@free.fr> (raw)
In-Reply-To: <43e72e891001061739t5ded13e7u6b16c73f1b26b246@mail.gmail.com>

[-- 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 = &reg_rule->power_rule;
 	freq_range = &reg_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 = &reg_rule->power_rule;
 	freq_range = &reg_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);

  reply	other threads:[~2010-01-07  7:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2010-01-07 15:43           ` Luis R. Rodriguez
2010-01-07 21:08             ` Benoit PAPILLAULT

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B458BBC.6040200@free.fr \
    --to=benoit.papillault@free.fr \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mcgrof@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).