* carl9170: wnda3100 only 54MB/s [not found] <AANLkTimN3X_e4fZhUSoTs-GmQ9kmaJUrgnxAu8=W2dT_@mail.gmail.com> @ 2010-10-01 14:22 ` Saqeb Akhter 2010-10-01 14:36 ` Christian Lamparter 0 siblings, 1 reply; 20+ messages in thread From: Saqeb Akhter @ 2010-10-01 14:22 UTC (permalink / raw) To: linux-wireless 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: carl9170: wnda3100 only 54MB/s 2010-10-01 14:22 ` carl9170: wnda3100 only 54MB/s Saqeb Akhter @ 2010-10-01 14:36 ` Christian Lamparter [not found] ` <AANLkTimZYgDLLag+uGgdojrckZ5tgySC+UeyHCfee74J@mail.gmail.com> 0 siblings, 1 reply; 20+ messages in thread From: Christian Lamparter @ 2010-10-01 14:36 UTC (permalink / raw) To: Saqeb Akhter; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <AANLkTimZYgDLLag+uGgdojrckZ5tgySC+UeyHCfee74J@mail.gmail.com>]
* Re: carl9170: wnda3100 only 54MB/s [not found] ` <AANLkTimZYgDLLag+uGgdojrckZ5tgySC+UeyHCfee74J@mail.gmail.com> @ 2010-10-01 22:34 ` Saqeb Akhter 2010-10-01 22:52 ` Christian Lamparter 1 sibling, 0 replies; 20+ messages in thread From: Saqeb Akhter @ 2010-10-01 22:34 UTC (permalink / raw) To: linux-wireless 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 > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: carl9170: wnda3100 only 54MB/s [not found] ` <AANLkTimZYgDLLag+uGgdojrckZ5tgySC+UeyHCfee74J@mail.gmail.com> 2010-10-01 22:34 ` Saqeb Akhter @ 2010-10-01 22:52 ` Christian Lamparter 2010-10-01 23:56 ` Saqeb Akhter 1 sibling, 1 reply; 20+ messages in thread From: Christian Lamparter @ 2010-10-01 22:52 UTC (permalink / raw) To: linux-wireless; +Cc: Saqeb Akhter 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: carl9170: wnda3100 only 54MB/s 2010-10-01 22:52 ` Christian Lamparter @ 2010-10-01 23:56 ` Saqeb Akhter 2010-10-02 0:26 ` Christian Lamparter 0 siblings, 1 reply; 20+ messages in thread From: Saqeb Akhter @ 2010-10-01 23:56 UTC (permalink / raw) To: linux-wireless 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 > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: carl9170: wnda3100 only 54MB/s 2010-10-01 23:56 ` Saqeb Akhter @ 2010-10-02 0:26 ` Christian Lamparter 2010-10-02 2:32 ` Saqeb Akhter 0 siblings, 1 reply; 20+ messages in thread From: Christian Lamparter @ 2010-10-02 0:26 UTC (permalink / raw) To: Saqeb Akhter; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: carl9170: wnda3100 only 54MB/s 2010-10-02 0:26 ` Christian Lamparter @ 2010-10-02 2:32 ` Saqeb Akhter 2010-10-02 2:52 ` Christian Lamparter 0 siblings, 1 reply; 20+ messages in thread From: Saqeb Akhter @ 2010-10-02 2:32 UTC (permalink / raw) To: linux-wireless ------------------------------------------------------------ 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 > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: carl9170: wnda3100 only 54MB/s 2010-10-02 2:32 ` Saqeb Akhter @ 2010-10-02 2:52 ` Christian Lamparter 2010-10-02 2:56 ` Saqeb Akhter 0 siblings, 1 reply; 20+ messages in thread From: Christian Lamparter @ 2010-10-02 2:52 UTC (permalink / raw) To: Saqeb Akhter; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: carl9170: wnda3100 only 54MB/s 2010-10-02 2:52 ` Christian Lamparter @ 2010-10-02 2:56 ` Saqeb Akhter 2010-10-02 3:19 ` Christian Lamparter 0 siblings, 1 reply; 20+ messages in thread From: Saqeb Akhter @ 2010-10-02 2:56 UTC (permalink / raw) To: linux-wireless 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 > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: carl9170: wnda3100 only 54MB/s 2010-10-02 2:56 ` Saqeb Akhter @ 2010-10-02 3:19 ` Christian Lamparter 2010-10-02 3:28 ` Saqeb Akhter 2010-10-04 17:58 ` carl9170: wnda3100 only 54MB/s Dan Williams 0 siblings, 2 replies; 20+ messages in thread From: Christian Lamparter @ 2010-10-02 3:19 UTC (permalink / raw) To: Saqeb Akhter; +Cc: linux-wireless 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: carl9170: wnda3100 only 54MB/s 2010-10-02 3:19 ` Christian Lamparter @ 2010-10-02 3:28 ` Saqeb Akhter 2010-10-02 6:18 ` Saqeb Akhter 2010-10-04 17:58 ` carl9170: wnda3100 only 54MB/s Dan Williams 1 sibling, 1 reply; 20+ messages in thread From: Saqeb Akhter @ 2010-10-02 3:28 UTC (permalink / raw) To: linux-wireless 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. > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: carl9170: wnda3100 only 54MB/s 2010-10-02 3:28 ` Saqeb Akhter @ 2010-10-02 6:18 ` Saqeb Akhter 2010-10-02 11:32 ` Christian Lamparter 0 siblings, 1 reply; 20+ messages in thread From: Saqeb Akhter @ 2010-10-02 6:18 UTC (permalink / raw) To: linux-wireless 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. >> >> > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: carl9170: wnda3100 only 54MB/s 2010-10-02 6:18 ` Saqeb Akhter @ 2010-10-02 11:32 ` Christian Lamparter 2010-10-02 16:40 ` Saqeb Akhter 2010-11-29 17:14 ` [RFC] mac80211: filter multicast rx (was: Re: carl9170: wnda3100 only 54MB/s) Christian Lamparter 0 siblings, 2 replies; 20+ messages in thread From: Christian Lamparter @ 2010-10-02 11:32 UTC (permalink / raw) To: Saqeb Akhter; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: carl9170: wnda3100 only 54MB/s 2010-10-02 11:32 ` Christian Lamparter @ 2010-10-02 16:40 ` Saqeb Akhter 2010-11-29 17:14 ` [RFC] mac80211: filter multicast rx (was: Re: carl9170: wnda3100 only 54MB/s) Christian Lamparter 1 sibling, 0 replies; 20+ messages in thread From: Saqeb Akhter @ 2010-10-02 16:40 UTC (permalink / raw) To: linux-wireless 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 > ^ permalink raw reply [flat|nested] 20+ messages in thread
* [RFC] mac80211: filter multicast rx (was: Re: carl9170: wnda3100 only 54MB/s) 2010-10-02 11:32 ` Christian Lamparter 2010-10-02 16:40 ` Saqeb Akhter @ 2010-11-29 17:14 ` Christian Lamparter 2010-11-29 18:37 ` [PATCH for-2.6.37?] mac80211: ignore non-bcast mcast managment frames Christian Lamparter 1 sibling, 1 reply; 20+ messages in thread From: Christian Lamparter @ 2010-11-29 17:14 UTC (permalink / raw) To: Saqeb Akhter; +Cc: linux-wireless, Johannes Berg, Jouni Malinen 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; ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH for-2.6.37?] mac80211: ignore non-bcast mcast managment frames 2010-11-29 17:14 ` [RFC] mac80211: filter multicast rx (was: Re: carl9170: wnda3100 only 54MB/s) Christian Lamparter @ 2010-11-29 18:37 ` Christian Lamparter 2010-11-29 18:45 ` Johannes Berg 0 siblings, 1 reply; 20+ messages in thread From: Christian Lamparter @ 2010-11-29 18:37 UTC (permalink / raw) To: Saqeb Akhter; +Cc: linux-wireless, Johannes Berg, Jouni Malinen, linville 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; ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH for-2.6.37?] mac80211: ignore non-bcast mcast managment frames 2010-11-29 18:37 ` [PATCH for-2.6.37?] mac80211: ignore non-bcast mcast managment frames Christian Lamparter @ 2010-11-29 18:45 ` Johannes Berg 2010-11-29 19:53 ` [PATCH for-2.6.37 v2] mac80211: ignore non-bcast mcast deauth/disassoc franes Christian Lamparter 0 siblings, 1 reply; 20+ messages in thread From: Johannes Berg @ 2010-11-29 18:45 UTC (permalink / raw) To: Christian Lamparter; +Cc: Saqeb Akhter, linux-wireless, Jouni Malinen, linville 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH for-2.6.37 v2] mac80211: ignore non-bcast mcast deauth/disassoc franes 2010-11-29 18:45 ` Johannes Berg @ 2010-11-29 19:53 ` Christian Lamparter 2010-12-04 21:38 ` Jouni Malinen 0 siblings, 1 reply; 20+ messages in thread From: Christian Lamparter @ 2010-11-29 19:53 UTC (permalink / raw) To: Johannes Berg; +Cc: Saqeb Akhter, linux-wireless, Jouni Malinen, linville 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; ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH for-2.6.37 v2] mac80211: ignore non-bcast mcast deauth/disassoc franes 2010-11-29 19:53 ` [PATCH for-2.6.37 v2] mac80211: ignore non-bcast mcast deauth/disassoc franes Christian Lamparter @ 2010-12-04 21:38 ` Jouni Malinen 0 siblings, 0 replies; 20+ messages in thread From: Jouni Malinen @ 2010-12-04 21:38 UTC (permalink / raw) To: Christian Lamparter; +Cc: Johannes Berg, Saqeb Akhter, linux-wireless, linville 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: carl9170: wnda3100 only 54MB/s 2010-10-02 3:19 ` Christian Lamparter 2010-10-02 3:28 ` Saqeb Akhter @ 2010-10-04 17:58 ` Dan Williams 1 sibling, 0 replies; 20+ messages in thread From: Dan Williams @ 2010-10-04 17:58 UTC (permalink / raw) To: Christian Lamparter; +Cc: Saqeb Akhter, linux-wireless 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2010-12-04 21:39 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <AANLkTimN3X_e4fZhUSoTs-GmQ9kmaJUrgnxAu8=W2dT_@mail.gmail.com>
2010-10-01 14:22 ` carl9170: wnda3100 only 54MB/s Saqeb Akhter
2010-10-01 14:36 ` Christian Lamparter
[not found] ` <AANLkTimZYgDLLag+uGgdojrckZ5tgySC+UeyHCfee74J@mail.gmail.com>
2010-10-01 22:34 ` Saqeb Akhter
2010-10-01 22:52 ` Christian Lamparter
2010-10-01 23:56 ` Saqeb Akhter
2010-10-02 0:26 ` Christian Lamparter
2010-10-02 2:32 ` Saqeb Akhter
2010-10-02 2:52 ` Christian Lamparter
2010-10-02 2:56 ` Saqeb Akhter
2010-10-02 3:19 ` Christian Lamparter
2010-10-02 3:28 ` Saqeb Akhter
2010-10-02 6:18 ` Saqeb Akhter
2010-10-02 11:32 ` Christian Lamparter
2010-10-02 16:40 ` Saqeb Akhter
2010-11-29 17:14 ` [RFC] mac80211: filter multicast rx (was: Re: carl9170: wnda3100 only 54MB/s) Christian Lamparter
2010-11-29 18:37 ` [PATCH for-2.6.37?] mac80211: ignore non-bcast mcast managment frames Christian Lamparter
2010-11-29 18:45 ` Johannes Berg
2010-11-29 19:53 ` [PATCH for-2.6.37 v2] mac80211: ignore non-bcast mcast deauth/disassoc franes Christian Lamparter
2010-12-04 21:38 ` Jouni Malinen
2010-10-04 17:58 ` carl9170: wnda3100 only 54MB/s Dan Williams
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).