

To keep a Mac permanently online, tons of subroutines run in the background: They establish connections to servers, secure them and close them again. The Transmission Control Protocol (TCP) responsible for this is established and forms the basis for web and email, among other things. However, even with proven frameworks, errors can creep in – especially if they only become apparent after a long period of operation. Photon, a service for integrating AI agents into messenger platforms, claims to have discovered one of these: 49.71 days after a restart, the number of TCP connections begins to become scarce. This causes the network to fail within a few hours. The phenomenon was noticed because the developers used dedicated test Macs to check the quality of the iMessage service. On March 30, they discovered that some of these devices were unable to establish new TCP connections while established ones continued to exist. A reaction control via ping also worked. Only a restart fixed the error. The Macs that showed this problem were all started at the same time – just over 49 days ago.
Timer with rollover protection
According to the developers, the cause is an internal system timestamp, which is used to properly terminate expired TCP connections. This apparently consists of a 32-bit millisecond counter – that corresponds to 49 days, 17 hours and a good 47 seconds. At the end of this period, it should actually jump to zero. However, a newly added function (“monotonicity guard”) prevents this. The counter remains at the maximum value and abandoned TCP sockets remain permanently reserved.
Problem after another few hours
Since the discoverers had launched two more Macs almost 49.71 days ago, they were able to test their theory. A test script revealed the increase in TIME_WAIT values of TCP connections after the timestamp, whereas before they never exceeded the upper limit of 30 seconds. Nine and a half hours later, the network connections of the two Macs failed. According to their own statement, the discoverers are working on an interim solution that does not require a restart. The blog article does not mention whether they reported the bug using the responsible disclosure procedure or submitted the findings to the XNU kernel.















