Unitymedia ipv6 Tunnel an ipv4 Anschluss - langsam

[BadBunny]

Heisst wohl auf nächstes OS warten :-/

Was bei Unitymedia zum Glück nicht lange dauert. :wand: :wand: :wand:

 

[Andreas1969]

Ich schätze mal so in 2 Jahren.

 

[hasselholz]

na da bin ich ja froh, dass ich nicht der einzige bin. Ich hab schon gedacht es liegt an mir :wand: Ich hab auch den Verdacht, dass bei der Fritzbox 6490 was mit der MTU daneben läuft. Der Support (ich habs nochmal versucht) konnte natürlich nicht helfen, hat mich auch gar nicht verstanden was ich wollte. Und als ich dann so böse Worte wie MTU, ICMPv6 und PMTU Discovery in den Mund nahm, wurde es ziemlich ruhig am anderen Ende :mussweg:

Ich hab IPv6 erstmal wieder zu den Akten gelegt. Schade, so wird das nie was mit dem neuen Standard ...

 

[JurgenS]

Hallo,
gibt es inzwischen eine Lösung? Ich habe jetzt auch die Fritzbox 6490 und den 200/10'er Tarif.

Meine Symptome sind exakt wie von "hasselholz" am 12.2. auf Seite 1 beschrieben.
Adresszuteilung, Routing und eingehender wie ausgehender Ping etc. funktionieren tadellos. Ping mit einer Pufferlänge bis 1232 funktioniert auch. Ab einer Pufferlänge von 1233 geht bei Ping gar nichts mehr.

Falls einer von Euch etwas herausgefunden hat oder noch herausfinden sollte dann bitte kurz hier melden.

Danke
Jürgen

 

[SpaceRat]

Ihr könntet ja mal - unter Linux - folgendes ausprobieren:

i=1360; while ping -s $i -M do -nc1 82.135.16.28 >/dev/null; do i=$((i+1)); done; echo $((i-1+8))

Von dem Wert, der da rauskommt. wären für einen 6in4-Tunnel incl. SixXS-Tunnel 20 Bytes abzuziehen.

Möglicherweise ist ja die IPv4-MTU bereits reduziert und jede gängige MTU für den 6in4-Tunnel damit zu groß?
Notfalls wäre die MTU für den Tunnel dann halt auf 1232 Bytes anzupassen, wobei mich eine MTU von 1252 für die IPv4-Verbindung schon erstaunen würde ...

 

[JurgenS]

Ihr könntet ja mal - unter Linux - folgendes ausprobieren:
...

Hallo,
nein soweit war ich gestern auch schon, die ermittelte IPv4 Pufferlänge beträgt z.B. in meinem Fall 1709. Damit gibt es also gar keine Probleme. Die MTU auf 1232 festzulegen geht auch nicht, da IPv6 eine Minimallänge von 1280 vorschreibt. Weder Fritzbox noch SixSX lassen richtigerweise kleinere Werte als 1280 zu.

Ich bin momentan auf einem ganz anderen Dampfer. Unter IPv6 wird nicht mehr fragmentiert. Die Beschränkung der Paketgröße erfolgt durch Verwerfen des Paketes und Senden einer ICMPv6 "Paket zu groß" Nachricht. Der Sender müßte dann neue, kleinere Pakete senden.
Meine Vermutung im Moment: Diese ICMP Pakete werden irgendwo geblockt. Ich konnte sie auf meiner Seite mit Wireshark nie sehen. Das würde erklären warum der ganze Ablauf nicht funktioniert.

Naja,
Jürgen

 

[SpaceRat]

nein soweit war ich gestern auch schon, die ermittelte IPv4 Pufferlänge beträgt z.B. in meinem Fall 1709.

Bei 1709 muß aber was oberfaul sein ...

Die MTU auf 1232 festzulegen geht auch nicht, da IPv6 eine Minimallänge von 1280 vorschreibt. Weder Fritzbox noch SixSX lassen richtigerweise kleinere Werte als 1280 zu.

Stimmt, das habe ich nicht bedacht.

Meine Vermutung im Moment: Diese ICMP Pakete werden irgendwo geblockt. Ich konnte sie auf meiner Seite mit Wireshark nie sehen. Das würde erklären warum der ganze Ablauf nicht funktioniert.

Versuch doch aus Jux mal, eine IPv6-Freigabe für den Test-Rechner zu machen und IPv6-Pings (oder auch mal temporär alles) zu erlauben. Vielleicht sind die fehlenden ICMPv6-Geschichten ja versehentlich mit in die Firewall gewandert, obwohl diese eigentlich nie geblockt werden dürften ...

 

[JurgenS]

Versuch doch aus Jux mal, eine IPv6-Freigabe für den Test-Rechner zu machen und IPv6-Pings (oder auch mal temporär alles) zu erlauben. Vielleicht sind die fehlenden ICMPv6-Geschichten ja versehentlich mit in die Firewall gewandert, obwohl diese eigentlich nie geblockt werden dürften ...

Habe ich gestern auch schon gemacht. Wie in meinem ersten Beitrag geschrieben kommen Pings von außen an meinem HeimServer problemlos an.

Kannst gern auch selber schauen:
Geht: ping6 2a01:198:200:8c0d:20c:29ff:fe6d:19dc
Geht nicht: wget http://[2a01:198:200:8c0d:20c:29ff:fe6d:19dc]/ (Timeout :wut: )

Jürgen

 

[SpaceRat]

Kannst gern auch selber schauen:
Geht: ping6 2a01:198:200:8c0d:20c:29ff:fe6d:19dc

Yepp.

Und:

root@OpenWrt:~# i=1200; while ping6 -s $i -M do -nc1 2a01:198:200:8c0d:20c:29ff:fe6d:19dc >/dev/null; do i=$((i+1)); done; echo $((i-1+8))
1240

Irgendwas an der MTU is verkorkst.

 

[JurgenS]

1240

Irgendwas an der MTU is verkorkst.

Naja, das ist doch was hasselholz schon auf Seite 1 schrieb und ich auf Seite 3 bestätigte. Ping6 nur bis Pufferlänge 1232. Dein Script zählt noch 8 dazu und zeigt 1240 an.

Die MTU in Fritzbox und SixXS steht aber momentan auf 1328. Was aber auch egal zu sein scheint. Auch mit 1280 oder 1400 immer dasselbe Verhalten.

:wand: :wand: :wand:

 

[SpaceRat]

Die MTU in Fritzbox und SixXS steht aber momentan auf 1328. Was aber auch egal zu sein scheint. Auch mit 1280 oder 1400 immer dasselbe Verhalten.
:wand: :wand: :wand:

Man könnte mit der MTU für die IPv4-Verbindung rumspielen, sofern UM das nicht sofort überschreibt.
Es gibt diverse MTU-Einstellungen in der .export-Datei der Fritz!Box, an denen man mal drehen könnte.

 

[JurgenS]

Man könnte mit der MTU für die IPv4-Verbindung rumspielen, sofern UM das nicht sofort überschreibt.
Es gibt diverse MTU-Einstellungen in der .export-Datei der Fritz!Box, an denen man mal drehen könnte.

Gute Idee. Ich habe dazu beide gleichartige Export-Dateien (6490 und 6360) miteinander verglichen um einen Ansatzpunkt zu finden an welchen Punkten sie sich unterscheiden. Alles was nach Firewall oder MTU oder so aussieht ist aber gleich eingestellt. Bliebe also nur blindes herumstochern...

 

[Andreas1969]

Ich vermute mal,
es wird erst mal keine Lösung geben.
Oder hat noch jemand ne Idee?

 

[hasselholz]

vielleicht wenn alle, die davon betroffen sind mal bei UM anrufen und ein Ticket aufmachen :zwinker:

 

[SpaceRat]

vielleicht wenn alle, die davon betroffen sind mal bei UM anrufen und ein Ticket aufmachen :zwinker:

Wie willst Du erreichen, daß die ein Ticket aufmachen, wo doch eh alles die kleinen grünen Männchen, Wasseradern und der Stand des Mondes schuld sind?

 

[SpaceRat]

Gute Idee. Ich habe dazu beide gleichartige Export-Dateien (6490 und 6360) miteinander verglichen um einen Ansatzpunkt zu finden an welchen Punkten sie sich unterscheiden. Alles was nach Firewall oder MTU oder so aussieht ist aber gleich eingestellt.

Es geht ja durchaus auch um das, was nicht drin bzw. auf Einstellungen a la "autodetect" steht.

Wenn Du mir sagst "Jetzt links abbiegen." biege ich links ab, wenn Du das gleiche meiner Frau sagst, biegt sie rechts ab, es sei denn, es wurde vorher die Einstellung "Meine Seite = links" vorgenommen.

Das gleiche kann ja auch in der Firmware passiert sein:
Wenn Du der 6360 sagst "Erkenne die MTU selber" dann kommt sie wohl auf 1480, die 6490 womöglich nur auf 1280.
Oder es gibt Unterschiede zwischen den Profilen für 100 und 200 MBit/s, die man aber evtl. durch bestimmte feste Vorgaben in der Fritz!Box kompensieren kann ...

Irgendwas nach der Art ...

Bliebe also nur blindes herumstochern...

Richtig.

Ich kann da nicht viel machen, ich habe keinen Zugriff auf einen Anschluß mit 200 MBit/s und IPv4.
Ich kann nur Vergleichswerte vom 100/10er Profil liefern und da kommt für IPv4 folgendes raus:

root@Pi ~ # i=1360; while ping -s $i -M do -nc1 82.135.16.28 >/dev/null; do i=$((i+1)); done; echo $((i-1+8))
1480

Wenn beim 200er Profil auf der 6490 schon für IPv4 etwas anderes herauskommt, könnte es sinnvoll sein hier mal damit rumzuspielen, den Wert 1480 vorzugeben und den MTU-Test zu wiederholen.

 

[Conan179]

Wen es von inntresse ist, hier 120mbit, DS-lite

root@Raspberry:~# i=1360; while ping -s $i -M do -nc1 82.135.16.28 >/dev/null; do i=$((i+1)); done; echo $((i-1+8))
1440

 

[SpaceRat]

Wen es von inntresse ist, hier 120mbit, DS-lite
1440

Ne, ist es in dem Fall nicht.

DS-lite ist ja quasi genau das Umgekehrte dessen, was hier im Thread Thema ist.

 

[Conan179]

tja war ein versuch wert.

 

[Fabricio75]

IPV4 und 200er Leitung, frage mich warum da ein noch kleinerer und vor allem krummer Wert rauskommt:

root@Raspberry:~# i=1360; while ping -s $i -M do -nc1 82.135.16.28 >/dev/null; do i=$((i+1)); done; echo $((i-1+8))
1367

 

[SpaceRat]

IPV4 und 200er Leitung, frage mich warum da ein noch kleinerer und vor allem krummer Wert rauskommt:

root@Raspberry:~# i=1360; while ping -s $i -M do -nc1 82.135.16.28 >/dev/null; do i=$((i+1)); done; echo $((i-1+8))
1367

Krumm ist der Wert, weil schon der Startwert zu hoch ist, d.h. die MTU liegt noch unter 1360 ...

Mach mal

i=1240; while ping -s $i -M do -nc1 82.135.16.28 >/dev/null; do i=$((i+1)); done; echo $((i-1+8))

Und damit wäre mein nächster Schritt:
1. pro-forma-Ermittlung der MTU ... so niedrig kann die aber eigentlich nicht wirklich sein ...
2. In der .export nachgucken, wo die MTU der Internet-Verbindung (IPv4) vorgegeben wird und dort 1480 einsetzen

 

[Fabricio75]

Ich glaube wir müssen nochmal von vorn anfangen da der Test vermutlich aufgrund des fehlenden "echten" Linux nicht korrekt funktioniert. Ich habe jetzt mal wie folgt getestet und bin bis 1472 (soweit ich weiß muss man noch 28 Bytes addieren) und käme somit auf eine max. MTU von 1500. Sobald ich mit 1473 teste kommt die Meldung, dass das Paket fragmentiert werden müsste:

ping -f -l 1472 82.135.16.28
Ping wird ausgeführt für 82.135.16.28 mit 1472 Bytes Daten:
Antwort von 82.135.16.28: Bytes=1472 Zeit=26ms TTL=244
Antwort von 82.135.16.28: Bytes=1472 Zeit=29ms TTL=244
Antwort von 82.135.16.28: Bytes=1472 Zeit=40ms TTL=244
Antwort von 82.135.16.28: Bytes=1472 Zeit=29ms TTL=244
Ping-Statistik für 82.135.16.28: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.: Minimum = 26ms, Maximum = 40ms, Mittelwert = 31ms

Dann habe ich mir die Export angeschaut.

Im Abschnitt ar7cfg:

mtu_cutback_mode = mtumode_auto;
mtu_cutback = 1500;

und im Abschnitt IPV6 (den SIXXS Tunnel habe ich derzeit nicht aktiviert):

use_fixed_mtu = yes;
fixed_mtu = 1500

Im IPV6 Abschnitt variiert der Wert entsprechend sobald ich ihn übers Webinterface ändere und wieder exportiere, im Abschnitt ar7cfg bleibt es immer auf auto und 1500 stehen.

Hilft das weiter?

Ich denke einen geänderten MTU Wert für IPV4 (Abschnitt ar7cfg) wird die Box nicht übernehmen, solange mtumode_auto drin steht, ich weiß aber nicht wie der Wert für manuell lautet.

 

[Fabricio75]

Habe jetzt mal die max MTU per IPV6 (SIXXS Tunnel aktiviert) ermittelt. Die Minimum MTU bei SIXXS ist ja mit 1280 angegeben, allerdings funktioniert der IPV6 ping, ich habe heise.de genommen, erst ab 1232, sobald ich höher gehe kommt eine Zeitüberschreitung.

Per IPV4 ping auf 82.135.16.28 bin ich mit einer MTU von 1500 erfolgreich.

PS: ich kann die MTU für ipv4 in der Fritzbox eh nicht anpassen, weil ich die geändert Export nicht mehr einlesen kann. Übers Webinterface kann ich den kleinsten Wert 1280 wählen.

 

[Andreas1969]

So, habe jetzt mal ausgelesen:
Fritz 6360 mit 100/5 IPV4 Anschluß mit funktionierenden SIXXS-Tunnel und
Fritz 6490 mit 200/10 IPV4 Anschluß mit nicht funktionierenden SIXXS-Tunnel
Konnte dies tun, da ich 2 Anschlüsse bei UM an 2 Standorten mit den beiden Fritz-Boxen habe.
Die MTU usw. unterscheiden sich jedenfalls nicht.
In der Export-Config ist mir jedoch ein Unterschied in der SIXXS Einstellung aufgefallen:

Fritz 6360:
ip6_static_cfg {
prefix = ::;
prefixlen = 56;
wan_use_firstprefix = yes;
wan_prefix = ::;
wan_ifid_automatic = yes;
wan_ifid = ::;
wan_dns1 = ::;
wan_dns2 = ::;
}
he {
update_server = "ipv4.tunnelbroker.net";
tunnel {
popaddr = 0.0.0.0;
local = ::;
remote = ::;
prefix = ::;
prefixlen = 0;
}
}
firewall {
enabled = yes;
exposed_host = no;
ping6_allowed = no;
rules = "TCP 8089", "TCP 443", "TCP 21";
}
aftr = ::;
}

Fritz 6490:
ip6_static_cfg {
prefix = ::;
prefixlen = 56;
wan_use_firstprefix = yes;
wan_prefix = ::;
wan_ifid_automatic = yes;
wan_ifid = ::;
wan_dns1 = ::;
wan_dns2 = ::;
}
he {
update_server = "ipv4.tunnelbroker.net";
tunnel {
popaddr = 0.0.0.0;
local = ::;
remote = ::;
prefix = ::;
prefixlen = 0;
}
}
firewall {
enabled = yes;
exposed_host = no;
ping6_allowed = no;
rules = "TCP 443", "TCP 21";
}
aftr = ::;
manual_aftrfqdn = "";
use_gw_as_pcpserver = no;
pcpserver_supports_rfc7220 = no;
}

In der 6490 steht hinter aftr = ::; noch folgender Eintrag:
manual_aftrfqdn = "";
use_gw_as_pcpserver = no;
pcpserver_supports_rfc7220 = no;

In der 6360 gibt es diesen zusätzlichen Eintrag nicht.

Vielleicht ist dies ja der Ansatz.
Kann das ev. mal jemand gegenchecken ?

 

[Fabricio75]

In der 6490 steht hinter aftr = ::; noch folgender Eintrag:
manual_aftrfqdn = "";
use_gw_as_pcpserver = no;
pcpserver_supports_rfc7220 = no;

Vielleicht ist dies ja der Ansatz.
Kann das ev. mal jemand gegenchecken ?

Kann ich bei meiner 6490 bestätigen. Habe den Eintrag ebenfalls wie du geschrieben hast.