nachdem wir gerade auch gemeinsam mit FFBSee an dem Problem debuggen, warum sich Meshes teilweise komisch verhalten.
Wollte ich mal wissen wer sonst noch Probleme mit BATMAN_V hat?
Indizien bis jetzt:
Es müssen mehr als 5 Meshpartner in der Nähe sein
Es tritt bei Wifi öfter auf als bei Kabel Meshes
Die Verbindungen werden einseitig (aka 0-100% und nicht mehr 100%-100%)
Meistens kommt man über das direkte Nachbarnode per SSH noch auf den Knoten der auf 0% steht
Es beruhigt sich nach einiger Zeit von selbst
Was wir getan haben bis jetzt:
Eine neu Firmware mit batman-adv 2019.2 gebaut (Add cherry-pick of batman-adv-2019.2 · freifunkMUC/site-ffm@19b40f6 · GitHub), scheint das Problem der einseitgen Verbindungen zu beheben, aber es werden oft schlechte Links preferiert. Als ob BATMAN die Routen nicht schwenkt, wenn eine bessere vorhanden wäre.
Workarounds für ath9k Bugs aus der Firmware ausgebaut um Link-Flapping zu reduzieren
Wir sind etwas ratlos, wie wir weiter machen sollen. Auch haben wir noch keine zuverlässige Möglichkeit gefunden es zu reproduzieren. Falls also eine andere Community noch auf der Suche nach Lösungen ist, wäre es super wenn wir alle zusammen arbeiten könnten.
Es ging bis zum Update auf BATMAN 2019.2 immer auf 0% runter. Natürlich dann auch keine Daten mehr im Grafana :/. Und die andere Seite zeigte weiter die 100%.
Beim Wireless Battlemesh v10 in Wien damals, schien es ein paar Merkwürdigkeiten mit BATMAN_V zu geben. Konnten wir danach noch nicht wieder reproduzieren, aber vielleicht seid ihr da ja jetzt auf einer heißen Spur.
Zum Debuggen: Das „ab 5“ klingt fast in Richtung Congestion. Könntet ihr evtl. mal mit (a) H.O.R.S.T. schauen, wie es sich mit der Airtime bei 1,2,3,4,5,… Knoten verhält? Auch mit Wireshark am besten mal auf einem Monitor-Mode Interface schauen, wieviele OGMs und ELP Pakete da so rumschwirren. Die genaue Paketrate von denen wäre interessant und ob es da evtl. sporadische Spikes gibt. Auch ob ihr OGMs mit verdächtig niedriger TTL finden solltet, wäre interessant (könnte auf einen Routing-Loop hindeuten).
Dissektoren für BATMAN_V sollten in einem aktuellen Wireshark eigentlich drin sein (ob die Version in z.B. Debian unstable schon neu genug ist, weiß ich gerade nicht).
In „batctl log“ mit „batctl loglevel batman“ wäre ansonsten noch das nächste Level. Ist aber bei hoher Paketrate etwas anstrengender zu lesen.
Das ist schonmal interessant, auf den Gluon Kisten ist das debuggen halt immer etwas schwer, da ich nicht so einfach Kernelzeug nach laden kann etc…
Eventuell versuche ich mal in diese Situation mit ein paar VMs und Raspberries zu kommen.
Da ist es deutlich einfacher Tracing Funktionen einzubauen und vor Allem ist genug Platz für Debugwerkzeuge vorhanden ;).
Was auf BATMAN_V auf jeden Fall schonmal schlecht ist, ist dass ein gewählter Nexthop gefühlt für immer der Nexthop zum Gateway bleibt, auch wenn sich die Linkqualität deutlich verschlechtert. Das führt zu einer schlechten Nutzerexperience und gerade für Wifi Links ist das richtig schädlich.
Eine prozentuale Abbildung der Metrik ist nicht hilfreich zum debuggen, denn welcher Linkspeed wird hier als 100% angelegt? Davon solltet ihr wegkommen, das hat bei BATMAN_IV funktioniert, um die 0-255 Skala abzubilden, bei BATMAN_V sollte die Metrik einfach roh, ggf. mit Einheit, angegeben werden.
Das ist eine sehr gute Frage, ich habe mich auch schon oft gefragt was die 100% nun heißen sollen …
Aber ob da nun 0 oder 100 steht ist im Grunde erstmal egal, interessant ist dass dann in dem Moment nichts mehr gerouted wird.
Ich bin gerade dabei Hardware aufzutreiben um das Szenario nachstellen zu können. Ich habe einen Verdacht wie es zustande kommt, kann das aber nicht beweisen oder untermauern.
Im Moment sieht es aber so aus, dass es vor allem in Szenarien mit vielen wackligen Verbindungen auftaucht, als ob sich irgendwann bei zuvielen Flaps irgendwas vertut.
Was nimmt diese Konvertierung vor, ist das yanic? Ich halte es für gut möglich, dass wer auch immer das konvertiert gar nicht mit BATMAN_V umgehen kann und einfach 255 Mbit/s auf 100% mapped oder so.
Mir ist eine Kartensoftware demonstriert worden, welche von BATMAN IV auf BATMAN V portiert wurde. Im Zuge dieser Portierung, wurden reichlich Annahmen eingebaut, welche die BATMAN V Metrik (MBit/s) auf Prozent umrechnet. Der Code enthielt auch viele fest eingebaute Werte, wie z.b. VPN-Server-Links haben immer 100%, Schwellwert von XX MBit/s auch 100%, etc. Das fuehrte dazu, dass die Karte gar nicht das BATMAN V routing abgebildet hat, sondern reichlich eigene Werte produzierte. Zum Zeitpunkt der Demo waren fast alle Werte bei 100% oder 25%.
Es scheint, als wuerdet auch ihr diese Karte benutzen, daher die Frage: Sind die beschriebenen Probleme auf Inkonsistenzen zwischen dem, was die Karte zeigt und was das Routing macht, zurueckzufuehren ? Oder gibt es tatsaechliche Routingprobleme und falls ja, wie sehen diese Probleme aus ?
Ich hab gestern genug Hardware aufgetrieben, um mal in einem Lab zu schauen ob ich den Zustand hinbekomme.
Denn im Moment tritt es nur sporadisch in wackligen Meshes auf, die eben mehr als 5 Nodes besitzen. Und zum Debuggen ist das wie gesagt eine Katastrophe, wenn ich den Zustand aber künstlich herbeiführen kann ist die Chance rauszufinden was und ob was schief läuft deutlich höher.
Dann bitte nicht auf Basis der kaputten Prozentangaben zu Schlussfolgerungen kommen.
Wie sehen denn die echten Metrikinformationen zu dem Zeitpunkt der Routingprobleme aus ? Was sind schlechtere Routen im Vergleich zu bessere Routen (in Bezug zu Metrik, verfuegbare Links, etc) ?
Mir sind keine Probleme bzgl. BATMAN V und der Wahl von schlechten Routen bekannt und ich lese so ziemlich alle Emails der batman mailing list und IRC Kanal. Vielleicht solltet ihr euch dorthin wenden ?
Die Prozentwerte sind nur ein Indikator um die Router auf der Karte zu finden, die gerade ein Problem haben.
Meistens kommt man auf diese aber nicht mehr drauf, also ist es schwer dann Aussagen zu treffen ;).
Meistens wenn man doch noch drauf kommt, sieht man dass der throughput deutlich unter den anderen Routen liegt, was schlicht daraufhin deuten kann dass einfach keine Daten mehr fließen.
In erster Linie ging es mir erstmal darum, zu hören ob noch andere Communities „komische“ Phänomene mit BATMAN_V haben. Um irgendwie das Problem eingrenzen zu können.
Zitat auch von FFBSee:
bei 4er meshes hatten wir auch schon probleme gesehen. wir haben allerdings nicht 0/100 sondern per wifi batman unerreichbare router die ab und zu wieder erreichbar sind und ggf iwann wieder normal laufen.
zu den routen: stable over fast ist wohl gewollt aber nicht immer sinnvoll
solang die route nicht ausfällt wird nicht neu gewählt
Es fehlen weiterhin technische Details, um Vermutung anzustellen. Der betroffene Router hat nur einen Link zu einem Nachbarn und ist darueber nicht mehr erreichbar ? Ueber WiFi ? Wieso muss das ein BATMAN V Problem sein und kann kein WiFi bezogenes Problem (Treiber, Umgebung, etc) ?
Was deutet in diesem Problemfall daraufhin, dass BATMAN V schlechtere Routen bevorzugt ? Wenn es nur eine Route gibt ?
Was spricht dagegen, sich bei den BATMAN Entwicklern zu melden, die vielleicht viel eher was zu BATMAN V Problemen sagen koennten ?
Die Router besitzen mehrere Routen zu den Nachbarn, es passiert über Wifi wie auch Kabelmesh, was für uns den Treiber rausnimmt.
Es passiert scheinbar auch nur in Umgebungen in denen es viele Wackler der Routen gibt und ständig Bewegung ist.
Es spricht nichts dagegen, sich bei den BATMAN Entwicklern zu melden, aber erstmal möchten wir das Problem eingrenzen. Wenn hier Leute schreiben nein mit BATMAN_V läuft bei uns alles super wir haben nie die Probleme, müssen wir eventuell woanders suchen. Das Problem tritt sporadisch auf und von uns kann niemand 24/7 beobachten und sofort debuggen, wir bekommen meistens die Rückmeldung „x-y war wieder nicht erreichbar, auf der Karte war 0%“.
Deswegen auch die Idee das in einer kontrollierten Umgebung zu provozieren.
Wir stehen zusammen mit FFBSee am Anfang der Suche was es sein könnte.
