I have updated the D36243 and now it works well !

See D38807.

See D38807 and D38753.

This patch works well with my rtl8188eu.

This patch is no longer needed since I'm trying to use wpa_supplicant(8) on wtap(4). See D38508.

In D38753#882303, @cy wrote:

I think the reason might be (though I haven't traced this yet) is that we exploit a race with ic_parent and the 2d time we come through ieee80211_start_locked() though this time with the interface UP. This then calls ieee80211_new_state_locked() which will then kick off another task. If we manage to call the ioctl for scanning in between we'll still be in INIT. Basically the IFF_DOWN kicks us back to INIT, no scan running and then on IFF_UP it's a simple race for the 1st VAP (only).

Now that would mean SCAN_ONCE should not be unset and we should not enter in the early case above even if match_bss et al decide they couldn't find a result.

Move ieee80211_notify_scan_done() to a more reasonable place after seeing the comments of @bz.

Can you check that what you are seeing is not caused by an early return in ieee80211_scan_sw.c::scan_end() in the block which has a debug message containing "done, restart"?

In D38508#877995, @emaste wrote:

Phabricator should automatically make likes, at least for hashes in plain text:
5fcdc19a81115
d06d7eb09131

I have found that Linux drivers don't always notify the scan result event to nl80211, so in wpa_supplicant, Linux code just registers timeout on the scan function (wpa_driver_nl80211_scan()). Once the timeout fire, it reports the EVENT_SCAN_RESULTS to wpa_supplicant_event().

In D38508#876443, @bz wrote:

Has this always been a problem or did something in wpa_supplicant change that it now is a problem?

I traced wpa_supplicant 2.4 but the mechanism (use routing socket to wait for RTM_IEEE80211_SCAN) seems the same as 2.10.

Remove unnecessary .El and the term "vap" in wtapctl.8.

In D37070#841801, @bz wrote:

See also https://reviews.freebsd.org/D32847

In D36242#823477, @cy wrote:

Will there be a man page update for this at some point?

Update diff.

In D35624#808065, @lwhsu wrote:

Probably the commit message can be more precise. For example:

Remove store only variable and unnecessary bzero()

- Remove the variable set but not used to fix build on -CURRENT
- Remove bzero() on the space malloc'd with M_ZERO flag.

@rickywu0421_gmail.com: is this message correct?