Nach einer Nacht voller Fehlschläge meine ich das Problem identifiziert zu haben: es handelt sich sehr wahrscheinlich um SMP. Ich kann den Fehler nach einer Stunde auf zwei Maschinen mit nur einem CPU-Kern nicht reproduzieren. Um sicher zu sein fehlen mir aber noch weitere Maschinen, die zuvor im Versuch dabei waren und die ich heute Nacht abgeschossen habe und nun drauf warte, dass sie von anderen Freifunkern eingeschaltet werden.
Der Hintergrund ist: Kerneldumps von Multiprozessormaschinen sind wertlos, da man sie meines Wissens nicht Debuggen kann. Es hat laaaaaaange gedauert, bis mir das wieder eingefallen ist.
danke für den Link … ich werde dort auch was eintragen. Fragt sich nur, ob man was damit anfangen kann, denn aus dmesg-Ausgaben kann man nicht wirklich viel erfahren und SMP-Kernel-Dumps bekomme ich nicht analysiert.
Seit gestern kommt auch der Alfred wieder durch! Deine Optimierungen scheinen geholfen zu haben.
Mit L2TP würden doch auch weiter Supernodes (ohne Gateway) die Wupper Supernodes entlasten, oder? D.h.:
Router
|
viel Rechenarbeit, fastd
↓ GL Supernode
|
wenig Rechenarbeit, L2TP
↓ Wupper Gateway
Der nächste Schritt wäre dann, das Batman nur bis zu den GL Supernodes zu fahren und danach per Layer 3
Welch Implementation kommt eigentlich zum Einsatz? Es gibt ja irgendwie verschiedene. Wird IPSEC benutzt (soweit ich das verstanden habe ist das ein Krypto-Layer oben drauf)?
L2TP wurde nicht umgesetzt, da sonst die Superknoten abstürzen würden! Es ist alles beim Alten. Jedoch habe ich viel Zeit zum Ausprobieren gebraucht, um festzustellen, dass kein einziger Ansatz funktioniert, der mir eingefallen ist. Sogar die feste Zuweisung eines fastd, Alfred, bat-vis Prozesses zu einem bestimmten CPU-Kern haben nur kurzfristig Abhilfe geschaffen und mit mehr als einem L2TP Tunnel fliegen die Superknoten um die Ohren.
Es gibt noch andere Ansätze, jedoch habe ich erst Mal keine Zeit. Ich schreibe ein paar Bugreports und das war ’s vorerst. Viel später teste ich reine L2TP Knoten.
Alle in Wupper sollten im Übrigen ihre Kartenserver bekanntgeben, damit sie statisch angebunden werden und nicht beim Neustarten der Superknoten die Verbindung verlieren. Niemand außer Troisdorf hat das bis heute getan … ich brauche die Adresse oder IP plus öffentlichen fastd-Schlüssel ins Wiki. Dies ist der Grund für die falsche Statistik bzw. Meshviewer-Anzeige der letzten 5 Tage.
Das würde demnach auch für die Anbindung normaler Freifunkknoten an den Superknoten gelten. Irgendwo im Code ist ein Fehler, der durch bestimmtes Verhalten provoziert wird. Die Wahrscheinlichkeit, dass es im Datenstrom zwischen den Superknoten auftritt ist höher, da dort mehr Daten geleitet werden. Es ist also durchaus möglich, dass dies während der Kommunikation mit einem Freifunkknoten oder Offloader nicht auftritt, da sie nicht schnell genug ist, man kann aber nicht ausschließen, dass es da nicht auftreten wird. So wie ich das bisher sehe, sind nur Maschinen mit mehr als einem CPU-Kern betroffen.
Ja. Zweite Zeile: SMP-Kernel. Entweder singlecore mit maxcpu=1 oder mit nosmp in den Kernelparametern starten. Ist ein Bug, den man so nicht wirklich debuggen kann, da es ja SMP ist.
Noch ein mal in die Runde: Wer weiß, wie man einen SMP-Kernel debuggen kann? In der Literatur lese ich immer nur vom Debugging von nicht SMP-Kerneln …
Das ist einigermaßen schwierig wenn man die Console erst Post-mortem öffnet und das ein Web-VNC ist, also „APA“. Oder gibt es dafür irgendwo eine fixe OCR-Lösung im Web.
Bei debian 4.2 Backports funktioniert nosmp nicht wirklich … ich glaube man fährt da am besten mit einem selbst kompilierten Kernel. maxcpus=0 habe ich noch nicht getestet, klingt aber vielversprechend … scheint aber identisch zu nosmp zu sein. maxcpus=1 bootet immer noch einen SMP-Kernel.
