Ping et ARP [Résolu]

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

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), http://www.rfc-editor.org/rfc/rfc4436.txt

bonsoir,
as tu une capture wireshark?

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

Salut,
Quelle est la topologie ?
Y-at-il Routeur, Switch, les deux ? Pc directement connectés entre eux ?

Les PCs sont connectés entre eux via un simple switch/hub.

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.

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.

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

Je suis sur le réseau en 192.168.1.32 /27

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 ...

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 ?

En effet. une requete ARP faite sur une adresse précise n'a pas réellement de sens.

Ca semble logique vu comem ça ;-) ... C'était donc bien une perturbation ^^