* [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 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: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 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
* [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
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.