5 ms·
According to the post: $ netstat -an | grep -c TIME_WAIT If the count it returns keeps growing, you're seeing a slow leak. At some point, new connections will
by Aloisius 5mo ago
According to the post:
$ netstat -an | grep -c TIME_WAIT
If the count it returns keeps growing, you're seeing a slow leak. At some point, new connections will start failing. How soon depends entirely on how quickly your machine closes new connections.
Since a lot of client traffic involves the server closing connections instead, I imagine it could take a while.
It's unclear if it'll leak whenever your mac closes or only when it fails to get a (FIN, ACK) back from the peer so the TCP_WAIT garbage collector runs. If it's the latter, then it could take substantially longer, depending on connection quality.
- throw0101d 5mo ago% netstat -an | grep -c TIME_WAIT | wc -l 1
- Aloisius 5mo agoYou 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.
- comex 5mo agoThey probably aren’t affected because the buggy code was only added in macOS 26: https://github.com/apple-oss-distributions/xnu/blame/f6217f891ac0bb64f3d375211650a4c1ff8ca1ea/bsd/netinet/tcp_subr.c#L3753 https://github.com/apple-oss-distributions/xnu/blame/f6217f8...
- pjjpo 5mo agoOuch - "every Mac" from the original post is a hallucination then. I can live with the writing style when the topic is interesting (here it was for me) but complete untruths are much worse.