I've worked on TCP full time for a couple years and have to say, the more I learn the more WiFi intimidates the heck out of me. I'm barely smart enough to work on wired connections, and think RF DSP is largely beyond my faculties. There's so much going on down there, and the cards are starting to become effectively what we used to call TCP Offload Engines which is unfortunate. The perceived benefit is lower power usage and optimization by RF-aware companies but the negatives are pretty obvious to me. This means that changes like this to mac80211 code (or moral equiv in other OSes) will be increasingly bypassed and done in opaque closed firmware.

I wonder what the real-world impact of this regression is as I'm sure there are plenty of IOT devices out there that are running the affected Linux versions. As the issue likely only manifests at higher bandwidths, I guess things like wireless IP cameras or Wifi attached NAS would be the most affected.

WiFi cameras don’t send that much data, WiFi quality varies based on distance to AP and radio interference. Also WiFi is often slower. A camera that streams 50 mbit/sec or more would be completely broken on any 802.11g 54 mbit/sec network.

NAS-es are better example; they are often bandwidth bound. My guess is, users are typically connecting them with a cable. Most clients are wireless these days (e.g. I happen to type this on a wifi connected laptop), so doing 2 radio hops, NAS-router and router-client, isn’t good for performance: both data streams are competing for the same radio frequencies.

The afflicted Linux devices will be spoiling the commons, even if they can still get their own data sent without stalling.

Instead of combining frames for more efficient use of the available wireless channel they will be sending an individual frame per packet and degrading the total useful capacity of the channel. Wikipedia asserts in its WiFi frame aggregation article that the overhead of a packet can be greater than the actual data of the packet on high speed WiFi.

The afflicted devices definitely make much worse usage of their airtime, but do they actually end up getting much more total airtime/TXOPs? The stations in question are definitely their own worst victim, and the impact they have on competing stations could be far smaller.

Most IOT things aren't high bandwith. They're low latency if anything. So this regression wasn't bad for them.

Looks like OpenWRT snapshot versions since Nov/Dev 2017, and now their 18.06-rc1, should have this incorporated. https://github.com/openwrt/openwrt/blob/a367645f23d2ed93ea29...

It doesn't help much to deploy this to routers, since they aren't endpoints for much TCP traffic volume. Smartphones, laptops and other Linux-based client devices are what need this fix the most.

I feel as though the spirit of this article fits very well with the "hacker" ethos appropriate for HN.

How was this only recently addressed? WiFi transmission rates should be a commonly seen problem?

It takes some skill to figure out that your throughput is significantly lower than the actual radio transmission rate. There are a lot of factors that can hurt WiFi performance, and ruling out poor signal strength and interference isn't easy for most users.

Yup, we had a microwave that will happily take out Wifi in a 200' radius.

Every time I go through a drivethrough there's a 70% probability that my 2-meter radios breaks squelch even though I've only got it tuned to licensed amateur bands.

Long way of saying that RF is hard and amazing it works as well as it does.

Anyone know if this was backported to older kernels?

No. It requires changes that were added late last year to the BBR scheduler.