Question CPL / Ethernet et MTU
Fermé
acampeaux
Messages postés
2
Date d'inscription
samedi 26 janvier 2019
Statut
Membre
Dernière intervention
27 janvier 2019
-
26 janv. 2019 à 19:14
brupala Messages postés 109458 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 26 avril 2024 - 27 janv. 2019 à 12:18
brupala Messages postés 109458 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 26 avril 2024 - 27 janv. 2019 à 12:18
A voir également:
- Question CPL / Ethernet et MTU
- Ethernet n'a pas de configuration ip valide - Guide
- Transformer ethernet en wifi - Forum Réseaux sociaux
- Cpl connecté mais pas internet - Forum CPL
- Cpl perte de débit - Forum CPL
- Câble ethernet branché mais pas de connexion internet ✓ - Forum Réseau
2 réponses
brupala
Messages postés
109458
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
26 avril 2024
13 626
26 janv. 2019 à 19:42
26 janv. 2019 à 19:42
Salut,
très bonne analyse du problème,
mais,
il n'ya aucune raison que des modems CPL bloquent des trames d'une certaine longueur, il faut virer ces engins du réseau, absolument et trouver autre chose.
un modem se doit d'être transparent à ce niveau.
tu as iperf pour faire des tests plus précis.
sinon,
essaie avec un ssh sous linux, avec un live cd si tu ne veux pas l'installer pour voir si ça fait une différence par rapport à Putty.
si il y a une différence, il faudra s'armer de wireshark pour essayer de voir la différence.
très bonne analyse du problème,
mais,
il n'ya aucune raison que des modems CPL bloquent des trames d'une certaine longueur, il faut virer ces engins du réseau, absolument et trouver autre chose.
un modem se doit d'être transparent à ce niveau.
tu as iperf pour faire des tests plus précis.
sinon,
essaie avec un ssh sous linux, avec un live cd si tu ne veux pas l'installer pour voir si ça fait une différence par rapport à Putty.
si il y a une différence, il faudra s'armer de wireshark pour essayer de voir la différence.
brupala
Messages postés
109458
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
26 avril 2024
13 626
Modifié le 27 janv. 2019 à 12:28
Modifié le 27 janv. 2019 à 12:28
Je réfléchis toujours à ton problème, du moins ce que tu as découvert, car c'est intéressant et important, dommage d'ailleurs que ce soit caché par les vendeurs de modems CPL.
je suis en train de me demander, si en fait ça n'est pas un défaut de conception plutôt qu'une panne, un problème de taille de tampons dans les modems.
On est d'accord que ces modems ont un port ethernet gigabit et ton PC aussi.
Le Raspberry pi est en 100Mbit/s lui par contre, c'est ce qui me met la puce à l'oreille vu la dissymétrie et que tu n'aies pas besoin de changer la MTU de son côté.
Il faudrait que tu testes en mettant une MTU "normale" à 1500 côté PC mais en réduisant le débit de la carte réseau à 100 Mbit/s voir le bouton configurer sur les paramètres réseau de la carte.
La piste à étudier:
Le modem CPL a une interface ethernet gigabit négocie le gigabit entre lui et le PC.
Cependant, comme tout bon CPL, il est bien incapable ailleurs que sur le papier de transmettre à ce débit sur les fils électriques, si il arrive à 300Mbit/s c'est déjà bien.
Comme il reçoit des données à 1000Mbit/s du PC, il est bien obligé de stocker ce qu'il reçoit vu que ça repart moins vite.
Si ses tampons sont trop petits une trame trop grande ne sera pas stockée en entier et devra être détruite.
Après, il existe des mécanismes de contrôle de flux, mais toutes les cartes réseau ne les gèrent pas.
Pareil, sur les cartes gigabit, la segmentation est souvent gérée par la carte, plutôt que par l'OS ou le pilote.
Les cartes gigabit gèrent en principe les jumbo frames (trames ethernet jusqu'à 9000 octets) quand elles sont reliées à un switch gigabit, ce qui est le cas avec ton GS108.
https://www.n9ws.com/forum/viewtopic.php?t=122123
Les switchs ont en général les mémoires tampon nécessaires pour gérer ces différences de débit entreport entrée et port sortie (ça peut aller jusqu'à un rapport de 100 entre un port gigabit et un port connecté à 10).
Si les modems CPL ne sont pas capables d'intégrer la même chose, c'est très dommage.
Certains ont un switch intégré, probablement qu'ils gérent mieux ça.
Bref,
STP fait le test en forçant ton PC en 100, ou bien, encore mieux, ton GS108 est manageable, tu peux forcer le port vers le modem CPL à 100 au lieu de auto.
je suis en train de me demander, si en fait ça n'est pas un défaut de conception plutôt qu'une panne, un problème de taille de tampons dans les modems.
On est d'accord que ces modems ont un port ethernet gigabit et ton PC aussi.
Le Raspberry pi est en 100Mbit/s lui par contre, c'est ce qui me met la puce à l'oreille vu la dissymétrie et que tu n'aies pas besoin de changer la MTU de son côté.
Il faudrait que tu testes en mettant une MTU "normale" à 1500 côté PC mais en réduisant le débit de la carte réseau à 100 Mbit/s voir le bouton configurer sur les paramètres réseau de la carte.
La piste à étudier:
Le modem CPL a une interface ethernet gigabit négocie le gigabit entre lui et le PC.
Cependant, comme tout bon CPL, il est bien incapable ailleurs que sur le papier de transmettre à ce débit sur les fils électriques, si il arrive à 300Mbit/s c'est déjà bien.
Comme il reçoit des données à 1000Mbit/s du PC, il est bien obligé de stocker ce qu'il reçoit vu que ça repart moins vite.
Si ses tampons sont trop petits une trame trop grande ne sera pas stockée en entier et devra être détruite.
Après, il existe des mécanismes de contrôle de flux, mais toutes les cartes réseau ne les gèrent pas.
Pareil, sur les cartes gigabit, la segmentation est souvent gérée par la carte, plutôt que par l'OS ou le pilote.
Les cartes gigabit gèrent en principe les jumbo frames (trames ethernet jusqu'à 9000 octets) quand elles sont reliées à un switch gigabit, ce qui est le cas avec ton GS108.
https://www.n9ws.com/forum/viewtopic.php?t=122123
Les switchs ont en général les mémoires tampon nécessaires pour gérer ces différences de débit entreport entrée et port sortie (ça peut aller jusqu'à un rapport de 100 entre un port gigabit et un port connecté à 10).
Si les modems CPL ne sont pas capables d'intégrer la même chose, c'est très dommage.
Certains ont un switch intégré, probablement qu'ils gérent mieux ça.
Bref,
STP fait le test en forçant ton PC en 100, ou bien, encore mieux, ton GS108 est manageable, tu peux forcer le port vers le modem CPL à 100 au lieu de auto.
Modifié le 27 janv. 2019 à 08:13
Moi non plus je ne vois pas la raison et le lien qu'il y a entre la connexion CPL et le MTU des trames Ethernet. Et pourtant je constate que ce lien existe bien car sans la liaision CPL tout fonctionne et avec les CPL mon SSH ne fonctionne qu'avec un MTU réduit.
D'ailleurs j'ai fait les tests avec la commande ping. Quand j'envois un "ping" vers le raspberry, par défaut la trame envoyée est de 64 octets de données. Et ça passe. Quand je fais un ping -l 1500, qui précise d'envoyer une trame de 1500 octets, cela ne passe plus. Je dois descendre jusqu'à 1444 pour que ça passe à nouveau.
Une page internet parle aussi de ce problème https://www.dsfc.net/infrastructure/reseau/un-probleme-mtu-avec-le-cpl/
Peut etre qu'il y a autre chose que je ne comprends pas! mais quoi ?
Modifié le 27 janv. 2019 à 09:38
si tu fais sur une interface normale un ping avec l'option f (don't fragment) à 1500, ça ne passera pas, il faut limiter à 1472
Attention aussi sous windows, si tu as ipv6, le ping sur nom, va prendre ipv6 par défaut si le dns retourne une adresse ipv6 pour nom.
Si les modems CPL refusent les paquets ipv4 fragmentés, c'est très embêtant
En plus si tu dis 1444 c'est encore 28 octets de moins que 1472
ah non, pardon, tu parles de ssh pour 1444, bizarre car la différence entre icmp et tcp, c'est 12 octets, donc ça devrait passer à 1472 -12 soit 1460 si c'est bien les paquets fragmentés qui sont refusés
Tu l'as mis à combien ta MTU en fait ?
Ce qui est surprenant dans l'affaire, c'est que la framboise, elle tu la laisses à 1500, et dans le SSH, c'est elle qui envoie le plus de données, donc les paquets de 1500 passeraient dans un sens mais pas dans l'autre ?
c'est très beurk,
je pense que tu as un des modems CPL en panne.
En ipv6 la MTU est négociée car la fragmentation n'existe pas, mais pas en ipv4.
PS,
tu peux aussi modifier la MTU plus facilement avec la commande netshell
nesh interface ip set interface x mtu=1500
le x est le numéro de l'interface lu dans netsh interface ip show interface