0.9.0 - 802.11b(ye, bye)

Das Release von 0.9.0 nach beta fand bereits heute Nacht statt. Es stellt unser erstes Release auf Basis von Gluon 2016.2 statt.

Änderungen seit 0.8.8

  • Die Gluon-Basis wurde auf 2016.2.1 aktualisiert
  • Hardware-Highlights:
    • TP-Link Archer C5/C7 gelten nun als stabil
    • TP-Link WR842N v3 wird nun unterstützt
    • Unifi AP AC Lite/Pro werden nun unterstützt
    • Raspberry Pi 1 & 2 werden nun unterstützt
  • Konfiguration
    • PoE Passthrough kann nun auf Modellen, die dies unterstützen, im Konfigurationsmodus aktiviert werden
    • Statische DNS Server werden nun wieder korrekt verwendet
    • Dialoge im Konfigurationsmodus überarbeitet
  • W-LAN:
    • Raten des 802.11b Standards (1, 2, 5.5 und 11 Mbps) werden nun nicht mehr ausgehandelt. Es sollte dadurch zu weniger Links mit schlechter Qualität kommen, außerdem wird in diesen Fällen die verfügbare Airtime geschont.

Bekannte Probleme

Bisher sind keine funktionalen Probleme mit dieser Firmware-Version bekannt. Wir warten derzeit jedoch auf Rückmeldungen zu drei Knoten (64283-Graf, 64665-BS33, 64342-Herrenhaus-Extern), die nach dem Update heute Nacht verschwunden sind.

Hinweis für Nutzer von MAC-Filtern
Mit Gluon 2016.2 hat sich die Generierung der MAC-Adressen für die Netzwerkinterfaces verwendet. Wenn auf WAN-Seite ein MAC-Adressenfilter existiert so muss dieser auf die neue Adresse des WAN Interfaces (br-wan) aktualisiert werden.
Die neue Adresse findet man bspw. per Konsole wie folgt:

root@64283-hackspace:~# ip link show dev br-wan
9: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue 
    link/ether 7e:c6:b1:6e:3a:88 brd ff:ff:ff:ff:ff:ff

Die MAC-Adresse lautet in diesem Beispiel 7e:c6:b1:6e:3a:88.

Sehr cool @hexa danke für deine Arbeit!

Den Knoten habe ich ja bereits geprüft und es gab keine Probleme des Knoten selbst. Es war die custom network konfig mit vlan. Der 64342-Herrenhaus-Extern Knoten ist über ein internes Mesh VLAN angebunden. Dazu wurde an dem Knoten 64342-Herrenhaus-Intern “mesh-lan” auf eth1.X gesetzt was nach dem Update wieder zurückgesetzt wurde.
Nach dem einrichten eines eigenen VLAN Interface für dieses Mesh wurde die korrekte Funktion wieder hergestellt.
FAZIT: Es sollte IMMER ein eigenes Mesh Interface angelegt werden bei Verwendung von VLAN. Dies sollte updatefester sein.

Grüße
Dirk

1 „Gefällt mir“

Ich habe soeben den ersten Beitrag um einen Hinweis für Nutzer, die ihren Router hinter einem MAC-Filter betreiben, erweitert.