Que fait ping -n différemment?

Sep 03 2020

Lors du dépannage d'un «blocage» occasionnel du réseau sur mon réseau Internet domestique, je suis tombé sur cette astuce technique de Dell . Ils suggèrent d'utiliser ping -npour éviter un blocage causé par la résolution DNS. Cela m'a fait réfléchir, que fait -nréellement le commutateur? Il me semble que la résolution DNS est requise si vous cinglez un nom DNS, mais pas si vous cinglez une adresse IP.

Depuis la page de manuel:
-n Sortie numérique uniquement. Aucune tentative ne sera faite pour rechercher des noms symboliques pour les adresses d'hôte.

Si je cingle une adresse IP, ping 8.8.8.8comment y a-t-il une recherche DNS ici? Fait ping -n 8.8.8.8quelque chose de différent?

Réponses

2 KamilMaciorowski Sep 03 2020 at 06:23

Si je cingle une adresse IP, ping 8.8.8.8comment y a-t-il une recherche DNS ici? Fait ping -n 8.8.8.8quelque chose de différent?

Cela peut dépendre de la mise en œuvre. Si pingsans -ninclut dns.googledans sa sortie, ce ping -nn'est probablement pas le cas, c'est la différence. Mais il est possible qu'aucune sortie n'inclue la chaîne.

Dans mon Ubuntu 18.04.4 LTS man 8 pinglit:

pingfait partie du iputilspackage et les dernières versions sont disponibles sous forme source sur http://www.skbuff.net/iputils/iputils-current.tar.bz2.

Cette adresse exacte semble ne pas fonctionner, toujours http://www.skbuff.net/iputilsfournit d'autres liens, dont celui vers SourceForge . J'ai téléchargé iputils-s20151218 et lu le code.

-nest traité dans ping_common.c:

case 'n':
        options |= F_NUMERIC;
        break;

Ensuite, l'option ( options & F_NUMERIC) est importante dans ping.c:

pr_addr(__u32 addr)
{
        …

        if (exiting || (options & F_NUMERIC) ||
            !(hp = gethostbyaddr((char *)&addr, 4, AF_INET)))
                sprintf(buf, "%s", inet_ntoa(*(struct in_addr *)&addr));
        else {
                …

Pour y arriver gethostbyaddr, les deux exitinget options & F_NUMERICdoivent être faux (car a || bdoes n'évaluera pas bsi aest vrai). Cette dernière dépend de si elle -na été utilisée ou non.

gethostbyaddrest la "tentative de recherche de noms symboliques pour les adresses d'hôte". Voir man 3 gethostbyaddr. Il s'agit du même appel de bibliothèque que celui getent hostsutilisé lorsque vous fournissez une adresse IP (voir man 1 getent).

Regarde la différence:

$ getent hosts 8.8.8.8 8.8.8.8 dns.google $ ping -c 1 dns.google
…
64 bytes from dns.google (8.8.8.8): icmp_seq=1 ttl=120 time=10.6 ms
…
$ ping -n -c 1 dns.google … 64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=11.3 ms … $

Cela peut sembler pingsans -nutiliser simplement la chaîne fournie par l'utilisateur; mais non:

$ getent hosts poczta.wp.pl 193.17.41.99 poczta.wp.pl $ getent hosts 193.17.41.99
193.17.41.99    poczta.o2.pl
$ ping -c 1 poczta.wp.pl … 64 bytes from poczta.o2.pl (193.17.41.99): icmp_seq=1 ttl=60 time=9.71 ms … $

Ici a poczta.wp.plété résolu 193.17.41.99et ensuite 193.17.41.99résolu à poczta.o2.pl(noter o2au lieu de wp). L'utilisation de -nsupprimerait la dernière étape.

Pour certaines adresses, cela se produit:

$ getent hosts superuser.com 151.101.1.69 superuser.com 151.101.193.69 superuser.com 151.101.65.69 superuser.com 151.101.129.69 superuser.com $ getent hosts 151.101.1.69 151.101.193.69 151.101.65.69 151.101.129.69        
$ # the output was empty $ ping -c 1 superuser.com
…
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=1 ttl=58 time=37.1 ms
…
$ ping -n -c 1 superuser.com … 64 bytes from 151.101.1.69: icmp_seq=1 ttl=58 time=36.8 ms … $

Mais si je fournis une adresse numérique, il n'y aura aucune différence:

$ getent hosts 8.8.8.8 8.8.8.8 dns.google $ ping -c 1 8.8.8.8
…
64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=10.8 ms
…
$ ping -n -c 1 8.8.8.8 … 64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=8.91 ms … $

C'est à cause de ce fragment de ping.c:

if (inet_aton(target, &whereto.sin_addr) == 1) {
        hostname = target;
         if (argc == 1)
                 options |= F_NUMERIC;
} else

inet_atonconvertit la notation des nombres et points IPv4 en forme binaire. Il revient 1sur le succès. Si le dernier argument donné à pingpeut être converti, le fragment est évalué options |= F_NUMERIC comme s'il -navait été utilisé .

J'ai en fait compilé à pingpartir de la source en deux versions: l'original et avec if … options |= F_NUMERIC;commenté. La version modifiée se comporte comme ceci:

$ ./ping -c 1 8.8.8.8 … 64 bytes from dns.google (8.8.8.8): icmp_seq=1 ttl=120 time=9.67 ms … $ ./ping -n -c 1 8.8.8.8
…
64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=8.69 ms
…
$

Maintenant, je peux répondre explicitement à la question:

Fait ping -n 8.8.8.8quelque chose de différent [de ping 8.8.8.8]?

Non. L'adresse dans la notation des nombres et points IPv4 fait ping(à partir iputilsde Linux) fonctionner comme si elle -nétait utilisée.

Si je cingle une adresse IP, ping 8.8.8.8comment y a-t-il une recherche DNS ici?

J'ai créé un espace de noms réseau séparé (pour m'assurer que le moins de trafic possible interfère) avec une paire veth, puis utilisé wiresharklà-bas. (Si vous souhaitez reproduire mes résultats et avez besoin d'aide pour la procédure, voir cette réponse , exemple 2).