Hi HN, I’ve been working on a Rust userspace radio stack for running WFB-style links from macOS using RTL8812AU USB adapters. Full disclosure: I'm a software engineer, but not really a hardware or embedded systems engineer, so Codex GPT 5.5 has done the lion-share of the work here along with a bit of help from Claude Opus 4.7 here and there. It's taken about 1.5 to 2 weeks to get from zero to this first release.

macOS doesn't expose the monitor-mode / packet-injection path that WFB systems normally rely on. I really didn't like the idea of needing a separate linux box just to talk WFB to other edge devices, like drones. This talks to the ALFA AWUS036ACH as a USB peripheral directly, initializes the RTL8812AU, submits raw 802.11 WFB frames over bulk OUT, receives frames over bulk IN, and bridges them to WFB-NG’s distributor/aggregator UDP protocols.

Basically, this is what's working (you can see more detail in the readme):

- native macOS userspace RTL8812AU bring-up

- TX/RX of WFB datagrams

- production-ish service runtime

- macOS utun bridge helper (if you need an IP-based link)

- RF diagnostics, telemetry, LED heartbeat, TDD airtime controls

There's a GitHub alpha release with arm64 macOS binaries

This is definitely still alpha. The direct-radio path is currently macOS-focused and tested with ALFA AWUS036ACH adapters on both sides (the other side is a Raspberry Pi 5 running Bookworm). macOS 26 works through IOUSBHost as libusb is not reliable there. Linux should still use native WFB-NG + rtl88xxau monitor mode rather than this USB bridge. Long-range RF quality and calibration work are ongoing. So far, some short range profiles are showing pretty good results.

I’m sharing early because getting WFB-like radio links working from a Mac seemed unlikely when I started, and the path turned out to be more interesting than expected.

My goal is for this to be cross-platform as-needed. Next up is an attempt at Android support via USB-OTG. We'll see how that goes.

Super cool approach. What ended up being the hardest part of bypassing macOS’s lack of monitor mode—was it USB throughput constraints or getting reliable timing for TX/RX?

This is very cool. I'm excited to see where this goes.