FreeBSD WiFi management — Apple stack research RESEARCH

What macOS uses for WiFi (it's not wpa_supplicant), what's open source vs closed, why we use wpa_supplicant from ports anyway, and what a hypothetical Apple-shaped WiFi management daemon for FreeBSD would look like. Companion to the IPConfiguration porting plan.

1. Apple's WiFi stack

Multiple components, layered. From hardware up:

Net: only the EAP authentication piece is published. The 802.11 association layer, scanning, key management, profile storage — all closed.

1.1 The architecture diagram

2. Open source status — what's actually published

So when people say "Apple uses eapolclient" — that's true for the 802.1X piece, and that piece IS open source. But "Apple's WiFi" as a whole is overwhelmingly closed.

3. macOS WiFi stack vs wpa_supplicant

Function-by-function comparison.

Conclusion: wpa_supplicant covers everything that matters functionally. Apple's wifid has more sophisticated autojoin heuristics and tighter integration with proprietary features (AirDrop, Continuity), but the protocol coverage is essentially equal.

4. What this project ships today

Already in place from the launchd Phase 1 + configd Phase 1d work:

• security/wpa_supplicant from ports — supersedes the base FreeBSD wpa_supplicant. Newer WPA3-SAE / OWE coverage, current EAP methods, more aggressive CVE backports. Listed in pkglist.txt.
• dhcpcd's wpa_supplicant integration — dhcpcd's built-in wpa_supplicant hook detects the control socket on a wifi iface and gates DHCP behind ASSOCIATED state. Out-of-the-box pairing, no extra glue.
• No launchd plist for wpa_supplicant yet. Users still configure SSIDs manually via /etc/wpa_supplicant.conf or wpa_cli. A Phase 2+ enhancement (in the configd plan) is to introduce a netconfigd-managed flow where Network.plist declares wpa_supplicant config and netconfigd materializes it per wifi iface.

5. Hypothetical: a wifid-shaped daemon for FreeBSD

If we ever wanted Apple-shape WiFi management on FreeBSD — exposing a CoreWLAN-equivalent API to apps — the realistic shape would be a thin daemon (call it wifid-fbsd or org.freebsd.wifid) that:

1. Talks to wpa_supplicant via its UNIX control socket (/var/run/wpa_supplicant/<iface>). Standard protocol: STATUS, SCAN, SCAN_RESULTS, LIST_NETWORKS, ADD_NETWORK, SET_NETWORK, ENABLE_NETWORK, SELECT_NETWORK, plus event monitoring (ATTACH + async events: CTRL-EVENT-CONNECTED, CTRL-EVENT-DISCONNECTED, CTRL-EVENT-SSID-TEMP-DISABLED).
2. Exposes a CoreWLAN-equivalent API over DO IPC (consistent with the project's Mach-IPC-replacement choice). ObjC @protocol sketch:

   @protocol NCWiFiClient
   - (NSArray<NCWiFiInterface *> *)interfaces;
   @end
   
   @protocol NCWiFiInterface
   - (NSString *)ssid;
   - (NSString *)bssid;
   - (NSNumber *)rssi;
   - (NSNumber *)txRate;
   - (NSString *)hardwareAddress;
   - (BOOL)powerOn;
   - (NCStatus)setPower:(BOOL)on;
   
   - (NSArray<NCWiFiNetwork *> *)scanForNetworksAndReturnError:(NSError **)err;
   - (NCStatus)associateToNetwork:(NCWiFiNetwork *)net
                         password:(NSString *)pwd;
   - (NCStatus)disassociate;
   @end
   
   @protocol NCWiFiNetwork
   - (NSString *)ssid;
   - (NSString *)bssid;
   - (NSNumber *)rssi;
   - (NSNumber *)channel;
   - (NCSecurityType)securityType;  // open, WPA2-PSK, WPA3-SAE, EAP, etc.
   @end

3. Stores credentials in /Local/Library/Preferences/Network.plist (eventually keychain-backed when we have one). Translates user intent into wpa_supplicant SET_NETWORK calls. Persists across reboots.
4. Coordinates with dhcpcd via the SCDynamicStore-equivalent. Publishes State:/Network/Interface/<wlan>/AirPort with SSID_STR, BSSID, CHANNEL, SecurityType. dhcpcd's hook reads this and times its DHCP attempts after associate.
5. Optionally pulls in Apple's eap8021x source for EAP methods wpa_supplicant lacks or implements differently. Only if needed; wpa_supplicant covers the standard ones.

Effort estimate: ~3-4k LOC of ObjC, ~2 person-months. Way smaller than the IPConfiguration port because we're not reimplementing the protocol layer — wpa_supplicant stays as the protocol implementation. We're just wrapping it in an Apple-shape API.

Would we do this? Only if Gershwin's WiFi-config UI explicitly wants the CoreWLAN API surface for code symmetry with Mac apps. Today, users using wpa_cli + a launchd plist for wpa_supplicant works fine; nothing is functionally broken. This is a cosmetic / API-symmetry investment, not a functional one.

5.1 Prior art

• HelloSystem explored a similar daemon in the HelloWifid repo — never shipped, but documents the API shape.
• NetworkManager on Linux is the closest production analog — wraps wpa_supplicant via D-Bus, exposes higher-level GTK/Qt-friendly APIs. Different IPC choice (D-Bus vs DO) but same architectural shape.
• iwd (Intel's WiFi daemon, Linux) replaces wpa_supplicant entirely with a smaller, more modern codebase — D-Bus API, but no significant FreeBSD interest because of cfg80211 dependency.

6. Open questions

7. References

• Apple's open-source EAP code: github.com/apple-oss-distributions/eap8021x
• wpa_supplicant upstream: w1.fi/wpa_supplicant/
• FreeBSD wpa_supplicant port: freshports.org/security/wpa_supplicant
• wpa_supplicant control interface protocol: w1.fi ctrl_iface docs
• HelloSystem's wifid exploration: github.com/Karmaz95/HelloWifid
• FreeBSD net80211(4): man 4 net80211
• CoreWLAN public API reference: developer.apple.com/documentation/corewlan
• Companion plans: freebsd-launchd, freebsd-configd, freebsd-IPConfiguration, freebsd-mDNSResponder