Solving the crypto-fq bug in ath9k (2016) | Hacker News Reader

Solving the crypto-fq bug in ath9k (2016)

blog.cerowrt.org

38 pointsedwintorok9 comments

The code shipped in lede 17.01 that january(2017) and also went Linux mainline at the same time. Everybody on linux using an ath9k and ath10 chip is benefiting today, and it (or a variant) is in multiple commercial products now. I kind of expect it to be in all new products leveraging these chips.

Our writeup of how it works is here: https://arxiv.org/pdf/1703.00064.pdf - lots of pretty pictures.

I recently had to shut down my lab for lack of funding.

Great work and thanks for solving the Crypto FQ bug making ath9k faster! Looking forward to using the fixes and the speed improvements we will get. It seems like you needed the WPA IV packets which are the same as for WPA key handshake. It must have been extra elusive to find the bug since the traffic was encrypted. Thanks also for working on solving buffer bloat, buffer bloat is annoying.

https://www.bufferbloat.net/projects/bloat/wiki/Introduction...

I truly admire the CeroWrt team for their work on bufferbloat. Few people would have both the knowledge and persistence in solving this.

Well, cerowrt was the big "what can we do to fix ipv6, routing, wifi AND bufferbloat?" project, to produce an existence proof that typical home cpe could be made into something that did all these things. We made sure that everything important we did ended up upstream when cerowrt ended and the mailing lists with the accumulated expertise remain.

make-wifi-fast was this project where we took a deep dive into wifi, and cut 100x of the latency out across all rates and improved throughput on our tests by 2.5. That damn "fq bug" was the not the only, but certainly the worst bug we dealt with. Even harder was spending about 2 years, stumped, trying to come up with an efficient implementation of the fq_codel theory, in wifi. 5 years of work to get to this goal, with no progress til the end. No corp would have supported us...

This past year's project was sch_cake, which helps defeat bufferbloat on really slow connections. That will be in linux 4.19, writeup here: https://lwn.net/Articles/758353/

None of our projects ever attract funding, yet we do somehow manage to ship something great every other year.

After every "improvement", new problems emerge. We enabled ecn universally in the fq_codel for wifi code, in sch_cake, and partially in the sqm-scripts... then apple enabled ecn universally in their TCPs... last year... and I'm concerned now about how well that is working out. ECN was a "debugging aid" for us, mostly.

Good job! Might have closed a side leak there. Next step might be to to make sure certain TCP packets under a certain classification gets encrypted together with data traffic?

Missing (2016) in title

That is all well and good, and I don't want to sound ungrateful (I'm sure I do), but will we ever get WiFi working on ramips platform with mt76 driver?

Our company got burned when our sales people yielded to client's demand of using the cheapest chip around, and yes, Mediatek it was

Probably when and if mediatek releases new hardware.

Reply on news.ycombinator.com