Change Details

The mechanism of Hostap mode's beacon generation is the same as in IBSS mode, so simply add `IEEE80211_M_HOSTAP` on `iv->newstate()`. Currently, wtap(4) has trouble combined with wpa_supplicant(8), please see D38508. The patch D38807 doesn't fix the problem, although this patch works well on many hardware NICs.

wtap(4): support hostap/sta mode and WPA/WPA2 Wtap originally only supported mesh/ad-hoc mode, and cannot be combined with wpa_supplicant(8) and hostapd(8). Now I have supported hostap and sta mode by simply ORing IEEE80211_C_HOSTAP and IEEE80211_C_STA in ic->caps, and making hostap vap can send beacon frame. The beacon frame-sending mechanism is already done in mesh/ad-hoc mode, so simply use it. There is a problem when combining wtap(4) with wpa_supplicant(8): A race is introduced by net80211's scan request and wpa_supplicant's scan request, and if ic->parent in drivers (yes, all of 802.11 drivers) finished too quickly, wpa_supplicant's scan request will lose net80211's scan request and leads to a connection-fail problem. D38753 introduces the problem, and D38807 fix the problem with real world NIC (ic->parent takes time), but wtap(4) (ic->parent finishes too quick). I have solved this problem by making wtap(4) sleeping for a while in ic->parent. Now wtap(4) supports wpa_supplicant(8) and hostapd(8) well. This patch depends on D37973.

The mechanism of Hostap mode's beacon generation is the same as in IBSSwtap(4): support hostap/sta mode and WPA/WPA2 Wtap originally only supported mesh/ad-hoc mode, and cannot be combined with wpa_supplicant(8) and hostapd(8). Now I have supported hostap and sta mode by simply ORing IEEE80211_C_HOSTAP and IEEE80211_C_STA in ic->caps, and making hostap vap can send beacon frame. The beacon frame-sending mechanism is already done in mesh/ad-hoc mode, so simply add `IEEE80211_M_HOSTAP` onuse it. There is a problem when combining wtap(4) with wpa_supplicant(8): `iv->newstate()`A race is introduced by net80211's scan request and wpa_supplicant's scan request, and if ic->parent in drivers (yes, all of 802.11 drivers) finished too quickly, wpa_supplicant's scan request will lose net80211's scan request and leads to a connection-fail problem. D38753 introduces the problem, and D38807 fix the problem with real world NIC (ic->parent takes time), but wtap(4) (ic->parent finishes too quick). I have solved this problem by making wtap(4) sleeping for a while in ic->parent. Now wtap(4) supports wpa_supplicant(8) and hostapd(8) well. Currently, wtap(4) has trouble combined with wpa_supplicant(8), please see D38508. The patch D38807 doesn't fix the problem, although this patch works well on many hardware NICsThis patch depends on D37973.