Fortsetzung der Diskussion von D-Link DAP-X1860 FF_OFFLINE_xxx:
Huh, ja? Welche 1.6.1? Deiner tut mit 1.6.1~44 bei mir nicht (kein WiFi); er funktioniert aber auch mit OpenWrt 22.03.06 nicht (WLAN-Scan hängt) – der Basis für 1.6.1 … Mit OpenWrt 23.05 klappt WLAN, also vermutlich in Problem in OpenWrt 22.03.06. Dein 33332-Ottilienstr-4-edd8 mit 1.6.1~44 reportet auch keine Airtimes …
Also brauchen wir wohl doch ein größeres Testing der 1.6.1er 
Ich hatte die 1.6.1~27 geflashed, damit gings, autoupdate hat es dann auf ~44 gebracht, damit gehts nicht.
Nun zurück auf ~27 und es tut wieder.
Okay, danke; 1.6.1~45 wird dann wieder auf 22.03.05 basieren, baut gerade, 20-40 Minuten je Target (davon gibt es 26 …).
EDIT: Mit OpenWrt 22.03.5 r20134-5f15225c1e tut das WiFi des DAP-X1860 (wieder). Narf, wieso ist das bei OpenWrt niemandem aufgefallen, daß ihre letzte Bugfix-Release ramips/mt7621-WiFi mindestens beim DAP-X1860 karpott macht?
Außer-der-Reihe-Bau des auf 22.03.05 basierenden Images bringt funktionierendes WLAN-Scanning im DAP-X1860 im Config-Mode, bitte, wenn verfügbar, auf ≥1.6.1~45 updaten!
FTR: aufgrund des zeitaufwendigen Buildprozesses (375 - 476 Minuten für einen kompletten Build aller Targets) werden für tng z. Zt. nur noch ath79-generic (›Mainstream‹), ipq40xx-generic (u. a. 4040), ramips-mt7621 (u. a. DAP-X1860) und x86-64 (VMs) gebaut, daß ist in 30-60 Minuten durch. Für ›Release Candidates‹ wird’s dann jeweils komplette Builds geben …
1.6.1~51 hat nun auch die DAP-X1860-Patches für grüne Power-LED mit drin (damit Stand wie zuletzt bei1.5.0), zudem ein funktionierendes Package, daß die 3 RSSI-LEDs oben links an mesh1 bindet (statt wlan1 im OpenWrt-Default, was unter Gluon nicht existiert).
Zudem wird für den ASUS RT-AX53U ein Image mitgebaut, bitte aber die Hinweise/Warnung bzgl. Erstinstallation beachten!
hab nun die ~52
die Power-LED ist grün statt orange 
die 3 RSSI-LEDs sind dauerhaft aus
Moin.
Ich habe meinen ersten Asus AX53U V1 geflasht …
Der Weg war über die SSH-Console der Asus-Firmware und wget … (SCP funktioniert nicht / Anleitung) erst zu OpenWRT und dann zu unserem Sysupgrade-Image. Leider geht bei der Version 1.6.1~58 die Geolocation nicht. Downgrade zu Version 1.6.0~42 … dort die wichtigsten Einstellungen machen, Reboot und per Autoupdater auf die aktuelle Version hoch.
Läuft. 
Der Versuch mit der Version 1.6.1~51 war auch nicht erfolgreich … Die Konfigurations-Seite sprang immer wieder auf »Keine Kordinaten angegeben« zurück. 
Monatswechsel, bei Google hinterlegte KKs waren ungültig, aber das sollte nur bei Lokalisierung per WLAN relevant sein. Gerade probiert, worked like a charme. Bitte noch mal checken, danke.
Ok. Jetzt funktioniert die Lokalisierung wieder.
Beim Reset(Taster) ist mir aufgefallen, das die Lämpchen beim ax53u nicht wie bei TP-Linik alle angehen… oder liegt das an der Firmware-Version? 
Odd, aber danke für’s verifizieren!
Ich glaube einerseits, daß das bei jeder Hardware anders ist — und kann ansonsten zum AX53U nix sagen, da bis Du das Testkanninchen 
TP-Link EAP225-Outdoor-v3
Moin,
ich habe versucht ein Image für den TP-Link EAP225-Outdoor-v3 mit site-ffgt-v2022.1 zu bauen. Da die Patches nicht in der v2202.1.x sind ( draft: ath79-generic: add support for TP-Link EAP225-Outdoor v3 by yksflip · Pull Request #2653 · freifunk-gluon/gluon · GitHub ), habe ich die entsprechenden Änderungen in 2 Patches gepackt: 0103-Add-TP-Link-EAP225-Outdoor-v3-to-Gluon.patch · GitHub und 0102-Add-TP-Link-EAP225-Outdoor-v3.patch · GitHub
Die Patches werden scheinbar auch richtig angewendet, beim kompilieren bekomme ich aber den Fehler:
Configuration failed:
* unable to set 'CONFIG_TARGET_DEVICE_PACKAGES_ath79_generic_DEVICE_tplink_eap225-outdoor-v3="-kmod-ipt-offload -kmod-nft-offload -libustream-wolfssl -libwolfssl -nftables -odhcpd-ipv6only -ppp -ppp-mod-pppoe -wpad-mini -wpad-basic -wpad-basic-wolfssl -firewall4 gluon-core ip6tables-zz-legacy gluon-ebtables-limit-arp gluon-web-wifi-config gluon-config-mode-mesh-vpn gluon-mesh-vpn-tunneldigger gluon-status-page gluon-config-mode-geo-location gluon-ebtables-filter-multicast gluon-web-autoupdater gluon-status-page-mesh-batman-adv gluon-wireless-encryption-wpa3 gluon-web-network gluon-web-private-wifi gluon-radvd gluon-config-mode-hostname gluon-respondd gluon-config-mode-outdoor gluon-mesh-batman-adv-15 gluon-ebtables-filter-ra-dhcp gluon-config-mode-autoupdater gluon-autoupdater gluon-tunneldigger-watchdog gluon-config-mode-contact-info gluon-web-admin ffda-domain-director ffda-name-conformizer ffgt-banner ffgt-config-mode-wizard ffgt-nachtruhe ffgt-preserve-mods ffgt-speedtest ffho-ap-timer gluon-radv-filterd gluon-ssid-changer gluon-web-logging iwinfo respondd-module-airtime tecff-autoupdater-wifi-fallback ca-bundle libustream-openssl"'
* unable to enable device 'tplink_eap225-outdoor-v3'
mit manuellen Änderungen und einem make in gluon-build konnte ich ein Image bauen.
Da ich gerade irgendwie nicht weiter komme mal die Frage hier im Forum: was mache ich falsch?
so nochmal alles neu gemacht und einen Fehler im Patch gefunden (spaces vs. tab ). Nun wurde das Image gebaut, mal gucken ob es auch funktioniert :).
Ich habe den TP-Link EAP225-Outdoor-v3 mit ein paar manuellen Anpassungen zum laufen bekommen, aber leider instabil (Mesh-on-WAN/LAN. bzw. Single bricht regelmäßig weg). Werde den AP erstmal mit Openwrt betreiben und wenn ich wieder etwas Zeit habe mit gluon weiter testen…
Moin Philipp,
schön, das Du hier bist!
Du scheinst Dich mit Gluon und OpenWrt und seiner Build-Umgebung auszukennen — uns fehlt in dem Bereich latent Manpower, falls Du Dich da einbringen könntest, wäre das für uns alle von Vorteil
Zum Thema:
Das deckt sich mit Tom’s Hinweisen (FFRN, Mai 2023):
Kurzer historischer Einschub: /me ist in den Auflösungserscheinungen Ende 2019 angetreten, dem Freifunk Rhein-Necker (e. V.), administrativ über die Straße zu helfen, nachdem die bisherigen Admins ihren Abschied angekündigt haben und über den Kontext kenne ich @TomH — der sich dann auch hier einen Account geklickt hat. @TomH wiederrum ist auch im Freifunk Darmstadt aktiv und in der Gluon-Entwicklung — insofern würde ich ihn via Mentions bitten, ggf. eine aktuelle ›Wertschätzung‹ zum TP-Link EAP225-Outdoor-v3 mit Gluon zu artikulieren
Moin Kai,
ich hätte gerne mehr Zeit um mich einzubringen, aber neben meinen Job, Ehrenamt und der Familie ist das leider nicht machbar. Würde auch nicht sagen, dass ich mich besonders gut mit dem build-system auskenne.
Um das 5Ghz WLAN (ath10k) zum auf dem EAP225-Outdoor-v3 zum laufen zu bekommen, musste ich mit »ath10k-bdencoder« eine neue »board-2.bin« erstellen und auf den AP kopieren (Hinweis dazu hatte ich hier gefunden). Das läuft eigentlich auch. Aber meine LAN-Mesh-Verbindung fliegt nach einiger Zeit immer weg :(. Der AP hängt hinter einer Fritzbox 4040 (Offloader).
Mir ist nicht bekannt das sich die Situation geändert hätte. Mein Sachstand war/ist da unverändert.
In Darmstadt setzten wir aktuell in der Regel auf den NWA55AXE. Die EAP225 sind wir größtenteils los geworden. Leider ist das auch alles nicht problemfrei. Aber es wird sukzessive schon besser.
In Zukunft könnte ggf. noch der Cudy AP3000 Outdoor (v1) interessant sein (hat einen moderneren SoC). Aber habe ich keine unmittelbare Erfahrungen mit dem.
Für mich klingt das jedoch aber auch so als ob sich @piepre sich da tiefer als ich mit beschäftigt hat.