Hacker News new | past | comments | ask | show | jobs | submit login

The difference is probably in the way WPA is handled; WPA Supplicant can be made to work with any radio module that supports passing through the authentication and encryption. But Windows doesn't use WPA Supplicant and instead relies on each manufacturer to make sure their driver either has its own WPA Supplicant or uses on-chip authentication and encryption in the WiFi module itself.

The big difference between them is that on Linux it will work, but heavy traffic will eat CPU cycles. On Windows it simply might not work at all, but when it does, and if the driver is not written by 1000 monkeys on typewriters, it can offload a lot of heavy lifting to the WiFi ASIC.

I'd say that in all cases, the WiFi chip manufacturers are to blame, but the software fallback that WPA supplicant provides should really be the lowest bar any device or OS should be able to pass.




Only authentication will not be offloaded, actual data encryption still is.

The only exception is if your driver doesn't support management frame protection (802.11w). Then, if your AP has 11w enabled or you are using WPA3, it will use software encryption.

ath9k, ath10k, ath11k, ath9k_htc, ath6kl, brcmfmac, brcmsmac, iwlwifi, iwlegacy, mt76, mwifiex, mwl8k, rtl8xxxu, all rtl8xxxe drivers support 11w, while some others: rt2xxxpci rt2xxxusb, ipw2200, carl9170 don't.


In the old days we needed a lot of tricks because firmware loading either didn't work or we didn't have the firmware binaries yet, so even (IIRC) ath9k didn't utilise on-ASIC for everything. But that was in the B (and maybe G) days.


I did not know that the system could push the encryption and auth up to the CPU. Always assumed the card did all the heavy lifting.

Very interesting!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: