carl9170: wnda3100 only 54MB/s

carl9170: wnda3100 only 54MB/s

[Saqeb Akhter]

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

Re: carl9170: wnda3100 only 54MB/s

[Christian Lamparter]

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

Re: carl9170: wnda3100 only 54MB/s

[Saqeb Akhter]

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 ?

It looks like its maxing out at 54MB/s on a 5Ghz AP, makes me wonder
if its using 802.11a, in lieu of 802.11n ?

-------------------------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.10.52, TCP port 5001
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[148] local 192.168.10.60 port 50087 connected with 192.168.10.52 port 5001
[ ID] Interval       Transfer     Bandwidth
[148]  0.0-10.0 sec  76.0 MBytes  63.7 Mbits/sec  (Windows 7)

-------------------------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.10.52, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.10.60 port 42587 connected with 192.168.10.52 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  25.5 MBytes  21.3 Mbits/sec (Ubuntu)

-------------------------------------------------------------------------------
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

> On Fri, Oct 1, 2010 at 10:36 AM, Christian Lamparter
> <chunkeey@googlemail.com> wrote:
>>
>> 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
>
>

Re: carl9170: wnda3100 only 54MB/s

[Christian Lamparter]

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
 

Re: carl9170: wnda3100 only 54MB/s

[Saqeb Akhter]

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
<chunkeey@googlemail.com> 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
>
>

Re: carl9170: wnda3100 only 54MB/s

[Christian Lamparter]

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

Re: carl9170: wnda3100 only 54MB/s

[Saqeb Akhter]

------------------------------------------------------------
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
<chunkeey@googlemail.com> 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
>

Re: carl9170: wnda3100 only 54MB/s

[Christian Lamparter]

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

Re: carl9170: wnda3100 only 54MB/s

[Saqeb Akhter]

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
<chunkeey@googlemail.com> 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
>

Re: carl9170: wnda3100 only 54MB/s

[Christian Lamparter]

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.

Re: carl9170: wnda3100 only 54MB/s

[Saqeb Akhter]

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
<chunkeey@googlemail.com> 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.
>
>

Re: carl9170: wnda3100 only 54MB/s

[Saqeb Akhter]

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 <saqeb.akhter@gmail.com> 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
> <chunkeey@googlemail.com> 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.
>>
>>
>

Re: carl9170: wnda3100 only 54MB/s

[Christian Lamparter]

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

Re: carl9170: wnda3100 only 54MB/s

[Saqeb Akhter]

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
<chunkeey@googlemail.com> 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
>

[RFC] mac80211: filter multicast rx (was: Re: carl9170: wnda3100 only 54MB/s)

[Christian Lamparter]

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;

[PATCH for-2.6.37?] mac80211: ignore non-bcast mcast managment frames

[Christian Lamparter]

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: <stable@kernel.org>
Cc: Jouni Malinen <j@w1.fi>
Cc: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Saqeb Akhter <saqeb.akhter@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
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;
 

Re: [PATCH for-2.6.37?] mac80211: ignore non-bcast mcast managment frames

[Johannes Berg]

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

[PATCH for-2.6.37 v2] mac80211: ignore non-bcast mcast deauth/disassoc franes

[Christian Lamparter]

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 <j@w1.fi>
Cc: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Saqeb Akhter <saqeb.akhter@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
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;

Re: [PATCH for-2.6.37 v2] mac80211: ignore non-bcast mcast deauth/disassoc franes

[Jouni Malinen]

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

Re: carl9170: wnda3100 only 54MB/s

[Dan Williams]

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