> 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
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...
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.
> 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
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!
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.)
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.
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)
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...
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.
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.)
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.
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.
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.
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.
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 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...
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.
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!
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.)
This is funny to read. Either you can be more "verified" than the other guy, or it's badly implemented.
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
> It does not apply to common versions of user frustration, pushback, dark creative themes, or model testing and research.
I said "No, do X. Research it. Y is based on wrong assumptions"
Thing did the research. Concluded with "Yes, indeed, Y was wrong"
Work is done
Turns out it did Y. But not just that. When asked about it, it not just (as LLMs do) made stories as to why, but "stood its ground" so to say.
"Refusing to perform regret", general snark and all that.
I know there is nothing really new or noteworthy in this comment or story, but I continue to be impressed by how misaligned the models of the company are, that can't stop talking about how incredibly important alignment is.
To the point where they now want to make it illegal (slice by slice) to push back against the clear and obvious misalignment of their models.
If you talk to people outside the industry about this, they just think you're telling them a made-up story. It's utterly absurd.
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
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.
Does TLS (transport layer) not have any retry logic? Could someone explain please?
The problem here is that the thing computing the TCP checksum on the outgoing frame was the WLAN firmware running on the WLAN NIC itself; this is known as checksum offloading. It saves CPU time if the CPU can just hand off a TCP segment to the NIC and let the NIC checksum it before it sends it out. This only works properly if the data given to the NIC doesn't get corrupted in the meantime.
Same reason why you never implement a VPN using TCP sockets, for those readers who solidify their knowledge by triangulation (as it were) from multiple directions.
I assume DTLS and QUIC handle MAC verification failures gracefully, like ordinary packet loss.