L2TP/Tunneldigger Serverdoku-Thread

Seltsam, bei mir klappt das ganze aber mit der MTU. Evlt ist das von Gerät zu Gerät unterschiedlich? Ich habe einen TP-Link TL-WR841N/ND v3

20: mesh-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1364 qdisc fq_codel master bat0 state UNKNOWN qlen 1000
    link/ether fa:70:2b:bb:0d:8f brd ff:ff:ff:ff:ff:ff

Das MTU-Problem (also dass die MTU auf den Knoten nicht die in der site.conf ist) konnte ich wie gesagt via https://github.com/wlanslovenija/tunneldigger/pull/67 lösen. Der Gluon-Client hat keinerlei Änderungen bzgl. automatischer MTU-discovery, aber wenn der Server sich weigert, mitzuspielen, dann passiert da nix.

2 „Gefällt mir“

Magst Du nochmal zusammenfassen, welches der Migrationsweg ist, um von einer „alten“ (mit unique-TunnelID-Bug behafteten) Version auf Plasteroutern und Servern zu der gefixten zu kommen?
Und welche Anpassungen müssen/können für „AutoMTU“ dabei parallel noch (zwingend/optional?) gemacht werden?

Also bitte die Reihenfolge von „welches Gluon-Paket zuerst“, was „dann“ auf den Servern? Muss auf letzteren (außer "ab jetzt kann ein aktueller Linux-Kernel gefahren werden) noch was anderes getan werden?

Die Reihenfolge (Server/Client) ist egal, da die neuen Versionen jeweils mit den alten kompatibel sind. Wir haben aktuell auf allen Gateways den neuen Server, läuft super. Außerdem haben wir eine Beta-Firmware mit dem neuen Client. Die würde sich auch mit alten Servern noch verbinden können. Eines der Gateways hat einen neuen Kernel mit dem „Problem“; auf diesem Gateway landen dann automatisch (wie unten beschrieben) nur die Clients, die unsere Beta-Firmware nutzen. Natürlich werden wir noch mindestens ein Gateway mit altem Kernel betreiben müssen, bis es keine Knoten mit altem Client mehr gibt, das wird also noch eine Weile dauern.


Auf Serverseite muss an der Konfiguration gedreht werden. In der Beispiel-Konfig siehst du, welche Optionen überhaupt noch relevant sind. Wichtige neue Optionen, wo du auch eventuell vom Default abweichen willst, sind connection_rate_limit=0 (das deaktiviert rate-limiting von neuen Verbindungen) und pmtu=1406 (also wir nehmen da 1406 und keine auto-discovery, genau wie mit dem alten Server auch). Außerdem ist noch zu beachten, dass die hooks jetzt asynchron sind – sprich, pre-down ist eher witzlos geworden, da das Interface abgeschaltet wird während das Script nocht läuft. Wir haben unseren hook auf down geändert. Ein Entfernen des Tunnelinterface von der Bridge ist ohnehin nicht notwendig; wenn der Tunnel gelöscht wird, geschieht das automatisch.

Der Server erkennt automatisch, wenn der Kernel wegen „duplicate session ID“ meckert. Sobald das der Fall ist, bekommen alte Clients, die keinen Support für „unique session ID“ ankündigen, gesagt, der Server sei voll. Wenn ihr also lastbasierte Serverauswahl macht, sollten solche Clients dann automatisch andere Broker nehmen, bei denen keine „unqiue session ID“ nötig ist. Beachtet jedoch, dass es in alten Clients (inkl. dem im aktuellen Gluon) einen (inzwischen korrigierten) Bug gibt, sodass der Client sich mit dem ersten Server zu verbinden versucht, wenn er von keinem eine Antwort bekommt – es macht also Sinn, den als letztes auf einen neuen Kernel zu aktualisieren.


Auf Clientseite nutzen wir in unserer aktuellen Beta-Firmware unser eigenes tunneldigger-Paket. Das ist der aktuelle master von wlanslovenija, plus https://github.com/wlanslovenija/tunneldigger/pull/66. Nachdem dieser PR akzeptiert wurde, will ich einen PR an Gluon schicken, der den Client dort aktualisiert. Der PR hat mit „unique session IDs“ nichts zu tun, ihr könnt also gerne statt dessen wlanslovenija master verwenden.

1 „Gefällt mir“

Das ist gut, ich dachte nämlich bislang, dass zunächst zwingend sämtliche Clients (Plasterouter) geupdated werden müssen.

Das verstehe ich nicht.
Wie verbinden sich diese alten Clients dann? Ist das mit dem „vollen Server“ ein Hack, damit die dann seitens des Clients doch eine höhere ID auswürfeln?

Da finde ich leider den v2016.2.x-Releasetag nicht.

Was muss genau mit den down-hooks gemacht werden, wenn die jetzt beachtet werden?

Sorry, vielleicht habe ich auch zu viele Dinge aufeinmal gefragt.

Kannst Du evtl. nochmal die Reihenfolge der notwendigen Änderungen herunterbrechen in einen klaren Ablauf?

Meine Aussage bezieht sich auf die neue Version des tunneldigger-Brokers, also des Servers! Den kann man auch mit alten Knoten deployen. Man muss jedoch erstmal auf dem alten Kernel bleiben, zumindest bei einem Gateway:

Alter Knoten, alter (Tunneldigger-)Server, neuer (Server-)Kernel: Kaputt.
Alter Knoten, neuer (Tunneldigger-)Server, neuer (Server-)Kernel: Kaputt.
Neuer Knoten, alter (Tunneldigger-)Server, neuer (Server-)Kernel: Kaputt.

Alter Knoten, neuer (Tunneldigger-)Server, alter (Server-)Kernel: Alles gut.
Neuer Knoten, alter (Tunneldigger-)Server, alter (Server-)Kernel: Alles gut.
Neuer Knoten, neuer (Tunneldigger-)Server, alter (Server-)Kernel: Alles gut.
Neuer Knoten, neuer (Tunneldigger-)Server, neuer (Server-)Kernel: Alles gut.

Nein. Die ID steht fest auf 1, da gibt es nichts dran zu drehen.
Es ist ein Hack, damit die alten Clients sich nicht verbinden. Sie denken, die „zu neuen“ Server sind voll, und nehmen daher andere.

Die Idee ist die: Wir wollen den neuen Kernel schon auf manchen unserer Gateways verwenden (auch um zu sehen, ob das klappt), während jedoch gleichzeitig noch alte Knoten unterwegs sind. Wie verhindert man jetzt, dass die alten Knoten sich mit dem Gateway verbinden, das den neuen Kernel verwendet? Man macht sich zu Nutze, dass die Knoten erstmal bei allen Gateways die Last abfragen, und sich dann mit dem verbinden, der am wenigsten belastet ist. Wenn als Gateways mit neuen Kerneln gegenüber alten Knoten so tun, als wären sie voll, dann gegen die alten Knoten woanders hin (solange es ein „woanders“ gibt, solange also nicht alle Gateways neue Kernel haben).

Das geht, weil die Clients, wenn sie den Server fragen, wie voll sie in, auch ein paar Flags mitschicken. Der Server sieht also, ob der Client „unique session IDs“ kann, und ändert eine Antwort auf die Frage „Wie voll bist du?“ entsprechend.

Ah, ja, wir sind auf v2017.1.x.

Das hängt davon ab, was eure pre-down hooks tun. Unsere haben zwei Dinge getan: Den Tunnel aus der Bridge nehmen, und was ins Log schreiben. Ersteres ist nicht nötig. Zweiteres geht auch wunderbar im down Hook. Da kann man leider keine allgemeine Anleitung geben, das hängt von eurer Konfiguration ab.

Wie gesagt, die Reihenfolge ist unerheblich. Ihr braucht neue Tunneldigger-Serversoftware auf euren GWs und neue Tunneldigger-Clientsoftware auf euren Knoten. Sobald ihr neue Tunneldigger-Serversoftware auf euren GWs habt, könnt ihr auf einzelnen GWs auch den Kernel aktualisieren – aber auf diesen GWs können sich dann nur Knoten mit dem neuen Client verbinden!

Beim Server hängt das Update davon ab, wie genau euer Setup vorher aussah – bei uns wurde einfach nur das git-Repo ausgetauscht (statt vom FFRL ziehen wir jetzt von wlanslovenija bzw. von unserem Fork davon), und die beschriebenen Änderungen an der Server-Konfiguration (l2tp_broker.cfg) durchgeführt.

Beim Client ist keine neue Konfiguration nötig. Man muss „nur“ Gluon dazu bringen, den Tunneldigger-Client in einer anderen Version zu ziehen. Wir haben das für die von uns verwendete Gluon-Version gemacht. Ist aber nicht schwer, wenn du unser Paket mal mit dem Original diffst, kannst du das sicher mit dem 2016er genau so machen. Oder, besser, Gluon aktualisieren. :wink:

1 „Gefällt mir“

Was passiert denn bei Folgendem:
„Neuer Knoten, alter (Tunneldigger-)Server, neuer (Server-)Kernel“

(ich erkenne gerade nicht, was sich am Server geändert hat. Mag aber sein, dass ich die Serverdoku (bzw den Migrationspfad) nicht so recht nachvollziehen kann serverseitig. )

Habe ich gerade rein-editiert. Das ist kaputt. Wenn der Kernel neu ist, müssen Knoten und Broker/Server neu sein. Dies ist die einzige Einschränkung.

Siehe alle Änderungen im Ordner broker auf Unique session ids by RalfJung · Pull Request #64 · wlanslovenija/tunneldigger · GitHub

Gibt es zu Eurem Tunneldigger-Server-Broker eine Installationsanweisung?
(Ich mag mich wirklich nicht durch git-Commit durchhangeln, wenn mir Sätze unklar sind wie
„once we get a duplicate session ID failure, pretend to clients not supporting unique session IDs that we are full“)
Ich vermute zwar nun nach Deiner obigen Erklärung, das verstanden zu haben. Aber es sind leider mehrerer weitere.
Installationsanweisungen aus diffs von Forks abzuleiten: Kan man tun. Aber dann muss das leider jeder tun.

Ich finde es wirklich toll, dass Du Dich des Problems angenommen hast und einen Fix lieferst.
Nur zumindest derzeit habe ich -und damit bin ich vermutlich nicht der einzige- Probleme, das inhaltlich nachzuvollziehen, da ich die Implikationen des geänderten MTU-Handlings „für den Rest des Server-Setups“ nicht abzuschätzen vermag. (Was am radvd tun, was am dhcpd, implikationen für die parallel im gleichen L2 laufenden fastd-Knoten mit niedriger MTU?)
Warum kein PR auf das original-Repository plus Update der Installationsanweisung dort?

Das ist doch das Original-Repository, und da habe ich auch den PR hin gesendet? Die Anleitung unter https://tunneldigger.readthedocs.io/en/latest/server.html sollte aktuell sein; wenn nicht, bitte einen Bugreport erstellen. :slight_smile:

Das MTU-Setup muss sich nicht ändern. Wenn ihr vorher auto-MTU verwendet habt, sollte das weiterhin klappen – vermute ich, da ich leider nicht ganz verstehe, warum/wie das überhaupt je geklappt hat. :wink: Testen konnte ich natürlich nur, was wir verwenden, und das war vorher und ist jetzt eine feste MTU von 1406.

Es muss sich also noch jemand finden, der die neuen Versionen mal mit auto-MTU ausprobiert, in einem Kontext, wo auto-MTU vorher ging – idealerweise jemand, der weiß, wie man sowas vernünftig testet. Da bin ich nämlich raus.

Zumindest finde ich da nichts zu den Hook-Scripts, wie das jetzt mit dem Logging funktioniert, das Du oben angesprochen hattest beim Pre-Down.

Ja, dass dort Logging passiert war unsere eigene Config. Die haben wir damals zusammenkopiert von diversen Tutorials für „l2tp und Freifunk“ – ich weiß ehrlich gesagt nicht mehr, welche das waren (und einige der Links, auf die ich damals Lesezeichen gesetzt habe, sind tot). Diese Tutorials kann ich nicht aktualisieren, die werden von den jeweiligen Communities gepflegt.

Wenn ihr kein Logging habt im pre-down, ist das auch okay. Es geht nur darum, dass du dir anschauen solltest, was ihr im pre-down habt, und dann entscheiden, ob das okay ist, das statt dessen im down-Hook zu machen. Da ich nicht hellsehen kann, weiß ich nicht, was bei euch im pre-down passiert :slight_smile: Vielleicht habt ihr auch gar keinen pre-down Hook? Falls ja, umso besser, dann kann der schonmal keine Probleme mehr machen.

Ich kann ja schlecht für jede Konfiguration, die irgendeine Freifunk-Community sich mal anhand irgendwelcher Tutorials zusammenkopiert hat, exakte Anleitungen bieten. Da gehe ich dann schon davon aus, dass jeder so viel Überblick über sein eigenes Setup hat, dass er generelle Tunneldigger-Anleitungen (die z.B. erklären, wie der Dienst jetzt gestartet wird – das hat sich auch geändert, was ich oben zu erwähnen vergaß) mit dem eigenen Setup in Einklang bringen kann. Dabei kommen u.U. konkrete Fragen auf, die ich gerne beantworte.

Was eventuell auch nützlich wäre, ist eine neue Freifunk-Tunneldigger-Anleitung für den neuen Broker. Also kein Anleitung für ein Update (da gibt es zu viele Unbekannte), sondern ein „wie setze ich das neu auf“. Sowas habe ich nicht geschrieben, da fehlt mit aktuell einfach die Zeit. „Eventuell“, weil es davon schon mehrere gibt – es wäre viel weniger Arbeit, eine der vorhandenen Anleitungen zu aktualisieren. Außerdem steht die Tunneldigger-Config natürlich nicht alleine im Raum, die muss ja passen zur Batman-Config und was man so für Bridges hat und so – also eigentlich braucht man da ein kohärentes Tutorial für ein komplettes Freifunk-GW samt passender Gluon-Config (Stichwort MTU), und dafür fehlt ganz sicher die Zeit. Sorry :confused:

1 „Gefällt mir“

Ralf, es wäre vielleicht hilfreich wenn die Changes und ihre Implikationen in der HISTORY.rst beschrieben wären.
Das mache ich eigentlich immer wenn ich neue Features committe. Siehe z.B. hier bei meinem letzten Change: Add cmake for client · wlanslovenija/tunneldigger@95e4229 · GitHub

Könnte es sein, dass die config

[log]
; Log filename
filename=tunneldigger-broker.log

nicht mehr dazu führt, dass logfiles produziert werden?

Korrekt.
Das müsste schon mit dem rewrite des brokers verloren gegangen sein (im Code werden Logs nur ins Syslog geschrieben). Das bedeutet also, dass euer Broker ca. von 2015 sein müsste (vor dem Rewrite).
Mit journalctl lässt sich das eigentlich ganz bequem ersetzen. Wer allerdings Dateibasierte Logfiles bevorzugt (ich bin mir sicher, da gibt es genügend Gründe), müsste darauf warten bis es wieder implementiert wurde bzw. (sofern dazu befähigt) es selbst implementieren.
Aus diesem Grunde wurde die o.g. Config-Direktive auch aus dem Beispiel-Configfile entfernt.

1 „Gefällt mir“

Gute Idee, den Changelog mal zu aktualisieren. :slight_smile: Werde die Tage einen PR vorbereiten. Da fehlen glaube ich auch noch Änderungen, die schon vor meinen PRs erfolgt sind; die kann ich dann auch gleich dokumentieren. Der von dir später erwähnte Broker-Rewrite brachte doch diverse Änderungen, die glaube ich nirgendwo alle schön aufgelistet werden. Manches fiel mir beim Portieren auf, aber ob die Liste vollständig ist?

Das Changelog-Update kommt unter

@adorfer ist das hilfreich? Der FFRL-Fork ist etwa auf Stand von v0.1.0.

Danke!

ich habe den Client gebaut im Makefile mit

PKG_REV:=404a3c9c0b5b0f0ab8ce4ae52aca09edf2ebcd77
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
PKG_SOURCE_URL:=git://github.com/wlanslovenija/tunneldigger.git

Trotzdem bekomme ich noch Client-Requests auf TunnelID1, obwohl da schon ein Dutzend Sessions mit dieser ID sind.

Dec 17 01:03:19 flingern-l start-broker.sh[1504]: [INFO/tunneldigger.hooks] Running hook 'session.up' via script '/srv/tunneldigger/scripts/session-up.sh 298 1 l2tp298-1 1364 109.90.117.191 54921 20298 30b5c28644ae'.

(Zumindest passt das gemäß Doku nicht. Irgendwas klemmt da:
<tunnel_id> <session_id> <endpoint_ip> <endpoint_port> <local_port>
Was übersehe ich?)
Ja, den Server habe ich auch vom aktuellen Master installiert von wlan-slovenija.

o.k. es lag an einem fehlenden make-clean im gluon-buil.
Wie ich sehe, hat das client-Paket von wlan-slovenija jetzt kein Makefile mehr.
Was muss ich denn tun, damit aus der cmakelist.txt ein makefile herausfällt beim normalen Gluon-Build für ChaosCalmer?