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. 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.
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 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
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
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.
Gute Idee, den Changelog mal zu aktualisieren. 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?
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?
als diff gegen das alte Paket-Makefile sieht das dann so aus:
EDIT: Das Forum schneidet leider den Anchor-Link ab. Aber du wirst die Commits schon finden, der PR ist so lang nicht
EDIT2: Aha, der Anchor verbirgt sich nur im grauen github.com Link.
Wie ist denn der aktuelle Stand, was installiert man wie seit Mitte 2018 für Gluon v2018-Clients, vorzugsweise auf Ubuntu 16.04 LTS (oder 18.04 LTS mit ifupdown)? Gibt’s Erfahrungen mit FFNWs puppet-Modul?
Ich schließe mich der Frage von @wusel an und würde auch gerne den aktuellen Stand erfahren. Der Verweis auf die Tunneldigger-Doku ist für mich nicht sonderlich hilfreich, da mir eine Übersicht des Gesamtzusammenhangs aus Kernelversion und Tunneldigger fehlt.
Konkret: welchen Tunneldigger muss ich wie auf Gateway und Knoten installieren, damit es funktioniert und abwärtskompatibel ist?
Mit welchen Kernel-Versionen wäre dieses Setup dann kompatibel?
Hat schon jemand erfolgreich ein Gateway mit Ubuntu 18.04 aufgesetzt?
Zugegeben, es ist nicht ganz einfach aus der commit ID in der git Lognachricht die genauen Kernelversionen zu ersehen, die den Fix haben. Daher hab ich das mal für dich besorgt:
Zu finden ist der Patch in allen Linux Kerneln ab:
Für den 3.2 LTS Zweig: 3.2.91
Für den 3.16 LTS Zweig: 3.16.46
Für den 4.9 LTS Zweig: 4.9.36
und alles ab 4.11
Diese Versionen sind inzwischen so alt, dass ich nicht mehr glaube, dass sie in irgendeiner aktuell unterstützten Distribution Anwendung finden.
Wir betreiben erfolgreich Gateways auf Fedora 28 und 29, die jeweils den Kernel 4.18.16 nutzen. Zu Ubuntu kann ich im Speziellen nichts sagen, sehe aber keinen Grund weshalb man damit nicht auch erfolgreich ein Gateway betreiben können sollte.
Bei der Vorbereitung der Migration stolpere ich grade über komische Effekte: Grundidee ist es, die br-mesh der fastd+v14- und tunneldigger+v15-Teilnetze per L2TP-Tunnel zu verbinden (oder VXLAN oder $l33tsh1t); das „alte“ Netz bekommt eine Hälfte des /20, das neue die andere, v6 geht wg. SLAAC kunterbunt durcheinander. Kopplung via Layer 2, alles schick, tut auch soweit. Problem 1:
Wohl weil der dhcpd auf br-mesh hängt, und br-mesh auf beiden Gateways (v14, v15) per l2tp-Tunnel gebridged sind, greift die batman-adv-interne Filterung nicht, jedenfalles landen DHCP-Anfragen aus dem v14-Netzsegment auch beim v15-dhcpd, der brav antwortet, was bißchen doof ist (Cross-Gateway-Traffic). ebtables to the rescue, jeweils:
Und auf beiden Seiten kommen nun keine DHCP-Pakete an.
Während Clients die neue Geschwindigkeit wohlwollend konsumieren, bleibt noch ein Wermutstropfen: Direkt am Gateway hängenden Knoten kann ich i. d. R. nicht per IP erreichen, wohl aber per Flattervogel
root@l2tp-gut02:~# ping6 -c 10 2001:bf7:1310:11:c6e9:84ff:fef9:a823
PING 2001:bf7:1310:11:c6e9:84ff:fef9:a823(2001:bf7:1310:11:c6e9:84ff:fef9:a823) 56 data bytes
From 2001:bf7:1310:11::12:2 icmp_seq=1 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=2 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=3 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=4 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=5 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=6 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=7 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=8 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=9 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=10 Destination unreachable: Address unreachable
--- 2001:bf7:1310:11:c6e9:84ff:fef9:a823 ping statistics ---
10 packets transmitted, 0 received, +10 errors, 100% packet loss, time 8999ms
root@l2tp-gut02:~# batctl-ffgt tr c4:e9:84:f9:a8:23
traceroute to c4:e9:84:f9:a8:23 (46:c6:64:6b:a4:db), 50 hops max, 20 byte packets
1: 46:c6:64:6b:a4:db 15.749 ms 17.958 ms 15.979 ms
Testen konnte ich natürlich nur, was wir verwenden, und das war vorher und ist jetzt eine feste MTU von 1406.
