On Fri, Jan 05, 2001 at 12:42:03PM +0100, Marc SCHAEFER wrote:
>
> Je ne connais pas Ethereal, mais par contre j'utilise tcpdump depuis assez
> longtemps (cf TCP/IP Illustrated volume 1 pour de plus amples détails).
Voici donc ce que me retourne tcpdump après un simple
# ping www.alphanet.ch
[tcpdump result]
18:49:22.792274 0.61.43.54 > 0.0.64.17: ip-proto-0 -24 [ttl 0]
18:49:23.841677 0.61.43.54 > 0.0.64.17: ip-proto-0 -24 [ttl 0]
18:49:24.711761 0.61.43.54 > 0.0.64.17: ip-proto-0 -24 [ttl 0]
18:49:24.721031 0.61.43.54 > 0.0.64.17: ip-proto-0 -24 [ttl 0]
18:49:24.821871 0.61.43.54 > 0.0.64.17: ip-proto-0 -24 [ttl 0]
18:49:24.862245 0.61.43.54 > 0.0.64.17: ip-proto-0 -24 [ttl 0]
18:49:24.899883 0.61.43.54 > 0.0.64.17: ip-proto-0 -24 [ttl 0]
18:49:24.903633 0.61.43.54 > 0.0.64.17: ip-proto-0 -24 [ttl 0]
18:49:24.948133 0.61.43.54 > 0.0.64.17: ip-proto-0 -24 [ttl 0]
18:49:24.951379 0.61.43.54 > 0.0.64.17: ip-proto-0 -24 [ttl 0]
18:49:24.989618 0.61.43.54 > 0.0.64.17: ip-proto-0 -24 [ttl 0]
18:49:25.026810 0.61.43.54 > 0.0.64.17: ip-proto-33 -24 [ttl 0]
18:49:27.811948 ip_hl < 5 (0)
18:49:27.889925 194.158.230.53.domain > 194.230.133.2.1055: 2102 1/3/3 (184)
18:49:27.893803 0.84.43.56 > 0.0.64.1: (frag 4352:34@46608)
18:49:28.000553 194.148.1.27 > 194.230.133.2: icmp: echo reply
18:49:28.891816 0.84.43.57 > 0.0.64.1: (frag 4352:34@46608)
18:49:28.989891 194.148.1.27 > 194.230.133.2: icmp: echo reply
18:49:29.951771 ip_hl < 5 (0)
18:49:30.059983 194.148.1.27 > 194.230.133.2: icmp: echo reply
18:49:30.951780 ip_hl < 5 (0)
18:49:31.048448 194.148.1.27 > 194.230.133.2: icmp: echo reply
18:49:31.951778 truncated-ip - 6563 bytes missing!0.84.43.60 > 0.0.64.1: (frag
2:6629@20480) [ttl 0]
18:49:32.059420 194.148.1.27 > 194.230.133.2: icmp: echo reply
18:49:32.951777 truncated-ip - 6563 bytes missing!0.84.43.61 > 0.0.64.1: (frag
2:6629@20480) [ttl 0]
18:49:33.051756 194.148.1.27 > 194.230.133.2: icmp: echo reply
18:49:33.951785 truncated-ip - 6563 bytes missing!0.84.43.62 > 0.0.64.1: (frag
2:6629@20480) [ttl 0]
18:49:34.053602 194.148.1.27 > 194.230.133.2: icmp: echo reply
18:49:34.951790 truncated-ip - 6563 bytes missing!0.84.43.63 > 0.0.64.1: (frag
2:6629@20480) [ttl 0]
Tu peux donc voir que le "comportement" de tcpdump est très bizarre...
Les messages que j'envoye sont "étranges" (en fait tcpdump ne sait
pas les interpréter) mais je recois des réponses cohérentes... Les
adresses IP utilisées pour les paquets émis en fait des valeurs
d'autres champs, vu l'en-tete de 10 octets avant le paquet IP.
J'ai vu dans la FAQ de isdn4linux qu'effectivement tcpdump gère mal
l'encapsulation... Il existe donc un patch pour tcpdump... mais pas
pour Ethereal...
> Oui, TCP/IP supporte les fragments (tu envoies un datagramme UDP de 8192
Ouais, je savais déjà cela, mais le problème est que tcpdump l'identifie
tel quel, mais le paquet n'est pas fragmenté... Il y a un décalage
entre les bits analysés par tcpdump et les bits du véritable paquet IP.
> > En fait, il y a un en-tête de 10 octets avant les paquets IP... Ce qui sème la
> Peut-être la frame Ethernet (encore que sauf erreur c'est 12 bytes).
Pas sur une ligne ISDN (syncPPP) :)
> > ISDN ELSA Microlink PCI et une interface ippp0... J'ai pensé que le kernel
> aha, alors du framing HDLC ?
Kesako ??? C'est utilisé pour syncPPP ?
Et si c'était du HDLC:
* Pourquoi le kernel renverrait un protocole de couche 2 (data link) à tcpdump ?
(Y aurait-il double encapsulation ???)
* Pourquoi j'enverrais du IP encapsulé dans de l'HDLC et le "modem" ISDN en-face
ne m'enverrai que de l'IP ?
C'est vraiment très bizarre.
Yann
--
Yann GAUTERON, Ch. des Saules 6, 2013 Colombier (Suisse)
Site personnel: http://www.gauteron.ch
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.
