FreeBSD Wi-Fi Host Access Point Operations: Validate Drivers and Clients

FreeBSD can provide a host-based 802.11 access point when the wireless chipset, native driver, firmware, regulatory domain, and security configuration support the intended mode. This is not the same workflow as joining an existing Wi-Fi network, and it is not automatically a router or DHCP server. A working radio can advertise an SSID while clients still have no address, route, DNS, or upstream connectivity.

Treat access-point work as a layered change. First prove the adapter supports hostap mode. Then configure the interface and authentication daemon, associate a test client, and only afterward connect the WLAN to a routed or bridged network. Keep the console or a separate management path available; changing network interfaces remotely can cut off the host.

Check native driver and AP capability

Inventory the wireless hardware and its driver before creating persistent configuration:

pciconf -lv
dmesg | egrep -i 'wireless|802.11|wlan|firmware'
ifconfig -a
kldstat

The FreeBSD Handbook notes that the NDIS wrapper for Windows drivers does not support AP operation; native FreeBSD wireless drivers are required. Do not infer support from the adapter name, its ability to scan, or successful client mode. Hardware revision and driver implementation matter.

Create a temporary station-mode pseudo-device and query capabilities, using the real driver interface name:

ifconfig wlan0 create wlandev ath0
ifconfig wlan0 list caps
ifconfig wlan0 destroy

Look for HOSTAP in the driver capabilities. Review the output for supported bands, channels, ciphers, and related features, and compare it with the intended configuration. If HOSTAP is absent, stop. Installing hostapd cannot add a kernel driver capability that the adapter does not provide.

The Handbook explains that hostap mode is selected when creating the wlan pseudo-device. If a pseudo-device was created in another mode, destroy and recreate it. This action can interrupt traffic using that interface, so ensure it has no active client, route, bridge, or management role before doing so.

Plan the Layer 2 and Layer 3 design

Choose the intended subnet and decide whether the access point will be a bridged segment or a routed interface. Bridging and routing have different broadcast, firewall, DHCP, and client-isolation behavior. This guide configures the AP interface and hostapd but deliberately does not enable forwarding or NAT. Those functions require an explicit gateway design and rules in the selected firewall.

Select a regulatory country and channel supported by local requirements, the radio, and the driver. Do not copy a channel number from another region or treat an example as regulatory advice. Check the device’s channel list and current domain with ifconfig and the driver documentation. DFS channels can involve radar detection behavior and may not be suitable for every test plan.

For a controlled WPA2-PSK example on an adapter confirmed to support the 2.4 GHz 802.11g mode, a temporary runtime setup resembles:

ifconfig wlan0 create wlandev ath0 wlanmode hostap
ifconfig wlan0 inet 192.168.50.1 netmask 255.255.255.0 ssid lab-ap mode 11g channel 1 up
ifconfig wlan0 list caps
ifconfig wlan0

The addresses and channel above are placeholders for a lab network and a jurisdiction where channel 1 is permitted. Change them only after documenting the subnet, regulatory domain, driver support, and lack of conflicts. The interface should report hostap mode. A configured IP does not make the host a DHCP server.

Configure authentication with hostapd

hostapd handles authentication and key management for a WPA2 AP. Use a distinct, strong passphrase for a lab or small deployment. Keep secrets out of a public repository, shell history, ticket screenshots, and world-readable backups. Validate file ownership and permissions through the host’s normal configuration-management process.

A minimal /etc/hostapd.conf example is:

interface=wlan0
ctrl_interface=/var/run/hostapd
ctrl_interface_group=wheel
ssid=lab-ap
wpa=2
wpa_passphrase=REPLACE_WITH_A_UNIQUE_LONG_SECRET
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP

The value wpa=2 selects WPA2 in the documented configuration, and CCMP/AES is preferred over obsolete TKIP. The literal placeholder is not a usable passphrase; replace it with a unique secret meeting the hostapd requirements and the deployment policy. Do not use the example SSID or credential on a real network.

Check the current hostapd.conf(5) page for parameter semantics supported by the installed base system. Do not add unsupported WPA3, 802.1X, or cipher settings by copying another platform’s file. If the requirement is enterprise authentication, configure the appropriate EAP/RADIUS architecture and certificates; a PSK sample is not an enterprise configuration.

Start the daemon for a controlled test:

service hostapd forcestart
service hostapd status
ifconfig wlan0
ifconfig wlan0 list sta
tail -100 /var/log/messages

Check that the interface reports hostap mode and WPA2 privacy, that hostapd remains running, and that the expected client appears as an associated station. If hostapd exits, preserve its first error and the kernel’s wireless messages before restarting it.

Make startup reproducible

Once the runtime test is understood, persistent configuration in /etc/rc.conf can follow the documented structure:

wlans_ath0="wlan0"
create_args_wlan0="wlanmode hostap"
ifconfig_wlan0="inet 192.168.50.1 netmask 255.255.255.0 ssid lab-ap mode 11g channel 1"
hostapd_enable="YES"

Replace ath0, addressing, SSID, mode, and channel with values proven on the actual machine. Keep credentials in the hostapd configuration file rather than exposing them as command-line arguments. Validate rc.conf syntax and service ordering with a controlled reboot before relying on the AP for a remote site.

Do not persist settings for an adapter whose unit number changes unpredictably without first designing a stable device selection. A different adapter could be enumerated as ath1 or use another driver. Confirm the created wlan interface maps to the expected physical card after boot.

If the device lacks HOSTAP or clients cannot associate, do not repeatedly rewrite rc.conf. Remove the experimental persistent values, return to a known-good station-mode configuration, and isolate the layer that failed.

Diagnose association, addressing, and reachability separately

Use a test client whose Wi-Fi settings are known. First confirm that it sees the SSID and can associate. On FreeBSD, inspect hostapd logs and ifconfig wlan0 list sta. If the SSID is invisible, check radio capability, mode, channel, regulatory domain, interface status, firmware, and hostapd startup. If visible but association fails, examine authentication logs and ensure the client supports the configured WPA2/CCMP combination.

After association, determine the client’s IP configuration. The AP interface does not provide DHCP by itself. A client can show a successful Wi-Fi connection while having no lease. Configure an approved DHCP service for the subnet or use a static test address; do not install a second DHCP server into an existing LAN without checking for conflicts.

Test a sequence that distinguishes local AP, IP, DNS, and upstream routing:

ifconfig wlan0
netstat -rn
ping -c 3 192.168.50.1
service hostapd status

From the client, first test its address and the AP gateway, then the approved upstream destination, then DNS. A working local ping proves neither Internet routing nor name resolution. If a bridge is intended, inspect bridge membership and spanning-tree state using the relevant bridge operations runbook. If routing is intended, confirm forwarding and firewall/NAT policy under a separate reviewed change.

Avoid disabling the firewall wholesale as a diagnostic. Capture rules and counters, identify the exact expected path, and add only a narrowly scoped test rule with a rollback plan. Do not expose the host’s management services to the wireless subnet unintentionally.

Measure service and capture a useful baseline

Record adapter and driver identifiers, firmware, regulatory domain, channel, width, security mode, client model, RSSI, negotiated rate when exposed, and the traffic path. Measure throughput and latency from a stable test position with competing clients and load documented. A PHY rate is not application throughput, and one speed test is not a service-level result.

Watch host CPU, interface errors, retransmissions if visible, hostapd logs, and upstream routing. Test at least one disconnect/reconnect cycle and one host restart. A configuration that advertises an SSID after an interactive setup but fails after boot is not production-ready.

Acceptance and rollback

Acceptance requires a stable AP interface after reboot, hostapd running with the intended parameters, a client associating with the expected security settings, address assignment from the approved network service, and successful traffic only to the destinations allowed by the design. Save status output and configuration hashes with the change record while redacting the PSK.

Rollback should disable hostapd, remove the AP-specific persistent rc.conf entries, and restore the prior network configuration. Keep a wired or serial management path until rollback is confirmed. Do not destroy an interface that is carrying the only management path.

An AP may be a useful test, lab, or small gateway component, but radio support, regulatory compliance, capacity, and client isolation require explicit validation. It should not be assumed to replace a managed access point or a router simply because hostapd reports a running service.

Related:

Sources: