Qualité et vitesse ne sont pas toujours synonymes 
Un ping à 18ms indique que le ping entre votre ordinateur et le server pingé à mis 18ms.
Ça ne veut pas forcément dire que les X prochains pings seront aussi rapides ou même qu’ils arriveront avant le timeout.
Oui, vous pouvez utiliser l’adresse IP des serveurs DNS de Google. S’ils tombent, c’est que c’est la guerre…
bonjour,
pour information, Ariase ping votre box à partir de ses propres serveurs pour les tests de rapidité de connexion.
Leurs serveurs sont dits disponibles, rapides, et surtout connectés sur une ligne ADSL de qualité (ligne louée)
Ne pas avoir de réponse au ping ne signifiera pas forcément que votre connexion est HS.
Certains serveurs ne répondent pas au ping. C’est le cas des serveurs Microsoft (depuis une attaque d’un pirate qui a paralysé les serveurs en lançant un ping à partir d’un grand nombre de machines).
Le ping vers des serveurs très sollicités sera aussi aléatoire.
c’est le cas avec l’adresse que vous communiquez 8.8.8.8 : 2 paquets perdus sur 4
De plus, si l’adresse fixe de ce serveur est modifiée, vous n’aurez plus de réponse.
Vous pouvez alors tenter de pinguer un serveur par son nom.
Prenons par exemple smtp.gmail.com
il faut faire des tests préalables. vous pouvez tenter de pinguer la maison blanche www.whitehouse.gov
bien que lointaine, elle répond en moins de 30 ms (à moins que Mars Attack)
cdt
Pour moi, smtp.gmail.com et 8.8.8.8 ne sont pas très fiable 
→ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=57 time=20.268 ms
Request timeout for icmp_seq 1
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=20.367 ms
Request timeout for icmp_seq 3
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=20.085 ms
Request timeout for icmp_seq 5
64 bytes from 8.8.8.8: icmp_seq=6 ttl=57 time=19.786 ms
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
64 bytes from 8.8.8.8: icmp_seq=9 ttl=57 time=20.556 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=57 time=19.960 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=57 time=19.891 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=57 time=20.344 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=57 time=20.103 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=57 time=20.062 ms
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
64 bytes from 8.8.8.8: icmp_seq=18 ttl=57 time=20.097 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=57 time=20.158 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=57 time=19.871 ms
64 bytes from 8.8.8.8: icmp_seq=21 ttl=57 time=20.001 ms
Request timeout for icmp_seq 22
64 bytes from 8.8.8.8: icmp_seq=23 ttl=57 time=20.316 ms
Request timeout for icmp_seq 24
64 bytes from 8.8.8.8: icmp_seq=25 ttl=57 time=20.200 ms
Request timeout for icmp_seq 26
64 bytes from 8.8.8.8: icmp_seq=27 ttl=57 time=20.097 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=57 time=20.157 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=57 time=20.100 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=57 time=20.390 ms
Request timeout for icmp_seq 31
64 bytes from 8.8.8.8: icmp_seq=32 ttl=57 time=20.067 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=57 time=20.375 ms
Request timeout for icmp_seq 34
64 bytes from 8.8.8.8: icmp_seq=35 ttl=57 time=20.171 ms
64 bytes from 8.8.8.8: icmp_seq=36 ttl=57 time=20.221 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=57 time=20.363 ms
Request timeout for icmp_seq 38
Request timeout for icmp_seq 39
64 bytes from 8.8.8.8: icmp_seq=40 ttl=57 time=20.119 ms
64 bytes from 8.8.8.8: icmp_seq=41 ttl=57 time=20.048 ms
Request timeout for icmp_seq 42
Request timeout for icmp_seq 43
Request timeout for icmp_seq 44
Request timeout for icmp_seq 45
64 bytes from 8.8.8.8: icmp_seq=46 ttl=57 time=20.250 ms
64 bytes from 8.8.8.8: icmp_seq=47 ttl=57 time=20.619 ms
64 bytes from 8.8.8.8: icmp_seq=48 ttl=57 time=20.408 ms
^C
--- 8.8.8.8 ping statistics ---
49 packets transmitted, 30 packets received, 38.8% packet loss
round-trip min/avg/max/stddev = 19.786/20.182/20.619/0.191 ms
→ ping smtp.gmail.com
PING gmail-smtp-msa.l.google.com (74.125.195.108): 56 data bytes
64 bytes from 74.125.195.108: icmp_seq=0 ttl=47 time=23.997 ms
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 74.125.195.108: icmp_seq=3 ttl=47 time=24.409 ms
64 bytes from 74.125.195.108: icmp_seq=4 ttl=47 time=24.047 ms
Request timeout for icmp_seq 5
64 bytes from 74.125.195.108: icmp_seq=6 ttl=47 time=24.274 ms
64 bytes from 74.125.195.108: icmp_seq=7 ttl=47 time=24.227 ms
64 bytes from 74.125.195.108: icmp_seq=8 ttl=47 time=23.843 ms
Request timeout for icmp_seq 9
64 bytes from 74.125.195.108: icmp_seq=10 ttl=47 time=23.990 ms
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
64 bytes from 74.125.195.108: icmp_seq=13 ttl=47 time=24.093 ms
Request timeout for icmp_seq 14
64 bytes from 74.125.195.108: icmp_seq=15 ttl=47 time=23.845 ms
64 bytes from 74.125.195.108: icmp_seq=16 ttl=47 time=24.032 ms
64 bytes from 74.125.195.108: icmp_seq=17 ttl=47 time=24.141 ms
64 bytes from 74.125.195.108: icmp_seq=18 ttl=47 time=23.914 ms
64 bytes from 74.125.195.108: icmp_seq=19 ttl=47 time=23.930 ms
64 bytes from 74.125.195.108: icmp_seq=20 ttl=47 time=23.996 ms
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
Request timeout for icmp_seq 23
64 bytes from 74.125.195.108: icmp_seq=24 ttl=47 time=24.157 ms
Request timeout for icmp_seq 25
Request timeout for icmp_seq 26
Request timeout for icmp_seq 27
Request timeout for icmp_seq 28
64 bytes from 74.125.195.108: icmp_seq=29 ttl=47 time=24.427 ms
64 bytes from 74.125.195.108: icmp_seq=30 ttl=47 time=24.066 ms
Request timeout for icmp_seq 31
Request timeout for icmp_seq 32
64 bytes from 74.125.195.108: icmp_seq=33 ttl=47 time=23.924 ms
64 bytes from 74.125.195.108: icmp_seq=34 ttl=47 time=24.032 ms
64 bytes from 74.125.195.108: icmp_seq=35 ttl=47 time=23.949 ms
Request timeout for icmp_seq 36
64 bytes from 74.125.195.108: icmp_seq=37 ttl=47 time=23.924 ms
Request timeout for icmp_seq 38
Request timeout for icmp_seq 39
Request timeout for icmp_seq 40
Request timeout for icmp_seq 41
Request timeout for icmp_seq 42
Request timeout for icmp_seq 43
64 bytes from 74.125.195.108: icmp_seq=44 ttl=47 time=23.973 ms
Request timeout for icmp_seq 45
Request timeout for icmp_seq 46
64 bytes from 74.125.195.108: icmp_seq=47 ttl=47 time=23.950 ms
64 bytes from 74.125.195.108: icmp_seq=48 ttl=47 time=24.087 ms
Request timeout for icmp_seq 49
Request timeout for icmp_seq 50
Request timeout for icmp_seq 51
Request timeout for icmp_seq 52
64 bytes from 74.125.195.108: icmp_seq=53 ttl=47 time=24.230 ms
64 bytes from 74.125.195.108: icmp_seq=54 ttl=47 time=24.050 ms
Request timeout for icmp_seq 55
64 bytes from 74.125.195.108: icmp_seq=56 ttl=47 time=24.127 ms
Request timeout for icmp_seq 57
64 bytes from 74.125.195.108: icmp_seq=58 ttl=47 time=23.984 ms
Request timeout for icmp_seq 59
Request timeout for icmp_seq 60
Request timeout for icmp_seq 61
64 bytes from 74.125.195.108: icmp_seq=62 ttl=47 time=24.214 ms
64 bytes from 74.125.195.108: icmp_seq=63 ttl=47 time=23.952 ms
64 bytes from 74.125.195.108: icmp_seq=64 ttl=47 time=24.212 ms
Request timeout for icmp_seq 65
64 bytes from 74.125.195.108: icmp_seq=66 ttl=47 time=24.102 ms
64 bytes from 74.125.195.108: icmp_seq=67 ttl=47 time=24.302 ms
64 bytes from 74.125.195.108: icmp_seq=68 ttl=47 time=24.175 ms
64 bytes from 74.125.195.108: icmp_seq=69 ttl=47 time=24.175 ms
^C
--- gmail-smtp-msa.l.google.com ping statistics ---
70 packets transmitted, 35 packets received, 50.0% packet loss
round-trip min/avg/max/stddev = 23.843/24.079/24.427/0.145 ms
Par contre, la 
blanche m’a l’air bien plus fiable 
→ ping www.whitehouse.gov
PING e4036.dscb.akamaiedge.net (104.124.194.98): 56 data bytes
64 bytes from 104.124.194.98: icmp_seq=0 ttl=57 time=19.845 ms
64 bytes from 104.124.194.98: icmp_seq=1 ttl=57 time=20.032 ms
64 bytes from 104.124.194.98: icmp_seq=2 ttl=57 time=19.886 ms
64 bytes from 104.124.194.98: icmp_seq=3 ttl=57 time=19.652 ms
64 bytes from 104.124.194.98: icmp_seq=4 ttl=57 time=20.027 ms
64 bytes from 104.124.194.98: icmp_seq=5 ttl=57 time=20.023 ms
64 bytes from 104.124.194.98: icmp_seq=6 ttl=57 time=20.093 ms
64 bytes from 104.124.194.98: icmp_seq=7 ttl=57 time=19.913 ms
64 bytes from 104.124.194.98: icmp_seq=8 ttl=57 time=19.917 ms
64 bytes from 104.124.194.98: icmp_seq=9 ttl=57 time=19.790 ms
64 bytes from 104.124.194.98: icmp_seq=10 ttl=57 time=19.842 ms
64 bytes from 104.124.194.98: icmp_seq=11 ttl=57 time=19.725 ms
64 bytes from 104.124.194.98: icmp_seq=12 ttl=57 time=19.724 ms
64 bytes from 104.124.194.98: icmp_seq=13 ttl=57 time=19.681 ms
64 bytes from 104.124.194.98: icmp_seq=14 ttl=57 time=19.899 ms
64 bytes from 104.124.194.98: icmp_seq=15 ttl=57 time=19.887 ms
64 bytes from 104.124.194.98: icmp_seq=16 ttl=57 time=19.615 ms
64 bytes from 104.124.194.98: icmp_seq=17 ttl=57 time=19.715 ms
64 bytes from 104.124.194.98: icmp_seq=18 ttl=57 time=19.710 ms
64 bytes from 104.124.194.98: icmp_seq=19 ttl=57 time=19.723 ms
64 bytes from 104.124.194.98: icmp_seq=20 ttl=57 time=19.837 ms
64 bytes from 104.124.194.98: icmp_seq=21 ttl=57 time=19.895 ms
64 bytes from 104.124.194.98: icmp_seq=22 ttl=57 time=20.014 ms
64 bytes from 104.124.194.98: icmp_seq=23 ttl=57 time=19.773 ms
64 bytes from 104.124.194.98: icmp_seq=24 ttl=57 time=20.049 ms
64 bytes from 104.124.194.98: icmp_seq=25 ttl=57 time=19.726 ms
64 bytes from 104.124.194.98: icmp_seq=26 ttl=57 time=20.122 ms
64 bytes from 104.124.194.98: icmp_seq=27 ttl=57 time=19.852 ms
64 bytes from 104.124.194.98: icmp_seq=28 ttl=57 time=19.837 ms
64 bytes from 104.124.194.98: icmp_seq=29 ttl=57 time=19.400 ms
64 bytes from 104.124.194.98: icmp_seq=30 ttl=57 time=19.557 ms
64 bytes from 104.124.194.98: icmp_seq=31 ttl=57 time=19.690 ms
64 bytes from 104.124.194.98: icmp_seq=32 ttl=57 time=20.021 ms
64 bytes from 104.124.194.98: icmp_seq=33 ttl=57 time=20.063 ms
64 bytes from 104.124.194.98: icmp_seq=34 ttl=57 time=20.096 ms
64 bytes from 104.124.194.98: icmp_seq=35 ttl=57 time=19.913 ms
64 bytes from 104.124.194.98: icmp_seq=36 ttl=57 time=19.964 ms
64 bytes from 104.124.194.98: icmp_seq=37 ttl=57 time=19.833 ms
64 bytes from 104.124.194.98: icmp_seq=38 ttl=57 time=20.084 ms
64 bytes from 104.124.194.98: icmp_seq=39 ttl=57 time=19.779 ms
64 bytes from 104.124.194.98: icmp_seq=40 ttl=57 time=20.142 ms
64 bytes from 104.124.194.98: icmp_seq=41 ttl=57 time=19.999 ms
64 bytes from 104.124.194.98: icmp_seq=42 ttl=57 time=19.545 ms
64 bytes from 104.124.194.98: icmp_seq=43 ttl=57 time=20.076 ms
^C
--- e4036.dscb.akamaiedge.net ping statistics ---
44 packets transmitted, 44 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 19.400/19.863/20.142/0.173 ms
Mais au vu de la paranoïa américaine, j’éviterais de pinger indéfiniment ce site…
Alternativement, on peut utiliser les serveurs d’OpenDNS (de resolver1.opendns.com à resolver4.opendns.com).
sinon, il suffit de pinguer le DNS de son FAI.
smtp.gmail.com c’était pour l’exemple de l’usage du nom, plûtot que l’IP fixe qui n’est peut être plus utilisée. au même titre que le 2e DNS google : 8.8.4.4
il paraît qu’il fait beau à Guantanamo. un peu de vacances … 
Pour ma part, afin de tester ma latence sur le réseau je pinguais la première passerelle réseau de mon FAI.
si j’arrive a la pinguer, j’ai pas forcément le net, mais déjà ça sert a rien de rebooter la box.
pour la trouver, il suffit de faire un traceroute/tracepath vers une adresse internet et de regarder la première adresse en dehors du réseau local.
oui, sous windows, on peut lancer la commande
tracert -4 www.google.com
(-4 force l’usage de IPv4)
la 1ère IP affichée sera celle du routeur local
la 2eme celle du DSLAM du FAI
Pouah! Cela à généré des réponses! ^^
Je ferai des essais et je dirai ce qu’il en est.
Merci
J’ai fais plusieurs test avec l’invite de commande et c’est vrai que j’ai des pertes sur les DNS de Google.
Par contre le DNS de Free me parait être la bonne solution mais effectivement le serveur de Free peut répondre à chaque fois sans pour autant avoir un accès internet si le problème est chez eux.
J’ai eu une idée que j’ai testé et qui me parait fonctionner, vous allez peut être pouvoir me le confirmer.
J’ai pingué mon IP tout simplement et ça fonctionne, j’ai testé tout ça en débranchant la box de ma ligne FT donc plus d’accès vers le DNS de Free ni vers mon IP mais accès à tout ce qui est sous le réseau local.
J’ai rebranché, c’était de nouveau accessible.
Donc pourquoi ne pas pinguer sa propre IP tout simplement?
Il est possible que votre adresse IP publique change (en fonction des besoins de votre FAI).
Ah ok. Du coup si cela arrive, il me faudra la modifier dans ma redirection de port pour l’accès a l’IPX depuis l’extérieur je suppose?
Bonjour,
si vous avez opté pour une IP fixe chez votre FAI (chez Free c’est gratuit, je suis en IP fixe depuis 10 ans), vous pouvez pinguer votre IP publique.
Dans ce cas, faites un Tracert vers votre IP. Vous verrez que vous ne dépassez pas le DSLAM. Cela ne vous certifie donc pas un accès internet non plus si on suit votre raisonnement.
Si vous êtes en NO-IP, vous pouvez faire un tracert également vers votre nom de domaine NO-IP. vous verrez bien si vous utilisez plus de dispositifs externes.
Dans ce cas pinguez un second DNS, ou bien un nom de domaine (ce qui utilisera le dns du FAI)
Votre accès internet sera actif si 1 ping est ok;
Mais le doute existera toujours, vous aurez beau multiplier les pings, il suffit que l’un d’eux ne réponde pas.
Donc, en connaissance de cause, pinguez un serveur que vous jugez stable (serveur de temps par exemple) et rebootez si pas de ping.
Vous rebooterez sûrement la freebox pour rien, quelques fois, mais comment faire autrement. Il n’y a pas de méthode infaillible, car il n’y a pas de serveur infaillible.
cdt
Non, votre adresse publique n’a rien à voir avec vos règles NAT.
cdt
Ok merci pour ces infos.
Je viens de mettre ça en test sur une sortie virtuelle avec un compteur afin de savoir s’il se déclenche et combien de fois. Je test en coupant le net le scénario se lance. Par contre l’appel du ping ne se fait qu’une fois? Il n’y a pas moyen de le lancer genre toute les X minutes quand il n’y a pas de connexion?
Si pas de réponse de ping j’ai un premier déclenchement de mon scénario mais si le ping ne répond toujours pas après j’ai pas de remise en route du scénario donc pas de nouveau reboot.
Est ce possible de modifier cela?
je n’ai pas encore IP V4. je ne peux pas répondre de manière précise.
Mais je me demande s’il n’existe pas un plannificateur de scènes ?
ou bien un compte à rebours ?
EDIT : en fait, il existe un paramètre : « Temps entre 2 pings »
mais je ne saurais vous guider plus.
cdt
J’ai l’impression que le temps entre les ping est en fait le temps entre chaque essais.
On renseigne le nombre d’essais pour chaque ping.
J’ai pas l’impression que ce soit une boucle continue d’envoi de ping??
Ou peut être que mon scénario est mal construit?
Ma sortie virtuelle (qui simule le relais de ma box) est avec un TB 20 pour avoir une coupure de 2sec.
Selon vos paramètres : l’IPX va pinger toutes les IPs configurées toutes les 10 secondes.
Pour l’IP « 213.228.11.254 », le ping watchdog passera à 1 (ON) si 4 pings à la suite ne sont pas revenu dans le temps imparti.
Il vous faut donc attendre au moins 4 * 10 = 40 secondes avant un changement d’état
C’est le même principe pour le retour à 0 (OFF), il faut 4 pings à la suite qui reviennent dans le temps imparti.
Petit retour la dessus. J’ai donc mis en place le ping watchdog sur le premier DNS de Free que j’ai eu en faisant Trace Route.
En scénario pendant 10 jours sur une sortie virtuelle et un compteur pour voir si le ping se déclenchait intempestivement et RAS. J’ai donc mis ça en place sur mon relais Freebox.
Merci pour vos conseil.
