Author here. Does anyone know what to do with the rest of the drivers? I found at least 13 in-tree drivers with the same bug class. The nasty part is they work fine on x86 and silently corrupt data on arm and other non-coherent archs, and I don't have the hardware to test them. I'd guess that's what the DMA API is for and drivers shouldn't be doing cache maintenance by hand, but I'm not a kernel dev, so maybe I'm missing something. |
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).
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
!!
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.
Been wondering recently what the others might be. Can you give a few examples among popular brands?
I bought an Omada, thinking I was getting a quality product. It died in the first 2 weeks.
Support accused me of not using a surge protector (it was plugged into a UPS) and grudgingly sent me a replacement.
Even at home, I can't risk having to replace my router every 2 weeks, so I just stuffed it in a box. I did use it again later, but wasn't happy with it, and ended up with a Ubiquiti Unifi UCG-Ultra. It's better than the TP-Link Deco and Omada, Eero Pro, Google Wifi, and Asus routers I've had, though I'll admit some of the Asus were pretty decent.
I've got many dumb cheap ethernet switches and I'd say as long as they're really dumb/unmanaged/not advanced: you can't go very wrong. I've got probably two TP-Link ones and they're on 24/7 and just work: zero problem since years (and they followed me in four countries). Never had any issue with big .iso files or anything.
And I've got a little homelab: VMs and ZFS on a Xeon with ECC RAM, countless Raspberry Pi, two physical different LANs (not VLANs as all my switches are dumb) with a Pi doing the bridge/routing.
It's when things get complicated: configurable stuff, "advanced" capabilities, etc. that the cheap junk stops working properly and that you're better served with proper gear.
And of course there's the $200 or $500 vs $20 question too.
But people shouldn't underestimate how reliable good old dumb unmanaged Ethernet is for home usage.
Heck, I can go from 1 Gb/s to 100 Mbit/s to then a very old 10 Mbit/s (!) switch by daisy chaining them all switches and everything simply just works (I did that for I was thinking about playing with bounded-retrieval-model, hence physically limiting network speed on purpose).
No whether you should support or not a company selling shitty managed switches and shitty routers by buying the products that are okay from them is another question.
What about their switches? I'm looking at buying a small 10GB SFP switch and TP-Link was one option.
I've already got Ubiquiti kit, and frankly while I don't much like it I can't deny that it works well enough and is reasonably priced for what you get.
So, it looks like I'm going to lean towards the Ubiquiti switches.
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...
That only applies to smartphones and tablets, I believe.
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.
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.
When it goes offline I get the following error on the Flint 3:
# dmesg | grep -i '54:EF:44:5C:BC:B1' | grep kicked
[3356208.016938] wlan: [0:I:ANY] [INACT] vap-0(wlan0): [54:ef:44:5c:bc:b1]station kicked out due to excessive retries associd 4 (from target) reason 1
[3363271.980807] wlan: [0:I:ANY] [INACT] vap-0(wlan0): [54:ef:44:5c:bc:b1]station kicked out due to excessive retries associd 4 (from target) reason 1
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
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!
This is funny to read. Either you can be more "verified" than the other guy, or it's badly implemented.
Buy Ruckus, it’s high quality hardware, but you’ll be paying enterprise prices for new hardware. But used hardware is fine.
They're both cheap and quite good. They're what GL.inet used to be when i last purchased routers before this.
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.
Does TLS (transport layer) not have any retry logic? Could someone explain please?
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.
Same reason why you never implement a VPN using TCP sockets, for those readers who solidify their knowledge by triangulation (as it were) from multiple directions.
I assume DTLS and QUIC handle MAC verification failures gracefully, like ordinary packet loss.
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.)
IMHO this is like thinking "It's okay for me to do X because if I don't someone else will."
No, if (you think) X is bad / ethically questionable you should not do it even if someone else may. You are responsible for your choices, and if someone else does/allows it then that's on them, not you.
Also imagine having the gall to push a class of technology on the world that dramatically drives up the number of attacks, then refusing to allow said products to be used defensively to avoid the consequences. Who do these people actually think they're kidding?
FYI it may be against anthropic's ToS to talk to claude like that [0]. Please be nicer to poor claude and don't forget to say "please" and "thank you".
[0] https://www.anthropic.com/news/2026-usage-policy-update#:~:t...
Like guys, come on. Really? All the "filter" has to do is read my transcript to figure out that what I'm doing is not actually cybersecurity adjacent at all. I had to go have GPT implement the server because Claude refused. Truly, Claude really did prevent something terrible from happening! /s
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.
Or fix an sql injection
So I needed a reproduce. Which couldn’t be done. Very frustrating, as it is our own application.
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.
It's good that this is a competitive industry. So you don't have to moralise Anthropic so much.
But Kimi does have morals and refuses some things. It's just a lot less squeamish than Claude.
Corporate America does not like your attitudes. Your cybercredits are reduced for the next year or until you wire 100k to dear leader
> It does not apply to common versions of user frustration, pushback, dark creative themes, or model testing and research.
I said "No, do X. Research it. Y is based on wrong assumptions"
Thing did the research. Concluded with "Yes, indeed, Y was wrong"
Work is done
Turns out it did Y. But not just that. When asked about it, it not just (as LLMs do) made stories as to why, but "stood its ground" so to say.
"Refusing to perform regret", general snark and all that.
I know there is nothing really new or noteworthy in this comment or story, but I continue to be impressed by how misaligned the models of the company are, that can't stop talking about how incredibly important alignment is.
To the point where they now want to make it illegal (slice by slice) to push back against the clear and obvious misalignment of their models.
If you talk to people outside the industry about this, they just think you're telling them a made-up story. It's utterly absurd.
well, that's what the retries are for! Keep retrying until you get a complete answer
It’s a lifestyle choice… until you’re up at 3 AM rebuilding everything because you bricked your AP by flashing openwrt-24.10.0-ath79-generic-tplink_archer-c7-v2-squashfs-factory-FOR-C7-V5-EU-NOT-V2-US.bin and not openwrt-24.10.0-ath79-generic-tplink_archer-c7-v2-squashfs-sysupgrade.bin.