Taille d'une trame Ethernet dans Wireshark/Ethereal ... étrange
17 réponses
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.
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
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
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 ?
...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
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
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 ?
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
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
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
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
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
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.
(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
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.
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.
(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
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.
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.
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.
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.
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 ...
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.
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.
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
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
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 ?
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 ?
