Bug macOS TCP: fallo total de red a los 49.7 dias

El bug silencioso que reinicia tu infraestructura macOS cada 49 dias

Si gestionas servidores, pipelines de CI/CD o cualquier infraestructura de larga duracion sobre macOS, hay una bomba de tiempo corriendo en el kernel de tu sistema: un bug critico en la implementacion TCP que provoca el colapso total de las conexiones de red exactamente a los 49.7 dias de uptime continuo. El equipo de Photon Codes, creadores de OpenClaw (una plataforma de agentes de IA deployable en macOS), lo descubrio de la manera mas dura posible: su producto simplemente dejaba de funcionar en maquinas que llevaban semanas encendidas sin reiniciarse.

Que es el overflow de 32 bits y por que importa

En el corazon del sistema operativo de Apple existe un contador de tiempo interno de 32 bits sin signo que mide el tiempo del sistema en milisegundos. Un entero de 32 bits puede almacenar valores hasta 4,294,967,295. Cuando ese contador alcanza su valor maximo y hace overflow (es decir, vuelve a cero), el reloj interno de TCP se congela.

Este no es un bug nuevo en la historia del software: Windows 95 y Windows 98 sufrieron exactamente el mismo problema con su driver VTDAPI.VXD, que usaba enteros sin signo de 32 bits para medir el uptime del sistema en milisegundos. El resultado: el sistema se congelaba tras exactamente 49.7 dias de funcionamiento continuo. La aritmetica es simple: 2^32 milisegundos = aproximadamente 49.71 dias.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

En el caso de macOS, el mecanismo es diferente pero el patron es el mismo: el contador desbordado impide que el subsistema TCP actualice correctamente sus temporizadores internos.

Como el reloj TCP congelado destruye tus conexiones de red

Para entender el impacto, es necesario conocer el estado TIME_WAIT en el protocolo TCP. Cuando una conexion TCP se cierra, no desaparece inmediatamente: entra en un estado llamado TIME_WAIT durante un periodo de tiempo (normalmente 2 minutos segun el RFC 793) para garantizar que todos los paquetes pendientes han sido procesados y descartados correctamente.

Aqui esta el problema: si el reloj interno de TCP se congela por el overflow del contador de 32 bits, el sistema operativo deja de procesar las expiraciones de TIME_WAIT. Las conexiones cerradas no desaparecen; se acumulan indefinidamente en la tabla de conexiones del kernel.

El resultado directo es la saturacion de puertos efimeros (ephemeral port exhaustion). En macOS, el rango de puertos efimeros disponibles para conexiones salientes es limitado (tipicamente entre los puertos 49152 y 65535, unos 16,383 puertos disponibles). Cuando todos esos puertos estan ocupados por conexiones TIME_WAIT que nunca expiran, el sistema operativo es incapaz de abrir ninguna conexion TCP nueva. El resultado: fallo total de red hasta que el sistema es reiniciado.

Impacto real en servidores macOS y equipos de infraestructura

Este bug no afecta al usuario promedio que reinicia su MacBook cada dia o cada semana. El problema se materializa en escenarios donde macOS opera como servidor o nodo de infraestructura de larga duracion:

Servidores de CI/CD sobre macOS: Los runners de plataformas como GitHub Actions, GitLab CI o Buildkite que corren sobre hardware Apple (especialmente maquinas con chips M1/M2/M3) pueden llevar semanas o meses encendidas sin reinicios. En el dia 49.7, el runner simplemente dejara de poder establecer conexiones de red.
Mac minis como nodos de cluster: Cada vez mas equipos de DevOps usan Mac minis como servidores por su eficiencia energetica y soporte nativo para builds de iOS/macOS. Estos nodos suelen tener uptimes muy largos.
Productos de software corriendo sobre macOS como servidor: Es exactamente el caso de OpenClaw: una plataforma de agentes de IA con arquitectura gateway que puede deployarse en macOS. Con usuarios que dejan el sistema corriendo semanas seguidas, el fallo en el dia 49 es reproducible, misterioso al principio y devastador para la experiencia del usuario.
Entornos de automatizacion no-code e integraciones: Cualquier herramienta de automatizacion o integracion que dependa de conexiones TCP continuas sobre macOS (webhooks, APIs, bases de datos remotas) quedara completamente inoperativa.

El descubrimiento: de bug misterioso a causa raiz documentada

El equipo de Photon Codes describe en su blog un proceso de investigacion ejemplar para cualquier founder tech. Los sintomas iniciales eran confusos: OpenClaw dejaba de responder en maquinas de usuarios que llevaban mucho tiempo sin reiniciar. Las conexiones fallaban de manera aparentemente aleatoria, sin logs claros de error en la capa de aplicacion.

La clave fue correlacionar el tiempo de uptime del sistema con los fallos. Al reproducir el problema en un entorno controlado esperando 49.7 dias (o acelerando el contador mediante manipulacion del kernel), el fallo fue 100% reproducible. La investigacion profunda en el codigo del kernel de XNU (el kernel open-source de macOS/iOS) revelo el desbordamiento del contador de 32 bits y su efecto en el subsistema TCP.

Este tipo de debugging a nivel de kernel es extraordinariamente raro en equipos de producto de startups, lo que hace que el hallazgo y su documentacion publica sean especialmente valiosos para toda la comunidad de infraestructura sobre Apple Silicon.

Mitigaciones temporales mientras Apple no parchea

Hasta que Apple emita un parche oficial (el equipo de Photon Codes reporto el bug, aunque al momento de publicacion no hay confirmacion de un fix en camino), existen varias estrategias para proteger tu infraestructura:

Reinicios programados periodicos: La mitigacion mas directa es configurar reinicios del sistema cada 30-40 dias. En macOS, esto puede hacerse con un LaunchDaemon programado via launchd. Es una solucion burda pero efectiva mientras no hay parche.
Monitoreo del uptime con alertas: Implementar alertas cuando el uptime supere los 40 dias para tener tiempo de planificar un reinicio controlado antes del umbral critico de 49.7 dias.
Monitoreo de puertos efimeros: Supervisar el numero de conexiones en estado TIME_WAIT con herramientas como netstat -an | grep TIME_WAIT | wc -l. Un incremento sostenido sin decrementos es una senal temprana del problema.
Migracion a Linux para cargas de servidor: Para equipos que no necesitan builds nativos de Apple, considerar mover la infraestructura de servidor a Linux (donde este bug especifico no existe) y reservar los nodos macOS solo para compilaciones que lo requieran.
Tunning de parametros TCP del kernel: En algunos casos es posible reducir el tiempo de TIME_WAIT o aumentar el rango de puertos efimeros via sysctl, aunque esto tiene limites y no resuelve la causa raiz del overflow.

Por que este bug importa mas alla de OpenClaw

El caso de OpenClaw es el detonante del descubrimiento, pero el bug afecta potencialmente a cualquier proceso que use TCP en un sistema macOS con mas de 49.7 dias de uptime. Esto incluye desde servicios web locales, proxies, herramientas de observabilidad, hasta bases de datos embebidas.

El patron del bug, un overflow de contador de 32 bits, es una clase de vulnerabilidad bien documentada en la historia del software. Fue el culpable detras de los fallos de Windows 95/98 tras 49.7 dias, y una variante diferente (contadores en centesimas de segundo en lugar de milisegundos) afecto las conexiones TCP en Windows Vista, Windows 7 y Windows Server 2003/2008 tras 497 dias de uptime. El problema del año 2038 pertenece a la misma familia: enteros con signo de 32 bits que representan tiempo Unix y que desbordaran el 19 de enero de 2038.

La lectura para founders tech es clara: los bugs de overflow de tiempo son silenciosos, dificiles de diagnosticar sin contexto y devastadores cuando se materializan. Documentarlos y compartirlos publicamente, como hizo el equipo de Photon Codes, es exactamente el tipo de contribucion que eleva a toda la comunidad.

Conclusion

El bug del kernel de macOS descubierto por Photon Codes es un recordatorio de que la infraestructura tecnica siempre tiene capas ocultas de complejidad. Para los founders y equipos de ingenieria que operan sobre macOS, el mensaje es claro: ningun sistema deberia correr mas de 45 dias sin un reinicio programado, al menos hasta que Apple emita un parche para este overflow de 32 bits en el subsistema TCP. Monitorea tu uptime, programa tus reinicios y mantente al dia con los hallazgos de la comunidad. Este tipo de bugs no avisa; simplemente detiene todo el trafico de red cuando menos lo esperas.

Conecta con founders e ingenieros que gestionan infraestructura real: comparte hallazgos, evita estos bugs y escala con menos fricciones.

Unirme a la comunidad