On Sun, Nov 2, 2008 at 2:42 PM, Tomas Winkler <tomasw@xxxxxxxxx> wrote: > On Mon, Nov 3, 2008 at 12:03 AM, Michael Buesch <mb@xxxxxxxxx> wrote: >> On Sunday 02 November 2008 22:05:56 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. >> >> IMO this is a mac80211 issue. >> mac80211 immediately assumes the connection is broken, if one probe-resp >> to a keekalife-proberequest is lost. >> So if you scan just after the request got sent, you'll never receive the response >> and mac80211 will terminate the connection. >> It should try a few times, instead, before blowing up things. > > I've seen this happening in high traffic with some APs but it can be > also NIC issue. It needs to really investigate the sniffer capture I > wouldn't assume its only mac80211 issue. Probe is issued only when RX > is not received for some time so there is some problem, nevertheless > monitoring beacons is a better approach from my experience. Agreed if it can be NIC issue, but it seems to be a common issue now across a few drivers, not just ath5k/ath9k. Hm, ieee80211_rx_mgmt_beacon() is not being hit with ath5k, something is fishy. 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
