Es ist zwar bis jetzt eher ein “optisches” Problem, aber es kann bei der Auswertung der Daten durchaus verwirren:
Ich habe in Ladenburg und Schriesheim einen Futro als Offloader und dahinter einige Knoten. Es gibt keinen zweiten Knoten mit Uplink bisher in dem Mesh hinter dem Offloader. Also muss der gesamte Traffic vom Uplink zu dem entsprechenden Knoten geschickt werden. Das sieht man in Grafana als “forward”-Traffic vom Offloader und muss in Summe nahezu identisch sein zu dem “rx”-Traffic der Knoten.
In Ladenburg sehe ich das oft auch als Kette, also Offloader->T01->005->004 … also ich kann sehen welchen Weg die Datenströme nehmen.
Aber sowohl in Ladenburg als auch in Schriesheim kommt es manchmal über viele Minuten zu dem Problem, dass der offloader nicht den Traffic richtig anzeigt. über längere Zeit ist das was die Clients aus dem Netz holen bei insgesamt 7-8 Mbit (mehr gibt der Anschluss zur Zeit nicht her) und der “forward”-Traffic vom Offloader zeigt nichts an oder nur einen Teil des Traffics … Das es für einzelne Minuten immer mal Abweichungen gibt es klar, aber über 1h müsste der Schnitt ziemlich genau passen. Tut er aber nicht.
Der Offloader-Forward ist oft fast Null oder nur ein Bruchteil des Traffics den dann z.B. OHS-001 weitergibt. Aber OHS-001 bekommt ja alle Daten vom Offloader … der zeigt das aber nicht an.
Ähnliches habe ich in der Unterkunft in Bürstadt auch schon gehabt. Guck dir die dazugehörigen Packet Statistik mal an. Das kommt bei mir immer dann vor wenn viele Pakete gesendet werden (tx). Wieso das aber im Traffic so angezeigt wird kann ich auch nicht erklären.
Hier fallen gerade das eigentliche Problem und etwas anderes zusammen. Einmal das die Daten nicht richtig aufgeschlüsselt werden und folgendes: Wenn jemand viel Traffic macht, erzeugt das gleichzeig viel ACK Pakete für TCP. Diese ACK Pakete machen dabei nichts anderes als der sendenden Gegenstelle zu bestätigen, dass ein Paket gut angekommen ist. Das sorgt für die vielen Pakete im Upload Richtung die quasi keinen Traffic machen.
Spannend finde ich das hier > 30Mbit/s in der Unterkunft angezeigt werden. Das ist deutlich mehr als du bisher beobachtet hast. Aber das ist ein anderes Thema und ein anderer Thread.
Leider nein. Das ist extrem komisch, zumal da es ja manchmal stimmt und manchmal nicht.
Erst dachte ich, es würde sich vielleicht einfach um LAN-Traffic handeln, der nicht durch den Offloader durch muss, aber dann passen die RX/TX-Werte nicht zusammen.
Ich hatte selber mal ein ähnliches Phänomen, als ich auf einem Router mit 32-Bit Betriebssystem den Traffic gemonitored habe, und die 32-Bit counter laufen erstaunlich schnell über (bei 8 MBit/s -> 1MByte/s läuft der 32-Bit counter ca. einmal jede Stunde über).
Nicht ganz schlüssig mit den angezeitgten Werten, aber mal eine Idee. Alternativ könnte ich ein iptables / python / zabbix-client setup beisteuern, mit dem man eine zweite Messung parallel laufen lassen könnte.
es ist halt witzig, dass es Zeiten gibt, wo der offloader-Forward ziemlich exakt die Summe aller RX-Werte der Knoten danach ist…
Und bei mir zuhause ist es ja so, dass der OHS-001 als einziger Knoten am Offloader hängt. Der muss also entweder selber RX liefern (wenn der Client da angemeldet ist) oder er muss es als Forward anzeigen (wenn es per WLAN-Mesh weitergeschickt wird) Das MACHT der auch so. Aber der Offloader selber ist sehr häufig ohne Forward-Trafic in der gleichen Zeit.
also ich sehe in Grafana z.B. einen Forward von 001 und einen von 002 und dann einen von 005 und bei 004 den RX … das alles passt in etwa, denn den weg nehmen die Daten.
aber der Offloader - der ja der einzige Uplink da ist, sagt “ich hab nix gemacht” …
Vielleicht könnte man in den Graphen noch die “dropped”-Pakete eintragen (in der nodes.js sind sie ja drin), wobei das in RX-Richtung das Problem eigentlich nicht erklären kann.
Batman sendet große Daten fragmentiert und hat dafür eigene Counter. Kann es sein, dass irgendwo vergessen wurde, den Fragmentation-Traffic zu den normalen Trafficdaten dazuzuaddieren?
Würde das erklären, warum der offloader den Traffic nicht “sieht”, aber die nachfolgenden Knoten schon (auch wenn die ebenfalls die Daten nur weiterleiten)?
Wenn die Daten im VPN fragmentiert werden (was oft passiert, da wir dort eine kleine MTU fahren [müssen]), dann könnte es sein, dass der Offloader die Pakete wieder zusammensetzt und sie deshalb in seinen Statistiken fehlen. Ist aber nur eine Theorie. Kannst ja mal die Ausgabe von batctl s loggen, vielleicht kann man dann was sehen.