* [PATCH v2.6.31] mac80211: disable mesh
From: Johannes Berg @ 2009-07-10 9:38 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Javier Cardona, Andrey Yurovsky
My kvm instance was complaining a lot about sleeping
in atomic contexts in the mesh code, and it turns out
that both mesh_path_add() and mpp_path_add() need to
be able to sleep (they even use synchronize_rcu()!).
I put in a might_sleep() to annotate that, but I see
no way, at least right now, of actually making sure
those functions are only called from process context
since they are both called during TX and RX and the
mesh code itself even calls them with rcu_read_lock()
"held".
Therefore, let's disable it completely for now.
It's possible that I'm only seeing this because the
hwsim's beaconing is broken and thus the peers aren't
discovered right away, but it is possible that this
happens even if beaconing is working, for a peer that
doesn't exist or so.
It should be possible to solve this by deferring the
freeing of the tables to call_rcu() instead of using
synchronize_rcu(), and also using atomic allocations,
but maybe it makes more sense to rework the code to
not call these from atomic contexts and defer more of
the work to the workqueue. Right now, I can't work on
either of those solutions though.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
Javier, sorry -- I don't see how this could ever have
worked?
net/mac80211/Kconfig | 1 +
net/mac80211/mesh_pathtbl.c | 3 +++
2 files changed, 4 insertions(+)
--- wireless-testing.orig/net/mac80211/mesh_pathtbl.c 2009-07-10 11:27:09.000000000 +0200
+++ wireless-testing/net/mac80211/mesh_pathtbl.c 2009-07-10 11:28:49.000000000 +0200
@@ -175,6 +175,8 @@ int mesh_path_add(u8 *dst, struct ieee80
int err = 0;
u32 hash_idx;
+ might_sleep();
+
if (memcmp(dst, sdata->dev->dev_addr, ETH_ALEN) == 0)
/* never add ourselves as neighbours */
return -ENOTSUPP;
@@ -265,6 +267,7 @@ int mpp_path_add(u8 *dst, u8 *mpp, struc
int err = 0;
u32 hash_idx;
+ might_sleep();
if (memcmp(dst, sdata->dev->dev_addr, ETH_ALEN) == 0)
/* never add ourselves as neighbours */
--- wireless-testing.orig/net/mac80211/Kconfig 2009-07-10 11:28:57.000000000 +0200
+++ wireless-testing/net/mac80211/Kconfig 2009-07-10 11:29:05.000000000 +0200
@@ -67,6 +67,7 @@ endmenu
config MAC80211_MESH
bool "Enable mac80211 mesh networking (pre-802.11s) support"
depends on MAC80211 && EXPERIMENTAL
+ depends on BROKEN
---help---
This options enables support of Draft 802.11s mesh networking.
The implementation is based on Draft 1.08 of the Mesh Networking
^ permalink raw reply
* [PATCH] cfg80211: update misleading comment
From: Helmut Schaa @ 2009-07-10 12:54 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Johannes Berg
In cfg80211_scan_request n_channels refers to the total number
of channels to scan. Update the misleading comment accordingly.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
Maybe the comment is correct and it is just me who thinks it is
misleading ;) but I just stumbled over that.
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index dba7874..d458972 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -538,7 +538,7 @@ struct cfg80211_ssid {
* @ssids: SSIDs to scan for (active scan only)
* @n_ssids: number of SSIDs
* @channels: channels to scan on.
- * @n_channels: number of channels for each band
+ * @n_channels: total number of channels to scan
* @ie: optional information element(s) to add into Probe Request or %NULL
* @ie_len: length of ie in octets
* @wiphy: the wiphy this was for
^ permalink raw reply related
* Re: [regression] ath5k: Overrides regulatory domain set for cfg80211
From: Frans Pop @ 2009-07-10 11:43 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, netdev, Linux Kernel Mailing List
In-Reply-To: <43e72e890907081907j279f48eep99e73cc2951dfdb@mail.gmail.com>
Thanks again for your elaborate explanation Louis.
On Thursday 09 July 2009, Luis R. Rodriguez wrote:
> EU is a valid regulatory domain only when the relic option
> CONFIG_WIRELESS_OLD_REGULATORY is used. When you use OLD_REG and "EU"
> you get stuck to a statically defined regulatory domain in the kernel.
>
> > [Now I specify NL and it gives me US; how's that an improvement?]
>
> Since you are using OLD_REG the default is "US", that was the behavior
> prior to the new regulatory code so its left as is. So that is by
> design following the old crap regulatory code design.
>
> > cfg80211: Calling CRDA for country: NL
> > [no agent, so this does not actually change anything]
>
> Users of OLD_REG who do not have new userspace should stick to using
> the 3 static regulatory domains:
>
> 1) US *
> 2) JP
> 3) EU
Right, so the EU I had originally was correct after all :-)
> >> For further information please also read
> >> Documentation/feature-removal-schedule.txt. Please use a valid
> >> ISO-3166 alpha2 country code, I also advise to abandon the usage of
> >> the ieee80211_regdom module parameter which we do eventually intend
> >> on deprecating and if you know anyone using that please suggest the
> >> same.
> >
> > As mentioned above I do not currently have the option of abandoning
> > it.
>
> Yes you do, but you don't seem to want to do anything beyond what your
> distribution offers, which is different.
You're right :-)
However, I am also a Debian Developer and Debian may (just as we did for
Etch), at some point want to offer a newer kernel than the current .26
for stable (possibly .31). From that PoV it is important to ensure there
are no incompatibilities with what's in Debian stable.
For that reason I am very conservative when it comes to installer newer or
backported versions of packages.
> > That seems particularly bad in my case. For some weird reason this
> > Trust PCMCIA card seems to have AM in its EEPROM, which is Armenia...
> > The card was bought in the Netherlands (NL), which is also where I
> > live.
>
> Yeah the short story of that is Armenia and Netherlands both have the
> same regulatory rules, the first alpha2 that matched the same group
> was picked up, which just so happened to be Armenia. In the future it
> will be easier if cards are just programmed with the alpha2 country
> code or with a world regulatory domain code, and just abandon the
> grouping idea. That is something we will have to look forward to
> change and promote for future device. What counts for regulatory
> purposes is your device is complaint. The alternative was to keep all
> the regulatory information statically in the kernel for each
> regulatory group for Atheros devices.
Ah! I had no idea about that and I guess that this is the real issue here:
a simple usability problem. If I had seen the correct countrycode (NL
instead of AM), I probably never would have reported a regression. What
prompted my mail was that, from a user PoV, the country being selected
looked to be completely broken. How am I, as a simple user, supposed to
know that Armenia uses the same domain as the Netherlands and that what
the driver is doing is actually 100% correct (and even that my PCMCIA
card is not as broken as I thought)?
Would it be possible to improve the info presented by the kernel? Maybe
print an extra line with a list of countries that use the selected reg
domain (depends I guess on what's the max. nr. of countries that share a
domain). Or at least indicate that the country code is a somewhat random
choice.
> > I can to some extend understand respecting hardware settings for APs,
> > but for a wireless NIC it seems a useless limitation.
>
> You are right to a certain degree. The thing is wireless cards *can*
> be used as APs on a regular desktops. Perhaps not with iwlagn, but
> with ath5k and ath9k you can do AP, IBSS, Mesh, all of which actually
> do start transmit with out any AP being around. For these cases you
> *do* need to ensure proper regulatory compliance. And we haven't even
> touched on DFS!
Well, IIUC you do know what mode the card is being used in, so in theory
you could distinguish between them. I'm not pushing for that though.
End conclusion is that there is no regression and no backwards
compatibility issue (which is good news), just a usability issue.
Thanks,
FJP
^ permalink raw reply
* Re: [PATCH v2] mac80211: monitor the connection
From: Kalle Valo @ 2009-07-10 11:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1247187640.1905.16.camel@johannes.local>
Johannes Berg <johannes@sipsolutions.net> writes:
> With the recent MLME rework I accidentally removed the connection
> monitoring code. In order to add it back, this patch will add new
> code to monitor both for beacon loss and for the connection actually
> working, with possibly separate triggers.
>
> When no unicast frames have been received from the AP for (currently)
> two seconds, we will send the AP a probe request.
I think this is too short, but we can change it later.
I quickly looked at the patch and it looks ok for me. Unfortunately I
can't test it right now because N800 support is broken in 2.6.31. I'm
fixing that currently.
--
Kalle Valo
^ permalink raw reply
* Re: Problem with p54 driver and ibss mode
From: Alexander Wenzel @ 2009-07-10 10:29 UTC (permalink / raw)
To: Max Filippov; +Cc: linux-wireless
In-Reply-To: <200907092157.21784.jcmvbkbc@gmail.com>
Hi there...
>> I just checked the other N810 devices and every device has
>> the same mac address. And here we go... [p54spi_eeprom.h:39]
>> 0x00, 0x02, 0xee, 0xc0, 0xff, 0xee,
>> So is there a way to let the kernel receive and set the
>> correct mac address of the wlan device?
>> I guess my problem is this line:
>> [ 3685.320800] cx3110x spi2.0: loading default eeprom...
> You're right. I guess that easiest way to deal with it is to save blob from p54spi_eeprom.h into a file
> 3826.eeprom in the same directory as 3826.arm and fix MAC address in it, according to comments in p54spi_eeprom.h
[ 2675.558532] cx3110x spi2.0: firmware: requesting 3826.eeprom
[ 2675.625579] cx3110x spi2.0: loading user eeprom...
[ 2675.625671] phy0: hwaddr 00:1d:6e:9c:**:**, MAC:isl3820 RF:Longbow
Ok, p54 with user eeprom and manually inserted mac address works fine.
So, a part of the problem is somehow "fixed"... Thanks.
Regards,
AleX
--
**********************************************
Dipl.-Inform. (FH) Alexander Wenzel
Forschungsgesellschaft fuer
Angewandte Naturwissenschaften e. V. (FGAN)
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel. : 0049 (0)228 9435-263
Fax : 0049 (0)228 9435-685
E-Mail: wenzel@fgan.de
Web : http://www.fgan.de/
**********************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. Maurus Tacke (komm. Vors.)
Prof. Dr. Joachim Ender (Stellv.)
^ permalink raw reply
* Fwd: 4318 misbehaving with bleeding edge kernels
From: Michael Buesch @ 2009-07-10 9:31 UTC (permalink / raw)
To: linux-wireless; +Cc: bcm43xx-dev, Celejar
---------- Forwarded Message ----------
Subject: 4318 misbehaving with bleeding edge kernels
Date: Friday 10 July 2009
From: Celejar <celejar@gmail.com>
To: bcm43xx-dev <bcm43xx-dev@lists.berlios.de>
Hi,
I have a 4318 (rev 02), which has been working fine with b43.
Recently, with 2.6.31-rc2 kernels from the wireless-testing git repo,
I've been having trouble. Sometimes the card simply fails to associate
after doing 'iwconfig eth0 essid xxxx'. It doesn't even seem to try;
i.e., when it does associate, I see log entries like these:
Jul 10 02:25:19 lizzie kernel: [ 318.302652] eth0: direct probe to AP 00:1a:70:f5:76:7e (try 1)
Jul 10 02:25:19 lizzie kernel: [ 318.310396] eth0 direct probe responded
Jul 10 02:25:19 lizzie kernel: [ 318.310401] eth0: authenticate with AP 00:1a:70:f5:76:7e (try 1)
Jul 10 02:25:19 lizzie kernel: [ 318.312273] eth0: authenticated
Jul 10 02:25:19 lizzie kernel: [ 318.510040] eth0: associate with AP 00:1a:70:f5:76:7e (try 1)
Jul 10 02:25:19 lizzie kernel: [ 318.511947] eth0: RX AssocResp from 00:1a:70:f5:76:7e (capab=0x401 status=0 aid=1)
Jul 10 02:25:19 lizzie kernel: [ 318.511952] eth0: associated
Jul 10 02:25:19 lizzie kernel: [ 318.513218] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
but often I see nothing in the logs at all, and iwconfig shows
"Not-associated". I just keep repeating the 'iwconfig eth0 essid xxxx'
command until it finally takes, and then the connection seems to behave
normally. When the card is not functioning, trying 'iwlist eth0 scan'
initially gives:
~# iwlist eth0 scan
eth0 Failed to read scan data : Resource temporarily unavailable
and subsequent invocations, when the card is still not working, gives:
~# iwlist eth0 scan
eth0 Interface doesn't support scanning : Device or resource busy
When the card resumes functioning, scanning works correctly.
I have tried both the old and new firmware, with similar results. Any
ideas?
>From lspci -v:
06:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
Subsystem: AMBIT Microsystem Corp. TravelMate 2410
Flags: bus master, fast devsel, latency 64, IRQ 22
Memory at d0002000 (32-bit, non-prefetchable) [size=8K]
Kernel driver in use: b43-pci-bridge
uname -a:
Linux lizzie 2.6.31-rc2-wl-lizzie-27873-ga483c23-dirty #4 Thu Jul 9 19:13:30 EDT 2009 i686 GNU/Linux
Celejar
--
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
_______________________________________________
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
-------------------------------------------------------
--
Greetings, Michael.
^ permalink raw reply
* Re: rt73 in AP mode: PS frames buffered but missing TIM bit?
From: Stefan Steuerwald @ 2009-07-10 9:08 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <a32f33a40907090458j73b714d6w2fb0648d61beea08@mail.gmail.com>
With Ivo's help, we have a tested patch. Ivo will take care of
submitting it and extending it to all rt2x00 drivers.
I love it when things just work out!
Thank you,
Stefan.
2009/7/9 Ivo Van Doorn <ivdoorn@gmail.com>:
> On Thu, Jul 9, 2009 at 7:30 AM, Stefan
> Steuerwald<salsasepp@googlemail.com> wrote:
>>> > Sounds like a driver problem, it must not be reacting to set_tim()
>>> > properly.
>>> >
>>> > johannes
>>>
>>> Looking at rt73usb.c:2242, there isn't any initializer for .set_tim .
>>> Plausible explanation.
>>> It may be totally beyond me to just implement it. Let me find someone
>>> to ask nicely ;-) ...
>>
>> I have an experimental patch working (sent for review to the rt2x00
>> mailing list).
>> I will report back here.
>
> Are you sure you've send it already? Because I haven't seen anything yet.
>
> Ivo
>
^ permalink raw reply
* Re: Problem with p54 driver and ibss mode
From: Max Filippov @ 2009-07-10 8:36 UTC (permalink / raw)
To: Kalle Valo
Cc: Johannes Berg, Christian Lamparter, Alexander Wenzel,
linux-wireless
In-Reply-To: <87iqi10xi0.fsf@litku.valot.fi>
> Basically we have been talking about fetching calibration data via the
> request_firmware() interface. In user space there would be a udev script
> which would dynamically retrieve the calibration data specific to the
> platform it is running on. In N800/N810 case that would mean to run
> stlc45xx-cal and provide the calibration data to the driver.
>
> This way we can have platform specific implementations and use already
> existing user space interface. The idea was discussed in this mailing
> list few months ago. The implementation details are currently unknown to
> me. I was planning to talk about this at the Wireless Summit, but of
> course I forgot :/
>
> stlc45xx-cal will most probably need some changes, maybe dumping the
> calibration data to stdout so that udev script can forward it to the
> driver? I can do the necessary changes to stlc45xx-cal, but it's better
> to have a some sort of working prototype before I'll start changing
> stlc45xx-cal.
Ok. Gonna make such prototype during this weekend.
--
Max
^ permalink raw reply
* Re: Problem with p54 driver and ibss mode
From: Kalle Valo @ 2009-07-10 8:10 UTC (permalink / raw)
To: Max Filippov
Cc: Johannes Berg, Christian Lamparter, Alexander Wenzel,
linux-wireless
In-Reply-To: <73aaf0dd0907100043p7916c4fbid9aa2faa3580477d@mail.gmail.com>
Max Filippov <jcmvbkbc@gmail.com> writes:
>>> Should be easy to copy the code into p54spi, we just never did, hoping
>>> Kalle would come up with a better way, maybe request_firmware() :)
>>
>> I agree with you, better not to copy the sysfs interface to p54spi. I'm
>> planning to experiment with the firmware interface at some point, but it
>> would be great if someone else could take a look at it first.
>
> I can take a look at it. (:
Excellent!
> But the question is... to take a look at it to see what?
:)
Basically we have been talking about fetching calibration data via the
request_firmware() interface. In user space there would be a udev script
which would dynamically retrieve the calibration data specific to the
platform it is running on. In N800/N810 case that would mean to run
stlc45xx-cal and provide the calibration data to the driver.
This way we can have platform specific implementations and use already
existing user space interface. The idea was discussed in this mailing
list few months ago. The implementation details are currently unknown to
me. I was planning to talk about this at the Wireless Summit, but of
course I forgot :/
stlc45xx-cal will most probably need some changes, maybe dumping the
calibration data to stdout so that udev script can forward it to the
driver? I can do the necessary changes to stlc45xx-cal, but it's better
to have a some sort of working prototype before I'll start changing
stlc45xx-cal.
--
Kalle Valo
^ permalink raw reply
* xbox wireless network adapter in linux
From: Ram kumar @ 2009-07-10 7:44 UTC (permalink / raw)
To: linux-wireless
hi,
I would like to know whether we can support xbox wireless network
adapter in linux ?
http://www.xbox.com/en-US/hardware/x/xbox360wirelessnetadapter/default.htm
This xbox wireless network adapter has marvell 8388 controller.
Any info on how to support xbox wireless network adapter in linux
using libertas driver will be helpful to me.
And i have seen that the marvell 8388 controller with usb interface,
support "AP"(access point mode).
so i am assuming that the above xbox wirless network adapter can be
made to work as AP(access point)
correct me if i am wrong.
http://www.free60.org/wiki/Wifi_Adapter
this link says it will work very well with any operating system if it
has drivers.
Please let me know whether has anyone supported this xbox wireless
network adapter in linux.
Regards,
Ram
^ permalink raw reply
* Re: Problem with p54 driver and ibss mode
From: Max Filippov @ 2009-07-10 7:43 UTC (permalink / raw)
To: Kalle Valo
Cc: Johannes Berg, Christian Lamparter, Alexander Wenzel,
linux-wireless
In-Reply-To: <87my7d10nz.fsf@litku.valot.fi>
>> Should be easy to copy the code into p54spi, we just never did, hoping
>> Kalle would come up with a better way, maybe request_firmware() :)
>
> I agree with you, better not to copy the sysfs interface to p54spi. I'm
> planning to experiment with the firmware interface at some point, but it
> would be great if someone else could take a look at it first.
I can take a look at it. (: But the question is... to take a look at
it to see what?
--
Max
^ permalink raw reply
* Re: Problem with p54 driver and ibss mode
From: Kalle Valo @ 2009-07-10 7:01 UTC (permalink / raw)
To: Johannes Berg
Cc: Max Filippov, Christian Lamparter, Alexander Wenzel,
linux-wireless
In-Reply-To: <1247176098.1905.8.camel@johannes.local>
Johannes Berg <johannes@sipsolutions.net> writes:
>> > stlc45xx-cal pushes the device specific calibration data and sets the
>> > MAC address. It's recommended to run it to get optimal performance.
>> >
>> IIRC stlc45xx-cal pushes these data into sysfs entries, which
>> stlc45xx used to create. There's no such interface in p54spi.
Oh yeah, I forgot that.
> Should be easy to copy the code into p54spi, we just never did, hoping
> Kalle would come up with a better way, maybe request_firmware() :)
I agree with you, better not to copy the sysfs interface to p54spi. I'm
planning to experiment with the firmware interface at some point, but it
would be great if someone else could take a look at it first.
--
Kalle Valo
^ permalink raw reply
* Re: 2.6.31-rc2: Reported regressions from 2.6.30
From: Andres Freund @ 2009-07-10 2:10 UTC (permalink / raw)
To: John Dykstra, Rafael J. Wysocki
Cc: Eric Sesterhenn, Linux Kernel Mailing List, Adrian Bunk,
Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <1247190417.7306.2.camel@merlyn>
Hi John, Hi Rafael,
On Friday 10 July 2009 03:46:57 John Dykstra wrote:
> On Tue, 2009-07-07 at 03:25 +0200, Andres Freund wrote:
> > There is also http://lkml.org/lkml/2009/6/30/398 : Soft-Lockup/Race
> > in
> > networking in 2.6.31-rc1+195 (possibly caused by netem)
>
> There is some similarity between this soft lockup and the one reported
> in http://www.spinics.net/lists/netdev/msg100957.html. In both, the
> process is doing both sends and receives on raw sockets.
The issue turned out to be a hrtimer bug - i dont see anything like it in your
trace. If you still want to test the fix, its
de907e8432b08f2d5966c36e0747e97c0e596810 in -tip (or
http://lkml.org/lkml/2009/7/9/150)
Rafael: In case youre reading this, I guess you can mark that bug as resolved.
Andres
^ permalink raw reply
* Re: 2.6.31-rc2: Reported regressions from 2.6.30
From: John Dykstra @ 2009-07-10 1:46 UTC (permalink / raw)
To: Andres Freund
Cc: Eric Sesterhenn, Rafael J. Wysocki, Linux Kernel Mailing List,
Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <200907070325.51439.andres@anarazel.de>
On Tue, 2009-07-07 at 03:25 +0200, Andres Freund wrote:
> There is also http://lkml.org/lkml/2009/6/30/398 : Soft-Lockup/Race
> in
> networking in 2.6.31-rc1+195 (possibly caused by netem)
There is some similarity between this soft lockup and the one reported
in http://www.spinics.net/lists/netdev/msg100957.html. In both, the
process is doing both sends and receives on raw sockets.
-- John
^ permalink raw reply
* [PATCH v2] mac80211: monitor the connection
From: Johannes Berg @ 2009-07-10 1:00 UTC (permalink / raw)
To: John Linville; +Cc: Kalle Valo, linux-wireless
In-Reply-To: <1247186507.1905.14.camel@johannes.local>
With the recent MLME rework I accidentally removed the connection
monitoring code. In order to add it back, this patch will add new
code to monitor both for beacon loss and for the connection actually
working, with possibly separate triggers.
When no unicast frames have been received from the AP for (currently)
two seconds, we will send the AP a probe request. Also, when we don't
see beacons from the AP for two seconds, we do the same (but those
times need not be the same due to the way the code is now written).
Additionally, clean up the parameters to the ieee80211_set_disassoc()
function that I need here, those are all useless except sdata.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
v2: print a message when this happens
net/mac80211/ieee80211_i.h | 20 ++-
net/mac80211/mlme.c | 252 ++++++++++++++++++++++++++++++++++++---------
net/mac80211/rx.c | 22 +--
3 files changed, 222 insertions(+), 72 deletions(-)
--- wireless-testing.orig/net/mac80211/mlme.c 2009-07-09 22:08:56.000000000 +0200
+++ wireless-testing/net/mac80211/mlme.c 2009-07-10 02:50:07.000000000 +0200
@@ -31,8 +31,23 @@
#define IEEE80211_AUTH_MAX_TRIES 3
#define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
#define IEEE80211_ASSOC_MAX_TRIES 3
-#define IEEE80211_MONITORING_INTERVAL (2 * HZ)
-#define IEEE80211_PROBE_WAIT (HZ / 5)
+
+/*
+ * beacon loss detection timeout
+ * XXX: should depend on beacon interval
+ */
+#define IEEE80211_BEACON_LOSS_TIME (2 * HZ)
+/*
+ * Time the connection can be idle before we probe
+ * it to see if we can still talk to the AP.
+ */
+#define IEEE80211_CONNECTION_IDLE_TIME (2 * HZ)
+/*
+ * Time we wait for a probe response after sending
+ * a probe request because of beacon loss or for
+ * checking the connection still works.
+ */
+#define IEEE80211_PROBE_WAIT (HZ / 5)
#define TMR_RUNNING_TIMER 0
#define TMR_RUNNING_CHANSW 1
@@ -666,7 +681,8 @@ void ieee80211_recalc_ps(struct ieee8021
if (count == 1 && found->u.mgd.powersave &&
found->u.mgd.associated && list_empty(&found->u.mgd.work_list) &&
- !(found->u.mgd.flags & IEEE80211_STA_PROBEREQ_POLL)) {
+ !(found->u.mgd.flags & (IEEE80211_STA_BEACON_POLL |
+ IEEE80211_STA_CONNECTION_POLL))) {
s32 beaconint_us;
if (latency < 0)
@@ -872,6 +888,10 @@ static void ieee80211_set_associated(str
sdata->u.mgd.associated = bss;
memcpy(sdata->u.mgd.bssid, bss->cbss.bssid, ETH_ALEN);
+ /* just to be sure */
+ sdata->u.mgd.flags &= ~(IEEE80211_STA_CONNECTION_POLL |
+ IEEE80211_STA_BEACON_POLL);
+
ieee80211_led_assoc(local, 1);
sdata->vif.bss_conf.assoc = 1;
@@ -983,16 +1003,21 @@ ieee80211_authenticate(struct ieee80211_
return RX_MGMT_NONE;
}
-static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata,
- const u8 *bssid, bool deauth)
+static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
struct ieee80211_local *local = sdata->local;
struct sta_info *sta;
u32 changed = 0, config_changed = 0;
+ u8 bssid[ETH_ALEN];
ASSERT_MGD_MTX(ifmgd);
+ if (WARN_ON(!ifmgd->associated))
+ return;
+
+ memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
+
ifmgd->associated = NULL;
memset(ifmgd->bssid, 0, ETH_ALEN);
@@ -1112,32 +1137,22 @@ void ieee80211_sta_rx_notify(struct ieee
* from AP because we know that the connection is working both ways
* at that time. But multicast frames (and hence also beacons) must
* be ignored here, because we need to trigger the timer during
- * data idle periods for sending the periodical probe request to
- * the AP.
+ * data idle periods for sending the periodic probe request to the
+ * AP we're connected to.
*/
- if (!is_multicast_ether_addr(hdr->addr1))
- mod_timer(&sdata->u.mgd.timer,
- jiffies + IEEE80211_MONITORING_INTERVAL);
+ if (is_multicast_ether_addr(hdr->addr1))
+ return;
+
+ mod_timer(&sdata->u.mgd.conn_mon_timer,
+ round_jiffies_up(jiffies + IEEE80211_CONNECTION_IDLE_TIME));
}
-void ieee80211_beacon_loss_work(struct work_struct *work)
+static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
+ bool beacon)
{
- struct ieee80211_sub_if_data *sdata =
- container_of(work, struct ieee80211_sub_if_data,
- u.mgd.beacon_loss_work);
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
const u8 *ssid;
-
- /*
- * The driver has already reported this event and we have
- * already sent a probe request. Maybe the AP died and the
- * driver keeps reporting until we disassociate... We have
- * to ignore that because otherwise we would continually
- * reset the timer and never check whether we received a
- * probe response!
- */
- if (ifmgd->flags & IEEE80211_STA_PROBEREQ_POLL)
- return;
+ bool already = false;
mutex_lock(&ifmgd->mtx);
@@ -1145,12 +1160,35 @@ void ieee80211_beacon_loss_work(struct w
goto out;
#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
- if (net_ratelimit())
- printk(KERN_DEBUG "%s: driver reports beacon loss from AP "
+ if (beacon && net_ratelimit())
+ printk(KERN_DEBUG "%s: detected beacon loss from AP "
"- sending probe request\n", sdata->dev->name);
#endif
- ifmgd->flags |= IEEE80211_STA_PROBEREQ_POLL;
+ /*
+ * The driver/our work has already reported this event or the
+ * connection monitoring has kicked in and we have already sent
+ * a probe request. Or maybe the AP died and the driver keeps
+ * reporting until we disassociate...
+ *
+ * In either case we have to ignore the current call to this
+ * function (except for setting the correct probe reason bit)
+ * because otherwise we would reset the timer every time and
+ * never check whether we received a probe response!
+ */
+ if (ifmgd->flags & (IEEE80211_STA_BEACON_POLL |
+ IEEE80211_STA_CONNECTION_POLL))
+ already = true;
+
+ if (beacon)
+ ifmgd->flags |= IEEE80211_STA_BEACON_POLL;
+ else
+ ifmgd->flags |= IEEE80211_STA_CONNECTION_POLL;
+
+ if (already)
+ goto out;
+
+ ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
mutex_lock(&sdata->local->iflist_mtx);
ieee80211_recalc_ps(sdata->local, -1);
@@ -1160,11 +1198,21 @@ void ieee80211_beacon_loss_work(struct w
ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
ssid + 2, ssid[1], NULL, 0);
- run_again(ifmgd, jiffies + IEEE80211_PROBE_WAIT);
+ run_again(ifmgd, ifmgd->probe_timeout);
+
out:
mutex_unlock(&ifmgd->mtx);
}
+void ieee80211_beacon_loss_work(struct work_struct *work)
+{
+ struct ieee80211_sub_if_data *sdata =
+ container_of(work, struct ieee80211_sub_if_data,
+ u.mgd.beacon_loss_work);
+
+ ieee80211_mgd_probe_ap(sdata, true);
+}
+
void ieee80211_beacon_loss(struct ieee80211_vif *vif)
{
struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
@@ -1278,7 +1326,7 @@ ieee80211_rx_mgmt_deauth(struct ieee8021
sdata->dev->name, bssid, reason_code);
if (!wk) {
- ieee80211_set_disassoc(sdata, bssid, true);
+ ieee80211_set_disassoc(sdata);
} else {
list_del(&wk->list);
kfree(wk);
@@ -1311,7 +1359,7 @@ ieee80211_rx_mgmt_disassoc(struct ieee80
printk(KERN_DEBUG "%s: disassociated (Reason: %u)\n",
sdata->dev->name, reason_code);
- ieee80211_set_disassoc(sdata, ifmgd->associated->cbss.bssid, false);
+ ieee80211_set_disassoc(sdata);
return RX_MGMT_CFG80211_DISASSOC;
}
@@ -1412,9 +1460,6 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee
return RX_MGMT_NONE;
}
- /* update new sta with its last rx activity */
- sta->last_rx = jiffies;
-
set_sta_flags(sta, WLAN_STA_AUTH | WLAN_STA_ASSOC |
WLAN_STA_ASSOC_AP);
if (!(ifmgd->flags & IEEE80211_STA_CONTROL_PORT))
@@ -1517,10 +1562,12 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee
ieee80211_set_associated(sdata, wk->bss, changed);
/*
- * initialise the time of last beacon to be the association time,
- * otherwise beacon loss check will trigger immediately
+ * Start timer to probe the connection to the AP now.
+ * Also start the timer that will detect beacon loss.
*/
- ifmgd->last_beacon = jiffies;
+ ieee80211_sta_rx_notify(sdata, (struct ieee80211_hdr *)mgmt);
+ mod_timer(&ifmgd->bcn_mon_timer,
+ round_jiffies_up(jiffies + IEEE80211_BEACON_LOSS_TIME));
list_del(&wk->list);
kfree(wk);
@@ -1604,11 +1651,24 @@ static void ieee80211_rx_mgmt_probe_resp
if (ifmgd->associated &&
memcmp(mgmt->bssid, ifmgd->associated->cbss.bssid, ETH_ALEN) == 0 &&
- ifmgd->flags & IEEE80211_STA_PROBEREQ_POLL) {
- ifmgd->flags &= ~IEEE80211_STA_PROBEREQ_POLL;
+ ifmgd->flags & (IEEE80211_STA_BEACON_POLL |
+ IEEE80211_STA_CONNECTION_POLL)) {
+ ifmgd->flags &= ~(IEEE80211_STA_CONNECTION_POLL |
+ IEEE80211_STA_BEACON_POLL);
mutex_lock(&sdata->local->iflist_mtx);
ieee80211_recalc_ps(sdata->local, -1);
mutex_unlock(&sdata->local->iflist_mtx);
+ /*
+ * We've received a probe response, but are not sure whether
+ * we have or will be receiving any beacons or data, so let's
+ * schedule the timers again, just in case.
+ */
+ mod_timer(&ifmgd->bcn_mon_timer,
+ round_jiffies_up(jiffies +
+ IEEE80211_BEACON_LOSS_TIME));
+ mod_timer(&ifmgd->conn_mon_timer,
+ round_jiffies_up(jiffies +
+ IEEE80211_CONNECTION_IDLE_TIME));
}
}
@@ -1658,27 +1718,42 @@ static void ieee80211_rx_mgmt_beacon(str
if (rx_status->freq != local->hw.conf.channel->center_freq)
return;
- if (WARN_ON(!ifmgd->associated))
+ /*
+ * We might have received a number of frames, among them a
+ * disassoc frame and a beacon...
+ */
+ if (!ifmgd->associated)
return;
bssid = ifmgd->associated->cbss.bssid;
- if (WARN_ON(memcmp(bssid, mgmt->bssid, ETH_ALEN) != 0))
+ /*
+ * And in theory even frames from a different AP we were just
+ * associated to a split-second ago!
+ */
+ if (memcmp(bssid, mgmt->bssid, ETH_ALEN) != 0)
return;
- if (ifmgd->flags & IEEE80211_STA_PROBEREQ_POLL) {
+ if (ifmgd->flags & IEEE80211_STA_BEACON_POLL) {
#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
if (net_ratelimit()) {
printk(KERN_DEBUG "%s: cancelling probereq poll due "
"to a received beacon\n", sdata->dev->name);
}
#endif
- ifmgd->flags &= ~IEEE80211_STA_PROBEREQ_POLL;
+ ifmgd->flags &= ~IEEE80211_STA_BEACON_POLL;
mutex_lock(&local->iflist_mtx);
ieee80211_recalc_ps(local, -1);
mutex_unlock(&local->iflist_mtx);
}
+ /*
+ * Push the beacon loss detection into the future since
+ * we are processing a beacon from the AP just now.
+ */
+ mod_timer(&ifmgd->bcn_mon_timer,
+ round_jiffies_up(jiffies + IEEE80211_BEACON_LOSS_TIME));
+
ncrc = crc32_be(0, (void *)&mgmt->u.beacon.beacon_int, 4);
ncrc = ieee802_11_parse_elems_crc(mgmt->u.beacon.variable,
len - baselen, &elems,
@@ -1980,6 +2055,37 @@ static void ieee80211_sta_work(struct wo
/* then process the rest of the work */
mutex_lock(&ifmgd->mtx);
+ if (ifmgd->flags & (IEEE80211_STA_BEACON_POLL |
+ IEEE80211_STA_CONNECTION_POLL) &&
+ ifmgd->associated) {
+ if (time_is_after_jiffies(ifmgd->probe_timeout))
+ run_again(ifmgd, ifmgd->probe_timeout);
+ else {
+ u8 bssid[ETH_ALEN];
+ /*
+ * We actually lost the connection ... or did we?
+ * Let's make sure!
+ */
+ ifmgd->flags &= ~(IEEE80211_STA_CONNECTION_POLL |
+ IEEE80211_STA_BEACON_POLL);
+ memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
+ ieee80211_set_disassoc(sdata);
+ printk(KERN_DEBUG "No probe response from AP %pM"
+ " after %dms, disconnecting.\n",
+ bssid, 1000 * (IEEE80211_PROBE_WAIT/HZ));
+ mutex_unlock(&ifmgd->mtx);
+ /*
+ * must be outside lock due to cfg80211,
+ * but that's not a problem.
+ */
+ ieee80211_send_deauth_disassoc(sdata, bssid,
+ IEEE80211_STYPE_DEAUTH,
+ WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY,
+ NULL);
+ mutex_lock(&ifmgd->mtx);
+ }
+ }
+
list_for_each_entry(wk, &ifmgd->work_list, list) {
if (wk->state != IEEE80211_MGD_STATE_IDLE) {
anybusy = true;
@@ -2067,15 +2173,51 @@ static void ieee80211_sta_work(struct wo
ieee80211_recalc_idle(local);
}
+static void ieee80211_sta_bcn_mon_timer(unsigned long data)
+{
+ struct ieee80211_sub_if_data *sdata =
+ (struct ieee80211_sub_if_data *) data;
+ struct ieee80211_local *local = sdata->local;
+
+ if (local->quiescing)
+ return;
+
+ queue_work(sdata->local->hw.workqueue,
+ &sdata->u.mgd.beacon_loss_work);
+}
+
+static void ieee80211_sta_conn_mon_timer(unsigned long data)
+{
+ struct ieee80211_sub_if_data *sdata =
+ (struct ieee80211_sub_if_data *) data;
+ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
+ struct ieee80211_local *local = sdata->local;
+
+ if (local->quiescing)
+ return;
+
+ queue_work(local->hw.workqueue, &ifmgd->monitor_work);
+}
+
+static void ieee80211_sta_monitor_work(struct work_struct *work)
+{
+ struct ieee80211_sub_if_data *sdata =
+ container_of(work, struct ieee80211_sub_if_data,
+ u.mgd.monitor_work);
+
+ ieee80211_mgd_probe_ap(sdata, false);
+}
+
static void ieee80211_restart_sta_timer(struct ieee80211_sub_if_data *sdata)
{
if (sdata->vif.type == NL80211_IFTYPE_STATION) {
- /*
- * Need to update last_beacon to avoid beacon loss
- * test to trigger.
- */
- sdata->u.mgd.last_beacon = jiffies;
+ sdata->u.mgd.flags &= ~(IEEE80211_STA_BEACON_POLL |
+ IEEE80211_STA_CONNECTION_POLL);
+ /* let's probe the connection once */
+ queue_work(sdata->local->hw.workqueue,
+ &sdata->u.mgd.monitor_work);
+ /* and do all the other regular work too */
queue_work(sdata->local->hw.workqueue,
&sdata->u.mgd.work);
}
@@ -2100,6 +2242,11 @@ void ieee80211_sta_quiesce(struct ieee80
cancel_work_sync(&ifmgd->chswitch_work);
if (del_timer_sync(&ifmgd->chswitch_timer))
set_bit(TMR_RUNNING_CHANSW, &ifmgd->timers_running);
+
+ cancel_work_sync(&ifmgd->monitor_work);
+ /* these will just be re-established on connection */
+ del_timer_sync(&ifmgd->conn_mon_timer);
+ del_timer_sync(&ifmgd->bcn_mon_timer);
}
void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata)
@@ -2120,10 +2267,15 @@ void ieee80211_sta_setup_sdata(struct ie
ifmgd = &sdata->u.mgd;
INIT_WORK(&ifmgd->work, ieee80211_sta_work);
+ INIT_WORK(&ifmgd->monitor_work, ieee80211_sta_monitor_work);
INIT_WORK(&ifmgd->chswitch_work, ieee80211_chswitch_work);
INIT_WORK(&ifmgd->beacon_loss_work, ieee80211_beacon_loss_work);
setup_timer(&ifmgd->timer, ieee80211_sta_timer,
(unsigned long) sdata);
+ setup_timer(&ifmgd->bcn_mon_timer, ieee80211_sta_bcn_mon_timer,
+ (unsigned long) sdata);
+ setup_timer(&ifmgd->conn_mon_timer, ieee80211_sta_conn_mon_timer,
+ (unsigned long) sdata);
setup_timer(&ifmgd->chswitch_timer, ieee80211_chswitch_timer,
(unsigned long) sdata);
skb_queue_head_init(&ifmgd->skb_queue);
@@ -2323,7 +2475,7 @@ int ieee80211_mgd_deauth(struct ieee8021
if (ifmgd->associated && &ifmgd->associated->cbss == req->bss) {
bssid = req->bss->bssid;
- ieee80211_set_disassoc(sdata, bssid, true);
+ ieee80211_set_disassoc(sdata);
} else list_for_each_entry(wk, &ifmgd->work_list, list) {
if (&wk->bss->cbss == req->bss) {
bssid = req->bss->bssid;
@@ -2365,7 +2517,7 @@ int ieee80211_mgd_disassoc(struct ieee80
return -ENOLINK;
}
- ieee80211_set_disassoc(sdata, req->bss->bssid, false);
+ ieee80211_set_disassoc(sdata);
mutex_unlock(&ifmgd->mtx);
--- wireless-testing.orig/net/mac80211/ieee80211_i.h 2009-07-09 22:06:30.000000000 +0200
+++ wireless-testing/net/mac80211/ieee80211_i.h 2009-07-09 22:14:41.000000000 +0200
@@ -256,12 +256,13 @@ struct ieee80211_mgd_work {
/* flags used in struct ieee80211_if_managed.flags */
enum ieee80211_sta_flags {
- IEEE80211_STA_PROBEREQ_POLL = BIT(3),
- IEEE80211_STA_CONTROL_PORT = BIT(4),
- IEEE80211_STA_WMM_ENABLED = BIT(5),
- IEEE80211_STA_DISABLE_11N = BIT(6),
- IEEE80211_STA_CSA_RECEIVED = BIT(7),
- IEEE80211_STA_MFP_ENABLED = BIT(8),
+ IEEE80211_STA_BEACON_POLL = BIT(0),
+ IEEE80211_STA_CONNECTION_POLL = BIT(1),
+ IEEE80211_STA_CONTROL_PORT = BIT(2),
+ IEEE80211_STA_WMM_ENABLED = BIT(3),
+ IEEE80211_STA_DISABLE_11N = BIT(4),
+ IEEE80211_STA_CSA_RECEIVED = BIT(5),
+ IEEE80211_STA_MFP_ENABLED = BIT(6),
};
/* flags for MLME request */
@@ -271,11 +272,16 @@ enum ieee80211_sta_request {
struct ieee80211_if_managed {
struct timer_list timer;
+ struct timer_list conn_mon_timer;
+ struct timer_list bcn_mon_timer;
struct timer_list chswitch_timer;
struct work_struct work;
+ struct work_struct monitor_work;
struct work_struct chswitch_work;
struct work_struct beacon_loss_work;
+ unsigned long probe_timeout;
+
struct mutex mtx;
struct ieee80211_bss *associated;
struct list_head work_list;
@@ -292,8 +298,6 @@ struct ieee80211_if_managed {
unsigned long request;
- unsigned long last_beacon;
-
unsigned int flags;
u32 beacon_crc;
--- wireless-testing.orig/net/mac80211/rx.c 2009-07-09 22:06:29.000000000 +0200
+++ wireless-testing/net/mac80211/rx.c 2009-07-09 22:14:41.000000000 +0200
@@ -833,28 +833,22 @@ ieee80211_rx_h_sta_process(struct ieee80
if (!sta)
return RX_CONTINUE;
- /* Update last_rx only for IBSS packets which are for the current
- * BSSID to avoid keeping the current IBSS network alive in cases where
- * other STAs are using different BSSID. */
+ /*
+ * Update last_rx only for IBSS packets which are for the current
+ * BSSID to avoid keeping the current IBSS network alive in cases
+ * where other STAs start using different BSSID.
+ */
if (rx->sdata->vif.type == NL80211_IFTYPE_ADHOC) {
u8 *bssid = ieee80211_get_bssid(hdr, rx->skb->len,
NL80211_IFTYPE_ADHOC);
if (compare_ether_addr(bssid, rx->sdata->u.ibss.bssid) == 0)
sta->last_rx = jiffies;
- } else
- if (!is_multicast_ether_addr(hdr->addr1) ||
- rx->sdata->vif.type == NL80211_IFTYPE_STATION) {
- /* Update last_rx only for unicast frames in order to prevent
- * the Probe Request frames (the only broadcast frames from a
- * STA in infrastructure mode) from keeping a connection alive.
+ } else if (!is_multicast_ether_addr(hdr->addr1)) {
+ /*
* Mesh beacons will update last_rx when if they are found to
* match the current local configuration when processed.
*/
- if (rx->sdata->vif.type == NL80211_IFTYPE_STATION &&
- ieee80211_is_beacon(hdr->frame_control)) {
- rx->sdata->u.mgd.last_beacon = jiffies;
- } else
- sta->last_rx = jiffies;
+ sta->last_rx = jiffies;
}
if (!(rx->flags & IEEE80211_RX_RA_MATCH))
^ permalink raw reply
* [PATCH] cfg80211: fix a locking bug
From: Johannes Berg @ 2009-07-10 0:45 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Jouni Malinen
The cfg80211_sme_disassoc() function is already holding
a lock here that cfg80211_mlme_deauth() would take, so
it needs to use __cfg80211_mlme_deauth() instead.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/sme.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- wireless-testing.orig/net/wireless/sme.c 2009-07-10 02:43:53.000000000 +0200
+++ wireless-testing/net/wireless/sme.c 2009-07-10 02:43:59.000000000 +0200
@@ -826,8 +826,8 @@ void cfg80211_sme_disassoc(struct net_de
return;
memcpy(bssid, wdev->auth_bsses[idx]->pub.bssid, ETH_ALEN);
- if (cfg80211_mlme_deauth(rdev, dev, bssid,
- NULL, 0, WLAN_REASON_DEAUTH_LEAVING)) {
+ if (__cfg80211_mlme_deauth(rdev, dev, bssid,
+ NULL, 0, WLAN_REASON_DEAUTH_LEAVING)) {
/* whatever -- assume gone anyway */
cfg80211_unhold_bss(wdev->auth_bsses[idx]);
cfg80211_put_bss(&wdev->auth_bsses[idx]->pub);
^ permalink raw reply
* [PATCH] mac80211: monitor the connection
From: Johannes Berg @ 2009-07-10 0:41 UTC (permalink / raw)
To: John Linville; +Cc: Kalle Valo, linux-wireless
With the recent MLME rework I accidentally removed the connection
monitoring code. In order to add it back, this patch will add new
code to monitor both for beacon loss and for the connection actually
working, with possibly separate triggers.
When no unicast frames have been received from the AP for (currently)
two seconds, we will send the AP a probe request. Also, when we don't
see beacons from the AP for two seconds, we do the same (but those
times need not be the same due to the way the code is now written).
Additionally, clean up the parameters to the ieee80211_set_disassoc()
function that I need here, those are all useless except sdata.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/ieee80211_i.h | 20 ++-
net/mac80211/mlme.c | 249 +++++++++++++++++++++++++++++++++++----------
net/mac80211/rx.c | 22 +--
3 files changed, 219 insertions(+), 72 deletions(-)
--- wireless-testing.orig/net/mac80211/mlme.c 2009-07-09 22:08:56.000000000 +0200
+++ wireless-testing/net/mac80211/mlme.c 2009-07-10 02:36:12.000000000 +0200
@@ -31,8 +31,23 @@
#define IEEE80211_AUTH_MAX_TRIES 3
#define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
#define IEEE80211_ASSOC_MAX_TRIES 3
-#define IEEE80211_MONITORING_INTERVAL (2 * HZ)
-#define IEEE80211_PROBE_WAIT (HZ / 5)
+
+/*
+ * beacon loss detection timeout
+ * XXX: should depend on beacon interval
+ */
+#define IEEE80211_BEACON_LOSS_TIME (2 * HZ)
+/*
+ * Time the connection can be idle before we probe
+ * it to see if we can still talk to the AP.
+ */
+#define IEEE80211_CONNECTION_IDLE_TIME (2 * HZ)
+/*
+ * Time we wait for a probe response after sending
+ * a probe request because of beacon loss or for
+ * checking the connection still works.
+ */
+#define IEEE80211_PROBE_WAIT (HZ / 5)
#define TMR_RUNNING_TIMER 0
#define TMR_RUNNING_CHANSW 1
@@ -666,7 +681,8 @@ void ieee80211_recalc_ps(struct ieee8021
if (count == 1 && found->u.mgd.powersave &&
found->u.mgd.associated && list_empty(&found->u.mgd.work_list) &&
- !(found->u.mgd.flags & IEEE80211_STA_PROBEREQ_POLL)) {
+ !(found->u.mgd.flags & (IEEE80211_STA_BEACON_POLL |
+ IEEE80211_STA_CONNECTION_POLL))) {
s32 beaconint_us;
if (latency < 0)
@@ -872,6 +888,10 @@ static void ieee80211_set_associated(str
sdata->u.mgd.associated = bss;
memcpy(sdata->u.mgd.bssid, bss->cbss.bssid, ETH_ALEN);
+ /* just to be sure */
+ sdata->u.mgd.flags &= ~(IEEE80211_STA_CONNECTION_POLL |
+ IEEE80211_STA_BEACON_POLL);
+
ieee80211_led_assoc(local, 1);
sdata->vif.bss_conf.assoc = 1;
@@ -983,16 +1003,21 @@ ieee80211_authenticate(struct ieee80211_
return RX_MGMT_NONE;
}
-static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata,
- const u8 *bssid, bool deauth)
+static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
struct ieee80211_local *local = sdata->local;
struct sta_info *sta;
u32 changed = 0, config_changed = 0;
+ u8 bssid[ETH_ALEN];
ASSERT_MGD_MTX(ifmgd);
+ if (WARN_ON(!ifmgd->associated))
+ return;
+
+ memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
+
ifmgd->associated = NULL;
memset(ifmgd->bssid, 0, ETH_ALEN);
@@ -1112,32 +1137,22 @@ void ieee80211_sta_rx_notify(struct ieee
* from AP because we know that the connection is working both ways
* at that time. But multicast frames (and hence also beacons) must
* be ignored here, because we need to trigger the timer during
- * data idle periods for sending the periodical probe request to
- * the AP.
+ * data idle periods for sending the periodic probe request to the
+ * AP we're connected to.
*/
- if (!is_multicast_ether_addr(hdr->addr1))
- mod_timer(&sdata->u.mgd.timer,
- jiffies + IEEE80211_MONITORING_INTERVAL);
+ if (is_multicast_ether_addr(hdr->addr1))
+ return;
+
+ mod_timer(&sdata->u.mgd.conn_mon_timer,
+ round_jiffies_up(jiffies + IEEE80211_CONNECTION_IDLE_TIME));
}
-void ieee80211_beacon_loss_work(struct work_struct *work)
+static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
+ bool beacon)
{
- struct ieee80211_sub_if_data *sdata =
- container_of(work, struct ieee80211_sub_if_data,
- u.mgd.beacon_loss_work);
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
const u8 *ssid;
-
- /*
- * The driver has already reported this event and we have
- * already sent a probe request. Maybe the AP died and the
- * driver keeps reporting until we disassociate... We have
- * to ignore that because otherwise we would continually
- * reset the timer and never check whether we received a
- * probe response!
- */
- if (ifmgd->flags & IEEE80211_STA_PROBEREQ_POLL)
- return;
+ bool already = false;
mutex_lock(&ifmgd->mtx);
@@ -1145,12 +1160,35 @@ void ieee80211_beacon_loss_work(struct w
goto out;
#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
- if (net_ratelimit())
- printk(KERN_DEBUG "%s: driver reports beacon loss from AP "
+ if (beacon && net_ratelimit())
+ printk(KERN_DEBUG "%s: detected beacon loss from AP "
"- sending probe request\n", sdata->dev->name);
#endif
- ifmgd->flags |= IEEE80211_STA_PROBEREQ_POLL;
+ /*
+ * The driver/our work has already reported this event or the
+ * connection monitoring has kicked in and we have already sent
+ * a probe request. Or maybe the AP died and the driver keeps
+ * reporting until we disassociate...
+ *
+ * In either case we have to ignore the current call to this
+ * function (except for setting the correct probe reason bit)
+ * because otherwise we would reset the timer every time and
+ * never check whether we received a probe response!
+ */
+ if (ifmgd->flags & (IEEE80211_STA_BEACON_POLL |
+ IEEE80211_STA_CONNECTION_POLL))
+ already = true;
+
+ if (beacon)
+ ifmgd->flags |= IEEE80211_STA_BEACON_POLL;
+ else
+ ifmgd->flags |= IEEE80211_STA_CONNECTION_POLL;
+
+ if (already)
+ goto out;
+
+ ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
mutex_lock(&sdata->local->iflist_mtx);
ieee80211_recalc_ps(sdata->local, -1);
@@ -1160,11 +1198,21 @@ void ieee80211_beacon_loss_work(struct w
ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
ssid + 2, ssid[1], NULL, 0);
- run_again(ifmgd, jiffies + IEEE80211_PROBE_WAIT);
+ run_again(ifmgd, ifmgd->probe_timeout);
+
out:
mutex_unlock(&ifmgd->mtx);
}
+void ieee80211_beacon_loss_work(struct work_struct *work)
+{
+ struct ieee80211_sub_if_data *sdata =
+ container_of(work, struct ieee80211_sub_if_data,
+ u.mgd.beacon_loss_work);
+
+ ieee80211_mgd_probe_ap(sdata, true);
+}
+
void ieee80211_beacon_loss(struct ieee80211_vif *vif)
{
struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
@@ -1278,7 +1326,7 @@ ieee80211_rx_mgmt_deauth(struct ieee8021
sdata->dev->name, bssid, reason_code);
if (!wk) {
- ieee80211_set_disassoc(sdata, bssid, true);
+ ieee80211_set_disassoc(sdata);
} else {
list_del(&wk->list);
kfree(wk);
@@ -1311,7 +1359,7 @@ ieee80211_rx_mgmt_disassoc(struct ieee80
printk(KERN_DEBUG "%s: disassociated (Reason: %u)\n",
sdata->dev->name, reason_code);
- ieee80211_set_disassoc(sdata, ifmgd->associated->cbss.bssid, false);
+ ieee80211_set_disassoc(sdata);
return RX_MGMT_CFG80211_DISASSOC;
}
@@ -1412,9 +1460,6 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee
return RX_MGMT_NONE;
}
- /* update new sta with its last rx activity */
- sta->last_rx = jiffies;
-
set_sta_flags(sta, WLAN_STA_AUTH | WLAN_STA_ASSOC |
WLAN_STA_ASSOC_AP);
if (!(ifmgd->flags & IEEE80211_STA_CONTROL_PORT))
@@ -1517,10 +1562,12 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee
ieee80211_set_associated(sdata, wk->bss, changed);
/*
- * initialise the time of last beacon to be the association time,
- * otherwise beacon loss check will trigger immediately
+ * Start timer to probe the connection to the AP now.
+ * Also start the timer that will detect beacon loss.
*/
- ifmgd->last_beacon = jiffies;
+ ieee80211_sta_rx_notify(sdata, (struct ieee80211_hdr *)mgmt);
+ mod_timer(&ifmgd->bcn_mon_timer,
+ round_jiffies_up(jiffies + IEEE80211_BEACON_LOSS_TIME));
list_del(&wk->list);
kfree(wk);
@@ -1604,11 +1651,24 @@ static void ieee80211_rx_mgmt_probe_resp
if (ifmgd->associated &&
memcmp(mgmt->bssid, ifmgd->associated->cbss.bssid, ETH_ALEN) == 0 &&
- ifmgd->flags & IEEE80211_STA_PROBEREQ_POLL) {
- ifmgd->flags &= ~IEEE80211_STA_PROBEREQ_POLL;
+ ifmgd->flags & (IEEE80211_STA_BEACON_POLL |
+ IEEE80211_STA_CONNECTION_POLL)) {
+ ifmgd->flags &= ~(IEEE80211_STA_CONNECTION_POLL |
+ IEEE80211_STA_BEACON_POLL);
mutex_lock(&sdata->local->iflist_mtx);
ieee80211_recalc_ps(sdata->local, -1);
mutex_unlock(&sdata->local->iflist_mtx);
+ /*
+ * We've received a probe response, but are not sure whether
+ * we have or will be receiving any beacons or data, so let's
+ * schedule the timers again, just in case.
+ */
+ mod_timer(&ifmgd->bcn_mon_timer,
+ round_jiffies_up(jiffies +
+ IEEE80211_BEACON_LOSS_TIME));
+ mod_timer(&ifmgd->conn_mon_timer,
+ round_jiffies_up(jiffies +
+ IEEE80211_CONNECTION_IDLE_TIME));
}
}
@@ -1658,27 +1718,42 @@ static void ieee80211_rx_mgmt_beacon(str
if (rx_status->freq != local->hw.conf.channel->center_freq)
return;
- if (WARN_ON(!ifmgd->associated))
+ /*
+ * We might have received a number of frames, among them a
+ * disassoc frame and a beacon...
+ */
+ if (!ifmgd->associated)
return;
bssid = ifmgd->associated->cbss.bssid;
- if (WARN_ON(memcmp(bssid, mgmt->bssid, ETH_ALEN) != 0))
+ /*
+ * And in theory even frames from a different AP we were just
+ * associated to a split-second ago!
+ */
+ if (memcmp(bssid, mgmt->bssid, ETH_ALEN) != 0)
return;
- if (ifmgd->flags & IEEE80211_STA_PROBEREQ_POLL) {
+ if (ifmgd->flags & IEEE80211_STA_BEACON_POLL) {
#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
if (net_ratelimit()) {
printk(KERN_DEBUG "%s: cancelling probereq poll due "
"to a received beacon\n", sdata->dev->name);
}
#endif
- ifmgd->flags &= ~IEEE80211_STA_PROBEREQ_POLL;
+ ifmgd->flags &= ~IEEE80211_STA_BEACON_POLL;
mutex_lock(&local->iflist_mtx);
ieee80211_recalc_ps(local, -1);
mutex_unlock(&local->iflist_mtx);
}
+ /*
+ * Push the beacon loss detection into the future since
+ * we are processing a beacon from the AP just now.
+ */
+ mod_timer(&ifmgd->bcn_mon_timer,
+ round_jiffies_up(jiffies + IEEE80211_BEACON_LOSS_TIME));
+
ncrc = crc32_be(0, (void *)&mgmt->u.beacon.beacon_int, 4);
ncrc = ieee802_11_parse_elems_crc(mgmt->u.beacon.variable,
len - baselen, &elems,
@@ -1980,6 +2055,34 @@ static void ieee80211_sta_work(struct wo
/* then process the rest of the work */
mutex_lock(&ifmgd->mtx);
+ if (ifmgd->flags & (IEEE80211_STA_BEACON_POLL |
+ IEEE80211_STA_CONNECTION_POLL) &&
+ ifmgd->associated) {
+ if (time_is_after_jiffies(ifmgd->probe_timeout))
+ run_again(ifmgd, ifmgd->probe_timeout);
+ else {
+ u8 bssid[ETH_ALEN];
+ /*
+ * We actually lost the connection ... or did we?
+ * Let's make sure!
+ */
+ ifmgd->flags &= ~(IEEE80211_STA_CONNECTION_POLL |
+ IEEE80211_STA_BEACON_POLL);
+ memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
+ ieee80211_set_disassoc(sdata);
+ mutex_unlock(&ifmgd->mtx);
+ /*
+ * must be outside lock due to cfg80211,
+ * but that's not a problem.
+ */
+ ieee80211_send_deauth_disassoc(sdata, bssid,
+ IEEE80211_STYPE_DEAUTH,
+ WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY,
+ NULL);
+ mutex_lock(&ifmgd->mtx);
+ }
+ }
+
list_for_each_entry(wk, &ifmgd->work_list, list) {
if (wk->state != IEEE80211_MGD_STATE_IDLE) {
anybusy = true;
@@ -2067,15 +2170,51 @@ static void ieee80211_sta_work(struct wo
ieee80211_recalc_idle(local);
}
+static void ieee80211_sta_bcn_mon_timer(unsigned long data)
+{
+ struct ieee80211_sub_if_data *sdata =
+ (struct ieee80211_sub_if_data *) data;
+ struct ieee80211_local *local = sdata->local;
+
+ if (local->quiescing)
+ return;
+
+ queue_work(sdata->local->hw.workqueue,
+ &sdata->u.mgd.beacon_loss_work);
+}
+
+static void ieee80211_sta_conn_mon_timer(unsigned long data)
+{
+ struct ieee80211_sub_if_data *sdata =
+ (struct ieee80211_sub_if_data *) data;
+ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
+ struct ieee80211_local *local = sdata->local;
+
+ if (local->quiescing)
+ return;
+
+ queue_work(local->hw.workqueue, &ifmgd->monitor_work);
+}
+
+static void ieee80211_sta_monitor_work(struct work_struct *work)
+{
+ struct ieee80211_sub_if_data *sdata =
+ container_of(work, struct ieee80211_sub_if_data,
+ u.mgd.monitor_work);
+
+ ieee80211_mgd_probe_ap(sdata, false);
+}
+
static void ieee80211_restart_sta_timer(struct ieee80211_sub_if_data *sdata)
{
if (sdata->vif.type == NL80211_IFTYPE_STATION) {
- /*
- * Need to update last_beacon to avoid beacon loss
- * test to trigger.
- */
- sdata->u.mgd.last_beacon = jiffies;
+ sdata->u.mgd.flags &= ~(IEEE80211_STA_BEACON_POLL |
+ IEEE80211_STA_CONNECTION_POLL);
+ /* let's probe the connection once */
+ queue_work(sdata->local->hw.workqueue,
+ &sdata->u.mgd.monitor_work);
+ /* and do all the other regular work too */
queue_work(sdata->local->hw.workqueue,
&sdata->u.mgd.work);
}
@@ -2100,6 +2239,11 @@ void ieee80211_sta_quiesce(struct ieee80
cancel_work_sync(&ifmgd->chswitch_work);
if (del_timer_sync(&ifmgd->chswitch_timer))
set_bit(TMR_RUNNING_CHANSW, &ifmgd->timers_running);
+
+ cancel_work_sync(&ifmgd->monitor_work);
+ /* these will just be re-established on connection */
+ del_timer_sync(&ifmgd->conn_mon_timer);
+ del_timer_sync(&ifmgd->bcn_mon_timer);
}
void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata)
@@ -2120,10 +2264,15 @@ void ieee80211_sta_setup_sdata(struct ie
ifmgd = &sdata->u.mgd;
INIT_WORK(&ifmgd->work, ieee80211_sta_work);
+ INIT_WORK(&ifmgd->monitor_work, ieee80211_sta_monitor_work);
INIT_WORK(&ifmgd->chswitch_work, ieee80211_chswitch_work);
INIT_WORK(&ifmgd->beacon_loss_work, ieee80211_beacon_loss_work);
setup_timer(&ifmgd->timer, ieee80211_sta_timer,
(unsigned long) sdata);
+ setup_timer(&ifmgd->bcn_mon_timer, ieee80211_sta_bcn_mon_timer,
+ (unsigned long) sdata);
+ setup_timer(&ifmgd->conn_mon_timer, ieee80211_sta_conn_mon_timer,
+ (unsigned long) sdata);
setup_timer(&ifmgd->chswitch_timer, ieee80211_chswitch_timer,
(unsigned long) sdata);
skb_queue_head_init(&ifmgd->skb_queue);
@@ -2323,7 +2472,7 @@ int ieee80211_mgd_deauth(struct ieee8021
if (ifmgd->associated && &ifmgd->associated->cbss == req->bss) {
bssid = req->bss->bssid;
- ieee80211_set_disassoc(sdata, bssid, true);
+ ieee80211_set_disassoc(sdata);
} else list_for_each_entry(wk, &ifmgd->work_list, list) {
if (&wk->bss->cbss == req->bss) {
bssid = req->bss->bssid;
@@ -2365,7 +2514,7 @@ int ieee80211_mgd_disassoc(struct ieee80
return -ENOLINK;
}
- ieee80211_set_disassoc(sdata, req->bss->bssid, false);
+ ieee80211_set_disassoc(sdata);
mutex_unlock(&ifmgd->mtx);
--- wireless-testing.orig/net/mac80211/ieee80211_i.h 2009-07-09 22:06:30.000000000 +0200
+++ wireless-testing/net/mac80211/ieee80211_i.h 2009-07-09 22:14:41.000000000 +0200
@@ -256,12 +256,13 @@ struct ieee80211_mgd_work {
/* flags used in struct ieee80211_if_managed.flags */
enum ieee80211_sta_flags {
- IEEE80211_STA_PROBEREQ_POLL = BIT(3),
- IEEE80211_STA_CONTROL_PORT = BIT(4),
- IEEE80211_STA_WMM_ENABLED = BIT(5),
- IEEE80211_STA_DISABLE_11N = BIT(6),
- IEEE80211_STA_CSA_RECEIVED = BIT(7),
- IEEE80211_STA_MFP_ENABLED = BIT(8),
+ IEEE80211_STA_BEACON_POLL = BIT(0),
+ IEEE80211_STA_CONNECTION_POLL = BIT(1),
+ IEEE80211_STA_CONTROL_PORT = BIT(2),
+ IEEE80211_STA_WMM_ENABLED = BIT(3),
+ IEEE80211_STA_DISABLE_11N = BIT(4),
+ IEEE80211_STA_CSA_RECEIVED = BIT(5),
+ IEEE80211_STA_MFP_ENABLED = BIT(6),
};
/* flags for MLME request */
@@ -271,11 +272,16 @@ enum ieee80211_sta_request {
struct ieee80211_if_managed {
struct timer_list timer;
+ struct timer_list conn_mon_timer;
+ struct timer_list bcn_mon_timer;
struct timer_list chswitch_timer;
struct work_struct work;
+ struct work_struct monitor_work;
struct work_struct chswitch_work;
struct work_struct beacon_loss_work;
+ unsigned long probe_timeout;
+
struct mutex mtx;
struct ieee80211_bss *associated;
struct list_head work_list;
@@ -292,8 +298,6 @@ struct ieee80211_if_managed {
unsigned long request;
- unsigned long last_beacon;
-
unsigned int flags;
u32 beacon_crc;
--- wireless-testing.orig/net/mac80211/rx.c 2009-07-09 22:06:29.000000000 +0200
+++ wireless-testing/net/mac80211/rx.c 2009-07-09 22:14:41.000000000 +0200
@@ -833,28 +833,22 @@ ieee80211_rx_h_sta_process(struct ieee80
if (!sta)
return RX_CONTINUE;
- /* Update last_rx only for IBSS packets which are for the current
- * BSSID to avoid keeping the current IBSS network alive in cases where
- * other STAs are using different BSSID. */
+ /*
+ * Update last_rx only for IBSS packets which are for the current
+ * BSSID to avoid keeping the current IBSS network alive in cases
+ * where other STAs start using different BSSID.
+ */
if (rx->sdata->vif.type == NL80211_IFTYPE_ADHOC) {
u8 *bssid = ieee80211_get_bssid(hdr, rx->skb->len,
NL80211_IFTYPE_ADHOC);
if (compare_ether_addr(bssid, rx->sdata->u.ibss.bssid) == 0)
sta->last_rx = jiffies;
- } else
- if (!is_multicast_ether_addr(hdr->addr1) ||
- rx->sdata->vif.type == NL80211_IFTYPE_STATION) {
- /* Update last_rx only for unicast frames in order to prevent
- * the Probe Request frames (the only broadcast frames from a
- * STA in infrastructure mode) from keeping a connection alive.
+ } else if (!is_multicast_ether_addr(hdr->addr1)) {
+ /*
* Mesh beacons will update last_rx when if they are found to
* match the current local configuration when processed.
*/
- if (rx->sdata->vif.type == NL80211_IFTYPE_STATION &&
- ieee80211_is_beacon(hdr->frame_control)) {
- rx->sdata->u.mgd.last_beacon = jiffies;
- } else
- sta->last_rx = jiffies;
+ sta->last_rx = jiffies;
}
if (!(rx->flags & IEEE80211_RX_RA_MATCH))
^ permalink raw reply
* [PATCH] mac80211: fix multi-use timer
From: Johannes Berg @ 2009-07-10 0:39 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
We have, sometimes, multiple things that want to
run but don't have their own timer. Introduce a
new function to mac80211's mlme run_again() that
makes sure that the timer will run again at the
_first_ needed time, use that function and also
properly reprogram the timer once it fired.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/mlme.c | 40 +++++++++++++++++++++++++++++++++-------
1 file changed, 33 insertions(+), 7 deletions(-)
--- wireless-testing.orig/net/mac80211/mlme.c 2009-07-09 17:04:43.000000000 +0200
+++ wireless-testing/net/mac80211/mlme.c 2009-07-09 22:08:56.000000000 +0200
@@ -72,6 +72,26 @@ static inline void ASSERT_MGD_MTX(struct
WARN_ON(!mutex_is_locked(&ifmgd->mtx));
}
+/*
+ * We can have multiple work items (and connection probing)
+ * scheduling this timer, but we need to take care to only
+ * reschedule it when it should fire _earlier_ than it was
+ * asked for before, or if it's not pending right now. This
+ * function ensures that. Note that it then is required to
+ * run this function for all timeouts after the first one
+ * has happened -- the work that runs from this timer will
+ * do that.
+ */
+static void run_again(struct ieee80211_if_managed *ifmgd,
+ unsigned long timeout)
+{
+ ASSERT_MGD_MTX(ifmgd);
+
+ if (!timer_pending(&ifmgd->timer) ||
+ time_before(timeout, ifmgd->timer.expires))
+ mod_timer(&ifmgd->timer, timeout);
+}
+
static int ecw2cw(int ecw)
{
return (1 << ecw) - 1;
@@ -916,7 +936,7 @@ ieee80211_direct_probe(struct ieee80211_
ieee80211_send_probe_req(sdata, NULL, wk->ssid, wk->ssid_len, NULL, 0);
wk->timeout = jiffies + IEEE80211_AUTH_TIMEOUT;
- mod_timer(&ifmgd->timer, wk->timeout);
+ run_again(ifmgd, wk->timeout);
return RX_MGMT_NONE;
}
@@ -958,7 +978,7 @@ ieee80211_authenticate(struct ieee80211_
wk->auth_transaction = 2;
wk->timeout = jiffies + IEEE80211_AUTH_TIMEOUT;
- mod_timer(&ifmgd->timer, wk->timeout);
+ run_again(ifmgd, wk->timeout);
return RX_MGMT_NONE;
}
@@ -1079,7 +1099,7 @@ ieee80211_associate(struct ieee80211_sub
ieee80211_send_assoc(sdata, wk);
wk->timeout = jiffies + IEEE80211_ASSOC_TIMEOUT;
- mod_timer(&ifmgd->timer, wk->timeout);
+ run_again(ifmgd, wk->timeout);
return RX_MGMT_NONE;
}
@@ -1140,7 +1160,7 @@ void ieee80211_beacon_loss_work(struct w
ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
ssid + 2, ssid[1], NULL, 0);
- mod_timer(&ifmgd->timer, jiffies + IEEE80211_PROBE_WAIT);
+ run_again(ifmgd, jiffies + IEEE80211_PROBE_WAIT);
out:
mutex_unlock(&ifmgd->mtx);
}
@@ -1350,8 +1370,7 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee
sdata->dev->name, tu, ms);
wk->timeout = jiffies + msecs_to_jiffies(ms);
if (ms > IEEE80211_ASSOC_TIMEOUT)
- mod_timer(&ifmgd->timer,
- jiffies + msecs_to_jiffies(ms));
+ run_again(ifmgd, jiffies + msecs_to_jiffies(ms));
return RX_MGMT_NONE;
}
@@ -1981,8 +2000,15 @@ static void ieee80211_sta_work(struct wo
}
list_for_each_entry_safe(wk, tmp, &ifmgd->work_list, list) {
- if (time_before(jiffies, wk->timeout))
+ if (time_is_after_jiffies(wk->timeout)) {
+ /*
+ * This work item isn't supposed to be worked on
+ * right now, but take care to adjust the timer
+ * properly.
+ */
+ run_again(ifmgd, wk->timeout);
continue;
+ }
switch (wk->state) {
default:
^ permalink raw reply
* Re: [ipw3945-devel] iwlwifi 4965 uCode available
From: reinette chatre @ 2009-07-09 23:26 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <b170af450907091613l1607f664he482e13e6fe268bd@mail.gmail.com>
On Thu, 2009-07-09 at 16:13 -0700, Rafał Miłecki wrote:
> 2009/7/9 reinette chatre <reinette.chatre@intel.com>:
> > Version 228.61.2.24 of uCode for Intel Wireless WiFi Link 4965AGN is now
> > available for download from
> > http://intellinuxwireless.org/?n=Downloads
> >
> > Changes:
> >
> > -- More graceful handling of Rx hangs (NMI)
> > -- More reliable scanning
> > -- Wait 10 seconds after association before power down
> > -- Reset receiver via retune after missing beacons
> > -- Disable TGK measurement when receiving packet
> > -- More reliable Tx of ACK/BA/CTS
>
> Nice work, AFAICU this should fix a few annoying issues, right?
We hope so.
> Can you reveal some plans of upgrading 5100/5300/5350 uCode? Any
> estimate would be nice to known. This month? This year?
I am not aware of any scheduled date for a new release. Are there
critical issues that you are aware of that requires a new uCode?
Reinette
^ permalink raw reply
* Re: [ipw3945-devel] iwlwifi 4965 uCode available
From: Rafał Miłecki @ 2009-07-09 23:13 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless, ipw3945-devel
In-Reply-To: <1247174482.17896.1304.camel@rc-desk>
2009/7/9 reinette chatre <reinette.chatre@intel.com>:
> Version 228.61.2.24 of uCode for Intel Wireless WiFi Link 4965AGN is now
> available for download from
> http://intellinuxwireless.org/?n=Downloads
>
> Changes:
>
> -- More graceful handling of Rx hangs (NMI)
> -- More reliable scanning
> -- Wait 10 seconds after association before power down
> -- Reset receiver via retune after missing beacons
> -- Disable TGK measurement when receiving packet
> -- More reliable Tx of ACK/BA/CTS
Nice work, AFAICU this should fix a few annoying issues, right?
Can you reveal some plans of upgrading 5100/5300/5350 uCode? Any
estimate would be nice to known. This month? This year?
--
Rafał Miłecki
^ permalink raw reply
* [PATCH v2] Assign next hop address to pending mesh frames once the path is resolved.
From: Javier Cardona @ 2009-07-09 21:42 UTC (permalink / raw)
To: linux-wireless; +Cc: Javier Cardona, Andrey Yurovsky, johannes, linville, devel
In-Reply-To: <1247049613.4755.65.camel@johannes.local>
Regression. Frames transmitted when a mesh path was wating to be resolved were
being transmitted with an invalid Receiver Address.
[Changes since v1]
Suggested by Johannes:
- Improved frame_queue traversal
- Narower RCU scope
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
---
net/mac80211/mesh_pathtbl.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index ae98766..1981af9 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -55,7 +55,25 @@ static DEFINE_RWLOCK(pathtbl_resize_lock);
*/
void mesh_path_assign_nexthop(struct mesh_path *mpath, struct sta_info *sta)
{
+ struct sk_buff *skb;
+ struct ieee80211_hdr *hdr;
+ struct sk_buff_head tmpq;
+ unsigned long flags;
+
rcu_assign_pointer(mpath->next_hop, sta);
+
+ __skb_queue_head_init(&tmpq);
+
+ spin_lock_irqsave(&mpath->frame_queue.lock, flags);
+
+ while ((skb = __skb_dequeue(&mpath->frame_queue)) != NULL) {
+ hdr = (struct ieee80211_hdr *) skb->data;
+ memcpy(hdr->addr1, sta->sta.addr, ETH_ALEN);
+ __skb_queue_tail(&tmpq, skb);
+ }
+
+ skb_queue_splice(&tmpq, &mpath->frame_queue);
+ spin_unlock_irqrestore(&mpath->frame_queue.lock, flags);
}
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH v2] Assign next hop address to pending mesh frames once the path is resolved.
From: Johannes Berg @ 2009-07-09 21:54 UTC (permalink / raw)
To: Javier Cardona; +Cc: linux-wireless, Andrey Yurovsky, linville
In-Reply-To: <1247175736-6915-1-git-send-email-javier@cozybit.com>
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]
On Thu, 2009-07-09 at 14:42 -0700, Javier Cardona wrote:
> Regression. Frames transmitted when a mesh path was wating to be resolved were
> being transmitted with an invalid Receiver Address.
>
> [Changes since v1]
>
> Suggested by Johannes:
> - Improved frame_queue traversal
> - Narower RCU scope
>
> Signed-off-by: Javier Cardona <javier@cozybit.com>
> Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> net/mac80211/mesh_pathtbl.c | 18 ++++++++++++++++++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
> index ae98766..1981af9 100644
> --- a/net/mac80211/mesh_pathtbl.c
> +++ b/net/mac80211/mesh_pathtbl.c
> @@ -55,7 +55,25 @@ static DEFINE_RWLOCK(pathtbl_resize_lock);
> */
> void mesh_path_assign_nexthop(struct mesh_path *mpath, struct sta_info *sta)
> {
> + struct sk_buff *skb;
> + struct ieee80211_hdr *hdr;
> + struct sk_buff_head tmpq;
> + unsigned long flags;
> +
> rcu_assign_pointer(mpath->next_hop, sta);
> +
> + __skb_queue_head_init(&tmpq);
> +
> + spin_lock_irqsave(&mpath->frame_queue.lock, flags);
> +
> + while ((skb = __skb_dequeue(&mpath->frame_queue)) != NULL) {
> + hdr = (struct ieee80211_hdr *) skb->data;
> + memcpy(hdr->addr1, sta->sta.addr, ETH_ALEN);
> + __skb_queue_tail(&tmpq, skb);
> + }
> +
> + skb_queue_splice(&tmpq, &mpath->frame_queue);
> + spin_unlock_irqrestore(&mpath->frame_queue.lock, flags);
> }
>
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Problem with p54 driver and ibss mode
From: Johannes Berg @ 2009-07-09 21:48 UTC (permalink / raw)
To: Max Filippov
Cc: Kalle Valo, Christian Lamparter, Alexander Wenzel, linux-wireless
In-Reply-To: <200907100143.29004.jcmvbkbc@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]
On Fri, 2009-07-10 at 01:43 +0400, Max Filippov wrote:
> В сообщении от Thursday 09 July 2009 Kalle Valo написал(a):
> > Christian Lamparter <chunkeey@web.de> writes:
> >
> > >> These data for sure must reside on /dev/mtdblk1 partition, but
> > >> they're probably somehow coded/obfuscated. I couldn't find anything
> > >> similar to MAC of my own n810 there.
> > >
> > > well, this is c0ffee comes from nokia's stlc45xx-driver.
> > > Unfortunately, they don't say how to get the device eeprom from the
> > > mtdblk1 partition. However, they certainly provide a tool stlc45xx-cal
> > > (available at: http://stlc45xx.garage.maemo.org/ ) which can be used
> > > to locate the eeprom's calibration data.
> >
> > stlc45xx-cal pushes the device specific calibration data and sets the
> > MAC address. It's recommended to run it to get optimal performance.
> >
> IIRC stlc45xx-cal pushes these data into sysfs entries, which stlc45xx used to create.
> There's no such interface in p54spi.
Should be easy to copy the code into p54spi, we just never did, hoping
Kalle would come up with a better way, maybe request_firmware() :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Problem with p54 driver and ibss mode
From: Max Filippov @ 2009-07-09 21:43 UTC (permalink / raw)
To: Kalle Valo; +Cc: Christian Lamparter, Alexander Wenzel, linux-wireless
In-Reply-To: <87vdm1pr5m.fsf@litku.valot.fi>
В сообщении от Thursday 09 July 2009 Kalle Valo написал(a):
> Christian Lamparter <chunkeey@web.de> writes:
>
> >> These data for sure must reside on /dev/mtdblk1 partition, but
> >> they're probably somehow coded/obfuscated. I couldn't find anything
> >> similar to MAC of my own n810 there.
> >
> > well, this is c0ffee comes from nokia's stlc45xx-driver.
> > Unfortunately, they don't say how to get the device eeprom from the
> > mtdblk1 partition. However, they certainly provide a tool stlc45xx-cal
> > (available at: http://stlc45xx.garage.maemo.org/ ) which can be used
> > to locate the eeprom's calibration data.
>
> stlc45xx-cal pushes the device specific calibration data and sets the
> MAC address. It's recommended to run it to get optimal performance.
>
IIRC stlc45xx-cal pushes these data into sysfs entries, which stlc45xx used to create.
There's no such interface in p54spi.
Thanks.
-- Max
^ permalink raw reply
* iwlwifi 4965 uCode available
From: reinette chatre @ 2009-07-09 21:21 UTC (permalink / raw)
To: linux-wireless, ipw3945-devel
Version 228.61.2.24 of uCode for Intel Wireless WiFi Link 4965AGN is now
available for download from
http://intellinuxwireless.org/?n=Downloads
Changes:
-- More graceful handling of Rx hangs (NMI)
-- More reliable scanning
-- Wait 10 seconds after association before power down
-- Reset receiver via retune after missing beacons
-- Disable TGK measurement when receiving packet
-- More reliable Tx of ACK/BA/CTS
Reinette
^ 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