Paquets sur ippp0
Salut, C'est encore moi... Une nouvelle question, assez interressante... J'ai eu quelques problèmes pour me connecter à un serveur sur le net et j'ai voulu examiner ce qui passait sur la ligne pour voir les messages échangés entre le client et le serveur à l'aide de Ethereal... J'ai été véritablement très surpris lorsque je voyais des paquets assez "bizarres"... Ethereal les identifiait comme du "Fragmented IP protocol". En fait, il y a un en-tête de 10 octets avant les paquets IP... Ce qui sème la zizanie dans Ethereal (qui ne peut pas l'identifier et interpréter les résultats). Le plus surprenant est que seul les messages sortant ont ce problème... Les messages entrant sont du véritable IP... J'ai constaté ce défaut avec le kernel 2.2.18pre21 de Debian, le kernel 2.2.18 compilé moi-même et le kernel 2.2.14 de la SuSE 6.4 !!! J'utilise une carte ISDN ELSA Microlink PCI et une interface ippp0... J'ai pensé que le kernel rajoutait le protocole PPP, mais ca n'explique pas pourquoi je ne vois pas le protocole PPP dans les paquets qui entrent... et surtout pas non plus pourquoi les analyseurs voient PPP alors que tcpdump ne devrait pas avoir de problème à le gérer, ainsi que Ethereal... Sur le kernel 2.2.14, j'ai testé les paquets émis sur eth0, et ces derniers sont corrects... donc seuls les messages sur ippp0 ont ce problème... (pas testé ppp0) Je n'ai pas testé les paquets émis sur eth0 sur le kernel 2.2.18, mais je suppose qu'ils sont bons aussi. Quelqu'un peut-il me dire ce qu'est cet en-tête ? Est-il possible de le supprimer ? Existe-t-il des softs d'analyse qui l'interprète correctement ? (tcpdump foire aussi avec cet en-tête (truncated-ip dit-il) ). Merci bcp 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.
Re: Paquets sur ippp0
On Fri, 5 Jan 2001 [EMAIL PROTECTED] wrote: > J'ai eu quelques problèmes pour me connecter à un serveur sur le net et j'ai > voulu examiner ce qui passait sur la ligne pour voir les messages échangés > entre le client et le serveur à l'aide de Ethereal... 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). Exemple: > J'ai été véritablement très surpris lorsque je voyais des paquets assez > "bizarres"... Ethereal les identifiait comme du "Fragmented IP protocol". Oui, TCP/IP supporte les fragments (tu envoies un datagramme UDP de 8192 bytes, comme courant en NFS, mais Ethernet ne supporte que 1500 bytes, donc le routeur juste avant va découper le paquets en DEBUT, fragments de milieu, et FIN. A l'arrivée, il y a `packet reassembly' par la couche IP (en théorie un routeur pourrait le faire, mais je crois que cela se fait, en pratique, sur la destination). Cela pose d'ailleurs des problèmes intéressants quant à la place mémoire et aux abus (DoS). Dès qu'un fragment se perd, tout doit être ré-émis. Une meilleure méthode est de mettre dans le paquet de bit DONTFRAGMENT à 1 et le premier routeur avec un problème envoie un message ICMP, ce qui permet d'ajuster, à l'émetteur, le MTU dynamiquement pour cette connexion, sans le coût des fragments. > 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). > ISDN ELSA Microlink PCI et une interface ippp0... J'ai pensé que le kernel aha, alors du framing HDLC ? Exemple de sortie tcpdump: defian:/home/schaefer# tcpdump -i eth0 -n tcpdump: listening on eth0 12:41:26.028154 193.72.186.8.1027 > 193.72.186.6.22: P 1070273025:1070273045(20) ack 4130706157 win 32120 (DF) [tos 0x10] 12:41:26.042655 193.72.186.6.22 > 193.72.186.8.1027: . ack 20 win 32736 (DF) [tos 0x10] 12:41:26.052918 193.72.186.6.22 > 193.72.186.8.1027: P 1:21(20) ack 20 win 32736 (DF) [tos 0x10] 12:41:26.072729 193.72.186.8.1027 > 193.72.186.6.22: . ack 21 win 32120 (DF) [tos 0x10] On voit que la pile IP concernée (Linux) utilise le DF bit. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question.
Re: Paquets sur ippp0
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.
Re: Paquets sur ippp0
On Fri, 05 Jan 2001, Marc SCHAEFER wrote: > Oui, TCP/IP supporte les fragments (tu envoies un datagramme UDP de 8192 > bytes, comme courant en NFS, mais Ethernet ne supporte que 1500 bytes, > donc le routeur juste avant va découper le paquets en DEBUT, fragments de > milieu, et FIN. A l'arrivée, il y a `packet reassembly' par la couche IP > (en théorie un routeur pourrait le faire, mais je crois que cela se fait, > en pratique, sur la destination). Cela pose d'ailleurs des problèmes > intéressants quant à la place mémoire et aux abus (DoS). Dès qu'un > fragment se perd, tout doit être ré-émis. Je ne sais pas si j'ai bien compris, mais il me semble que c'est TCP qui est charge du 'flow control' et donc du reassemblage des paquets. TCP 'reconstruit' le bloc de data en remettant tous les paquets bout-a-bout. Par contre, TCP ne garde pas les blocs qui representent des trous. Par exemple, si le syst A envoie les blocs 1,2,3,4,5 et que B recoive 1,2,4,5 B ne va pas garder les blocs 4 & 5, mais va redemander l'envoi des blocs a partir du numero 3. Ceci est bien decrit dans quelques bouquins dont un paru chez Adison-Wesley. Maintenant, je ne sais pas si les routeurs s'orientent vers la gestion au niveau TCP ou si on laisse "l'encapsulation" faire le travaile a l'aide du TTL ? Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question.
Re: Paquets sur ippp0
On Mon, 8 Jan 2001, Daniel Cordey wrote: > Je ne sais pas si j'ai bien compris, mais il me semble que c'est TCP qui > est charge du 'flow control' et donc du reassemblage des paquets. TCP Attention, il y a deux niveaux ici: les paquets et les fragments. Un paquet contient les données du byte X au byte Y. Maintenant, si l'on veut transmettre plus que le MTU du medium local, on peut: - envoyer des paquets à la suite de plus petite taille (TCP fait cela tout seul, UDP je ne sais pas: soit une erreur, soit fragmente, VOIR PLUS LOIN) - envoyer un gros paquet virtuel qui est composé de *fragments*. Maintenant, à quoi ça sert d'avoir des fragments, finalement, vu que TCP peut couper à la source en paquets ? Ben si tu ne peux pas deviner quel est le MIN(MTU, chemin parcouru sur Internet), il y aura forcément un jour ou l'autre fragmentation du paquet en petits morceaux (sauf si tu envoies des paquets de size 200, p.ex., il y a grande chance que cela passe partout, mais alors ta performance sera abysmale: certains réseaux veulent des tailles de paquets de 32k ou 64k, voire plus (cf window scale option)). L'autre solution que la fragmentation est le bit DF, cf autre mail. Plus efficace (car de nos jours les routeurs perdent souvent des paquets). Les paquets (sans la fragmentation, donc) sont réassemblés par TCP pour garantir l'intégrité (checksum simple) et l'ordre (numéro de séquence). Quand un paquet n'arrive pas (ie timeout: un ordre incorrect n'est pas suffisant), il y a réémission *depuis* ce paquet. Si l'on ajoute la problématique des fragments, c'est la même chose (si timeout et >= 1 fragment d'un paquet pas arrivé -> réémission du paquet). PS: j'espère que je ne dis pas trop de bêtises, car les fragments cela n'a jamais été mon fort. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question.
Re: Paquets sur ippp0
On Mon, 08 Jan 2001, Marc SCHAEFER wrote: > Maintenant, à quoi ça sert d'avoir des fragments, finalement, vu que TCP > peut couper à la source en paquets ? Ben si tu ne peux pas deviner quel > est le MIN(MTU, chemin parcouru sur Internet), il y aura forcément un jour > ou l'autre fragmentation du paquet en petits morceaux (sauf si tu envoies > des paquets de size 200, p.ex., il y a grande chance que cela passe > partout, mais alors ta performance sera abysmale: certains réseaux veulent > des tailles de paquets de 32k ou 64k, voire plus (cf window scale > option)). Merci pour tes explications. Je parlais bien des paquets et non des fragments (c'est certainement encore moins mon truc que toi...). Mais si je comprend l'utilite d'avoir de gros paquets sur les reseaux a haut debits (> 10 Mbits/s), qu'en est-il de ppp sur les lignes telephoniques classiques ? Meme des paquets de 1500 bytes me semblent trop gros pour ces vitesses... Peut-etre ok lorsque l'on est seul a faire un ftp mais pas vraiment aproprie lorsqu'il y a plusieurs process communicants sur la ligne. Certe le throughput est globalement meilleur mais le temps de reponse des petites transactions est moins bon lorsqu'il y a un mix avec d'autres gros transferts. Daniel PS: Promis, je ne pose plsu de questions a ce propos :-) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question.
Re: Paquets sur ippp0
> classiques ? Meme des paquets de 1500 bytes me semblent trop gros pour > ces vitesses... Peut-etre ok lorsque l'on est seul a faire un ftp mais > pas vraiment aproprie lorsqu'il y a plusieurs process communicants sur > la ligne. Certe le throughput est globalement meilleur mais le temps de C'est bien ça: - gros MTU: efficacité meilleure (chaque paquet IP a un poids, sauf erreur environ 28 bytes, cf sizeof(iphdr), faut encore ajouter les headers TCP, et probablement on arrive à 50 bytes. Donc si tu as un MTU de 250, tu perdras 20% sur la bande passante de ton modem (à peut près ce que tu gagnes par la conversion synchrone de 2 bits sur 10 sans le framing). - petit MTU: interactivité meilleure. On ne doit attendre que MTU bytes au maximum pour pouvoir émettre. Exemple: MTU de 1000 sur une liaison PPP à 28'800 bps (donc disons 3000 cps), en interactif (telnet) il faudra donc attendre au plus 2 * 1/3 de secondes, soit 600 ms pour avoir l'écho de ses caractères en telnet (le NAG algorithm, qui va grouper les caractères va donc provoquer un effet de saccades, mais rendre la chose relativement utilisable. Sans NAG ça va être insupportable). Bien sûr, sans trafic sur la liaison, le MTU n'a aucune importance. L'importance arrive dès que tu fais p.ex. du FTP simultanément à du telnet ou SSH. A cela s'ajoute, sans MTU discovery, le fait que plus le MTU est gros, plus il y a risque de fragmentation et donc de pertes de paquets baissant la performance. NB: on peut changer le MTU dynamiquement (ifconfig ppp0 mtu 300) suivant ce qu'on fait. > reponse des petites transactions est moins bon lorsqu'il y a un mix avec > d'autres gros transferts. > PS: Promis, je ne pose plsu de questions a ce propos :-) Les bonnes questions ne sont pas forcément celles auxquelles une réponse est facilement trouvée :) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question.
