Bonjour tout le monde !
En tapant la commande tcpdump -i eth0 -v -n dans une première fenetre et la commande traceroute hostname dans une seconde fenetre via mon terminal, dans la sortie de la commande tcpdump j'aimerais savoir comment reconnaitre le protocole des messages dont la transmission échoue pour indiquer l'identité des routeurs intermédiaires à la commande traceroute ?
Merci d'avance pour votre aide !
# tshark ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 4. Dernière modification le 27 juin 2016 à 16:27.
Si le but est de faire du débogage réseau en interactif ou de retraiter les infos en sortie, l'outil tshark (wireshark en CLI, disponible normalement dans le paquet wireshark ou tshark suivant les distributions) me semble plus adapté (et plus puissant pour cette tâche).
[^] # Re: tshark ?
Posté par roger91 . Évalué à -1.
Merci pour ton retour.
Non je voudrais simplement reconnaitre dans la sortie de la commande le protocole des messages dont la transmission échoue pour indiquer l'identité des routeurs intermédiaires à la commande traceroute.
La sortie de ma commande est:
:~$ sudo tcpdump -i eth0 -v -n
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:59:22.631677 IP (tos 0x28, ttl 54, id 27492, offset 0, flags [none], proto TCP (6), length 52)
216.58.211.78.443 > 192.160.16.36.33879: Flags [.], cksum 0xb746 (correct), ack 2043997011, win 358, options [nop,nop,TS val 1646372628 ecr 2851789], length 0
15:59:22.643672 IP (tos 0x28, ttl 54, id 27494, offset 0, flags [none], proto TCP (6), length 52)
216.58.211.78.443 > 192.160.16.36.33879: Flags [.], cksum 0xb701 (correct), ack 47, win 358, options [nop,nop,TS val 1646372639 ecr 2851801], length 0
15:59:23.172668 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.160.16.80 tell 192.160.16.254, length 46
15:59:23.422276 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.160.16.40 tell 192.160.16.254, length 46
15:59:24.197483 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.160.16.80 tell 192.160.16.254, length 46
15:59:24.422253 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.160.16.40 tell 192.160.16.254, length 46
15:59:24.730807 IP (tos 0x0, ttl 64, id 62813, offset 0, flags [DF], proto UDP (17), length 71)
192.160.16.36.62502 > 192.160.16.254.53: 48084+ PTR? 20.1.160.192.in-addr.arpa. (43)
15:59:24.731773 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 96)
192.160.16.254.53 > 192.160.16.36.62502: 48084* 1/0/0 20.1.160.192.in-addr.arpa. PTR yannick-001. (68)
# port / protocole
Posté par eric gerbier (site web personnel) . Évalué à 1.
La sortie de tcpdump va t'afficher les flux réseau : ip source, port source -> ip destination, port distant.
Si les applications utilisent les ports par défaut, tu prends ton numéro de port distant,
tu fais une recherche dans le fichier /etc/services, et tu sauras quel protocole est concerné.
# Question ambiguë
Posté par ecid . Évalué à 1.
J'ai deux interprétations pour votre question:
hypothèse 1
Il y a un traceroute qui tourne et vous cherchez à savoir comment reconnaître les paquets associés via tcpdump.
Quand il y a une réponse d'un routeur qui est sur le chemin, c'est du ICMP TIME_EXCEEDED.
hypothèse 2
Il y a des échecs de transmission et vous esssayez d'en connaître la cause.
C'est beaucoup trop vaste pour donner une réponse exhaustive car cela dépend de la couche
où se situe le problème de connexion.
Exemples:
Si l'adresse IP n'est pas joignable (aucune réponse à la demande [Broadcast ARP]: qui connait l'adresse IP x.y.z.t ?), la tentative de connexion échoue. Dans les traces tcpump, aucun paquet de réponse ne sera vu.
En TCP, la connection commence toujours par un SYN mais si n'y a pas de réponse (ACKnowlegement du SYN) après plusieurs tentatives, la connexion échoue. Si la connexion échoue parce qu'un routeur ou firewall intermédiaire bloque la connexion, cela ne se verra absolument pas dans les traces tcpump.
En UDP, il n'y a pas de confirmation des paquets reçcus, donc c'est au niveau de la couche application qu'on décide ce qu'il faut faire.
[^] # Re: Question ambiguë
Posté par roger91 . Évalué à 1.
D'accord merci pour la réponse, je suis un peu fixé à présent.
[^] # Re: Question ambiguë
Posté par benja . Évalué à 1.
hypothèse 3
L'auteur de la question nous fait part d'un extrait de l'énoncé de son TP. Encore une fois, cet extrait est malheureux car il manque les informations nécessaires pour désambiguïser la question. N'ayant pas non plus le contexte de son cours vu que notre ami ne nous l'expose pas et que nous n'avons de toute évidence pas assisté à son cours (probablement que lui non plus finalement vu les lacunes systématiques de ses questions), il nous demande de deviner quel est le problème qui lui est demandé d'être résolu et ensuite de lui donner des solutions.
En ce qui me concerne, tant que tu ne changeras pas ta manière de faire, je laisse tomber avec toi, roger91. Parce que :
1) il serait plus honnête de ta part de nous donner toutes les informations qui sont en ta possession afin de nous éviter un travail inutile de devinette;
2) vu la constance dans ton comportement, je m'explique plus simplement ce "flou" par le fait que tu manques d'assiduité dans tes études plus que par le fait que tout tes profs soient très mauvais : je peux imaginer qu'il soit possible qu'il y aie des ambiguïtés ou des imprécisions dans un énoncé mais à la lumière tu cours que tu as du avoir, il n'est franchement pas possible qu'il demeure à chaque fois autant d'inconnues (ou bien si tu es vraiment tombé dans une mauvaise école, je te suggèrerais alors d'en changer si tu souhaites que tes études te servent à quelque chose).
Ceci n'engage que moi bien sûr, bravo à tous les autres qui ne sont pas encore découragés ;-)
[^] # Re: Question ambiguë
Posté par NeoX . Évalué à 2.
hypothese confirmé quand on regarde les precedentes questions de l'utilisateur
http://linuxfr.org/users/roger91/posts
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.