@MisterCrumble Meinst du l2tp oder tunneldigger? l2tp ist im Kernel, da nutzen ziemlich sicher alle das gleiche (es sei denn, jemand hat das mal mit macOS/Windows versucht). Andere tunneldigger-implementierungen (protokollkompatibel) außer den diversen Forks von wlanslovenija sind mir nicht bekannt. gluon nutzt den „original“-client von wlanslovenija – der tatsächlich einiges an diff hat zum dem beim FFRL.
Ganz ehrlich, da nehme ich einfach keine Rücksicht drauf. Ausgehende Portsperren sind 0er Jahre.
Wie wäre es, wenn man übergangsweise die neueren Kernel so patcht, dass sie sie die Session-ID ignorieren, also das Commit rückgängig macht? Dann alle Knoten aktualisieren, das sollte jetzt direkt im Upstream-Gluon passieren und dann kann man irgendwann, wenn alle Knoten die neue Firmware haben, den Patch auf den Gateways weglassen.
Eine Konfigurierbarkeit per site.conf wäre super. Soweit ich das verstanden habe, könnten Communities, die mehrere Batman-Domänen betreiben, dann zukünftig statt dem Einwahlport die Session-ID zur Differenzierung der Domänen verwenden. Das vereinfacht auch die Konfiguration. Wenn nur noch ein Port gebraucht wird, könnte man 443 verwenden. Das ermöglicht auch eine Verbindung durch verwaltete und kaputte Firewallkonfigurationen.
Die Session ID muss (pro Gateway) für jeden Client verschieden sein. Das ist ja gerade das Problem hier, dass sie das aktuell nicht. Statt der 1 jetzt einen anderen Wert in der site.conf festzulegen hilft uns keinen Meter weiter.
Ich sehe jetzt ganz ehrlich den Zusammenhang hier nicht?
Die Session ID dient dazu, über eine einzige UDP-Verbindung mehrere unabhängige Tunnel gleichzeitig aufzubauen. Damit könnte also dann u.U ein Knoten gleichzeitig in zwei verschiedenen Domänen am selben GW hängen, aber das ist ja wohl nicht, was du willst.
Natürlich könnte man den Client so erweitern, dass er dem Server noch irgendeine Form von ID mitteilt, die dann an den session-up-hook weitergereicht wird. Anhand dieser ID könnte der hook entscheiden, welcher Bridge (und damit welchem Batman) dieser Client hinzugefügt wird. Aber das ist völlig unabhängig von der Problematik der Sitzungs-IDs. Wenn wir jedoch hier eh am Tunneldigger-Protokol herumbasteln, könnte man diese ID auch schon mal hinzufügen.
Wir hatten bisher eigentlich vor, das Anhand der Ports zu machen, also einfach mehrere Tunneldigger laufen zu lassen. Was ist das Problem damit?
1 „Gefällt mir“
Ziel ist doch, einen Serverseite zu haben, die zumindest temporär sowohl „wie bisher“ als auch „korrekt“ als client verarbeiten kann.
Was ist denn das Problem des aktuellen Servers, dass der nicht mit gefixten Clients zurechtkommt?
- Die Session-ID darf derzeit identisch sein bei unterschiedlichen tunneln (
- Die Session-ID muss identisch sein mit dem was der Client nutzt
- Die Session-ID wird vom Client nicht übergeben
- Die Session-ID wird derzeit im Server immer als „0“ gesetzt.
Alles soweit korrekt?
Wenn 2 zutrifft, was passiert in diesem Fall beim Client? Was beim Server? Zombie-Verbindung? Fehlermeldung(en)?
Die ID ist immer „1“, nicht „0“.
Wenn der Server jetzt einfach anfängt, am Serverende die Tunnel ID auch als Session ID zu verwenden (hoffentlich geht das), der Client da aber weiterhin 1 setzt, dann werden die beiden Tunnelenden sich vermutlich einfach gegenseitig ignorieren. Es kommt ja nie was für die eingestellte Sitzung an.
Vermutlich ist der einfachste Fix der, ein CONTROL_TYPE_TUNNEL2 einzuführen, das von neuen Clients verwendet wird. Dann sieht der Server anhand der Information, ob CONTROL_TYPE_TUNNEL2 oder CONTROL_TYPE_TUNNEL verwendet wird, um welche Client-Version es sich handelt. Nach dem Kernelupdate auf Serverseite könnte sich dann immerhin pro Gateway ein alter Client verbinden – und dann hoffentlich das Update ziehen…
1 „Gefällt mir“
Wenn wir jetzt schon das Protokoll anfassen wollen dann könnten wir auch gleich implementieren, dass der Client sein gewünschtes Bandbreitenlimit mitteilt. Dann können wir den Egress auf dem Server in Richtung Node schon limitieren, was effektiver ist als dies auf dem Node zu tun.
Wer macht jetzt das neue Freifunk Upstream Repo auf? 
1 „Gefällt mir“
Die Frage wäre: Wer mag es generisch tun? Also nicht gleich wieder eine Default-Config mit Hood-Selector und anderen Pfeiffchen dran.
Also so, dass es zum „plain vanilla“ Gluon passt.
(Falls man es nicht in das Gluon-Repository nehmen mag)
Ich hätte für meine Wunschliste ein funktionsfähiges AutoMTU.
Zumindest so weit vorbereitet, dass man es später einfach Nachimplementieren kann, wenn der Client die Strecke „vorab“ vermisst. Oder der Server auch die Rückrichtung probed (gibt ja leider asymetrische MTU-sizes), bevor der L2TP-Tunnel dann final aufgebaut wird.
Danke für deine Erläuterungen, hatte es in der Tat noch nicht im Detail verstanden.
In der Theorie nichts, aber wenn man immer 443 nutzen könnte, würde man sich eine Menge Arbeit mit dämlich konfigurierten Firewalls sparen.
Die müssten tatsächlich wirklich dämlich konfiguriert sein. Wer alles abriegelt und dann 443 UDP durchlässt, Muss ein harter Verfechter des QUIC Protokolls sein.
2 „Gefällt mir“
Per Default lauscht der Tunneldigger auf 53.
Wobei ich vermute, dass die ParanoikerInnen auch das „transparent“ über den lokalen Proxy schicken… dnsmasq.
Zumindest der upstream (wlanslovenija) broker hat eine CONTROL_TYPE_LIMIT Nachricht, das gibt’s also offenbar schon.
Ich habe inzw. endlich jemanden bei denen erreicht, und die schauen mal, was mit ihrem Bugtracker los ist. Außerdem gibt es auf GitHub durchaus PRs (ich muss blind gewesen sein). Eventuell kann man also durchaus deren broker verwenden; deren Client nutzt gluon ja eh schon. Wenn wir jetzt am Protokoll basteln, wäre es irgendwie schade, dabei total vom Upstream wegzuforken (wie es ja wohl bei der „broker usage“ schon mal geschehen ist…).
Server und Client haben schon irgendeine Form vom MTU-discovery; wenn die nicht geht, müsste sie halt mal jemand korrigieren.
Ah stimmt hast recht. Ist auch noch UDP, dann ist es eh egal.
Zumindest im repository des ffrl sind die scripte alle auf „fixed1364“ ausgelegt. (wenn ich es recht erinnere…)
Das mag eine pragmatische Entscheidung sein, weil „schneller“ oder „stabiler“ oder schlicht „besser wenn für alle Clients gleich“. Oder eben weil ‚grundsätzlich broken‘)
Meine Vermutung ist aber, dass da irgendwas nicht so funktioniert wie es sollte und das man’s daher abgeschaltet hat.
Dann wäre zu prüfen, ob das reparierbar ist, ohne Rückwärtskompatibilität zu gefährden. Oder es nur reparierebar ist mit zusätzlichen Informationen im Handshake.
Die Leute von wlanslovenija haben den Issue tracker unter https://github.com/wlanslovenija/tunneldigger/ aktiviert 
. Außerdem habe ich auch schon erste Reaktionen auf meine Pull Requests dort bekommen. Sieht also recht gut aus m.E.; das könnte man durchaus als Upstream-Repo verwenden und seine Fixes da hin senden, damit auch alle was davon haben.
Sowohl Gluon als auch Freifunk Franken verwenden jetzt schon den aktuellen Client von wlanslovenija.
Einen unserer Server habe ich mal umgestellt auf den neuen Broker von wlanslovenija. Der wurde neu geschrieben, nutzt jetzt nicht mehr das grausige ctypes sondern eine ordentliche FFI-lib, und auch ansonsten hat der Code mehr Struktur. Allerdings habe ich aktuell noch Probleme mit einem FD-leak.
Ich habe außerdem angefangen mit dem Fix für das Session-ID-Problem, basierend auf dem aktuellen Server & Client von wlanslovenija. EDIT: Wer da den Fortschritt verfolgen will, kann das hier tun:
6 „Gefällt mir“
@ralfj, scheint als bist du unser neuer Tunneldigger-Flüsterer. 
Vielen Dank für deine Arbeit!
Hast du dich mal als Maintainer ins Spiel gebracht? Wäre eventuell cool, wenn das Upstreamrepo von mehreren Ecken aus gepflegt wird.
Das Problem ist eher dass die MTU discovery nach erstellen des Interfaces geschieht und dann das Interface angepasst wird.
Allerdings unterstützt batman-adv dies nicht und es führt zu Fehlern (größere Pakete werden stumm verworfen wenn die MTU vom Interface nach hinzufügen zu batX geändert wird). Klar könnte man jetzt für jede MTU eine Bridge erstellen aber dies ist eine unsaubere Lösung.
Die MTU-Aushandlung sollte teil des Verbindungsaufbaus sein damit diese sich nicht erst später ändert.
Daher arbeiten wir bei Gluon mit einer statischen MTU.
Das ist zumindest die Lösung, die ich in vielen Communities gesehen habe, die AutoMTU-Pakete fahren. Und ja, mir ist klar, dass man dann im schlimmsten Fall zur Laufzeit Tunnel in andere Bridges umhängen müsste und das das Paketverlust mit sich bringt. Aber das tun so viele andere Dinge auch die im Batman getan werden.
Trotdem empfinde ich die Lösung nicht als „unsauber“, sondern schlicht der Notwendigkeit geschuldet. (Und ja, man kann natürlich nicht für 500+ mögliche MTU-Werte jedeweils eine Bridge auf Vorrat anlegen, sondern wird sich -so wie bei den AutoMTU-Paketen auch- auf ein paar (4-5) gängige Werte beschränken und dann die ankommenden Verbindungen passend zuordnen.
(Dass das potentiell trotzdem problembehaftet ist, innerhalb einer Domain mehrere MTUs zu haben für „schlechte Clients“: Ohne Frage. Denn dann muss pmtu und mss-clamping auf Kernelbasis fnktionieren, man kann nicht nur stumpf per dhcp und radvd limbo-MTUs announcen. Aber gefühlt möchte ich inzwischen eigentlich „ordentlich implentierte IP-Stacks - und Gerte mit solchen“ eher belohnen als dafür bestrafen, dass andere sich nicht die Mühe machen.)
Auf der Server Seite ist das sicher kein Problem aber auf der Seite des Clients sehe ich das als problematisch mehrere Bridges anzulegen. Evtl kann man mit dem MTU change hook arbeiten so das erst nach MTU Aushandlung das Interface in bat0 gehangen wird aber das forciert dann die Nutzung von MTU Discovery weil es für alle Setups gleich sein sollte um keine Sonderfälle in die Gluon Pakete zu bauen.