* Does linux wireless support TL-WN861N
From: JD @ 2011-01-18 19:11 UTC (permalink / raw)
To: linux-wireless
TP-Link TL-WN861N
see
http://www.tp-link.com/products/productDetails.asp?class=&content=spe&pmodel=TL-WN861N
^ permalink raw reply
* Re: WWAN driver for Huawei MU509 chip?
From: Dan Williams @ 2011-01-18 16:23 UTC (permalink / raw)
To: Brzezowski, Karen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <0826983CC0CB074798C42E77D8ACD07F06921D@pdtms1.pdt.com>
On Mon, 2011-01-17 at 16:52 +0000, Brzezowski, Karen wrote:
> Is this the right mailing list for asking for information
> on drivers for the Huawei MU509 WCDMA chip?
No, it's not the right list. But the MU509 appears to provide a USB
interface, and assuming it's the standard type of "vendor-specific USB
serial interface" then what you want to do is try adding the USB IDs of
the MU509 to the 'option' driver in the linux kernel, and then seeing if
you can talk to the device over ttyUSBx using minicom or screen. Most
WWAN devices that provide USB interfaces expose at least one
AT-compatible serial port, and at the moment most Huawei UMTS/CDMA2000
devices are supported by the 'option' driver.
The specific list you want is linux-usb.
Dan
^ permalink raw reply
* [PATCH wireless-2.6.38] iwlwifi: fix valid chain reading from EEPROM
From: Wey-Yi Guy @ 2011-01-18 15:59 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy
When read valid tx/rx chains from EEPROM, there is a bug to use the
tx chain value for both tx and rx, the result of this cause low
receive throughput on 1x2 devices becuase rx will only utilize single
chain instead of two chains
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
this patch is also available from wireless-2.6 branch on
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
---
drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
index 97906dd..14ceb4d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
@@ -168,7 +168,7 @@ int iwl_eeprom_check_sku(struct iwl_priv *priv)
/* not using .cfg overwrite */
radio_cfg = iwl_eeprom_query16(priv, EEPROM_RADIO_CONFIG);
priv->cfg->valid_tx_ant = EEPROM_RF_CFG_TX_ANT_MSK(radio_cfg);
- priv->cfg->valid_rx_ant = EEPROM_RF_CFG_TX_ANT_MSK(radio_cfg);
+ priv->cfg->valid_rx_ant = EEPROM_RF_CFG_RX_ANT_MSK(radio_cfg);
if (!priv->cfg->valid_tx_ant || !priv->cfg->valid_rx_ant) {
IWL_ERR(priv, "Invalid chain (0X%x, 0X%x)\n",
priv->cfg->valid_tx_ant,
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2.6.32.y] hostap_cs: fix sleeping function called from invalid context
From: Stanislaw Gruszka @ 2011-01-18 15:43 UTC (permalink / raw)
To: Tim Gardner; +Cc: stable, Dominik Brodowski, linux-wireless, linux-pcmcia
In-Reply-To: <4D35A87D.3020600@canonical.com>
On Tue, Jan 18, 2011 at 07:49:33AM -0700, Tim Gardner wrote:
> Yes - I think this patch is correct. I didn't drill deep enough to
> notice the GFP_KERNEL memory allocation. However, I think there is
> still a problem with the interrupt handler which will only be
> noticed if there is another active device on the same shared
> interrupt. Shouldn't it return IRQ_NONE? See attached.
I'm not sure. I think kernel could disable interrupt line when IRQ_NONE
is returned, but line is not shared.
Generally hostap pcmcia initialization procedure does not look correct.
It should be rahter rearranged to request irq when we are ready to
receive it, like that:
ret = pcmcia_enable_device(link);
if (ret)
goto failed;
dev->irq = link->irq;
dev->base_addr = link->resource[0]->start;
ret = pcmcia_request_irq(link, prism2_interrupt);
if (ret)
goto failed;
However I'm not sure if pcmcia_enable_device() does not require
to have pcmcia_request_irq() before?
Stanislaw
^ permalink raw reply
* Re: intermittent eap authentication failure
From: Johannes Berg @ 2011-01-18 15:39 UTC (permalink / raw)
To: Chuck Crisler; +Cc: linux-wireless
In-Reply-To: <8D410FA49EFD4D8997BAC548BA2D55AF@ChuckPC>
On Tue, 2011-01-18 at 10:33 -0500, Chuck Crisler wrote:
> The deauth reason code isn't passed up to the supplicant,
With -Dnl80211 it should be, no?
johannes
^ permalink raw reply
* Re: intermittent eap authentication failure
From: Chuck Crisler @ 2011-01-18 15:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1295364238.3563.24.camel@jlt3.sipsolutions.net>
The deauth reason code isn't passed up to the supplicant, so the supplicant
doesn't have the best info to make a decision. If the notification message
was changed to include the reason code, then the supplicant wouldn't need to
do a scan in this case, which makes everything faster (unless you have
accurate scan results from a background scan). Dropping a scan means
everything works much faster.
Background scans probably won't work for our app because we are transmitting
about 2-3 (sometimes more) good sized data packets every ~40 msec. We would
have to drop video frames to make room for background scanning, but that
degrades the video quality, and that is noticeable.
Chuck
----- Original Message -----
From: "Johannes Berg" <johannes@sipsolutions.net>
To: "Chuck Crisler" <ccrisler@vgocom.com>
Cc: <linux-wireless@vger.kernel.org>
Sent: Tuesday, January 18, 2011 10:23 AM
Subject: Re: intermittent eap authentication failure
> On Tue, 2011-01-18 at 10:21 -0500, Chuck Crisler wrote:
>> What is the reason that the design calls for a scan in response to a
>> session
>> timeout? A session timeout doesn't happen because of a roam, so the
>> original
>> AP is probably still good. Why scan?
>
> I don't think there's any design here, and in any case that's
> wpa_supplicant's doing. :)
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: intermittent eap authentication failure
From: Johannes Berg @ 2011-01-18 15:23 UTC (permalink / raw)
To: Chuck Crisler; +Cc: linux-wireless
In-Reply-To: <48A27D1459A9493C8A16D0D6308A5FB1@ChuckPC>
On Tue, 2011-01-18 at 10:21 -0500, Chuck Crisler wrote:
> What is the reason that the design calls for a scan in response to a session
> timeout? A session timeout doesn't happen because of a roam, so the original
> AP is probably still good. Why scan?
I don't think there's any design here, and in any case that's
wpa_supplicant's doing. :)
johannes
^ permalink raw reply
* Re: intermittent eap authentication failure
From: Chuck Crisler @ 2011-01-18 15:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1295362622.3563.23.camel@jlt3.sipsolutions.net>
What is the reason that the design calls for a scan in response to a session
timeout? A session timeout doesn't happen because of a roam, so the original
AP is probably still good. Why scan?
Chuck
----- Original Message -----
From: "Johannes Berg" <johannes@sipsolutions.net>
To: "Chuck Crisler" <ccrisler@vgocom.com>
Cc: <linux-wireless@vger.kernel.org>
Sent: Tuesday, January 18, 2011 9:57 AM
Subject: Re: intermittent eap authentication failure
> On Tue, 2011-01-18 at 09:54 -0500, Chuck Crisler wrote:
>> I will have to reply later about why it is associating. I will have to
>> add a
>> printk to my driver but I currently have 2 tests running and don't want
>> to
>> stop either.
>> It looks like it might be called by ieee80211_sta_work() in mlme.c
>> because
>> it might still be in the IEEE80211_STA_MLME_ASSOCIATE state. I will
>> confirm
>> that.
>
> Did you ever consider using compat-wireless? Frankly, my main memory
> isn't large enough to hold information about old mac80211 behaviour so I
> have to get that information from swap (git tree) and that's really
> slow :-)
>
> johannes
>
>
^ permalink raw reply
* Re: intermittent eap authentication failure
From: Chuck Crisler @ 2011-01-18 15:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1295362622.3563.23.camel@jlt3.sipsolutions.net>
Yes, I am advocating for compat-wireless. But have repeated lost a political
battle over that one. :-(
----- Original Message -----
From: "Johannes Berg" <johannes@sipsolutions.net>
To: "Chuck Crisler" <ccrisler@vgocom.com>
Cc: <linux-wireless@vger.kernel.org>
Sent: Tuesday, January 18, 2011 9:57 AM
Subject: Re: intermittent eap authentication failure
> On Tue, 2011-01-18 at 09:54 -0500, Chuck Crisler wrote:
>> I will have to reply later about why it is associating. I will have to
>> add a
>> printk to my driver but I currently have 2 tests running and don't want
>> to
>> stop either.
>> It looks like it might be called by ieee80211_sta_work() in mlme.c
>> because
>> it might still be in the IEEE80211_STA_MLME_ASSOCIATE state. I will
>> confirm
>> that.
>
> Did you ever consider using compat-wireless? Frankly, my main memory
> isn't large enough to hold information about old mac80211 behaviour so I
> have to get that information from swap (git tree) and that's really
> slow :-)
>
> johannes
>
>
^ permalink raw reply
* Re: [PATCH v2] mac80211: drop non-auth 3-addr data frames when running as a 4-addr station
From: Felix Fietkau @ 2011-01-18 15:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linville
In-Reply-To: <1295362547.3563.22.camel@jlt3.sipsolutions.net>
On 2011-01-18 3:55 PM, Johannes Berg wrote:
> On Tue, 2011-01-18 at 15:48 +0100, Felix Fietkau wrote:
>> When running as a 4-addr station against an AP that has the 4-addr VLAN
>> interface and the main 3-addr AP interface bridged together, sometimes
>> frames originating from the station were looping back from the 3-addr AP
>> interface, causing the bridge code to emit warnings about receiving frames
>> with its own source address.
>> I'm not sure why this is happening yet, but I think it's a good idea to
>> drop all frames (except 802.1x/EAP frames) that do not match the configured
>> addressing mode, including 4-address frames sent to a 3-address station.
>> User test reports indicate that the problem goes away with this patch.
>
> This looks better, thanks. But did they really test _this_ patch? :)
A few users tested this and told me that it didn't make things worse
compared to my first patch - which did fix some, but not all issues
related to this.
- Felix
^ permalink raw reply
* Re: intermittent eap authentication failure
From: Johannes Berg @ 2011-01-18 14:57 UTC (permalink / raw)
To: Chuck Crisler; +Cc: linux-wireless
In-Reply-To: <1F9D19D1999A4D7885D0A4DD7BEBCEE8@ChuckPC>
On Tue, 2011-01-18 at 09:54 -0500, Chuck Crisler wrote:
> I will have to reply later about why it is associating. I will have to add a
> printk to my driver but I currently have 2 tests running and don't want to
> stop either.
> It looks like it might be called by ieee80211_sta_work() in mlme.c because
> it might still be in the IEEE80211_STA_MLME_ASSOCIATE state. I will confirm
> that.
Did you ever consider using compat-wireless? Frankly, my main memory
isn't large enough to hold information about old mac80211 behaviour so I
have to get that information from swap (git tree) and that's really
slow :-)
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: drop non-auth 3-addr data frames when running as a 4-addr station
From: Johannes Berg @ 2011-01-18 14:55 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville
In-Reply-To: <1295362128-2294-1-git-send-email-nbd@openwrt.org>
On Tue, 2011-01-18 at 15:48 +0100, Felix Fietkau wrote:
> When running as a 4-addr station against an AP that has the 4-addr VLAN
> interface and the main 3-addr AP interface bridged together, sometimes
> frames originating from the station were looping back from the 3-addr AP
> interface, causing the bridge code to emit warnings about receiving frames
> with its own source address.
> I'm not sure why this is happening yet, but I think it's a good idea to
> drop all frames (except 802.1x/EAP frames) that do not match the configured
> addressing mode, including 4-address frames sent to a 3-address station.
> User test reports indicate that the problem goes away with this patch.
This looks better, thanks. But did they really test _this_ patch? :)
johannes
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> ---
> net/mac80211/rx.c | 25 ++++++++++++++++++++++---
> 1 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index a6701ed..1236710 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -1556,17 +1556,36 @@ __ieee80211_data_to_8023(struct ieee80211_rx_data *rx)
> {
> struct ieee80211_sub_if_data *sdata = rx->sdata;
> struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)rx->skb->data;
> + bool check_port_control = false;
> + struct ethhdr *ehdr;
> + int ret;
>
> if (ieee80211_has_a4(hdr->frame_control) &&
> sdata->vif.type == NL80211_IFTYPE_AP_VLAN && !sdata->u.vlan.sta)
> return -1;
>
> + if (sdata->vif.type == NL80211_IFTYPE_STATION &&
> + !!sdata->u.mgd.use_4addr != !!ieee80211_has_a4(hdr->frame_control)) {
> +
> + if (!sdata->u.mgd.use_4addr)
> + return -1;
> + else
> + check_port_control = true;
> + }
> +
> if (is_multicast_ether_addr(hdr->addr1) &&
> - ((sdata->vif.type == NL80211_IFTYPE_AP_VLAN && sdata->u.vlan.sta) ||
> - (sdata->vif.type == NL80211_IFTYPE_STATION && sdata->u.mgd.use_4addr)))
> + sdata->vif.type == NL80211_IFTYPE_AP_VLAN && sdata->u.vlan.sta)
> return -1;
>
> - return ieee80211_data_to_8023(rx->skb, sdata->vif.addr, sdata->vif.type);
> + ret = ieee80211_data_to_8023(rx->skb, sdata->vif.addr, sdata->vif.type);
> + if (ret < 0 || !check_port_control)
> + return ret;
> +
> + ehdr = (struct ethhdr *) rx->skb->data;
> + if (ehdr->h_proto != rx->sdata->control_port_protocol)
> + return -1;
> +
> + return 0;
> }
>
> /*
^ permalink raw reply
* Re: intermittent eap authentication failure
From: Chuck Crisler @ 2011-01-18 14:54 UTC (permalink / raw)
To: Chuck Crisler, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <BB274B92115347F9A8E250DEF0C2B732@ChuckPC>
I will have to reply later about why it is associating. I will have to add a
printk to my driver but I currently have 2 tests running and don't want to
stop either.
It looks like it might be called by ieee80211_sta_work() in mlme.c because
it might still be in the IEEE80211_STA_MLME_ASSOCIATE state. I will confirm
that.
Chuck
----- Original Message -----
From: "Chuck Crisler" <ccrisler@vgocom.com>
To: "Johannes Berg" <johannes@sipsolutions.net>
Cc: <linux-wireless@vger.kernel.org>
Sent: Tuesday, January 18, 2011 9:33 AM
Subject: Re: intermittent eap authentication failure
> It is the MAC80211 code. I am looking to find the exact code that
> re-associates. We are running an old kernel (2.6.31.6) but can't update
> right now.
>
> Our app is a mobile video conferencing system (a robot). It is imperative
> that my connection to the network always be good. When you get a session
> timeout from the AP there isn't any reason to do a scan. The MAC driver
> can send the association request and then notify the supplicant when it
> receives the assosication response. The supplicant can then handle the
> higher layer authentication. With the minor supplicant change that I
> included earler this works with all authentication schemes. However, I
> have removed the 2 lines that dealt with setting the EAP authentication to
> NULL. I think that they were causing the EAP problems. The result is that
> now I re-connect after a session timeout withint 0.75 seconds.
>
> Another problem that I found is that sometimes (not often) the Cisco WLC
> was sending us a second deauthentication while we were still
> 'disconnected'. The MAC driver dutifully sent that to the supplicant which
> was busy trying to re-authenticate, again causing a mess. Now, I have
> changed the MAC driver to drop that second deauth message if we aren't
> connected. It works a lot better.
>
> The response that Daniel Halperin made to Larry Finger concerning the
> reason code 4 (inactivity) isn't correct. That may be the intent but Cisco
> sends that reason code more often. I have received it withint 3 seconds of
> receiving an association response. Again, not often but it does happen. I
> am currently working to understand why the Cisco WLC does this and have
> extensive logging enabled on my WLC. Unfortuantely, all of the failures
> are occurring after the WLC times out my putty session!
>
> More to come.
>
> ----- Original Message -----
> From: "Johannes Berg" <johannes@sipsolutions.net>
> To: "Chuck Crisler" <ccrisler@vgocom.com>
> Cc: <linux-wireless@vger.kernel.org>
> Sent: Tuesday, January 18, 2011 5:52 AM
> Subject: Re: intermittent eap authentication failure
>
>
>> Chuck,
>>
>>> Sometime ago I found a conflict between the supplicant and the MAC80211
>>> code
>>> dealing with Cisco session timeouts. When we were 'deauthenticated', the
>>> MAC
>>> code notified the supplicant AND re-associated with the AP.
>>
>> That doesn't seem right, mac80211 will never re-associate by itself.
>>
>>> We modified the driver so that if it received a
>>> de-auth with reason code 1 (undefined?), it would *NOT* notify the
>>> supplicant but would re-associate, then notify the supplicant of the new
>>> association.
>>
>> What's that driver you're talking about? A mac80211 driver that
>> reassociates by itself doesn't seem right at all.
>>
>> johannes
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 2.6.32.y] hostap_cs: fix sleeping function called from invalid context
From: Tim Gardner @ 2011-01-18 14:49 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: stable, Dominik Brodowski, linux-wireless
In-Reply-To: <1295269524-4937-1-git-send-email-sgruszka@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]
On 01/17/2011 06:05 AM, Stanislaw Gruszka wrote:
> commit 4e5518ca53be29c1ec3c00089c97bef36bfed515 upstream.
>
> pcmcia_request_irq() and pcmcia_enable_device() are intended
> to be called from process context (first function allocate memory
> with GFP_KERNEL, second take a mutex). We can not take spin lock
> and call them.
>
> It's safe to move spin lock after pcmcia_enable_device() as we
> still hold off IRQ until dev->base_addr is 0 and driver will
> not proceed with interrupts when is not ready.
>
> Patch resolves:
> https://bugzilla.redhat.com/show_bug.cgi?id=643758
>
> Reported-and-tested-by: rbugz@biobind.com
> Signed-off-by: Stanislaw Gruszka<sgruszka@redhat.com>
> ---
> drivers/net/wireless/hostap/hostap_cs.c | 10 ++--------
> 1 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/hostap/hostap_cs.c b/drivers/net/wireless/hostap/hostap_cs.c
> index b4ff1dc..6992f8f 100644
> --- a/drivers/net/wireless/hostap/hostap_cs.c
> +++ b/drivers/net/wireless/hostap/hostap_cs.c
> @@ -662,12 +662,6 @@ static int prism2_config(struct pcmcia_device *link)
> link->dev_node =&hw_priv->node;
>
> /*
> - * Make sure the IRQ handler cannot proceed until at least
> - * dev->base_addr is initialized.
> - */
> - spin_lock_irqsave(&local->irq_init_lock, flags);
> -
> - /*
> * Allocate an interrupt line. Note that this does not assign a
> * handler to the interrupt, unless the 'Handler' member of the
> * irq structure is initialized.
> @@ -690,9 +684,10 @@ static int prism2_config(struct pcmcia_device *link)
> CS_CHECK(RequestConfiguration,
> pcmcia_request_configuration(link,&link->conf));
>
> + /* IRQ handler cannot proceed until at dev->base_addr is initialized */
> + spin_lock_irqsave(&local->irq_init_lock, flags);
> dev->irq = link->irq.AssignedIRQ;
> dev->base_addr = link->io.BasePort1;
> -
> spin_unlock_irqrestore(&local->irq_init_lock, flags);
>
> /* Finally, report what we've done */
> @@ -724,7 +719,6 @@ static int prism2_config(struct pcmcia_device *link)
> return ret;
>
> cs_failed:
> - spin_unlock_irqrestore(&local->irq_init_lock, flags);
> cs_error(link, last_fn, last_ret);
>
> failed:
Yes - I think this patch is correct. I didn't drill deep enough to
notice the GFP_KERNEL memory allocation. However, I think there is still
a problem with the interrupt handler which will only be noticed if there
is another active device on the same shared interrupt. Shouldn't it
return IRQ_NONE? See attached.
rtg
--
Tim Gardner tim.gardner@canonical.com
[-- Attachment #2: 0001-hostap-Return-IRQ_NONE-if-the-device-has-not-been-co.patch --]
[-- Type: text/x-patch, Size: 888 bytes --]
>From 638d3ea93e2a9cccb860d9e31c84e5d3a3eb38bd Mon Sep 17 00:00:00 2001
From: Tim Gardner <tim.gardner@canonical.com>
Date: Tue, 18 Jan 2011 07:47:45 -0700
Subject: [PATCH] 2.6.32.y, hostap: Return IRQ_NONE if the device has not been configured
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
drivers/net/wireless/hostap/hostap_hw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_hw.c b/drivers/net/wireless/hostap/hostap_hw.c
index 8721850..789a503 100644
--- a/drivers/net/wireless/hostap/hostap_hw.c
+++ b/drivers/net/wireless/hostap/hostap_hw.c
@@ -2624,7 +2624,7 @@ static irqreturn_t prism2_interrupt(int irq, void *dev_id)
printk(KERN_DEBUG "%s: Interrupt, but dev not configured\n",
dev->name);
}
- return IRQ_HANDLED;
+ return IRQ_NONE;
}
iface = netdev_priv(dev);
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2] mac80211: drop non-auth 3-addr data frames when running as a 4-addr station
From: Felix Fietkau @ 2011-01-18 14:48 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, johannes
When running as a 4-addr station against an AP that has the 4-addr VLAN
interface and the main 3-addr AP interface bridged together, sometimes
frames originating from the station were looping back from the 3-addr AP
interface, causing the bridge code to emit warnings about receiving frames
with its own source address.
I'm not sure why this is happening yet, but I think it's a good idea to
drop all frames (except 802.1x/EAP frames) that do not match the configured
addressing mode, including 4-address frames sent to a 3-address station.
User test reports indicate that the problem goes away with this patch.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
net/mac80211/rx.c | 25 ++++++++++++++++++++++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index a6701ed..1236710 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1556,17 +1556,36 @@ __ieee80211_data_to_8023(struct ieee80211_rx_data *rx)
{
struct ieee80211_sub_if_data *sdata = rx->sdata;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)rx->skb->data;
+ bool check_port_control = false;
+ struct ethhdr *ehdr;
+ int ret;
if (ieee80211_has_a4(hdr->frame_control) &&
sdata->vif.type == NL80211_IFTYPE_AP_VLAN && !sdata->u.vlan.sta)
return -1;
+ if (sdata->vif.type == NL80211_IFTYPE_STATION &&
+ !!sdata->u.mgd.use_4addr != !!ieee80211_has_a4(hdr->frame_control)) {
+
+ if (!sdata->u.mgd.use_4addr)
+ return -1;
+ else
+ check_port_control = true;
+ }
+
if (is_multicast_ether_addr(hdr->addr1) &&
- ((sdata->vif.type == NL80211_IFTYPE_AP_VLAN && sdata->u.vlan.sta) ||
- (sdata->vif.type == NL80211_IFTYPE_STATION && sdata->u.mgd.use_4addr)))
+ sdata->vif.type == NL80211_IFTYPE_AP_VLAN && sdata->u.vlan.sta)
return -1;
- return ieee80211_data_to_8023(rx->skb, sdata->vif.addr, sdata->vif.type);
+ ret = ieee80211_data_to_8023(rx->skb, sdata->vif.addr, sdata->vif.type);
+ if (ret < 0 || !check_port_control)
+ return ret;
+
+ ehdr = (struct ethhdr *) rx->skb->data;
+ if (ehdr->h_proto != rx->sdata->control_port_protocol)
+ return -1;
+
+ return 0;
}
/*
--
1.7.3.2
^ permalink raw reply related
* Re: intermittent eap authentication failure
From: Chuck Crisler @ 2011-01-18 14:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1295347932.3563.13.camel@jlt3.sipsolutions.net>
It is the MAC80211 code. I am looking to find the exact code that
re-associates. We are running an old kernel (2.6.31.6) but can't update
right now.
Our app is a mobile video conferencing system (a robot). It is imperative
that my connection to the network always be good. When you get a session
timeout from the AP there isn't any reason to do a scan. The MAC driver can
send the association request and then notify the supplicant when it receives
the assosication response. The supplicant can then handle the higher layer
authentication. With the minor supplicant change that I included earler this
works with all authentication schemes. However, I have removed the 2 lines
that dealt with setting the EAP authentication to NULL. I think that they
were causing the EAP problems. The result is that now I re-connect after a
session timeout withint 0.75 seconds.
Another problem that I found is that sometimes (not often) the Cisco WLC was
sending us a second deauthentication while we were still 'disconnected'. The
MAC driver dutifully sent that to the supplicant which was busy trying to
re-authenticate, again causing a mess. Now, I have changed the MAC driver to
drop that second deauth message if we aren't connected. It works a lot
better.
The response that Daniel Halperin made to Larry Finger concerning the reason
code 4 (inactivity) isn't correct. That may be the intent but Cisco sends
that reason code more often. I have received it withint 3 seconds of
receiving an association response. Again, not often but it does happen. I am
currently working to understand why the Cisco WLC does this and have
extensive logging enabled on my WLC. Unfortuantely, all of the failures are
occurring after the WLC times out my putty session!
More to come.
----- Original Message -----
From: "Johannes Berg" <johannes@sipsolutions.net>
To: "Chuck Crisler" <ccrisler@vgocom.com>
Cc: <linux-wireless@vger.kernel.org>
Sent: Tuesday, January 18, 2011 5:52 AM
Subject: Re: intermittent eap authentication failure
> Chuck,
>
>> Sometime ago I found a conflict between the supplicant and the MAC80211
>> code
>> dealing with Cisco session timeouts. When we were 'deauthenticated', the
>> MAC
>> code notified the supplicant AND re-associated with the AP.
>
> That doesn't seem right, mac80211 will never re-associate by itself.
>
>> We modified the driver so that if it received a
>> de-auth with reason code 1 (undefined?), it would *NOT* notify the
>> supplicant but would re-associate, then notify the supplicant of the new
>> association.
>
> What's that driver you're talking about? A mac80211 driver that
> reassociates by itself doesn't seem right at all.
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 1/5] mac80211: add DFS related channel flags
From: Zefir Kurtisi @ 2011-01-18 14:29 UTC (permalink / raw)
To: Bernhard Schmidt
Cc: Johannes Berg, linux-wireless, lrodriguez, nbd, dubowoj,
simon.wunderlich
In-Reply-To: <201101181328.04540.bernhard.schmidt@saxnet.de>
On 01/18/2011 01:27 PM, Bernhard Schmidt wrote:
> On Tuesday, January 18, 2011 13:16:13 Johannes Berg wrote:
>> On Tue, 2011-01-18 at 12:59 +0100, Bernhard Schmidt wrote:
>>>> I'm not sure about this -- shouldn't that be global information?
>>>> If one device in the system records a radar on the channel, it
>>>> surely applies to other devices as well, even if they are
>>>> hot-plugged after the radar was found?
>>>
>>> True, I've based this on our IRC discussions, the consensus there
>>> was to do it per-wiphy only at first.
>>
>> I thought what we had discussed there (but I missed at least one
>> meeting) was that the *detector* state, for software-based detection,
>> should be per wiphy. I never heard anywhere that the result of that
>> should be local too.
>
> Hmm, ok, I might have got that wrong. We should discuss this today on
> IRC and whatever the consensus is, I will adjust the code.
>
We discussed that each wiphy needs to have its own pattern detector, due to a missing common time base for accurately time stamp the pulse events.
The channel states on the other hand should be system global, i.e. if one wiphy detected radars on some channel, that channel should not be used by other wiphys.
Ideally the state should be even regulatory specific to support pure radar scanning devices (johill already told that mac82011 does not support per wiphy multi-countrycode operation, but let's plan long term...)
Cheers
Zefir
^ permalink raw reply
* Re: [RFC] mac80211: reset connection poll on receiving unicast data frames
From: Rajkumar Manoharan @ 2011-01-18 14:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: Rajkumar Manoharan, linux-wireless@vger.kernel.org
In-Reply-To: <1295358680.3563.21.camel@jlt3.sipsolutions.net>
On Tue, Jan 18, 2011 at 07:21:20PM +0530, Johannes Berg wrote:
> On Tue, 2011-01-18 at 19:14 +0530, Rajkumar Manoharan wrote:
> > In noisy channel conditions, some APs do not reply to probe
> > requests which results in STA disconnection. It is perfectly
> > fine to reset the connection polling if unicast frames are
> > received from that AP properly.
>
> I'm not convinced. We often have no trouble hearing the AP but the AP
> isn't hearing us because sensitivity is different etc.
>
But it does affect data transmission. STA is continuously receiving
data from AP. So we can ensure that connection is still alive
based on unicast frame though STA is not hearing probe response.
--
Rajkumar
^ permalink raw reply
* Re: [RFC] mac80211: reset connection poll on receiving unicast data frames
From: Johannes Berg @ 2011-01-18 13:51 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: linux-wireless
In-Reply-To: <1295358285-9336-1-git-send-email-rmanoharan@atheros.com>
On Tue, 2011-01-18 at 19:14 +0530, Rajkumar Manoharan wrote:
> In noisy channel conditions, some APs do not reply to probe
> requests which results in STA disconnection. It is perfectly
> fine to reset the connection polling if unicast frames are
> received from that AP properly.
I'm not convinced. We often have no trouble hearing the AP but the AP
isn't hearing us because sensitivity is different etc.
johannes
^ permalink raw reply
* [RFC] mac80211: reset connection poll on receiving unicast data frames
From: Rajkumar Manoharan @ 2011-01-18 13:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Rajkumar Manoharan
In noisy channel conditions, some APs do not reply to probe
requests which results in STA disconnection. It is perfectly
fine to reset the connection polling if unicast frames are
received from that AP properly.
The reason behind to reset connection poll on unicast data
frames alone is that to preserve the PS recalculation on receiving
probe response.
This disconnection issue was reported with some buggy APs in noisy
environment, with the devices that does not support
IEEE80211_HW_REPORTS_TX_ACK_STATUS and running heavy downlink
unicast traffic from DS to STA. The probe response that was not
seen for the request sent followed by scan completion.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
---
net/mac80211/mlme.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 45fbb9e..03d6cfc 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -141,6 +141,7 @@ void ieee80211_sta_reset_conn_monitor(struct ieee80211_sub_if_data *sdata)
round_jiffies_up(jiffies + IEEE80211_CONNECTION_IDLE_TIME));
ifmgd->probe_send_count = 0;
+ ifmgd->flags &= ~IEEE80211_STA_CONNECTION_POLL;
}
static int ecw2cw(int ecw)
@@ -1033,7 +1034,8 @@ void ieee80211_sta_rx_notify(struct ieee80211_sub_if_data *sdata,
if (is_multicast_ether_addr(hdr->addr1))
return;
- ieee80211_sta_reset_conn_monitor(sdata);
+ if (ieee80211_is_data(hdr->frame_control))
+ ieee80211_sta_reset_conn_monitor(sdata);
}
static void ieee80211_reset_ap_probe(struct ieee80211_sub_if_data *sdata)
--
1.7.3.5
^ permalink raw reply related
* [PATCH] ath5k: fix locking in tx_complete_poll_work
From: Bob Copeland @ 2011-01-18 13:06 UTC (permalink / raw)
To: linville, jirislaby, mickflemm, lrodriguez, br1
Cc: linux-wireless, ath5k-devel, Bob Copeland
ath5k_reset must be called with sc->lock. Since the tx queue
watchdog runs in a workqueue and accesses sc, it's appropriate
to just take the lock over the whole function.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/base.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 019a74d..09ae4ef 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2294,6 +2294,8 @@ ath5k_tx_complete_poll_work(struct work_struct *work)
int i;
bool needreset = false;
+ mutex_lock(&sc->lock);
+
for (i = 0; i < ARRAY_SIZE(sc->txqs); i++) {
if (sc->txqs[i].setup) {
txq = &sc->txqs[i];
@@ -2321,6 +2323,8 @@ ath5k_tx_complete_poll_work(struct work_struct *work)
ath5k_reset(sc, NULL, true);
}
+ mutex_unlock(&sc->lock);
+
ieee80211_queue_delayed_work(sc->hw, &sc->tx_complete_work,
msecs_to_jiffies(ATH5K_TX_COMPLETE_POLL_INT));
}
--
1.7.1.1
^ permalink raw reply related
* [PATCH] mac80211: allow advertising correct maximum aggregate size
From: Johannes Berg @ 2011-01-18 12:52 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless@vger.kernel.org
From: Johannes Berg <johannes.berg@intel.com>
Currently, mac80211 always advertises that it may send
up to 64 subframes in an aggregate. This is fine, since
it's the max, but might as well be set to zero instead
since it doesn't have any information.
However, drivers might have that information, so allow
them to set a variable giving it, which will then be
used. The default of zero will be fine since to the
peer that means we don't know and it will just use its
own limit for the buffer size.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
This will apply only after Luca's patch
"mac80211: add hw configuration for max ampdu buffer size"
include/net/mac80211.h | 5 +++++
net/mac80211/agg-tx.c | 3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
--- wireless-testing.orig/include/net/mac80211.h 2011-01-18 13:49:49.000000000 +0100
+++ wireless-testing/include/net/mac80211.h 2011-01-18 13:50:20.000000000 +0100
@@ -1154,6 +1154,10 @@ enum ieee80211_hw_flags {
* This is only relevant if the device has restrictions on the
* number of subframes, if it relies on mac80211 to do reordering
* it shouldn't be set.
+ *
+ * @max_tx_aggregation_subframes: maximum number of subframes in an
+ * aggregate an HT driver will transmit, used by the peer as a
+ * hint to size its reorder buffer.
*/
struct ieee80211_hw {
struct ieee80211_conf conf;
@@ -1173,6 +1177,7 @@ struct ieee80211_hw {
u8 max_report_rates;
u8 max_rate_tries;
u8 max_rx_aggregation_subframes;
+ u8 max_tx_aggregation_subframes;
};
/**
--- wireless-testing.orig/net/mac80211/agg-tx.c 2011-01-18 13:49:49.000000000 +0100
+++ wireless-testing/net/mac80211/agg-tx.c 2011-01-18 13:50:20.000000000 +0100
@@ -342,7 +342,8 @@ void ieee80211_tx_ba_session_handle_star
/* send AddBA request */
ieee80211_send_addba_request(sdata, sta->sta.addr, tid,
tid_tx->dialog_token, start_seq_num,
- 0x40, tid_tx->timeout);
+ local->hw.max_tx_aggregation_subframes,
+ tid_tx->timeout);
}
int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid,
^ permalink raw reply
* [PATCH] mac80211: track receiver's aggregation reorder buffer size
From: Johannes Berg @ 2011-01-18 12:51 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless@vger.kernel.org
From: Johannes Berg <johannes.berg@intel.com>
The aggregation code currently doesn't implement the
buffer size negotiation. It will always request a max
buffer size (which is fine, if a little pointless, as
the mac80211 code doesn't know and might just use 0
instead), but if the peer requests a smaller size it
isn't possible to honour this request.
In order to fix this, look at the buffer size in the
addBA response frame, keep track of it and pass it to
the driver in the ampdu_action callback when called
with the IEEE80211_AMPDU_TX_OPERATIONAL action. That
way the driver can limit the number of subframes in
aggregates appropriately.
Note that this doesn't fix any drivers apart from the
addition of the new argument -- they all need to be
updated separately to use this variable!
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/ath/ar9170/main.c | 3 ++-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 2 +-
drivers/net/wireless/ath/carl9170/main.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 3 ++-
drivers/net/wireless/iwlwifi/iwl-agn.h | 3 ++-
drivers/net/wireless/mac80211_hwsim.c | 3 ++-
drivers/net/wireless/mwl8k.c | 3 ++-
drivers/net/wireless/rt2x00/rt2800lib.c | 3 ++-
drivers/net/wireless/rt2x00/rt2800lib.h | 3 ++-
drivers/net/wireless/rtlwifi/core.c | 3 ++-
include/net/mac80211.h | 7 ++++++-
net/mac80211/agg-rx.c | 4 ++--
net/mac80211/agg-tx.c | 20 +++++++++++++++++---
net/mac80211/driver-ops.h | 6 +++---
net/mac80211/driver-trace.h | 11 +++++++----
net/mac80211/sta_info.h | 2 ++
17 files changed, 56 insertions(+), 24 deletions(-)
--- wireless-testing.orig/include/net/mac80211.h 2011-01-18 13:46:47.000000000 +0100
+++ wireless-testing/include/net/mac80211.h 2011-01-18 13:50:21.000000000 +0100
@@ -1731,6 +1731,10 @@ enum ieee80211_ampdu_mlme_action {
* ieee80211_ampdu_mlme_action. Starting sequence number (@ssn)
* is the first frame we expect to perform the action on. Notice
* that TX/RX_STOP can pass NULL for this parameter.
+ * The @buf_size parameter is only valid when the action is set to
+ * %IEEE80211_AMPDU_TX_OPERATIONAL and indicates the peer's reorder
+ * buffer size (number of subframes) for this session -- aggregates
+ * containing more subframes than this may not be transmitted to the peer.
* Returns a negative error code on failure.
* The callback can sleep.
*
@@ -1833,7 +1837,8 @@ struct ieee80211_ops {
int (*ampdu_action)(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
enum ieee80211_ampdu_mlme_action action,
- struct ieee80211_sta *sta, u16 tid, u16 *ssn);
+ struct ieee80211_sta *sta, u16 tid, u16 *ssn,
+ u8 buf_size);
int (*get_survey)(struct ieee80211_hw *hw, int idx,
struct survey_info *survey);
void (*rfkill_poll)(struct ieee80211_hw *hw);
--- wireless-testing.orig/net/mac80211/agg-tx.c 2011-01-18 13:44:44.000000000 +0100
+++ wireless-testing/net/mac80211/agg-tx.c 2011-01-18 13:50:21.000000000 +0100
@@ -190,7 +190,7 @@ int ___ieee80211_stop_tx_ba_session(stru
ret = drv_ampdu_action(local, sta->sdata,
IEEE80211_AMPDU_TX_STOP,
- &sta->sta, tid, NULL);
+ &sta->sta, tid, NULL, 0);
/* HW shall not deny going back to legacy */
if (WARN_ON(ret)) {
@@ -311,7 +311,7 @@ void ieee80211_tx_ba_session_handle_star
start_seq_num = sta->tid_seq[tid] >> 4;
ret = drv_ampdu_action(local, sdata, IEEE80211_AMPDU_TX_START,
- &sta->sta, tid, &start_seq_num);
+ &sta->sta, tid, &start_seq_num, 0);
if (ret) {
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "BA request denied - HW unavailable for"
@@ -487,7 +487,8 @@ static void ieee80211_agg_tx_operational
drv_ampdu_action(local, sta->sdata,
IEEE80211_AMPDU_TX_OPERATIONAL,
- &sta->sta, tid, NULL);
+ &sta->sta, tid, NULL,
+ sta->ampdu_mlme.tid_tx[tid]->buf_size);
/*
* synchronize with TX path, while splicing the TX path
@@ -742,9 +743,11 @@ void ieee80211_process_addba_resp(struct
{
struct tid_ampdu_tx *tid_tx;
u16 capab, tid;
+ u8 buf_size;
capab = le16_to_cpu(mgmt->u.action.u.addba_resp.capab);
tid = (capab & IEEE80211_ADDBA_PARAM_TID_MASK) >> 2;
+ buf_size = (capab & IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK) >> 6;
mutex_lock(&sta->ampdu_mlme.mtx);
@@ -767,12 +770,23 @@ void ieee80211_process_addba_resp(struct
if (le16_to_cpu(mgmt->u.action.u.addba_resp.status)
== WLAN_STATUS_SUCCESS) {
+ /*
+ * IEEE 802.11-2007 7.3.1.14:
+ * In an ADDBA Response frame, when the Status Code field
+ * is set to 0, the Buffer Size subfield is set to a value
+ * of at least 1.
+ */
+ if (!buf_size)
+ goto out;
+
if (test_and_set_bit(HT_AGG_STATE_RESPONSE_RECEIVED,
&tid_tx->state)) {
/* ignore duplicate response */
goto out;
}
+ tid_tx->buf_size = buf_size;
+
if (test_bit(HT_AGG_STATE_DRV_READY, &tid_tx->state))
ieee80211_agg_tx_operational(local, sta, tid);
--- wireless-testing.orig/net/mac80211/sta_info.h 2011-01-18 13:44:44.000000000 +0100
+++ wireless-testing/net/mac80211/sta_info.h 2011-01-18 13:48:49.000000000 +0100
@@ -82,6 +82,7 @@ enum ieee80211_sta_info_flags {
* @state: session state (see above)
* @stop_initiator: initiator of a session stop
* @tx_stop: TX DelBA frame when stopping
+ * @buf_size: reorder buffer size at receiver
*
* This structure's lifetime is managed by RCU, assignments to
* the array holding it must hold the aggregation mutex.
@@ -101,6 +102,7 @@ struct tid_ampdu_tx {
u8 dialog_token;
u8 stop_initiator;
bool tx_stop;
+ u8 buf_size;
};
/**
--- wireless-testing.orig/net/mac80211/agg-rx.c 2011-01-18 13:46:47.000000000 +0100
+++ wireless-testing/net/mac80211/agg-rx.c 2011-01-18 13:48:49.000000000 +0100
@@ -76,7 +76,7 @@ void ___ieee80211_stop_rx_ba_session(str
#endif /* CONFIG_MAC80211_HT_DEBUG */
if (drv_ampdu_action(local, sta->sdata, IEEE80211_AMPDU_RX_STOP,
- &sta->sta, tid, NULL))
+ &sta->sta, tid, NULL, 0))
printk(KERN_DEBUG "HW problem - can not stop rx "
"aggregation for tid %d\n", tid);
@@ -290,7 +290,7 @@ void ieee80211_process_addba_request(str
}
ret = drv_ampdu_action(local, sta->sdata, IEEE80211_AMPDU_RX_START,
- &sta->sta, tid, &start_seq_num);
+ &sta->sta, tid, &start_seq_num, 0);
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "Rx A-MPDU request on tid %d result %d\n", tid, ret);
#endif /* CONFIG_MAC80211_HT_DEBUG */
--- wireless-testing.orig/net/mac80211/driver-ops.h 2011-01-18 13:44:44.000000000 +0100
+++ wireless-testing/net/mac80211/driver-ops.h 2011-01-18 13:48:49.000000000 +0100
@@ -382,17 +382,17 @@ static inline int drv_ampdu_action(struc
struct ieee80211_sub_if_data *sdata,
enum ieee80211_ampdu_mlme_action action,
struct ieee80211_sta *sta, u16 tid,
- u16 *ssn)
+ u16 *ssn, u8 buf_size)
{
int ret = -EOPNOTSUPP;
might_sleep();
- trace_drv_ampdu_action(local, sdata, action, sta, tid, ssn);
+ trace_drv_ampdu_action(local, sdata, action, sta, tid, ssn, buf_size);
if (local->ops->ampdu_action)
ret = local->ops->ampdu_action(&local->hw, &sdata->vif, action,
- sta, tid, ssn);
+ sta, tid, ssn, buf_size);
trace_drv_return_int(local, ret);
--- wireless-testing.orig/net/mac80211/driver-trace.h 2011-01-18 13:44:44.000000000 +0100
+++ wireless-testing/net/mac80211/driver-trace.h 2011-01-18 13:48:49.000000000 +0100
@@ -784,9 +784,9 @@ TRACE_EVENT(drv_ampdu_action,
struct ieee80211_sub_if_data *sdata,
enum ieee80211_ampdu_mlme_action action,
struct ieee80211_sta *sta, u16 tid,
- u16 *ssn),
+ u16 *ssn, u8 buf_size),
- TP_ARGS(local, sdata, action, sta, tid, ssn),
+ TP_ARGS(local, sdata, action, sta, tid, ssn, buf_size),
TP_STRUCT__entry(
LOCAL_ENTRY
@@ -794,6 +794,7 @@ TRACE_EVENT(drv_ampdu_action,
__field(u32, action)
__field(u16, tid)
__field(u16, ssn)
+ __field(u8, buf_size)
VIF_ENTRY
),
@@ -804,11 +805,13 @@ TRACE_EVENT(drv_ampdu_action,
__entry->action = action;
__entry->tid = tid;
__entry->ssn = ssn ? *ssn : 0;
+ __entry->buf_size = buf_size;
),
TP_printk(
- LOCAL_PR_FMT VIF_PR_FMT STA_PR_FMT " action:%d tid:%d",
- LOCAL_PR_ARG, VIF_PR_ARG, STA_PR_ARG, __entry->action, __entry->tid
+ LOCAL_PR_FMT VIF_PR_FMT STA_PR_FMT " action:%d tid:%d buf:%d",
+ LOCAL_PR_ARG, VIF_PR_ARG, STA_PR_ARG, __entry->action,
+ __entry->tid, __entry->buf_size
)
);
--- wireless-testing.orig/drivers/net/wireless/ath/ar9170/main.c 2011-01-18 13:44:45.000000000 +0100
+++ wireless-testing/drivers/net/wireless/ath/ar9170/main.c 2011-01-18 13:48:49.000000000 +0100
@@ -1945,7 +1945,8 @@ static int ar9170_conf_tx(struct ieee802
static int ar9170_ampdu_action(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
enum ieee80211_ampdu_mlme_action action,
- struct ieee80211_sta *sta, u16 tid, u16 *ssn)
+ struct ieee80211_sta *sta, u16 tid, u16 *ssn,
+ u8 buf_size)
{
switch (action) {
case IEEE80211_AMPDU_RX_START:
--- wireless-testing.orig/drivers/net/wireless/ath/ath9k/htc_drv_main.c 2011-01-18 13:44:45.000000000 +0100
+++ wireless-testing/drivers/net/wireless/ath/ath9k/htc_drv_main.c 2011-01-18 13:48:49.000000000 +0100
@@ -1548,7 +1548,7 @@ static int ath9k_htc_ampdu_action(struct
struct ieee80211_vif *vif,
enum ieee80211_ampdu_mlme_action action,
struct ieee80211_sta *sta,
- u16 tid, u16 *ssn)
+ u16 tid, u16 *ssn, u8 buf_size)
{
struct ath9k_htc_priv *priv = hw->priv;
struct ath9k_htc_sta *ista;
--- wireless-testing.orig/drivers/net/wireless/ath/ath9k/main.c 2011-01-18 13:44:45.000000000 +0100
+++ wireless-testing/drivers/net/wireless/ath/ath9k/main.c 2011-01-18 13:48:49.000000000 +0100
@@ -2029,7 +2029,7 @@ static int ath9k_ampdu_action(struct iee
struct ieee80211_vif *vif,
enum ieee80211_ampdu_mlme_action action,
struct ieee80211_sta *sta,
- u16 tid, u16 *ssn)
+ u16 tid, u16 *ssn, u8 buf_size)
{
struct ath_wiphy *aphy = hw->priv;
struct ath_softc *sc = aphy->sc;
--- wireless-testing.orig/drivers/net/wireless/ath/carl9170/main.c 2011-01-18 13:44:45.000000000 +0100
+++ wireless-testing/drivers/net/wireless/ath/carl9170/main.c 2011-01-18 13:48:49.000000000 +0100
@@ -1279,7 +1279,7 @@ static int carl9170_op_ampdu_action(stru
struct ieee80211_vif *vif,
enum ieee80211_ampdu_mlme_action action,
struct ieee80211_sta *sta,
- u16 tid, u16 *ssn)
+ u16 tid, u16 *ssn, u8 buf_size)
{
struct ar9170 *ar = hw->priv;
struct carl9170_sta_info *sta_info = (void *) sta->drv_priv;
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-agn.c 2011-01-18 13:46:37.000000000 +0100
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-agn.c 2011-01-18 13:50:22.000000000 +0100
@@ -3425,7 +3425,8 @@ int iwlagn_mac_set_key(struct ieee80211_
int iwlagn_mac_ampdu_action(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
enum ieee80211_ampdu_mlme_action action,
- struct ieee80211_sta *sta, u16 tid, u16 *ssn)
+ struct ieee80211_sta *sta, u16 tid, u16 *ssn,
+ u8 buf_size)
{
struct iwl_priv *priv = hw->priv;
int ret = -EINVAL;
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-agn.h 2011-01-18 13:44:45.000000000 +0100
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-agn.h 2011-01-18 13:48:49.000000000 +0100
@@ -374,7 +374,8 @@ void iwlagn_mac_update_tkip_key(struct i
int iwlagn_mac_ampdu_action(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
enum ieee80211_ampdu_mlme_action action,
- struct ieee80211_sta *sta, u16 tid, u16 *ssn);
+ struct ieee80211_sta *sta, u16 tid, u16 *ssn,
+ u8 buf_size);
int iwlagn_mac_sta_add(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_sta *sta);
--- wireless-testing.orig/drivers/net/wireless/mac80211_hwsim.c 2011-01-18 13:44:45.000000000 +0100
+++ wireless-testing/drivers/net/wireless/mac80211_hwsim.c 2011-01-18 13:48:49.000000000 +0100
@@ -943,7 +943,8 @@ static int mac80211_hwsim_testmode_cmd(s
static int mac80211_hwsim_ampdu_action(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
enum ieee80211_ampdu_mlme_action action,
- struct ieee80211_sta *sta, u16 tid, u16 *ssn)
+ struct ieee80211_sta *sta, u16 tid, u16 *ssn,
+ u8 buf_size)
{
switch (action) {
case IEEE80211_AMPDU_TX_START:
--- wireless-testing.orig/drivers/net/wireless/mwl8k.c 2011-01-18 13:44:45.000000000 +0100
+++ wireless-testing/drivers/net/wireless/mwl8k.c 2011-01-18 13:48:49.000000000 +0100
@@ -4356,7 +4356,8 @@ static int mwl8k_get_survey(struct ieee8
static int
mwl8k_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
enum ieee80211_ampdu_mlme_action action,
- struct ieee80211_sta *sta, u16 tid, u16 *ssn)
+ struct ieee80211_sta *sta, u16 tid, u16 *ssn,
+ u8 buf_size)
{
switch (action) {
case IEEE80211_AMPDU_RX_START:
--- wireless-testing.orig/drivers/net/wireless/rt2x00/rt2800lib.c 2011-01-18 13:44:45.000000000 +0100
+++ wireless-testing/drivers/net/wireless/rt2x00/rt2800lib.c 2011-01-18 13:48:49.000000000 +0100
@@ -3533,7 +3533,8 @@ EXPORT_SYMBOL_GPL(rt2800_get_tsf);
int rt2800_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
enum ieee80211_ampdu_mlme_action action,
- struct ieee80211_sta *sta, u16 tid, u16 *ssn)
+ struct ieee80211_sta *sta, u16 tid, u16 *ssn,
+ u8 buf_size)
{
int ret = 0;
--- wireless-testing.orig/drivers/net/wireless/rt2x00/rt2800lib.h 2011-01-18 13:44:45.000000000 +0100
+++ wireless-testing/drivers/net/wireless/rt2x00/rt2800lib.h 2011-01-18 13:48:49.000000000 +0100
@@ -198,7 +198,8 @@ int rt2800_conf_tx(struct ieee80211_hw *
u64 rt2800_get_tsf(struct ieee80211_hw *hw);
int rt2800_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
enum ieee80211_ampdu_mlme_action action,
- struct ieee80211_sta *sta, u16 tid, u16 *ssn);
+ struct ieee80211_sta *sta, u16 tid, u16 *ssn,
+ u8 buf_size);
int rt2800_get_survey(struct ieee80211_hw *hw, int idx,
struct survey_info *survey);
--- wireless-testing.orig/drivers/net/wireless/rtlwifi/core.c 2011-01-18 13:44:45.000000000 +0100
+++ wireless-testing/drivers/net/wireless/rtlwifi/core.c 2011-01-18 13:48:49.000000000 +0100
@@ -748,7 +748,8 @@ static void rtl_op_sta_notify(struct iee
static int rtl_op_ampdu_action(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
enum ieee80211_ampdu_mlme_action action,
- struct ieee80211_sta *sta, u16 tid, u16 * ssn)
+ struct ieee80211_sta *sta, u16 tid, u16 *ssn,
+ u8 buf_size)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
^ permalink raw reply
* [PATCH] mac80211: don't return beacons when mesh is disabled
From: Johannes Berg @ 2011-01-18 12:45 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless@vger.kernel.org
From: Johannes Berg <johannes.berg@intel.com>
When mesh is disabled, mac80211 was returning
beacons with an empty mesh ID. That isn't
desirable, even if drivers shouldn't be trying
to get beacons to start with.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/tx.c | 5 +++++
1 file changed, 5 insertions(+)
--- wireless-testing.orig/net/mac80211/tx.c 2011-01-13 12:07:19.000000000 +0100
+++ wireless-testing/net/mac80211/tx.c 2011-01-13 12:07:26.000000000 +0100
@@ -2299,6 +2299,11 @@ struct sk_buff *ieee80211_beacon_get_tim
struct ieee80211_mgmt *mgmt;
u8 *pos;
+#ifdef CONFIG_MAC80211_MESH
+ if (!sdata->u.mesh.mesh_id_len)
+ goto out;
+#endif
+
/* headroom, head length, tail length and maximum TIM length */
skb = dev_alloc_skb(local->tx_headroom + 400 +
sdata->u.mesh.vendor_ie_len);
^ permalink raw reply
* Re: [PATCH 4/5] mac80211: add primarily CAC support
From: Bernhard Schmidt @ 2011-01-18 12:28 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, lrodriguez, nbd, dubowoj, zefir.kurtisi,
simon.wunderlich
In-Reply-To: <1295352740.3563.14.camel@jlt3.sipsolutions.net>
On Tuesday, January 18, 2011 13:12:20 Johannes Berg wrote:
> On Tue, 2011-01-18 at 13:01 +0100, Bernhard Schmidt wrote:
> > > > + mutex_lock(&radar->mtx);
> > >
> > > Clearly, you haven't even tested this code. I'm not sure why I'm
> > > even reviewing it.
> >
> > Granted, I did only some basic tests with only a few predefined
> > scenarios, not at all is just wrong. Anyways, I should have
> > mentioned in 0/13 that preventing channel changes while in CAC
> > should be considered and chan should be assigned to local variable
> > then.
>
> I was more referring to the fact that you're trying to lock a mutex
> in a timer -- so you can't have executed this code path ever?!
I'm running it right now, the code path *is* executed, what am I missing
here?
--
Best regards,
Dipl.-Inf. (FH) Bernhard Schmidt (software development)
saxnet GmbH, Willy-Brandt-Ring 1, 08606 Oelsnitz
Tel. +49 (0) 3741 300 6. 100 - Fax +49 (0) 3741 300 6. 101
managing director: Steffen Dreise - county court Chemnitz - HRB 23017
http://www.saxnet.de
^ 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