Hey Guys,
I just got around to compiling compat-wireless on ubuntu 10.04, to
make use of the new carl9170 driver which is supposed to be able to
handle 802.11n.
My router is a wndr3700 running @ 5ghz on windows I'm able to get
pretty good speeds. But on Ubuntu it does not seem to connect faster
than 54MB/s, iwlist scan shows that 54Mb/s is the highest it can go.
Is there something special that needs to be done or enabled to let the
wnda3100 know it can go faster, or is this a bug or is 54MB/s the
fastest the driver can go right now?
Wireless Adapter: WNDA3100
Wireless Router: WNDR3700
Yeah, doesn't look like its NetworkManager from what I can tell. I
don't notice any scanning going on, etc.
Thanks for all the help. I guess the code for the channel changes just
isn't fast enough ?
This is what I get in dmesg:
[ 174.026110] wlan1: associated
[ 207.799194] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
[ 208.065258] cfg80211: All devices are disconnected, going to
restore regulatory settings
[ 208.065265] cfg80211: Restoring regulatory settings
[ 208.065269] cfg80211: Calling CRDA to update world regulatory domain
[ 208.070474] cfg80211: World regulatory domain updated:
[ 208.070478] (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 208.070482] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 208.070486] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 208.070489] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 208.070492] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 208.070495] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 213.390525] wlan1: authenticate with 30:46:9a:10:49:f7 (try 1)
On Fri, Oct 1, 2010 at 11:19 PM, Christian Lamparter
<[email protected]> wrote:
> On Saturday 02 October 2010 04:56:35 Saqeb Akhter wrote:
>> Nope I already noticed that 1.8.8.3 was available so to that step, I
>> am getting frequent disconnects though, it might have to do with
>> NetworkManager doing background scanning so going to try and it it to
>> stop doing that.
> Channel changes (especially with HT) are more expensive with AR9170
> than AR9271 which features "fastcc" (fast channel change).
>
>> The NetGear driver on windows seems to ignore the WMM requirement
>> looks like.
> You can actually peek into the Windows' driver logic.
> The code is available under drivers/staging/otus/(80211core)
> AFAIK, it only checks if the HT IEs are all present.
>
>> Either way that's what the problem was, going to see if i
>> can get this disconnect problem sorted out.
> I thought "the new" NetworkManager is more intelligent and
> doesn't schedule scans while the device is actively
> transmitting/receiving data. Anyway, NetworkManager is
> "just" a manager for wpa_supplicant and wpa_supp works
> well enough.
>
> bye.
>
>
On Friday 01 October 2010 16:22:45 Saqeb Akhter wrote:
> Hey Guys,
>
> I just got around to compiling compat-wireless on ubuntu 10.04, to
> make use of the new carl9170 driver which is supposed to be able to
> handle 802.11n.
>
> My router is a wndr3700 running @ 5ghz on windows I'm able to get
> pretty good speeds. But on Ubuntu it does not seem to connect faster
> than 54MB/s, iwlist scan shows that 54Mb/s is the highest it can go.
sure, that's a limitation of iwlist. If you want to know the current
link speed (link speed as in "the last used tx rate", so if there's
no traffic then the rate is low) you should be using the "iw" utility:
iw dev wlanX link
Regards,
Chr
Nope I already noticed that 1.8.8.3 was available so to that step, I
am getting frequent disconnects though, it might have to do with
NetworkManager doing background scanning so going to try and it it to
stop doing that.
The NetGear driver on windows seems to ignore the WMM requirement
looks like. Either way that's what the problem was, going to see if i
can get this disconnect problem sorted out.
On Fri, Oct 1, 2010 at 10:52 PM, Christian Lamparter
<[email protected]> wrote:
> On Saturday 02 October 2010 04:32:04 Saqeb Akhter wrote:
>> ------------------------------------------------------------
>> Client connecting to 192.168.10.52, TCP port 5001
>> TCP window size: 16.0 KByte (default)
>> ------------------------------------------------------------
>> [ ?3] local 192.168.10.60 port 50647 connected with 192.168.10.52 port 5001
>> [ ID] Interval ? ? ? Transfer ? ? Bandwidth
>> [ ?3] ?0.0-10.0 sec ?98.6 MBytes ?82.6 Mbits/sec
>>
>> Seems to be doing a lot better now thanks :)
> Hm, I'm not too optimistic. After all, it took a long time to get to this
> point and even now the driver isn't "stable" yet (hence the EXPERIMENTAL
> flag).
>
>> I was not aware the WMM extensions were needed to get HT working.
> ;)
>
> I think 802.11n says somewhere, something like:
> "An HT STA is also a QoS STA"
>
> And QoS is enabled/setup by WMM.
>> I ended up upgrading my distro to 10.10 RC, and compiling the
>> compat-wireless u posted, and enable WMM extensions on my router.
>> Working considerably better :)
>
> One more thing: I've updated the firmware to 1.8.8.3
> http://wireless.kernel.org/en/users/Drivers/carl9170#Firmware_binary
> (In case you are still using the original 1.8.8.1)
>
> Best Regards,
> ? ? ? ?Christian
>
On Saturday 02 October 2010 04:32:04 Saqeb Akhter wrote:
> ------------------------------------------------------------
> Client connecting to 192.168.10.52, TCP port 5001
> TCP window size: 16.0 KByte (default)
> ------------------------------------------------------------
> [ 3] local 192.168.10.60 port 50647 connected with 192.168.10.52 port 5001
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0-10.0 sec 98.6 MBytes 82.6 Mbits/sec
>
> Seems to be doing a lot better now thanks :)
Hm, I'm not too optimistic. After all, it took a long time to get to this
point and even now the driver isn't "stable" yet (hence the EXPERIMENTAL
flag).
> I was not aware the WMM extensions were needed to get HT working.
;)
I think 802.11n says somewhere, something like:
"An HT STA is also a QoS STA"
And QoS is enabled/setup by WMM.
> I ended up upgrading my distro to 10.10 RC, and compiling the
> compat-wireless u posted, and enable WMM extensions on my router.
> Working considerably better :)
One more thing: I've updated the firmware to 1.8.8.3
http://wireless.kernel.org/en/users/Drivers/carl9170#Firmware_binary
(In case you are still using the original 1.8.8.1)
Best Regards,
Christian
On Saturday 02 October 2010 04:56:35 Saqeb Akhter wrote:
> Nope I already noticed that 1.8.8.3 was available so to that step, I
> am getting frequent disconnects though, it might have to do with
> NetworkManager doing background scanning so going to try and it it to
> stop doing that.
Channel changes (especially with HT) are more expensive with AR9170
than AR9271 which features "fastcc" (fast channel change).
> The NetGear driver on windows seems to ignore the WMM requirement
> looks like.
You can actually peek into the Windows' driver logic.
The code is available under drivers/staging/otus/(80211core)
AFAIK, it only checks if the HT IEs are all present.
> Either way that's what the problem was, going to see if i
> can get this disconnect problem sorted out.
I thought "the new" NetworkManager is more intelligent and
doesn't schedule scans while the device is actively
transmitting/receiving data. Anyway, NetworkManager is
"just" a manager for wpa_supplicant and wpa_supp works
well enough.
bye.
On Sat, 2010-10-02 at 05:19 +0200, Christian Lamparter wrote:
> On Saturday 02 October 2010 04:56:35 Saqeb Akhter wrote:
> > Nope I already noticed that 1.8.8.3 was available so to that step, I
> > am getting frequent disconnects though, it might have to do with
> > NetworkManager doing background scanning so going to try and it it to
> > stop doing that.
> Channel changes (especially with HT) are more expensive with AR9170
> than AR9271 which features "fastcc" (fast channel change).
>
> > The NetGear driver on windows seems to ignore the WMM requirement
> > looks like.
> You can actually peek into the Windows' driver logic.
> The code is available under drivers/staging/otus/(80211core)
> AFAIK, it only checks if the HT IEs are all present.
>
> > Either way that's what the problem was, going to see if i
> > can get this disconnect problem sorted out.
> I thought "the new" NetworkManager is more intelligent and
> doesn't schedule scans while the device is actively
> transmitting/receiving data. Anyway, NetworkManager is
> "just" a manager for wpa_supplicant and wpa_supp works
> well enough.
NM >= 0.8.1 will request periodic scans unless you've locked the device
to a specific BSSID, because if you've done this you are indicating that
you don't need roaming. If you haven't specified a BSSID, then we still
need periodic scans in case the device needs to roam between APs in a
multi-AP system.
Note that some drivers still appear to ignore BSSID locking.
Dan
On Saturday 02 October 2010 08:18:07 Saqeb Akhter wrote:
> I guess you were right about it being unstable - almost unusable for
> video streaming.
Video streaming? Does your application use QoS AC_VI(deo) for streaming,
or just bulk data (AC_BE(st effort))?
> sakhter@sakhter-laptop:~$ dmesg | grep Reason
> [ 1166.512087] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ 1526.059997] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ 2125.324356] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ 2845.783011] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ 3565.994832] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ 5128.903576] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ 5726.046230] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ 6326.042938] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ 6835.689445] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ 7197.337060] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
>
> Seems to disconnect quite frequently. Even tried uninstalling networkmanager.
Reason 7 is: [AP received a] class 3 (data) frame from non-associated STA.
This can happen when your are "actively" disassociating from the AP (unlikely),
when the AP thinks you are out-of-reach(unlikely, since your signal seems to
be strong and PSM isn't enabled by default) or when the AP crashes and resets.
You should check your AP's TSF. (iw dev wlanX scan).
It should not go backwards.
(But if it does, then it might be because carl9170 has accidentally DoSed it?!)
Regards,
Christian
I guess you were right about it being unstable - almost unusable for
video streaming.
sakhter@sakhter-laptop:~$ dmesg | grep Reason
[ 1166.512087] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
[ 1526.059997] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
[ 2125.324356] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
[ 2845.783011] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
[ 3565.994832] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
[ 5128.903576] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
[ 5726.046230] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
[ 6326.042938] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
[ 6835.689445] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
[ 7197.337060] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
Seems to disconnect quite frequently. Even tried uninstalling networkmanager.
On Fri, Oct 1, 2010 at 11:28 PM, Saqeb Akhter <[email protected]> wrote:
> Yeah, doesn't look like its NetworkManager from what I can tell. I
> don't notice any scanning going on, etc.
>
> Thanks for all the help. I guess the code for the channel changes just
> isn't fast enough ?
>
> This is what I get in dmesg:
>
> [ ?174.026110] wlan1: associated
> [ ?207.799194] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ ?208.065258] cfg80211: All devices are disconnected, going to
> restore regulatory settings
> [ ?208.065265] cfg80211: Restoring regulatory settings
> [ ?208.065269] cfg80211: Calling CRDA to update world regulatory domain
> [ ?208.070474] cfg80211: World regulatory domain updated:
> [ ?208.070478] ? ? (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [ ?208.070482] ? ? (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ ?208.070486] ? ? (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> [ ?208.070489] ? ? (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> [ ?208.070492] ? ? (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ ?208.070495] ? ? (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ ?213.390525] wlan1: authenticate with 30:46:9a:10:49:f7 (try 1)
>
>
>
>
>
> On Fri, Oct 1, 2010 at 11:19 PM, Christian Lamparter
> <[email protected]> wrote:
>> On Saturday 02 October 2010 04:56:35 Saqeb Akhter wrote:
>>> Nope I already noticed that 1.8.8.3 was available so to that step, I
>>> am getting frequent disconnects though, it might have to do with
>>> NetworkManager doing background scanning so going to try and it it to
>>> stop doing that.
>> Channel changes (especially with HT) are more expensive with AR9170
>> than AR9271 which features "fastcc" (fast channel change).
>>
>>> The NetGear driver on windows seems to ignore the WMM requirement
>>> looks like.
>> You can actually peek into the Windows' driver logic.
>> The code is available under drivers/staging/otus/(80211core)
>> AFAIK, it only checks if the HT IEs are all present.
>>
>>> Either way that's what the problem was, going to see if i
>>> can get this disconnect problem sorted out.
>> I thought "the new" NetworkManager is more intelligent and
>> doesn't schedule scans while the device is actively
>> transmitting/receiving data. Anyway, NetworkManager is
>> "just" a manager for wpa_supplicant and wpa_supp works
>> well enough.
>>
>> bye.
>>
>>
>
Here's a scan before a dropout:
-------------------------------------------------------------------------------------------
sakhter@sakhter-laptop:~$ sudo iw dev wlan1 scan
BSS 30:46:9a:10:49:f7 (on wlan1) -- associated
TSF: 35799960635 usec (0d, 09:56:39)
freq: 5220
beacon interval: 100
capability: ESS ShortSlotTime (0x0401)
signal: -51.00 dBm
last seen: 7988 ms ago
SSID: sakhter-5g
Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
DS Parameter set: channel 44
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: 0x1ce
HT20/HT40
SM Power Save disabled
RX HT40 SGI
TX STBC
RX STBC 1-stream
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
WPS: * Version: 1.0
* Manufacturer: Netgear, Inc.
* Model: WNDR3700
* Device name: WNDR3700(Wireless AP)
* Config methods: Ethernet, Label, PBC
-------------------------------------------------------------------------------------------
After a dropout -
TSF: 36735900731 usec (0d, 10:12:15), So I guess that's not the reason.
For the QoS I'm not sure how the Video is being sent it's over samba,
most likely just BE.
On Sat, Oct 2, 2010 at 7:32 AM, Christian Lamparter
<[email protected]> wrote:
> On Saturday 02 October 2010 08:18:07 Saqeb Akhter wrote:
>> I guess you were right about it being unstable - almost unusable for
>> video streaming.
> Video streaming? Does your application use QoS AC_VI(deo) for streaming,
> or just bulk data (AC_BE(st effort))?
>
>> sakhter@sakhter-laptop:~$ dmesg | grep Reason
>> [ 1166.512087] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
>> [ 1526.059997] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
>> [ 2125.324356] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
>> [ 2845.783011] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
>> [ 3565.994832] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
>> [ 5128.903576] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
>> [ 5726.046230] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
>> [ 6326.042938] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
>> [ 6835.689445] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
>> [ 7197.337060] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
>>
>> Seems to disconnect quite frequently. Even tried uninstalling networkmanager.
> Reason 7 is: [AP received a] class 3 (data) frame from non-associated STA.
> This can happen when your are "actively" disassociating from the AP (unlikely),
> when the AP thinks you are out-of-reach(unlikely, since your signal seems to
> be strong and PSM isn't enabled by default) or when the AP crashes and resets.
>
> You should check your AP's TSF. (iw dev wlanX scan).
> It should not go backwards.
> (But if it does, then it might be because carl9170 has accidentally DoSed it?!)
>
> Regards,
> ? ? ? ?Christian
>
------------------------------------------------------------
Client connecting to 192.168.10.52, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.10.60 port 50647 connected with 192.168.10.52 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 98.6 MBytes 82.6 Mbits/sec
Seems to be doing a lot better now thanks :)
I was not aware the WMM extensions were needed to get HT working, I
ended up upgrading my distro to 10.10 RC, and compiling the
compat-wireless u posted, and enable WMM extensions on my router.
Working considerably better :)
On Fri, Oct 1, 2010 at 8:26 PM, Christian Lamparter
<[email protected]> wrote:
> On Saturday 02 October 2010 01:56:06 Saqeb Akhter wrote:
>> Yes carl9170 (from 9/23).
> wow, that's old. Luis posted a "special" compat-wireless release
> for carl9170:
>
> "See Announcement: Re: Compat-wireless release for 2010-10-01 v2 with RX filter for carl9170 on -p release"
> http://www.orbit-lab.org/kernel/compat-wireless-2.6/2010/10/compat-wireless-2010-10-01-p.tar.bz2
>
> ---
>> output iw dev wlan2 scan
>>
>> BSS 30:46:9a:10:49:f7 (on wlan2) -- associated
>> ? ? ? TSF: 90703162427 usec (1d, 01:11:43)
>> ? ? ? freq: 5200
>> ? ? ? beacon interval: 100
>> ? ? ? capability: ESS ShortSlotTime (0x0401)
>> ? ? ? signal: -53.00 dBm
>> ? ? ? last seen: 672 ms ago
>> ? ? ? SSID: sakhter-5g
>> ? ? ? Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
>> ? ? ? DS Parameter set: channel 40
>> ? ? ? HT capabilities:
>> ? ? ? ? ? ? ? Capabilities: 0x1ce
>> ? ? ? ? ? ? ? ? ? ? ? HT20/HT40
>> ? ? ? ? ? ? ? ? ? ? ? SM Power Save disabled
>> ? ? ? ? ? ? ? ? ? ? ? RX HT40 SGI
>> ? ? ? ? ? ? ? ? ? ? ? TX STBC
>> ? ? ? ? ? ? ? ? ? ? ? RX STBC 1-stream
>> ? ? ? ? ? ? ? ? ? ? ? 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
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Now that's interesting, apparently Netgear's AP can't send HT (802.11n) frames!
>
> But that's not your problem, it's the missing WMM extension.
>
> Your AP should (additionally) display:
> ? ? ? ?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
>
>
> But since it doesn't, mac80211 does not enable ht.
>
> Maybe a new firmware for the router would fix the issue?
>
> Regards,
> ? ? ? ?Chr
>
Yes carl9170 (from 9/23).
-----------------------------------------------------------------------------------------------------
Output from lshw -C network:
*-network
description: Wireless interface
physical id: 1
bus info: usb@1:3
logical name: wlan2
serial: 00:22:3f:99:cd:81
capabilities: ethernet physical wireless
configuration: broadcast=yes driver=carl9170
driverversion=2.6.32-24-generic firmware=1.8.8.3 ip=192.168.10.60
multicast=yes wireless=IEEE 802.11abgn
----------------------------------------------------------------------------------------------
sakhter@sakhter-laptop:~$ dmesg | grep alg
[ 0.342735] alg: No test for stdrng (krng)
[ 143.665241] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
------------------------------------------------------------------------------------------------
output iw dev wlan2 scan
BSS 30:46:9a:10:49:f7 (on wlan2) -- associated
TSF: 90703162427 usec (1d, 01:11:43)
freq: 5200
beacon interval: 100
capability: ESS ShortSlotTime (0x0401)
signal: -53.00 dBm
last seen: 672 ms ago
SSID: sakhter-5g
Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
DS Parameter set: channel 40
HT capabilities:
Capabilities: 0x1ce
HT20/HT40
SM Power Save disabled
RX HT40 SGI
TX STBC
RX STBC 1-stream
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
WPS: * Version: 1.0
* Manufacturer: Netgear, Inc.
* Model: WNDR3700
* Device name: WNDR3700(Wireless AP)
* Config methods: Ethernet, Label, PBC
---------------------------------------------------------------------------------------------------
Hopefully some of that info can help u out.
On Fri, Oct 1, 2010 at 6:52 PM, Christian Lamparter
<[email protected]> wrote:
> On Saturday 02 October 2010 00:30:28 Saqeb Akhter wrote:
>> Below is the out put from iperf on windows (about 3x faster).
>>
>> Not sure what to do to get better throughput...is this considered a bug or a
>> lacking feature ?
> nope, the "feature" is there... It's just not utilized
>
>> -------------------------------------------------------------------------------
>> sakhter@sakhter-laptop:~$ iw dev wlan2 link
>> Connected to 30:46:9a:10:49:f7 (on wlan2)
>> ? ? SSID: sakhter-5g
>> ? ? freq: 5200
>> ? ? RX: 222040 bytes (949 packets)
>> ? ? TX: 12082 bytes (77 packets)
>> ? ? signal: -45 dBm
>> ? ? tx bitrate: 54.0 MBit/s
> are you sure carl9170 is actually handling the device (and not ar9170usb?).
> Also what's the chosen rate control alg? ( - dmesg - will tell you that,
> if it isn't "minstrel_ht", then post please post what "iw dev wlan2 scan"
> shows you about your AP)
>
> Regards,
> ? ? ? ?Chr
>
>
On Saturday 02 October 2010 01:56:06 Saqeb Akhter wrote:
> Yes carl9170 (from 9/23).
wow, that's old. Luis posted a "special" compat-wireless release
for carl9170:
"See Announcement: Re: Compat-wireless release for 2010-10-01 v2 with RX filter for carl9170 on -p release"
http://www.orbit-lab.org/kernel/compat-wireless-2.6/2010/10/compat-wireless-2010-10-01-p.tar.bz2
---
> output iw dev wlan2 scan
>
> BSS 30:46:9a:10:49:f7 (on wlan2) -- associated
> TSF: 90703162427 usec (1d, 01:11:43)
> freq: 5200
> beacon interval: 100
> capability: ESS ShortSlotTime (0x0401)
> signal: -53.00 dBm
> last seen: 672 ms ago
> SSID: sakhter-5g
> Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
> DS Parameter set: channel 40
> HT capabilities:
> Capabilities: 0x1ce
> HT20/HT40
> SM Power Save disabled
> RX HT40 SGI
> TX STBC
> RX STBC 1-stream
> 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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now that's interesting, apparently Netgear's AP can't send HT (802.11n) frames!
But that's not your problem, it's the missing WMM extension.
Your AP should (additionally) display:
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
But since it doesn't, mac80211 does not enable ht.
Maybe a new firmware for the router would fix the issue?
Regards,
Chr
On Saturday 02 October 2010 00:30:28 Saqeb Akhter wrote:
> Below is the out put from iperf on windows (about 3x faster).
>
> Not sure what to do to get better throughput...is this considered a bug or a
> lacking feature ?
nope, the "feature" is there... It's just not utilized
> -------------------------------------------------------------------------------
> sakhter@sakhter-laptop:~$ iw dev wlan2 link
> Connected to 30:46:9a:10:49:f7 (on wlan2)
> SSID: sakhter-5g
> freq: 5200
> RX: 222040 bytes (949 packets)
> TX: 12082 bytes (77 packets)
> signal: -45 dBm
> tx bitrate: 54.0 MBit/s
are you sure carl9170 is actually handling the device (and not ar9170usb?).
Also what's the chosen rate control alg? ( - dmesg - will tell you that,
if it isn't "minstrel_ht", then post please post what "iw dev wlan2 scan"
shows you about your AP)
Regards,
Chr
On Mon, 2010-11-29 at 19:37 +0100, Christian Lamparter wrote:
> @@ -1999,6 +1999,10 @@ ieee80211_rx_h_mgmt_check(struct ieee80211_rx_data *rx)
> if (!ieee80211_is_mgmt(mgmt->frame_control))
> return RX_DROP_MONITOR;
>
> + if (is_multicast_ether_addr(mgmt->da) &&
> + !is_broadcast_ether_addr(mgmt->da))
> + return RX_DROP_MONITOR;
> +
I'm not sure we should do this here since the nl80211 hook is later?
johannes
This patch fixes an curious issue due to insufficient
rx frame filtering.
Saqeb Akhter reported frequent disconnects while streaming
videos over samba:
> [ 1166.512087] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ 1526.059997] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ 2125.324356] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [...]
The reason is that the device generates frames with slightly
bogus SA/TA addresses.
e.g.:
[ 2314.402316] Ignore 9f:1f:31:f8:64:ff
[ 2314.402321] Ignore 9f:1f:31:f8:64:ff
[ 2352.453804] Ignore 0d:1f:31:f8:64:ff
[ 2352.453808] Ignore 0d:1f:31:f8:64:ff
^^ the group-address flag is set!
(the correct SA/TA would be: 00:1f:31:f8:64:ff)
Since the AP does not know from where the frame comes from it
generates a DEAUTH response. This mcast mgmt frame confuses
the stack because the broadcast flag are not filtered and the
stack thinks we haven been kicked by the AP.
This patch fixes the problem simply by ignoring
non-broadcast group-addressed management frames.
Cc: <[email protected]>
Cc: Jouni Malinen <[email protected]>
Cc: Johannes Berg <[email protected]>
Reported-by: Saqeb Akhter <[email protected]>
Signed-off-by: Christian Lamparter <[email protected]>
---
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index d2fcd22..3dbf79c 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1999,6 +1999,10 @@ ieee80211_rx_h_mgmt_check(struct ieee80211_rx_data *rx)
if (!ieee80211_is_mgmt(mgmt->frame_control))
return RX_DROP_MONITOR;
+ if (is_multicast_ether_addr(mgmt->da) &&
+ !is_broadcast_ether_addr(mgmt->da))
+ return RX_DROP_MONITOR;
+
if (!(status->rx_flags & IEEE80211_RX_RA_MATCH))
return RX_DROP_MONITOR;
On Saturday 02 October 2010 13:32:09 Christian Lamparter wrote:
> On Saturday 02 October 2010 08:18:07 Saqeb Akhter wrote:
> > I guess you were right about it being unstable - almost unusable for
> > video streaming.
> Video streaming? Does your application use QoS AC_VI(deo) for streaming,
> or just bulk data (AC_BE(st effort))?
>
> > sakhter@sakhter-laptop:~$ dmesg | grep Reason
> > [ 1166.512087] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> > [ 1526.059997] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> > [ 2125.324356] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> > [ 2845.783011] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> > [ 3565.994832] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> > [ 5128.903576] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> > [ 5726.046230] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> > [ 6326.042938] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> > [ 6835.689445] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> > [ 7197.337060] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> >
> > Seems to disconnect quite frequently. Even tried uninstalling networkmanager.
> Reason 7 is: [AP received a] class 3 (data) frame from non-associated STA.
> This can happen when your are "actively" disassociating from the AP (unlikely),
> when the AP thinks you are out-of-reach(unlikely, since your signal seems to
> be strong and PSM isn't enabled by default) or when the AP crashes and resets.
>
I think I found the reason. Apparently, there's something wrong with the AES
engine. As you may know, as soon as the hwcrypto is disabled, the problem
"magically" disappears... It looks like carl9170 (and otus?) is generating
frames with slightly bogus SA/TA addresses.
e.g.:
(the correct SA/TA would be: 00:1f:31:f8:64:ff)
[ 2314.402316] Ignore 9f:1f:31:f8:64:ff
[ 2314.402321] Ignore 9f:1f:31:f8:64:ff
[ 2352.453804] Ignore 0d:1f:31:f8:64:ff
[ 2352.453808] Ignore 0d:1f:31:f8:64:ff
^ notice: the group address flag!
Since the AP doesn't know from where the frame comes from, it creates
a valid DEAUTH (with the correct reason: 7). Because the RA/DA looks
too similar for the hardware/software filters to discard, the stack
thinks it was kicked by the AP...
The attached patch -for now- only "enhances" mac80211's rx frame filter
when operating as a station (what about mesh, adhoc?). The filter takes
a closer look at each multicast frame and verifies that the group
address is listed in the multicast list before processing it.
Best regards,
Christian
---
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index d2fcd22..fe99d66 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2543,8 +2543,21 @@ void ieee80211_release_reorder_timeout(struct sta_info *sta, int tid)
ieee80211_rx_handlers(&rx, &frames);
}
-/* main receive path */
+static bool check_mc_group(struct ieee80211_local *local,
+ u8 *da)
+{
+ struct netdev_hw_addr *ha;
+ if (is_broadcast_ether_addr(da))
+ return true;
+ netdev_hw_addr_list_for_each(ha, &local->mc_list) {
+ if (compare_ether_addr(ha->addr, da) == 0)
+ return true;
+ }
+ return false;
+}
+
+/* main receive path */
static int prepare_for_handlers(struct ieee80211_rx_data *rx,
struct ieee80211_hdr *hdr)
{
@@ -2558,8 +2571,9 @@ static int prepare_for_handlers(struct ieee80211_rx_data *rx,
case NL80211_IFTYPE_STATION:
if (!bssid && !sdata->u.mgd.use_4addr)
return 0;
- if (!multicast &&
- compare_ether_addr(sdata->vif.addr, hdr->addr1) != 0) {
+ if ((!multicast &&
+ compare_ether_addr(sdata->vif.addr, hdr->addr1) != 0) ||
+ (multicast && !check_mc_group(rx->local, hdr->addr1))) {
if (!(sdata->dev->flags & IFF_PROMISC))
return 0;
status->rx_flags &= ~IEEE80211_RX_RA_MATCH;
This patch fixes an curious issue due to insufficient
rx frame filtering.
Saqeb Akhter reported frequent disconnects while streaming
videos over samba: <http://marc.info/?m=128600031109136>
> [ 1166.512087] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ 1526.059997] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ 2125.324356] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [...]
The reason is that the device generates frames with slightly
bogus SA/TA addresses.
e.g.:
[ 2314.402316] Ignore 9f:1f:31:f8:64:ff
[ 2314.402321] Ignore 9f:1f:31:f8:64:ff
[ 2352.453804] Ignore 0d:1f:31:f8:64:ff
[ 2352.453808] Ignore 0d:1f:31:f8:64:ff
^^ the group-address flag is set!
(the correct SA/TA would be: 00:1f:31:f8:64:ff)
Since the AP does not know from where the frames come, it
generates a DEAUTH response for the (invalid) mcast address.
This mcast deauth frame then passes through all filters and
tricks the stack into thinking that the AP brutally kicked
us!
This patch fixes the problem by simply ignoring
non-broadcast, group-addressed deauth/disassoc frames.
Cc: Jouni Malinen <[email protected]>
Cc: Johannes Berg <[email protected]>
Reported-by: Saqeb Akhter <[email protected]>
Signed-off-by: Christian Lamparter <[email protected]>
---
v1 -> v2:
* johannes pointed out that nl80211 might want
group-addressed action frames.
---
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index d2fcd22..73973d6 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2245,6 +2245,10 @@ ieee80211_rx_h_mgmt(struct ieee80211_rx_data *rx)
break;
case cpu_to_le16(IEEE80211_STYPE_DEAUTH):
case cpu_to_le16(IEEE80211_STYPE_DISASSOC):
+ if (is_multicast_ether_addr(mgmt->da) &&
+ !is_broadcast_ether_addr(mgmt->da))
+ return RX_DROP_MONITOR;
+
/* process only for station */
if (sdata->vif.type != NL80211_IFTYPE_STATION)
return RX_DROP_MONITOR;
On Mon, Nov 29, 2010 at 08:53:23PM +0100, Christian Lamparter wrote:
> This patch fixes an curious issue due to insufficient
> rx frame filtering.
Well.. In theory, there is nothing saying that Deauthentication /
Disassociation frames could not be used with multicast addresses.. Not
that I would expect anyone to really use this option ever.
> [ 2352.453804] Ignore 0d:1f:31:f8:64:ff
> [ 2352.453808] Ignore 0d:1f:31:f8:64:ff
> ^^ the group-address flag is set!
> (the correct SA/TA would be: 00:1f:31:f8:64:ff)
>
> Since the AP does not know from where the frames come, it
> generates a DEAUTH response for the (invalid) mcast address.
> This mcast deauth frame then passes through all filters and
> tricks the stack into thinking that the AP brutally kicked
> us!
This is an interesting frame for from the AP view point, too.. I don't
remember whether there is any explicit statement about the SA being
individual address, but it would sounds reasonable to avoid sending out
Deauth/Disassoc frames based on this type of bogus addresses if the
result would go out as a multicast frame.
> This patch fixes the problem by simply ignoring
> non-broadcast, group-addressed deauth/disassoc frames.
While this is not strictly speaking correct (i.e., we would need to
check whether we are part of the multicast group group), this sounds
like a reasonable thing to do in case of Deauthentication and
Disassociation frames. I don't really see any reasonable use cases for
non-broadcast multicast with them. Action frames may actually get such
use, so the v2 is a good update.
--
Jouni Malinen PGP id EFC895FA