News for hackers. Stuff that matters.
Re:Solving the crypto-fq bug in ath9k (2016) by dtaht99 on Monday August 27, 2018 @11:05AM (#17851912)
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.

Re:Solving the crypto-fq bug in ath9k (2016) by acd on Sunday August 26, 2018 @03:32PM (#17847440)
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...

Re:Solving the crypto-fq bug in ath9k (2016) by lima on Sunday August 26, 2018 @06:04PM (#17848194)
I truly admire the CeroWrt team for their work on bufferbloat. Few people would have both the knowledge and persistence in solving this.
Re:Solving the crypto-fq bug in ath9k (2016) by dtaht99 on Monday August 27, 2018 @11:18AM (#17851990)
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.

Re:Solving the crypto-fq bug in ath9k (2016) by zpiro on Sunday August 26, 2018 @12:13PM (#17846495)
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?
Re:Solving the crypto-fq bug in ath9k (2016) by softblush on Sunday August 26, 2018 @11:03AM (#17846215)
Missing (2016) in title
Re:Solving the crypto-fq bug in ath9k (2016) by milankragujevic on Sunday August 26, 2018 @11:03AM (#17846214)
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?
Re:Solving the crypto-fq bug in ath9k (2016) by baybal2 on Sunday August 26, 2018 @11:28AM (#17846326)
Our company got burned when our sales people yielded to client's demand of using the cheapest chip around, and yes, Mediatek it was
Re:Solving the crypto-fq bug in ath9k (2016) by mangix on Sunday August 26, 2018 @11:46AM (#17846395)
Probably when and if mediatek releases new hardware.