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