Anpassungen siehe Github:
1 „Gefällt mir“
btw: ‚8.8.8.8‘ als Destination liefert nach meiner Beobachtung an 1500er-MTU-Anschlüssen seltenst ein 1500 zurück.
Ja, gibt’s im Consumer-Bereich eher selten, aber wenn doch, dann möchte man das auch nutzen. Ich würde eher gegen einen (welchen?) der fastd-server pingen.
Ja Google ist ungeeignet für solche tests.
1 „Gefällt mir“
Hab 8.8.8.8 einfach mal genommen weil es funktioniert hat. Keine Ahnung ob das ein temporäres Phänomen ist.
Und möglichst immer erreichbar sollte das Ping-Target halt sein. Da habe ich aber so meine Bedenken mit unseren lokalen fastd-Servern. Duck und wech…
Nein, es funktioniert eben nicht, siehe erstes Posting dieses Threads. Du bekommst nie eine MTU von 1500, selbst wenn Dein Anschluss das eigentlich könnte.
Ein wichtiger Hinweis zu meinem Auto-MTU Skript:
Bei meinem Futro S550 hängt sich fastd manchmal beim einem Wechsel der MTU-Size auf!
Meine Plaste-Routern haben dieses Probleme nicht.
Mit meiner Futro-Ethernetkart-Kombo habe ich die Erfahrung gemacht, dass es zu Problemen bei fastd -Restarts kommen kann. Wenigsten mit meiner Futro-Ethernet-Kombo ist das so.
Das Problem tritt u.a. auf, wenn fastd noch aktiv beim Verbindungsaufbau zu seinen Supernodes ist, oder wenn gar kein WAN Kabel gesteckt ist, und dann fastd neu gestartet wird.
Reproduzieren kann ich dieses, indem ich folgende fastd-Restarts unverzüglich nacheinander absetze:
/etc/init.d/fastd restart
/etc/init.d/fastd restart
Da hängt sich dann ein fastd Prozess auf, der sich auch nicht mehr killen läßt.
Nach einem Reboot ist alles wieder gut.
Das Problem bei meinem Skript bzw. Verfahren ist nun folgendes:
Wird beim Booten ein Wechsel der MTU-Size erkannt, so startet das Skript fastd neu auf. Unabhängig von dem aktuellen fastd Zustandes. Und dann kann das oben beschrieben Szenario zuschlagen :o(
Damit das Skript nicht unendlich viele Sonderzustände und Use-Cases erkennen muss, habe ich mich letztendlich entschlossen das Skript funktional abzuspecken.
Es wird beim Booten wie gehabt eine optimale MTU-Size erkannt und auch gespeichert, lediglich fastd wird durch das Skript nicht neugestartet. Die erkannte MTU-Size wird eben erst beim nächsten Reboot verwendet.
1 „Gefällt mir“
Weitere technische Information zum Futro S550 MTU fastd Hänger:
Wird auf meinem Futro fastd neugestartet, obwohl der aktuelle fastd-Prozess noch keine erfolgreiche Verbindung zu seinen Super-Nodes herstellen konnte, so kommt es zu Problemen.
Reproduzieren kann ich dieses, indem ich folgende fastd-Restarts unverzüglich nacheinander absetze:
/etc/init.d/fastd restart
/etc/init.d/fastd restart
Es hat sich herausgestellt, dass fastd und weitere Prozesse dann im Status ‚D‘ festhängen (Deep Sleep, warten auf irgend welche I/O Daten).
Ein ‚killen‘ der Prozesse ist in diesem Zustand/Status nicht mehr möglich.
Wie gesagt, meine Plaste-Router haben dieses Probleme nicht.
Es gibt eine einfache Lösung für das Futro-fastd-MTU-Problem
Mein letzter Lösungsversuch, dass fastd eine ggf. geänderte MTU-Size erst mit dem nächsten Reboot übernimmt, ist auch nicht das gelbe vom Ei. Es gibt einen Use-Case, da hängt auch so ein System.
Z.B. bei einer Räumlichen-Änderung von einem Standort mit einer grossen MTU zu einem Standort mit kleiner MTU. Das System würde erstmalig mit grosser MTU aufstarten, was aber nicht zu einer Verbindung zu einem Super-Node führen kann. Daher ist auch hier ein weiterer Neustart notwendig.
Die Lösung für alle Use-Cases ist:
Die MTU-Autoerkennung wird weiterhin beim Booten durchgeführt. Eine ggf. erkannt veränderte MTU-Size wird ebenfalls per UCI abgespeichert. Und jetzt kommt’s:
Anstelle jetzt nichts zu tun, oder wie im fehlerhaften ersten Schritt, fastd neu zu starten, wird einfach folgender Befehl abgesetzt:
/etc/init.d/network restart
Hierdurch werden alle Netzwerkkomponenten inkl. abhängige Dienste geordnet runter und auch wieder hochgefahren.
fastd übernimmt dabei ebenfalls sofort die neu erkannte MTU-Size 
3 „Gefällt mir“
Gesetzt den Fall man hat jetzt mehrere Fastd-Server, die jeweils eine zum Anschluss des VPN-Knotens passende MTU anbietet (gehen wir mal von einer komfortablen Situation aus, sogar 5 Stück: 1500, 1486, 1406, 1364,1280):
Was tut man dann mit dem dhcp-server? Welchen Wert trägt man dann ein in die /etc/dhcp/dhcpd.conf unter
option interface-mtu 1326;
Wenn das getrennte Server sind (mit jeweils eigenem bat0), dann kann man ja ggf. noch getrennte DHCP-server laufen lassen.
Aber wenn da Hosts sind, die nur verschieden tun-interfaces haben für die fastd-Instanzen, alles aber in einem bat landet hinterher, wie trennt man das dann?
Und was tut man dann im Anschluss mit der iptables-rule, die meines Wissens auch systemweit ilt. Oder kann man dann nach Tabellen trennen?
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1286
Selbst wenn man dann getrennte Server für jede MTU hat, spätestens bei Meshwolken mit mehreren Uplinks und dann wirklich unvermeidbarem Quertraffic könnte das sehr schmerzhaft werden. (Meiner Vorstellung nach.)
Eben wurde ich darauf hingewiesen, dass in Gluon folgender batman-atv-Patch anwendet wird:
./patches/packages/routing/0003-batman-adv-decrease-maximum-fragment-size.patch
Hier wird BATADV_FRAG_MAX_FRAG_SIZE auf 1280 gesetzt.
Die zu patchende Datei „net/batman-adv/main.h“ gibt es auf meinem Build-System dreimal. Aber nur eine Version wird gepatcht. (Zur Info: Ich habe nur das Target ar71xx_generic gebaut).
Ich habe keine Ahnung wo und wie dieser Patch eingeht bzw. wirkt.
Ist dann das Detektieren einer großen fastd-MTU überhaupt notwendig?
Darüber hatten wir doch beim fffffm-Basteltreff am Mittwoch gesprochen (wenn auch im anderen Kontext, dort „Bugs, die es in stable-releases schaffen“): Das ist dieser nach wie vor nicht gefixte Bug, dass bereits einmal fragmentierte Pakete nicht erneut fragmentiert werden.
Workaround ist, beim ersten fragmentieren gleich auf 1280 herunterzubrechen (MTU-Size-Limbo)
Und ja, das ist ist sehr, sehr blöde und schlägt vorwiegend in Multi-Hop/MoL-Szenarien zu.
Stimmt, ich erinnere mich.
Aber ergibt es jetzt noch Sinn, die MTU für fastd so hoch wie möglich zu setzen?
Würde nicht die Batman Fragmet-Size von 1280 Byte plus einem fastd-Offset reichen?
Oder werfe ich da was durcheinander? Äpfel - Birnen ?