La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Actus fibre Free => Discussion démarrée par: ghue le 29 février 2016 à 18:17:54
-
Bonjour à tous,
Le fibre vient enfin d'arriver chez moi, au Plessis Trévise (94420), immeuble cablé par Orange, installation par Free dès mise à disposition.
Transfert Free ADSL --> Free FTTH.
J'héberge mon propre site web, et je rencontre beaucoup de soucis avec la fibre free (tout fonctionnait parfaitement avec l'ADSL)
Mon site fonctionne sur les ports 80 et 443.
Evidemment, redirections faite sur la Freebox vers le serveur.
Mon site est toujours accessible sur le port 80, mais "presque" jamais sur le port 443.
Typiquement, il est accessible à partir d'une "autre" connexion Free, ou Bouygues, d'une connexion 3G B&You, mais inaccessible d'Orange Fibre, Orange 3G, Numericable.
==> afin de vérifier que le soucis ne venait pas de mon serveur, j'ai supprimé la redirection des ports de la Freebox, et configurer l'accès distant de la Freebox sur 2 ports : 80 et 443 (au moins, si ca merde, c'est pas moi :-) )
Le comportement est le même : Interface Freebox accessible d'une autre liaison Free, Bouygues, mais inaccessible d'Orange ou Numericable.
Idem, quand je fais un test "http header", j'ai un résultat positif sur 80, négatif sur 443, sur le site : http://www.webconfs.com/http-header-check.php
De même, ping impossible
Avez-vous le même soucis que moi ?
Vous serait-il possible de tester mon IP ?
Merci d'avance !!!
-
C'est une connexion Free avec cet ONT ?
(https://lafibre.info/images/free/201512_convertisseur_pon_ftth_free_zmd_01.jpg)
Si oui, tu as une plage de port réservée (partage de l'IPv4 entre 4 abonnés, de type A+P) de ce fait une redirection avec un autre port en dehors de la plage ne fonctionnera pas.
En IPv6 ça donne quoi ?
-
Vous serait-il possible de tester mon IP ?
Donne-nous l'adresse de ton site. STP
-
Oui, j'ai ce boîtier additionnel.
D'après l'interface Freebox, plage de 0 à 16000 pour les ports.
IP : 91.160.13.53
(message court depuis smartphone, sorry)
-
Depuis le réseau OVH, l'accès à la box en HTTPS fonctionne (à part un problème de certificat ssl).
Je teste depuis Orange...
-
Depuis le réseau OVH, l'accès à la box en HTTPS fonctionne (à part un problème de certificat ssl).
+1 depuis un datacenter Suisse, ça passe sans soucis.
-
Merci de ton retour !
Pourtant, si on fait un check de http header à partir d'un site US, connexion impossible...
-
Aucun souci ici depuis K-Net, Online et Bouygues Télécom.
-
Salut,
Pas d'accès à ton site depuis une connexion Bouygues ADSL.
La connexion au port 80, pour recevoir une redirection 301 vers la version HTTPS se déroule sans problème.
Lors de la connexion au port 443, le handshake TCP se déroule (SYN SYN/ACK ACK), le navigateur envoie le Client Hello TLS, le serveur répond par un ACK, puis ensuite un paquet est vraisemblablement perdu, je reçois un paquet de continuation de données sans celui qui aurait dû précéder.
Le comportement paraît stable à travers les différents essais.
=> Une cause possible pourrait être liée aux problèmes relatifs au MTU rencontrés sur la nouvelle architecture Free FTTH ZMD, discutés actuellement sur d'autres sujets (https://lafibre.info/free-la-fibre/ftth-zmd-free-fait-du-ds-lite/96/).
-
Info à part : sur le RIPE cette plage semble être notée différemment ( TIF-DSL-20060817 ??)
inetnum: 91.160.0.0 - 91.163.255.255
netname: TIF-DSL-20060817
descr: Broadband Pool
country: FR
admin-c: NR1053-RIPE
admin-c: ACP23-RIPE
tech-c: TCP8-RIPE
status: ASSIGNED PA
mnt-by: PROXAD-MNT
created: 2006-08-25T14:47:36Z
last-modified: 2010-07-22T12:49:11Z
source: RIPE
-
Marin : J'ai bien accès à la page en 4G moi, bizarre.
-
Info à part : sur le RIPE cette plage semble être notée différemment (DSL?)
Rien de nouveau. Tous les clients sur la nouvelle architecture sont sur cette plage.
https://lafibre.info/free-la-fibre/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/msg283332/?topicseen#msg283332
Marin : J'ai bien accès à la page en 4G moi, bizarre.
Je ne vois pas de rapport. Les réseaux d'accès utilisés sont fondamentalement différents.
-
Salut,
Pas d'accès à ton site depuis une connexion Bouygues ADSL.
La connexion au port 80, pour recevoir une redirection 301 vers la version HTTPS se déroule sans problème.
Lors de la connexion au port 443, le handshake TCP se déroule (SYN SYN/ACK ACK), le navigateur envoie le Client Hello TLS, le serveur répond par un ACK, puis ensuite un paquet est vraisemblablement perdu, je reçois un paquet de continuation de données sans celui qui aurait dû précéder.
Le comportement paraît stable à travers les différents essais.
=> Une cause possible pourrait être liée aux problèmes relatifs au MTU rencontrés sur la nouvelle architecture Free FTTH ZMD, discutés actuellement sur d'autres sujets (https://lafibre.info/free-la-fibre/ftth-zmd-free-fait-du-ds-lite/96/).
Bien vu !
Le paquet IP faisant transiter le "TLS Server Hello" envoyé par le serveur semble trop gros pour le MTU du lien.
Test depuis une connexion Orange ADSL.
Par défaut (MTU 1500), j'obtiens le comportement décrit par Marin.
En abaissant le MTU côté client Web, ça passe (grâce au MSS annoncé dans lors du TCP-SYN)
pi@raspberrypi:~ $ curl https://91.160.13.53
curl: (35) Unknown SSL protocol error in connection to 91.160.13.53:443
pi@raspberrypi:~ $ sudo ifconfig wlan0 mtu 576
pi@raspberrypi:~ $ curl https://91.160.13.53
curl: (51) SSL: certificate subject name 'xx.xxxxx.fr' does not match target host name '91.160.13.53'
-
Idem sur une connexion Orange ADSL. Après le paquet ssl Client Hello, le serveur répond par un second paquet ACK. En même temps, le navigateur mouline.
J'ai remarqué que FF retente de se connecter sur le port 80 avec un ACK, puis le serveur me retransmet la redirection HTTP 301. S'en suit deux échanges [FIN, ACK] [ACK].
-
Ma connexion n'a pas une MTU à 1500, c'est p'tet pour ça
-
[...]
Quelqu'un pour faire remonter une description claire du problème (avec vecteurs de tests) aux équipes réseau de Free ?
C'est presque étonnant que ça ait passé ce niveau de production.
-
Ils ont testé que en IPv6, IPv4 est passé à la trappe, protocole déprécié sûrement.
-
Quelqu'un pour faire remonter une description claire du problème (avec vecteurs de tests) aux équipes réseau de Free ?
C'est presque étonnant que ça ait passé ce niveau de production.
Je viens de le faire !!
-
Voici ma capture Wireshark, sur une connexion Orange ADSL.
-
Il est possible que la Freebox abaisse le TCP-MSS pour les connexions TCP sortantes (pour tenir compte du MTU < 1500), mais oublie de le faire pour les connexions TCP entrantes.
La Freebox est-elle en bridge ou en mode routeur ?
-
En IPv6 ça donne quoi ? Tu pourrais nous donner l'IPv6 de ton serveur qui héberge le site, pour voir si le problème est identique ou non?
-
Cela montre d'ailleurs que le MTU IPv4 serait de 1473 :
$ sudo ifconfig eth0 mtu 1474
$ curl https://91.160.13.53
^C (pas de réponse)
$ sudo ifconfig eth0 mtu 1473
$ curl https://91.160.13.53
curl: (51) SSL: certificate subject name 'hue.freeboxos.fr' does not match target host name '91.160.13.53'
-
A tous,
Merci de votre aide sur ce sujet !
Il est possible que la Freebox abaisse le TCP-MSS pour les connexions TCP sortantes (pour tenir compte du MTU < 1500), mais oublie de le faire pour les connexions TCP entrantes.
La Freebox est-elle en bridge ou en mode routeur ?
La Freebox est en mode routeur
En IPv6 ça donne quoi ? Tu pourrais nous donner l'IPv6 de ton serveur qui héberge le site, pour voir si le problème est identique ou non?
Mon IP V6 est : 2a01:e0a:3:4d40::1
(paramètres en pièce jointe)
-
En IPv6, c'est OK, je tombe, en utilisant l'adresse plutôt que l'IP, https://hue.freeboxos.fr/login.php, sur ton freeboxOS.
P.S : Le PMTU serait d'ailleurs de 1480 ;)
C:\>netsh interface ipv6 show destinationcache
....
Interface 5 : Connexion au réseau local
...
PMTU Adresse de destination Adresse de saut suivant
...
1480 2a01:e0a:3:4d40::1 fe80::224:d4ff:fea4:7a2a
Rq : normal, je pars en 6rd, donc avec un MTU de 1480.
-
Si c'est un problème de MTU, pourquoi est-ce que ça touche seulement certains opérateurs ?
-
Si le soucis se confirme être le MTU, alors ce qui peut faire varier l'accessibilité c'est la techno d'accès, xDSL, et aussi si l'opérateur à dégroupé ou si il passe par une collecte (L2TP, PPP)
Je dis ça car en passant par OpenVPN ça fonctionnait (donc le MTU du tunnel est plus faible, par dessus de l'ADSL).
-
Tous les opérateurs ne proposent pas une MTU au maximum et donc si le client dit avoir une MTU limitée, le serveur ne va pas dépasser la taille, donc cela va passer.
Si le client offre une MTU de 1500, le serveur va envoyer des paquets de 1500 sauf que la Freebox va jeter le paquet, trop gros pour être encapsulé dans de l'IPv6.
MTU :
Chaque interface réseau possède une propriété particulière appelée MTU (Maximum Transmission Unit). C'est une valeur entière qui correspond à la taille maximale d'un paquet transitant par cette interface.
- Ethernet : 1500
- Connexion ADSL qui utilise L2TP : 1460
- PPPoA : 1500
- PPPoE : 1492
- PPTP : 1500
- PPP en RTC :
Download : MSS size 1408 bytes (MTU 1448 bytes, unknown interface)
Upload : MSS size 1420 bytes (MTU 1500 bytes, ethernet)
- ATM : 9180
-
Quelqu'un pour faire remonter une description claire du problème (avec vecteurs de tests) aux équipes réseau de Free ?
D'ailleurs maintenant que Rani a un compte sur le forum, ça pourrait être intéressant de voir s'il accepterait de répondre à une sélection de questions faite par Vivien (par exemple, ça peut être une/des autre(s) personne(s)). Ça pourrait permettre d'éclaircir certains points qui restent un peu obscurs et éventuellement de faire remonter les problèmes repérés et d'avoir des retours dessus.
-
Suite à vos messages, j'ai réactivé mon site web (et non plus uniquement l'interface de la Freebox)
Résultat : sudo ifconfig eth0
eth0 Link encap:Ethernet HWaddr b8:27:eb:b4:8b:27
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Quand je fais un http header check sur http://www.webconfs.com/http-header-check.php, j'arrive sur un Time-out
Ensuite : sudo ifconfig eth0 mtu 1000
eth0 Link encap:Ethernet HWaddr b8:27:eb:b4:8b:27
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1000 Metric:1
--> et dans ce cas, un http header check sur http://www.webconfs.com/http-header-check.php, j'arrive sur : 200 OK
==> votre analyse est la bonne, c'est bien un pb de MTU au niveau de la Freebox qui ne gère pas un MTU de 1500.
Cela montre d'ailleurs que le MTU IPv4 serait de 1473 :
J'ai essayé en modifiant 1473, 1474 et 1475, et au final, c'est 1474 inclus.
Avez-vous besoin d'autres tests ?
(et merci à tous, vraiment, pour votre aide et vos analyses !!!)
-
Si le client offre une MTU de 1500, le serveur va envoyer des paquets de 1500 sauf que la Freebox va jeter le paquet, trop gros pour être encapsulé dans de l'IPv6.
non. le 4rd impose de fragmenter si c'est trop gros, c'est dans la norme. La freebox doit donc fragmenter (sauf si y'a DF dans le paquet) et pas rejeter le paquet.
y'a peut-être un souci ailleurs. genre un icmp qui passerai pas quelque part dans le réseau 4rd.
-
Avez-vous besoin d'autres tests ?
(et merci à tous, vraiment, pour votre aide et vos analyses !!!)
oui remet 1500 si tu veux. je vais faire quelques captures coté Orange.
-
J'ai remis la config par défaut, interface standard Freebox, donc, ça marche pas. (MTU freebox supposée à 1500)
Je vous laisse faire les logs.
Bonne nuit :-)
-
thx. bonne nuit :)
-
non. le 4rd impose de fragmenter si c'est trop gros, c'est dans la norme. La freebox doit donc fragmenter (sauf si y'a DF dans le paquet) et pas rejeter le paquet.
y'a peut-être un souci ailleurs. genre un icmp qui passerai pas quelque part dans le réseau 4rd.
Il y a DF dans les premiers paquets, donc je suppose que le PMTU Discovery est activé.
Il semble que les PC derrière la Freebox en ZMD (au moins en mode bridge) ne reçoivent pas les ICMP "Destination Unreachable / Fragmentation required, and DF flag set" qui auraient dû être envoyés par la Freebox, créant un "black hole".
Je ne sais pas pourquoi ça semble affecter la Freebox elle même également (elle devrait connaitre la MTU du tunnel pourtant).
Pour un PC Linux derrière la Freebox, je vois 3 solutions :
- forcer la valeur de MTU (ce qui semble bien fonctionner)
- positionner /proc/sys/net/ipv4/tcp_mtu_probing à 1 (Linux devrait déterminer la PMTU à l'aide des pertes de paquets à défaut d'avoir les ICMP : http://www.bortzmeyer.org/4821.html)
- positionner /proc/sys/net/ipv4/ip_no_pmtu_disc à 1, ce qui désactive le code de PMTU Discovery (le flag DF ne sera plus positionné pour le TCP, et la Freebox devrait fragmenter les paquets si elle implèmente bien du 4rd) : ça devrait fonctionner avec une MTU à 1500 mais des performances probablement moins bonnes
On ne sait pas si des ICMP "Destination Unreachable / Fragmentation required, and DF flag set" émis par des clients ou routeurs sur le réseau seraient reçus. Si ce n'est pas le cas ce qui pourrait aussi poser problème avec la première solution s'il y a une partie du réseau entre le client et le serveur (hors Free) qui a un MTU encore plus faible et qui n'ajuste pas le MSS.
Pour réellement corriger le problème, la Freebox devrait ajuster les MSS et/ou envoyer les ICMP (sachant qu'ajuster le MSS ne fonctionne que pour le TCP, et n'est pas parfait : les routes pouvant changer dynamiquement, le PMTU n'est pas forcèment une constante...).
-
Le probleme serait donc un filtrage trop fort de l'icmp sur la Freebox ?
-
Le probleme serait donc un filtrage trop fort de l'icmp sur la Freebox ?
Soit la Freebox jette le paquet trop gros, mais n'envoie pas l'ICMP.
Soit c'est plus loin dans le réseau, et là ça peut être soit un soucis de filtrage, soit de routage : avec le A+P, il faut regarder le port TCP dans les données ICMP (la copie du début du paquet ayant généré l'erreur : entête IP + 8 premiers octets de l'entête TCP/UDP) pour savoir à laquelle des 4 Freebox il faut envoyer l'ICMP.
-
Depuis le réseau OVH, l'accès à la box en HTTPS fonctionne (à part un problème de certificat ssl).
Le certificat est bon pour la bonne adresse : https://www.famille-hue.fr/
-
Pour info, l'utilisateur qui avait posté sur l'ADUF à propos de ses problèmes d'accès à certains sites ou services (sous Linux uniquement) a confirmé que réduire la MTU corrigeait le soucis.
-
Le certificat est bon pour la bonne adresse : https://www.famille-hue.fr/
En fait non il n'est pas bon. Il ne passe pas sous Mozilla et il me semble qu'aucune autorité n'est envoyée, c'est un peu n'importe quoi.
Enfin on s'éloigne...
-
Connexion OK depuis :
https://sslanalyzer.comodoca.com/?url=https://www.famille-hue.fr/
Vulnerable to SSLv3 POODLE attack
https://www.ssllabs.com/ssltest/analyze.html?d=famille-hue.fr&latest
Certificates provided 1 (1444 bytes)
SSL 3 INSECURE
Bref plein de problèmes avec le SSL/TLS, mais aucun problème de connectivité depuis ces services.
-
Pour info, l'utilisateur qui avait posté sur l'ADUF à propos de ses problèmes d'accès à certains sites ou services (sous Linux uniquement) a confirmé que réduire la MTU corrigeait le soucis.
Warning : le pb est résolu en diminuant le MTU sous Linux, mais le pb reste quand on veut juste utiliser l'interface Freebox en accès distant (ce que 90% des utilisateurs essaieront de faire)
Connexion OK depuis :
https://sslanalyzer.comodoca.com/?url=https://www.famille-hue.fr/
https://www.ssllabs.com/ssltest/analyze.html?d=famille-hue.fr&latest
Bref plein de problèmes avec le SSL/TLS, mais aucun problème de connectivité depuis ces services.
Niveau certificat, il est généré avec "LetsEncrypt", et il me pose pas mal de soucis. Obligation d'envoyé la "chaine" complète, sinon pas de détection sous Chrome / Firefox, et effectivement, vulnérable SSLv3 POODLE.
A traiter ce soir.
-
Connexion OK depuis :
https://sslanalyzer.comodoca.com/?url=https://www.famille-hue.fr/
https://www.ssllabs.com/ssltest/analyze.html?d=famille-hue.fr&latest
Bref plein de problèmes avec le SSL/TLS, mais aucun problème de connectivité depuis ces services.
Merci pour ces infos, j'ai corrigé la majorité des soucis. Encore un problème de chaîne de certification à finir.
-
Niveau certificat, il est généré avec "LetsEncrypt", et il me pose pas mal de soucis.
Pas reconnu par Mozilla semble-t-il.
Obligation d'envoyé la "chaine" complète, sinon pas de détection sous Chrome / Firefox, ()
Pour moi ça marche sous Chrome (sous Windows), mais c'est sans doute une anomalie.
Regarde comment est annoncé le certificat de lafibre.
-
A priori, il s'agit de remplacer dans la configuration de ton serveur apache, le certificat du serveur par la concaténation "certificat serveur + certificat autorité intermédiaire.
Ainsi, le serveur transmettra ces 2 certificats au cours de la négociation TLS.
Dans ton cas :
- Télécharger le certificat de l'autorité intermédiaire "Let’s Encrypt Authority X1" au format PEM à l'adresse https://letsencrypt.org/certificates/
- Concaténer les certificats (certificat du serveur en premier)
cat server.pem intermediate-ca.pem > chain.pem
- Utiliser ce nouveau fichier en tant que certificat (paramètre apache "SSLCertificateFile ")
-
Bonjour,
Dites, je pensais à un truc tout bête concernant les problèmes de MTU que certains ont.
- Est-ce qu'il n'y aurait pas par hasard une configuration des clients en IP fixe ? Dans ce cas, qui a pensé à configurer la MTU ?
- Est-ce que le serveur DHCP de la freebox envoie bien l'option MTU (option 6 il me semble) en IPv4 pour réduire la MTU ? Est-ce que cette option est bien pris en charge par les clients linux et windows ?
Ensuite, par expérience malheureuse en IPv6, j'avais constaté à un moment que le 6rd de Free n'envoyait pas d'ICMP 'MTU too big' quand le client était configuré avec une MTU IPv6 de 1500 et que j'envoyai un gros ping, comme s'il considérait que par défaut le client a la bonne MTU. Résultat j'avais plein de soucis de connexions en IPv6. Résolu depuis que j'utilise la configuration du RA (merci @corrector).
On doit pouvoir voir ça si on a un ICMP d'erreur en retour avec un simple tcpdump d'un 'ping -s 1472'.
-
Pourtant, en IPv6, tu as une MTU de 1500, non ?
-
En 6rd, le MTU IPv6 est de 1480. Il est encapsulé dans un IPv4 qui lui a un MTU de 1500.
-
Ici (FTTH ZMD) on est en 4rd : C'est l'IPv4 qui a un MTU plus faible, car l'IPv4 est encapsulé dans de l'IPv6 qui lui a une MTU de 1500.
-
Oui, mais le problème de MTU ressemble fortement au problème que j'avais (perte de connexions) en ayant mal configuré le RA de mon routeur qui envoyait une MTU de 1500 (alors que c'est 1480 en 6rd).
Il faut juste inverser le problème entre IPv4 et IPv6: on dirait que le serveur DHCP IPv4, ou que le client IPv4 ne prend pas/mal en compte la nouvelle MTU. Et si en plus la box n'envoie pas de code d'erreur "MTU too big", on est marron.
-
Ensuite, par expérience malheureuse en IPv6, j'avais constaté à un moment que le 6rd de Free n'envoyait pas d'ICMP 'MTU too big' quand le client était configuré avec une MTU IPv6 de 1500 et que j'envoyai un gros ping, comme s'il considérait que par défaut le client a la bonne MTU.
Je viens de tester et j'observe l'inverse.
-
En 6rd, le MTU IPv6 est de 1480. Il est encapsulé dans un IPv4 qui lui a un MTU de 1500.
En ZMD, la mtu es à 1500 que ça soit en v4 ou en v6. On supporte les jumbo.
Par contre, y a un soucis (lire bug) sur certains ONU qui prennent pas correctement leur conf pour
accepter les jumbo qui est apparu suite à une modif mi-février (ce qui pose donc des pbs en v4).
Y a eu une correction la nuit dernière mais on voit encore quelques cas => on va voir avec le constructeur.
-
Merci pour l'éclaircissement
-
Ça explique effectivement pourquoi les premiers tests par cyberjuls ne montraient pas le problème, et pourquoi il n'y avait pas d'ICMP : les paquets étaient perdus entre la Freebox et l'ONU.
Est-ce que les jumbo frames sont supportées côté LAN ? Est-ce que ça pourrait permettre une MTU supérieure à 1500, au moins entre deux freenautes ZMD, mais peut-être avec certains serveurs (Internet2) ?
-
En ZMD, la mtu es à 1500 que ça soit en v4 ou en v6. On supporte les jumbo.
Je suis étonné que le MTU soit de 1500 aussi bien en v4 qu'en v6, car l'en-tête IPv6 est quand même de 40 octets, contre 20 en IPv4, donc il y a quand même 20 octets de plus pour l'IPv6 ? A moins de prendre sur la partie data, peut-être le fameux MSS (Maximum Segment Size), en IPv6 ?
-
Ça veut juste dire que le réseau est capable de transporter des paquets d'une taille supérieure à 1500. C'est les fameuses "jumbo frames" dont parle Rani.
-
Les jumbo frames demandent de changer le MTU (9000 par exemple), donc je ne pense pas que cela soit par défaut ?
-
Ben c'est transparent pour l'utilisateur à priori. Si tu envoies un paquet IPv4 de taille 1500 à la box, il est empaqueté dans un paquet IPv6 dont la taille dépasse 1500 mais ça ne pose pas de problème parce que le réseau de Free est en fait capable d'accepter des paquets plus gros.
-
Les jumbo frames demandent de changer le MTU (9000 par exemple), donc je ne pense pas que cela soit par défaut ?
Tu peut avoir un MTU de 9k sur eth0 et de 1500 sur eth1.
Il faut juste faire attention à la taille des paquets destiné aux hôte derrière eth1.
-
oui c'est donc
WAN: mtu 9000 via ce qu'il appele l'ONU, ce qu'on appelle plus habituellement dans ces forums un ONT
LAN: mtu 1500 usuel
Il n'y a que de l'IPv6 qui sort coté WAN de la Freebox: soit a 1500 si c'est du trafic IPv6 normal, soit a 1520 si c'est du 4rd (de l'ipv6 qui transporte de l'Ipv4).
IPv4: PC (1500) -- lan (1500) -- Freebox (1520) -- ONU -- réseau IPv6 Free (1520) -- Gateway 4rd (1500) -- réseau IPv4 Free (1500) --- Internet v4
IPv6: PC (1500) -- lan (1500) -- Freebox (1500) -- ONU -- réseau IPv6 Free (1500) -- Internet v6
(j'ai mis 1520 au 'pif' ca peut être plus ou moins, je n'ai pas fait le calcul de la valeur exacte, cf doc du 4rd pour avoir la valeur exacte).
Le mtu 9000 possible n'est jamais utilisé au max (pour le moment et sous réserve), il sert juste pour éviter la fragmentation d'IPv4. Les paquets de taille >1500 ne transitent que sur le "domaine 4rd" de Free donc entre des équipements contrôlés par Free.
-
Je viens de tester et j'observe l'inverse.
Autant pour moi :-[, je viens de retester et j'ai compris le problème de MTU que j'avais: le firewall qui bloquait l'ICMP retourné.
Au passage j'ai fais d'autres tests et je suis tombé sur cette conclusion: certain serveurs n'autorisent tout simplement pas la fragmentation en ipv6, alors que d'autres oui.
Typiquement:
:~$ sudo ping6 -s 1433 ipv6.google.com
PING ipv6.google.com(par10s21-in-x0e.1e100.net) 1433 data bytes
^C
--- ipv6.google.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2009ms
$ sudo ping6 -s 1433 www.subnetonline.com
PING www.subnetonline.com(2a02:348:82:cb69::1) 1433 data bytes
1441 bytes from 2a02:348:82:cb69::1: icmp_seq=1 ttl=57 time=29.7 ms
1441 bytes from 2a02:348:82:cb69::1: icmp_seq=2 ttl=57 time=29.2 ms
^C
--- www.subnetonline.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 29.209/29.470/29.732/0.312 ms
Oui à la fin de la fragmentation !
Edit:
Un dernier test MTU pour la route maintenant que je suis chaud:
Sur PC derrière un routeur, je ping la freebox (IP = mafreebox6.freebox.fr):
$ ping6 -M do -s 1433 fd0f:ee:b0::1
PING fd0f:ee:b0::1(fd0f:ee:b0::1) 1433 data bytes
1441 bytes from fd0f:ee:b0::1: icmp_seq=1 ttl=63 time=1.17 ms
1441 bytes from fd0f:ee:b0::1: icmp_seq=2 ttl=63 time=0.986 ms
1441 bytes from fd0f:ee:b0::1: icmp_seq=3 ttl=63 time=1.03 ms
1441 bytes from fd0f:ee:b0::1: icmp_seq=4 ttl=63 time=0.979 ms
^C
--- fd0f:ee:b0::1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.979/1.042/1.174/0.081 ms
Sur le routeur, un tcpdump sur l'interface wan montre:
$ sudo tcpdump -nai eth0 ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:50:48.212663 IP6 2a01:xx::xx > fd0f:ee:b0::1: ICMP6, echo request, seq 1, length 1441
16:50:48.213012 IP6 fd0f:ee:b0::1 > 2a01:xx::xx: frag (0|1432) ICMP6, echo reply, seq 1, length 1432
16:50:48.213070 IP6 fd0f:ee:b0::1 > 2a01:xx::xx: frag (1432|9)
Il s'agit du premier paquet de la séquence du ping.
En gros:
- la box répond bien à un paquet lui étant destiné, même si le paquet est trop grand par rapport à sa MTU (1480)
- la réponse est fragmentée (soit !)
- ce qui en soit n'est pas choquant, la MTU de l'interface en IPv6 devant être forcé à 1480 je suppose par son ravd interne
- mais à AUCUN moment je n'ai eu un ICMP too big => ça ce n'est pas normal
Le même tcpdump sur ping trop grand vers un serveur internet qui l'accepte (www.subnetonline.com) montre bien que la freebox retourne un "ICMP6, packet too big", mais quelle fragmente bien le request car je vois également les fragments de reply arriver.
A mon avis, quand on accède à une IPv6 de la Freebox avec un paquet trop grand:
- soit la freebox doit retourner un ICMP too big en plus de ses fragments
- soit elle doit être capable de répondre sans fragmenter
Voila, c'est à mon avis un petit bug qui va être vite corrigé.
-
A moins de prendre sur la partie data, peut-être le fameux MSS (Maximum Segment Size), en IPv6 ?
Attention, le concept the MSS ne s'applique qu'à TCP : cela correspond aux données de l'application transportées en une fois. La couche TCP a bien sûr plus de données que les données de l'application à donner à la couche IP.
En UDP on parle de charge utile mais pas de MSS.
Ce qui est discuté ici s'applique à IP donc s'impose à tous les protocoles utilisateurs.
-
...
Tu mélanges un peu les notions et les règles de fragmentation en IPv6:
En IPv6 il n'est pas interdit de fragmenter aux extrémités, c'est meme assez usuel.
Ce qui est interdit c'est de fragmenter 'au milieu', c-a-d que les routeurs intermédiaires fragmentent un flux.
Quand tu ping un hote lointain au travers de la Freebox, celle-ci est un routeur intermédiaire donc elle n'a pas le droit de fragmenter si le paquet est plus grand que son MTU: elle répond "ICMP6, packet too big".
Quand tu ping directement la Freebox, elle n'est plus routeur intermédiaire mais le nœud d'extrémité , elle peut donc fragmenter sa réponse. Elle n'a pas a répondre "ICMP6, packet too big" si elle sait (ou veut) fragmenter.
-
Tu mélanges un peu les notions et les règles de fragmentation en IPv6:
...
Merci ! C'est très clair !