Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A macOS bug that causes TCP networking to stop working after 49.7 days

photon.codes

Post reply on HN
Print view View original

81–90 of 120 posts

Re: A macOS bug that causes TCP networking to stop working after 49.7 days

#81

Post by BitsAndObjects »

nslsm wrote: post #74
gowld wrote: post #55

Earlier quoted context omitted.

AI does a good job of condensing the blog post to 2 paragraphs -- Mac refuses to let the tcp_now clock rollover when it exceeds the max value in its data type.

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.

This but Gemini and Email - literally marketed as "write bullet points and Gemini will draft your email", followed by "received a long email? Let Gemini summarise it for you."

The world's most effective _de_compression technology for email - total waste of time and compute when combined, but each product would make sense in isolation if human-generated mail was the majority of email sent/received (except sadly it isn't). We're using AI to spam people, AI to detect spam, AI to write non-spam and AI to summarise non-spam. AI inefficiency at every level and no way back.

Re: A macOS bug that causes TCP networking to stop working after 49.7 days

#82

Post by bigiain »

throw0101d wrote: post #27
josephcsible wrote: post #12

Earlier quoted context omitted.

Individual TCP connections don't need to live that long. Once a macOS system reaches 49.7 days of uptime, this bug starts affecting all TCP connections.

> 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 Am I supposed to be having issues with TCP connections right now? (I'm not.) My personal iMac is at 279 days of uptime.

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

> Am I supposed to be having issues with TCP connections right now? (I'm not.)

If my skim read of the slop post is correct, you'll only have issues on that machine if it hasn't spent any of that time asleep. (I have one Macbook that never sleeps, and I'm pretty sure it hit this bug a week or two back.)

Re: A macOS bug that causes TCP networking to stop working after 49.7 days

#83

Post by bigiain »

JensRantil wrote: post #71

This reminds me of the Linux kernel scheduler bug that kicked in after 208 days: https://www.claudiokuenzler.com/blog/247/linux-virtual-serve...

And Boeing 787s

https://airguide.info/boeing-787s-must-be-turned-off-every-5...

Re: A macOS bug that causes TCP networking to stop working after 49.7 days

#84

Post by netcoyote »

This type of problem plagues all sorts of software. Having experienced this type of problem before, for Guild Wars game servers -- which run deterministic game instances that live for long periods of time -- we initialized a per-game-context variable that gets added to Windows GetTickCount() to a value such that the result was either 5 seconds before 0x7fff_ffff ticks, or 5 seconds before 0xffff_ffff ticks, so that any weird time-computation overflow errors would be likely to show up immediately.

Re: A macOS bug that causes TCP networking to stop working after 49.7 days

#85

Post by mcculley »

hombre_fatal wrote: post #48
mcculley wrote: post #26

> It will not be caught in development testing — who runs a test for 50 days? You don't have to run the system for 50 days. You can simulate the environment and tick the clock faster. Many high reliability systems are tested this way.

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.

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.

Re: A macOS bug that causes TCP networking to stop working after 49.7 days

#86

Post by Aloisius »

justinfrankel wrote: post #43
justinfrankel wrote: post #32

have multiple macOS machines with 600-1000+ day uptimes, which do TCP connections every minute or so at a minimum, they are still expiring their TIME_WAIT connections as normal. these kernel versions: Darwin Kernel Version 20.6.0: Thu Jul 6 22:12:47 PDT 2023; root:xnu-7195.141.49.702.12~1/RELEASE_ARM64_T8101 arm64 Darwin Kernel Version 17.7.0: Wed Apr 24 21:17:24 PDT 2019; root:xnu-4570.71.45~1/RELEASE_X86_64 x86_64…

ah reading their analysis, there are errors that explain this. Particularly this: tcp_now = 4,294,960,000 (frozen at pre-overflow value) timer = 4,294,960,000 + 30,000 = 4,294,990,000 (exceeds uint32 max → wraps to a small number) timer wraps to a small number, they say TSTMP_GEQ(4294960000, 4294990000) they forgot to wrap it there, it should be TSTMP_GEQ(4294960000, small_number) = (int)(4294960000 - 4294990000) = (…

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

Re: A macOS bug that causes TCP networking to stop working after 49.7 days

#87

Post by justinfrankel »

Aloisius wrote: post #86
justinfrankel wrote: post #43

Earlier quoted context omitted.

ah reading their analysis, there are errors that explain this. Particularly this: tcp_now = 4,294,960,000 (frozen at pre-overflow value) timer = 4,294,960,000 + 30,000 = 4,294,990,000 (exceeds uint32 max → wraps to a small number) timer wraps to a small number, they say TSTMP_GEQ(4294960000, 4294990000) they forgot to wrap it there, it should be TSTMP_GEQ(4294960000, small_number) = (int)(4294960000 - 4294990000) = (…

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…

yep that makes sense

Re: A macOS bug that causes TCP networking to stop working after 49.7 days

#88

Post by dawnerd »

tjohns wrote: post #31

Does anybody else find these AI-authored blog posts difficult to read? Something about the writing style and structure just feels unnatural, it's hard put my finger on it. At the very least, the writing takes way too long to get to a point.

Same, AI written anything is really difficult for me to read and pretty exhausting.

Re: A macOS bug that causes TCP networking to stop working after 49.7 days

#89

Post by castillar76 »

bigiain wrote: post #76
BitsAndObjects wrote: post #34

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…

> very few users are likely to be affected by this I have a reasonably strong suspicion that I experienced this a week or two back, on a MacBook that doesn't go into sleep automatically and quite likely had 50-ish days of uptime. It had all the symptoms described - tcp connections not working while I could still ping everywhere just fine, and all the other devices on the same network were fine. Switching WiFi network…

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.

Post reply on HN