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 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.
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.
@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.
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
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?
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.
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).
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.
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.
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.
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…
Nun, zur Strecke gebracht ist er noch nicht, nur in die Ecke gedrängt.
Wenn meine Analyse stimmt, müssen Server und Client so angepasst werden, dass sie sich auf eine eindeutige session ID einigen. Der Server teilt dem Client bereits eine tunnel ID mit (CONTROL_TYPE_TUNNEL), da bietet es sich m.E. an, einfach dieselbe ID auch als session ID zu verwenden. Das Problem dabei ist die Rückwärtskompatibilität: Damit sich alte Clients mit neuen Brokern verbinden können, müssen Broker weiterhin per Default session ID 1 verwenden. Neue Clients müssen dem broker irgendwie (in der CONTROL_TYPE_PREPARE?) signalisieren, dass sie gerne die tunnel ID als session ID verwenden würden, und wenn der Broker dem zustimmt (in der CONTROL_TYPE_TUNNEL?), müssen beide dieselbe ID verwenden.
Ich werde mir mal das Broker-Protokoll genauer anschauen.
Lasse mich mal zusammenfassen:
Das Problem lässt sich mit neueren Kerneln ja dann offenbar nicht lösen, da Clientseitig ja das fehlerhafte Verhalten durch das Hardcoding der Session ID erzwungen wird. Du hast Serverseitig mit neueren Kerneln da auch nicht die Möglichkeit das auszubügeln, da die Session ID ja auf beiden Seiten bekannt und gleich sein muss.
Aus meiner Sicht gibt es daher nur die Möglichkeit erst alle Clients zu updaten bevor man neuere Kernel einsetzen kann.
Das einfachste Wäre wirklich:
Client und Broker anpassen
Zweiten Broker mit neuem Verhalten parallel auf neuem Port laufen lassen
Firmware update mit neuem Client und auf den neuen Port angepasster site.conf ausrollen
Erst wenn kritische Masse erreicht den Kernel updaten
Bedingt natürlich, das autoupdate aktiv ist und funktioniert.
Was leider in Problem ist, da überraschend viele Leute ihren Freifunk-Knoten in Dinge wie „AVM Gastlan“ gestellt haben, wo per default nur 80/443/53 frei ist (ich spare mir mal die Details) und wo dann für L2TP die „Ausnahme“ für Port10000 (YMMD) händisch eingefügt wurde.
Bei einer Migration im Emscherland „Domain05“ hat’s dabei etwa 30% der Knoten „in Geschäften“ den Uplink gekostet. Trotz Ankündigung. (Da kann man jetzt in den Heise-Foristen-Modus schalten, nicht nicht ‚Mit Linux wär‘ das nicht passiert’, sondern der andere Standardspruchdort. Hilft aber in der Sache nicht.)
Sprich: Portwechsel: ganz schlecht. Da würde ich mir eher noch IP-Adressen besorgen… Oder in Domains mit mehreren Supernodes nacheinander umzustellen.
Da gibt es leider nach wie vor viele Experten, die das abgeschalten habe, weil sie sich „spezialconfigs“ gebaut haben, von denen sie ahnen(!), dass die nicht updatefest sind… Eine zusätzliche Hürde.
Aber da bin ich dann hart und sage: Wer nach 14 Tagen auch auf Mail (siehe PPA) nicht reagiert oder keine Mailadresse angegeben hat, auf den wird keine Rücksicht genommen.
Könnte man nicht auch - sofern je Domäne zwei Gateways genutzt werden - auf einem Gateway die alte Tunneldigger-Version und auf dem anderen die dann gepatchte Version laufen lassen? Klar wäre dann für die Übergangszeit die Redundanz weg, aber sofern das geht wäre das auf den ersten Blick weniger problembehaftet so wie ich das sehe. Ich weiß nur gerade nicht, ob der alte Tunneldigger auf den Knoten irgendwann automatisch zum anderen Gateway wechselt, wenn das erste Gateway zwar erreichbar ist, aber der Tunnelaufbau fehlschlägt - das wäre die Voraussetzung für diese Lösung.
vllt. hing da noch irgendwas fest oder so, kann ich jetzt nachträglich nicht mehr sagen 
