* Re: [PATCH v4 2/2] mac80211: Support ht-cap over-rides.
From: Johannes Berg @ 2011-11-07 17:06 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4EB8051D.5010704@candelatech.com>
On Mon, 2011-11-07 at 08:19 -0800, Ben Greear wrote:
> > Why is this not just a static const that you fill manually? There's
> > nothing that's not constant here. So e.g.
> >
> > static const struct ieee80211_ht_cap mac80211_ht_capa_mod_mask = {
> > .ampdu_params_info = IEEE80211_HT_AMPDU_PARM_FACTOR |
> > IEEE80211_HT_AMPDU_PARM_DENSITY,
> > .mcs = {
> > .rx_mask = { 0xff, 0xff, 0xff, 0xff, 0xff,
> > 0xff, 0xff, 0xff, 0xff, 0xff, },
> > },
> > /* etc */
> > };
>
> Well, you suggested a pointer in the wiphy struct that was null
> for non mac80211 interfaces. I'm not sure how to distinguish between
> mac80211 and other wiphys when reporting the capabilities if I use
> this global static. I also like that the non-static logic lets
> us tweak this for individual drivers if that becomes an issue.
Right. So if you assign this pointer in alloc_hw() then the driver can
still override it before register_hw(). I don't see at all why it needs
to be dynamically allocated.
johannes
^ permalink raw reply
* Re: [PATCH v4 1/2] wireless: Support ht-capabilities over-rides.
From: Johannes Berg @ 2011-11-07 17:02 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4EB806D7.6050104@candelatech.com>
On Mon, 2011-11-07 at 08:27 -0800, Ben Greear wrote:
> >> + kfree(rdev->wiphy.ht_capa_mod_mask);
> >> + rdev->wiphy.ht_capa_mod_mask = NULL;
> >
> > That doesn't seem right -- drivers should typically assign a static
> > const variable to this pointer that can't be freed.
>
> Earlier I think you argued that all of mac80211 drivers automatically supported
> these features as long as I put in the limitations that certain values
> could only be increased and certain only decreased, etc.
>
> So, I put it in the mac80211 code instead of down in the drivers.
> But, I can move it into ath9k if you prefer.
Err, no -- if I'm talking about "drivers" from cfg80211's point of view,
mac80211 is one of those "drivers"! This comment was only about the
weird way of freeing it and static const etc.
johannes
^ permalink raw reply
* Re: [PATCH v4 1/2] wireless: Support ht-capabilities over-rides.
From: Ben Greear @ 2011-11-07 16:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1320656776.3993.21.camel@jlt3.sipsolutions.net>
On 11/07/2011 01:06 AM, Johannes Berg wrote:
> On Fri, 2011-11-04 at 13:10 -0700, greearb@candelatech.com wrote:
>
>> + * @NL80211_ATTR_DISABLE_HT: Force HT capable interfaces to disable
>> + * this feature.
>
> I can see this, but
>
>> + * @NL80211_ATTR_DISABLE_HT40: Disable HT-40 even if AP and hardware
>> + * support it.
>> + * @NL80211_ATTR_HT_CAPABILITY_MASK: Specify which bits of the HT_CAPs
>> + * to pay attention to.
>
> if you have the mask why do you still need the HT40? Isn't HT40 a flag
> in the mask? Or do you want this to affect TX/RX separately? You should
> spell that out more explicitly then.
I think it would work to just use the mask & ht-cap overrides to disable HT40.
I'll see if I can get that working properly.
>
>> --- a/net/wireless/core.c
>> +++ b/net/wireless/core.c
>> @@ -704,6 +704,9 @@ void wiphy_unregister(struct wiphy *wiphy)
>> flush_work(&rdev->scan_done_wk);
>> cancel_work_sync(&rdev->conn_work);
>> flush_work(&rdev->event_work);
>> +
>> + kfree(rdev->wiphy.ht_capa_mod_mask);
>> + rdev->wiphy.ht_capa_mod_mask = NULL;
>
> That doesn't seem right -- drivers should typically assign a static
> const variable to this pointer that can't be freed.
Earlier I think you argued that all of mac80211 drivers automatically supported
these features as long as I put in the limitations that certain values
could only be increased and certain only decreased, etc.
So, I put it in the mac80211 code instead of down in the drivers.
But, I can move it into ath9k if you prefer.
>> @@ -537,6 +539,12 @@ int __cfg80211_mlme_assoc(struct cfg80211_registered_device *rdev,
>> memcpy(&req.crypto, crypt, sizeof(req.crypto));
>> req.use_mfp = use_mfp;
>> req.prev_bssid = prev_bssid;
>> + req.flags = assoc_flags;
>> + if (ht_capa)
>> + memcpy(&req.ht_capa, ht_capa, sizeof(req.ht_capa));
>> + if (ht_capa_mask)
>> + memcpy(&req.ht_capa_mask, ht_capa_mask,
>> + sizeof(req.ht_capa_mask));
>
> I think somewhere here you should mask this mask with the
> ht_capa_mod_mask. That way, you force drivers to advertise a correct
> ht_capa_mod_mask, if you don't do that we will certainly see drivers use
> more of ht_capa than contained in ht_capa_mod_mask. Probably should be a
> helper function since I think you might need it in more places.
Sure, I can add that.
Thanks,
Ben
>
> johannes
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v4 2/2] mac80211: Support ht-cap over-rides.
From: Ben Greear @ 2011-11-07 16:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1320657208.3993.29.camel@jlt3.sipsolutions.net>
On 11/07/2011 01:13 AM, Johannes Berg wrote:
> On Fri, 2011-11-04 at 13:10 -0700, greearb@candelatech.com wrote:
>
>> +/*
>> + * Stations supporting 802.11n are required to support
>> + * at least the first 8 MCS rates. See section 7.3.2.56.4
>> + * and 20.1.1 of the 802.11n spec.
>> + */
>> +#define IEEE80211_HT_MCS_REQ_RATES_STA 8
>
> I'd prefer if this was a validation on the input from userspace directly
> in cfg80211, that way other drivers that want to implement this don't
> have to bother.
>
> That probably goes well with the validation of the supported mask that I
> asked for.
It is valid to request that the station use a lesser rate, it just
needs to advertise that it supports the first 8 rates. So, for the
rate-control logic, we use exactly what is passed in from user-space,
but when generating the HT-caps objects, we set a minimum of 8 MCS
rates.
So, if you want validation, then I'm going to have to add a second
mcs argument and mask to distinguish between what we should advertise
v/s what we should use to over-ride the local rate-control mechanism.
I will do this if you ask, but in my opinion, the current functionality
is good enough.
>> + /* mac80211 allows over-riding some of the ht-capabilities */
>> + local->hw.wiphy->ht_capa_mod_mask =
>> + kzalloc(sizeof(*local->hw.wiphy->ht_capa_mod_mask),
>> + GFP_KERNEL);
>> + if (local->hw.wiphy->ht_capa_mod_mask) {
>> + struct ieee80211_ht_cap *cm = local->hw.wiphy->ht_capa_mod_mask;
>> + u8 *r = (u8 *)(&cm->mcs.rx_mask);
>> + memset(r, 0xff, IEEE80211_HT_MCS_MASK_LEN);
>> + cm->cap_info |= IEEE80211_HT_CAP_MAX_AMSDU;
>> + cm->ampdu_params_info |= IEEE80211_HT_AMPDU_PARM_FACTOR;
>> + cm->ampdu_params_info |= IEEE80211_HT_AMPDU_PARM_DENSITY;
>> + }
>
> Why is this not just a static const that you fill manually? There's
> nothing that's not constant here. So e.g.
>
> static const struct ieee80211_ht_cap mac80211_ht_capa_mod_mask = {
> .ampdu_params_info = IEEE80211_HT_AMPDU_PARM_FACTOR |
> IEEE80211_HT_AMPDU_PARM_DENSITY,
> .mcs = {
> .rx_mask = { 0xff, 0xff, 0xff, 0xff, 0xff,
> 0xff, 0xff, 0xff, 0xff, 0xff, },
> },
> /* etc */
> };
Well, you suggested a pointer in the wiphy struct that was null
for non mac80211 interfaces. I'm not sure how to distinguish between
mac80211 and other wiphys when reporting the capabilities if I use
this global static. I also like that the non-static logic lets
us tweak this for individual drivers if that becomes an issue.
>> @@ -988,6 +1001,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
>> fail_wiphy_register:
>> if (local->wiphy_ciphers_allocated)
>> kfree(local->hw.wiphy->cipher_suites);
>> + kfree(local->hw.wiphy->ht_capa_mod_mask);
>> + local->hw.wiphy->ht_capa_mod_mask = NULL;
>
> No need for this then obviously.
>
>
> Looks pretty good overall. This is _much_ more readable than the
> previous series. :-)
Thanks...making progress :)
Ben
>
> johannes
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2] mac80211: disassociate when direct probe timed out
From: Johannes Berg @ 2011-11-07 16:05 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: John W. Linville, linux-wireless, Lukasz Jagiello
In-Reply-To: <20111107160058.GC5990@redhat.com>
On Mon, 2011-11-07 at 17:00 +0100, Stanislaw Gruszka wrote:
> On Mon, Nov 07, 2011 at 04:43:22PM +0100, Johannes Berg wrote:
> > On Mon, 2011-11-07 at 16:42 +0100, Johannes Berg wrote:
> > > On Mon, 2011-11-07 at 16:34 +0100, Stanislaw Gruszka wrote:
> > >
> > > > +++ b/net/mac80211/mlme.c
> > > > @@ -2379,8 +2379,14 @@ ieee80211_probe_auth_done(struct ieee80211_work *wk,
> > > > struct sk_buff *skb)
> > > > {
> > > > struct ieee80211_local *local = wk->sdata->local;
> > > > + struct ieee80211_if_managed *ifmgd = &wk->sdata->u.mgd;
> > > >
> > > > if (!skb) {
> > > > + mutex_lock(&ifmgd->mtx);
> > > > + if (ifmgd->associated)
> > > > + ieee80211_set_disassoc(wk->sdata, true, false);
> > > > + mutex_unlock(&ifmgd->mtx);
> > > > +
> > > > cfg80211_send_auth_timeout(wk->sdata->dev, wk->filter_ta);
> > > > goto destroy;
> > > > }
> > >
> > > This doesn't seem right -- we can authenticate with a new AP while
> > > connected to an old one, but if the connection to the new one fails why
> > > should we tear down the connection to the *old* one?
> >
> > Also, we should never be able to get into a situation where the new AP
> > is the same as the old AP as cfg80211 won't let you authenticate with a
> > BSS that you're connected to (I believe).
>
> Oh, I see. So this problem happens with roaming, and we are doing something
> wrong with channels switching. Johannes, do you have idea how to
> possibly fix that? Here is full dmesg from Lukasz with warnings:
> http://bugzilla.redhat.com/attachment.cgi?id=523540
I think I'll just have to set up this scenario in mac80211_hwsim. It
must be related to the work.c channel stuff.
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: disassociate when direct probe timed out
From: Stanislaw Gruszka @ 2011-11-07 16:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, linux-wireless, Lukasz Jagiello
In-Reply-To: <1320680602.3993.47.camel@jlt3.sipsolutions.net>
On Mon, Nov 07, 2011 at 04:43:22PM +0100, Johannes Berg wrote:
> On Mon, 2011-11-07 at 16:42 +0100, Johannes Berg wrote:
> > On Mon, 2011-11-07 at 16:34 +0100, Stanislaw Gruszka wrote:
> >
> > > +++ b/net/mac80211/mlme.c
> > > @@ -2379,8 +2379,14 @@ ieee80211_probe_auth_done(struct ieee80211_work *wk,
> > > struct sk_buff *skb)
> > > {
> > > struct ieee80211_local *local = wk->sdata->local;
> > > + struct ieee80211_if_managed *ifmgd = &wk->sdata->u.mgd;
> > >
> > > if (!skb) {
> > > + mutex_lock(&ifmgd->mtx);
> > > + if (ifmgd->associated)
> > > + ieee80211_set_disassoc(wk->sdata, true, false);
> > > + mutex_unlock(&ifmgd->mtx);
> > > +
> > > cfg80211_send_auth_timeout(wk->sdata->dev, wk->filter_ta);
> > > goto destroy;
> > > }
> >
> > This doesn't seem right -- we can authenticate with a new AP while
> > connected to an old one, but if the connection to the new one fails why
> > should we tear down the connection to the *old* one?
>
> Also, we should never be able to get into a situation where the new AP
> is the same as the old AP as cfg80211 won't let you authenticate with a
> BSS that you're connected to (I believe).
Oh, I see. So this problem happens with roaming, and we are doing something
wrong with channels switching. Johannes, do you have idea how to
possibly fix that? Here is full dmesg from Lukasz with warnings:
http://bugzilla.redhat.com/attachment.cgi?id=523540
Stanislaw
^ permalink raw reply
* Re: [PATCH v2] mac80211: disassociate when direct probe timed out
From: Johannes Berg @ 2011-11-07 15:43 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: John W. Linville, linux-wireless, Lukasz Jagiello
In-Reply-To: <1320680552.3993.46.camel@jlt3.sipsolutions.net>
On Mon, 2011-11-07 at 16:42 +0100, Johannes Berg wrote:
> On Mon, 2011-11-07 at 16:34 +0100, Stanislaw Gruszka wrote:
>
> > +++ b/net/mac80211/mlme.c
> > @@ -2379,8 +2379,14 @@ ieee80211_probe_auth_done(struct ieee80211_work *wk,
> > struct sk_buff *skb)
> > {
> > struct ieee80211_local *local = wk->sdata->local;
> > + struct ieee80211_if_managed *ifmgd = &wk->sdata->u.mgd;
> >
> > if (!skb) {
> > + mutex_lock(&ifmgd->mtx);
> > + if (ifmgd->associated)
> > + ieee80211_set_disassoc(wk->sdata, true, false);
> > + mutex_unlock(&ifmgd->mtx);
> > +
> > cfg80211_send_auth_timeout(wk->sdata->dev, wk->filter_ta);
> > goto destroy;
> > }
>
> This doesn't seem right -- we can authenticate with a new AP while
> connected to an old one, but if the connection to the new one fails why
> should we tear down the connection to the *old* one?
Also, we should never be able to get into a situation where the new AP
is the same as the old AP as cfg80211 won't let you authenticate with a
BSS that you're connected to (I believe).
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: disassociate when direct probe timed out
From: Johannes Berg @ 2011-11-07 15:42 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: John W. Linville, linux-wireless, Lukasz Jagiello
In-Reply-To: <20111107153410.GB5990@redhat.com>
On Mon, 2011-11-07 at 16:34 +0100, Stanislaw Gruszka wrote:
> +++ b/net/mac80211/mlme.c
> @@ -2379,8 +2379,14 @@ ieee80211_probe_auth_done(struct ieee80211_work *wk,
> struct sk_buff *skb)
> {
> struct ieee80211_local *local = wk->sdata->local;
> + struct ieee80211_if_managed *ifmgd = &wk->sdata->u.mgd;
>
> if (!skb) {
> + mutex_lock(&ifmgd->mtx);
> + if (ifmgd->associated)
> + ieee80211_set_disassoc(wk->sdata, true, false);
> + mutex_unlock(&ifmgd->mtx);
> +
> cfg80211_send_auth_timeout(wk->sdata->dev, wk->filter_ta);
> goto destroy;
> }
This doesn't seem right -- we can authenticate with a new AP while
connected to an old one, but if the connection to the new one fails why
should we tear down the connection to the *old* one?
johannes
^ permalink raw reply
* Re: ifconfig down and mac80211 issue
From: Johannes Berg @ 2011-11-07 15:40 UTC (permalink / raw)
To: voncken; +Cc: linux-wireless
In-Reply-To: <1320677698.1687.13.camel@voncken-desktop>
On Mon, 2011-11-07 at 15:54 +0100, voncken wrote:
> Hi,
>
> I am currently trying to use rstp protocol (using rstpd ) over
> wireless interfaces (ath9k) and I've noticed some strange hostapd
> behaviour.
>
> Everything seems to work great with wired Ethernet devices.
>
> this is what I do :
> - I have configured an AP (with hostapd), and it works perfectly
> (beacons were sent)
> - ifconfig wlanx down
> - ifconfig wlanx up
>
> after the ifconfig up, the wlanx does not send any beacons although
> clients are perfectly able to associate with (WPA-SUPPLICANT does an
> active scan).
You can't do that. If you set down everything is unconfigured. If you
need to take it down/up then you need to do that before you start
hostapd.
johannes
^ permalink raw reply
* [PATCH v2] mac80211: disassociate when direct probe timed out
From: Stanislaw Gruszka @ 2011-11-07 15:34 UTC (permalink / raw)
To: Johannes Berg, John W. Linville; +Cc: linux-wireless, Lukasz Jagiello
In-Reply-To: <20111107152859.GA5990@redhat.com>
We disassociate only in cfg80211 and upper layers when direct probe
timed out. Mac80211 is not aware about connection problem until
ieee80211_sta_connection_lost() and operate in associate mode. If in
this time window, upper layers decide to change channel we can observe
warnings like below:
WARNING: at include/net/mac80211.h:3081 rate_control_send_low+0x8b/0x10f [mac80211]()
Call Trace:
<IRQ> [<ffffffff81054c2e>] warn_slowpath_common+0x83/0x9b
[<ffffffff81054c60>] warn_slowpath_null+0x1a/0x1c
[<ffffffffa025d5ff>] rate_control_send_low+0x8b/0x10f [mac80211]
[<ffffffffa02ab306>] rs_get_rate+0x138/0x215 [iwlagn]
[<ffffffffa025d993>] rate_control_get_rate+0x86/0x14c [mac80211]
[<ffffffffa0265f18>] invoke_tx_handlers+0x829/0xe7d [mac80211]
[<ffffffff8124bbf9>] ? swiotlb_unmap_page+0x9/0xb
[<ffffffffa02bfc93>] ? pci_unmap_single+0x54/0x5b [iwlagn]
[<ffffffffa02665d1>] ieee80211_tx+0x65/0x90 [mac80211]
[<ffffffffa026675b>] ieee80211_xmit+0x15f/0x16e [mac80211]
[<ffffffff813cfdd4>] ? __alloc_skb+0x8d/0x133
[<ffffffffa02671cc>] ieee80211_tx_skb+0x56/0x5e [mac80211]
[<ffffffffa02547ea>] ieee80211_send_bar+0xda/0xe9 [mac80211]
[<ffffffffa024f5cf>] ieee80211_tx_status+0x1e1/0x706 [mac80211]
[<ffffffff8148867c>] ? _raw_spin_unlock_irqrestore+0x17/0x19
[<ffffffffa024eb5b>] ieee80211_tasklet_handler+0x5b/0xa8 [mac80211]
WARNING: at include/net/mac80211.h:3081 rate_control_send_low+0x8b/0x10f [mac80211]()
Call Trace:
[<ffffffff81054c8e>] warn_slowpath_common+0x83/0x9b
[<ffffffff81054cc0>] warn_slowpath_null+0x1a/0x1c
[<ffffffffa0248627>] rate_control_send_low+0x8b/0x10f [mac80211]
[<ffffffffa029d306>] rs_get_rate+0x138/0x215 [iwlagn]
[<ffffffffa02489bb>] rate_control_get_rate+0x86/0x14c [mac80211]
[<ffffffffa0250f2c>] invoke_tx_handlers+0x829/0xe7d [mac80211]
[<ffffffffa02515e5>] ieee80211_tx+0x65/0x90 [mac80211]
[<ffffffffa025176f>] ieee80211_xmit+0x15f/0x16e [mac80211]
[<ffffffff813cf834>] ? __alloc_skb+0x8d/0x133
[<ffffffffa02521e0>] ieee80211_tx_skb+0x56/0x5e [mac80211]
[<ffffffffa023ef74>] ieee80211_send_delba+0x136/0x145 [mac80211]
[<ffffffffa0240062>] ___ieee80211_stop_rx_ba_session+0xdc/0x10e [mac80211]
[<ffffffffa02400e5>] __ieee80211_stop_rx_ba_session+0x51/0x68 [mac80211]
[<ffffffffa023fc01>] ? ieee80211_start_tx_ba_cb+0x5b/0xd2 [mac80211]
[<ffffffffa023ece5>] ieee80211_sta_tear_down_BA_sessions+0x50/0x5d [mac80211]
[<ffffffffa0241be7>] ieee80211_set_disassoc+0xd1/0x1ee [mac80211]
[<ffffffffa0241eb0>] ieee80211_sta_connection_lost+0x45/0x98 [mac80211]
[<ffffffffa024450a>] ieee80211_sta_work+0x119/0x12c [mac80211]
[<ffffffffa0247003>] ieee80211_iface_work+0x2af/0x2d2 [mac80211]
Lukasz, who can reproduce these warnings when switching between APs
confirmed patch fixes the problem in his setup.
Reported-and-tested-by: Lukasz Jagiello <jagiello.lukasz@gmail.com>
Cc: stable@vger.kernel.org # 3.0+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
Ccing to 3.0+ stable only because warnings showed up after update
to that kernel version. Even if problem existed before, it for some
reason did not manifest itself.
v1 -> v2 change order, first do mac80211 disassociate
net/mac80211/mlme.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 57fb58f..5147f38 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2379,8 +2379,14 @@ ieee80211_probe_auth_done(struct ieee80211_work *wk,
struct sk_buff *skb)
{
struct ieee80211_local *local = wk->sdata->local;
+ struct ieee80211_if_managed *ifmgd = &wk->sdata->u.mgd;
if (!skb) {
+ mutex_lock(&ifmgd->mtx);
+ if (ifmgd->associated)
+ ieee80211_set_disassoc(wk->sdata, true, false);
+ mutex_unlock(&ifmgd->mtx);
+
cfg80211_send_auth_timeout(wk->sdata->dev, wk->filter_ta);
goto destroy;
}
@@ -2390,9 +2396,9 @@ ieee80211_probe_auth_done(struct ieee80211_work *wk,
goto destroy;
}
- mutex_lock(&wk->sdata->u.mgd.mtx);
+ mutex_lock(&ifmgd->mtx);
ieee80211_rx_mgmt_probe_resp(wk->sdata, skb);
- mutex_unlock(&wk->sdata->u.mgd.mtx);
+ mutex_unlock(&ifmgd->mtx);
wk->type = IEEE80211_WORK_AUTH;
wk->probe_auth.tries = 0;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] mac80211: disassociate when direct probe timed out
From: Stanislaw Gruszka @ 2011-11-07 15:29 UTC (permalink / raw)
To: Johannes Berg, John W. Linville; +Cc: linux-wireless, Lukasz Jagiello
In-Reply-To: <20111107142620.GA5852@redhat.com>
On Mon, Nov 07, 2011 at 03:26:21PM +0100, Stanislaw Gruszka wrote:
> if (!skb) {
> cfg80211_send_auth_timeout(wk->sdata->dev, wk->filter_ta);
> +
> + mutex_lock(&ifmgd->mtx);
> + if (ifmgd->associated)
> + ieee80211_set_disassoc(wk->sdata, true, false);
> + mutex_unlock(&ifmgd->mtx);
Patch tested by Lukasz was a bit different, it first did
ieee80211_set_dissasoc() and then cfg80211_send_auth_timeout().
I changed order by accident when forward porting, I think it's better
to apply the orginal order, I'll post v2.
Stanislaw
^ permalink raw reply
* ifconfig down and mac80211 issue
From: voncken @ 2011-11-07 14:54 UTC (permalink / raw)
To: linux-wireless
Hi,
I am currently trying to use rstp protocol (using rstpd ) over
wireless interfaces (ath9k) and I've noticed some strange hostapd
behaviour.
Everything seems to work great with wired Ethernet devices.
this is what I do :
- I have configured an AP (with hostapd), and it works perfectly
(beacons were sent)
- ifconfig wlanx down
- ifconfig wlanx up
after the ifconfig up, the wlanx does not send any beacons although
clients are perfectly able to associate with (WPA-SUPPLICANT does an
active scan).
Have you ever encounter such issue ?
Thanks in advance,
--
VONCKEN Cédric
ACKSYS R&D dept
^ permalink raw reply
* Re: [PATCH v2 1/3] nl80211: Add probe response offload attribute
From: Arik Nemtsov @ 2011-11-07 14:42 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Guy Eilam
In-Reply-To: <1319313081-28722-1-git-send-email-guy@wizery.com>
On Sat, Oct 22, 2011 at 21:51, Guy Eilam <guy@wizery.com> wrote:
> Notify the userspace of the probe response offloading
> support by the driver.
>
> Signed-off-by: Guy Eilam <guy@wizery.com>
> ---
> v2:
> use struct wiphy instead of a function pointer
> this change made the previous second PATCH:
> "Get the probe response offloading support from the driver" irrelevant
> changed WPS to WSC
I'll revert the WSC wording to WPS in the v3 of the probe-resp
patches. Seems more appropriate in light of the new defunct AP_SME
attribute, and the naming conventions for this in hostap
Arik
^ permalink raw reply
* [PATCH] mac80211: disassociate when direct probe timed out
From: Stanislaw Gruszka @ 2011-11-07 14:26 UTC (permalink / raw)
To: Johannes Berg, John W. Linville; +Cc: linux-wireless, Lukasz Jagiello
We disassociate only in cfg80211 and upper layers when direct probe
timed out. Mac80211 is not aware about connection problem until
ieee80211_sta_connection_lost() and operate in associate mode. If in
this time window, upper layers decide to change channel we can observe
warnings like below:
WARNING: at include/net/mac80211.h:3081 rate_control_send_low+0x8b/0x10f [mac80211]()
Call Trace:
<IRQ> [<ffffffff81054c2e>] warn_slowpath_common+0x83/0x9b
[<ffffffff81054c60>] warn_slowpath_null+0x1a/0x1c
[<ffffffffa025d5ff>] rate_control_send_low+0x8b/0x10f [mac80211]
[<ffffffffa02ab306>] rs_get_rate+0x138/0x215 [iwlagn]
[<ffffffffa025d993>] rate_control_get_rate+0x86/0x14c [mac80211]
[<ffffffffa0265f18>] invoke_tx_handlers+0x829/0xe7d [mac80211]
[<ffffffff8124bbf9>] ? swiotlb_unmap_page+0x9/0xb
[<ffffffffa02bfc93>] ? pci_unmap_single+0x54/0x5b [iwlagn]
[<ffffffffa02665d1>] ieee80211_tx+0x65/0x90 [mac80211]
[<ffffffffa026675b>] ieee80211_xmit+0x15f/0x16e [mac80211]
[<ffffffff813cfdd4>] ? __alloc_skb+0x8d/0x133
[<ffffffffa02671cc>] ieee80211_tx_skb+0x56/0x5e [mac80211]
[<ffffffffa02547ea>] ieee80211_send_bar+0xda/0xe9 [mac80211]
[<ffffffffa024f5cf>] ieee80211_tx_status+0x1e1/0x706 [mac80211]
[<ffffffff8148867c>] ? _raw_spin_unlock_irqrestore+0x17/0x19
[<ffffffffa024eb5b>] ieee80211_tasklet_handler+0x5b/0xa8 [mac80211]
WARNING: at include/net/mac80211.h:3081 rate_control_send_low+0x8b/0x10f [mac80211]()
Call Trace:
[<ffffffff81054c8e>] warn_slowpath_common+0x83/0x9b
[<ffffffff81054cc0>] warn_slowpath_null+0x1a/0x1c
[<ffffffffa0248627>] rate_control_send_low+0x8b/0x10f [mac80211]
[<ffffffffa029d306>] rs_get_rate+0x138/0x215 [iwlagn]
[<ffffffffa02489bb>] rate_control_get_rate+0x86/0x14c [mac80211]
[<ffffffffa0250f2c>] invoke_tx_handlers+0x829/0xe7d [mac80211]
[<ffffffffa02515e5>] ieee80211_tx+0x65/0x90 [mac80211]
[<ffffffffa025176f>] ieee80211_xmit+0x15f/0x16e [mac80211]
[<ffffffff813cf834>] ? __alloc_skb+0x8d/0x133
[<ffffffffa02521e0>] ieee80211_tx_skb+0x56/0x5e [mac80211]
[<ffffffffa023ef74>] ieee80211_send_delba+0x136/0x145 [mac80211]
[<ffffffffa0240062>] ___ieee80211_stop_rx_ba_session+0xdc/0x10e [mac80211]
[<ffffffffa02400e5>] __ieee80211_stop_rx_ba_session+0x51/0x68 [mac80211]
[<ffffffffa023fc01>] ? ieee80211_start_tx_ba_cb+0x5b/0xd2 [mac80211]
[<ffffffffa023ece5>] ieee80211_sta_tear_down_BA_sessions+0x50/0x5d [mac80211]
[<ffffffffa0241be7>] ieee80211_set_disassoc+0xd1/0x1ee [mac80211]
[<ffffffffa0241eb0>] ieee80211_sta_connection_lost+0x45/0x98 [mac80211]
[<ffffffffa024450a>] ieee80211_sta_work+0x119/0x12c [mac80211]
[<ffffffffa0247003>] ieee80211_iface_work+0x2af/0x2d2 [mac80211]
Lukasz, who can reproduce these warnings when switching between APs
confirmed patch fixes the problem in his setup.
Reported-and-tested-by: Lukasz Jagiello <jagiello.lukasz@gmail.com>
Cc: stable@vger.kernel.org # 3.0+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
Ccing to 3.0+ stable only because warnings showed up after update
to that kernel version. Even if problem existed before, it for some
reason did not manifest itself.
net/mac80211/mlme.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 57fb58f..0946772 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2379,9 +2379,16 @@ ieee80211_probe_auth_done(struct ieee80211_work *wk,
struct sk_buff *skb)
{
struct ieee80211_local *local = wk->sdata->local;
+ struct ieee80211_if_managed *ifmgd = &wk->sdata->u.mgd;
if (!skb) {
cfg80211_send_auth_timeout(wk->sdata->dev, wk->filter_ta);
+
+ mutex_lock(&ifmgd->mtx);
+ if (ifmgd->associated)
+ ieee80211_set_disassoc(wk->sdata, true, false);
+ mutex_unlock(&ifmgd->mtx);
+
goto destroy;
}
@@ -2390,9 +2397,9 @@ ieee80211_probe_auth_done(struct ieee80211_work *wk,
goto destroy;
}
- mutex_lock(&wk->sdata->u.mgd.mtx);
+ mutex_lock(&ifmgd->mtx);
ieee80211_rx_mgmt_probe_resp(wk->sdata, skb);
- mutex_unlock(&wk->sdata->u.mgd.mtx);
+ mutex_unlock(&ifmgd->mtx);
wk->type = IEEE80211_WORK_AUTH;
wk->probe_auth.tries = 0;
--
1.7.1
^ permalink raw reply related
* Re: iwlagn is getting very shaky
From: Norbert Preining @ 2011-11-07 12:38 UTC (permalink / raw)
To: Guy, Wey-Yi
Cc: David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <20111104045817.GA25778@gamma.logic.tuwien.ac.at>
Hi Wey, hi all,
On Fr, 04 Nov 2011, Norbert Preining wrote:
> > after the firmware reloaded, is the traffic resume? or it is continuous
> > without traffic?
>
> Ok, I compiled a new kernel from todays git, and I see that there
> are kernel bugs, but after the hardware restart traffic gets through.
Well, not always actually. I just had *at*home*, were it used to work
without any flaws till 3.1, I saw that after resume it worked for a
short time, then the queue got stuck, then not even forcing a reset via
the /ss/kernel/debug/..../iwlwifi/debug/force_reset did work. Only
an unload and reload of the module, followed by a few more hickups,
restarted the wlan card:
[ 6564.905884] PM: Finishing wakeup.
[ 6564.905889] Restarting tasks ... done.
[ 6564.924087] video LNXVIDEO:00: Restoring backlight state
[ 6566.045358] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
[ 6566.100108] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
[ 6566.101277] iwlwifi 0000:06:00.0: L1 Enabled; Disabling L0S
[ 6566.105210] iwlwifi 0000:06:00.0: Radio type=0x1-0x2-0x0
[ 6573.822081] wlan0: authenticate with 00:0a:79:eb:56:10 (try 1)
[ 6573.829824] wlan0: authenticated
[ 6573.835543] wlan0: associate with 00:0a:79:eb:56:10 (try 1)
[ 6573.841527] wlan0: RX AssocResp from 00:0a:79:eb:56:10 (capab=0x411 status=0 aid=2)
[ 6573.841537] wlan0: associated
Here it worked for a bit, 20secs
[ 6593.731625] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 00:0a:79:eb:56:10 tid = 0
[ 6603.704072] iwlwifi 0000:06:00.0: Queue 11 stuck for 10000 ms.
[ 6603.704084] iwlwifi 0000:06:00.0: Current read_ptr 249 write_ptr 14
[ 6603.704092] iwlwifi 0000:06:00.0: On demand firmware reload
[ 6603.704566] ieee80211 phy0: Hardware restart was requested
[ 6603.704680] iwlwifi 0000:06:00.0: L1 Enabled; Disabling L0S
[ 6603.707700] iwlwifi 0000:06:00.0: Radio type=0x1-0x2-0x0
Here I forced the reset
[ 6774.772656] iwlwifi 0000:06:00.0: On demand firmware reload
[ 6774.773868] ieee80211 phy0: Hardware restart was requested
[ 6774.773958] iwlwifi 0000:06:00.0: L1 Enabled; Disabling L0S
[ 6774.777053] iwlwifi 0000:06:00.0: Radio type=0x1-0x2-0x0
unloading and reloading
[ 6823.909282] wlan0: deauthenticating from 00:0a:79:eb:56:10 by local choice (reason=3)
[ 6823.976417] cfg80211: Calling CRDA for country: JP
[ 6824.037466] iwlwifi 0000:06:00.0: PCI INT A disabled
[ 6830.344831] Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:d
[ 6830.344835] Copyright(c) 2003-2011 Intel Corporation
[ 6830.344941] iwlwifi 0000:06:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 6830.344974] iwlwifi 0000:06:00.0: setting latency timer to 64
[ 6830.345174] iwlwifi 0000:06:00.0: pci_resource_len = 0x00002000
[ 6830.345176] iwlwifi 0000:06:00.0: pci_resource_base = ffffc90000048000
[ 6830.345179] iwlwifi 0000:06:00.0: HW Revision ID = 0x0
[ 6830.345292] iwlwifi 0000:06:00.0: irq 46 for MSI/MSI-X
[ 6830.345369] iwlwifi 0000:06:00.0: Detected Intel(R) WiFi Link 5100 AGN, REV=0x54
[ 6830.345467] iwlwifi 0000:06:00.0: L1 Enabled; Disabling L0S
[ 6830.367544] iwlwifi 0000:06:00.0: device EEPROM VER=0x11e, CALIB=0x4
[ 6830.367547] iwlwifi 0000:06:00.0: Device SKU: 0Xf0
[ 6830.367557] iwlwifi 0000:06:00.0: Tunable channels: 13 802.11bg, 24 802.11a channels
[ 6830.425994] iwlwifi 0000:06:00.0: loaded firmware version 8.83.5.1 build 33692 (EXP)
[ 6830.426214] Registered led device: phy1-led
[ 6830.426519] ieee80211 phy1: Selected rate control algorithm 'iwl-agn-rs'
more hickups
[ 6830.518627] iwlwifi 0000:06:00.0: L1 Enabled; Disabling L0S
[ 6830.522336] iwlwifi 0000:06:00.0: Radio type=0x1-0x2-0x0
[ 6830.636966] iwlwifi 0000:06:00.0: L1 Enabled; Disabling L0S
[ 6830.640324] iwlwifi 0000:06:00.0: Radio type=0x1-0x2-0x0
[ 6838.327066] wlan0: authenticate with 00:0a:79:eb:56:10 (try 1)
[ 6838.330447] wlan0: authenticated
[ 6838.335890] wlan0: associate with 00:0a:79:eb:56:10 (try 1)
[ 6838.341503] wlan0: RX AssocResp from 00:0a:79:eb:56:10 (capab=0x411 status=0 aid=2)
[ 6838.341507] wlan0: associated
finally got it working, one more final hickup
[ 6860.602423] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 00:0a:79:eb:56:10 tid = 0
from now on working
Would be great to fix that for 3.2
Herzliche Grüße
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
PEEBLES (pl.n.)
Small, carefully rolled pellets of skegness (q.v.)
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: [PATCH 3/5] net/mac80211/debugfs.c: use kstrtoul, etc
From: Julia Lawall @ 2011-11-07 11:58 UTC (permalink / raw)
To: Eliad Peller
Cc: Julia Lawall, John W. Linville, kernel-janitors, Johannes Berg,
David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <CAB3XZEfHV+sO=+vJdZUQVqXFtHvZyhJQ1Cm8LJ8Puyz9eqq9Kg@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1159 bytes --]
On Mon, 7 Nov 2011, Eliad Peller wrote:
> On Sun, Nov 6, 2011 at 3:26 PM, Julia Lawall <julia@diku.dk> wrote:
>> From: Julia Lawall <julia@diku.dk>
>>
>> Use kstrtoul, etc instead of the now deprecated strict_strtoul, etc.
>>
>> A semantic patch rule for the kstrtoul case is as follows:
>> (http://coccinelle.lip6.fr/)
>>
>> // <smpl>
>> @@
>> expression a,b;
>> {int,long} *c;
>> @@
>>
>> -strict_strtoul
>> +kstrtoul
>> (a,b,c)
>> // </smpl>
>>
>> Signed-off-by: Julia Lawall <julia@diku.dk>
>>
>> ---
>> net/mac80211/debugfs.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff -u -p a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
>> --- a/net/mac80211/debugfs.c
>> +++ b/net/mac80211/debugfs.c
>> @@ -190,7 +190,7 @@ static ssize_t uapsd_max_sp_len_write(st
>> return -EFAULT;
>> buf[len] = '\0';
>>
>> - ret = strict_strtoul(buf, 0, &val);
>> + ret = kstrtoul(buf, 0, &val);
>>
>> if (ret)
>> return -EINVAL;
>>
>
> maybe while cleaning it up change copy_from_user +
> strict_stroul/kstroul -> kstroul_from_user?
Thanks for the suggestion. I will look into it.
julia
^ permalink raw reply
* Re: [PATCH 3/5] net/mac80211/debugfs.c: use kstrtoul, etc
From: Eliad Peller @ 2011-11-07 11:47 UTC (permalink / raw)
To: Julia Lawall
Cc: John W. Linville, kernel-janitors, Johannes Berg, David S. Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <1320586010-21931-4-git-send-email-julia@diku.dk>
On Sun, Nov 6, 2011 at 3:26 PM, Julia Lawall <julia@diku.dk> wrote:
> From: Julia Lawall <julia@diku.dk>
>
> Use kstrtoul, etc instead of the now deprecated strict_strtoul, etc.
>
> A semantic patch rule for the kstrtoul case is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression a,b;
> {int,long} *c;
> @@
>
> -strict_strtoul
> +kstrtoul
> (a,b,c)
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
>
> ---
> net/mac80211/debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -u -p a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
> --- a/net/mac80211/debugfs.c
> +++ b/net/mac80211/debugfs.c
> @@ -190,7 +190,7 @@ static ssize_t uapsd_max_sp_len_write(st
> return -EFAULT;
> buf[len] = '\0';
>
> - ret = strict_strtoul(buf, 0, &val);
> + ret = kstrtoul(buf, 0, &val);
>
> if (ret)
> return -EINVAL;
>
maybe while cleaning it up change copy_from_user +
strict_stroul/kstroul -> kstroul_from_user?
Eliad.
^ permalink raw reply
* [PATCH v3 05/12] nl80211: advertise device AP SME
From: Johannes Berg @ 2011-11-07 11:39 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Arik Nemtsov
In-Reply-To: <20111104101943.704950080@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Add the ability to advertise that the device
contains the AP SME and what features it can
support. There are currently no features in
the bitmap -- probe response offload will be
advertised by a few patches Arik is working
on now (who took over from Guy Eilam) and a
device with AP SME will typically implement
and require response offload.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
v2: fix attribute name (thanks Eliad)
v3: remove WSC bit
drivers/net/wireless/ath/ath6kl/init.c | 3 ++-
include/linux/nl80211.h | 15 +++++++++++++++
include/net/cfg80211.h | 6 ++++++
net/wireless/core.c | 4 ++++
net/wireless/nl80211.c | 4 ++++
5 files changed, 31 insertions(+), 1 deletion(-)
--- a/include/linux/nl80211.h 2011-11-04 11:21:17.000000000 +0100
+++ b/include/linux/nl80211.h 2011-11-07 12:35:59.000000000 +0100
@@ -1121,6 +1121,11 @@ enum nl80211_commands {
* %NL80211_CMD_TDLS_MGMT. Otherwise %NL80211_CMD_TDLS_OPER should be
* used for asking the driver to perform a TDLS operation.
*
+ * @NL80211_ATTR_DEVICE_AP_SME: This u32 attribute may be listed for devices
+ * that have AP support to indicate that they have the AP SME integrated
+ * with support for the features listed in this attribute, see
+ * &enum nl80211_ap_sme_features.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1349,6 +1354,8 @@ enum nl80211_attrs {
NL80211_ATTR_TDLS_SUPPORT,
NL80211_ATTR_TDLS_EXTERNAL_SETUP,
+ NL80211_ATTR_DEVICE_AP_SME,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -2662,4 +2669,12 @@ enum nl80211_tdls_operation {
NL80211_TDLS_DISABLE_LINK,
};
+/*
+ * enum nl80211_ap_sme_features - device-integrated AP features
+ * Reserved for future use, no bits are defined in
+ * NL80211_ATTR_DEVICE_AP_SME yet.
+enum nl80211_ap_sme_features {
+};
+ */
+
#endif /* __LINUX_NL80211_H */
--- a/include/net/cfg80211.h 2011-11-04 11:21:17.000000000 +0100
+++ b/include/net/cfg80211.h 2011-11-07 12:31:55.000000000 +0100
@@ -1675,6 +1675,7 @@ struct cfg80211_ops {
* teardown packets should be sent through the @NL80211_CMD_TDLS_MGMT
* command. When this flag is not set, @NL80211_CMD_TDLS_OPER should be
* used for asking the driver/firmware to perform a TDLS operation.
+ * @WIPHY_FLAG_HAVE_AP_SME: device integrates AP SME
*/
enum wiphy_flags {
WIPHY_FLAG_CUSTOM_REGULATORY = BIT(0),
@@ -1693,6 +1694,7 @@ enum wiphy_flags {
WIPHY_FLAG_AP_UAPSD = BIT(14),
WIPHY_FLAG_SUPPORTS_TDLS = BIT(15),
WIPHY_FLAG_TDLS_EXTERNAL_SETUP = BIT(16),
+ WIPHY_FLAG_HAVE_AP_SME = BIT(17),
};
/**
@@ -1903,6 +1905,8 @@ struct wiphy_wowlan_support {
* may request, if implemented.
*
* @wowlan: WoWLAN support information
+ *
+ * @ap_sme_capa: AP SME capabilities, flags from &enum nl80211_ap_sme_features.
*/
struct wiphy {
/* assign these fields before you register the wiphy */
@@ -1926,6 +1930,8 @@ struct wiphy {
u32 flags;
+ u32 ap_sme_capa;
+
enum cfg80211_signal_type signal_type;
int bss_priv_size;
--- a/net/wireless/core.c 2011-11-03 14:41:41.000000000 +0100
+++ b/net/wireless/core.c 2011-11-04 11:21:17.000000000 +0100
@@ -492,6 +492,10 @@ int wiphy_register(struct wiphy *wiphy)
!(wiphy->wowlan.flags & WIPHY_WOWLAN_SUPPORTS_GTK_REKEY)))
return -EINVAL;
+ if (WARN_ON(wiphy->ap_sme_capa &&
+ !(wiphy->flags & WIPHY_FLAG_HAVE_AP_SME)))
+ return -EINVAL;
+
if (WARN_ON(wiphy->addresses && !wiphy->n_addresses))
return -EINVAL;
--- a/net/wireless/nl80211.c 2011-11-04 11:21:17.000000000 +0100
+++ b/net/wireless/nl80211.c 2011-11-07 12:31:55.000000000 +0100
@@ -1007,6 +1007,10 @@ static int nl80211_send_wiphy(struct sk_
if (nl80211_put_iface_combinations(&dev->wiphy, msg))
goto nla_put_failure;
+ if (dev->wiphy.flags & WIPHY_FLAG_HAVE_AP_SME)
+ NLA_PUT_U32(msg, NL80211_ATTR_DEVICE_AP_SME,
+ dev->wiphy.ap_sme_capa);
+
return genlmsg_end(msg, hdr);
nla_put_failure:
--- a/drivers/net/wireless/ath/ath6kl/init.c 2011-11-03 14:41:41.000000000 +0100
+++ b/drivers/net/wireless/ath/ath6kl/init.c 2011-11-07 12:34:45.000000000 +0100
@@ -1548,7 +1548,8 @@ static int ath6kl_init(struct net_device
ar->conf_flags = ATH6KL_CONF_IGNORE_ERP_BARKER |
ATH6KL_CONF_ENABLE_11N | ATH6KL_CONF_ENABLE_TX_BURST;
- ar->wdev->wiphy->flags |= WIPHY_FLAG_SUPPORTS_FW_ROAM;
+ ar->wdev->wiphy->flags |= WIPHY_FLAG_SUPPORTS_FW_ROAM |
+ WIPHY_FLAG_HAVE_AP_SME;
status = ath6kl_target_config_wlan_params(ar);
if (!status)
^ permalink raw reply
* Re: [ANN] iw: v3.2
From: Johannes Berg @ 2011-11-07 9:55 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <E1RNLZe-0005kI-RP@sipsolutions.net>
On Mon, 2011-11-07 at 10:34 +0100, wireless@sipsolutions.net wrote:
> A new release of iw (v3.2) is available at:
>
> http://wireless.kernel.org/download/iw/iw-3.2.tar.bz2
>
> SHA1 sum: 2871d58ab1f8d5b2b8d548d57489873f21c085be
>
> Here is the short log of the changes (since v0.9.22)
> included in this release:
This is an artifact of how I created 3.0 and 3.1, the log since 3.1 is
shorter:
Christian Lamparter (1):
iw: fix HT PHY BSS Membership selector value encoding
Helmut Schaa (1):
iw: show STA flags in station dump
Javier Cardona (1):
support for setting RANN interval and mesh gate
Johannes Berg (11):
update nl80211.h
update nl80211.h
print roam capability
show supported ciphers
print PHY membership selector only for membership rates
SSID printing: escape space at beginning end, backslash
print wiphy idx in iface info
update nl80211.h
print PMKSA candidate event
print out AP-side uAPSD support
update version to 3.2
Yegor Yefremov (1):
iw: add libnl-3.0 support
johannes
^ permalink raw reply
* [ANN] iw: v3.2
From: wireless @ 2011-11-07 9:33 UTC (permalink / raw)
To: linux-wireless
A new release of iw (v3.2) is available at:
http://wireless.kernel.org/download/iw/iw-3.2.tar.bz2
SHA1 sum: 2871d58ab1f8d5b2b8d548d57489873f21c085be
Here is the short log of the changes (since v0.9.22)
included in this release:
Christian Lamparter (1):
iw: fix HT PHY BSS Membership selector value encoding
Helmut Schaa (1):
iw: show STA flags in station dump
Javier Cardona (1):
support for setting RANN interval and mesh gate
Jo-Philipp Wich (1):
iw: Fix calculation of fractional multicast rates
Johannes Berg (30):
use nla_type
report IBSS RSN
fix frequency parsing
print frame TX status event
update nl80211.h
validate tx power argument is a number
update nl80211.h
wowlan support
update nl80211.h
show interface combinations
scan: print WPS UUID
scan: print MS OUI as what it is
a little bit of P2P parsing
more verbose output for interface combinations
update nl80211.h
add set_rekey_offload cmd
new wowlan triggers/info
add remain-on-channel
fix bug in version.sh
update nl80211.h
update nl80211.h
print roam capability
show supported ciphers
print PHY membership selector only for membership rates
SSID printing: escape space at beginning end, backslash
print wiphy idx in iface info
update nl80211.h
print PMKSA candidate event
print out AP-side uAPSD support
update version to 3.2
Paul Stewart (1):
Add station BSS params to iw output
Sean Robinson (1):
Add send callbacks with optional debug handler
Sujith Manoharan (1):
iw: Clarify bitrate mask documentation
Yegor Yefremov (1):
iw: add libnl-3.0 support
^ permalink raw reply
* Re: [PATCH v4 2/2] mac80211: Support ht-cap over-rides.
From: Johannes Berg @ 2011-11-07 9:13 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1320437440-6463-2-git-send-email-greearb@candelatech.com>
On Fri, 2011-11-04 at 13:10 -0700, greearb@candelatech.com wrote:
> +/*
> + * Stations supporting 802.11n are required to support
> + * at least the first 8 MCS rates. See section 7.3.2.56.4
> + * and 20.1.1 of the 802.11n spec.
> + */
> +#define IEEE80211_HT_MCS_REQ_RATES_STA 8
I'd prefer if this was a validation on the input from userspace directly
in cfg80211, that way other drivers that want to implement this don't
have to bother.
That probably goes well with the validation of the supported mask that I
asked for.
> + /* mac80211 allows over-riding some of the ht-capabilities */
> + local->hw.wiphy->ht_capa_mod_mask =
> + kzalloc(sizeof(*local->hw.wiphy->ht_capa_mod_mask),
> + GFP_KERNEL);
> + if (local->hw.wiphy->ht_capa_mod_mask) {
> + struct ieee80211_ht_cap *cm = local->hw.wiphy->ht_capa_mod_mask;
> + u8 *r = (u8 *)(&cm->mcs.rx_mask);
> + memset(r, 0xff, IEEE80211_HT_MCS_MASK_LEN);
> + cm->cap_info |= IEEE80211_HT_CAP_MAX_AMSDU;
> + cm->ampdu_params_info |= IEEE80211_HT_AMPDU_PARM_FACTOR;
> + cm->ampdu_params_info |= IEEE80211_HT_AMPDU_PARM_DENSITY;
> + }
Why is this not just a static const that you fill manually? There's
nothing that's not constant here. So e.g.
static const struct ieee80211_ht_cap mac80211_ht_capa_mod_mask = {
.ampdu_params_info = IEEE80211_HT_AMPDU_PARM_FACTOR |
IEEE80211_HT_AMPDU_PARM_DENSITY,
.mcs = {
.rx_mask = { 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, },
},
/* etc */
};
> @@ -988,6 +1001,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
> fail_wiphy_register:
> if (local->wiphy_ciphers_allocated)
> kfree(local->hw.wiphy->cipher_suites);
> + kfree(local->hw.wiphy->ht_capa_mod_mask);
> + local->hw.wiphy->ht_capa_mod_mask = NULL;
No need for this then obviously.
Looks pretty good overall. This is _much_ more readable than the
previous series. :-)
johannes
^ permalink raw reply
* Re: [PATCH v4 1/2] wireless: Support ht-capabilities over-rides.
From: Johannes Berg @ 2011-11-07 9:06 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1320437440-6463-1-git-send-email-greearb@candelatech.com>
On Fri, 2011-11-04 at 13:10 -0700, greearb@candelatech.com wrote:
> + * @NL80211_ATTR_DISABLE_HT: Force HT capable interfaces to disable
> + * this feature.
I can see this, but
> + * @NL80211_ATTR_DISABLE_HT40: Disable HT-40 even if AP and hardware
> + * support it.
> + * @NL80211_ATTR_HT_CAPABILITY_MASK: Specify which bits of the HT_CAPs
> + * to pay attention to.
if you have the mask why do you still need the HT40? Isn't HT40 a flag
in the mask? Or do you want this to affect TX/RX separately? You should
spell that out more explicitly then.
> --- a/net/wireless/core.c
> +++ b/net/wireless/core.c
> @@ -704,6 +704,9 @@ void wiphy_unregister(struct wiphy *wiphy)
> flush_work(&rdev->scan_done_wk);
> cancel_work_sync(&rdev->conn_work);
> flush_work(&rdev->event_work);
> +
> + kfree(rdev->wiphy.ht_capa_mod_mask);
> + rdev->wiphy.ht_capa_mod_mask = NULL;
That doesn't seem right -- drivers should typically assign a static
const variable to this pointer that can't be freed.
> @@ -537,6 +539,12 @@ int __cfg80211_mlme_assoc(struct cfg80211_registered_device *rdev,
> memcpy(&req.crypto, crypt, sizeof(req.crypto));
> req.use_mfp = use_mfp;
> req.prev_bssid = prev_bssid;
> + req.flags = assoc_flags;
> + if (ht_capa)
> + memcpy(&req.ht_capa, ht_capa, sizeof(req.ht_capa));
> + if (ht_capa_mask)
> + memcpy(&req.ht_capa_mask, ht_capa_mask,
> + sizeof(req.ht_capa_mask));
I think somewhere here you should mask this mask with the
ht_capa_mod_mask. That way, you force drivers to advertise a correct
ht_capa_mod_mask, if you don't do that we will certainly see drivers use
more of ht_capa than contained in ht_capa_mod_mask. Probably should be a
helper function since I think you might need it in more places.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: uAPSD - fix IEEE80211_FCTL_MOREDATA bit setting
From: Johannes Berg @ 2011-11-07 8:50 UTC (permalink / raw)
To: Janusz.Dziedzic; +Cc: linux-wireless
In-Reply-To: <3078A9B976EF864C8DDD0C499FFD07911E3B56E1EC@EXMB01.eu.tieto.com>
On Mon, 2011-11-07 at 09:47 +0200, Janusz.Dziedzic@tieto.com wrote:
> Set IEEE80211_FCTL_MOREDATA bit also in case we have buffered
> frames (more than one) only for one AC.
>
> Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Thanks!
> ---
> net/mac80211/sta_info.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
> index ce962d2..8eaa746 100644
> --- a/net/mac80211/sta_info.c
> +++ b/net/mac80211/sta_info.c
> @@ -1354,12 +1354,12 @@ ieee80211_sta_ps_deliver_response(struct sta_info *sta,
> * Use MoreData flag to indicate whether there are
> * more buffered frames for this STA
> */
> - if (!more_data)
> - hdr->frame_control &=
> - cpu_to_le16(~IEEE80211_FCTL_MOREDATA);
> - else
> + if (more_data || !skb_queue_empty(&frames))
> hdr->frame_control |=
> cpu_to_le16(IEEE80211_FCTL_MOREDATA);
> + else
> + hdr->frame_control &=
> + cpu_to_le16(~IEEE80211_FCTL_MOREDATA);
>
> if (ieee80211_is_data_qos(hdr->frame_control) ||
> ieee80211_is_qos_nullfunc(hdr->frame_control))
^ permalink raw reply
* Re: [PATCH 05/12] nl80211: advertise device AP SME
From: Johannes Berg @ 2011-11-07 8:49 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: John Linville, linux-wireless
In-Reply-To: <CA+XVXfemN4dZC2GkKqpvGsFxs81dST4Mth0rEDd-MQrXc8rnXw@mail.gmail.com>
On Mon, 2011-11-07 at 10:29 +0200, Arik Nemtsov wrote:
> > +/**
> > + * enum nl80211_ap_sme_features - device-integrated AP features
> > + * @NL80211_AP_SME_WSC: The driver is capable of indicating received probe
> > + * request frames to userspace via management frame subscription events
> > + * if the payload includes the WSC IE. The driver is capable of adding
> > + * the WSC IE as configured from userspace into beacons, probe responses
> > + * and (re)association reponse frame and allows userspace to update them
> > + * during the lifetime of the BSS.
> > + */
> > +enum nl80211_ap_sme_features {
> > + NL80211_AP_SME_WSC = 1 << 0,
> > +};
>
> Perhaps we should break up this feature into two? With the upcoming
> probe-resp patches a wl12xx card will be able to indicate
> probe-requests with WSC IE up, but won't be able to add a userspace
> provided WSC IE into beacons.
Break up how? wl12xx obviously wouldn't say it has AP SME included.
Also, I think here it is actually still doing this by reporting probe
requests up, but it's somewhat different.
> Also I'm wondering what this is used for. For instance this contains
> no indication about WPS1 and p2p. Pretty sure ath6kl handles these in
> a similar fashion (at least for the put-IE-from-userspace-in-beacon
> part).
Yeah. This was more or less a placeholder, I guess we need more info
from the ath6kl people.
> And as a final nit-pick, I think WPS2 is more appropriate, as this is
> also the name of the option in the hostapd code and config file.
Good point. Let's discuss the bits & the behaviour a bit more, although
I hate having to postpone the patchset for it :-)
I think the thing here is that we approach a middle ground from two
different sides. With mac80211, we typically handle everything on the
host, so things like replying to probe requests is an offload. With
AP_SME, we initially expect everything to be handled on the device and
approach middle ground by not replying to WPS probe requests. I thought
it makes sense to put these into different attributes rather than use
the same probe response offload attribute you have for wl12xx, but I'll
admit that the semantics are pretty similar.
However, I could see much more features come into play here, for example
FT would probably not be a feature an AP_SME device has, but for
mac80211 based drivers it's obviously just implemented in hostapd. So
such a feature might also need a bit in this new bitfield.
johannes
^ permalink raw reply
* Re: [PATCH 05/12] nl80211: advertise device AP SME
From: Arik Nemtsov @ 2011-11-07 8:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <20111104101943.704950080@sipsolutions.net>
On Fri, Nov 4, 2011 at 12:18, Johannes Berg <johannes@sipsolutions.net> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Add the ability to advertise that the device
> contains the AP SME and what features it can
> support.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
[...]
>
> +/**
> + * enum nl80211_ap_sme_features - device-integrated AP features
> + * @NL80211_AP_SME_WSC: The driver is capable of indicating received probe
> + * request frames to userspace via management frame subscription events
> + * if the payload includes the WSC IE. The driver is capable of adding
> + * the WSC IE as configured from userspace into beacons, probe responses
> + * and (re)association reponse frame and allows userspace to update them
> + * during the lifetime of the BSS.
> + */
> +enum nl80211_ap_sme_features {
> + NL80211_AP_SME_WSC = 1 << 0,
> +};
Perhaps we should break up this feature into two? With the upcoming
probe-resp patches a wl12xx card will be able to indicate
probe-requests with WSC IE up, but won't be able to add a userspace
provided WSC IE into beacons.
Also I'm wondering what this is used for. For instance this contains
no indication about WPS1 and p2p. Pretty sure ath6kl handles these in
a similar fashion (at least for the put-IE-from-userspace-in-beacon
part).
And as a final nit-pick, I think WPS2 is more appropriate, as this is
also the name of the option in the hostapd code and config file.
Arik
^ 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