Ständige Neustarts in der Domäne Ruhrgebiet

Hallo zusammen,

Geräte der Domäne Ruhrgebiet starten mittlerweile von minütlich bis stündlich neu. Das Netz erreicht damit einen nicht mehr nutzbaren Zustand.

Die Uptimes aus der Alfred-Liste zeigen das Problem:

http://map.freifunk-ruhrgebiet.de/alfred/alfred.html

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.

Gruß
apo

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.

Hallo @Enrique

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) :smiley:

G T

Schickt mal bitte die Ausgabe von

ps w
logread
free

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.

habe logread -f am laufen und mir fällt da grad auf:

2 Likes

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.

Nein, wurde überprüft, kein LAN Kabel dran, außerdem stehen die 7 Meter weit auseinander.

1 Like

zu den ipv6-Meldungen im Log passt, dass manchmal ziemlich viele dhcpv6.script in top auftauchen. Was macht das Script?

So gegen 15:51 hat sich mein Knoten neu gestartet. Mein Log ergibt überhaupt keinen Erkenntnisgewinn:

1 Like

sieht so aus als wäre die kiste gerade erbotet … just in the moment.

der logread nach dem Booten sieht auch nicht pralle aus.

Haben wir hier ein IPv6 Problem?
Oder kommt das über das IPv6 Ndp (Neighbor discovery Protokoll)?

Gruß
THomas

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ß …

G T

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.

https://dev.openwrt.org/ticket/11846

Weitere Infos folgen!

Gruß,
Philip

Hallo,

auf meinem TP-Link TL-WDR4300 v1 sind folgende Kernel Meldungen zu sehen:

Nov 20 18:27:31 FF-E-Bdorf-xx-01 kern.warn kernel: [1205419.820000] ipv4: Neighbour table overflow.
Nov 20 18:27:31 FF-E-Bdorf-xx-01 kern.warn kernel: [1205419.870000] ipv4: Neighbour table overflow.
Nov 20 18:27:31 FF-E-Bdorf-xx-01 kern.warn kernel: [1205419.910000] ipv4: Neighbour table overflow.
Nov 20 18:27:31 FF-E-Bdorf-xx-01 kern.warn kernel: [1205419.910000] ipv4: Neighbour table overflow.

Und auch auf einem TP-Link TL-WR841N/ND v9 sind die Meldungen ähnlich.

Nov 20 18:24:14 FF-E-Bdorf-xxx-01 kern.warn kernel: [ 1177.180000] ipv4: Neighbour table overflow.
Nov 20 18:24:14 FF-E-Bdorf-xxx-01 kern.warn kernel: [ 1177.240000] ipv4: Neighbour table overflow.
Nov 20 18:24:15 FF-E-Bdorf-xxx-01 kern.warn kernel: [ 1177.600000] ipv4: Neighbour table overflow.
Nov 20 18:24:15 FF-E-Bdorf-xxx-01 kern.warn kernel: [ 1177.740000] ipv4: Neighbour table overflow.

Der Unterschied ist nur, das der TL-WR841N/ND v9 dauert rebooted und ich keine Change habe, eine Fehleranalyse durchzuführen.

Gruß Jörg

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

Gruß Jörg