nombre d'erreurs

Le
bpdu92
bonsoir à tous
y a t'il un freeware qui affiche le nombre de répetitions de trames IP
?
sinon inclus dans Ethereal, Winlan ou autre ?
ce serait pour voir l'effet de la modification de la MTU
merci d'avance
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
Mateusz Viste
Le #18614611
On Sunday 08 February 2009 03:19, bpdu92 wrote:
y a t'il un freeware qui affiche le nombre de répetitions de trames IP
?



Jamais entendu parler de "trames IP", moi... :-P

sinon inclus dans Ethereal, Winlan ou autre ?
ce serait pour voir l'effet de la modification de la MTU
merci d'avance



Suffit de regarder la capture avec un utilitaire de type Wireshark...

Cordialement,
Mateusz VISTE
bpdu92
Le #18615321
On Sun, 08 Feb 2009 09:58:03 +0100, Mateusz Viste

On Sunday 08 February 2009 03:19, bpdu92 wrote:
y a t'il un freeware qui affiche le nombre de répetitions de trames IP
?



Jamais entendu parler de "trames IP", moi... :-P


ben si tu demandes 'trame IP' à Google, ya que 172.000 réponses ?
tu preferres quoi ? bloc ? datagramme ? paquet ? autre ?

sinon inclus dans Ethereal, Winlan ou autre ?
ce serait pour voir l'effet de la modification de la MTU
merci d'avance



Suffit de regarder la capture avec un utilitaire de type Wireshark...


-merci pour l'info, je savais pas que Ethereal avait changé de nom

-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9,
il semble que c'est pas possible, la couche pcap ne fournit pas
les paquets avec CRC errors à Ethereal, ceci en reception,
et en emission, je vois pas où il indique les retries ?

Cordialement,


au plaisir de te lire

Mateusz VISTE


suisse ?
Pascal Hambourg
Le #18616321
Salut,

bpdu92 a écrit :

On Sunday 08 February 2009 03:19, bpdu92 wrote:
y a t'il un freeware qui affiche le nombre de répetitions de trames IP
?







Qu'entends-tu exactement par "répétitions" ?

-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9,
il semble que c'est pas possible, la couche pcap ne fournit pas
les paquets avec CRC errors à Ethereal, ceci en reception,
et en emission, je vois pas où il indique les retries ?



De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?
bpdu92
Le #18617061
On Sun, 08 Feb 2009 13:00:16 +0100, Pascal Hambourg
salut Pascal

Salut,

bpdu92 a écrit :

On Sunday 08 February 2009 03:19, bpdu92 wrote:
y a t'il un freeware qui affiche le nombre de répetitions de trames IP
?







Qu'entends-tu exactement par "répétitions" ?


dans le cas où je suis l'emetteur,
je répète un certain nb de fois si je n'ai pas l'accusé de reception
de mon correspondant

-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9,
il semble que c'est pas possible, la couche pcap ne fournit pas
les paquets avec CRC errors à Ethereal, ceci en reception,
et en emission, je vois pas où il indique les retries ?



De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?


tous ceux qui obligent mon correspondant à réemettre

c'est l'ensemble des 2 cas d'erreurs pour lequels je cherche un
freeware, qui m'aiderait de façon quantitative à regler le mtu

TCP Optimizer me botte : il détaille pas les erreurs,
il essaie tout seul différentes longueurs,
et donne sa préférence

cordialt
Pascal Hambourg
Le #18619821
bpdu92 a écrit :

dans le cas où je suis l'emetteur,
je répète un certain nb de fois si je n'ai pas l'accusé de reception
de mon correspondant



Si tu es l'émetteur, tu dois bien savoir combien de fois tu répètes ?

-d'aprés la Faq http://www.wireshark.org/faq.html, Q 7.9,
il semble que c'est pas possible, la couche pcap ne fournit pas
les paquets avec CRC errors à Ethereal, ceci en reception,







Faut dire qu'en émission il y a peu de chance d'y avoir des erreurs, et
en réception je ne garantirais pas que le pilote de l'adaptateur
ethernet voire l'adaptateur lui-même livre les trames avec une erreur de
FCS à la couche supérieure. En revanche je ne vois pas pourquoi pcap ne
fournirait pas les paquets reçus avec une erreur de checksum de couche
supérieure (IP, TCP, UDP, ICMP...).

et en emission, je vois pas où il indique les retries ?



De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?



tous ceux qui obligent mon correspondant à réemettre



Attention, il n'y a pas d'accusé de réception ni de mécanisme de
retransmission systématique en ethernet, IP ou UDP, ni de signalement
d'une erreur de checksum à l'émetteur. En UDP, c'est à la couche
applicative de retransmettre si elle l'estime nécessaire. Seuls TCP et
autres protocoles du même type ont un mécanisme de retransmission. Mais
l'erreur de checksum n'est pas la seule cause de retransmission, il y a
bien d'autres raisons qui peuvent faire qu'un paquet n'arrive pas à
destination, notamment la congestion.

c'est l'ensemble des 2 cas d'erreurs pour lequels je cherche un
freeware, qui m'aiderait de façon quantitative à regler le mtu

TCP Optimizer me botte : il détaille pas les erreurs,
il essaie tout seul différentes longueurs,
et donne sa préférence



S'il mesure le débit en TCP pour chaque valeur et si tu cherches à
optimiser le débit en TCP en tenant compte du taux d'erreurs de
transmission, alors ça me semble être une bonne approche pleine de
pragmatisme.

Par curiosité, quelle est donc cette liaison dont le taux d'erreur de
transmission est tel qu'il nécessiterait une réduction du MTU ?
Stephane Bortzmeyer
Le #18621021
bpdu92 wrote:

je répète un certain nb de fois si je n'ai pas l'accusé de reception
de mon correspondant



Mais cela n'a rien à voir avec des erreurs de transmission. La plupart
du temps, c'est la congestion qui fait que le routeur laisse tomber des
paquets.

De quel CRC parles-tu ? FCS ethernet ? Checksum d'en-tête IP, TCP, UDP ?


tous ceux qui obligent mon correspondant à réemettre



Cf. ci-dessus. Sur les réseaux modernes, à part peut-être les liens
radios, les erreurs de transmission sont rares (c'est une des raisons
pour lesquelles la somme de contrôle IP qui existait en IPv4 a disparu
en IPv6).

c'est l'ensemble des 2 cas d'erreurs pour lequels je cherche un
freeware, qui m'aiderait de façon quantitative à regler le mtu



Mais quel rapport entre MTU et nombre d'erreurs de transmission ? Ou
alors c'est sur des liens catastrophiques (liens radios à grande
distance), où le teux d'erreurs est tel qu'il vaut parfois mieux réduire
la MTU.

TCP Optimizer me botte : il détaille pas les erreurs,
il essaie tout seul différentes longueurs,
et donne sa préférence



Cf. RFC 4821 méthode de ce genre.
Michelot
Le #18621271
Bonjour Stéphane,

Cf. ci-dessus. Sur les réseaux modernes, à part peut-être les liens
radios, les erreurs de transmission sont rares (c'est une des raisons
pour lesquelles la somme de contrôle IP qui existait en IPv4 a disparu
en IPv6).



Lorsque les signaux parcourent les fibres optiques des réseaux de
transport, un résiduel de taux d'erreur bit de 10^-10 à 10^-9 existe,
sans parler des coupures de liaisons, des glissements de trames, des
bascules de synchronisation, des répétitions de trames... Le résiduel
est normalement corrigé par les codages de Reed-Solomon, mais pas
toujours.

Cordialement,
Michelot
bpdu92
Le #18621911
On Sun, 08 Feb 2009 19:53:30 +0100, Pascal Hambourg


Par curiosité, quelle est donc cette liaison dont le taux d'erreur de
transmission est tel qu'il nécessiterait une réduction du MTU ?


c'est une liaison Orange dans Paris 16eme un peu bizarre :
même aprés reduction (par la HotLine Orange) du débit
de 18 à 8 Mbps,il était impossible d'aller sur certains sites,
par ex Boursorama et Yahoo,
alors que d'autres, par ex les pages Google étaient accédés sans pb

aprés réduction de MTU à 1400, au lieu de 1500, tout est redevenu ok,
sauf DSLtest qui continue à dire que la ligne n'existe pas ??

pour pas mourir idiot, mon post cherche donc à connaitre
les taux d'erreurs selon la taille du mtu,
mais peut-être est-ce simplement la 1ere grosse trame, à 1500 octets
sui n'arrive pas à passer ?
Google passe car il n'emet pas de grosses trames ?
merci
bpdu92
Le #18621921
On Sun, 08 Feb 2009 22:14:58 +0100, Stephane Bortzmeyer


Mais quel rapport entre MTU et nombre d'erreurs de transmission ? Ou
alors c'est sur des liens catastrophiques (liens radios à grande
distance), où le teux d'erreurs est tel qu'il vaut parfois mieux réduire
la MTU.


voir post précédent en réponse à Pascal, je n'ai pas de preuve qu'il
s'agit d'erreurs de transmission, de trames droppées à cause de
congestion, ou autre cas d'erreur, simplement ça ne passait pas sur
certains sites avant de reduire le mtu

TCP Optimizer me botte : il détaille pas les erreurs,
il essaie tout seul différentes longueurs,
et donne sa préférence



Cf. RFC 4821 méthode de ce genre.


ya une implémentation pour Windows ?
ce RFC (d'accord, je devrais le lire) distingue t'il les clients et
les box ?
merci
Pascal Hambourg
Le #18630421
bpdu92 a écrit :
On Sun, 08 Feb 2009 19:53:30 +0100, Pascal Hambourg wrote:

Par curiosité, quelle est donc cette liaison dont le taux d'erreur de
transmission est tel qu'il nécessiterait une réduction du MTU ?



c'est une liaison Orange dans Paris 16eme un peu bizarre :



Une liaison ADSL ? PPPoE ou PPPoA ?

même aprés reduction (par la HotLine Orange) du débit
de 18 à 8 Mbps,il était impossible d'aller sur certains sites,
par ex Boursorama et Yahoo,
alors que d'autres, par ex les pages Google étaient accédés sans pb

aprés réduction de MTU à 1400, au lieu de 1500, tout est redevenu ok,



Problème de MTU a priori, surtout si c'est du tout ou rien. Je ne vois
pas ce qui te fais penser à des erreurs de transmission en ligne,
surtout si la diminution drastique du débit de synchronisation n'a
apporté aucune amélioration.

sauf DSLtest qui continue à dire que la ligne n'existe pas ??



C'est quoi, DSLtest ?

pour pas mourir idiot, mon post cherche donc à connaitre
les taux d'erreurs selon la taille du mtu,



Le taux d'erreur par bit est le même quelle que soit la taille du
paquet. Le taux d'erreur par paquet est proportionnel à la taille du
paquet. En fait c'est un peu plus compliqué que ça, car c'est le taux
d'erreur brut avant correction qui est proportionnel à la taille ; le
taux d'erreur non corrigeables dépend aussi de l'entrelacement
(interleave) qui permet de répartir une salve d'erreurs (causée par un
gros paraiste impulsionnel par exemple) sur plusieurs paquets afin de
mieux les corriger.

mais peut-être est-ce simplement la 1ere grosse trame, à 1500 octets
sui n'arrive pas à passer ?



Ça peut arriver, notamment en PPPoE qui limite à 1492. Il y a quelques
problèmes connus de "trou noir de MTU" avec cette encapsulation.

Google passe car il n'emet pas de grosses trames ?



Ce n'est pas difficile à vérifier : capture réseau des communications
HTTP avec l'un ou l'autre serveur, regarder les valeurs de MSS échangées
à l'établissement de la connexion et les tailles maxi des paquets reçus.
Publicité
Poster une réponse
Anonyme