On 05/11/12 08:17, Greg KH wrote:
> On Sat, Nov 03, 2012 at 07:52:20PM +0000, Eddie Chapman wrote:
>> On 3.6.5 my rt2800usb adapter's speeds (measured downloading a file
>> on the my LAN with wget) dropped down to around 900 Kbyte/s from the
>> usual approx. 4 Mbyte/s. Also some packet loss and latency spikes.
>> Nothing unusual reported in dmesg.
>>
>> Rebooting back into 3.6.4 with identical .config and the problem goes away.
>>
>> So I reversed the following 4 patches introduced in 3.6.5:
>>
>> Felix Fietkau:
>> mac80211: use ieee80211_free_txskb in a few more places
>>
>> Johannes Berg:
>> mac80211: connect with HT20 if HT40 is not permitted
>>
>> Stanislaw Gruszka:
>> mac80211: check if key has TKIP type before updating IV
>> cfg80211/mac80211: avoid state mishmash on deauth
>>
>> rebuilt 3.6.5, rebooted into it, and speeds back to normal.
>>
>> Sorry can't be more specific, didn't have enough time to revert each
>> one individually to find out which one caused the regression.
>> Though if anyone would really like me to find out let me know.
>
> I would, if you could narrow this down to one patch, that would be
> great.
>
> Also, copying the wireless developers on the email about this, would be
> best, there's nothing that the stable tree developers can do about this
> on their own.
>
> And, can you also test 3.7-rc4, to ensure that the problem isn't there
> as well?
>
> thanks,
>
> greg k-h
Thanks Greg.
I've narrowed it down to this patch which introduces the problem:
Johannes Berg:
mac80211: connect with HT20 if HT40 is not permitted
commit: 3a40414f826a8f1096d9b94c4a53ef91b25ba28d
The other 3 patches above give me no problems at all, so I am now
running my 3.6.5 with those 3 back in, and just the HT20/HT40 patch
removed, and throughput is perfect. As soon as I introduce the patch
HT20/HT40 throughput drops right down to a fifth of what it was.
So I've copied into this message the original people from the HT20/HT40
patch as well as linux-wireless.
This is my original message in full sent to stable list for the benefit
of the new recipients:
http://www.mail-archive.com/[email protected]/msg22645.html
If I can do anything else to help figure out why this patch causes
problems for my device, please let me know.
thanks,
Eddie
On 05/11/12 12:01, Johannes Berg wrote:
> On Mon, 2012-11-05 at 11:04 +0000, Eddie Chapman wrote:
>
>>> And, can you also test 3.7-rc4, to ensure that the problem isn't there
>>> as well?
>
>
>> I've narrowed it down to this patch which introduces the problem:
>>
>> Johannes Berg:
>> mac80211: connect with HT20 if HT40 is not permitted
>> commit: 3a40414f826a8f1096d9b94c4a53ef91b25ba28d
>>
>> The other 3 patches above give me no problems at all, so I am now
>> running my 3.6.5 with those 3 back in, and just the HT20/HT40 patch
>> removed, and throughput is perfect. As soon as I introduce the patch
>> HT20/HT40 throughput drops right down to a fifth of what it was.
>
> This should also be the case on 3.7-rc4, since the patch came from
> there, and I don't see any reason to believe rt2800 would behave
> differently here, for some reason.
>
> Can you show me the contents of
> the /sys/kernel/debug/ieee80211/phy0/ht40allow_map debugfs file and "iw
> reg get" command?
>
> johannes
Hi Johannes,
Here is the output of /sys/kernel/debug/ieee80211/phy0/ht40allow_map:
2412 HT40 +
2417 HT40 +
2422 HT40 +
2427 HT40 +
2432 HT40 -+
2437 HT40 -+
2442 HT40 -+
2447 HT40 -
2452 HT40 -
2457 HT40 -
2462 HT40 -
2467 HT40
2472 HT40
2484 HT40
and "iw reg get" says:
country 00:
(2402 - 2472 @ 40), (6, 20)
(2457 - 2482 @ 20), (6, 20), PASSIVE-SCAN, NO-IBSS
(2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS
(5170 - 5250 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS
(5735 - 5835 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS
(57240 - 63720 @ 2160), (N/A, 0)
I captured both of these with the HT20/HT40 patch applied.
let me know if you need anything else.
thanks,
Eddie
On Tue, Nov 06, 2012 at 09:31:34PM +0100, Johannes Berg wrote:
> On Tue, 2012-11-06 at 19:35 +0000, Eddie Chapman wrote:
>
> > > Right, we're still looking at that. It seems that it's not an ideal
> > > solution, the regulatory change I proposed is probably better. Could you
> > > check if it helps as well? That is, remove this patch, and apply this
> > > one: http://p.sipsolutions.net/8877cbe3440d94b1.txt
> >
> > OK, so I've removed 0129f39c7d882289.txt, applied 8877cbe3440d94b1.txt,
> > and I've kept 3a40414f826a8f1096d9b94c4a53ef91b25ba28d applied.
> >
> > Rebooted, and happy to report throughput is still good, so
> > 8877cbe3440d94b1.txt also "fixes" it for me.
>
> Great, thanks. I'm not really sure which one to apply, and if we apply
> the 8877 one we'll also want to update the reg db (that you aren't
> using). A lot of people are in Barcelona right now though, so that might
> be a week or so until we can close this.
I'm in Barcelona all this week, but a nice summary of what I'm supposed
to do here for the stable tree would be great to have when ever you
figure it out, don't wait for me to return, my email queues up just fine :)
thanks,
greg k-h
Hi Eddie,
> Here is the output of /sys/kernel/debug/ieee80211/phy0/ht40allow_map:
Ok, thanks.
> 2412 HT40 +
> 2417 HT40 +
> 2422 HT40 +
> 2427 HT40 +
> 2432 HT40 -+
> 2437 HT40 -+
> 2442 HT40 -+
> 2447 HT40 -
> 2452 HT40 -
> 2457 HT40 -
> 2462 HT40 -
> 2467 HT40
> 2472 HT40
> 2484 HT40
That looks correct.
> and "iw reg get" says:
>
> country 00:
> (2402 - 2472 @ 40), (6, 20)
> (2457 - 2482 @ 20), (6, 20), PASSIVE-SCAN, NO-IBSS
> (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS
> (5170 - 5250 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS
> (5735 - 5835 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS
> (57240 - 63720 @ 2160), (N/A, 0)
That also looks fine.
> I captured both of these with the HT20/HT40 patch applied.
Ok, that shouldn't change anything in this case, but good to know.
> let me know if you need anything else.
Yeah, I forgot to ask about the AP. Can you show the output of "iw wlan0
scan dump" for your AP while you're connected? It should show something
like this (note the "associated" indication):
BSS 02:00:00:00:00:00 (on wlan1) -- associated
TSF: 1352188517669470 usec (15650d, 07:55:17)
freq: 2432
[...]
I'm particularly interested in the "freq" (as above) and the HT
capabilities/operation information.
johannes
On Tue, 2012-11-06 at 17:39 +0100, Johannes Berg wrote:
> On Tue, 2012-11-06 at 16:54 +0100, Johannes Berg wrote:
>
> > > BSS 82:e1:fa:1a:65:00 (on wlan0) -- associated
> > [...]
> > > HT operation:
> > > * primary channel: 9
> > > * secondary channel offset: above
> >
> > As you can see, it's using HT40+ on channel 9 (2452 MHz). Your HT40
> > allow (correctly) map showed:
> >
> > 2452 HT40 -
> >
> > This is because HT40+ isn't actually allowed on channel 9 by the
> > standard (cf. 802.11-2012 Table E-1 (US), E-2 (Europe), E-3 (Japan).
>
> Oops, no, that is obviously wrong. This is permitted outside the US, and
> that is reflected in those tables as well (I was confused). However,
> your AP isn't transmitting any info on where it is, and your device is
> set up for world roaming (country is "00" rather than a real country).
> Thus, channel 13 isn't allowed and you can't do HT40+ on channel 9.
Here's another idea. I'm not sure if you're running CRDA, but you could
try this patch:
http://p.sipsolutions.net/8877cbe3440d94b1.txt
and see if "iw reg get" changes like this:
country 00:
(2402 - 2472 @ 40), (6, 20)
- (2457 - 2482 @ 20), (6, 20), PASSIVE-SCAN, NO-IBSS
+ (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS
(2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS
(5170 - 5250 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS
(5735 - 5835 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS
(57240 - 63720 @ 2160), (N/A, 0)
If yes, then your problem will likely go away, if no you'd need an
updated regulatory database for CRDA. +Luis, what do you think?
johannes
On 06/11/12 16:57, Johannes Berg wrote:
> On Tue, 2012-11-06 at 17:55 +0100, Johannes Berg wrote:
>> Hi Eddie,
>>
>>> In the AP's dmesg output which I included in my other message, I see this:
>>>
>>> <6>[ 9.300000] cfg80211: Regulatory domain changed to country: GB
>>>
>>> So it seems the AP knows where it is, but is it not transmitting that to
>>> the client?
>>
>> Evidently, I don't see a country IE in the iw scan output you posted.
>
> Then again, what version of iw do you have? This only applies if it's
> version 0.9.20 or higher.
>
> johannes
I don't see a country specified in the output I sent you either. We're
talking about iw scan on the client right, not the AP?
Over on the AP, I just looked in the web interface, and there is a drop
down box for "Regulatory Domain", and I have it set to "United Kingdom".
as for iw version on the client it says:
nc6400 ~ # iw --version
iw version 3.3
You mentioned crda, it seems gentoo has it, I can install it on the
client if you think it will help in figuring this out?
nc6400 ~ # emerge --search crda
Searching...
[ Results for search key : crda ]
[ Applications found : 1 ]
* net-wireless/crda
Latest version available: 1.1.2-r3
Latest version installed: [ Not Installed ]
Size of files: 21 kB
Homepage: http://wireless.kernel.org/en/developers/Regulatory
Description: Central Regulatory Domain Agent for wireless networks.
License: as-is
On 06/11/12 15:54, Johannes Berg wrote:
> The problem here is that some devices (notably iwlwifi) will not allow
> (by firmware) to connect to such an AP as HT40- if that is not allowed.
> So I prevented it generally, but we can make it device dependent. I
> don't like it much, but I suppose we can do it. Try this patch:
>
> http://p.sipsolutions.net/0129f39c7d882289.txt
>
> It will still prohibit this configuration when the driver said it's not
> allowed, but will allow it when there were other reasons to not allow
> it.
Just to report, with the patch under discussion re-applied
(3a40414f826a8f1096d9b94c4a53ef91b25ba28d), plus the patch at your link
above, my throughput is back to normal again.
So I guess the above patch resolves the issue (on the face of it) for
me, but whether it is a suitable solution I've no idea.
Eddie
On Wed, Nov 07, 2012 at 08:53:34AM +0100, Johannes Berg wrote:
> On Wed, 2012-11-07 at 08:36 +0100, Greg KH wrote:
>
> > > Great, thanks. I'm not really sure which one to apply, and if we apply
> > > the 8877 one we'll also want to update the reg db (that you aren't
> > > using). A lot of people are in Barcelona right now though, so that might
> > > be a week or so until we can close this.
> >
> > I'm in Barcelona all this week, but a nice summary of what I'm supposed
> > to do here for the stable tree would be great to have when ever you
> > figure it out, don't wait for me to return, my email queues up just fine :)
>
> Sure :)
> So first of all, I'm sure (even without Eddie having tested it) that the
> bug affects 3.7-rc as well, not just 3.6 stable, since the same patch
> was applied there. Therefore, we're looking for a fix for that as well.
>
> There are two possible fixes (that I can think of right now), both of
> which Eddie tested.
>
> One is a change to my old change, to make it only adhere to the
> regulatory rules that the *driver* asked for, which will still fix the
> iwlwifi problem of crashing the firmware in situations like Eddie's.
> However, it's a bit strange to be ignoring our regulatory rules.
>
> The other fix is a relaxation of the regulatory rules to allow 40 MHz
> operation involving channels 12 and 13 (like in Eddie's setup, where
> channel 9 HT40+ is used, which means the effective channel spans from
> the bottom of channel 6 to the top of channel 13.) This seems like a
> much cleaner solution, but the change needs to be done in two places
> (both the kernel's idea of the "world roaming" regulatory domain, and
> userspace's).
>
> I prefer the second fix, but want to run it by somebody more familiar
> with regulatory rules.
>
> Ultimately, I'll apply either one for 3.7, and tag it with Cc stable.
Wonderful, thanks for the summary, and the work on this, I'll just take
it through the normal cc: stable process.
greg k-h
Hi Eddie,
> The AP is a Netgear WNR2000v3 running DD-WRT v24-sp2 (03/19/12) std.
>
> After sshing into it and playing around with the iw command, the phy is
> phy0 and the device is ath0.
>
> "iw ath0 scan dump" returns nothing unfortunately.
Yeah, sorry, I guess I confused you. I did want this info from the
client, as you provided:
> In case it helps, on the laptop (the client) I do get output from "iw
> wlan0 scan dump":
>
> BSS 82:e1:fa:1a:65:00 (on wlan0) -- associated
[...]
> HT operation:
> * primary channel: 9
> * secondary channel offset: above
As you can see, it's using HT40+ on channel 9 (2452 MHz). Your HT40
allow (correctly) map showed:
2452 HT40 -
This is because HT40+ isn't actually allowed on channel 9 by the
standard (cf. 802.11-2012 Table E-1 (US), E-2 (Europe), E-3 (Japan).
I wonder, what is the oldest kernel you tried? I think the fact that we
can connect here was introduced by some older patch, and then reverted
by my patch, so older kernels should have been slower as well?
The problem here is that some devices (notably iwlwifi) will not allow
(by firmware) to connect to such an AP as HT40- if that is not allowed.
So I prevented it generally, but we can make it device dependent. I
don't like it much, but I suppose we can do it. Try this patch:
http://p.sipsolutions.net/0129f39c7d882289.txt
It will still prohibit this configuration when the driver said it's not
allowed, but will allow it when there were other reasons to not allow
it.
johannes
Hi Eddie,
> In the AP's dmesg output which I included in my other message, I see this:
>
> <6>[ 9.300000] cfg80211: Regulatory domain changed to country: GB
>
> So it seems the AP knows where it is, but is it not transmitting that to
> the client?
Evidently, I don't see a country IE in the iw scan output you posted.
johannes
On Tue, 2012-11-06 at 18:59 +0000, Eddie Chapman wrote:
> On 06/11/12 15:54, Johannes Berg wrote:
> > The problem here is that some devices (notably iwlwifi) will not allow
> > (by firmware) to connect to such an AP as HT40- if that is not allowed.
> > So I prevented it generally, but we can make it device dependent. I
> > don't like it much, but I suppose we can do it. Try this patch:
> >
> > http://p.sipsolutions.net/0129f39c7d882289.txt
> >
> > It will still prohibit this configuration when the driver said it's not
> > allowed, but will allow it when there were other reasons to not allow
> > it.
>
> Just to report, with the patch under discussion re-applied
> (3a40414f826a8f1096d9b94c4a53ef91b25ba28d), plus the patch at your link
> above, my throughput is back to normal again.
Ok, thanks.
> So I guess the above patch resolves the issue (on the face of it) for
> me, but whether it is a suitable solution I've no idea.
Right, we're still looking at that. It seems that it's not an ideal
solution, the regulatory change I proposed is probably better. Could you
check if it helps as well? That is, remove this patch, and apply this
one: http://p.sipsolutions.net/8877cbe3440d94b1.txt
johannes
On Tue, 2012-11-06 at 17:55 +0100, Johannes Berg wrote:
> Hi Eddie,
>
> > In the AP's dmesg output which I included in my other message, I see this:
> >
> > <6>[ 9.300000] cfg80211: Regulatory domain changed to country: GB
> >
> > So it seems the AP knows where it is, but is it not transmitting that to
> > the client?
>
> Evidently, I don't see a country IE in the iw scan output you posted.
Then again, what version of iw do you have? This only applies if it's
version 0.9.20 or higher.
johannes
On Wed, 2012-11-07 at 08:36 +0100, Greg KH wrote:
> > Great, thanks. I'm not really sure which one to apply, and if we apply
> > the 8877 one we'll also want to update the reg db (that you aren't
> > using). A lot of people are in Barcelona right now though, so that might
> > be a week or so until we can close this.
>
> I'm in Barcelona all this week, but a nice summary of what I'm supposed
> to do here for the stable tree would be great to have when ever you
> figure it out, don't wait for me to return, my email queues up just fine :)
Sure :)
So first of all, I'm sure (even without Eddie having tested it) that the
bug affects 3.7-rc as well, not just 3.6 stable, since the same patch
was applied there. Therefore, we're looking for a fix for that as well.
There are two possible fixes (that I can think of right now), both of
which Eddie tested.
One is a change to my old change, to make it only adhere to the
regulatory rules that the *driver* asked for, which will still fix the
iwlwifi problem of crashing the firmware in situations like Eddie's.
However, it's a bit strange to be ignoring our regulatory rules.
The other fix is a relaxation of the regulatory rules to allow 40 MHz
operation involving channels 12 and 13 (like in Eddie's setup, where
channel 9 HT40+ is used, which means the effective channel spans from
the bottom of channel 6 to the top of channel 13.) This seems like a
much cleaner solution, but the change needs to be done in two places
(both the kernel's idea of the "world roaming" regulatory domain, and
userspace's).
I prefer the second fix, but want to run it by somebody more familiar
with regulatory rules.
Ultimately, I'll apply either one for 3.7, and tag it with Cc stable.
johannes
Hi Johannes,
> Yeah, I forgot to ask about the AP. Can you show the output of "iw wlan0
> scan dump" for your AP while you're connected? It should show something
> like this (note the "associated" indication):
>
> BSS 02:00:00:00:00:00 (on wlan1) -- associated
> TSF: 1352188517669470 usec (15650d, 07:55:17)
> freq: 2432
> [...]
>
> I'm particularly interested in the "freq" (as above) and the HT
> capabilities/operation information.
The AP is a Netgear WNR2000v3 running DD-WRT v24-sp2 (03/19/12) std.
After sshing into it and playing around with the iw command, the phy is
phy0 and the device is ath0.
"iw ath0 scan dump" returns nothing unfortunately.
In case it helps, on the laptop (the client) I do get output from "iw
wlan0 scan dump":
BSS 82:e1:fa:1a:65:00 (on wlan0) -- associated
TSF: 2791936678 usec (0d, 00:46:31)
freq: 2452
beacon interval: 100
capability: ESS Privacy ShortSlotTime (0x0411)
signal: -37.00 dBm
last seen: 98451 ms ago
Information elements from Probe Response frame:
SSID: e79164285
Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
DS Parameter set: channel 9
ERP: Barker_Preamble_Mode
Extended supported rates: 24.0 36.0 48.0 54.0
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSK
* Capabilities: 16-PTKSA-RC (0x000c)
HT capabilities:
Capabilities: 0x11ee
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-15
HT operation:
* primary channel: 9
* secondary channel offset: above
* STA channel width: any
* RIFS: 0
* HT protection: no
* non-GF present: 0
* OBSS non-GF present: 0
* dual beacon: 0
* dual CTS protection: 0
* STBC beacon: 0
* L-SIG TXOP Prot: 0
* PCO active: 0
* PCO phase: 0
WMM: * Parameter version 1
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: CW 3-7, AIFSN 2, TXOP 1504 usec
Back on the AP, I played around and below is the output of some of the
commands I ran that seemed to return useful information, as well as
dmesg output. Many of the commands I tried either returned nothing or
some error like "not supported". Do any of them give you the info you
need? If not any other command you want me to run?
All this was done with the HT20/HT40 patch NOT applied.
thanks again for investigating this and all your dev efforts :-)
regards,
Eddie
root@DD-WRT:~# iwconfig ath0
ath0 IEEE 802.11bgn Mode:Master Frequency:2.452 GHz Tx-Power=17
dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
root@DD-WRT:~# iwlist ath0 power
ath0 Current mode:off
root@DD-WRT:~# iw ath0 info
Interface ath0
ifindex 6
type AP
wiphy 3
root@DD-WRT:~# iw phy0 info
Wiphy phy0
Band 1:
Capabilities: 0x11ee
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-15
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
max # scan SSIDs: 4
max scan IEs length: 2257 bytes
Coverage class: 5 (up to 2250m)
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP (00-0f-ac:4)
* CMAC (00-0f-ac:6)
Available Antennas: TX 0x3 RX 0x3
Configured Antennas: TX 0x3 RX 0x3
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* WDS
* monitor
* P2P-client
* P2P-GO
software interface modes (can always be added):
* AP/VLAN
* monitor
interface combinations are not supported
Supported commands:
* new_interface
* set_interface
* new_key
* new_beacon
* new_station
* set_bss
* authenticate
* associate
* deauthenticate
* disassociate
* join_ibss
* remain_on_channel
* set_tx_bitrate_mask
* action
* frame_wait_cancel
* set_wiphy_netns
* set_channel
* set_wds_peer
* Unknown command (82)
* Unknown command (81)
* Unknown command (84)
* Unknown command (87)
* Unknown command (85)
* connect
* disconnect
Supported TX frame types:
* IBSS: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070
0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
* managed: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070
0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
* AP: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080
0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
* AP/VLAN: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070
0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
* mesh point: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070
0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
* P2P-client: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070
0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
* P2P-GO: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070
0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
Supported RX frame types:
* IBSS: 0x00d0
* managed: 0x0040 0x00d0
* AP: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
* AP/VLAN: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
* mesh point: 0x00b0 0x00c0 0x00d0
* P2P-client: 0x0040 0x00d0
* P2P-GO: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
Device supports RSN-IBSS.
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
Device supports HT-IBSS.
root@DD-WRT:~# iw ath0 survey dump
Survey data from ath0
frequency: 2412 MHz
noise: -94 dBm
channel active time: 51 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel transmit time: 0 ms
Survey data from ath0
frequency: 2417 MHz
noise: -94 dBm
channel active time: 58 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel transmit time: 0 ms
Survey data from ath0
frequency: 2422 MHz
noise: -95 dBm
channel active time: 58 ms
channel busy time: 12 ms
channel receive time: 3 ms
channel transmit time: 0 ms
Survey data from ath0
frequency: 2427 MHz
noise: -95 dBm
channel active time: 58 ms
channel busy time: 1 ms
channel receive time: 0 ms
channel transmit time: 0 ms
Survey data from ath0
frequency: 2432 MHz
noise: -95 dBm
channel active time: 58 ms
channel busy time: 11 ms
channel receive time: 2 ms
channel transmit time: 0 ms
Survey data from ath0
frequency: 2437 MHz
noise: -95 dBm
channel active time: 58 ms
channel busy time: 1 ms
channel receive time: 0 ms
channel transmit time: 0 ms
Survey data from ath0
frequency: 2442 MHz
noise: -95 dBm
channel active time: 58 ms
channel busy time: 4 ms
channel receive time: 0 ms
channel transmit time: 0 ms
Survey data from ath0
frequency: 2447 MHz
noise: -95 dBm
channel active time: 58 ms
channel busy time: 8 ms
channel receive time: 0 ms
channel transmit time: 0 ms
Survey data from ath0
frequency: 2452 MHz [in use]
noise: -95 dBm
channel active time: 244549336 ms
channel busy time: 19353849 ms
channel receive time: 1387651 ms
channel transmit time: 10752120 ms
Survey data from ath0
frequency: 2457 MHz
noise: -95 dBm
channel active time: 58 ms
channel busy time: 4 ms
channel receive time: 0 ms
channel transmit time: 0 ms
Survey data from ath0
frequency: 2462 MHz
noise: -95 dBm
channel active time: 58 ms
channel busy time: 17 ms
channel receive time: 9 ms
channel transmit time: 0 ms
Survey data from ath0
frequency: 2467 MHz
noise: -95 dBm
channel active time: 58 ms
channel busy time: 17 ms
channel receive time: 6 ms
channel transmit time: 0 ms
Survey data from ath0
frequency: 2472 MHz
noise: -95 dBm
channel active time: 58 ms
channel busy time: 16 ms
channel receive time: 8 ms
channel transmit time: 0 ms
root@DD-WRT:~# iwlist ath0 frequency
ath0 13 channels in total; available frequencies :
Channel 01 : 2.412 GHz
Channel 02 : 2.417 GHz
Channel 03 : 2.422 GHz
Channel 04 : 2.427 GHz
Channel 05 : 2.432 GHz
Channel 06 : 2.437 GHz
Channel 07 : 2.442 GHz
Channel 08 : 2.447 GHz
Channel 09 : 2.452 GHz
Channel 10 : 2.457 GHz
Channel 11 : 2.462 GHz
Channel 12 : 2.467 GHz
Channel 13 : 2.472 GHz
Current Frequency=2.452 GHz (Channel 9)
Finally, here is dmesg output on the AP:
<5>[ 0.000000] Linux version 3.2.12-rc1-svn18774 (root@dd-wrt) (gcc
version 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02) ) #1482 Mon
Mar 19 11:54:29 CET 2012
<4>[ 0.000000] flash_size passed from bootloader = 4
<6>[ 0.000000] bootconsole [early0] enabled
<6>[ 0.000000] CPU revision is: 00019374 (MIPS 24Kc)
<6>[ 0.000000] Determined physical RAM map:
<6>[ 0.000000] memory: 02000000 @ 00000000 (usable)
<4>[ 0.000000] Zone PFN ranges:
<4>[ 0.000000] Normal 0x00000000 -> 0x00002000
<4>[ 0.000000] Movable zone start PFN for each node
<4>[ 0.000000] early_node_map[1] active PFN ranges
<4>[ 0.000000] 0: 0x00000000 -> 0x00002000
<7>[ 0.000000] On node 0 totalpages: 8192
<7>[ 0.000000] free_area_init_node: node 0, pgdat 8026e830,
node_mem_map 81000000
<7>[ 0.000000] Normal zone: 64 pages used for memmap
<7>[ 0.000000] Normal zone: 0 pages reserved
<7>[ 0.000000] Normal zone: 8128 pages, LIFO batch:0
<7>[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
<7>[ 0.000000] pcpu-alloc: [0] 0
<4>[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 8128
<5>[ 0.000000] Kernel command line: console=ttyS0,115200 root=1f02
rootfstype=squashfs noinitrd init=/sbin/init
<6>[ 0.000000] PID hash table entries: 128 (order: -3, 512 bytes)
<6>[ 0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384
bytes)
<6>[ 0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192
bytes)
<4>[ 0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize
32 bytes.
<4>[ 0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases,
linesize 32 bytes
<6>[ 0.000000] Writing ErrCtl register=00000000
<6>[ 0.000000] Readback ErrCtl register=00000000
<6>[ 0.000000] Memory: 29528k/32768k available (2081k kernel code,
3240k reserved, 402k data, 160k init, 0k highmem)
<6>[ 0.000000] NR_IRQS:80
<6>[ 0.000000] Calibrating delay loop... 239.61 BogoMIPS (lpj=1198080)
<6>[ 0.070000] pid_max: default: 32768 minimum: 301
<6>[ 0.070000] Mount-cache hash table entries: 512
<6>[ 0.080000] NET: Registered protocol family 16
<6>[ 0.100000] found calibration data for slot 0 on 0xBF3F1000
<4>[ 0.310000] registering PCI controller with io_map_base unset
<6>[ 0.330000] bio: create slab <bio-0> at 0
<7>[ 0.330000] pci 0000:00:00.0: [168c:ff1c] type 0 class 0x000200
<6>[ 0.330000] pci 0000:00:00.0: fixup device configuration
<0>[ 0.340000] bootstrap returns device 168C:2E
<7>[ 0.340000] pci 0000:00:00.0: reg 10: [mem 0x00000000-0x0000ffff
64bit]
<7>[ 0.340000] pci 0000:00:00.0: supports D1
<7>[ 0.340000] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
<7>[ 0.340000] pci 0000:00:00.0: PME# disabled
<6>[ 0.340000] pci 0000:00:00.0: BAR 0: assigned [mem
0x10000000-0x1000ffff 64bit]
<6>[ 0.350000] pci 0000:00:00.0: BAR 0: set to [mem
0x10000000-0x1000ffff 64bit] (PCI address [0x10000000-0x1000ffff])
<6>[ 0.360000] PCI: mapping irq 72 to pin1@0000:00:00.0
<6>[ 0.360000] Switching to clocksource MIPS
<6>[ 0.370000] NET: Registered protocol family 2
<6>[ 0.370000] IP route cache hash table entries: 1024 (order: 0,
4096 bytes)
<6>[ 0.380000] TCP established hash table entries: 1024 (order: 1,
8192 bytes)
<6>[ 0.390000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
<6>[ 0.390000] TCP: Hash tables configured (established 1024 bind 1024)
<6>[ 0.400000] TCP reno registered
<6>[ 0.400000] UDP hash table entries: 256 (order: 0, 4096 bytes)
<6>[ 0.410000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
<6>[ 0.420000] NET: Registered protocol family 1
<7>[ 0.420000] PCI: CLS 0 bytes, default 32
<5>[ 0.420000] gpio_proc: module loaded and /proc/gpio/ created
<5>[ 0.430000] wl0gpio_proc: module loaded and /proc/wl0gpio/ created
<6>[ 0.440000] squashfs: version 3.0 (2006/03/15) Phillip Lougher
<6>[ 0.440000] msgmni has been set to 57
<6>[ 0.450000] io scheduler noop registered
<6>[ 0.450000] io scheduler deadline registered (default)
<6>[ 0.460000] Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
<6>[ 0.480000] serial8250.0: ttyS0 at MMIO 0x18020000 (irq = 11) is a
16550A
<6>[ 0.490000] console [ttyS0] enabled, bootconsole disabled
<0>[ 0.500000] guessed flashsize = 4M
<0>[ 0.510000] scanning for root partition
<0>[ 0.510000] WNR2000 uboot detected
<0>[ 0.510000] guessed bootloader size = 50000
<0>[ 0.520000]
<0>[ 0.520000] found squashfs at 150000
<5>[ 0.530000] Creating 8 MTD partitions on "ar7240-nor0":
<5>[ 0.530000] 0x000000000000-0x000000050000 : "RedBoot"
<5>[ 0.540000] 0x000000050000-0x0000003e0000 : "linux"
<5>[ 0.550000] 0x000000150000-0x0000003e0000 : "rootfs"
<5>[ 0.550000] mtd: partition "rootfs" set to be root filesystem
<5>[ 0.560000] 0x0000003e0000-0x000000400000 : "ddwrt"
<5>[ 0.570000] 0x0000003e0000-0x0000003f0000 : "nvram"
<5>[ 0.570000] 0x0000003f0000-0x000000400000 : "board_config"
<5>[ 0.580000] 0x000000000000-0x000000400000 : "fullflash"
<5>[ 0.590000] 0x000000000000-0x000000050000 : "fullboot"
<6>[ 0.600000] tun: Universal TUN/TAP device driver, 1.6
<6>[ 0.600000] tun: (C) 1999-2004 Max Krasnyansky <[email protected]>
<6>[ 1.010000] PPP generic driver version 2.4.2
<6>[ 1.010000] PPP BSD Compression module registered
<6>[ 1.020000] PPP Deflate Compression module registered
<6>[ 1.020000] PPP MPPE Compression module registered
<6>[ 1.030000] NET: Registered protocol family 24
<6>[ 1.030000] Software Watchdog Timer: 0.07 initialized.
soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout= 0)
<7>[ 1.040000] Registered led device: generic_0
<7>[ 1.040000] Registered led device: generic_1
<7>[ 1.050000] Registered led device: generic_2
<7>[ 1.050000] Registered led device: generic_3
<7>[ 1.050000] Registered led device: generic_4
<7>[ 1.050000] Registered led device: generic_5
<7>[ 1.050000] Registered led device: generic_6
<7>[ 1.050000] Registered led device: generic_7
<7>[ 1.050000] Registered led device: generic_8
<7>[ 1.050000] Registered led device: generic_9
<7>[ 1.050000] Registered led device: generic_10
<7>[ 1.050000] Registered led device: generic_11
<7>[ 1.050000] Registered led device: generic_12
<7>[ 1.050000] Registered led device: generic_13
<7>[ 1.050000] Registered led device: generic_14
<7>[ 1.050000] Registered led device: generic_15
<7>[ 1.050000] Registered led device: generic_16
<7>[ 1.050000] Registered led device: generic_17
<7>[ 1.050000] Registered led device: generic_18
<7>[ 1.050000] Registered led device: generic_19
<7>[ 1.050000] Registered led device: generic_20
<7>[ 1.050000] Registered led device: generic_21
<7>[ 1.050000] Registered led device: generic_22
<7>[ 1.050000] Registered led device: generic_23
<7>[ 1.050000] Registered led device: generic_24
<7>[ 1.050000] Registered led device: generic_25
<7>[ 1.050000] Registered led device: generic_26
<7>[ 1.050000] Registered led device: generic_27
<7>[ 1.050000] Registered led device: generic_28
<7>[ 1.050000] Registered led device: generic_29
<7>[ 1.060000] Registered led device: generic_30
<7>[ 1.060000] Registered led device: generic_31
<7>[ 1.060000] Registered led device: wireless_generic_0
<7>[ 1.060000] Registered led device: wireless_generic_1
<7>[ 1.060000] Registered led device: wireless_generic_2
<7>[ 1.060000] Registered led device: wireless_generic_3
<7>[ 1.060000] Registered led device: wireless_generic_4
<7>[ 1.060000] Registered led device: wireless_generic_5
<7>[ 1.060000] Registered led device: wireless_generic_6
<7>[ 1.060000] Registered led device: wireless_generic_7
<7>[ 1.060000] Registered led device: wireless_generic_8
<7>[ 1.060000] Registered led device: wireless_generic_9
<7>[ 1.060000] Registered led device: wireless_generic_10
<7>[ 1.060000] Registered led device: wireless_generic_11
<7>[ 1.060000] Registered led device: wireless_generic_12
<7>[ 1.060000] Registered led device: wireless_generic_13
<7>[ 1.060000] Registered led device: wireless_generic_14
<7>[ 1.060000] Registered led device: wireless_generic_15
<6>[ 1.060000] u32 classifier
<6>[ 1.060000] input device check on
<6>[ 1.070000] Actions configured
<6>[ 1.070000] Netfilter messages via NETLINK v0.30.
<6>[ 1.080000] nf_conntrack version 0.5.0 (461 buckets, 1844 max)
<4>[ 1.080000] nf_conntrack_rtsp v0.6.21 loading
<4>[ 1.090000] nf_nat_rtsp v0.6.21 loading
<6>[ 1.090000] ip_tables: (C) 2000-2006 Netfilter Core Team
<6>[ 1.100000] IPP2P v0.8.2 loading
<6>[ 1.100000] TCP westwood registered
<6>[ 1.100000] TCP hybla registered
<6>[ 1.110000] TCP vegas registered
<6>[ 1.110000] NET: Registered protocol family 17
<6>[ 1.120000] 8021q: 802.1Q VLAN Support v1.8
<6>[ 1.120000] searching for nvram
<6>[ 1.120000] nvram size = 0
<6>[ 1.160000] VFS: Mounted root (squashfs filesystem) readonly on
device 31:2.
<6>[ 1.170000] Freeing unused kernel memory: 160k freed
<6>[ 4.250000] ag71xx_mdio: probed
<6>[ 4.250000] eth0: Atheros AG71xx at 0xb9000000, irq 4
<7>[ 4.850000] eth0: connected to PHY at ag71xx-mdio.1:04
[uid=004dd041, driver=Generic PHY]
<6>[ 4.850000] eth1: Atheros AG71xx at 0xba000000, irq 5
<6>[ 5.440000] eth1: Found an AR7240/AR9330 built-in switch
<6>[ 5.730000] Compat-wireless backport release:
compat-wireless-2012-02-23-9-g3e5b1f0
<6>[ 5.730000] Backport based on wireless-testing.git master-2012-02-27
<6>[ 5.910000] cfg80211: Calling CRDA to update world regulatory domain
<6>[ 6.300000] cfg80211: World regulatory domain updated:
<6>[ 6.310000] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
<6>[ 6.320000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
<6>[ 6.320000] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz),
(300 mBi, 2000 mBm)
<6>[ 6.330000] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz),
(300 mBi, 2000 mBm)
<6>[ 6.340000] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
<6>[ 6.350000] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
<6>[ 6.590000] eth1: link up (1000Mbps/Full duplex)
<7>[ 6.780000] PCI: Setting latency timer of device 0000:00:00.0 to 64
<3>[ 6.780000] ath: eeprom contains invalid mac address:
ff:ff:ff:ff:ff:ff
<3>[ 6.790000] ath: random mac address will be used: 42:83:03:c5:15:55
<7>[ 6.800000] ath: EEPROM regdomain: 0x0
<7>[ 6.800000] ath: EEPROM indicates default country code should be used
<7>[ 6.800000] ath: doing EEPROM country->regdmn map search
<7>[ 6.800000] ath: country maps to regdmn code: 0x3a
<7>[ 6.800000] ath: Country alpha2 being used: US
<7>[ 6.800000] ath: Regpair used: 0x3a
<7>[ 6.810000] ieee80211 phy0: Selected rate control algorithm
'minstrel_ht'
<7>[ 6.810000] Registered led device: ath9k-phy0
<6>[ 6.810000] ieee80211 phy0: Atheros AR9287 Rev:2 mem=0xb0000000,
irq=72
<6>[ 6.820000] cfg80211: Calling CRDA for country: US
<6>[ 6.940000] cfg80211: Regulatory domain changed to country: US
<6>[ 6.950000] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
<6>[ 6.960000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz),
(300 mBi, 2700 mBm)
<6>[ 6.970000] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz),
(300 mBi, 1700 mBm)
<6>[ 6.970000] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
<6>[ 6.980000] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
<6>[ 6.990000] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
<6>[ 7.000000] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz),
(300 mBi, 3000 mBm)
<6>[ 9.010000] device eth0 entered promiscuous mode
<6>[ 9.020000] eth1: link down
<6>[ 9.090000] device eth1 entered promiscuous mode
<6>[ 9.180000] cfg80211: Calling CRDA to update world regulatory domain
<6>[ 9.210000] eth1: link up (1000Mbps/Full duplex)
<6>[ 9.210000] br0: port 2(eth1) entering forwarding state
<6>[ 9.220000] br0: port 2(eth1) entering forwarding state
<6>[ 9.230000] cfg80211: World regulatory domain updated:
<6>[ 9.230000] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
<6>[ 9.240000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
<6>[ 9.250000] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz),
(300 mBi, 2000 mBm)
<6>[ 9.260000] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz),
(300 mBi, 2000 mBm)
<6>[ 9.260000] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
<6>[ 9.270000] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
<6>[ 9.280000] cfg80211: Calling CRDA for country: GB
<6>[ 9.300000] cfg80211: Regulatory domain changed to country: GB
<6>[ 9.310000] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
<6>[ 9.320000] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz),
(N/A, 2000 mBm)
<6>[ 9.320000] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz),
(N/A, 2000 mBm)
<6>[ 9.330000] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz),
(N/A, 2000 mBm)
<6>[ 9.340000] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz),
(N/A, 2700 mBm)
<6>[ 11.220000] br0: port 2(eth1) entering forwarding state
<6>[ 30.490000] device ath0 entered promiscuous mode
<6>[ 30.490000] br0: port 3(ath0) entering forwarding state
<6>[ 30.500000] br0: port 3(ath0) entering forwarding state
<6>[ 32.420000] device ath0.1 entered promiscuous mode
<6>[ 32.420000] br0: port 4(ath0.1) entering forwarding state
<6>[ 32.430000] br0: port 4(ath0.1) entering forwarding state
<6>[ 32.500000] br0: port 3(ath0) entering forwarding state
<6>[ 32.810000] device eth1 left promiscuous mode
<6>[ 32.810000] br0: port 2(eth1) entering forwarding state
<6>[ 32.890000] device eth1.2 entered promiscuous mode
<6>[ 32.890000] device eth1 entered promiscuous mode
<6>[ 32.900000] br0: port 2(eth1.2) entering forwarding state
<6>[ 32.900000] br0: port 2(eth1.2) entering forwarding state
<6>[ 32.970000] device eth1.6 entered promiscuous mode
<6>[ 32.970000] br1: port 1(eth1.6) entering forwarding state
<6>[ 32.980000] br1: port 1(eth1.6) entering forwarding state
<6>[ 32.990000] device ath0.1 left promiscuous mode
<6>[ 33.000000] br0: port 4(ath0.1) entering forwarding state
<6>[ 33.010000] device ath0.1 entered promiscuous mode
<6>[ 33.020000] br1: port 2(ath0.1) entering forwarding state
<6>[ 33.020000] br1: port 2(ath0.1) entering forwarding state
<6>[ 34.900000] br0: port 2(eth1.2) entering forwarding state
<6>[ 48.000000] br1: port 1(eth1.6) entering forwarding state
<6>[ 48.040000] br1: port 2(ath0.1) entering forwarding state
On Tue, 2012-11-06 at 19:35 +0000, Eddie Chapman wrote:
> > Right, we're still looking at that. It seems that it's not an ideal
> > solution, the regulatory change I proposed is probably better. Could you
> > check if it helps as well? That is, remove this patch, and apply this
> > one: http://p.sipsolutions.net/8877cbe3440d94b1.txt
>
> OK, so I've removed 0129f39c7d882289.txt, applied 8877cbe3440d94b1.txt,
> and I've kept 3a40414f826a8f1096d9b94c4a53ef91b25ba28d applied.
>
> Rebooted, and happy to report throughput is still good, so
> 8877cbe3440d94b1.txt also "fixes" it for me.
Great, thanks. I'm not really sure which one to apply, and if we apply
the 8877 one we'll also want to update the reg db (that you aren't
using). A lot of people are in Barcelona right now though, so that might
be a week or so until we can close this.
Thanks for all the testing!
johannes
On Mon, 2012-11-05 at 11:04 +0000, Eddie Chapman wrote:
> > And, can you also test 3.7-rc4, to ensure that the problem isn't there
> > as well?
> I've narrowed it down to this patch which introduces the problem:
>
> Johannes Berg:
> mac80211: connect with HT20 if HT40 is not permitted
> commit: 3a40414f826a8f1096d9b94c4a53ef91b25ba28d
>
> The other 3 patches above give me no problems at all, so I am now
> running my 3.6.5 with those 3 back in, and just the HT20/HT40 patch
> removed, and throughput is perfect. As soon as I introduce the patch
> HT20/HT40 throughput drops right down to a fifth of what it was.
This should also be the case on 3.7-rc4, since the patch came from
there, and I don't see any reason to believe rt2800 would behave
differently here, for some reason.
Can you show me the contents of
the /sys/kernel/debug/ieee80211/phy0/ht40allow_map debugfs file and "iw
reg get" command?
johannes
On Tue, 2012-11-06 at 16:54 +0100, Johannes Berg wrote:
> > BSS 82:e1:fa:1a:65:00 (on wlan0) -- associated
> [...]
> > HT operation:
> > * primary channel: 9
> > * secondary channel offset: above
>
> As you can see, it's using HT40+ on channel 9 (2452 MHz). Your HT40
> allow (correctly) map showed:
>
> 2452 HT40 -
>
> This is because HT40+ isn't actually allowed on channel 9 by the
> standard (cf. 802.11-2012 Table E-1 (US), E-2 (Europe), E-3 (Japan).
Oops, no, that is obviously wrong. This is permitted outside the US, and
that is reflected in those tables as well (I was confused). However,
your AP isn't transmitting any info on where it is, and your device is
set up for world roaming (country is "00" rather than a real country).
Thus, channel 13 isn't allowed and you can't do HT40+ on channel 9.
johannes
On 06/11/12 20:31, Johannes Berg wrote:
> On Tue, 2012-11-06 at 19:35 +0000, Eddie Chapman wrote:
>
>>> Right, we're still looking at that. It seems that it's not an ideal
>>> solution, the regulatory change I proposed is probably better. Could you
>>> check if it helps as well? That is, remove this patch, and apply this
>>> one: http://p.sipsolutions.net/8877cbe3440d94b1.txt
>>
>> OK, so I've removed 0129f39c7d882289.txt, applied 8877cbe3440d94b1.txt,
>> and I've kept 3a40414f826a8f1096d9b94c4a53ef91b25ba28d applied.
>>
>> Rebooted, and happy to report throughput is still good, so
>> 8877cbe3440d94b1.txt also "fixes" it for me.
>
> Great, thanks. I'm not really sure which one to apply, and if we apply
> the 8877 one we'll also want to update the reg db (that you aren't
> using). A lot of people are in Barcelona right now though, so that might
> be a week or so until we can close this.
No hurry at all from my point of view.
> Thanks for all the testing!
Not at all, it's a pleasure to be able to contribute in some tiny way to
kernel development.
On 06/11/12 15:54, Johannes Berg wrote:
> Hi Eddie,
>
>> The AP is a Netgear WNR2000v3 running DD-WRT v24-sp2 (03/19/12) std.
>>
>> After sshing into it and playing around with the iw command, the phy is
>> phy0 and the device is ath0.
>>
>> "iw ath0 scan dump" returns nothing unfortunately.
>
> Yeah, sorry, I guess I confused you. I did want this info from the
> client, as you provided:
>
>> In case it helps, on the laptop (the client) I do get output from "iw
>> wlan0 scan dump":
>>
>> BSS 82:e1:fa:1a:65:00 (on wlan0) -- associated
> [...]
>> HT operation:
>> * primary channel: 9
>> * secondary channel offset: above
>
> As you can see, it's using HT40+ on channel 9 (2452 MHz). Your HT40
> allow (correctly) map showed:
>
> 2452 HT40 -
>
> This is because HT40+ isn't actually allowed on channel 9 by the
> standard (cf. 802.11-2012 Table E-1 (US), E-2 (Europe), E-3 (Japan).
I've just realised what's going on. Not being too knowledgeable about
wireless I had no idea what HT20 and HT40 and the patch was about. Now
when I look at the AP web interface, I see a drop down box for "Channel
Width", with the options being:
Quarter (5MHz)
Half (10MHz)
Full (20MHz)
Turbo (40MHz)
Dynamic (20/40MHz)
and "Turbo" is selected. It doesn't say "HT" anywhere, but I'm guessing
this setting is actually the HT setting and I have it set to 40 where it
should be 20? It must be something I changed when setting the AP up,
not understanding what it did. Perhaps I should set it to Dynamic.
> I wonder, what is the oldest kernel you tried? I think the fact that we
> can connect here was introduced by some older patch, and then reverted
> by my patch, so older kernels should have been slower as well?
I've had this AP like this with the "Turbo" setting for a good few
months, and had excellent throughput (around 4 or 5 Mbyte/s) on a
mixture of kernels on my laptop the whole time; Fedora 15 with a 3.0
kernel (which they named 2.6.40), and then Gentoo using various 3.4 and
3.6 kernels. Only on upgrading to 3.6.5 was the first time throughput
dropped. I've also had an Android phone and another Windows XP laptop
connecting to this AP without any problems, though never measured
throughput with them so can't say if they have ever suffered.
> The problem here is that some devices (notably iwlwifi) will not allow
> (by firmware) to connect to such an AP as HT40- if that is not allowed.
> So I prevented it generally, but we can make it device dependent. I
> don't like it much, but I suppose we can do it. Try this patch:
>
> http://p.sipsolutions.net/0129f39c7d882289.txt
>
> It will still prohibit this configuration when the driver said it's not
> allowed, but will allow it when there were other reasons to not allow
> it.
OK, so I'll try re applying the HT20/HT40 patch in 3.6.5, and then
applying the above patch, and report back.
thanks,
Eddie
On 06/11/12 19:20, Johannes Berg wrote:
> On Tue, 2012-11-06 at 18:59 +0000, Eddie Chapman wrote:
>> On 06/11/12 15:54, Johannes Berg wrote:
>>> The problem here is that some devices (notably iwlwifi) will not allow
>>> (by firmware) to connect to such an AP as HT40- if that is not allowed.
>>> So I prevented it generally, but we can make it device dependent. I
>>> don't like it much, but I suppose we can do it. Try this patch:
>>>
>>> http://p.sipsolutions.net/0129f39c7d882289.txt
>>>
>>> It will still prohibit this configuration when the driver said it's not
>>> allowed, but will allow it when there were other reasons to not allow
>>> it.
>>
>> Just to report, with the patch under discussion re-applied
>> (3a40414f826a8f1096d9b94c4a53ef91b25ba28d), plus the patch at your link
>> above, my throughput is back to normal again.
>
> Ok, thanks.
>
>> So I guess the above patch resolves the issue (on the face of it) for
>> me, but whether it is a suitable solution I've no idea.
>
> Right, we're still looking at that. It seems that it's not an ideal
> solution, the regulatory change I proposed is probably better. Could you
> check if it helps as well? That is, remove this patch, and apply this
> one: http://p.sipsolutions.net/8877cbe3440d94b1.txt
OK, so I've removed 0129f39c7d882289.txt, applied 8877cbe3440d94b1.txt,
and I've kept 3a40414f826a8f1096d9b94c4a53ef91b25ba28d applied.
Rebooted, and happy to report throughput is still good, so
8877cbe3440d94b1.txt also "fixes" it for me.
Eddie
Hi Johannes,
On 06/11/12 16:39, Johannes Berg wrote:
> On Tue, 2012-11-06 at 16:54 +0100, Johannes Berg wrote:
>
>>> BSS 82:e1:fa:1a:65:00 (on wlan0) -- associated
>> [...]
>>> HT operation:
>>> * primary channel: 9
>>> * secondary channel offset: above
>>
>> As you can see, it's using HT40+ on channel 9 (2452 MHz). Your HT40
>> allow (correctly) map showed:
>>
>> 2452 HT40 -
>>
>> This is because HT40+ isn't actually allowed on channel 9 by the
>> standard (cf. 802.11-2012 Table E-1 (US), E-2 (Europe), E-3 (Japan).
>
> Oops, no, that is obviously wrong. This is permitted outside the US, and
> that is reflected in those tables as well (I was confused). However,
> your AP isn't transmitting any info on where it is, and your device is
> set up for world roaming (country is "00" rather than a real country).
> Thus, channel 13 isn't allowed and you can't do HT40+ on channel 9.
In the AP's dmesg output which I included in my other message, I see this:
<6>[ 9.300000] cfg80211: Regulatory domain changed to country: GB
So it seems the AP knows where it is, but is it not transmitting that to
the client?
Eddie
On Tue, 2012-11-06 at 17:07 +0000, Eddie Chapman wrote:
> >>> So it seems the AP knows where it is, but is it not transmitting that to
> >>> the client?
> >>
> >> Evidently, I don't see a country IE in the iw scan output you posted.
> >
> > Then again, what version of iw do you have? This only applies if it's
> > version 0.9.20 or higher.
> I don't see a country specified in the output I sent you either. We're
> talking about iw scan on the client right, not the AP?
Yes. The scan on the client shows the AP's information, after all.
> Over on the AP, I just looked in the web interface, and there is a drop
> down box for "Regulatory Domain", and I have it set to "United Kingdom".
Right. It just doesn't seem to tell the client for some reason.
> nc6400 ~ # iw --version
> iw version 3.3
Right, ok. That would print the country information if it was there.
> You mentioned crda, it seems gentoo has it, I can install it on the
> client if you think it will help in figuring this out?
No, I think actually *not* having it might be more helpful, although
once we have found the (different) solution(s) we'll have to make sure
we fix it in all possible places, including crda/regdb.
johannes