Multi MTU script

Unity Media:
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 2345

traceroute to 185.66.195.242 (185.66.195.242) from 192.168.168.25, 20 hops max, 2345 byte packets
1 192.168.168.253 (192.168.168.253) 0.864 ms
2 10.128.128.1 (10.128.128.1) 7.173 ms
3 1313a-mx960-01-ae13-1030.aah.unity-media.net (81.210.130.25) 6.512 ms
4 84.116.196.174 (84.116.196.174) 16.779 ms
5 84.116.196.178 (84.116.196.178) 20.263 ms
6 de-fra03b-ri1-ae5-0.aorta.net (84.116.133.118) 14.536 ms
7 ge0-0-3-br2.frankfurt1.iphh.net (80.81.192.27) 14.722 ms
8 te5-12-br1.hamburg2.iphh.net (213.128.159.217) 27.069 ms
9 te4-4-cr1.hamburg2.iphh.net (213.128.158.38) 26.113 ms
10 wende0.hamburg.freifunk.net (213.128.138.162) 24.815 ms
11 vlan3405.eth4.bb-a.ak.ber.de.ffrl.de (185.66.192.146) 31.070 ms
12 forum.freifunk.net (185.66.195.242) 27.087 ms

1 Like

kannst Du mal in einem openwrt ein „richtiges“ Ping installieren und damit testen?

Eventuell bekäme man ja durchaus einen dreckigen Hack für die Busybox als Patch hin, ohne gleich das ganze Ping-Paket zu nehmen.

Hast Du evtl. einen Namen des zu installierenden Packages?
Ach ja, Speicherprobleme habe ich auch noch → WR841N.

Ich nutze Gluon auf einem WR841N.

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.

Zu finden gibt es es als Gluon-Package hier:
Gesamt-Package → https://github.com/freifunk-ffm/packages/tree/master/ffffm/ffffm-fastd-auto-mtu
Skript → https://github.com/freifunk-ffm/packages/blob/master/ffffm/ffffm-fastd-auto-mtu/files/lib/gluon/fastd-auto-mtu/automtu.lua

ToDo:

  • Angepasst werden könnte noch der optimale rc.d Aufrufzeitpunkt (z.Z. S99)
  • Ebenfalls sind die variablen MTU-Grössen noch hartcodiert, also nicht einfach parametrisierbar ( z.B. über die site.conf).
  • Auch wenn der Konfig-Mod aktiv ist, wird versucht die UpLink-MTU-Frame-Size zu ermitteln.
5 Likes

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'

  • „Schön machen“ ist noch angesagt Edit: Erledigt

Code Reviews are welcome!

2 Likes

Like für die deutsche Readme!

Ich würde es mal nach dem Lan-Start machen. Also „nach 20, vor 50“… für fqdn-Auflösung wird aber vermutlich der dnsmasq gebraucht, also nach S60.

Habe gerade mal etwas getestet.

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.

1 Like

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)

1 Like

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.

Anpassungen siehe Github:

1 Like

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 Like

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 Like

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 :smile:

3 Likes

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.)