Sammelthread: Störungsmeldungen und Netzprobleme in Gelsenkirchen

Mehr als 100 Up/Downs nur seit Mitternacht.
Das komplette Tierheim ist verschwunden.

Alfred / Graph und Karte taugen als Monitoring-Handwerkszeug nicht, sagt man. Auch wenn trotzdem gerne alle die drei benutzen.

SenorKaffes Posting deckt sich mit meinen Beobachtungen und bestätigt diese.

Ich brauche / brauchte manchmal 5-8 Anläufe, um per SSH auf die Oberfläche zu kommen. Es kann bis zu 30 Sekunden dauern, bevor eine Rückmeldung kommt.

Es gibt Dauerneustarts.

Der Rest ist mehrfach gesagt - Router mit viel und wenig Traffic stürzen ab, Router mit und ohne uplink stürzen ab, Router mit guter und schlechter Verbindung stürzen ab.
Einige so, dass sie nur per manuellem Reset wieder online kommen.

Alles lief stabil und flott - hier in GE hat niemand etwas an den Routern verändert.
Plötzlich läuft nichts mehr.

Ein bisschen technische Unterstützung bekam ich ja mal durch den CHRIS und PHILLIP. Und bekomme sie noch regelmäßig durch adorfer.
Falls adorfer nicht klammheimlich die Firmware verändert hat, irgendwelche obskuren Scripte eingeschmuggelt hat, wäre eine Fehlersuche an anderen Orten, z.B. auf den Servern nicht sinnvoller?

Vielleicht sollten mal andere auf die Server schauen - manchmal gibt es auch so etwas wie Betriebsblindheit? :wink:

Neoraider hat sich Typ 133 und 134 angesehen. (Router Solicitation, Router Advertisement)

Nach wie vor steht die Aussage im Raum das die RA (Typ 134) das Script triggern.

Gluon ist derzeit nicht für die Nutzung von so vielen IPv6 Gateways gebaut. Da es keine echte Lösung gibt mussten wir die Anzahl der IPv6 Gateways nun gestern auf 4 reduzieren.

Aus meiner Sicht hat es keinen Nennenswerten Unterschied ausgelöst?

Kannst Du Dir jetzt noch einmal Router, vorzugsweise mit hoher Load und wenig Traffic ansehen, wo die CPU Last herstammt und ob nun weniger dhcpv6.script dort gestartet sind?

Als 3. Gegenprobe hatte ich nun eine Picostation an eine schlappe Leitung von o2 gestellt, um schlechte Internetzugänge in betracht zu ziehen. (in der Liste der 3. Router in FF-HER-)

Nach 24 Stunden ebenfalls keine nennenswerte Load, keine klemmenden dhcpv6.script, etc.

Ich habe diesen nun soeben auf die 0.6 hoch geflasht (war noch auf 0.4), um nun eine Gegenprobe mit jüngerer Firmware zu haben.

Was alle 3 derzeit jedoch gemeinsam haben ist, dass dort lokal keine anderen Router, also kein Mesh existiert.

Werde ich mir anschauen.
Kann es sein, dass die RS/RA innerhalb einer lokalen Wifimesh-Wolke als broadcast von Router zu Router hüpfen und daher „ein Client“ den Prozess auf allen Routern der Wolke anstößt?
(Und dass erst Richtung Mesh-VPN gefiltert wird.)

Klar, muss ja, sonst würden die Router im Mesh kein IPv6 Prefix, Gateway etc. bekommen…

Da ich wegen der neuen IPs nochmal in der GE-Instanz vom Uptime Robot war, ist mir im Moment zumindest aufgefallen, dass im Tierheim der Single Point of Failure zugeschlagen hat. Wenn ich mich recht erinnere, hat wegen der Beschwerde eines Dienstleisters nur noch der Tierheim-1 Büro einen Uplink und knipst im Fall der Fälle die ganze lokale Wolke aus. Hat jemand von euch Erfahrung, inwiefern so einen Punkt entschärft werden könnte, wenn man einen kleinen Switch hinstellt und so zwei benachbarte Router mit Uplink versorgt? Bringt das was?

Ansonsten ist mir nur aufgefallen, dass relativ viele Modelle 74x in GE im Einsatz sind - in den Innereien scheinen die aber sehr ähnlich zu den 841 zu sein, bis auf eine Antenne weniger. Mich würde ja schon interessieren, ob die aktuelle Beta mit Barrier Braker da nochmal mehr Stabilität bringt.

@SenorKaffee
Wäre es nicht zielführender einen Robot auf einem dedizierten Router laufen zu lassen,
(wifimesh-node, ohne meshvpn, etwas mehr Ram/Flash, vielleicht USB-Speicher, den man tauschen kann, wenn kaputtgeschrieben) der
a) schaut ob es überhaupt noch „IPv4 per DHCP“ in der Domain zu bekommen ist
b) schaut, ob er via IPv4 ins Internet kommt (nach draußen)
c) die Nodes in batctl o zählt (auf plausibilität)
d) die zu überwachenden Nodes mit einem batctl p anspricht.

Wenn diese 4 Bedingungen erfüllt sind, dann würde zumindest ich davon ausgehen, dass ein Knoten auch für dahinterliegende/angeschlossene AP-Clients nutzbar ist.

(Das würde die Überwachung der Nodes von dem Wackel am „inbound IPv6“ wegführen, das meiner Meinung nach zumindest teilweise sehr irreführend ist.)

1 „Gefällt mir“

Wie würde ich a/b auf dem Gerät überprüfen?

Wenn ich Google anpinge, mag er z.B. nur ping -6, nicht ping -4.

Klar, weil Du keine IPv4 auf einem WifimeshOnly-Node hast.
(auf einem vpn-mesh würde es nix bringen, da auch der keine FF-IP hat)

So, wie ich so höre, geht das nicht einfach mit „IPv4 auf br-WHATSOEVER“.
Du brauchst einen weiteren Router unter normalem OpenWRT dafür. Notfalls halt einen alten WR740, den Du als client an die Gelbe eines FF-Routers hängst. Der könnte dann auch gefahrlos ein wenig mehr testen.
Seine Logs könnte der dann per Syslog auf dem größeren nachbar Router über die IPv6-LinkLocal loswerden.

das verrückte daran: manche werden nur als down angezeigt, sind aber up und manche sind tatsächlich nicht erreichbar.

Ich wurde gerade ganz analog und Angesicht zu Angesicht darauf aufmerksam gemacht, dass ein Freifunk Zugang seit Samstag keine Internet Verbindung herstellen würde. Ob ich das irgendwie erklären könnte.

Nicht wirklich.

Ich habe für mich beschlossen, erst dann wieder Router zu flashen bzw. an Mann & Frau zu bringen, bis hier ganz offiziell von berechtigter und kompetenter Seite gesagt wird, dass man nun mit ruhigem Gewissen und aus voller Überzeugung die Freifunk-Sache vertreten kann.
(Ich weiß dass niemand 25 Stunden Tag und Nacht Zugang versprochen hat - und ich werde jetzt auch nicht sagen „halbes Freifunk ist gar kein Freifunk, Einhaltung von picos gentleman agreement“)

Es lässt sich ein Script auf die Router spielen, das dafür sorgt, dass das (öffentliche) Accesspoint-Wlan abgeschaltet wird wenn der Weg ins Internet defekt ist. Dann wären die disfunktionalen Knoten wenigstens unsichtbar.
Siehe Gluon: Freifunk SSID bei fehlendem Uplink automatisch umbenennen - #20 von MrMM

Dafür bräuchte es einen ssh-Login auf den Routern, um nach jedem FW-Update das Script (und den cronjob) wieder (halbautomatisch) einspielen zu können.

[quote=„adorfer, post:6, topic:559, full:true“]
Es lässt sich ein Script auf die Router spielen…
Dafür bräuchte es einen ssh-Login auf den Routern, um nach jedem FW-Update das Script (und den cronjob) wieder (halbautomatisch) einspielen zu können.
[/quote]Dazu müsste ich rund 20 Geräte einsammeln was sehr mühsam, zeitaufwändig und wenig vertrauenserweckend ist.

Dann müsste ich mir eine Erlaubniserklärung (die noch formuliert und gedruckt werden müsste) unterzeichnen lassen, was mich erst mal wieder in Erklärungszwang bringen würde. Mir fehlt zur Zeit das nötige Vertrauen in die Technik und das Projekt Freifunk, um das mit dem wünschenswerten Überzeugungsdruck zu machen.

Mir scheint dass die Freifunkgemeinde keine abschließende Meinung darüber hat, ob solch ein script wünschenswert ist, ich würde wahrscheinlich also wieder irgendwelche ǵeschriebenen oder ungeschriebenen Gesetze übertreten, wozu ich keine Neigung verspüre.

Wenn ichs recht verstehe, würde es trotzdem eine Dauerbeschäftigung bleiben, weil es immer wieder händisch erneuert werden müsste? Somit unpraktikabel.

Die Lösung kann meiner Meinung nach nur sein, dass ein zentral gesteuertes Firmware Upgrade gefahren wird, das die bekannten bugs, die jetzt schon behoben sind, sofort behebt.

Technisch ist mir das ein Rätsel, dass man z.B. im Falle einer Pressekonferenz ein temporär funktionierendes Freifunk gewährleisten kann und danach dann alles weitgehend zusammen brechen lassen kann.

Ich habe gerade den Zugangspunkt Abrazo überprüft. Nach wie vor keine Verbindung ins Internet, alle Nachbarknoten sind über Alfred erreichbar. Nadeshda zeigt Status „UP“ und 100% Replies an.
Über Alfred sehe ich auch, dass mehrere (viele) Router, die definitiv nicht abgeschaltet werden, erst zwischen 8-13 Stunden online sind, andere dagegen zwischen 300 und 700 Stunden.

Also, anstatt irgendwelche Skripte zu installieren würde ich diesen Problemen auf den Grund gehen. Alle paar Minuten Up and Down sieht sehr seltsam aus und ich kann mir nicht vorstellen, dass es an der Freifunk-Infrastruktur der Domäne Ruhrgebiet liegt.
Mein Node hier war neulich auch mal nicht erreichbar, aber nicht täglich oder gar mehrmals am Tag.

Und dann frage ich mich, wer die Nodes betreibt. Bist du das, @Enrique? Dann bräuchtest du keine Einverständniserklärung, remote auf die Notes zugreifen zu können, sondern dass die Besitzer einverstanden sind, dass du die Nodes betreibst. Betreiben ohne Remotezugang geht nicht!
Oder betreiben die Besitzer die Nodes selbst? Dann müssten sie sich kümmern…

[quote=„Reka, post:8, topic:559“]
Oder betreiben die Besitzer die Nodes selbst?
[/quote]Sorry dass ich die Begrifflichkeiten nicht differenzieren kann.
Manche haben die Router gekauft von mir bzw. über mich. Manche haben sich dem Thema nicht gewidtmet - und sich den Router als Dauerleihgabe ins Fenster stellen lassen.
Uecker und Abrazo haben die Router gekauft, sind also dann Betreiber und Besitzer?

Nachtrag: ich habe keinen SSH / Passwort / Remote Zugriff eingerichtet

gekauft bedeutet erstmal nur Besitzer. Und wenn ihr nichts anderes abgemacht habt, müßten sie auch Betreiber sein.
Kläre mit ihnen, ob du die Dinger für sie betreiben/warten sollst, wenn ja, musst du dir einen SSH-Zugang einrichten. Anders wirst du es nicht können.

Dort wo eine Leihgabe steht, kannst du sie nicht einfach austauschen?

wie oben beschrieben, alles mit Arbeit, Zeit etc. verbunden - an manche Geräte komme ich nur mit Mühe. Ich habe in den nächsten Tagen anderes zu tun, genau in Lokal in dem seit Samstag nix geht, finden am 13. und am 19. wichtige, entscheidende Versammlungen statt. Dafür muss ich noch einige Vorbereitungen treffen. Ich freue mich schon auf das Gestammel von mir, wenn ich erkläre warum das alles gerade nicht funktioniert.

Ich kann ehrlich gesagt nicht glauben, dass nur bei mir hier dieses Problem so gehäuft auftritt.

Hier von gerade:

und noch einer:

Das Script funktioniert nicht, es schaltet das gesamte WLAN ab. Geräte die hinter einer Node hängen müssen dann manuell neu gestartet werden da auch das Mesh Interface abgeschaltet wird.
Bitte verbindet keine Bastelscripts mit Gluon. Wenn es ein unterstütztes Feature sein soll dann bitte als Gluon Modul releasen und keine „Dann installier das hier mal manuell“ Anleitungen mehr :wink:

1 „Gefällt mir“