John W. Linville wrote: > On Sun, Mar 30, 2008 at 10:33:19AM +0200, Johannes Berg wrote: > >> The first one is that there is no actual expiration of BSS structs. Each >> BSS struct has a 'last_update' member that contains (in jiffies) the >> time this item was last updated. This means that we accumulate BSS >> information forever, but due to the 'last_update' only the last few >> items will be returned to the user on asking for a scan result. This >> obviously has problems since a rogue station could bombard us with fake >> probe responses and cause us to build a huge BSS list which is never >> again freed until the hardware is deregistered. This will need to be >> fixed, of course. > > Assuming this was fixed, does the rest of this issue go away? > It seems like it would. I can just add another bug this is causing, this time for IBSS. The scenario: - you happen to have 2 IBSS entries for the same SSID/different BSSID (both of them inactive at this time; this can happen e.g. with IBSS merge), - you start new IBSS with the same SSID, - there is no other IBSS station with this SSID around. In this case, the stack will end up using those 2 BSSIDs alternately, in 30sec intervals. The reason is that since there is no other active IBSS STA, it will look at its BSS list and adopts the BSSID (and other params) of first matching IBSS that is different to current one (or triggers a new scan, which will never happen in this scenario; see ieee80211_sta_find_ibss). This seems to be fine when BSS list expiration is fixed, though (with timeout of less than 30s (IEEE80211_IBSS_MERGE_INTERVAL)). Vlado
Attachment:
signature.asc
Description: OpenPGP digital signature
