FF3L-AP hinter Fiber7 und Turris Omnia: Wahrscheinlich falsche MTU in /etc/config/fastd - aber warum?

[David Lutz]

Hi Axel!

In der Tat habe ich in der neuesten Firmware (2017.1.2+001) die MTU im
fastd-Tunnel gesenkt, da der ursprüngliche Wert von 1426 in manchen
Fällen einfach zu hoch ist.

Die Überlegung war damals: Ein normales Ethernet-Frame hat maximal 1500
Bytes. Bei einer eventuellen PPPoE-Verbindung fallen 8 Bytes weg,
bleiben 1492. 14 Bytes entfallen auf den Ethernet Header, bleiben 1478.
20 Bytes für den IPv4-Header: 1458. fastd läuft über UDP, also fallen 8
Bytes UDP-Header und 24 Bytes fastd-Header weg. Bleiben also 1426 Bytes.

Wenn nun irgendetwas nicht optimal läuft, weil zum Beispiel bei DS-Lite
das IPv4-Paket in ein IPv6-Paket gepackt wird, oder die Verbindung nicht
per IPv4 sondern per IPv6 aufgebaut wird, zieht das Fragmentierung nach
sich. Und da die Knoten eh schon mit Ver- und Entschlüsselung des VPN
beschäftigt sind bremst das ziemlich.
Zusätzlich filtern wohl manche Kabelmodems die "Packet size too large"
ICMP-Pakete, so dass die Fragmentierung nicht erfolgt und die Pakete
einfach verworfen werden.

Um nun zu verhindern, dass Pakete via IPv6 fragmentiert werden, war die
Überlegung, die MTU des fastd-Tunnels zu reduzieren, damit die
entstehenden Pakete nicht fragmentiert werden müssen.

Da fastd aber nur eine Verbindung aufbaut wenn beide Enden des Tunnels
mit der gleichen MTU konfiguriert sind, haben wir nun auf einem der
Gateways die MTU gesenkt auf 1398.

Mit der 2017.1.2+001 ist es also normal, dass bei allen anderen Gateways
ein Fehler wegen unterschiedlicher MTU angezeigt wird, allerdings
wundert es mich in der Tat, dass der Knoten sich nicht mit Gateway 9
verbinden möchte...

Ich denke es wird Zeit, die Firmware vollends auszurollen, so dass wir
die MTU auf den restlichen Gateways auch noch umstellen können. Momentan
erhält man die neue Firmware nur über den Downloader oder auf dem
experimental-Updatezweig.

Die Firmware ist unabhängig vom Updatezweig identisch. Der einzige
Unterschied zwischen der stable und der experimental ist, dass der
Defaultwert des Autoupdaters jeweils auf "stable" oder "experimental"
steht, und die Experimental auch für Routermodelle gebaut wird die noch
als "BROKEN" geflaggt sind. Die Stable und die IPv6 wiederum
unterscheiden sich nur darin, dass die fastd-Verbindung einmal per IPv4
und einmal per IPv6 aufgebaut wird.

Liebe Grüße

David

P.S.

https://lists.ff3l.net/pipermail/ff3l/2017-April/000445.html #chfreewifi ;)

Gruß, David

Am 28.08.2017 um 10:59 schrieb Axel Beckert:
> Moin.
>
> Schon wieder ich. :-)
>
> On Mon, Aug 28, 2017 at 12:37:32AM +0200, Axel Beckert wrote:
> [MTU-Probleme]
>> Grade im Mailinglisten-Archiv diese Mail gefunden:
>> https://lists.ff3l.net/pipermail/ff3l/2017-August/000594.html
> Nach der Mail kam mir dann noch, dass ich ja zum initialen Aufsetzen
> die selbe Datei wie für meinen ersten FF-AP das Wochenende zuvor
> benutzt habe. Also mindestens eine Woche alt. Deswegen habe ich grade
> nochmal nachgesehen, ob ich eventuell eine mittlerweile veraltete
> Version installiert habe. Dem ist aber nicht so: Alle meine Router
> habe ich mit Version v2017.1.2+001, also der "neuen" Version
> installiert.
>
> Konkrete Dateiliste:
>
> Tat out-of-the-box in Lauchringen hinter Unitymedia DS-Lite:
>
> gluon-ff3l-wtk-v2017.1.2+001-tp-link-tl-wr1043n-nd-v4.bin (ipv6)
>
> Tat out-of-the-box nicht in Zürich hinter Fiber7:
>
> gluon-ff3l-v2017.1.2+001-tp-link-tl-wr1043n-nd-v4.bin (ipv6)
> gluon-ff3l-v2017.1.2+001-tp-link-tl-wr1043n-nd-v4-sysupgrade.bin (stable)
>
> Nebenbei: Gibt es einen Grund, warum nicht auch noch der Branch
> (stable, beta, experimental, testing, ipv6) im Dateinamen vorkommt?
> Oder werden die fertigen Images dann einfach zum Release ein
> Verzeichnis weitergeschoben und nicht nochmal neu gebaut?
>
> 		Gruss, Axel