On Tue, Nov 4, 2008 at 10:19 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Sun, Nov 02, 2008 at 01:05:56PM -0800, Luis R. Rodriguez wrote: >> I'm curious if others are getting this frequently as I am: >> >> No ProbeResp from current AP 00:DE:AD:BE:EE:FF - assume out of range >> >> I get this with ath5k and ath9k, can be triggered easily in ath5k by >> doing a lot of consecutive: >> >> iwlist wlan0 scan >> >> I have to check if I can trigger this with ath9k by scanning too. We >> were seeing this with ath9k but were thinking it was ath9k related as >> it can be triggered on it after doing a large TX. Wondering if this is >> more of a generic and mac80211 issue. > > I'm seeing this all the time with ath9k. For now I'm running with the > following local hack: > > Index: linux-2.6/net/mac80211/mlme.c > =================================================================== > --- linux-2.6.orig/net/mac80211/mlme.c 2008-11-04 18:10:41.000000000 +0100 > +++ linux-2.6/net/mac80211/mlme.c 2008-11-04 18:10:56.000000000 +0100 > @@ -972,7 +972,7 @@ static void ieee80211_associated(struct > "current AP %s - assume out of " > "range\n", > sdata->dev->name, print_mac(mac, ifsta->bssid)); > - disassoc = 1; > +// disassoc = 1; > } else > ieee80211_send_probe_req(sdata, ifsta->bssid, > ifsta->ssid, > > which makes the problem of an actual disassociation after this message > go away which made wireless completely unuseable with -rc3 for. Given > that the message never appears a second time just increasing the time > it appears that just increasing IEEE80211_MONITORING_INTERVAL should > fix the problem, too. I posted a patch which enables beacons to be received by the STA -- this however, as was pointed out by the patch that disabled the beacon filter on ath5k (note not ath9k, but ath9k also had it disabled), increases the number of interrupts on the device, as it seems it enables beacons not only for the BSSID you are on but for all BSSIDs. Not sure what other devices support and how their beacon filter, if they have any, works. The patch I posted is a fix that works with what mac80211 expects -- beacons. The way I'm inclined to resolve this properly in mac80211 is so that we tell drivers to enable beacons in STA mode (if it supports this, HW_CAP flag I guess) only after we miss a probe reply, or while we are scanning, that way we can also listen for beacons in case we want to roam away to another AP. Just throwing some ideas out there. Any comments? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
