#848: Beacon misses cause client to reassociate
----------------------------------------+-----------------------------------
Reporter: [EMAIL PROTECTED] | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: madwifi: 802.11 stack | Version:
Resolution: | Keywords:
Patch_attached: 0 |
----------------------------------------+-----------------------------------
Comment (by [EMAIL PROTECTED]):
Beacon disconnects have been problematic for us ( Pepper ) too. We're
currently running MADWiFi 0.9.1 on the Pepper Pad 3 with a bunch of
patches.
We're using wpa_supplicant (v0.4.7) which puts the driver into manual
roaming mode. When a beacon disconnect is processed in manual roaming
mode, the driver is put into ''SCAN'' state, which causes a disconnect.
We then have to direct wpa_supplicant to re-associate. In auto-roaming
mode ( the default mode ), the driver re-associates directly. See
''ieee80211_beacon_miss()'' in ieee80211_proto.c.
There are two seemingly redundant sources of calls to
''ieee80211_beacon_miss()''. The first is a software timer in the
net80211 layer. Look for code that references ''vap->iv_swbmiss''. The
second source is the HAL itself. The '''ath_pci''' module configures the
beacon miss interrupts based upon values received ( eg. beacon interval,
dtim period ) in beacon frames. The code clamps the beacon miss threshold
to a value between 1 and 10!!! Way too low in my opinion.
We're running with two patches to the beacon miss code:
1. I removed the code that initializes the software beacon miss timer.
2. I modified the '''ath_pci''' module to take two parameters,
''bmiss_thresh'' and ''beacon_sleep''. These are used to override the
similarly named fields passed to the HAL via the
''ath_hal_beacontimers()'' call. We're currently running with the beacon
miss threashold set to 150. That seems to make us pretty immune to beacon
disconnects, however it's still not perfect.
If there's interest, I can post our patch for (2).
Disabling beacon interrupts altogether isn't a good idea ( we tried it )
since signal quality is calculated from incoming beacons when there's no
data traffic. Signal quality drops continually until the point at which
no more beacons are being received, at this point it stays at the
last/lowest calculated signal quality... ( ie. 4 or 5 ). Our system has a
signal quality process that monitors signal strength and will cause a
disconnect to happen if the signal quality drops to 0 and stays there for
a certain time period. So, it's a catch-22. Disabling beacon miss
interrupts gets rid of the disconnects/re-associations, however it
prevents the signal strength from ever reaching 0.
One other thought... in conjunction with the bmiss_thresh patch, I may
try to modify the ''beacon_miss()'' function to cause a reassociation just
like when in auto-roaming mode.
--
Ticket URL: <http://madwifi.org/ticket/848>
MadWifi <http://madwifi.org/>
Multiband Atheros Driver for Wireless Fidelity
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Madwifi-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/madwifi-tickets
