* Re: [PATCH 41/44] includecheck fix: include/linux, rfkill.h
From: Jaswinder Singh Rajput @ 2009-07-09 4:01 UTC (permalink / raw)
To: Marcel Holtmann
Cc: johannes, linux-wireless, Andrew Morton, Sam Ravnborg, LKML
In-Reply-To: <1247081557.9709.16.camel@localhost.localdomain>
Hello Marcel,
On Wed, 2009-07-08 at 12:32 -0700, Marcel Holtmann wrote:
> Hi Jaswinder,
>
> > fix the following 'make includecheck' warning:
> >
> > include/linux/rfkill.h: linux/types.h is included more than once.
> >
> > Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> > ---
> > include/linux/rfkill.h | 1 -
> > 1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
> > index e73e242..2ce2983 100644
> > --- a/include/linux/rfkill.h
> > +++ b/include/linux/rfkill.h
> > @@ -99,7 +99,6 @@ enum rfkill_user_states {
> > #undef RFKILL_STATE_UNBLOCKED
> > #undef RFKILL_STATE_HARD_BLOCKED
> >
> > -#include <linux/types.h>
> > #include <linux/kernel.h>
> > #include <linux/list.h>
> > #include <linux/mutex.h>
>
> with the #ifdef __KERNEL__ in between it is kinda weird, but patch seems
> correct.
>
ACK or Reviewed-by ?
Thanks,
--
JSR
^ permalink raw reply
* Re: [PATCH] wireless: fix supported cards for rtl8187
From: Hin-Tak Leung @ 2009-07-09 4:18 UTC (permalink / raw)
To: Marcin Slusarz
Cc: John W. Linville, Linux wireless, Przemyslaw Kulczycki, LKML,
Gábor Stefanik
In-Reply-To: <4A551B43.3020104@gmail.com>
On Wed, Jul 8, 2009 at 11:18 PM, Marcin Slusarz<marcin.slusarz@gmail.com> wrote:
> Hin-Tak Leung wrote:
>> Is there a v1, and what does it use?
>
> I don't know.
2009/7/8 Gábor Stefanik <netrolller.3d@gmail.com>:
> On Wed, Jul 8, 2009 at 11:49 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>> Is there a v1, and what does it use?
>
> I have the v1, it is rt73-based. (v3 is rt2070, not rt3070, though.)
I guess I have two questions: (1) are the 3 variants labelled in that
way as such v1/v2/v3 (on the box,
or one of the USB device identity queries)? (2) are they distinguished
by different product IDs?
The point is that the commit (which only changes the help message) is
only appropriate if they are labelled as v1/v2/v3 and not
distinguished by different product IDs. If they are distinguished by
different product IDs and the current codes for the three drivers bind
correctly to each, then the change is only relevant to people who
manually build their kernel and want to build one driver but not the
others. (i.e. instead of distros which ship the full set of driver
modules). Which goes to my first question...
if they are not labelled v1/v2/v3 as such, it may be more
useful/informative to change to
[some variant of ] ... [(other variants are supported by the
rt2070/rt3070 modules)]
instead of just adding [v2] to the end.
^ permalink raw reply
* Re: [PATCH] wireless: fix supported cards for rtl8187
From: Larry Finger @ 2009-07-09 4:44 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: Marcin Slusarz, John W. Linville, Linux wireless,
Przemyslaw Kulczycki, LKML, Gábor Stefanik
In-Reply-To: <3ace41890907082118h52764c98i7ebd9365bcd69b2c@mail.gmail.com>
Hin-Tak Leung wrote:
>
> if they are not labelled v1/v2/v3 as such, it may be more
> useful/informative to change to
>
> [some variant of ] ... [(other variants are supported by the
> rt2070/rt3070 modules)]
>
> instead of just adding [v2] to the end.
I don't know about the box as I bought mine used on Ebay, but the
label on the device clearly states that it is a WG111v2.
Larry
^ permalink raw reply
* Re: rt73 in AP mode: PS frames buffered but missing TIM bit?
From: Stefan Steuerwald @ 2009-07-09 5:30 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <f76a32050907061320n18f3c4c9j4d5589c9c9e45c02@mail.gmail.com>
> > Sounds like a driver problem, it must not be reacting to set_tim()
> > properly.
> >
> > johannes
>
> Looking at rt73usb.c:2242, there isn't any initializer for .set_tim .
> Plausible explanation.
> It may be totally beyond me to just implement it. Let me find someone
> to ask nicely ;-) ...
I have an experimental patch working (sent for review to the rt2x00
mailing list).
I will report back here.
Stefan.
^ permalink raw reply
* Re: [PATCH 41/44] includecheck fix: include/linux, rfkill.h
From: Marcel Holtmann @ 2009-07-09 5:47 UTC (permalink / raw)
To: Jaswinder Singh Rajput
Cc: johannes, linux-wireless, Andrew Morton, Sam Ravnborg, LKML
In-Reply-To: <1247112119.2453.4.camel@ht.satnam>
Hi Jaswinder,
> > > fix the following 'make includecheck' warning:
> > >
> > > include/linux/rfkill.h: linux/types.h is included more than once.
> > >
> > > Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> > > ---
> > > include/linux/rfkill.h | 1 -
> > > 1 files changed, 0 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
> > > index e73e242..2ce2983 100644
> > > --- a/include/linux/rfkill.h
> > > +++ b/include/linux/rfkill.h
> > > @@ -99,7 +99,6 @@ enum rfkill_user_states {
> > > #undef RFKILL_STATE_UNBLOCKED
> > > #undef RFKILL_STATE_HARD_BLOCKED
> > >
> > > -#include <linux/types.h>
> > > #include <linux/kernel.h>
> > > #include <linux/list.h>
> > > #include <linux/mutex.h>
> >
> > with the #ifdef __KERNEL__ in between it is kinda weird, but patch seems
> > correct.
> >
>
> ACK or Reviewed-by ?
both if you want to, but John already picked it up for wireless-testing
if I am not mistaken. So it is on its way into 2.6.32 somehow.
Regards
Marcel
^ permalink raw reply
* Re: [regression] ath5k: Overrides regulatory domain set for cfg80211
From: Holger Schurig @ 2009-07-09 7:05 UTC (permalink / raw)
To: linux-wireless
Cc: Luis R. Rodriguez, Frans Pop, netdev, Linux Kernel Mailing List
In-Reply-To: <43e72e890907081508n6fa5781an1dcbda078efc5379@mail.gmail.com>
> Eventually, as you will read from the feature-removal
> schedule, we intend on getting the Linux desktop to provide
> automatic hints of the user's location through things like
> GeoClue.
Please think about embedded people. We don't need no stinkin'
geoclue. We'll need a kernel parameter or an commant for "iw" or
some other netlink based command.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [regression] ath5k: Overrides regulatory domain set for cfg80211
From: Holger Schurig @ 2009-07-09 7:11 UTC (permalink / raw)
To: linux-wireless
Cc: Frans Pop, Luis R. Rodriguez, netdev, Linux Kernel Mailing List
In-Reply-To: <200907090311.40205.elendil@planet.nl>
> For Debian iw is available in testing/unstable, but not in
> stable.
Make an effort to get it into backports.org .... and AFAIK,
Kernel 2.6.30xxx isn't in Debian stable either. So by using a
different kernel you've moved away from a purely "Debian stable"
setup anyway.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [regression] ath5k: Overrides regulatory domain set for cfg80211
From: Luis R. Rodriguez @ 2009-07-09 7:10 UTC (permalink / raw)
To: Holger Schurig
Cc: linux-wireless, Frans Pop, netdev, Linux Kernel Mailing List
In-Reply-To: <200907090905.27154.hs4233@mail.mn-solutions.de>
On Thu, Jul 9, 2009 at 12:05 AM, Holger
Schurig<hs4233@mail.mn-solutions.de> wrote:
>> Eventually, as you will read from the feature-removal
>> schedule, we intend on getting the Linux desktop to provide
>> automatic hints of the user's location through things like
>> GeoClue.
>
> Please think about embedded people. We don't need no stinkin'
> geoclue. We'll need a kernel parameter or an commant for "iw" or
> some other netlink based command.
Note I wrote "Linux desktop" not Linux embedded. And we already have a
nl80211 command for this exact purpose. You can even use
wpa_supplicant if you don't want to use iw.
I wouldn't be surprised to see geoclue in embedded devices though.
Luis
^ permalink raw reply
* [PATCH] cfg80211: fix NULL dereference in IBSS SIOCGIWAP
From: Zhu Yi @ 2009-07-09 8:59 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Zhu Yi, Johannes Berg
This patch avoids memcpy from wdev->wext.ibss.bssid if it is NULL.
This could happen if we SIOCGIWAP before SIOCSIWAP.
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
net/wireless/ibss.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
index 99ef936..cf3a7dc 100644
--- a/net/wireless/ibss.c
+++ b/net/wireless/ibss.c
@@ -434,8 +434,11 @@ int cfg80211_ibss_wext_giwap(struct net_device *dev,
wdev_lock(wdev);
if (wdev->current_bss)
memcpy(ap_addr->sa_data, wdev->current_bss->pub.bssid, ETH_ALEN);
- else
+ else if (wdev->wext.ibss.bssid)
memcpy(ap_addr->sa_data, wdev->wext.ibss.bssid, ETH_ALEN);
+ else
+ memset(ap_addr->sa_data, 0, ETH_ALEN);
+
wdev_unlock(wdev);
return 0;
--
1.6.0.4
^ permalink raw reply related
* [PATCH] iwmc3200wifi: fix NULL pointer dereference in iwm_if_free
From: Zhu Yi @ 2009-07-09 9:16 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Zhu Yi
The driver private data is now based on wiphy. So we should not
touch the private data after wiphy_free() is called. The patch
fixes the potential NULL pointer dereference by making the
iwm_wdev_free() the last one on the interface removal path.
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/netdev.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/netdev.c b/drivers/net/wireless/iwmc3200wifi/netdev.c
index e94e969..bb71f8a 100644
--- a/drivers/net/wireless/iwmc3200wifi/netdev.c
+++ b/drivers/net/wireless/iwmc3200wifi/netdev.c
@@ -155,11 +155,11 @@ void iwm_if_free(struct iwm_priv *iwm)
if (!iwm_to_ndev(iwm))
return;
- free_netdev(iwm_to_ndev(iwm));
- iwm_wdev_free(iwm);
- iwm_priv_deinit(iwm);
kfree(iwm->umac_profile);
iwm->umac_profile = NULL;
+ free_netdev(iwm_to_ndev(iwm));
+ iwm_priv_deinit(iwm);
+ iwm_wdev_free(iwm);
}
int iwm_if_add(struct iwm_priv *iwm)
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2.6.31] iwmc3200wifi: fix NULL pointer dereference in iwm_if_free
From: Zhu Yi @ 2009-07-09 9:24 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Zhu Yi
The driver private data is now based on wiphy. So we should not
touch the private data after wiphy_free() is called. The patch
fixes the potential NULL pointer dereference by making the
iwm_wdev_free() the last one on the interface removal path.
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/netdev.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/netdev.c b/drivers/net/wireless/iwmc3200wifi/netdev.c
index e94e969..bb71f8a 100644
--- a/drivers/net/wireless/iwmc3200wifi/netdev.c
+++ b/drivers/net/wireless/iwmc3200wifi/netdev.c
@@ -151,8 +151,8 @@ void iwm_if_free(struct iwm_priv *iwm)
return;
free_netdev(iwm_to_ndev(iwm));
- iwm_wdev_free(iwm);
iwm_priv_deinit(iwm);
+ iwm_wdev_free(iwm);
}
int iwm_if_add(struct iwm_priv *iwm)
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] wireless: fix supported cards for rtl8187
From: Hin-Tak Leung @ 2009-07-09 10:47 UTC (permalink / raw)
To: Larry Finger
Cc: Marcin Slusarz, John W. Linville, Linux wireless,
Przemyslaw Kulczycki, LKML, Gábor Stefanik
In-Reply-To: <4A5575C1.8090403@lwfinger.net>
2009/7/9 Larry Finger <Larry.Finger@lwfinger.net>:
> Hin-Tak Leung wrote:
>>
>> if they are not labelled v1/v2/v3 as such, it may be more
>> useful/informative to change to
>>
>> [some variant of ] ... [(other variants are supported by the
>> rt2070/rt3070 modules)]
>>
>> instead of just adding [v2] to the end.
>
> I don't know about the box as I bought mine used on Ebay, but the
> label on the device clearly states that it is a WG111v2.
>
> Larry
>
>
But that's a Netgear WG111v2 ? We are talking about Linksys
WUSB54GC-EU and its v1/v2/v3 . I am just thinking that if it is for
informative purposes (for those who actually selectively build their
kernel modules), adding a bit more info, such as suggesting to use
rt73usb/rt2070/rt3070 modules, won't hurt.
Incidentally I like to know a bit more about this patch - presumably
Marcin has such a device? I am also a little curious, as this commit
should be accompanied by a corresponding update in another Kconfig
which supports the device? I am not trying to be picky, but for an
informative (non-code-changing) patch, it can be more informative.
^ permalink raw reply
* Re: [PATCH] wireless: fix supported cards for rtl8187
From: Marcin Slusarz @ 2009-07-09 11:14 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: Larry Finger, John W. Linville, Linux wireless,
Przemyslaw Kulczycki, LKML, Gábor Stefanik
In-Reply-To: <3ace41890907090347m1f337731rb09b90327664ed5@mail.gmail.com>
Hin-Tak Leung pisze:
> 2009/7/9 Larry Finger <Larry.Finger@lwfinger.net>:
>> Hin-Tak Leung wrote:
>>> if they are not labelled v1/v2/v3 as such, it may be more
>>> useful/informative to change to
>>>
>>> [some variant of ] ... [(other variants are supported by the
>>> rt2070/rt3070 modules)]
>>>
>>> instead of just adding [v2] to the end.
>> I don't know about the box as I bought mine used on Ebay, but the
>> label on the device clearly states that it is a WG111v2.
>>
>> Larry
>>
>>
>
> But that's a Netgear WG111v2 ? We are talking about Linksys
> WUSB54GC-EU and its v1/v2/v3 . I am just thinking that if it is for
> informative purposes (for those who actually selectively build their
> kernel modules), adding a bit more info, such as suggesting to use
> rt73usb/rt2070/rt3070 modules, won't hurt.
>
> Incidentally I like to know a bit more about this patch - presumably
> Marcin has such a device? I am also a little curious, as this commit
> should be accompanied by a corresponding update in another Kconfig
> which supports the device? I am not trying to be picky, but for an
> informative (non-code-changing) patch, it can be more informative.
I have a v3 device and this driver does not support it.
Below is the commit which added the string my patch corrects.
I've sent yesterday another patch which adds support for WUSB54GC v3
to the rt3070 driver.
commit aeeab4ff06b8e29cfe2fe730ba626f7e2487ba03
Author: John W. Linville <linville@tuxdriver.com>
Date: Wed May 27 09:21:57 2009 +0200
rtl8187: add USB ID for Linksys WUSB54GC-EU v2 USB wifi dongle
http://bugzilla.kernel.org/show_bug.cgi?id=13383
Reported-by: Przemyslaw Kulczycki <azrael@autocom.pl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index 8a08235..3d94e7d 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -430,6 +430,7 @@ config RTL8187
ASUS P5B Deluxe
Toshiba Satellite Pro series of laptops
Asus Wireless Link
+ Linksys WUSB54GC-EU
Thanks to Realtek for their support!
diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
index bac6cfb..d51ba0a 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -71,6 +71,8 @@ static struct usb_device_id rtl8187_table[] __devinitdata = {
{USB_DEVICE(0x18E8, 0x6232), .driver_info = DEVICE_RTL8187},
/* AirLive */
{USB_DEVICE(0x1b75, 0x8187), .driver_info = DEVICE_RTL8187},
+ /* Linksys */
+ {USB_DEVICE(0x1737, 0x0073), .driver_info = DEVICE_RTL8187B},
{}
};
^ permalink raw reply related
* Re: [PATCH] cfg80211: fix NULL dereference in IBSS SIOCGIWAP
From: Johannes Berg @ 2009-07-09 11:32 UTC (permalink / raw)
To: Zhu Yi; +Cc: linville, linux-wireless
In-Reply-To: <1247129989-24989-1-git-send-email-yi.zhu@intel.com>
[-- Attachment #1: Type: text/plain, Size: 965 bytes --]
On Thu, 2009-07-09 at 16:59 +0800, Zhu Yi wrote:
> This patch avoids memcpy from wdev->wext.ibss.bssid if it is NULL.
> This could happen if we SIOCGIWAP before SIOCSIWAP.
Indeed, thanks.
> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> net/wireless/ibss.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
> index 99ef936..cf3a7dc 100644
> --- a/net/wireless/ibss.c
> +++ b/net/wireless/ibss.c
> @@ -434,8 +434,11 @@ int cfg80211_ibss_wext_giwap(struct net_device *dev,
> wdev_lock(wdev);
> if (wdev->current_bss)
> memcpy(ap_addr->sa_data, wdev->current_bss->pub.bssid, ETH_ALEN);
> - else
> + else if (wdev->wext.ibss.bssid)
> memcpy(ap_addr->sa_data, wdev->wext.ibss.bssid, ETH_ALEN);
> + else
> + memset(ap_addr->sa_data, 0, ETH_ALEN);
> +
> wdev_unlock(wdev);
>
> return 0;
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* nl80211 and wext interoperability
From: Johannes Berg @ 2009-07-09 11:43 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]
Hi!
With the recent work I've done in cfg80211 for nl80211 and wext, we've
mostly removed wext code everywhere. The only thing missing right now is
the key support, and I think then we can declare cfg80211's wext compat
layer pretty much done in terms of what mac80211 had -- orinoco will
need the sensitivity (or AP density) thing but I'm not sure how we
should do that since it's a value that is hardware dependent -- we'll
need to have very good discovery code for the allowed values (unlike
wext where you can set 0..3 and don't know what that means). Anyway,
that wasn't the point of this email.
Currently, if you use wpa_supplicant -Dwext and -Dnl80211 mixed,
-Dnl80211 gets confused because -Dwext will set a 32-byte random SSID to
"disconnect". When then the interface is brought UP again, the cfg80211
code assumes that you set configuration while it was DOWN, and tries to
recover that configuration. This means it will start scanning for the
network, which means -Dnl80211 gets -EBUSY for the scan and it all gets
very delayed. This also happens if you set an SSID with iwconfig before
using -Dnl80211.
Do we just ignore that issue? It's only added timeout and people using
purely nl80211 will never have a problem.
I'm all for ignoring wext issues, but I can also see people complain
about things like this. Not sure what mac80211 did, did it just ignore
settings while interfaces were down? I never really made sense of that
code.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: rt73 in AP mode: PS frames buffered but missing TIM bit?
From: Ivo Van Doorn @ 2009-07-09 11:58 UTC (permalink / raw)
To: Stefan Steuerwald; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <f76a32050907082230r7b98c438ybf08d1a421717ad6@mail.gmail.com>
On Thu, Jul 9, 2009 at 7:30 AM, Stefan
Steuerwald<salsasepp@googlemail.com> wrote:
>> > Sounds like a driver problem, it must not be reacting to set_tim()
>> > properly.
>> >
>> > johannes
>>
>> Looking at rt73usb.c:2242, there isn't any initializer for .set_tim .
>> Plausible explanation.
>> It may be totally beyond me to just implement it. Let me find someone
>> to ask nicely ;-) ...
>
> I have an experimental patch working (sent for review to the rt2x00
> mailing list).
> I will report back here.
Are you sure you've send it already? Because I haven't seen anything yet.
Ivo
^ permalink raw reply
* Re: [PATCH] wireless: fix supported cards for rtl8187
From: Hin-Tak Leung @ 2009-07-09 12:40 UTC (permalink / raw)
To: Marcin Slusarz
Cc: Larry Finger, John W. Linville, Linux wireless,
Przemyslaw Kulczycki, LKML, Gábor Stefanik
In-Reply-To: <4A55D123.5090802@gmail.com>
2009/7/9 Marcin Slusarz <marcin.slusarz@gmail.com>:
> Hin-Tak Leung pisze:
>> 2009/7/9 Larry Finger <Larry.Finger@lwfinger.net>:
>>> Hin-Tak Leung wrote:
>>>> if they are not labelled v1/v2/v3 as such, it may be more
>>>> useful/informative to change to
>>>>
>>>> [some variant of ] ... [(other variants are supported by the
>>>> rt2070/rt3070 modules)]
>>>>
>>>> instead of just adding [v2] to the end.
>>> I don't know about the box as I bought mine used on Ebay, but the
>>> label on the device clearly states that it is a WG111v2.
>>>
>>> Larry
>>>
>>>
>>
>> But that's a Netgear WG111v2 ? We are talking about Linksys
>> WUSB54GC-EU and its v1/v2/v3 . I am just thinking that if it is for
>> informative purposes (for those who actually selectively build their
>> kernel modules), adding a bit more info, such as suggesting to use
>> rt73usb/rt2070/rt3070 modules, won't hurt.
>>
>> Incidentally I like to know a bit more about this patch - presumably
>> Marcin has such a device? I am also a little curious, as this commit
>> should be accompanied by a corresponding update in another Kconfig
>> which supports the device? I am not trying to be picky, but for an
>> informative (non-code-changing) patch, it can be more informative.
>
> I have a v3 device and this driver does not support it.
> Below is the commit which added the string my patch corrects.
> I've sent yesterday another patch which adds support for WUSB54GC v3
> to the rt3070 driver.
Here is some info from Gabor (shouldn't this be reply-all rather than just me):
------------------
The v1 and v2 look identical (though the label on the device indicates
the revision). The v3 looks completely different. They all have
different USB IDs (v1 is stock RT73, v2 has a custom ID, while v3 is
AFAIK stock RT2070).
------------------
I guess to be informative, may I suggest adding '(for v1 see rt73usb,
and v3 see rt3070)' or something similiar to the 'v2' change?
It is fair customary in Kconfig to mention even alternative/competing
drivers for the same device. And when you add v3 support to the rt3070
driver, a reverse mention may be appropriate. (I guess I am spending
far too long on this discussion - but I reckon, the purpose of a
non-code-changing change is meant to be informative, so one might want
to be as informative as appropriate without being too wordy...)
>
> commit aeeab4ff06b8e29cfe2fe730ba626f7e2487ba03
> Author: John W. Linville <linville@tuxdriver.com>
> Date: Wed May 27 09:21:57 2009 +0200
>
> rtl8187: add USB ID for Linksys WUSB54GC-EU v2 USB wifi dongle
>
> http://bugzilla.kernel.org/show_bug.cgi?id=13383
>
> Reported-by: Przemyslaw Kulczycki <azrael@autocom.pl>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
> index 8a08235..3d94e7d 100644
> --- a/drivers/net/wireless/Kconfig
> +++ b/drivers/net/wireless/Kconfig
> @@ -430,6 +430,7 @@ config RTL8187
> ASUS P5B Deluxe
> Toshiba Satellite Pro series of laptops
> Asus Wireless Link
> + Linksys WUSB54GC-EU
>
> Thanks to Realtek for their support!
>
> diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
> index bac6cfb..d51ba0a 100644
> --- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
> +++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
> @@ -71,6 +71,8 @@ static struct usb_device_id rtl8187_table[] __devinitdata = {
> {USB_DEVICE(0x18E8, 0x6232), .driver_info = DEVICE_RTL8187},
> /* AirLive */
> {USB_DEVICE(0x1b75, 0x8187), .driver_info = DEVICE_RTL8187},
> + /* Linksys */
> + {USB_DEVICE(0x1737, 0x0073), .driver_info = DEVICE_RTL8187B},
> {}
> };
>
>
>
>
^ permalink raw reply
* Problem with p54 driver and ibss mode
From: Alexander Wenzel @ 2009-07-09 11:59 UTC (permalink / raw)
To: linux-wireless
Hi!
I'm trying to get the latest p54 wireless drivers (ad-hoc mode)
to work on a Nokia N810... So far, without any success.
Some words about my scenario:
- Nokia N810 running a custom omap1 kernel
(linux-omap-2.6.git / tag: "v2.6.29-omap1")
Patched keyboard (board-n800.c) and usb driver (usb-tusb6010.c)
to get it working...
- Installed Mer (Ubuntu 9.04) on an external mmc 4GB card
Patched the bootmenu stuff to get rid of static /dev/ nodes problem
which come up with the new kernel...
- compiled compat wireless drivers 2009-07-09
disabled CONFIG_RFKILL_BACKPORT_LEDS because it didn't compile
- A second N810 running debian and nokias 2.6.21er kernel
Ad-hoc mode is active. (ad-hoc is working, tested with some
other N810 devices)
After all these preparations, patching and workaround stuff,
i finally inserted the wireless modules into the kernel
(rfkill_backport, cfg80211, mac80211, p54common, p54spi)
dmesg looks fine so far:
[ 3671.237365] cfg80211: Using static regulatory domain info
[ 3671.237396] cfg80211: Regulatory domain: US
[ 3671.237426] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 3671.237457] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
[ 3671.237487] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 3671.237518] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 3671.237548] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 3671.237579] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 3671.237609] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[ 3671.238555] cfg80211: Calling CRDA for country: US
[ 3685.186523] cx3110x spi2.0: firmware: requesting 3826.arm
[ 3685.265045] phy0: p54 detected a LM20 firmware
[ 3685.265106] p54: rx_mtu reduced from 3240 to 2376
[ 3685.265106] phy0: FW rev 2.13.0.0.a.22.8 - Softmac protocol 5.6
[ 3685.265136] phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
[ 3685.265197] cx3110x spi2.0: firmware: requesting 3826.eeprom
[ 3685.320800] cx3110x spi2.0: loading default eeprom...
[ 3685.320922] phy0: hwaddr 00:02:ee:c0:ff:ee, MAC:isl3820 RF:Longbow
[ 3685.455108] phy0: Selected rate control algorithm 'minstrel'
[ 3685.456787] Registered led device: p54-phy0::assoc
[ 3685.457031] Registered led device: p54-phy0::tx
[ 3685.457275] Registered led device: p54-phy0::rx
[ 3685.457489] Registered led device: p54-phy0::radio
[ 3685.457550] cx3110x spi2.0: is registered as 'phy0'
Monitor mode is also working. Here are some beacons from my second device:
00:01:37.463744 51669459us tsft 1.0 Mb/s 2462 MHz (0x00a0) 30dB signal -63dB noise antenna 0 [0x0000000e] Beacon (rita) [1.0* 2.0* 5.5 11.0 Mbit] IBSS CH: 11
00:01:37.566100 51771860us tsft 1.0 Mb/s 2462 MHz (0x00a0) 29dB signal -63dB noise antenna 0 [0x0000000e] Beacon (rita) [1.0* 2.0* 5.5 11.0 Mbit] IBSS CH: 11
00:01:37.668517 51874300us tsft 1.0 Mb/s 2462 MHz (0x00a0) 30dB signal -63dB noise antenna 0 [0x0000000e] Beacon (rita) [1.0* 2.0* 5.5 11.0 Mbit] IBSS CH: 11
After this short test, i switched the driver into ad-hoc mode,
setup the essid, channel and assigned an ip address... I tried
to ping, tcpdump, whatsoever... nothing happens. Driver statistics
are also frozen (in monitor mode the rx stats incr.).
The only hints to the problem are:
- this repeating kernel msg:
[...cut...]
[ 3905.535125] WARNING: at /home/wen/work/NokiaN810/compat-wireless-2009-07-09/net/mac80211/sta_info.c:339 sta_info_insert+0x7c/0x15c [mac80211]()
[ 3905.535186] Modules linked in: p54spi p54common mac80211 cfg80211 rfkill_backport
[ 3905.535247] [<c02b73a0>] (dump_stack+0x0/0x14) from [<c00541cc>] (warn_slowpath+0x70/0x8c)
[ 3905.535308] [<c005415c>] (warn_slowpath+0x0/0x8c) from [<bf02af40>] (sta_info_insert+0x7c/0x15c [mac80211])
[ 3905.535522] r3:00000000 r2:00000000
[ 3905.535552] r7:c53a4200 r6:c7e65800 r5:0000c0ee r4:c5303b60
[ 3905.535583] [<bf02aec4>] (sta_info_insert+0x0/0x15c [mac80211]) from [<bf02f220>] (ieee80211_ibss_add_sta+0x114/0x130 [mac80211])
[ 3905.535919] r7:c7d9442e r6:c7e65800 r5:c53a4200 r4:c7e65800
[ 3905.535949] [<bf02f10c>] (ieee80211_ibss_add_sta+0x0/0x130 [mac80211]) from [<bf02f35c>] (ieee80211_rx_bss_info+0x120/0x160 [mac80211])
[ 3905.536407] [<bf02f23c>] (ieee80211_rx_bss_info+0x0/0x160 [mac80211]) from [<bf02f590>] (ieee80211_ibss_rx_queued_mgmt+0x1f4/0x274 [mac80211])
[ 3905.536743] [<bf02f39c>] (ieee80211_ibss_rx_queued_mgmt+0x0/0x274 [mac80211]) from [<bf02f684>] (ieee80211_ibss_work+0x74/0x198 [mac80211])
[ 3905.537048] [<bf02f610>] (ieee80211_ibss_work+0x0/0x198 [mac80211]) from [<c0064318>] (run_workqueue+0xac/0x124)
[ 3905.537261] r5:c53ac000 r4:c53a7a80
[ 3905.537292] [<c006426c>] (run_workqueue+0x0/0x124) from [<c00649dc>] (worker_thread+0x104/0x118)
[ 3905.537353] r7:c53a7a88 r6:c53adfa4 r5:c53ac000 r4:c53a7a80
[ 3905.537384] [<c00648d8>] (worker_thread+0x0/0x118) from [<c0067fe4>] (kthread+0x58/0x94)
[ 3905.537475] r7:00000000 r6:c53a7a80 r5:c00648d8 r4:c53ac000
[ 3905.537506] [<c0067f8c>] (kthread+0x0/0x94) from [<c0057054>] (do_exit+0x0/0x67c)
[ 3905.537567] r7:00000000 r6:00000000 r5:00000000 r4:00000000
[ 3905.537597] ---[ end trace 09523b411832988b ]---
[...cut...]
- and the fact, that the device is up, but not "running"
# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:02:ee:c0:ff:ee
inet addr:10.0.59.34 Bcast:10.0.59.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:550 errors:0 dropped:0 overruns:0 frame:0
TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:58779 (58.7 KB) TX bytes:1080 (1.0 KB)
# iwconfig wlan0
wlan0 IEEE 802.11bg ESSID:"rita"
Mode:Ad-Hoc Frequency:2.462 GHz Cell: 1A:7E:4B:A7:14:45
Tx-Power=27 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
If you have any ideas, or patches or infos,
i'll be happy to try these and give some feedback :)
Regards,
AleX
ps: If you need further infos, just let me know...
--
**********************************************
Dipl.-Inform. (FH) Alexander Wenzel
Forschungsgesellschaft fuer
Angewandte Naturwissenschaften e. V. (FGAN)
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel. : 0049 (0)228 9435-263
Fax : 0049 (0)228 9435-685
E-Mail: wenzel@fgan.de
Web : http://www.fgan.de/
**********************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. Maurus Tacke (komm. Vors.)
Prof. Dr. Joachim Ender (Stellv.)
^ permalink raw reply
* Re: [PATCH] wireless: fix supported cards for rtl8187
From: Gábor Stefanik @ 2009-07-09 12:49 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: Marcin Slusarz, Larry Finger, John W. Linville, Linux wireless,
Przemyslaw Kulczycki, LKML
In-Reply-To: <3ace41890907090540v6895e2bay8128c0d565a7a55f@mail.gmail.com>
2009/7/9 Hin-Tak Leung <hintak.leung@gmail.com>:
> Here is some info from Gabor (shouldn't this be reply-all rather than just me):
> ------------------
> The v1 and v2 look identical (though the label on the device indicates
> the revision). The v3 looks completely different. They all have
> different USB IDs (v1 is stock RT73, v2 has a custom ID, while v3 is
> AFAIK stock RT2070).
> ------------------
>
> I guess to be informative, may I suggest adding '(for v1 see rt73usb,
> and v3 see rt3070)' or something similiar to the 'v2' change?
> It is fair customary in Kconfig to mention even alternative/competing
> drivers for the same device. And when you add v3 support to the rt3070
> driver, a reverse mention may be appropriate. (I guess I am spending
> far too long on this discussion - but I reckon, the purpose of a
> non-code-changing change is meant to be informative, so one might want
> to be as informative as appropriate without being too wordy...)
>
Yes, sorry, it was intended to be reply-to-all, but Gmail's
default-reply-to-all feature appears to be broken.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] wireless: fix supported cards for rtl8187
From: Marcin Slusarz @ 2009-07-09 13:11 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: Larry Finger, John W. Linville, Linux wireless,
Przemyslaw Kulczycki, LKML, Gábor Stefanik
In-Reply-To: <3ace41890907090540v6895e2bay8128c0d565a7a55f@mail.gmail.com>
Hin-Tak Leung wrote:
> 2009/7/9 Marcin Slusarz <marcin.slusarz@gmail.com>:
>> Hin-Tak Leung pisze:
>>> 2009/7/9 Larry Finger <Larry.Finger@lwfinger.net>:
>>>> Hin-Tak Leung wrote:
>>>>> if they are not labelled v1/v2/v3 as such, it may be more
>>>>> useful/informative to change to
>>>>>
>>>>> [some variant of ] ... [(other variants are supported by the
>>>>> rt2070/rt3070 modules)]
>>>>>
>>>>> instead of just adding [v2] to the end.
>>>> I don't know about the box as I bought mine used on Ebay, but the
>>>> label on the device clearly states that it is a WG111v2.
>>>>
>>>> Larry
>>>>
>>>>
>>> But that's a Netgear WG111v2 ? We are talking about Linksys
>>> WUSB54GC-EU and its v1/v2/v3 . I am just thinking that if it is for
>>> informative purposes (for those who actually selectively build their
>>> kernel modules), adding a bit more info, such as suggesting to use
>>> rt73usb/rt2070/rt3070 modules, won't hurt.
>>>
>>> Incidentally I like to know a bit more about this patch - presumably
>>> Marcin has such a device? I am also a little curious, as this commit
>>> should be accompanied by a corresponding update in another Kconfig
>>> which supports the device? I am not trying to be picky, but for an
>>> informative (non-code-changing) patch, it can be more informative.
>> I have a v3 device and this driver does not support it.
>> Below is the commit which added the string my patch corrects.
>> I've sent yesterday another patch which adds support for WUSB54GC v3
>> to the rt3070 driver.
>
> Here is some info from Gabor (shouldn't this be reply-all rather than just me):
> ------------------
> The v1 and v2 look identical (though the label on the device indicates
> the revision). The v3 looks completely different. They all have
> different USB IDs (v1 is stock RT73, v2 has a custom ID, while v3 is
> AFAIK stock RT2070).
> ------------------
>
> I guess to be informative, may I suggest adding '(for v1 see rt73usb,
> and v3 see rt3070)' or something similiar to the 'v2' change?
> It is fair customary in Kconfig to mention even alternative/competing
> drivers for the same device. And when you add v3 support to the rt3070
> driver, a reverse mention may be appropriate. (I guess I am spending
> far too long on this discussion - but I reckon, the purpose of a
> non-code-changing change is meant to be informative, so one might want
> to be as informative as appropriate without being too wordy...)
Look, support for Ralink chipsets is a mess. They are supported by too sets
of drivers - Ralink's ugly as hell but working staging drivers (rt2860,
rt2870, rt3070, soon rt3090) and properly developed but lagging rt2x00
drivers (RT2400PCI, RT2500PCI, RT61PCI, RT2500USB, RT73USB, RT2800USB).
Theoretically my WUSB54GCv3 is supported by RT2800USB (which was added during
2.6.31 merge window), but it doesn't work. With tiny patch added to rt3070
(just usb id) my card works. Some day rt2x00 drivers will be better than Ralink's,
but right now they are not.
So I wouldn't like to encourage any of them. I just wanted to fix clearly
wrong help text which stated that rtl8187 (Realtek's chipset!) supports
all WUSB54GC cards.
Marcin
^ permalink raw reply
* Re: Problem with p54 driver and ibss mode
From: Max Filippov @ 2009-07-09 13:20 UTC (permalink / raw)
To: Alexander Wenzel; +Cc: linux-wireless
In-Reply-To: <4A55DB91.2070305@fgan.de>
On Thu, Jul 9, 2009 at 3:59 PM, Alexander Wenzel<wenzel@fgan.de> wrote:
> Hi!
> I'm trying to get the latest p54 wireless drivers (ad-hoc mode)
> to work on a Nokia N810... So far, without any success.
>
> Some words about my scenario:
> - Nokia N810 running a custom omap1 kernel
> (linux-omap-2.6.git / tag: "v2.6.29-omap1")
> Patched keyboard (board-n800.c) and usb driver (usb-tusb6010.c)
> to get it working...
>
> - Installed Mer (Ubuntu 9.04) on an external mmc 4GB card
> Patched the bootmenu stuff to get rid of static /dev/ nodes problem
> which come up with the new kernel...
>
> - compiled compat wireless drivers 2009-07-09
> disabled CONFIG_RFKILL_BACKPORT_LEDS because it didn't compile
>
> - A second N810 running debian and nokias 2.6.21er kernel
> Ad-hoc mode is active. (ad-hoc is working, tested with some
> other N810 devices)
>
> After all these preparations, patching and workaround stuff,
> i finally inserted the wireless modules into the kernel
> (rfkill_backport, cfg80211, mac80211, p54common, p54spi)
> dmesg looks fine so far:
> [ 3671.237365] cfg80211: Using static regulatory domain info
> [ 3671.237396] cfg80211: Regulatory domain: US
> [ 3671.237426] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> [ 3671.237457] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
> [ 3671.237487] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 3671.237518] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 3671.237548] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 3671.237579] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 3671.237609] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
> [ 3671.238555] cfg80211: Calling CRDA for country: US
> [ 3685.186523] cx3110x spi2.0: firmware: requesting 3826.arm
> [ 3685.265045] phy0: p54 detected a LM20 firmware
> [ 3685.265106] p54: rx_mtu reduced from 3240 to 2376
> [ 3685.265106] phy0: FW rev 2.13.0.0.a.22.8 - Softmac protocol 5.6
> [ 3685.265136] phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
> [ 3685.265197] cx3110x spi2.0: firmware: requesting 3826.eeprom
> [ 3685.320800] cx3110x spi2.0: loading default eeprom...
> [ 3685.320922] phy0: hwaddr 00:02:ee:c0:ff:ee, MAC:isl3820 RF:Longbow
> [ 3685.455108] phy0: Selected rate control algorithm 'minstrel'
> [ 3685.456787] Registered led device: p54-phy0::assoc
> [ 3685.457031] Registered led device: p54-phy0::tx
> [ 3685.457275] Registered led device: p54-phy0::rx
> [ 3685.457489] Registered led device: p54-phy0::radio
> [ 3685.457550] cx3110x spi2.0: is registered as 'phy0'
>
> Monitor mode is also working. Here are some beacons from my second device:
> 00:01:37.463744 51669459us tsft 1.0 Mb/s 2462 MHz (0x00a0) 30dB signal -63dB noise antenna 0 [0x0000000e] Beacon (rita) [1.0* 2.0* 5.5 11.0 Mbit] IBSS CH: 11
> 00:01:37.566100 51771860us tsft 1.0 Mb/s 2462 MHz (0x00a0) 29dB signal -63dB noise antenna 0 [0x0000000e] Beacon (rita) [1.0* 2.0* 5.5 11.0 Mbit] IBSS CH: 11
> 00:01:37.668517 51874300us tsft 1.0 Mb/s 2462 MHz (0x00a0) 30dB signal -63dB noise antenna 0 [0x0000000e] Beacon (rita) [1.0* 2.0* 5.5 11.0 Mbit] IBSS CH: 11
>
> After this short test, i switched the driver into ad-hoc mode,
> setup the essid, channel and assigned an ip address... I tried
> to ping, tcpdump, whatsoever... nothing happens. Driver statistics
> are also frozen (in monitor mode the rx stats incr.).
> The only hints to the problem are:
> - this repeating kernel msg:
> [...cut...]
> [ 3905.535125] WARNING: at /home/wen/work/NokiaN810/compat-wireless-2009-07-09/net/mac80211/sta_info.c:339 sta_info_insert+0x7c/0x15c [mac80211]()
> [ 3905.535186] Modules linked in: p54spi p54common mac80211 cfg80211 rfkill_backport
> [ 3905.535247] [<c02b73a0>] (dump_stack+0x0/0x14) from [<c00541cc>] (warn_slowpath+0x70/0x8c)
> [ 3905.535308] [<c005415c>] (warn_slowpath+0x0/0x8c) from [<bf02af40>] (sta_info_insert+0x7c/0x15c [mac80211])
> [ 3905.535522] r3:00000000 r2:00000000
> [ 3905.535552] r7:c53a4200 r6:c7e65800 r5:0000c0ee r4:c5303b60
> [ 3905.535583] [<bf02aec4>] (sta_info_insert+0x0/0x15c [mac80211]) from [<bf02f220>] (ieee80211_ibss_add_sta+0x114/0x130 [mac80211])
> [ 3905.535919] r7:c7d9442e r6:c7e65800 r5:c53a4200 r4:c7e65800
> [ 3905.535949] [<bf02f10c>] (ieee80211_ibss_add_sta+0x0/0x130 [mac80211]) from [<bf02f35c>] (ieee80211_rx_bss_info+0x120/0x160 [mac80211])
> [ 3905.536407] [<bf02f23c>] (ieee80211_rx_bss_info+0x0/0x160 [mac80211]) from [<bf02f590>] (ieee80211_ibss_rx_queued_mgmt+0x1f4/0x274 [mac80211])
> [ 3905.536743] [<bf02f39c>] (ieee80211_ibss_rx_queued_mgmt+0x0/0x274 [mac80211]) from [<bf02f684>] (ieee80211_ibss_work+0x74/0x198 [mac80211])
> [ 3905.537048] [<bf02f610>] (ieee80211_ibss_work+0x0/0x198 [mac80211]) from [<c0064318>] (run_workqueue+0xac/0x124)
> [ 3905.537261] r5:c53ac000 r4:c53a7a80
> [ 3905.537292] [<c006426c>] (run_workqueue+0x0/0x124) from [<c00649dc>] (worker_thread+0x104/0x118)
> [ 3905.537353] r7:c53a7a88 r6:c53adfa4 r5:c53ac000 r4:c53a7a80
> [ 3905.537384] [<c00648d8>] (worker_thread+0x0/0x118) from [<c0067fe4>] (kthread+0x58/0x94)
> [ 3905.537475] r7:00000000 r6:c53a7a80 r5:c00648d8 r4:c53ac000
> [ 3905.537506] [<c0067f8c>] (kthread+0x0/0x94) from [<c0057054>] (do_exit+0x0/0x67c)
> [ 3905.537567] r7:00000000 r6:00000000 r5:00000000 r4:00000000
> [ 3905.537597] ---[ end trace 09523b411832988b ]---
> [...cut...]
>
> - and the fact, that the device is up, but not "running"
> # ifconfig wlan0
> wlan0 Link encap:Ethernet HWaddr 00:02:ee:c0:ff:ee
> inet addr:10.0.59.34 Bcast:10.0.59.255 Mask:255.255.255.0
> UP BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:550 errors:0 dropped:0 overruns:0 frame:0
> TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:58779 (58.7 KB) TX bytes:1080 (1.0 KB)
>
> # iwconfig wlan0
> wlan0 IEEE 802.11bg ESSID:"rita"
> Mode:Ad-Hoc Frequency:2.462 GHz Cell: 1A:7E:4B:A7:14:45
> Tx-Power=27 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
>
> If you have any ideas, or patches or infos,
> i'll be happy to try these and give some feedback :)
>
> Regards,
> AleX
>
> ps: If you need further infos, just let me know...
> --
> **********************************************
> Dipl.-Inform. (FH) Alexander Wenzel
> Forschungsgesellschaft fuer
> Angewandte Naturwissenschaften e. V. (FGAN)
> Neuenahrer Str. 20, 53343 Wachtberg, Germany
> Tel. : 0049 (0)228 9435-263
> Fax : 0049 (0)228 9435-685
> E-Mail: wenzel@fgan.de
> Web : http://www.fgan.de/
> **********************************************
> Sitz der Gesellschaft: Bonn
> Registergericht: Amtsgericht Bonn VR 2530
> Vorstand: Prof. Dr. Maurus Tacke (komm. Vors.)
> Prof. Dr. Joachim Ender (Stellv.)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hello.
> [ 3905.535125] WARNING: at /home/wen/work/NokiaN810/compat-wireless-2009-07-09/net/mac80211/sta_info.c:339 sta_info_insert+0x7c/0x15c [mac80211]()
As far as I can see, this is check that incoming STA and your STA have
different MAC addresses. If you don't set up MAC manually on both
devices and make it unique, chances high that they are equal.
--
Max
^ permalink raw reply
* Re: nl80211 and wext interoperability
From: John W. Linville @ 2009-07-09 14:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1247139797.2144.27.camel@johannes.local>
On Thu, Jul 09, 2009 at 01:43:17PM +0200, Johannes Berg wrote:
> Do we just ignore that issue? It's only added timeout and people using
> purely nl80211 will never have a problem.
In my opinion this is acceptable.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: Problem with p54 driver and ibss mode
From: Alexander Wenzel @ 2009-07-09 15:35 UTC (permalink / raw)
To: Max Filippov; +Cc: linux-wireless
In-Reply-To: <73aaf0dd0907090620i752b7f9cq60563f8e22c02d75@mail.gmail.com>
Hi!
>> I'm trying to get the latest p54 wireless drivers (ad-hoc mode)
>> to work on a Nokia N810... So far, without any success.
>> [ 3905.535125] WARNING: at /home/wen/work/NokiaN810/compat-wireless-2009-07-09/net/mac80211/sta_info.c:339 sta_info_insert+0x7c/0x15c [mac80211]()
> As far as I can see, this is check that incoming STA and your STA have
> different MAC addresses. If you don't set up MAC manually on both
> devices and make it unique, chances high that they are equal.
You saved my day :D Finally it works...! Thanks for the hint.
[ 214.478668] wlan0: Selected IBSS BSSID 56:97:1a:24:11:6c based on configured SSID
# iw dev wlan0 station dump
Station 00:02:ee:c0:ff:ee (on wlan0)
inactive time: 429 ms
rx bytes: 8964
tx bytes: 408
signal: 55 dBm
tx bitrate: 1.0 MBit/s
I just checked the other N810 devices and every device has
the same mac address. And here we go... [p54spi_eeprom.h:39]
0x00, 0x02, 0xee, 0xc0, 0xff, 0xee,
The original kernel with default os shows the correct address.
When booting a different os with the with the original or custom
kernel it shows the 'coffee' address.
So is there a way to let the kernel receive and set the
correct mac address of the wlan device?
I guess my problem is this line:
[ 3685.320800] cx3110x spi2.0: loading default eeprom...
Anyway, i'm happy that it's working now.
Regards,
AleX
--
**********************************************
Dipl.-Inform. (FH) Alexander Wenzel
Forschungsgesellschaft fuer
Angewandte Naturwissenschaften e. V. (FGAN)
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel. : 0049 (0)228 9435-263
Fax : 0049 (0)228 9435-685
E-Mail: wenzel@fgan.de
Web : http://www.fgan.de/
**********************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. Maurus Tacke (komm. Vors.)
Prof. Dr. Joachim Ender (Stellv.)
^ permalink raw reply
* Re: kernel .30 BROKE ATH5K with my AR5212 atheros.
From: Jasin Colegrove @ 2009-07-09 16:42 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless
In-Reply-To: <20090708114252.GG7199@hash.localnet>
> BTW, can you (re?)post the "Atheros AR5212 chip found (MAC xxx,
> PHY xxxx)?"
>
What exact information do you want and where can I find it?
> Also at least /net (you can add multiple paths to git bisect).
$git bisect start v2.6.30-rc4 v2.6.29 -- drivers/net net/
Is that what you where hinting at? I wasted a whole day trying to fix
errors in drivers/staging before I was told I could just disable
compilation of staging with one switch. Oh well...
^ permalink raw reply
* Re: kernel .30 BROKE ATH5K with my AR5212 atheros.
From: Bob Copeland @ 2009-07-09 16:55 UTC (permalink / raw)
To: Jasin Colegrove; +Cc: linux-wireless
In-Reply-To: <6c354a1a0907090942o66c4e1b8ue2c952cf7ed7bf9a@mail.gmail.com>
On Thu, Jul 9, 2009 at 12:42 PM, Jasin
Colegrove<j.wholesalesupply@gmail.com> wrote:
>> BTW, can you (re?)post the "Atheros AR5212 chip found (MAC xxx,
>> PHY xxxx)?"
>>
> What exact information do you want and where can I find it?
Run 'dmesg'; a string like the above is printed out when the module
loads. In case there was something broken specifically for your
chipset, the mac/phy versions will help narrow it down.
> $git bisect start v2.6.30-rc4 v2.6.29 -- drivers/net net/
>
> Is that what you where hinting at? I wasted a whole day trying to fix
> errors in drivers/staging before I was told I could just disable
> compilation of staging with one switch. Oh well...
Yes, that's what I meant. And it does help to have a relatively
slimmed down .config, especially when bisecting. :\
--
Bob Copeland %% www.bobcopeland.com
^ 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