Jein, das sind entweder die über IPv6 angebundenen Knoten, die eine andere MTU benutzen, oder FF-Nutzer, denen ein FF-Gerät „aufgezwungen“ wurden und nicht wissen, was für ein Schätzchen bei ihnen auf der Fensterbank steht, und keinen Neustart durchführen.
Da B.A.T.M.A.N.-advanced scheinbar immer noch einen Bug in der internen Paketfragmentierung aufweist, stürzt der Kernel ab. Zum Reporten komme ich aus Gründen nicht, hier kann man nachlesen, was früher geschah. Aus diesem Grund hat batman auf der VM nun ein Hop-Penalty von 250. Kann sein, dass dadurch die KArte nichts von diesen Knoten mitbekommt.
ich habe einen der Schafe zugelassen, k. A. warum dieser nicht möchte … ich habe nun den zuvor gesperrt und den nächsten zugelassen.
k. A. was Du mit USA anstellst
kann man machen, geht aber schöner. Nichts für ungut und nicht falsch verstehen. Ich habe im Moment keine Zeit und die Wahl zwischen mehreren fastd-Tunneln von einer IP oder ständigen VM-Crash für alle. Ich hoffe, dass meine Entscheidung nachvollziehbar ist.
Das ist echt ehrenvoll und komplett als FF-Gedanke zu verstehen; „drüben“ ist aber etwas™ extrem schief gelaufen. Eine Analyse wollte ich am Wochenende vornehmen, das Leben lies es aber nicht zu. Übrigens, könnte die Fehlkonfiguration „drüben“ auch einer der Gründe für das Fehlverhalten sein, welches Du mal berichtet hast und ich nicht genau eingrenzen konnte.
Ich schlage vor, Du sendest mir einen fastd-Key, des Knotens, welches Du am liebsten an das Gateway angeschlossen hättest. Du hattest drei, das erste im alphabetischen Sinne war freigegeben. Nach deiner Meldung hier versuche ich es nun mit dem 2ten Key.
Entschuldigt die voreilige Meldung oben, ich hätte das Problem gelöst. Es war auch gelöst, bis neue auftraten. Da dies FFRL nicht interessierte (aus Gründen oder weil alles dort i. O. ist) Habe ich das mit so einer Meldung abgehackt.
Das Problem ist teils Batman, teils falsche Konfiguration der Aufsteller (2 sind raus, aus kommunizierten Gründen, im Übrigen, das erste Mal, dass ich zu dieser Maßnahme greife – aus zeitlichen und Erfolgs-Gründen – ), teils hausgemacht (mein Co-Admin deffiniert eine andere MTU auf dem gleichen Port, statt auf einem Anderen). Ich mutmaße auch, dass irgendwo bei den Schuldigen Bridge Loop Avoidance nicht aktiviert wurde.
Ich möchte mich nicht aus dem Fenster lehnen und nichts versprechen, was ich zeitlich nicht einhalten kann, aber eine neue Firmware muss her … Dies steht mittlerweile ganz oben auf meiner Liste, da ich nach den Jahren es doch geschafft habe die davor liegenden Punkte abzuarbeiten.
Dass der Bahnhof und ein weiterer Akteur offline sind, tut mir wirklich furchtbar traurig. Leider muss man hier an alle denken, und nicht an die, die „to big to fail“ sind. Warum die anderen Knoten nicht in der Map sichtbar sind, weiß ich nicht, ich nehme an, dass dies an der Firmware liegt, die sich bei der MTU-Entscheidung verschluckt hat. Ein Reset würde echt helfen. Sollten die sich aber für die richtige MTU und IPv4 entscheiden, muss ich diese aber manuell freigeben – IPv6 darf ungeprüft rein, bis es auch ein Grund für Paketverluste wird.
Bei den Knoten in der Wolke, die daran teilnehmen, sollte FF aber ohne Paketverluste und mit allem, was die Hardware her gibt, funktionieren. Ab und zu – in einer freien Sekunde – füge ich neue Knoten in die White-List hinzu. Wenn, die VM aus Paketfragmentierungsgründen abstürzt, ist sie in ca. 1 min wieder online und stellt DHCP in 2 min bereit.
Bis Bald