Kompression macht fastd zwar nicht, aber die Verschlüsselung und Integritätsprüfung der Pakete könnte in der Tat einen Einfluss auf das Problem haben. 2 Dinge fallen mir ein, die potentiell eine Auswirkung haben könnten:
- fastd verwirft doppelte und extrem start reorderte Pakete (um mehr als 64 Sequenznummern), ich weiß nicht, wie das mit L2TP ist? Gibt es da auch Sequenznummern? Werden Reordering und Duplikate erkannt, wenn ja, wie behandelt? Ich habe schon DSL-Anschlüsse gesehen, bei denen der ISP für UDP absolut keine sinnvollen Flows definiert hat und jedes Paket intern anders geroutet wird, was zu ständigem Reordering führt
- Es gibt einige extrem kaputte DSL-Modems, die nicht nur im Header, sondern auch im Payload alles, was nach bekannten IP-Adressen aussieht, NATen. Unverschlüsselte Tunnel kann man da drüber vergessen.
Man könnte mal vergleichen mit anderen fastd-Methods:
- „null“: Keine Verschlüsselung, keine Integritätsprüfung, keine Erkennung von Reordering & Duplikaten
- „null+cipher-test“: Keine Verschlüsselung, keine Integritätsprüfung, aber Erkennung von Reordering & Duplikaten
- „null+salsa2012+umac“: Keine Verschlüsselung, aber Integritätsprüfung, Erkennung von Reordering & Duplikaten
(für cipher-test muss die Methode mit CONFIG_FASTD_ENABLE_METHOD_CIPHER_TEST=y in der include/config von Gluon aktiviert werden)
Wenn man den Log-Level von fastd auf ‚debug2‘ stellt, bekommt man auch ne Menge Ausgaben über Reordering und Duplikate, wenn vorhanden.