L2TP/Tunneldigger Serverdoku-Thread


#21

Ich weiß ja nicht wo Du guckst, aber die Doku ist aktuell.

https://tunneldigger.readthedocs.io/en/latest/index.html

Btw. Der aktuelle “Rewrite” vom Tunneldigger performed extrem schlecht.
Sehr hohe CPU Load.

Gruß


#22

@Comacho dein link sagt in der anleitung sagt pip install -r tunneldigger/broker/requirements.txt das ist allerdings nicht mehr korrekt mit dem aktuellsten master. die requirements.txt existiert nicht.


#23

Wobei der running unten wieder korrekt ist :slight_smile:


#24

hi

gibt es dazu eine Lösung? Bisher war die Lösung eine alte Tunneldiggerversion zu verwenden. Problem dabei die läuft nicht unter Debian 9 weil wegen irgendein Kernelmodul (netconntrack oder so ähnlich, sry habs grad nicht ganz aufm Schirm) Speicherfehler um sich wirft und nicht startet.

mfg

Christian


#25

@mtrnord
Oh das habe ich auch nicht gesehen :smile:
Aber warum bist Du dann nicht so nett, und schickst ein PR, sodass
die Doku für alle wieder korrekt ist ?

@ChrisD
Nicht das ich wüsste, das mit Debian 9 ist mir auch neu.
Bei uns läuft der alte seit Ubuntu 14.04 ohne mukken,
aktuell auf Ubuntu 16.04 und mir ist kein vorteil gegenüber dem neuen bekannt.
Da Debian grundsätzlich ältere Pakete verwendet als Ubuntu,
fände ich das jetzt schon etwas komisch, das es nicht noch mehr aufgefallen ist.
Wenn du mal eine Fehlermeldung hast wo der Broker aussteigt,
könnte man mal schauen wodran es liegt.


#26

ich hab leider grad kein System wo er aktuell läuft, habs eben aus Backlogs aus einen Channel gezogen:

root@:/home/# /srv/tunneldigger/env_tunneldigger/bin/python /srv/tunneldigger/tunneldigger/broker/l2tp_broker.py /srv/tunneldigger/tunneldigger/broker/ficht-broker.cfg
Speicherzugriffsfehler

und aus dmesg;

root@:/home/#[287591.857996] python[24138]: segfault at ffffffffa019a590 ip 00007ff9a861c753 sp 00007fff00a934a8 error 7 in libnetfilter_conntrack.so.3.6.0[7ff9a8614000+1c000]
[287691.691838] python[24448]: segfault at 194af590 ip 00007f26018e6753 sp 00007fff885276f8 error 6 in libnetfilter_conntrack.so.3.6.0[7f26018de000+1c000]

Konnten Kollegen auf weiteren Debian 9 Server nachvollziehen, scheint daher erstmal kein Einzelfall zu sein.

mfg

Christian


#27

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


#28

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.


#29

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


#30

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


#31

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


#32

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.


Kein Internet im RG-West
[Anleitung] Gateway aufsetzen mit Ansible für Neulinge
#33

@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.


#34

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?


#35

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


#41

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


#42

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?


Tunndeldigger - Durchsatzprobleme ab 300 Knoten
#43

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


#44

@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?


#45

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

Grüße
Matthias