Thomas Johnson (High School Janitor)
“Oh yeah, I’ve seen that code. It’s worse than what I clean up in the bathrooms after Prom or Homecoming. The kids get high and drunk and party too hard and puke all over the place. I deal with enough vomit from 7:30 to 6; I wouldn’t touch the staging drivers with a mop twice as long as the one I have at work.”
Just Say No
Thomas just found out that none of the “staging” wifi drivers will work with hidden access points because they don’t set the IW_SCAN_CAPA_ESSID capability bit. Furthermore, the most popular “staging” drivers (for the Ralink hardware used in many netbooks) don’t even have specific SSID scanning capability at all.
Why do you care? Hidden APs don’t broadcast their network ID, which misinformed people think is more secure (hint: it’s not). Before a driver can associate to the network, it needs to discover available APs and capabilities, which requires a probe-request, which exposes the network ID to everyone anyway. But that requires driver support which none of the staging drivers have.
I fixed this issue upstream two years ago by adding IW_SCAN_CAPA_ESSID to Wireless Extensions. Of course the staging WiFi drivers that many distros enable never got fixed because the vendor it came from didn’t bother to work with the community in the first place. And people wonder why they don’t work.
Broadly speaking, staging WiFi drivers come in two flavors: (a) old dried gum from under the cafeteria table (drivers with a future), and (b) fresh vomit from the hung-over kid in your math class (those without a future).
The drivers with a future (winbond, rtl81xx) are or will based on the kernel-standard mac80211 wireless stack, which implements the 802.11 WiFi specification in the kernel. Since they use the standard mac80211 stack, they get all these nice features like probe-scanning and the correct capability bits for free. All you have to do is work on supporting the hardware itself.
The drivers without a future (rt2860, rt2870, rt3070, rt3090, wlan-ng, vt665x) are based on forks of the ancient ieee80211 stack that Intel’s ipw2x00 drivers forked from the hostap driver. Each of these drivers includes their own copy of the core ieee80211 stack forked at different times and with different hacks. When a bug shows up, that means 4x the work, and 4x the chance for the fix to slip through the cracks. Which is why these drivers have no future. They are a maintenance nightmare. Besides, they have crap like this:
pAdapter->StaCfg.bScanReqIsFromWebUI = TRUE;
It just blows my mind why people think staging wifi drivers are a great idea. There’s a reason staging drivers set the TAINT_CRAP flag in your kernel; because that’s what they literally are.
So what’s the right thing to do?
There’s one huge reason why dead-end staging drivers are a bad idea: there aren’t enough developers. So do you spend that effort on maintaining unmaintainable shit code? Or do you spend it on fixing the code that has a future? Most of the time you can’t do both.
If you choose to maintain the staging drivers, then things become worse over time since the staging code is simply less tested and less maintainable. So you continue to drop hacks and fixes onto an ever-growing steaming pile of manure. Nobody cares much about the driver (because it doesn’t use the standard kernel interfaces and thus doesn’t have a future), so your staging driver never benefits from all the great feature work and bug fixing that the mac80211 and wireless developers are doing.
But if you choose to help fix the upstream drivers that do use mac80211 (like rt2x00), and thus have a future, maybe for a few months some users won’t have great wireless. But they didn’t before either. But then 6 months later, all the users get great wireless with features like power saving, background scanning, WiFi Direct, Bluetooth 3, access-point mode, etc. Those things will never be done to the staging drivers, because those drivers are a dead-end maintenance nightmare, because their code is awful, and because they don’t use the standard kernel wireless stack.
I know I’d invest the effort where it helps users the most, even if it means a few more months of subpar driver support while the official upstream drivers get fixed and the staging drivers go untouched. That’s how things actually get better when you can’t fix everything at once.
