Wanted to download an ISO, ended up writing a kernel exploit

> 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

!!

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).

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.

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.

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!

> 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.

Shopping for new router/AP should start with looking at OpenWRT, it's just a lottery relying on vendor hardware.

Wait TP-link EOL their fancy Wifi-7 router. Jezz how long do they support their product, 1 month ?

So what is a good router nowadays? I'm about to buy one and I'm not looking towards this particular rabbit hole.

This is why I use openwrt where supported.

It’s cool but couldn’t you return the broken hardware to the store?

> TLS, which rejected the record with bad record mac.

Does TLS (transport layer) not have any retry logic? Could someone explain please?

I have done some similar work.

First, when Claude refuses I sometimes continue with Kimi or DeepSeek. They are less squeamish. Alas, the combination of C + kernel reliably makes Claude freak out: because of all the UB any tiny error becomes a security hole. (I have the cybersecurity verification stuff from OpenAI and Anthropic but they are still fairly strict.)

Second, contributing directly to the Linux kernel has never been easier. Claude knows all about how to interact with the archaic kernel mailing lists. The main rule I suggest: put in real effort, don't dump AI slop.

However I mostly worked in fixing filesystem bugs so far. I don't know whether the networking and DMA folks are as nice. But probably yes.

(Coincidence: the isofs filesystem code in the kernel is full of tiny holes as far as I can tell. I've patched some of them, but better don't try to mount a malicious CD image.)

[flagged]

[flagged]

[flagged]