Moin,
in einer abendlichen Mumblerunde stellte sich uns die Frage wie viel mehr Performance wir denn aus unseren Routern bekommen könnten wenn wir zumindest dort wo es geht mit einer höheren MTU arbeiten.
Ein kurzer Test mit einem 1043er von TPlink mit Fichtenfirmware:
MTU 1280: 12 Mbit
MTU 1450: 20 Mbit
Nun die Idee:
wir fahren auf den Servern eine weitere Fastd Instanz mit der höheren MTU auf einem anderen Port und legen in der Site.conf je eine peergroup für die 1280er und die 1450er MTU an.
Auf den Routern läuft folgendes Script beim Start, testet die höhere MTU und bei Erfolg wird die 1280er group deaktiviert, die 1450er aktiviert und fastd einmal neugestartet. Ins flash schreiben wir nicht, denn es wird bei jedem Start die MTU erneut besttimmt.
#!/bin/ash
log="/tmp/automtu.log"
echo "$(date) Prüfe Internetverbindung" >> $log
if ping -I $(uci get network.mesh_wan.ifname) -W 60 185.66.195.242 | grep -q "time";
then echo "$(date) Internetverbindung vorhanden" >> $log && if uci get gluon-setup-mode.@setup_mode[0].enabled | grep -q "0";
then echo "$(date) Config Mode=off" >> $log && if uci show fastd.mesh_vpn.enabled | grep -q "1";
then echo "$(date) Fastd=on" >> $log && if traceroute -s $(ip -f inet address show $(uci get network.mesh_wan.ifname)| grep inet|cut -f 6 -d " "|cut -f 0 -d "/") -F -w 1 -m 20 -q 1 185.66.195.242 1450 | grep -q "forum.freifunk.net";
then echo "$(date) Setze MTU hoch" >> $log && uci set fastd.mesh_vpn.mtu=1450 && uci set fastd.mesh_vpn_backbone_1450.enabled=1 && uci set fastd.mesh_vpn_backbone_1280.enabled=0 && /etc/init.d/fastd restart;
fi;
fi;
fi;
fi
echo "$(date) Fertig" >> $log
Wir setzen das ganze an einer Hand voll Router in der Fichte testweise ein ohne große Probleme.
Anmerkungen:
Die URL/IP vom Forum sind nur Platzhalter
Nehmt nicht 8.8.8.8 bzw. google für den test denn die begrenzen die MTU bei 1406
Das Problem des Scriptes ist, dass der serienmäßige Ping der Busybox kein „dont fragment“ setzen kann.
Das kann nur das Traceroute. Daher der faktische Hack mit dem Traceroute (der ziemlich viel Laufzeit kostet)
Man könnte natürlich auch ein besseres Ping als Paket ins Gluon-Image mit hineinwerfen. Aber da der Platz cronisch knapp ist, möchte man das vielleicht vermeiden.
Und wenn schon was „externes“, dann vielleicht doch was natives, was den ganzen Job der MaxMTU-Ermittlung.
Gibt’s da was „fertiges“ für OpenWRT?
Ja, das mit dem BusyBox Ping ist mir auch schon aufgestossen.
Merkwürdig ist nur, dass es selbst mit einem „-F“ im Traceroute bei mir mit meinem Telekom-DSL irgendwie nicht so funktioniert wie es sollte.
Soll heissen:
Bei mir würde das Skript immer auf MTU=1450 umstellen.
In meinem Fall (Telekom-DSL) kein Problem. Aber was ist wenn ich kein Telekom-DSL hätte?
Könnte das evtl. mal jemand mit einem Cabel-Modem / einer Cabel-Fritzbox o.ä. versuchen?
Also,
das Script ist nur für die Tools auf dem Gluon gedacht und getestet. Wir habe keine probleme mit Batman, aber wir ändern ja auch nur die Fastd MTU.
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.