I would not be surprised if people on HN were more likely to hit this issue than Apple's average users. We're a weird bunch ;)

Yep, I concur: this explains a bizarre behavior I’ve noted in my Mac laptops for ages now. I have a tendency to just suspend them without rebooting for ages, especially the work one that doesn’t leave my office as frequently. Periodically, I’d come in to find the system bizarrely frozen just as they describe: TCP stack blocked up, but everything else on it behaving normally. (Well, mostly: some apps would block starting and bounce eternally, but I suspect that’s because they’re trying to make a network call while starting up and it’s blocking.) The only fix was a reboot.

It’s not a disaster, but very annoying. At least now I can just schedule a reboot every 30 days at minimum to keep things running.

Did you need to make this blog post 20 pages long and have AI write it? Especially in such dramatic style?

Remember the golden rule: if you can't be bothered to write it yourself, why should your audience be bothered to read it ourselves?

Might want to update it if you used the blog post explanation because it's incorrect as justinfrankel noted below. From the post:

    tcp_now   = 4,294,960,000  (frozen at pre-overflow value)

    timer     = 4,294,960,000 + 30,000 = 4,294,990,000 - MAX_INT = 22,704

    TSTMP_GEQ(4294960000, 22704)
    = 4294960000 - 22704
    = 4294937296
    = 4294937296 >= 0 ?  → true! (not false)

A bug similar to what the blog described can happen however if tcp_now gets stuck at least 30 seconds before it it would have wrapped. Since tcp_now is only updated if there is TCP traffic, this can happen if there is no TCP traffic for at least 30 seconds before before it would roll over (MAX_INT ms from boot).

It's should be easy to prevent the latter from happening with some TCP traffic, though reaping TCP_WAIT connections early isn't great either.

Can it summarize it down to a non-post?

Use AI to expand your thoughts into a long-winded post, use AI to compress the long-winded post into something that can be digested by a human.

WinCE too

Yes. I do mean designing software to make it testable.

The code that uses that value can be run in an environment where that value can be controlled.

I have written code that does this same thing and built a test harness for 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.

> Once a macOS system reaches 49.7 days of uptime, this bug starts affecting all TCP connections.

Current `uptime` on my work MacBook (macOS 15.7.4):

    17:14  up 50 days, 22 mins, 16 users, load averages: 2.06 1.95 1.94

My personal iMac is at 279 days of uptime.

Sure they do. They need to live until torn down.

They almost never do live that long, for whatever reason, but they should.

For OpenClaw this bug is a security feature

There does appear to be a bug, but it's not what the blog describes.

If tcp_now stops updating at <= 2^32 - 30000 milliseconds, then TSTMP_GEQ(tcp_now, timer) will always fail since timer is tcp_now + 30000 which won't wrap.

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 looks like TCP sockets in the TIME_WAIT will end up being closed immediately instead of waiting 30 seconds, which isn't great either.

> Apple Community #250867747: macOS Catalina — "New TCP connections can not establish." New connections enter SYN_SENT then immediately close. Existing connections unaffected. Only a reboot fixes it.

This is a weird thing to cite if it's a macOS 26 bug. I quite regularly go over 50 days of uptime without issues so it makes sense for it to be a new bug, and maybe they had different bugs in the past with similar symptoms.

Interesting. The article mentions complaints on the forums running Catalina, so that must be something else.

The article does mention a few instances found over the years, including the windows one. That’s the one I remember though because we used to joke it was not a big deal - the only way for a windows 95 computer to reach 49 days of uptime is if it’s literally not doing anything or being used in any way. Windows 95 would crash if you looked at it funny.

49-7=42 it is all clear

It could be an overflow but related with the frequency at which the register was increasing, rather than the max value of te register. E.g. +1 this uint16 (65535) once every 500,000 cycles on this 32 Mhz chip, that previously was a 1 Mhz chip and never had a problem.

> I’m still at where when I connect external hard drive or SSD via USB, use it and then eject it, I shut down the MacBook Pro completely before I unplug the cable. Just in case.

That sounds... a bit paranoid? At least on Linux (Gnome), if I click to "safely remove drive" it actually powers off the drive and stops external mechanical drives from spinning. No useful syncing is going to happen anyway once a hard drive no longer spins. A modern OS should definitely be reliable enough that it can be trusted to properly unmount a drive.

> For the laptops that I actually carry around and plug and unplug things to etc, normal amount of time between reboots for me is somewhere between every 1 and 3 days. Cold boot is plenty fast anyway, so shutting it down after a day of work or when ejecting an external HDD or SSD doesn’t really cost me any noticeable amount of time.

I personally don't reboot my laptop that often, but it's not because of a boot taking too much time. It's because I like to keep state: open applications, open files, terminal emulator sessions, windows on particular virtual desktops, etc.

> 17:27:20 up 1112 days, 10:36, 50 users, load average: 0.20, 0.19, 0.18

I thought I had a record going here with my Dell laptop, but I guess you win. After a certain point, I just decided to see how long I can make it go.