Moin zusammen.
Hat jemand Erfahrung mit dem Zyxel Outdoor NWA55AXE in zusammenspiel mit der neusten Gluon-Version ?
Mit der Annahme, das darin ja ein MediaTek MT7621 werkelt (klassich wie ein ER-X Router), genug RAM zur Verfügung steht, dachte ich man könnte damit ein kleines Event ausleuchten (Installiert waren 3 NWAs; 5Ghz im Outdoor Mode HE40, 2,4 GHz klassich mit Mesh und FF SSID, HE/HT20)
Alle Knoten machten VPN null@l2tp
Beim Einrichten/Testen (max. 10 Clients in der Wolke) war alles bestens. Durchsatz via 5GHz Wlan ~ 130mbit
Als dann das Event im vollen Gang war (>70 Clients per AP) ging nix mehr . Nahezu keine Perfomance mehr, auch im Monitoring (Status Page) machte jeder AP ~ 12-20 MBit/s.
Teilweise konnten clients nicht mehr connecten, teilweise keine IP und wenn kamen laut Speedtest nur (DL/UL) 2,04/0,13 MBi/s durch.
Gateway und Anbindung waren dennoch sauber. (Anbindung war Gigabit GoeTel) – Währen des Event am GoeTel (bei voller User Zahl) 761 down / 104 up
Erst zum Ende (per AP ~ 20 Clients) ging wieder alles.
Hat da jemand ähnliche Erfahrungen ?
Bei einem selben Szenario (ER-X → Stock Unfi APs) geht dann trotz Last noch ordentlich was durch)
An was könnte es liegen ?
Auch die ein Umbau auf AC (HT20/VHT40) änderrte an der Sache nx.
EDIT: Ein UAP-AC-M mit selbiger FW und Setup macht weniger Probleme seitens der Performance (ausser das er eine sehr hohe CPU-Last erzeugt)
Wo waren die Clients, auf 2,4 oder 5 GHz? Was sagte das Airtime-Plugin? 5 GHz auf gleichem Kanal oder auf unterschiedlichen? Anbindung per LAN/WAN oder WiFi-Mesh?
Da hast Du dann aber 1 Offloader und Unifi-Mesh in der Luft, oder?
Zu diesem Zeitpunkt waren alle auf Gluon v2023.2.1
Die Gluon-APs waren alle per GB-LAN am GoeTel-Anschluss angebunden + VPN.
Überwiegend waren die Clients im 5GHz Netz (1/3 - 2,4 GHz, 2/3 - 5GHz). Airtime (zumindest im 5GHz lag so bei ~ 20-55%); Alle APs hatten eigene Kanäle im Oberband (CH:100, 108,124,132 ohne Mesh). 2,4GHz bei uns Community Standart CH:1 + MESH
Ich habe das WIFI-Mesh dann gänzlich deaktiviert → Ohne Verbesserung.
Tag 2 habe - zum Testen - alle Gluon-APs via MoL (also ohne VPN) hinter einen ERX geschaltet, welcher dann VPN und eben MoL auf den restlichen Ports machte → ebenfalls schlechte Wifi-Perfomance.
Tag 3 habe ich dann alle NWAs abgebaut und 2 ER-Xe an denen jeweils 2x Stock Unifi Geräte (UAP-AC-M) dran waren (kein Unifi Mesh, ähnliche WLAN config (auuser auf 2,4 GHz eben Kanäle aufgeteilt und „Prefer 5GHz“ im Manager aktiviert. Da waren im Peak so ~340 Clients online und die WLAN Perfomance war immer noch gut.
Alle Tests wurden mit Smartphone und IMMER im 5GHz Netz vorgenommen
Die CPU-/Speicherauslastung der NWAs war auch im unteren Bereich, so das ich eine Überlastung ausschließen kann.
Was mir aufgefallen war, das einige Clients (iwinfo client1 assoclist) an der Grasnarbe waren (-91dBm) wobei das ja bei immer wieder so sein kann (leute kommen und gehen / verlassen dadurch den Empfangsbereich)
Das dürfte bei 5 GHz nicht stören, aber 2,4 GHz hätte da schon ziemlich ‚zu‘ sein dürfen bei so vielen Clients. FF-Standard-Mesh ist für sowas IMHO nix, da sind Ubiquity oder TP-Link AFAICS besser aufgestellt mit mehrbandigem Relaying der Nachrichten.
Aber ich hätte in der Tat gerne einen ‚Shootout‘ zwischen den verschiedenen Architekturen bzw. WiFi-Chip-Herstellern unter Last — zu den Mediateks gibt es unterschiedliche Berichte zumindest mit OpenWrt/Gluon. Nur sind 200+ Clients ja nicht mal eben so da und auf Events verhalten sie sich auch nicht homogen.
Auch Gluon / batman-adv können/tun mehrbandig per „Interface alternating“ relayen, wenn denn mehrere verfügbar sind: Multi-link-optimize - batman-adv - Open Mesh. Ist natürlich nur der Fall, wenn 5GHz auch vorhanden ist und im indoor Mode ist, mit Kanälen ohne DFS.
Ja, das ist bekannt, aber dennoch ist das ›FF-Standard-Mesh‹: alles findet auf (beispielsweise) 1 und 36 statt; flexiblere Systeme nehmen optimalerweise z. B. 1/36, 5/36, 5/44, …
Wir haben in FFAC auch eine größere NWA55AXE installation, die das selbe Fehlerverhalten aufweist.
Allerdings stürzt der throughput auch ohne last nach etwas zeit häufiger auf (DL/UL) 2/0.1 MBits ab…
Ich war nie vor Ort, aber das Problem ist auf jeden fall auch mit aktuellstem v2023.2.3 und v2023.2.x noch vorhanden.
Ich werde dort mal den openwrt master testen lassen (bzw gluon-next) - vielleicht hilft das.
Die ramips-mt7621 mt7915e wifi6 Geräte haben bisher noch ein Problem, dass das Wifi unbenutzbar wird - zeitgleich tritt folgende Nachricht im logread auf:
Also on-Stock performen die schon recht gut.
Habe einen bei uns an der Schule laufen, als Stock-AP hinter einem ER-X. Da gibt es keine Probleme. (Clientlast: ~40-60 / peak: >100)
Vorher war dort selbiger mit Gluon-FW,da ging ab >40 Clients nix mehr
Mit der Firmware für den MT7915e hab ich auch schon etwas rumgespielt, brachte aber auch keinen nennenswerten Verbesserungen.
Hab aber gesehen, das sich da wohl einer der Sache angenommen hat (siehe https://github.com/openwrt/mt76)
AFAICS sollte im Gluon v2025.1 zugrundeliegenden OpenWrt sich gerade bei MediaTek-Geräen einiges verbessert haben — aber ich habe das nur am Rande verfolgt …
Du kannst den Patch von diesem PR hier anwenden um das Problem in v2023.2.x zu fixen:
Das ffac-mt7915-hotfix Thema hat sich mit aktuellerem mt76 auch gelöst und ich benutze das Paket nicht mehr. Da müsste man das alte openwrt-23.05 dabei noch patchen um ein aktuelleren mt76 treiber zu benutzen.
Oder eben den Umstieg auf gluon-v2025.1.x anstreben - ist ja mittelfristig eh notwendig.
Die Patches für mt7915 kamen afaik erst später - man sollte also Gluon v2025.1 (basierend auf openwrt 24.10) für die Geräte verwenden. Das ist auch in v2023.2.5 nicht drin.
Ja, zumindest hatte ich den Eindruck beim Blick in einige Gluon-Issues. Wir haben die MT-Geräte daher skeptisch gesehen, fing ja schon mit den 802.11s-Problemen zwischen Atheros(?) und MediaTek an. Derlei, entnehme ich den Release Notes, soll ja in v2025.1 auch zumindest weitgehend gefixt sein. Aber Tests stehen auch hier noch aus …
Wie wende ich den Patch auf OpenWRT23.05 an? Zumindest bei mir sieht der content in
./linux-5.15.189/drivers/net/wireless/mediatek/mt76/mt7915 so “anders” aus, dass ich das auch nicht backported bekomme. (Zumindest nicht mit meinem Klippschul-C, da fehlen ua. ganze Labels auf die sich der Patch bezieht, die schlicht nicht vorhanden sind.)
Oder gibt es da vorher noch was “einmal den ganzen MT7915-Treiber austauschen”-Move?