On Mon, 2009-09-21 at 09:46 +0200, Holger Schurig wrote: > > It's not actually the same, and you didn't explain that well. > > You care about the disappear case, but you made it sound like > > you cared about the _reappear_ case. > > Okay, sorry. I thought you read my other mails about > scan-life-time and that thus the context was/is clear. > > > The base issue is: SCAN_TRIGGER does normally not a "clean scan", > it normally adds entries to the BSS list or updates existing > ones. > > Entries in the BSS list are only deleted after 15 seconds. So on the supplicant side, this weekend I was discussing with Jouni about making the supplicant *not* trigger a completely new scan when trying to associate if the scan list was current in the past 5 or 10 seconds. The issue here is that NM requests a scan, figures out what AP to start using, then tells the supplicant to associate with it. Then the supplicant throws away any scan results it has an does a full *new* scan before associating. That adds about 5 seconds to each NM connection attempt that I'd like to get rid of. Would that interfere with your forklift case? BTW, 10 years ago I did a forklift deployment too with pre-802.11 Aironet equipment and Netware. Wasn't that fun to get up and running. This was at a paper company too, and guess what huge rolls of paper do? They absorb radio waves quite well. Suck. And forklifts can go *fast*. Dan > > > However, in 15 seconds you can easily leave the range of AP_OLD > and be in the range of a completely AP_NEW. But it can also be > the case that the (now stale!) signal of AP_OLD is higher than > the (real) signal of AP_NEW. In this case wpa_supplicant tries > to associate to AP_OLD, which is out-of-sight. And that takes > unneeded time. > > > I simple tried to mimick this scenario in the office, by > switching off an AP (just that I didn't really switch it off, > because the boot-times of Cisco-APs are soooooooo sloooooow). > > About your "It's not actually the same": I think that my > laboratory experiment very well shows this behavior, e.g. see my > 2nd message with subject "Life-time of scan-results?": > > 1253275108.958746: Trying to authenticate with 00:13:19:80:da:30 > (SSID='MNHS' freq=2412 MHz) > > Bit this is the "vanished" AP_OLD. With wireshark on a second > WLAN card I saw the attemps of mac80211 to associate to this > now-out-of-sight AP. This takes some tries from mac80211, then a > timeout on wpa_supplicant, than a new scan, then a new attempt. > All of those delays completely unnecessary if there would have > been a way to not get stale data via SCAN_DUMP. > > > > So, clearly I have a visible problem and need to fix that. > > I could fix that by making SCAN_TRIGGER always delete all stale > (cached) entries. Then I wouldn't need NL80211_ATTR_SCAN_EXPIRE. > > However, a scan because "I want to look what is around" might be > different to a scan because "I need fresh data of APs around for > associating". And so I thought I make that configurable. > > > I hope this now makes more sense. > -- > 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 -- 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
