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ß
@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.
Wobei der running unten wieder korrekt ist 
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
@mtrnord
Oh das habe ich auch nicht gesehen 
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.
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
kommt wenn ich zeit habe aber ich glaube denen ist das bewusst der change ist nicht so alt 
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
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 „Gefällt mir“
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 „Gefällt mir“
@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?
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 vllt. hing da noch irgendwas fest oder so, kann ich jetzt nachträglich nicht mehr sagen 
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
mfg
Christian
1 „Gefällt mir“
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
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