Comment définir un court délai avec la commande ping?

J'essaie d'écrire un script qui répertorie tous les hôtes de 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, j'ai donc toutes les adresses IP (par exemple, 10.0.0.1, 10.0.0.2, etc.), tout ce dont j'ai besoin est l'état du 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, la requête ping prend du temps à expirer. J'ai vérifié man ping, il semble y avoir deux options pour définir le délai d'expiration: -w deadlineet -W timeout. Je pense que je suis intéressé par ce dernier.

Alors j'ai 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 prendre en compte le paramètre du tout:

ping -c 1 -W 0.1 10.0.0.1  # timeout option is ignored, apparently

Existe-t-il un moyen de régler le délai d’attente sur une valeur inférieure? Si non, y a-t-il des alternatives?

Modifier

• Le système d'exploitation est Debian Lenny.
• Les hôtes sur lesquels j'essaie de faire un ping sont en réalité des points d'accès. Ils sont sur le même vlan et le même sous-réseau que les utilisateurs (pour simplifier le déploiement et le remplacement). C'est pourquoi je ne veux pas analyser tout le sous-réseau (avec un ping -bexemple).

Modifier # 2

J'ai accepté la fpingsolution (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 dure au maximum 500 ms et me donne l’état du 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 peut être un meilleur outil que le ping standard que vous utilisez. Vous êtes sur quel OS?

• "fping diffère de ping en ce que vous pouvez spécifier autant de cibles que vous le souhaitez sur la ligne de commande ou spécifier un fichier contenant les listes de cibles à ping."
• "Au lieu d’envoyer à une cible jusqu’à expiration du délai imparti ou réponse, fping enverra un paquet ping et passera à la cible suivante de manière alternée."
• "A la différence de ping, fping est destiné à être utilisé dans des scripts, sa sortie est donc conçue pour être facile à analyser."

Pour les personnes recherchant une solution impliquant ping, utilisez le -icommutateur.

ping -i 0.2 www.google.com

Ou, si vous voulez 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 avec la timeoutcommande 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

Consultez la documentation de nmap pour plus de détails à ce sujet.

vous voudrez peut-être consulter l'outil ping d'arp si tous vos hôtes se trouvent sur le réseau local physique. Il fait la même chose mais utilise des paquets arp de couche 2 pour effectuer le "ping". Vous pouvez utiliser une combinaison d'arping et de ping icmp, ou en fait de ping tcp, pour déterminer la nature de l'échec. Exemple: un crash de pile TCP, bien que cela soit rare de nos jours, nous pourrions trouver si une pile TCP de machine s’était é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 combinant arpping, tcpping et icmp ping, vous pouvez savoir si le service sur la machine est tombé en panne, si la pile TCP est tombée en panne ou si la machine est complètement verrouillée. Si vous avez géré des commutateurs Ethernet, vous pouvez obtenir des données de liaison physique, en indiquant si la machine est réellement allumée ou si elle avait été physiquement débranchée. Nous avons eu une situation où les machines (clients dans les salles publiques) seraient éteintes, nous avons rassemblé ces données et les paquets de réveil envoyés, pour alimenter les machines. :-)

Quelles que soient les solutions que vous développez, si votre réseau est occupé, pensez à mettre en œuvre 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 la congestion du réseau peut donner de fausses alarmes. Si vous utilisez qos pour surveiller les paquets, vous devrez alors réfléchir à la collecte de 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 un administrateur surveille 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'attente de ping ne commencent que lorsque l'adresse IP a été déterminée. Si vous utilisez un DNS et que votre poste de travail est hors ligne, alors ping ne peut pas déterminer l'adresse IP et semble donc attendre environ 20 secondes par défaut avant de renvoyer 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 , sous Windows et Debian.

C'est un moyen rapide de vérifier si la machine répond, en supposant qu'elle répondra dans un délai 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 des alarmes de sécurité, sans vous soucier de quelques données supplémentaires, Angry IP Scanner est rapide et gratuit, vous permet de cliquer pour trier par statut et de fournir des informations plus détaillées. .

Pourquoi ne pas lancer ping en arrière-plan, avec la sortie dans un fichier temporaire, en parallèle pour chaque hôte? Mettez-vous ensuite en veille, arrêtez tous les processus ping en cours et lisez les fichiers pour collecter la sortie.

Le délai d'attente est une valeur entière indiquant la distance et la longueur du paquet pouvant être envoyé. 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'effectuer 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 courir.

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

ping a les options [-t timeout] et [-W waittime] pour que vous puissiez faire:

ping -c 1 -t 1 -W 1 google.com