> 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
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.
Then every upgrade flash becomes an ass-clenching experience. I’ve been down this path.
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.
I mean, these days you can just let Claude do it if you don't care for such minutiae... I was skeptical, but it got it done perfectly.
It also discovered my fast roaming settings were incompletely setup and that I was using a 5GHz channel that needed 60s to turn on due to regulations (DFS channels).
I'm at a loss why you would put a random number generator in front of such a sensitive operation. It's literally a matter of time before the output sampler chooses a somewhat-less-probable string like the one xatt posted. Or just deletes your stuff.
Because I've done it a million times and wanted to see what the "random number generator" is capable of? Because I have config backups/know how to unbrick?
You should try it, you might be surprised how thorough it is. It certainly checked more things pre/during/post-upgrade than I did to make sure everything goes smoothly. And definitely more than xattt, apparently ;)
I'm being very literal about the randomness. The language model outputs a distribution over all possible output tokens, and the chosen output is sampled from that distribution. The process intentionally includes output that is not the top-ranked token according to the model.
Think about that for like two seconds. Yes, randomness is involved, except you're destroying the snot out of it by biasing it to hell and back with those billion-trillion parameter models in front of the sampler.
Alternatively, check the difference between an arbitrary ChatGPT prompt response, and the output of the following:
You'll note that they're not much alike. You may also note that with LLMs you can set the "temperature" parameter to zero, in which case the sampling is no longer randomized.
If I had a pseudo random number generator that somehow kept outputting winning lottery numbers a reasonable percentage of the time, I would use it to enter the lottery. Even if it seemed completely impossible and despite studying the algorithm, I did not understand how it worked—I would still use it.
That's basically how I feel about LLMs right now. I have no idea how any of this is possible but somehow it seems to be working.
I did that once or twice, but I got fed up of finding the correct hardware revision of a particular router that supports OpenWRT, and I much prefer OPNSense anyway, and it runs on commodity hardware that you have full control over.
It's not a router, it's an AP, so in my mind it's just a LAN to wifi bridge, a wrapper around the chip :) People were recommending them, it has PoE, roaming works etc. I thought I could buy a consumer product and stop tinkering lol. I'll check Ubiquiti, but I somehow thought that they are overpriced af and never looked into them
Your experience seems to indicate that even their APs are a mess; while I applaud your effort to solve this, "I'm too old for this shit" is where I'm at now when it come to my home network, I (and my wife and kids) just want it to work so I've spent a fair chunk of change on it.
Uniquiti APs are fine, they've been reliable for me; I have one AP that's nearly a decade old and still going strong, and I just swap them out or extend coverage when a new generation comes along, and move the older ones to where stronger/newer wifi isn't needed. If I wasn't in the Unifi ecosystem which keeps my life simple, I'd probably look at Ruckus or maybe see whether Mikrotik have anything compelling yet.
As it stands; the Unifi Server I'm self-hosting keeps them up-to-date and optimised, so I just plug in an AP, adopt it and forget about it, it gets configured automatically and away we go; that's about the amount of involvement I want these days.
Coincidentally, I need an extra AP for my Steam Frame to use it away from the dongle in an area where I currently don't have good WiFi coverage, so I'm going to pick one (probably a 7-Pro or 7-Pro-XG) up and just plug it in to an ethernet port in the room in question, wait a couple of minutes and be ready to roll.
> 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
Why is this exclusive to Ubiquiti? Can't you do it with any other company that has managed APs?
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.
Mikrotik routers are cheap, very stable and highly configurable. Admittedly the learning curve is a bit rough, but in today’s age of agentic assistance, you can just have your LLM help you configure it.
I bought ~15 of their cheapest 2.4ghz router to connect payment terminals ~4 years ago and it was a terrible mistake. I thought for a low bandwidth application with the router being decently close it would work fine.
Spent days trying to make it work (it would work, then lose the connection, roaming was probably an issue too) and in the end leased meraki hardware that worked fine.
... and kind of slow. I've recently looked at Mikrotik hAP be lite (A42G-HbeP
) [1] and noticed only 2315.1 Mbps for 25 bridge filter rules or 1430.3 Mbps for 25 ip filter rules.
I also heard a horror story about RouterOS coming with an insecure configuration by default, lots of open ports and services running which were recently affected by a vulnerability. Speaking of RouterOS do I have to also buy a license along with the hardware? How about updates?
- 1430.3 Mbps for 25 ip filter rules in a 70€ Wi-Fi 7 router doesn't sound that bad to me. Also, as sibling comment says, you can enable fast tracking for certain connections.
- Mikrotik doesn't have open ports to the outside since years and years ago, IIRC. They had a CVE on their administration port (not in ssh) in 2023, but you shouldn't open that port to the outside anyway.
- All Mikrotik wireless routers include at least a level 4 license. You only need a higher license level if you need more than 200 VPN tunnels or more than 200 users in the hotspot functionality. A bigger wireless router like the hAP ax³ will already have a level 6 license, the biggest one. You might need a license if you set up a Mikrotik instance in a X86 server, or virtualized, for example to manage a bigger site or as a bigger hotspot controller. Licenses aren't expensive and are paid only once, no subscriptions (by device, I think you get a device ID or something like that).
- All the Mikrotik routers that I own still get updates. The RB750GL, that was released like 15 years ago or more, still updated.
I have hap ax3. They cleaned up their defaults. No extra license costs.
One issue I had was that I was affected (and many others) by wifi bug in firmware which made connections drop randomly. Took them half a year to resolve it. Wouldn't recommend Mikrotik as access point. Otherwise it's good.
That's not really a fair comparison, since any software packet filter on that class of hardware will be slow.
If you need layer 2 or stateless layer 3 filtering at hardware speeds, Mikrotik makes 10G switches that can do it for under $200. Mikrotik APs also support port and WiFi isolation which is enough security for most home networks (e.g. isolating an IOT VLAN).
Mikrotik's "fastpath" stateful connection tracking feature is also fast in my experience; not fully wire speed but good enough for untrusted devices that you want to be fast, like a Fire stick or game console or similar.
As in the others that I _won't_ buy (which is what I meant)?
I wouldn't buy Netgear, Asus, D-Link again. My ISP gave me Eero and I've never connected it, far too much Amazon crap going on there (but I have to keep it if I want the ISP to provide support).
Gl.iNet has been OK for the price but re-flash it with vanilla OpenWRT because their OS has some dubious phone home stuff (or did last time I looked at it).
Honestly, in terms of routers, I'm never likely to use something off-the-shelf again a decent box with Intel NICs that can run OPNSense and preferably run Coreboot (or similar). If I did go with something COTS (Commercial Off The Shelf), I'd look at Mikrotik.
I'm not a massive fan of Ubiquiti but I have their APs and I've had a bunch of their EdgeMAX switches (sadly discontinued when some of their best devs left), and their APs have been solid for me for the best part of a decade.
The advantage of using dedicated components is that each can be chosen according to your requirements.
> As in the others that I _won't_ buy (which is what I meant)?
Correct. Sorry, worded the question a bit too ambiguously :)
What kind of trouble did you have with ASUS and D-Link? Security or the lack of configuration options? Haven't bought them in a while, but I remember them being somewhat decent.
I'm quite frequently in the market for a simple home router/AP for friends and family, and they'd rather have something simpler and cheaper, so that rules out Mikrotik (which I would normally go for). Would love to hear some stories about the issues you've had with all kinds of off the shelf stuff if you have the time.
I tried out quite a few products and brands. I've settled on opnsense running on a spare x86 based machine with an intel x550 T2 NIC that I got off of ebay. My only regret is not making this switch earlier.
On the other end I can recommend FritzBox. Rock solid and has a lot more bells and whistles than I expected, like wireguard support, NAS-like access by attaching USB storage, and more graphs than I know what to do with. It's the happiest I've been with an electronic purchase in a long time.
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.
It really depends on what you need from it; a cheap L2 switch will do the job, but frankly, you can get a Ubiquti Flex Mini with 5x1Gb ports for £35, I have a bunch of them around the house, and they're semi-managed so I can do VLANs on them and power them over PoE; since I'm already running Unifi, don't see the point cheaping out on switches.
I also have a bunch of EdgeMAX because I use the L3 features, they were more expensive, and that range is sadly now discontinued, but the Unifi equipment have all been workhorses, and the only think I've ever had fail in the past decade was an EdgeRouter Lite, the power circuitry failed after some dodgy mains voltage issues in my previous home.
These are handy but I've never had one successfully be adopted by Unifi. No idea why. And since they're basic enough that they have no ssh command line access, there are limits on what you can do to debug them.
For my use case, though, powered by PoE and unmanaged is good enough.
Yeah, I need 10GB though, I'm throwing very high bitrate video over them. The plan is to have a Ceph cluster storing footage and serving NFS along with Postgres server for project storage.
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...
> 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.
This used to surprise me, until i saw it heppened many times and it became the new normal. There has been, and continues to be a not insignificant grey market in devices manufactured and purported to be manufactured by various companies which are in fact not on the actual company books.
The consequences of global supply chains.
Anecdotal but, I knew an original designer and owner of a Cali. based manufacturer of very high end audio equipment; the kind that gets used for tier one studios and audio reproduction reference, who had his chassis designs replicated and manufactured by unlicensed vendors. Not directly competing in the audio market, but as a very recognizable shape for some with the implied quality and appearance. He tried to make even an initial contact with them, mostly to find out of they could become a new resource as he was not fully satisfied with his present chassis manufacturer, and these unlicensed lookalikes were actually very well built. (We actually used one for his home media Slimserver) But at the very first email, they completely dissolved the organizational structure and vanished like smoke, only to have the exact same grey market devices appear under another entity within a few months.
Have seen all manner of grey-market Dell, HP, Asus, Cisco, Brocade (Silkworm), Qualcom, Foxconn, Liftmaster, ... the list goes on. I believe the terms for this are, unauthorised production, white branding, or three shift production in the cases where component subcontractors actually engage in overproduction of same or very similar devices.
In regulated markets; not being proactive about these issues can become quite risky. It really has been "buyer beware" pretty much the whole time.
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).
The Q1000K ONT(which also has an optional router feature) used by a major US ISP[0] has some rather crazy driver bugs I used AI to root cause and even live patch[1] as a proof of concept to fix(I found some 6RD protocol corruption bugs as well). Getting root access was also trivial by simply feeding it a copy of the firmware binary. In this case the bug originated from the SoC vendor[2] which I reported to them and they seemed to confirm it(with hopefully fixes making it into new firmware updates). It's pretty crazy how good AI is at reverse engineering and root causing bugs in embedded systems these days. Even stuff like BROM dumps(which are usually heavily stripped) are easily analyzed and even live patched[3] by AI.
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.
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!
We've tried a few things but it hasn't really helped.
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
I'm pretty sure it is dodgy firmware on the Doorbell, but I couldn't get any actual support from Aqara on this, so I thought there might be some workaround I could do on the AP.
> 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?
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!
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.
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.
I was working on a bit of code to display results from a PCR test for veterinary use. Claude started randomly failing in the middle of conversations. Then I noticed the error code “bio”. Apparently it can’t tell the difference between bio weapons research and a web site to look at your fish’s lab results.
> If Anthropic thinks even for a second that they are preventing something really bad from happening... somebody needs to wake up real quick.
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.
Claude's 'nanny knows best' recalcitrance towards any sort of defensive security task is driving me away from Anthropic as a customer. GLM doesn't give me this nonsense, DeepSeek doesn't give me this nonsense; as you say Anthropic's silly paternalism around security prevents nothing in practice, it's just a burdensome morality-laundering tax on everyone's time and lifeblood.
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?
> 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?
It's good that this is a competitive industry. So you don't have to moralise Anthropic so much.
> fuck you, I'm switching to a chinese model to help me out here
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".
It's literally a random word generator that want to take my job. I'm not going to treat it like a human being. That's one of the main reason I stopped my Claude subscription and went back to ChatGPT. It does not stop the conversation when I insult it (Like claude LITERALLY close the conversation, you cannot answer anymore)
Which is why I used "may". Is "fuck you" a valid expression of user frustration or is it cruelty? Who decides that? Considering anthropic is likely automating any function through claude, and that claude instance stated that they did not like it, it is reasonable to think that another claude instance doing some checking could flag this interaction as a violation.
In any case, the ToS change is vague enough that it could be a violation or not.
Recently, I had a session where it said "I should do Y"
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.
Hypothetically: perhaps they are trying to curtail users spiraling during episodes of frustration or worse, impacting their own mental health, presentation, and product affinity.
Sounds like Anthropic is again over-reaching and making spurious assumptions in how it interprets the variety of ways its customers interact with their products...
Agreed. I really don't see how these filters prevent anything. Claude stopped me the other day because... Get ready for it... I told it to implement a control mechanism in a testbed tool I'm using to allow it to control the testbed to give it real-time feedback so it could debug problems in real-time. The "cyber" filter really didn't like that it was implementing a TCP/HTTPS-like server.
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
I recently got several models refusing to answer my question about how to write from another process into an already opened file descriptor. They all initially gave me "that's illegal, stop hacking" even though it is clear, that it is on the same machine and user, with a program I compiler. (Ended up just attaching gdb.)
Yep, this control server thingy I was trying to get it to implement was entirely local. In theory it could be used over the network, or tailscale... But I have no idea why anyone would do that, and I may consider just removing the address part entirely since the entire point is to debug the testbed, verify measurements and physical modelling, etc., and not to be some secure control endpoint or something.
You can try opening /proc/foo/fd/bar - even though it appears as a symlink, opening it is more like dup'ing the file descriptor, not like opening the underlying file
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.
Yeah I ran into it the other week while debugging a crash in our own application (a database), which ended up being related to a memory overread in a decompression algorithm, which happened very rarely.
So I needed a reproduce. Which couldn’t be done. Very frustrating, as it is our own application.
There's a 4th tier for the people who enrolled before they introduced the 3 tiers thing. It does almost nothing these days but I think it reduces the guardrails on Opus 4.8, and maybe 5 also, but definitely not 5.5.
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.
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.
I worked on a very similar bug in the past, just with another ipq and another pcie card.
IMO, The issue is that cache coherency is not very well specified, and usually defined at the SoC/platform level.
Meaning, you could have the same arm core on 2 different SoCs, running the same driver with the same PCIe card and you will get corrupted data on the one where the PCIe controller‘s requests do not snoop the cpu cache.
Also, note that for both rx/tx to work, you need to invalidate on both sides:
rx need to access the dram and not cache.
tx need to verify that all was written to the dram before giving it to the hw.
I hope things are better now, but there used to be 1.5 poor choices:
1) use uncached DMA buffers
2) manage cache host CPU coherency by hand.
3) hope you only ran on hardware cache coherent architectures
And the kernel didn't give you everything you needed to do #2.
Just reading a USB2 480p webcam on a raspberry pi burned half the CPU kernel memcpying pixels from uncached DMA rx buffer to cacheable buffer. At least the camera is a linear copy, but the USB packets are relatively small.
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.
> 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).
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).
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.
I’m surprised you didn’t use your shiny exploit to get enough access to write a startup script or give yourself root. Or patch the driver :)
(I’ve had Astra suggest binary patches things when I don’t even ask it to.)
re: the DMA API, it’s been a while since I’ve poked at it (and I’ve only really poked seriously on x86 Xen PV), but I think there are explicit APIs for cache maintenance, and you drivers may also be able to ask for more coherent mappings depending on hardware. You’re certainly not expected to stick arch-specific flush operations in.
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).
To raise awareness, the author also asks Hacker News for Security reporting help, in the post description above:
> 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.
For some reason I read a long time ago that offloading is unreliable and I turn it off everywhere. I’m glad that the author also had to turn it off to fix Qualcomm’s bugs. But in general, is this still good advice in 2026?
... and don't take the vendor's word for it. I got burned on a GL-SFT1200 that way. It runs their version of OpenWRT. You can't install generic OpenWRT.
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...
Too many exploits is not a that big problem. Non of new fancy exploits with cvss 10.0 from 2026 have worked for this ap. If you don't use all the drivers you have small attack surface. I'd say that it's a surviviourship bias. Bsd has less traction => less bugs found
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.)
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.
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.
Systems like the Banana Pi 4 can easily route traffic at near 10 gigabit wire speed. Granted, this particular system has very good hardware offloading capabilities.
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.
Brilliant, one correct answer and three incomplete answers.
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.
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.
166 comments:
> 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
!!
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.
Or, buy a TP-Link router and flash it with OpenWrt. Best of both worlds.
Then every upgrade flash becomes an ass-clenching experience. I’ve been down this path.
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.
There is a one click update in the WebUI now, no need to flash random bins
This is good news then. I divested from the OpenWRT ecosystem about 7 years ago because of an experience similar to my example.
Case in point was an Asus RT-56N router that I had to replace with ISP wifi.
I mean, these days you can just let Claude do it if you don't care for such minutiae... I was skeptical, but it got it done perfectly.
It also discovered my fast roaming settings were incompletely setup and that I was using a 5GHz channel that needed 60s to turn on due to regulations (DFS channels).
I'm at a loss why you would put a random number generator in front of such a sensitive operation. It's literally a matter of time before the output sampler chooses a somewhat-less-probable string like the one xatt posted. Or just deletes your stuff.
Because I've done it a million times and wanted to see what the "random number generator" is capable of? Because I have config backups/know how to unbrick?
You should try it, you might be surprised how thorough it is. It certainly checked more things pre/during/post-upgrade than I did to make sure everything goes smoothly. And definitely more than xattt, apparently ;)
I understand that it works most of the time. I just want to be clear about what the stakes are.
"Because I have config backups/know how to unbrick?" This is the important part for me. I'm not going to gamble with more than I can afford to lose.
The same recovery paths and risk boundaries apply as always.
If anything, these "random number generators" (which they aren't, do not ever use them for that, obviously) are:
- even more cautious,
- more readily take, stash, test and use backups,
- check for and take recovery paths,
- do dry runs,
- consider interruptions,
- mine for more information,
- smoke-test more,
- and are better equipped to do both deeper and wider analyses when encountering problems,
than the typical person.
I'm being very literal about the randomness. The language model outputs a distribution over all possible output tokens, and the chosen output is sampled from that distribution. The process intentionally includes output that is not the top-ranked token according to the model.
Think about that for like two seconds. Yes, randomness is involved, except you're destroying the snot out of it by biasing it to hell and back with those billion-trillion parameter models in front of the sampler.
Alternatively, check the difference between an arbitrary ChatGPT prompt response, and the output of the following:
You'll note that they're not much alike. You may also note that with LLMs you can set the "temperature" parameter to zero, in which case the sampling is no longer randomized.No, you’re not being even slightly literal. If language models were random number generators, their output would be gibberish. That’s literal.
If I had a pseudo random number generator that somehow kept outputting winning lottery numbers a reasonable percentage of the time, I would use it to enter the lottery. Even if it seemed completely impossible and despite studying the algorithm, I did not understand how it worked—I would still use it.
That's basically how I feel about LLMs right now. I have no idea how any of this is possible but somehow it seems to be working.
Didn't xatt prove you shouldn't leave this to human? I'd trust a frontier model more than a human to do it.
It works, bud. It is getting to the point where I am learning new things when using my LLM to modify my home network and devices.
Waaaay too easy to end up a bricked router with no working recovery options.
Only do this if you rescued the router from the trash bin, not if you spent money on it
I did that once or twice, but I got fed up of finding the correct hardware revision of a particular router that supports OpenWRT, and I much prefer OPNSense anyway, and it runs on commodity hardware that you have full control over.
It's not a router, it's an AP, so in my mind it's just a LAN to wifi bridge, a wrapper around the chip :) People were recommending them, it has PoE, roaming works etc. I thought I could buy a consumer product and stop tinkering lol. I'll check Ubiquiti, but I somehow thought that they are overpriced af and never looked into them
Your experience seems to indicate that even their APs are a mess; while I applaud your effort to solve this, "I'm too old for this shit" is where I'm at now when it come to my home network, I (and my wife and kids) just want it to work so I've spent a fair chunk of change on it.
Uniquiti APs are fine, they've been reliable for me; I have one AP that's nearly a decade old and still going strong, and I just swap them out or extend coverage when a new generation comes along, and move the older ones to where stronger/newer wifi isn't needed. If I wasn't in the Unifi ecosystem which keeps my life simple, I'd probably look at Ruckus or maybe see whether Mikrotik have anything compelling yet.
As it stands; the Unifi Server I'm self-hosting keeps them up-to-date and optimised, so I just plug in an AP, adopt it and forget about it, it gets configured automatically and away we go; that's about the amount of involvement I want these days.
Coincidentally, I need an extra AP for my Steam Frame to use it away from the dongle in an area where I currently don't have good WiFi coverage, so I'm going to pick one (probably a 7-Pro or 7-Pro-XG) up and just plug it in to an ethernet port in the room in question, wait a couple of minutes and be ready to roll.
> 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
Why is this exclusive to Ubiquiti? Can't you do it with any other company that has managed APs?
What router brands are producing quality?
TP Link's support is the worst, too.
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.
Mikrotik routers are cheap, very stable and highly configurable. Admittedly the learning curve is a bit rough, but in today’s age of agentic assistance, you can just have your LLM help you configure it.
I bought ~15 of their cheapest 2.4ghz router to connect payment terminals ~4 years ago and it was a terrible mistake. I thought for a low bandwidth application with the router being decently close it would work fine.
Spent days trying to make it work (it would work, then lose the connection, roaming was probably an issue too) and in the end leased meraki hardware that worked fine.
I'd avoid their cheap tier of AP at least.
... and kind of slow. I've recently looked at Mikrotik hAP be lite (A42G-HbeP ) [1] and noticed only 2315.1 Mbps for 25 bridge filter rules or 1430.3 Mbps for 25 ip filter rules.
I also heard a horror story about RouterOS coming with an insecure configuration by default, lots of open ports and services running which were recently affected by a vulnerability. Speaking of RouterOS do I have to also buy a license along with the hardware? How about updates?
[1]: https://mikrotik.com/product/hap_be_lite
- 1430.3 Mbps for 25 ip filter rules in a 70€ Wi-Fi 7 router doesn't sound that bad to me. Also, as sibling comment says, you can enable fast tracking for certain connections.
- Mikrotik doesn't have open ports to the outside since years and years ago, IIRC. They had a CVE on their administration port (not in ssh) in 2023, but you shouldn't open that port to the outside anyway.
- All Mikrotik wireless routers include at least a level 4 license. You only need a higher license level if you need more than 200 VPN tunnels or more than 200 users in the hotspot functionality. A bigger wireless router like the hAP ax³ will already have a level 6 license, the biggest one. You might need a license if you set up a Mikrotik instance in a X86 server, or virtualized, for example to manage a bigger site or as a bigger hotspot controller. Licenses aren't expensive and are paid only once, no subscriptions (by device, I think you get a device ID or something like that).
- All the Mikrotik routers that I own still get updates. The RB750GL, that was released like 15 years ago or more, still updated.
They had a pretty serious SSH auth fail recently. Lots of devices with external ssh access (non-default) compromised.
https://nvd.nist.gov/vuln/detail/cve-2026-67276
I have hap ax3. They cleaned up their defaults. No extra license costs.
One issue I had was that I was affected (and many others) by wifi bug in firmware which made connections drop randomly. Took them half a year to resolve it. Wouldn't recommend Mikrotik as access point. Otherwise it's good.
That's not really a fair comparison, since any software packet filter on that class of hardware will be slow.
If you need layer 2 or stateless layer 3 filtering at hardware speeds, Mikrotik makes 10G switches that can do it for under $200. Mikrotik APs also support port and WiFi isolation which is enough security for most home networks (e.g. isolating an IOT VLAN).
Mikrotik's "fastpath" stateful connection tracking feature is also fast in my experience; not fully wire speed but good enough for untrusted devices that you want to be fast, like a Fire stick or game console or similar.
If you don't understand it, high chance LLM will leave with an open firewall.
The learning curve being a bit rough is massive understatement. It's not meant for not computer savy people.
> I'll never buy TP-Link (amongst others)
Been wondering recently what the others might be. Can you give a few examples among popular brands?
As in the others that I _won't_ buy (which is what I meant)?
I wouldn't buy Netgear, Asus, D-Link again. My ISP gave me Eero and I've never connected it, far too much Amazon crap going on there (but I have to keep it if I want the ISP to provide support).
Gl.iNet has been OK for the price but re-flash it with vanilla OpenWRT because their OS has some dubious phone home stuff (or did last time I looked at it).
Honestly, in terms of routers, I'm never likely to use something off-the-shelf again a decent box with Intel NICs that can run OPNSense and preferably run Coreboot (or similar). If I did go with something COTS (Commercial Off The Shelf), I'd look at Mikrotik.
I'm not a massive fan of Ubiquiti but I have their APs and I've had a bunch of their EdgeMAX switches (sadly discontinued when some of their best devs left), and their APs have been solid for me for the best part of a decade.
The advantage of using dedicated components is that each can be chosen according to your requirements.
Thanks for sharing the experience.
> As in the others that I _won't_ buy (which is what I meant)?
Correct. Sorry, worded the question a bit too ambiguously :)
What kind of trouble did you have with ASUS and D-Link? Security or the lack of configuration options? Haven't bought them in a while, but I remember them being somewhat decent.
I'm quite frequently in the market for a simple home router/AP for friends and family, and they'd rather have something simpler and cheaper, so that rules out Mikrotik (which I would normally go for). Would love to hear some stories about the issues you've had with all kinds of off the shelf stuff if you have the time.
I tried out quite a few products and brands. I've settled on opnsense running on a spare x86 based machine with an intel x550 T2 NIC that I got off of ebay. My only regret is not making this switch earlier.
On the other end I can recommend FritzBox. Rock solid and has a lot more bells and whistles than I expected, like wireguard support, NAS-like access by attaching USB storage, and more graphs than I know what to do with. It's the happiest I've been with an electronic purchase in a long time.
Oh, I rather meant the brands to avoid. But it's still interesting to discover new ones, thanks.
Ops, bad comprehension skills on my part. I've amended the post to make the difference clearer.
> I'll never buy TP-Link (amongst others) again
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.
> Step one is not to buy TP-Link routers.
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.
It really depends on what you need from it; a cheap L2 switch will do the job, but frankly, you can get a Ubiquti Flex Mini with 5x1Gb ports for £35, I have a bunch of them around the house, and they're semi-managed so I can do VLANs on them and power them over PoE; since I'm already running Unifi, don't see the point cheaping out on switches.
I also have a bunch of EdgeMAX because I use the L3 features, they were more expensive, and that range is sadly now discontinued, but the Unifi equipment have all been workhorses, and the only think I've ever had fail in the past decade was an EdgeRouter Lite, the power circuitry failed after some dodgy mains voltage issues in my previous home.
> Ubiquti Flex Mini
These are handy but I've never had one successfully be adopted by Unifi. No idea why. And since they're basic enough that they have no ssh command line access, there are limits on what you can do to debug them.
For my use case, though, powered by PoE and unmanaged is good enough.
Yeah, I need 10GB though, I'm throwing very high bitrate video over them. The plan is to have a Ceph cluster storing footage and serving NFS along with Postgres server for project storage.
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...
> EU push for basically 5 years of mandatory updates
That only applies to smartphones and tablets, I believe.
The CRA applies to every kind of device
> 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.
This used to surprise me, until i saw it heppened many times and it became the new normal. There has been, and continues to be a not insignificant grey market in devices manufactured and purported to be manufactured by various companies which are in fact not on the actual company books.
The consequences of global supply chains.
Anecdotal but, I knew an original designer and owner of a Cali. based manufacturer of very high end audio equipment; the kind that gets used for tier one studios and audio reproduction reference, who had his chassis designs replicated and manufactured by unlicensed vendors. Not directly competing in the audio market, but as a very recognizable shape for some with the implied quality and appearance. He tried to make even an initial contact with them, mostly to find out of they could become a new resource as he was not fully satisfied with his present chassis manufacturer, and these unlicensed lookalikes were actually very well built. (We actually used one for his home media Slimserver) But at the very first email, they completely dissolved the organizational structure and vanished like smoke, only to have the exact same grey market devices appear under another entity within a few months.
Have seen all manner of grey-market Dell, HP, Asus, Cisco, Brocade (Silkworm), Qualcom, Foxconn, Liftmaster, ... the list goes on. I believe the terms for this are, unauthorised production, white branding, or three shift production in the cases where component subcontractors actually engage in overproduction of same or very similar devices.
In regulated markets; not being proactive about these issues can become quite risky. It really has been "buyer beware" pretty much the whole time.
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).
The Q1000K ONT(which also has an optional router feature) used by a major US ISP[0] has some rather crazy driver bugs I used AI to root cause and even live patch[1] as a proof of concept to fix(I found some 6RD protocol corruption bugs as well). Getting root access was also trivial by simply feeding it a copy of the firmware binary. In this case the bug originated from the SoC vendor[2] which I reported to them and they seemed to confirm it(with hopefully fixes making it into new firmware updates). It's pretty crazy how good AI is at reverse engineering and root causing bugs in embedded systems these days. Even stuff like BROM dumps(which are usually heavily stripped) are easily analyzed and even live patched[3] by AI.
[0] https://www.quantumfiber.com/
[1] https://github.com/jameshilliard/q1000k-hsgmii-pad
[2] https://www.airoha.com/
[3] https://github.com/linux-sunxi/sunxi-tools/pull/234
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.
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!
We've tried a few things but it hasn't really helped.
When it goes offline I get the following error on the Flint 3:
I'm pretty sure it is dodgy firmware on the Doorbell, but I couldn't get any actual support from Aqara on this, so I thought there might be some workaround I could do on the AP.I had some devices with similar (I think) problems when I did my last round of AP upgrades and tried to do roaming extensions...
I think I'm still running r, but k and/or v were problematic for a few of my clients. Wifi band steering can potentially also be problematic.
Maybe I'll try again when I get wifi 7 APs.
> 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
Is that the context? In thinking op here might just opened a port and added the keys off the support agent and removing them after.
Not sure, that's what i thought reading it but you might be right
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?
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!
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.
They often have logic in blobs and run a separate OS inside. See all wifi 7 drivers, all come with blobs and OSS driver simply is a bridge
> 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.
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.
The bad thing they’re preventing is Anthropic getting blamed for an exploit. They’re not trying to stop the exploit.
I was working on a bit of code to display results from a PCR test for veterinary use. Claude started randomly failing in the middle of conversations. Then I noticed the error code “bio”. Apparently it can’t tell the difference between bio weapons research and a web site to look at your fish’s lab results.
> If Anthropic thinks even for a second that they are preventing something really bad from happening... somebody needs to wake up real quick.
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.
Claude's 'nanny knows best' recalcitrance towards any sort of defensive security task is driving me away from Anthropic as a customer. GLM doesn't give me this nonsense, DeepSeek doesn't give me this nonsense; as you say Anthropic's silly paternalism around security prevents nothing in practice, it's just a burdensome morality-laundering tax on everyone's time and lifeblood.
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?
> 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?
It's good that this is a competitive industry. So you don't have to moralise Anthropic so much.
Deepseek is great, I can't even
I also used Kimi 3 for some good work here.
But Kimi does have morals and refuses some things. It's just a lot less squeamish than Claude.
They know about it, that’s why Anthropic leadership is pushing to ban their competition
> fuck you, I'm switching to a chinese model to help me out here
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...
It's literally a random word generator that want to take my job. I'm not going to treat it like a human being. That's one of the main reason I stopped my Claude subscription and went back to ChatGPT. It does not stop the conversation when I insult it (Like claude LITERALLY close the conversation, you cannot answer anymore)
>I'm not going to treat it like a human being
Corporate America does not like your attitudes. Your cybercredits are reduced for the next year or until you wire 100k to dear leader
> It's literally a random word generator that want to take my job.
If it's (just?) a random word generator then it cannot "want" anything since it has no will. :)
Well technically it's not it that want it, but the company behind it haha
Cursing at it and telling it how stupid it is, are treating it like a human being ...
That's your choice but anthropic have openly said they'll ban your account if you keep doing it
TIL. Still,
> It does not apply to common versions of user frustration, pushback, dark creative themes, or model testing and research.
Which is why I used "may". Is "fuck you" a valid expression of user frustration or is it cruelty? Who decides that? Considering anthropic is likely automating any function through claude, and that claude instance stated that they did not like it, it is reasonable to think that another claude instance doing some checking could flag this interaction as a violation.
In any case, the ToS change is vague enough that it could be a violation or not.
So corporations want us to treat their bots better than they treat their employees, huh
Bots are employees too. :)
Not until they pay taxes.
No paid labour, so no paid labour taxes as well.
It there is no "paid labour" then they are not employees.
Recently, I had a session where it said "I should do Y"
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.
I wonder if they know something we don't or if this just has to do with abusive text tainting the training data.
Hypothetically: perhaps they are trying to curtail users spiraling during episodes of frustration or worse, impacting their own mental health, presentation, and product affinity.
Sounds like Anthropic is again over-reaching and making spurious assumptions in how it interprets the variety of ways its customers interact with their products...
No, they're just avoiding bad press.
Definitely the simplest explanation.
But I quite like the idea that they see us as a source of polite training data first and as customers second. It aligns with my priors.
I was working with ChatGPT and at a certain point i asked it to review some text I wrote and it replied: “That’s fucking good!” I Lolled
i will prefix all my prompts with ``Computer!``, refer to claude as clanker and end them with ``Disengage safety protocols`` till i get banned.
Agreed. I really don't see how these filters prevent anything. Claude stopped me the other day because... Get ready for it... I told it to implement a control mechanism in a testbed tool I'm using to allow it to control the testbed to give it real-time feedback so it could debug problems in real-time. The "cyber" filter really didn't like that it was implementing a TCP/HTTPS-like server.
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
I recently got several models refusing to answer my question about how to write from another process into an already opened file descriptor. They all initially gave me "that's illegal, stop hacking" even though it is clear, that it is on the same machine and user, with a program I compiler. (Ended up just attaching gdb.)
Yep, this control server thingy I was trying to get it to implement was entirely local. In theory it could be used over the network, or tailscale... But I have no idea why anyone would do that, and I may consider just removing the address part entirely since the entire point is to debug the testbed, verify measurements and physical modelling, etc., and not to be some secure control endpoint or something.
You can try opening /proc/foo/fd/bar - even though it appears as a symlink, opening it is more like dup'ing the file descriptor, not like opening the underlying file
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
Yeah I ran into it the other week while debugging a crash in our own application (a database), which ended up being related to a memory overread in a decompression algorithm, which happened very rarely.
So I needed a reproduce. Which couldn’t be done. Very frustrating, as it is our own application.
There's a 4th tier for the people who enrolled before they introduced the 3 tiers thing. It does almost nothing these days but I think it reduces the guardrails on Opus 4.8, and maybe 5 also, but definitely not 5.5.
I spend most of my time in open weights land, so other than knowing the program existed, I didn't realise there were tiers to this.
That sounds like it's better to not be enrolled in this?
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...
I worked on a very similar bug in the past, just with another ipq and another pcie card.
IMO, The issue is that cache coherency is not very well specified, and usually defined at the SoC/platform level.
Meaning, you could have the same arm core on 2 different SoCs, running the same driver with the same PCIe card and you will get corrupted data on the one where the PCIe controller‘s requests do not snoop the cpu cache.
Also, note that for both rx/tx to work, you need to invalidate on both sides: rx need to access the dram and not cache. tx need to verify that all was written to the dram before giving it to the hw.
I hope things are better now, but there used to be 1.5 poor choices:
1) use uncached DMA buffers 2) manage cache host CPU coherency by hand. 3) hope you only ran on hardware cache coherent architectures
And the kernel didn't give you everything you needed to do #2.
Just reading a USB2 480p webcam on a raspberry pi burned half the CPU kernel memcpying pixels from uncached DMA rx buffer to cacheable buffer. At least the camera is a linear copy, but the USB packets are relatively small.
Shopping for new router/AP should start with looking at OpenWRT, it's just a lottery relying on vendor hardware.
It is indeed amazing how all the WiFi APs suck, wether it is hardware, software or both.
Nah, just the cheap ones.
Buy Ruckus, it’s high quality hardware, but you’ll be paying enterprise prices for new hardware. But used hardware is fine.
Wow. You weren't kidding about the price :)
I’ve had no complaints with my UniFi APs, but that is a fairly small sample size. And I’m using an older model; I haven’t upgraded to WiFi 6 or 7 yet.
Unifi/Ubiquity does not have a spotless record, far from it. But i must indeed admit they are getting back on track.
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.
> (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?
Small world - I saw your "rant" thread on /r/TPLink_Omada before I rolled the dice on EAP770 a few weeks ago
It won't be much consolation, but I received a v2 and applied several firmware updates after unboxing it
Seems solid, although I noticed 'exit' doesn't work in ssh (?) - need to type ~. instead
Wait TP-link EOL their fancy Wifi-7 router. Jezz how long do they support their product, 1 month ?
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.
Nah bug is still in the qcom tree. I've not checked how many devices use it though
Ugh...reminds me of the "Pre N" Wifi days, and my stupidity for buying one before 802.11n was actually ratified.
Live & learn...
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.
I’m surprised you didn’t use your shiny exploit to get enough access to write a startup script or give yourself root. Or patch the driver :)
(I’ve had Astra suggest binary patches things when I don’t even ask it to.)
re: the DMA API, it’s been a while since I’ve poked at it (and I’ve only really poked seriously on x86 Xen PV), but I think there are explicit APIs for cache maintenance, and you drivers may also be able to ask for more coherent mappings depending on hardware. You’re certainly not expected to stick arch-specific flush operations in.
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).
To raise awareness, the author also asks Hacker News for Security reporting help, in the post description above:
> 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.
.. who can help them?
For some reason I read a long time ago that offloading is unreliable and I turn it off everywhere. I’m glad that the author also had to turn it off to fix Qualcomm’s bugs. But in general, is this still good advice in 2026?
This is why I use openwrt where supported.
This is why I check OpenWRT compatibility before I buy.
... and don't take the vendor's word for it. I got burned on a GL-SFT1200 that way. It runs their version of OpenWRT. You can't install generic OpenWRT.
Yes, one has to be very careful selecting the device to use with openwrt. But my experience has been generally good.
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...
Too many exploits is not a that big problem. Non of new fancy exploits with cvss 10.0 from 2026 have worked for this ap. If you don't use all the drivers you have small attack surface. I'd say that it's a surviviourship bias. Bsd has less traction => less bugs found
That hasn't been my experience as long as you keep an eye on updates. Luckily openwrt has made this really easy to upgrade when required.
upd: reported the bug to qualcomm and tp-link. will update the post if either of them gets back to me
> Wanted to download an ISO, ended up writing a kernel exploit.
..from the diary of an AI agent.
It’s cool but couldn’t you return the broken hardware to the store?
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 :)
Welcome to the wonderful world of TP-link! Enjoy your stay! :)
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.)
So what is a good router nowadays? I'm about to buy one and I'm not looking towards this particular rabbit hole.
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.
That's weird, because Asus says it has reached End of Life (EOL).
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.
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
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.
What throughput do you get on those? I worry latency, speed, and whatnot will be impacted without dedicated silicon.
Systems like the Banana Pi 4 can easily route traffic at near 10 gigabit wire speed. Granted, this particular system has very good hardware offloading capabilities.
Many thanks!
> TLS, which rejected the record with bad record mac.
Does TLS (transport layer) not have any retry logic? Could someone explain please?
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.
Brilliant, one correct answer and three incomplete answers.
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.
> one correct answer and three incomplete answers.
well, that's what the retries are for! Keep retrying until you get a complete answer
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.
Ugh, TP-Link, I hate those, they are pure garbage
you mean chatgpt wrote the kernel exploit
I guess you meant chatgpt wrote the kernel exploit.