j’ai un soucis au boulot, depuis plusieurs mois, qui commence à m’agacer un peu.
Ça peut paraitre tout con, je voudrais juste garder ma session putty/ssh ouverte quand le wifi merde ou qu’il y a une micro-coupure réseau.
Enfin je dis « je » mais c’est un client lourd pour un ERP qui utilise putty en arrière plan, et se ferme complètement dès qu’il y a une merdouille sur le réseau.
La version précédente de l’ERP utilisait rlogin/telnet et ne se coupait pas en cas de problème réseau, donc certains utilisateurs se plaignent de ce problème, et je peux les comprendre.
J’ai essayé toutes les options de putty/ssh aussi bien côté client que serveur (redhat /etc/ssh/sshd_config) donc TCPKeepAlive,ClientAliveInterval,ClientAliveInterval, etc.
Mais rien à faire, à chaque coupure, j’ai une erreur « Network error : Software caused connection abort » (je désactive/réactive la carte réseau pour tester).
J’ai essayé de comprendre comment ça fonctionnait, j’ai aussi lu que c’était Windows qui gérait la fermeture des connexions TCP et qu’il n’y avait rien à faire . Bref je trouve un peu de toute mais rien qui m’aide.
Est-ce que je demande la lune ? Est-ce que c’est possible d’une manière ou d’une autre ? Peut-être que couper la carte réseau est trop bourrin pour tester ? Ou va le monde ?
Bref plein de questions, si vous avez de quoi m’aiguiller dans ce bazar, je suis preneur
Essaie de tester aussi avec les options ServerAliveInterval, ServerAliveCountMax.
Mais bon j’y crois moyennement, et puis ça dépend un peu de la nature des coupures réseau en question, je ne sais pas si ce que tu veux faire sera possible tel que tu le décris.
En effet, que va t-il se passer lorsque le serveur va essayer de t’envoyer un message alors que ton client n’est pas joignable? je ne sais pas mais je suppose qu’après quelques tentatives il doit abandonner et fermer son socket.
Alternativement, tu peux donc explorer d’autres pistes:
Utiliser tmux (ou screen) pour conserver une session active côté serveur, ainsi lorsque le client se reconnecte il retrouve les choses dans l’état dans lequel il les avait laissées (même si un processus était actif dans le shell).
Utiliser autossh pour que le client se reconnecte automatiquement dès que la connexion revient (désolé je ne sais pas comment faire ça sous Windows, mais c’est probablement possible, peut être pas avec putty).
Au login, entrer automatiquement dans la session tmux (ou screen). Par exemple, avec tmux, dans ton ~/.bashrc tu pourrais mettre:
if [ -z "$TMUX" ]; then
tmux attach-session -t ma_session || tmux new-session -s ma_session
fi
(le test sur $TMUX permet d’éviter d’entrer dans la session alors qu’on y est déjà si le bashrc est réinterprêté).
Ceci combiné avec autossh permettrait peut-être de contourner ton problème.
En réseau il y a coupure et coupure. Tout dépend si c’est une perte de liaison physique ou si c’est « juste » une perte de paquet ponctuelle.
Le deuxième cas ne devrait pas, dans une certaine mesure (ça dépend de la sévérité de perte de paquet), entrainer de coupure de connexion ssh.
Dans le premier cas, si ton interface tombe côté client (même brièvement), tu vas perdre la table de routage associée (au moins temporairement) et il y a de fortes chances que toutes les sessions tcp ouvertes utilisant cette table de routage soient clôturées sans autre forme de procès.
Tu peux tester un truc un peu dégueulasse : avoir une route vers ton serveur toujours valide mais avec une métrique beaucoup plus élevée pour qu’elle ne soit utilisée qu’en cas de perte de liaison. Cela devrait permettre de pouvoir conserver les socket tcp ouverts (sous réserve que la coupure soit suffisamment brève pour que les timers ne ferment pas les sessions tcp d’eux-même).
Le mieux étant bien sûr de résoudre ton problème de stabilité réseau plutôt que de passer par des workaround pas très propre…
A une époque lointaine, j’avais eu le même genre de pb et en installant un VPN par dessus ça avait résolu le pb, le VPN se chargeant de bufferiser et rétablir la communication. L’appli voyait l’interface du VPN stable…
Comme suggéré par @Pollux ta méthode de test n’est pas bonne. Si tu coupe l’interface tu fait sauter tout l’état de la connexion. Débrancher le câble de la carte n’est pas mieux.
Effectivement ça fait parti des pistes vues sur le net, malheureusement non applicable dans mon cas. En effet la coupure ssh n’est que la première entraine aussi la fermeture du client lourd et de toute la session utilisateur, rétablir la connexion se réouvrira pas le client, c’est pourquoi j’essaye de garder la connexion ouverte et qu’elle ne se ferme pas du tout
Alors je suis pas sur d’avoir tout compris, mais intervenir au niveau du réseau n’est pas possible. Le soft est chez plusieurs clients chez qui nous ne gérons pas le réseau. A la rigueur je peux leur suggérer de tester un autre câble réseau ou une autre carte réseau/un autre pc. Sinon je n’ai la main que sur le serveur et éventuellement sur le poste client.
Ok merci, ça me parait difficile à mettre en place chez les clients mais je garde ça en tête.
Je me disais aussi que c’était un peu bourrin, je vais regarder avec clumsy + ClientAliveInterval/ClientAliveCountMax
. Bref je trouve un peu de toute mais rien qui m’aide.