* Re: [PATCH] b43: Don't abuse wl->current_dev in the led work
From: Larry Finger @ 2009-09-15 13:27 UTC (permalink / raw)
To: Michael Buesch; +Cc: John W. Linville, Broadcom Wireless, linux-wireless
In-Reply-To: <200909151149.22565.mb@bu3sch.de>
Michael Buesch wrote:
> On Tuesday 15 September 2009 00:58:18 Larry Finger wrote:
>> Michael Buesch wrote:
>>> Don't abuse wl->current_dev in the LED work for checking whether we're
>>> going down. Add an explicit variable.
>>> This fixes a crash on rmmod dereferencing the wl->current_dev NULL pointer
>>> in various other places of the driver.
>>>
>>> Signed-off-by: Michael Buesch <mb@bu3sch.de>
>> This patch does not apply. What other patches should I have beyond the
>> current state of wireless-testing?
>
> All patches that are currently queued up.
I found the ones I needed in my mailboxes.
The patch cured my problem. Thanks and ack.
Larry
^ permalink raw reply
* Re: [RFC] ar9170usb: add ar9170 usbid
From: Stefan Lippers-Hollmann @ 2009-09-15 11:37 UTC (permalink / raw)
To: Christian Lamparter
Cc: Fabian Lenz, linux-wireless, Stephen.Chen, Luis R. Rodriguez
In-Reply-To: <200909151006.26631.chunkeey@googlemail.com>
Hi
On Tuesday 15 September 2009, Christian Lamparter wrote:
> On Tuesday 15 September 2009 07:52:19 Fabian Lenz wrote:
> > Here the output of lsusb:
> >
> > Bus 002 Device 003: ID 0cf3:1002 Atheros Communications, Inc.
>
> they made two revisions (v1 and v2).
> Do you know which one you've got?
v1 (FCC ID: TE7WN821NV1) at least identifies itself as:
ID 0cf3:9170 Atheros Communications, Inc. AR9170 802.11n
> > and the product page of the WLAN stick:
> >
> > http://www.tp-link.com/products/product_des.asp?id=140
> >
> > I added { USB_DEVICE(0x0cf3, 0x1002) } to the usb.c file manually some time
> > ago and got my stick to work but the connection is somewhat unstable... but
> > that's another story.
> what firmware image do you use?
> the two-stage (ar9170-1.fw & ar9170-2.fw) firmware should work.
> for one-stage you should use a bleeding edge wireless-testing tree.
On this TL-WN821N v1 the one-stage (as published in binary from by Atheros,
so far I had problems with my self compiled one) and two-stage firmwares
work equally well on a vanilla 2.6.31 kernel:
usb 1-2: new high speed USB device using ehci_hcd and address 4
usb 1-2: New USB device found, idVendor=0cf3, idProduct=9170
usb 1-2: New USB device strings: Mfr=16, Product=32, SerialNumber=48
usb 1-2: Product: USB2.0 WLAN
usb 1-2: Manufacturer: ATHER
usb 1-2: SerialNumber: 12345
usb 1-2: configuration #1 chosen from 1 choice
usb 1-2: reset high speed USB device using ehci_hcd and address 4
usb 1-2: firmware: requesting ar9170.fw
ath: EEPROM regdomain: 0x809c
ath: EEPROM indicates we should expect a country code
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x52
ath: Country alpha2 being used: CN
ath: Regpair used: 0x52
phy2: Selected rate control algorithm 'minstrel'
cfg80211: Calling CRDA for country: CN
Registered led device: ar9170-phy2::tx
Registered led device: ar9170-phy2::assoc
usb 1-2: Atheros AR9170 is registered as 'phy2'
usbcore: registered new interface driver ar9170usb
udev: renamed network interface wlan2 to wlan3
cfg80211: Current regulatory domain intersected:
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Regards
Stefan Lippers-Hollmann
^ permalink raw reply
* Re: [PATCH] b43: Don't abuse wl->current_dev in the led work
From: Michael Buesch @ 2009-09-15 9:49 UTC (permalink / raw)
To: Larry Finger; +Cc: John W. Linville, Broadcom Wireless, linux-wireless
In-Reply-To: <4AAECA8A.1060200@lwfinger.net>
On Tuesday 15 September 2009 00:58:18 Larry Finger wrote:
> Michael Buesch wrote:
> > Don't abuse wl->current_dev in the LED work for checking whether we're
> > going down. Add an explicit variable.
> > This fixes a crash on rmmod dereferencing the wl->current_dev NULL pointer
> > in various other places of the driver.
> >
> > Signed-off-by: Michael Buesch <mb@bu3sch.de>
>
> This patch does not apply. What other patches should I have beyond the
> current state of wireless-testing?
All patches that are currently queued up.
--
Greetings, Michael.
^ permalink raw reply
* Re: alloc skb based on a given data buffer
From: Zhu Yi @ 2009-09-15 9:15 UTC (permalink / raw)
To: David Miller
Cc: mel@csn.ul.ie, Chatre, Reinette, elendil@planet.nl,
Larry.Finger@lwfinger.net, linville@tuxdriver.com,
penberg@cs.helsinki.fi, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, akpm@linux-foundation.org,
cl@linux-foundation.org, Krauss, Assaf, johannes@sipsolutions.net,
Abbas, Mohamed, netdev@vger.kernel.org
In-Reply-To: <20090915.020903.93643290.davem@davemloft.net>
On Tue, 2009-09-15 at 17:09 +0800, David Miller wrote:
> From: Zhu Yi <yi.zhu@intel.com>
> Date: Tue, 15 Sep 2009 16:57:29 +0800
>
> > Thanks. So we can put the 8K buffer into 2 skb_shinfo()->frags[] slots
> > and set nr_frags to 2, right? Is this supported allover the network code
> > already? At a first glance, I didn't find any frags handling in mac80211
> > stack.
>
> You have to pre-pull the link level protocol headers into the
> linear area, but that's it.
>
> Again, see niu.c for details, it does:
>
> static void niu_rx_skb_append(struct sk_buff *skb, struct page *page,
> u32 offset, u32 size)
> {
> int i = skb_shinfo(skb)->nr_frags;
> skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
>
> frag->page = page;
> frag->page_offset = offset;
> frag->size = size;
>
> skb->len += size;
> skb->data_len += size;
> skb->truesize += size;
>
> skb_shinfo(skb)->nr_frags = i + 1;
> }
>
> to add pages to SKBs and then at the end it goes:
>
> skb_reserve(skb, NET_IP_ALIGN);
> __pskb_pull_tail(skb, min(len, NIU_RXPULL_MAX));
>
> Right before giving the SKB to the networking stack. NIU_RXPULL_MAX
> should be a value that will be large enough to cover the largest
> possible link level header.
I see. Thanks for this info. I'll try implementing the same for iwlagn.
Thanks,
-yi
^ permalink raw reply
* Re: alloc skb based on a given data buffer
From: David Miller @ 2009-09-15 9:09 UTC (permalink / raw)
To: yi.zhu
Cc: mel, reinette.chatre, elendil, Larry.Finger, linville, penberg,
linux-kernel, linux-wireless, ipw3945-devel, akpm, cl,
assaf.krauss, johannes, mohamed.abbas, netdev
In-Reply-To: <1253005050.7549.58.camel@debian>
From: Zhu Yi <yi.zhu@intel.com>
Date: Tue, 15 Sep 2009 16:57:29 +0800
> Thanks. So we can put the 8K buffer into 2 skb_shinfo()->frags[] slots
> and set nr_frags to 2, right? Is this supported allover the network code
> already? At a first glance, I didn't find any frags handling in mac80211
> stack.
You have to pre-pull the link level protocol headers into the
linear area, but that's it.
Again, see niu.c for details, it does:
static void niu_rx_skb_append(struct sk_buff *skb, struct page *page,
u32 offset, u32 size)
{
int i = skb_shinfo(skb)->nr_frags;
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
frag->page = page;
frag->page_offset = offset;
frag->size = size;
skb->len += size;
skb->data_len += size;
skb->truesize += size;
skb_shinfo(skb)->nr_frags = i + 1;
}
to add pages to SKBs and then at the end it goes:
skb_reserve(skb, NET_IP_ALIGN);
__pskb_pull_tail(skb, min(len, NIU_RXPULL_MAX));
Right before giving the SKB to the networking stack. NIU_RXPULL_MAX
should be a value that will be large enough to cover the largest
possible link level header.
^ permalink raw reply
* Re: alloc skb based on a given data buffer
From: Zhu Yi @ 2009-09-15 8:57 UTC (permalink / raw)
To: David Miller
Cc: mel@csn.ul.ie, Chatre, Reinette, elendil@planet.nl,
Larry.Finger@lwfinger.net, linville@tuxdriver.com,
penberg@cs.helsinki.fi, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, akpm@linux-foundation.org,
cl@linux-foundation.org, Krauss, Assaf, johannes@sipsolutions.net,
Abbas, Mohamed, netdev@vger.kernel.org
In-Reply-To: <20090915.013321.07006714.davem@davemloft.net>
On Tue, 2009-09-15 at 16:33 +0800, David Miller wrote:
> From: Zhu Yi <yi.zhu@intel.com>
> Date: Tue, 15 Sep 2009 16:30:20 +0800
>
> > This way, device drivers can allocate the Rx buffers with their own size
> > and alignment requirement. i.e. do an order-1 page allocation directly
> > with free_pages() in the iwlagn driver for a 256 bytes aligned 8K Rx
> > buffer. After DMA is finished, drivers can use the above function to
> > assemble an skb based on the Rx buffer. It should resolve the problem
> > for requiring an order-2 allocation by alloc_skb() in the first place.
>
> You can create paged RX skbs just like drivers such as niu.c
> and others already do, there is no need for special APIs for
> this.
Thanks. So we can put the 8K buffer into 2 skb_shinfo()->frags[] slots
and set nr_frags to 2, right? Is this supported allover the network code
already? At a first glance, I didn't find any frags handling in mac80211
stack.
Thanks,
-yi
^ permalink raw reply
* Re: [RFC] ar9170usb: add ar9170 usbid
From: Christian Lamparter @ 2009-09-15 8:54 UTC (permalink / raw)
To: Stephen Chen; +Cc: Fabian Lenz, linux-wireless@vger.kernel.org, Luis Rodriguez
In-Reply-To: <618D4DE9D5223A45A46C48063FD64045109947ACC0@TAEXMB-01.global.atheros.com>
On Tuesday 15 September 2009 01:39:40 Stephen Chen wrote:
> Hi Christian,
>
> I could not find this VID/PID in INF file in Windows release.
> This ID combination could be obsolete.
you can get their vendor driver from here:
http://www.tp-link.com/support/download.asp?a=1&m=TL-WN821N
-> Driver Files/XP/arusb_xp.inf
--- snip --- Driver Files/${OS}/arusb_${OS}.inf
%ATHR.DeviceDesc.9170% = ATHRXP9170.ndi, USB\VID_0CF3&PID_1002
ATHR.DeviceDesc.9170 = "TP-LINK TL-WN821N 11N Wireless Adapter"
--- snip ---
Looks like they are trying to hijack Atheros' usbid space
by assigning custom product IDs.
This can confuse the unsuspected user and maybe break some stuff.
I'm not joking, this is an accident waiting to happen!
(see "rt2500usb vs. rt73usb" => http://patchwork.kernel.org/patch/45342/
for how this can go wrong.)
For now, you/[Atheros] should add the PID to your win driver as well
(so it's marked as _used_) and get in touch with TP-Link to come up
with a way for vendors - w/o their own VID - to get custom PIDs.
Regards,
Chr
^ permalink raw reply
* Re: alloc skb based on a given data buffer
From: David Miller @ 2009-09-15 8:33 UTC (permalink / raw)
To: yi.zhu
Cc: mel, reinette.chatre, elendil, Larry.Finger, linville, penberg,
linux-kernel, linux-wireless, ipw3945-devel, akpm, cl,
assaf.krauss, johannes, mohamed.abbas, netdev
In-Reply-To: <1253003420.7549.51.camel@debian>
From: Zhu Yi <yi.zhu@intel.com>
Date: Tue, 15 Sep 2009 16:30:20 +0800
> This way, device drivers can allocate the Rx buffers with their own size
> and alignment requirement. i.e. do an order-1 page allocation directly
> with free_pages() in the iwlagn driver for a 256 bytes aligned 8K Rx
> buffer. After DMA is finished, drivers can use the above function to
> assemble an skb based on the Rx buffer. It should resolve the problem
> for requiring an order-2 allocation by alloc_skb() in the first place.
You can create paged RX skbs just like drivers such as niu.c
and others already do, there is no need for special APIs for
this.
^ permalink raw reply
* alloc skb based on a given data buffer
From: Zhu Yi @ 2009-09-15 8:30 UTC (permalink / raw)
To: Mel Gorman
Cc: Chatre, Reinette, Frans Pop, Larry Finger, John W. Linville,
Pekka Enberg, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Andrew Morton,
cl@linux-foundation.org, Krauss, Assaf, Johannes Berg,
Abbas, Mohamed, netdev
In-Reply-To: <20090914130612.GA11778@csn.ul.ie>
[ Cc netdev and change the subject ]
On Mon, 2009-09-14 at 21:06 +0800, Mel Gorman wrote:
> > Essentially, the hardware only requires an order-1 allocation aligned on
> > 256 bytes boundary. But as it is used as an SKB, a trailing struct
> > skb_shared_info is added. This forces us to both increase the order and
> > do alignment ourselves. I believe some improvement could be done here.
> > But it should not be an easy one.
> >
>
> Probably not. I can only assume that moving the location of
> skb_shared_info such that it is sometimes located after the buffer and
> sometimes allocated via a separate kmalloc() would be a significant
> undertaking.
Shall I propose below function as a variant to alloc_skb()?
struct sk_buff *alloc_skb_attach_buff(void *data_buff,
unsigned int real_size,
unsigned int size, gfp_t mask);
If real_size >= size + sizeof(struct skb_shared_info), we can still put
the shinfo at the end of the buffer. Otherwise we can allocate from a
new slab that put sk_buff and shinfo together. Of course, kfree_skbmem()
needs to recognize it.
This way, device drivers can allocate the Rx buffers with their own size
and alignment requirement. i.e. do an order-1 page allocation directly
with free_pages() in the iwlagn driver for a 256 bytes aligned 8K Rx
buffer. After DMA is finished, drivers can use the above function to
assemble an skb based on the Rx buffer. It should resolve the problem
for requiring an order-2 allocation by alloc_skb() in the first place.
Comments are welcome.
Thanks,
-yi
^ permalink raw reply
* Re: [RFC] ar9170usb: add ar9170 usbid
From: Christian Lamparter @ 2009-09-15 8:06 UTC (permalink / raw)
To: Fabian Lenz; +Cc: linux-wireless, Stephen.Chen, Luis R. Rodriguez
In-Reply-To: <200909150752.19146.lenz_fabian@yahoo.de>
On Tuesday 15 September 2009 07:52:19 Fabian Lenz wrote:
> Here the output of lsusb:
>
> Bus 002 Device 003: ID 0cf3:1002 Atheros Communications, Inc.
they made two revisions (v1 and v2).
Do you know which one you've got?
> and the product page of the WLAN stick:
>
> http://www.tp-link.com/products/product_des.asp?id=140
>
> I added { USB_DEVICE(0x0cf3, 0x1002) } to the usb.c file manually some time
> ago and got my stick to work but the connection is somewhat unstable... but
> that's another story.
what firmware image do you use?
the two-stage (ar9170-1.fw & ar9170-2.fw) firmware should work.
for one-stage you should use a bleeding edge wireless-testing tree.
Regards,
Chr
^ permalink raw reply
* Re: [PATCH] cfg80211: don't report SME connection errs at SIOCSIW{FREQ/AP/ESSID}
From: Holger Schurig @ 2009-09-15 6:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John W Linville
In-Reply-To: <1252950234.23427.51.camel@johannes.local>
> And doesn't look correct to me at all. probably something
> missing wrt. disconnect() while connecting.
Can you then outline the right solution ?
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: RTL8187B wireless driver issue
From: Hin-Tak Leung @ 2009-09-15 4:04 UTC (permalink / raw)
To: Vignette consultant; +Cc: Larry Finger, linux-wireless
In-Reply-To: <3b0e19890909141951uf8b80c0ta3619045b54efff3@mail.gmail.com>
On Tue, Sep 15, 2009 at 3:51 AM, Vignette consultant
<vignette75@gmail.com> wrote:
> 1 how can i check if wpa_supplicant is running or not?
(sigh...) well, have a look at 'ps -lax' , e.g.
ps -lax | grep wpa
ps -lax | grep -i net
ps -lax | grep dh
and see if there is anything you don't know the nature of... (and look
it up on the web!).
> 3 are you saying "to use different driver"?
yes, different version/release of the driver
>
> 2 where do i need put essid, so udev can use it?
YMMV, on my system (fedora) these are the system locations for wlan2.
/etc/wpa_supplicant/wpa_supplicant.conf
/etc/sysconfig/networking/devices/ifcfg-wlan2
/etc/sysconfig/networking/devices/keys-wlan2
/etc/sysconfig/networking/profiles/default/ifcfg-wlan2
/etc/sysconfig/networking/profiles/default/keys-wlan2
essid is in /etc/wpa_supplicant/wpa_supplicant.conf and ifcfg-*, and
the key is in keys-* and also in
/etc/wpa_supplicant/wpa_supplicant.conf . Also if you use
NetworkManager, it can take credentials from the gnome-keyring-manager
as well.
In the normal course of event, when one if up a network interface,
udev tells either the network service to configure the interface or
talk to NetworkManger via dbus to do it. both network service and
NetworkManager tells wpa_supplicant to start scanning for known APs or
open APs and try to authenticate.
If you are not aware of what wpa_supplicant might be doing, it could
unset whatever credentials you try to set as it scans and look for
known or open APs. You should try to use the NetworkManager applet or
Wireless assistant to set essid and credentials, rather than by hand
on the command line.
Hmm, your Vista screenshot says the AP is unsecure (and the signal
strength is poor), is that the case?
^ permalink raw reply
* Re: RTL8187B wireless driver issue
From: Vignette consultant @ 2009-09-15 2:51 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Larry Finger, linux-wireless
In-Reply-To: <3ace41890909141824i2f274a91rc19e50eac254e950@mail.gmail.com>
1 how can i check if wpa_supplicant is running or not?
3 are you saying "to use different driver"?
2 where do i need put essid, so udev can use it?
On 9/14/09, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
> On Mon, Sep 14, 2009 at 10:34 PM, Vignette consultant
> <vignette75@gmail.com> wrote:
>> Hi
>>
>> I get timed out errors consistently as per attached log file.
>> I tried several Live Cds from fedora, sidux - but i get the same dhcp
>> error. I used to be able to connect before.
>>
>> Please check attached log and see if you can point me towards the
>> solution.
>
> Your log do not add anything new - I already asked you to do 3 things,
> and there is no indication you have done any of them; there is no
> point writing me the same things you had wrote to Larry or
> linux-wireless, and try to get a private answer - Your won't. (please
> do not remove the CC:'s and please do not write privately on general
> help matters).
>
> 1) make sure that wpa_supplicant is *not* running - newer liveCDs can
> have wpa_supplicant working (compare to older which does not use it).
>
> 2) make sure your authentication credentials - essid, passphases - are
> in the network config files and agree with what you are trying to set
> on the command line, just in case udev wants to unset your credentials
> you are setting manually on the comamnd line.
>
> 3) switch from kernel-modules-backport to a different version of
> compat-wireless and/or vice versa. There were some transient bugs a
> while ago.
>
>>
>> thanks
>> sam
>>
>> On 9/14/09, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
>>> On Mon, Sep 14, 2009 at 6:56 PM, Vignette consultant
>>> <vignette75@gmail.com> wrote:
>>>> Larry,
>>>>
>>>> I got the same error even after adding wlan0 in
>>>> /etc/network/interfaces file. I set the essid using "sudo iwconfig
>>>> wlan0 essid linksys" command and restarted network. I tried other
>>>> essids, but it gives same error.
>>>>
>>>> Attached files contain log files. Please advise about solution.
>>>>
>>>> How do I disable usb monitoring log, so I can see wlan0 interface log
>>>> from dmesg?
>>>>
>>>> Thanks
>>>> Sam
>>>>
>>>> On 9/14/09, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>>>> Vignette consultant wrote:
>>>>>> Hi
>>>>>>
>>>>>> Attached files contain several logs of various commands. The log-1
>>>>>> file is before running command and log-2 file is after running
>>>>>> specific command.
>>>>>>
>>>>>> Here are commands that I give as soon as I log in. It's server
>>>>>> edition.
>>>>>>
>>>>>> $ sudo ifconfig wlan0 up
>>>>>> $ sudo iwconfig wlan0 ESSID linksys
>>>>>> $ sudo dhclient wlan0 - results in no IP addr leased
>>>>>
>>>>> Your wireless has not associated and has no communication, which is
>>>>> why it cannot get an IP using DHCP.
>>>>>
>>>>> A quick check with Google indicates that Ubuntu uses
>>>>> /etc/network/interfaces to control the devices. Once that is correct,
>>>>> you should be able to 'sudo /etc/init.d/networking restart' to start
>>>>> the network. If the server is properly configured, the network should
>>>>> start on boot.
>>>>>
>>>>> BTW, the dmesg buffer is circular. All that usb monitoring output has
>>>>> completely filled the buffer, and it contains no useful information.
>>>>>
>>>>
>>>
>>> scanning works, so there doesn't seem to be anything wrong with the
>>> device or the driver itself. However, even for static configuration,
>>> sometimes wpa_supplicant can still be involved and interfere, so you
>>> probably want to make sure you put all the relevant config in
>>> wpa_supplicant.conf , as well as manually; or make sure no other
>>> network tools are running. (udev can launch wpa_supplicant/dhcp on
>>> ifconfig up automatically - the 'not ready' messages are from udev
>>> hooks). Lastly, I think the Ubuntu/Debian family packages
>>> compat-wireless as 'kernel-modules-backport' or something; try that or
>>> even compat-wireless. ( a while back there was a bug with
>>> associattion).
>>>
>>
>
^ permalink raw reply
* email for compat-wireless patch contact...
From: Hin-Tak Leung @ 2009-09-15 2:32 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
Hi Luis,
The e-mail addressed listed for you (the winlab one) on
http://linuxwireless.org/en/users/Download and the README inside
compat-wireless bounced... time to update with either the gmail or the
atheros address?
Cheers,
Hin-Tak
^ permalink raw reply
* [PATCH] compat-2.6: adding driver-select script support for rtl818x
From: Hin-Tak Leung @ 2009-09-15 2:26 UTC (permalink / raw)
To: linux-wireless, mcgrof; +Cc: Hin-Tak Leung, Hin-Tak Leung
adding driver-select script support for rtl818x
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
---
scripts/driver-select | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/scripts/driver-select b/scripts/driver-select
index e0d7305..dcb777c 100755
--- a/scripts/driver-select
+++ b/scripts/driver-select
@@ -44,6 +44,7 @@ function usage {
echo -e "\t${CYAN}ath${NORMAL} < ${PURPLE} ath5k ath9k ar9170 ${NORMAL}>"
echo -e "\t${CYAN}intel${NORMAL} < ${PURPLE} iwl3945 iwlagn ipw2100 ipw2200 ${NORMAL}>"
echo -e "\t${CYAN}iwlwifi${NORMAL} < ${PURPLE} iwl3945 iwlagn ${NORMAL}>"
+ echo -e "\t${CYAN}rtl818x${NORMAL} < ${PURPLE} rtl8180 rtl8187 ${NORMAL}>"
echo -e "\t${CYAN}wl12xx${NORMAL} < ${PURPLE} wl1251 (SPI and SDIO) wl1271 ${NORMAL}>"
echo -e "Restoring compat-wireless:"
@@ -127,6 +128,13 @@ function disable_var_01 {
disable_var
}
+function disable_var_02 {
+ #var_01 with eeprom not disabled
+ disable_lib80211
+ disable_ssb
+ disable_usbnet
+}
+
function select_ath_driver
{
backup_file $ATH_MAKEFILE
@@ -227,6 +235,10 @@ case $1 in
select_driver CONFIG_ATH_COMMON
select_ath_driver CONFIG_AR9170_USB
;;
+ rtl818x)
+ select_drivers CONFIG_RTL8180 CONFIG_RTL8187
+ disable_var_02
+ ;;
zd1211rw)
select_driver CONFIG_ZD1211RW
disable_var_01
--
1.6.2.5
^ permalink raw reply related
* [PATCH] compat-2.6: adding notes on installing to non-running kernel
From: Hin-Tak Leung @ 2009-09-15 2:26 UTC (permalink / raw)
To: linux-wireless, mcgrof; +Cc: Hin-Tak Leung, Hin-Tak Leung
adding notes on installing to non-running kernel
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
---
README | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 7c6c2cd..380fc5a 100644
--- a/README
+++ b/README
@@ -142,6 +142,15 @@ compat-wireless-2.6 drivers for it you can use this syntax:
make KLIB=/home/mcgrof/kernels/linux-2.6.23.9 KLIB_BUILD=/home/mcgrof/kernels/linux-2.6.23.9
+If you have a kernel installed, which is not your currently running kernel (e.g. via
+distro updates; plus its corresponding kernel-dev package), you can use this syntax:
+
+make KLIB=/lib/modules/2.6.30.6-53.fc11.x86_64
+
+ and to install to your system's root path for the non-running kernel:
+
+make KLIB=/lib/modules/2.6.30.6-53.fc11.x86_64 KMODPATH_ARG='INSTALL_MOD_PATH=' install
+
Bugs
-----
--
1.6.2.5
^ permalink raw reply related
* [PATCH] compat-2.6: adding notes on installing to non-running kernel
From: Hin-Tak Leung @ 2009-09-15 2:20 UTC (permalink / raw)
To: linux-wireless, mcgrof; +Cc: Hin-Tak Leung, Hin-Tak Leung
adding notes on installing to non-running kernel
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
---
README | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 7c6c2cd..380fc5a 100644
--- a/README
+++ b/README
@@ -142,6 +142,15 @@ compat-wireless-2.6 drivers for it you can use this syntax:
make KLIB=/home/mcgrof/kernels/linux-2.6.23.9 KLIB_BUILD=/home/mcgrof/kernels/linux-2.6.23.9
+If you have a kernel installed, which is not your currently running kernel (e.g. via
+distro updates; plus its corresponding kernel-dev package), you can use this syntax:
+
+make KLIB=/lib/modules/2.6.30.6-53.fc11.x86_64
+
+ and to install to your system's root path for the non-running kernel:
+
+make KLIB=/lib/modules/2.6.30.6-53.fc11.x86_64 KMODPATH_ARG='INSTALL_MOD_PATH=' install
+
Bugs
-----
--
1.6.2.5
^ permalink raw reply related
* [PATCH] adding notes on installing to non-running kernel
From: Hin-Tak Leung @ 2009-09-15 2:17 UTC (permalink / raw)
To: linux-wireless, mcgrof; +Cc: Hin-Tak Leung, Hin-Tak Leung
adding notes on installing to non-running kernel
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
---
README | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 7c6c2cd..380fc5a 100644
--- a/README
+++ b/README
@@ -142,6 +142,15 @@ compat-wireless-2.6 drivers for it you can use this syntax:
make KLIB=/home/mcgrof/kernels/linux-2.6.23.9 KLIB_BUILD=/home/mcgrof/kernels/linux-2.6.23.9
+If you have a kernel installed, which is not your currently running kernel (e.g. via
+distro updates; plus its corresponding kernel-dev package), you can use this syntax:
+
+make KLIB=/lib/modules/2.6.30.6-53.fc11.x86_64
+
+ and to install to your system's root path for the non-running kernel:
+
+make KLIB=/lib/modules/2.6.30.6-53.fc11.x86_64 KMODPATH_ARG='INSTALL_MOD_PATH=' install
+
Bugs
-----
--
1.6.2.5
^ permalink raw reply related
* [PATCH] compat-2.6: adding driver-select script support for rtl818x
From: Hin-Tak Leung @ 2009-09-15 2:16 UTC (permalink / raw)
To: linux-wireless, mcgrof; +Cc: Hin-Tak Leung, Hin-Tak Leung
adding driver-select script support for rtl818x
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
---
scripts/driver-select | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/scripts/driver-select b/scripts/driver-select
index e0d7305..dcb777c 100755
--- a/scripts/driver-select
+++ b/scripts/driver-select
@@ -44,6 +44,7 @@ function usage {
echo -e "\t${CYAN}ath${NORMAL} < ${PURPLE} ath5k ath9k ar9170 ${NORMAL}>"
echo -e "\t${CYAN}intel${NORMAL} < ${PURPLE} iwl3945 iwlagn ipw2100 ipw2200 ${NORMAL}>"
echo -e "\t${CYAN}iwlwifi${NORMAL} < ${PURPLE} iwl3945 iwlagn ${NORMAL}>"
+ echo -e "\t${CYAN}rtl818x${NORMAL} < ${PURPLE} rtl8180 rtl8187 ${NORMAL}>"
echo -e "\t${CYAN}wl12xx${NORMAL} < ${PURPLE} wl1251 (SPI and SDIO) wl1271 ${NORMAL}>"
echo -e "Restoring compat-wireless:"
@@ -127,6 +128,13 @@ function disable_var_01 {
disable_var
}
+function disable_var_02 {
+ #var_01 with eeprom not disabled
+ disable_lib80211
+ disable_ssb
+ disable_usbnet
+}
+
function select_ath_driver
{
backup_file $ATH_MAKEFILE
@@ -227,6 +235,10 @@ case $1 in
select_driver CONFIG_ATH_COMMON
select_ath_driver CONFIG_AR9170_USB
;;
+ rtl818x)
+ select_drivers CONFIG_RTL8180 CONFIG_RTL8187
+ disable_var_02
+ ;;
zd1211rw)
select_driver CONFIG_ZD1211RW
disable_var_01
--
1.6.2.5
^ permalink raw reply related
* Re: RTL8187B wireless driver issue
From: Hin-Tak Leung @ 2009-09-15 1:24 UTC (permalink / raw)
To: Vignette consultant; +Cc: Larry Finger, linux-wireless
In-Reply-To: <3b0e19890909141434t758a9b3dk2799623dfb19c6a6@mail.gmail.com>
On Mon, Sep 14, 2009 at 10:34 PM, Vignette consultant
<vignette75@gmail.com> wrote:
> Hi
>
> I get timed out errors consistently as per attached log file.
> I tried several Live Cds from fedora, sidux - but i get the same dhcp
> error. I used to be able to connect before.
>
> Please check attached log and see if you can point me towards the solution.
Your log do not add anything new - I already asked you to do 3 things,
and there is no indication you have done any of them; there is no
point writing me the same things you had wrote to Larry or
linux-wireless, and try to get a private answer - Your won't. (please
do not remove the CC:'s and please do not write privately on general
help matters).
1) make sure that wpa_supplicant is *not* running - newer liveCDs can
have wpa_supplicant working (compare to older which does not use it).
2) make sure your authentication credentials - essid, passphases - are
in the network config files and agree with what you are trying to set
on the command line, just in case udev wants to unset your credentials
you are setting manually on the comamnd line.
3) switch from kernel-modules-backport to a different version of
compat-wireless and/or vice versa. There were some transient bugs a
while ago.
>
> thanks
> sam
>
> On 9/14/09, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
>> On Mon, Sep 14, 2009 at 6:56 PM, Vignette consultant
>> <vignette75@gmail.com> wrote:
>>> Larry,
>>>
>>> I got the same error even after adding wlan0 in
>>> /etc/network/interfaces file. I set the essid using "sudo iwconfig
>>> wlan0 essid linksys" command and restarted network. I tried other
>>> essids, but it gives same error.
>>>
>>> Attached files contain log files. Please advise about solution.
>>>
>>> How do I disable usb monitoring log, so I can see wlan0 interface log
>>> from dmesg?
>>>
>>> Thanks
>>> Sam
>>>
>>> On 9/14/09, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>>> Vignette consultant wrote:
>>>>> Hi
>>>>>
>>>>> Attached files contain several logs of various commands. The log-1
>>>>> file is before running command and log-2 file is after running
>>>>> specific command.
>>>>>
>>>>> Here are commands that I give as soon as I log in. It's server
>>>>> edition.
>>>>>
>>>>> $ sudo ifconfig wlan0 up
>>>>> $ sudo iwconfig wlan0 ESSID linksys
>>>>> $ sudo dhclient wlan0 - results in no IP addr leased
>>>>
>>>> Your wireless has not associated and has no communication, which is
>>>> why it cannot get an IP using DHCP.
>>>>
>>>> A quick check with Google indicates that Ubuntu uses
>>>> /etc/network/interfaces to control the devices. Once that is correct,
>>>> you should be able to 'sudo /etc/init.d/networking restart' to start
>>>> the network. If the server is properly configured, the network should
>>>> start on boot.
>>>>
>>>> BTW, the dmesg buffer is circular. All that usb monitoring output has
>>>> completely filled the buffer, and it contains no useful information.
>>>>
>>>
>>
>> scanning works, so there doesn't seem to be anything wrong with the
>> device or the driver itself. However, even for static configuration,
>> sometimes wpa_supplicant can still be involved and interfere, so you
>> probably want to make sure you put all the relevant config in
>> wpa_supplicant.conf , as well as manually; or make sure no other
>> network tools are running. (udev can launch wpa_supplicant/dhcp on
>> ifconfig up automatically - the 'not ready' messages are from udev
>> hooks). Lastly, I think the Ubuntu/Debian family packages
>> compat-wireless as 'kernel-modules-backport' or something; try that or
>> even compat-wireless. ( a while back there was a bug with
>> associattion).
>>
>
^ permalink raw reply
* Re: zd1211rw on ppc (iBook G4) -- Solved, somewhat)
From: Hin-Tak Leung @ 2009-09-15 1:08 UTC (permalink / raw)
To: Leonardo Hamada; +Cc: linux-wireless
In-Reply-To: <8ea57b3c57061154c0d312925100c827.squirrel@webmail.ufra.edu.br>
(I'd prefer *not* to have one-on-one exchanges, so where appropriate
please CC: the list)
On Tue, Sep 15, 2009 at 12:30 AM, Leonardo Hamada
<leonardo.hamada@ufra.edu.br> wrote:
>
> Em Seg, Setembro 14, 2009 18:11, Hin-Tak Leung escreveu:
>> On Mon, Sep 14, 2009 at 5:47 PM, Leonardo H. Souza Hamada
>> <leonardo.hamada@ufra.edu.br> wrote:
>>
>>> <<<Disabling original zd1211rw in kernel configuration, recompiled
>>> kernel as instructed above, installed new kernel, reboot, many times
>>> until I got it right>>>
>>
>> The patch isn't particularly version-specific - may have applied to
>> the kernel source itself...
>
>
> No, the patch was applied to compat package. The script install what is
> necessary.
I meant the patch should have applied to the vanilla kernel source as
well, if you have gone to the trouble of recompiling the kernel to get
mac80211 as module. (i.e. don't bother with compat-wireless).
>
>
>>
>>> Results:
>>>
>>> dmesg seems ok. no errors.
>>
>> No, I want to see dmesg - there should be something similiar to this?
>>
>> cfg80211: Calling CRDA for country: GB
>> cfg80211: Regulatory domain changed to country: GB
>> (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
>> (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>> (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>> (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>> (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
>
>
> I'm sure saw the first line as: cfg80211: Calling CRDA for country: JP
>
> There wasn't the rest (frequency stuff), I think. So this is suspicious.
That's strange. Do you have the crda package installed? You need the
regulatory database userland stuff for crda to work.
http://www.linuxwireless.org/en/developers/Regulatory/CRDA
>>> can do iwlist wlan0
>>>
>>> iwconfig wlan0 shows:
>>> IEEE 802.11bg Mode:Managed Access Point: Not-Associated
>>> Tx-Power=20 dBm
>>> Retry long limit:7 RTS thr:off Fragment thr:off
>>> Encryption key:off
>>> Power Management:off
>>>
>>>
>>> I do not seem to be able to connect to a given access point so far. LED
>>> does not blink.
>>
>> stay dark or stay lit?
>>
>
>
> Before ifconfig wlan0 up it stays lit. After it, always dark.
Hmm, I am not familiar with the LED code in zd1211rw - somebody else
please comment.
^ permalink raw reply
* Re: [PATCH v2] genetlink: fix netns vs. netlink table locking
From: David Miller @ 2009-09-15 0:07 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <1252760595.23427.20.camel@johannes.local>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Sat, 12 Sep 2009 07:03:15 -0600
> Since my commits introducing netns awareness into
> genetlink we can get this problem:
>
> BUG: scheduling while atomic: modprobe/1178/0x00000002
> 2 locks held by modprobe/1178:
> #0: (genl_mutex){+.+.+.}, at: [<ffffffff8135ee1a>] genl_register_mc_grou
> #1: (rcu_read_lock){.+.+..}, at: [<ffffffff8135eeb5>] genl_register_mc_g
> Pid: 1178, comm: modprobe Not tainted 2.6.31-rc8-wl-34789-g95cb731-dirty #
> Call Trace:
> [<ffffffff8103e285>] __schedule_bug+0x85/0x90
> [<ffffffff81403138>] schedule+0x108/0x588
> [<ffffffff8135b131>] netlink_table_grab+0xa1/0xf0
> [<ffffffff8135c3a7>] netlink_change_ngroups+0x47/0x100
> [<ffffffff8135ef0f>] genl_register_mc_group+0x12f/0x290
>
> because I overlooked that netlink_table_grab() will
> schedule, thinking it was just the rwlock. However,
> in the contention case, that isn't actually true.
>
> Fix this by letting the code grab the netlink table
> lock first and then the RCU for netns protection.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Applied, thanks.
^ permalink raw reply
* RE: [RFC] ar9170usb: add ar9170 usbid
From: Stephen Chen @ 2009-09-14 23:39 UTC (permalink / raw)
To: Christian Lamparter, Fabian Lenz
Cc: linux-wireless@vger.kernel.org, Luis Rodriguez
In-Reply-To: <200909142308.19569.chunkeey@googlemail.com>
Hi Christian,
I could not find this VID/PID in INF file in Windows release.
This ID combination could be obsolete.
Thank you!
Stephen
-----Original Message-----
From: Christian Lamparter [mailto:chunkeey@googlemail.com]
Sent: Tuesday, September 15, 2009 5:08 AM
To: Fabian Lenz
Cc: linux-wireless@vger.kernel.org; Luis Rodriguez; Stephen Chen
Subject: [RFC] ar9170usb: add ar9170 usbid
Reported-by: Fabian Lenz <lenz_fabian@yahoo.de>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
Stephen,
- since 0x0cf3 is Atheros' vendor id - can you please lookup the real product
code name for 0x0cf3:0x1002.
I will take care of the re-spin and update the wiki.
Thanks,
Chr
---
diff --git a/drivers/net/wireless/ath/ar9170/usb.c b/drivers/net/wireless/ath/ar9170/usb.c
index e0138ac..68b0bda 100644
--- a/drivers/net/wireless/ath/ar9170/usb.c
+++ b/drivers/net/wireless/ath/ar9170/usb.c
@@ -64,6 +64,8 @@ static struct usb_device_id ar9170_usb_ids[] = {
{ USB_DEVICE(0x0cf3, 0x9170) },
/* Atheros TG121N */
{ USB_DEVICE(0x0cf3, 0x1001) },
+ /* Atheros - Unknown Product Name - */
+ { USB_DEVICE(0x0cf3, 0x1002) },
/* Cace Airpcap NX */
{ USB_DEVICE(0xcace, 0x0300) },
/* D-Link DWA 160A */
^ permalink raw reply related
* [RFC PATCH] mac80211: Fix [re]association power saving issue on AP side
From: Igor Perminov @ 2009-09-14 23:02 UTC (permalink / raw)
To: Johannes Berg, Jouni Malinen; +Cc: linux-wireless
Consider the following step-by step:
1. A STA authenticates and associates with the AP and exchanges
traffic.
2. The STA reports to the AP that it is going to PS state.
3. Some time later the STA device goes to the stand-by mode (not only
its wi-fi card, but the device itself) and drops the association state
without sending a disassociation frame.
4. The STA device wakes up and begins authentication with an
Auth frame as it hasn't been authenticated/associated previously.
At the step 4 the AP "remembers" the STA and considers it is still in
the PS state, so the AP buffers frames, which it has to send to the STA.
But the STA isn't actually in the PS state and so it neither checks
TIM bits nor reports to the AP that it isn't power saving.
Because of that reauthentication/association fails.
To fix this issue:
1. Auth, Assoc Resp and Reassoc Resp frames are transmitted disregarding
of STA's power saving state.
2. When an application (hostapd) tries to add a STA to an AP (that
occurs when the STA has [re]associated successfully) and mac80211
already "knows" that STA, the AP resets the power saving state of the
STA and purges of frames that was previously buffered if any.
Signed-off-by: Igor Perminov <igor.perminov@inbox.ru>
---
net/mac80211/cfg.c | 15 +++++++++------
net/mac80211/sta_info.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
net/mac80211/sta_info.h | 1 +
net/mac80211/tx.c | 5 ++++-
4 files changed, 61 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 5608f6c..20d4c12 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -704,7 +704,7 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
struct sta_info *sta;
struct ieee80211_sub_if_data *sdata;
int err;
- int layer2_update;
+ int iftype_ap;
if (params->vlan) {
sdata = IEEE80211_DEV_TO_SUB_IF(params->vlan);
@@ -731,7 +731,7 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
rate_control_rate_init(sta);
- layer2_update = sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+ iftype_ap = sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
sdata->vif.type == NL80211_IFTYPE_AP;
rcu_read_lock();
@@ -739,17 +739,20 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
err = sta_info_insert(sta);
if (err) {
/* STA has been freed */
- if (err == -EEXIST && layer2_update) {
- /* Need to update layer 2 devices on reassociation */
+ if (err == -EEXIST && iftype_ap) {
+ /* Need to reset PS state
+ * and update layer 2 devices on reassociation */
sta = sta_info_get(local, mac);
- if (sta)
+ if (sta) {
+ sta_info_reset_ps(sta);
ieee80211_send_layer2_update(sta);
+ }
}
rcu_read_unlock();
return err;
}
- if (layer2_update)
+ if (iftype_ap)
ieee80211_send_layer2_update(sta);
rcu_read_unlock();
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index eec0014..09dc8de 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -459,6 +459,53 @@ void sta_info_clear_tim_bit(struct sta_info *sta)
spin_unlock_irqrestore(&sta->local->sta_lock, flags);
}
+void sta_info_reset_ps(struct sta_info *sta)
+{
+ struct ieee80211_sub_if_data *sdata = sta->sdata;
+ struct ieee80211_local *local = sdata->local;
+ struct ieee80211_if_ap *bss = sdata->bss;
+ unsigned long flags;
+ int filtered, buffered;
+
+ BUG_ON(!bss);
+
+ spin_lock_irqsave(&sta->local->sta_lock, flags);
+
+ if (!test_sta_flags(sta, WLAN_STA_PS)) {
+ spin_unlock_irqrestore(&sta->local->sta_lock, flags);
+ return;
+ }
+
+#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
+ printk(KERN_DEBUG "%s: STA %pM aid %d resets power save mode\n",
+ sdata->dev->name, sta->sta.addr, sta->sta.aid);
+#endif /* CONFIG_MAC80211_VERBOSE_PS_DEBUG */
+
+ atomic_dec(&bss->num_sta_ps);
+
+ clear_sta_flags(sta, WLAN_STA_PS);
+ drv_sta_notify(local, &sdata->vif, STA_NOTIFY_AWAKE, &sta->sta);
+
+ filtered = skb_queue_len(&sta->tx_filtered);
+ skb_queue_purge(&sta->tx_filtered);
+
+ buffered = skb_queue_len(&sta->ps_tx_buf);
+ skb_queue_purge(&sta->ps_tx_buf);
+
+ if (buffered) {
+ __sta_info_clear_tim_bit(bss, sta);
+ local->total_ps_buffered -= buffered;
+ }
+
+#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
+ printk(KERN_DEBUG "%s: STA %pM aid %d purged of "
+ "%d filtered/%d PS frames\n", sdata->dev->name,
+ sta->sta.addr, sta->sta.aid, filtered, buffered);
+#endif /* CONFIG_MAC80211_VERBOSE_PS_DEBUG */
+
+ spin_unlock_irqrestore(&sta->local->sta_lock, flags);
+}
+
static void __sta_info_unlink(struct sta_info **sta)
{
struct ieee80211_local *local = (*sta)->local;
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index ccc3adf..bd65d9c 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -445,6 +445,7 @@ void sta_info_unlink(struct sta_info **sta);
void sta_info_destroy(struct sta_info *sta);
void sta_info_set_tim_bit(struct sta_info *sta);
void sta_info_clear_tim_bit(struct sta_info *sta);
+void sta_info_reset_ps(struct sta_info *sta);
void sta_info_init(struct ieee80211_local *local);
int sta_info_start(struct ieee80211_local *local);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 10a1099..4d981e7 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -367,7 +367,10 @@ ieee80211_tx_h_unicast_ps_buf(struct ieee80211_tx_data *tx)
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx->skb->data;
u32 staflags;
- if (unlikely(!sta || ieee80211_is_probe_resp(hdr->frame_control)))
+ if (unlikely(!sta || ieee80211_is_probe_resp(hdr->frame_control)
+ || ieee80211_is_auth(hdr->frame_control)
+ || ieee80211_is_assoc_resp(hdr->frame_control)
+ || ieee80211_is_reassoc_resp(hdr->frame_control)))
return TX_CONTINUE;
staflags = get_sta_flags(sta);
^ permalink raw reply related
* Re: [PATCH] b43: Don't abuse wl->current_dev in the led work
From: Larry Finger @ 2009-09-14 22:58 UTC (permalink / raw)
To: Michael Buesch; +Cc: John W. Linville, Broadcom Wireless, linux-wireless
In-Reply-To: <200909142322.09152.mb@bu3sch.de>
Michael Buesch wrote:
> Don't abuse wl->current_dev in the LED work for checking whether we're
> going down. Add an explicit variable.
> This fixes a crash on rmmod dereferencing the wl->current_dev NULL pointer
> in various other places of the driver.
>
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
This patch does not apply. What other patches should I have beyond the
current state of wireless-testing?
Larry
^ 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