* Re: [PATCH 2/4] rt2x00: Enable RT30xx by default.
From: John W. Linville @ 2010-05-04 17:17 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: Pavel Roskin, Stefan Lippers-Hollmann, Ivo van Doorn,
linux-wireless, users
In-Reply-To: <4BDF94FD.7050606@gmail.com>
On Tue, May 04, 2010 at 05:31:09AM +0200, Gertjan van Wingerde wrote:
> To be honest, at the moment I would just change the default from 'n' to 'y'
> for one kernel cycle, and then remove the entire option in the next kernel
> release.
> This is just to make it easier to revert back if for some reasons problems
> arise with the rt30xx support.
> The overall goal is to get rid of all these of the RT2800PCI_yyy and RT2800USB_zzz
> symbols, but that can only happen if the devices denoted by these symbols
> are properly supported.
>
> John, I leave it up to you, but for me my original patch should be merged, and
> I'll send an equivalent patch for Stefan's one for the next kernel release.
Since the options are already inside "if RT2800PCI" and "if RT2800USB"
blocks, I don't see why anyone should object to the boolean defaulting
to 'y'. It's not as if you are enabling a new driver.
I think Gertjan's proposal seems reasonable -- just don't forget! :-)
I would suggest a feature-removal-schedlue.txt patch, but I don't
know that it is worth the trouble.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: wl1251_sdio PSM
From: Grazvydas Ignotas @ 2010-05-04 16:19 UTC (permalink / raw)
To: gnutoo; +Cc: linux-wireless
In-Reply-To: <1272986655.2486.42.camel@gnutoo-desktop>
On Tue, May 4, 2010 at 6:24 PM, gnutoo <GNUtoo@no-log.org> wrote:
>
>> You need a few more patches for PS to work (on top of current compat-wireless):
>> http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff;h=8eb97a1915ae2ab0a19cc6eef1a2753b9514017d
>> http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-wifi.git;a=commitdiff;h=d16ed8871faa892f5fd4e8161412051ee11c5ecb
>>
>> I'm working on mainline mergeable versions of those..
> 2 things:
> *I rebased the patches against lastest compat wireless but I don't know
> where to send them...
> Basically or they apply or they are already in compat-wireless(verified)
> here are the one which applies:
> 0007-wl1251-read-default-MAC-address-from-EEPROM-when-ava.patch
> 0008-wl1251-register-platform_device-to-pass-board-data.patch
> 0009-wl1251-add-support-for-dedicated-IRQ-line.patch
> 0010-wl1251-use-sdio_readb_ext-for-ELP-to-work.patch
> 0011-wl1251-add-reset-handling.patch
> 0013-wl1251-prevent-scan-when-connected.patch
>
> against compat-wireless-2010-04-26
>From your list 0007-0009 are on their way to mainline, 0010-0013 are
not mainline friendly (0010 needs a new function in MMC subsystem
which I sent for review, 0011 depends on some code from Android tree,
0013 is a hack).
> By the way we can't make ad-hoc work,Is ad-hoc supported by the driver?
AFAIK it is not.
Grazvydas
^ permalink raw reply
* Re: [Fwd: USB AP card and/or rt2870 issue]
From: Ivo Van Doorn @ 2010-05-04 15:32 UTC (permalink / raw)
To: GNUtoo; +Cc: linux-wireless
In-Reply-To: <1272986923.2486.45.camel@gnutoo-desktop>
On Tue, May 4, 2010 at 5:28 PM, GNUtoo <GNUtoo@no-log.org> wrote:
> hi, I sent the following mail(attached) to the hostapd mailing list,but
> Now I think It's a driver issue.
> Is it possible to make an access point with a rt2870 card.
> Does the driver support it?
> I don't have much hope for now as it is a staging driver...and it
> displayed a warning about that in dmesg...
You could try compat-wireless and the rt2800usb driver.
That one actually does have Master mode support, but doesn't work
on all cards yet. rt2800usb is also found in the main kernel tree, but
using compat-wireless will give you the most recent version with
_many_ fixes applied to it. :)
Ivo
^ permalink raw reply
* [Fwd: USB AP card and/or rt2870 issue]
From: GNUtoo @ 2010-05-04 15:28 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 310 bytes --]
hi, I sent the following mail(attached) to the hostapd mailing list,but
Now I think It's a driver issue.
Is it possible to make an access point with a rt2870 card.
Does the driver support it?
I don't have much hope for now as it is a staging driver...and it
displayed a warning about that in dmesg...
Denis.
[-- Attachment #2: Forwarded message - USB AP card and/or rt2870 issue --]
[-- Type: message/rfc822, Size: 6814 bytes --]
From: GNUtoo <GNUtoo@no-log.org>
To: hostap@lists.shmoo.com
Subject: USB AP card and/or rt2870 issue
Date: Sat, 24 Apr 2010 17:51:41 +0200
Message-ID: <1272124301.2536.18.camel@gnutoo-desktop>
hi,I'm thinking about replacing my pentium III 500 router with something
like a sheevaplug.
The sheevaplug-like hardware do not have a pci slot or a wireless card
supported that can do access point(if they have one(depend on the
versions)).
So I'm looking for an usb card that can do AP
Someone wanted the exact same thing than me,but for other kind of
embedded devices.he tested a rt8070 and hostap displayed a line with the
ESSID,but the access point essid didn't appear when another computer
scanned it,association was also impossible.
I bought a card with the same chipset.
with my distribution(based on ubuntu hardy) I had the same results.
But...
I wanted and planed to try wireless-compat,libnl2,and hostapd from git:
(that's why I bought it,I was thinking that I could make it work)
here are the results:
With a card that does not support AP mode:
root@gnutoo-desktop:/usr/local/bin# LD_LIBRARY_PATH=/usr/local/lib/
hostapd -ddd /usr/local/etc/hostapd.conf
Configuration file: /usr/local/etc/hostapd.conf
nl80211: Add own interface ifindex 11
nl80211: Failed to set interface 11 to mode 3: -95 (Operation not
supported)
nl80211: Failed to set interface 11 to mode 3: -95 (Operation not
supported)
nl80211: Interface mode change to 3 from 0 failed
nl80211: Failed to set interface wlan2 into AP mode
nl80211 driver initialization failed.
ELOOP: remaining socket: sock=4 eloop_data=0x8c26718 user_data=0x8c26bf8
handler=0x8072580
ELOOP: remaining socket: sock=6 eloop_data=0x8c286e8 user_data=(nil)
handler=0x807be40
With the rt2870 card:
root@gnutoo-desktop:/usr/local/bin# LD_LIBRARY_PATH=/usr/local/lib/
hostapd -ddd /usr/local/etc/hostapd.conf
Configuration file: /usr/local/etc/hostapd.conf
nl80211: Register Action command failed: ret=-19 (No such device)
nl80211: Register Action match - hexdump(len=1): 06
nl80211: Failed to register Action frame processing - ignore for now
nl80211: Add own interface ifindex 10
nl80211: Failed to set interface 10 to mode 3: -19 (No such device)
nl80211: Failed to set interface 10 to mode 3: -19 (No such device)
nl80211: Interface mode change to 3 from 0 failed
nl80211: Failed to set interface wlan0 into AP mode
nl80211 driver initialization failed.
ELOOP: remaining socket: sock=4 eloop_data=0x9fca718 user_data=0x9fcabf8
handler=0x8072580
ELOOP: remaining socket: sock=6 eloop_data=0x9fcc6e8 user_data=(nil)
handler=0x807be40
here's the configuration(interface was changed between the 2 cards)
interface=wlan0
driver=nl80211
ssid=ralink
channel=2
hw_mode=g
here are the version used:
hostapd: 0b86f67a2970403d1b1b6d34ce49f5485ef5dbb3
libnl2: d378220c96c3c8b6f27dca33e7d8ba03318f9c2d
compat-wireless: compat-wireless-2010-04-23.tar.bz2
here is the config of hostapd compilation:
root@gnutoo-desktop:~/wireless/hostap/hostapd# cat .config | sed
's/#.*//' | sed '/^$/d'
CONFIG_DRIVER_NL80211=y
LIBNL=/usr/local
CFLAGS += -I$(LIBNL)/include
LIBS += -L$(LIBNL)/lib
CONFIG_LIBNL20=y
CONFIG_IAPP=y
CONFIG_RSN_PREAUTH=y
CONFIG_PEERKEY=y
CONFIG_EAP=y
CONFIG_EAP_MD5=y
CONFIG_EAP_TLS=y
CONFIG_EAP_MSCHAPV2=y
CONFIG_EAP_PEAP=y
CONFIG_EAP_GTC=y
CONFIG_EAP_TTLS=y
CONFIG_PKCS12=y
CONFIG_IPV6=y
I started to post here because I'm not shure if it's an hostap,a libnl2
or a wireless-dev problem.
I hope the problem can be fixed(or that after time(and effort of the
developers) it would be fixed,so I would only have to wait,I hope not
too long),else I would need to search for another card.
Denis.
_______________________________________________
HostAP mailing list
HostAP@lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
^ permalink raw reply
* Re: wl1251_sdio PSM
From: gnutoo @ 2010-05-04 15:24 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-wireless
In-Reply-To: <loom.20100427T143119-272@post.gmane.org>
> You need a few more patches for PS to work (on top of current compat-wireless):
> http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff;h=8eb97a1915ae2ab0a19cc6eef1a2753b9514017d
> http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-wifi.git;a=commitdiff;h=d16ed8871faa892f5fd4e8161412051ee11c5ecb
>
> I'm working on mainline mergeable versions of those..
2 things:
*I rebased the patches against lastest compat wireless but I don't know
where to send them...
Basically or they apply or they are already in compat-wireless(verified)
here are the one which applies:
0007-wl1251-read-default-MAC-address-from-EEPROM-when-ava.patch
0008-wl1251-register-platform_device-to-pass-board-data.patch
0009-wl1251-add-support-for-dedicated-IRQ-line.patch
0010-wl1251-use-sdio_readb_ext-for-ELP-to-work.patch
0011-wl1251-add-reset-handling.patch
0013-wl1251-prevent-scan-when-connected.patch
against compat-wireless-2010-04-26
By the way we can't make ad-hoc work,Is ad-hoc supported by the driver?
Denis.
^ permalink raw reply
* [PATCH] compat-wireless, unload rt2800usb
From: Walter Goldens @ 2010-05-04 14:30 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, users
Signed-off-by: Walter Goldens <goldenstranger@yahoo,com>
---
If rt2800usb is already loaded, calling scripts 'unload' and 'wlunload' from compat-wireless will complain of "FATAL: Module rt2xXXXX is in use." This patch will solve the unloading issue.
--- a/scripts/wlunload.sh 2010-05-04 16:51:50.000000000 +0300
+++ b/scripts/wlunload.sh 2010-05-04 16:51:40.000000000 +0300
@@ -17,6 +17,7 @@ MODULES="$MODULES ath9k ath5k ar9170usb
MODULES="$MODULES p54pci p54usb p54spi p54common"
MODULES="$MODULES rt2400pci rt2500pci rt61pci"
MODULES="$MODULES rt2500usb rt73usb"
+MODULES="$MODULES rt2800usb rt2800lib"
MODULES="$MODULES rt2x00usb rt2x00lib"
MODULES="$MODULES rtl8180 rtl8187"
MODULES="$MODULES mwl8k mac80211_hwsim"
--- a/scripts/unload.sh 2010-05-04 16:56:43.000000000 +0300
+++ b/scripts/unload.sh 2010-05-04 16:56:44.000000000 +0300
@@ -17,6 +17,7 @@ MODULES="$MODULES ath9k ath5k ar9170usb
MODULES="$MODULES p54pci p54usb p54spi p54common"
MODULES="$MODULES rt2400pci rt2500pci rt61pci"
MODULES="$MODULES rt2500usb rt73usb"
+MODULES="$MODULES rt2800usb rt2800lib"
MODULES="$MODULES rt2x00usb rt2x00lib"
MODULES="$MODULES rtl8180 rtl8187"
MODULES="$MODULES mwl8k mac80211_hwsim"
^ permalink raw reply
* Re: [PATCH] mac80211: Add HT IE to IBSS beacons and probe responses.
From: Johannes Berg @ 2010-05-04 8:26 UTC (permalink / raw)
To: Benoit Papillault; +Cc: linux-wireless
In-Reply-To: <1272955622-6987-3-git-send-email-benoit.papillault@free.fr>
> @@ -118,7 +119,10 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
> *pos++ = basic | (u8) (rate / 5);
> }
>
> - /* Build IBSS probe response */
> + /*
> + * Build IBSS probe response template (also used for beacon template
> + * in ieee80211_beacon_get_tim())
> + */
That change is wrong -- no way beacon code can call into IBSS code.
I think you meant to say "I need to create a common helper function that
I call here and in the beacon code."
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -967,7 +967,7 @@ int ieee80211_build_preq_ies(struct ieee80211_local *local, u8 *buffer,
>
> if (sband->ht_cap.ht_supported) {
> u16 cap = sband->ht_cap.cap;
> - __le16 tmp;
> + struct ieee80211_ht_cap ht_cap;
>
> if (ieee80211_disable_40mhz_24ghz &&
> sband->band == IEEE80211_BAND_2GHZ) {
> @@ -975,18 +975,19 @@ int ieee80211_build_preq_ies(struct ieee80211_local *local, u8 *buffer,
> cap &= ~IEEE80211_HT_CAP_SGI_40;
> }
>
> + ht_cap.cap_info = cpu_to_le16(cap);
> + ht_cap.ampdu_params_info = sband->ht_cap.ampdu_factor |
> + (sband->ht_cap.ampdu_density <<
> + IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT);
> + ht_cap.mcs = sband->ht_cap.mcs;
> + ht_cap.extended_ht_cap_info = cpu_to_le16(0);
> + ht_cap.tx_BF_cap_info = cpu_to_le32(0);
> + ht_cap.antenna_selection_info = 0;
> +
> *pos++ = WLAN_EID_HT_CAPABILITY;
> *pos++ = sizeof(struct ieee80211_ht_cap);
> - memset(pos, 0, sizeof(struct ieee80211_ht_cap));
> - tmp = cpu_to_le16(cap);
> - memcpy(pos, &tmp, sizeof(u16));
> - pos += sizeof(u16);
> - *pos++ = sband->ht_cap.ampdu_factor |
> - (sband->ht_cap.ampdu_density <<
> - IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT);
> - memcpy(pos, &sband->ht_cap.mcs, sizeof(sband->ht_cap.mcs));
> - pos += sizeof(sband->ht_cap.mcs);
> - pos += 2 + 4 + 1; /* ext info, BF cap, antsel */
> + memcpy(pos, &ht_cap, sizeof(struct ieee80211_ht_cap));
> + pos += sizeof(struct ieee80211_ht_cap);
And this is an unrelated change that doesn't belong into this patch at
all.
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: Check for channel HT capabilities in an IBSS
From: Johannes Berg @ 2010-05-04 8:23 UTC (permalink / raw)
To: Benoit Papillault; +Cc: linux-wireless
In-Reply-To: <1272955622-6987-2-git-send-email-benoit.papillault@free.fr>
On Tue, 2010-05-04 at 08:47 +0200, Benoit Papillault wrote:
> When configuring an HT IBSS, we need to check if the specified channel
> is capable of ht40+, ht40- or ht20.
These first two patches cannot be separate.
johannes
^ permalink raw reply
* Re: HT rate warning with openwrt AP using wireless-compat and ath9k
From: Felix Fietkau @ 2010-05-04 8:08 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87och0j7jj.fsf@purkki.valot.fi>
On 2010-05-01 11:27 AM, Kalle Valo wrote:
> Hi,
>
> I'm running OpenWrt 10.03 on Netgear WNDR3700 and I'm having stability
> issues. The AP reboots few times a week, maybe even daily. I get the
> feeling that my wife's windows laptop is related to the reboots
> somehow, but I haven't investigated this in detail yet. Also I do not
> have access to serial console, so I don't have proper logs.
>
> But today the AP didn't reboot, wireless was just dead. I managed to
> find this with ssh:
>
> ------------[ cut here ]------------
> WARNING: at
> /home/openwrt/backfire/build/ar71xx/build_dir/linux-ar71xx/compat-wireless-2010-03-24/net/mac80211/rx.c:2528
> 0x83115884()
I just posted the following patch to linux-wireless:
[PATCH] ath9k: fix another source of corrupt frames
It might reduce the frequency of these warnings, or fix them entirely.
- Felix
^ permalink raw reply
* [PATCH] ath9k: fix another source of corrupt frames
From: Felix Fietkau @ 2010-05-04 7:58 UTC (permalink / raw)
To: linux-wireless; +Cc: Luis R. Rodriguez, John W. Linville
Atheros hardware supports receiving frames that span multiple
descriptors and buffers. In this case, the rx status of every
descriptor except for the last one is invalid and may contain random
data. Because the driver does not support this, it needs to drop such
frames.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -57,13 +57,19 @@ static bool ath9k_rx_accept(struct ath_c
* rs_more indicates chained descriptors which can be used
* to link buffers together for a sort of scatter-gather
* operation.
- *
+ * reject the frame, we don't support scatter-gather yet and
+ * the frame is probably corrupt anyway
+ */
+ if (rx_stats->rs_more)
+ return false;
+
+ /*
* The rx_stats->rs_status will not be set until the end of the
* chained descriptors so it can be ignored if rs_more is set. The
* rs_more will be false at the last element of the chained
* descriptors.
*/
- if (!rx_stats->rs_more && rx_stats->rs_status != 0) {
+ if (rx_stats->rs_status != 0) {
if (rx_stats->rs_status & ATH9K_RXERR_CRC)
rxs->flag |= RX_FLAG_FAILED_FCS_CRC;
if (rx_stats->rs_status & ATH9K_RXERR_PHY)
^ permalink raw reply
* Re: [RFC] mac80211: radiotap vendor data
From: Johannes Berg @ 2010-05-04 7:52 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Joshua Zhao, Matt Smith
In-Reply-To: <o2k43e72e891005031516g31c22cdbt3ee5d766e63b3f2c@mail.gmail.com>
On Mon, 2010-05-03 at 15:16 -0700, Luis R. Rodriguez wrote:
> > Note: 11n shouldn't be done there, in case somebody
> > got ideas!!
>
> Well you mean 802.11n standard stuff, I take it, because there are
> vendor 802.11n specific stuff.
Well most of it should really be standardised :)
> > + * @vendor_radiotap_bitmap: radiotap vendor namespace presence bitmap
> > + * @vendor_radiotap_len: radiotap vendor namespace length
> > + * @vendor_radiotap_align: radiotap vendor namespace alignment. Note
> > + * that the actual data must be at the start of the SKB data
> > + * already.
>
> I see your WARN_ON() on the alignment being set to 0 and set it to 1
> then. Can you clarify a little more on this here. If there is no
> strict alignment requirements why not just treat 0 as 1 then?
Just want people to be aware that they need to think about alignment --
zero being the default value for most things here due to kzalloc would
mean accepting it people wouldn't think about allocations. And most of
the time alignment should be required.
> > @@ -190,11 +218,26 @@ ieee80211_add_rx_radiotap_header(struct
> > /* IEEE80211_RADIOTAP_RX_FLAGS */
> > /* ensure 2 byte alignment for the 2 byte field as required */
> > if ((pos - (u8 *)rthdr) & 1)
> > - pos++;
> > + *pos++ = 0;
>
> Why is this needed though? We already memset(rthdr, 0, rtap_len); above.
Yeah you're probably right, dunno.
> > + vendor_data = skb_push(skb, 4);
> > + rx_status.vendor_radiotap_len = 4;
> > + rx_status.vendor_radiotap_align = 4;
> > + rx_status.vendor_radiotap_oui[0] = 0xff;
> > + rx_status.vendor_radiotap_oui[1] = 0xff;
> > + rx_status.vendor_radiotap_oui[2] = 0xff;
> > + rx_status.vendor_radiotap_subns = 129;
> > + rx_status.vendor_radiotap_bitmap = 0x1;
> > +
> > + *vendor_data++ = 1;
> > + *vendor_data++ = 2;
> > + *vendor_data++ = 3;
> > + *vendor_data++ = 4;
> > +
>
> Heh nice, now we just need a sample radiotap vendor extension parser example.
http://git.sipsolutions.net/?p=radiotap.git;a=summary
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4421
johannes
^ permalink raw reply
* [PATCH] cfg80211: Parse channel_type in NL80211_CMD_JOIN_IBSS
From: Benoit Papillault @ 2010-05-04 6:47 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Benoit Papillault
This field is filled by iw and parse by cfg80211 before being sent to
mac80211 for instance. This information is needed to properly configure
an HT IBSS.
It requires a patch to iw to fill this field.
Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
---
include/net/cfg80211.h | 1 +
net/wireless/nl80211.c | 12 ++++++++++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 7d10c01..93e5558 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -806,6 +806,7 @@ struct cfg80211_ibss_params {
u8 *ssid;
u8 *bssid;
struct ieee80211_channel *channel;
+ enum nl80211_channel_type channel_type;
u8 *ie;
u8 ssid_len, ie_len;
u16 beacon_interval;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 01da83d..8da9823 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3792,6 +3792,7 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
struct cfg80211_ibss_params ibss;
struct wiphy *wiphy;
struct cfg80211_cached_keys *connkeys = NULL;
+ enum nl80211_channel_type channel_type = NL80211_CHAN_NO_HT;
int err;
memset(&ibss, 0, sizeof(ibss));
@@ -3813,6 +3814,17 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
return -EINVAL;
}
+ if (info->attrs[NL80211_ATTR_WIPHY_CHANNEL_TYPE]) {
+ channel_type = nla_get_u32(
+ info->attrs[NL80211_ATTR_WIPHY_CHANNEL_TYPE]);
+ if (channel_type != NL80211_CHAN_NO_HT &&
+ channel_type != NL80211_CHAN_HT20 &&
+ channel_type != NL80211_CHAN_HT40PLUS &&
+ channel_type != NL80211_CHAN_HT40MINUS)
+ return -EINVAL;
+ }
+ ibss.channel_type = channel_type;
+
rtnl_lock();
err = get_rdev_dev_by_info_ifindex(info, &rdev, &dev);
--
1.5.6.5
^ permalink raw reply related
* [PATCH] mac80211: Add HT IE to IBSS beacons and probe responses.
From: Benoit Papillault @ 2010-05-04 6:47 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Benoit Papillault
In-Reply-To: <1272955622-6987-2-git-send-email-benoit.papillault@free.fr>
When an HT IBSS is configured, we add HT Information and HT Capabilities
IE to beacon & probe responses. This is done according to channel_type
transmitted by iw/cfg80211.
Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
---
net/mac80211/ibss.c | 114 +++++++++++++++++++++++++++++++++++++++++---
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/util.c | 23 +++++----
3 files changed, 120 insertions(+), 18 deletions(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index f657854..c501d3b 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -64,6 +64,7 @@ static void ieee80211_rx_mgmt_auth_ibss(struct ieee80211_sub_if_data *sdata,
static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
const u8 *bssid, const int beacon_int,
struct ieee80211_channel *chan,
+ enum nl80211_channel_type channel_type,
const u32 basic_rates,
const u16 capability, u64 tsf)
{
@@ -103,7 +104,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
sdata->drop_unencrypted = capability & WLAN_CAPABILITY_PRIVACY ? 1 : 0;
local->oper_channel = chan;
- local->oper_channel_type = NL80211_CHAN_NO_HT;
+ local->oper_channel_type = channel_type;
ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
sband = local->hw.wiphy->bands[chan->band];
@@ -118,7 +119,10 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
*pos++ = basic | (u8) (rate / 5);
}
- /* Build IBSS probe response */
+ /*
+ * Build IBSS probe response template (also used for beacon template
+ * in ieee80211_beacon_get_tim())
+ */
mgmt = (void *) skb_put(skb, 24 + sizeof(mgmt->u.beacon));
memset(mgmt, 0, 24 + sizeof(mgmt->u.beacon));
mgmt->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
@@ -165,6 +169,64 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
memcpy(pos, &supp_rates[8], rates);
}
+ if (channel_type != NL80211_CHAN_NO_HT &&
+ sband->ht_cap.ht_supported) {
+ u16 cap = sband->ht_cap.cap;
+ struct ieee80211_ht_cap ht_cap;
+ struct ieee80211_ht_info ht_info;
+
+ if (ieee80211_disable_40mhz_24ghz &&
+ sband->band == IEEE80211_BAND_2GHZ) {
+ cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
+ cap &= ~IEEE80211_HT_CAP_SGI_40;
+ }
+
+ ht_cap.cap_info = cpu_to_le16(cap);
+ ht_cap.ampdu_params_info = sband->ht_cap.ampdu_factor |
+ (sband->ht_cap.ampdu_density <<
+ IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT);
+ ht_cap.mcs = sband->ht_cap.mcs;
+ ht_cap.extended_ht_cap_info = cpu_to_le16(0);
+ ht_cap.tx_BF_cap_info = cpu_to_le32(0);
+ ht_cap.antenna_selection_info = 0;
+
+ /* HT Capabilities element */
+ pos = skb_put(skb, 2 + sizeof(struct ieee80211_ht_cap));
+ *pos++ = WLAN_EID_HT_CAPABILITY;
+ *pos++ = sizeof(struct ieee80211_ht_cap);
+ memcpy(pos, &ht_cap, sizeof(struct ieee80211_ht_cap));
+
+ ht_info.control_chan =
+ ieee80211_frequency_to_channel(chan->center_freq);
+ ht_info.ht_param = 0;
+ switch (local->oper_channel_type) {
+ case NL80211_CHAN_NO_HT: /* to make compiler happy */
+ case NL80211_CHAN_HT20:
+ ht_info.ht_param |= IEEE80211_HT_PARAM_CHA_SEC_NONE;
+ break;
+ case NL80211_CHAN_HT40MINUS:
+ ht_info.ht_param |= IEEE80211_HT_PARAM_CHA_SEC_BELOW;
+ break;
+ case NL80211_CHAN_HT40PLUS:
+ ht_info.ht_param |= IEEE80211_HT_PARAM_CHA_SEC_ABOVE;
+ break;
+ }
+ if (sband->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40)
+ ht_info.ht_param |= IEEE80211_HT_PARAM_CHAN_WIDTH_ANY;
+ ht_info.operation_mode = cpu_to_le16(0);
+ ht_info.stbc_param = cpu_to_le16(0);
+ /* It seems that Basic MCS set and Supported MCS set
+ are identical for the first 10 bytes */
+ memset(&ht_info.basic_set, 0, 16);
+ memcpy(&ht_info.basic_set, &ht_cap.mcs, 10);
+
+ /* HT Information element */
+ pos = skb_put(skb, 2 + sizeof(struct ieee80211_ht_info));
+ *pos++ = WLAN_EID_HT_INFORMATION;
+ *pos++ = sizeof(struct ieee80211_ht_info);
+ memcpy(pos, &ht_info, sizeof(struct ieee80211_ht_info));
+ }
+
if (ifibss->ie_len)
memcpy(skb_put(skb, ifibss->ie_len),
ifibss->ie, ifibss->ie_len);
@@ -202,6 +264,9 @@ static void ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
u32 basic_rates;
int i, j;
u16 beacon_int = cbss->beacon_interval;
+ const u8 * ht_info_ie;
+ const struct ieee80211_ht_info *ht_info;
+ enum nl80211_channel_type channel_type = NL80211_CHAN_NO_HT;
if (beacon_int < 10)
beacon_int = 10;
@@ -223,9 +288,28 @@ static void ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
}
}
+ /* parse HT Information IE, if present */
+ ht_info_ie = ieee80211_bss_get_ie(cbss, WLAN_EID_HT_INFORMATION);
+ if (ht_info_ie) {
+ ht_info = (const struct ieee80211_ht_info *)(ht_info_ie + 2);
+ switch (ht_info->ht_param
+ & IEEE80211_HT_PARAM_CHA_SEC_OFFSET) {
+ case IEEE80211_HT_PARAM_CHA_SEC_NONE:
+ channel_type = NL80211_CHAN_HT20;
+ break;
+ case IEEE80211_HT_PARAM_CHA_SEC_ABOVE:
+ channel_type = NL80211_CHAN_HT40PLUS;
+ break;
+ case IEEE80211_HT_PARAM_CHA_SEC_BELOW:
+ channel_type = NL80211_CHAN_HT40MINUS;
+ break;
+ }
+ }
+
__ieee80211_sta_join_ibss(sdata, cbss->bssid,
beacon_int,
cbss->channel,
+ channel_type,
basic_rates,
cbss->capability,
cbss->tsf);
@@ -529,7 +613,8 @@ static void ieee80211_sta_create_ibss(struct ieee80211_sub_if_data *sdata)
sdata->drop_unencrypted = 0;
__ieee80211_sta_join_ibss(sdata, bssid, sdata->vif.bss_conf.beacon_int,
- ifibss->channel, 3, /* first two are basic */
+ ifibss->channel, ifibss->channel_type,
+ 3, /* first two are basic */
capability, 0);
}
@@ -906,6 +991,7 @@ int ieee80211_ibss_join(struct ieee80211_sub_if_data *sdata,
sdata->vif.bss_conf.beacon_int = params->beacon_interval;
sdata->u.ibss.channel = params->channel;
+ sdata->u.ibss.channel_type = params->channel_type;
sdata->u.ibss.fixed_channel = params->channel_fixed;
if (params->ie) {
@@ -915,11 +1001,25 @@ int ieee80211_ibss_join(struct ieee80211_sub_if_data *sdata,
sdata->u.ibss.ie_len = params->ie_len;
}
+ /*
+ * Allocate IBSS probe response template (see
+ * __ieee80211_sta_join_ibss for the needed size). According to IEEE
+ * 802.11-2007 10.4.4.2, there is only 20 possibles values. We
+ * support up IEEE80211_MAX_SUPP_RATES (currently 32) : so 8 for
+ * Supported Rates and IEEE80211_MAX_SUPP_RATES-8 for Extended
+ * Supported Rates
+ */
+
skb = dev_alloc_skb(sdata->local->hw.extra_tx_headroom +
- 36 /* bitrates */ +
- 34 /* SSID */ +
- 3 /* DS params */ +
- 4 /* IBSS params */ +
+ sizeof(struct ieee80211_hdr_3addr) +
+ 12 /* struct ieee80211_mgmt.u.beacon */ +
+ 2 + IEEE80211_MAX_SSID_LEN /* max SSID */ +
+ 2 + 8 /* max Supported Rates */ +
+ 3 /* max DS params */ +
+ 4 /* IBSS params */ +
+ 2 + (IEEE80211_MAX_SUPP_RATES-8) /* max Ext Rates */ +
+ 2 + sizeof(struct ieee80211_ht_cap) +
+ 2 + sizeof(struct ieee80211_ht_info) +
params->ie_len);
if (!skb)
return -ENOMEM;
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c8077a3..30876f3 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -404,6 +404,7 @@ struct ieee80211_if_ibss {
u8 ssid_len, ie_len;
u8 *ie;
struct ieee80211_channel *channel;
+ enum nl80211_channel_type channel_type;
unsigned long ibss_join_req;
/* probe response/beacon for IBSS */
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 2b75b4f..b83f264 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -967,7 +967,7 @@ int ieee80211_build_preq_ies(struct ieee80211_local *local, u8 *buffer,
if (sband->ht_cap.ht_supported) {
u16 cap = sband->ht_cap.cap;
- __le16 tmp;
+ struct ieee80211_ht_cap ht_cap;
if (ieee80211_disable_40mhz_24ghz &&
sband->band == IEEE80211_BAND_2GHZ) {
@@ -975,18 +975,19 @@ int ieee80211_build_preq_ies(struct ieee80211_local *local, u8 *buffer,
cap &= ~IEEE80211_HT_CAP_SGI_40;
}
+ ht_cap.cap_info = cpu_to_le16(cap);
+ ht_cap.ampdu_params_info = sband->ht_cap.ampdu_factor |
+ (sband->ht_cap.ampdu_density <<
+ IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT);
+ ht_cap.mcs = sband->ht_cap.mcs;
+ ht_cap.extended_ht_cap_info = cpu_to_le16(0);
+ ht_cap.tx_BF_cap_info = cpu_to_le32(0);
+ ht_cap.antenna_selection_info = 0;
+
*pos++ = WLAN_EID_HT_CAPABILITY;
*pos++ = sizeof(struct ieee80211_ht_cap);
- memset(pos, 0, sizeof(struct ieee80211_ht_cap));
- tmp = cpu_to_le16(cap);
- memcpy(pos, &tmp, sizeof(u16));
- pos += sizeof(u16);
- *pos++ = sband->ht_cap.ampdu_factor |
- (sband->ht_cap.ampdu_density <<
- IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT);
- memcpy(pos, &sband->ht_cap.mcs, sizeof(sband->ht_cap.mcs));
- pos += sizeof(sband->ht_cap.mcs);
- pos += 2 + 4 + 1; /* ext info, BF cap, antsel */
+ memcpy(pos, &ht_cap, sizeof(struct ieee80211_ht_cap));
+ pos += sizeof(struct ieee80211_ht_cap);
}
/*
--
1.5.6.5
^ permalink raw reply related
* [PATCH] cfg80211: Check for channel HT capabilities in an IBSS
From: Benoit Papillault @ 2010-05-04 6:47 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Benoit Papillault
In-Reply-To: <1272955622-6987-1-git-send-email-benoit.papillault@free.fr>
When configuring an HT IBSS, we need to check if the specified channel
is capable of ht40+, ht40- or ht20.
Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
---
net/wireless/nl80211.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8da9823..0a82623 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3858,11 +3858,11 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
ibss.ie_len = nla_len(info->attrs[NL80211_ATTR_IE]);
}
- ibss.channel = ieee80211_get_channel(wiphy,
- nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_FREQ]));
+ ibss.channel = rdev_freq_to_chan(rdev,
+ nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_FREQ]),
+ channel_type);
if (!ibss.channel ||
- ibss.channel->flags & IEEE80211_CHAN_NO_IBSS ||
- ibss.channel->flags & IEEE80211_CHAN_DISABLED) {
+ ibss.channel->flags & IEEE80211_CHAN_NO_IBSS) {
err = -EINVAL;
goto out;
}
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] mac80211: improve IBSS scanning
From: Benoit Papillault @ 2010-05-04 5:52 UTC (permalink / raw)
To: Joerg Pommnitz; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <1272895986.3614.40.camel@jlt3.sipsolutions.net>
Le 03/05/2010 16:13, Johannes Berg a écrit :
> On Mon, 2010-05-03 at 14:08 +0000, Joerg Pommnitz wrote:
>> Johannes Berg<johannes@...> writes:
>>>
>>> Interesting. I guess we never rejected it although it's invalid
>>> according to the standard. Yuck. I think I would like to make nl80211
>>> reject it, but maybe I'll forget about it and let you use it ;)
>>
>> Sorry, I don't know about mac80211. This was more a general point.
>> I thought this woudn't work at all but a co-worker was adamant that
>> it works fine with Madwifi. So I sat down and observed it with
>> a monitoring interface and lo and behold: The beacons really contained
>> the broadcast SSID.
>
> Oh ok. I didn't see anything in cfg80211 but will check and post a
> patch :)
>
> johannes
Sorry to reply late, but in IBSS, beacons are really critical for
synchronization (including BSSID & TSF). As such, they cannot be removed.
AFAIK, adhoc DEMO is just like adhoc, but without beacons. As such,
there is no synchronization and every node use the BSSID
00:00:00:00:00:00, preventing from having several "networks" on the same
frequency (since there is no SSID to distinguish them).
What you said is that you are using the broadcast SSID instead? And a
fixed BSSID? I would indeed appreciate the capture file :-)
Regards,
Benoit
^ permalink raw reply
* Re: [RFC PATCHv4 0/2] mac80211: cfg80211: dynamic ps timeout based on pm-qos
From: Juuso Oikarinen @ 2010-05-04 5:25 UTC (permalink / raw)
To: ext Luis R. Rodriguez; +Cc: Kalle Valo, linux-wireless@vger.kernel.org
In-Reply-To: <o2z43e72e891005031544ufd3f84a5g4e0a3a0dceac8002@mail.gmail.com>
On Tue, 2010-05-04 at 00:44 +0200, ext Luis R. Rodriguez wrote:
> On Thu, Apr 29, 2010 at 6:45 AM, Kalle Valo <kvalo@adurom.com> wrote:
> > Juuso Oikarinen <juuso.oikarinen@nokia.com> writes:
> >
> >> These patches propose a way to adjust the dynamic ps timeout in the
> >> mac80211 based on the pm-qos network latency value. This allows user
> >> space to influence the level of power saving performed by the
> >> mac80211.
> >>
> >> v4 of these patches change the way pm qos network latency ranges
> >> converted to dynamic ps timeout values a little bit saner. Unlike
> >> the previous set of patches, now the latancy values make sense in a
> >> wider scope than this ps timeout thing only. I hope this makes them
> >> somewhat more future-proof.
> >
> > This looks very good now. Bonus points for adding the comment about
> > the two second value!
> >
> > Thank you for implementing this.
>
> Even more bonus points (if this was a video game you'd get an extra
> life) if you add the new changes on the documentation here:
>
> http://wireless.kernel.org/en/developers/Documentation/pm-qos
>
Can't resist a new life! Yes, I will add the changes. Honestly, I was
planning to, and almost remembered ;)
-Juuso
> Luis
^ permalink raw reply
* Re: [PATCH 2/4] rt2x00: Enable RT30xx by default.
From: Gertjan van Wingerde @ 2010-05-04 3:31 UTC (permalink / raw)
To: Pavel Roskin
Cc: Stefan Lippers-Hollmann, John W. Linville, Ivo van Doorn,
linux-wireless, users
In-Reply-To: <1272926643.6239.1.camel@mj>
On 05/04/10 00:44, Pavel Roskin wrote:
> On Tue, 2010-05-04 at 00:08 +0200, Stefan Lippers-Hollmann wrote:
>
>> RT2800PCI_RT30XX is not a new/ separate module, its only function is to
>> limit the PCI ID space (to not claim PCI IDs for chipset generations not
>> yet debugged properly) of rt2800pci.ko; this symbol isn't even used
>> anywhere else than within the PCI table.
>
> I realize that. Still, somebody upstream can object.
>
>> A 100% equivalent patch would be
>> to just drop the config option completely. I doubt that doing that would
>> meet resistance, as it merely adds previously 'unknown' (to be supported)
>> PCI IDs.
>
> That's what I would do.
>
To be honest, at the moment I would just change the default from 'n' to 'y'
for one kernel cycle, and then remove the entire option in the next kernel
release.
This is just to make it easier to revert back if for some reasons problems
arise with the rt30xx support.
The overall goal is to get rid of all these of the RT2800PCI_yyy and RT2800USB_zzz
symbols, but that can only happen if the devices denoted by these symbols
are properly supported.
John, I leave it up to you, but for me my original patch should be merged, and
I'll send an equivalent patch for Stefan's one for the next kernel release.
---
Gertjan.
^ permalink raw reply
* Re: [PATCH] compat-wireless: refresh patches
From: Luis R. Rodriguez @ 2010-05-04 0:01 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof
In-Reply-To: <1272911746-17268-1-git-send-email-hauke@hauke-m.de>
On Mon, May 3, 2010 at 11:35 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> Make the patches apply cleanly again.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Applied, thanks!
Luis
^ permalink raw reply
* Re: [PATCH v2] compat: backport usb_alloc_coherent() and usb_free_coherent()
From: Luis R. Rodriguez @ 2010-05-03 23:58 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof, proski
In-Reply-To: <1272915401-7431-1-git-send-email-hauke@hauke-m.de>
On Mon, May 3, 2010 at 12:36 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> ---
> v2: Add arguments to define
Thanks applied.
Luis
^ permalink raw reply
* Re: HT rate warning with openwrt AP using wireless-compat and ath9k
From: Luis R. Rodriguez @ 2010-05-03 23:56 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <w2z43e72e891005031654rea8e3628i6906895089bd6b03@mail.gmail.com>
On Mon, May 3, 2010 at 4:54 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Mon, May 3, 2010 at 4:10 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> 0x7b
>
> Actually 0x7b fits 0x7f if the rate was marked as an HT rate by
> hardware (0x80) so technically it could have been an HT rate marked as
> 0x7b and that is why you get the warning. So I wonder what hardware
> rate 0xfb should be mapping to (0x7b | 0x80).
What I'm saying is I don't think you will hit that debug print I
pointed out, and we need to figure out what 0xfb or 0x7b should map
too as hardware seems to be spewing it out on RX'd frames.
Luis
^ permalink raw reply
* Re: HT rate warning with openwrt AP using wireless-compat and ath9k
From: Luis R. Rodriguez @ 2010-05-03 23:54 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <w2q43e72e891005031610uf6b912aduf271b0a97933d68a@mail.gmail.com>
On Mon, May 3, 2010 at 4:10 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> 0x7b
Actually 0x7b fits 0x7f if the rate was marked as an HT rate by
hardware (0x80) so technically it could have been an HT rate marked as
0x7b and that is why you get the warning. So I wonder what hardware
rate 0xfb should be mapping to (0x7b | 0x80).
Luis
^ permalink raw reply
* Re: HT rate warning with openwrt AP using wireless-compat and ath9k
From: Luis R. Rodriguez @ 2010-05-03 23:10 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87och0j7jj.fsf@purkki.valot.fi>
On Sat, May 1, 2010 at 2:27 AM, Kalle Valo <kvalo@adurom.com> wrote:
> Hi,
>
> I'm running OpenWrt 10.03 on Netgear WNDR3700 and I'm having stability
> issues. The AP reboots few times a week, maybe even daily. I get the
> feeling that my wife's windows laptop is related to the reboots
> somehow, but I haven't investigated this in detail yet. Also I do not
> have access to serial console, so I don't have proper logs.
>
> But today the AP didn't reboot, wireless was just dead. I managed to
> find this with ssh:
>
> ------------[ cut here ]------------
> WARNING: at
> /home/openwrt/backfire/build/ar71xx/build_dir/linux-ar71xx/compat-wireless-2010-03-24/net/mac80211/rx.c:2528
> 0x83115884()
> Rate marked as an HT rate but passed status->rate_idx is not an MCS
> index [0-76]: 123 (0x7b)
This happens when the hardware passes up a frame with an invalid rate.
Instead of discarding them we just set the rate as 1 Mbps as the frame
is already processed and marked as OK but I'm starting to think that
is a mistake and we should just consider dropping them altogether.
This will need some more review.
For now lets review your specific case since it might be that you can
reproduce this. ath9k *should not* be passing up frames with a bad
rate index, in fact ath9k will override the rate to 0, the first rate,
which is 1mbps. In ath9k_process_rate() we have:
static u8 ath9k_process_rate(struct ath_common *common,
struct ieee80211_hw *hw,
struct ath_rx_status *rx_stats,
struct ieee80211_rx_status *rxs,
struct sk_buff *skb)
{
struct ieee80211_supported_band *sband;
enum ieee80211_band band;
unsigned int i = 0;
band = hw->conf.channel->band;
sband = hw->wiphy->bands[band];
if (rx_stats->rs_rate & 0x80) {
/* HT rate */
rxs->flag |= RX_FLAG_HT;
if (rx_stats->rs_flags & ATH9K_RX_2040)
rxs->flag |= RX_FLAG_40MHZ;
if (rx_stats->rs_flags & ATH9K_RX_GI)
rxs->flag |= RX_FLAG_SHORT_GI;
return rx_stats->rs_rate & 0x7f;
}
for (i = 0; i < sband->n_bitrates; i++) {
if (sband->bitrates[i].hw_value == rx_stats->rs_rate)
return i;
if (sband->bitrates[i].hw_value_short == rx_stats->rs_rate) {
rxs->flag |= RX_FLAG_SHORTPRE;
return i;
}
}
/* No valid hardware bitrate found -- we should not get here */
ath_print(common, ATH_DBG_XMIT, "unsupported hw bitrate detected "
"0x%02x using 1 Mbit\n", rx_stats->rs_rate);
if ((common->debug_mask & ATH_DBG_XMIT))
print_hex_dump_bytes("", DUMP_PREFIX_NONE, skb->data, skb->len);
return 0;
}
Can you enable ATH_DBG_XMIT on the box and see if this comes up?
ATH_DBG_XMIT = 0x00000080,
So just modprobe ath9k debug=0x80. I'll send an RFT patch soon.
Luis
^ permalink raw reply
* Re: [RFC PATCHv4 0/2] mac80211: cfg80211: dynamic ps timeout based on pm-qos
From: Luis R. Rodriguez @ 2010-05-03 22:44 UTC (permalink / raw)
To: Kalle Valo; +Cc: Juuso Oikarinen, linux-wireless
In-Reply-To: <87633al6di.fsf@purkki.valot.fi>
On Thu, Apr 29, 2010 at 6:45 AM, Kalle Valo <kvalo@adurom.com> wrote:
> Juuso Oikarinen <juuso.oikarinen@nokia.com> writes:
>
>> These patches propose a way to adjust the dynamic ps timeout in the
>> mac80211 based on the pm-qos network latency value. This allows user
>> space to influence the level of power saving performed by the
>> mac80211.
>>
>> v4 of these patches change the way pm qos network latency ranges
>> converted to dynamic ps timeout values a little bit saner. Unlike
>> the previous set of patches, now the latancy values make sense in a
>> wider scope than this ps timeout thing only. I hope this makes them
>> somewhat more future-proof.
>
> This looks very good now. Bonus points for adding the comment about
> the two second value!
>
> Thank you for implementing this.
Even more bonus points (if this was a video game you'd get an extra
life) if you add the new changes on the documentation here:
http://wireless.kernel.org/en/developers/Documentation/pm-qos
Luis
^ permalink raw reply
* Re: [PATCH 2/4] rt2x00: Enable RT30xx by default.
From: Pavel Roskin @ 2010-05-03 22:44 UTC (permalink / raw)
To: Stefan Lippers-Hollmann
Cc: Gertjan van Wingerde, John W. Linville, Ivo van Doorn,
linux-wireless, users
In-Reply-To: <201005040008.36956.s.L-H@gmx.de>
On Tue, 2010-05-04 at 00:08 +0200, Stefan Lippers-Hollmann wrote:
> RT2800PCI_RT30XX is not a new/ separate module, its only function is to
> limit the PCI ID space (to not claim PCI IDs for chipset generations not
> yet debugged properly) of rt2800pci.ko; this symbol isn't even used
> anywhere else than within the PCI table.
I realize that. Still, somebody upstream can object.
> A 100% equivalent patch would be
> to just drop the config option completely. I doubt that doing that would
> meet resistance, as it merely adds previously 'unknown' (to be supported)
> PCI IDs.
That's what I would do.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [RFC] mac80211: radiotap vendor data
From: Luis R. Rodriguez @ 2010-05-03 22:16 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Joshua Zhao, Matt Smith
In-Reply-To: <1272734031.8461.0.camel@jlt3.sipsolutions.net>
On Sat, May 1, 2010 at 10:13 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> This allows drivers to add radiotap vendor data
> to any received frame, which will be simply
> passed into userspace and ignored by the kernel.
> Can be used by drivers to convey hw-specific
> information.
Thanks a lot for all your work on this area, on the standardization
part, mac80211 and even for providing a simple example, its really
appreciated! Some comments below.
> Note: 11n shouldn't be done there, in case somebody
> got ideas!!
Well you mean 802.11n standard stuff, I take it, because there are
vendor 802.11n specific stuff.
> Note: didn't test this after the paged RX changes
> ---
> drivers/net/wireless/mac80211_hwsim.c | 17 ++++++++++
> include/net/mac80211.h | 12 +++++++
> net/mac80211/rx.c | 53 ++++++++++++++++++++++++++++++----
> 3 files changed, 77 insertions(+), 5 deletions(-)
>
> --- wireless-testing.orig/include/net/mac80211.h 2010-05-01 08:46:26.000000000 +0200
> +++ wireless-testing/include/net/mac80211.h 2010-05-01 08:47:54.000000000 +0200
> @@ -565,6 +565,13 @@ enum mac80211_rx_flags {
> * @rate_idx: index of data rate into band's supported rates or MCS index if
> * HT rates are use (RX_FLAG_HT)
> * @flag: %RX_FLAG_*
> + * @vendor_radiotap_bitmap: radiotap vendor namespace presence bitmap
> + * @vendor_radiotap_len: radiotap vendor namespace length
> + * @vendor_radiotap_align: radiotap vendor namespace alignment. Note
> + * that the actual data must be at the start of the SKB data
> + * already.
I see your WARN_ON() on the alignment being set to 0 and set it to 1
then. Can you clarify a little more on this here. If there is no
strict alignment requirements why not just treat 0 as 1 then?
> + * @vendor_radiotap_oui: radiotap vendor namespace OUI
> + * @vendor_radiotap_subns: radiotap vendor sub namespace
> */
> struct ieee80211_rx_status {
> u64 mactime;
> @@ -575,6 +582,11 @@ struct ieee80211_rx_status {
> int antenna;
> int rate_idx;
> int flag;
> + u32 vendor_radiotap_bitmap;
> + u16 vendor_radiotap_len;
> + u8 vendor_radiotap_align;
> + u8 vendor_radiotap_oui[3];
> + u8 vendor_radiotap_subns;
> };
>
> /**
> --- wireless-testing.orig/net/mac80211/rx.c 2010-05-01 08:46:26.000000000 +0200
> +++ wireless-testing/net/mac80211/rx.c 2010-05-01 08:47:54.000000000 +0200
> @@ -37,6 +37,8 @@
> static struct sk_buff *remove_monitor_info(struct ieee80211_local *local,
> struct sk_buff *skb)
> {
> + struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
> +
> if (local->hw.flags & IEEE80211_HW_RX_INCLUDES_FCS) {
> if (likely(skb->len > FCS_LEN))
> __pskb_trim(skb, skb->len - FCS_LEN);
> @@ -48,6 +50,9 @@ static struct sk_buff *remove_monitor_in
> }
> }
>
> + if (status->vendor_radiotap_len)
> + __pskb_pull(skb, status->vendor_radiotap_len);
> +
> return skb;
> }
>
> @@ -69,8 +74,8 @@ static inline int should_drop_frame(stru
> }
>
> static int
> -ieee80211_rx_radiotap_len(struct ieee80211_local *local,
> - struct ieee80211_rx_status *status)
> +ieee80211_rx_radiotap_space(struct ieee80211_local *local,
> + struct ieee80211_rx_status *status)
> {
> int len;
>
> @@ -87,6 +92,21 @@ ieee80211_rx_radiotap_len(struct ieee802
> if (len & 1) /* padding for RX_FLAGS if necessary */
> len++;
>
> + if (status->vendor_radiotap_len) {
> + /* allocate extra bitmap */
> + len += 4;
> +
> + if (WARN_ON(status->vendor_radiotap_align == 0))
> + status->vendor_radiotap_align = 1;
> + /* align standard part of vendor namespace */
> + len = ALIGN(len, 2);
> + /* allocate standard part of vendor namespace */
> + len += 6;
> + /* align vendor-defined part */
> + len = ALIGN(len, status->vendor_radiotap_align);
> + /* vendor-defined part is already in skb */
> + }
> +
> return len;
> }
>
> @@ -115,10 +135,18 @@ ieee80211_add_rx_radiotap_header(struct
> (1 << IEEE80211_RADIOTAP_CHANNEL) |
> (1 << IEEE80211_RADIOTAP_ANTENNA) |
> (1 << IEEE80211_RADIOTAP_RX_FLAGS));
> - rthdr->it_len = cpu_to_le16(rtap_len);
> + rthdr->it_len = cpu_to_le16(rtap_len + status->vendor_radiotap_len);
>
> pos = (unsigned char *)(rthdr+1);
>
> + if (status->vendor_radiotap_len) {
> + rthdr->it_present |=
> + cpu_to_le32(BIT(IEEE80211_RADIOTAP_VENDOR_NAMESPACE)) |
> + cpu_to_le32(BIT(IEEE80211_RADIOTAP_EXT));
> + put_unaligned_le32(status->vendor_radiotap_bitmap, pos);
> + pos += 4;
> + }
> +
> /* the order of the following fields is important */
>
> /* IEEE80211_RADIOTAP_TSFT */
> @@ -190,11 +218,26 @@ ieee80211_add_rx_radiotap_header(struct
> /* IEEE80211_RADIOTAP_RX_FLAGS */
> /* ensure 2 byte alignment for the 2 byte field as required */
> if ((pos - (u8 *)rthdr) & 1)
> - pos++;
> + *pos++ = 0;
Why is this needed though? We already memset(rthdr, 0, rtap_len); above.
> if (status->flag & RX_FLAG_FAILED_PLCP_CRC)
> rx_flags |= IEEE80211_RADIOTAP_F_RX_BADPLCP;
> put_unaligned_le16(rx_flags, pos);
> pos += 2;
> +
> + if (status->vendor_radiotap_len) {
> + /* ensure 2 byte alignment for the vendor field as required */
> + if ((pos - (u8 *)rthdr) & 1)
> + *pos++ = 0;
> + *pos++ = status->vendor_radiotap_oui[0];
> + *pos++ = status->vendor_radiotap_oui[1];
> + *pos++ = status->vendor_radiotap_oui[2];
> + *pos++ = status->vendor_radiotap_subns;
> + put_unaligned_le16(status->vendor_radiotap_len, pos);
> + pos += 2;
> + /* align the actual payload as requested */
> + while ((pos - (u8 *)rthdr) & (status->vendor_radiotap_align - 1))
> + *pos++ = 0;
> + }
> }
>
> /*
> @@ -223,7 +266,7 @@ ieee80211_rx_monitor(struct ieee80211_lo
> */
>
> /* room for the radiotap header based on driver features */
> - needed_headroom = ieee80211_rx_radiotap_len(local, status);
> + needed_headroom = ieee80211_rx_radiotap_space(local, status);
>
> if (local->hw.flags & IEEE80211_HW_RX_INCLUDES_FCS)
> present_fcs_len = FCS_LEN;
> --- wireless-testing.orig/drivers/net/wireless/mac80211_hwsim.c 2010-05-01 08:46:27.000000000 +0200
> +++ wireless-testing/drivers/net/wireless/mac80211_hwsim.c 2010-05-01 19:04:57.000000000 +0200
> @@ -484,6 +484,7 @@ static bool mac80211_hwsim_tx_frame(stru
> struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
> struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> struct ieee80211_rx_status rx_status;
> + u8 *vendor_data;
>
> if (data->idle) {
> printk(KERN_DEBUG "%s: Trying to TX when idle - reject\n",
> @@ -509,6 +510,20 @@ static bool mac80211_hwsim_tx_frame(stru
> secpath_reset(skb);
> nf_reset(skb);
>
> + vendor_data = skb_push(skb, 4);
> + rx_status.vendor_radiotap_len = 4;
> + rx_status.vendor_radiotap_align = 4;
> + rx_status.vendor_radiotap_oui[0] = 0xff;
> + rx_status.vendor_radiotap_oui[1] = 0xff;
> + rx_status.vendor_radiotap_oui[2] = 0xff;
> + rx_status.vendor_radiotap_subns = 129;
> + rx_status.vendor_radiotap_bitmap = 0x1;
> +
> + *vendor_data++ = 1;
> + *vendor_data++ = 2;
> + *vendor_data++ = 3;
> + *vendor_data++ = 4;
> +
Heh nice, now we just need a sample radiotap vendor extension parser example.
Thanks!!!
Luis
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox