Ping et ARP
Résolu
ACervoise
Messages postés
216
Date d'inscription
Statut
Membre
Dernière intervention
-
marspar Messages postés 91 Date d'inscription Statut Membre Dernière intervention -
marspar Messages postés 91 Date d'inscription Statut Membre Dernière intervention -
17 réponses
Bon, un +1, un résolu et un merci peut être lol
Et pour être complet dans ma réponse voici un extrait du RFC 4436 qui montre que la requête ARP en unicast peut arriver dans plusieurs situations, donc je vous donne la citation du RFC en anglais, je suis sure que vous n'avez pas besoin de traduction. En tout cas la référence complète est sur le site de l'IETF :
"The use of unicast ARP has a number of benefits. One benefit is that
unicast packets impose less burden on the network than broadcast
packets, particularly on 802.11 networks where broadcast packets may
be sent at rates as low as 1 Mb/sec. Another benefit is that if the
host is not on the link it hoped to find itself on, a broadcast ARP
Request could pollute the ARP caches of peers on that link. When
using private addresses [RFC1918], another device could be
legitimately using the same address, and a broadcast ARP Request
could disrupt its communications, causing TCP connections to be broken, and
similar problems. Also, using a unicast ARP packet
addressed to the MAC address of the router the host is expecting to
find means that if the host is not on the expected link there will be
no device with that MAC address, and the ARP packet will harmlessly
disappear into the void without doing any damage.
"
Référence : RFC 4436, Detecting Network Attachment in IPv4 (DNAv4), https://www.rfc-editor.org/rfc/rfc4436.txt
Et pour être complet dans ma réponse voici un extrait du RFC 4436 qui montre que la requête ARP en unicast peut arriver dans plusieurs situations, donc je vous donne la citation du RFC en anglais, je suis sure que vous n'avez pas besoin de traduction. En tout cas la référence complète est sur le site de l'IETF :
"The use of unicast ARP has a number of benefits. One benefit is that
unicast packets impose less burden on the network than broadcast
packets, particularly on 802.11 networks where broadcast packets may
be sent at rates as low as 1 Mb/sec. Another benefit is that if the
host is not on the link it hoped to find itself on, a broadcast ARP
Request could pollute the ARP caches of peers on that link. When
using private addresses [RFC1918], another device could be
legitimately using the same address, and a broadcast ARP Request
could disrupt its communications, causing TCP connections to be broken, and
similar problems. Also, using a unicast ARP packet
addressed to the MAC address of the router the host is expecting to
find means that if the host is not on the expected link there will be
no device with that MAC address, and the ARP packet will harmlessly
disappear into the void without doing any damage.
"
Référence : RFC 4436, Detecting Network Attachment in IPv4 (DNAv4), https://www.rfc-editor.org/rfc/rfc4436.txt
ACervoise
Messages postés
216
Date d'inscription
Statut
Membre
Dernière intervention
85
Merci beaucoup !
ACervoise
Messages postés
216
Date d'inscription
Statut
Membre
Dernière intervention
85
Tu pourrais me donner le lien d'ou tu as trouver la première référence ?
marspar
Messages postés
91
Date d'inscription
Statut
Membre
Dernière intervention
162
https://insecure.org/sploits/arp.games.html
bon, je vais te traduire la réponse, mais je commence par te la donner en anglais :
".. an ARP caching implementation feature.
Some systems (e.g. Linux) would try to update their cache entries by sending
a unicast ARP request to the cached address (like your wife calling you just
to make sure you're there)."
Certaines implémentation dans des systèmes tel que Linux essaient de mettre à jour leurs cache ARP en envoyant une requête ARP en unicast à l'adresse existante en cache, exactement comme une femme qui appèle son mari qui est à coté pour s'assurer qu'il est là
voilà, ça explique tout, c'est une question implémentation par l'OS
".. an ARP caching implementation feature.
Some systems (e.g. Linux) would try to update their cache entries by sending
a unicast ARP request to the cached address (like your wife calling you just
to make sure you're there)."
Certaines implémentation dans des systèmes tel que Linux essaient de mettre à jour leurs cache ARP en envoyant une requête ARP en unicast à l'adresse existante en cache, exactement comme une femme qui appèle son mari qui est à coté pour s'assurer qu'il est là
voilà, ça explique tout, c'est une question implémentation par l'OS
J'ai oublié de préciser, les deux machines sont brancher en réseau local. Les seules informations renseignées sont leur adresses IP et leur masques (pas de passerelles ni de DNS).
Voila la capture : http://www.monsterup.com/image.php?url=upload/1269553464235.png
Voila la capture : http://www.monsterup.com/image.php?url=upload/1269553464235.png
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Salut,
Quelle est la topologie ?
Y-at-il Routeur, Switch, les deux ? Pc directement connectés entre eux ?
Quelle est la topologie ?
Y-at-il Routeur, Switch, les deux ? Pc directement connectés entre eux ?
as tu fait le test de consulter la table ARP de la machine qui a l'adresse 192.168.1.33 pendant les lignes 4-11 de ta capture wireshark? si oui peut tu donner le résultat? je pense que la machine 192.168.1.33 n'avait pas l'adresse MAC de A durant les lignes 4 à 11, tu peux revérifier en vidant les tables ARP au début et on recomançant le ping?
Comme je l'ai dit au début j'ai déjà fait l'expérience (je n'ai plus le screen) mais la machine 192.168.1.33 à bien la correspondance IP/MAC dans sa table ARP pour la machine 192.168.1.32.
D'où mon interrogation.
D'où mon interrogation.
dans ta capture il n'y a pas l'adresse 192.168.1.32!! tu voulais dire la 1.34? je te re-conseille de refaire le test car en réseau pour comprendre ce qui se passe il faut tester et retester..
Je voulais dire .34 (.32 est l'adresse du réseau). J'ai fait le test à 4 reprises avec un hub ou un switch entre deux machines windows, deux machines linux, une windows et une linux. Le résultat est toujours le même.
D'ailleurs, si la machine 192.168.1.33 n'avait pas la machine 192.168.1.34 dans sa table ARP elle enverrait sa requête ARP sur le broadcast et non directement sur la machine en 192.168.1.34.
Qui plus est la définition du protocole ARP veut que lors d'une requête ARP d'une machine A vers une machine B, la machine B répond à la requête et inscrit dans sa table ARP la correspondance de la machine A. Puis la machine A reçoit la réponse et inscrit la correspondance.
D'ailleurs, si la machine 192.168.1.33 n'avait pas la machine 192.168.1.34 dans sa table ARP elle enverrait sa requête ARP sur le broadcast et non directement sur la machine en 192.168.1.34.
Qui plus est la définition du protocole ARP veut que lors d'une requête ARP d'une machine A vers une machine B, la machine B répond à la requête et inscrit dans sa table ARP la correspondance de la machine A. Puis la machine A reçoit la réponse et inscrit la correspondance.
Ok ACervoise, je vais voir encore, mais il y a une chose que tu dis qui m'inquiète:
tu dis que la .32 c'est l'adresse du réseau.. comment ça?!!
la .32 c'est l'adresse de quoi au juste, parce que fait attention une adresse de réseau est sous forme de plage avec masque exemple 192.168.1.0/24
tu dis que la .32 c'est l'adresse du réseau.. comment ça?!!
la .32 c'est l'adresse de quoi au juste, parce que fait attention une adresse de réseau est sous forme de plage avec masque exemple 192.168.1.0/24
192.168.1.32 / 27 ... ou même /28, /29 et /30 sont tous des subnets valables.
LA seule chose qui change c'est la plage d'adresses IP qui y entre.
Pour ce qui est de l'ARP, de mon point de vue, la requête ARP faite en fin de capture par la machine .34 n'a pas lieu d'être ... sauf ... si l'entrée qu'elle avait est arrivé en fin de vie.
Le principe général est le suivant;
A doit envoyer une trame à B mais il n'a pas sa MAC
A envoi une requête ARP via une trame broadcast
B reçoit la requête ARP, il enregistre la MAC de A dans sa propre table ARP
B envoi la réponse ARP à A
A reçoit la réponse de B, enregistre la MAC de B dans sa table ARP et envoi donc la trame prévue.
A priori il n'y a aucune raison que B fasse la moindre requête ARP. Je comprends donc bien l'interrogation de ACervoise. Maintenant il faut voir si un élément ne perturbe pas le résultat ... mais quoi ...
LA seule chose qui change c'est la plage d'adresses IP qui y entre.
Pour ce qui est de l'ARP, de mon point de vue, la requête ARP faite en fin de capture par la machine .34 n'a pas lieu d'être ... sauf ... si l'entrée qu'elle avait est arrivé en fin de vie.
Le principe général est le suivant;
A doit envoyer une trame à B mais il n'a pas sa MAC
A envoi une requête ARP via une trame broadcast
B reçoit la requête ARP, il enregistre la MAC de A dans sa propre table ARP
B envoi la réponse ARP à A
A reçoit la réponse de B, enregistre la MAC de B dans sa table ARP et envoi donc la trame prévue.
A priori il n'y a aucune raison que B fasse la moindre requête ARP. Je comprends donc bien l'interrogation de ACervoise. Maintenant il faut voir si un élément ne perturbe pas le résultat ... mais quoi ...
ah fallait nous préciser ce masque (non classique), je suis sur une piste de solution je te réponds dans quelques minutes..
J'ai réalisés les tests sur des machines différentes avec des équipements réseaux différents.
Si l'entrée était arrivée en fin de vie, alors B aurait envoyé une requête ARP sur le broadcast et non directement a A non ?
Si l'entrée était arrivée en fin de vie, alors B aurait envoyé une requête ARP sur le broadcast et non directement a A non ?