> My HW I'm working on doesn't really behave, and it can't tx anything > unless it is associated to an AP. So, it can't send probe requests, just > listen to beacons initially. Except for worse scan results, not really > an issue. > > Now, since sta_bss_list is never cleaned up, once I do a proper active scan, > entries for BSSes found will get bss->probe_resp flag set. If I bring the > interface down and back up (ie, can't send out probe request once again), > I'm not able to scan (or join) any of those networks, since we prefer > stored probe response info to that of beacons (ieee80211_rx_bss_info; > bss->last_update won't be updated on beacon either). And finally, > ieee80211_sta_scan_result will skip expired BSSes, so even it can receive > beacons for such networks, they won't be reported back to the user. Bit odd, it seems that at least the probe_resp flags should all be cleared as soon as we disassociate or so. Not really sure though. > So, my question is whether this is being worked on (didn't find any note > on this), and if not, what would be the best place to put this to? (I'm not > that familiar with mac80211 internals, so any input on this is kindly > welcome). I'm not aware of anybody working on this. It seems that some expiry code, if added, should live in ieee80211_sta.c. > In my case, clearing the list on ifdown/up would help, but periodic > cleanup would be better, so I'd better go that way (or maybe both). It seems things should at least be expired from that list since we don't export the info to userspace after IEEE80211_SCAN_RESULT_EXPIRE jiffies, and imho then shouldn't use it any more either. Dan? > Then, having bss->last_update being updated also by beacons might be a > good idea, otherwise we would expire probed networks, right? I think the issue with proberesp vs. beacons is about more than this, but it seems that indeed we should keep an entry alive if we get beacons for it. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
