{"id":2689,"date":"2026-04-07T13:30:00","date_gmt":"2026-04-07T11:30:00","guid":{"rendered":"https:\/\/elearningsamba.com\/index.php\/macos-votre-reseau-tcp-meurt-au-bout-de-49-jours\/"},"modified":"2026-04-07T13:30:00","modified_gmt":"2026-04-07T11:30:00","slug":"macos-votre-reseau-tcp-meurt-au-bout-de-49-jours","status":"publish","type":"page","link":"https:\/\/elearningsamba.com\/index.php\/macos-votre-reseau-tcp-meurt-au-bout-de-49-jours\/","title":{"rendered":"macOS – Votre r\u00e9seau TCP meurt au bout de 49 jours"},"content":{"rendered":"

49 jours, les amis, c’est la dur\u00e9e de vie d’un Mac avant que son r\u00e9seau TCP ne s’effondre dans un silence assourdissant. Il suffit d’un overflow d’entier 32 bits dans le kernel XNU, une horloge interne qui se bloque, et hop, plus moyen d’ouvrir la moindre connexion. Le ping marche toujours, parce qu’ICMP se fout du TCP, mais pour le reste… c’est reboot obligatoire ou rien.<\/p>\n

Pour savoir combien de temps il vous reste, tapez uptime<\/code> dans le Terminal. Si votre Mac sous macOS Sequoia, Sonoma ou m\u00eame Ventura tourne depuis plus de 7 semaines sans red\u00e9marrage, c’est le moment d’y rem\u00e9dier car le bug touche toutes les versions.<\/p>\n

C’est l’\u00e9quipe de
\nPhoton<\/a>
\nqui a r\u00e9v\u00e9l\u00e9 le probl\u00e8me. Celui-ci est apparu sur une flotte de Macs d\u00e9di\u00e9e \u00e0 la t\u00e9l\u00e9m\u00e9trie iMessage. Pile 49,7 jours apr\u00e8s le dernier red\u00e9marrage, plusieurs machines ont l\u00e2ch\u00e9 en m\u00eame temps. Plus de nouvelles connexions r\u00e9seau, mais le ping r\u00e9pondait toujours.<\/p>\n

En fouillant le code du
\nnoyau XNU d’Apple<\/a>
\n(qui est open source, faut le rappeler), ils sont tomb\u00e9 sur une variable tcp_now<\/code>, qui est un compteur 32 bits qui s’incr\u00e9mente chaque milliseconde. En gros, imaginez un compteur kilom\u00e9trique qui arriv\u00e9 au max (environ 4,3 milliards), repasse \u00e0 z\u00e9ro.<\/p>\n

Sauf que le code contient un garde fou cens\u00e9 emp\u00eacher l’horloge de reculer du genre “si la nouvelle valeur est plus petite que l’ancienne, on ne met pas \u00e0 jour<\/em>“. \u00c7a a l’air malin mais en fait, au moment du rebouclage, patatras : la nouvelle valeur (proche de z\u00e9ro) est forc\u00e9ment plus petite que l’ancienne (proche du max), du coup le garde fou bloque tout et l’horloge TCP se fige.<\/p>\n

Et ensuite, \u00e7a part en cascade. Les connexions ferm\u00e9es restent normalement en TIME_WAIT durant 30 secondes sur macOS, avant d’\u00eatre nettoy\u00e9es par tcp_gc()<\/code> mais avec l’horloge gel\u00e9e, ce nettoyage ne se fait plus. Un netstat -an | grep TIME_WAIT<\/code> montre alors la catastrophe en temps r\u00e9el avec des connexions mortes qui s’empilent, et finissent par bouffer les 16 384 ports \u00e9ph\u00e9m\u00e8res (range 49152-65535 sur macOS) restant… Et au bout de quelques heures, plus rien ne passe !<\/p>\n

Photon a laiss\u00e9 tourner deux machines apr\u00e8s l’overflow pour voir. Neuf heures plus tard, l’une affichait 8 000 connexions zombies et un load average de 49. La machine ne faisait plus que scanner sa propre file d’attente de connexions mortes.<\/p>\n

Si \u00e7a vous rappelle quelque chose, c’est normal car j’sais pas si vous vous souvenais mais Windows 95 plantait au bout du m\u00eame d\u00e9lai pour la m\u00eame raison (le fameux GetTickCount()<\/code> en 32 bits). Le Boeing 787 avait \u00e9galement un souci similaire au bout de 51 jours sur ses switches r\u00e9seau, sans oublier le bug de l’an 2038 sous Unix, qui est la version sign\u00e9e du m\u00eame ph\u00e9nom\u00e8ne. 30 ans s\u00e9parent certains de ces bugs qui pourtant appartiennent \u00e0 la m\u00eame cat\u00e9gorie !<\/p>\n

Apr\u00e8s flippez pas car des devs avec des Macs \u00e0 plus de 600 jours d’uptime disent n’avoir jamais eu le souci. \u00c0 vrai dire, le bug ne se d\u00e9clencherait que si votre Mac n’a aucun trafic TCP pile au moment de l’overflow. Si votre machine cause au r\u00e9seau en permanence (et c’est le cas de 99% des Macs), l’horloge passe le cap sans broncher.<\/p>\n

Les machines les plus expos\u00e9es sont en fait les serveurs CI\/CD sous macOS, les
\nMac mini<\/a>
\nen ferme de build Jenkins ou GitHub Actions, les Mac Pro d\u00e9di\u00e9s au rendu 3D avec Blender ou Cinema 4D. Le MacBook qui passe en veille tous les soirs n’est pas vraiment concern\u00e9 (le compteur tcp_now<\/code> ne tourne pas pendant la veille, donc le d\u00e9lai de 49 jours ne concerne que le temps d’activit\u00e9 r\u00e9el).<\/p>\n

Maintenant pour v\u00e9rifier votre compte \u00e0 rebours personnel, ouvrez un Terminal et collez y ceci :<\/p>\n

\n
boot_sec=$(sysctl kern.boottime | grep -o 'sec = [0-9]*' | head -1 | awk '{print $3}')\n<\/span><\/span>now_sec=$(date +%s)\n<\/span><\/span>remain=$(( 4294967 - (now_sec - boot_sec) ))\n<\/span><\/span>echo \"Temps restant avant overflow : $((remain\/3600))h $((remain%3600\/60))m\"\n<\/span><\/span><\/code><\/pre>\n
Bref, y’a rien \u00e0 faire si ce n’est de v\u00e9rifier votre uptime et faire \u00e9ventuellement un petit reboot pr\u00e9ventif. Tic tac, l’horloge tourne ^^.<\/p>\n
\nSource<\/a>\n<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
49 jours, les amis, c’est la dur\u00e9e de vie d’un Mac avant que son r\u00e9seau TCP ne s’effondre dans un silence assourdissant. Il suffit d’un overflow d’entier 32 bits dans le kernel XNU, une horloge interne qui se bloque, et hop, plus moyen d’ouvrir la moindre connexion. Le ping marche toujours, parce qu’ICMP se fout du TCP, mais pour le reste… c’est reboot obligatoire ou rien. Pour savoir combien de temps il vous reste, tapez uptime dans le Terminal. Si votre Mac sous macOS Sequoia, Sonoma ou m\u00eame Ventura tourne depuis plus de 7 semaines sans red\u00e9marrage, c’est le moment d’y rem\u00e9dier car le bug touche toutes les versions. C’est l’\u00e9quipe de Photon qui a r\u00e9v\u00e9l\u00e9 le probl\u00e8me. Celui-ci est apparu sur une flotte de Macs d\u00e9di\u00e9e \u00e0 la t\u00e9l\u00e9m\u00e9trie iMessage. Pile 49,7 jours apr\u00e8s le dernier red\u00e9marrage, plusieurs machines ont l\u00e2ch\u00e9 en m\u00eame temps. Plus de nouvelles connexions r\u00e9seau, mais le ping r\u00e9pondait toujours. En fouillant le code du noyau XNU d’Apple (qui est open source, faut le rappeler), ils sont tomb\u00e9 sur une variable tcp_now, qui est un compteur 32 bits qui s’incr\u00e9mente chaque milliseconde. En gros, imaginez un compteur kilom\u00e9trique qui arriv\u00e9 au max (environ 4,3 milliards), repasse \u00e0 z\u00e9ro. Sauf que le code contient un garde fou cens\u00e9 emp\u00eacher l’horloge de reculer du genre “si la nouvelle valeur est plus petite que l’ancienne, on ne met pas \u00e0 jour“. \u00c7a a l’air malin mais en fait, au moment du rebouclage, patatras : la nouvelle valeur (proche de z\u00e9ro) est forc\u00e9ment plus petite que l’ancienne (proche du max), du coup le garde fou bloque tout et l’horloge TCP se fige. Et ensuite, \u00e7a part en cascade. Les connexions ferm\u00e9es restent normalement en TIME_WAIT durant 30 secondes sur macOS, avant d’\u00eatre nettoy\u00e9es par tcp_gc() mais avec l’horloge gel\u00e9e, ce nettoyage ne se fait plus. Un netstat -an | grep TIME_WAIT montre alors la catastrophe en temps r\u00e9el avec des connexions mortes qui s’empilent, et finissent par bouffer les 16 384 ports \u00e9ph\u00e9m\u00e8res (range 49152-65535 sur macOS) restant… Et au bout de quelques heures, plus rien ne passe ! Photon a laiss\u00e9 tourner deux machines apr\u00e8s l’overflow pour voir. Neuf heures plus tard, l’une affichait 8 000 connexions zombies et un load average de 49. La machine ne faisait plus que scanner sa propre file d’attente de connexions mortes. Si \u00e7a vous rappelle quelque chose, c’est normal car j’sais pas si vous vous souvenais mais Windows 95 plantait au bout du m\u00eame d\u00e9lai pour la m\u00eame raison (le fameux GetTickCount() en 32 bits). Le Boeing 787 avait \u00e9galement un souci similaire au bout de 51 jours sur ses switches r\u00e9seau, sans oublier le bug de l’an 2038 sous Unix, qui est la version sign\u00e9e du m\u00eame ph\u00e9nom\u00e8ne. 30 ans s\u00e9parent certains de ces bugs qui pourtant appartiennent \u00e0 la m\u00eame cat\u00e9gorie ! Apr\u00e8s flippez pas car des devs avec des Macs \u00e0 plus de 600 jours d’uptime disent n’avoir jamais eu le souci. \u00c0 vrai dire, le bug ne se d\u00e9clencherait que si votre Mac n’a aucun trafic TCP pile au moment de l’overflow. Si votre machine cause au r\u00e9seau en permanence (et c’est le cas de 99% des Macs), l’horloge passe le cap sans broncher. Les machines les plus expos\u00e9es sont en fait les serveurs CI\/CD sous macOS, les Mac mini en ferme de build Jenkins ou GitHub Actions, les Mac Pro d\u00e9di\u00e9s au rendu 3D avec Blender ou Cinema 4D. Le MacBook qui passe en veille tous les soirs n’est pas vraiment concern\u00e9 (le compteur tcp_now ne tourne pas pendant la veille, donc le d\u00e9lai de 49 jours ne concerne que le temps d’activit\u00e9 r\u00e9el). Maintenant pour v\u00e9rifier votre compte \u00e0 rebours personnel, ouvrez un Terminal et collez y ceci : boot_sec=$(sysctl kern.boottime | grep -o ‘sec = [0-9]*’ | head -1 | awk ‘{print $3}’) now_sec=$(date +%s) remain=$(( 4294967 – (now_sec – boot_sec) )) echo “Temps restant avant overflow : $((remain\/3600))h $((remain%3600\/60))m” Apple n’a pour l’instant rien communiqu\u00e9 sur le sujet, ce qui n’est gu\u00e8re surprenant vu que c’est un peu leur sp\u00e9cialit\u00e9 quand une vuln\u00e9rabilit\u00e9 est remont\u00e9e. L’\u00e9quipe de Photon dit travailler sur un moyen de contourner le probl\u00e8me qui \u00e9viterait de rebooter, mais en attendant, le seul fix c’est le red\u00e9marrage, qui remet le compteur \u00e0 z\u00e9ro… et relance le compte \u00e0 rebours. Bref, y’a rien \u00e0 faire si ce n’est de v\u00e9rifier votre uptime et faire \u00e9ventuellement un petit reboot pr\u00e9ventif. Tic tac, l’horloge tourne ^^. Source<\/p>\n","protected":false},"author":1,"featured_media":2690,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"give_campaign_id":0,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_kadence_starter_templates_imported_post":false,"footnotes":""},"class_list":["post-2689","page","type-page","status-publish","has-post-thumbnail","hentry"],"campaignId":"","_links":{"self":[{"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/pages\/2689","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/comments?post=2689"}],"version-history":[{"count":0,"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/pages\/2689\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/media\/2690"}],"wp:attachment":[{"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/media?parent=2689"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Apple n’a pour l’instant rien communiqu\u00e9 sur le sujet, ce qui n’est gu\u00e8re surprenant vu que
\nc’est un peu leur sp\u00e9cialit\u00e9<\/a>
\nquand une vuln\u00e9rabilit\u00e9 est remont\u00e9e. L’\u00e9quipe de Photon dit travailler sur un moyen de contourner le probl\u00e8me qui \u00e9viterait de rebooter, mais en attendant, le seul fix c’est le red\u00e9marrage, qui remet le compteur \u00e0 z\u00e9ro… et relance le compte \u00e0 rebours.<\/p>\n