* Re: CARL9170 features
From: Christian Lamparter @ 2010-05-24 21:40 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linux-wireless
In-Reply-To: <4BFAECC0.2000007@dlasys.net>
On Monday 24 May 2010 23:16:48 David H. Lynch Jr. wrote:
> I am trying to kick carl9170 1.0.9 into either add-hoc or monitor
> mode or anything else where I can xmit to any wireless device. I do not
> care if the receiving device is interested - so long as the radio ACK's
> the packet, which it should do automatically.
iwconfig and all other wext-based wireless-tools are obsolete.
The new CLI "iw" can be found on:
http://wireless.kernel.org/en/users/Documentation/iw
> I tried iwconfig wl_ath mode ad-hoc
> And I get and errror:
>
> root# iwconfig wl_ath mode ad-hoc
> Error for wireless request "Set Mode" (8B06) :
> SET failed on device wl_ath ; Device or resource busy.
This is expected. The wl_ath interface must be *down* before
you can chance the operation mode of the master interface.
try: (of course, after calling: ifconfig wl_ath down)
iw dev wlanX ibss join <SSID> freq/channel <MHz/Chan No.>
> root# iwconfig wl_ath mode monitor
> Error for wireless request "Set Mode" (8B06) :
> SET failed on device wl_ath ; Device or resource busy.
iw dev wlanX set monitor [otherbss control ...]
> root# iwconfig wl_ath mode master
> Error for wireless request "Set Mode" (8B06) :
> SET failed on device wl_ath ; Invalid argument.
Master/Accesspoint mode is no longer fully implemented into the
kernel and therefore needs a userspace daemon: hostapd.
http://wireless.kernel.org/en/users/Documentation/hostapd
> I can add something to the driver if needed if you could recommend
> another wireless driver for a reference.
Well, we could add a beacon scheduler. This way we might be able
to support more than just one AP/IBSS interface. But this is
really complicated as the whole CAB implementation needs to be
extended to support multiple (concurrent) AP/IBSS links.
(And of course, there's the problem of the shared TSF in such a
configuration, so this might not be feasible after all...)
Regards,
Chr
^ permalink raw reply
* Re: [stable] [PATCH] Revert "ath9k: fix lockdep warning when unloading module" on stable kernels
From: Greg KH @ 2010-05-24 21:52 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: stable, Ming Lei, linux-wireless, linux-kernel, John W. Linville,
Johannes Berg
In-Reply-To: <1274304829-14367-1-git-send-email-lrodriguez@atheros.com>
On Wed, May 19, 2010 at 05:33:49PM -0400, Luis R. Rodriguez wrote:
> Johannes' patch 34e8950 titled:
>
> mac80211: allow station add/remove to sleep
>
> changed the way mac80211 adds and removes peers. The new
> sta_add() / sta_remove() callbacks allowed the driver callbacks
> to sleep. Johannes also ported ath9k to use sta_add() / sta_remove()
> via the patch 4ca7786 titled:
>
> ath9k: convert to new station add/remove callbacks
>
> but this patch forgot to address a change in locking issue which
> Ming Lei eventually found on his 2.6.33-wl #12 build. The 2.6.33-wl
> build includes code for the 802.11 subsystem for 2.6.34 though so did
> already have the above two patches (ath9k_sta_remove() on his trace),
> the 2.6.33 kernel did not however have these two patches. Ming eventually
> cured his lockdep warnign via the patch a9f042c titled:
>
> ath9k: fix lockdep warning when unloading module
>
> This went in to 2.6.34 and although it was not marked as a stable
> fix it did get trickled down and applied on both 2.6.33 and 2.6.32.
>
> In review, the culprits:
>
> mac80211: allow station add/remove to sleep
> git describe --contains 34e895075e21be3e21e71d6317440d1ee7969ad0
> v2.6.34-rc1~233^2~49^2~107
>
> ath9k: convert to new station add/remove callbacks
> git describe --contains 4ca778605cfec53d8a689f0b57babb93b030c784
> v2.6.34-rc1~233^2~49^2~10
>
> ath9k: fix lockdep warning when unloading module
>
> This last one trickled down to 2.6.33 (OK), 2.6.33 (invalid) and 2.6.32 (invalid).
>
> git describe --contains a9f042cbe5284f34ccff15f3084477e11b39b17b
> v2.6.34-rc2~48^2~77^2~7
> git describe --contains 0524bcfa80f1fffb4e1fe18a0a28900869a58a7c
> v2.6.33.2~125
> git describe --contains 0dcc9985f34aef3c60bffab3dfc7f7ba3748f35a
> v2.6.32.11~79
>
> The patch titled "ath9k: fix lockdep warning when unloading module"
> should be reverted on both 2.6.33 and 2.6.32 as it is invalid and
> actually ended up causing the following warning:
>
> ADDRCONF(NETDEV_CHANGE): wlan31: link becomes ready
> phy0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 txop=0
> phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0
> phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94
> phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47
> phy0: device now idle
> ------------[ cut here ]------------
> WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x7b/0xa0()
> Hardware name: 7660A14
> Modules linked in: ath9k(-) mac80211 ath cfg80211 <whatever-bleh-etc>
> Pid: 2003, comm: rmmod Not tainted 2.6.32.11 #6
> Call Trace:
> [<ffffffff8105d178>] warn_slowpath_common+0x78/0xb0
> [<ffffffff8105d1bf>] warn_slowpath_null+0xf/0x20
> [<ffffffff81063f8b>] local_bh_enable_ip+0x7b/0xa0
> [<ffffffff815121e4>] _spin_unlock_bh+0x14/0x20
> [<ffffffffa034aea5>] ath_tx_node_cleanup+0x185/0x1b0 [ath9k]
> [<ffffffffa0345597>] ath9k_sta_notify+0x57/0xb0 [ath9k]
> [<ffffffffa02ac51a>] __sta_info_unlink+0x15a/0x260 [mac80211]
> [<ffffffffa02ac658>] sta_info_unlink+0x38/0x60 [mac80211]
> [<ffffffffa02b3fbe>] ieee80211_set_disassoc+0x1ae/0x210 [mac80211]
> [<ffffffffa02b42d9>] ieee80211_mgd_deauth+0x109/0x110 [mac80211]
> [<ffffffffa02ba409>] ieee80211_deauth+0x19/0x20 [mac80211]
> [<ffffffffa028160e>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
> [<ffffffff81118540>] ? init_object+0x50/0x90
> [<ffffffffa0285429>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
> [<ffffffffa027125f>] cfg80211_netdev_notifier_call+0x10f/0x450 [cfg80211]
> [<ffffffff81514ca7>] notifier_call_chain+0x47/0x90
> [<ffffffff8107f501>] raw_notifier_call_chain+0x11/0x20
> [<ffffffff81442d66>] call_netdevice_notifiers+0x16/0x20
> [<ffffffff8144352d>] dev_close+0x4d/0xa0
> [<ffffffff814439a8>] rollback_registered+0x48/0x120
> [<ffffffff81443a9d>] unregister_netdevice+0x1d/0x70
> [<ffffffffa02b6cc4>] ieee80211_remove_interfaces+0x84/0xc0 [mac80211]
> [<ffffffffa02aa072>] ieee80211_unregister_hw+0x42/0xf0 [mac80211]
> [<ffffffffa0347bde>] ath_detach+0x8e/0x180 [ath9k]
> [<ffffffffa0347ce1>] ath_cleanup+0x11/0x50 [ath9k]
> [<ffffffffa0351a2c>] ath_pci_remove+0x1c/0x20 [ath9k]
> [<ffffffff8129d712>] pci_device_remove+0x32/0x60
> [<ffffffff81332373>] __device_release_driver+0x53/0xb0
> [<ffffffff81332498>] driver_detach+0xc8/0xd0
> [<ffffffff81331405>] bus_remove_driver+0x85/0xe0
> [<ffffffff81332a5a>] driver_unregister+0x5a/0x90
> [<ffffffff8129da00>] pci_unregister_driver+0x40/0xb0
> [<ffffffffa03518d0>] ath_pci_exit+0x10/0x20 [ath9k]
> [<ffffffffa0353cd5>] ath9k_exit+0x9/0x2a [ath9k]
> [<ffffffff81092838>] sys_delete_module+0x1a8/0x270
> [<ffffffff8107ebe9>] ? up_read+0x9/0x10
> [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
> ---[ end trace fad957019ffdd40b ]---
> phy0: Removed STA 00:22:6b:56:fd:e8
> phy0: Destroyed STA 00:22:6b:56:fd:e8
> wlan31: deauthenticating from 00:22:6b:56:fd:e8 by local choice (reason=3)
> ath9k 0000:16:00.0: PCI INT A disabled
>
> The original lockdep fixed an issue where due to the new changes
> the driver was not disabling the bottom halves but it is incorrect
> to do this on the older kernels since IRQs are already disabled.
>
> Cc: Ming Lei <tom.leiming@gmail.com>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Cc: John W. Linville <linville@tuxdriver.com>
For some reason, you never signed-off on this patch, why? Care to send
me a "Signed-off-by:" line so I can add it?
thanks,
greg k-h
^ permalink raw reply
* Re: iwl3945 bug in 2.6.34
From: reinette chatre @ 2010-05-24 22:08 UTC (permalink / raw)
To: Satish Eerpini; +Cc: linux-kernel, linux-wireless@vger.kernel.org
In-Reply-To: <1274726029.2091.15160.camel@rchatre-DESK>
On Mon, 2010-05-24 at 11:33 -0700, reinette chatre wrote:
> On Sat, 2010-05-22 at 23:25 -0700, Satish Eerpini wrote:
>
> > No probe response from AP 00:1b:da:2a:a1:53 after 500ms, disconnecting.
> > iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
> > iwl3945 0000:10:00.0: Error setting new configuration (-110).
> > iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
> > iwl3945 0000:10:00.0: Error setting new configuration (-110).
>
> This did not use to be an issue with 3945 and unfortunately we do not
> know what is triggering it now. Please try the "Enable stuck queue
> detection on 3945" patch that is attached to
> http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 as a
> workaround.
Actually, sorry, but that patch will not work on 2.6.34 since the
feature it enables is not present there - it will be in 2.6.35 though.
To enable the feature in 2.6.34 will take some more backporting effort
that I'm looking into now.
Reinette
^ permalink raw reply
* Re: [stable] [PATCH] Revert "ath9k: fix lockdep warning when unloading module" on stable kernels
From: Luis R. Rodriguez @ 2010-05-24 22:16 UTC (permalink / raw)
To: Greg KH
Cc: stable, Ming Lei, linux-wireless, linux-kernel, John W. Linville,
Johannes Berg
In-Reply-To: <20100524215216.GJ16655@kroah.com>
On Mon, May 24, 2010 at 2:52 PM, Greg KH <greg@kroah.com> wrote:
> On Wed, May 19, 2010 at 05:33:49PM -0400, Luis R. Rodriguez wrote:
>> Johannes' patch 34e8950 titled:
>>
>> mac80211: allow station add/remove to sleep
>>
>> changed the way mac80211 adds and removes peers. The new
>> sta_add() / sta_remove() callbacks allowed the driver callbacks
>> to sleep. Johannes also ported ath9k to use sta_add() / sta_remove()
>> via the patch 4ca7786 titled:
>>
>> ath9k: convert to new station add/remove callbacks
>>
>> but this patch forgot to address a change in locking issue which
>> Ming Lei eventually found on his 2.6.33-wl #12 build. The 2.6.33-wl
>> build includes code for the 802.11 subsystem for 2.6.34 though so did
>> already have the above two patches (ath9k_sta_remove() on his trace),
>> the 2.6.33 kernel did not however have these two patches. Ming eventually
>> cured his lockdep warnign via the patch a9f042c titled:
>>
>> ath9k: fix lockdep warning when unloading module
>>
>> This went in to 2.6.34 and although it was not marked as a stable
>> fix it did get trickled down and applied on both 2.6.33 and 2.6.32.
>>
>> In review, the culprits:
>>
>> mac80211: allow station add/remove to sleep
>> git describe --contains 34e895075e21be3e21e71d6317440d1ee7969ad0
>> v2.6.34-rc1~233^2~49^2~107
>>
>> ath9k: convert to new station add/remove callbacks
>> git describe --contains 4ca778605cfec53d8a689f0b57babb93b030c784
>> v2.6.34-rc1~233^2~49^2~10
>>
>> ath9k: fix lockdep warning when unloading module
>>
>> This last one trickled down to 2.6.33 (OK), 2.6.33 (invalid) and 2.6.32 (invalid).
>>
>> git describe --contains a9f042cbe5284f34ccff15f3084477e11b39b17b
>> v2.6.34-rc2~48^2~77^2~7
>> git describe --contains 0524bcfa80f1fffb4e1fe18a0a28900869a58a7c
>> v2.6.33.2~125
>> git describe --contains 0dcc9985f34aef3c60bffab3dfc7f7ba3748f35a
>> v2.6.32.11~79
>>
>> The patch titled "ath9k: fix lockdep warning when unloading module"
>> should be reverted on both 2.6.33 and 2.6.32 as it is invalid and
>> actually ended up causing the following warning:
>>
>> ADDRCONF(NETDEV_CHANGE): wlan31: link becomes ready
>> phy0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 txop=0
>> phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0
>> phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94
>> phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47
>> phy0: device now idle
>> ------------[ cut here ]------------
>> WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x7b/0xa0()
>> Hardware name: 7660A14
>> Modules linked in: ath9k(-) mac80211 ath cfg80211 <whatever-bleh-etc>
>> Pid: 2003, comm: rmmod Not tainted 2.6.32.11 #6
>> Call Trace:
>> [<ffffffff8105d178>] warn_slowpath_common+0x78/0xb0
>> [<ffffffff8105d1bf>] warn_slowpath_null+0xf/0x20
>> [<ffffffff81063f8b>] local_bh_enable_ip+0x7b/0xa0
>> [<ffffffff815121e4>] _spin_unlock_bh+0x14/0x20
>> [<ffffffffa034aea5>] ath_tx_node_cleanup+0x185/0x1b0 [ath9k]
>> [<ffffffffa0345597>] ath9k_sta_notify+0x57/0xb0 [ath9k]
>> [<ffffffffa02ac51a>] __sta_info_unlink+0x15a/0x260 [mac80211]
>> [<ffffffffa02ac658>] sta_info_unlink+0x38/0x60 [mac80211]
>> [<ffffffffa02b3fbe>] ieee80211_set_disassoc+0x1ae/0x210 [mac80211]
>> [<ffffffffa02b42d9>] ieee80211_mgd_deauth+0x109/0x110 [mac80211]
>> [<ffffffffa02ba409>] ieee80211_deauth+0x19/0x20 [mac80211]
>> [<ffffffffa028160e>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
>> [<ffffffff81118540>] ? init_object+0x50/0x90
>> [<ffffffffa0285429>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
>> [<ffffffffa027125f>] cfg80211_netdev_notifier_call+0x10f/0x450 [cfg80211]
>> [<ffffffff81514ca7>] notifier_call_chain+0x47/0x90
>> [<ffffffff8107f501>] raw_notifier_call_chain+0x11/0x20
>> [<ffffffff81442d66>] call_netdevice_notifiers+0x16/0x20
>> [<ffffffff8144352d>] dev_close+0x4d/0xa0
>> [<ffffffff814439a8>] rollback_registered+0x48/0x120
>> [<ffffffff81443a9d>] unregister_netdevice+0x1d/0x70
>> [<ffffffffa02b6cc4>] ieee80211_remove_interfaces+0x84/0xc0 [mac80211]
>> [<ffffffffa02aa072>] ieee80211_unregister_hw+0x42/0xf0 [mac80211]
>> [<ffffffffa0347bde>] ath_detach+0x8e/0x180 [ath9k]
>> [<ffffffffa0347ce1>] ath_cleanup+0x11/0x50 [ath9k]
>> [<ffffffffa0351a2c>] ath_pci_remove+0x1c/0x20 [ath9k]
>> [<ffffffff8129d712>] pci_device_remove+0x32/0x60
>> [<ffffffff81332373>] __device_release_driver+0x53/0xb0
>> [<ffffffff81332498>] driver_detach+0xc8/0xd0
>> [<ffffffff81331405>] bus_remove_driver+0x85/0xe0
>> [<ffffffff81332a5a>] driver_unregister+0x5a/0x90
>> [<ffffffff8129da00>] pci_unregister_driver+0x40/0xb0
>> [<ffffffffa03518d0>] ath_pci_exit+0x10/0x20 [ath9k]
>> [<ffffffffa0353cd5>] ath9k_exit+0x9/0x2a [ath9k]
>> [<ffffffff81092838>] sys_delete_module+0x1a8/0x270
>> [<ffffffff8107ebe9>] ? up_read+0x9/0x10
>> [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
>> ---[ end trace fad957019ffdd40b ]---
>> phy0: Removed STA 00:22:6b:56:fd:e8
>> phy0: Destroyed STA 00:22:6b:56:fd:e8
>> wlan31: deauthenticating from 00:22:6b:56:fd:e8 by local choice (reason=3)
>> ath9k 0000:16:00.0: PCI INT A disabled
>>
>> The original lockdep fixed an issue where due to the new changes
>> the driver was not disabling the bottom halves but it is incorrect
>> to do this on the older kernels since IRQs are already disabled.
>>
>> Cc: Ming Lei <tom.leiming@gmail.com>
>> Cc: Johannes Berg <johannes@sipsolutions.net>
>> Cc: John W. Linville <linville@tuxdriver.com>
>
> For some reason, you never signed-off on this patch, why? Care to send
> me a "Signed-off-by:" line so I can add it?
WTF, sorry, you're right, can you just peg it for me?
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Luis
^ permalink raw reply
* Re: How the mac80211 handle "\0" essid?
From: Dan Williams @ 2010-05-24 22:24 UTC (permalink / raw)
To: leo liang; +Cc: linux-wireless
In-Reply-To: <AANLkTilXnak_JDwWcx7ZqwNGEax89_Qj1YcFIH5VtecY@mail.gmail.com>
On Fri, 2010-05-21 at 14:05 -0400, leo liang wrote:
> On Thu, May 20, 2010 at 4:30 PM, Dan Williams <dcbw@redhat.com> wrote:
> > On Thu, 2010-05-20 at 15:40 -0400, leo liang wrote:
> >> Hi,
> >>
> >> Does any one know that if the application send "\0" as essid to
> >> mac80211, how it handle this case?
> >
> > What are you trying to do? Are you trying to work with a hidden AP, or
> > do something else?
>
> I want to hide the associated AP name. Or disassociate and do not let
> the interface connect to any AP.
"I want to hide the associated AP name"
What do you mean by this? Do you mean make 'iwconfig' or some other
program not report the currently associated AP name? Or do you mean
something else?
"Or disassociate and do not let..."
For complete disassociation, you don't need to send an empty BSSID when
using nl80211, just send the disassociate command using nl80211 (in
code) or the 'iw' command. When using WEXT (which is the older
predecessor of nl80211) you need to send a random SSID (ie, 32 random
ascii characters for example) not including \0. That should cause
devices to disassociate from the AP and not attempt to reconnect to it
until you send a new, valid SSID.
> >
> > An SSID is simply a 32-byte array; the protocol and the stack don't care
> > what's in that array. So while you can't use command-line tools like
> > 'iwconfig' to send an SSID containing a \0, you can use netlink or
> > wpa_supplicant's nl80211 driver to do so.
>
> I checked "iwconfig" source code, if you run "iwconfig wlan0 essid
> off", it will set the first char as "\0".
Right, iwconfig is pretty old and does not correctly handle empty
BSSIDs. Don't depend on the iwconfig behavior.
Dan
> >
> > But in the end, if you're trying to associate with an AP that has an
> > SSID of only '\0', that AP is likely broken or trying to hide it's SSID,
> > and you should be using the real SSID of that AP instead of '\0'.
> >
> > Dan
> >
> >
> >
> --
> 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
^ permalink raw reply
* Re: Iwlwifi and LEDS?
From: reinette chatre @ 2010-05-24 22:30 UTC (permalink / raw)
To: Gregy; +Cc: Kolekar, Abhijeet, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTilnK6lkypJkajiwUbhl6JlNR7S8dL6YzKUe2yd3@mail.gmail.com>
On Fri, 2010-05-21 at 13:49 -0700, Gregy wrote:
> On 21 May 2010 20:07, Abhijeet Kolekar <abhijeet.kolekar@intel.com> wrote:
> > On Fri, 2010-05-21 at 02:11 -0700, Gregy wrote:
> >> Hello, I noticed you removed support for led subsystem from iwlwifi. I
> >> have used it to control wifi led from userspace. Is it still possible
> >> somehow?
> >>
> > There is module parameter for iwlcore called 'led_mode'.
>
> Yes but I cannot control the led through it. I can only set one of two
> modes. Before I could use it as "connected to internet" indicator or
> I could turn it off completely.
No - we did not remove support for LEDs from iwlwifi. The led_mode
module parameter is just to change the blinking behavior (0=blinking,
1=On(RF On)/Off(RF Off)).
What did you do before that does not work anymore?
Reinette
^ permalink raw reply
* Re: [stable] [PATCH] Revert "ath9k: fix lockdep warning when unloading module" on stable kernels
From: Greg KH @ 2010-05-24 22:38 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Ming Lei, linux-wireless, John W. Linville, linux-kernel,
Johannes Berg, stable
In-Reply-To: <AANLkTinhpYvUrxIw9-eZG3ihyshCZiSZP9wQ7ThLs_kx@mail.gmail.com>
On Mon, May 24, 2010 at 03:16:37PM -0700, Luis R. Rodriguez wrote:
> >
> > For some reason, you never signed-off on this patch, why? Care to send
> > me a "Signed-off-by:" line so I can add it?
>
> WTF, sorry, you're right, can you just peg it for me?
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Yes, I'll go add it to the patch, thanks.
greg k-h
^ permalink raw reply
* [32/34] Revert "ath9k: fix lockdep warning when unloading module" on stable kernels
From: Greg KH @ 2010-05-24 23:00 UTC (permalink / raw)
To: linux-kernel, stable, greg
Cc: stable-review, torvalds, akpm, alan, Luis R. Rodriguez, Ming Lei,
linux-wireless, John W. Linville, Johannes Berg
In-Reply-To: <20100524230418.GA12770@kroah.com>
2.6.34-stable review patch. If anyone has any objections, please let us know.
------------------
Johannes' patch 34e8950 titled:
mac80211: allow station add/remove to sleep
changed the way mac80211 adds and removes peers. The new
sta_add() / sta_remove() callbacks allowed the driver callbacks
to sleep. Johannes also ported ath9k to use sta_add() / sta_remove()
via the patch 4ca7786 titled:
ath9k: convert to new station add/remove callbacks
but this patch forgot to address a change in locking issue which
Ming Lei eventually found on his 2.6.33-wl #12 build. The 2.6.33-wl
build includes code for the 802.11 subsystem for 2.6.34 though so did
already have the above two patches (ath9k_sta_remove() on his trace),
the 2.6.33 kernel did not however have these two patches. Ming eventually
cured his lockdep warnign via the patch a9f042c titled:
ath9k: fix lockdep warning when unloading module
This went in to 2.6.34 and although it was not marked as a stable
fix it did get trickled down and applied on both 2.6.33 and 2.6.32.
In review, the culprits:
mac80211: allow station add/remove to sleep
git describe --contains 34e895075e21be3e21e71d6317440d1ee7969ad0
v2.6.34-rc1~233^2~49^2~107
ath9k: convert to new station add/remove callbacks
git describe --contains 4ca778605cfec53d8a689f0b57babb93b030c784
v2.6.34-rc1~233^2~49^2~10
ath9k: fix lockdep warning when unloading module
This last one trickled down to 2.6.33 (OK), 2.6.33 (invalid) and 2.6.32 (invalid).
git describe --contains a9f042cbe5284f34ccff15f3084477e11b39b17b
v2.6.34-rc2~48^2~77^2~7
git describe --contains 0524bcfa80f1fffb4e1fe18a0a28900869a58a7c
v2.6.33.2~125
git describe --contains 0dcc9985f34aef3c60bffab3dfc7f7ba3748f35a
v2.6.32.11~79
The patch titled "ath9k: fix lockdep warning when unloading module"
should be reverted on both 2.6.33 and 2.6.32 as it is invalid and
actually ended up causing the following warning:
ADDRCONF(NETDEV_CHANGE): wlan31: link becomes ready
phy0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 txop=0
phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0
phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94
phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47
phy0: device now idle
------------[ cut here ]------------
WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x7b/0xa0()
Hardware name: 7660A14
Modules linked in: ath9k(-) mac80211 ath cfg80211 <whatever-bleh-etc>
Pid: 2003, comm: rmmod Not tainted 2.6.32.11 #6
Call Trace:
[<ffffffff8105d178>] warn_slowpath_common+0x78/0xb0
[<ffffffff8105d1bf>] warn_slowpath_null+0xf/0x20
[<ffffffff81063f8b>] local_bh_enable_ip+0x7b/0xa0
[<ffffffff815121e4>] _spin_unlock_bh+0x14/0x20
[<ffffffffa034aea5>] ath_tx_node_cleanup+0x185/0x1b0 [ath9k]
[<ffffffffa0345597>] ath9k_sta_notify+0x57/0xb0 [ath9k]
[<ffffffffa02ac51a>] __sta_info_unlink+0x15a/0x260 [mac80211]
[<ffffffffa02ac658>] sta_info_unlink+0x38/0x60 [mac80211]
[<ffffffffa02b3fbe>] ieee80211_set_disassoc+0x1ae/0x210 [mac80211]
[<ffffffffa02b42d9>] ieee80211_mgd_deauth+0x109/0x110 [mac80211]
[<ffffffffa02ba409>] ieee80211_deauth+0x19/0x20 [mac80211]
[<ffffffffa028160e>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
[<ffffffff81118540>] ? init_object+0x50/0x90
[<ffffffffa0285429>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
[<ffffffffa027125f>] cfg80211_netdev_notifier_call+0x10f/0x450 [cfg80211]
[<ffffffff81514ca7>] notifier_call_chain+0x47/0x90
[<ffffffff8107f501>] raw_notifier_call_chain+0x11/0x20
[<ffffffff81442d66>] call_netdevice_notifiers+0x16/0x20
[<ffffffff8144352d>] dev_close+0x4d/0xa0
[<ffffffff814439a8>] rollback_registered+0x48/0x120
[<ffffffff81443a9d>] unregister_netdevice+0x1d/0x70
[<ffffffffa02b6cc4>] ieee80211_remove_interfaces+0x84/0xc0 [mac80211]
[<ffffffffa02aa072>] ieee80211_unregister_hw+0x42/0xf0 [mac80211]
[<ffffffffa0347bde>] ath_detach+0x8e/0x180 [ath9k]
[<ffffffffa0347ce1>] ath_cleanup+0x11/0x50 [ath9k]
[<ffffffffa0351a2c>] ath_pci_remove+0x1c/0x20 [ath9k]
[<ffffffff8129d712>] pci_device_remove+0x32/0x60
[<ffffffff81332373>] __device_release_driver+0x53/0xb0
[<ffffffff81332498>] driver_detach+0xc8/0xd0
[<ffffffff81331405>] bus_remove_driver+0x85/0xe0
[<ffffffff81332a5a>] driver_unregister+0x5a/0x90
[<ffffffff8129da00>] pci_unregister_driver+0x40/0xb0
[<ffffffffa03518d0>] ath_pci_exit+0x10/0x20 [ath9k]
[<ffffffffa0353cd5>] ath9k_exit+0x9/0x2a [ath9k]
[<ffffffff81092838>] sys_delete_module+0x1a8/0x270
[<ffffffff8107ebe9>] ? up_read+0x9/0x10
[<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
---[ end trace fad957019ffdd40b ]---
phy0: Removed STA 00:22:6b:56:fd:e8
phy0: Destroyed STA 00:22:6b:56:fd:e8
wlan31: deauthenticating from 00:22:6b:56:fd:e8 by local choice (reason=3)
ath9k 0000:16:00.0: PCI INT A disabled
The original lockdep fixed an issue where due to the new changes
the driver was not disabling the bottom halves but it is incorrect
to do this on the older kernels since IRQs are already disabled.
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/wireless/ath/ath9k/xmit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2190,7 +2190,7 @@ void ath_tx_node_cleanup(struct ath_soft
if (ATH_TXQ_SETUP(sc, i)) {
txq = &sc->tx.txq[i];
- spin_lock_bh(&txq->axq_lock);
+ spin_lock(&txq->axq_lock);
list_for_each_entry_safe(ac,
ac_tmp, &txq->axq_acq, list) {
@@ -2211,7 +2211,7 @@ void ath_tx_node_cleanup(struct ath_soft
}
}
- spin_unlock_bh(&txq->axq_lock);
+ spin_unlock(&txq->axq_lock);
}
}
}
^ permalink raw reply
* [38/39] Revert "ath9k: fix lockdep warning when unloading module" on stable kernels
From: Greg KH @ 2010-05-24 23:15 UTC (permalink / raw)
To: linux-kernel, stable, greg
Cc: stable-review, torvalds, akpm, alan, Luis R. Rodriguez, Ming Lei,
linux-wireless, John W. Linville, Johannes Berg
In-Reply-To: <20100524231840.GA17857@kroah.com>
2.6.33-stable review patch. If anyone has any objections, please let us know.
------------------
Johannes' patch 34e8950 titled:
mac80211: allow station add/remove to sleep
changed the way mac80211 adds and removes peers. The new
sta_add() / sta_remove() callbacks allowed the driver callbacks
to sleep. Johannes also ported ath9k to use sta_add() / sta_remove()
via the patch 4ca7786 titled:
ath9k: convert to new station add/remove callbacks
but this patch forgot to address a change in locking issue which
Ming Lei eventually found on his 2.6.33-wl #12 build. The 2.6.33-wl
build includes code for the 802.11 subsystem for 2.6.34 though so did
already have the above two patches (ath9k_sta_remove() on his trace),
the 2.6.33 kernel did not however have these two patches. Ming eventually
cured his lockdep warnign via the patch a9f042c titled:
ath9k: fix lockdep warning when unloading module
This went in to 2.6.34 and although it was not marked as a stable
fix it did get trickled down and applied on both 2.6.33 and 2.6.32.
In review, the culprits:
mac80211: allow station add/remove to sleep
git describe --contains 34e895075e21be3e21e71d6317440d1ee7969ad0
v2.6.34-rc1~233^2~49^2~107
ath9k: convert to new station add/remove callbacks
git describe --contains 4ca778605cfec53d8a689f0b57babb93b030c784
v2.6.34-rc1~233^2~49^2~10
ath9k: fix lockdep warning when unloading module
This last one trickled down to 2.6.33 (OK), 2.6.33 (invalid) and 2.6.32 (invalid).
git describe --contains a9f042cbe5284f34ccff15f3084477e11b39b17b
v2.6.34-rc2~48^2~77^2~7
git describe --contains 0524bcfa80f1fffb4e1fe18a0a28900869a58a7c
v2.6.33.2~125
git describe --contains 0dcc9985f34aef3c60bffab3dfc7f7ba3748f35a
v2.6.32.11~79
The patch titled "ath9k: fix lockdep warning when unloading module"
should be reverted on both 2.6.33 and 2.6.32 as it is invalid and
actually ended up causing the following warning:
ADDRCONF(NETDEV_CHANGE): wlan31: link becomes ready
phy0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 txop=0
phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0
phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94
phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47
phy0: device now idle
------------[ cut here ]------------
WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x7b/0xa0()
Hardware name: 7660A14
Modules linked in: ath9k(-) mac80211 ath cfg80211 <whatever-bleh-etc>
Pid: 2003, comm: rmmod Not tainted 2.6.32.11 #6
Call Trace:
[<ffffffff8105d178>] warn_slowpath_common+0x78/0xb0
[<ffffffff8105d1bf>] warn_slowpath_null+0xf/0x20
[<ffffffff81063f8b>] local_bh_enable_ip+0x7b/0xa0
[<ffffffff815121e4>] _spin_unlock_bh+0x14/0x20
[<ffffffffa034aea5>] ath_tx_node_cleanup+0x185/0x1b0 [ath9k]
[<ffffffffa0345597>] ath9k_sta_notify+0x57/0xb0 [ath9k]
[<ffffffffa02ac51a>] __sta_info_unlink+0x15a/0x260 [mac80211]
[<ffffffffa02ac658>] sta_info_unlink+0x38/0x60 [mac80211]
[<ffffffffa02b3fbe>] ieee80211_set_disassoc+0x1ae/0x210 [mac80211]
[<ffffffffa02b42d9>] ieee80211_mgd_deauth+0x109/0x110 [mac80211]
[<ffffffffa02ba409>] ieee80211_deauth+0x19/0x20 [mac80211]
[<ffffffffa028160e>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
[<ffffffff81118540>] ? init_object+0x50/0x90
[<ffffffffa0285429>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
[<ffffffffa027125f>] cfg80211_netdev_notifier_call+0x10f/0x450 [cfg80211]
[<ffffffff81514ca7>] notifier_call_chain+0x47/0x90
[<ffffffff8107f501>] raw_notifier_call_chain+0x11/0x20
[<ffffffff81442d66>] call_netdevice_notifiers+0x16/0x20
[<ffffffff8144352d>] dev_close+0x4d/0xa0
[<ffffffff814439a8>] rollback_registered+0x48/0x120
[<ffffffff81443a9d>] unregister_netdevice+0x1d/0x70
[<ffffffffa02b6cc4>] ieee80211_remove_interfaces+0x84/0xc0 [mac80211]
[<ffffffffa02aa072>] ieee80211_unregister_hw+0x42/0xf0 [mac80211]
[<ffffffffa0347bde>] ath_detach+0x8e/0x180 [ath9k]
[<ffffffffa0347ce1>] ath_cleanup+0x11/0x50 [ath9k]
[<ffffffffa0351a2c>] ath_pci_remove+0x1c/0x20 [ath9k]
[<ffffffff8129d712>] pci_device_remove+0x32/0x60
[<ffffffff81332373>] __device_release_driver+0x53/0xb0
[<ffffffff81332498>] driver_detach+0xc8/0xd0
[<ffffffff81331405>] bus_remove_driver+0x85/0xe0
[<ffffffff81332a5a>] driver_unregister+0x5a/0x90
[<ffffffff8129da00>] pci_unregister_driver+0x40/0xb0
[<ffffffffa03518d0>] ath_pci_exit+0x10/0x20 [ath9k]
[<ffffffffa0353cd5>] ath9k_exit+0x9/0x2a [ath9k]
[<ffffffff81092838>] sys_delete_module+0x1a8/0x270
[<ffffffff8107ebe9>] ? up_read+0x9/0x10
[<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
---[ end trace fad957019ffdd40b ]---
phy0: Removed STA 00:22:6b:56:fd:e8
phy0: Destroyed STA 00:22:6b:56:fd:e8
wlan31: deauthenticating from 00:22:6b:56:fd:e8 by local choice (reason=3)
ath9k 0000:16:00.0: PCI INT A disabled
The original lockdep fixed an issue where due to the new changes
the driver was not disabling the bottom halves but it is incorrect
to do this on the older kernels since IRQs are already disabled.
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/wireless/ath/ath9k/xmit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2244,7 +2244,7 @@ void ath_tx_node_cleanup(struct ath_soft
if (ATH_TXQ_SETUP(sc, i)) {
txq = &sc->tx.txq[i];
- spin_lock_bh(&txq->axq_lock);
+ spin_lock(&txq->axq_lock);
list_for_each_entry_safe(ac,
ac_tmp, &txq->axq_acq, list) {
@@ -2265,7 +2265,7 @@ void ath_tx_node_cleanup(struct ath_soft
}
}
- spin_unlock_bh(&txq->axq_lock);
+ spin_unlock(&txq->axq_lock);
}
}
}
^ permalink raw reply
* Re: Realtek rtl8188 support?
From: Paul Thomas @ 2010-05-25 0:16 UTC (permalink / raw)
To: Pavel Roskin
Cc: Gábor Stefanik, linux-wireless, Andrea Merello, Jerry chuang
In-Reply-To: <c785bba31003291519tfd7d26fy466a4ee4310ac590@mail.gmail.com>
On Mon, Mar 29, 2010 at 3:19 PM, Paul Thomas <pthomas8589@gmail.com> wrote:
> OK, I'd love to get to where Pavel & Gabor are, but I think I'm having
> trouble with the PCI dependency. I'm on an arm platform without PCI
> (atmel at91sam9g20). If I remove the PCI dependency from the Kconfig
> it does compile with warnings, and then when the module loads I get
> "r8192s_usb: Unknown symbol wireless_send_event".
>
> I'm happy to hang out and try again when the driver leaves staging,
> but I thought I might mention the PCI dependency now.
>
> thanks,
> Paul
I haven't seen any activity on this driver in awhile. Is anyone
working on it? My main request is to remove the PCI dependency. Any
chance of this?
Or does anyone else know of a "mini" wireless adapters with a
supported chipset (i.e. without needing PCI)? Both devices I've
ordered from newegg ended up having the rtl8188 chip.
thanks,
Paul
^ permalink raw reply
* ioctl for b43 driver
From: Huy Le @ 2010-05-25 1:02 UTC (permalink / raw)
To: linux-wireless
Hi,
Currently I try aircrack-ng with b43 driver but it is fail at this
statement due to the following statement:
ioctl( fd, SIOCGIWFREQ, &wrq ) < 0
This happens because we do not have ioctl for b43 driver. I just want to
ask if there is any way to work around.
Thanks.
^ permalink raw reply
* Re: ioctl for b43 driver
From: Gábor Stefanik @ 2010-05-25 1:08 UTC (permalink / raw)
To: Huy Le; +Cc: linux-wireless
In-Reply-To: <4BFB21C1.3060703@gmail.com>
On Tue, May 25, 2010 at 3:02 AM, Huy Le <lehuy0406@gmail.com> wrote:
> Hi,
>
> Currently I try aircrack-ng with b43 driver but it is fail at this statement
> due to the following statement:
>
> ioctl( fd, SIOCGIWFREQ, &wrq ) < 0
>
> This happens because we do not have ioctl for b43 driver. I just want to ask
> if there is any way to work around.
Confirmed with ath9k. Apparently rdev->channel is NULL for monitor interfaces.
>
> Thanks.
> --
> 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
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: ioctl for b43 driver
From: Gábor Stefanik @ 2010-05-25 1:26 UTC (permalink / raw)
To: Huy Le; +Cc: linux-wireless
In-Reply-To: <AANLkTil4AnMqzSN4d_VTRJGFqWQl7CkZtr80GcffqM3h@mail.gmail.com>
2010/5/25 Gábor Stefanik <netrolller.3d@gmail.com>:
> On Tue, May 25, 2010 at 3:02 AM, Huy Le <lehuy0406@gmail.com> wrote:
>> Hi,
>>
>> Currently I try aircrack-ng with b43 driver but it is fail at this statement
>> due to the following statement:
>>
>> ioctl( fd, SIOCGIWFREQ, &wrq ) < 0
>>
>> This happens because we do not have ioctl for b43 driver. I just want to ask
>> if there is any way to work around.
>
> Confirmed with ath9k. Apparently rdev->channel is NULL for monitor interfaces.
I meant wdev->channel - it got changed recently.
>
>>
>> Thanks.
>> --
>> 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
>>
>
>
>
> --
> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* iwl3945 bug in 2.6.34
From: Satish Eerpini @ 2010-05-25 2:21 UTC (permalink / raw)
To: linux-kernel, linux-wireless
In-Reply-To: <AANLkTinFt5yiINXrc9-fnUl7NiyzN42eUotFnZdcxbas@mail.gmail.com>
> Actually, sorry, but that patch will not work on 2.6.34 since the
> feature it enables is not present there - it will be in 2.6.35 though.
> To enable the feature in 2.6.34 will take some more backporting effort
> that I'm looking into now.
>
the patch does lead to a reject, I am not very experienced with
code-fu in the kernel, and have no clue about the iwl code base, but
comparing the code from 2.6.24 and the latest compat-wireless tarball,
I found that in iwl-core.c
iwl_check_stuck_queue
iwl_bg_monitor_recover
are not present in the 2.6.34 version of the file, is there a
particular reason for doing this ?
is there a patch series/discussion I can follow to know the details on this ?
and I am trying to compile 2.6.34 by adding just these two functions
to iwl-core.c. If that works I will report back (though you might
already know if it will work or not)
Cheers
Satish
--
http://tuxitter.blogspot.com
--
http://tuxitter.blogspot.com
^ permalink raw reply
* Re: ath5k past 2.6.30 breaks monitor mode (and thus the aircrack suite)
From: Gábor Stefanik @ 2010-05-25 2:23 UTC (permalink / raw)
To: Weedy, linux-wireless
In-Reply-To: <AANLkTimYeL4KQozuTl4le9WUpObsjwp0YAx7eAYq6MBr@mail.gmail.com>
2010/5/25 Weedy <weedy2887@gmail.com>:
> 2010/5/23 Gábor Stefanik <netrolller.3d@gmail.com>:
>> In the meantime, one thing to test: Add a printk of sc->opmode.
>
> May 24 22:04:20 tiny-h4x kernel: [41147.243149] sc->opmode: 02 (over9000 times)
>
> So i'm guessing I did it wrong (I don't know C).
> printk(KERN_NOTICE "sc->opmode: %02x\n", sc->opmode);
>
No, that is correct, and proves my theory (2 is NL80211_IFTYPE_STATION
- it should be 6 for monitor mode).
BTW, please use "Reply to all".
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* ioctl with b43 driver
From: Huy Le @ 2010-05-25 2:37 UTC (permalink / raw)
To: linux-wireless
I am trying aircrack-ng and I found in the source of aircrack-ng that they called ioctl( fd, SIOCGIWFREQ,&wrq ). But the driver of b43 doesn't supportioctl, so this call is failed. Is there any solution for me?
My wireless card is BCM4312 [14e4:4315]
Thanks.
^ permalink raw reply
* Re: ioctl for b43 driver
From: Gábor Stefanik @ 2010-05-25 2:42 UTC (permalink / raw)
To: Huy Le; +Cc: linux-wireless
In-Reply-To: <4BFB36B9.8010706@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]
2010/5/25 Huy Le <lehuy0406@gmail.com>:
> On 05/24/2010 06:26 PM, Gábor Stefanik wrote:
>
> 2010/5/25 Gábor Stefanik <netrolller.3d@gmail.com>:
>
>
> On Tue, May 25, 2010 at 3:02 AM, Huy Le <lehuy0406@gmail.com> wrote:
>
>
> Hi,
>
> Currently I try aircrack-ng with b43 driver but it is fail at this statement
> due to the following statement:
>
> ioctl( fd, SIOCGIWFREQ, &wrq ) < 0
>
> This happens because we do not have ioctl for b43 driver. I just want to ask
> if there is any way to work around.
>
>
> Confirmed with ath9k. Apparently rdev->channel is NULL for monitor
> interfaces.
>
>
> I meant wdev->channel - it got changed recently.
>
>
>
>
>
> Thanks.
> --
> 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
>
>
>
> --
> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>
>
>
>
>
> Thanks for your respond. However, I can't get what you meant. I am trying
> aircrack-ng and I found in the source of aircrack-ng that they call ioctl(
> fd, SIOCGIWFREQ, &wrq ). But the driver of b43 doesn't support ioctl, so
> this call is failed. Is there any solution for me? My wireless card is
> BCM4312 [14e4:4315]
>
> Thanks.
>
Well, b43 supports ioctls using cfg80211, at least if cfg80211 wext
compat support is enabled in the kernel configuration. The problem is
something else - since the change from rdev->channel to wdev->channel,
monitor interfaces do not have a valid channel pointer in either rdev
or wdev. The same problem exists on ath9k and ath5k, and probably
anything that uses mac80211.
Attached is a C source for a test app that shows whether SIOCGIWFREQ
completes successfully. Compile it using "gcc iwfreqtest.c -o
iwfreqtest", the run as "iwfreqtest <name of interface>". It seems to
consistently fail on monitor interfaces, and succeed on anything else.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
[-- Attachment #2: iwfreqtest.c --]
[-- Type: application/octet-stream, Size: 999 bytes --]
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <sys/time.h>
#include <sys/stat.h>
#include <netpacket/packet.h>
#include <linux/if_ether.h>
#include <linux/if.h>
#include <linux/wireless.h>
#include <netinet/in.h>
#include <linux/if_tun.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <dirent.h>
#include <sys/utsname.h>
int main(int argc, char *argv[])
{
int fd = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
struct iwreq wrq;
int ret;
if (fd < 0) {
printf("Unable to open socket!\n");
return -1;
}
memset(&wrq, 0, sizeof(struct iwreq));
if (argc > 1)
strncpy(wrq.ifr_name, argv[1], IFNAMSIZ);
else
strncpy(wrq.ifr_name, "mon0", IFNAMSIZ);
ret = ioctl(fd, SIOCGIWFREQ, &wrq);
printf("SIOCGIWFREQ returned %d with status code %d/%d\n", wrq.u.freq.m, ret, errno);
close(fd);
return 0;
}
^ permalink raw reply
* Path for fixed channel issue in aircrack-ng suite
From: Joker Joker @ 2010-05-25 5:07 UTC (permalink / raw)
To: linux-wireless
Below is a patch to fix monitor mode channel issue for aircrack-ng suit
(fixed channel mon0: -1)
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index d92d088..93f6c19 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -48,6 +48,7 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
enum nl80211_channel_type channel_type)
{
struct ieee80211_channel *chan;
+ struct wireless_dev *old_wdev = wdev;
int result;
if (wdev->iftype == NL80211_IFTYPE_MONITOR)
@@ -73,8 +74,8 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
if (result)
return result;
- if (wdev)
- wdev->channel = chan;
+ wdev = old_wdev;
+ wdev->channel = chan;
return 0;
}
^ permalink raw reply related
* [RFC PATCH 0/1] cfg80211: Fix user-space crda query stall
From: Juuso Oikarinen @ 2010-05-25 6:50 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
When the user-space crda daemon fails to respond to kernel queries, the kernel
crda subsystem will stall, refusing any further regulatory hints. Details are
in the description of the patch itself.
The patch proposes a fix to the problem by adding a timeout to the user-space
crda accesses, reverting to the 00 domain if user space fails to respond. This
seems safe assuming we don't know what the rules of the requested domain and
allows further regulatory hints to be processed again.
In my testing, this patch appears to function in the various scenarios I can
produce (user hints and 11d hints.) My understanding of the crda subsystem is
still relatively shallow, so I'm asking for your thoughts on this approach.
Comments will be appreaciated!
Juuso Oikarinen (1):
cfg80211: Fix user-space crda query stall
net/wireless/reg.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH] cfg80211: Fix user-space crda query stall
From: Juuso Oikarinen @ 2010-05-25 6:50 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <1274770211-22710-1-git-send-email-juuso.oikarinen@nokia.com>
The userspace crda utility can fail to respond to kernel requests in (at least)
two scenarios: it is not runnable for any reason, or it is invoked with a
country code not in its database.
When the userspace crda utility fails to respond to kernel requests (i.e. it
does not use NL80211_CMD_SET_REG to provide the kernel regulatory information
for the requested country) the kernel crda subsystem will stall. It will
refuse to process any further regulatory hints. This is easiest demonstrated
by using for instance the "iw" tool:
iw reg set EU
iw reg set US
"EU" is not a country code present in the database, so user space crda will
not respond. Attempting to define US after that will be silently ignored
(internally, an -EAGAIN is the result, as the "EU" request is still
"being processed".)
To fix this issue, this patch implements timeout protection for the userspace
crda invocation. If there is no response for five seconds, the crda code will
force itself to the world regulatory domain for maximum safety.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
net/wireless/reg.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 8f0d97d..6c945f0 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -385,6 +385,40 @@ static inline void reg_regdb_query(const char *alpha2) {}
#endif /* CONFIG_CFG80211_INTERNAL_REGDB */
/*
+ * This gets invoked if crda in userspace is not responding (it's not getting
+ * executed or the country code in the hint is not in the database.
+ */
+
+static void call_crda_timeout_work(struct work_struct *work)
+{
+ if (!last_request)
+ return;
+
+ printk(KERN_INFO "cfg80211: crda request timed out, reverting to 00\n");
+
+ mutex_lock(&cfg80211_mutex);
+
+ /*
+ * As we are not getting data for the current country, force us back
+ * to the world regdomain.
+ */
+ last_request->alpha2[0] = '0';
+ last_request->alpha2[1] = '0';
+ set_regdom(cfg80211_world_regdom);
+ mutex_unlock(&cfg80211_mutex);
+}
+
+static DECLARE_WORK(crda_uevent_timeout_work, call_crda_timeout_work);
+
+#define CRDA_UEVENT_TIMEOUT 5000
+static void crda_uevent_timeout(unsigned long data)
+{
+ schedule_work(&crda_uevent_timeout_work);
+}
+
+static DEFINE_TIMER(crda_uevent_timer, crda_uevent_timeout, 0, 0);
+
+/*
* This lets us keep regulatory code which is updated on a regulatory
* basis in userspace.
*/
@@ -409,6 +443,10 @@ static int call_crda(const char *alpha2)
country_env[8] = alpha2[0];
country_env[9] = alpha2[1];
+ /* start timeout timer */
+ mod_timer(&crda_uevent_timer,
+ jiffies + msecs_to_jiffies(CRDA_UEVENT_TIMEOUT));
+
return kobject_uevent_env(®_pdev->dev.kobj, KOBJ_CHANGE, envp);
}
@@ -2581,6 +2619,9 @@ int set_regdom(const struct ieee80211_regdomain *rd)
assert_cfg80211_lock();
+ /* cancel timeout */
+ del_timer(&crda_uevent_timer);
+
mutex_lock(®_mutex);
/* Note that this doesn't update the wiphys, this is done below */
@@ -2683,6 +2724,9 @@ void regulatory_exit(void)
cancel_work_sync(®_work);
+ del_timer_sync(&crda_uevent_timer);
+ cancel_work_sync(&crda_uevent_timeout_work);
+
mutex_lock(&cfg80211_mutex);
mutex_lock(®_mutex);
--
1.6.3.3
^ permalink raw reply related
* wireless-regdb: A band is missing for IL
From: Emmanuel Grumbach @ 2010-05-25 7:03 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
According to http://en.wikipedia.org/wiki/List_of_WLAN_channels#5.C2.A0GHz_.28802.11a.2Fh.2Fj.2Fn.29
Channels 34 - 64 are allowed in 20 Mhz in Israel. This is not what is
written in db.txt:
country IL:
(2402 - 2482 @ 40), (N/A, 20)
This wikipedia page relies on an official page from the Israel
Ministry of the Communication.
Emmanuel Grumbach
egrumbach@gmail.com
^ permalink raw reply
* [RFC PATCH] mac80211: Add support for hardware ARP query filtering
From: Juuso Oikarinen @ 2010-05-25 7:48 UTC (permalink / raw)
To: linux-wireless
Some hardware allow extended filtering of ARP frames not intended for
this host. To perform such filtering, the hardware needs to know the current
IP address(es) of the host, bound to its interface.
Add support for ARP filtering to mac80211 by adding a new op to the driver
interface, allowing to configure the current IP addresses. Call this op when
the interface is opened (as there may be an address already configured) and
whenever the IP addresses change.
This patch adds configuration of IPv4 addresses only, as IPv6 addresses don't
need ARP filtering. IPv6 support could be added later if someone comes up with
more frame types that can be filtered in hardware already.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
include/net/mac80211.h | 9 ++++++++
net/mac80211/driver-ops.h | 12 ++++++++++
net/mac80211/ieee80211_i.h | 2 +
net/mac80211/iface.c | 1 +
net/mac80211/main.c | 49 +++++++++++++++++++++++++++++++++++++++++++-
5 files changed, 72 insertions(+), 1 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index de22cbf..2354956 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1468,6 +1468,8 @@ enum ieee80211_ampdu_mlme_action {
IEEE80211_AMPDU_TX_OPERATIONAL,
};
+struct in_ifaddr;
+
/**
* struct ieee80211_ops - callbacks from mac80211 to the driver
*
@@ -1535,6 +1537,11 @@ enum ieee80211_ampdu_mlme_action {
* of the bss parameters has changed when a call is made. The callback
* can sleep.
*
+ * @configure_ip_filter: Configuration function for IP address based filters,
+ * such as an ARP query filter. This function is called with all the IP
+ * addresses configured to the interface as argument - all frames targeted
+ * to any of these addresses should pass through.
+ *
* @prepare_multicast: Prepare for multicast filter configuration.
* This callback is optional, and its return value is passed
* to configure_filter(). This callback must be atomic.
@@ -1674,6 +1681,8 @@ struct ieee80211_ops {
struct ieee80211_vif *vif,
struct ieee80211_bss_conf *info,
u32 changed);
+ int (*configure_ip_filter)(struct ieee80211_hw *hw,
+ struct in_ifaddr *ifa_list);
u64 (*prepare_multicast)(struct ieee80211_hw *hw,
struct netdev_hw_addr_list *mc_list);
void (*configure_filter)(struct ieee80211_hw *hw,
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 4f22713..fff6aca 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -83,6 +83,18 @@ static inline void drv_bss_info_changed(struct ieee80211_local *local,
trace_drv_bss_info_changed(local, sdata, info, changed);
}
+struct in_ifaddr;
+static inline int drv_configure_ip_filter(struct ieee80211_hw *hw,
+ struct in_ifaddr *ifa_list)
+{
+ struct ieee80211_local *local = hw_to_local(hw);
+ int ret = 0;
+
+ if (local->ops->configure_ip_filter)
+ ret = local->ops->configure_ip_filter(hw, ifa_list);
+ return ret;
+}
+
static inline u64 drv_prepare_multicast(struct ieee80211_local *local,
struct netdev_hw_addr_list *mc_list)
{
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 1a9e2da..56e1331 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -851,6 +851,7 @@ struct ieee80211_local {
struct work_struct dynamic_ps_disable_work;
struct timer_list dynamic_ps_timer;
struct notifier_block network_latency_notifier;
+ struct notifier_block ifa_notifier;
int user_power_level; /* in dBm */
int power_constr_level; /* in dBm */
@@ -996,6 +997,7 @@ void ieee80211_send_pspoll(struct ieee80211_local *local,
void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency);
int ieee80211_max_network_latency(struct notifier_block *nb,
unsigned long data, void *dummy);
+int ieee80211_set_arp_filter(struct net_device *ndev);
void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
struct ieee80211_channel_sw_ie *sw_elem,
struct ieee80211_bss *bss,
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 50deb01..5b488b8 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -330,6 +330,7 @@ static int ieee80211_open(struct net_device *dev)
if (sdata->vif.type == NL80211_IFTYPE_STATION)
ieee80211_queue_work(&local->hw, &sdata->u.mgd.work);
+ ieee80211_set_arp_filter(dev);
netif_tx_start_all_queues(dev);
return 0;
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 22a384d..f39e065 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -20,6 +20,7 @@
#include <linux/rtnetlink.h>
#include <linux/bitmap.h>
#include <linux/pm_qos_params.h>
+#include <linux/inetdevice.h>
#include <net/net_namespace.h>
#include <net/cfg80211.h>
@@ -329,6 +330,43 @@ static void ieee80211_recalc_smps_work(struct work_struct *work)
mutex_unlock(&local->iflist_mtx);
}
+int ieee80211_set_arp_filter(struct net_device *ndev)
+{
+ struct ieee80211_local *local;
+ struct in_device *idev;
+ int ret;
+
+ BUG_ON(!ndev);
+
+ idev = ndev->ip_ptr;
+ if (!idev)
+ return 0;
+
+ local = wdev_priv(ndev->ieee80211_ptr);
+ ret = drv_configure_ip_filter(&local->hw, idev->ifa_list);
+ return ret;
+}
+
+static int ieee80211_ifa_changed(struct notifier_block *nb,
+ unsigned long data, void *arg)
+{
+ struct in_ifaddr *ifa = arg;
+ struct ieee80211_local *local =
+ container_of(nb, struct ieee80211_local,
+ ifa_notifier);
+ struct net_device *ndev = ifa->ifa_dev->dev;
+ struct wireless_dev *wdev = ndev->ieee80211_ptr;
+
+ if (!wdev)
+ return NOTIFY_DONE;
+
+ if (wdev->wiphy != local->hw.wiphy)
+ return NOTIFY_DONE;
+
+ ieee80211_set_arp_filter(ndev);
+ return NOTIFY_DONE;
+}
+
struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
const struct ieee80211_ops *ops)
{
@@ -612,14 +650,22 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
ieee80211_max_network_latency;
result = pm_qos_add_notifier(PM_QOS_NETWORK_LATENCY,
&local->network_latency_notifier);
-
if (result) {
rtnl_lock();
goto fail_pm_qos;
}
+ local->ifa_notifier.notifier_call = ieee80211_ifa_changed;
+ result = register_inetaddr_notifier(&local->ifa_notifier);
+ if (result)
+ goto fail_ifa;
+
return 0;
+ fail_ifa:
+ pm_qos_remove_notifier(PM_QOS_NETWORK_LATENCY,
+ &local->network_latency_notifier);
+ rtnl_lock();
fail_pm_qos:
ieee80211_led_exit(local);
ieee80211_remove_interfaces(local);
@@ -647,6 +693,7 @@ void ieee80211_unregister_hw(struct ieee80211_hw *hw)
pm_qos_remove_notifier(PM_QOS_NETWORK_LATENCY,
&local->network_latency_notifier);
+ unregister_inetaddr_notifier(&local->ifa_notifier);
rtnl_lock();
--
1.6.3.3
^ permalink raw reply related
* Re: Path for fixed channel issue in aircrack-ng suite
From: Johannes Berg @ 2010-05-25 8:11 UTC (permalink / raw)
To: Joker Joker; +Cc: linux-wireless
In-Reply-To: <AANLkTinAnMwY0ZCetUmUbuhsp3rB360xvlaGM5ifdFHz@mail.gmail.com>
On Tue, 2010-05-25 at 01:07 -0400, Joker Joker wrote:
> Below is a patch to fix monitor mode channel issue for aircrack-ng suit
> (fixed channel mon0: -1)
>
> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
> index d92d088..93f6c19 100644
> --- a/net/wireless/chan.c
> +++ b/net/wireless/chan.c
> @@ -48,6 +48,7 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
> enum nl80211_channel_type channel_type)
> {
> struct ieee80211_channel *chan;
> + struct wireless_dev *old_wdev = wdev;
> int result;
>
> if (wdev->iftype == NL80211_IFTYPE_MONITOR)
> @@ -73,8 +74,8 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
> if (result)
> return result;
>
> - if (wdev)
> - wdev->channel = chan;
> + wdev = old_wdev;
> + wdev->channel = chan;
NACK. That will crash when there really is no interface being passed in.
johannes
^ permalink raw reply
* Re: [RFC PATCH] mac80211: Add support for hardware ARP query filtering
From: Johannes Berg @ 2010-05-25 9:13 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1274773685-11168-1-git-send-email-juuso.oikarinen@nokia.com>
On Tue, 2010-05-25 at 10:48 +0300, Juuso Oikarinen wrote:
> +struct in_ifaddr;
> +
I think you should include a header file for that, or was there a reason
you didn't?
> + * @configure_ip_filter: Configuration function for IP address based filters,
> + * such as an ARP query filter. This function is called with all the IP
> + * addresses configured to the interface as argument - all frames targeted
> + * to any of these addresses should pass through.
Huh ok I thought you wanted ARP filtering, not IP filtering. You need to
be more explicit about what this should do. IP filtering is not useful
since those frames will be unicast on the ethernet layer. I think this
should be more focused on ARP filtering.
Additionally, it needs to be very explicit that it must filter ONLY ARP
packets that do not match any of the given IP addresses. If, for
example, the hardware can only handle 2 addresses, but you have 3 in the
list, the filter must be turned off. Any packet that the device cannot
parse properly must also be passed through. All such things should be
documented.
> +struct in_ifaddr;
You should get the right include too.
> +static inline int drv_configure_ip_filter(struct ieee80211_hw *hw,
> + struct in_ifaddr *ifa_list)
> +{
> + struct ieee80211_local *local = hw_to_local(hw);
> + int ret = 0;
> +
> + if (local->ops->configure_ip_filter)
> + ret = local->ops->configure_ip_filter(hw, ifa_list);
> + return ret;
> +}
Tracing would be nice, you should even able able to trace all addresses
in a variable-length array.
> @@ -330,6 +330,7 @@ static int ieee80211_open(struct net_device *dev)
> if (sdata->vif.type == NL80211_IFTYPE_STATION)
> ieee80211_queue_work(&local->hw, &sdata->u.mgd.work);
>
> + ieee80211_set_arp_filter(dev);
That seems unnecessary if drivers assume that there are no addresses to
start with?
BTW, how will drivers deal with getting this while unassociated? If, for
example, I set an address before associating, you'll get it while
unassociated and not again when associated. Another thing to document --
driver needs to handle that, DHCP is not everything :)
> +static int ieee80211_ifa_changed(struct notifier_block *nb,
> + unsigned long data, void *arg)
> +{
> + struct in_ifaddr *ifa = arg;
> + struct ieee80211_local *local =
> + container_of(nb, struct ieee80211_local,
> + ifa_notifier);
> + struct net_device *ndev = ifa->ifa_dev->dev;
> + struct wireless_dev *wdev = ndev->ieee80211_ptr;
> +
> + if (!wdev)
> + return NOTIFY_DONE;
> +
> + if (wdev->wiphy != local->hw.wiphy)
> + return NOTIFY_DONE;
> +
> + ieee80211_set_arp_filter(ndev);
> + return NOTIFY_DONE;
> +}
This is obviously broken when you have multiple virtual interfaces, so
you either need to build a common list of IP addresses, or punt the
problem to the driver and give the callback an ieee80211_vif argument
and clearly document that the driver will have to keep track of it for
each interface.
johannes
^ permalink raw reply
* Re: [RFC PATCH] mac80211: Add support for hardware ARP query filtering
From: Juuso Oikarinen @ 2010-05-25 9:31 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1274778802.3635.30.camel@jlt3.sipsolutions.net>
On Tue, 2010-05-25 at 11:13 +0200, ext Johannes Berg wrote:
> On Tue, 2010-05-25 at 10:48 +0300, Juuso Oikarinen wrote:
>
> > +struct in_ifaddr;
> > +
>
> I think you should include a header file for that, or was there a reason
> you didn't?
Yeah, I'll add the header.
> > + * @configure_ip_filter: Configuration function for IP address based filters,
> > + * such as an ARP query filter. This function is called with all the IP
> > + * addresses configured to the interface as argument - all frames targeted
> > + * to any of these addresses should pass through.
>
> Huh ok I thought you wanted ARP filtering, not IP filtering. You need to
> be more explicit about what this should do. IP filtering is not useful
> since those frames will be unicast on the ethernet layer. I think this
> should be more focused on ARP filtering.
True, this is about ARP filtering. I was pondering naming it arp or IP,
then opted to go with IP just because I was thinking that there may be
some other frames we might want to filter based on IP in the future.
Maybe I'm thinking too far ahead ;)
I'll update the naming to be ARP all around.
> Additionally, it needs to be very explicit that it must filter ONLY ARP
> packets that do not match any of the given IP addresses. If, for
> example, the hardware can only handle 2 addresses, but you have 3 in the
> list, the filter must be turned off. Any packet that the device cannot
> parse properly must also be passed through. All such things should be
> documented.
This is a valid point. That's actually what the wl1271 driver does - as
the HW only supports one address for its filter. I'll add some text for
this.
> > +struct in_ifaddr;
>
> You should get the right include too.
>
> > +static inline int drv_configure_ip_filter(struct ieee80211_hw *hw,
> > + struct in_ifaddr *ifa_list)
> > +{
> > + struct ieee80211_local *local = hw_to_local(hw);
> > + int ret = 0;
> > +
> > + if (local->ops->configure_ip_filter)
> > + ret = local->ops->configure_ip_filter(hw, ifa_list);
> > + return ret;
> > +}
>
> Tracing would be nice, you should even able able to trace all addresses
> in a variable-length array.
Yeah, I was lazy. I will look into this :P
>
> > @@ -330,6 +330,7 @@ static int ieee80211_open(struct net_device *dev)
> > if (sdata->vif.type == NL80211_IFTYPE_STATION)
> > ieee80211_queue_work(&local->hw, &sdata->u.mgd.work);
> >
> > + ieee80211_set_arp_filter(dev);
>
> That seems unnecessary if drivers assume that there are no addresses to
> start with?
>
The drivers assume there is no address to start with - this is for the
scenario when there is, so that the driver enables the filtering from
scratch. You can do this, for instance:
ifconfig wlan0 up 192.168.1.1
ifconfig wlan0 down
ifconfig wlan0 up
The address 192.168.1.1 will be there already on ifconfig wlan0 up.
> BTW, how will drivers deal with getting this while unassociated? If, for
> example, I set an address before associating, you'll get it while
> unassociated and not again when associated. Another thing to document --
> driver needs to handle that, DHCP is not everything :)
This is actually a good point. The wl1271 driver configures the ARP
filter immediately - associated or not - once the chipset is booted up
(as above.) This is indeed not very generic.
I will move the set_arp_filter -thingy from _open() to when the we are
associated. That way we get the initial IP address (if there happen to
be any) from start when the address is actually needed.
>
> > +static int ieee80211_ifa_changed(struct notifier_block *nb,
> > + unsigned long data, void *arg)
> > +{
> > + struct in_ifaddr *ifa = arg;
> > + struct ieee80211_local *local =
> > + container_of(nb, struct ieee80211_local,
> > + ifa_notifier);
> > + struct net_device *ndev = ifa->ifa_dev->dev;
> > + struct wireless_dev *wdev = ndev->ieee80211_ptr;
> > +
> > + if (!wdev)
> > + return NOTIFY_DONE;
> > +
> > + if (wdev->wiphy != local->hw.wiphy)
> > + return NOTIFY_DONE;
> > +
> > + ieee80211_set_arp_filter(ndev);
> > + return NOTIFY_DONE;
> > +}
>
> This is obviously broken when you have multiple virtual interfaces, so
> you either need to build a common list of IP addresses, or punt the
> problem to the driver and give the callback an ieee80211_vif argument
> and clearly document that the driver will have to keep track of it for
> each interface.
Good point. I will "punt" (never heard this expression before!) the
problem to the driver with a vif pointer.
Thanks for your review. :)
-Juuso
> johannes
>
^ 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