Ist es nicht nicht mehr. Funktioniert einfach.
zu „Fastd vs. L2TP“: ja, aber kein spezielles R6120-Problem.
Das Thema ist meist in höchstem Maße politisch aufgeladen und sollte besser innerhalb der jeweiligen lokalen Community diskutiert werden. Jegliche Einmischung von Ortsfremden wird meist als störend empfunden.
Das kommt darauf an, welche Firmware du benutzt und in welcher Version, je nachdem ist der mt76 Treiber vielleicht neu genug, dass auch Mesh brauchbar funktioniert.
Ich habe sowohl 4.0 als auch 4.1 da, was genau soll ich wie messen?
Im Spontantest des C50v4.1 gegen einen WDR4900 gingen 21 MBit/s über das 2,4 GHz Mesh und 30 Mbit/s über das 5 GHz Mesh. Letzteres könnte auch die Grenze dessen sein, was der WDR4900 über fastd schafft. Muss ich noch extra mit einem Futro testen oder reicht das um „massive Probleme“ zu widerlegen?
Wie ist denn Eure Erfahrung mit dem R6120 in einem WLAN-Mesh? Also wenn der Node seinen Uplink über WLAN-Mesh bekommt? Bei mir (ffmuc Firmware, aktuell ist das Gluon v2018.2.2) geht das nur vernünftig, wenn ich 5Ghz Mesh abschalte. Ansonsten ist der Downstream aus mir unerfindlichen Gründen bei ca. 500 kbit/s gedeckelt, während der Upstream den Erwartungen entspricht.
Also ich hab im Mesh via 2,4Ghz mit einem 741 keine Probleme gehabt und die 10Mbits, die der 741 kann, auch durch bekommen auf beiden Bändern.
Btw:
Kurz mal als Übergangslösung zusammengeklöppelt.
Geht beim 6120 viel einfacher als beim 841 damals. Die Antennen lassen sich abmontieren und passen direkt in die Verschraubungen.
Heißkleber kann man schön auf die Kühlkörper schmieren und bekommt es dann auch wieder los.
Bleibt erstmal so bis ich ne preisgünstige AC Mesh aufgetrieben habe.
Er macht mol mit einem Er-X.
Habe den R6120 nun auch seit ungefähr 2 Wochen, und bislang einen gemischten Eindruck.
Maximal kommen ca 10 Mbit/s (bei 25 Mbit VDSL Anschluss) bei den Clients an (egal ob 2,4 oder 5 GHz).
Jedoch ein richtiges Problem:
Bereits 3x ist es vorgekommen, dass die „Load“ des Routers über Stunden und Tage bei 1,0x liegt (kein Client verbunden, keine Mesh Links). Die WLAN-Clients welche sich versuchen zu verbinden, bekommen entweder gar keine IP oder nur ganz kurz eine (?).
In den Logs erscheint immer dies hier:
Mon Sep 9 01:11:28 2019 daemon.info hostapd: client0: STA 90:f1:aa:da:dc:8f IEEE 802.11: authenticated
Mon Sep 9 01:11:28 2019 daemon.info hostapd: client0: STA 90:f1:aa:da:dc:8f IEEE 802.11: associated (aid 1)
Mon Sep 9 01:11:28 2019 daemon.notice hostapd: client0: AP-STA-CONNECTED 90:f1:aa:da:dc:8f
Mon Sep 9 01:11:34 2019 daemon.notice hostapd: client0: AP-STA-DISCONNECTED 90:f1:aa:da:dc:8f
Mon Sep 9 01:11:34 2019 daemon.info hostapd: client0: STA 90:f1:aa:da:dc:8f IEEE 802.11: authenticated
Mon Sep 9 01:11:34 2019 daemon.info hostapd: client0: STA 90:f1:aa:da:dc:8f IEEE 802.11: associated (aid 1)
Mon Sep 9 01:11:34 2019 daemon.notice hostapd: client0: AP-STA-CONNECTED 90:f1:aa:da:dc:8f
Mon Sep 9 01:11:39 2019 daemon.notice hostapd: client0: AP-STA-DISCONNECTED 90:f1:aa:da:dc:8f
[…]
root@ffka-fritz-erler-strasse:~# uptime
12:29:19 up 3 days, 17:53, load average: 1.09, 1.03, 1.00
„top“ berichtet: Der Prozess „ksoftirqd/0“ erzeugt ständig zwischen 95-99% CPU-Last.
root@ffka-fritz-erler-strasse:~# cat /proc/interrupts
CPU0
4: 21439445 MIPS 4 mt76x2e
5: 19732095 MIPS 5 10100000.ethernet
6: 22046798 MIPS 6 mt7603e
7: 33186592 MIPS 7 timer
25: 7 INTC 17 esw
26: 1 INTC 18 ehci_hcd:usb1, ohci_hcd:usb2
28: 12 INTC 20 ttyS0
ERR: 47558
root@ffka-fritz-erler-strasse:~#
Habt Ihr eine Idee? „Einfache“ Lösung ist ein reboot des Routers, es geht um diesen hier:
https://stats.karlsruhe.freifunk.net/d/000000021/router-meshviewer-export?orgId=2&var-node=1459c0c70460&from=now-7d&to=now-1m&refresh=15m
Gestern Abend gab es die hohe Last ab ca 21:40 Uhr, (1 Client connected). Dieser hat aber zufällig in der Zeit von 5 GHz auf 2,4 GHz gewechselt… Zufall?
Habt Ihr auch ähnliche Probleme?
Firmware 0.7.4-stable / gluon-v2017.1-827-g76eda123
bitte einmal den output von
brctl show
batctl ifroot@ffka-fritz-erler-strasse:~# brctl show
bridge name bridge id STP enabled interfaces
br-client 7fff.1459c0c70460 no eth0.1
local-port
bat0
client1
client0
br-wan 7fff.0eca14052e28 no eth0.2
root@ffka-fritz-erler-strasse:~# batctl if
primary0: active
mesh0: active
mesh1: active
mesh-vpn: active
root@ffka-fritz-erler-strasse:~#
ich hatte jetzt spontan auf „MoW“ und „ClientLan“ gleichzeitig aktiv auf den Lanports getippt:
Leider/zum Glück nicht.
Aber was dann? Habt ihr evtl auch ein 2018.2er-Gluon für die Geräte, und sei es „nur“ beta/experimental? 2017.x hatte solche Loadeffekte wirklich massiv, auch auf anderen Routermodellen.
Danke dir, ich frage Mal bei uns nach.
Das kann kein 2017.x sein, dort wird der R6120 nicht unterstützt. Die Build-ID gluon-v2017.1-827-g76eda123 deutet daraufhin, dass es ein deutlich neueres Gluon ist, nur jemand die neueren Git Tags nicht mitgezogen oder gepushed hat.
zur Load-Sache: Wir hatten ja auch Fälle, wo viel ARP-Traffic auf dem WAN-Port (also in dem LAN, dass den Internet-Uplink bereitstellt) zu hoher Load geführt hat.
Leider hat das bisher niemand versucht systematisch nachzustellen (Trafficgenerator oder so)
Könntet ihr testeise mal eine Version bauen mit „zram an“?
Wir haben bei uns das auch für die 64MB-Geräte angeschaltet und evtl. daher den Effekt noch nie gesehen.
Zumindest das kann man hier ausschließen: Der R6120 hängt am „Gäste-LAN Port“ der Fritzbox, hat ein komplett eigenes 192.168.179er Netz. Auch per WLAN ist sonst kein Client eingeloggt.
Wegen „zram an“ frage ich Mal nach, danke soweit!
Gestern hatte er plötzlich wieder eine hohe Load, und hat diesmal sogar seinen VPN-Tunnel verloren. Zumindest war er nicht mehr von außen erreichbar; der eingebuchte Client hatte zwar noch WLAN, aber kein Internet.
ich hab nu 30 stk im netz.
z.b.
http://statistik.freifunk-nordheide.de:3000/d/fLurVy4Zk/node-stat-1-minute-interval?orgId=1&var-nodeid=78d2947bfdc8
da zickt nicht einer …
Wow nicht schlecht 
Wie viel Durchsatz schaffen denn deine? Bei mir ist leider (egal ob ein Client oder mehrere) bei maximal 10 Mbit/s Download Schluss. Scheint ein CPU-Limit zu sein, der fastd Prozess braucht fast 100% CPU
Das wird jetzt wieder zur L2TP-Debatte führen.
Oder zu „checkt eure MTU-Sizes für Fast und das MSS-Clamping auf den Supernodes“. (oder anders: 18MBit/s mit Fastd sind möglich, am richtigen Broadband-Provider, mit richtig eingestellen Supernodes…)
Eigentlich bin ich aber auch der Meinung: Für den Preis (ist halt das LowEnd-Einsteigendengerät) ist es schon schnell.
OK OK, wollte keine hitzige Debatte anzetteln 
Finde jedoch diese „maximal zu erwartende Bandbreite“ könnte auf der Hardware-Übersichtsseite stehen. Hätte mir sonst einen schnelleren gekauft
Ich werde meinen heute Abend mal auf fastd umflashen und schauen, was der dann liefert.
Wir haben Speedtests von einigen Routern gemacht:
Me2: