ATH9k speicherleck bei 40/60+ clients ("Reboots nach hoher Prozessorlast")

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 Like

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

Hallo.
Wie stellst du bei dir fest dass es der respondd ist?
Ich hatte hier heute testweise auf einer Loco den respondd deaktiviert, aber auch auf dieser ist plötzlich innerhalb von ca. 5 Minuten der Speicher vollgelaufen bis sie sich selbst neu gestartet hat.

Das das ist offensichtlich (siehe Diskussion am Gluon-Issue) alles nur noch das Symptom der „Todesspirale“: respondd-Meldungen, hohe Prozessorlast, ebtables-messages.

Da der Spuk offensichtlich bei Erreichen einer bestimmten Wifi-Client-Zahl auftritt (bei wired-clients nicht) und mit einem einzigen (rechtzeitig eingetippten) „wifi<enter“ kurzfristig beendet werden kann:

Derzeitige Vermutung ist, dass ein Speicherleck im im Wifi-Treiber selbst besteht. (oder hypothetisch auch im Batman, falls der schlicht durch durch die „herausfallenden Wifi-Clients“ auch dort Tabellen gerade noch rechtzeitig reorganisiert. Allerding eher unwahrscheinlich, weil eben wired-clients das Problem nicht zu verursachen scheinen.)

Ich habe das Problem bisher tatsÀchlich nicht beobachtet (oder einfach nicht bemerkt).
Überall wo wir aktuelle Firmware haben, verwenden wir Tunneldigger (L2TP), vielleicht ist das Problem nur auf Nodes mit Crypto so deutlich vertreten?

Alle auffÀlligen Knoten hier werden per Kabelmesh versorgt und haben mit Crypto nichts am Hut.
Unsere grĂ¶ĂŸten Sorgenkinder aktuell
https://map-hemer.freifunk-mk.de/#!v:m;n:68725144834b
und
https://map-hemer.freifunk-mk.de/#!v:m;n:c46e1fc9c410
Es scheinen am ehesten die Knoten betroffen zu sein, an denen viele An- und Abmeldungen per Wlan passieren. Dort wo viele Leute ĂŒber lĂ€ngere Zeit fest eingeloggt sind und nur friedlich Daten saugen scheint die Situation weniger kritisch zu sein.

Ich werde mal die Statistiken prĂŒfen aber ich glaube die Orte die ich bewirtschafte, sind relativ dicht versorgt, haben also eine gute Verteilung. Das höchste bisher waren 35 Clients an einer Nano M2 (2018.2.1), allerdings kein Reboot, dafĂŒr stĂ€ndig wechselnde Clients.
Kabelmesh habe ich nirgends, alle Nodes haben WAN/LAN-Mesh aus, lediglich 11s-Mesh und VPN an.

Kann man das Problem mit Tools unter Linux provozieren, also Fake-Clients erzeugen? Dann kann ich das gerne mal untersuchen.

Mich wĂŒrde aktuell insbesondere interessieren, ob ihr das Verhalten (Memory leak bis reboot ab ~40 Clients) auch bei anderen GerĂ€ten, die nicht ar71xx/ath79 sind, seht.

Könnt ihr euch da mal in euren Communities umsehen?

GerĂŒchteweise haben Leute hier grĂ¶ĂŸere Kisten mit 841ern. Falls also jemand einen halbwegs intelligenten Clientsimulator als factory-image fĂŒr 841v9-11 bauen mag, die man da per PushbuttonTFTP drauf bringt und vollautomatisch ins nĂ€chstbeste „Freifunk“ einbucht und loslegt.

Ich habe keine genaue Vorstellung davon was so ein Handy im Netz tut und was realistische Last ist, aber ich denke mal

  • reichlich DNS zu CDNs (aws, fastly, cloudflare)

  • reichlich offene TCP-connects fĂŒr „Push-Dienste“
    Dieser Transportcontent wird einen Batman-Knoten jetzt eher weniger stressen (evtl. einen lokalen dnsmasq-proxy, aber der ist hier wohl nicht in Verdacht)

  • hĂ€ufige connects/disconnects, evtl. „low-power-keepalives“, was immer Handies so tun um im Halbschlaf Strom zu sparen und nur ab und an bei Whatsapp&Co nach neuen Nachrichten zu schauen.

(Wenn man also so 50 StĂŒck 841er „aus dem Verkehr gezogen hĂ€tte fĂŒr eine Testbench“, wo immer das dann hingestellt wĂŒrde, dann wĂŒrde das bestimmt Leute freuen
 Auf eine Wand gedĂŒbelt könnte man fast ein Matelight draus machen
 Toppoint anyone?)

Offtopic: Na da haste doch ne Verwendung fĂŒr dann :rofl:

Wir haben einen CPE2.0 im Freibad, bei dem das nachvollziehbar ist.
Ab ca 35 Clients, steigt nach ca 12 Min die Speicherauslastung an und der Knoten rebootet dann bei irgendwas ĂŒber 75% Speicherauslastung.
Ein Downgrade von 2018.2.1 auf 2017.1.8 brachte nichts.
dmesg zeigt nichts. Genausowenig gibt es EintrÀge im syslog.
Mit top seh ich nichts auffĂ€lliges - außer dass der freie Speicher dann von ca 33 MB zu dem genannten Zeitpunkt rapide runtergeht und bei ca 10MB rebootet er dann:

Kann ich sonst noch irgendwelche nĂŒtzlichen Infos beisteuern. ?

Ah, der Knoten macht macht vpn mit tunneldigger und hat keine mesh Nachbarn.
Ein wifi-restart gibt den Speicher wieder frei und der Knoten lÀuft wieder 10-15 Min mit konstantem Speicher (auch bei 50 Clients) bis es dann mit dem Speicherverbrauch wieder steil bergauf geht.

Du mĂŒsstest auf Gluon 2016.2 runter, aber das wird natĂŒrlich nix, weil da die CPE210v2 noch nicht drin war.

Jep. Das war auch mein erster Gedanke, bis ich feststellen musste dass es den da noch nicht gab. :crazy_face:

Wenn ich mit irgendwelchen Logs zur Fehlereingrenzung was beisteuern kann, sagt Bescheid.

Die Diskussion lÀuft im Gluon-Issue plus IRC. Es scheint wirklich voranzugehen, der Suchradius nach dem Bug wird dem Anschein nach immer kleiner. Will sagen: Es besteht Grund zur Hoffnung.

Mithilfe benötigt!
GemĂ€ĂŸ Gluon Issue

Issue: ath9k devices run out of memory above certain client count

ist derzeit der Stand: (man korrigiere mich, wenn ich etwas falsch aufgeschnappt haben sollte.)

  • betrifft ATH9k-GerĂ€te (nicht Mediatek oder IPQ) ab Gluon 2017.x (inkl. 2018.2 und master)

  • wenn Clientcount einen (noch nicht nĂ€her gefundenen) Wert ĂŒbersteigt „kippt“ irgendetwas, ab dann verliert der der Router eine ziemlich konstante Menge von MB Ram pro Minute, bis der Speicher so knapp wird, dass a) die Last wegen einsetzenden Swappings ansteigt und b) irgendwelche Prozesse gar nicht mehr starten können (ebtables-Update) aus Ram-Mangel c) final ein Panik-Reboot erfolgt

  • Es gibt zahlreiche Debug-Optionen die zum Testen mit in Openwrt/Kernel eincompiliert werden mĂŒssen um detailliertere Logs zu bekommen als derzeit vorliegen

  • Die Debug-Optionen verlangsamen den Router so arg, dass er kaum noch real nutzbar ist und die „magische Client-Anzahl“ in normalen Produktionsumgebungen gar nicht realistisch erreicht werden kann, weil die Clients schon vorher „aus Frust ĂŒber unsĂ€glich langsames Freifunk“ wieder ins Mobilnetz zurĂŒckwechseln. Ausserdem ist wohl ab und an eine serielle Konsole notwendig, um ĂŒberhaupt noch etwas mitzubekommen.

  • Es Bedarf also akut an Leuten, die

    • Firmware compilieren mögen mit diversen vorgeschlagenen Kernel-Options und/oder patches
    • mit einem zweiten halbwegs leistungsfĂ€higen Router STA-Emulation (also Clients vorgaukeln)
    • Debuglogs ziehen/filtern, also Informationsverdichtung betreiben mögen.
1 Like