Die MTU bei KD ist zu gering und verletzt offenbar die IPv6 Anforderung minimaler MTU = 1280. Die MTU ist nur für TCP Verbindungen von Bedeutung. Die „MTU“ Probleme sind zum Teil selbst verursacht. Auf unsere Supernode wird die MSS für alle Interface entsprechend Interface MTU festgeklemmt. Damit sorgen wir für ein nicht funktionierenden pmtu discovery. Die zur Verfügung stehende pmtu ist von vieles anhängig IPv4/IPv6 Verbindung der Node zur GW, pmtu für einzelnen Interface,…
zur geringe mtu/mss sorgen für eine erhöhten Datenaufkommen, zu hohe ebenso, dazu kommt noch die Reassemblierung der TCP Pakete. die eine Belastung der CPU bedeutet, usw.
Scheinbar macht der Anschluß nur (gerade) Probleme, aufgefallen ist es mir nachdem ich den experimental Knoten zum Testen mit an das Gäste-Lan der Fritzbox gehängt hatte.
Es funktionierte vorher ja und das Einzige was sich geändert hat ist das zum Test zwei nun FF-Knoten dran hängen.
Der andere Knoten der vorher schon angeschlossen war läuft mit gluon v2015.1.2 und der site.conf https://github.com/freifunk-suedpfalz/site-ffsuedpfalz/blob/ffhassloch/site.conf
Aufgefallen war mir das die Knoten mit unterschiedlichen Supernodes verbunden waren (wie haben nur zwei).
Eine schlüßige Erklärung für die super kleine MTU unter 1280 kann ich mir daraus zwar auch nicht herleiten, aber ich habe den experimental Knoten einfach mal abgehängt und versucht den alten Knoten mit ping6 -s 1123 zu erreichen was trotzdem nicht ging. Nur kleinere Pakete gehen durch.
Ich würde zum Testen ja auch einfach mal die Fritzbox neustarten damit sie eine neue Verbindung aufbaut aber wenn es dann funktioniert sind wir auch nicht schlauer und haben keine Möglichkeit mehr das zu debuggen.
Es sei noch dazu gesagt das Wir eine Fritz!Box 6490 Cable haben … bei anderen Routern von UMKBW/Kabel Deutschland kann das abweichen zB. bei einem Technicolor wird es nicht angezeigt welche MTU du bekommen hast … bei der neuen Surfbox habe ich noch keine Gelegenheit gehabt
Wenn ich es also richtig verstanden habe, dann sind die fastd-server nicht per IPv6 erreichbar, die Gluon-Knoten gehen also in diesem Fall zwangsweise über DSlite (den GCN Tunnel).
Die Benchmarkerei an IPv6 kann man sich hier also sparen, da nicht relevant.
Ich würde dann sagen: 1406er-MTU für die Fastd-peers ist schicht zu groß. Versucht es mit 1364 oder macht die Supernodes per IPv6 erreichbar. (letzteres hilft aber nicht Leuten, die ihre Freifunk-Router aus Sicherheitsgründen (z.b. Arztpraxen) in einer Routerkaskade hängen haben hinter einem TC7200, welche leider keine IPv6-Prefixe deligieren kann. Da gibt es dann nur IPv4.)
0.queich.net has address 78.46.193.78
0.queich.net has IPv6 address 2a01:4f8:c17:29e::2
1.queich.net has address 78.46.191.160
1.queich.net has IPv6 address 2a01:4f8:c17:207::2
udp6 0 0 :::10000 :::* 0 13401 1338/fastd
socat - UNIX-CONNECT:/var/tmp/fastd.ffld.sock
zeigt sowohl IPv4 also auch ipV6 Peers an.
Die fastd MTU hatte roman von ffka auf 1406 ausgerechnet damit der fastd Tunnel sowohl über IPv4 und IPv6 passt.
Erklärst du mir den Vorschlag von 1364 bitte.
Die MTU der GRE Tunnel zum FFRL Backbone ist auf 1400 gesetzt.
Und wir haben TCPMSS clamp to PMTU mit iptables gesetzt.
Das Problem scheint auch nur meinen Anschluss zu Betreffen.
Andere Knoten in unserer Domäne die ich sporadisch testet hatten das Problem nicht.
Die fastd MTU hatte roman von ffka auf 1406 ausgerechnet damit der fastd Tunnel sowohl über IPv4 und IPv6 passt.
Erklärst du mir den Vorschlag von 1364 bitte.
Meistens haben die Kabelanbieter wesentlich kleinere MTUs als 1406, 1364 ist der Wert womit wir am wenigsten Probleme hatten.
(ich überlege, zu welchem der vielen MTU-Size-Limbo-Threads das hier gejoined werden könnte. Neue Erkenntniss, abgesehen von „Alles fsck da draussen“ ist nicht mehr zu erwarten. Dass der Code für AutoMTU im fastd ja mal vorgesehen war, wegen dauer-broken aber removed wurde. Ärgerlich… wäre schön, wenn sich da mal jemand drum kümmern würde. Aber dafür bräuchte es halt mehr fähige Programmier. Die Liste der wünschenswerten Dinge ist lang.)
Auf MTU test - LetMeCheck.it kann man die MTU auch ermitteln.
Der Test mit der IP 2a03:2260:100a:a:f6f2:6dff:fe22:67da kommt aufs gleiche Ergebnis.
1122 bytes maximaler Payload
Wie finde ich heraus welcher Hop die Größe so runterzieht?
EDIT: da war ja was… tracepath
tracepath6 2a03:2260:100a:a:f6f2:6dff:fe22:67da
...
9: freifunk-rheinland.speedboneber1.nlsix.net 23.711ms asymm 6
10: freifunk-rheinland.speedboneber1.nlsix.net 23.750ms pmtu 1400
10: 2a01:4f8:c17:29e::2 17.409ms asymm 9
11: 2a01:4f8:c17:29e::2 17.507ms pmtu 1328
11: no reply
12: no reply
13: no reply
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
25: no reply
26: no reply
27: no reply
28: no reply
29: no reply
30: no reply
Too many hops: pmtu 1328
Resume: pmtu 1328
nach 2a01:4f8:c17:29e::2 kommt normal der FF-Knoten
traceroute6 läuft ja durch mit den kleinen Paketen.
Achtung, wir geben per radvd eine mtu von 1328 bekannt. Dieser Wert wird selbst verständlicherweise für IPv6 Adressen verwendet (es sei den die Gegenstelle hätte ein geringere Wert)…
Woher es kommt ist schwer zu sagen. Unter Umständen kommt eine Rückantwort über der 2. GW. Ich hatte bei einige Test mit wireshark komische Phänomene die auf so etwas deuten.
