On Sun, 30 Mar 2008 10:33:19 +0200, Johannes Berg wrote:
> 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;
> }
>
> I failed to find any explanation for it in the git archive (it was part
> of the first code drop from Jiri that made it into a wireless tree and I
> don't have any older git archives handy) nor in my email though I
> vaguely remember there was a reason for it (or I may have made it up).
It was already in the initial Devicescape release:
1478 if (bss->probe_resp && beacon) {
1479 /* Do not allow beacon to override data from Probe Response. */
1480 ieee80211_rx_bss_put(dev, bss);
1481 return;
1482 }
The only reason I can think of is handling of hidden SSIDs. Seems it
was necessary at that time. I'd vote for removing it.
> However, that actually seems to have another bug, if you have such an AP
> will you find two BSSes, one with a hidden and one with a visible SSID?
That's what I would consider a correct behaviour. You in fact do have
two distinct BSSes. But I don't know how the current user space handles
that.
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
--
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
