Changes:
- Removed unnecessary TSF insertion in probe response frames
- Removed pause() workaround for wpa_supplicant(8) race condition
- Added ic_cryptocaps configuration to declare supported cipher suites
Changes:
I have updated the D36243 and now it works well !
See D38807.
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?