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