Pourquoi Windows 7 / PuTTY abandonne les connexions TCP même lors de très brèves interruptions?

J'ai un petit réseau local qui se superpose à un WiFi captif, et j'utilise sshsur OS X avec -oServerAliveInterval=240et PuTTY 0.62 sur Windows 7 Professionnel pour établir des connexions avec mon Linode, Hetzner et d'autres serveurs.

Avec PuTTY, je sélectionne Connection→ Sending of null packets to keep session activeà 240. Le Enable TCP keepalives (SO_KEEPALIVE option)est désactivé, par défaut.

Lorsque mon Internet est temporairement hors service pendant environ une minute (je dois me réauthentifier sur le portail captif), PuTTY perd presque toujours toutes les sessions ssh ouvertes que j'ai, et en particulier celles où il y avait une activité, mais OpenSSH sur OS X ne perd jamais de sessions tant que mon Internet est sauvegardé dans environ une minute ou deux, même si j'essaie de taper quelque chose en ssh et de ne voir aucune réponse pendant 60 secondes environ, jusqu'à ce que ma connexion soit à nouveau active. (Je sais donc avec certitude que les états NAT sont toujours préservés.)

Puis-je empêcher Windows / PuTTY de supprimer de manière préventive les bonnes connexions?

Il me semble que SO_KEEPALIVE ou quelque chose de ce genre est réellement activé par défaut dans Windows, et le délai d'attente pour détecter les connexions périmées est beaucoup trop court. Je voudrais l'augmenter à quelque chose de plus que quelques secondes, de la même manière que l'OS X est immunisé contre ces brèves pannes temporaires tant que la panne n'est que de quelques centaines de secondes et est inférieure à la valeur de -oServerAliveInterval(fois ServerAliveCountMax).

— cnst
source

J'écris juste pour dire que j'ai le même problème et pour voter ... je regarderai cette question. Je suppose que cela a quelque chose à voir avec la mise en œuvre du pilote réseau sous Windows.

— allquixotic

J'utilise du mastic depuis 10 ans maintenant et je ne cherche pas de solution à cela depuis le début. Ce point douloureux ne peut être atténué, pas résolu. Putty nécessite une connexion Internet fiable à 100,00% et 0,00% des paquets perdus. Dans le nouveau monde de l'Internet toujours instable partout, le mastic devient de moins en moins utile au fil des ans, car il ne peut fonctionner que quelques minutes à la fois avant que votre travail ne soit interrompu et que vous deviez redémarrer le mastic, vous reconnecter , puis reprenez là où vous vous étiez arrêté, décompressez les fichiers corrompus et essayez de faire votre travail avant la prochaine panne.

— Eric Leschinski

@EricLeschinski, vous avez tort. Cette atténuation décrite dans cette question fonctionne très bien, je n'ai pas eu mes connexions IPv4 interrompues depuis très, très longtemps. (En dehors des cas où l'adresse IPv4 entière change, ou je fais un sommeil, etc. - pour ces cas, moshc'est une meilleure alternative.)

— cst

http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#faq-timeout

Il semble que TcpMaxDataRetransmissions(REG_DWORD) affecte directement cela. La valeur peut être ajoutée à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parametersavec regedit.exe(la clé est manquante par défaut, vous devez donc d'abord l'ajouter pour la modifier). Lorsqu'il n'est pas défini - c'est 5. Ajoutez-le, et définissez-le au moins sur f(15), et redémarrez.

La valeur par défaut de 5 semble tout à fait inadéquate pour conserver les connexions lors de brèves et temporaires pannes de réseau; vous obtiendrez un délai d'attente en quelques secondes. J'ai ajouté cette TcpMaxDataRetransmissionsclé au registre et défini sa valeur sur f(15), redémarré la machine et après avoir fait sysctl net.inet.ip.forwarding=0sur le routeur juste avant de taper un caractère dans PuTTY, le caractère m'a été renvoyé après avoir réactivé la redirection sur mon routeur après avoir attendu 5 minutes (je l'ai testé pour déterminer qu'une valeur de 0x0000000c (12) fait rompre la connexion exactement 7 minutes après la première tentative d'envoi d'un paquet pendant une panne). Avant le redémarrage, PuTTY expirait immédiatement la connexion en quelques secondes. Notez que le redémarrage était nécessaire - au moins sur Windows 7 Professionnel,simplement changer le registre n'a aucun effet sur les connexions existantes ou nouvelles ! Rien ne change jamais sous Windows!

Pendant qu'il y est, peut également ajouter et définir KeepAliveIntervalen 60000décimal (60 sec) à partir de la valeur par défaut de 1000(1 sec), mais il n'est pas censé avoir aucun effet dans mon cas spécifique comme ci-dessus, car les keepalives TCP n'étaient pas activés.

— cnst
source