Déco incessantes

Bonjour,
J'ai un problème depuis ce début d'année, (CROUS Toulouse) l'an dernier j'étais exactement au même endroit et je n'avais aucunes déconnexions, mais là j'en ai de manière random, je sais pas si cela vient de la co ou si je peux faire quelque chose, je vous donne le détail du journal de toute la journée (v 1.6.7 - premium-01-fr-03) :

https://pastebin.com/Qyh7sb6h

Réponses

  • Bonsoir,

    Il y a des déconnexions par timeout ce qui veut dire qu'aucune donnée ne passe pendant 30 secondes. C'est souvent dû à un mauvais signal WiFi.

    Est-ce que le temps où FrozenWay est connecté la connexion est bonne ?
  • Bonsoir, merci d'avoir répondu

    Je suis connecté en Ethernet, la liaison est juste coupée d'un instant à l'autre.
    Je précise que les déconnexions s'effectuent majoritairement quand FrozenWay est ouvert (et connecté) et que je fais quelque chose Discord/ Youtube / Jeux vidéo, du coup je ne vois pas bien d'où cela peut venir.

    Bonne soirée.
  • Bonsoir l'adresse 5.135.103.185 fait-elle référence à un de vos services ?
  • Bonsoir,

    Non l'adresse 5.135.103.185 ne nous appartient pas.

    Lancez un http://speedof.me avec ET sans FrozenWay de connecté et à la fin des tests, cliquez sur le bouton Share et copiez/collez ici l'url des résultats svp.
  • Je n'arrive pas à Share, chargement infini, un image suffit-elle ?
  • Oui, c'est pour voir la stabilité du réseau.
  • Bonjour,

    Désolé pour le temps de réponse ! Le speedtest ne montre pas d'instabilité particulière. Le problème est-il toujours d'actualité ?
  • Bonjour,
    Je me permets de remonter le sujet, faisant face au même problème. L'année dernière, le problème était déjà survenu.
    Les micro-déconnexions semblent être irrégulières (parfois toutes les 30 minutes, parfois toutes les 2 heures, rarement deux en 5 minutes), mais la plupart provoquent le relancement du protocole de FrozenWay. Certaines micro-déconnexions n'ont pas réinitialisé le VPN, mais elles ont été impactantes sur le programme que j'utilisais.

    Je précise que la connexion se fait par réseau filaire.

    Lien vers le journal FW (corps de texte trop long) : https://docs.google.com/document/d/18Txd-h8uZfInffXXhpGJO8ssKo0uU6d00WYNTNAnLB8/edit?usp=sharing

    L'année dernière, vous m'aviez demandé de lancer un gros téléchargement, afin de voir si la déconnexion pouvait survenir durant ledit téléchargement.
    J'ai donc téléchargé le jeu "Apex Legends" pendant la nuit dernière. Le lendemain, le journal indique 2 coupures, une à 02 heures du matin, puis une à 4 heures du matin.

    Je ne pense pas que FW est à l'origine de ce problème. Néanmoins, le problème semble trop en amont pour être corrigé par de simples utilisateurs, comme nous.
  • Bonjour,

    D'après votre journal, vous avez 5 déconnexions et à chaque fois c'est une erreur inconnue, ce qui n'est pas banal... Je miserai plus sur un problème de système d'exploitation... Avez-vous moyen de tester depuis un autre ordinateur sur le même réseau ?
  • Pas à ma connaissance.
    Si je crée une nouvelle partition disque avec Ubuntu dessus, cela pourra t-il servir de test ?
  • Oui. Sauf si le soucis est hardware mais j'en doute !
  • Bonjour,
    J'ai essayé sous Ubuntu 18.10, mais les déconnexions persistent. Sauf que cette fois-ci, FW ne se reconnecte pas automatique (l'option est bien coché néanmoins).
    Le journal précise une déconnexion suite à une inactivité. Or, j'avais lancé un téléchargement. Mystère.

    Lien vers le journal : https://docs.google.com/document/d/1RLdAz2M7wL7om6roo-A1J3fSvWMi1lb89zxE8phaZ08/edit?usp=sharing
  • Bonjour,

    Déconnexion suite à inactivité, ça veut dire que pendant 30 secondes, aucune donnée n'a été reçue par votre PC, et pourtant une nouvelle connexion fonctionne immédiatement...

    Surement un routeur entre votre PC et le serveur FrozenWay (le routeur de votre réseau je pense, sinon, beaucoup de personnes auraient le même problème) qui doit droper des connexions TCP à cause d'un manque de puissance ou de RAM.

    Je pense que quand je parlais de faire un gros téléchargement, je voulais dire sans FrozenWay de connecté, afin de vois si la connexion TCP tenait le coup sans FrozenWay sur la durée. Mais je pense qu'il n'y a rien à faire dans l'immédiat : / Il faudrait pouvoir détecter ces drops de connexion mais c'est compliqué car le routeur ne prévient pas, il ignore juste. Je vais voir si je peux améliorer ça dans le VPN que je suis en train de développer pour remplacer OpenVPN. Désolé de ne pas pouvoir en faire plus.
  • avril 2019 modifié
    imageBonjour,
    J'ai réalisé un test de ping avec le logiciel PingPlotter. Via une commande IP, j'ai récupéré une adresse IP qu'utilise le serveur d'un de mes jeux.

    J'ai attendu une déconnexion (qui est arrivée rapidemment). Voici les résultats du ping lors du crash. image" />
    Ou lien (si problème de visibilité) : https://zupimages.net/up/19/14/lg01.png

    Le serveur du jeu en lui-même présente 100 % de PL, ce qui est normal. Néanmoins, j'observe une forte augmentation des PL sur chaque routeur/noeud. Ces valeurs retombent ensuite doucement à 0, sauf pour le premier noeud, et le serveur à la fin (ce qui est normal pour le serveur).
    Le premier noeud, cependant, affiche environ 40 % de PL en temps normal, même lorsqu'il n'y a encore eu de déconnexion.

    Par ailleurs, lorsque je regarde la consommation de données Internet, via l'outil Windows, évidemment, la très grande majorité des données Web est consommée lorsque le VPN est actif (soit 90 % des données). Or, Windows peut seulement m'afficher la quantité de données consommées par FW lui-même. Je ne sais pas combien j'ai utilisé de données Web avec Firefox, par exemple, lorsque FW est actif, puisque Windows considère alors que c'est FW qui utilise de la data.
    Ma question : est ce que FW consomme de la data supplémentaire pour son fonctionnement ?
  • avril 2019 modifié
    FrozenWay ne transmet pas de données autres que celles des applications lancées sur le système. Il y a juste un léger overhead dû à l'encapsulation dans des paquets TCP.

    Le plus embêtant dans votre mtr (votre logiciel de ping effectue un mtr), c'est les ~40% de loss entre votre PC et le serveur FrozenWay. C'est énorme...

    Pour info, voici mon mtr connecté au même serveur et avec le même serveur en destination :

    image

    Et pourtant, je suis connecté en 4G...

    Pour savoir d'où viennent ces 40% de loss, il faudrait faire le mtr sans FrozenWay de connecté, mais comme votre réseau dois bloquer l'ICMP/UDP, il faudrait voir si votre logiciel permet de faire le mtr en TCP... Essayez de faire le mtr sans FrozenWay de connecté avec pour destination : 62.210.151.1 (c'est le routeur juste avant le serveur FrozenWay #2).
  • Bonjour,
    Malheureusement, le logiciel utilisait le protocole ICMP, ce qui était bloqué, comme vous l'aviez prévu. J'ai changé en protocole TCP, même résultat : bloqué.
    En revanche, le protocole UDP (si c'est un protocole, je me perds dans mon absence de connaissances) a fonctionné : https://zupimages.net/up/19/14/lqqy.png
  • Oui, UDP est bien un protocole. Il est aussi bloqué par votre réseau (ça envoi, mais ça ne reçoit rien).

    Mais ça permet de voir qu'il n'y a qu'un hop entre le routeur de votre réseau et le routeur du serveur FrozenWay. Ce qui n'est pas possible physiquement car entre Toulouse et Paris (où se trouve le serveur), RENATER n'a pas de lien direct. Du coup ils ont dû mettre en place des VPN entre les différents noeuds RENATER, ce qui explique qu'il n'y ait qu'un hop. On ne peut donc pas savoir quel routeur est en cause car les paquets sont encapsulés (de la même façon qu'avec FrozenWay, votre mtr ne montrait rien avant le serveur FrozenWay).

    J'ai 2 idées :

    - Premièrement, si les données encapsulées dans le VPN de RENATER passent par Montpellier -> Marseille -> Lyon -> Paris (ce qui est le plus probable), il est possible que vous soyez impacté par cet incident ouvert depuis le 5 mars et qui concerne une dégradation de la liaison entre Toulouse et Montpellier : https://pasillo.renater.fr/TICKETS/requete_ticket.php?NUMBER=1194411&DATER=1551803813

    Dans ce cas, il n'y a qu'à attendre qu'ils règlent le problème. Mais 40% de perte de paquets, ça me parait vraiment beaucoup...

    - Deuxièmement, il est possible que le port du switch sur lequel votre prise ethernet est connectée ait un défaut (rare, mais c'est déjà arrivé à un utilisateur FrozenWay). Du coup, il faudrait tester depuis une autre prise ethernet (dans un autre bâtiment idéalement) ou en WiFi.

    Liste des incidents RENATER : https://pasillo.renater.fr/TICKETS/historique-tickets.incidents.html
    Carte RENATER : https://pasillo.renater.fr/weathermap/weathermap_metropole.html
  • Bonjour,
    J'ai réalisé un test avec le réseau Wifi sur d'autres bâtiments. Résultat, aucun problème durant 1 heure 30.
    J'ai relancé deux PingPlotter :
    https://zupimages.net/up/19/14/hxzl.png (vers la destination 62.210.151.1)
    https://zupimages.net/up/19/14/nsvm.png (vers une IP de serveur de jeu vidéo)

    Je pense que votre deuxième hypothèse pourrait se valider. Après, je me demande si changer la prise que j'utilise résoudra le problème, ou si le problème serait plus "profond".
  • Ça peut être un problème au niveau de la prise ethernet, au niveau du câble, au niveau du switch, ou à cause d'une mauvaise configuration du routeur... Je ne peux malheureusement plus rien faire à ce niveau là : /
Connectez-vous ou Inscrivez-vous pour répondre.