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

111–120 of 120 posts

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

#111

Post by MikeRichardson »

jasonjayr wrote: post #45
exe34 wrote: post #38

Earlier quoted context omitted.

$ uptime 22:22:45 up 3748 days 21:20, 2 users, load average: 1.42, 1.36, 1.02 It's very funny, I think it's because my laptop battery died and when I replaced it, it had to update the time from 10 years ago? I'm not sure why, as the laptop is from mid-2012.

> 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.

50 users???

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

#113

Post by toast0 »

jijji wrote: post #110
toast0 wrote: post #109

Earlier quoted context omitted.

Wrong Alan Cox for a kernel with the FreeBSD tcp stack from ~ 2000.

So, you're implying that there is a second person named Alan Cox from Swansea, Wales who worked on FreeBSD, not Linux? Where is your source for that? lol

You asked about Alan Cox, I said no, and provided links. You moved the goal posts to Swansea.

Alan Cox relevant to Mac is Alan Cox, professor(+etc) at Rice and well known FreeBSD contributor; no connection to Swansea, Wales, AFAIK. https://scholar.google.com/citations?user=z28ApZkAAAAJ&hl=en

I do see some networking stuff on there, but much after Apple forked tcp. I don't know that Apple took much memory management from BSD either. Most likely, neither Alan Cox is relevant to Mac.

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

#114

Post by binaryturtle »

fortran77 wrote: post #61

Nobody keeps their Macs running for more than 49.7 days? We have Windows Servers here (with long-term TCP/IP connections) that are only rebooted every 6 months to apply patches.

Macs that no longer get reboot-requiring updates by Apple usually have long(er) uptimes. :) My record here with my primary Mac mini was a bit over a year. Only to be forced to reboot because of a power outage.

Generally it feels like sometimes you boot into a stable "session" that can go on forever, but often enough you boot in a "session" and something goes wrong quickly and you'll have to reboot after a week or two. But I do experience the same with my Raspberry PI. :)

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

#116

Post by apple4ever »

castillar76 wrote: post #89
bigiain wrote: post #76

Earlier quoted context omitted.

> 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 start…

I experienced the exact same issue. Now that I know, I know what to do.

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

#117

Post by e28eta »

Aloisius wrote: post #92
RyanZhuuuu wrote: post #41

Earlier quoted context omitted.

yes we have reported to Apple and they have filed it in their internal system.

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) The mistake in the blog post is timer isn't wrapped, even though it notes it should be: timer = 4,294,960,000 + 30,000 = 4,294,990,000 - MAX_INT = 22,704 Therefore: TSTMP_GEQ(4294960000, 22704) = 4294960000 - 22704 = 4294937296 = 42949…

Since the code they show and their comment says `uint32_t timer` wraps, but then their math doesn’t wrap it, I wonder how they missed this.

It’s also weird that their “smoking gun” example is with active TCP traffic, which (should?) be updating tcp_now and would make them more likely to fall into the “TCP_WAIT is immediately closed” case.

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

#119

Post by mhjkl »

Aloisius wrote: post #92
RyanZhuuuu wrote: post #41

Earlier quoted context omitted.

yes we have reported to Apple and they have filed it in their internal system.

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) The mistake in the blog post is timer isn't wrapped, even though it notes it should be: timer = 4,294,960,000 + 30,000 = 4,294,990,000 - MAX_INT = 22,704 Therefore: TSTMP_GEQ(4294960000, 22704) = 4294960000 - 22704 = 4294937296 = 42949…

But the TSTMP_GEQ macro casts the difference to int, so any number above the signed integer limit (about 2 billion) becomes negative and the comparison returns false as they said

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

#120

Post by mhjkl »

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) = (…

They didn’t need to wrap it because it’s modular arithmetic so the result after casting to int is the same regardless of wrapping behavior. 4294990000 after wrapping is 22704 and 4294960000 - 22704 = 4294937296 which is -30000 after uint to int cast
Post reply on HN