* [PATCH] iwlwifi: recalculate average tpt if not current
From: reinette chatre @ 2010-05-03 17:55 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless@vger.kernel.org, johannes, Adel Gadllah
In-Reply-To: <1272908934.7879.5748.camel@rchatre-DESK>
From: Reinette Chatre <reinette.chatre@intel.com>
We currently have this check as a BUG_ON, which is being hit by people.
Previously it was an error with a recalculation if not current, return that
code.
The BUG_ON was introduced by:
commit 3110bef78cb4282c58245bc8fd6d95d9ccb19749
Author: Guy Cohen <guy.cohen@intel.com>
Date: Tue Sep 9 10:54:54 2008 +0800
iwlwifi: Added support for 3 antennas
... the portion adding the BUG_ON is reverted since we are encountering the error
and BUG_ON was created with assumption that error is not encountered.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
index b93e491..75a145c 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
@@ -2070,10 +2070,12 @@ static void rs_rate_scale_perform(struct iwl_priv *priv,
}
/* Else we have enough samples; calculate estimate of
* actual average throughput */
-
- /* Sanity-check TPT calculations */
- BUG_ON(window->average_tpt != ((window->success_ratio *
- tbl->expected_tpt[index] + 64) / 128));
+ if (window->average_tpt != ((window->success_ratio *
+ tbl->expected_tpt[index] + 64) / 128)) {
+ IWL_ERR(priv, "expected_tpt should have been calculated by now\n");
+ window->average_tpt = ((window->success_ratio *
+ tbl->expected_tpt[index] + 64) / 128);
+ }
/* If we are searching for better modulation mode, check success. */
if (lq_sta->search_better_tbl &&
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] iwlagn: Change the TPT calculations sanity-check to WARN_ON
From: reinette chatre @ 2010-05-03 17:48 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org, johill@sipsolutions.net,
Adel Gadllah
In-Reply-To: <1272907549-25847-1-git-send-email-linville@tuxdriver.com>
On Mon, 2010-05-03 at 10:25 -0700, John W. Linville wrote:
> From: Adel Gadllah <adel.gadllah@gmail.com>
>
> Currently it is a BUG_ON() which will hang the machine once triggered.
>
> (Changed from WARN_ON to WARN_ON_ONCE. -- JWL)
>
> Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
I can see a potential race condition here in the calculation of the
average throughput so a BUG_ON seems extreme.
I looked at the history of this code and it seems as though the BUG_ON was
added as a sidenote to a patch implementing something else.
The patch adding this BUG_ON is:
commit 3110bef78cb4282c58245bc8fd6d95d9ccb19749
Author: Guy Cohen <guy.cohen@intel.com>
Date: Tue Sep 9 10:54:54 2008 +0800
iwlwifi: Added support for 3 antennas
... and it thus seems as though this BUG_ON was added along the way while doing
something else ... especially considering that the comments describing the
original code has not been removed yet. Since the current code still contains:
/* Else we have enough samples; calculate estimate of
* actual average throughput */
.. .which is obviously not done right now.
I looked at the original code and think we can revert the portion of this patch
adding the BUG_ON. Since users have not encountered the error I assume the
author considered that a BUG_ON was warranted, but now we know that users do
indeed encounter the error and we should return the original code.
I'll send the revert as a separate patch.
Reinette
^ permalink raw reply
* [PATCH] iwlagn: Change the TPT calculations sanity-check to WARN_ON
From: John W. Linville @ 2010-05-03 17:25 UTC (permalink / raw)
To: linux-wireless; +Cc: johill, reinette.chatre, Adel Gadllah, John W. Linville
From: Adel Gadllah <adel.gadllah@gmail.com>
Currently it is a BUG_ON() which will hang the machine once triggered.
(Changed from WARN_ON to WARN_ON_ONCE. -- JWL)
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
index 8f8d5e3..ca63ff9 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
@@ -2079,8 +2079,9 @@ static void rs_rate_scale_perform(struct iwl_priv *priv,
* actual average throughput */
/* Sanity-check TPT calculations */
- BUG_ON(window->average_tpt != ((window->success_ratio *
- tbl->expected_tpt[index] + 64) / 128));
+ if (WARN_ON_ONCE(window->average_tpt != ((window->success_ratio *
+ tbl->expected_tpt[index] + 64) / 128)))
+ return;
/* If we are searching for better modulation mode, check success. */
if (lq_sta->search_better_tbl &&
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH] wireless: rt2x00: delete duplicates ids in rt73usb rt2500usb
From: Xose Vazquez Perez @ 2010-05-03 17:28 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: Ivo van Doorn, linux-wireless, users, linville
In-Reply-To: <j2z14add3d11004061506q8b45b003ucbb3537cda763b58@mail.gmail.com>
On 04/07/2010 12:06 AM, Gertjan van Wingerde wrote:
> On Tue, Apr 6, 2010 at 11:28 PM, Ivo van Doorn <ivdoorn@gmail.com> wrote:
>> On Tuesday 06 April 2010, Xose Vazquez Perez wrote:
>>> Follow the precepts of the ralink drivers.
>>>
>>> (0x050d, 0x7050) is only found in:
>>>
>>> RT25USB-SRC-V2.0.8.0/rt2570sw.h:#define RTVID8 0x050D //ralink
>>> RT25USB-SRC-V2.0.8.0/rt2570sw.h:#define RTPID8 0x7050
>>> RT25USB-SRC-V2.0.8.0/rt2570sw.h: {USB_DEVICE(RTVID8,RTPID8)},
>>>
>>> and (0x050d, 0x705a) (0x1371, 0x9022) (0x148f, 0x2573) are only in:
>>>
>>> 2009_0713_RT73_Linux_STA_Drv1.1.0.3/Module/rtmp_def.h: {USB_DEVICE(0x050d,0x705a)}, /* Belkin */
>>> 2009_0713_RT73_Linux_STA_Drv1.1.0.3/Module/rtmp_def.h: {USB_DEVICE(0x1371,0x9022)}, /* CNet */
>>> 2009_0713_RT73_Linux_STA_Drv1.1.0.3/Module/rtmp_def.h: {USB_DEVICE(0x148f,0x2573)}, /* Ralink */
>>>
>>> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
>>
>> I have my doubts about this one.
>> Gertjan, do you consider it wise to remove these ID's?
>>
>
> Yes, I have my doubts here as well. We know about overlap in USB IDs
> between rt2500 and rt73 devices,
> and these could very well be these devices.
>
> However, if Ralink doesn't have this overlap in their devices, then
> why should we care.
>
> Xose, can you verify with the Windows drivers whether the situation on
> the USB IDs is the same as for the
> Ralink Linux drivers?
OK, here it goes:
W = Windows:ralink_driver
L = Linux:ralink_driver
USB_IDs W_73 W_2500 L_73 L_2500
============= ==== ====== ==== ======
0x050d,0x7050 - - - YES
0x050d,0x705a - - YES -
0x1371,0x9022 - YES YES -
0x148f,0x2573 YES - YES -
--
«Allá muevan feroz guerra, ciegos reyes por un palmo más de tierra;
que yo aquí tengo por mío cuanto abarca el mar bravío, a quien nadie
impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor,
que no sienta mi derecho y dé pecho a mi valor.»
^ permalink raw reply
* Re: [ANN] Mendiosus rt2800usb project
From: John W. Linville @ 2010-05-03 16:52 UTC (permalink / raw)
To: info; +Cc: linux-wireless, rt2x00 Users List
In-Reply-To: <38430.62.163.0.236.1272900540.squirrel@www.mendiosus.nl>
On Mon, May 03, 2010 at 05:29:00PM +0200, info@mendiosus.nl wrote:
> The Dutch company Mendiosus is pleased to announce that, with support
> of an United States based open-source development house, it will
> be working on the rt2800usb drivers. Development will focus on
> improving support for the rt2870 and rt2770 chipsets.
> Besides improvements of the basic functionality development will also
> focus on adding hardware cryptography and better 11n support.
Excellent! I look forward to seeing some good results from this!
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 USB-ID 148f:2573 from rt2500usb driver
From: rain_maker @ 2010-05-03 16:53 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
In-Reply-To: <20100503154745.GB24781@tuxdriver.com>
Am Monday 03 May 2010 17:47:46 schrieben Sie:
>
> http://osdir.com/ml/linux-wireless/2009-07/msg00267.html
>
> This seems to be such an example?
Yeah, I also found that one before, but the message about missing firmware
(which is the most common user's error with rt73usb) and lack of feedback
from the person opening the thread if rt2500usb got the device working made
it "inconclusive" to me.
But maybe this is the main reason one finds so many threads about problems
with this device id and rt73usb being the correct driver.
If it works out of the box (no matter which driver), nobody starts a thread,
if it doesn't work, in most cases it's missing firmware and if rt2500usb
works instead of rt73usb, you can't miss that as it does not need
installation of extra firmware.
I CCed Ivo instead of first sending him this mail only personally, because
although I knew he would be the most likely person to know if my idea was
good or bad (which was exactly what happened), I expected that if there
really are a few devices with 148f:2573 needing rt2500usb instead of rt73usb,
the more likely somebody else actually will know about such a (rare)
exception.
Maybe that was not too clever, sorry for this rather useless thread.
Greetings,
Axel K
^ permalink raw reply
* [ANN] Mendiosus rt2800usb project
From: info @ 2010-05-03 15:29 UTC (permalink / raw)
To: linux-wireless, rt2x00 Users List
The Dutch company Mendiosus is pleased to announce that, with support
of an United States based open-source development house, it will
be working on the rt2800usb drivers. Development will focus on
improving support for the rt2870 and rt2770 chipsets.
Besides improvements of the basic functionality development will also
focus on adding hardware cryptography and better 11n support.
Mendiosus is a Software Development company based in
Haarlem, The Netherlands. It was founded by Ivo van Doorn in
April 2010 and offers software development services for its customers.
Ivo van Doorn
Mendiosus
^ permalink raw reply
* Re: [PATCH] rt2x00: remove USB-ID 148f:2573 from rt2500usb driver
From: John W. Linville @ 2010-05-03 15:47 UTC (permalink / raw)
To: rain_maker@root-forum.org; +Cc: linux-wireless
In-Reply-To: <201005031720.36288.rain_maker@root-forum.org>
On Mon, May 03, 2010 at 05:20:36PM +0200, rain_maker@root-forum.org wrote:
> Am Monday 03 May 2010 16:58:16 schrieben Sie:
> > So I'm curious, how can you be sure that 148f:2573 is _always_ wrong
> > for rt2500usb? I do acknowledge that the "73" part makes it suspicious...
> But of course the problem in such cases is, you can't prove it, you can only
> add more and more examples for "not being wrong" while finding one example
> where actually a device with 148f:2573 working with rt2500usb und not working
> with rt73usb would prove me wrong once and for all.
http://osdir.com/ml/linux-wireless/2009-07/msg00267.html
This seems to be such an example?
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 USB-ID 148f:2573 from rt2500usb driver
From: Ivo Van Doorn @ 2010-05-03 15:30 UTC (permalink / raw)
To: Johannes Berg; +Cc: rain_maker@root-forum.org, linux-wireless
In-Reply-To: <1272900556.3614.42.camel@jlt3.sipsolutions.net>
On 5/3/10, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Mon, 2010-05-03 at 17:13 +0200, Ivo Van Doorn wrote:
>> > This trivial patch removes the id 148f:2573 from rt2500usb driver.
>
>> The ID is confusing indeed, but unfortunately we can't remove this ID,
>> since in the early days people did report they had to use the rt2500usb
>> driver
>> for these devices. So the majority of devices with this ID is indeed
>> rt73usb, but not for all.
>
> Since this seems to come up every couple of weeks, and none of us will
> always be around to remember and answer it, how about capturing that in
> a comment in the code? :)
Good point. :)
I;ll send a patch later today.
Ivo
^ permalink raw reply
* Re: [PATCH] rt2x00: remove USB-ID 148f:2573 from rt2500usb driver
From: Johannes Berg @ 2010-05-03 15:29 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: rain_maker@root-forum.org, linux-wireless
In-Reply-To: <v2wa32f33a41005030813m36cbea0blf3963369a934cdac@mail.gmail.com>
On Mon, 2010-05-03 at 17:13 +0200, Ivo Van Doorn wrote:
> > This trivial patch removes the id 148f:2573 from rt2500usb driver.
> The ID is confusing indeed, but unfortunately we can't remove this ID,
> since in the early days people did report they had to use the rt2500usb driver
> for these devices. So the majority of devices with this ID is indeed
> rt73usb, but not for all.
Since this seems to come up every couple of weeks, and none of us will
always be around to remember and answer it, how about capturing that in
a comment in the code? :)
johannes
^ permalink raw reply
* Re: [PATCH] rt2x00: remove USB-ID 148f:2573 from rt2500usb driver
From: rain_maker @ 2010-05-03 15:20 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
In-Reply-To: <20100503145815.GA24781@tuxdriver.com>
Am Monday 03 May 2010 16:58:16 schrieben Sie:
> I also get more than 100 hits from (probably the same) well-known
> search engine for "rt73usb_init_eeprom: Error - Invalid RT chipset
> detected". I'm sure those aren't all for the same USB ID, and perhaps
> none of them are. Then again, not all of the 1500+ that you cite
> are for the same USB ID either.
Well, of course I can't be 100% sure, I had this patch "in storage" for a long
time and already applied it so some packages I build, but hesitated for quite
a while if I should submit it.
Additionally, the search string was not too good, it would have been better to
cite this one here
148f:2573 rt2500usb_init_eeprom: Error
(about 500 hits)
>
> So I'm curious, how can you be sure that 148f:2573 is _always_ wrong
> for rt2500usb? I do acknowledge that the "73" part makes it suspicious...
>
As I am active in several fora and read quite a few more, I stumbled over this
annoyance (as I said it is not a fatal error) for several times in the past
few months/years and in all cases I know rt73usb was the working driver.
But of course the problem in such cases is, you can't prove it, you can only
add more and more examples for "not being wrong" while finding one example
where actually a device with 148f:2573 working with rt2500usb und not working
with rt73usb would prove me wrong once and for all.
Best wishes,
Axel K
^ permalink raw reply
* Re: [PATCH] rt2x00: remove USB-ID 148f:2573 from rt2500usb driver
From: Ivo Van Doorn @ 2010-05-03 15:13 UTC (permalink / raw)
To: rain_maker@root-forum.org; +Cc: linux-wireless
In-Reply-To: <201005031624.45409.rain_maker@root-forum.org>
On 5/3/10, rain_maker@root-forum.org <rain_maker@root-forum.org> wrote:
> The drivers rt2500usb and rt73usb both contain the usb id 148f:2573 while
> only
> the latter is suitable for devices with that id.
>
> As a consequence, both drivers will be loaded and system log shows messages
> like "rt2500usb_init_eeprom: Error - Invalid RT chipset detected".
>
> If you use the above search term, you will find more than 1500 hits with a
> well known search engine, confirming that rt2500usb is always the wrong
> driver for devices with usb id 148f:2573 and quite often as a side effect
> confusion arose about this -non fatal but misleading- error message in the
> respective bug reports or threads.
>
> This trivial patch removes the id 148f:2573 from rt2500usb driver.
>
> Signed-off-by: Axel Koellhofer <rain_maker@root-forum.org>
NACK
The ID is confusing indeed, but unfortunately we can't remove this ID,
since in the early days people did report they had to use the rt2500usb driver
for these devices. So the majority of devices with this ID is indeed
rt73usb, but
not for all.
Ivo
^ permalink raw reply
* Re: [PATCH] rt2x00: remove USB-ID 148f:2573 from rt2500usb driver
From: John W. Linville @ 2010-05-03 14:58 UTC (permalink / raw)
To: rain_maker@root-forum.org; +Cc: linux-wireless, Ivo van Doorn
In-Reply-To: <201005031624.45409.rain_maker@root-forum.org>
On Mon, May 03, 2010 at 04:24:45PM +0200, rain_maker@root-forum.org wrote:
> The drivers rt2500usb and rt73usb both contain the usb id 148f:2573 while only
> the latter is suitable for devices with that id.
>
> As a consequence, both drivers will be loaded and system log shows messages
> like "rt2500usb_init_eeprom: Error - Invalid RT chipset detected".
>
> If you use the above search term, you will find more than 1500 hits with a
> well known search engine, confirming that rt2500usb is always the wrong
> driver for devices with usb id 148f:2573 and quite often as a side effect
> confusion arose about this -non fatal but misleading- error message in the
> respective bug reports or threads.
I also get more than 100 hits from (probably the same) well-known
search engine for "rt73usb_init_eeprom: Error - Invalid RT chipset
detected". I'm sure those aren't all for the same USB ID, and perhaps
none of them are. Then again, not all of the 1500+ that you cite
are for the same USB ID either.
So I'm curious, how can you be sure that 148f:2573 is _always_ wrong
for rt2500usb? I do acknowledge that the "73" part makes it suspicious...
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
* [PATCH] rt2x00: remove USB-ID 148f:2573 from rt2500usb driver
From: rain_maker @ 2010-05-03 14:24 UTC (permalink / raw)
To: linux-wireless; +Cc: Ivo van Doorn
The drivers rt2500usb and rt73usb both contain the usb id 148f:2573 while only
the latter is suitable for devices with that id.
As a consequence, both drivers will be loaded and system log shows messages
like "rt2500usb_init_eeprom: Error - Invalid RT chipset detected".
If you use the above search term, you will find more than 1500 hits with a
well known search engine, confirming that rt2500usb is always the wrong
driver for devices with usb id 148f:2573 and quite often as a side effect
confusion arose about this -non fatal but misleading- error message in the
respective bug reports or threads.
This trivial patch removes the id 148f:2573 from rt2500usb driver.
Signed-off-by: Axel Koellhofer <rain_maker@root-forum.org>
---
diff -Naur a/drivers/net/wireless/rt2x00/rt2500usb.c
b/drivers/net/wireless/rt2x00/rt2500usb.c
--- a/drivers/net/wireless/rt2x00/rt2500usb.c 2010-05-03 16:03:29.572101896
+0200
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c 2010-05-03 16:03:51.902854565
+0200
@@ -1879,7 +1879,6 @@
/* Ralink */
{ USB_DEVICE(0x148f, 0x1706), USB_DEVICE_DATA(&rt2500usb_ops) },
{ USB_DEVICE(0x148f, 0x2570), USB_DEVICE_DATA(&rt2500usb_ops) },
- { USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt2500usb_ops) },
{ USB_DEVICE(0x148f, 0x9020), USB_DEVICE_DATA(&rt2500usb_ops) },
/* Sagem */
{ USB_DEVICE(0x079b, 0x004b), USB_DEVICE_DATA(&rt2500usb_ops) },
^ permalink raw reply
* Re: [PATCH] mac80211: improve IBSS scanning
From: Johannes Berg @ 2010-05-03 14:13 UTC (permalink / raw)
To: Joerg Pommnitz; +Cc: linux-wireless
In-Reply-To: <loom.20100503T160346-724@post.gmane.org>
On Mon, 2010-05-03 at 14:08 +0000, Joerg Pommnitz wrote:
> Johannes Berg <johannes@...> writes:
> >
> > Interesting. I guess we never rejected it although it's invalid
> > according to the standard. Yuck. I think I would like to make nl80211
> > reject it, but maybe I'll forget about it and let you use it ;)
>
> Sorry, I don't know about mac80211. This was more a general point.
> I thought this woudn't work at all but a co-worker was adamant that
> it works fine with Madwifi. So I sat down and observed it with
> a monitoring interface and lo and behold: The beacons really contained
> the broadcast SSID.
Oh ok. I didn't see anything in cfg80211 but will check and post a
patch :)
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: improve IBSS scanning
From: Joerg Pommnitz @ 2010-05-03 14:08 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1272895062.3614.39.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@...> writes:
>
> Interesting. I guess we never rejected it although it's invalid
> according to the standard. Yuck. I think I would like to make nl80211
> reject it, but maybe I'll forget about it and let you use it ;)
Sorry, I don't know about mac80211. This was more a general point.
I thought this woudn't work at all but a co-worker was adamant that
it works fine with Madwifi. So I sat down and observed it with
a monitoring interface and lo and behold: The beacons really contained
the broadcast SSID.
^ permalink raw reply
* Re: [PATCH] mac80211: improve IBSS scanning
From: Johannes Berg @ 2010-05-03 13:57 UTC (permalink / raw)
To: Joerg Pommnitz; +Cc: linux-wireless
In-Reply-To: <loom.20100503T154149-617@post.gmane.org>
On Mon, 2010-05-03 at 13:43 +0000, Joerg Pommnitz wrote:
> Johannes Berg <johannes@...> writes:
> > Hidden SSID is a hack (which doesn't work with IBSS obviously), but this
> > kinda seems worse.
>
> Actually, it does (work on IBSS, that is). And because I thought what you think
> I have the
> radiotap traces to prove it.
Interesting. I guess we never rejected it although it's invalid
according to the standard. Yuck. I think I would like to make nl80211
reject it, but maybe I'll forget about it and let you use it ;)
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: improve IBSS scanning
From: Joerg Pommnitz @ 2010-05-03 13:43 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <loom.20100503T153803-630@post.gmane.org>
Johannes Berg <johannes@...> writes:
> Hidden SSID is a hack (which doesn't work with IBSS obviously), but this
> kinda seems worse.
Actually, it does (work on IBSS, that is). And because I thought what you think
I have the
radiotap traces to prove it.
^ permalink raw reply
* Re: [PATCH] mac80211: improve IBSS scanning
From: Joerg Pommnitz @ 2010-05-03 13:40 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1272893084.3614.37.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@...> writes:
> Hidden SSID is a hack (which doesn't work with IBSS obviously), but this
> kinda seems worse.
Actually, it does. And because I thought what you think I have the
radiotap traces to prove it. :-)
> Seriously though, why should the upstream kernel support such bad design
> decisions...? :)
Well, because this topic comes up every few months. It seems there
are other people who are attached to AH-demo for their very own reasons.
Regards
Joerg
^ permalink raw reply
* Re: [PATCH] mac80211: improve IBSS scanning
From: Johannes Berg @ 2010-05-03 13:24 UTC (permalink / raw)
To: Joerg Pommnitz; +Cc: linux-wireless
In-Reply-To: <469051.90774.qm@web51402.mail.re2.yahoo.com>
On Mon, 2010-05-03 at 06:20 -0700, Joerg Pommnitz wrote:
> > WHY is it required for you? And yeah, I _am_ still opposed
> > to that.
>
> Please don't laugh! Really, don't!
>
> We have an embedded system that normally uses an IBSS network
> as a delivery system (can be deployed for field measurements).
> Some customers were unhappy that the networks could be detected
> on WLAN snoopers like Netstumbler. The quick and dirty solution
> to make the networks invisible was using the AH-demo mode.
>
> Now "invisible on Netstumbler" is an advertised feature that
> must be maintained for ever after (the GUI has a checkbox
> "hide from Netstumbler").
Ok ... I'll go improve netstumbler instead of laughing ... if there's
any traffic it can trivially be detected anyway, so what's the point?
Hidden SSID is a hack (which doesn't work with IBSS obviously), but this
kinda seems worse.
Seriously though, why should the upstream kernel support such bad design
decisions...? :)
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: improve IBSS scanning
From: Joerg Pommnitz @ 2010-05-03 13:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1272892320.3614.34.camel@jlt3.sipsolutions.net>
> WHY is it required for you? And yeah, I _am_ still opposed
> to that.
Please don't laugh! Really, don't!
We have an embedded system that normally uses an IBSS network
as a delivery system (can be deployed for field measurements).
Some customers were unhappy that the networks could be detected
on WLAN snoopers like Netstumbler. The quick and dirty solution
to make the networks invisible was using the AH-demo mode.
Now "invisible on Netstumbler" is an advertised feature that
must be maintained for ever after (the GUI has a checkbox
"hide from Netstumbler").
Regards
Joerg
^ permalink raw reply
* Re: [PATCH] mac80211: improve IBSS scanning
From: Johannes Berg @ 2010-05-03 13:12 UTC (permalink / raw)
To: Joerg Pommnitz; +Cc: linux-wireless
In-Reply-To: <loom.20100503T150104-147@post.gmane.org>
On Mon, 2010-05-03 at 13:10 +0000, Joerg Pommnitz wrote:
> Johannes Berg <johannes@...> writes:
> > Note that this can be further improved to start
> > the IBSS right away if both frequency and BSSID
> > are fixed.
>
> Doing this and switching off beaconing would be the same as
> the infamous AH-Demo mode supported by Madwifi and creeping
> into the current kernel, no?
and switching of beaconing. Don't think we want that.
> see http://madwifi-project.org/wiki/UserDocs/AhdemoInterface
> and HTC_M_AHDEMO in enum htc_opmode.
>
> For me, AH-Demo is required to ditch Madwifi, so are you still
> opposed to its integration? It seems that the pieces of the
> puzzle are almost there now.
WHY is it required for you? And yeah, I _am_ still opposed to that.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: improve IBSS scanning
From: Joerg Pommnitz @ 2010-05-03 13:10 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1272869388.3614.0.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@...> writes:
> Note that this can be further improved to start
> the IBSS right away if both frequency and BSSID
> are fixed.
Doing this and switching off beaconing would be the same as
the infamous AH-Demo mode supported by Madwifi and creeping
into the current kernel, no?
see http://madwifi-project.org/wiki/UserDocs/AhdemoInterface
and HTC_M_AHDEMO in enum htc_opmode.
For me, AH-Demo is required to ditch Madwifi, so are you still
opposed to its integration? It seems that the pieces of the
puzzle are almost there now.
Regards
Joerg
^ permalink raw reply
* [PATCH 1/1] wireless: rt2x00: rt2800usb: be in sync with latest windows drivers.
From: Xose Vazquez Perez @ 2010-05-03 11:11 UTC (permalink / raw)
To: linux-wireless; +Cc: users, linville, IvDoorn, gwingerde, xose.vazquez
0x07d1,0x3c17 D-Link Wireless N 150 USB Adapter DWA-125
0x1b75,0x3071 Ovislink Airlive WN-301USB
0x1d4d,0x0011 Pegatron Ralink RT3072 802.11b/g/n Wireless Lan USB Device
0x083a,0xf511 Arcadyan 802.11 USB Wireless LAN Card
0x13d3,0x3322 AzureWave 802.11 n/g/b USB Wireless LAN Card
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800usb.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 95c8a61..df82b52 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -1027,7 +1027,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
#ifdef CONFIG_RT2800USB_UNKNOWN
/*
* Unclear what kind of devices these are (they aren't supported by the
- * vendor driver).
+ * vendor linux driver).
*/
/* Amigo */
{ USB_DEVICE(0x0e0b, 0x9031), USB_DEVICE_DATA(&rt2800usb_ops) },
@@ -1040,6 +1040,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
/* AzureWave */
{ USB_DEVICE(0x13d3, 0x3262), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x13d3, 0x3284), USB_DEVICE_DATA(&rt2800usb_ops) },
+ { USB_DEVICE(0x13d3, 0x3322), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Belkin */
{ USB_DEVICE(0x050d, 0x825a), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Buffalo */
@@ -1058,6 +1059,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x07d1, 0x3c0b), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x07d1, 0x3c13), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x07d1, 0x3c15), USB_DEVICE_DATA(&rt2800usb_ops) },
+ { USB_DEVICE(0x07d1, 0x3c17), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Encore */
{ USB_DEVICE(0x203d, 0x14a1), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Gemtek */
@@ -1074,11 +1076,13 @@ static struct usb_device_id rt2800usb_device_table[] = {
/* Motorola */
{ USB_DEVICE(0x100d, 0x9032), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Ovislink */
+ { USB_DEVICE(0x1b75, 0x3071), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x1b75, 0x3072), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Pegatron */
{ USB_DEVICE(0x05a6, 0x0101), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x1d4d, 0x0002), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x1d4d, 0x0010), USB_DEVICE_DATA(&rt2800usb_ops) },
+ { USB_DEVICE(0x1d4d, 0x0011), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Planex */
{ USB_DEVICE(0x2019, 0xab24), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Qcom */
@@ -1087,6 +1091,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x083a, 0xa512), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x083a, 0xc522), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x083a, 0xd522), USB_DEVICE_DATA(&rt2800usb_ops) },
+ { USB_DEVICE(0x083a, 0xf511), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Sweex */
{ USB_DEVICE(0x177f, 0x0153), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x177f, 0x0313), USB_DEVICE_DATA(&rt2800usb_ops) },
--
1.6.6.1
^ permalink raw reply related
* [PATCH] mac80211_hwsim: fix double-scan detection
From: Johannes Berg @ 2010-05-03 7:21 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Luis R. Rodriguez
Currently, hwsim will always detect a double scan
after the first one has finished ...
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
drivers/net/wireless/mac80211_hwsim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- wireless-testing.orig/drivers/net/wireless/mac80211_hwsim.c 2010-05-03 09:19:54.000000000 +0200
+++ wireless-testing/drivers/net/wireless/mac80211_hwsim.c 2010-05-03 09:20:01.000000000 +0200
@@ -1021,7 +1021,7 @@ static void mac80211_hwsim_sw_scan_compl
mutex_lock(&hwsim->mutex);
printk(KERN_DEBUG "hwsim sw_scan_complete\n");
- hwsim->scanning = true;
+ hwsim->scanning = false;
mutex_unlock(&hwsim->mutex);
}
^ 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