* Re: [PATCH] ath9k: remove usage of deprecated noise value
From: Benoit PAPILLAULT @ 2010-04-27 6:22 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1272312561-22648-1-git-send-email-linville@tuxdriver.com>
John W. Linville a écrit :
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> drivers/net/wireless/ath/ath9k/common.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c
> index 09effde..b4424a6 100644
> --- a/drivers/net/wireless/ath/ath9k/common.c
> +++ b/drivers/net/wireless/ath/ath9k/common.c
> @@ -212,7 +212,6 @@ int ath9k_cmn_rx_skb_preprocess(struct ath_common *common,
> rx_status->mactime = ath9k_hw_extend_tsf(ah, rx_stats->rs_tstamp);
> rx_status->band = hw->conf.channel->band;
> rx_status->freq = hw->conf.channel->center_freq;
> - rx_status->noise = common->ani.noise_floor;
> rx_status->signal = ATH_DEFAULT_NOISE_FLOOR + rx_stats->rs_rssi;
> rx_status->antenna = rx_stats->rs_antenna;
> rx_status->flag |= RX_FLAG_TSFT;
>
Hey, I'm still using this value here in my setup (I've done some work on
noise floor calibration and can submit a patch that report noise &
signal values that makes more sense to me). I mentioned in an earlier
patch that I was using the {last_signal, last_noise} debugfs file as
well (in February, 17th).
Before removing noise reporting and all related code, wouln't it be
better to have a replacement API? I was told that noise reporting is
buggy for most chipset, but that's a bug in each driver, not in mac80211
then. Such bugs could be fixed by using a default value of -101dBm
(thermal noise at room temperature over a 20 MHz channel) if they are
unable to determine a correct value.
Moreover, it is very convenient to have the {last_signal, last_noise}
sampled at the same time and be in the same location. Likewise for the
radiotap header, it is very easy to plot noise value over time if it is
stored on a per packet basis. Of course, I know noise is a global
property of the channel and not DEFINED on a per packet basis, but once
you know that, it's still useful to have it REPORTED on a per packet basis.
So far, the solution for me was to revert the single patch for making
the noise field deprecated, but I'm not going to revert each & every
patches related to noise. After all, isn't it the purpose of peer review?
Regards,
Benoit
^ permalink raw reply
* Re: update compat drivers,adpter can not be work,4 help.tks
From: Pavel Roskin @ 2010-04-27 5:55 UTC (permalink / raw)
To: seco.wu; +Cc: Gábor Stefanik, linux-wireless
In-Reply-To: <s2ne4fca08d1004250142ga518cbfdn1692b54c23191bef@mail.gmail.com>
On Sun, 2010-04-25 at 16:42 +0800, SECO wrote:
> tks Sir
>
> what's matter with update compat-wireless under bt4?
...
> 00000-9FFFF write-back
> A0000-BFFFF uncachable
Please don't waste bandwidth and space with irrelevant logs.
> b43: Unknown symbol ssb_pmu_set_ldo_paref
It looks like b43 was compiled, but ssb wasn't. I can reproduce the
problem with Linux 2.6.26 without SSB enabled.
The logic for enabling ssb and SSB based devices in compat-wireless has
been broken for some time. I reported it in the past. But not enabling
the ssb module is a new problem.
> 2010/4/23, Gábor Stefanik <netrolller.3d@gmail.com>:
> > On Fri, Apr 23, 2010 at 2:20 AM, SECO <secowu@gmail.com> wrote:
> >> & this is the full log
> >>
> >>
> >> ./scripts/gen-compat-autoconf.sh config.mk >
> >> include/linux/compat_autoconf.h
> >> make -C /lib/modules/2.6.30.9/build M=/root/compat-wireless-2.6.34-rc4
> >> modules
> >> make[1]: Entering directory `/usr/src/linux-source-2.6.30.9'
Please don't quote text irrelevant to your message.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] ath9k: Avoid corrupt frames being forwarded to mac80211.
From: Luis R. Rodriguez @ 2010-04-27 5:40 UTC (permalink / raw)
To: Vivek Natarajan
Cc: Felix Fietkau, linville, linux-wireless, stable, Ranga Rao Ravuri
In-Reply-To: <l2v8e92b4101004262232n344621f3ufcd861290d40157d@mail.gmail.com>
On Mon, Apr 26, 2010 at 10:32 PM, Vivek Natarajan
<vivek.natraj@gmail.com> wrote:
> On Sat, Apr 24, 2010 at 9:15 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>> On 2010-04-23 9:26 AM, Vivek Natarajan wrote:
>>> If bit 29 is set, MAC H/W can attempt to decrypt the received aggregate
>>> with WEP or TKIP, eventhough the received frame may be a CRC failed
>>> corrupted frame.
>>> diff --git a/drivers/net/wireless/ath/ath9k/ar5008_initvals.h b/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
>>> index cd953f6..025c31a 100644
>>> --- a/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
>>> +++ b/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
>>> @@ -249,7 +249,7 @@ static const u32 ar5416Common[][2] = {
>>> { 0x00008258, 0x00000000 },
>>> { 0x0000825c, 0x400000ff },
>>> { 0x00008260, 0x00080922 },
>>> - { 0x00008264, 0xa8000010 },
>>> + { 0x00008264, 0x88000010 },
>> I don't think this is enough. This register is called
>> AR_MAC_PCU_LOGIC_ANALYZER and the field you're modifying
>> (AR_MAC_PCU_LOGIC_ANALYZER_DISBUG20768) is being touched by the function
>> ar9002_hw_enable_async_fifo() in ar9002_hw.c.
>> So unless this AR9287 v1.2 or later is unaffected by this issue, the
>> REG_SET_BIT call should be removed as well.
>> By the way, is this change in the other Atheros codebases as well?
>
> Yes. This change is present in other Atheros codebases as well and the
> REG_SET_BIT call is also present for AR9287. This is the feedback that
> I got from the Systems team regarding this register.
> "How H/W works is, if bit 29 is set, H/W obeys key type in keycache.
> If bit 29 is not set and if key type in keycache is neither open nor
> AES, H/W forces key type to be open. Since AsyncFIFO feature wants to
> encrypt/decrypt aggregate with WEP or TKIP, bit 29 should have been
> set to 1 after populating keycache with WEP or TKIP key type."
This would make that commit log entry for this patch actually a good
one. Would you mind massaging that a little and resending with some of
that added?
> Hence I suppose the REG_SET_BIT call needs to be there while enabling
> AsyncFIFO for AR9287.
>
> Vivek.
> --
> 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] ath9k: Avoid corrupt frames being forwarded to mac80211.
From: Vivek Natarajan @ 2010-04-27 5:32 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linville, linux-wireless, stable, Ranga Rao Ravuri
In-Reply-To: <4BD2696D.9030509@openwrt.org>
On Sat, Apr 24, 2010 at 9:15 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-04-23 9:26 AM, Vivek Natarajan wrote:
>> If bit 29 is set, MAC H/W can attempt to decrypt the received aggregate
>> with WEP or TKIP, eventhough the received frame may be a CRC failed
>> corrupted frame.
>> diff --git a/drivers/net/wireless/ath/ath9k/ar5008_initvals.h b/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
>> index cd953f6..025c31a 100644
>> --- a/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
>> +++ b/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
>> @@ -249,7 +249,7 @@ static const u32 ar5416Common[][2] = {
>> { 0x00008258, 0x00000000 },
>> { 0x0000825c, 0x400000ff },
>> { 0x00008260, 0x00080922 },
>> - { 0x00008264, 0xa8000010 },
>> + { 0x00008264, 0x88000010 },
> I don't think this is enough. This register is called
> AR_MAC_PCU_LOGIC_ANALYZER and the field you're modifying
> (AR_MAC_PCU_LOGIC_ANALYZER_DISBUG20768) is being touched by the function
> ar9002_hw_enable_async_fifo() in ar9002_hw.c.
> So unless this AR9287 v1.2 or later is unaffected by this issue, the
> REG_SET_BIT call should be removed as well.
> By the way, is this change in the other Atheros codebases as well?
Yes. This change is present in other Atheros codebases as well and the
REG_SET_BIT call is also present for AR9287. This is the feedback that
I got from the Systems team regarding this register.
"How H/W works is, if bit 29 is set, H/W obeys key type in keycache.
If bit 29 is not set and if key type in keycache is neither open nor
AES, H/W forces key type to be open. Since AsyncFIFO feature wants to
encrypt/decrypt aggregate with WEP or TKIP, bit 29 should have been
set to 1 after populating keycache with WEP or TKIP key type."
Hence I suppose the REG_SET_BIT call needs to be there while enabling
AsyncFIFO for AR9287.
Vivek.
^ permalink raw reply
* Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
From: Juuso Oikarinen @ 2010-04-27 4:27 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1272285059.3619.31.camel@jlt3.sipsolutions.net>
Hi,
On Mon, 2010-04-26 at 14:30 +0200, ext Johannes Berg wrote:
> On Mon, 2010-04-26 at 15:23 +0300, Juuso Oikarinen wrote:
>
> > Heh, I could in turn say that you think too little about power
> > consumption :) This particular thing, dynamic ps timer, has a *huge*
> > effect on the total power consumption just because it's so frequent.
>
> Heh :)
>
> > I'm basically open for any means to tell cfg80211 that it should
> > sacrifice service quality in the name of saving as much power as it can
> > (apart from shutting the thing down :). Can you give me a hint on what
> > you would consider an acceptable way to do this?
>
> Well personally I'm happy with this approach.
>
> I just fear that at one point, somebody will tweak the algorithm, and
> you will have deeply ingrained assumptions about where the cutoff points
> are in your userland software, which will cause all kinds of grief.
Ok, I shall then propose this as a patch. I'm pretty sure there are
people out there, probably more innovative than I, who are having the
same thoughts about the dynamic ps as I, as linux is being more widely
used in handhelds. So I count on it that someone will tweak the
algorithm, and make it better.
-Juuso
> 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/2] cfg80211: add ap isolation support
From: Luis R. Rodriguez @ 2010-04-27 1:53 UTC (permalink / raw)
To: Felix Fietkau; +Cc: John W. Linville, Jouni Malinen, linux-wireless, johannes
In-Reply-To: <4BD640F5.8010206@openwrt.org>
On Mon, Apr 26, 2010 at 6:42 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-04-27 3:34 AM, Luis R. Rodriguez wrote:
>> On Mon, Apr 26, 2010 at 5:25 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>>> On Mon, Apr 26, 2010 at 5:12 PM, John W. Linville
>>> <linville@tuxdriver.com> wrote:
>>>> On Tue, Apr 27, 2010 at 01:30:02AM +0200, Felix Fietkau wrote:
>>>>> On 2010-04-27 1:23 AM, John W. Linville wrote:
>>>>> > On Tue, Apr 27, 2010 at 01:23:35AM +0200, Felix Fietkau wrote:
>>>>> >> This is used to configure APs to not bridge traffic between connected stations.
>>>>> >>
>>>>> >> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>>>>> >
>>>>> > Is this useful?
>>>>> Yes, if you have an AP with lots of users that aren't expected to
>>>>> communicate with each other (e.g. only for internet access), it can save
>>>>> a lot of airtime by not forwarding every broadcast message emitted from
>>>>> any station.
>>>>> I'm sure there are a more situations where this can be useful.
>>>>
>>>> Ah, OK -- I suppose that makes sense.
>>>
>>> In fact technically IEEE-802.11 2007 section 11.7 states "STAs are not
>>> allowed to transmit frames directly to other STAs in a BSS and should
>>> always rely
>>> on the AP for the delivery of the frames", with the exception being
>>> using DLS direct links for QoS STAs. This would prevent the STAs from
>>> going into PS mode for as long duration of the stream.
>>>
>>> If the AP does not support this it would just set the result code for
>>> DLS requests to "Not allowed in the BSS". It does not seem the
>>> standard has a way for an AP to teardown an existing DLS links though
>>> (at no reason code for it), so I guess if we ever support DLS we won't
>>> be able to enable this option if a direct links is already
>>> established.
>>
>> Now that I think about it, why is this even required, why not just
>> enforce this all the time and have an option to disable DLS? Are there
>> ways to enable direct STA <--> STA communication on a BSS other than
>> DLS?
> I think allowing/disallowing DLS should be separate from AP isolation.
> In some cases, AP isolation might only be used to reduce the amount of
> broadcast traffic, and DLS wouldn't be a problem then.
So the other way for an AP to forward traffic from STAs on the BSS to
others is to transmit broadcast frames and the purpose of this patch
is to disable that? If so can the description of the command be a
little more descriptive about this? Perhaps annotating that other
communication would not be done unless DLS links are created ?
Luis
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: add ap isolation support
From: Felix Fietkau @ 2010-04-27 1:42 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: John W. Linville, Jouni Malinen, linux-wireless, johannes
In-Reply-To: <k2y43e72e891004261834w1eb604d0q83f9cd80820e3d8@mail.gmail.com>
On 2010-04-27 3:34 AM, Luis R. Rodriguez wrote:
> On Mon, Apr 26, 2010 at 5:25 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Mon, Apr 26, 2010 at 5:12 PM, John W. Linville
>> <linville@tuxdriver.com> wrote:
>>> On Tue, Apr 27, 2010 at 01:30:02AM +0200, Felix Fietkau wrote:
>>>> On 2010-04-27 1:23 AM, John W. Linville wrote:
>>>> > On Tue, Apr 27, 2010 at 01:23:35AM +0200, Felix Fietkau wrote:
>>>> >> This is used to configure APs to not bridge traffic between connected stations.
>>>> >>
>>>> >> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>>>> >
>>>> > Is this useful?
>>>> Yes, if you have an AP with lots of users that aren't expected to
>>>> communicate with each other (e.g. only for internet access), it can save
>>>> a lot of airtime by not forwarding every broadcast message emitted from
>>>> any station.
>>>> I'm sure there are a more situations where this can be useful.
>>>
>>> Ah, OK -- I suppose that makes sense.
>>
>> In fact technically IEEE-802.11 2007 section 11.7 states "STAs are not
>> allowed to transmit frames directly to other STAs in a BSS and should
>> always rely
>> on the AP for the delivery of the frames", with the exception being
>> using DLS direct links for QoS STAs. This would prevent the STAs from
>> going into PS mode for as long duration of the stream.
>>
>> If the AP does not support this it would just set the result code for
>> DLS requests to "Not allowed in the BSS". It does not seem the
>> standard has a way for an AP to teardown an existing DLS links though
>> (at no reason code for it), so I guess if we ever support DLS we won't
>> be able to enable this option if a direct links is already
>> established.
>
> Now that I think about it, why is this even required, why not just
> enforce this all the time and have an option to disable DLS? Are there
> ways to enable direct STA <--> STA communication on a BSS other than
> DLS?
I think allowing/disallowing DLS should be separate from AP isolation.
In some cases, AP isolation might only be used to reduce the amount of
broadcast traffic, and DLS wouldn't be a problem then.
- Felix
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: add ap isolation support
From: Luis R. Rodriguez @ 2010-04-27 1:34 UTC (permalink / raw)
To: John W. Linville, Jouni Malinen; +Cc: Felix Fietkau, linux-wireless, johannes
In-Reply-To: <t2i43e72e891004261725kdd3c1388jc2758db8a0b7e82@mail.gmail.com>
On Mon, Apr 26, 2010 at 5:25 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Mon, Apr 26, 2010 at 5:12 PM, John W. Linville
> <linville@tuxdriver.com> wrote:
>> On Tue, Apr 27, 2010 at 01:30:02AM +0200, Felix Fietkau wrote:
>>> On 2010-04-27 1:23 AM, John W. Linville wrote:
>>> > On Tue, Apr 27, 2010 at 01:23:35AM +0200, Felix Fietkau wrote:
>>> >> This is used to configure APs to not bridge traffic between connected stations.
>>> >>
>>> >> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>>> >
>>> > Is this useful?
>>> Yes, if you have an AP with lots of users that aren't expected to
>>> communicate with each other (e.g. only for internet access), it can save
>>> a lot of airtime by not forwarding every broadcast message emitted from
>>> any station.
>>> I'm sure there are a more situations where this can be useful.
>>
>> Ah, OK -- I suppose that makes sense.
>
> In fact technically IEEE-802.11 2007 section 11.7 states "STAs are not
> allowed to transmit frames directly to other STAs in a BSS and should
> always rely
> on the AP for the delivery of the frames", with the exception being
> using DLS direct links for QoS STAs. This would prevent the STAs from
> going into PS mode for as long duration of the stream.
>
> If the AP does not support this it would just set the result code for
> DLS requests to "Not allowed in the BSS". It does not seem the
> standard has a way for an AP to teardown an existing DLS links though
> (at no reason code for it), so I guess if we ever support DLS we won't
> be able to enable this option if a direct links is already
> established.
Now that I think about it, why is this even required, why not just
enforce this all the time and have an option to disable DLS? Are there
ways to enable direct STA <--> STA communication on a BSS other than
DLS?
Luis
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: add ap isolation support
From: Luis R. Rodriguez @ 2010-04-27 0:25 UTC (permalink / raw)
To: John W. Linville; +Cc: Felix Fietkau, linux-wireless, johannes
In-Reply-To: <20100427001233.GB2079@tuxdriver.com>
On Mon, Apr 26, 2010 at 5:12 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Tue, Apr 27, 2010 at 01:30:02AM +0200, Felix Fietkau wrote:
>> On 2010-04-27 1:23 AM, John W. Linville wrote:
>> > On Tue, Apr 27, 2010 at 01:23:35AM +0200, Felix Fietkau wrote:
>> >> This is used to configure APs to not bridge traffic between connected stations.
>> >>
>> >> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>> >
>> > Is this useful?
>> Yes, if you have an AP with lots of users that aren't expected to
>> communicate with each other (e.g. only for internet access), it can save
>> a lot of airtime by not forwarding every broadcast message emitted from
>> any station.
>> I'm sure there are a more situations where this can be useful.
>
> Ah, OK -- I suppose that makes sense.
In fact technically IEEE-802.11 2007 section 11.7 states "STAs are not
allowed to transmit frames directly to other STAs in a BSS and should
always rely
on the AP for the delivery of the frames", with the exception being
using DLS direct links for QoS STAs. This would prevent the STAs from
going into PS mode for as long duration of the stream.
If the AP does not support this it would just set the result code for
DLS requests to "Not allowed in the BSS". It does not seem the
standard has a way for an AP to teardown an existing DLS links though
(at no reason code for it), so I guess if we ever support DLS we won't
be able to enable this option if a direct links is already
established.
Luis
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: add ap isolation support
From: John W. Linville @ 2010-04-27 0:12 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, johannes
In-Reply-To: <4BD621FA.1000405@openwrt.org>
On Tue, Apr 27, 2010 at 01:30:02AM +0200, Felix Fietkau wrote:
> On 2010-04-27 1:23 AM, John W. Linville wrote:
> > On Tue, Apr 27, 2010 at 01:23:35AM +0200, Felix Fietkau wrote:
> >> This is used to configure APs to not bridge traffic between connected stations.
> >>
> >> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> >
> > Is this useful?
> Yes, if you have an AP with lots of users that aren't expected to
> communicate with each other (e.g. only for internet access), it can save
> a lot of airtime by not forwarding every broadcast message emitted from
> any station.
> I'm sure there are a more situations where this can be useful.
Ah, OK -- I suppose that makes sense.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: add ap isolation support
From: Bruno Randolf @ 2010-04-27 0:09 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, johannes
In-Reply-To: <20100426232332.GA2079@tuxdriver.com>
On Tuesday 27 April 2010 08:23:33 you wrote:
> On Tue, Apr 27, 2010 at 01:23:35AM +0200, Felix Fietkau wrote:
> > This is used to configure APs to not bridge traffic between connected
> > stations.
> >
> > Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>
> Is this useful?
oh, yes! especially when you set up hotspots for internet access only.
bruno
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: add ap isolation support
From: Felix Fietkau @ 2010-04-26 23:30 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, johannes
In-Reply-To: <20100426232332.GA2079@tuxdriver.com>
On 2010-04-27 1:23 AM, John W. Linville wrote:
> On Tue, Apr 27, 2010 at 01:23:35AM +0200, Felix Fietkau wrote:
>> This is used to configure APs to not bridge traffic between connected stations.
>>
>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>
> Is this useful?
Yes, if you have an AP with lots of users that aren't expected to
communicate with each other (e.g. only for internet access), it can save
a lot of airtime by not forwarding every broadcast message emitted from
any station.
I'm sure there are a more situations where this can be useful.
- Felix
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: add ap isolation support
From: John W. Linville @ 2010-04-26 23:23 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, johannes
In-Reply-To: <1272324216-73349-1-git-send-email-nbd@openwrt.org>
On Tue, Apr 27, 2010 at 01:23:35AM +0200, Felix Fietkau wrote:
> This is used to configure APs to not bridge traffic between connected stations.
>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Is this useful?
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH 1/2] cfg80211: add ap isolation support
From: Felix Fietkau @ 2010-04-26 23:23 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, johannes, Felix Fietkau
This is used to configure APs to not bridge traffic between connected stations.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
include/linux/nl80211.h | 5 +++++
include/net/cfg80211.h | 2 ++
net/wireless/nl80211.c | 4 ++++
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 2ea3ede..f8750f9 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -709,6 +709,9 @@ enum nl80211_commands {
* NL80211_CMD_AUTHENTICATE, NL80211_CMD_DEAUTHENTICATE,
* NL80211_CMD_DISASSOCIATE.
*
+ * @NL80211_ATTR_AP_ISOLATE: (AP mode) Do not forward traffic between stations
+ * connected to this BSS.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -864,6 +867,8 @@ enum nl80211_attrs {
NL80211_ATTR_LOCAL_STATE_CHANGE,
+ NL80211_ATTR_AP_ISOLATE,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 5a4efe5..f6b29bf 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -511,6 +511,7 @@ struct mpath_info {
* @basic_rates: basic rates in IEEE 802.11 format
* (or NULL for no change)
* @basic_rates_len: number of basic rates
+ * @ap_isolate: do not forward packets between connected stations
*/
struct bss_parameters {
int use_cts_prot;
@@ -518,6 +519,7 @@ struct bss_parameters {
int use_short_slot_time;
u8 *basic_rates;
u8 basic_rates_len;
+ int ap_isolate;
};
struct mesh_config {
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 356a84a..01da83d 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -152,6 +152,7 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_PS_STATE] = { .type = NLA_U32 },
[NL80211_ATTR_CQM] = { .type = NLA_NESTED, },
[NL80211_ATTR_LOCAL_STATE_CHANGE] = { .type = NLA_FLAG },
+ [NL80211_ATTR_AP_ISOLATE] = { .type = NLA_U8 },
};
/* policy for the attributes */
@@ -2442,6 +2443,7 @@ static int nl80211_set_bss(struct sk_buff *skb, struct genl_info *info)
params.use_cts_prot = -1;
params.use_short_preamble = -1;
params.use_short_slot_time = -1;
+ params.ap_isolate = -1;
if (info->attrs[NL80211_ATTR_BSS_CTS_PROT])
params.use_cts_prot =
@@ -2458,6 +2460,8 @@ static int nl80211_set_bss(struct sk_buff *skb, struct genl_info *info)
params.basic_rates_len =
nla_len(info->attrs[NL80211_ATTR_BSS_BASIC_RATES]);
}
+ if (info->attrs[NL80211_ATTR_AP_ISOLATE])
+ params.ap_isolate = !!nla_get_u8(info->attrs[NL80211_ATTR_AP_ISOLATE]);
rtnl_lock();
--
1.6.4.2
^ permalink raw reply related
* [PATCH 2/2] mac80211: implement ap isolation support
From: Felix Fietkau @ 2010-04-26 23:23 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, johannes, Felix Fietkau
In-Reply-To: <1272324216-73349-1-git-send-email-nbd@openwrt.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
net/mac80211/cfg.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 845a6e6..b6fed60 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1115,6 +1115,13 @@ static int ieee80211_change_bss(struct wiphy *wiphy,
changed |= BSS_CHANGED_BASIC_RATES;
}
+ if (params->ap_isolate >= 0) {
+ if (params->ap_isolate)
+ sdata->flags |= IEEE80211_SDATA_DONT_BRIDGE_PACKETS;
+ else
+ sdata->flags &= ~IEEE80211_SDATA_DONT_BRIDGE_PACKETS;
+ }
+
ieee80211_bss_info_change_notify(sdata, changed);
return 0;
--
1.6.4.2
^ permalink raw reply related
* [PATCH v2] mac80211: fix handling of 4-address-mode in ieee80211_change_iface
From: Felix Fietkau @ 2010-04-26 22:26 UTC (permalink / raw)
To: linux-wireless; +Cc: Pavel Roskin, John W. Linville, Johannes Berg
In-Reply-To: <1272318607.22987.2.camel@mj>
A misplaced interface type check bails out too early if the interface
is not in monitor mode. This patch moves it to the right place, so that
it only covers changes to the monitor flags.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
---
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -97,9 +97,6 @@ static int ieee80211_change_iface(struct
params->mesh_id_len,
params->mesh_id);
- if (sdata->vif.type != NL80211_IFTYPE_MONITOR || !flags)
- return 0;
-
if (type == NL80211_IFTYPE_AP_VLAN &&
params && params->use_4addr == 0)
rcu_assign_pointer(sdata->u.vlan.sta, NULL);
@@ -107,7 +104,9 @@ static int ieee80211_change_iface(struct
params && params->use_4addr >= 0)
sdata->u.mgd.use_4addr = params->use_4addr;
- sdata->u.mntr_flags = *flags;
+ if (sdata->vif.type == NL80211_IFTYPE_MONITOR && flags)
+ sdata->u.mntr_flags = *flags;
+
return 0;
}
^ permalink raw reply
* Re: [PATCH] mac80211: fix handling of 4-address-mode in ieee80211_change_iface
From: Pavel Roskin @ 2010-04-26 21:50 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, John W. Linville, Johannes Berg
In-Reply-To: <4BD5D34F.8080205@openwrt.org>
On Mon, 2010-04-26 at 19:54 +0200, Felix Fietkau wrote:
> A misplaced interface type check bails out too early if the interface
> is not in monitor mode. This patch moves it to the right place, so that
> it only covers changes to the monitor flags.
...
> + if (sdata->vif.type != NL80211_IFTYPE_MONITOR || !flags)
> + return 0;
> +
> sdata->u.mntr_flags = *flags;
> return 0;
> }
Perhaps you could write it in a more readable way:
if (sdata->vif.type == NL80211_IFTYPE_MONITOR && flags)
sdata->u.mntr_flags = *flags;
return 0;
Just an idea, not an objection.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] rt2x00: rt2800lib: Fix rx path on SoC devices
From: Gertjan van Wingerde @ 2010-04-26 21:46 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, Ivo van Doorn, linux-wireless
In-Reply-To: <201004261348.45044.helmut.schaa@googlemail.com>
On 04/26/10 13:48, Helmut Schaa wrote:
> Restore the rfcsr initialization for RT305x SoC devices which was removed
> by "rt2x00: Finish rt3070 support in rt2800 register initialization.".
>
> This fixes the rx path on SoC devices.
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 34 ++++++++++++++++++++++++++++++-
> 1 files changed, 33 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index 2648f31..1358d9a 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -1703,7 +1703,8 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> if (!rt2x00_rt(rt2x00dev, RT3070) &&
> !rt2x00_rt(rt2x00dev, RT3071) &&
> !rt2x00_rt(rt2x00dev, RT3090) &&
> - !rt2x00_rt(rt2x00dev, RT3390))
> + !rt2x00_rt(rt2x00dev, RT3390) &&
> + !(rt2x00_is_soc(rt2x00dev) && rt2x00_rt(rt2x00dev, RT2872)))
> return 0;
As indicated in the separate email, we should also check for the presence of an RF3020, RF3021
or RF3022 RF chipset for the RT2872 case (maybe this should be more generic, because I'm sure
this will also hold for the other RT chipsets).
>
> /*
> @@ -1771,6 +1772,37 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> rt2800_rfcsr_write(rt2x00dev, 29, 0x8f);
> rt2800_rfcsr_write(rt2x00dev, 30, 0x20);
> rt2800_rfcsr_write(rt2x00dev, 31, 0x0f);
> + } else if (rt2x00_rt(rt2x00dev, RT2872)) {
> + rt2800_rfcsr_write(rt2x00dev, 0, 0x50);
> + rt2800_rfcsr_write(rt2x00dev, 1, 0x01);
> + rt2800_rfcsr_write(rt2x00dev, 2, 0xf7);
> + rt2800_rfcsr_write(rt2x00dev, 3, 0x75);
> + rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
> + rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
> + rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
> + rt2800_rfcsr_write(rt2x00dev, 7, 0x50);
> + rt2800_rfcsr_write(rt2x00dev, 8, 0x39);
> + rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
> + rt2800_rfcsr_write(rt2x00dev, 10, 0x60);
> + rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
> + rt2800_rfcsr_write(rt2x00dev, 12, 0x75);
> + rt2800_rfcsr_write(rt2x00dev, 13, 0x75);
> + rt2800_rfcsr_write(rt2x00dev, 14, 0x90);
> + rt2800_rfcsr_write(rt2x00dev, 15, 0x58);
> + rt2800_rfcsr_write(rt2x00dev, 16, 0xb3);
> + rt2800_rfcsr_write(rt2x00dev, 17, 0x92);
> + rt2800_rfcsr_write(rt2x00dev, 18, 0x2c);
> + rt2800_rfcsr_write(rt2x00dev, 19, 0x02);
> + rt2800_rfcsr_write(rt2x00dev, 20, 0xba);
> + rt2800_rfcsr_write(rt2x00dev, 21, 0xdb);
> + rt2800_rfcsr_write(rt2x00dev, 22, 0x00);
> + rt2800_rfcsr_write(rt2x00dev, 23, 0x31);
> + rt2800_rfcsr_write(rt2x00dev, 24, 0x08);
> + rt2800_rfcsr_write(rt2x00dev, 25, 0x01);
> + rt2800_rfcsr_write(rt2x00dev, 26, 0x25);
> + rt2800_rfcsr_write(rt2x00dev, 27, 0x23);
> + rt2800_rfcsr_write(rt2x00dev, 28, 0x13);
> + rt2800_rfcsr_write(rt2x00dev, 29, 0x83);
> }
>
> if (rt2x00_rt_rev_lt(rt2x00dev, RT3070, REV_RT3070F)) {
Here we need 2 additional rfcsr_writes, for RF CSR 30 and RF CSR 31, both set to value 0x00.
Also, we can add an "return 0" at the end of the sequence, as nothing more needs to be done for RT2872.
---
Gertjan.
^ permalink raw reply
* Re: [PATCH 6/9] rt2x00: Finish rt3070 support in rt2800 register initialization.
From: Gertjan van Wingerde @ 2010-04-26 21:43 UTC (permalink / raw)
To: Helmut Schaa
Cc: John W. Linville, Ivo van Doorn, linux-wireless, users,
Luis Correia
In-Reply-To: <201004262159.34077.helmut.schaa@googlemail.com>
On 04/26/10 21:59, Helmut Schaa wrote:
> Am Montag 26 April 2010 schrieb Gertjan van Wingerde:
>> On 04/26/10 13:02, Helmut Schaa wrote:
>>> Am Sonntag 11 April 2010 schrieb Gertjan van Wingerde:
<snip>
>>>
>>> This part is actually needed for getting rx to work on the SoC devices.
>>
>> Hmm, interesting, as I don't know where this code actually came from. It isn't needed for
>> PCI devices in general (at least not the PCI devices I've checked), so it may be specific to SoC.
>>
>>>
>>> Should I post a patch that adds this code again and is only executed on SoC
>>> devices with rf3020, 3021 and 3022?
>>>
>>
>> OK. I have just checked the two RT2872 based devices I have (one PCI one and one USB one),
>> and both of them act very strangely.
>
> Strangely ;) ? The SoC device was basically able to transmit frames but
> could't receive at all (at least that was my impression). Do you have a
> different issue?
Turns out I forgot to enable the PCIe one in my AP's ACL, so it simply was refused by the AP.
This card now works perfectly without your patch. Now, the difference is that my RT2872 is actually
accompanied by an RF2720 RF chipset, so there is a difference there.
>
>> I'll check against the Ralink SoC driver code that I've got as to how the initialization should actually
>> be.
>
> Ok.
>
The Ralink SoC driver code that I have follows exactly the procedure that was removed. So, I guess the original
code came from there, but it actually isn't needed for RT2860 devices. The Ralink code only runs this when an
RT2872 revision 0x0200 is accompanied with an RF3020, an RF3021 or an RF3022. For the benefit of correctness
I suggest we mimmick this in rt2x00, and only execute the sequence in those cases.
And, BTW, we can stop RF CSR initialization right after programming these static values. The Ralink driver doesn't
do anything else as well.
Finally, the Ralink driver has two more RF CSR writes in this sequence. It writes the value 0x00 to both RF CSR 30
and RF CSR 31. I suggest we add that to the sequence that will be added to rt2x00.
--
Gertjan.
^ permalink raw reply
* Re: [PATCH PING] ssb patches for SPROM location
From: John W. Linville @ 2010-04-26 21:03 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: Larry Finger, linux-wireless
In-Reply-To: <h2vb170af451004261249k43377e65n9d85f6dc7c377e67@mail.gmail.com>
On Mon, Apr 26, 2010 at 09:49:02PM +0200, Rafał Miłecki wrote:
> 2010/4/26 John W. Linville <linville@tuxdriver.com>:
> > P.S. With those patches, this box (soon to be Larry's) still uses
> > an sprom_offset value of 0x1000.
>
> Hm, so it looks like you device doesn't match our "if (version)"
> condition... It's just a blind guess, but maybe it would be worth to
> *force* other SPROM location on your machine? It seems quite proven
> that reading some incorrect registers (in this case incorrect SPROM
> location) can cause lock up. Of course it's just my guess, assuming
> you have other SPROM location, lock up is caused by reading wrong
> register and that Larry's condition in incorrect/not full. However if
> you're gonna to send whole machine to Larry, it sounds worthy to check
> this trick.
Well I thought I had done that before, but apparently not. I forced
sprom_offset to 0x0800 and ssb and b43 both load and act like they
are working. OTOH, b43 doesn't seem to be passing traffic but I may
just not have the right firmware...?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] rt2x00: remove usage of deprecated noise value
From: Gertjan van Wingerde @ 2010-04-26 20:46 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1272312567-22853-1-git-send-email-linville@tuxdriver.com>
On 04/26/10 22:09, John W. Linville wrote:
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> drivers/net/wireless/rt2x00/rt2x00dev.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
> index b93731b..33c2f5f 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00dev.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
> @@ -434,7 +434,6 @@ void rt2x00lib_rxdone(struct rt2x00_dev *rt2x00dev,
> rx_status->mactime = rxdesc.timestamp;
> rx_status->rate_idx = rate_idx;
> rx_status->signal = rxdesc.rssi;
> - rx_status->noise = rxdesc.noise;
> rx_status->flag = rxdesc.flags;
> rx_status->antenna = rt2x00dev->link.ant.active.rx;
>
This could actually go further than just this, as the noise field of rxdesc is only used for this
purpose, so it can actually be removed as well.
However, I guess that can be done as a follow-up, so:
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
^ permalink raw reply
* [PATCH] ath9k: remove usage of deprecated noise value
From: John W. Linville @ 2010-04-26 20:09 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ath/ath9k/common.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c
index 09effde..b4424a6 100644
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -212,7 +212,6 @@ int ath9k_cmn_rx_skb_preprocess(struct ath_common *common,
rx_status->mactime = ath9k_hw_extend_tsf(ah, rx_stats->rs_tstamp);
rx_status->band = hw->conf.channel->band;
rx_status->freq = hw->conf.channel->center_freq;
- rx_status->noise = common->ani.noise_floor;
rx_status->signal = ATH_DEFAULT_NOISE_FLOOR + rx_stats->rs_rssi;
rx_status->antenna = rx_stats->rs_antenna;
rx_status->flag |= RX_FLAG_TSFT;
--
1.6.6.1
^ permalink raw reply related
* [PATCH] p54: remove usage of deprecated noise value
From: John W. Linville @ 2010-04-26 20:09 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/p54/txrx.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/p54/txrx.c b/drivers/net/wireless/p54/txrx.c
index 2ceff54..4e68910 100644
--- a/drivers/net/wireless/p54/txrx.c
+++ b/drivers/net/wireless/p54/txrx.c
@@ -350,7 +350,6 @@ static int p54_rx_data(struct p54_common *priv, struct sk_buff *skb)
rx_status->flag |= RX_FLAG_MMIC_ERROR;
rx_status->signal = p54_rssi_to_dbm(priv, hdr->rssi);
- rx_status->noise = priv->noise;
if (hdr->rate & 0x10)
rx_status->flag |= RX_FLAG_SHORTPRE;
if (priv->hw->conf.channel->band == IEEE80211_BAND_5GHZ)
--
1.6.6.1
^ permalink raw reply related
* [PATCH] b43: remove usage of deprecated noise value
From: John W. Linville @ 2010-04-26 20:09 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/b43/xmit.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/b43/xmit.c b/drivers/net/wireless/b43/xmit.c
index eda0652..e6b0528 100644
--- a/drivers/net/wireless/b43/xmit.c
+++ b/drivers/net/wireless/b43/xmit.c
@@ -610,7 +610,6 @@ void b43_rx(struct b43_wldev *dev, struct sk_buff *skb, const void *_rxhdr)
}
/* Link quality statistics */
- status.noise = dev->stats.link_noise;
if ((chanstat & B43_RX_CHAN_PHYTYPE) == B43_PHYTYPE_N) {
// s8 rssi = max(rxhdr->power0, rxhdr->power1);
//TODO: Find out what the rssi value is (dBm or percentage?)
--
1.6.6.1
^ permalink raw reply related
* [PATCH] rt2x00: remove usage of deprecated noise value
From: John W. Linville @ 2010-04-26 20:09 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/rt2x00/rt2x00dev.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index b93731b..33c2f5f 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -434,7 +434,6 @@ void rt2x00lib_rxdone(struct rt2x00_dev *rt2x00dev,
rx_status->mactime = rxdesc.timestamp;
rx_status->rate_idx = rate_idx;
rx_status->signal = rxdesc.rssi;
- rx_status->noise = rxdesc.noise;
rx_status->flag = rxdesc.flags;
rx_status->antenna = rt2x00dev->link.ant.active.rx;
--
1.6.6.1
^ permalink raw reply related
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