Taille d'une trame Ethernet dans Wireshark/Ethereal ... étrange

Le
none
Bonjour,

je viens d'effectuer une capture de trame avec Wireshark sur mon réseau
local Ethernet. Et là surprise : certaines trames ont une taille
supérieure à 4000 octets alors que je pensais que la taille maximum pour
les données d'une trame Ethernet (MTU) était de 1500 octets

Ou est le problème ?

Merci d'avance pour vos eclairages et bonne journée.
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Michelot
Le #803205
Bonjour,

Pouvez-vous l'afficher complètement ?

Etes-vous en domestique ou en entreprise ?

Sur quelle inteerface : 10, 100 Mbit/s, 1 Gbit/s ?

Cordialement,
Michelot
none
Le #803204
Bonjour,

Pouvez-vous l'afficher complètement ?

Etes-vous en domestique ou en entreprise ?

Sur quelle inteerface : 10, 100 Mbit/s, 1 Gbit/s ?

Cordialement,
Michelot


C'est un réseau domestique (PC <-> Freebox), j'ai un petit script Python
qui envoi 9999 octets sur le port 80 sur un serveur web sur internet.

Les trames trop grandes ont une taille de 2962 octets exactement, en
tout cas largement supérieur au MTU théorique d'Ethernet (1500 octets)

Mon interface réseau doit être en 10Mbits/s voire 100, je ne suis pas
très sur ...

La capture a été effectuée dans un premier temps avec Wireshark et
ensuite avec tcpdump pour comparer (=> mêmes résultats)

Voici un résumé de la trame :

Frame 6 (2962 bytes on wire, 2962 bytes captured)
Arrival Time: Jan 31, 2008 15:08:21.869672000
[Time delta from previous captured frame: 0.006671000 seconds]
[Time delta from previous displayed frame: 0.006671000 seconds]
[Time since reference or first frame: 0.064122000 seconds]
Frame Number: 6
Frame Length: 2962 bytes
Capture Length: 2962 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:http:data]
[Coloring Rule Name: HTTP]
[Coloring Rule String: http || tcp.port == 80]

Ethernet II, Src: xxx (xx:xx:xx:xx:xx:xx), Dst: yyy (yy:yy:yy:yy:yy:yy)
Type: IP (0x0800)

Internet Protocol, Src: ee.ff.gg.hh (ee.ff.gg.hh), Dst: aa.bb.cc.dd
(aa.bb.cc.dd)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 2948
Identification: 0xaff2 (45042)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: TCP (0x06)
Header checksum: 0xab3f [correct]
[Good: True]
[Bad : False]
Source: ee.ff.gg.hh (ee.ff.gg.hh)
Destination: aa.bb.cc.dd (aa.bb.cc.dd)
Transmission Control Protocol, Src Port: 57735 (57735), Dst Port: http
(80), Seq: 1, Ack: 1, Len: 2896
Source port: 57735 (57735)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
[Next sequence number: 2897 (relative sequence number)]
Acknowledgement number: 1 (relative ack number)
Header length: 32 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 5888 (scaled)
Checksum: 0x29ab [correct]
[Good Checksum: True]
[Bad Checksum: False]
Options: (12 bytes)
NOP
NOP
Timestamps: TSval 4876810, TSecr 18156749
Hypertext Transfer Protocol
Data (2896 bytes)

Michelot
Le #802990
Re-bonjour,

Merci pour les indications.

...je pensais que la taille maximum pour
les données d'une trame Ethernet (MTU) était de 1500 octets ...


S'il fallait préciser cela, je dirai plutôt : l'IEEE 802.3 de juin
2005 spécifie une taille maximum de trame MAC non étiquetée, hors
préambule et SFD, de 1518 octets, soit 1500 octets de charge utile.

La valeur de MTU pour la couche IP peut être cadrée sur cette valeur
de 1500 ou être plus importante.

La longueur max. de charge utile d'une trame 802.11 est spécifiée à
2312 octets (je viens de vérifier sur une version 1999). Si la charge
utile de 802.11 repasse sur 802.3, on devrait s'apercevoir que la
taille de 1518 octets est largement dépassée.

Il y a probablement d'autres cas. La longueur réelle dépend de
l'opérateur et, sur l'accès, la liberté devrait être plus importante
qu'à l'intérieur d'un réseau d'entreprise.

Ces longueurs supérieures à 1500 apparaissent-elles toujours dans le
sens descendant ?

Cordialement,
Michelot

Michelot
Le #802989
C'est donc pour la liaison montante !

C'est un réseau domestique (PC <-> Freebox), j'ai un petit script Python
qui envoi 9999 octets sur le port 80 sur un serveur web sur internet.


Savez-vous lire le MTU dans la base de registre ? sinon, qq pourrait
indiquer la manière.

Le serveur web de l'internet reçoit-il correctement vos 2962 octets ?

Cordialement,
Michelot

none
Le #802988
C'est donc pour la liaison montante !

C'est un réseau domestique (PC <-> Freebox), j'ai un petit script Python
qui envoi 9999 octets sur le port 80 sur un serveur web sur internet.


Savez-vous lire le MTU dans la base de registre ? sinon, qq pourrait
indiquer la manière.

Le serveur web de l'internet reçoit-il correctement vos 2962 octets ?

Cordialement,
Michelot


Alors effectivement les trames de 2962 octets sont dans le sens montant
(vers internet)
Dans le sen descendant (ex: téléchargement FTP), j'ai bien des trames de
1514 octets maximum

Mon MTU est de 1500 (obtenu avec la commande ifconfig)

Par contre je ne sais pas si le serveur recoit bien les octets

La valeur de MTU pour la couche IP peut être cadrée sur cette valeur
de 1500 ou être plus importante.


Comment est-ce possible avec le principe d'encapsulation :
-> Ethernet > IP > TCP > Donnees

Merci encore pour votre aide


Michelot
Le #802987
Bon ! on efface tout et on recommence.

Autre piste :

(1) Votre script injecte directement des bonnes données dans la couche
Ethernet, mais sans passer par la pile TCP/IP de votre PC configurée
avec MTU 1500 octets. Donc ça sort de votre PC, Ethernet n'a pas de
raison de bloquer l'envoi. Votre analyseur constate cet envoi.

(2) Il est possible que la Freebox accepte aussi cette longueur au
niveau Ethernet. Elle décapsule IP et renvoie sur l'accès WAN en
fragmentant pour ne pas dépasser les 1500. Auquel cas, on se retrouve
en situation normale.

A mon avis,

- si le serveur reçoit correctement les données, cela veut dire que la
Freebox accepte cette taille de trame Ethernet en entrée.

- si le serveur ne reçoit pas correctement les données, la partie
switch de la Freebox refuse de traiter les trames Ethernet jumbo.

Cordialement,
Michelot
none
Le #802986
Bon ! on efface tout et on recommence.

Autre piste :

(1) Votre script injecte directement des bonnes données dans la couche
Ethernet, mais sans passer par la pile TCP/IP de votre PC configurée
avec MTU 1500 octets. Donc ça sort de votre PC, Ethernet n'a pas de
raison de bloquer l'envoi. Votre analyseur constate cet envoi.

(2) Il est possible que la Freebox accepte aussi cette longueur au
niveau Ethernet. Elle décapsule IP et renvoie sur l'accès WAN en
fragmentant pour ne pas dépasser les 1500. Auquel cas, on se retrouve
en situation normale.

A mon avis,

- si le serveur reçoit correctement les données, cela veut dire que la
Freebox accepte cette taille de trame Ethernet en entrée.

- si le serveur ne reçoit pas correctement les données, la partie
switch de la Freebox refuse de traiter les trames Ethernet jumbo.

Cordialement,
Michelot


Merci pour tout, je vais explorer ces pistes (script et freebox).
Bonne soirée.

Michelot
Le #802985
Bonsoir,

Merci pour tout, je vais explorer ces pistes (script et freebox).
Bonne soirée


Un dernier point.

Dans le datagramme IP, votre bit de fragmentation est à 1. Donc la
Freebox ne peut pas fragmenter et, probablement, elle ne transmet pas
le datagramme sur l'accès en raison de son MTU.

D'ici qq temps, après mastication, donnez-nous votre verdict.
Bonne soirée,
Michelot

none
Le #802984
Bonsoir,

Merci pour tout, je vais explorer ces pistes (script et freebox).
Bonne soirée


Un dernier point.

Dans le datagramme IP, votre bit de fragmentation est à 1. Donc la
Freebox ne peut pas fragmenter et, probablement, elle ne transmet pas
le datagramme sur l'accès en raison de son MTU.

D'ici qq temps, après mastication, donnez-nous votre verdict.
Bonne soirée,
Michelot



Nouveau test du même script sur le réseau de mon entreprise, et là j'ai
bien une taille totale de trame correcte, ça doit donc venir de la
freebox ...


Michelot
Le #802983
Bonjour,

Nouveau test du même script sur le réseau de mon entreprise, et là j 'ai
bien une taille totale de trame correcte, ça doit donc venir de la
freebox ...


Bigre ! La capture est-elle en sortie du PC sur la liaison PC-Freebox,
ou en sortie de la Freebox sur la liaison Freebox-Web ?

Cordialement,
Michelot

Publicité
Poster une réponse
Anonyme