TP-Link EOL'd my Wi-Fi 7 AP, so I wrote a kernel exploit to fix it
Wanted to download an ISO, ended up writing a kernel exploit
My TP-Link EAP770 v1 corrupted large downloads over Wi-Fi, and TP-Link end-of-lifed it before I even unboxed it. The fix was two sysfs writes to disable Qualcomm's SFE/PPE offload, but the shell runs as uid 1 with no capabilities. So I chained CVE-2022-0185 with pipe-buffer manipulation to get root, overwrite modprobe_path, and disable the offload. The corruption turned out to be a DMA cache coherency bug in Qualcomm's driver.
The fix is two zeros in sysfs. TP-Link's shell won't let me write them, so I wrote a kernel exploit for my own fucking access point.
- Shank
> The connection was a bit janky, a video would occasionally start buffering, but it didn't bother me much.
This is truly bonkers! Please, if you buy hardware that does not work correctly from day 1, return it. If you do not vote with your wallet these companies will never learn and will never adjust their practices. Rewarding TP-Link by keeping their terrible hardware does nothing.
> I contacted support in June because the website only had firmware for v2. They couldn't find v1 in their database and asked for photos of the device and box
!!
- commandersaki
Really happy with my Flint 3. I like that I can SSH to root and do whatever I want.
But what really shocked me is how amazing GL.Inet support is. I think they're probably the best support people I've come across, helping me track down an issue I've had for months with an Aqara doorbell that intermittently goes offline, suggesting configuration changes, even logging into my router (with my permission) to diagnose things. Don't have to register an account in any support system or forum either, can do everything over email. Complete opposite to pretty much every networking vendor I've encountered both low end and enterprise.
- myself248
Checksum offload, recalculating a bad checksum after corrupting the data, is really insidious.
Shows that trust in TCP can be badly misplaced -- in this case the trouble was cache coherency, but lack of ECC RAM or other electrical gremlins could easily corrupt packets too (and NIC buffer RAM is never ECC afaik), and blindly trusting TCP checksums would eat your data every time.
(Side note, doesn't 'zfs send' blindly trust TCP checksums?)
Props to Rsync and SSH and Wireguard and everything else that went beyond the call of duty to keep your data safe, with varying levels of alertness.
- cataflam
Great write-up!
Not surprised by the driver software quality issues. When I was still working in consumer electronics / embedded, I saw many examples of the internals of those devices. The software was often a hodgepodge of scripts and drivers, whatever seemed to work, from companies without a great software and details culture.
We would usually rewrite the drivers entirely from the datasheets or from reversing the vendor ones!
- circularfoyers
> I have the Cyber Verification Program enabled on my account, which hasn't helped.
This is funny to read. Either you can be more "verified" than the other guy, or it's badly implemented.
- nticompass
Does TP-Link just make buggy stuff, or are we just unlucky? I used to have a TP-Link WiFi 6E router, that I used as an access point and a switch (the "routing" was disabled since I use another router).
For whatever reason, that device would drop packets if they were VLAN-tagged. Other packets were fine, but anything to do with VLAN just didn't work. Took me a while to figure out that was the issue and it wasn't with the machine I was trying to configure.
I sold that thing on eBay and replaced it with a "real" access point (and a PoE switch).
- InsidiousWombat
Shopping for new router/AP should start with looking at OpenWRT, it's just a lottery relying on vendor hardware.
- mrheosuper
Wait TP-link EOL their fancy Wifi-7 router. Jezz how long do they support their product, 1 month ?