Es bringt vor allem nichts, selbst wenn die CPE210 oder der 1043er nicht in Panik rebootet: Wenn irgendwo mehr als 30 clients drauf sind, dann ist der AP nur noch damit beschäftigt, alle im Netz online zu halten und die v6-Neighbor-Discoveries und anderweitige Broadcasts herumzusenden. Nutztraffic ist dann nicht mehr sinnvoll möglich, auch wenn’s auf der Karte vielleicht toll ausschaut mit den vielen Punkten am Knoten.
(Ist aber ein anderes Thema…)
Das ist für mich die letzte Option:
„Edgerouter X“ als VPN ubd einen AP mit Stock dran…
Nur trifft es auch die Nanos…
Selbes Phänomen.
Respondd frisst ab >35 Clients den Speicher auf
So, haber das Problem mal genauer beobachtet (aktuell sehr schön zu sehen , da ich einen CPE v1.1 als Freifunk AP bei uns im Kulturzelt aufgebaut habe)
Szenario 1: LTE-Router → CPE 210 v1.1 mit 2018.2.1 (ohne custom Patches; 1 Supernode GW fastd)
…-> OOM Kernel Panic nach >25 Clients
Szenario 2: LTE Router → UBNT Edge Router X mit 2018.2.1 (ohne Custom Patches, 1Supernode fastd) -MOL-> CPE 210 (wie oben)
Auslastung UBNT ERX <20%
Auslastung CPE ~50 %
…läuft eine weile (auch mit >35 Clients), dann irgendwann nach vielen an-/abmeldungen (laut logread) schiesst der RAM Verbrauch innerhalb von wenigen Sekunden nach oben —> OOM Kernel Panic (CPE)
Der ERX läuft gechillt weiter…
Immer respondd, was den Speicher auffrist.
Morgen hänge ihc mal eine CPE mit Stock FW auf und Lasse den UBNT ERX das FF-Netz bereit stellen… (habe dann zwar kein Mesh, ist aber als „Testobjekt“ zu sehen, ob der ERX dann auch zu kämpfen hat)
1 „Gefällt mir“
wieviele Ipv6-Prefixe und/oder Supernodes habt ihr in Eurem Layer2-Netz?
Das dürfte in vielen Freifunk-Communities keine valide Option sein, weil dann nicht über Funk gemescht werden kann.
Der hat auch 256 MB RAM im Vergleich zu den 32 MB der 841er.
Streng genommen könntest du respondd auch einfach abschalten. Dann sind die Router halt Karteileichen auf der Karte. Aber besser als wenn das Netz nicht nutzbar ist.
Ich liebe diese „Dark-Nodes“… Aber man soll ja nie Vorsatz unterstellen.
Aber wenn man mal so schaut wie das Verhältnis zu batman-Knoten zu Map-Knoten ist, da bekommt man doch schon Stirnrunzeln. (Ja, ich weiss, dass interne Server/Supernodes ohne accounce-Tool auch „dunkel“ sind für Map)
Aber ganzu nur Not gibt es ja noch den „Graph der alten Schule“.
Es Betrifft auch die Nanostation, CPEs und 1043er.
Die haben 64MB oder nicht ?
Wir haben einen 941er mit 2016.2 laufen der muss teilweise >70 CLients fassen , der macht allerdingskein reboot… (Klar Nutzbare Bandbreite ist da nicht mehr viel aber er bleibt am leben und läuft eben nicht durch ein OOM)
RAM-Auslastung ist bei dem ~85-90% bei >70 Clients
und das macht mich so stutzig
Und klar, kann man an den ERX ein Mesh über ein sep. Port und eigenen AP (der eben nur WIFI MESHed) dran hängen . haben wir auch einige
Da häng ich mich mal dran ohne einen neuen Thread auf zumachen.
Das Rebootproblem habe ich auch … allerdings mit einem WDR4300v1 und gluon-v2018.2.1.
zeigen schön wie plötzlich das freie RAM schwindet und ein Reboot erfolgt.
… und das bei 100MB RAM !!!
hast Du mal geschaut, ob es im letzten Moment vor der Panik noch was per „logread“ (also „logread -f“ offen sehenlassen) gibt?
Oder wenn’s die Panik-Meldungen nicht mehr durch den Netzworkstack schaffen: Bitte mal mit der serialconsole auf dem PCB schauen.
Sorry, ich hab das erst abends in Grafana gesehen als alles längst durch war.
Da aber respondd noch bis zu letzt Daten meldet, denke ich am network-stack geht noch bis zum Schluss alles durch.
Ich komme an das Ding höchstens per SSH dran. Ich werde mal das mesh-radio0 und 1 aus machen und hoffen, dass das Schwimmbad wieder voll wird. Dann schau ich per SSH auf das logread.
Hat jemand ein Skript, was per Webhook bei nem Trigger Infos von logread raus hauen kann? Dann bekomme ich ne Info auf Telegram wenn es los geht.
So, hat geklappt. Rebootet aktuell wieder mehrfach nach RAM-Mangel. Der Logread-Mitschnitt ist hier:
Grafana sagt ab ca. 16:15 geht das freie RAM kontinuierlich zurück.
https://pastebin.com/xpix93ik
1 „Gefällt mir“
Verstehe ich nicht …
Eine spannende Frage wäre: Ist der Knoten in dem Moment wo der ebtable-arp-limiter seine batctl-calls nimmer durchbekommt bereits in der Todesspirale und die vielen fehschlagenden Calls sind nur noch ein Symptom oder sorgt die davon verursachte Last dafür, dass das System final abkippt.
Wenn das RAM bereits um 16:15 verloren geht ist der arp-limiter nur Symptom.
ARP, ja das dachte ich mir auch schon.
Gerade weil es dann auftritt, wenn viele An-/Abmeldungen erfolgen. Die Einträge müssen ja erst TTL erreichen, bis sie raus geworfen werden.
Ich denke mal, das mangels Ram , batctl nicht mehr aufgerufen werden kann.
Oder es ist der Limiter an sich…
Weil ich ja sagte, bei 2017.1.x hatten wir die Probleme nicht (Gleiche Hartdware / Gleicher Standort)
Eben genau nicht ARP, lies nochmal nach.
Hallo.
Ich beobachte das gleiche Phänomen. Wir versorgen hier die Liegewiese eines Freibads u.a. mit 3 NSM Locos, 2 mit xm und 1 mit xw Hardware.
Mit 2017.1.x kamen die xm-Locos erst bei >70 Clients aus dem Tritt, mit der 2018.2.1 bereits ab ca. 30-40. Die xw-Loco macht aufgrund des größeren RAM erst ab ca. 60 Clients Probleme.
Ich habe auf allen dreien logread -f mitlaufen lassen, in fast allen Fällen bekomme ich vor dem Reboot keine Fehlermeldung. In einem einzigen Fall konnte ich folgendes mitschneiden:
Tue Jun 25 14:24:00 2019 daemon.info hostapd: client0: STA 24:18:1d:a5:f1:df IEEE 802.11: authenticated
Tue Jun 25 14:24:00 2019 daemon.info hostapd: client0: STA 24:18:1d:a5:f1:df IEEE 802.11: authenticated
Tue Jun 25 14:24:00 2019 daemon.info hostapd: client0: STA 24:18:1d:a5:f1:df IEEE 802.11: associated (aid 18)
Tue Jun 25 14:24:00 2019 daemon.notice hostapd: client0: AP-STA-CONNECTED 24:18:1d:a5:f1:df
Tue Jun 25 14:24:00 2019 kern.info kernel: [75504.475761] do_page_fault(): sending SIGSEGV to odhcp6c for invalid read access from 0000002c
Tue Jun 25 14:24:00 2019 kern.info kernel: [75504.484592] epc = 0040451d in odhcp6c[400000+8000]
Tue Jun 25 14:24:00 2019 kern.info kernel: [75504.489724] ra = 004044e9 in odhcp6c[400000+8000]
Tue Jun 25 14:24:00 2019 daemon.notice netifd: Interface 'client' has lost the connection
Tue Jun 25 14:24:01 2019 daemon.warn dnsmasq[706]: no servers found in /tmp/resolv.conf.auto, will retry
Tue Jun 25 14:24:01 2019 daemon.info hostapd: client0: STA 00:b5:d0:ea:4f:af IEEE 802.11: authenticated
Tue Jun 25 14:24:01 2019 daemon.info hostapd: client0: STA 00:b5:d0:ea:4f:af IEEE 802.11: associated (aid 66)
Tue Jun 25 14:24:01 2019 daemon.notice hostapd: client0: AP-STA-CONNECTED 00:b5:d0:ea:4f:af
ssh: Connection to root@2a03:2260:120:300:6a72:51ff:fe44:834b:22 exited: Error reading: Connection reset by peer
Vielleicht ist die Fehlermeldung hilfreich.
P.S.: der 1043er im Kiosk schmiert nun auch ab ca. 30 Clients einmal pro Stunde mit plötzlich vollaufendem Speicher ab. Alle o.g. Geräte hängen an einem Offloader und Wlan-Mesh ist zur Zeit deaktiviert. In der lokalen Wolke sind insges. ca. 200 Clients.
Wir haben auch auf vielen Nodes ab circa 30-40 Clients reboots.
Hier im Moment sehr prominente Beispiele:
https://map.ffmuc.net/#!/en/map/60e327edfb5a
https://map.ffmuc.net/#!/en/map/98ded0a79164
https://map.ffmuc.net/#!/en/map/68725132e37f
Auch hier keine Fehler im logread -f die Nodes sind aber auf einmal weg und kommen dann wieder.
Das ist schön, wie sich hier Meldungen sammeln, ich wünsche mir aber mehr Beteiligung im Upstream Bugreport, damit wir das Problem weiter eingrenzen können.
Dafür sind zum jetzigen Zeitpunkt Beobachtungen in dmesg und logread, sowie Muster in den betroffenen Geräte, Chipsätzen, usw. überaus hilfreich.
1 „Gefällt mir“
Ich Stimme Dir zu, allerdings bin ich da noch etwas ungeübt. Software backen und aus meiner beruflichen Tätigkeit in Sachen IT Infrastruktur kenne ich Die Layer 2/3 problematiken.
BATMAN / fastd usw. Sind für mich auch Neuland.
Geht schon los, das ich es bisher noch nicht hinbekomme habe, einen eigenen. Supernode zum testen aufzusetzen.
Taste mich da langsam ran.
Nutze daher gerne hier das Forum um mich weiter nach vorne zu bringen…
EDIT: Hab gesehen das du das gemacht hast. Danke