Hacker News Reader

Comment by BitsAndObjects | Hacker News Reader

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 the TCP stack - which may be why some people are reporting much longer uptimes without hitting this problem, since (iirc) uptime doesn’t reset on Macs just for a sleep? Only for a full reboot?

Anyway, all in all, yeah hopefully Apple fix this but it’s not something anyone needs to panic about.

View on HN

> 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 networks and plugging in to ethernet didn't help. A reboot "fixed" it.

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 ;)

Can confirm at least on of us (me) is weird.

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.

GP said that suspending without rebooting prevents the issue.

My uptime resets only when forced by an OS upgrade and I have never experienced this issue. This is consistent with the sleep-heals-the-stack theory.

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

Apparently no. They'll be fixing it themselves? It really reads like Claude run amok on the blog.

> We are actively working on a fix that is better than rebooting — a targeted workaround that addresses the frozen tcp_now without requiring a full system restart. Until then, schedule your reboots before the clock runs out.

I think I might've hit my head on this a few times with my Mac Mini that's on basically 24/7 and doesn't go to sleep.

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

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

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)

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
    = 4294937296 >= 0 ?  → true! (not false)

This is a bug of course, but it would cause sockets in TCP_WAIT state to be reaped anytime tcp_gc() is called, regardless of whether 2*MSL has passed or not. This only happens though if tcp_now gets stuck after 4,294,937,296 ms from boot.

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.

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.

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

Reply on news.ycombinator.com