There is a project in progress to adapt the latest FreeBSD wifi stack for NetBSD.

This stack introduces the concept of a virtual access point (VAP) and requires changes to the way wifi networks are configured.

Currently there are no pre-build binary sets, so first task is to check out the wifi topic from hg and build it.

At this point a full build will not work (due to unconverted drivers), but you can do something along the lines of:

build.sh -m ${arch} -V MKRUMP=no -V MKKMOD=no sets

to build the sets, and then create you own kernel configuration or add a GENERIC.local file and exclude the non buildable drivers.

The devices referenced in the GENERIC kernels differ a bit from arch to arch (especially there are a few types of hardware that only ever appeared in x86 notebooks), so you may need to adjust your GENERIC.local file for other architectures.

For evbarm:

no athn*
no bwfm*
no atu*
no otus*
no rum*
no upgt*
no ural*
no urtw*
no zyd*

and optionally:

options DEBUG       # expensive debugging checks/support
options LOCKDEBUG   # expensive locking checks/support
options IEEE80211_DEBUG # debug 802.11 code

For amd64 the GENERIC.local could look like this:

options     DEBUG       # expensive debugging checks/support
options     LOCKDEBUG   # expensive locking checks/support

no an*
no ath*
no athn*
no atw*
no awi*
no bwi*
no bwfm*
no iwi*
no malo*
no ral*
no rtw*
no wi*
no wpi*
no atu*
no otus*
no rum*
no upgt*
no ural*
no urtw*
no zyd*

# options       URTWN_DEBUG # debug the urtwn driver
options     IWM_DEBUG   # debug the iwm driver
options     IWN_DEBUG   # debug the iwn driver
options     RTWN_DEBUG  # debug the rtwn driver
options     IEEE80211_DEBUG # debug 802.11 code
options     KERNHIST    # allow debug output to go to a kernhist(9)

After building userland sets and kernel install both! Important tools like ifconfig(8) and wpa_supplicant(8) have changed and the old binaries will not work with the new kernel.

After booting into the new system you will notice that no wlan devices show up in ifconfig -a output. Instead you can see the wlan devices in sysctl output:

# sysctl net.wlan
net.wlan.debug = 0
net.wlan.devices = urtwn0

Now you can create a VAP (called wlan0) by doing:

# ifconfig wlan0 create wlandev urtwn0

This VAP shows up in sysctl output:

# sysctl net.wlan
net.wlan.debug = 0
net.wlan.devices = urtwn0
net.wlan.wlan0.parent = urtwn0
net.wlan.wlan0.driver_caps = 629194753
net.wlan.wlan0.debug = 0
net.wlan.wlan0.bmiss_max = 2
net.wlan.wlan0.inact_run = 300
net.wlan.wlan0.inact_probe = 30
net.wlan.wlan0.inact_auth = 180
net.wlan.wlan0.inact_init = 30
net.wlan.wlan0.ampdu_mintraffic_bk = 128
net.wlan.wlan0.ampdu_mintraffic_be = 64
net.wlan.wlan0.ampdu_mintraffic_vo = 32
net.wlan.wlan0.ampdu_mintraffic_vi = 32
net.wlan.wlan0.force_restart = 0

and you can further configure it with ifconfig

# ifconfig wlan0 up
# ifconfig wlan0 list scan
SSID                  BSSID              CHAN RATE  S:N     INT CAPS
aprisoft              e0:28:6d:59:cb:90    1   54M  94:0    100 EPS  WME WPA RSN

This sounds a bit strange at first sight, but multiple networks (one per VAP) for a single radio do make sense. Here is the original paper describing the design: FreeBSD wireless BSDCan 2005.

VAP is the term used internally in the code, it is meant to mean a virtual wifi radio. In the wifi world nowadays VAP would be a virtual access point, which is not quite the same thing as the virtualized interface we are talking about here. You can think of VAP as something similar to a VLAN, or a tap(4) or vether(4) connected to a bridge(4), where the real "wlandev" from the ifconfig create command line is the equivalent of the bridge.