Hallo liebes Forum,
Gibt es aktuell Probleme mit Freifunk Rhein Neckar? Hinter dem Node ffrn-aufaucon-offloader geht aktuell gerade nichts mehr.
Auf die stats.ffrn.de komme ich aktuell leider auch nicht.
Grüße Michael
Hallo, sieht nach einem Problem mit gw04 aus?!
Alle nodes zu gw04 haben aktuell eine Verbindung 40-60%, bei gw09 sind es (wie sonst üblich) so 97-100% Qualität.
Siehe
gw04: Meshviewer - loading...
gw09: Meshviewer - loading...
Sieht so aus, als wäre gestern Abend etwas kaputt:
EDITEDIT:
Wie im " Neue Firmware 1.2.0" Thread schon erwähnt, kommt hierdurch wohl auch die hohe CPU-Last? Gibt es hier Broadcasts oder Ähnliches?
Hier die CPU eines anderen Nodes (hängt an gw04 aktuell):
Das deckt sich exakt mit meinem Problem von ffrn-aufaucon-offloader / gw04.
CPU-Last wird ausgelöst von:
Mem: 35480K used, 24184K free, 132K shrd, 2780K buff, 9728K cached CPU: 0% usr 0% sys 0% nic 36% idle 0% io 0% irq 63% sirq Load average: 0.55 0.68 0.71 2/55 1073 PID PPID USER STAT VSZ %VSZ %CPU COMMAND 2296 1 root R 1216 2% 56% /usr/bin/fastd --config - --daemon --pid-file /var/run/fastd.mesh_vpn.pid
1 „Gefällt mir“
Danke für die präzise Diagnose. Ich hab den gw04 mal durchgetreten. Guck bitte mal ob es jetzt besser ist.
Hi Leah, Problen besteht leider weiterhin und betrifft irgendwie wohl ziemlich viel aktuell.
Grüße Michael
Dann müsst ihr leider warten bis @NurticVibe Zeit hat das zu untersuchen. Ich kann aktuell leider nicht mehr machen.
Habe aktuell in einer Unterkunft das selbe Problem, Offloader hängt an Gw3… gw6 scheint auch nicht zu gehen… 600ms Ping zu Google und webseiten kann man vergessen. eventuell ein Bug in der Firmware?
@leah bei sowas wäre es schön, wenn es ggf. noch mehrere Gäbe die in die Infrastruktur eingelernt wären.
Und so helfen könnten.
Gibt sicher Vertrauenswürdige Personen 
Heute Abend kann ich nichts mehr machen. Und selbst wenn ich was sehe, kann ich dann auch nur Bescheid geben.
Das kann aber grundsätzlich ja jeder. Einfach mal schauen was bei einer unbenutzten Node /am Besten Offloader) an Traffic rein brettert.
Ich würde auf irgendwas tippen, das Amok läuft, ein Router oder eventuell auch ein Client. Sollte sich dann eventuell an Hand der Hardwareadressen identifizieren lassen. Wenn der Traffic immer von der gleichen Maschine kommt.
Beliebt sind wohl auch falsch eingesteckte Kabel - vielleicht gucken alle die die letzen Tage mal ihre Verkabelung geändert haben, ob die wirklich passt oder eventuell Lan mit Wan verbunden wurde.
Was ich noch auf die Schnelle anbieten kann sind ein paar Pings von einer Node aus:
root@ffrn-rgrTestCPE:~# ping -4 gw04.ffrn.de
PING gw04.ffrn.de (88.99.210.123): 56 data bytes
64 bytes from 88.99.210.123: seq=0 ttl=51 time=19.645 ms
64 bytes from 88.99.210.123: seq=1 ttl=51 time=19.691 ms
64 bytes from 88.99.210.123: seq=2 ttl=51 time=21.011 ms
64 bytes from 88.99.210.123: seq=3 ttl=51 time=23.162 ms
64 bytes from 88.99.210.123: seq=4 ttl=51 time=16.929 ms
64 bytes from 88.99.210.123: seq=5 ttl=51 time=21.237 ms
64 bytes from 88.99.210.123: seq=6 ttl=51 time=26.315 ms
64 bytes from 88.99.210.123: seq=7 ttl=51 time=24.598 ms
64 bytes from 88.99.210.123: seq=8 ttl=51 time=18.859 ms
^C
— gw04.ffrn.de ping statistics —
9 packets transmitted, 9 packets received, 0% packet loss
round-trip min/avg/max = 16.929/21.271/26.315 ms
root@ffrn-rgrTestCPE:~# ping -6 gw04.ffrn.de
PING gw04.ffrn.de (2a01:4f8:10a:3b48::4): 56 data bytes
64 bytes from 2a01:4f8:10a:3b48::4: seq=0 ttl=64 time=186.093 ms
64 bytes from 2a01:4f8:10a:3b48::4: seq=3 ttl=64 time=247.844 ms
64 bytes from 2a01:4f8:10a:3b48::4: seq=5 ttl=64 time=244.471 ms
64 bytes from 2a01:4f8:10a:3b48::4: seq=6 ttl=64 time=276.526 ms
^C
— gw04.ffrn.de ping statistics —
9 packets transmitted, 4 packets received, 55% packet loss
round-trip min/avg/max = 186.093/238.733/276.526 ms
root@ffrn-rgrTestCPE:~# batctl n
[B.A.T.M.A.N. adv openwrt-2018.1-5, MainIF/MAC: primary0/6a:01:f2:f8:c5:93 (bat0/60:e3:27:53:08:3e BATMAN_IV)]
IF Neighbor last-seen
mesh-vpn 52:54:00:6e:60:44 3.150s
root@ffrn-rgrTestCPE:~# batctl p 52:54:00:6e:60:44
PING 52:54:00:6e:60:44 (52:54:00:0a:ca:9d) 20(48) bytes of data
20 bytes from 52:54:00:6e:60:44 icmp_seq=1 ttl=50 time=81.39 ms
20 bytes from 52:54:00:6e:60:44 icmp_seq=2 ttl=50 time=38.76 ms
20 bytes from 52:54:00:6e:60:44 icmp_seq=3 ttl=50 time=91.27 ms
20 bytes from 52:54:00:6e:60:44 icmp_seq=4 ttl=50 time=88.95 ms
20 bytes from 52:54:00:6e:60:44 icmp_seq=5 ttl=50 time=58.59 ms
20 bytes from 52:54:00:6e:60:44 icmp_seq=6 ttl=50 time=116.86 ms
Reply from host 52:54:00:6e:60:44 timed out
20 bytes from 52:54:00:6e:60:44 icmp_seq=8 ttl=50 time=61.26 ms
Reply from host 52:54:00:6e:60:44 timed out
20 bytes from 52:54:00:6e:60:44 icmp_seq=10 ttl=50 time=99.36 ms
20 bytes from 52:54:00:6e:60:44 icmp_seq=11 ttl=50 time=49.84 ms
20 bytes from 52:54:00:6e:60:44 icmp_seq=12 ttl=50 time=79.00 ms
Reply from host 52:54:00:6e:60:44 timed out
Reply from host 52:54:00:6e:60:44 timed out
20 bytes from 52:54:00:6e:60:44 icmp_seq=15 ttl=50 time=55.10 ms
^C— 52:54:00:6e:60:44 ping statistics —
15 packets transmitted, 11 received, 26% packet loss
rtt min/avg/max/mdev = 38.757/74.580/116.863/22.685 ms
Paket loss auf batman-Ebene, obwohl die Strecke auf der fastd läuft frei zu sein scheint.
batman Verbindungen zwischen den Gateways auch alle weit weg von 100% zeigt die Karte. (https://map.ffrn.de/#/de/map/d22f9cdd6d44)
Nein und leider noch weniger fähige. Das ist jetzt kein Bashing, aber eine so komplexe Infra inkl. Protokollen etc. ist nichts was du mal eben so verstehst. Zumal das Problem nicht unbedingt an den Gateways sondern in der Firmware liegt.
Wenn aktuell niemand Zeit hat, das Problem zu debuggen, wäre es möglich, die ältere (funktionierende) Firmware als 1.2.1 neu zu veröffentlichen um quasi ein Rollback zu machen? Würde natürlich das Finden des Fehlers erschweren. Aber aktuell scheint Freifunk unbenutzbar zu sein, zumindest an den beiden Orten wo ich das beurteilen kann.
Ich denke diese Herangehensweise macht keinen Sinn, das Problem tritt seit vorgestern Abend auf.
Das Firmware Update ist schon fast 2 Wochen her, ich bin da bei @rgr es wir irgendetwas (ein node oder gateway) wohl “Amok laufen”.
Ich kann vielleicht heute Abend mal debuggen, es gibt jedoch diverse Tutorials fastd zu debuggen, könntest z. B. du auch gerne tun @tobox.
Einfach mal fastd debugging googeln.
Für mich sieht es so aus, als käme das Problem seit vorgestern Abend, und da habe ich im Chat folgendes gefunden:
New Firmware has been released in “nightly” branch with version “1.2.x-20190319”
Bringen vielleicht neue Geräte mit dieser Firmware das Netz zum Wackeln? Oder wurde auch an den Gateways was gepatcht?
Achso, sorry… Dann nehme ich meine Aussage natürlich zurück, hier könnte auf jeden Fall ein Zusammenhang bestehen.
Ich habe dich falsch verstanden, ich dachte es geht um die Stable 1.20.
Aber die drei Nodes mit der 20190319 FW sind eh alle drei seit 12 Stunden offline… Hm…
1 Gerät soll das Ganze Netzwerk so ans Wackeln bringen ? Sollte dann eigentlich nur eine Gateway betroffen sein…? Ich konnte die Probleme ja schon auf 2 Verschiedenen Gateways festellen…
Also ich konnte das Problem anfänglich nur auf GW4 nachvollziehen, dort ging dann gar nichts mehr, seit Wechsel auf GW8 geht wieder alles, die Auslastung ist trotzdem von ~0.3 erhöht auf ~0.8.
GW 4 & 6 Gehen bei mir nicht . Beides Offloader
Also GW09 ist bei mir normal nutzbar. Es ist aber langsamer als üblich. Nur (27 Mbps down und 9,77 Up; Ping ist so wie eh und je bei 30 ms). Normalerweise ist es schon mehr als doppelt so viel. Aber das merkt man bei der normalen Nutzung ja nicht wirklich. Ich schätze mich dann mal glücklich.
fastd ist zwar extrem am rödeln, aber eher wenig gesprächig mit loglevel debug2:
Kurze Frage, wie änder ich nochmal das Gateway ?SSH Zugriff ist vorhanden