* Re: [PATCH] iwlagn: Change the TPT calculations sanity-check to WARN_ON
From: Adel Gadllah @ 2010-05-03 21:10 UTC (permalink / raw)
To: Pavel Roskin
Cc: Gábor Stefanik, Kalle Valo, John W. Linville, linux-wireless,
johill, reinette.chatre
In-Reply-To: <1272920504.4907.5.camel@mj>
2010/5/3 Pavel Roskin <proski@gnu.org>:
> On Mon, 2010-05-03 at 22:48 +0200, Gábor Stefanik wrote:
>
>> One exception I can think of: major misconfiguration can cause a
>> wireless device to DMA data into sensitive memory locations. When
>> evidence of this is detected, it might make sense to BUG_ON()
>> (especially if the bogus DMA operations can be exploited remotely to
>> overwrite arbitrary memory addresses). However, in that case, the
>> attacker may have already overwritten panic() with malicious code as
>> well, so even this case doesn't hold.
>
> And then there is a case when encryption fails and there is a risk of
> transmitting data without encryption or accepting data without
> verification.
So kill the connection rather than the whole system.
^ permalink raw reply
* Re: [PATCH] iwlagn: Change the TPT calculations sanity-check to WARN_ON
From: Gábor Stefanik @ 2010-05-03 21:20 UTC (permalink / raw)
To: Adel Gadllah
Cc: Pavel Roskin, Kalle Valo, John W. Linville, linux-wireless,
johill, reinette.chatre
In-Reply-To: <l2m6cf6b73e1005031410t7c6d3148x832ddd405fc482ec@mail.gmail.com>
On Mon, May 3, 2010 at 11:10 PM, Adel Gadllah <adel.gadllah@gmail.com> wrote:
> 2010/5/3 Pavel Roskin <proski@gnu.org>:
>> On Mon, 2010-05-03 at 22:48 +0200, Gábor Stefanik wrote:
>>
>>> One exception I can think of: major misconfiguration can cause a
>>> wireless device to DMA data into sensitive memory locations. When
>>> evidence of this is detected, it might make sense to BUG_ON()
>>> (especially if the bogus DMA operations can be exploited remotely to
>>> overwrite arbitrary memory addresses). However, in that case, the
>>> attacker may have already overwritten panic() with malicious code as
>>> well, so even this case doesn't hold.
>>
>> And then there is a case when encryption fails and there is a risk of
>> transmitting data without encryption or accepting data without
>> verification.
>
> So kill the connection rather than the whole system.
Or maybe just drop the packet, as mac80211 AFAIK usually does. Perhaps
print a WARN_ON to let developers know of the issue. But a BUG_ON is
still excessive - I can't think of any way a WARN_ON + interface down
may fail in preventing unencrypted data leak.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: ar9170-fw II
From: Luis R. Rodriguez @ 2010-05-03 21:39 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: Christian Lamparter, linux-wireless
In-Reply-To: <4BDC719E.3060505@dlasys.net>
On Sat, May 1, 2010 at 11:23 AM, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> On 05/01/2010 01:19 PM, Christian Lamparter wrote:
>>
>> Well, for starters the ar9170 uses a ZyDas MAC (aka ZD1221)
>> and a AR900x PHY/Radio. Therefore the phy code and registers
>> are very similar to those #definitions you can find in ath9k.
>> And for the MAC code& registers you can look into zd1211rw,
>> or look into drivers/staging/otus (original vendor driver,
>> shares some code with their windows drivers)
>>
>> AFAICT, there are no technical documents about the AR9170
>> solution available w/o signing a NDA with Atheros
>> (probably because the devices are still produced and sold in high
>> quantities?).
>>
>
> Thanks;
> I did just discover a reasonably good 150p spec. in what I received
> from my client. If I can I will share it. I am under an NDA, but the client also told
> me that they received no cooperation from atheros.
You should be more specific. Atheros did GPL their ar9170 driver after
all, so it is in fact the first hardware vendor to ever have GPL'd
firmware for *any* device driver upstream. Releasing more docs takes
time, you are better off working directly with the upstream Atheros
developers than just subjectively claiming lack of cooperation.
Luis
^ permalink raw reply
* Re: [PATCH 2/4] rt2x00: Enable RT30xx by default.
From: Stefan Lippers-Hollmann @ 2010-05-03 22:08 UTC (permalink / raw)
To: Pavel Roskin
Cc: Gertjan van Wingerde, John W. Linville, Ivo van Doorn,
linux-wireless, users
In-Reply-To: <1272920358.4907.3.camel@mj>
Hi
On Monday 03 May 2010, Pavel Roskin wrote:
> On Mon, 2010-05-03 at 22:43 +0200, Gertjan van Wingerde wrote:
> > Now that RT30xx support is at the same level as RT28xx support we can enable
> > these devices by default.
[...]
> > --- a/drivers/net/wireless/rt2x00/Kconfig
> > +++ b/drivers/net/wireless/rt2x00/Kconfig
> > @@ -87,7 +87,7 @@ if RT2800PCI
> >
> > config RT2800PCI_RT30XX
> > bool "rt2800pci - Include support for rt30xx (PCI/PCIe/PCMCIA) devices"
> > - default n
> > + default y
>
> I believe defaulting booleans to "y" is discouraged, especially for
> drivers. Most users don't have any particular hardware device.
[disclaimer, I have no access to any rt30xx USB/ PCI devices, so I'm not
proposing the attached patch, as I can't evaluate the stability of
rt2800pci's rt30xx support myself but merely use it for demonstration
purposes]
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. 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.
[However if RT2800PCI_RT30XX is going to be kept, but changed to default
to 'y', I'd propose to drop the 'Support for these devices is
non-functional at the moment and is intended for testers and developers"
paragraph at the same time.]
Regards
Stefan Lippers-Hollmann
rt2x00: claim RT30xx PCI IDs in rt2800pci
Now that RT30xx support is at the same level as RT28xx, it can be enabled
unconditionally.
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
index 5239e08..ee088ac 100644
--- a/drivers/net/wireless/rt2x00/Kconfig
+++ b/drivers/net/wireless/rt2x00/Kconfig
@@ -85,17 +85,6 @@ config RT2800PCI
if RT2800PCI
-config RT2800PCI_RT30XX
- bool "rt2800pci - Include support for rt30xx (PCI/PCIe/PCMCIA) devices"
- default n
- ---help---
- This adds support for rt30xx wireless chipset family to the
- rt2800pci driver.
- Supported chips: RT3090, RT3091 & RT3092
-
- Support for these devices is non-functional at the moment and is
- intended for testers and developers.
-
config RT2800PCI_RT35XX
bool "rt2800pci - Include support for rt35xx (PCI/PCIe/PCMCIA) devices"
default n
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index 0e52f17..9efd4fb 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -1225,12 +1225,10 @@ static DEFINE_PCI_DEVICE_TABLE(rt2800pci_device_table) = {
{ PCI_DEVICE(0x1432, 0x7758), PCI_DEVICE_DATA(&rt2800pci_ops) },
{ PCI_DEVICE(0x1432, 0x7768), PCI_DEVICE_DATA(&rt2800pci_ops) },
{ PCI_DEVICE(0x1a3b, 0x1059), PCI_DEVICE_DATA(&rt2800pci_ops) },
-#ifdef CONFIG_RT2800PCI_RT30XX
{ PCI_DEVICE(0x1814, 0x3090), PCI_DEVICE_DATA(&rt2800pci_ops) },
{ PCI_DEVICE(0x1814, 0x3091), PCI_DEVICE_DATA(&rt2800pci_ops) },
{ PCI_DEVICE(0x1814, 0x3092), PCI_DEVICE_DATA(&rt2800pci_ops) },
{ PCI_DEVICE(0x1462, 0x891a), PCI_DEVICE_DATA(&rt2800pci_ops) },
-#endif
#ifdef CONFIG_RT2800PCI_RT35XX
{ PCI_DEVICE(0x1814, 0x3060), PCI_DEVICE_DATA(&rt2800pci_ops) },
{ PCI_DEVICE(0x1814, 0x3062), PCI_DEVICE_DATA(&rt2800pci_ops) },
^ permalink raw reply related
* 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
* 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 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: 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: 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: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: [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: [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 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: [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] 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
* [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
* [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: 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
* 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] 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: 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
* 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: [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
* [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: 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
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