Paketverlust auf den Wupper-VMs

… das lässt jetzt verschiedene Menschen („stille Mitleser“) ratlos zurück. Zumindest ich hätte aber sowieso nichts beitragen können, weshalb ich eben auch nur still bin. :wink:

2 Likes

Das stimmt, ich habe die stillen Mitleser („Google“) vergessen. Wie soll ich die Problemlösung beschreiben, ohne, dass es mir mein ganzes restliches Leben nachgetragen wird? Ich versuche es mal zu beschreiben, in der Hoffnung, dass ich nicht gesteinigt werde.

Ich habe hier mehrere Unbekannte:

  • k. A., ob mit der FFRL VM alles in Ordnung ist (keine Rückmeldung hier im Forum)
  • k. A., wie das FFRL Wetter ist; sprich: Wie ist der BB zustand
  • k. A., wie dicht die Leitung zur VM ist

Ich habe mehrere Störquellen:

  • fastd stürzt reproduzierbar ab und ich habe keine Zeit es zu melden, da mir FF um die Ohren fliegt und ich auch noch irgendwie „leben“ muss
  • bleche in der freien Wildbahn stürzen reproduzierbar mit FFW und den anderen Huckepack-Comunities ab und sind keine Hilfe, um das Problem zu lösen
  • ich habe die FF-Nutzer, die – Gott weiß – was mit dem FF anstellen
  • ich habe einen „mit“-Administrator, der überhaupt nicht administriert. Als ich vor dem Beginn meines Studiums jede Woche eine Übergabe im Hackerspace machen wollte, wollte dieser nichts davon wissen und verwies auf später. Ich behaupte, ich bin der Einzige, der FFW administriert.

Was ich tat:

  • die eine VM stürzt reproduzierbar nach einem Neustart ab
  • alle fastd-Tunnel wurden deaktiviert und nach und nach wieder erlaubt
    • gleichzeitig wurde eine IP erkannt, die der VM auf der BB Paketverluste verursacht hatte
      • siehe erster Beitrag im Thread
    • ich meine, das muss man sich mal vorstellen: Paketverluste auf der BB, bei 10 Mbit/s Last
  • das Netz wurde regelmäßig auf Funktion überprüft; es scheint nun performant zu laufen
    • die fastd-Tunnel wurden stufenweise wieder in den Freifunk integriert
    • die Störer (mir bekannt) wurden nicht mehr zum Tunnel zugelassen
      • dies bleibt noch, bis ich das Netz mit weiteren Servern stabilisiert habe
      • leider gilt das auch für neue Knoten
      • in dringenden Fällen kann hier im Forum ein fastd key genannt werden, der dann aktiviert wird
    • die Youtube-Gucker (nicht die oben erwähnten Störer) sind abgesprungen, was eine zusätzliche Entspannung bewirkt
  • dies hier geschrieben

Es muss aber noch ausdrücklich erwähnt werden, dass der von mir oben als Störer bezeichnete FF-Teilnehmer nicht unbedingt der Störer sein muss, sondern ein Freifunknutzer bei ihm. Neun fastd-Tunnel von einer IP sind aber auch schon ein bisschen derbe. Krank dabei ist, dass das zur Abhilfe hinzugezogenes Blech (dritter Beitrag) sich im gleichen Rechenzentrum befindet, wie die IP des Störers. Hierbei muss aber unterschieden werden zwischen Rechenzentrum und Standleitung nach X (Ort bekannt), beide befinden sich jedoch im selben AS. Auf jeden Fall, hat das Blech nur einen Tag als GW überlebt. Davor war es passiv im Verbund.

Was ich daraus lerne:

  • ich (Co-Administrator) habe keinen anderen Co-Administrator
  • wenn
    • nichts mehr geht
    • auf der Arbeit gerade ein Projekt kurz vor dem Abschluss steht
    • privat so viel zu erledigen ist, dass man nicht mal in Ruhe ein Hackerspace besuchen kann
    • die Arbeit kündigen müsste, um die/das FF-Pensum/-Debugging/-Ursachenforschung/-Administration zu bewältigen
    • die Steuererklärung abgegeben werden sollte
  • dann einfach mal FF abschalten und kontrolliert wieder hochfahren
    • es hat ja nur eine Nacht gedauert
      • eine Nacht, die ich schon wieder wegen FF nicht gepennt habe
  • es ist nur ein ehrenamtliches Projekt
  • Furos (aka. Powerfreifunker) meinen sich an den FF-fastd anstöpseln zu können statt eine bessere alternative zu wählen
    • die Durchsatzrate eines Plasterouters bewirkt, dass alle was vom FF haben und nicht nur die allseits bekannte Person mit dem Namen „ich“.

Mag sein, dass ich lange nichts mehr für den FF getan habe, aber ich habe auch ein Leben. Gespendete Server, die ich nicht mal ein- und ausschalten kann, geschweige über eine Konsole debuggen kann, nützen mir nicht viel, da sie sofort abstürzen. Da sie kommen und gehen, ich FFRL aber von ständigen GRE-Änderungen verschonen möchte, und weil wir Spenden für VMs gesammelt haben, bleibt erst ein Mal alles, so wie es ist, bis die Leitung in unser Rechennetz steht.

Wer FF nur zum Speedtesten nutzen möchte, dem Empfehle ich IPoverBrieftaube: nichts ist schneller.

BTT. Ich mutmaße, dass sich neben dem Störer noch ein paar Experimentierer im FF befinden, die den FF, ohne zu wissen was sie tun, zusätzlich instabilisierten. Ich finde es zutiefst traurig, dass Experimente hier im Forum nicht ein Mal angekündigt werden.

10 Likes

Bist Du Dir sicher das alles wieder ok ist?

Es sind mehr als die Hälfte aller Nodes offline.

Ansonsten sieht es wieder halbwegs ok aus an meinem Node.

Ich bin noch unschlüssig, was davon „Messfehler“ ist und z.B. „Anbindung des Kartenservers an die FF-Domain“ geschuldet sein könnte.

Oder long-Term-View der Wupper-L2-Domain:

Dass in der Domain manchmal komischer Traffic ist: Habe ich eigentlich schon aufgehört mich zu wundern im vergangenn Jahr.
Peaks von >600kBit/s Traffic auf einem Node (hier:Kartenserver), der „kein geroutetes IPv6“ (geschweige denn IPv4) macht und nur „seitlich an der Domain dranhängt“: komisch:

Deshalb noch mal meine Frage: Es sind immer noch ca. die Hälfte aller Wuppertaler Nodes offline. Einige meiner Router sind davon ebenfalls betroffen. Mehrfacher Neustart brachte keine Änderung.

Bitte untertänigst um Antwort.

Potentiell (Spekulation) gibt es schlicht einen Netsplit, d.h. zwei Gruppen/Wolken von Supernodes, die keinen Kontakt zueinander haben und der Mapserver sieht halt nur die Hälfte von diesen.
Oder wechseln die offline-Nodes und die Knotenzahl ist sehr konstant? Dann könnte irgendwo ein „Max-Peers“ irgendwo zuschlagen.

Wie nebenan geschrieben: die Nodes scheinen mir hier lokal zumindest „echt“ offline, nicht nur ohne korrekte Info auf dem Kartenserver. Pingen von der Shell nicht nach draußen und sind von Clients nicht nutzbar (Default-IP, „keine Internetverbindung“). Angemeldeter Client kommt nicht mal auf die 10.3.0.1.

Wenn ich „hier“ richtig deute, dann ist damit Utopiastadt/Mirker Bahnhof gemeint, korrekt?
Dann habe ich Phips Posting so verstanden, dass von dort netztechnisch problematische Pakete kamen und daher die Site ausgesperrt wurde.

Ich weiss nicht, um was es da geht, ich unterstelle jedoch Gesprächsbedarf.

Der ist definitiv gegeben. Nein, ich rede von den drei Schafen drunter (Wolkenschaf, Strassenschaf, fabrikschaf), die stehen gegenüber vom Bf. bei mir zuhause und hatten eigentlich immer separaten fastd über meine Leitung, falls die US-Wolke mal keinen Uplinik hat etc. Fürs Protokoll: drei Zugänge über eine IP, aber hier schon einigemale Thema gewesen und keine Experimente, reines „mein Uplink ist fett genug, um auch ein wenig Last rauszunehmen“.

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

1 Like

Falls es hilft: stell uns die aktuell genutzte site.conf und die Änderungswünsche in dieser zur Verfügung.
Wir haben gerade Übung im Firmwarebau und können eure Konfiguration gerne auf die aktuelle gluon Version migrieren und auf dem build-server von FFDUS und Neanderfunk für euch bauen.

3 Likes

Die Nodes sind wirklich offline, nicht nur auf der Karte, z.B der hier bleibt stur offline (wichernhaus-martin-luther-3) nachdem er drei Jahre brav seinen Dienst versah. Neustart usw bringt nix. Und ich garantiere das an dem Teil nichts aber auch gar nichts gebastelt wurde.

Welches ist lastworking site-conf?
Dann bauen wir darauf auf.
2017 hatten wir schonmal was „inoffizielles“ (noch Gluon 2016.2) gemacht.

danke für die Rückmeldung. Ich glaube Dir, was Du schreibst. Das einzige, was jetzt noch übrig bleibt: der Anschluss kann IPv6 und darüber wird eine Anmeldung versucht … aus unerfindlichen Gründen klappt sie aber nicht und IPv4 wird versucht. Durch die Anmeldung über IPv6 ist IPv4 aber nun gesperrt … Wenn es sich nicht verbindet, dann muss ich leider auf den Sonntag vertrösten … ich hoffe, das ist ein kleiner Trost

Danke

ja …

danke


es ist nicht so, dass ich nicht weiß wie eine Firmware gemacht wird … Nicht falsch verstehen. Nachdem ich aber das nötigste aus meinen alten Dateien heraus gekramt habe, um es Euch zu nennen, habe ich anschließend in der Zeit, in der ich Euch detailliert erkläre was ich noch so alles ändern muss, die Firmware selbst gebaut, die Server entsprechend angepasst und mit 5 Geräten selbst getestet …

wie du meinst. Wenn du Hilfe benötigst einfach melden.

Die aktuelle Krise der Wupperdomain kommt meines Erachten ja nicht nur daher, dass es zu wenig Menschen gibt, die sich dort in die Wartung der Supernodes eingearbeitet haben und bereit waren, dort auch langfristig mitzuwirken.

Es ist auch symptomatisch, dass sich in den letzten 2,5 Jahren niemand gefunden hat, der sich das Thema „Firmwarebau“ angenommen hat.
(Gerade wo dieses Thema doch vergleichsweise überschaubare Einstiegshürden hat und man dazu auch viel Hilfe im Netz findet zur Einarbeitung)
Will sagen: Bei aller Bereitschaft die Riege der „ich will doch nur daheim einen Knoten aufstellen und nutzen können“ zu unterstützten: Wenn sich trotz erkennbaren Bedarfes dort auch nach über einem Jahr niemand findet, der oder die in die erkennbar zu besetzenden Lücken geht, dann ist die langfristige Perspektive nicht gut.

Aktueller Status: Betroffene Nodes alle weiterhin offline (128 online, 125 offline, 1 neu, 131 verschwunden)

Trösten würde mich wenn man die Hilfe die hier ja nun von mehreren Seiten angeboten wurde annehmen würde.

Da wir jetzt rund 14 Tage später sind: Wie steht’s denn so?
Gibt es diese Firmware (evtl. mit neuen Supernodes) irgendwo?

Ich würde nämlich gern in die site.conf schauen, um ggf. die Anbindung der Map zu den neuen Servern einzustellen, siehe Wuppertal-Maps nicht erreichbar via Webseite

ich bin bisher nicht dazu gekommen die site.conf aus meinem alten Rechnerbestand zu extrahieren. Ich habe privat einfach keine Zeit dafür. Tut mir leid. In einem Monat habe ich Urlaub … hoffe ich.