> But then, why just block IPv4 and not also IPv6?
I’ll take “what’s the most overlooked thing in corporate networks” for 200. 😅
> But then, why just block IPv4 and not also IPv6?
I’ll take “what’s the most overlooked thing in corporate networks” for 200. 😅
> But then, why just block IPv4 and not also IPv6?
I’ll take “what’s the most overlooked thing in corporate networks” for 200. 😅
> But then, why just block IPv4 and not also IPv6?
I’ll take “what’s the most overlooked thing in corporate networks” for 200. 😅
> But then, why just block IPv4 and not also IPv6?
I’ll take “what’s the most overlooked thing in corporate networks” for 200. 😅
Yeah, it is definitely something on my laptop that rejects connections to IPv4 ports 80 and 443. All other devices here can access the stuff without issue, only this work machine is unable to. The "Connection refused" happens within a few milliseconds.
Unfortunately, I do not have the slightest idea how it works. But maybe I can look into that tomorrow. Kernel modules are a very good hint, thank you! <3
You're right, it might be some sort of fail-safe mechanism. But then, why just block IPv4 and not also IPv6? But maybe because the VPN and company servers require IPv4, there is zero IPv6 support. (Yeah, don't ask, I don't understand it either.)
- Can you disable the snakeoil junk temporarily? Probably not, eh?
- Have you verified with an external device that it really is your laptop that’s dropping the packets? Like, what does
tcpdump on your router see?If this works reliably in the office, then it feels like some kind of fail-safe mechanism of the snakeoil stuff. If it can’t see its control server (which might only be reachable from the office?), then it shuts down web traffic? Something like that?
Any idea how the snakeoil works? Maybe it does
LD_PRELOAD magic to hijack syscalls like connect()? Does it use kernel modules?
- Can you disable the snakeoil junk temporarily? Probably not, eh?
- Have you verified with an external device that it really is your laptop that’s dropping the packets? Like, what does
tcpdump on your router see?If this works reliably in the office, then it feels like some kind of fail-safe mechanism of the snakeoil stuff. If it can’t see its control server (which might only be reachable from the office?), then it shuts down web traffic? Something like that?
Any idea how the snakeoil works? Maybe it does
LD_PRELOAD magic to hijack syscalls like connect()? Does it use kernel modules?
- Can you disable the snakeoil junk temporarily? Probably not, eh?
- Have you verified with an external device that it really is your laptop that’s dropping the packets? Like, what does
tcpdump on your router see?If this works reliably in the office, then it feels like some kind of fail-safe mechanism of the snakeoil stuff. If it can’t see its control server (which might only be reachable from the office?), then it shuts down web traffic? Something like that?
Any idea how the snakeoil works? Maybe it does
LD_PRELOAD magic to hijack syscalls like connect()? Does it use kernel modules?
- Can you disable the snakeoil junk temporarily? Probably not, eh?
- Have you verified with an external device that it really is your laptop that’s dropping the packets? Like, what does
tcpdump on your router see?If this works reliably in the office, then it feels like some kind of fail-safe mechanism of the snakeoil stuff. If it can’t see its control server (which might only be reachable from the office?), then it shuts down web traffic? Something like that?
Any idea how the snakeoil works? Maybe it does
LD_PRELOAD magic to hijack syscalls like connect()? Does it use kernel modules?
I had this problem four weeks ago on Friday morning the very first time at home. On Thursday evening, everything was perfectly fine. Eventually, I plugged in the LAN cable in the office and everything got automatically fixed. Nobody can explain what's happening.
Then, last week Friday morning out of the blue, the same issue was back. So, I went to the office yesterday and it got fixed again by plugging in the network cable. This evening, I have exactly the same bloody problem again.
What the hell is going on? Does anyone have any ideas? I'm certainly not an expert, but I don't see anything suspicious in iptables or nft rules. I also do not see anything showing up in /var/log/kern.log. Even tried to stop firewalld, flush the iptables and nft rules, but that didn't result in any changes.
felt soooo good
#running
felt soooo good
#running
felt soooo good
#running
----
Share your solution via Twtxt and how you arrived at it and I'll share my solution tomorrow!
#napkin-math
----
Share your solution via Twtxt and how you arrived at it and I'll share my solution tomorrow!
#napkin-math
> Warning: pub is still in development, if it breaks, you can keep the pieces.
> Warning: pub is still in development, if it breaks, you can keep the pieces.
> Warning: pub is still in development, if it breaks, you can keep the pieces.
… returned 200 but no Last-Modified header - can’t cache content
export LC_TYPE=C.UTF-8 👌
zs a web server? I see on the source of the page that is simply posting to /cgi-bin/hello, and some JavaScript to get the value of that post, from the same CGI.
"us-ascii" but setting it to "utf-8" changed nothing... 🤔h
skinshafi@thunix:~$ neomutt -Q charset
set charset = "us-ascii"
skinshafi@thunix:~$ neomutt -Q charset
set charset = "utf-8"
> /Me adding a new entry in a #Todo list.
> /Me adding a new entry in a #Todo list.
> /Me adding a new entry in a #Todo list.
\360\237\230\261 (escapesd unicode?), sometime that shows in the mail body and sometimes not. Could it have something to do with the remote/pubnix machin's Locale or something? one more thing to digg through 🫠
Screenshot of waht's going on
Coalition for
Universal
Needs
Truth and
Solutions
:set spell to catch up with the typos