Ik kan geen VPN verbinding maken met Forticlient als ik een hotspot maak op mijn iPhone. Als ik een andere APN instel zoals advancedinternet of portalmmm.nl wil mijn laptop überhaupt niet eens verbinden met de hotspot. Of ja, wel verbinden maar er is dan geen internet.
Als ik een zelfde iPhone gebruik met bijvoorbeeld een Odido of Vodafone simkaart werkt het prima.
Als er 1 interface in het traject naar het adres waar je heen pingt zit die 1500 of lager ingesteld staat kom je nooit hoger als die waarde.
Ook je device is een interface.
Klopt helemaal immers dat is precies waar Path MTU discovery voor bedoeld is. Mijn stelling is echter dat er geen harde limiet van 1500 bytes op de interface van de telefoon zit maar dat deze "gewoon" onderhandeld wordt met het netwerk.
+3En dat is dus niet het geval. Deze berichten over icmpv6 waar. Mtunpath discovery op werkt komen niet aan. Het is hetzelfde als de communicatie met kpn.. wij kunnen wel schreeuwen maar als je die schreeuw niet door laat houdt het op.
En dat is dus niet het geval. Deze berichten over icmpv6 waar. Mtunpath discovery op werkt komen niet aan.
Waar baseer je dat op? Kom eens met bewijs.
Als dat zo zou zijn dan zouden we hier, denk ik, van veel meer telefoons problemen gemeld zien en dat heb ik nog niet zien gebeuren.
Ik hoop dat
Ook jij
+10
--- 8 dec 2024 15:08:44
--- IP (rmnet_data2) 2a02:****:b8:f9cb:5095:31ff:fed1:7991
--- IP (rmnet_data1) 2a02:****:23b:4526:f48f:5ff:fef0:854b
--- IP (rmnet_data1) 192.0.0.2
--- IP (rmnet_data3) 2a02:****:e8:79f8:7421:85ff:fe60:3d68
--- Connection: LTE
PING 2a02:****:23b:4526:f8a5:5aff:fe51:2dc9(2a02:****:23b:4526:f8a5:5aff:fe51:2dc9) 2000 data bytes
--- 2a02:****:23b:4526:f8a5:5aff:fe51:2dc9 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
--- 8 dec 2024 15:09:44
--- IP (rmnet_data2) 2a02:****:b8:f9cb:5095:31ff:fed1:7991
--- IP (rmnet_data1) 2a02:****:23b:4526:f48f:5ff:fef0:854b
--- IP (rmnet_data1) 192.0.0.2
--- IP (rmnet_data3) 2a02:****:e8:79f8:7421:85ff:fe60:3d68
--- Connection: LTE
PING 192.0.0.2 (192.0.0.2) 2000(2028) bytes of data.
2008 bytes from 192.0.0.2: icmp_seq=1 ttl=64 time=0.163 ms
2008 bytes from 192.0.0.2: icmp_seq=2 ttl=64 time=0.233 ms
2008 bytes from 192.0.0.2: icmp_seq=3 ttl=64 time=0.525 ms
--- 192.0.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2044ms
min = 0.163 ms
avg = 0.307 ms
max = 0.525 ms
mdev = 0.156 ms
--- 8 dec 2024 15:10:58
--- IP (rmnet_data2) 2a02:****:b8:f9cb:5095:31ff:fed1:7991
--- IP (rmnet_data1) 2a02:****:23b:4526:f48f:5ff:fef0:854b
--- IP (rmnet_data1) 192.0.0.2
--- IP (rmnet_data3) 2a02:****:e8:79f8:7421:85ff:fe60:3d68
--- Connection: LTE
PING 127.0.0.1 (127.0.0.1) 2000(2028) bytes of data.
2008 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.110 ms
2008 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.211 ms
2008 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.508 ms
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2048ms
min = 0.110 ms
avg = 0.276 ms
max = 0.508 ms
mdev = 0.169 ms
En ping naar jouw eigen IPv6 adres niet naar een ander IPv6 adres.
In jouw voorbeeld lijk je te pingen naar 2a02:****:23b:4526:f8a5:5aff:fe51:2dc9 maar ik zou je willen vragen om te pingen naar één van de IPv6 adressen die daarboven vermeld staan.
Vergewis jezelf ervan dat het IPv6 adres wat je pingt bij het resultaat nog steeds erboven vermeld staat en dat het dus niet een tijdelijk IPv6 adres was dat ondertussen is komen te vervallen.
+10
Maar je pingde niet naar dat adres, je pingde immers naar 2a02:****:23b:4526:f8a5:5aff:fe51:2dc9.
Doe die ping naar 2a02:****:23b:4526:f48f:5ff:fef0:854b en plaats daarvan het resultaat hier.
+10Maar je pingde niet naar dat adres, je pingde immers naar 2a02:****:23b:4526:f8a5:5aff:fe51:2dc9.
Doe die ping naar 2a02:****:23b:4526:f48f:5ff:fef0:854b en plaats daarvan het resultaat hier.
Maar ook dat IPv6 adres pingde je niet. Daarbij kan het zijn dat het IPv6 adres frequent verandert omdat daar altijd een tijdelijk IPv6 adres getoond wordt. Ik wil je vragen om een ping te doen naar het IPv6 adres dat in Ping & Net getoond wordt bij "rmnet_data1" en het resultaat hier te posten.
+10
Nu doe ik nog een keer maar met Eindhoven IP en het is zonder probleem. Ik snap niet waarom met Utrecht IP alles verloren was en met Eindhoven niet. Lijkt afhankelijk zijn van de regionale node
--- 8 dec 2024 16:13:12
--- IP (rmnet_data2) 2a02:****:b8:f9cb:5095:31ff:fed1:7991
--- IP (rmnet_data4) 2a02:****:23b:4526:9cc9:d6ff:fe28:8637
--- IP (rmnet_data4) 192.0.0.2
--- IP (rmnet_data3) 2a02:****:e8:79f8:7421:85ff:fe60:3d68
--- Connection: LTE
PING 2a02:****:23b:4526:9cc9:d6ff:fe28:8637(2a02:****:23b:4526:9cc9:d6ff:fe28:8637) 2000 data bytes
2008 bytes from 2a02:****:23b:4526:9cc9:d6ff:fe28:8637: icmp_seq=1 ttl=64 time=0.139 ms
2008 bytes from 2a02:****:23b:4526:9cc9:d6ff:fe28:8637: icmp_seq=2 ttl=64 time=0.259 ms
2008 bytes from 2a02:****:23b:4526:9cc9:d6ff:fe28:8637: icmp_seq=3 ttl=64 time=0.378 ms
--- 2a02:****:23b:4526:9cc9:d6ff:fe28:8637 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2052ms
min = 0.139 ms
avg = 0.258 ms
max = 0.378 ms
mdev = 0.099 ms
Dat was het resultaat waar ik naar opzoek was. Er staat dus geen limiet van 1500 bytes voor de MTU size op de interface van de telefoon zelf want anders was het pingen van het eigen IPv6 adres met een grotere packetsize ook fout gelopen en dat is dus blijkbaar niet het geval.
Wat voor een OnePlus gebruik je
Zelf heb ik een paar dagen terug na zes jaar afscheid genomen van mijn OnePlus 5T en een OnePlus Nord 4 in gebruik genomen.
Zou je voor mij ook nog even een Path MTU discovery via de Ping & Net app kunnen doen naar 2606:4700:4700::1111? Wat is het resultaat daarvan?
+10Wat voor een telefoon gebruik je
One+ NordCE 5G
Zou je voor mij ook nog even een Path MTU discovery via de Ping & Net app kunnen doen naar 2606:4700:4700::1111? Wat is het resultaat daarvan?
MTU=1500
Zou je voor mij ook nog even een Path MTU discovery via de Ping & Net app kunnen doen naar 2606:4700:4700::1111? Wat is het resultaat daarvan?
MTU=1500
Dan weten we nu dat Path MTU discovery goed lijkt te werken op het mobiele netwerk van KPN.
Wegens verbouwing geen tijd gehad om te reageren. Sorry daarvoor. 🙂 Hier mijn resultaten van Samsung S21.
Instellingen ping en net app.
Naar IPv6 adres van mijn toestel op 4G.
Naar IPv4 adres van mijn toestel op 4G.
Loopback adres
Dank je
+3Nogmaals deze test zegt niks in dit geval.
Verder betreft de test ipv4.
probleem treed alleen icm ipv6 op.
Ook is deze tool niet geschikt om te testen vanaf een toestel met een hard limiet op de interface zo als de s21. Issue zit ergens op een interface binnen het kpn deel wat bijgewerkt is eind mei.
Nogmaals deze test zegt niks in dit geval.
Waarom niet? Verklaar je nader.
Verder betreft de test ipv4.
Hoe kom je daar nu bij?
probleem treed alleen icm ipv6 op.
De ping en Path MTU discovery naar een IPv6 adres die door
Ook is deze tool niet geschikt om te testen vanaf een toestel met een hard limiet op de interface zo als de s21.
Maar de S21 heeft, zoals je uit die check van
+10Android heeft geen MTU limiet voor TCP/IP, waarom zou Samsung extra in drivers inbouwen? Een MTU limiet bestond voor Bluetooth, maar sinds Android 14 kan men ook veranderen.
+3Zucht. Android heeft alleen op de nieuwere toestellen voor ipv6 geen MTU. Daarom bestaan deze problemen. Op oudere toestellen is default 1500 ingesteld. De benoemd de s21 heeft 100% een MTU van 1500 ingesteld staan af fabriek.
Zonder rooten kan je dit echter niet uitlezen.
Ook zit je met het feit dat Android door elke fabrikant eigen gemaakt wordt en instellingen mee krijgt. Dit maakt dat uitspraken als hierboven onzin zijn en zaken per toestel serie bekeken moeten worden.
Dit verklaart ook waarom het ene toestel wel en het andere toestel niet geraakt is.
Maar nogmaals met deze houding komt er nooit een oplossing. Ik heb een Redmi note 11t met issues geroot en d.m.v. de MTU voor ipv6 in de terminal vast te zetten op 1500 weer aan de gang gekregen. Nu echter geeft ipv6 icm veel commerciële vpn's de problemen die anderen beschrijven.
Blijven jullie maar lekker onder die steen.
Android heeft alleen op de nieuwere toestellen voor ipv6 geen MTU. Daarom bestaan deze problemen.
Maar het "bewijs" is toch geleverd dat zowel de Samsung S21 als de OnePlus Nord CE 5G geen MTU limiet hebben. Het pingen naar het eigen IPv6 adres zonder packet fragmentation met een packetsize van 2000 bytes gaat toch prima? Waar is die MTU limiet dan?
En wat versta je onder "nieuwere" toestellen? Vanaf welk jaar is dat dan? Die door jou genoemde Redmi Note 11T is, net als de S21 en OnePlus CE 5G, uit 2021.
Wat als ik mijn zoon vraag om zijn nieuwe OnePlus Nord 4 in gebruik te nemen die hij afgelopen vrijdag heeft ontvangen, is dat dan wel voldoende "bewijs" voor je? Zelf kan ik het niet testen want ik heb mijn mobiele telefonie bij Odido ondergebracht.
De benoemd de s21 heeft 100% een MTU van 1500 ingesteld staan af fabriek.
Heb je een artikel waaruit dat blijkt?
Ik heb een Redmi note 11t met issues geroot en d.m.v. de MTU voor ipv6 in de terminal vast te zetten op 1500 weer aan de gang gekregen. Nu echter geeft ipv6 icm veel commerciële vpn's de problemen die anderen beschrijven.
Als daardoor die Redmi geen path MTU discovery meer doet maar altijd een MTU size van 1500 gebruikt dan is dat ook heel goed te begrijpen.
+3+3En als bewijs
Logisch, de MTU size op het mobiele netwerk van KPN is immers 1500 bytes maar dat komt dus niet door een limiet van 1500 bytes op de interface van de telefoon zelf immers naar die interface is prima met een grotere packetsize zonder fragmentatie te pingen. Dat is wat aangetoond wordt met die checks van
2. Niet nodig. Ik nodig je uit om een s21 te rooten en eens in de terminal te kijken. is heel leerzaam
Voor jou mag dat dan niet nodig zijn, voor mij wel want, zoals je gemerkt hebt, heb ik een academische instelling en dat betekent dat ik elke uitspraak in principe in twijfel trek en graag onderbouwing wil zien van de geponeerde stelling.
3. en dat is de exacte reden waarom het MTU binnen de KPN masten omhoog moet naar minimaal 1520 voor IPv6
Dat is natuurlijk nergens voor nodig, de minimale MTU voor IPv6 is 1280 en elke MTU groter of gelijk aan die waarde is correct. Het zijn niet de nodes in het netwerk die de MTU size moeten verhogen, het is de cliënt (telefoon) die de payload moet verkleinen. Ik wil je er graag op wijzen dat de MTU size bij IPv6 via het vaste netwerk van KPN ook 1500 bytes is en ook daar is dat uiteraard geen enkel probleem. De telefoon behoort m.b.v. Path MTU discovery gezien te hebben dat de MTU size 1500 bytes is en de apps die via die interface willen communiceren zouden dan een maximale payload van 1460 bytes (tcp/udp) of 1452 bytes (icmpv6) moeten hanteren. Gebruiken ze toch een payload van 1480 of 1472 die voor IPv4 bij een MTU size van 1500 bytes van toepassing is dan loopt dat bij IPv6 dus fout.
4. Is het je al opgevallen dat KPN de ENIGE provider is met deze problematiek?
Ik betwijfel of er überhaupt een probleem is dat aan de KPN toegewezen kan worden.
Wel is het zo dat KPN één van de weinige providers is die IPv6 aanbiedt op haar mobiele netwerk en daarmee kan je het dus ook omdraaien en tot de conclusie kunnen komen dat sommige telefoons niet goed omgaan met het vaststellen van de te gebruiken MTU size op IPv6 netwerken.
Odido is IPv4 only en ook van Vodafone heb ik geen artikel gevonden waarin staat dat zij IPv6 ondersteunen op haar mobiele netwerk.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
