Différences

Ci-dessous, les différences entre deux révisions de la page.

--- 045-icmpv4:010-ping [le 04/10/2025 à 15:53] – supprimée - modification externe (Date inconnue) 127.0.0.1
+++ 045-icmpv4:010-ping [le 04/10/2025 à 15:53] (Version actuelle) – ↷ Page déplacée de 055-icmpv4:010-ping à 045-icmpv4:010-ping prof
@@ Ligne 1: / Ligne 1: @@
+====== Ping (pong) ======
+Probablement le plus utilisé, ICMP dispose de deux types de message:
+  * **8** Demande d'écho (ping request);
+  * **0** Envoi de l'écho (ping reply).
+Largement utilisé pour savoir si la cible est présente et accessoirement, pour connaître le temps mis pour la joindre.
+La commande ''ping'' est utilisable aussi bien en IPv4 qu'en IPv6.
+Bien entendu, l'application (''ping'') qui utilise directement ce message ''8'' va lancer le ping et attendre «un certain temps» avant de décider qu'il n'y a pas de réponse. La commande ''ping'' de GNU/Linux propose quelques paramètres fondamentalement utiles:
+  * **-c //nombre//** indique le nombre de ping request à envoyer. Si ce paramètre n'est pas fourni, la commande envoie des ping request jusqu'à extinction du processus (Ctrl+C)
+  * **-n** Pour éviter que le système cherche à faire du RDNS (recherche d'un nom à partir d'une adresse) Non seulement cette résolution inverse n'aboutit pas systématiquement, mais encore lorsqu'elle aboutit, rien ne dit que la réponse est vraie. L'étude détaillée de DNS expliquera pourquoi.
+  * **-4** pour forcer l'emploi d'IPv4 sur une machine disposant de la double configuration;
+  * **-6** même chose, mais pour IPv6.
+Il y en a encore beaucoup d'autres, moins souvent utilisées. Voir le «man ping» pour les afficher toutes.
+les types ICMP utilisée par ''ping'' sont exploitables aussi bien en IPv4 qu'en IPv6.
+===== Démonstrations =====
+<html><pre class="code">
+<b>ping -c4 www.debian.org</b>
+PING <span class="hly">www.debian.org(static-mirror-grnet-01.debian.org (2001:648:2ffc:deb:216:61ff:fe2b:6138))</span> 56 data bytes
+bytes from static-mirror-grnet-01.debian.org (2001:648:2ffc:deb:216:61ff:fe2b:6138): icmp_seq=1 ttl=42 time=65.6 ms
+bytes from static-mirror-grnet-01.debian.org (2001:648:2ffc:deb:216:61ff:fe2b:6138): icmp_seq=2 ttl=42 time=65.1 ms
+bytes from static-mirror-grnet-01.debian.org (2001:648:2ffc:deb:216:61ff:fe2b:6138): icmp_seq=3 ttl=42 time=65.6 ms
+bytes from static-mirror-grnet-01.Debian.org (2001:648:2ffc:deb:216:61ff:fe2b:6138): icmp_seq=4 ttl=42 time=65.4 ms
+--- www.debian.org ping statistics ---
+packets transmitted, 4 received, 0% packet loss, time 3004ms
+rtt min/avg/max/mdev = 65.106/65.421/65.638/0.203 ms
+</pre></html>
+D'où l'utilité de certains paramètres. La résolution RDNS a été appliquée à des adresses IPv6. Et ce RDNS a donné un autre URI que ''www.debian.org''. La réponse, encore expliquée avec l'étude détaillée de DNS est que  ''www.debian.org'' n'est pas un nom de nœud mais un «pseudo» qui peut pointer vers différents nœuds, mais qui ont la particularité d'être des copies parfaites.
+Reprenons la manip. autrement:
+<html><pre class="code">
+<b>ping <span class="hly">-c2 -n -4</span> www.debian.org</b>
+PING  (130.89.148.77) 56(84) bytes of data.
+bytes from 130.89.148.77: icmp_seq=1 ttl=54 time=33.0 ms
+bytes from 130.89.148.77: icmp_seq=2 ttl=54 time=29.7 ms
+---  ping statistics ---
+packets transmitted, 2 received, 0% packet loss, time 1001ms
+rtt min/avg/max/mdev = 29.683/31.323/32.964/1.640 ms
+</pre></html>
+Ici **-c 2** pour n'envoyer que 2 requêtes, **-n** pour éviter le RDNS et **-4** pour forcer IPv4. L'expérience permet de déduire que dans le cas d'une double configuration IPv4 et IPv6, c'est IPv6 qui est utilisé par défaut, IPv4 ne venant qu'en cas d'échec IPv6 ou si le protocole a été explicitement demandé.
+===== Analyse =====
+La curiosité n'est pas toujours un défaut. Wireshark était là par hasard, et il a capturé ceci:
+<code>
+No.Time    Source         Destination     Protocol Length Info
+0.00    192.168.60.47  130.89.148.77   ICMP     98     Echo (ping) request  id=0x5037, seq=1/256, ttl=64 (reply in 2)
+0.03    130.89.148.77  192.168.60.47   ICMP     98     Echo (ping) reply    id=0x5037, seq=1/256, ttl=54 (request in 1)
+1.00    192.168.60.47  130.89.148.77   ICMP     98     Echo (ping) request  id=0x5037, seq=2/512, ttl=64 (reply in 4)
+1.03    130.89.148.77  192.168.60.47   ICMP     98     Echo (ping) reply    id=0x5037, seq=2/512, ttl=54 (request in 3)
+</code>
+Regardons le détail de la couche ICMP de la première trame:
+<html><pre class="code">
+Internet Control Message Protocol
+    <span class="bhly">Type: 8</span> (Echo (ping) request)
+    <span class="hly">Code: 0</span>
+    Checksum: 0x5bd2
+    Identifier (BE): 20535 (0x5037)
+    Identifier (LE): 14160 (0x3750)
+    Sequence Number (BE): 1 (0x0001)
+    Sequence Number (LE): 256 (0x0100)
+<span class="hlg">    Timestamp from icmp data: Mar  6, 2025 17:43:01.000000000 CET
+    Data (48 bytes)
+  21 ea 0c 00 00 00 00 00 10 11 12 13 14 15 16 17   !...............
+  18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27   ........ !"#$%&'
+  28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37   ()*+,-./01234567</span>
+</pre></html>
+Nous retrouvons le type **8** avec un code **0** qui n'a pas d'importance particulière, le type 8 ne dispose pas d'autre code. Il y a 48 octets de données...
+Voyons la réponse:
+<html><pre class="code">
+Internet Control Message Protocol
+    <span class="bhly">Type: 0</span> (Echo (ping) reply)
+    <span class="hly">Code: 0</span>
+    Checksum: 0x63d2
+    Identifier (BE): 20535 (0x5037)
+    Identifier (LE): 14160 (0x3750)
+    Sequence Number (BE): 1 (0x0001)
+    Sequence Number (LE): 256 (0x0100)
+<span class="hlg">    Timestamp from icmp data: Mar  6, 2025 17:43:01.000000000 CET
+    Data (48 bytes)
+  21 ea 0c 00 00 00 00 00 10 11 12 13 14 15 16 17   !...............
+  18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27   ........ !"#$%&'
+  28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37   ()*+,-./01234567</span>
+</pre></html>
+Type **0** comme prévu, là encore, le code = 0 mais n'a pas de signification particulière. Le «timestamp» et les «data» sont les mêmes que dans le ping request. les 48 octets de data + les 8 octets de timestamp = 56, ce que l'on retrouve dans le «man ping»  à la description du paramètre **-s**:
+//**-s taille_paquet :** Spécifier le nombre d'octets de données à envoyer. Le nombre par défaut est 56, ce qui se traduit en 64 octets de données ICMP quand ils sont combinés avec les 8 octets de données de l'en-tête ICMP.//
+Ces 56 octets **doivent** être identiques dans la requête et sa réponse, mais nous pouvons aussi en déduire que la taille de la charge peut être modifiée et donc éventuellement devenir explosive...
+<note tip>Il est possible de définir jusqu'à 16 octets à insérer dans les données transportées par le ping request avec l'option **-p** (comme «pattern»)</note>Mais cette option ne servira pas dans la plupart des cas.