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.
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.
Case in point was an Asus RT-56N router that I had to replace with ISP wifi.
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).
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 ;)
"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.
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.
Alternatively, check the difference between an arbitrary ChatGPT prompt response, and the output of the following:
import tiktoken, secrets
enc = tiktoken.get_encoding("o200k_base")
tokens = tuple(enc._mergeable_ranks.values())
msg_len = 128 + secrets.randbelow(2048 - 128)
token_ids = [secrets.choice(tokens) for _ in range(msg_len)]
print(enc.decode(token_ids))
Even if you mean it on a "higher level", imbued into the language emitted, do feel free to ask a model with disabled tool calling to give you some random numbers / words. You'll find that it isn't very random. Certainly wasn't when I last tried this for entertainment.
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.
Only do this if you rescued the router from the trash bin, not if you spent money 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.
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.
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.
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?
- 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.
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.
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.
The learning curve being a bit rough is massive understatement. It's not meant for not computer savy people.
Been wondering recently what the others might be. Can you give a few examples among popular brands?
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'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 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.
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.
> !!
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.
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.
[0] https://www.quantumfiber.com/
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
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.
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.
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?
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.
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...
Corporate America does not like your attitudes. Your cybercredits are reduced for the next year or until you wire 100k to dear leader
If it's (just?) a random word generator then it cannot "want" anything since it has no will. :)
> It does not apply to common versions of user frustration, pushback, dark creative themes, or model testing and research.
In any case, the ToS change is vague enough that it could be a violation or not.
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.
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.
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.
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.
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.
Buy Ruckus, it’s high quality hardware, but you’ll be paying enterprise prices for new hardware. But used hardware is fine.
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.
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).
https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Oper...
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
Live & learn...
(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.
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).
> 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?
..from the diary of an AI agent.
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.)
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.
They're both cheap and quite good. They're what GL.inet used to be when i last purchased routers before this.
See also: pfSense, OpenWrt
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.
well, that's what the retries are for! Keep retrying until you get a complete answer
I assume DTLS and QUIC handle MAC verification failures gracefully, like ordinary packet loss.