Wichtige Hinweise
- Du kannst nur von Gluon-Versionen ab 2022.1 oder höher auf 2023.2 und spätere Versionen upgraden. Frühere Versionen werden nicht unterstützt, da internere Migrationen entfernt wurden.
- Das VPN-System Tunneldigger wird in künftigen Gluon-Versionen aus dem Basis-Paket entfernt. Es wird empfohlen, stattdessen fastd oder WireGuard zu verwenden.
- Tunneldigger bleibt aber als Community-Paket verfügbar, falls du es weiterhin möchtest.
Änderungen & Neuerungen
Änderungen bei der Seiten-/Konfigurationsstruktur
- Die bisherigen
GLUON_FEATURESundGLUON_PACKAGESDirektiven in dersite.mkwerden ersetzt durch ein neues Framework auf Basis von Lua. - Damit kannst du Funktionen und Pakete feinkörniger für jedes Zielgerät oder Gerätetyp konfigurieren.
- Bestehende Konfigurationsdateien müssen angepasst werden – z. B. wird statt
site.mkeine Dateiimage-customization.luaverwendet. - Zudem erlaubt dieses Framework, Geräte auszuschließen oder einzuschließen, je nachdem, ob du willst, dass sie gebaut werden oder nicht.
Neu hinzugefügte Hardware-Unterstützung
Gluon 2023.2 unterstützt jetzt zusätzlich (oder neu) folgende Zielarchitekturen bzw. Geräte:
- armsr-armv7 – 32-Bit Arm SystemReady mit EFI-Unterstützung
- armsr-armv8 – 64-Bit Arm SystemReady mit EFI
- Diese Targets ermöglichen, Gluon in virtuellen Maschinen auf ARM-Systemen laufen zu lassen.
- Viele neue Geräte unter ath79, ipq40xx, mediatek, ramips etc.
- Beispiel: Fritz!Repeater 1750E, ASUS TUF-AX4200, Cudy WR3000, Unifi 6 Plus, ZyXEL NWA50AX Pro etc.
Entfernte Hardware-Unterstützung
Einige Geräte bzw. Plattformen wurden aus der offiziellen Unterstützung entfernt:
- Unter
ath79-generic: z. B. TP-Link Archer C60 (v1), RE355, RE450 v1 - Bei Ubiquiti: mehrere airMax-Geräte (NanoBeam, NanoStation etc.)
- Grund: ein ungelöstes Problem mit Write-Protect beim Flashen. Sobald das behoben ist, könnten sie wieder aufgenommen werden.
- Unter
ramips-mt7621: etwa TP-Link RE305 entfällt.
Neue Funktionen & Neuerungen
- TLS-Unterstützung: Mit der
tls-Feature-Option kann Gluon jetzt verschlüsselte HTTPS-Verbindungen für Autoupdater, Paketquellen und andere Dienste nutzen. - EFI-Images: Die Gluon-Builds für x86-64 unterstützen nun EFI-Bootsysteme zusätzlich zum klassischen MBR.
- CAKE mit fastd: Als QoS-Mechanismus kann CAKE (Congestion Aware Queueing) auf Geräten mit mindestens 200 MB RAM aktiviert werden, wenn du Mesh-VPN-Grenzen (Throughput-Limits) setzt.
- Docker-Container: Ein offizieller Gluon-Build-Container steht im GitHub Container Registry zur Verfügung – damit kannst du Gluon-Builds in einem Container ablaufen lassen.
- GitHub Actions: Die Tests für Gluon laufen nun in Docker-Containern, die aus dem Gluon-Build-Dockerfile erzeugt werden.
Behobene Fehler (Bugfixes)
- Fehler beim Reconfigurieren von Interface-Gruppen ohne zugewiesene Rolle behoben.
- Host-Tools wurden während der ersten Kompilierung zweimal gebaut – das wurde korrigiert.
Große & kleinere Änderungen
Große Änderungen
- Basis ist jetzt OpenWRT 23.05.
- Kernel-Version: 5.15.y
- batman-adv: Version 2023.1
- Wireless-Backports: 6.1.24
Kleinere Änderungen
- Für manche Geräte (z. B. D-Link DIR-825 B1) werden keine Factory-Images mehr erzeugt – stattdessen muss man mit einem OpenWRT-Image starten und dann Gluon per Sysupgrade installieren.
- Die
robots.txtverbietet jetzt das Crawlen der Statusseite. - Die Reihenfolge, in der Gluon-Pakete in das OpenWRT-System eingebunden werden, wurde verändert, um Site- und Gluon-Pakete zu priorisieren.
- Bei ausreichendem Update-Fortschritt wird eine Optimierung für IPv6-Multicast im batman-adv-Netzwerk verwendet.
- Hostapd und wpa-supplicant nutzen jetzt mbedtls statt WolfSSL.
Bekannte Probleme & Einschränkungen
- Die Integration des BATMAN_V Routing-Algorithmus ist noch nicht vollständig.
- Beispiel: Mesh-Nachbarn tauchen nicht korrekt auf der Statusseite auf.
- Viele Tools sind noch auf den älteren BATMAN_IV-Metriktyp fest verdrahtet.
- Durchsatzwerte (Bandwidth/Rate) werden mitunter falsch angezeigt, besonders bei virtuellen Interfaces wie Bridges oder VXLAN.
- Bei vielen Ubiquiti-Geräten ist die voreingestellte Sendeleistung (TX-Power) zu hoch – es kann empfohlen sein, diese manuell zu reduzieren.
- Wenn in Konfigurationen kein VXLAN verwendet wird, kann die MAC-Adresse der WAN-Schnittstelle modifiziert werden – selbst wenn Mesh-on-WAN deaktiviert ist.
- Problematisch in Umgebungen mit festen MAC-Adressen, z. B. in virtuellen Maschinen, bei denen Promiscuous-Mode nicht erlaubt ist.


Schreibe einen Kommentar