Hallo
Den Knoten habe ich gestern Abend ca. um 21:00 Uhr, auf die neue FW (basierend auf LEDE) umgestellt.
Da sieht man es noch ganz genau…
https://karte.freifunk-lippe.de/map/#!v:m;n:30b5c2e2fec4
Hallo
Den Knoten habe ich gestern Abend ca. um 21:00 Uhr, auf die neue FW (basierend auf LEDE) umgestellt.
Da sieht man es noch ganz genau…
https://karte.freifunk-lippe.de/map/#!v:m;n:30b5c2e2fec4
Ich habe, wie descilla auch, da einen lückenhafte Übertragung.
Wenn Du jedoch gar keine Statistikdaten mehr hast, dann liegt es an Eurer Hoppglas-Installation.
Denn am Collector kann es nciht liegen, sondern nur am FrontEnd, wenn Du etwas anderes angezeigt bekommst als wir.
Die Hopglass-Installation funktioniert mit den Openwrt-Knoten tadellos. Die Verluste treten nur bei den paar LEDE-Knoten auf.
Tippe es liegtr eher an der LEDE-Firmware. Nach dem Update sind darauf sofort die Daten lückenhaft oder nicht vorhanden.
@adorfer @collimas Eigentlich geht es hier gar nicht um die Karte. Es geht um respondd bzw respondd->script->graphite (carbon-cache).
Aufgrund von
schließe ich Graphite mal als Ursache aus.
Es wird also ein Problem zwischen respondd client auf dem Knoten und respondd server aka node-stats script sein.
Aufgrund des konkreten Fehlerbildes würde ich möglicherweise ein anderes zeitliches Verhalten unter LEDE als Ursache vermuten.
Da du aber sagst, dass es auf der Karte (also auch beim hopglass server) keine Probleme gibt und die Daten dort regelmäßig eintreffen, würde ich eine schlechte Programmierung unseres Scriptes als Ursache vermuten.
Das prinzipielle Problem:
n
Zeiteinheiten nach der letzten Nachricht, die rein gekommen ist, bevor sich der Port schließt.Prüfe also bitte mal welcher Wert dort eingestellt ist.
Anmerkung: Das Script stammt aus den Anfangstagen von Freifunk Münster, ich habe es recht stümperhaft von alfred auf respondd als Datenquelle umgestellt. Da ich sowie vor hatte/habe das Teil neu zu schreiben.
Da die Daten, die wir brauchen eh schon vom Hopglass-Server erfasst werden, nutze ich in der Neuimplementation direkt diese Daten, damit sparen wir dann redundante respondd Abfragen ein.
Du findest die neue Version hier:
Diese läuft bei FFMS auch schon produktiv, ist aber noch nicht im Ansible eingebaut, da ich hier und da ggf. noch die resultierende Datenstruktur geändert werden könnte. Außerdem wird das Script momentan auch noch per Cron minütlich aufgerufen. Geplant ist es das Programm als Dienst laufen zu lassen.
Bei Bedarf ließe sich sicherlich auch ein „respondd-server“ als alternative Datenquelle zum hopglass server realisieren…
Aber wenn ein User keine Statistikdaten bekommt und einer (oder mehrere) andere zumindest lückenhafte, dann würde ich erstmal dort suchen. Das kann unmöglich an LEDE (oder dem Node) liegen.
Das stimmt. Ich habe dem TE einfach mal unterstellt sich unklar ausgedrückt zu haben.
Nun ist v2017.1 released worden und dieses Problem ist noch immer vorhanden.
Ich könnte etwas Hilfestellung gebrauchen. Am Verhalten hat sich nichts geändert. Das Hopglass-Backend schließe ich aus, da es mit den Openwrt-Knoten überhaupt keine Probleme gibt.
Im Moment ist mir nicht klar, an welcher Stelle ich ansetzen könnte, um die Ursache zu ermitteln.
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.
Hallo, kurze Zwischenfrage: welches alfred-json verwendet ihr?
GitHub - ffnord/alfred-json: Simple alfred client with JSON output oder GitHub - kratz00/alfred-json: Simple alfred client with JSON output ?
MFG
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.
Ja, ist der HopGlass-Server. Nicht der ganze Knoten verschwindet, sondern es fehlen Statistikdaten: https://karte.freifunk-lippe.de/map/#!v:m;n:14cc20918ba6
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.
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
Ich gebe dir gerne Zugriff auf Hopglass und Gateway, wenn das hilft. Schick mir dazu deinen SSH-Key an michael@collimas.net.
Hier gibt es passende Firmware zum Testen:
https://www.hidrive.strato.com/share/3z6.zwm755#$/Firmware/Release%20-LEDE%20