
Solving the crypto-fq bug in ath9k (2016) - edwintorok
http://blog.cerowrt.org/post/crypto_fq_bug/
======
dtaht99
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](https://arxiv.org/pdf/1703.00064.pdf)
\- lots of pretty pictures.

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

------
acd
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...](https://www.bufferbloat.net/projects/bloat/wiki/Introduction/)

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

~~~
dtaht99
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/](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.

------
zpiro
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?

------
softblush
Missing (2016) in title

------
milankragujevic
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?

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

