L2TP/Tunneldigger Serverdoku-Thread

kommt wenn ich zeit habe aber ich glaube denen ist das bewusst der change ist nicht so alt :slight_smile:

Ich glaube nicht. Auf deren Mailingliste wird nämlich ein anderes GSOC-Projekt (eine Art Monitor-System) fleißig dokumentiert. Bzgl. V6 habe ich noch nichts gelesen. Ich glaube, es ist niemand gefunden worden, der das übernimmt.

Ah ok habe nur die Issue steht wo steht das es angenommen wurde als Projekt :slight_smile:

Kann ich auch bestätigen.
Eine Idee oder sogar Lösung für das Problem hat nicht zufällig schon jemand gefunden?

Aug 03 13:57:09 handle kernel: python[6889]: segfault at 2743d8c0 ip 00007f1d5659f753 sp 00007ffc89c8b408 error 6 in libnetfilter_conntrack.so.3.6.0[7f1d56597000+1c000]

Gruß Marius

hi

ein Kollege hat die komplette(?) conntrack.py neu geschrieben. Scheint zu laufen die CPU Last ist aber relativ hoch allerdings nicht ganz so schlimm, wie wenn man den neuesten Tunneldigger nimmt.

Es läuft aktuell mit dieser Version:

https://wiki.freifunk-franken.de/w/L2TP_und_Tunneldigger#Installation:

und folgender ersetzter conntrack.py

https://zerobin.fff.community/?25c36b119163da93#S+BESoSUXIg04YlVNQoqrHWK2+htaDTNQbu92CU3JSc=

Es sind ~240 Tunnel offen auf ca. 20 Bridges (mehrere getrennte Batmannetze), es ist eine VM auf einen Xeon E5 mit 8 Kerne die damit ganz gut zu tun haben. loadavg bei 2-3 und es sind durchaus einige Zeit ein paar Kerne bei 100%. Nicht schön aber seit gestern läuft es erstmal und ist auch nutzbar.

Kollege wünscht sich (da er auch nicht gerade der absolute Python Crack ist) das gerne mal weitere Leute über den Code gucken, wer also versteht was das Ding tut und Verbesserungsvorschläge hat, immer raus damit.

mfg

Christian

1 Like

Vor ein paar Tagen wurde BatmanAdv2017.2 released.
Nach einem Kernelupdate plus Update von Batman auf diese Version konnten sich nur noch 2 Clients mit Tunneln verbinden.
Ein „Debug auf die Schnelle“ war erfolglos. Der alte Batman ließ sich auch nimmer compilieren, da nicht mehr mit aktuellen Kerneln kompatibel. Daher war dann ein Restore fällig.
Auf einem zweiten Supernode genau das gleiche Szenario.
Mag ein lokales Problem gewesen sein, ich möchte an dieser Stelle nur warnen und vor ähnlichen Versuchen dazu raten, evtl. nicht nur ein Backup, sondern auch einen Snapshot zu machen.

P.S. es scheint nicht der Batman zu sein, sondern der Kernel.
Der 4.11.0-13 liefert nur 2-3 Tunnel sichtbar im Batman „via Bridge“, gleiher host gebootet mit Kernel 4.10.0-26: Läuft korrekt.

1 Like

@adorfer Ich hatte zuletzt kurz 4.12 getestet, da ging dann auf einmal nichts mehr. Das deckt sich also mit deiner Erfahrung. @descilla hat das glaube ich auch bereits vor einigen Wochen beobachtet.

Wäre ja nicht schlecht, wenn ihr das hier (oder meinetwegen im Git als Issue) melden würdet.

Aber gut, selbst gemachte Erfahrungen sind auch was wert.
Dem einen oder anderem Client hätte ich vielleicht doch gern den Ausfall erspart.


Und wie bekommen wir die Kuh nun vom Eis? Wie debugt man das?

9 Beiträge wurden in ein neues Thema verschoben: Tunndeldigger - Durchsatzprobleme ab 300 Knoten

hi

mit der von mir oben genannten conntrack.py funktioniert es jetzt unter Debian 9 wunderbar. Man musste die Kiste nur nochmal neu starten, dann ging die CPU Last auch gegen 0 zurück :slight_smile: vllt. hing da noch irgendwas fest oder so, kann ich jetzt nachträglich nicht mehr sagen :frowning:

Es laufen jetzt auf der VM wo 8 Kerne von 2x Xeon E5620 (glaub ich) drauf geschaltet sind, 10 Tunnelbroker Instanzen (verschiedene Batmannetze) mit insgesamt 247 Tunnels. Last vom Tunnelbroker ist gegen 0 Load ist unter 1 meist bei ca. 0.6. Sieht sehr hübsch jetzt aus :slight_smile:

mfg

Christian

1 Like

Wir haben jetzt auch das Problem mit Debian 9 (Stretch). Leider ist das Pastebin mit der conntrack.py oben tot. Hat die jemand in git oder so? Wieso ist das noch nicht auf https://github.com/ffrl/tunneldigger gelandet?

hi

https://github.com/rohammer/fff-tunneldigger-debian_9

da müsste die conntrack.py von zerobinlink oben drinnen sein, einfach raus ziehen. Achtung das Git ist auf unsere config angepasst, am besten wirklich nur die conntrack.py raus ziehen.

mfg

Christian

@ChrisD Super, danke :slight_smile:

Ist eigentlich der upstream-tunneldigger https://github.com/wlanslovenija/tunneldigger/releases/tag/v0.3.0 kompatibel mit dem Client in Gluon?

Als ich den zuletzt getestet habe, hatte der Stabilitätsprobleme, aber kompatibel sollte er sein.

Grüße
Matthias

Ich bekomme ihn aktuell nicht mal gestartet. Die Doku ist veraltet (erwähnt z.B. eine Datei broker/requirements.txt die es nicht mehr gibt), und Bugs kann man auch nicht berichten (Registrierung im Bugtracker erfolgreich, aber Login geht mit diesem Account nicht; ich hatte deswegen Ende letzten Jahres schon mal nachgefragt aber bislang keine Antwort bekommen).

Ich bleibe dann wohl erstmal bei einem Fork.

Hallo, vielleicht hilft euch L2TP und Tunneldigger – Freifunk Franken ein bisschen weiter, so läuft l2tp bei uns

Mit dem alten Setup + @ChrisD s conntrack.py läufts leider auch nicht richtig. Es sieht so aus als ob, sobald die 2. Verbindung aufgebaut wird, die erste abbricht.

Das Verbindungsproblem konnte ich noch nicht beheben… aber immerhin habe ich die Ursache der SEGFAULTs gefunden. Das Problem besteht darin, dass tunneldigger hier die Python ctypes Bibliothek verwendet. Und wenn man nicht aufpasst, dann rundet die Pointer auf 32bit runter. Auf Debian Jessie geht das offenbar weil höhere Adressen nicht verwendet werden, auf auf Stretch werden sie verwendet und deshalb fliegt alles in die Luft.

Der Fix sieht wie folgt aus:

3 Likes

Ich habe jetzt immerhin herausgefunden, warum er nur einen Tunnel anlegen kann. Aber das wirft dann die Frage auf, warum das jemals geklappt hat…

Wie sich rausstellt, kann man mit tcpdump netfilter-Pakete abfangen. Damit konnte ich dann sehen, dass tatsächlich eine der Netfilter-Queries vom Tunneldigger schief geht. Eigentlich hat Tunneldigger Code, um solche Fehler zu erkennen und zu melden, aber der hatte einen Bug. Folgender Commit behebt den Fehler in der Fehlererkennung:

Damit sehe ich jetzt immerhin, dass das Erstellen einer L2TP-Session im schon aufgebauten L2TP-Tunnel schief geht. Fehler: EEXIST. Offenbar ist der Kernel der Meinung, die session ID würde schon verwendet. Nun, die session ID ist immer 1 (das ist im Client sogar hard-coded), aber das sind ja sessions in verschiedenen Tunneln. Ich habe lange gesucht und durch den Kernel-Quelltext geschaut, um herauszufinden, ob session IDs jetzt global oder pro Tunnel eindeutig sein müssen – und schließlich folgenden Kommentar im Kernel gefunden:

	/* In L2TPv3, session_ids are unique over all tunnels and we
	 * sometimes need to look them up before we know the
	 * tunnel.
	 */

Der Kommentar existiert in v4.12 nicht mehr, weil die ganze Funktion entfernt wurde – aber das muss ja nicht heißen, dass er nicht mehr gültig ist. Es gibt immer noch Code, der eine globale Liste aller Sessions verwaltet.

Wenn das richtig ist, dass die session IDs global eindeutig sein müssen, dann wären auch Änderungen am Client nötig – schließlich muss jedes Ende des L2TP-Tunnels die session ID der anderen Seite kennen.

Was mich gerade am meisten wundert, ist, dass das ganze früher überhaupt geklappt hat. Gab es einen Bug im Kernel, sodass doppelte session IDs akzeptiert wurden? Oder was ist hier los? Und wenn das bei euch alles klappt – welche Kernel-Version verwendet ihr? Ich habe 4.9 und 4.12 probiert und mit beiden das gleiche Problem.

EDIT: Aha! Im alten Kernel gab es zwar die Liste auch schon, aber er hat nicht geprüft, ob da Einträge doppelt drin sind. Und mit Version v4.9.36 landete dann folgender Commit:

https://github.com/linux-stable/linux-stable/commit/d9face6fc62a73059f0fc3a3de4dfe8f53536aa7

und seit dem werden die IDs korrekt geprüft. Und vermutlich habt ihr alle euer Debian 9 installiert bevor v4.9.36 in Debian ankam? Das würde dann alles erklären – aber das Problem nicht lösen.

5 Likes

Vielen, vielen Dank, dass Du den Bug zur Strecke gebracht hast.
Ich habe seit Monaten Bauchschmerzen, dass ich auf alten Kerneln auf den l2tp-VMs festgenagelt bin…