Nabend zusammen,
in unserem IRC Channel wurde heute die Nachricht hinterlassen dass der Knoten FF_Gemen_01 bei euch gelöscht wurde da er euer und unser Freifunk Netzwerk gebridged hat.
Bevor wir versuchen den Knotenbetreiber zu kontaktieren wollte ich mich kurz bei euch erkundigen was hier genau los war ?
War der Knoten an eurem fastd verbunden ?
Grüße,
VOID
hallo VOID,
Hier mal der entsprechende Eintrag im Forum.
Gruß
Thomas
OK … bei uns scheint der Knoten noch online zu sein.
Habt Ihr hierzu den Knotenbetreiber bereits kontaktiert bzw informiert ?
Wisst Ihr wie es zu dem falsch geflashten Router kam ? Also welche Firmware über welche Firmware geflasht wurde ?
Interessanterweise schien das bei uns im Netzt keine Auswirkungen gehabt zu haben was irgendwie merkwürdig ist ?
Gruß,
VOID
Weil euer Netz alles überschreibt, wenn das wirklich euer Netz gewesen ist.
Alleine schon die Tatsache, dass die 3 Gateways so enorm unterschiedliche Bandbreitenwerte eingestellt haben ist sehr merkwürdig, davon mal abgesehen das ein Wert im Gigabit Bereich ohnehin schon sehr fraglich ist.
Warum der Router bei euch noch online ist, wenn er lediglich bei uns gelöscht wurde, das ist ja hoffentlich klar?!
Um ehrlich zu sein bin ich es so langsam leid den Knotenbetreibern hinterher zu laufen, weil ich so langsam von den ständigen ungewünschten Netzkopplungen, die mir unnütz meine Admin Zeit wegfressen, einfach nur noch genervt bin, zumal der entsprechende Router ja eben in einem anderen Netz ohnehin noch online ist - aber es gibt oder gab in diesem Fall auch keine Kontaktdaten in den Alfred Daten des Routers.
Womit wir dann wieder bei „Pro/Contra Autoregistrierung“ wären.
Also vielleicht doch „Token per Email zustellen“, damit zumindest nur die ganz grob vorsätzilchen (OneTimeMailer-User) ohne Kontaktdaten segeln?
Hallo Chris,
gerade darum möchte ich ja versuchen so viele Informationen so gut wie möglich zusammenzusuchen.
Ich stimme dir ja voll und ganz zu dass solche Probleme am besten von vorneherein vermieden werden sollten.
Wenn z.B. durch umflashen eines Routers (wie oben ja bereits angedeutet) so eine Situation entstehen kann macht es Sinn dem nachzugehen und dafür eine technische Lösung zu schaffen.
Da die einzelnen Freifunk-Communities sich ja weiter ausdehnen wird halt auch ein Wandern von Routern zu einer neuen Community immer häufiger vorkommen.
Also Investieren wir doch lieber jetzt die Zeit für eine nachhaltige Problemlösung damit wir uns in Zukunft zumindest mit diesem Problem nicht mehr herumschlagen müssen ?
Gruß,
VOID
Wir haben uns aus genau diesem Grund gegen eine Autoregistrierung entschieden.
Da wir durch die Zusendung des Keys auch eine E-Mail Adresse haben (zumindest meistens) werden wir hier auch bei dem Knotenbetreiber nachfragen wie es zu der Situation kommen konnte.
Da die Kontaktdaten im Alfred öffentlich im Netz verfügbar sind haben halt nur die wenigsten Knoten (zumindest bei uns) dort einen Eintrag.
„Einfach nur sysupgrade ohne -d nach Umzug zwischen zwei Domains“ hört sich für mich als Erklärung nicht schlüssig an.
Denn wie sollte so eine fastd-config mit den Supernodes aus beiden Domains zustande gekommen? Oder wie entstand die Brücke?
Oder gibt es da irgendein Update-Script, welches zwar die neuen Supernodes hinzufügt, ohne die alten aber zu löschen im Zweifelsfall?
Aber vermutlich übersehe ich schlicht etwas. (Von Vorsatz will ich mal nicht ausgehen. Nur wo kommen dann gateways mit Linkspeed 1GBit/s her?)
Ich war bei euch im IRC, freut mich, dass ihr den Weg hierhin gefunden habt.
Gruß,
Philip
Der Uplink nach Münster ist nun aus dem Gelsenkirchener Graph verschwunden - diesen uplink „Gemen“ meine ich dort auch gesehen zu haben, bin mir aber nicht sicher.
Hat das alles mit den Störungen in Gelsekirchen zu tun? Kann es sein, das seit der Löschung dieser Verbindung die Zahl der Clients in GE sprunghaft angestiegen ist?
Ich will hier keine Mehrarbeit verursachen, aber ein Hinweis darauf, dass das die Fehlerquelle war, wäre hilfreich.
Danke
Doch Andreas, ein sysupgrade ohne verwerfen der Config ist die Ursache. Das Ergebnis ist dann eine Mischung der alten UND der neuen Config.
Da der Tunnelaufbau, bzw vielmehr die Auswahl des Tunnels mehr oder weniger zufällig ist, hat man dann nicht zwangsläufig sofort, aber irgendwann die Situation das ein Tunnel in die alte Infrastruktur und der andere Tunnel in die neu hinzu geflashte Infrstruktur zeigt. Und schon hat man eine tofte Bridge von einem Netz in das andere Netz über die leistungsschwache CPE und vergleichsweise kleine Endkundenleitung.
Den „Gateway Speed“ legt man selber im batman fest, einfach ein Anzeigewert, der mit in die Metrikberechnung einbezogen wird. Im Ruhrgebiet steht die Bandbreite auf 48Mbit/48Mbit, im Rheinufer und Möhne glaube ich auf 96Mbit/96Mbit. Generell waren in allen Configs die ich bislang gesehen habe immer Werte zwischen 48Mbit/48Mbit und 96Mbit/96Mbit. das ist nun das erste Mal gewesen das wir fremde Supernodes im Netz hatten die einen höheren Wert hatten.
Vorsatz wird es nicht sein, einfach entweder fehlendes Wissen das man spätestens beim Infrastrukturwechsel mit sysupgrade -n flashen muss oder ein Flüchtigkeitsfehler.
Wir bräuchten, wie schon mehrfach von mir vorgeschlagen, einen kleinen Security Daemon, der die Ausgabe von ‚batctl gwl‘ fortlaufend überwacht und sobald ein Gateway auftaucht das im Feld Next-Node keine identische Mac Adresse zum Gateway hat, muss die fastd Registrierung der Node mit der Next-Node Mac-Adresse gelöscht werden und wenn vorhanden sowohl an die Adminz wie auch an die Mail des Node-Betreibers aus den Alfred Daten eine entsprechende Email gesendet werden. Das würde zumindest die meisten Fehler dann direkt im Keim ersticken und man müsste nicht mehr selber manuell die Node aus den Alfred Daten raussuchen, anhand des Namens die fastd Registrierung suchen und dann die Registrierung für den fastd löschen.
das gleiche Problem gab es im September, als ein Node zur Bridge zwischen Ruhrgebiet und Rheinufer wurde:
Daher denke ich, dass ein automatischer Mechanismus, der solche Fälle erkennt und unterbindet, sehr wichtig für die Stabilität der Netze ist.
Ich glaube, es kann keiner mit Sicherheit sagen, dass es der Node Gemen die Ursache aller Störungen in Gelsenkirchen war. Ihr habt Störungen, die unterschiedlicher Natur sind, daher tippe ich mal darauf, dass ein Teil der Störungen daher kam. Einfach weiter beobachten…
Wenn ich das gewusst hätte, hätte ich den uplink nach Münster und diesen Gemen sofort gemeldet.
Aber - man (ich) traut sich ja schon gar nicht mehr hier was zu schreiben… (ist übrigens nur teilweise ironisch gemein, aber ich will hier kein neues Fass aufmachen)
Nachtrag:
Ich gehe davon aus, dass das hier gesehen und als ungefährlich eingestuft wurde - frei von Störeinflüssen?
Hallo CHRIS,
wärst du so nett kurz zu erläutern warum die die Werte im Gigabit Bereich so „fraglich“ findest ?
Diese Werte entsprechen den Anbindungen der Server … zwei haben im Rechenzentrum eine Gigabit Anbindung und einer eine 100 MBit Anbindung.
Danke schon mal für deinen Input !
VOID
Sind das die Portgeschwindigkeiten des Switches, an dem die Server hängen, oder steht tatsächlich diese Internetbandbreite zur Verfügung?
Da stimme ich euch voll und ganz zu!
Das ist ein Fehler der schlich vorkommen kann und auch jedem von uns mal passieren kann.
Ich habe hier mal einen Neuen Thread für die Entwicklung eine Lösung erstellt Lösungentwicklung erstellt.
Grüße aus Münster,
VOID
Kann man kontrollieren ob man ein falsches upgrade gemacht hat?
Die vom Provider angegebene Bandbreite.
Damit also die maximal verfügbare Bandbreite.
„Bedenklich“ weil die Bandbreite in der Dimension nicht der ausschlaggebende Punkt bei der Bewertung der Metrik sein kann.
Da dieser Datendurchsatz in der Praxis nicht erreichbar ist verschiebt man damit zumindest tendenziell die Metrik in eine falsche Richtung…
Guter Ansatz 
Ich habe hierfür auf unseren Gateways ein Nagios Plugin implementiert … aktuell wird zwar zur die Anzahl der Gateways geprüft aber für einen Hinweis reicht es ja schon mal.
Fell free to use
VOID