WDR3600 Router scheinen länger zu leben…
Das lässt die Vermutung zu, dass hier ein Ressourcenproblem vorliegt.
Ist eine gute Seele in der Lage diese Problematik zu debuggen?
In der momentanen Situation hilft nur das Abschalten der Router. Meine Nachbarn sollen Freifunk als ein stabiles System erleben. Diese Thematik hat meiner Meinung nach höchste Brisanz.
Phillip und ich hatten heute 2 mehrstündige, sehr optimistisch stimmende Gespräche vor Ort mit der Politik und einem größeren Dienstleister.
Bitter, sehr bitter wäre es, wenn diese Aufbauarbeit fahrlässig zunichte gemacht würde, weil hier möglicherweise ernsthafte Probleme nicht kommuniziert werden.
Fairness wäre, wenn man die Leute vor Ort informieren würde, was das Problem ist, wann das behoben ist und ob es nicht sinnvoller wäre, bis dahin das Projekt einzufrieren.
Klingt für mich so, als ob irgendwo im Netz ein Node sitzt, der so viel Broadcast-Traffic macht, dass es die kleineren Router ständig aus dem Netz kegelt oder sie wegen Speichermangels in den Reboot treibt.
Zumal es ja so massiv nur in ffruhrgebiet auftritt, nicht in ffrheinufer.
(und das auch in meinem selbstgestrickten gluon, auf identisch gebliebenden WR841ern, nur eben andere FW… gleiche site.mk-Datei, nur andere Site.conf, also andere fastd-hosts und andere Keys, sonst wirklich ALLES gleich. Sobald die im ffruhrgebiet sind, geht die load auf mindestens das Doppelte bis Vierfache. Und die Dosen booten spätenstens nach 24h neu durch, was in ffrheinufer nicht passiert. Wie gesagt: gleiches git-checkout, gleiche site.mk, gleiche physikalische boards, gleicher Internetprovider, gleicher Routerstandort auf dem Schreibtisch…)
Mal in den Nebel gestochert und den Wind gesprochen - irgendwo sitzt irgendwer und arbeitet an der Lösung des Problems (oder auch nicht - ich kann es ja nicht wissen)
Andere hier bieten ihre Hilfe an - und bekommen keine Antwort - oder habe ich etwas überlesen?
Das Problem scheint eingekreist zu sein - genau das Alleinstellungsmerkmal des Freifunks ( jeder kann Teil des Netzes werden) zwingt nun das Netz in die Knie. Die Kette reißt an ihrem dünnsten Glied - Freifunk erkennt dünne Glieder (defekte Knoten) aber nicht.
Wenig transparent das alles - dafür für mich aber unübersichtlich und undurchschaubar.
Eingekreist ist da nichts. Aber es gibt Anzeichen woran es liegen könnte.
Für mein verstaendnis müssen hier die Armins ran und auf den Supermodels analysieren.
Warum auf den Supermodels? Na das sind gleichberechtigt Nodes die allen Traffic sehen und sind wesentlich leistungsfähiger sind als die kleinen Router (Tools und Performance).
@Enrique: Natürlich ist es unverständlich und undurchsichtig, wenn man nicht so viel technik macht und sich noch nicht so tief eingelesen hat. Aber entweder man nimmt es so hin und betrachtet es nur highlevel oder man steigt ein.
Linux und Netzwerktechniksind hier die Themen (denk ich)
und schaut mal was top so meldet. Nicht, dass ich mich bei Euch auskenne, aber so wie Ihr das schildert leiden die Knoten unter hoher Last und rebooten dadurch. Beobachtet so einen Knoten auch mal mit durchgehend mit logread -f
mein Router ff-kk-reka hat gestern zur etwa gleichen Zeit rebootet! und der Router hat außer seinem Uplink nichts zu tun. Der fast gleichzeitige Reboot betrifft viele Router.
Irgend etwas muss zw. 18 und 19 Uhr diese HW mit der 0.5-FW dazu veranlasst haben, zu booten.
Ich hab noch zwei Router mit entsprechender HW und FW (2014.3-stable-1) in Rheinufer laufen, die haben mehr zu tun und haben eine längere Uptime.
Nachtrag: mein Router hat eine Load von 3-4, sonst lag die Load eher bei knapp 1. Ohne verbundene Clients.
Ob die Last durch fastd, alfred, etc. normal ist, kann ich nicht beurteilen:
Ich weiß nicht ob diese Info wichtig ist:
ein Internetzugang (Alice Box - nun O2) war komplett weg. Der Techniker sagte, dass da Drähte ab und an Kontakt hätten bzw. die Leitungsleistung falsch eingestellt wäre (Dämpfung etc. was weiß ich) es gab merkwürdige Phänomene beim Telefonieren - kurz - es wurde daran gearbeitet und nach einem Kompletten Neustart der Alice Box und des Freifunkrouters ist dieser Knoten nun wieder im Netz bzw. der uplink + Knoten der daran hängt.
Wie gesagt - keine Ahnung ob die Info hilft.
Hi,
The monitor YIN (2a02:f98:0:26:eade:27ff:fe30:2c92) is back UP (Host Is Reachable) (It was down for 30 hours, 15 minutes and 26 seconds).
Ein weiterer Hinweis (auch hier weiß ich nicht ob es wichtig ist) seit Tagen wird ein uplink (Kosmos) der bis dahin korrekt angezeigt wurde, nicht mehr auf der Karte / im Graph angezeigt. Stattdessen wird der Knoten der an ihm hängt (Abrazo) als uplink aufgeführt.
Nachdem mein Knoten auch von den Neustarts betroffen ist, habe mir erstmal mit netcat eine Weiterleitung des syslogs an einen anderen Rechner gebaut. Auf dem (Linux)-Rechner führe ich folgendes aus:
nc -l 2030
Auf dem Freifunk-Knoten dann noch dies hier:
logread -f | nc 192.168.xxx.10 2030
Beides führe ich in einer „screen“ umgebung aus (auf dem Knoten musste ich das mit „opkg update && opkg install screen“ nachinstallieren), damit es auch nach meinem logout weiter die daten schickt.
Ist erstmal eine quick&dirty-Lösung, man kann das bestimmt noch eleganter machen. Aber vielleicht hilft das ja jemandem.
Wenn es wieder einen Absturz gab, werde ich das Log auch hier rein kippen.
Wurde hier eventuell der 2. Rouer in die LAN-Buchsen des ersten, momentan verschwundenen, gesteckt? Er wäre dann Client des Freifunknetzwerkes und zeitgleich FF-Router. Anders kann der Abrazo keinen Tunnel aufbauen… Das wäre nach meinem Verständnis übrigens recht ungünstig für die Domäne.
Hier noch von einem weiteren Router … den hatte ich heute morgen mal ausgeschaltet und eben eingeschaltet. Der war schon out of memory bevor er überhaupt den fastd tunnel gestartet hat.
Beim Logread habe ich auch keinen Prompt mehr zurückbekommen.
Beide Router sind weiterhin per ping6 erreichbar!
Nur SSH geht quasi gar nicht mehr und sie Booten.
Als Konsequenz aus der nicht Funktion habe ich bis weitere Ideen zur Behebung des Problems parat sind alle meine FF Router abgeschaltet.
Vielleicht ist die Wolke auch einfach zu groß …
Wir haben heute im Hintergrund, mit viel Manpower, die Reboot Probleme in der Domäne Ruhrgebiet versucht nachzuvollziehen und zu analysieren.
Die Vermutung liegt nahe, dass es sich um ein Speicherproblem im Zusammenhang mit OpenWRT auf den Routern handelt.
Die vorhandenen 3600er und 4300 er TP-LINK Modelle mit deutlich mehr Speicher scheint es nicht so hart zu treffen.
Es wäre interessant zu erfahren, wie sich die in dem OpenWRT Bug-Ticket beschriebenen Einstellungen verhalten.
Das kann ich bestätigen. Die großen Modelle wie z.B. TP-Link TL-WDR3600 v1 oder TP-Link TL-WDR4300 v1 haben bisher bei mir keine Probleme.
Keine Chance:
sysctl: error: ‚net.ipv6.neigh.default.gc_thresh1=512‘ is an unknown key
sysctl: error: ‚net.ipv6.neigh.default.gc_thresh2=2048‘ is an unknown key
sysctl: error: ‚net.ipv6.neigh.default.gc_thresh3=4096‘ is an unknown key
