* 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
* [RFC/RFT] cfg80211/mac80211: better channel handling
From: Johannes Berg @ 2010-05-03 7:12 UTC (permalink / raw)
To: linux-wireless
Currently (all tested with hwsim) you can do stupid
things like setting up an AP on a certain channel,
then adding another virtual interface and making
that associate on another channel -- this will make
the beaconing to move channel but obviously without
the necessary IEs data update.
In order to improve this situation, first make the
configuration APIs (cfg80211 and nl80211) aware of
multi-channel operation -- we'll eventually need
that in the future anyway. There's one userland API
change and one API addition. The API change is that
now SET_WIPHY must be called with virtual interface
index rather than only wiphy index in order to take
effect for that interface -- luckily all current
users (hostapd) do that. For monitor interfaces, the
old setting is preserved, but monitors are always
slaved to other devices anyway so no guarantees.
The second userland API change is the introduction
of a per virtual interface SET_CHANNEL command, that
hostapd should use going forward to make it easier
to understand what's going on (it can automatically
detect a kernel with this command).
Other than mac80211, no existing cfg80211 drivers
are affected by this change because they only allow
a single virtual interface.
mac80211, however, now needs to be aware that the
channel settings are per interface now, and needs
to disallow (for now) real multi-channel operation,
which is another important part of this patch.
One of the immediate benefits is that you can now
start hostapd to operate on a hardware that already
has a connection on another virtual interface, as
long as you specify the same channel.
Note that two things are left unhandled (this is an
improvement -- not a complete fix):
* different HT/no-HT modes
currently you could start an HT AP and then
connect to a non-HT network on the same channel
which would configure the hardware for no HT;
that can be fixed fairly easily
* CSA
An AP we're connected to on a virtual interface
might indicate switching channels, and in that
case we would follow it, regardless of how many
other interfaces are operating; this requires
more effort to fix but is pretty rare after all
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
PLEASE test, especially all the monitoring people. I've done various
tests and it feels like a great improvement, and certainly shouldn't
really change anything in the typical 'single-interface' mode.
I'm going to subject this to some more testing, and post it for
inclusion in the next couple of days if all goes well, so there's your
chance :)
drivers/net/wireless/libertas/cfg.c | 1
drivers/net/wireless/orinoco/cfg.c | 1
drivers/net/wireless/rndis_wlan.c | 4
include/linux/nl80211.h | 13 ++
include/net/cfg80211.h | 11 +-
net/mac80211/Makefile | 3
net/mac80211/cfg.c | 41 +++++++++
net/mac80211/chan.c | 57 ++++++++++++
net/mac80211/ieee80211_i.h | 11 ++
net/wireless/chan.c | 56 +++---------
net/wireless/core.h | 12 --
net/wireless/ibss.c | 5 -
net/wireless/nl80211.c | 163 +++++++++++++++++++++++++++---------
net/wireless/sme.c | 5 -
net/wireless/wext-compat.c | 15 ++-
net/wireless/wext-sme.c | 2
16 files changed, 291 insertions(+), 109 deletions(-)
--- wireless-testing.orig/include/linux/nl80211.h 2010-05-02 17:47:47.000000000 +0200
+++ wireless-testing/include/linux/nl80211.h 2010-05-02 17:47:51.000000000 +0200
@@ -52,6 +52,8 @@
* %NL80211_ATTR_WIPHY_CHANNEL_TYPE, %NL80211_ATTR_WIPHY_RETRY_SHORT,
* %NL80211_ATTR_WIPHY_RETRY_LONG, %NL80211_ATTR_WIPHY_FRAG_THRESHOLD,
* and/or %NL80211_ATTR_WIPHY_RTS_THRESHOLD.
+ * However, for setting the channel, see %NL80211_CMD_SET_CHANNEL
+ * instead, the support here is for backward compatibility only.
* @NL80211_CMD_NEW_WIPHY: Newly created wiphy, response to get request
* or rename notification. Has attributes %NL80211_ATTR_WIPHY and
* %NL80211_ATTR_WIPHY_NAME.
@@ -329,6 +331,15 @@
* @NL80211_CMD_NOTIFY_CQM: Connection quality monitor notification. This
* command is used as an event to indicate the that a trigger level was
* reached.
+ * @NL80211_CMD_SET_CHANNEL: Set the channel (using %NL80211_ATTR_WIPHY_FREQ
+ * and %NL80211_ATTR_WIPHY_CHANNEL_TYPE) the given interface (identifed
+ * by %NL80211_ATTR_IFINDEX) shall operate on.
+ * In case multiple channels are supported by the device, the mechanism
+ * with which it switches channels is implementation-defined.
+ * When a monitor interface is given, it can only switch channel while
+ * no other interfaces are operating to avoid disturbing the operation
+ * of any other interfaces, and other interfaces will again take
+ * precedence when they are used.
*
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
@@ -428,6 +439,8 @@ enum nl80211_commands {
NL80211_CMD_SET_CQM,
NL80211_CMD_NOTIFY_CQM,
+ NL80211_CMD_SET_CHANNEL,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
--- wireless-testing.orig/net/wireless/nl80211.c 2010-05-02 17:47:47.000000000 +0200
+++ wireless-testing/net/wireless/nl80211.c 2010-05-02 17:47:51.000000000 +0200
@@ -689,10 +689,90 @@ static int parse_txq_params(struct nlatt
return 0;
}
+static bool nl80211_can_set_dev_channel(struct wireless_dev *wdev)
+{
+ /*
+ * You can only set the channel explicitly for AP, mesh
+ * and WDS type interfaces; all others have their channel
+ * managed via their respective "establish a connection"
+ * command (connect, join, ...)
+ *
+ * Monitors are special as they are normally slaved to
+ * whatever else is going on, so they behave as though
+ * you tried setting the wiphy channel itself.
+ */
+ return !wdev ||
+ wdev->iftype == NL80211_IFTYPE_AP ||
+ wdev->iftype == NL80211_IFTYPE_WDS ||
+ wdev->iftype == NL80211_IFTYPE_MESH_POINT ||
+ wdev->iftype == NL80211_IFTYPE_MONITOR;
+}
+
+static int __nl80211_set_channel(struct cfg80211_registered_device *rdev,
+ struct wireless_dev *wdev,
+ struct genl_info *info)
+{
+ enum nl80211_channel_type channel_type = NL80211_CHAN_NO_HT;
+ u32 freq;
+ int result;
+
+ if (!info->attrs[NL80211_ATTR_WIPHY_FREQ])
+ return -EINVAL;
+
+ if (!nl80211_can_set_dev_channel(wdev))
+ return -EOPNOTSUPP;
+
+ if (info->attrs[NL80211_ATTR_WIPHY_CHANNEL_TYPE]) {
+ channel_type = nla_get_u32(info->attrs[
+ NL80211_ATTR_WIPHY_CHANNEL_TYPE]);
+ if (channel_type != NL80211_CHAN_NO_HT &&
+ channel_type != NL80211_CHAN_HT20 &&
+ channel_type != NL80211_CHAN_HT40PLUS &&
+ channel_type != NL80211_CHAN_HT40MINUS)
+ return -EINVAL;
+ }
+
+ freq = nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_FREQ]);
+
+ mutex_lock(&rdev->devlist_mtx);
+ if (wdev) {
+ wdev_lock(wdev);
+ result = cfg80211_set_freq(rdev, wdev, freq, channel_type);
+ wdev_unlock(wdev);
+ } else {
+ result = cfg80211_set_freq(rdev, NULL, freq, channel_type);
+ }
+ mutex_unlock(&rdev->devlist_mtx);
+
+ return result;
+}
+
+static int nl80211_set_channel(struct sk_buff *skb, struct genl_info *info)
+{
+ struct cfg80211_registered_device *rdev;
+ struct net_device *netdev;
+ int result;
+
+ rtnl_lock();
+
+ result = get_rdev_dev_by_info_ifindex(info, &rdev, &netdev);
+ if (result)
+ goto unlock;
+
+ result = __nl80211_set_channel(rdev, netdev->ieee80211_ptr, info);
+
+ unlock:
+ rtnl_unlock();
+
+ return result;
+}
+
static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
{
struct cfg80211_registered_device *rdev;
- int result = 0, rem_txq_params = 0;
+ struct net_device *netdev;
+ struct wireless_dev *wdev;
+ int result, rem_txq_params = 0;
struct nlattr *nl_txq_params;
u32 changed;
u8 retry_short = 0, retry_long = 0;
@@ -701,16 +781,41 @@ static int nl80211_set_wiphy(struct sk_b
rtnl_lock();
+ /*
+ * Try to find the wiphy and netdev. Normally this
+ * function shouldn't need the netdev, but this is
+ * done for backward compatibility -- previously
+ * setting the channel was done per wiphy, but now
+ * it is per netdev. Previous userland like hostapd
+ * also passed a netdev to set_wiphy, so that it is
+ * possible to let that go to the right netdev!
+ */
+ result = get_rdev_dev_by_info_ifindex(info, &rdev, &netdev);
+
mutex_lock(&cfg80211_mutex);
+ if (result) {
+ rdev = __cfg80211_rdev_from_info(info);
+ if (IS_ERR(rdev)) {
+ mutex_unlock(&cfg80211_mutex);
+ result = PTR_ERR(rdev);
+ goto unlock;
+ }
+ wdev = NULL;
+ netdev = NULL;
+ result = 0;
+
+ mutex_lock(&rdev->mtx);
+ } else if (netif_running(netdev) &&
+ nl80211_can_set_dev_channel(netdev->ieee80211_ptr))
+ wdev = netdev->ieee80211_ptr;
+ else
+ wdev = NULL;
- rdev = __cfg80211_rdev_from_info(info);
- if (IS_ERR(rdev)) {
- mutex_unlock(&cfg80211_mutex);
- result = PTR_ERR(rdev);
- goto unlock;
- }
+ /*
+ * end workaround code, by now the rdev is available
+ * and locked, and wdev may or may not be NULL
+ */
- mutex_lock(&rdev->mtx);
if (info->attrs[NL80211_ATTR_WIPHY_NAME])
result = cfg80211_dev_rename(
@@ -749,26 +854,7 @@ static int nl80211_set_wiphy(struct sk_b
}
if (info->attrs[NL80211_ATTR_WIPHY_FREQ]) {
- enum nl80211_channel_type channel_type = NL80211_CHAN_NO_HT;
- u32 freq;
-
- result = -EINVAL;
-
- if (info->attrs[NL80211_ATTR_WIPHY_CHANNEL_TYPE]) {
- channel_type = nla_get_u32(info->attrs[
- NL80211_ATTR_WIPHY_CHANNEL_TYPE]);
- if (channel_type != NL80211_CHAN_NO_HT &&
- channel_type != NL80211_CHAN_HT20 &&
- channel_type != NL80211_CHAN_HT40PLUS &&
- channel_type != NL80211_CHAN_HT40MINUS)
- goto bad_res;
- }
-
- freq = nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_FREQ]);
-
- mutex_lock(&rdev->devlist_mtx);
- result = rdev_set_freq(rdev, NULL, freq, channel_type);
- mutex_unlock(&rdev->devlist_mtx);
+ result = __nl80211_set_channel(rdev, wdev, info);
if (result)
goto bad_res;
}
@@ -865,6 +951,8 @@ static int nl80211_set_wiphy(struct sk_b
bad_res:
mutex_unlock(&rdev->mtx);
+ if (netdev)
+ dev_put(netdev);
unlock:
rtnl_unlock();
return result;
@@ -3562,9 +3650,8 @@ static int nl80211_associate(struct sk_b
{
struct cfg80211_registered_device *rdev;
struct net_device *dev;
- struct wireless_dev *wdev;
struct cfg80211_crypto_settings crypto;
- struct ieee80211_channel *chan, *fixedchan;
+ struct ieee80211_channel *chan;
const u8 *bssid, *ssid, *ie = NULL, *prev_bssid = NULL;
int err, ssid_len, ie_len = 0;
bool use_mfp = false;
@@ -3607,16 +3694,6 @@ static int nl80211_associate(struct sk_b
goto out;
}
- mutex_lock(&rdev->devlist_mtx);
- wdev = dev->ieee80211_ptr;
- fixedchan = rdev_fixed_channel(rdev, wdev);
- if (fixedchan && chan != fixedchan) {
- err = -EBUSY;
- mutex_unlock(&rdev->devlist_mtx);
- goto out;
- }
- mutex_unlock(&rdev->devlist_mtx);
-
ssid = nla_data(info->attrs[NL80211_ATTR_SSID]);
ssid_len = nla_len(info->attrs[NL80211_ATTR_SSID]);
@@ -5186,6 +5263,12 @@ static struct genl_ops nl80211_ops[] = {
.policy = nl80211_policy,
.flags = GENL_ADMIN_PERM,
},
+ {
+ .cmd = NL80211_CMD_SET_CHANNEL,
+ .doit = nl80211_set_channel,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+ },
};
static struct genl_multicast_group nl80211_mlme_mcgrp = {
--- wireless-testing.orig/include/net/cfg80211.h 2010-05-02 17:47:47.000000000 +0200
+++ wireless-testing/include/net/cfg80211.h 2010-05-02 17:47:51.000000000 +0200
@@ -966,7 +966,11 @@ struct cfg80211_pmksa {
*
* @set_txq_params: Set TX queue parameters
*
- * @set_channel: Set channel
+ * @set_channel: Set channel for a given wireless interface. Some devices
+ * may support multi-channel operation (by channel hopping) so cfg80211
+ * doesn't verify much. Note, however, that the passed netdev may be
+ * %NULL as well if the user requested changing the channel for the
+ * device itself, or for a monitor interface.
*
* @scan: Request to do a scan. If returning zero, the scan request is given
* the driver, and will be valid until passed to cfg80211_scan_done().
@@ -1095,7 +1099,7 @@ struct cfg80211_ops {
int (*set_txq_params)(struct wiphy *wiphy,
struct ieee80211_txq_params *params);
- int (*set_channel)(struct wiphy *wiphy,
+ int (*set_channel)(struct wiphy *wiphy, struct net_device *dev,
struct ieee80211_channel *chan,
enum nl80211_channel_type channel_type);
@@ -1461,6 +1465,8 @@ struct cfg80211_cached_keys;
* @list: (private) Used to collect the interfaces
* @netdev: (private) Used to reference back to the netdev
* @current_bss: (private) Used by the internal configuration code
+ * @channel: (private) Used by the internal configuration code to track
+ * user-set AP, monitor and WDS channels for wireless extensions
* @bssid: (private) Used by the internal configuration code
* @ssid: (private) Used by the internal configuration code
* @ssid_len: (private) Used by the internal configuration code
@@ -1507,6 +1513,7 @@ struct wireless_dev {
struct cfg80211_internal_bss *authtry_bsses[MAX_AUTH_BSSES];
struct cfg80211_internal_bss *auth_bsses[MAX_AUTH_BSSES];
struct cfg80211_internal_bss *current_bss; /* associated / joined */
+ struct ieee80211_channel *channel;
bool ps;
int ps_timeout;
--- wireless-testing.orig/net/wireless/chan.c 2010-05-02 17:47:47.000000000 +0200
+++ wireless-testing/net/wireless/chan.c 2010-05-02 17:47:51.000000000 +0200
@@ -10,38 +10,6 @@
#include "core.h"
struct ieee80211_channel *
-rdev_fixed_channel(struct cfg80211_registered_device *rdev,
- struct wireless_dev *for_wdev)
-{
- struct wireless_dev *wdev;
- struct ieee80211_channel *result = NULL;
-
- WARN_ON(!mutex_is_locked(&rdev->devlist_mtx));
-
- list_for_each_entry(wdev, &rdev->netdev_list, list) {
- if (wdev == for_wdev)
- continue;
-
- /*
- * Lock manually to tell lockdep about allowed
- * nesting here if for_wdev->mtx is held already.
- * This is ok as it's all under the rdev devlist
- * mutex and as such can only be done once at any
- * given time.
- */
- mutex_lock_nested(&wdev->mtx, SINGLE_DEPTH_NESTING);
- if (wdev->current_bss)
- result = wdev->current_bss->pub.channel;
- wdev_unlock(wdev);
-
- if (result)
- break;
- }
-
- return result;
-}
-
-struct ieee80211_channel *
rdev_freq_to_chan(struct cfg80211_registered_device *rdev,
int freq, enum nl80211_channel_type channel_type)
{
@@ -75,15 +43,22 @@ rdev_freq_to_chan(struct cfg80211_regist
return chan;
}
-int rdev_set_freq(struct cfg80211_registered_device *rdev,
- struct wireless_dev *for_wdev,
- int freq, enum nl80211_channel_type channel_type)
+int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
+ struct wireless_dev *wdev, int freq,
+ enum nl80211_channel_type channel_type)
{
struct ieee80211_channel *chan;
int result;
- if (rdev_fixed_channel(rdev, for_wdev))
- return -EBUSY;
+ if (wdev->iftype == NL80211_IFTYPE_MONITOR)
+ wdev = NULL;
+
+ if (wdev) {
+ ASSERT_WDEV_LOCK(wdev);
+
+ if (!netif_running(wdev->netdev))
+ return -ENETDOWN;
+ }
if (!rdev->ops->set_channel)
return -EOPNOTSUPP;
@@ -92,11 +67,14 @@ int rdev_set_freq(struct cfg80211_regist
if (!chan)
return -EINVAL;
- result = rdev->ops->set_channel(&rdev->wiphy, chan, channel_type);
+ result = rdev->ops->set_channel(&rdev->wiphy,
+ wdev ? wdev->netdev : NULL,
+ chan, channel_type);
if (result)
return result;
- rdev->channel = chan;
+ if (wdev)
+ wdev->channel = chan;
return 0;
}
--- wireless-testing.orig/net/wireless/core.h 2010-05-02 17:47:47.000000000 +0200
+++ wireless-testing/net/wireless/core.h 2010-05-02 17:47:51.000000000 +0200
@@ -70,9 +70,6 @@ struct cfg80211_registered_device {
struct work_struct conn_work;
struct work_struct event_work;
- /* current channel */
- struct ieee80211_channel *channel;
-
/* must be last because of the way we do wiphy_priv(),
* and it should at least be aligned to NETDEV_ALIGN */
struct wiphy wiphy __attribute__((__aligned__(NETDEV_ALIGN)));
@@ -388,14 +385,11 @@ int cfg80211_change_iface(struct cfg8021
void cfg80211_process_rdev_events(struct cfg80211_registered_device *rdev);
struct ieee80211_channel *
-rdev_fixed_channel(struct cfg80211_registered_device *rdev,
- struct wireless_dev *for_wdev);
-struct ieee80211_channel *
rdev_freq_to_chan(struct cfg80211_registered_device *rdev,
int freq, enum nl80211_channel_type channel_type);
-int rdev_set_freq(struct cfg80211_registered_device *rdev,
- struct wireless_dev *for_wdev,
- int freq, enum nl80211_channel_type channel_type);
+int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
+ struct wireless_dev *wdev, int freq,
+ enum nl80211_channel_type channel_type);
u16 cfg80211_calculate_bitrate(struct rate_info *rate);
--- wireless-testing.orig/net/wireless/wext-compat.c 2010-05-02 17:47:47.000000000 +0200
+++ wireless-testing/net/wireless/wext-compat.c 2010-05-02 17:47:51.000000000 +0200
@@ -782,16 +782,22 @@ int cfg80211_wext_siwfreq(struct net_dev
return cfg80211_mgd_wext_siwfreq(dev, info, wextfreq, extra);
case NL80211_IFTYPE_ADHOC:
return cfg80211_ibss_wext_siwfreq(dev, info, wextfreq, extra);
- default:
+ case NL80211_IFTYPE_MONITOR:
+ case NL80211_IFTYPE_WDS:
+ case NL80211_IFTYPE_MESH_POINT:
freq = cfg80211_wext_freq(wdev->wiphy, wextfreq);
if (freq < 0)
return freq;
if (freq == 0)
return -EINVAL;
+ wdev_lock(wdev);
mutex_lock(&rdev->devlist_mtx);
- err = rdev_set_freq(rdev, NULL, freq, NL80211_CHAN_NO_HT);
+ err = cfg80211_set_freq(rdev, wdev, freq, NL80211_CHAN_NO_HT);
mutex_unlock(&rdev->devlist_mtx);
+ wdev_unlock(wdev);
return err;
+ default:
+ return -EOPNOTSUPP;
}
}
EXPORT_SYMBOL_GPL(cfg80211_wext_siwfreq);
@@ -801,7 +807,6 @@ int cfg80211_wext_giwfreq(struct net_dev
struct iw_freq *freq, char *extra)
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
- struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
switch (wdev->iftype) {
case NL80211_IFTYPE_STATION:
@@ -809,9 +814,9 @@ int cfg80211_wext_giwfreq(struct net_dev
case NL80211_IFTYPE_ADHOC:
return cfg80211_ibss_wext_giwfreq(dev, info, freq, extra);
default:
- if (!rdev->channel)
+ if (!wdev->channel)
return -EINVAL;
- freq->m = rdev->channel->center_freq;
+ freq->m = wdev->channel->center_freq;
freq->e = 6;
return 0;
}
--- wireless-testing.orig/net/wireless/wext-sme.c 2010-05-02 17:47:47.000000000 +0200
+++ wireless-testing/net/wireless/wext-sme.c 2010-05-02 17:47:51.000000000 +0200
@@ -108,7 +108,7 @@ int cfg80211_mgd_wext_siwfreq(struct net
/* SSID is not set, we just want to switch channel */
if (chan && !wdev->wext.connect.ssid_len) {
- err = rdev_set_freq(rdev, wdev, freq, NL80211_CHAN_NO_HT);
+ err = cfg80211_set_freq(rdev, wdev, freq, NL80211_CHAN_NO_HT);
goto out;
}
--- wireless-testing.orig/net/wireless/ibss.c 2010-05-02 17:47:47.000000000 +0200
+++ wireless-testing/net/wireless/ibss.c 2010-05-02 17:47:51.000000000 +0200
@@ -81,15 +81,10 @@ int __cfg80211_join_ibss(struct cfg80211
struct cfg80211_cached_keys *connkeys)
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
- struct ieee80211_channel *chan;
int err;
ASSERT_WDEV_LOCK(wdev);
- chan = rdev_fixed_channel(rdev, wdev);
- if (chan && chan != params->channel)
- return -EBUSY;
-
if (wdev->ssid_len)
return -EALREADY;
--- wireless-testing.orig/net/wireless/sme.c 2010-05-02 17:47:47.000000000 +0200
+++ wireless-testing/net/wireless/sme.c 2010-05-02 17:47:51.000000000 +0200
@@ -741,7 +741,6 @@ int __cfg80211_connect(struct cfg80211_r
const u8 *prev_bssid)
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
- struct ieee80211_channel *chan;
struct cfg80211_bss *bss = NULL;
int err;
@@ -750,10 +749,6 @@ int __cfg80211_connect(struct cfg80211_r
if (wdev->sme_state != CFG80211_SME_IDLE)
return -EALREADY;
- chan = rdev_fixed_channel(rdev, wdev);
- if (chan && chan != connect->channel)
- return -EBUSY;
-
if (WARN_ON(wdev->connect_keys)) {
kfree(wdev->connect_keys);
wdev->connect_keys = NULL;
--- wireless-testing.orig/drivers/net/wireless/libertas/cfg.c 2010-05-02 17:47:48.000000000 +0200
+++ wireless-testing/drivers/net/wireless/libertas/cfg.c 2010-05-02 17:47:51.000000000 +0200
@@ -79,6 +79,7 @@ static const u32 cipher_suites[] = {
static int lbs_cfg_set_channel(struct wiphy *wiphy,
+ struct net_device *netdev,
struct ieee80211_channel *chan,
enum nl80211_channel_type channel_type)
{
--- wireless-testing.orig/drivers/net/wireless/orinoco/cfg.c 2010-05-02 17:47:47.000000000 +0200
+++ wireless-testing/drivers/net/wireless/orinoco/cfg.c 2010-05-02 17:47:51.000000000 +0200
@@ -159,6 +159,7 @@ static int orinoco_scan(struct wiphy *wi
}
static int orinoco_set_channel(struct wiphy *wiphy,
+ struct net_device *netdev,
struct ieee80211_channel *chan,
enum nl80211_channel_type channel_type)
{
--- wireless-testing.orig/drivers/net/wireless/rndis_wlan.c 2010-05-02 17:47:47.000000000 +0200
+++ wireless-testing/drivers/net/wireless/rndis_wlan.c 2010-05-02 17:47:51.000000000 +0200
@@ -535,7 +535,7 @@ static int rndis_join_ibss(struct wiphy
static int rndis_leave_ibss(struct wiphy *wiphy, struct net_device *dev);
-static int rndis_set_channel(struct wiphy *wiphy,
+static int rndis_set_channel(struct wiphy *wiphy, struct net_device *dev,
struct ieee80211_channel *chan, enum nl80211_channel_type channel_type);
static int rndis_add_key(struct wiphy *wiphy, struct net_device *netdev,
@@ -2291,7 +2291,7 @@ static int rndis_leave_ibss(struct wiphy
return deauthenticate(usbdev);
}
-static int rndis_set_channel(struct wiphy *wiphy,
+static int rndis_set_channel(struct wiphy *wiphy, struct net_device *netdev,
struct ieee80211_channel *chan, enum nl80211_channel_type channel_type)
{
struct rndis_wlan_private *priv = wiphy_priv(wiphy);
--- wireless-testing.orig/net/mac80211/cfg.c 2010-05-02 17:47:47.000000000 +0200
+++ wireless-testing/net/mac80211/cfg.c 2010-05-02 17:47:51.000000000 +0200
@@ -1162,11 +1162,24 @@ static int ieee80211_set_txq_params(stru
}
static int ieee80211_set_channel(struct wiphy *wiphy,
+ struct net_device *netdev,
struct ieee80211_channel *chan,
enum nl80211_channel_type channel_type)
{
struct ieee80211_local *local = wiphy_priv(wiphy);
+ switch (ieee80211_get_channel_mode(local, NULL)) {
+ case CHAN_MODE_HOPPING:
+ return -EBUSY;
+ case CHAN_MODE_FIXED:
+ if (local->oper_channel == chan &&
+ local->oper_channel_type == channel_type)
+ return 0;
+ return -EBUSY;
+ case CHAN_MODE_UNDEFINED:
+ break;
+ }
+
local->oper_channel = chan;
local->oper_channel_type = channel_type;
@@ -1214,6 +1227,20 @@ static int ieee80211_auth(struct wiphy *
static int ieee80211_assoc(struct wiphy *wiphy, struct net_device *dev,
struct cfg80211_assoc_request *req)
{
+ struct ieee80211_local *local = wiphy_priv(wiphy);
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+
+ switch (ieee80211_get_channel_mode(local, sdata)) {
+ case CHAN_MODE_HOPPING:
+ return -EBUSY;
+ case CHAN_MODE_FIXED:
+ if (local->oper_channel == req->bss->channel)
+ break;
+ return -EBUSY;
+ case CHAN_MODE_UNDEFINED:
+ break;
+ }
+
return ieee80211_mgd_assoc(IEEE80211_DEV_TO_SUB_IF(dev), req);
}
@@ -1236,8 +1263,22 @@ static int ieee80211_disassoc(struct wip
static int ieee80211_join_ibss(struct wiphy *wiphy, struct net_device *dev,
struct cfg80211_ibss_params *params)
{
+ struct ieee80211_local *local = wiphy_priv(wiphy);
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ switch (ieee80211_get_channel_mode(local, sdata)) {
+ case CHAN_MODE_HOPPING:
+ return -EBUSY;
+ case CHAN_MODE_FIXED:
+ if (!params->channel_fixed)
+ return -EBUSY;
+ if (local->oper_channel == params->channel)
+ break;
+ return -EBUSY;
+ case CHAN_MODE_UNDEFINED:
+ break;
+ }
+
return ieee80211_ibss_join(sdata, params);
}
--- wireless-testing.orig/net/mac80211/Makefile 2010-05-02 17:47:47.000000000 +0200
+++ wireless-testing/net/mac80211/Makefile 2010-05-02 17:47:51.000000000 +0200
@@ -23,7 +23,8 @@ mac80211-y := \
key.o \
util.o \
wme.o \
- event.o
+ event.o \
+ chan.o
mac80211-$(CONFIG_MAC80211_LEDS) += led.o
mac80211-$(CONFIG_MAC80211_DEBUGFS) += \
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ wireless-testing/net/mac80211/chan.c 2010-05-02 17:47:51.000000000 +0200
@@ -0,0 +1,57 @@
+/*
+ * mac80211 - channel management
+ */
+
+#include "ieee80211_i.h"
+
+enum ieee80211_chan_mode
+__ieee80211_get_channel_mode(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *ignore)
+{
+ struct ieee80211_sub_if_data *sdata;
+
+ WARN_ON(!mutex_is_locked(&local->iflist_mtx));
+
+ list_for_each_entry(sdata, &local->interfaces, list) {
+ if (sdata == ignore)
+ continue;
+
+ if (!ieee80211_sdata_running(sdata))
+ continue;
+
+ if (sdata->vif.type == NL80211_IFTYPE_MONITOR)
+ continue;
+
+ if (sdata->vif.type == NL80211_IFTYPE_STATION &&
+ !sdata->u.mgd.associated)
+ continue;
+
+ if (sdata->vif.type == NL80211_IFTYPE_ADHOC) {
+ if (!sdata->u.ibss.ssid_len)
+ continue;
+ if (!sdata->u.ibss.fixed_channel)
+ return CHAN_MODE_HOPPING;
+ }
+
+ if (sdata->vif.type == NL80211_IFTYPE_AP &&
+ !sdata->u.ap.beacon)
+ continue;
+
+ return CHAN_MODE_FIXED;
+ }
+
+ return CHAN_MODE_UNDEFINED;
+}
+
+enum ieee80211_chan_mode
+ieee80211_get_channel_mode(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *ignore)
+{
+ enum ieee80211_chan_mode mode;
+
+ mutex_lock(&local->iflist_mtx);
+ mode = __ieee80211_get_channel_mode(local, ignore);
+ mutex_unlock(&local->iflist_mtx);
+
+ return mode;
+}
--- wireless-testing.orig/net/mac80211/ieee80211_i.h 2010-05-02 17:47:50.000000000 +0200
+++ wireless-testing/net/mac80211/ieee80211_i.h 2010-05-02 17:47:51.000000000 +0200
@@ -1229,6 +1229,17 @@ int ieee80211_wk_remain_on_channel(struc
int ieee80211_wk_cancel_remain_on_channel(
struct ieee80211_sub_if_data *sdata, u64 cookie);
+/* channel management */
+enum ieee80211_chan_mode {
+ CHAN_MODE_UNDEFINED,
+ CHAN_MODE_HOPPING,
+ CHAN_MODE_FIXED,
+};
+
+enum ieee80211_chan_mode
+ieee80211_get_channel_mode(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *ignore);
+
#ifdef CONFIG_MAC80211_NOINLINE
#define debug_noinline noinline
#else
^ permalink raw reply
* [PATCH] mac80211: improve IBSS scanning
From: Johannes Berg @ 2010-05-03 6:49 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
When IBSS is fixed to a frequency, it can still
scan to try to find the right BSSID. This makes
sense if the BSSID isn't also fixed, but it need
not scan all channels -- just one is sufficient.
Make it do that by moving the scan setup code to
ieee80211_request_internal_scan() and include
a channel variable setting.
Note that this can be further improved to start
the IBSS right away if both frequency and BSSID
are fixed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/ibss.c | 9 ++++++---
net/mac80211/ieee80211_i.h | 3 ++-
net/mac80211/main.c | 17 +----------------
net/mac80211/scan.c | 28 +++++++++++++++++++++++++++-
4 files changed, 36 insertions(+), 21 deletions(-)
--- wireless-testing.orig/net/mac80211/main.c 2010-05-02 17:36:04.000000000 +0200
+++ wireless-testing/net/mac80211/main.c 2010-05-02 17:39:00.000000000 +0200
@@ -439,7 +439,7 @@ int ieee80211_register_hw(struct ieee802
struct ieee80211_local *local = hw_to_local(hw);
int result;
enum ieee80211_band band;
- int channels, i, j, max_bitrates;
+ int channels, max_bitrates;
bool supp_ht;
static const u32 cipher_suites[] = {
WLAN_CIPHER_SUITE_WEP40,
@@ -605,21 +605,6 @@ int ieee80211_register_hw(struct ieee802
ieee80211_led_init(local);
- /* alloc internal scan request */
- i = 0;
- local->int_scan_req->ssids = &local->scan_ssid;
- local->int_scan_req->n_ssids = 1;
- for (band = 0; band < IEEE80211_NUM_BANDS; band++) {
- if (!hw->wiphy->bands[band])
- continue;
- for (j = 0; j < hw->wiphy->bands[band]->n_channels; j++) {
- local->int_scan_req->channels[i] =
- &hw->wiphy->bands[band]->channels[j];
- i++;
- }
- }
- local->int_scan_req->n_channels = i;
-
local->network_latency_notifier.notifier_call =
ieee80211_max_network_latency;
result = pm_qos_add_notifier(PM_QOS_NETWORK_LATENCY,
--- wireless-testing.orig/net/mac80211/scan.c 2010-05-02 17:34:53.000000000 +0200
+++ wireless-testing/net/mac80211/scan.c 2010-05-02 17:41:49.000000000 +0200
@@ -729,10 +729,12 @@ int ieee80211_request_scan(struct ieee80
}
int ieee80211_request_internal_scan(struct ieee80211_sub_if_data *sdata,
- const u8 *ssid, u8 ssid_len)
+ const u8 *ssid, u8 ssid_len,
+ struct ieee80211_channel *chan)
{
struct ieee80211_local *local = sdata->local;
int ret = -EBUSY;
+ enum nl80211_band band;
mutex_lock(&local->scan_mtx);
@@ -740,6 +742,30 @@ int ieee80211_request_internal_scan(stru
if (local->scan_req)
goto unlock;
+ /* fill internal scan request */
+ if (!chan) {
+ int i, nchan = 0;
+
+ for (band = 0; band < IEEE80211_NUM_BANDS; band++) {
+ if (!local->hw.wiphy->bands[band])
+ continue;
+ for (i = 0;
+ i < local->hw.wiphy->bands[band]->n_channels;
+ i++) {
+ local->int_scan_req->channels[nchan] =
+ &local->hw.wiphy->bands[band]->channels[i];
+ nchan++;
+ }
+ }
+
+ local->int_scan_req->n_channels = nchan;
+ } else {
+ local->int_scan_req->channels[0] = chan;
+ local->int_scan_req->n_channels = 1;
+ }
+
+ local->int_scan_req->ssids = &local->scan_ssid;
+ local->int_scan_req->n_ssids = 1;
memcpy(local->int_scan_req->ssids[0].ssid, ssid, IEEE80211_MAX_SSID_LEN);
local->int_scan_req->ssids[0].ssid_len = ssid_len;
--- wireless-testing.orig/net/mac80211/ibss.c 2010-05-02 17:34:41.000000000 +0200
+++ wireless-testing/net/mac80211/ibss.c 2010-05-02 17:43:34.000000000 +0200
@@ -489,7 +489,9 @@ static void ieee80211_sta_merge_ibss(str
printk(KERN_DEBUG "%s: No active IBSS STAs - trying to scan for other "
"IBSS networks with same SSID (merge)\n", sdata->name);
- ieee80211_request_internal_scan(sdata, ifibss->ssid, ifibss->ssid_len);
+ ieee80211_request_internal_scan(sdata,
+ ifibss->ssid, ifibss->ssid_len,
+ ifibss->fixed_channel ? ifibss->channel : NULL);
}
static void ieee80211_sta_create_ibss(struct ieee80211_sub_if_data *sdata)
@@ -596,8 +598,9 @@ static void ieee80211_sta_find_ibss(stru
printk(KERN_DEBUG "%s: Trigger new scan to find an IBSS to "
"join\n", sdata->name);
- ieee80211_request_internal_scan(sdata, ifibss->ssid,
- ifibss->ssid_len);
+ ieee80211_request_internal_scan(sdata,
+ ifibss->ssid, ifibss->ssid_len,
+ ifibss->fixed_channel ? ifibss->channel : NULL);
} else {
int interval = IEEE80211_SCAN_INTERVAL;
--- wireless-testing.orig/net/mac80211/ieee80211_i.h 2010-05-02 17:39:13.000000000 +0200
+++ wireless-testing/net/mac80211/ieee80211_i.h 2010-05-02 17:39:38.000000000 +0200
@@ -1020,7 +1020,8 @@ void ieee80211_ibss_restart(struct ieee8
/* scan/BSS handling */
void ieee80211_scan_work(struct work_struct *work);
int ieee80211_request_internal_scan(struct ieee80211_sub_if_data *sdata,
- const u8 *ssid, u8 ssid_len);
+ const u8 *ssid, u8 ssid_len,
+ struct ieee80211_channel *chan);
int ieee80211_request_scan(struct ieee80211_sub_if_data *sdata,
struct cfg80211_scan_request *req);
void ieee80211_scan_cancel(struct ieee80211_local *local);
^ permalink raw reply
* [RFC v2] ibss: Added channel type in order to create HT IBSS
From: Benoit Papillault @ 2010-05-02 20:10 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Benoit Papillault
When joining an IBSS, the command line parameters could be used to
create the IBSS. As such, we need to know if the user wants to create an
HT IBSS or not. This is accomplish by passing the channel type (ie ht20,
ht40- or ht40+). Default is to create a non HT IBSS.
v2: Fixed parsing order of optionnal parameters. Parse argv[0] instead
of argv[1].
v3: Added parse_channel_type to factor some common parsing code.
Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
---
ibss.c | 9 ++++++++-
iw.h | 1 +
phy.c | 20 ++------------------
util.c | 27 +++++++++++++++++++++++++++
4 files changed, 38 insertions(+), 19 deletions(-)
diff --git a/ibss.c b/ibss.c
index 4715ac8..4d22157 100644
--- a/ibss.c
+++ b/ibss.c
@@ -18,6 +18,7 @@ static int join_ibss(struct nl80211_state *state,
{
char *end;
unsigned char abssid[6];
+ unsigned int htval;
if (argc < 2)
return 1;
@@ -35,6 +36,12 @@ static int join_ibss(struct nl80211_state *state,
argv++;
argc--;
+ if (argc && parse_channel_type(argv[0], &htval)) {
+ NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_CHANNEL_TYPE, htval);
+ argv++;
+ argc--;
+ }
+
if (argc && strcmp(argv[0], "fixed-freq") == 0) {
NLA_PUT_FLAG(msg, NL80211_ATTR_FREQ_FIXED);
argv++;
@@ -73,7 +80,7 @@ static int leave_ibss(struct nl80211_state *state,
COMMAND(ibss, leave, NULL,
NL80211_CMD_LEAVE_IBSS, 0, CIB_NETDEV, leave_ibss,
"Leave the current IBSS cell.");
-COMMAND(ibss, join, "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] [key d:0:abcde]",
+COMMAND(ibss, join, "<SSID> <freq in MHz> [HT20|HT40+|HT40-] [fixed-freq] [<fixed bssid>] [key d:0:abcde]",
NL80211_CMD_JOIN_IBSS, 0, CIB_NETDEV, join_ibss,
"Join the IBSS cell with the given SSID, if it doesn't exist create\n"
"it on the given frequency. When fixed frequency is requested, don't\n"
diff --git a/iw.h b/iw.h
index d1608e8..2ab4b90 100644
--- a/iw.h
+++ b/iw.h
@@ -120,6 +120,7 @@ void mac_addr_n2a(char *mac_addr, unsigned char *arg);
unsigned char *parse_hex(char *hex, size_t *outlen);
int parse_keys(struct nl_msg *msg, char **argv, int argc);
+int parse_channel_type(const char *str, unsigned int *htval);
void print_ht_mcs(const __u8 *mcs);
void print_ampdu_length(__u8 exponent);
diff --git a/phy.c b/phy.c
index 8f8d757..a33c4e1 100644
--- a/phy.c
+++ b/phy.c
@@ -32,30 +32,14 @@ static int handle_freqchan(struct nl_msg *msg, bool chan,
int argc, char **argv)
{
char *end;
- static const struct {
- const char *name;
- unsigned int val;
- } htmap[] = {
- { .name = "HT20", .val = NL80211_CHAN_HT20, },
- { .name = "HT40+", .val = NL80211_CHAN_HT40PLUS, },
- { .name = "HT40-", .val = NL80211_CHAN_HT40MINUS, },
- };
unsigned int htval = NL80211_CHAN_NO_HT;
unsigned int freq;
- int i;
if (!argc || argc > 2)
return 1;
- if (argc == 2) {
- for (i = 0; i < ARRAY_SIZE(htmap); i++) {
- if (strcasecmp(htmap[i].name, argv[1]) == 0) {
- htval = htmap[i].val;
- break;
- }
- }
- if (htval == NL80211_CHAN_NO_HT)
- return 1;
+ if (argc == 2 && !parse_channel_type(argv[1], &htval)) {
+ return 1;
}
if (!*argv[0])
diff --git a/util.c b/util.c
index 42c992d..9426306 100644
--- a/util.c
+++ b/util.c
@@ -338,6 +338,33 @@ int parse_keys(struct nl_msg *msg, char **argv, int argc)
return 2;
}
+/*
+ * Convert a string "HT20", "HT40+" or "HT40-" into nl80211
+ * value. Conversion is case insensitive. Returns 1 on success, 0 on error.
+ */
+
+int parse_channel_type(const char *str, unsigned int *htval)
+{
+ static const struct {
+ const char *name;
+ unsigned int val;
+ } htmap[] = {
+ { .name = "HT20", .val = NL80211_CHAN_HT20, },
+ { .name = "HT40+", .val = NL80211_CHAN_HT40PLUS, },
+ { .name = "HT40-", .val = NL80211_CHAN_HT40MINUS, },
+ };
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(htmap); i++) {
+ if (strcasecmp(htmap[i].name, str) == 0) {
+ *htval = htmap[i].val;
+ return 1;
+ }
+ }
+
+ return 0;
+}
+
static void print_mcs_index(const __u8 *mcs)
{
unsigned int mcs_bit, prev_bit = -2, prev_cont = 0;
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC] ibss: Added channel type in order to create HT IBSS
From: Benoit Papillault @ 2010-05-02 20:05 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1272817974.31265.0.camel@jlt3.sipsolutions.net>
Le 02/05/2010 18:32, Johannes Berg a écrit :
> On Sun, 2010-05-02 at 16:12 +0200, Benoit Papillault wrote:
>> When joining an IBSS, the parameters can be used to create the IBSS. As
>> such, we need to know if the user wants to create an HT IBSS or not.
>> This is accomplish by passing the channel type (ie ht20, ht40- or
>> ht40+). Default is to create a non HT IBSS.
>>
>> Signed-off-by: Benoit Papillault<benoit.papillault@free.fr>
>> ---
>> It is needed for upcoming patches regarding HT IBSS
>> ibss.c | 27 ++++++++++++++++++++++++++-
>> 1 files changed, 26 insertions(+), 1 deletions(-)
>>
>> diff --git a/ibss.c b/ibss.c
>> index 4715ac8..4003a38 100644
>> --- a/ibss.c
>> +++ b/ibss.c
>> @@ -18,6 +18,15 @@ static int join_ibss(struct nl80211_state *state,
>> {
>> char *end;
>> unsigned char abssid[6];
>> + int i;
>> + static const struct {
>> + const char *name;
>> + unsigned int val;
>> + } htmap[] = {
>> + { .name = "HT20", .val = NL80211_CHAN_HT20, },
>> + { .name = "HT40+", .val = NL80211_CHAN_HT40PLUS, },
>> + { .name = "HT40-", .val = NL80211_CHAN_HT40MINUS, },
>> + };
>
> There's code to do something like this already when setting the channel,
> please factor it out and use it in both places.
>
> johannes
>
Agreed. I did a copy/paste in the hurry, my bad.
I am going to post an update ASAP.
Regards,
Benoit
^ 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