J'ai donc deux machines sur un m=EAme r=E9seau mais sur deux
sous-r=E9seaux diff=E9rents.
Quand A fait un ping vers B je ne capture aucune trame de broadcast sur
A alors que c'est le cas si A ping yahoo.fr
Donc A voit B
Or dans la table arp de A, B n'existe pas. Donc si j'ai bien compris, A
"devrait" appliquer son masque sur l'adresse de B (soit 255.255.255.0
sur 82.67.64.88), voir que B n'est pas sur le m=EAme sous-r=E9seau
(82.67.66 !=3D 82.67.64) et faire un broadcast sur sa passerelle par
d=E9faut (comme elle le fait parfaitement pour yahoo.fr).
Or, de fait, A ne le fait pas.
Donc quelque chose cloche:
1=B0/ soit je consid=E8re que c'est normal que A voit B puisque qu'elles
sont sur le m=EAme r=E9seau p=E8re, =E0 savoir 82.67. Mais alors =E0 quoi
servent les masques de sous-r=E9seaux ?
Et d'autre part, on ne fait pas des sous-r=E9seaux pour rien et entre
deux sous-r=E9seaux, il faut une passerelle. Or les requettes arp ne les
passent pas. Comment fait-donc A pour joindre B sans faire de broadcast
?
2=B0/ Soit je consid=E8re que A ne peut pas voir B puisqu'elles sont sur
des sous-r=E9seaux diff=E9rents et auquel cas c'est anormal que A ne
fasse pas un broadcast sur sa passerelle ?
Si quelqu'un peut me donner des =E9l=E9ments de r=E9ponse ?
Quand A fait un ping vers B je ne capture aucune trame de broadcast sur A alors que c'est le cas si A ping yahoo.fr
Pas compris ce que tu voulais dire là.
[...]
Or, de fait, A ne le fait pas.
Tu as pensé à sortir la passerelle du cache ARP après avoir pingé Yahoo ? Parce que sinon, tu n'auras pas de requête pour la passerelle, puisqu'elle est déjà dans le cache.
1°/ soit je considère que c'est normal que A voit B puisque qu'elles sont sur le même réseau père, à savoir 82.67. Mais alors à quoi servent les masques de sous-réseaux ?
Si A "voyait" B, alors B serait dans le cache ARP, or ce n'est pas le cas.
Comment fait-donc A pour joindre B sans faire de broadcast ?
C'est quoi ces histoire de broadcast ? Ethernet, IP ? Avec quoi dedans ? Et puis est-ce que A joins vraiment B ? Le ping, il passe ou pas ?
2°/ Soit je considère que A ne peut pas voir B puisqu'elles sont sur des sous-réseaux différents et auquel cas c'est anormal que A ne fasse pas un broadcast sur sa passerelle ?
Modulo cet étrange broadcast, il n'y aura pas de requête ARP si la passerelle est dans le cache a A.
Amha, il faudrait revoir un peu le protocole de test.
-- Tout ça, c'est de la faute de Microsoft. Démolissons Microsoft. Oussama ? -+- AL in GFA : "À l'aide !!!" -+-
Le Mon, 18 Apr 2005 06:02:56 -0700, Pascal a écrit :
Quand A fait un ping vers B je ne capture aucune trame de broadcast sur
A alors que c'est le cas si A ping yahoo.fr
Pas compris ce que tu voulais dire là.
[...]
Or, de fait, A ne le fait pas.
Tu as pensé à sortir la passerelle du cache ARP après avoir pingé
Yahoo ? Parce que sinon, tu n'auras pas de requête pour la passerelle,
puisqu'elle est déjà dans le cache.
1°/ soit je considère que c'est normal que A voit B puisque qu'elles
sont sur le même réseau père, à savoir 82.67. Mais alors à quoi
servent les masques de sous-réseaux ?
Si A "voyait" B, alors B serait dans le cache ARP, or ce n'est pas le cas.
Comment fait-donc A pour joindre B sans faire de broadcast ?
C'est quoi ces histoire de broadcast ? Ethernet, IP ? Avec quoi dedans ?
Et puis est-ce que A joins vraiment B ? Le ping, il passe ou pas ?
2°/ Soit je considère que A ne peut pas voir B puisqu'elles sont sur
des sous-réseaux différents et auquel cas c'est anormal que A ne fasse
pas un broadcast sur sa passerelle ?
Modulo cet étrange broadcast, il n'y aura pas de requête ARP si la
passerelle est dans le cache a A.
Amha, il faudrait revoir un peu le protocole de test.
--
Tout ça, c'est de la faute de Microsoft.
Démolissons Microsoft.
Oussama ?
-+- AL in GFA : "À l'aide !!!" -+-
Quand A fait un ping vers B je ne capture aucune trame de broadcast sur A alors que c'est le cas si A ping yahoo.fr
Pas compris ce que tu voulais dire là.
[...]
Or, de fait, A ne le fait pas.
Tu as pensé à sortir la passerelle du cache ARP après avoir pingé Yahoo ? Parce que sinon, tu n'auras pas de requête pour la passerelle, puisqu'elle est déjà dans le cache.
1°/ soit je considère que c'est normal que A voit B puisque qu'elles sont sur le même réseau père, à savoir 82.67. Mais alors à quoi servent les masques de sous-réseaux ?
Si A "voyait" B, alors B serait dans le cache ARP, or ce n'est pas le cas.
Comment fait-donc A pour joindre B sans faire de broadcast ?
C'est quoi ces histoire de broadcast ? Ethernet, IP ? Avec quoi dedans ? Et puis est-ce que A joins vraiment B ? Le ping, il passe ou pas ?
2°/ Soit je considère que A ne peut pas voir B puisqu'elles sont sur des sous-réseaux différents et auquel cas c'est anormal que A ne fasse pas un broadcast sur sa passerelle ?
Modulo cet étrange broadcast, il n'y aura pas de requête ARP si la passerelle est dans le cache a A.
Amha, il faudrait revoir un peu le protocole de test.
-- Tout ça, c'est de la faute de Microsoft. Démolissons Microsoft. Oussama ? -+- AL in GFA : "À l'aide !!!" -+-
Jacques Caron
Salut,
On 18 Apr 2005 06:02:56 -0700, Pascal wrote:
Je découvre le fonctionnement de ARP et après avoir lu beaucoup de docs je me suis livré au test suivant:
J'ai donc deux machines sur un même réseau mais sur deux sous-réseaux différents.
Plus précisément, deux machines sur un même réseau niveau 2 mais sur deux réseaux de niveau 3 différents.
Quand A fait un ping vers B je ne capture aucune trame de broadcast sur A alors que c'est le cas si A ping yahoo.fr
Il faudrait faire le test avec le cache ARP vide dans les deux cas. En effet, dans un cas comme dans l'autre, A pour joindre B va devoir passer par le routeur (niveau 3) adapté (passerelle par défaut, en général), et donc va devoir faire une résolution ARP sur cette adresse (et non pas sur l'adresse de B, dont il *sait* qu'il n'est pas dans le même réseau). Mais une fois que cette résolution est faite, elle est conservée en cache, donc il est normal qu'il n'y en ait pas le deuxième coup.
Donc A voit B
Non.
Or dans la table arp de A, B n'existe pas. Donc si j'ai bien compris, A "devrait" appliquer son masque sur l'adresse de B (soit 255.255.255.0 sur 82.67.64.88), voir que B n'est pas sur le même sous-réseau (82.67.66 != 82.67.64) et faire un broadcast sur sa passerelle par défaut (comme elle le fait parfaitement pour yahoo.fr).
Exactement, sauf si la résolution ARP de l'adresse de la passerelle a déjà eu lieu, et qu'elle n'a pas besoin d'être faite à nouveau.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On 18 Apr 2005 06:02:56 -0700, Pascal <pascal@linuxorable.net> wrote:
Je découvre le fonctionnement de ARP et après avoir lu beaucoup de
docs je me suis livré au test suivant:
J'ai donc deux machines sur un même réseau mais sur deux
sous-réseaux différents.
Plus précisément, deux machines sur un même réseau niveau 2 mais sur deux
réseaux de niveau 3 différents.
Quand A fait un ping vers B je ne capture aucune trame de broadcast sur
A alors que c'est le cas si A ping yahoo.fr
Il faudrait faire le test avec le cache ARP vide dans les deux cas. En
effet, dans un cas comme dans l'autre, A pour joindre B va devoir passer
par le routeur (niveau 3) adapté (passerelle par défaut, en général), et
donc va devoir faire une résolution ARP sur cette adresse (et non pas sur
l'adresse de B, dont il *sait* qu'il n'est pas dans le même réseau). Mais
une fois que cette résolution est faite, elle est conservée en cache, donc
il est normal qu'il n'y en ait pas le deuxième coup.
Donc A voit B
Non.
Or dans la table arp de A, B n'existe pas. Donc si j'ai bien compris, A
"devrait" appliquer son masque sur l'adresse de B (soit 255.255.255.0
sur 82.67.64.88), voir que B n'est pas sur le même sous-réseau
(82.67.66 != 82.67.64) et faire un broadcast sur sa passerelle par
défaut (comme elle le fait parfaitement pour yahoo.fr).
Exactement, sauf si la résolution ARP de l'adresse de la passerelle a déjà
eu lieu, et qu'elle n'a pas besoin d'être faite à nouveau.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
J'ai donc deux machines sur un même réseau mais sur deux sous-réseaux différents.
Plus précisément, deux machines sur un même réseau niveau 2 mais sur deux réseaux de niveau 3 différents.
Quand A fait un ping vers B je ne capture aucune trame de broadcast sur A alors que c'est le cas si A ping yahoo.fr
Il faudrait faire le test avec le cache ARP vide dans les deux cas. En effet, dans un cas comme dans l'autre, A pour joindre B va devoir passer par le routeur (niveau 3) adapté (passerelle par défaut, en général), et donc va devoir faire une résolution ARP sur cette adresse (et non pas sur l'adresse de B, dont il *sait* qu'il n'est pas dans le même réseau). Mais une fois que cette résolution est faite, elle est conservée en cache, donc il est normal qu'il n'y en ait pas le deuxième coup.
Donc A voit B
Non.
Or dans la table arp de A, B n'existe pas. Donc si j'ai bien compris, A "devrait" appliquer son masque sur l'adresse de B (soit 255.255.255.0 sur 82.67.64.88), voir que B n'est pas sur le même sous-réseau (82.67.66 != 82.67.64) et faire un broadcast sur sa passerelle par défaut (comme elle le fait parfaitement pour yahoo.fr).
Exactement, sauf si la résolution ARP de l'adresse de la passerelle a déjà eu lieu, et qu'elle n'a pas besoin d'être faite à nouveau.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Pascal
Merci Jacques,
Ton hypothèse m'a traversé l'esprit mais j'ai un souci. Je suis sous Linux/Debian et je n'arrive pas à effacer le cache arp
J'ai un fichier /proc/net/arp que je n'arrive pas non plus à effacer.
J'ai essayé echo "" > /proc/net/arp mais sans résultat
Je suppose que de rebooter ne servira à rien.
Pascal
Merci Jacques,
Ton hypothèse m'a traversé l'esprit mais j'ai un souci.
Je suis sous Linux/Debian et je n'arrive pas à effacer le cache arp
J'ai un fichier /proc/net/arp que je n'arrive pas non plus à effacer.
J'ai essayé echo "" > /proc/net/arp mais sans résultat
Le Mon, 18 Apr 2005 11:24:14 -0700, Pascal a écrit :
Ton hypothèse m'a traversé l'esprit mais j'ai un souci. Je suis sous Linux/Debian et je n'arrive pas à effacer le cache arp
Je vais être lourd :)))
man arp : [...]
-d hostname, --delete hostname Remove any entry for the specified host. This can be used if the indicated host is brought down, for example.
Donc :
~# arp -d <IP|hostname>
Par contre, pas de flush complet avec la commande arp, faut virer les entrées une par une.
Sinon, y'a aussi la commande "ip" qui marche bien pour contrôler le cache ARP, avec le switch "neigh" :
~# ip neigh del <IP|hostname> dev <iface>
Et là, tu peux tirer la chasse, interface par interface.
~# ip neigh flush dev <iface>
-- je (moi) serait seul juge de l'acceptation ou non de telle signature dans le GPJ. -+- SD in Guide du Petit Joueur: je sangsure fassisstement -+-
Pascal
J'avais bien essayé arp -d mais j'avais des messages d'erreur. C'est rentré dans l'ordre. Je ne prenais pas les bonnes valeurs pour l'@IP
Et effectivement, c'est bien le cache qui posait problème.
Deux petites choses:
1°/ ethereal à un comportement très curieux en ce sens que les deux trames ARP s'affichent dans la boite de capture au moins 20s après la fin du ping !
2°/ c'est une petite précision: Jacques m'a répondu "Plus précisément, deux machines sur un même réseau niveau 2 mais sur deux réseaux de niveau 3". Que dois-je comprendre: le même réseau niveau 2 signifie même réseau ethernet et "deux réseaux de niveau 3" signifiant 2 réseaux logiques ?
Merci
Pascal
J'avais bien essayé arp -d mais j'avais des messages d'erreur.
C'est rentré dans l'ordre. Je ne prenais pas les bonnes valeurs pour
l'@IP
Et effectivement, c'est bien le cache qui posait problème.
Deux petites choses:
1°/ ethereal à un comportement très curieux en ce sens que les deux
trames ARP s'affichent dans la boite de capture au moins 20s après la
fin du ping !
2°/ c'est une petite précision: Jacques m'a répondu "Plus
précisément, deux machines sur un même réseau niveau 2 mais sur
deux réseaux de niveau 3".
Que dois-je comprendre: le même réseau niveau 2 signifie même
réseau ethernet et "deux réseaux de niveau 3" signifiant 2 réseaux
logiques ?
J'avais bien essayé arp -d mais j'avais des messages d'erreur. C'est rentré dans l'ordre. Je ne prenais pas les bonnes valeurs pour l'@IP
Et effectivement, c'est bien le cache qui posait problème.
Deux petites choses:
1°/ ethereal à un comportement très curieux en ce sens que les deux trames ARP s'affichent dans la boite de capture au moins 20s après la fin du ping !
2°/ c'est une petite précision: Jacques m'a répondu "Plus précisément, deux machines sur un même réseau niveau 2 mais sur deux réseaux de niveau 3". Que dois-je comprendre: le même réseau niveau 2 signifie même réseau ethernet et "deux réseaux de niveau 3" signifiant 2 réseaux logiques ?
Merci
Pascal
Jacques Caron
Salut,
On 18 Apr 2005 15:38:16 -0700, Pascal wrote:
1°/ ethereal à un comportement très curieux en ce sens que les deux trames ARP s'affichent dans la boite de capture au moins 20s après la fin du ping !
Ca sent une tentative pas très fructueuse de résolution inverse des adresses IP. En la désactivant ça devrait être instantané.
2°/ c'est une petite précision: Jacques m'a répondu "Plus précisément, deux machines sur un même réseau niveau 2 mais sur deux réseaux de niveau 3". Que dois-je comprendre: le même réseau niveau 2 signifie même réseau ethernet et "deux réseaux de niveau 3" signifiant 2 réseaux logiques ?
Niveau 2 = Ethernet (et autres choses genre Token Ring, PPP, ATM, FR, HDLC, et j'en passe) Niveau 3 = IP (et autres choses genre IPX, AppleTalk, etc.).
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On 18 Apr 2005 15:38:16 -0700, Pascal <pascal@linuxorable.net> wrote:
1°/ ethereal à un comportement très curieux en ce sens que les deux
trames ARP s'affichent dans la boite de capture au moins 20s après la
fin du ping !
Ca sent une tentative pas très fructueuse de résolution inverse des
adresses IP. En la désactivant ça devrait être instantané.
2°/ c'est une petite précision: Jacques m'a répondu "Plus
précisément, deux machines sur un même réseau niveau 2 mais sur
deux réseaux de niveau 3".
Que dois-je comprendre: le même réseau niveau 2 signifie même
réseau ethernet et "deux réseaux de niveau 3" signifiant 2 réseaux
logiques ?
Niveau 2 = Ethernet (et autres choses genre Token Ring, PPP, ATM, FR,
HDLC, et j'en passe)
Niveau 3 = IP (et autres choses genre IPX, AppleTalk, etc.).
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
1°/ ethereal à un comportement très curieux en ce sens que les deux trames ARP s'affichent dans la boite de capture au moins 20s après la fin du ping !
Ca sent une tentative pas très fructueuse de résolution inverse des adresses IP. En la désactivant ça devrait être instantané.
2°/ c'est une petite précision: Jacques m'a répondu "Plus précisément, deux machines sur un même réseau niveau 2 mais sur deux réseaux de niveau 3". Que dois-je comprendre: le même réseau niveau 2 signifie même réseau ethernet et "deux réseaux de niveau 3" signifiant 2 réseaux logiques ?
Niveau 2 = Ethernet (et autres choses genre Token Ring, PPP, ATM, FR, HDLC, et j'en passe) Niveau 3 = IP (et autres choses genre IPX, AppleTalk, etc.).
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Pascal
Ca sent une tentative pas très fructueuse de résolution inverse des adresses IP. En la désactivant ça devrait être instantané."
C'est peut-être du au fait que la commande: ~# arp renvoie ceci pour l'@IP: Address mutualite-2-82-67-64-25 (le 4 de 254 ne s'affiche pas mais c'est juste une question de longueur de champ, que je pense)
Mais je ne sais pas d'où le cache tire cette valeur car si je fais: ~# cat /proc/net/arp j'obtiens: IP address 82.67.64.254
Pourquoi cette différence de valeur ?
Tu me dis de désactiver RARP, on le désactive comment ? Ce n'est pas un service fournit automatiquement par la pile TCP/IP du noyau Linux ? Et si je peux désactiver RARP, est-ce à dire que je peux en faire autant avec ARP ?
D'autre part, étant raccordé à une Freebox, je suis en DHCP. A part /etc/network/interfaces que je dois renseigner pour dire au système de récupérer l'@IP par DHCP et les valeurs de DNS je n'ai rien configuré d'autre.
Comment mon système obtient-il alors l'@IP de la passerelle par défaut ?
Merci encore pour toutes vos explications. Quand on met le nez dans les réseaux on à très vite fait d'être un peu dépassé.
Pascal
Ca sent une tentative pas très fructueuse de résolution inverse des
adresses IP. En la désactivant ça devrait être instantané."
C'est peut-être du au fait que la commande:
~# arp
renvoie ceci pour l'@IP:
Address
mutualite-2-82-67-64-25 (le 4 de 254 ne s'affiche pas mais c'est juste
une question de longueur de champ, que je pense)
Mais je ne sais pas d'où le cache tire cette valeur car si je fais:
~# cat /proc/net/arp
j'obtiens:
IP address
82.67.64.254
Pourquoi cette différence de valeur ?
Tu me dis de désactiver RARP, on le désactive comment ?
Ce n'est pas un service fournit automatiquement par la pile TCP/IP du
noyau Linux ?
Et si je peux désactiver RARP, est-ce à dire que je peux en faire
autant avec ARP ?
D'autre part, étant raccordé à une Freebox, je suis en DHCP.
A part /etc/network/interfaces que je dois renseigner pour dire au
système de récupérer l'@IP par DHCP et les valeurs de DNS je n'ai
rien configuré d'autre.
Comment mon système obtient-il alors l'@IP de la passerelle par
défaut ?
Merci encore pour toutes vos explications.
Quand on met le nez dans les réseaux on à très vite fait d'être un
peu dépassé.
Ca sent une tentative pas très fructueuse de résolution inverse des adresses IP. En la désactivant ça devrait être instantané."
C'est peut-être du au fait que la commande: ~# arp renvoie ceci pour l'@IP: Address mutualite-2-82-67-64-25 (le 4 de 254 ne s'affiche pas mais c'est juste une question de longueur de champ, que je pense)
Mais je ne sais pas d'où le cache tire cette valeur car si je fais: ~# cat /proc/net/arp j'obtiens: IP address 82.67.64.254
Pourquoi cette différence de valeur ?
Tu me dis de désactiver RARP, on le désactive comment ? Ce n'est pas un service fournit automatiquement par la pile TCP/IP du noyau Linux ? Et si je peux désactiver RARP, est-ce à dire que je peux en faire autant avec ARP ?
D'autre part, étant raccordé à une Freebox, je suis en DHCP. A part /etc/network/interfaces que je dois renseigner pour dire au système de récupérer l'@IP par DHCP et les valeurs de DNS je n'ai rien configuré d'autre.
Comment mon système obtient-il alors l'@IP de la passerelle par défaut ?
Merci encore pour toutes vos explications. Quand on met le nez dans les réseaux on à très vite fait d'être un peu dépassé.
Pascal
Eric Lalitte
"Pascal" wrote in message news:
Ca sent une tentative pas très fructueuse de résolution inverse des adresses IP. En la désactivant ça devrait être instantané."
Tout à fait d'accord avec Jacques. Dans Ethereal, dans la partie capture, tu as une case "name resolution" Il suffit de ne pas demander la résolution de nom pour le faire, et ça devrait rouler.
C'est peut-être du au fait que la commande: ~# arp renvoie ceci pour l'@IP: Address mutualite-2-82-67-64-25 (le 4 de 254 ne s'affiche pas mais c'est juste une question de longueur de champ, que je pense)
Essaye plutôt arp -an
Mais je ne sais pas d'où le cache tire cette valeur car si je fais: ~# cat /proc/net/arp j'obtiens: IP address 82.67.64.254 Pourquoi cette différence de valeur ?
Parcequ'il y a une résolution inverse d'adresse qui est faite par la commande arp. Avec l'option -n, tu évites de la faire.
Et si je peux désactiver RARP, est-ce à dire que je peux en faire autant avec ARP ?
Tu peux désactiver arp, (ifconfig ethx -arp) mais ton réseau marchera beaucoup moins bien !! (comprendre pas du tout)
Comment mon système obtient-il alors l'@IP de la passerelle par défaut ?
Par DHCP.
Merci encore pour toutes vos explications. Quand on met le nez dans les réseaux on à très vite fait d'être un peu dépassé.
Mais c'est passionnant ! (je m'emballe là :-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Pascal" <pascal@linuxorable.net> wrote in message
news:1113896705.322841.293550@g14g2000cwa.googlegroups.com
Ca sent une tentative pas très fructueuse de résolution inverse des
adresses IP. En la désactivant ça devrait être instantané."
Tout à fait d'accord avec Jacques.
Dans Ethereal, dans la partie capture, tu as une case "name resolution"
Il suffit de ne pas demander la résolution de nom pour le faire, et ça
devrait rouler.
C'est peut-être du au fait que la commande:
~# arp
renvoie ceci pour l'@IP:
Address
mutualite-2-82-67-64-25 (le 4 de 254 ne s'affiche pas mais c'est juste
une question de longueur de champ, que je pense)
Essaye plutôt arp -an
Mais je ne sais pas d'où le cache tire cette valeur car si je fais:
~# cat /proc/net/arp
j'obtiens:
IP address
82.67.64.254
Pourquoi cette différence de valeur ?
Parcequ'il y a une résolution inverse d'adresse qui est faite par la
commande arp. Avec l'option -n, tu évites de la faire.
Et si je peux désactiver RARP, est-ce à dire que je peux en faire
autant avec ARP ?
Tu peux désactiver arp, (ifconfig ethx -arp) mais ton réseau marchera
beaucoup moins bien !! (comprendre pas du tout)
Comment mon système obtient-il alors l'@IP de la passerelle par
défaut ?
Par DHCP.
Merci encore pour toutes vos explications.
Quand on met le nez dans les réseaux on à très vite fait d'être un
peu dépassé.
Mais c'est passionnant ! (je m'emballe là :-)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Ca sent une tentative pas très fructueuse de résolution inverse des adresses IP. En la désactivant ça devrait être instantané."
Tout à fait d'accord avec Jacques. Dans Ethereal, dans la partie capture, tu as une case "name resolution" Il suffit de ne pas demander la résolution de nom pour le faire, et ça devrait rouler.
C'est peut-être du au fait que la commande: ~# arp renvoie ceci pour l'@IP: Address mutualite-2-82-67-64-25 (le 4 de 254 ne s'affiche pas mais c'est juste une question de longueur de champ, que je pense)
Essaye plutôt arp -an
Mais je ne sais pas d'où le cache tire cette valeur car si je fais: ~# cat /proc/net/arp j'obtiens: IP address 82.67.64.254 Pourquoi cette différence de valeur ?
Parcequ'il y a une résolution inverse d'adresse qui est faite par la commande arp. Avec l'option -n, tu évites de la faire.
Et si je peux désactiver RARP, est-ce à dire que je peux en faire autant avec ARP ?
Tu peux désactiver arp, (ifconfig ethx -arp) mais ton réseau marchera beaucoup moins bien !! (comprendre pas du tout)
Comment mon système obtient-il alors l'@IP de la passerelle par défaut ?
Par DHCP.
Merci encore pour toutes vos explications. Quand on met le nez dans les réseaux on à très vite fait d'être un peu dépassé.
Mais c'est passionnant ! (je m'emballe là :-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Pascal
Non, tu as raison: c'est passionnant et très instructif.
Ethereal est vraiment bizarre.
Il ne veut rien capturer si "Enable MAC name résolution" n'est pas activé. Pour l'instant c'est pas bien grave.
Pascal
Non, tu as raison: c'est passionnant et très instructif.
Ethereal est vraiment bizarre.
Il ne veut rien capturer si "Enable MAC name résolution" n'est pas
activé.
Pour l'instant c'est pas bien grave.
Non, tu as raison: c'est passionnant et très instructif.
Ethereal est vraiment bizarre.
Il ne veut rien capturer si "Enable MAC name résolution" n'est pas activé. Pour l'instant c'est pas bien grave.
Pascal
Jacques Caron
Salut,
On 19 Apr 2005 00:45:05 -0700, Pascal wrote:
C'est peut-être du au fait que la commande: ~# arp renvoie ceci pour l'@IP: Address mutualite-2-82-67-64-25 (le 4 de 254 ne s'affiche pas mais c'est juste une question de longueur de champ, que je pense)
Mais je ne sais pas d'où le cache tire cette valeur car si je fais: ~# cat /proc/net/arp j'obtiens: IP address 82.67.64.254
Pourquoi cette différence de valeur ?
La commande "arp" fait elle aussi une résolution inverse par défaut. Un bon petit "-n" devrait l'en dissuader.
Tu me dis de désactiver RARP, on le désactive comment ?
Non, je dis de désactiver une résolution DNS inverse (adresse IP -> nom, i.e. a.b.c.d -> PTR d.c.b.a.in-addr-arpa. -> nom). C'est souvent l'option -n (c'est le cas dans arp, ping, traceroute, netstat, tcpdump...). C'est aussi le cas de ethereal.
Comment mon système obtient-il alors l'@IP de la passerelle par défaut ?
C'est le serveur DHCP qui lui fournit.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On 19 Apr 2005 00:45:05 -0700, Pascal <pascal@linuxorable.net> wrote:
C'est peut-être du au fait que la commande:
~# arp
renvoie ceci pour l'@IP:
Address
mutualite-2-82-67-64-25 (le 4 de 254 ne s'affiche pas mais c'est juste
une question de longueur de champ, que je pense)
Mais je ne sais pas d'où le cache tire cette valeur car si je fais:
~# cat /proc/net/arp
j'obtiens:
IP address
82.67.64.254
Pourquoi cette différence de valeur ?
La commande "arp" fait elle aussi une résolution inverse par défaut. Un
bon petit "-n" devrait l'en dissuader.
Tu me dis de désactiver RARP, on le désactive comment ?
Non, je dis de désactiver une résolution DNS inverse (adresse IP -> nom,
i.e. a.b.c.d -> PTR d.c.b.a.in-addr-arpa. -> nom). C'est souvent l'option
-n (c'est le cas dans arp, ping, traceroute, netstat, tcpdump...). C'est
aussi le cas de ethereal.
Comment mon système obtient-il alors l'@IP de la passerelle par
défaut ?
C'est le serveur DHCP qui lui fournit.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
C'est peut-être du au fait que la commande: ~# arp renvoie ceci pour l'@IP: Address mutualite-2-82-67-64-25 (le 4 de 254 ne s'affiche pas mais c'est juste une question de longueur de champ, que je pense)
Mais je ne sais pas d'où le cache tire cette valeur car si je fais: ~# cat /proc/net/arp j'obtiens: IP address 82.67.64.254
Pourquoi cette différence de valeur ?
La commande "arp" fait elle aussi une résolution inverse par défaut. Un bon petit "-n" devrait l'en dissuader.
Tu me dis de désactiver RARP, on le désactive comment ?
Non, je dis de désactiver une résolution DNS inverse (adresse IP -> nom, i.e. a.b.c.d -> PTR d.c.b.a.in-addr-arpa. -> nom). C'est souvent l'option -n (c'est le cas dans arp, ping, traceroute, netstat, tcpdump...). C'est aussi le cas de ethereal.
Comment mon système obtient-il alors l'@IP de la passerelle par défaut ?
C'est le serveur DHCP qui lui fournit.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
