Hallo,
habe etwas rumgebastelt und ein ordentliches ‚ping‘ installieren können.
Das OpenWrt Package dazu heisst ‚iputils-ping‘.
‚iputils-tracepath‘ wäre nochbesser, weil es die MTU-Frame-Size selbstständig ermittelt, es ist aber ein ‚nicht terminierendes‘ Programm. Die Verwendung war mir mit Shell-Scripten zu kompliziert.
Zur Zeit testen wir in ffm gerade ein Auto-MTU Lua-Skript.
Wir haben hier zwei fastd-Instanzen pro Supernode.
Port 10001 mit einer fastd-MTU von 1280 (default)
Port 10002 mit einer fastd-MTU von 1426
Das Skript wird jedesmal beim Booten über /etc/rc.d aufgerufen.
Es überprüft ganz stumpf am Ende des Boot-Prozesses, ob der UpLink ein Telekom-artiger DSL-Anschluss ist und damit eine MTU-Frame-Size von 1492 Byte hat. Wenn ja, dann wird hier eine fastd-MTU-Frame-Size von 1426 verwendet und ggf. fastd neu gestartet.
Fallback ist immer die kleinere, aber sichere fastd-MTU-Frame-Size von 1280 Byte.
Das ganze ist per uci abschaltbar.
Die Entwicklung des Packages fastd-auto-mtu ist noch nicht ganz abgeschlossen!
ToDo:
Heute habe ich festgestellt, dass mit meinem Futro-HW-Setup das
Auto-MTU-Skript beim Booten immer die kleinere Frame-Grösse
detektiert. Starte ich das Skript jedoch zur Laufzeit per SSH, so
wird eine große MTU immer sicher erkannt und auch auf diese
umgeschaltet.Edit: Erledigt
Es fehlt noch der optimale rc.d Boot-Ausführungszeitpunkt (z.Z. S99)Edit: S99 ist gut
Das Logging funktioniert m.M.n. auch noch nicht richtig.Edit: Funktioniert mit 'logread'
Wenn das Skript beim Booten aufgerufen wird, dann hat das Interface „br-wan“ beim meinem Futro (x86-generic Image) noch keine IPv4 Adresse per DHCP bezogen. Daher geht der Ping in’s Leere und die sichere kleine MTU-Grösse wird verwendet. Das Fallback funktioniert also auch hier :o)
Baue ich eine Verzögerung von 5 Sekunden ein, dann klappt alles.
Das ist wohl den x86-Treibern geschuldet und unterscheidet sich damit zu den von mir bisher getesteten Plaste-Routern.
Lösung:
→ Werde mal eine schöne 10-Sekunden-IPv4-Abfrageschleife erstellen.
Du könntest auch mit dem Start warten, bis Du überhaupt irgendwen auf dem WAN-Interface anpingen kannst (wenn kein Ping durchgeht auf dem fastd-server, dann nochmal 5s warten)
Da ich ein /etc/init.d/fastd restart in dem Skript verwende, sollte ich mindestens bis S95 warten. Dann ist alles für fastd vorbereitet und fastd wird erstmalig aufgerufen. (Obwohl auch dann br-wan noch garnicht fertig ist :o) )
Damit ich aber auf jeden Fall auf der sicheren Seite bin und nix verwurschtelt wird, bleibe ich erstmal bei S99.
P.S.
Einen zeitlichen Einfluss, auf die Benutzbarkeit des Routers, wird dieses sowieso nur max. einmal haben. Bleibt die MTU wie sie ist, wird ja auch fastd nicht neu gestartet.
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.
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.
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:
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.
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:
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
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.)
