In D37973#1003520, @bz wrote:

@lwhsu I'll just pick the first review given they all live in a window here; last time I checked and asked if they were ready for review I was told to hold off for further changes? Have they been addressed, as in, is the stack of wtap changes ready for review?

@lwhsu I'll just pick the first review given they all live in a window here; last time I checked and asked if they were ready for review I was told to hold off for further changes? Have they been addressed, as in, is the stack of wtap changes ready for review?

Can you upload this with more context? Either use arc or git diff -U9999 when creating the diff. That'll help to see surrounding code (and probably stop asking me silly questions ;-) )

See D38807.

See D38807 and D38753.

In D38753#883173, @bz wrote:

The "backout+logging" change is at https://reviews.freebsd.org/D38807

The "backout+logging" change is at https://reviews.freebsd.org/D38807

In D38753#883103, @cy wrote:

IMO we should revert the specific upstream commit or set IFF_UP when the interface is downed or brought up. The below should work.

..

The above has been submitted in https://reviews.freebsd.org/D38805.

IMO we should revert the specific upstream commit or set IFF_UP when the interface is downed or brought up. The below should work.

In D38753#882743, @enweiwu wrote:

In D38753#882303, @cy wrote:

Feb 24 20:15:57 slippy wpa_supplicant[7099]: wlan0: CTRL-EVENT-DISCONNECTED bssid=4c:60:de:31:3c:62 reason=3 locally_generated=1
Feb 24 20:15:57 slippy wpa_supplicant[7099]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address
Feb 24 20:15:57 slippy wpa_supplicant[7099]: wlan0: CTRL-EVENT-DSCP-POLICY clear_all

Could you provide more logs for tracing? Just guessing by the three lines, the CTRL-EVENT-DISCONNECTED has reason code = 3 in the disauthentication frame, and by the spec, it means "Station has left the basic service area or extended service area and is disauthenticated", it seems weird because you said that re-adding rc scripts will work.

In D38753#882303, @cy wrote:

Having tested this, I'm seeing these in syslog and no carrier. It doesn't fix the problem.

The code looks reasonable to me, so far. I'll test it later tonight.

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).

I have to apologize again for the messy output I put in earlier.

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.

I surely ran into the early return part of scan_end(). Here is the most critical condition to indicate why it early return in scan_end(): https://cgit.freebsd.org/src/tree/sys/net80211/ieee80211_scan_sw.c?h=stable/13#n846. In STA mode, ss->ss_ops->scan_end(ss, vap) is pointed to ieee80211_scan_sta::sta_pick_bss(), and this function returned 0 (so the condition is true). It didn't pick any BSS (return 0) because the ieee80211_scan_sta::match_bss() returns 0 if we further trace more codes. And I found that the lines show BSS in the dmesg(8) output above all contains "wep!", and after tracing the codes, the "!" means the BSS didn't match our requirements of wireless setting. In summary, after the scan finished, it find that no suitable BSS is there (in match_bss()'s thoughts) so didn't call scan_done() and directly restart the scanning process.

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

(also I thought we had a program somewhere in tools/tools/net80211 that would listen to the routing socket for all net80211 messages, to make debugging this easier? if not, we should write one :-)

iirc, and don't quote me on this, the "scan done + restart" stuff can happen when the software scanner is doing things like background scans (which break softmac 11n/11ac/etc devices, sigh, someone needs to employ me for 6 months to properly fix that for softmac devices already) it can start and stop a scan, push up scan results, but not complete it. background scans can be interrupted by active traffic, which means it'll try to do a piecemeal scan before pushing things up.

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

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"?
It would probably be interesting to see a trace from your investigation when the problem of not reporting the scan end occurs with wlandebug +scan turned on. That'll likely give us an idea why we don't make it to either of the two current ieee80211_notify_scan_done() calls.

In D38508#877995, @emaste wrote:

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

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.

There may have been one or two hotels that I've stayed out where I hit this problem...
I'm not at them right now, or I'd test to see if this fixes things.

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

Manual page now LGTM.

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

In D37070#841801, @bz wrote:

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

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

For the record, we're thinking to move the tools to /usr/sbin as wtapctl(8).

We also need to add this directory to tests/sys/Makefile

I'll get this in the next 24 hours.

In D35841#821792, @adrian wrote:

hi! I think this looks ready to land, right?

hi! I think this looks ready to land, right?

In D35752#817661, @lwhsu wrote:

In D35752#816864, @bz wrote:

Can you please update the review after doing a git rebase? It doesn't apply to main.

I've checked that it can be applied to the current HEAD of main branch ( 2c4276aaa2d03217b9c1797196864bbbe4f2d8ea ). Is there anything we missed?

In D35752#816864, @bz wrote:

Can you please update the review after doing a git rebase? It doesn't apply to main.

Can you please update the review after doing a git rebase? It doesn't apply to main.

nice work!

Update diff.