User Details
- User Since
- May 27 2022, 6:57 AM (127 w, 6 d)
May 2 2023
Apr 19 2023
Mar 6 2023
I have updated the D36243 and now it works well !
Mar 5 2023
See D38807.
Mar 2 2023
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.
Feb 26 2023
Feb 24 2023
Feb 18 2023
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).
Feb 17 2023
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.
Feb 15 2023
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"?
Feb 13 2023
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().
Feb 12 2023
I traced wpa_supplicant 2.4 but the mechanism (use routing socket to wait for RTM_IEEE80211_SCAN) seems the same as 2.10.
Feb 11 2023
Jan 19 2023
Remove unnecessary .El and the term "vap" in wtapctl.8.
Jan 7 2023
Dec 3 2022
Nov 9 2022
Oct 20 2022
Sep 25 2022
Sep 7 2022
Sep 6 2022
Aug 20 2022
Aug 17 2022
Aug 12 2022
Jul 27 2022
Jul 25 2022
Jul 19 2022
Update diff.