Micro-déconnexions

Bonjour,
Depuis quelques jours, ma connexion est interrompue lors d'une vingtaine de secondes. Cela se produit entre tous les 30 minutes voire toutes les 3 heures.
Je voulais savoir si ce problème était du au VPN directement ou au fournisseur d'internet (soit le CROUS de Toulouse).
Sur le journal, il est mentionné 2 déconnexions, une à 12 H 03, et une autre à 14 H 51 (corps de texte trop long, j'ai supprimé la partie sur cete dernière coupure).

FrozenWay version 1.6.6
----------------------------------
Server: public-01-fr-01
Protocol: OpenVPN
----------------------------------
Sat May 19 11:35:59 2018 OpenVPN 2.3.8 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug 27 2015
Sat May 19 11:35:59 2018 library versions: OpenSSL 1.0.1p 9 Jul 2015, LZO 2.08

Sat May 19 11:36:00 2018 Control Channel Authentication: using 'C:/Users/Thomas/Documents/FrozenWay 1.6.6/FrozenWay 1.6.6/etc/keys/auth.key' as a OpenVPN static key file
Sat May 19 11:36:00 2018 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat May 19 11:36:00 2018 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat May 19 11:36:00 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sat May 19 11:36:00 2018 Attempting to establish TCP connection with [AF_INET]87.98.166.29:443 [nonblock]

Sat May 19 11:36:01 2018 TCP connection established with [AF_INET]87.98.166.29:443
Sat May 19 11:36:01 2018 TCPv4_CLIENT link local: [undef]
Sat May 19 11:36:01 2018 TCPv4_CLIENT link remote: [AF_INET]87.98.166.29:443

Sat May 19 11:36:01 2018 TLS: Initial packet from [AF_INET]87.98.166.29:443, sid=4c50de2a 3821950c

Sat May 19 11:36:01 2018 VERIFY OK: depth=1, C=FR, ST=France, L=Paris, O=FrozenWay, OU=FrozenWay, CN=FrozenWay, emailAddress=admin@frozenway.com
Sat May 19 11:36:01 2018 VERIFY OK: nsCertType=SERVER
Sat May 19 11:36:01 2018 VERIFY OK: depth=0, C=FR, ST=France, O=FrozenWay, OU=FrozenWay, CN=FrozenWay, emailAddress=admin@frozenway.com

Sat May 19 11:36:02 2018 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat May 19 11:36:02 2018 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat May 19 11:36:02 2018 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat May 19 11:36:02 2018 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat May 19 11:36:02 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Sat May 19 11:36:02 2018 [FrozenWay] Peer Connection Initiated with [AF_INET]87.98.166.29:443

Sat May 19 11:36:04 2018 SENT CONTROL [FrozenWay]: 'PUSH_REQUEST' (status=1)

Sat May 19 11:36:05 2018 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.13.0.1,dhcp-option WINS 10.13.0.1,route 10.13.0.1,topology net30,socket-flags TCP_NODELAY,ifconfig 10.13.6.2 10.13.6.1'
Sat May 19 11:36:05 2018 OPTIONS IMPORT: --socket-flags option modified
Sat May 19 11:36:05 2018 OPTIONS IMPORT: --ifconfig/up options modified
Sat May 19 11:36:05 2018 OPTIONS IMPORT: route options modified
Sat May 19 11:36:05 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat May 19 11:36:05 2018 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat May 19 11:36:05 2018 open_tun, tt->ipv6=0
Sat May 19 11:36:05 2018 TAP-WIN32 device [FrozenWay] opened: \\.\Global\{EBFD4713-5197-4432-883A-FACB4E994819}.tap
Sat May 19 11:36:05 2018 TAP-Windows Driver Version 9.21
Sat May 19 11:36:05 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.13.6.2/255.255.255.252 on interface {EBFD4713-5197-4432-883A-FACB4E994819} [DHCP-serv: 10.13.6.1, lease-time: 31536000]
Sat May 19 11:36:05 2018 Successful ARP Flush on interface [17] {EBFD4713-5197-4432-883A-FACB4E994819}

Sat May 19 11:36:10 2018 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Sat May 19 11:36:10 2018 C:\WINDOWS\system32\route.exe ADD 10.13.0.1 MASK 255.255.255.255 10.13.6.1
Sat May 19 11:36:10 2018 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
Sat May 19 11:36:10 2018 Route addition via IPAPI succeeded [adaptive]
Sat May 19 11:36:10 2018 Initialization Sequence Completed

IPv4 routing table :
0.0.0.0 0.0.0.0 172.17.160.2 172.17.160.187 35
0.0.0.0 128.0.0.0 10.13.6.1 10.13.6.2 35
10.13.0.1 255.255.255.255 10.13.6.1 10.13.6.2 35
10.13.6.0 255.255.255.252 10.13.6.2 10.13.6.2 291
10.13.6.2 255.255.255.255 10.13.6.2 10.13.6.2 291
10.13.6.3 255.255.255.255 10.13.6.2 10.13.6.2 291
87.98.166.29 255.255.255.255 172.17.160.2 172.17.160.187 35
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 331
127.0.0.1 255.255.255.255 127.0.0.1 127.0.0.1 331
127.255.255.255 255.255.255.255 127.0.0.1 127.0.0.1 331
128.0.0.0 128.0.0.0 10.13.6.1 10.13.6.2 35
172.17.160.0 255.255.240.0 172.17.160.187 172.17.160.187 291
172.17.160.187 255.255.255.255 172.17.160.187 172.17.160.187 291
172.17.175.255 255.255.255.255 172.17.160.187 172.17.160.187 291
224.0.0.0 240.0.0.0 127.0.0.1 127.0.0.1 331
224.0.0.0 240.0.0.0 10.13.6.2 10.13.6.2 291
224.0.0.0 240.0.0.0 172.17.160.187 172.17.160.187 291
255.255.255.255 255.255.255.255 127.0.0.1 127.0.0.1 331
255.255.255.255 255.255.255.255 10.13.6.2 10.13.6.2 291
255.255.255.255 255.255.255.255 172.17.160.187 172.17.160.187 291
Sat May 19 12:03:38 2018 read TCPv4_CLIENT: Connection timed out (WSAETIMEDOUT) (code=10060)
Sat May 19 12:03:38 2018 Connection reset, restarting [-1]
Sat May 19 12:03:38 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sat May 19 12:03:38 2018 Restart pause, 1 second(s)

Sat May 19 12:03:39 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sat May 19 12:03:39 2018 Attempting to establish TCP connection with [AF_INET]87.98.166.29:443 [nonblock]

Sat May 19 12:03:40 2018 TCP connection established with [AF_INET]87.98.166.29:443
Sat May 19 12:03:40 2018 TCPv4_CLIENT link local: [undef]
Sat May 19 12:03:40 2018 TCPv4_CLIENT link remote: [AF_INET]87.98.166.29:443
Sat May 19 12:03:40 2018 TLS: Initial packet from [AF_INET]87.98.166.29:443, sid=37806b85 6576a5d8

Sat May 19 12:03:40 2018 VERIFY OK: depth=1, C=FR, ST=France, L=Paris, O=FrozenWay, OU=FrozenWay, CN=FrozenWay, emailAddress=admin@frozenway.com
Sat May 19 12:03:40 2018 VERIFY OK: nsCertType=SERVER
Sat May 19 12:03:40 2018 VERIFY OK: depth=0, C=FR, ST=France, O=FrozenWay, OU=FrozenWay, CN=FrozenWay, emailAddress=admin@frozenway.com

Sat May 19 12:03:41 2018 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat May 19 12:03:41 2018 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat May 19 12:03:41 2018 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat May 19 12:03:41 2018 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat May 19 12:03:41 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Sat May 19 12:03:41 2018 [FrozenWay] Peer Connection Initiated with [AF_INET]87.98.166.29:443

Sat May 19 12:03:43 2018 SENT CONTROL [FrozenWay]: 'PUSH_REQUEST' (status=1)

Sat May 19 12:03:43 2018 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.13.0.1,dhcp-option WINS 10.13.0.1,route 10.13.0.1,topology net30,socket-flags TCP_NODELAY,ifconfig 10.13.6.2 10.13.6.1'
Sat May 19 12:03:43 2018 OPTIONS IMPORT: --socket-flags option modified
Sat May 19 12:03:43 2018 OPTIONS IMPORT: --ifconfig/up options modified
Sat May 19 12:03:43 2018 OPTIONS IMPORT: route options modified
Sat May 19 12:03:43 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat May 19 12:03:43 2018 Preserving previous TUN/TAP instance: FrozenWay
Sat May 19 12:03:43 2018 Initialization Sequence Completed

Réponses

  • Bonjour.

    Sans avoir les connaissances nécessaires pour envoyer des informations de connexion aussi détaillées, j'aimerais signaler avoir exactement le même problème en étant également dépendant du CROUS de Toulouse. La même question me vient alors, le problème vient-il de notre administrateur réseau, ou de Frozenway ?

    Cordialement.
    Sigvald.
  • Mise à jour ici, avec des crashlogs de ma part, le problème persistant :

    https://pastebin.com/ZvkShVPa

    Ici enregistrés trois crashs ayant eu lieu entre 19h42 et 22h14.

    Cordialement.
    Sigvald.
  • Bonjour,
    Les déconnexions se poursuient. Mais certaines ne sont pas enregistrées par le journal de FrozenWay (elles semblent encore plus courtes).
    Cela signifie t-il que le poblème est dû au fournisseur CROUS (le responsable réseau ne m'a pas répondu non plus) ?
  • Bonjour,

    Désolé pour le temps de réponse.

    Est-ce que vous vous connectez en WiFi ? Si oui, qu'en est-il de la qualité du signal ?

    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.
  • Bonjour,
    Je me connecte atuellement en réseau filaire.

    Test sans FrozenWay : https://speedof.me/show.php?img=180528144533-1351.png
    Test avec FrozenWay : https://speedof.me/show.php?img=180528144716-5499.png

    Je n'ai toujours pas de réponse du fournisseur réseau par contre.
  • Votre connexion a l'air très stable, pas de pertes de paquets apparente. De plus le FAI du CROUS, RENATER ne semble pas avoir d'accidents en cours (https://pasillo.renater.fr/TICKETS/historique-tickets.incidents.html). Ça peut donc venir d'un soucis materiel sur le réseau local (un switch ou routeur défectueux ou mal configuré).

    Arrivez-vous à télécharger un gros fichier (plusieurs Go) sans qu'il n'y ait de déconnexion (sans FrozenWay de connecté) ?
  • Je n'ai pas de gros fichier à DL là tout de suite, sous la main.
    Le problème peut-il provenir du cable réseau ?
    Je sais néanmoins que les déconnexions peuvent avoir lieu, lorsque le PC est inutilisé (je l'ai laissé tourner une nuit avec FrozenWay, et le matin, le logiciel m'a mentionné 2 déconnexions).

    Lors d'une matinée, j'ai joué à un jeu vidéo. Résultat : 9 déconnexions pour à peu près 4 heures de jeu.
    Il semble que les déconnexions soient plus importantes si la demande en réseau est plus forte.

    Par ailleurs, une partie des déconnexions n'est pas mentionnée par FrozenWay, elle s'est simplement manifestée par une absence de liaison entre le serveur de jeu et le PC (jeu "pausé" durant 15 secondes avant que les données ne reviennent subitement).
  • Ça va être compliqué à diagnostiquer, mais à mon avis, le soucis viens de la config réseau du CROUS.

    Il faudrait pouvoir télécharger un gros fichier et en même temps analyser la courbe de téléchargement et voir si il y a des creux de plusieurs secondes...
  • Je passe vite fait pour prévenir que je suis atteint des mêmes problèmes de connexion. J'utilise moi aussi la connexion du CROUS de Toulouse donc je pense que le problème vient de là.
  • J'ai quand même envoyé 5 mails au support. Il faut croire que les administrateurs réseau sont en vacances.
  • Bon du coup j'ai décidé de test un truc de mon côté. J'ai fait un ptit script qui ping YouTube toutes les 2 secondes pour vérifier que j'ai de la co. Je vais le laisser tourner un moment avec et sans FrozenWay pour avoir un verdict.
  • Ok, par contre les ping utilise le protocole ICMP qui ne passera pas par le proxy du CROUS. Donc si c'est le proxy qui est en cause, il ne devrait pas y avoir de problème de ping sans FrozenWay, mais avec oui car FrozenWay encapsule l'ICMP dans du TCP.
Connectez-vous ou Inscrivez-vous pour répondre.