net80211: do not enforce promiscuous mode for AP scan

[avos]

Summary

Drivers should set their own filters via ic_scan_start()/ic_scan_end() callbacks; and we don't need frames other than beacons or probe responses.

Test Plan

Tested with Intel 3945BG, RTL8188EU and WUSB54GC in HOSTAP mode.

[adrian]

ok, I wonder if there are some drivers that don't yet do this, and thus will break. :(

Maybe put a call out for this for some wider testing?

[avos]

Well, right now it's a noop (fixed in D5472)

[avos]

Some review on drivers with IEEE80211_C_HOSTAP bit set (not mentioned in Test Plan):
ath(4) (seems to work without promiscuous mode (partially?):

u_int32_t
ath_calcrxfilter(struct ath_softc *sc)
{
...
	/*
	 * NB: We don't recalculate the rx filter when
	 * ic_protmode changes; otherwise we could do
	 * this only when ic_protmode != NONE.
	 */
	if (ic->ic_opmode == IEEE80211_M_HOSTAP &&
	    IEEE80211_IS_CHAN_ANYG(ic->ic_curchan))   <<< 11g only?
		rfilt |= HAL_RX_FILTER_BEACON;
...
}

wi(4) (probably, never worked (look at comment in wi_parent()), may be fixed in D5381)
ural(4), run(4), rt2560/rt2661 - looks similar to rum(4)
mwl(4), rt2860 - no idea here

[avos]

In D5474#116711, @s3erios_gmail.com wrote:

Well, right now it's a noop (fixed in D5472)

and, after applying it (without this patch), I have got kernel panic (ic_promisc was decremented twice for the same vap by ieee80211_check_scan())

[adrian]

ok. Well, when you commit the scan framework stuff, you should likely fix this up at the same time and commit it?

[avos]

why not?