* Re: ar9170-fw II
From: Christian Lamparter @ 2010-05-02 12:52 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: Benoit Papillault, linux-wireless
In-Reply-To: <4BDD5EB3.7020802@dlasys.net>
On Sunday 02 May 2010 13:14:59 David H. Lynch Jr. wrote:
> On 05/02/2010 03:47 AM, Benoit Papillault wrote:
> > Le 01/05/2010 22:45, Christian Lamparter a écrit :
> >> On Saturday 01 May 2010 20:23:26 David H. Lynch Jr. wrote:
> >>> I think I can tell you what I am supposed add - I need to be able
> >>> to provide userspace apps with precise timing information for each
> >>> packet.
> >>> Since i am working on GPL'd code and the results are going to be
> >>> provided to third parties whatever I do is GPL'd too.
> >>
> >> if by precise timing you mean "exact mac time in TU/usecs when frame
> >> was received at the radio", then you might have a _problem_.
> >> You see, the firmware already receives fully packed frames from
> >> the MAC processor and only _forwards_ them all [as is] in
> >> one big DMA to the USB subsystem.
> >> (this is done in src/wlan.c handle_rx())
> >>
> >> So, unless the HW has a _magic_ flag to enable this capability...
> >> you are sort of screwed :-/.
> >
> > I would love this feature as well. I have a device to test if that can
> > help. I share the feeling of Christian however... but maybe your
> > documentation says something about a special flag.
> I am interested in round trip time as measured from some fixed point
> in the sending process to some fixed point in the packet acknowledgement.
> The more accurate the better. Preferably measured by events at the
> radio rather than on the linux side.
> I am interested in tx packets rather than rx packets.
ahh, well... there goes' benoit interest ;).
> If necessary I can measure the times myself as delta's from one
> event to another withing the SH2.
>
> I have not digested the docs I have thoroughly yet but a cursory
> review suggests a less than trivial project.
> I have not yet found a good high resolution clock inside the ar9170
> there are alot of clocks but they all seem to be 16bit. Probably that
> will make things harder.
TSF timer could be used for this. (see 802.11-2007, Section 11 et seq.)
It's a 2^64 bit timer with a 1us resolution and a accuracy _better_
or equal to +/- 0.01%.
The register address are at:
- 0x1c3514 (low, AR9170_MAC_REG_TSF_L, read only)
- 0x1c3518 (high, AR9170_MAC_REG_TSF_H, read only)
But it comes at a small price: this timer is sometimes
update & synchronized (802.11 11.1.3.4 and 11.1.4) in
station or ad-hoc mode. The exact details are hidden
inside MAC chip, but it should be possible to disable
both by selecting the monitor mode.
> I was expecting to have to make changes to the ar9170 firmware. I
> was expecting to have to devise some means of passing that information
> to the Linux driver and to the userspace application.
Well, then you have two more good reasons why to use carl9170:
* the ar9170usb driver and ar9170 firmware don't track tx frames.
carl9170 on the other hand does (every frame has a 8 bit "cookie").
This feature was necessary to generate an accurate tx transmission
feedback report for every individual frame for the driver.
* carl9170 has the ability to store additional per-frame data.
In fact, if you don't need to have a different retry rates
you could realloc the 3 * 32 bit "rr" (as in retry rate)
array in the carl9170_tx_superdesc and _carl9170_tx_superdesc
struct (see wlan.h) for your purposes (storage for your time values).
And if you fetched all the data, everything will be sent
with an ordinary tx status feedback report to the application
(add the timer fields into carl9170_tx_status and _carl9170_tx_status
struct - see fwcmd.h)
(* talked about this earlier, but you never know...
carlu _tool_ already provides a low-level HW driver for userspace.
This has the obvious advantage that you won't need to mess with
the kernel driver and network stacks.
The only work you'll have to do is: get the kernel code for
the MAC & PHY initialization and put it into carlu.
But the framework is already there so it's mostly copy + paste )
> I would be happy to do that in some fashion that conformed to an existing
> or future standard, but I was not anticipating a broad desire for what I am
> doing. Variable latencies are highly undesirable in this application,
> but the userspace application will be aggregating large amounts of
> information, if latencies in what is measured are constrained and the
> unit of time measurement is small enough everything will work.
> If it comes to that we switch to different hardware, but my project
> is bringing a concept that was demonstrated with an expensive SDR to an
> ar9170.
It's always nice to have some "added value" for cheap and generic devices.
e.g.: Atheros AR92xx chips can be used as among other stuff as a
full range spectrum analyzer.
Regards,
Chr
^ permalink raw reply
* Re: ar9170-fw II
From: David H. Lynch Jr. @ 2010-05-02 13:47 UTC (permalink / raw)
To: Christian Lamparter, linux-wireless
In-Reply-To: <201005021452.01101.chunkeey@googlemail.com>
On 05/02/2010 08:52 AM, Christian Lamparter wrote:
>
>
>> If necessary I can measure the times myself as delta's from one
>> event to another withing the SH2.
>>
>> I have not digested the docs I have thoroughly yet but a cursory
>> review suggests a less than trivial project.
>> I have not yet found a good high resolution clock inside the ar9170
>> there are alot of clocks but they all seem to be 16bit. Probably that
>> will make things harder.
>>
> TSF timer could be used for this. (see 802.11-2007, Section 11 et seq.)
> It's a 2^64 bit timer with a 1us resolution and a accuracy _better_
> or equal to +/- 0.01%.
>
> The register address are at:
> - 0x1c3514 (low, AR9170_MAC_REG_TSF_L, read only)
> - 0x1c3518 (high, AR9170_MAC_REG_TSF_H, read only)
>
> But it comes at a small price: this timer is sometimes
> update& synchronized (802.11 11.1.3.4 and 11.1.4) in
> station or ad-hoc mode. The exact details are hidden
> inside MAC chip, but it should be possible to disable
> both by selecting the monitor mode.
>
I will have to look into that it might work.
I beleive this project is in ad-hoc mode,
but if the timer is not being altered between the transmission of a
packet and the receipt of its ACK I am fine,
the worst case would be that it is and delta T becomes artificially
smaller. One characteristic of my problem is that
almost all the error is positive delta T overly large.
>
>> I was expecting to have to make changes to the ar9170 firmware. I
>> was expecting to have to devise some means of passing that information
>> to the Linux driver and to the userspace application.
>>
> Well, then you have two more good reasons why to use carl9170:
>
> * the ar9170usb driver and ar9170 firmware don't track tx frames.
> carl9170 on the other hand does (every frame has a 8 bit "cookie").
> This feature was necessary to generate an accurate tx transmission
> feedback report for every individual frame for the driver.
>
That would be necescary in my application and I have started to work
with the carl9170 driver.
I built the toolchain compiler the firmware and I am building a
linux kernel right now.
> * carl9170 has the ability to store additional per-frame data.
> In fact, if you don't need to have a different retry rates
> you could realloc the 3 * 32 bit "rr" (as in retry rate)
> array in the carl9170_tx_superdesc and _carl9170_tx_superdesc
> struct (see wlan.h) for your purposes (storage for your time values).
>
> And if you fetched all the data, everything will be sent
> with an ordinary tx status feedback report to the application
> (add the timer fields into carl9170_tx_status and _carl9170_tx_status
> struct - see fwcmd.h)
>
I need a delta T between some fixed point during the send and some
fixed point during the ACK.
And the MAC address of the device I was sending to. The latter
already is obviously already known, I just have to tie to it.
>
> (* talked about this earlier, but you never know...
>
> carlu _tool_ already provides a low-level HW driver for userspace.
> This has the obvious advantage that you won't need to mess with
> the kernel driver and network stacks.
>
> The only work you'll have to do is: get the kernel code for
> the MAC& PHY initialization and put it into carlu.
> But the framework is already there so it's mostly copy + paste )
>
I beleive you are using DEBUGFS and that was already part of my spec.
Regardless, I am comfortable on the Linux driver side.
The closer I get to the Linux side the more comfortable I am.
Further though the actual timing of each send's delta T needs to be
as accurate and fine grained as possible,
everything else in this project is non-critical. Within reason it
is unimportant how long it takes to propigate data from the AR9170
through to userspace,
Clean and simple will take precedence over any other technical demands.
>> I would be happy to do that in some fashion that conformed to an existing
>> or future standard, but I was not anticipating a broad desire for what I am
>> doing. Variable latencies are highly undesirable in this application,
>> but the userspace application will be aggregating large amounts of
>> information, if latencies in what is measured are constrained and the
>> unit of time measurement is small enough everything will work.
>> If it comes to that we switch to different hardware, but my project
>> is bringing a concept that was demonstrated with an expensive SDR to an
>> ar9170.
>>
> It's always nice to have some "added value" for cheap and generic devices.
> e.g.: Atheros AR92xx chips can be used as among other stuff as a
> full range spectrum analyzer.
>
And my ability to get consulting work is strongly effected by the
extent I can contribute to Linux.
References, and lists of skills and qualifications on my web site
are dwarfed by
Dave Lynch, DLA Systems <dhlii@dlasys.net> appearing inside the
kernel tree.
I love this work. I love working for myself, I want to continue to
do so.
I would contribute as I can regardless, but self interest helps.
> Regards,
> Chr
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 dhlii@dlasys.net http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* [RFC] ibss: Added channel type in order to create HT IBSS
From: Benoit Papillault @ 2010-05-02 14:12 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Benoit Papillault
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, },
+ };
if (argc < 2)
return 1;
@@ -52,6 +61,22 @@ static int join_ibss(struct nl80211_state *state,
if (!argc)
return 0;
+ if (argc) {
+ for (i = 0; i < ARRAY_SIZE(htmap); i++) {
+ if (strcasecmp(htmap[i].name, argv[1]) == 0) {
+ NLA_PUT_U32(msg,
+ NL80211_ATTR_WIPHY_CHANNEL_TYPE,
+ htmap[i].val);
+ argv++;
+ argc--;
+ break;
+ }
+ }
+ }
+
+ if (!argc)
+ return 0;
+
if (strcmp(*argv, "key") != 0 && strcmp(*argv, "keys") != 0)
return 1;
@@ -73,7 +98,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"
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC] ibss: Added channel type in order to create HT IBSS
From: Johannes Berg @ 2010-05-02 16:32 UTC (permalink / raw)
To: Benoit Papillault; +Cc: linux-wireless
In-Reply-To: <1272809528-11000-1-git-send-email-benoit.papillault@free.fr>
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
^ permalink raw reply
* 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
* [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
* [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/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_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
* [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
* 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
* 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: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: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: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: 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: 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 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 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
* [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] 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
* 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: 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: 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: 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
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