On Mon, 2011-01-24 at 23:21 +0200, Arik Nemtsov wrote:
> Well a wiphy flag won't do here. Probe requests may be filtered in
> some modes (AP-mode) but needed in others (p2p?).
> I think flexibility is a nice added bonus here. A FW can decide to
> handle most standard probe-requests and simply not pass them up.
> Others ("complicated" ones) it can pass up to hostapd and expect it to reply.
>
> The current patches leave this policy in the hands of the driver/fw.
That is _very_ dangerous. If the user has older firmware that doesn't
know about WSC2, how would the user know not to configure WSC2 in
hostapd? That needs to be known to hostapd so it can verify this
situation. For P2P, we already know whether or not P2P is supported, but
that's rather vague in case there will ever be a revision of the P2P
spec with say different IEs.
Additionally, a "regular AP" (not P2P, not WSC) would still want to
reply to probe requests from WSC/P2P devices with the normal template.
IMHO it would be smarter to rework the firmware to only reply to probe
requests if the probe response is configured. Then, if WSC, P2P, or
similar technologies are in use on the interface, hostapd can simply
decide to not configure the probe response and have host-based
processing. Would that be a change you could still make?
johannes
--
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
