Consider an implementation from someone who has no knowledge of the stack. It appears as a giant wall of text. Where do you start? What's the equivalent of main() and how do the handlers interoperate?
I would benefit from a walkthrough of how the driver works:

Probe requests go out and are correctly sent
I confirmed this with Wireshark on another machine
However, it does not appear to go to the next step in the handshake process.

Probe Requests go out correctly, Probe requests are sent back out and appear to come back in -- I verified via Wireshark on a 3rd machine.
But the driver is still sending out probe request frames and doesn't move to the next step.

Stuck on athn_usb_detach code or executes athn_usb_stop multiple times
I suspect this is due to the msleep on one threat and a wakeup on another, but I am not certain how to isolate the problem.

Updated per comments

Bump :)

Hi,
Checking if there are any updates necessary to merge this?

Current Problem: Running into a recursive mutex based on FreeBSD/OpenBSD mutex styles.

In D50264#1146885, @jhibbits wrote:

I'm not sure why this was never connected to the build, I would have fixed it during my IfAPI work if it were connected then.

You can use the script tools/ifnet/convert_ifapi.sh to assist in converting the driver to IfAPI.

Ordering of includes. It builds.

Changed Taiwan's from "Taiwan, Province of China" back to "Taiwan".

Working to update the athn_usb_init, currently working through the newstate handler.

In D50188#1144718, @lwhsu wrote:

FreeBSD uses a list derived from ISO 3166 [1], which is at src/share/misc/iso3166. It would be nice if we can have this enum generated from that list so we have a single source of truth.

In D49884#1137462, @imp wrote:

In D49884#1137457, @lwhsu wrote:

I think the current idea is avoiding directly import firmware file into repo. Perhaps we can separate the firmware out. The current approach is using firmware ports/pkg, before having that, we can just put it somewhere and ask people to grab it and put to the required place, for testing.

Or point them at the linux wireless firmware archive repo....

Mistakenly tagged dteske@ after misreading MAINTAINERS.

In D34484#781354, @rlibby wrote:

I don't have an objection to changing the LOG_WARNING to LOG_ERR, but I'm confused about what this actually changes. I looked at man 3 syslog and vsyslog1() to see if we printed to stderr by default for LOG_ERR but I'm not seeing that. So, what does this actually do?

Raising Warning to Err

Updated per @kevans comments, the previous update contained a misunderstanding on my part.

Updated per comments from kevans@

Removed adding admin user step

Bump

Added libfetch-style error reporting for SOCKS5. Examples below:

dump :(

bump :)

Any updates on this, @des and @thj ? :)

Rebased against current head

Silly mistake, removed the duplicate.

Updated per @markj 's comments.

Updated!

Minor style(9) change

Hi @kevans, any updates on this?

I believe I got all updates, except one. I can go ahead and make that change ASAP.

Updates from @kevans comments

Hi all. I see that this was changed to "Accepted" a while ago, but there has not been any movement on it.

Any updates on this? Its been sitting here for quite a while now...

Any updates on this?

Updated the man page + some macros

A few months old - any updates?

Updated per @lattera-gmail.com and @0mp comments.

I'm so sorry, I missed your comment from months ago!

If in the future we create an environmental variable toggle switch for DNS over the proxy vs locally, we should make sure not to use getaddrinfo() or fetch_resolve() of the destination host when DNS-over-SOCKS5 is set. This could result in a unintended DNS leaks and compromise privacy.

Hi,
Any updates on this? It should be a pretty quick documentation update.
Thanks!

Oddly enough, the device inexplicably stopped receiving frames on my computer, no idea why -- even though I wrote it!
Changing over to the OpenBSD power on sequence works. It was slightly less consistent with the Linux driver, but it worked.
Please verify on your end that it works, would hate to break the driver.

This was incorporated into a commit.

Fixed a bug in the SRCTOP variable, for some reason it was .SRCTOP with a preceding period character.

Hi all,
Has anyone had a chance to review this?

Hi,
I read what you wrote several times, but I really did not understand you.
Yes, the interrupt lands in rtwn_pci_intr and rtwn_classify. But the classification starts at r92c_handle_c2h_task, specifically from reading the R92C_C2H_EVT_CLEAR register:

Hi all, any views done on this? Its been a little less than a month :)

Previous commit set utf8 when false, not true. Resolved.

Changed the usage of the utf8 variable to true meaning "the terminal is utf8 capable"
Changed LC_ALL to LC_CTYPE

In D15922#336873, @kristof wrote:

I'm not sure if I object to this change or not, but it's worth noting that SSIDs are not necessarily UTF-8 strings. Unless the SSIDEncoding is set it is 0-32 octets. Having 0 bytes in the middle of the SSID is valid (though I'd be very surprised if that actually worked on more than a handful of devices). If SSIDEncoding is set it is indeed a UTF-8 string.
For additional fun Microsoft got this wrong and several Windows versions interpret the SSID as being Latin1 encoded.

Hey @s3erios_gmail.com, have you had a chance to poke at this again?

Minor correction to the diff to have quotes around the ssid name when it includes non-ASCII characters

The previous commit was a diff from the previous diff.
That was a mistake, I am still getting used to the tooling.
This is a diff from HEAD.

Attached Tx methods from rtl8192ce

Hi Andriy,

Attached Tx methods from rtl8192ce

I retrieved the rtl8188efw.bin firmware from here: https://github.com/lwfinger/rtlwifi_new/tree/master/firmware/rtlwifi
I uuencoded it with the following command:
uuencode rtl8188efw.bin rtwn-rtl8188eefw.fw.uu > rtwn-rtl8188eefw.fw.uu