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.
> In any case, the problem then is that last_update is updated only along
> with the remaining information in a BSS struct, which is quite correct.
> The question, however, is: why are beacons not allowed to override probe
> response information? That is, why does this piece of code exist:
>
> if (sdata->vif.type != IEEE80211_IF_TYPE_IBSS &&
> bss->probe_resp && beacon) {
> /* STA mode:
> * Do not allow beacon to override data from Probe Response. */
> ieee80211_rx_bss_put(dev, bss);
> return;
> }
Should we consider allowing the beacon to update the info if
last_update is old enough to keep the BSS out of the scan results?
John
--
John W. Linville
linville@xxxxxxxxxxxxx
--
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
