* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) @ 2009-01-28 2:55 Chris Kennedy 2009-01-28 3:17 ` Luis R. Rodriguez 0 siblings, 1 reply; 22+ messages in thread From: Chris Kennedy @ 2009-01-28 2:55 UTC (permalink / raw) To: ath9k-devel I have a DWA-552 and am in the US, using the newest wireless testing as of an hour ago. I have things working from the Jan 20th wireless testing, but since then these newer ones have not let me change the reg domain (even with newest version containing the fix). I have attached my boot up log and trying to change the reg domain to US, iw --debug output. It just won't use anything but the CO reg domain, can't change it from that for some odd reason. I'm trying to use AP mode, but just booting up and trying set the reg domain properly to US doesn't happen, and I can't use it because all channels are invalid I try (even when having hostapd not fail when the set reg domain call returns an error). Something seems wrong, if my card has the regdomain wrong and set to CO, that seems like it's useless unless that value is ignored, but works great as an AP in pre Jan 16 versions. Thanks, Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: log.gz Type: application/x-gzip Size: 7376 bytes Desc: not available Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090127/c283cfaf/attachment.bin ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-01-28 2:55 [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) Chris Kennedy @ 2009-01-28 3:17 ` Luis R. Rodriguez 2009-01-28 4:24 ` Chris Kennedy 0 siblings, 1 reply; 22+ messages in thread From: Luis R. Rodriguez @ 2009-01-28 3:17 UTC (permalink / raw) To: ath9k-devel On Tue, Jan 27, 2009 at 06:55:20PM -0800, Chris Kennedy wrote: > I have a DWA-552 and am in the US, using the newest wireless testing > as of an hour ago. > I have things working from the Jan 20th wireless testing, but since > then these newer > ones have not let me change the reg domain (even with newest version > containing the > fix). I have attached my boot up log and trying to change the reg > domain to US, iw --debug > output. It just won't use anything but the CO reg domain, can't > change it from that for some > odd reason. I'm trying to use AP mode, but just booting up and > trying set the reg domain > properly to US doesn't happen, and I can't use it because all > channels are invalid I try (even > when having hostapd not fail when the set reg domain call returns an > error). Something > seems wrong, if my card has the regdomain wrong and set to CO, that > seems like it's useless > unless that value is ignored, but works great as an AP in pre Jan 16 > versions. > > Thanks, > Chris Chris, It seems you do not have CRDA or the wireless-regdb installed, please install these as they are now required, otherwise a minimal world regulatory domain is set (what you are seeing). By shifting code to userspace we have reduced the size of ath9k, and since CRDA is no part of the regulatory support for Linux in general distributions in general will be shipping it soon. http://wireless.kernel.org/download/wireless-regdb/wireless-regdb-2009.01.15.tar.bz2 Once in the directory just do (no need to build): sudo make install http://wireless.kernel.org/download/crda/crda-1.0.1.tar.bz2 crda requires proper building: make sudo make install http://wireless.kernel.org/en/developers/Regulatory That should correct your info to match your Colombia regulatory domain: country CO: (2402 - 2472 @ 40), (3, 27) (5170 - 5250 @ 20), (3, 17) (5250 - 5330 @ 20), (3, 23), DFS (5735 - 5835 @ 20), (3, 30) Here is your card's reg info: -- ath9k: Country alpha2 being used: CO Regpair detected: 0x10 -- Here is your channel info because you lack CRDA (seems you have single 2.4 GHz band card): -- Frequencies: * 2412 MHz [1] (20.0 dBm) (passive scanning, no IBSS) * 2417 MHz [2] (20.0 dBm) (passive scanning, no IBSS) * 2422 MHz [3] (20.0 dBm) (passive scanning, no IBSS) * 2427 MHz [4] (20.0 dBm) (passive scanning, no IBSS) * 2432 MHz [5] (20.0 dBm) (passive scanning, no IBSS) * 2437 MHz [6] (20.0 dBm) (passive scanning, no IBSS) * 2442 MHz [7] (20.0 dBm) (passive scanning, no IBSS) * 2447 MHz [8] (20.0 dBm) (passive scanning, no IBSS) * 2452 MHz [9] (20.0 dBm) (passive scanning, no IBSS) * 2457 MHz [10] (20.0 dBm) (passive scanning, no IBSS) * 2462 MHz [11] (20.0 dBm) (passive scanning, no IBSS) * 2467 MHz [12] (disabled) * 2472 MHz [13] (disabled) * 2484 MHz [14] (disabled) -- Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-01-28 3:17 ` Luis R. Rodriguez @ 2009-01-28 4:24 ` Chris Kennedy 2009-01-28 6:10 ` Luis R. Rodriguez 0 siblings, 1 reply; 22+ messages in thread From: Chris Kennedy @ 2009-01-28 4:24 UTC (permalink / raw) To: ath9k-devel On Jan 27, 2009, at 9:17 PM, Luis R. Rodriguez wrote: > On Tue, Jan 27, 2009 at 06:55:20PM -0800, Chris Kennedy wrote: >> I have a DWA-552 and am in the US, using the newest wireless testing >> as of an hour ago. >> I have things working from the Jan 20th wireless testing, but since >> then these newer >> ones have not let me change the reg domain (even with newest version >> containing the >> fix). I have attached my boot up log and trying to change the reg >> domain to US, iw --debug >> output. It just won't use anything but the CO reg domain, can't >> change it from that for some >> odd reason. I'm trying to use AP mode, but just booting up and >> trying set the reg domain >> properly to US doesn't happen, and I can't use it because all >> channels are invalid I try (even >> when having hostapd not fail when the set reg domain call returns an >> error). Something >> seems wrong, if my card has the regdomain wrong and set to CO, that >> seems like it's useless >> unless that value is ignored, but works great as an AP in pre Jan 16 >> versions. >> >> Thanks, >> Chris > > Chris, > > It seems you do not have CRDA or the wireless-regdb installed, please > install these as they are now required, otherwise a minimal world > regulatory > domain is set (what you are seeing). By shifting code to userspace > we have > reduced the size of ath9k, and since CRDA is no part of the > regulatory support > for Linux in general distributions in general will be shipping it > soon. > > http://wireless.kernel.org/download/wireless-regdb/wireless- > regdb-2009.01.15.tar.bz2 > Once in the directory just do (no need to build): > > sudo make install > > http://wireless.kernel.org/download/crda/crda-1.0.1.tar.bz2 > > crda requires proper building: > > make > sudo make install > > http://wireless.kernel.org/en/developers/Regulatory I've actually already installed the newest git versions of both crda and wireless-regdb, Although I just realized I didn't put the udev file into the /etc/udev/ area for this system, after putting that file into place It now starts up hostapd alright and allows changing the regulatory domain with the newest wireless testing kernel. That seems ok, except now my wireless clients can't connect, in fact the hostapd log doesn't seem like they are even talking properly, there's no loging of them trying to associate (but can see AP and stay forever trying to setup the network). I tried US and CO in hostapd but either does the same thing, tried channels 11, 1, 3 and 7 so far. WIth that udev file setup, it works nicely now in my Jan 16 wireless testing kernel, uses that now instead of the default kernel built-in stuff. Is there anything I'm doing wrong, seems like since the card is using CO and my clients are in US that maybe they aren't going to talk? Thanks, Chris > > That should correct your info to match your Colombia regulatory > domain: > > country CO: > (2402 - 2472 @ 40), (3, 27) > (5170 - 5250 @ 20), (3, 17) > (5250 - 5330 @ 20), (3, 23), DFS > (5735 - 5835 @ 20), (3, 30) > > Here is your card's reg info: > > -- > ath9k: Country alpha2 being used: CO > Regpair detected: 0x10 > -- > > Here is your channel info because you lack CRDA (seems you have > single 2.4 GHz band card): > > -- > Frequencies: > * 2412 MHz [1] (20.0 dBm) (passive > scanning, no IBSS) > * 2417 MHz [2] (20.0 dBm) (passive > scanning, no IBSS) > * 2422 MHz [3] (20.0 dBm) (passive > scanning, no IBSS) > * 2427 MHz [4] (20.0 dBm) (passive > scanning, no IBSS) > * 2432 MHz [5] (20.0 dBm) (passive > scanning, no IBSS) > * 2437 MHz [6] (20.0 dBm) (passive > scanning, no IBSS) > * 2442 MHz [7] (20.0 dBm) (passive > scanning, no IBSS) > * 2447 MHz [8] (20.0 dBm) (passive > scanning, no IBSS) > * 2452 MHz [9] (20.0 dBm) (passive > scanning, no IBSS) > * 2457 MHz [10] (20.0 dBm) (passive > scanning, no IBSS) > * 2462 MHz [11] (20.0 dBm) (passive > scanning, no IBSS) > * 2467 MHz [12] (disabled) > * 2472 MHz [13] (disabled) > * 2484 MHz [14] (disabled) > -- > > Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-01-28 4:24 ` Chris Kennedy @ 2009-01-28 6:10 ` Luis R. Rodriguez 2009-01-28 9:39 ` Chris Kennedy 0 siblings, 1 reply; 22+ messages in thread From: Luis R. Rodriguez @ 2009-01-28 6:10 UTC (permalink / raw) To: ath9k-devel On Tue, Jan 27, 2009 at 08:24:31PM -0800, Chris Kennedy wrote: > > On Jan 27, 2009, at 9:17 PM, Luis R. Rodriguez wrote: > > > On Tue, Jan 27, 2009 at 06:55:20PM -0800, Chris Kennedy wrote: > >> I have a DWA-552 and am in the US, using the newest wireless testing > >> as of an hour ago. > >> I have things working from the Jan 20th wireless testing, but since > >> then these newer > >> ones have not let me change the reg domain (even with newest version > >> containing the > >> fix). I have attached my boot up log and trying to change the reg > >> domain to US, iw --debug > >> output. It just won't use anything but the CO reg domain, can't > >> change it from that for some > >> odd reason. I'm trying to use AP mode, but just booting up and > >> trying set the reg domain > >> properly to US doesn't happen, and I can't use it because all > >> channels are invalid I try (even > >> when having hostapd not fail when the set reg domain call returns an > >> error). Something > >> seems wrong, if my card has the regdomain wrong and set to CO, that > >> seems like it's useless > >> unless that value is ignored, but works great as an AP in pre Jan 16 > >> versions. > >> > >> Thanks, > >> Chris > > > > Chris, > > > > It seems you do not have CRDA or the wireless-regdb installed, please > > install these as they are now required, otherwise a minimal world > > regulatory > > domain is set (what you are seeing). By shifting code to userspace > > we have > > reduced the size of ath9k, and since CRDA is no part of the > > regulatory support > > for Linux in general distributions in general will be shipping it > > soon. > > > > http://wireless.kernel.org/download/wireless-regdb/wireless- > > regdb-2009.01.15.tar.bz2 > > Once in the directory just do (no need to build): > > > > sudo make install > > > > http://wireless.kernel.org/download/crda/crda-1.0.1.tar.bz2 > > > > crda requires proper building: > > > > make > > sudo make install > > > > http://wireless.kernel.org/en/developers/Regulatory > > > I've actually already installed the newest git versions of both crda > and wireless-regdb, Although I just realized I didn't put the udev > file into > the /etc/udev/ area for this system, after putting that file into > place It now > starts up hostapd alright and allows changing the regulatory domain > with the newest wireless testing kernel. Great. > That seems ok, except now my wireless clients can't connect, in fact the > hostapd log doesn't seem like they are even talking properly, there's no > loging of them trying to associate (but can see AP and stay forever > trying > to setup the network). I tried US and CO in hostapd but either does > the same > thing, tried channels 11, 1, 3 and 7 so far. Are you using hostapd from git? What are you using for your clients, what cards, what drivers, what OS? > WIth that udev file setup, it works nicely now in my Jan 16 wireless > testing kernel, > uses that now instead of the default kernel built-in stuff. Is there > anything I'm doing > wrong, seems like since the card is using CO and my clients are in US > that maybe > they aren't going to talk? If your AP is up I believe you should at least see some stuff in the logs, will see if I can try to reproduce your issue in the morning, for now going to get some sleep. Just one thing -- keep in mind that when you have a country value on your ath9k card it will be respected and when a user then enters a country you are helping compliance, not overriding it. That said you are getting the intersection between CO and US when trying to apply US on your CO card. Please show your latest 'iw list' output, and provide your hostapd log. Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-01-28 6:10 ` Luis R. Rodriguez @ 2009-01-28 9:39 ` Chris Kennedy 2009-01-30 17:39 ` Luis R. Rodriguez 0 siblings, 1 reply; 22+ messages in thread From: Chris Kennedy @ 2009-01-28 9:39 UTC (permalink / raw) To: ath9k-devel On Jan 28, 2009, at 12:10 AM, Luis R. Rodriguez wrote: > On Tue, Jan 27, 2009 at 08:24:31PM -0800, Chris Kennedy wrote: >> >> On Jan 27, 2009, at 9:17 PM, Luis R. Rodriguez wrote: >> >>> On Tue, Jan 27, 2009 at 06:55:20PM -0800, Chris Kennedy wrote: >>>> I have a DWA-552 and am in the US, using the newest wireless >>>> testing >>>> as of an hour ago. >>>> I have things working from the Jan 20th wireless testing, but since >>>> then these newer >>>> ones have not let me change the reg domain (even with newest >>>> version >>>> containing the >>>> fix). I have attached my boot up log and trying to change the reg >>>> domain to US, iw --debug >>>> output. It just won't use anything but the CO reg domain, can't >>>> change it from that for some >>>> odd reason. I'm trying to use AP mode, but just booting up and >>>> trying set the reg domain >>>> properly to US doesn't happen, and I can't use it because all >>>> channels are invalid I try (even >>>> when having hostapd not fail when the set reg domain call >>>> returns an >>>> error). Something >>>> seems wrong, if my card has the regdomain wrong and set to CO, that >>>> seems like it's useless >>>> unless that value is ignored, but works great as an AP in pre >>>> Jan 16 >>>> versions. >>>> >>>> Thanks, >>>> Chris >>> >>> Chris, >>> >>> It seems you do not have CRDA or the wireless-regdb installed, >>> please >>> install these as they are now required, otherwise a minimal world >>> regulatory >>> domain is set (what you are seeing). By shifting code to userspace >>> we have >>> reduced the size of ath9k, and since CRDA is no part of the >>> regulatory support >>> for Linux in general distributions in general will be shipping it >>> soon. >>> >>> http://wireless.kernel.org/download/wireless-regdb/wireless- >>> regdb-2009.01.15.tar.bz2 >>> Once in the directory just do (no need to build): >>> >>> sudo make install >>> >>> http://wireless.kernel.org/download/crda/crda-1.0.1.tar.bz2 >>> >>> crda requires proper building: >>> >>> make >>> sudo make install >>> >>> http://wireless.kernel.org/en/developers/Regulatory >> >> >> I've actually already installed the newest git versions of both crda >> and wireless-regdb, Although I just realized I didn't put the udev >> file into >> the /etc/udev/ area for this system, after putting that file into >> place It now >> starts up hostapd alright and allows changing the regulatory domain >> with the newest wireless testing kernel. > > Great. > >> That seems ok, except now my wireless clients can't connect, in >> fact the >> hostapd log doesn't seem like they are even talking properly, >> there's no >> loging of them trying to associate (but can see AP and stay forever >> trying >> to setup the network). I tried US and CO in hostapd but either does >> the same >> thing, tried channels 11, 1, 3 and 7 so far. > > Are you using hostapd from git? What are you using for your > clients, what > cards, what drivers, what OS? I'm using the current hostapd from git, 2 Win XP clients using Linksys WMP300N cards (newest driver for those) (US ones with Broadcom chips), and a Ubuntu Linux client (newest git wpa_supplicant) with a ipw2200 (newest wireless testing kernel) Intel 802.11g card. I've got it setup for 802.11n, although I tried just turning that off in hostapd.conf and still didn't work. > >> WIth that udev file setup, it works nicely now in my Jan 16 wireless >> testing kernel, >> uses that now instead of the default kernel built-in stuff. Is there >> anything I'm doing >> wrong, seems like since the card is using CO and my clients are in US >> that maybe >> they aren't going to talk? > > If your AP is up I believe you should at least see some stuff in > the logs, > will see if I can try to reproduce your issue in the morning, for > now going > to get some sleep. > > Just one thing -- keep in mind that when you have a country value > on your > ath9k card it will be respected and when a user then enters a > country you > are helping compliance, not overriding it. That said you are > getting the > intersection between CO and US when trying to apply US on your CO > card. > > Please show your latest 'iw list' output, and provide your hostapd > log. I've attached a tar ball of logs, the iw list output, the debugging dmesg again, the hostapd logs in syslog and output with -dd as command line args. Basically on higher debugging for hostapd, I see the stations just constantly repeat trying to authenticate. I'm using WPA2 (tried with 80211d=1 and =0)... # IEEE 802.11 related configuration ssid=MilkyWay country_code=US ieee80211d=1 hw_mode=g channel=7 # bridge=ap0 ieee80211n=1 ht_capab=[HT40+][SHORT-GI-40] wpa=3 wpa_passphrase=XXXXXXXXX wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP rsn_pairwise=CCMP Thanks, Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: logs.tgz Type: application/octet-stream Size: 10472 bytes Desc: not available Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090128/95f314e4/attachment.obj -------------- next part -------------- > > Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-01-28 9:39 ` Chris Kennedy @ 2009-01-30 17:39 ` Luis R. Rodriguez 2009-01-31 1:23 ` Chris Kennedy 0 siblings, 1 reply; 22+ messages in thread From: Luis R. Rodriguez @ 2009-01-30 17:39 UTC (permalink / raw) To: ath9k-devel On Wed, Jan 28, 2009 at 01:39:51AM -0800, Chris Kennedy wrote: > > On Jan 28, 2009, at 12:10 AM, Luis R. Rodriguez wrote: > > > On Tue, Jan 27, 2009 at 08:24:31PM -0800, Chris Kennedy wrote: > >> > >> On Jan 27, 2009, at 9:17 PM, Luis R. Rodriguez wrote: > >> > >>> On Tue, Jan 27, 2009 at 06:55:20PM -0800, Chris Kennedy wrote: > >>>> I have a DWA-552 and am in the US, using the newest wireless > >>>> testing > >>>> as of an hour ago. > >>>> I have things working from the Jan 20th wireless testing, but since > >>>> then these newer > >>>> ones have not let me change the reg domain (even with newest > >>>> version > >>>> containing the > >>>> fix). I have attached my boot up log and trying to change the reg > >>>> domain to US, iw --debug > >>>> output. It just won't use anything but the CO reg domain, can't > >>>> change it from that for some > >>>> odd reason. I'm trying to use AP mode, but just booting up and > >>>> trying set the reg domain > >>>> properly to US doesn't happen, and I can't use it because all > >>>> channels are invalid I try (even > >>>> when having hostapd not fail when the set reg domain call > >>>> returns an > >>>> error). Something > >>>> seems wrong, if my card has the regdomain wrong and set to CO, that > >>>> seems like it's useless > >>>> unless that value is ignored, but works great as an AP in pre > >>>> Jan 16 > >>>> versions. > >>>> > >>>> Thanks, > >>>> Chris > >>> > >>> Chris, > >>> > >>> It seems you do not have CRDA or the wireless-regdb installed, > >>> please > >>> install these as they are now required, otherwise a minimal world > >>> regulatory > >>> domain is set (what you are seeing). By shifting code to userspace > >>> we have > >>> reduced the size of ath9k, and since CRDA is no part of the > >>> regulatory support > >>> for Linux in general distributions in general will be shipping it > >>> soon. > >>> > >>> http://wireless.kernel.org/download/wireless-regdb/wireless- > >>> regdb-2009.01.15.tar.bz2 > >>> Once in the directory just do (no need to build): > >>> > >>> sudo make install > >>> > >>> http://wireless.kernel.org/download/crda/crda-1.0.1.tar.bz2 > >>> > >>> crda requires proper building: > >>> > >>> make > >>> sudo make install > >>> > >>> http://wireless.kernel.org/en/developers/Regulatory > >> > >> > >> I've actually already installed the newest git versions of both crda > >> and wireless-regdb, Although I just realized I didn't put the udev > >> file into > >> the /etc/udev/ area for this system, after putting that file into > >> place It now > >> starts up hostapd alright and allows changing the regulatory domain > >> with the newest wireless testing kernel. > > > > Great. > > > >> That seems ok, except now my wireless clients can't connect, in > >> fact the > >> hostapd log doesn't seem like they are even talking properly, > >> there's no > >> loging of them trying to associate (but can see AP and stay forever > >> trying > >> to setup the network). I tried US and CO in hostapd but either does > >> the same > >> thing, tried channels 11, 1, 3 and 7 so far. > > > > Are you using hostapd from git? What are you using for your > > clients, what > > cards, what drivers, what OS? > > > I'm using the current hostapd from git, 2 Win XP clients using > Linksys WMP300N cards (newest driver for those) > (US ones with Broadcom chips), and a Ubuntu Linux client (newest git > wpa_supplicant) > with a ipw2200 (newest wireless testing kernel) Intel 802.11g card. > I've got it setup for 802.11n, although I tried just > turning that off in hostapd.conf and still didn't work. > > > > > >> WIth that udev file setup, it works nicely now in my Jan 16 wireless > >> testing kernel, > >> uses that now instead of the default kernel built-in stuff. Is there > >> anything I'm doing > >> wrong, seems like since the card is using CO and my clients are in US > >> that maybe > >> they aren't going to talk? > > > > If your AP is up I believe you should at least see some stuff in > > the logs, > > will see if I can try to reproduce your issue in the morning, for > > now going > > to get some sleep. > > > > Just one thing -- keep in mind that when you have a country value > > on your > > ath9k card it will be respected and when a user then enters a > > country you > > are helping compliance, not overriding it. That said you are > > getting the > > intersection between CO and US when trying to apply US on your CO > > card. > > > > Please show your latest 'iw list' output, and provide your hostapd > > log. > > I've attached a tar ball of logs, the iw list output, the debugging > dmesg again, > the hostapd logs in syslog and output with -dd as command line args. > Basically > on higher debugging for hostapd, I see the stations just constantly > repeat > trying to authenticate. I'm using WPA2 (tried with 80211d=1 and =0)... > > # IEEE 802.11 related configuration > ssid=MilkyWay > country_code=US > ieee80211d=1 > hw_mode=g > channel=7 > # > bridge=ap0 > > ieee80211n=1 > ht_capab=[HT40+][SHORT-GI-40] > > wpa=3 > wpa_passphrase=XXXXXXXXX > wpa_key_mgmt=WPA-PSK > wpa_pairwise=CCMP > rsn_pairwise=CCMP Jouni found there was an issue with this patch which breaks AP mode. commit e22cab741afdd1e9857ea9fe51e28a6fe3c97b90 Author: Stephen Hemminger <shemminger@vyatta.com> Date: Tue Jan 27 05:29:25 2009 +1100 mac80211: convert to net_device_ops Convert to new net_device_ops in 2.6.28 and later. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.c --- Johannes just posted some patches to correct, this you may wnat to try those out, or wait until they get merged. Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-01-30 17:39 ` Luis R. Rodriguez @ 2009-01-31 1:23 ` Chris Kennedy 2009-01-31 4:12 ` Chris Kennedy 2009-02-02 21:06 ` Luis R. Rodriguez 0 siblings, 2 replies; 22+ messages in thread From: Chris Kennedy @ 2009-01-31 1:23 UTC (permalink / raw) To: ath9k-devel On Jan 30, 2009, at 11:39 AM, Luis R. Rodriguez wrote: > > Jouni found there was an issue with this patch which breaks > AP mode. > > commit e22cab741afdd1e9857ea9fe51e28a6fe3c97b90 > Author: Stephen Hemminger <shemminger@vyatta.com> > Date: Tue Jan 27 05:29:25 2009 +1100 > > mac80211: convert to net_device_ops > > Convert to new net_device_ops in 2.6.28 and later. > > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> > Acked-by: Johannes Berg <johannes@sipsolutions.net> > Signed-off-by: John W. Linville <linville@tuxdriver.c > > --- > > Johannes just posted some patches to correct, this you may > wnat to try those out, or wait until they get merged. > > Luis Great, it does seem to allow me to connect now with the newest wireless-testing. The bad part though is it won't connect above 11Mbps now, although iperf shows it definitely gets all 11 Mbit of bandwidth, but nothing more. (and of course using 802.11n) Is this because of the iw list output showing that (short preamble supported) for 2,5.5 and 11Mbps? Here's the current iw list output now... Wiphy phy0 Band 1: HT capabilities: 0x104e * 20/40 MHz operation * SM PS disabled * 40 MHz short GI * max A-MSDU len 3839 * DSSS/CCK 40 MHz HT A-MPDU factor: 0x0003 (65535 bytes) HT A-MPDU density: 0x0006 (8 usec) HT MCS set: ff ff 00 00 00 00 00 00 00 00 00 00 01 00 00 00 Frequencies: * 2412 MHz [1] (27.0 dBm) * 2417 MHz [2] (27.0 dBm) * 2422 MHz [3] (27.0 dBm) * 2427 MHz [4] (27.0 dBm) * 2432 MHz [5] (27.0 dBm) * 2437 MHz [6] (27.0 dBm) * 2442 MHz [7] (27.0 dBm) * 2447 MHz [8] (27.0 dBm) * 2452 MHz [9] (27.0 dBm) * 2457 MHz [10] (27.0 dBm) * 2462 MHz [11] (27.0 dBm) * 2467 MHz [12] (disabled) * 2472 MHz [13] (disabled) * 2484 MHz [14] (disabled) Bitrates: * 1.0 Mbps * 2.0 Mbps (short preamble supported) * 5.5 Mbps (short preamble supported) * 11.0 Mbps (short preamble supported) * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Supported interface modes: * IBSS * Station * AP * AP(VLAN) * Monitor Thanks, Chris ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-01-31 1:23 ` Chris Kennedy @ 2009-01-31 4:12 ` Chris Kennedy 2009-02-02 21:06 ` Luis R. Rodriguez 1 sibling, 0 replies; 22+ messages in thread From: Chris Kennedy @ 2009-01-31 4:12 UTC (permalink / raw) To: ath9k-devel On Jan 30, 2009, at 7:23 PM, Chris Kennedy wrote: > > On Jan 30, 2009, at 11:39 AM, Luis R. Rodriguez wrote: >> >> Jouni found there was an issue with this patch which breaks >> AP mode. >> >> commit e22cab741afdd1e9857ea9fe51e28a6fe3c97b90 >> Author: Stephen Hemminger <shemminger@vyatta.com> >> Date: Tue Jan 27 05:29:25 2009 +1100 >> >> mac80211: convert to net_device_ops >> >> Convert to new net_device_ops in 2.6.28 and later. >> >> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> >> Acked-by: Johannes Berg <johannes@sipsolutions.net> >> Signed-off-by: John W. Linville <linville@tuxdriver.c >> >> --- >> >> Johannes just posted some patches to correct, this you may >> wnat to try those out, or wait until they get merged. >> >> Luis > > > Great, it does seem to allow me to connect now with the newest > wireless-testing. > The bad part though is it won't connect above 11Mbps now, although > iperf shows > it definitely gets all 11 Mbit of bandwidth, but nothing more. (and > of course using 802.11n) > > Is this because of the iw list output showing that (short preamble > supported) for 2,5.5 and 11Mbps? > Here's the current iw list output now... > Well it's something else I guess, back in the old kernel I was using still getting less than 11Mbps speeds now. Weird, it's like the card just became slow, although I am still investigating since I hadn't been using it for my AP for a few days. Seems to be just slow and sometimes doesn't get a DHCP address because of it, very odd, but seems to not have anything to do with which kernel I use. Thanks, Chris ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-01-31 1:23 ` Chris Kennedy 2009-01-31 4:12 ` Chris Kennedy @ 2009-02-02 21:06 ` Luis R. Rodriguez 2009-02-02 21:35 ` Chris Kennedy 1 sibling, 1 reply; 22+ messages in thread From: Luis R. Rodriguez @ 2009-02-02 21:06 UTC (permalink / raw) To: ath9k-devel On Fri, Jan 30, 2009 at 05:23:06PM -0800, Chris Kennedy wrote: > > On Jan 30, 2009, at 11:39 AM, Luis R. Rodriguez wrote: > > > > Jouni found there was an issue with this patch which breaks > > AP mode. > > > > commit e22cab741afdd1e9857ea9fe51e28a6fe3c97b90 > > Author: Stephen Hemminger <shemminger@vyatta.com> > > Date: Tue Jan 27 05:29:25 2009 +1100 > > > > mac80211: convert to net_device_ops > > > > Convert to new net_device_ops in 2.6.28 and later. > > > > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> > > Acked-by: Johannes Berg <johannes@sipsolutions.net> > > Signed-off-by: John W. Linville <linville@tuxdriver.c > > > > --- > > > > Johannes just posted some patches to correct, this you may > > wnat to try those out, or wait until they get merged. > > > > Luis > > > Great, it does seem to allow me to connect now with the newest > wireless-testing. > The bad part though is it won't connect above 11Mbps now, although > iperf shows > it definitely gets all 11 Mbit of bandwidth, but nothing more. (and > of course using 802.11n) Keep in mind getting 11 Mbit/s on throughput is not the same as using 11 Mbit/s rate on the card. For example an average 802.11g capable card using 54 Mbit/s can achieve around ~ 20-25 Mbit/s although it will probably will actually be using the 54 Mbit/s OFDM rate. Regardless getting only 11 Mbit/s throughput with an 11N AP and 11N STA is pretty bad. What cards are you using for STAs? How about for AP (AR5416, or AR9280 or what)? > Is this because of the iw list output showing that (short preamble > supported) for 2,5.5 and 11Mbps? No, that just means its an option. > Here's the current iw list output now... > > > Wiphy phy0 > Band 1: > HT capabilities: 0x104e > * 20/40 MHz operation > * SM PS disabled > * 40 MHz short GI > * max A-MSDU len 3839 > * DSSS/CCK 40 MHz > HT A-MPDU factor: 0x0003 (65535 bytes) > HT A-MPDU density: 0x0006 (8 usec) > HT MCS set: ff ff 00 00 00 00 00 00 00 00 00 00 01 > 00 00 00 The above "HT MCS set" gives you the actual supported RX/TX MCS rates. I just sent a patch to parse this out, I've attached it for your convenience. > Frequencies: > * 2412 MHz [1] (27.0 dBm) > * 2417 MHz [2] (27.0 dBm) > * 2422 MHz [3] (27.0 dBm) > * 2427 MHz [4] (27.0 dBm) > * 2432 MHz [5] (27.0 dBm) > * 2437 MHz [6] (27.0 dBm) > * 2442 MHz [7] (27.0 dBm) > * 2447 MHz [8] (27.0 dBm) > * 2452 MHz [9] (27.0 dBm) > * 2457 MHz [10] (27.0 dBm) > * 2462 MHz [11] (27.0 dBm) > * 2467 MHz [12] (disabled) > * 2472 MHz [13] (disabled) > * 2484 MHz [14] (disabled) > Bitrates: This should say "Legacy Bitrates" or something like this list won't show the supported MCS rates, that is listed in the patch I posted. > * 1.0 Mbps > * 2.0 Mbps (short preamble supported) > * 5.5 Mbps (short preamble supported) > * 11.0 Mbps (short preamble supported) > * 6.0 Mbps > * 9.0 Mbps > * 12.0 Mbps > * 18.0 Mbps > * 24.0 Mbps > * 36.0 Mbps > * 48.0 Mbps > * 54.0 Mbps > Supported interface modes: > * IBSS > * Station > * AP > * AP(VLAN) > * Monitor > Luis From: Luis R. Rodriguez <lrodriguez@atheros.com> [PATCH] iw: add MCS set parsing (RX/TX MCS rates) This adds MCS set parsing to iw. When you can 'iw list' you can now see the MCS set actually parsed, this can tell you information such as all the RX/TX MCS indexes supported, max TX spatial streams, if TX unequal modulation is supported and your max supported HT RX data rate. This is as per 802.11n Draft 7 on section 7.3.2.57.4 Supported MCS Set field. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> --- I don't see anything on the max HT RX rate though, so cannot test that. My HT APs are also being shipped from NJ so I have no APs to test against which I can go and tweak to ensure HT is enabled as I want. Please test and review. info.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 57 insertions(+), 0 deletions(-) diff --git a/info.c b/info.c index bf3b8bd..cabd4b6 100644 --- a/info.c +++ b/info.c @@ -1,3 +1,4 @@ +#include <stdbool.h> #include <errno.h> #include <net/if.h> @@ -20,6 +21,24 @@ static void print_flag(const char *name, int *open) *open = 1; } +static void print_mcs_index(unsigned char *mcs) +{ + unsigned int mcs_bit; + + for (mcs_bit = 0; mcs_bit <= 76; mcs_bit++) { + unsigned int mcs_octet = mcs_bit/8; + unsigned int MCS_RATE_BIT = 1 << mcs_bit % 8; + bool mcs_rate_idx_set; + + mcs_rate_idx_set = !!(mcs[mcs_octet] & MCS_RATE_BIT); + + if (!mcs_rate_idx_set) + continue; + + printf("\t\t\tMCS index %d\n", mcs_bit); + } +} + static int print_phy_handler(struct nl_msg *msg, void *arg) { struct nlattr *tb_msg[NL80211_ATTR_MAX + 1]; @@ -128,10 +147,48 @@ static int print_phy_handler(struct nl_msg *msg, void *arg) } if (tb_band[NL80211_BAND_ATTR_HT_MCS_SET] && nla_len(tb_band[NL80211_BAND_ATTR_HT_MCS_SET]) == 16) { + /* As defined in 7.3.2.57.4 Supported MCS Set field */ + unsigned int tx_max_num_spatial_streams, max_rx_supp_data_rate; unsigned char *mcs = nla_data(tb_band[NL80211_BAND_ATTR_HT_MCS_SET]); + bool tx_mcs_set_defined, tx_mcs_set_equal, tx_unequal_modulation; + printf("\t\tHT MCS set: %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x\n", mcs[0], mcs[1], mcs[2], mcs[3], mcs[4], mcs[5], mcs[6], mcs[7], mcs[8], mcs[9], mcs[10], mcs[11], mcs[12], mcs[13], mcs[14], mcs[15]); + + max_rx_supp_data_rate = ((mcs[10] >> 8) & ((mcs[11] & 0x3) << 8)); + tx_mcs_set_defined = !!(mcs[12] & (1 << 0)); + tx_mcs_set_equal = !(mcs[12] & (1 << 1)); + tx_max_num_spatial_streams = (mcs[12] | ((1 << 3) | (1 << 4))) + 1; + tx_unequal_modulation = !!(mcs[12] & (1 << 5)); + + printf("\t\tHT Max RX data rate: %d Mbps\n", max_rx_supp_data_rate); + + if (tx_mcs_set_defined) { + if (tx_mcs_set_equal) { + printf("\t\tHT TX/RX MCS rate indexes supported:\n"); + print_mcs_index(&mcs[0]); + } else { + printf("\t\tHT RX MCS rate indexes supported:\n"); + print_mcs_index(&mcs[0]); + + if (tx_unequal_modulation) + printf("TX unequal modulation supported\n"); + else + printf("TX unequal modulation not supported\n"); + + printf("\t\tHT TX Max spatiel streams: %d\n", + tx_max_num_spatial_streams); + + printf("\t\tHT TX MCS rate indexes supported may differ\n"); + } + } + else { + printf("\t\tHT RX MCS rate indexes supported:\n"); + print_mcs_index(&mcs[0]); + printf("\t\tHT TX MCS rates indexes are undefined\n"); + } + } #endif -- 1.6.1.2.253.ga34a ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-02-02 21:06 ` Luis R. Rodriguez @ 2009-02-02 21:35 ` Chris Kennedy 2009-02-02 21:54 ` Chris Kennedy ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Chris Kennedy @ 2009-02-02 21:35 UTC (permalink / raw) To: ath9k-devel On Feb 2, 2009, at 3:06 PM, Luis R. Rodriguez wrote: > On Fri, Jan 30, 2009 at 05:23:06PM -0800, Chris Kennedy wrote: >> >> On Jan 30, 2009, at 11:39 AM, Luis R. Rodriguez wrote: >>> >>> Jouni found there was an issue with this patch which breaks >>> AP mode. >>> >>> commit e22cab741afdd1e9857ea9fe51e28a6fe3c97b90 >>> Author: Stephen Hemminger <shemminger@vyatta.com> >>> Date: Tue Jan 27 05:29:25 2009 +1100 >>> >>> mac80211: convert to net_device_ops >>> >>> Convert to new net_device_ops in 2.6.28 and later. >>> >>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> >>> Acked-by: Johannes Berg <johannes@sipsolutions.net> >>> Signed-off-by: John W. Linville <linville@tuxdriver.c >>> >>> --- >>> >>> Johannes just posted some patches to correct, this you may >>> wnat to try those out, or wait until they get merged. >>> >>> Luis >> >> >> Great, it does seem to allow me to connect now with the newest >> wireless-testing. >> The bad part though is it won't connect above 11Mbps now, although >> iperf shows >> it definitely gets all 11 Mbit of bandwidth, but nothing more. (and >> of course using 802.11n) > > Keep in mind getting 11 Mbit/s on throughput is not the same as > using 11 Mbit/s rate on the card. For example an average 802.11g > capable card using 54 Mbit/s can achieve around ~ 20-25 Mbit/s > although it will probably will actually be using the 54 Mbit/s > OFDM rate. Regardless getting only 11 Mbit/s throughput with an > 11N AP and 11N STA is pretty bad. Yeah it's basically around 21 Mbit/s in G mode, both in/out, so it's really stable solid when set that way as an AP. It's when I go into N mode that it's often very bad, down to 5Mbit/s at times, it once in awhile will be up to 75Mbit/s, but it's never long-term. Most of the time in N mode it seems to be very low, 11Mbit/s average basically. For example I just enabled 802.11n mode again, had been running in g and getting 21Mbit/s in/out for both g and n clients (same as apple access point). So I did get 80Mbit/s tests incoming to the n clients, but 5-10Mbit/s outgoing, it does seem like it's right now doing 70-80Mbit/s but in the paste over time it'll get slower than 5Mbit/s for periods of time, and like before there's some days when it'll just not go anywhere above 15Mbit/s. Well right now my g clients using it in N mode are getting 3-5 Mbit/s input, so they take a big hit from N mode, so that's interesting, G cards using the AP in N enabled mode are basically terrible (and I had seen that consistently in the past). So essentially N enabled AP makes G cards very degraded, N cards output is same or worse as G mode, and input of N cards will sometimes be quite amazing and other times super low in the 1-11Mbit/s range. > > What cards are you using for STAs? How about for AP (AR5416, or > AR9280 or what)? I'm using the Linksys WMP300N with broadcom chips in them as clients, and my AP is a DWA-552 which has the AR5116 in it. I switch on/off with an Apple Extreme AP, so with that I get 60Mbit/s both directions. It's my baseline, the ath9k AP will never allow client to output above 20Mbit/s (usually more like 5Mbit/s) out, but input sometimes gets up there to the 60-80Mbit/s area. Also interestingly the WMP300N clients claim 130Mbit/s pretty much all the time with the Apple Extreme AP, very rarely less and never more. When connecting to the ath9k AP it will say 270Mbit/s and even higher, but it never corresponds with real iperf testing, although it'll eventually start hovering around 11-80 Mbit/s. Seems like the bitrates it claims with the ath9k AP are out of touch with what it can really do or is doing at the time it's reporting those speeds. It does at times get way better bandwidth though incoming than with the Apple AP, but it's very inconsistent, yet really looks like a good sign that when more stable/consistent I'm guessing it'll beat the pants off the Apple AP in N mode. > >> Is this because of the iw list output showing that (short preamble >> supported) for 2,5.5 and 11Mbps? > > No, that just means its an option. > >> Here's the current iw list output now... >> >> >> Wiphy phy0 >> Band 1: >> HT capabilities: 0x104e >> * 20/40 MHz operation >> * SM PS disabled >> * 40 MHz short GI >> * max A-MSDU len 3839 >> * DSSS/CCK 40 MHz >> HT A-MPDU factor: 0x0003 (65535 bytes) >> HT A-MPDU density: 0x0006 (8 usec) >> HT MCS set: ff ff 00 00 00 00 00 00 00 00 00 00 01 >> 00 00 00 > > The above "HT MCS set" gives you the actual supported RX/TX MCS rates. > I just sent a patch to parse this out, I've attached it for your > convenience. > >> Frequencies: >> * 2412 MHz [1] (27.0 dBm) >> * 2417 MHz [2] (27.0 dBm) >> * 2422 MHz [3] (27.0 dBm) >> * 2427 MHz [4] (27.0 dBm) >> * 2432 MHz [5] (27.0 dBm) >> * 2437 MHz [6] (27.0 dBm) >> * 2442 MHz [7] (27.0 dBm) >> * 2447 MHz [8] (27.0 dBm) >> * 2452 MHz [9] (27.0 dBm) >> * 2457 MHz [10] (27.0 dBm) >> * 2462 MHz [11] (27.0 dBm) >> * 2467 MHz [12] (disabled) >> * 2472 MHz [13] (disabled) >> * 2484 MHz [14] (disabled) >> Bitrates: > > This should say "Legacy Bitrates" or something like this list > won't show the supported MCS rates, that is listed in the patch > I posted. > >> * 1.0 Mbps >> * 2.0 Mbps (short preamble supported) >> * 5.5 Mbps (short preamble supported) >> * 11.0 Mbps (short preamble supported) >> * 6.0 Mbps >> * 9.0 Mbps >> * 12.0 Mbps >> * 18.0 Mbps >> * 24.0 Mbps >> * 36.0 Mbps >> * 48.0 Mbps >> * 54.0 Mbps >> Supported interface modes: >> * IBSS >> * Station >> * AP >> * AP(VLAN) >> * Monitor >> Here's what I get now with that patch... Wiphy phy0 Band 1: HT capabilities: 0x104e * 20/40 MHz operation * SM PS disabled * 40 MHz short GI * max A-MSDU len 3839 * DSSS/CCK 40 MHz HT A-MPDU factor: 0x0003 (65535 bytes) HT A-MPDU density: 0x0006 (8 usec) HT MCS set: ff ff 00 00 00 00 00 00 00 00 00 00 01 00 00 00 HT Max RX data rate: 0 Mbps HT TX/RX MCS rate indexes supported: MCS index 0 MCS index 1 MCS index 2 MCS index 3 MCS index 4 MCS index 5 MCS index 6 MCS index 7 MCS index 8 MCS index 9 MCS index 10 MCS index 11 MCS index 12 MCS index 13 MCS index 14 MCS index 15 Frequencies: * 2412 MHz [1] (27.0 dBm) * 2417 MHz [2] (27.0 dBm) * 2422 MHz [3] (27.0 dBm) * 2427 MHz [4] (27.0 dBm) * 2432 MHz [5] (27.0 dBm) * 2437 MHz [6] (27.0 dBm) * 2442 MHz [7] (27.0 dBm) * 2447 MHz [8] (27.0 dBm) * 2452 MHz [9] (27.0 dBm) * 2457 MHz [10] (27.0 dBm) * 2462 MHz [11] (27.0 dBm) * 2467 MHz [12] (disabled) * 2472 MHz [13] (disabled) * 2484 MHz [14] (disabled) Bitrates: * 1.0 Mbps * 2.0 Mbps (short preamble supported) * 5.5 Mbps (short preamble supported) * 11.0 Mbps (short preamble supported) * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Supported interface modes: * IBSS * Station * AP * AP(VLAN) * Monitor oz iw-htrate # iw dev wlan0 station dump Station 00:22:6b:a4:a2:e4 (on wlan0) inactive time: 40930 ms rx bytes: 6583 tx bytes: 5087 signal: -89 dBm tx bitrate: MCS 43 40Mhz I'm not sure if the above output is supposed to say 0 for Max RX data rate part, but that's what it says. Thanks, Chris > > Luis > > From: Luis R. Rodriguez <lrodriguez@atheros.com> > [PATCH] iw: add MCS set parsing (RX/TX MCS rates) > > This adds MCS set parsing to iw. When you can 'iw list' you can > now see the MCS set actually parsed, this can tell you information > such as all the RX/TX MCS indexes supported, max TX spatial streams, > if TX unequal modulation is supported and your max supported HT > RX data rate. > > This is as per 802.11n Draft 7 on section 7.3.2.57.4 Supported MCS > Set field. > > Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> > --- > > I don't see anything on the max HT RX rate though, so cannot test > that. > My HT APs are also being shipped from NJ so I have no APs to test > against > which I can go and tweak to ensure HT is enabled as I want. Please > test > and review. > > info.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++ > 1 files changed, 57 insertions(+), 0 deletions(-) > > diff --git a/info.c b/info.c > index bf3b8bd..cabd4b6 100644 > --- a/info.c > +++ b/info.c > @@ -1,3 +1,4 @@ > +#include <stdbool.h> > #include <errno.h> > #include <net/if.h> > > @@ -20,6 +21,24 @@ static void print_flag(const char *name, int *open) > *open = 1; > } > > +static void print_mcs_index(unsigned char *mcs) > +{ > + unsigned int mcs_bit; > + > + for (mcs_bit = 0; mcs_bit <= 76; mcs_bit++) { > + unsigned int mcs_octet = mcs_bit/8; > + unsigned int MCS_RATE_BIT = 1 << mcs_bit % 8; > + bool mcs_rate_idx_set; > + > + mcs_rate_idx_set = !!(mcs[mcs_octet] & MCS_RATE_BIT); > + > + if (!mcs_rate_idx_set) > + continue; > + > + printf("\t\t\tMCS index %d\n", mcs_bit); > + } > +} > + > static int print_phy_handler(struct nl_msg *msg, void *arg) > { > struct nlattr *tb_msg[NL80211_ATTR_MAX + 1]; > @@ -128,10 +147,48 @@ static int print_phy_handler(struct nl_msg > *msg, void *arg) > } > if (tb_band[NL80211_BAND_ATTR_HT_MCS_SET] && > nla_len(tb_band[NL80211_BAND_ATTR_HT_MCS_SET]) == 16) { > + /* As defined in 7.3.2.57.4 Supported MCS Set field */ > + unsigned int tx_max_num_spatial_streams, max_rx_supp_data_rate; > unsigned char *mcs = nla_data(tb_band > [NL80211_BAND_ATTR_HT_MCS_SET]); > + bool tx_mcs_set_defined, tx_mcs_set_equal, tx_unequal_modulation; > + > printf("\t\tHT MCS set: %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x > %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x\n", > mcs[0], mcs[1], mcs[2], mcs[3], mcs[4], mcs[5], mcs[6], mcs[7], > mcs[8], mcs[9], mcs[10], mcs[11], mcs[12], mcs[13], mcs[14], > mcs[15]); > + > + max_rx_supp_data_rate = ((mcs[10] >> 8) & ((mcs[11] & 0x3) << 8)); > + tx_mcs_set_defined = !!(mcs[12] & (1 << 0)); > + tx_mcs_set_equal = !(mcs[12] & (1 << 1)); > + tx_max_num_spatial_streams = (mcs[12] | ((1 << 3) | (1 << 4))) > + 1; > + tx_unequal_modulation = !!(mcs[12] & (1 << 5)); > + > + printf("\t\tHT Max RX data rate: %d Mbps\n", > max_rx_supp_data_rate); > + > + if (tx_mcs_set_defined) { > + if (tx_mcs_set_equal) { > + printf("\t\tHT TX/RX MCS rate indexes supported:\n"); > + print_mcs_index(&mcs[0]); > + } else { > + printf("\t\tHT RX MCS rate indexes supported:\n"); > + print_mcs_index(&mcs[0]); > + > + if (tx_unequal_modulation) > + printf("TX unequal modulation supported\n"); > + else > + printf("TX unequal modulation not supported\n"); > + > + printf("\t\tHT TX Max spatiel streams: %d\n", > + tx_max_num_spatial_streams); > + > + printf("\t\tHT TX MCS rate indexes supported may differ\n"); > + } > + } > + else { > + printf("\t\tHT RX MCS rate indexes supported:\n"); > + print_mcs_index(&mcs[0]); > + printf("\t\tHT TX MCS rates indexes are undefined\n"); > + } > + > } > #endif > > -- > 1.6.1.2.253.ga34a > ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-02-02 21:35 ` Chris Kennedy @ 2009-02-02 21:54 ` Chris Kennedy 2009-02-02 22:13 ` Chris Kennedy 2009-02-02 22:40 ` Luis R. Rodriguez 2 siblings, 0 replies; 22+ messages in thread From: Chris Kennedy @ 2009-02-02 21:54 UTC (permalink / raw) To: ath9k-devel On Feb 2, 2009, at 3:35 PM, Chris Kennedy wrote: > > * Monitor > oz iw-htrate # iw dev wlan0 station dump > > Station 00:22:6b:a4:a2:e4 (on wlan0) > inactive time: 40930 ms > rx bytes: 6583 > tx bytes: 5087 > signal: -89 dBm > tx bitrate: MCS 43 40Mhz > > Just saw this, here's what it looks like mostly... oz iw-htrate # iw dev wlan0 station dump Station 00:0e:35:c9:14:af (on wlan0) inactive time: 206560 ms rx bytes: 872826 tx bytes: 16703616 signal: -54 dBm tx bitrate: 54.0 MBit/s Station 00:22:6b:a4:a2:e4 (on wlan0) inactive time: 3590 ms rx bytes: 251072064 tx bytes: -1495073552 signal: -48 dBm tx bitrate: MCS 43 40Mhz So one thing may be the fact it seems to have fluctuating dBm in N mode, I'm not sure, but may explain why N mode fluctuates so much in actual iperf testing. The G client above can be seen, it says 54Mbit/s but really can only do 5Mbit/s max. I have been getting some amazing 90Mbit/s input rates, it's odd, so it's happy right now incoming, but of course outgoing is 15-20Mbit/s max as usual. If it's signal then G mode doesn't show the problem at all, and I'd suspect it is not maintaining as strong of signal when in N mode, or something that may influence how the dBm will be terrible sometimes. Just more interesting observations, saw that bad dBm level in my email and gave me more ideas since it's right now a great -49 dBm compared to that. Thanks, Chris > I'm not sure if the above output is supposed to say 0 for Max RX data > rate part, > but that's what it says. > > > Thanks, > Chris > > >> >> Luis >> >> From: Luis R. Rodriguez <lrodriguez@atheros.com> >> [PATCH] iw: add MCS set parsing (RX/TX MCS rates) >> >> This adds MCS set parsing to iw. When you can 'iw list' you can >> now see the MCS set actually parsed, this can tell you information >> such as all the RX/TX MCS indexes supported, max TX spatial streams, >> if TX unequal modulation is supported and your max supported HT >> RX data rate. >> >> This is as per 802.11n Draft 7 on section 7.3.2.57.4 Supported MCS >> Set field. >> >> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> >> --- >> >> I don't see anything on the max HT RX rate though, so cannot test >> that. >> My HT APs are also being shipped from NJ so I have no APs to test >> against >> which I can go and tweak to ensure HT is enabled as I want. Please >> test >> and review. >> >> info.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++ >> ++++ >> 1 files changed, 57 insertions(+), 0 deletions(-) >> >> diff --git a/info.c b/info.c >> index bf3b8bd..cabd4b6 100644 >> --- a/info.c >> +++ b/info.c >> @@ -1,3 +1,4 @@ >> +#include <stdbool.h> >> #include <errno.h> >> #include <net/if.h> >> >> @@ -20,6 +21,24 @@ static void print_flag(const char *name, int >> *open) >> *open = 1; >> } >> >> +static void print_mcs_index(unsigned char *mcs) >> +{ >> + unsigned int mcs_bit; >> + >> + for (mcs_bit = 0; mcs_bit <= 76; mcs_bit++) { >> + unsigned int mcs_octet = mcs_bit/8; >> + unsigned int MCS_RATE_BIT = 1 << mcs_bit % 8; >> + bool mcs_rate_idx_set; >> + >> + mcs_rate_idx_set = !!(mcs[mcs_octet] & MCS_RATE_BIT); >> + >> + if (!mcs_rate_idx_set) >> + continue; >> + >> + printf("\t\t\tMCS index %d\n", mcs_bit); >> + } >> +} >> + >> static int print_phy_handler(struct nl_msg *msg, void *arg) >> { >> struct nlattr *tb_msg[NL80211_ATTR_MAX + 1]; >> @@ -128,10 +147,48 @@ static int print_phy_handler(struct nl_msg >> *msg, void *arg) >> } >> if (tb_band[NL80211_BAND_ATTR_HT_MCS_SET] && >> nla_len(tb_band[NL80211_BAND_ATTR_HT_MCS_SET]) == 16) { >> + /* As defined in 7.3.2.57.4 Supported MCS Set field */ >> + unsigned int tx_max_num_spatial_streams, max_rx_supp_data_rate; >> unsigned char *mcs = nla_data(tb_band >> [NL80211_BAND_ATTR_HT_MCS_SET]); >> + bool tx_mcs_set_defined, tx_mcs_set_equal, tx_unequal_modulation; >> + >> printf("\t\tHT MCS set: %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x >> %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x\n", >> mcs[0], mcs[1], mcs[2], mcs[3], mcs[4], mcs[5], mcs[6], mcs[7], >> mcs[8], mcs[9], mcs[10], mcs[11], mcs[12], mcs[13], mcs[14], >> mcs[15]); >> + >> + max_rx_supp_data_rate = ((mcs[10] >> 8) & ((mcs[11] & 0x3) << >> 8)); >> + tx_mcs_set_defined = !!(mcs[12] & (1 << 0)); >> + tx_mcs_set_equal = !(mcs[12] & (1 << 1)); >> + tx_max_num_spatial_streams = (mcs[12] | ((1 << 3) | (1 << 4))) >> + 1; >> + tx_unequal_modulation = !!(mcs[12] & (1 << 5)); >> + >> + printf("\t\tHT Max RX data rate: %d Mbps\n", >> max_rx_supp_data_rate); >> + >> + if (tx_mcs_set_defined) { >> + if (tx_mcs_set_equal) { >> + printf("\t\tHT TX/RX MCS rate indexes supported:\n"); >> + print_mcs_index(&mcs[0]); >> + } else { >> + printf("\t\tHT RX MCS rate indexes supported:\n"); >> + print_mcs_index(&mcs[0]); >> + >> + if (tx_unequal_modulation) >> + printf("TX unequal modulation supported\n"); >> + else >> + printf("TX unequal modulation not supported\n"); >> + >> + printf("\t\tHT TX Max spatiel streams: %d\n", >> + tx_max_num_spatial_streams); >> + >> + printf("\t\tHT TX MCS rate indexes supported may differ\n"); >> + } >> + } >> + else { >> + printf("\t\tHT RX MCS rate indexes supported:\n"); >> + print_mcs_index(&mcs[0]); >> + printf("\t\tHT TX MCS rates indexes are undefined\n"); >> + } >> + >> } >> #endif >> >> -- >> 1.6.1.2.253.ga34a >> > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-02-02 21:35 ` Chris Kennedy 2009-02-02 21:54 ` Chris Kennedy @ 2009-02-02 22:13 ` Chris Kennedy 2009-02-02 22:23 ` Chris Kennedy 2009-02-02 22:40 ` Luis R. Rodriguez 2 siblings, 1 reply; 22+ messages in thread From: Chris Kennedy @ 2009-02-02 22:13 UTC (permalink / raw) To: ath9k-devel On Feb 2, 2009, at 3:35 PM, Chris Kennedy wrote: > > I'm using the Linksys WMP300N with broadcom chips in them as clients, > and my AP is a DWA-552 > which has the AR5116 in it. I switch on/off with an Apple Extreme > I mean the AR5416 actually :). Thanks, Chris ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-02-02 22:13 ` Chris Kennedy @ 2009-02-02 22:23 ` Chris Kennedy 2009-02-02 22:46 ` Luis R. Rodriguez 0 siblings, 1 reply; 22+ messages in thread From: Chris Kennedy @ 2009-02-02 22:23 UTC (permalink / raw) To: ath9k-devel On Feb 2, 2009, at 4:13 PM, Chris Kennedy wrote: > > On Feb 2, 2009, at 3:35 PM, Chris Kennedy wrote: > >> >> I'm using the Linksys WMP300N with broadcom chips in them as clients, >> and my AP is a DWA-552 >> which has the AR5116 in it. I switch on/off with an Apple Extreme >> > > I mean the AR5416 actually :). And here's a good showing of the results I get pretty consistent right now in N mode for the ath9k AP, first is the Ath9k to the Linksys300N client, second is the Apple Extreme Ap to a Linksys300N client (to compare with), and the last is the ath9k to the G client (has an intel chipset, uses the ipw2200 driver)... Ath9k to the Linksys300N: oz iw-htrate # iperf -c 192.168.254.103 -r ------------------------------------------------------------ Client connecting to 192.168.254.103, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.254.3 port 33374 connected with 192.168.254.103 port 5001 [ 3] 0.0-10.0 sec 80.1 MBytes 67.2 Mbits/sec ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local 192.168.254.3 port 5001 connected with 192.168.254.103 port 1645 [ 4] 0.0-10.0 sec 6.16 MBytes 5.16 Mbits/sec Apple Extreme Ap to a Linksys300N : oz iw-htrate # iperf -c 192.168.254.105 -r ------------------------------------------------------------ Client connecting to 192.168.254.105, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.254.3 port 52080 connected with 192.168.254.105 port 5001 [ 3] 0.0-10.1 sec 72.7 MBytes 60.5 Mbits/sec ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local 192.168.254.3 port 5001 connected with 192.168.254.105 port 1712 [ 4] 0.0-10.0 sec 36.5 MBytes 30.6 Mbits/sec ath9k to the G client (has an intel chipset, uses the ipw2200 driver).: oz iw-htrate # iperf -c 192.168.254.150 -r ------------------------------------------------------------ Client connecting to 192.168.254.150, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.254.3 port 37313 connected with 192.168.254.150 port 5001 [ 3] 0.0-10.1 sec 4.32 MBytes 3.59 Mbits/sec ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local 192.168.254.3 port 5001 connected with 192.168.254.150 port 39018 [ 4] 0.0-14.5 sec 2.07 MBytes 1.20 Mbits/sec So those bi-directional tests show basically what I see. Of course there's times like the other day when it all goes to heck and I have 11Mbit/s speeds in N mode for the Ath9k AP. I'm using the newest git version of hostapd right now (newest wireless-testing), had been going back and forth between 0.6.7, which I don't really think much changes between those two from what I can tell. It was definitely acting up though the other day and it didn't get faster for about 12 hours and that was only in G mode, today is the first time I've tried N mode again and now it seems somewhat decent and like it had been at it's best in the past. It's almost like switching between the driver/kernel that had not worked, somehow kicked the card into a bad mood for a day or so, maybe that's crazy though and some other factor like dBm or something. Thanks, Chris > > > Thanks, > Chris > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-02-02 22:23 ` Chris Kennedy @ 2009-02-02 22:46 ` Luis R. Rodriguez 2009-02-02 23:31 ` Chris Kennedy 0 siblings, 1 reply; 22+ messages in thread From: Luis R. Rodriguez @ 2009-02-02 22:46 UTC (permalink / raw) To: ath9k-devel On Mon, Feb 02, 2009 at 02:23:23PM -0800, Chris Kennedy wrote: > > On Feb 2, 2009, at 4:13 PM, Chris Kennedy wrote: > > > > > On Feb 2, 2009, at 3:35 PM, Chris Kennedy wrote: > > > >> > >> I'm using the Linksys WMP300N with broadcom chips in them as clients, > >> and my AP is a DWA-552 > >> which has the AR5116 in it. I switch on/off with an Apple Extreme > >> > > > > I mean the AR5416 actually :). > > And here's a good showing of the results I get pretty consistent > right now in N mode for the ath9k AP, > first is the Ath9k to the Linksys300N client, second is the Apple > Extreme Ap to a Linksys300N client (to > compare with), and the last is the ath9k to the G client (has an > intel chipset, uses the ipw2200 driver)... > > > Ath9k to the Linksys300N: > oz iw-htrate # iperf -c 192.168.254.103 -r You may want to try iperf -c <ip> -i 1 -t 100000 Or something similar. > ------------------------------------------------------------ > Client connecting to 192.168.254.103, TCP port 5001 > TCP window size: 16.0 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.254.3 port 33374 connected with 192.168.254.103 > port 5001 > [ 3] 0.0-10.0 sec 80.1 MBytes 67.2 Mbits/sec > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 85.3 KByte (default) > ------------------------------------------------------------ > [ 4] local 192.168.254.3 port 5001 connected with 192.168.254.103 > port 1645 > [ 4] 0.0-10.0 sec 6.16 MBytes 5.16 Mbits/sec > > > Apple Extreme Ap to a Linksys300N : > oz iw-htrate # iperf -c 192.168.254.105 -r Apple Extreme AP, with iperf and a shell? > ------------------------------------------------------------ > Client connecting to 192.168.254.105, TCP port 5001 > TCP window size: 16.0 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.254.3 port 52080 connected with 192.168.254.105 > port 5001 > [ 3] 0.0-10.1 sec 72.7 MBytes 60.5 Mbits/sec > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 85.3 KByte (default) > ------------------------------------------------------------ > [ 4] local 192.168.254.3 port 5001 connected with 192.168.254.105 > port 1712 > [ 4] 0.0-10.0 sec 36.5 MBytes 30.6 Mbits/sec > > > > ath9k to the G client (has an intel chipset, uses the ipw2200 driver).: > oz iw-htrate # iperf -c 192.168.254.150 -r > ------------------------------------------------------------ > Client connecting to 192.168.254.150, TCP port 5001 > TCP window size: 16.0 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.254.3 port 37313 connected with 192.168.254.150 > port 5001 > [ 3] 0.0-10.1 sec 4.32 MBytes 3.59 Mbits/sec > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 85.3 KByte (default) > ------------------------------------------------------------ > [ 4] local 192.168.254.3 port 5001 connected with 192.168.254.150 > port 39018 > [ 4] 0.0-14.5 sec 2.07 MBytes 1.20 Mbits/sec > > > > > So those bi-directional tests show basically what I see. Of course > there's times like > the other day when it all goes to heck and I have 11Mbit/s speeds in > N mode for > the Ath9k AP. I'm using the newest git version of hostapd right now > (newest wireless-testing), had been going > back and forth between 0.6.7, which I don't really think much changes > between those > two from what I can tell. It was definitely acting up though the > other day and it didn't get > faster for about 12 hours and that was only in G mode, today is the > first time I've tried N > mode again and now it seems somewhat decent and like it had been at > it's best in the past. > It's almost like switching between the driver/kernel that had not > worked, somehow kicked the > card into a bad mood for a day or so, maybe that's crazy though and > some other factor like > dBm or something. What does your iwlist wlan0 scan look like? Busy? Thanks for your detailed reports and testing! Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-02-02 22:46 ` Luis R. Rodriguez @ 2009-02-02 23:31 ` Chris Kennedy 2009-02-02 23:47 ` Luis R. Rodriguez 0 siblings, 1 reply; 22+ messages in thread From: Chris Kennedy @ 2009-02-02 23:31 UTC (permalink / raw) To: ath9k-devel On Feb 2, 2009, at 4:46 PM, Luis R. Rodriguez wrote: > On Mon, Feb 02, 2009 at 02:23:23PM -0800, Chris Kennedy wrote: >> > What does your iwlist wlan0 scan look like? Busy? I actually get (Interface doesn't support scanning : Operation not supported), although I swear it worked one time for me a week ago when I did it but not sure what I had done (was maybe when the interface wasn't setup or something like that, I did some combination of loading the modules but not fully bringing the interface up with hostapd). Is it normal to just run hostapd on the interface, only other thing I do is change the txpower to 100mW using iwconfig (seems like 500mW default is crazy from what I read). I'm using gentoo, it's setup bridging eth0/ wlan0, and so basically just running hostapd and iwconfig for txpower after boot. Here's the iwconfig though if that helps at all.... wlan0 IEEE 802.11bgn Mode:Master Frequency:2.462 GHz Tx- Power=20 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:0C65-8267-BBF8-64F9-F74C-DCD8-C0C4-32DA [2] Power Management:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 ap0 no wireless extensions. mon.wlan0 IEEE 802.11bgn Mode:Monitor Frequency:2.462 GHz Tx- Power=20 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:off Power Management:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Thanks, Chris > > Thanks for your detailed reports and testing! > > Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-02-02 23:31 ` Chris Kennedy @ 2009-02-02 23:47 ` Luis R. Rodriguez 2009-02-02 23:59 ` Chris Kennedy 0 siblings, 1 reply; 22+ messages in thread From: Luis R. Rodriguez @ 2009-02-02 23:47 UTC (permalink / raw) To: ath9k-devel On Mon, Feb 02, 2009 at 03:31:37PM -0800, Chris Kennedy wrote: > > On Feb 2, 2009, at 4:46 PM, Luis R. Rodriguez wrote: > > > On Mon, Feb 02, 2009 at 02:23:23PM -0800, Chris Kennedy wrote: > >> > > What does your iwlist wlan0 scan look like? Busy? > > I actually get (Interface doesn't support scanning : Operation not > supported), Bring it up in Client/STA mode to scan. Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-02-02 23:47 ` Luis R. Rodriguez @ 2009-02-02 23:59 ` Chris Kennedy 2009-02-03 0:11 ` Luis R. Rodriguez 0 siblings, 1 reply; 22+ messages in thread From: Chris Kennedy @ 2009-02-02 23:59 UTC (permalink / raw) To: ath9k-devel Here's the scan... oz iw-htrate # iwlist wlan0 scan wlan0 Scan completed : Cell 01 - Address: 00:23:6C:BE:73:B2 ESSID:"Lakshmi" Mode:Master Channel:6 Frequency:2.437 GHz (Channel 6) Quality=100/100 Signal level:-20 dBm Encryption key:on IE: Unknown: 00074C616B73686D69 IE: Unknown: 010882848B0C12961824 IE: Unknown: 030106 IE: Unknown: 0706555320010B1B IE: Unknown: 2A0102 IE: Unknown: 32043048606C IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : CCMP Pairwise Ciphers (1) : CCMP Authentication Suites (1) : PSK IE: Unknown: 2D1A4C101BFFFF000000000000000000000000000000000000000000 IE: Unknown: 3D1606000800000000000000000000000000000000000000 IE: Unknown: DD180050F2020101030003A4000027A4000042435E0062322F00 IE: Unknown: DD1E00904C334C101BFFFF000000000000000000000000000000000000000000 IE: Unknown: DD1A00904C3406000800000000000000000000000000000000000000 IE: Unknown: DD0700039301690020 Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=00000001dda43db4 Extra: Last beacon: 290ms ago Thanks, Chris On Feb 2, 2009, at 5:47 PM, Luis R. Rodriguez wrote: > On Mon, Feb 02, 2009 at 03:31:37PM -0800, Chris Kennedy wrote: >> >> On Feb 2, 2009, at 4:46 PM, Luis R. Rodriguez wrote: >> >>> On Mon, Feb 02, 2009 at 02:23:23PM -0800, Chris Kennedy wrote: >>>> >>> What does your iwlist wlan0 scan look like? Busy? >> >> I actually get (Interface doesn't support scanning : Operation not >> supported), > > Bring it up in Client/STA mode to scan. > > Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-02-02 23:59 ` Chris Kennedy @ 2009-02-03 0:11 ` Luis R. Rodriguez 2009-02-03 0:16 ` Chris Kennedy 0 siblings, 1 reply; 22+ messages in thread From: Luis R. Rodriguez @ 2009-02-03 0:11 UTC (permalink / raw) To: ath9k-devel On Mon, Feb 02, 2009 at 03:59:26PM -0800, Chris Kennedy wrote: > Here's the scan... > > oz iw-htrate # iwlist wlan0 scan > wlan0 Scan completed : > Cell 01 - Address: 00:23:6C:BE:73:B2 Judging from the OUI 00-23-6C, I take it this is your Apple AP, what channel are you using for your ath9k AP? > ESSID:"Lakshmi" > Mode:Master > Channel:6 > Frequency:2.437 GHz (Channel 6) > Quality=100/100 Signal level:-20 dBm > Encryption key:on > IE: Unknown: 00074C616B73686D69 > IE: Unknown: 010882848B0C12961824 > IE: Unknown: 030106 > IE: Unknown: 0706555320010B1B > IE: Unknown: 2A0102 > IE: Unknown: 32043048606C > IE: IEEE 802.11i/WPA2 Version 1 > Group Cipher : CCMP > Pairwise Ciphers (1) : CCMP > Authentication Suites (1) : PSK > IE: Unknown: > 2D1A4C101BFFFF000000000000000000000000000000000000000000 > IE: Unknown: > 3D1606000800000000000000000000000000000000000000 > IE: Unknown: > DD180050F2020101030003A4000027A4000042435E0062322F00 > IE: Unknown: > DD1E00904C334C101BFFFF000000000000000000000000000000000000000000 > IE: Unknown: > DD1A00904C3406000800000000000000000000000000000000000000 > IE: Unknown: DD0700039301690020 > Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s > 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 > Mb/s > 48 Mb/s; 54 Mb/s > Extra:tsf=00000001dda43db4 > Extra: Last beacon: 290ms ago Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-02-03 0:11 ` Luis R. Rodriguez @ 2009-02-03 0:16 ` Chris Kennedy 2009-02-07 1:53 ` Chris Kennedy 0 siblings, 1 reply; 22+ messages in thread From: Chris Kennedy @ 2009-02-03 0:16 UTC (permalink / raw) To: ath9k-devel On Feb 2, 2009, at 6:11 PM, Luis R. Rodriguez wrote: > On Mon, Feb 02, 2009 at 03:59:26PM -0800, Chris Kennedy wrote: >> Here's the scan... >> >> oz iw-htrate # iwlist wlan0 scan >> wlan0 Scan completed : >> Cell 01 - Address: 00:23:6C:BE:73:B2 > > Judging from the OUI 00-23-6C, I take it this is your Apple AP, > what channel are you using for your ath9k AP? > >> ESSID:"Lakshmi" >> Mode:Master >> Channel:6 >> Frequency:2.437 GHz (Channel 6) >> Quality=100/100 Signal level:-20 dBm >> Encryption key:on >> IE: Unknown: 00074C616B73686D69 >> IE: Unknown: 010882848B0C12961824 >> IE: Unknown: 030106 >> IE: Unknown: 0706555320010B1B >> IE: Unknown: 2A0102 >> IE: Unknown: 32043048606C >> IE: IEEE 802.11i/WPA2 Version 1 >> Group Cipher : CCMP >> Pairwise Ciphers (1) : CCMP >> Authentication Suites (1) : PSK >> IE: Unknown: >> 2D1A4C101BFFFF000000000000000000000000000000000000000000 >> IE: Unknown: >> 3D1606000800000000000000000000000000000000000000 >> IE: Unknown: >> DD180050F2020101030003A4000027A4000042435E0062322F00 >> IE: Unknown: >> DD1E00904C334C101BFFFF000000000000000000000000000000000000000000 >> IE: Unknown: >> DD1A00904C3406000800000000000000000000000000000000000000 >> IE: Unknown: DD0700039301690020 >> Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 >> Mb/s >> 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 >> Mb/s >> 48 Mb/s; 54 Mb/s >> Extra:tsf=00000001dda43db4 >> Extra: Last beacon: 290ms ago > Yep that's the Apple, the Ath9k is on channel 11, although have moved it around plenty and not seen much difference. Here's a scan from the G laptop looking at the two networks together, also a speed test with N turned off for Ath9k to show the difference there... eth0 Scan completed : Cell 01 - Address: 00:23:6C:BE:73:B2 ESSID:"Lakshmi" Protocol:IEEE 802.11bg Mode:Master Frequency:2.437 GHz (Channel 6) Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Quality=91/100 Signal level=-37 dBm IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : CCMP Pairwise Ciphers (1) : CCMP Authentication Suites (1) : PSK Extra: Last beacon: 40ms ago Cell 02 - Address: 00:1E:58:3F:A9:4F ESSID:"MilkyWay" Protocol:IEEE 802.11bg Mode:Master Frequency:2.462 GHz (Channel 11) Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Quality=91/100 Signal level=-51 dBm IE: WPA Version 1 Group Cipher : CCMP Pairwise Ciphers (1) : CCMP Authentication Suites (1) : PSK IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : CCMP Pairwise Ciphers (1) : CCMP Authentication Suites (1) : PSK Extra: Last beacon: 120ms ago (This is identical for the other wireless clients too, all do 20Mbit/ s in/out when Ath9k AP is in G mode) oz iw-htrate # iperf -c 192.168.254.150 -r ------------------------------------------------------------ Client connecting to 192.168.254.150, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.254.3 port 59619 connected with 192.168.254.150 port 5001 [ 3] 0.0-10.1 sec 25.3 MBytes 20.9 Mbits/sec ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local 192.168.254.3 port 5001 connected with 192.168.254.150 port 56629 [ 4] 0.0-10.2 sec 26.5 MBytes 21.7 Mbits/sec Thanks, Chris > Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-02-03 0:16 ` Chris Kennedy @ 2009-02-07 1:53 ` Chris Kennedy 0 siblings, 0 replies; 22+ messages in thread From: Chris Kennedy @ 2009-02-07 1:53 UTC (permalink / raw) To: ath9k-devel On Feb 2, 2009, at 6:16 PM, Chris Kennedy wrote: > > On Feb 2, 2009, at 6:11 PM, Luis R. Rodriguez wrote: > >> On Mon, Feb 02, 2009 at 03:59:26PM -0800, Chris Kennedy wrote: >>> Here's the scan... >>> >>> oz iw-htrate # iwlist wlan0 scan >>> wlan0 Scan completed : >>> Cell 01 - Address: 00:23:6C:BE:73:B2 >> >> Judging from the OUI 00-23-6C, I take it this is your Apple AP, >> what channel are you using for your ath9k AP? >> >>> ESSID:"Lakshmi" >>> Mode:Master >>> Channel:6 >>> Frequency:2.437 GHz (Channel 6) >>> Quality=100/100 Signal level:-20 dBm >>> Encryption key:on >>> IE: Unknown: 00074C616B73686D69 >>> IE: Unknown: 010882848B0C12961824 >>> IE: Unknown: 030106 >>> IE: Unknown: 0706555320010B1B >>> IE: Unknown: 2A0102 >>> IE: Unknown: 32043048606C >>> IE: IEEE 802.11i/WPA2 Version 1 >>> Group Cipher : CCMP >>> Pairwise Ciphers (1) : CCMP >>> Authentication Suites (1) : PSK >>> IE: Unknown: >>> 2D1A4C101BFFFF000000000000000000000000000000000000000000 >>> IE: Unknown: >>> 3D1606000800000000000000000000000000000000000000 >>> IE: Unknown: >>> DD180050F2020101030003A4000027A4000042435E0062322F00 >>> IE: Unknown: >>> DD1E00904C334C101BFFFF000000000000000000000000000000000000000000 >>> IE: Unknown: >>> DD1A00904C3406000800000000000000000000000000000000000000 >>> IE: Unknown: DD0700039301690020 >>> Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 >>> Mb/s >>> 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/ >>> s; 36 >>> Mb/s >>> 48 Mb/s; 54 Mb/s >>> Extra:tsf=00000001dda43db4 >>> Extra: Last beacon: 290ms ago >> > > Yep that's the Apple, the Ath9k is on channel 11, although have moved > it around plenty and not > seen much difference. Here's a scan from the G laptop looking at the > two networks together, also > a speed test with N turned off for Ath9k to show the difference > there... > > eth0 Scan completed : > Cell 01 - Address: 00:23:6C:BE:73:B2 > ESSID:"Lakshmi" > Protocol:IEEE 802.11bg > Mode:Master > Frequency:2.437 GHz (Channel 6) > Encryption key:on > Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 > Mb/s > 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 > Mb/s > 48 Mb/s; 54 Mb/s > Quality=91/100 Signal level=-37 dBm > IE: IEEE 802.11i/WPA2 Version 1 > Group Cipher : CCMP > Pairwise Ciphers (1) : CCMP > Authentication Suites (1) : PSK > Extra: Last beacon: 40ms ago > Cell 02 - Address: 00:1E:58:3F:A9:4F > ESSID:"MilkyWay" > Protocol:IEEE 802.11bg > Mode:Master > Frequency:2.462 GHz (Channel 11) > Encryption key:on > Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 > Mb/s > 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 > Mb/s > 48 Mb/s; 54 Mb/s > Quality=91/100 Signal level=-51 dBm > IE: WPA Version 1 > Group Cipher : CCMP > Pairwise Ciphers (1) : CCMP > Authentication Suites (1) : PSK > IE: IEEE 802.11i/WPA2 Version 1 > Group Cipher : CCMP > Pairwise Ciphers (1) : CCMP > Authentication Suites (1) : PSK > Extra: Last beacon: 120ms ago > > > (This is identical for the other wireless clients too, all do 20Mbit/ > s in/out when Ath9k AP is in G mode) > oz iw-htrate # iperf -c 192.168.254.150 -r > ------------------------------------------------------------ > Client connecting to 192.168.254.150, TCP port 5001 > TCP window size: 16.0 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.254.3 port 59619 connected with 192.168.254.150 > port 5001 > [ 3] 0.0-10.1 sec 25.3 MBytes 20.9 Mbits/sec > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 85.3 KByte (default) > ------------------------------------------------------------ > [ 4] local 192.168.254.3 port 5001 connected with 192.168.254.150 > port 56629 > [ 4] 0.0-10.2 sec 26.5 MBytes 21.7 Mbits/sec > > With the newest wireless-testing and hostapd, as of today's git versions, now with the ath9k driver in AP mode my G clients get the normal G speeds (same as when AP is in G only mode, 20Mbit/s). So not sure, but seems like something has improved, since before I never got more than 5 Mbit/s in/out if the ath9k AP was set for N mode capability. One thing that's interesting is the hostapd newest features of figuring out what is the best way to setup the N mode, and scanning, I'm suspecting that may have helped. It at least seems to hold G mode very solid now whether N is on/off, same either AP mode setting now. N mode does still show some oddness for N clients with outgoing bandwidth, and even incoming somewhat. It seems to constantly fluctuate so in N mode it's going from 5-20 Mbit/s over and over again, slowly rising then dropping fast back down. Not sure what that means, but it results in transfers of large files across a LAN to not be very nice (but in G mode the 20Mbit/s is way faster because of this N mode problem). So G/N mode->G clients now looks good, totally normal and couldn't be better. N mode seems shaky outgoing, but tries to get faster now than before (so short little outgoing transfers can be 35 Mbit/s at times) , just keeps dropping the data rate as the transfers progress (and this is all actual transfers, not paying attention to what the link thinks it is capable of). Also some of the N rates seem to somewhat be how the wind blows, when I loaded the driver, having clients re-associate, hostapd restart. In N mode things are very unpredictable, but sometimes for a moment perfect then they can go haywire for awhile, seems the best way to describe it. Thanks, Chris > > Thanks, > Chris > > > > > > > > >> Luis > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-02-02 21:35 ` Chris Kennedy 2009-02-02 21:54 ` Chris Kennedy 2009-02-02 22:13 ` Chris Kennedy @ 2009-02-02 22:40 ` Luis R. Rodriguez 2009-02-02 23:44 ` Luis R. Rodriguez 2 siblings, 1 reply; 22+ messages in thread From: Luis R. Rodriguez @ 2009-02-02 22:40 UTC (permalink / raw) To: ath9k-devel On Mon, Feb 02, 2009 at 01:35:32PM -0800, Chris Kennedy wrote: > Here's what I get now with that patch... > > Wiphy phy0 > Band 1: > HT capabilities: 0x104e > * 20/40 MHz operation > * SM PS disabled > * 40 MHz short GI > * max A-MSDU len 3839 > * DSSS/CCK 40 MHz > HT A-MPDU factor: 0x0003 (65535 bytes) > HT A-MPDU density: 0x0006 (8 usec) > HT MCS set: ff ff 00 00 00 00 00 00 00 00 00 00 01 > 00 00 00 > HT Max RX data rate: 0 Mbps > HT TX/RX MCS rate indexes supported: > MCS index 0 > MCS index 1 > MCS index 2 > MCS index 3 > MCS index 4 > MCS index 5 > MCS index 6 > MCS index 7 > MCS index 8 > MCS index 9 > MCS index 10 > MCS index 11 > MCS index 12 > MCS index 13 > MCS index 14 > MCS index 15 > Frequencies: > * 2412 MHz [1] (27.0 dBm) > * 2417 MHz [2] (27.0 dBm) > * 2422 MHz [3] (27.0 dBm) > * 2427 MHz [4] (27.0 dBm) > * 2432 MHz [5] (27.0 dBm) > * 2437 MHz [6] (27.0 dBm) > * 2442 MHz [7] (27.0 dBm) > * 2447 MHz [8] (27.0 dBm) > * 2452 MHz [9] (27.0 dBm) > * 2457 MHz [10] (27.0 dBm) > * 2462 MHz [11] (27.0 dBm) > * 2467 MHz [12] (disabled) > * 2472 MHz [13] (disabled) > * 2484 MHz [14] (disabled) > Bitrates: > * 1.0 Mbps > * 2.0 Mbps (short preamble supported) > * 5.5 Mbps (short preamble supported) > * 11.0 Mbps (short preamble supported) > * 6.0 Mbps > * 9.0 Mbps > * 12.0 Mbps > * 18.0 Mbps > * 24.0 Mbps > * 36.0 Mbps > * 48.0 Mbps > * 54.0 Mbps > Supported interface modes: > * IBSS > * Station > * AP > * AP(VLAN) > * Monitor > oz iw-htrate # iw dev wlan0 station dump > > Station 00:22:6b:a4:a2:e4 (on wlan0) > inactive time: 40930 ms > rx bytes: 6583 > tx bytes: 5087 > signal: -89 dBm > tx bitrate: MCS 43 40Mhz > > > I'm not sure if the above output is supposed to say 0 for Max RX data > rate part, > but that's what it says. I get the same for "HT Max RX data rate: 0 Mbps", not sure yet if this is a bug in my patch or we don't somehow set this correctly in mac80211 (if we need to). Anyway, you can ignore that for now, in my patch I asked people to help test it. Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) 2009-02-02 22:40 ` Luis R. Rodriguez @ 2009-02-02 23:44 ` Luis R. Rodriguez 0 siblings, 0 replies; 22+ messages in thread From: Luis R. Rodriguez @ 2009-02-02 23:44 UTC (permalink / raw) To: ath9k-devel On Mon, Feb 02, 2009 at 02:40:16PM -0800, Luis Rodriguez wrote: > On Mon, Feb 02, 2009 at 01:35:32PM -0800, Chris Kennedy wrote: > > Here's what I get now with that patch... > > > > HT Max RX data rate: 0 Mbps > > > > I'm not sure if the above output is supposed to say 0 for Max RX data > > rate part, > > but that's what it says. > > I get the same for "HT Max RX data rate: 0 Mbps", not sure yet if this is a bug > in my patch or we don't somehow set this correctly in mac80211 (if we need to). > Anyway, you can ignore that for now, in my patch I asked people to help test > it. I just fixed this, if its zero we just ignore it, here is the new patch. From: Luis R. Rodriguez <lrodriguez@atheros.com> [PATCH v2] iw: add MCS set parsing This adds MCS set parsing to iw. When you can 'iw list' you can now see the MCS set actually parsed, this can tell you information such as all the RX/TX MCS indexes supported, max TX spatial streams, if TX unequal modulation is supported and your max supported HT RX data rate. This is as per 802.11n Draft 7 on section 7.3.2.57.4 Supported MCS Set field. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> --- OK now in v2 we don't print the rate if its 0 as the 802.11n Draft 7 indicates that if its 0 it does not indicate the max supported RX rate. It does refer us to 9.6.0e.5.3 though. We'll need to review that I guess to get this when this is not set. info.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 59 insertions(+), 0 deletions(-) diff --git a/info.c b/info.c index bf3b8bd..7ea8f99 100644 --- a/info.c +++ b/info.c @@ -1,3 +1,4 @@ +#include <stdbool.h> #include <errno.h> #include <net/if.h> @@ -20,6 +21,24 @@ static void print_flag(const char *name, int *open) *open = 1; } +static void print_mcs_index(unsigned char *mcs) +{ + unsigned int mcs_bit; + + for (mcs_bit = 0; mcs_bit <= 76; mcs_bit++) { + unsigned int mcs_octet = mcs_bit/8; + unsigned int MCS_RATE_BIT = 1 << mcs_bit % 8; + bool mcs_rate_idx_set; + + mcs_rate_idx_set = !!(mcs[mcs_octet] & MCS_RATE_BIT); + + if (!mcs_rate_idx_set) + continue; + + printf("\t\t\tMCS index %d\n", mcs_bit); + } +} + static int print_phy_handler(struct nl_msg *msg, void *arg) { struct nlattr *tb_msg[NL80211_ATTR_MAX + 1]; @@ -128,10 +147,50 @@ static int print_phy_handler(struct nl_msg *msg, void *arg) } if (tb_band[NL80211_BAND_ATTR_HT_MCS_SET] && nla_len(tb_band[NL80211_BAND_ATTR_HT_MCS_SET]) == 16) { + /* As defined in 7.3.2.57.4 Supported MCS Set field */ + unsigned int tx_max_num_spatial_streams, max_rx_supp_data_rate; unsigned char *mcs = nla_data(tb_band[NL80211_BAND_ATTR_HT_MCS_SET]); + bool tx_mcs_set_defined, tx_mcs_set_equal, tx_unequal_modulation; + printf("\t\tHT MCS set: %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x %.2x\n", mcs[0], mcs[1], mcs[2], mcs[3], mcs[4], mcs[5], mcs[6], mcs[7], mcs[8], mcs[9], mcs[10], mcs[11], mcs[12], mcs[13], mcs[14], mcs[15]); + + max_rx_supp_data_rate = ((mcs[10] >> 8) & ((mcs[11] & 0x3) << 8)); + tx_mcs_set_defined = !!(mcs[12] & (1 << 0)); + tx_mcs_set_equal = !(mcs[12] & (1 << 1)); + tx_max_num_spatial_streams = (mcs[12] | ((1 << 3) | (1 << 4))) + 1; + tx_unequal_modulation = !!(mcs[12] & (1 << 5)); + + if (max_rx_supp_data_rate) + printf("\t\tHT Max RX data rate: %d Mbps\n", max_rx_supp_data_rate); + /* XXX: else see 9.6.0e.5.3 how to get this I think */ + + if (tx_mcs_set_defined) { + if (tx_mcs_set_equal) { + printf("\t\tHT TX/RX MCS rate indexes supported:\n"); + print_mcs_index(&mcs[0]); + } else { + printf("\t\tHT RX MCS rate indexes supported:\n"); + print_mcs_index(&mcs[0]); + + if (tx_unequal_modulation) + printf("TX unequal modulation supported\n"); + else + printf("TX unequal modulation not supported\n"); + + printf("\t\tHT TX Max spatiel streams: %d\n", + tx_max_num_spatial_streams); + + printf("\t\tHT TX MCS rate indexes supported may differ\n"); + } + } + else { + printf("\t\tHT RX MCS rate indexes supported:\n"); + print_mcs_index(&mcs[0]); + printf("\t\tHT TX MCS rates indexes are undefined\n"); + } + } #endif -- 1.6.1.2.253.ga34a ^ permalink raw reply related [flat|nested] 22+ messages in thread
end of thread, other threads:[~2009-02-07 1:53 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-01-28 2:55 [ath9k-devel] Reg domain won't change and forced to CO (I'm in US) Chris Kennedy 2009-01-28 3:17 ` Luis R. Rodriguez 2009-01-28 4:24 ` Chris Kennedy 2009-01-28 6:10 ` Luis R. Rodriguez 2009-01-28 9:39 ` Chris Kennedy 2009-01-30 17:39 ` Luis R. Rodriguez 2009-01-31 1:23 ` Chris Kennedy 2009-01-31 4:12 ` Chris Kennedy 2009-02-02 21:06 ` Luis R. Rodriguez 2009-02-02 21:35 ` Chris Kennedy 2009-02-02 21:54 ` Chris Kennedy 2009-02-02 22:13 ` Chris Kennedy 2009-02-02 22:23 ` Chris Kennedy 2009-02-02 22:46 ` Luis R. Rodriguez 2009-02-02 23:31 ` Chris Kennedy 2009-02-02 23:47 ` Luis R. Rodriguez 2009-02-02 23:59 ` Chris Kennedy 2009-02-03 0:11 ` Luis R. Rodriguez 2009-02-03 0:16 ` Chris Kennedy 2009-02-07 1:53 ` Chris Kennedy 2009-02-02 22:40 ` Luis R. Rodriguez 2009-02-02 23:44 ` Luis R. Rodriguez
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.