Comment puis-je définir un court délai d'expiration avec la commande ping?
J'essaie d'écrire un script qui répertorie tous les hôtes sur mon réseau local (il y en a environ 20) et écrit l'état du ping à côté de chaque hôte. J'ai le fichier de baux DHCP, donc j'ai toutes les adresses IP (par exemple, 10.0.0.1, 10.0.0.2, etc.), tout ce dont j'ai besoin est le statut de ping pour chaque hôte.
Donc, mon script lance un seul ping pour chaque hôte:
ping -c 1 10.0.0.1
Malheureusement, lorsqu'un hôte est hors ligne, le ping met longtemps à expirer. J'ai vérifié man ping, il semble y avoir deux options pour définir le délai d'expiration: -w deadline et -W timeout. Je pense que je suis intéressé par ce dernier.
J'ai donc essayé ceci:
ping -c 1 -W 1 10.0.0.1
Mais attendre une seconde par hôte hors ligne est encore trop long. J'ai essayé de le régler en dessous d'une seconde, mais il ne semble pas du tout tenir compte du paramètre:
ping -c 1 -W 0.1 10.0.0.1 # timeout option is ignored, apparently
Existe-t-il un moyen de définir le délai d'expiration sur une valeur inférieure? Sinon, existe-t-il des alternatives?
Modifier
- L'O.S. est Debian Lenny.
- Les hôtes que j'essaye de cingler sont réellement des points d'accès. Ils sont sur le même vlan et sous-réseau que les utilisateurs (pour la simplicité du déploiement et du remplacement). C'est pourquoi je ne veux pas scanner tout le sous-réseau (avec un
ping -bpar exemple).
Éditer # 2
J'ai accepté la solution fping (merci pour toutes les autres réponses). Cette commande fait exactement ce que je cherchais:
fping -c1 -t500 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4
Cette commande prend au plus 500 ms pour se terminer et me donne l'état ping de tous les hôtes à la fois:
10.0.0.1 : [0], 84 bytes, 5.71 ms (5.71 avg, 0% loss)
10.0.0.2 : [0], 84 bytes, 7.95 ms (7.95 avg, 0% loss)
10.0.0.3 : [0], 84 bytes, 16.1 ms (16.1 avg, 0% loss)
10.0.0.4 : [0], 84 bytes, 48.0 ms (48.0 avg, 0% loss)
10.0.0.1 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 5.71/5.71/5.71
10.0.0.2 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 7.95/7.95/7.95
10.0.0.3 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 16.1/16.1/16.1
10.0.0.4 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 48.0/48.0/48.0
Sur Debian Lenny, l'installation est triviale:
aptitude update
aptitude install fping
fping pourrait être un meilleur outil que le ping standard que vous utilisez. Sur quel OS êtes-vous?
- "fping diffère de ping dans la mesure où vous pouvez spécifier n'importe quel nombre de cibles sur la ligne de commande, ou spécifier un fichier contenant les listes de cibles à envoyer."
- "Au lieu d'envoyer à une cible jusqu'à ce qu'elle expire ou réponde, fping enverra un paquet ping et passera à la cible suivante de manière alternée."
- "Contrairement à ping, fping est destiné à être utilisé dans des scripts, donc sa sortie est conçue pour être facile à analyser."
Pour les personnes à la recherche d'une solution impliquant ping, utilisez le -i commutateur.
ping -i 0.2 www.google.com
Ou, si vous souhaitez utiliser 0.1, vous devrez l'exécuter en tant que root
Sudo ping -i 0.1 www.google.com
Pas besoin de télécharger des utilitaires supplémentaires.
Vous pouvez définir un court délai d'expiration avec la commande timeout sur Ubuntu/Debian:
timeout 0.2 ping -c1 fqdn || { do_work }J'utiliserais nmap pour cette tâche.
nmap -sP --max-retries=1 --Host-timeout=1500ms 10.0.0.1
Voir nmap Documentation pour plus de détails à ce sujet.
vous voudrez peut-être regarder l'outil de ping arp si tous vos hôtes sont sur le LAN physique. Il fait la même chose mais utilise des paquets d'arp de couche 2 pour faire le 'ping'. Vous pouvez utiliser une combinaison d'arpping et de ping icmp, ou en fait de ping tcp, pour recueillir la nature de l'échec. Un exemple est un crash de la pile TCP, bien que rare de nos jours, nous pourrions trouver si une pile TCP de la machine s'est écrasée, car la machine ne répondrait pas au ping, mais elle répondrait à l'arp (qui est un morceau de code différent sur l'hôte) .
en utilisant une combinaison d'arpping, de tcpping et de ping icmp, vous pouvez savoir si le service sur la machine est tombé en panne, la pile tcp est tombée en panne ou la machine s'est complètement verrouillée. Si vous avez géré des commutateurs Ethernet, vous pouvez obtenir des données de liaison physique, révélant si la machine est réellement allumée ou si elle a été physiquement débranchée. Nous avons eu une situation où les machines (clients dans les salles publiques) seraient éteintes, nous avons collecté ces données et le sillage envoyé sur les paquets LAN, pour alimenter les machines. :-)
Quelles que soient les solutions que vous construisez, si votre réseau est occupé, pensez à implémenter une sorte de qos, afin que vos paquets de surveillance soient prioritaires sur le réseau, la perte de paquets de mesure en raison de l'encombrement du réseau peut donner de fausses alarmes. Si vous utilisez des qos pour surveiller les paquets, vous devrez penser à collecter des données sur l'utilisation du réseau.
Ainsi, vous pouvez rendre votre solution de surveillance aussi complexe ou aussi simple que vous le souhaitez. Nous trouvons que même le système de surveillance le plus élémentaire est un pas dans la bonne direction, au moins certains administrateurs gardent un œil sur les machines :-).
bonne chance!
@ jordon-bedwell a une excellente suggestion.
@ laszlo-valko https://stackoverflow.com/questions/20359487/why-does-ping-not-timeout-in-linux explique que les délais d'expiration du ping ne démarrent qu'après que l'adresse IP a été déterminée. Si vous utilisez un DNS et que votre poste de travail est hors ligne, le ping ne peut pas déterminer l'adresse IP et semble donc attendre environ 20 secondes par défaut avant de retourner false.
L'utilisation de l'outil 'timeout' de linux offre plus de contrôle lors de l'exécution de ping avec un nom de domaine.
Merci les gars
Utilisez le commutateur - w, à la fois sur Windows et Debian.
C'est un moyen rapide de vérifier si la machine répond du tout, en supposant qu'elle répondra en un temps inférieur au nombre de secondes spécifié.
ping -w 1 192.168.80.105
PING 192.168.80.105 (192.168.80.105) 56(84) bytes of data.
--- 192.168.80.105 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms
Si vous pouvez analyser votre sous-réseau (ou une partie de celui-ci) sans déclencher d'alarmes de sécurité, et ne vous occupez pas d'un peu de données supplémentaires, Angry IP Scanner est rapide, gratuit, vous permet de cliquer pour trier par état et peut fournir des informations plus détaillées.
Pourquoi ne pas lancer le ping en arrière-plan, avec une sortie dans un fichier temporaire, en parallèle pour chaque hôte? Ensuite, dormez une seconde, supprimez tous les processus ping en cours d'exécution et lisez les fichiers pour collecter la sortie.
Le délai d'attente est une valeur entière indiquant la distance et la durée d'envoi du paquet. Les valeurs inférieures à 1 n'ont pas de sens. Une valeur de 1 indique que vous envoyez une requête ping aux voisins immédiats uniquement.
La seule façon d'accélérer les choses est d'exécuter une vérification des antécédents et de récolter les résultats. C'est ce que font des outils comme Nagios.
Vous pouvez essayer quelque chose comme ça. Mais cela prend 15 minutes pour fonctionner.
a=258
while [ $a -ge 1 ]
do
echo "10.0.0.$a"
Sudo ping -i 0.1 -c 1 "10.0.0.$a">>/home/$USER/output.log
a=`expr $a - 1`
done
cat /home/$USER/output.log|grep -i "icmp_req=1"
cat /dev/null>/home/$USER/output.log
essaye ça:
ping -n 5 1.2.3.4.5 >nul