La Fibre
Fournisseurs d'accès à Internet mobile et 5G/4G fixe => 5G/4G Free Mobile => 
Actu Free Mobile => Discussion démarrée par: vivien le 27 mars 2022 à 12:08:20
-
Problème de MTU / MSS sur Free pour les flux montant utilisant le 464XLAT avec un APN configuré en IPv6
Pas d'upload possible vers les serveurs IPv4 only si le mobile est en IPv6
Je vais vous expliquer comment j'ai découvert le problème : en réalisant des tests nPerf
Avec un APN configuré en IPv4, le test d'envoi de nPerf fonctionne parfaitement :
(https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv4_free_ipv4.png) (https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv4_bouygues_paris_ipv4.png)
Avec un APN configuré en IPv6, le test d'envoi des même serveur nPerf affiche 0 Mb/s en montant :
(https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv6_free_ipv4.png) (https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv6_bouygues_paris_ipv4.png)
-
La solution ? Faire un test en IPv6, quand le serveur le propose, ce qui n'est pas le cas du serveur Free.
- Serveur testé en IPv4 (avec un APN IPv4) : débit montant ok
- Serveur testé en IPv4 (avec un APN IPv6) : débit montant nul (0 Mb/s)
- Serveur testé en IPv6 (avec un APN IPv6) : débit montant ok
Serveur Lasotel, testé en IPv4 puis en IPv6 :
(https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv6_lasotel_ipv4.png) (https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv6_lasotel_ipv6.png)
Serveur Orange, testé en IPv4 puis en IPv6 :
(https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv6_orange_ipv4.png) (https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv6_orange_ipv6.png)
Serveur OVH Roubaix, testé en IPv4 puis en IPv6 :
(https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv6_ovh_roubaix_ipv4.png) (https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv6_ovh_roubaix_ipv6.png)
-
Serveur OVH Strasbourg, testé en IPv4 puis en IPv6 :
(https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv6_ovh_strasbourg_ipv4.png) (https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv6_ovh_strasbourg_ipv6.png)
Serveur Rezopole, testé en IPv4 puis en IPv6 :
(https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv6_rezopole_ipv4.png) (https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv6_rezopole_ipv6.png)
Serveur Bouygues Lille, testé en IPv4 puis en IPv6 :
(https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv6_bouygues_lille_ipv4.png) (https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv6_bouygues_lille_ipv6.png)
Serveur Appliwave en IPv4 :
(https://lafibre.info/images/wireshark/202203_nperf_free_apn_ipv6_appliwave_ipv4.png)
-
J'ai pensé au début à un bug de nPerf.
Mais, non le problème se reproduit avec d'autres tests de débit, quand ils proposent des serveurs IPv4 only.
5Gmark, le débit montant est nul, uniquement sur les serveurs IPv4 (merci SFR de garder un serveur IPv4 only alors que presque tous les autres serveurs sont en dual stack)
(https://lafibre.info/images/wireshark/202203_5gmark_apn_ipv6_serveur_ipv4_1.png) (https://lafibre.info/images/wireshark/202203_5gmark_apn_ipv6_serveur_ipv4_2.png)
-
Le problème se reproduit avec SpeedTest.net d'Ookla :
SpeedTest ne donne aucune information sur la disponibilité IPv4 / IPv6 des serveurs.
La majorités des serveurs sont disponibles en IPv6 (sans possibilité de faire le test en IPv4 sur ces mêmes serveurs) et il faut donc viser des serveurs IPv4 only pour avoir un débit montant nul) :
(https://lafibre.info/images/wireshark/202203_speedtest_apn_ipv6_serveur_ipv4_1.png) (https://lafibre.info/images/wireshark/202203_speedtest_apn_ipv6_serveur_ipv4_2.png)
(https://lafibre.info/images/wireshark/202203_speedtest_apn_ipv6_serveur_ipv4_3.png) (https://lafibre.info/images/wireshark/202203_speedtest_apn_ipv6_serveur_ipv4_4.png)
-
Le problème se voit également dans un navigateur web avec le test d'UFC Que choisir qui est en IPv4 :
(https://lafibre.info/images/wireshark/202203_que-choisir_apn_ipv6_serveur_ipv4.png)
Les différents tests ont été réalisé avec ces IP, à Arcueil, au point entouré en vert, mon mobile étant attaché à l'antenne rouge (étonnant d'être sur une antenne si éloignée de ma position) :
(https://lafibre.info/images/wireshark/202203_free_apn_ipv6_ip.png) (https://lafibre.info/images/wireshark/202203_free_apn_ipv6_localisation.png)
-
Le problème se manifeste également en partage de connexion
L'upload d'images sur le site https://tinypng.com/ (serveur IPv4 only) est en échec :
(https://lafibre.info/images/wireshark/202203_tinypng_apn_ipv6.png)
-
J'ai réalisé des captures de trafic montant, en partage de connexion, avec une capture coté client et coté serveur, afin de mieux comprendre la cause de ce problème avec les flux upload.
J'ai utilisé un envoi (fichier temp.iso de 10 Mo) vers ip.lafibre.info avec Curl sous Linux (Ubuntu 21.04) connecté en Wi-Fi à mon mobile Android en partage de connexion :
- APN IPv4, flux IPv4 : curl -4 -o /dev/null -F "filecontent=@./temp.iso" http://ip.lafibre.info => ok
- APN IPv6, flux IPv4 : curl -4 -o /dev/null -F "filecontent=@./temp.iso" http://ip.lafibre.info => blocage des paquets de grande taille dans le sens montant
- APN IPv6, flux IPv6 : curl -6 -o /dev/null -F "filecontent=@./temp.iso" http://ip.lafibre.info => ok
Capture Wireshark APN IPv4 et flux en IPv4 : tout est ok
Capture coté client : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_free_upload_apn_ipv4_flux_ipv4_cli.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_free_upload_apn_ipv4_flux_ipv4_cli.pcapng.gz)
Capture coté serveur : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_free_upload_apn_ipv4_flux_ipv4_srv.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_free_upload_apn_ipv4_flux_ipv4_srv.pcapng.gz)
Capture Wireshark APN IPv6 et flux en IPv4 : blocage des paquets de grande taille
Capture coté client : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_free_upload_apn_ipv6_flux_ipv4_cli.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_free_upload_apn_ipv6_flux_ipv4_cli.pcapng.gz)
Capture coté serveur : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_free_upload_apn_ipv6_flux_ipv4_srv.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_free_upload_apn_ipv6_flux_ipv4_srv.pcapng.gz)
Capture Wireshark APN IPv6 et flux en IPv6 : tout est ok
Capture coté client : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_free_upload_apn_ipv6_flux_ipv6_cli.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_free_upload_apn_ipv6_flux_ipv6_cli.pcapng.gz)
Capture coté serveur : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_free_upload_apn_ipv6_flux_ipv6_srv.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_free_upload_apn_ipv6_flux_ipv6_srv.pcapng.gz)
-
APN IPv6 et flux IPv4 : visualisation du problème
Voici les échanges de paquets (chaque ligne = un paquet). J'ai entouré les paquets en 3 couleurs :
- Vert : le début de la connexion, parfaitement normal
- Rouge : les paquets émis de grande taille qui sont tous supprimés (car trop gros)
- Bleu : la fin de la connexion en time-out
Coté client : Les paquets sur fond noir sont des paquets retransmis une seconde fois
(https://lafibre.info/images/wireshark/202103_free_upload_apn_ipv6_flux_ipv4_cli_1.png)
Coté serveur : il manque tous les paquets rouge
(https://lafibre.info/images/wireshark/202103_free_upload_apn_ipv6_flux_ipv4_srv_1.png)
Voici le contenu texte des paquets vu que l'on est en http :
(https://lafibre.info/images/wireshark/202103_free_upload_apn_ipv6_flux_ipv4_srv_2.png)
-
APN IPv4 et flux IPv4 : un exemple quand tout est ok
(https://lafibre.info/images/wireshark/202103_free_upload_apn_ipv4_flux_ipv4_cli.png)
-
La cause ? Un MSS trop élevée en IPv4
Rappel des base du réseau : Lors de l'ouverture d'une connexion TCP, il y a dans les paquets [SYN] et [SYN-ACK] échange de la taille maximale que le réseau supporte, c'est le MSS, pour Maximum Segment Size.
MSS = MTU - en-têtes IP sans options - en -têtes TCP/UDP.
Si on prend un réseau parfait avec une MTU de 1500 octets, on a un MSS de 1460 octets en IPv4 et 1440 octets en IPv6.
Pourquoi cette différence ?
Un en-tête IPv4 (sans option) fait 20 octets
(https://lafibre.info/images/tuto/IPv4.png)
Un en-tête IPv4 fait 40 octets
(https://lafibre.info/images/tuto/IPv6.png)
-
Free utilise le 464XLAT pour joidre un serveur IPv4 quand l'APN est configuré en IPv6 only
C'est évoqué dans le rapport sur l’état d’internet en France de l'Arcep, édition 2021 :
Il y a quand même des nouveautés dans le rapport, comme les explications sur les accès IPv6 et le mécanisme de 464XLAT :
(https://lafibre.info/images/ipv6/202107_arcep_rapport_etat_internet_2021_ipv6_only_1.png)
(https://lafibre.info/images/ipv6/202107_arcep_rapport_etat_internet_2021_ipv6_only_2.png)
-
Avec un APN IPv6 only et un serveur joignable uniquement en IPv4, on va utiliser le 464XLAT et les paquets que le terminal pense envoyer en IPv4 partent finalement avec une en-tête IPv6, or rappelez vous, cela rajoute 20 octets de plus.
Il faudrait donc avoir une MSS identique entre IPv4 et IPv6.
Or ce n'est pas le cas chez Free :
Free APN IPv4 flux IPv4 : MSS renvoyée par le réseau de 1384 octets
Free APN IPv6 flux IPv4 : MSS renvoyée par le réseau de 1384 octets. La MSS réelle est de +20 octets soit 1404 octets.
Free APN IPv6 flux IPv6 : MSS renvoyée par le réseau de 1360 octets
La MSS de 1404 octets est visiblement trop importante pour le réseau qui supprime les paquets.
Visualisation de la MSS renvoyée par le réseau dans le paquet SYN-ACK pour un APN IPv6 et un flux IPv4 : 1384 octets
(https://lafibre.info/images/wireshark/202103_free_upload_apn_ipv6_flux_ipv4_cli_2.png)
Les paquets envoyé de grande taille n'arriveront jamais chez le destinataire.
Visualisation de la MSS renvoyée par le réseau dans le paquet SYN-ACK pour un APN IPv6 et un flux IPv6 : 1360 octets
(https://lafibre.info/images/wireshark/202103_free_upload_apn_ipv6_flux_ipv6_cli.png)
La solution pour Free est assez simple : il faut baisser la MSS de 20 octets quand le client utilise un APN IPv6 et le 464XLAT
-
Je suis intéressé pour savoir si vous êtes également impactés par cette MSS trop élevée sur un flux utilisant le 464XLAT, donc avec un APN IPv6 only et un serveur IPv4 only.
Pour faire ce test, il suffit d'avoir votre mobile Android en IPv6 et de faire un simple test nPerf, sur le serveur de Free (qui est IPv4 only) est suffisant.
Apple, qui utilise le CLAT ne devrait pas être impacté : Les paquets partent directement en IPv6 avec l''adresse IPv4 codée dans l'IPv6 sans passer par un véritable parque IPv4 comme c'est la cas avec le 464XLAT.
-
Je confirme que sur iphone de mon coté le problème ne se manifeste pas.
Pas de tel Android sous la main pour tester :/
-
Sur un iPhone, je veut bien le test de l'upload via le partage de connexion.
En partage de connexion, l'iPhone va utiliser le 464XLAT tous les flux IPv4 chez Free (chez Orange / Bouygues, il y a un DNS64 qui fait que 99% du trafic IPv4 est en fait du trafic qui est en IPv6 dés le début).
-
Hello
De mon côté, OnePlus 5, Android 11, je ne suis pas impacté par le souci en « 5G » affichée
-
Sur un iPhone, je veut bien le test de l'upload via le partage de connexion.
En partage de connexion, l'iPhone va utiliser le 464XLAT tous les flux IPv4 chez Free (chez Orange / Bouygues, il y a un DNS64 qui fait que 99% du trafic IPv4 est en fait du trafic qui est en IPv6 dés le début).
Je te ferais ça au bureau demain
-
Aucun souci pour moi également (Mi10 / Android 11) :
-
Pas de soucis particulier non plus. iPhone 5G -> macbook
IPv6 ok. J'utilise bien les DNS de free.
Bon, la vitesse d'upload est décevante comme d'hab chez Free Mobile, mais pas à 0. J'ai pas mieux en IPv4, ni vers un serveur nPref IPv6.
-
Free APN IPv4 flux IPv4 : MSS renvoyée par le réseau de 1384 octets
Free APN IPv6 flux IPv4 : MSS renvoyée par le réseau de 1384 octets. La MSS réelle est de +20 octets soit 1404 octets.
Free APN IPv6 flux IPv6 : MSS renvoyée par le réseau de 1360 octets
Alors là je suis étonné : J'ai déplacé la carte SIM dans un mobile plus récent (mon Pixel6 sous Android 12, qui au passage accroche Free en 5G) et là surprise, le flux montant fonctionne en IPv4 avec APN IPv6.
Curieux, je prend de nouvelles captures, le MSS IPv4 a bien baissé, ce qui fait que les paquets sont plus petits et peuvent maintenant passer !
Free APN IPv6 flux IPv4 : MSS renvoyée par le réseau de 1352 octets. La MSS réelle est de +20 octets soit 1372 octets.
Free APN IPv6 flux IPv6 : MSS renvoyée par le réseau de 1384 octets.
Si vous savez comment la MSS peut changer en fonction du mobile, je suis intéressé.
-
Nouvelles captures, avec mon Pixel6 sous Android 12 et en 5G.
J'ai utilisé un envoi (fichier temp.iso de 10 Mo) vers ip.lafibre.info avec Curl sous Linux (Ubuntu 21.04) connecté en Wi-Fi à mon mobile Android en partage de connexion :
- APN IPv6, flux IPv4 : curl -4 -o /dev/null -F "filecontent=@./temp.iso" http://ip.lafibre.info => blocage des paquets de grande taille dans le sens montant
- APN IPv6, flux IPv6 : curl -6 -o /dev/null -F "filecontent=@./temp.iso" http://ip.lafibre.info => ok
Capture Wireshark APN IPv6 et flux en IPv4 : tout est ok
Capture coté client : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_free_android12_upload_apn_ipv6_flux_ipv4_cli.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_free_android12_upload_apn_ipv6_flux_ipv4_cli.pcapng.gz)
Capture coté serveur : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_free_android12_upload_apn_ipv6_flux_ipv4_srv.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_free_android12_upload_apn_ipv6_flux_ipv4_srv.pcapng.gz)
Capture Wireshark APN IPv6 et flux en IPv6 : tout est ok
Capture coté client : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_free_android12_upload_apn_ipv6_flux_ipv6_cli.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_free_android12_upload_apn_ipv6_flux_ipv6_cli.pcapng.gz)
Capture coté serveur : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_free_android12_upload_apn_ipv6_flux_ipv6_srv.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_free_android12_upload_apn_ipv6_flux_ipv6_srv.pcapng.gz)
-
Avec mon vieux mobile : Samsung Galaxy S6 edge (SM-G925F) sous Andorid 7.0, un mobile 4G catégorie 6 équipé d'un Samsung Exynos 7 Octa 7420 (Quadri-cœur ARM-Cortex A57 à 2,1 GHz + quadri-cœur ARM Cortex-A53 à 1,5 GHz - 2.1 GHz gravé en 14nm) et de 3 Go RAM.
Visualisation de la MSS renvoyée par le réseau dans le paquet SYN-ACK pour un APN IPv6 et un flux IPv4 : 1384 octets
(https://lafibre.info/images/wireshark/202103_free_upload_apn_ipv6_flux_ipv4_cli_2.png)
Les paquets envoyé de grande taille n'arriveront jamais chez le destinataire.
Avec mon Pixel6 sous Android 12 et en 5G. : MSS renvoyée par le réseau de 1352 octets.
On perd 32 octets sur chaque paquets et ils ne sont plus trop gros avec une en-tête IPv4 transformée en IPv6par le 464XLAT.
Je note que entre les deux versions d'Android la plage IPv4 utilisée pour l'IPv4 LAN crée par le 464XLAT a changée, tout en restant dans le 192.168.0.0/16.
(https://lafibre.info/images/wireshark/202103_free_android12_upload_apn_ipv6_flux_ipv4_cli.png)
-
Avec un Alcatel Onetouch Idol 3 (5.5) sous Android 7.0 (mobile 4G équipé d'un Qualcomm Snapdragon 615 - 8 cœurs 64-bit Cortex A53 à 1,5 GHz et 2 Go de ram)
Spécifications :
- Cellular Modem-RF Specs: 1x20 MHz downlink (DL), 1x20 MHz (UL), LTE Category 4 (DL)
- Peak Download Speed: 150 Mbps
- Peak Upload Speed: 50 Mbps
APN IPv6 et flux IPv4 (ce mobile ne sais partager que l'IPv4 en partage de connexion) : MSS de 1372 octets et les flux passent bien avec le 464XLAT
(https://lafibre.info/images/wireshark/202103_free_alcatel_idol_upload_apn_ipv6_flux_ipv4_cli.png)
C'est quoi qui fait que la MSS à la bougeotte ?
-
J'ai testé avec un iPhone SE 2020 sous iOS 15.4
APN IPv6 et flux IPv4 : MSS de 1384 octets, comme pour mon Samsung S6 edge, sauf que là cela fonctionne... à ne rien y comprendre
(https://lafibre.info/images/wireshark/202103_free_iphone_upload_apn_ipv6_flux_ipv4_cli_1.png)
-
Je n'ai pas eu le temps de réaliser de capture serveur, par contre j'ai réalisé une capture client IPv6 et il y a un truc qui me choque : j'ai dans les deux cas le paquet [SYN] qui semble perdu (pas de réponse, retransmission au bout d'une seconde).
Plus incroyable : dans les deux cas j'ai une retransmission du [SYN-ACK] du serveur, ce qui indique que le paquet [SYN] n'était pas perdu !
C'est un comportement étrange.
Autre chose étonnant, le MSS que j'envoie dans le paquet SYN est de seulement 1360 en IPv6 (contre le classique 1460 en IPv4 qui signifie qu'on a une MTU de 1500 octets)
(https://lafibre.info/images/wireshark/202103_free_iphone_upload_apn_ipv6_flux_ipv4_cli_2.png)
-
Bonjour,
le paquet SYN sort normalement de suite de la plateforme NAT64, par contre si celle-ci est un peu chargée au niveau session elle peut retarder la transmission du retour (le temps que le mapping se fasse de l'autre côté, tout en gardant le paquet en buffer avec une règle spécifique sur les TCP handshakes)
Par curiosité, essaye avec un serveur très loin genre Perth 210ms, si ça se trouve le 1er SYN/ACK reviendra avant les 1000 ms.
Et plus globalement pour le reste du problème, mon ajout dans le guide page 30:
Attention à la MTU
L’en-tête IPv6 fait 20 bytes de plus qu’IPv6, un gros paquet IPv4 revenant à une plateforme NAT64 peut donc être perdu si la plateforme ne gère pas la fragmentation correctement. Comme la fragmentation ne peut se produire qu’en IPv4, avant la traduction de retour, il faut généralement définir un réglage MTU spécifique NAT64 qui touche au traitement interne et pas à un vrai MTU d’interface.
La plateforme peut également renvoyer un message ICMP “Fragmentation Needed” au serveur IPv4.
La 2e option est utile pour certains trafics, et assurément pour ceux qui ne supportent pas la fragmentation IPv4 comme TFTP. Voir le RFC 7915.
Dans l’autre sens, vous devez vous assurez que le PMUT-D envoie au moins 1280 bytes, positionnez donc toujours la MTU de l’interface IPv4 à au moins 1260 (1260 + 20 IPv6 overhead). Sans cela des attaquants pourraient profiter de la situation pour effectuer des fragmentations non désirées. Voir RFC 7269.
-
Les retransmissions de paquets, cela semble lié au réseau Free qui est surchargé le soir (logo 5G, mais impossibilité d'avoir une vidéo Netflix. Youtube possible, mais en 144p uniquement).
J'ai refais des traces ce matin, avec l'iPhone SE 2020 sous iOS 15.4 de ma femme et la même SIM Free, plus de retransmissions.
Capture Wireshark APN IPv6 et flux en IPv4 : tout est ok
Capture coté client : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_free_iphone_upload_apn_ipv6_flux_ipv4_cli.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_free_iphone_upload_apn_ipv6_flux_ipv4_cli.pcapng.gz)
Capture coté serveur : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_free_iphone_upload_apn_ipv6_flux_ipv4_srv.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_free_iphone_upload_apn_ipv6_flux_ipv4_srv.pcapng.gz)
Capture Wireshark APN IPv6 et flux en IPv6 : tout est ok
Capture coté client : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_free_iphone_upload_apn_ipv6_flux_ipv6_cli.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_free_iphone_upload_apn_ipv6_flux_ipv6_cli.pcapng.gz)
Capture coté serveur : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_free_iphone_upload_apn_ipv6_flux_ipv6_srv.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_free_iphone_upload_apn_ipv6_flux_ipv6_srv.pcapng.gz)
-
J'ai regardé la trace coté serveur : pas de fragmentation des paquets.
iPhone SE 2020 sous iOS 15.4 : MSS de 1384 octets et les paquets arrivent bien sans fragmentation
(https://lafibre.info/images/wireshark/202103_free_iphone_upload_apn_ipv6_flux_ipv4_cli_3.png)
Pourtant, la capture coté client est très proche de celle du S6 ou les paquets sont supprimés :
Samsung Galaxy S6 edge (SM-G925F) : MSS de 1384 octets mais les paquets envoyé de grande taille n'arriveront jamais chez le destinataire.
(https://lafibre.info/images/wireshark/202103_free_upload_apn_ipv6_flux_ipv4_cli_2.png)
-
Hello,
J’ai je crois le même genre de problème.
Mon serveur perso est derrière un routeur Mikrotik et tous les paquets UDP et TCP ipv4 de mon iPhone avec Bouygues (IPv6 only avec NAT64) a destination du serveur passent très mal ou pas.
Ceux à destination du routeur Mikrotik (tunnel WireGuard par exemple) ne posent pas de problème.
Lorsque j’utilise l’IPV6 de bout en bout (serveur et routeur en dual stack), tout marche correctement.
Pareil lorsque je suis en IPv4 de bout en bout bien sûr.
J’ai créé un post ici : https://lafibre.info/remplacer-livebox/probleme-etrange-mtu-mss/msg1023406/
J’ai essayé de jouer avec le clamp-mss sur le routeur mais c’est que pour le TCP et ça n’a rien donné. En plus j’ai le problème aussi en UDP.
Avez-vous trouvé une solution côté serveur / routeur pour que cela fonctionne correctement ?
Merci.
-
Mon problème se limite à Free avec de l'IPv6 only quand je tente d'accéder à des serveurs IPv4 via le 464XLAT, depuis un mobile ancien.
Il faudrait que je teste le mobile avec de l'upload en 464XLAT avec d'autres opérateurs.
Avec les autres opérateurs IPv6 only, le 464XLAT est peu utilisé vu que ces opérateurs ont un DNS64.
Je n'ai pas trouvé de solution.
-
Ok merci. Je vais continuer sur l’autre post.