101–110 of 120 posts
Hmm? torp@machinename ~ % uptime 11:43 up 59 days, 1:22, 4 users, load averages: 2.87 2.69 2.70 Sleep is disabled on that machine and it definitely had networking working fine last night. Mac Mini M2, Sequoia. Incidentally my laptop says 75 days uptime, but that one does go to sleep.
It's Tahoe specific
Hmm? torp@machinename ~ % uptime 11:43 up 59 days, 1:22, 4 users, load averages: 2.87 2.69 2.70 Sleep is disabled on that machine and it definitely had networking working fine last night. Mac Mini M2, Sequoia. Incidentally my laptop says 75 days uptime, but that one does go to sleep.
> Mac Mini M2, Sequoia. It's Tahoe specific https://news.ycombinator.com/item?id=47670995
Earlier quoted context omitted.
You want to drop the wc -l. Mac `grep -c` counts lines that match, so it always prints 1 line, so piping to wc -l will always return 1. Or just open up and do netstat -an |grep TCP_WAIT and just watch it. If any don't disappear after a few minutes, then you're seeing the issue.
They probably aren’t affected because the buggy code was only added in macOS 26: https://github.com/apple-oss-distributions/xnu/blame/f6217f8...
I can live with the writing style when the topic is interesting (here it was for me) but complete untruths are much worse.
I got tired of the AI writing before finding out if they even attempted to contact Apple about this issue? Does anyone know? Also, massively over-dramatised. Yes, a bug worth finding and knowing about, but it’s not a time bomb - very few users are likely to be affected by this. Knowing the nature of OS kernels, I’m guessing even just putting a Mac laptop to sleep would be enough to avoid this issue as it would reset…
Sometimes it just stops networking completely, turning the wifi adapter on/off brings it back just fine. It's also a good time to reboot =)
Earlier quoted context omitted.
It uses a hardware clock, one that pauses during sleep. There is no tick. If you wanted to see how time impacts the program, you'd prob change fns like calculate_tcp_clock to take uptime as an argument so that you could sanity check it.
We're talking about a company that produces the hardware their OS is running on. I'm sure they can find a way to make the hardware clock run faster.
I thought Alan Cox fixed all the TCP IP bugs in the early 1990s lol
Did Alan Cox work on tcp? I thought he was working on memory and stuff. That's what the wiki says anyway: [1], and a publication with his name is about huge pages [2] [1] https://wiki.freebsd.org/AlanCox [2] https://www.usenix.org/legacy/events/osdi02/tech/full_papers...
"His involvement with Linux began in the early 1990s when he was working on a project that required a stable networking solution. This led him to discover Linux, which was still in its infancy at the time.
Contributions to Linux Kernel
Cox's contributions to the Linux kernel are extensive and far-reaching. He is best known for his work on the Linux networking stack, which was critical in making Linux a viable option for server environments. Cox identified and addressed numerous issues in the kernel's TCP/IP implementation, enhancing its performance and reliability." [0]
"For those not familiar with the Linux kernel contributors, Alan Cox wrote large parts of the networking stack, was the maintainer of the 2.2 branch, and was commonly considered the "second in command" to Linus Torvalds at one point: http://en.wikipedia.org/wiki/Alan_Cox" [1]
"Alan started working on Version 0. There were bugs and problems he could correct. He put Linux on a machine in the Swansea University computer network, which revealed many problems in networking which he sorted out; later he rewrote the networking software. [2]
[0] https://machaddr.substack.com/p/kernel-chronicles-insights-a...
[1] https://news.ycombinator.com/item?id=8548738
[2] https://web.archive.org/web/20200923003028/https://www.swans...
Earlier quoted context omitted.
There does appear to be a bug, but it's not what the blog describes. If tcp_now stops updating at This does look like it is possible since calculate_tcp_clock() which updates tcp_now only runs when there's TCP traffic. So if at 49 days uptime you halted all TCP traffic and waited about a day, tcp_now would be stuck at the value before you halted TCP traffic. In cases where tcp_now gets stuck at > 2^32 - 30000, it loo…
Are you sure? tcp_now’s maximum cannot physically reach 2^32 because the trailing zeros of that number exceeds the bit width of data type. Therefore, tcp_now + 30000 will wrap when tcp_now is equal to 2^32 - 3000. Your inequality sign should be strict <, otherwise the result does not follow.
It should be that if tcp_now gets stuck before (=) (2^32 - 30000), it would cause them to potentially be reaped faster they should be.
Actually looking at the code a bit more, it looks like calculate_tcp_clock() is run at least once per hour even when there's no TCP traffic or sockets open, so getting into the state where it never reaps TIME_WAIT sockets which would be hard to predict if this would happen.
It also looks like if tcp_now gets stuck, other tcp timers may have problems as well.
Earlier quoted context omitted.
Did Alan Cox work on tcp? I thought he was working on memory and stuff. That's what the wiki says anyway: [1], and a publication with his name is about huge pages [2] [1] https://wiki.freebsd.org/AlanCox [2] https://www.usenix.org/legacy/events/osdi02/tech/full_papers...
Alan Cox of course worked on the TCP/IP stack: "His involvement with Linux began in the early 1990s when he was working on a project that required a stable networking solution. This led him to discover Linux, which was still in its infancy at the time. Contributions to Linux Kernel Cox's contributions to the Linux kernel are extensive and far-reaching. He is best known for his work on the Linux networking stack, whic…
Earlier quoted context omitted.
Alan Cox of course worked on the TCP/IP stack: "His involvement with Linux began in the early 1990s when he was working on a project that required a stable networking solution. This led him to discover Linux, which was still in its infancy at the time. Contributions to Linux Kernel Cox's contributions to the Linux kernel are extensive and far-reaching. He is best known for his work on the Linux networking stack, whic…
Wrong Alan Cox for a kernel with the FreeBSD tcp stack from ~ 2000.