Hacker News

Step one is not to buy TP-Link routers.

I know people have limited budgets, but having seen the code that sits on these devices and how poor quality and easily exploited it is, time and time again, I'll never buy TP-Link (amongst others) again.

For a while I collected a graveyard of routers that had been abandoned by the manufacturers (and contained serious vulnerabilities), with the intention of writing them all up one day; next thing you know I have two children rapidly reaching double-digit ages, and much better things to do with my life than write about how shitty the code is on actual products we buy every day.

I switched, about 7-8 years ago to a Protectli box running Coreboot and OPNSense and haven't looked back; I use Ubiquiti APs and switches. I'm not saying they're the best, but anything used in corporate/enterprise is going to have better support (if not better code quality).

The great thing about Ubiquiti APs for me is that each new WiFi generation (or two) I can just buy a few more, snap the existing APs off of the various ceilings they're attached to, snap on the new ones, adopt them, and away we go.

Hardware offload bugs are bane of NICs since hardware offload was offered (and that does include pricy enterprise ones, not just your random consumer one) and it can be drivers but majority it is on hardware/firmware side so I wouldn't be too crossed on TPLink for that one.

I wonder if EU push for basically 5 years of mandatory updates will make it better. Then again this isn't security bug but functional one...

IF you don't accept hardware that doesn't work correctly you'll never have certain types of hardware (I've not seen an ethernet card nor storage controller that didn't have SOME weird edge-case bug).

> 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

> !!

I was shocked when this happened to me. My company had a Dell switch kicking around in storage. It was a Dell Powerswitch Somethingorother_b. Big, expensive, enterprise switch. I went to set it up and found that I couldn't find the manual for that model online. Dell told me they only made a Somethingorother without any suffix. But we had records of buying it straight from them.

Apparently it happens. I have no idea how.

I’m running Flint 3 and an Aqara doorbell and have noticed intermittent doorbell offline messages. I just assumed it was flaky wifi or 2.4ghz congestion. If you do track down a bug or a solution please share it!

> even logging into my router (with my permission)

This is exactly why I want to migrate to a OpenWRT router, companies should not just be able to hop in my network like this. And I'd love to like the Flint 3 I stayed away from it because it didn't have upstream openwrt compatibility but I just saw this repo that might fix my issue: perceival/openwrt-flint3

They release new models and completely abandon the old ones. You are happy now. Have you asked owners of Flint 1 (or other older models), how they feel now?

Agreed, fun to read. Spite driven development. Reminded me of that Asus ACPI issue that somebody went buckwild on last year, or when Tavis Ormandy decided that xterm on windows took too long to launch.

https://github.com/Zephkek/Asus-ROG-Aml-Deep-Dive

https://cmpxchg8b.com/slowterm.html

Thanks for sharing. Do you have any blog or other links about this kind of research and the re-writes? I don’t work in the field so I feel modern chips are way too complex so it is not commercially viable to reverse and rewrite the drivers, but apparently I’m wrong.

Last week I got a report about a vuln in one of our products. Asked Claude to confirm it. It refused, so I told it "fuck you, I'm switching to a chinese model to help me out here". It replied, I'm paraphrasing, that it's "not offended, but doesn't like the tone of voice I used towards it, and still refuses to serve my request". Fine, so be it. I sent ^D^D back to it, switched to deepseek-v4.1-flash from within opencode and a minute later had my confirmation, along with a really nice explanation. If Anthropic thinks even for a second that they are preventing something really bad from happening... somebody needs to wake up real quick.

Anthropic doing free advertising for glm and other open models :D

Impressive capabilities shown on benchmarks don't really make a difference if you can't use them. I'll take a lower chance of success over constant downgrading and refusals. At least, as the author put it, you get to enjoy the token gamble exercise.

They have 3 tiers, individuals can have only blue teaming. But it's to restricted. For me it refused to fix a bash parser cause word ssh was in test cases.

Or fix an sql injection

I am in CVP too as I have worked professionally as a security engineer for various reputable companies for almost 10 years now and I got refusals to reverse engineer MS-DOS malware from 1994 because Anthropic has placed a blanket ban on reverse engineering any malware at all. Even the model would admit that was ridiculous.

OpenAI has no such restriction and I don't even need to use my Daybreak access, either, to analyze modern malware samples.

It's asinine, truly.

There are multiple degrees of verification. The basic one is “writing secure code”-style, which I suspect OP has. There’s also a security researcher one, which allows you to do the stuff that OP is doing.

0xdeafbeef or arcfour - Short of the CVP from Anthropic, would love to know if Mistral Large 4 would solve what you needed...

It is indeed amazing how all the WiFi APs suck, wether it is hardware, software or both.

> (Side note, doesn't 'zfs send' blindly trust TCP checksums?)

No.

https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Data...

> End-to-end checksums are a key feature of ZFS and an important differentiator for ZFS over other RAID implementations and filesystems. Advantages of end-to-end checksums include:

> [...]

> - checksums on ZFS replication streams, zfs send and zfs receive, ensure the data received is not corrupted by intervening storage or transport mechanisms

Edit: Also, as Asmod4n points out in a sibling comment, neither zfs send nor zfs recv actually transmit or receive any data. They just generate a data stream that you are then responsible for handling somehow (piping to e.g. ssh, redirection to a file, etc).

> Streams are checksummed, so corruption introduced by the network or by intermediate storage is detected on receive.

https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Oper...

I've set up all NFS mounts within my home LAN over WireGuard partly for this exact reason. The impacts to bandwidth and latency are negligible, and even the increase in CPU usage remains relatively low (at least on non-ancient hardware). This reduces some of my worries about silent data corruption (at least from this potential source).

zfs send/recv doesn’t do networking on its own?

Well, they EOL’d their early–release WiFi-7 router that came out before WiFi-7 was even finalized, and simultaneously released one that they have spent an extra year debugging. Presumably they fixed the firmware bug that fixes the synchronization problem, or switched to a different implementation. It’s a really bad idea to buy early products like this since.

This is standard tp-link policy. They release a model, give it almost no support, then release a new revision a year later with incompatible hardware and then the old one is never updated again.

If a product never got a firmware update during its support window, was it ever supported to begin with?

It was EOL from the factory. 0 updates. But other routers I "own" receive updates regularly so I guess I won some lottery.

This is why I check OpenWRT compatibility before I buy.

Do you update the kernel every week? Linux is an awful choice for routers: too many exploits and ultra fast cycle of updates/features plus there are number one target...

Nope. It was bought in the other country, tplink said to return it where it was bought. I don't even remeber where it was :)

I start from the OpenWrt devices page. Filter by the Wi-Fi revision I need (ac or ax), opt for 4 cores or more and sufficient RAM, and then read the forum posts and the device page to make a shortlist. Then I look at price and availability.

Pretty happy with my Asus RT-AC68U. I bought it like 8 years ago and they keep putting out firmware updates.

Before that I briefly had a Netgear Nighthawk R7000P and it kept interrupting long-running TCP connections. After much back-and-forth with their useless warranty department, I just returned it to the retailer.

Find a decent embedded system & put Linux on it. I've been using that setup for 20'ish years now & have never regretted it.

See also: pfSense, OpenWrt

I really like my Cudy Wifi routers. They can run upstream openwrt (double check your version). They run some modified openwrt.

They're both cheap and quite good. They're what GL.inet used to be when i last purchased routers before this.

TLDR: Any standard PC with two or more Ethernet interfaces and OpenBSD with PF.

I like the small Qotom Q305p 3205u computers for this, but any small device will do and if you don't care about the router being small and quiet, any form factor PC will work... just need two or more NICs to route packets from one network to the other.

TLS uses TCP, and TCP has checksums and retry logic. It therefore assumes any data corruption that made it all the way to the TLS layer is an unrecoverable scenario, probably indicative of an attack.

The problem here is that the thing computing the TCP checksum on the outgoing frame was the WLAN firmware running on the WLAN NIC itself; this is known as checksum offloading. It saves CPU time if the CPU can just hand off a TCP segment to the NIC and let the NIC checksum it before it sends it out. This only works properly if the data given to the NIC doesn't get corrupted in the meantime.

You do _not_ want to have multiple retry layers if you can help it. That can result in accidentally DoSing yourself, as each layer amplifies the number of retries.

TLS over TCP assumes TCP supplies a reliable uncorrupted stream of data. So it has no retries of its own, and terminates the connection when invalid data arrives.

I assume DTLS and QUIC handle MAC verification failures gracefully, like ordinary packet loss.

TLS expects a reliable connection, if the data are corrupted, that means some is tampering with the connection. It's best to avoid retrying until the tampering succeeds.