> 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
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.
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.
> 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".
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
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.
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.
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.
You do _not_ want to have multiple retry layers if you can help it. That can result in accidentally DoSing yourself, as each layer amplifies the number of retries.
TLS 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.
> 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
!!
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 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.
> 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...
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.
TIL. Still,
> It does not apply to common versions of user frustration, pushback, dark creative themes, or model testing and research.
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...
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
Anthropic doing free advertising for glm and other open models :D
Impressive capabilities shown on benchmarks don't really make a difference if you can't use them. I'll take a lower chance of success over constant downgrading and refusals. At least, as the author put it, you get to enjoy the token gamble exercise.
They have 3 tiers, individuals can have only blue teaming. But it's to restricted. For me it refused to fix a bash parser cause word ssh was in test cases.
Or fix an sql injection
I 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.
> 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.
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.
You do _not_ want to have multiple retry layers if you can help it. That can result in accidentally DoSing yourself, as each layer amplifies the number of retries.
TLS 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.
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 :)
Wanted to steal the honey jar, ended up being stun by the bees like Winnie-The-Poo
Wanted to go for a walk around the neighborhood, ended up breaking into a car and driving coast to coast on one charge (it was a Tesla).