In Düsseldorf haben wir beobachten können das respondd bei schon ausgelasteten Verbindungen schnell Pakete auf dem Weg verliert. Einen Unterschied zwischen Lede und OpenWRT haben wir bisher nicht beobachten können.
Wir sind daher zurück auf Alfred gewechselt weil dieser mit Transaktionen zwischen den Slaves & Mastern arbeitet und die Daten so zwar auch mal verloren gehen, aber mit wesentlich geringerer Wahrscheinlichkeit.
Für Hopglass-Server habe ich ein Alfred Backend geschrieben:
Der Branch-Name beinhaltet „Hack“ weil dieses Backend alfred-json als Binary benötigt, eine zukünftige Version wird die Daten selbst vom Socket abholen.
Ok, dass es mit respondd Probleme geben kann, sehe ich ein. Ich weiß gerade nur nicht, warum das Problem bei mir NUR mit LEDE-basierten Knoten auftritt.
Vielleicht könnte da ja jemand Licht ins Dunkel bringen. Eine entsprechende Test-Firmware gibt es hier:
Ich denke ohne Zugriff auf die Supernodes bzw Map-Server ist so etwas schwer zu debuggen.
Evtl. einfach mal respondd Daten von den Supernodes aus abfragen und schauen ob das Problem dort auch auftritt oder erst auf dem Map-Server.
Ich kann dir gerne Zugriff geben, wenn das weiterhelfen könnte. Vielleicht könnte mir jemand etwas auf die Sprünge helfen, wie ich beim Debuggen vorgehen muss. Solche eine Installation per Ansible ist bequem, aber wenn man nicht alles manuell selber installiert oder nachvollzogen hat, ist es nicht leicht, einen Überblick zu bekommen.
Ich habe den Wert auf 1250 ms gesetzt, leider ohne Veränderung. Mir erschließt sich nicht, weshalb es ein serverseitiges Problem sein soll, wenn der Großteil der Knoten problemlos seine Daten übermittelt und nur die wenigen LEDE-Testknoten dies nicht schaffen.
Benutzt ihr den HopGlass Server? Verschwinden die Knoten nur in den (wenn ich das richtig verstanden habe um den HopGlass Server herum generierten) Statistiken oder auch auf der Karte generell?
Beim HopGlass Server kann man die Zeit, nach der ein Knoten als offline angesehen wird, wenn keine Nachricht empfangen wurde, in der Konfiguration einstellen unter dem Namen „offlineTime“. Der Standardwert liegt bei 900 Sekunden also 15 Minuten. Nach Standardkonfiguration werden einmal pro Minute jewails statistics und neighbours abgefragt. Es müssten also mit der Standardkonfiguration mal eben mehr als 30 aufeinander folgende Pakete auf dem Weg verloren gehen.
Okay, der node-stats nimmt sich die raw.json vom HopGlass Server, da sind die Daten auch noch drin und die lastseen ist weniger als 5 minuten her. Die Daten verschwinden also höchstwahrscheinlich irgendwo im node-stats.
Läuft node-stats auf der gleichen Kiste? Ist vielleicht NTP abgeschaltet und die Zeit ungenau?
In der config von node-stats die offline time auf 900 sekunden erhöhen?
Sonst ist was anderes im node-stats kaputt oder graphite verliert daten
Generell: Ja, es ist schwierig, das Problem zu lösen ohne Zugriff auf den Mapserver aber man kann das Problem grob lokalisieren. In der raw.json sind die Daten drin und aktuell. Es liegt also auch nicht an respondd an sich, sondern das Problem liegt erst deutlich danach auf dem Mapserver nämlich.
Ich habe mir demensprechend mal erlaubt den Fred noch einmal umzubenennen. Sollte irgendjemand einen Einwand haben wird das selbstverständlich sofort wieder rückgängig gemacht.
Da das Problem nur mit einer bestimmten Gluon-Version auftritt köntte es am Parsen der Daten in node-stats liegen.
Die Zeit ist richtig und wird per NTP synchronisiert.
Wo kann ich die Offline-Time einstellen? Habe das nicht gefunden. Die node-stats laufen unter /opt/node-stats.
Dass node-stats generell kaputt ist oder graphite Daten verliert, halte ich für unwahrscheinlich, da ja alle Daten der Openwrt-Knoten korrekt verarbeitet werden.
Wurde etwas am Parsen der Daten in LEDE geändert? Weiß das jemand?
Hab nicht gesagt dass node-stats generell kaputt ist sondern „was anderes im node-stats“
Das Parsen der Daten findet in node-stats statt. Mit der neuen Gluon-Version werden möglicherweise manche Daten in einem anderen Format geliefert.
wahrscheinlich /opt/node-stats/config.json
jetzt bin ich an dem punkt angekommen an dem ich nichts mehr feststellen kann ohne mir logs anzugucken oder evtl. debug prints einzubauen falls die logs nicht genug auskunft geben
wie wird node-stats gestartet? per systemd-service? per init script? manuell?
sind logs von node-stats vorhanden? möchtest du die mal posten?
ansonsten werde ich gleich mal versuchen bei mir in einem container node-stats und graphite aufzusetzen, das problem zu reproduzieren und dann lokal zu debuggen. das aber erst nach einer verdienten mittagspause
Keine Ahnung wo ich die Logs finde, unter /var/logs sehe ich nichts. Ich kann dir nicht mal sagen, wie es genau gestartet wird, wie kann ich das herausbekommen?
Wie gesagt, du kannst dir gerne den Server anschauen, wenn du magst. Eine passende Firmware zum Testen ist vorhanden. Ich denke nur, dass das Problem eher auf Seiten des Knotens zu suchen ist, da es ja nur mit LEDE-Knoten und nicht mit Openwrt auftritt,.
Kleine Anmerkung am rand:
Es gibt inzwischen Gluon 2017.1.1 wo ein Workaround für einen Bug in Batman eingeflossen ist, evtl ist das Problem dadurch gelöst?
Schon getestet, leider keine Änderung. Auch das Paket gluon-ebtables-segment-mld, das ich auf Anraten von neoraider eingebaut habe, hatte keine Auswirkungen.
Das ist mir aber was ganz was neues? Wir arbeiten immer noch mit Gluon-2.7.3 basierend auf OpenWRT.
Wir haben nur testweise mal LEDE gebaut und den Router auch nicht getestet. Warum der Freifunker an der von dir verlinkten Stelle schon LEDE einsetzt, weiß ich nicht. Ist auch seine persönliche Sache ;).
Zu den Statistiken: Ich weiß, dass da irgendwann mal die Puffer für die eingehenden Daten hochgedreht wurden. Evtl. hat es damit was zu tun. War aber nicht meine Baustelle, sondern @descilla s.
Okay, das konnte ich nicht wissen…hatte nur gesehen das die neu LEDE bei euch schon eingesetzt wird und damit keine Anzeigefehler existieren…was ja schon mal Mut macht
