Ich hab ehrlich gesagt den Tunneldigger in Kombination mit den schwachen 32/4 Geräten im Verdacht.
Wenn ich bei mir VPN durch einen 1043er machen lasse und den 841er, der vorher die Auslastungsprobleme hatte, nur im Mesch mitlaufen lasse, tritt der Bug nicht auf.
@corny456, wir könnten mal den alten FFRL-Tunneldigger in die Firmware bauen und gucken, ob die auch auf den schwachen Kisten stabil läuft.
Hier http://[2a03:2260:115:3600:62e3:27ff:fe59:ecc0]/ ist eine 841er der über Mesh-on-WAN an einem 1043er hängt. Zzt. keine Clients aber load > 1.
Hier http://[2a03:2260:115:3600:62e3:27ff:fe59:ecc0]/ ist eine 841er der über Mesh-on-WAN an einem 1043er hängt. Zzt. keine Clients aber load > 1.
Mon Feb 19 12:20:19 2018 kern.info kernel: [252783.115532] br-client: Multicast hash table chain limit reached: bat0
Mon Feb 19 12:20:19 2018 kern.warn kernel: [252783.122537] br-client: Cannot rehash multicast hash table, disabling snooping: bat0, 175, -22
Mon Feb 19 12:56:08 2018 daemon.notice netifd: client (1221): cat: write error: Broken pipeIn der Domäne haben wir den Multicast-Modus von Batman noch nicht abgeschaltet. Evtl. hat das Problem mehrere Ursachen.
Oder es ist doch einfach etwas völlig anderes.
Der 841er hat sich dann wieder von alleine gefangen, im Syslog steht nichts.
Moin!
Leider muss ich berichten, dass nicht nur die kleinen Knoten vom Auslastungsbug betroffen sind. Einen von meinen hat´s getroffen:
Mem: 32732K used, 27548K free, 116K shrd, 2228K buff, 8984K cached
CPU: 6% usr 91% sys 0% nic 0% idle 0% io 0% irq 1% sirq
Load average: 6.42 6.55 6.37 8/61 12119
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
11633 2 root RW 0 0% 84% [kworker/u2:0]
4 2 root RW 0 0% 2% [kworker/0:0]
3 2 root RW 0 0% 1% [ksoftirqd/0]
12174 2 root RW 0 0% 1% [kworker/u2:1]
19017 1 root S 1556 3% 1% /usr/sbin/hostapd -s -P /var/run/wif
959 1 root R 1224 2% 1% /sbin/logd -S 64
12000 11999 root S 1192 2% 0% /bin/sh /usr/bin/sammelscript.sh
11934 11773 root R 1184 2% 0% top
1483 1177 root S 1016 2% 0% odhcp6c -s /lib/netifd/dhcpv6.script
1933 1927 nobody R 1008 2% 0% /usr/bin/tunneldigger -u 8416f95b88a
2191 1 dnsmasq S 2028 3% 0% /usr/sbin/dnsmasq -C /var/etc/dnsmas
17007 1 root S 1980 3% 0% /usr/bin/respondd -d /usr/lib/respon
1177 1 root S 1744 3% 0% /sbin/netifd
966 1 root S 1716 3% 0% /usr/sbin/haveged -w 1024 -d 32 -i 3
1 0 root S 1528 3% 0% /sbin/procd
1725 1 root S 1400 2% 0% /usr/sbin/uhttpd -f -h /lib/gluon/st
19273 1 root S 1188 2% 0% /usr/sbin/crond -f -c /etc/crontabs
2173 1 root S < 1188 2% 0% /usr/sbin/ntpd -n -N -S /usr/sbin/nt
514 1 root S 1184 2% 0% /sbin/ubusd
1645 1177 root S 1184 2% 0% udhcpc -p /var/run/udhcpc-br-wan.pidBevor ich den Knoten boote:
kann ich aus dem laufenden System noch hilfreiche Daten/Infos/Logs extrahieren, die der Usachenforschung dienlich sein könnten?
Edit:
Das Ding hat sich inzwischen selbst wieder gefangen. Was könnte ich beim nächsten Vorfall abfragen?
Also das Problem ist wohl, dass man das auf den 4 MB-Geräten nicht diagnostizieren kann, weil man perf nicht draufkriegt. Ich hab es nicht mehr genau im Kopf, aber ich meine, die Gluon-Entwickler hätten letztens gesagt, dass das auf den 8 MB-Flash-Geräten nicht viel anders ist, weil dem Kernel da einfach die Diagnoseschnittstellen fehlen.
Glaub wir müssen da evtl. doch nochmal ein separates Issue bei Gluon zu aufmachen, weil der Fehler bei uns anders auftritt als in anderen Freifunkgruppen.
Mir scheint, dass der Bug erst nach einer bestimmten Zeit auftritt. Bei mir steigt die Auslastung nach ca. 3 Tagen an.
Im IRC kam noch eine weitere Debugmöglichkeit auf: Selektiv mittels ebtables Traffic abdrehen und gucken, wann die Auslastung sinkt. Dann könnte man das etwas eingrenzen.
Welche Art von Paketen würdest du filtern?
<T_X> hexa-: wenn ihr demnächst nochmal so einen knoten mit hoher load und auch mit ssh zugang habt, könntet ihr einfach mal solange in die "ebtables -t nat PREROUTING" chain solange regeln zum droppen dazu packen, bis die load runter geht?
<hexa-> ^ blocktrron
<hexa-> ja, kriegen wir vermutlich hin
<hexa-> also einfach mal mit sowas wie arp anfangen?
<T_X> genau
<T_X> hier und da einfach mal traffic wegschnippeln. wenn ARP nicht hilft, dann ip4, dann ip6 usw. wenn ip4 zu helfen scheint, dann z.B. icmpv4 wegschneiden. oder auch einfach mal per bitmaske die hälfte aller MAC source-adressen wegfiltern
<hexa-> öh ja, bitmaske … klar x)
<T_X> also ebtables manpage hat ja da so einen eintrag zu "-s, --source [!] address[/mask]"
<hexa-> yep, sehe ich
<T_X> "-s 00:00:00:00:00:00/01:00:00:00:00:00" -> alles unicast. "00:00:00:00:00:00/01:00:00:00:00:01" würde dann schonmal alle mac-adressen wegfiltern, die als letztes bit eine 0 haben
<hexa-> hm ja, da fehlt mir ein wenig wissen wie mac addressen aufgebaut sind
<T_X> oder in vier unicast ranges geteilt: 00:00:00:00:00:00/01:00:00:00:00:03, 00:00:00:00:00:01/01:00:00:00:00:03, 00:00:00:00:00:02/01:00:00:00:00:03, 00:00:00:00:00:03/01:00:00:00:00:03
<T_X> hexa-: ne, das hat damit nix zu tun. hat was mit manpage lesen und verstehen zu tun ;)
<hexa-> buuuh :D
<hexa-> Unicast=00:00:00:00:00:00/01:00:00:00:00:00, Multicast=01:00:00:00:00:00/01:00:00:00:00:00, Broadcast=ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff
<hexa-> ja, gefunden :p
<T_X> sorry, nicht böse gemeint :P
<hexa-> nicht böse angekomen :)
<hexa-> ich weiss mit mühe und not, dass die 33er macs für multicast sind
<T_X> aber so ein vierteln des traffics wie oben genannt könnte auch schon interessant sein
<hexa-> oder so(TM)
<T_X> wenn das problem tatsächlich von einem bestimmten gerät ausgehen sollte, könnte man's mit dem vierteln nach source adressen evtl. schon festtstellen
<T_X> ach ja, und auchwenn ihr alles in der PREROUTING komplett filtert und die load trotzdem noch hoch bleibt, wäre das natürlich äuch interessant zu wissen (sollte man vll. sogar zu erst probieren)
<T_X> alle mac addressen, die _1:, _3:, _5:, ..., _F: haben, sind multicast
<T_X> _0:, _2:, ..., _E: sind unicast
<hexa-> https://md.darmstadt.ccc.de/ffda-ranz-debug# notiert :p
<T_X> (genauer, das erste bit im ersten byte der MAC 0 -> unicast. erstes bit im ersten byte 1: multicast)
<hexa-> top
<hexa-> also ungerade zweite stelle :D
<hexa-> ^ multicast
<T_X> aber ja, 33:33: wird z.B. von ipv6 für multicast benutzt
<T_X> denn _3: hat ja auch das 1. bit im 1. byte auf 0
<T_X> öh, erste stelle, nicht zweite? oder du meinst gerade zweite stelle in der ascii-hex-schreibweise. dann stimmt's wieder :D
<hexa-> jo :D
<T_X> immer verwirrend, dieses bitweise gefummel...Guten Morgen,
Seit Gestern Abend ca. 23.45 Uhr sind ein paar Router offline,
hat es Änderung gegeben die dazu geführt haben könnten.
Gruß Wolfgang
Wir haben gestern abend den Batman Multicast Modus abgeschaltet. Danach haben sich einige Knoten mit 3.2.0 nich wieder verbunden. Wir wissen noch nicht genau warum. Boot tut gut… Danach gehts wieder…
Danke hat geholfen.
Irgendwie müssen wir das nochmal analysieren. Schon komisch, dass die nicht oder nur sehr spät wieder kommen.
Soll aber wohl nur die 3.2.0-Firmware betreffen.
Ich habe hier auf zwei Geräten mit 3.2.0er-Firmware mal testweise das Mesh-Netz abgeschaltet. Ein wifi reload führt dazu, dass iw anscheinend hängen bleibt:
root@ffwaf-[.....]:~# ps | grep iw
17031 root 1076 D iw dev mesh0 delGerade bei meiner Firmware 3.2.1 (mit 11s-Migrierung) gesehen, dass die Meschlinkqualität signifikant niedriger ist als früher.
Sonst hatte ich immer zwischen 90 und 95% bei den beiden Knoten, jetzt sind es gerade mal 75%: http://backend-aegidiistrasse.knoten.ffmsl.de/
Kann das jemand anderes von den Testenden bestätigen oder widerlegen?
Jetzt ohne auf die genaue Domäne drauf schauen zu können tippe ich mal, dass die Version noch nicht signiert ist. Die Router nehmen das Update erst wenn:
Vorher muss erstmal per Hand das update gemacht werden.
Wenn du nicht dringend das update brauchst, ruhig so lassen. Wir brauchen auch Router, die den Autoupdater-Prozess im experimentellen Stadium durchlaufen. Dann ist auch das getestet. 
Gruß
Alu
Dom10. @P4w war das letztens aber auch schon irgendwo anders aufgefallen…
ich bin für schlichtes deaktivieren des altitude Feldes… Brauch eh keiner…
