[Freifunk-Bonn] [gluon] Gluon Mesh on Lan Problem mit v2022.1.1

[Matthias Schiffer]

On 17/05/2023 22:36, Julian Zielke wrote:
> OK ich habe den Fehler gefunden:
> 
>   
> 
> in /etc/config/firewall war der Abschnitt wie folgt definiert:
> 
>   
> 
> config zone 'wired_mesh'
> 
>         option name 'wired_mesh'
> 
>         option input 'REJECT'
> 
>         option forward 'REJECT'
> 
>         option output 'ACCEPT'
> 
>         list network 'mesh_lan'
> 
>   
> 
> richtig war jedoch die letzte Zeile so:
> 
>   
> 
> config zone 'wired_mesh'
> 
>         option name 'wired_mesh'
> 
>         option input 'REJECT'
> 
>         option forward 'REJECT'
> 
>         option output 'ACCEPT'
> 
>         list network 'mesh_other'
> 
>   
> 
> Gab es hier in Gluon 2022 eine Umbenennung des Interface-Namens? Das würde erklären, warum unsere Community-Konfig veraltet war.

Hallo Julian,

das ist korrekt, in v2022.1 wurde die Bridge umbenannt im Rahmen der 
"role-based interface configuration". Es werden jetzt alle Interfaces, für 
die die Rolle "mesh", aber nicht "uplink" aktiviert ist, in diese Bridge 
gesteckt, unabhängig davon, ob das dem LAN-Port entspricht oder nicht, 
daher passte der Name nicht mehr.

Die Interfaces mit Rolle "uplink" kommen aktuell weiterhin in die Bridge 
"br-wan", um nicht unnötig vom OpenWrt-Default-Setup abzuweichen - ob das 
in den nächsten Versionen so bleibt, kann ich aber nicht sagen.

-- NeoRaider




> 
>   
> 
> Julian
> 
>   
> 
>   
> 
> On 17.05.23, 12:35, "Julian Zielke" <freifunk at databunker.eu> wrote:
> 
>   
> 
> Ich muss meine erste Mail noch korrigieren:
> 
>   
> 
> die einzige IP, welche beim ping vom ersten Knoten antwortet, ist der Offloader, nicht jedoch der zweite Knoten. Aktiv ist dieser jedoch (PoE Passthrough). Ich habe beide Knoten sogar einmal komplett neu geflasht und eingerichtet – leide ohne Erfolg.
> 
>   
> 
> Ich verstehe nicht, wieso nicht zumindest die link-local Adresse des zweiten Knotens antwortet. Unabhängig von der Einrichtung (mesh an/aus) muss das interface ja zumindest eine fe80::/64 Adresse haben, weil dies dem IPv6 RFC-Standard entspricht.
> 
>   
> 
> Folgende Konfiguration ist auf dem ersten Knoten noch aktiv:
> 
> gluon.iface_lan=interface
> 
> gluon.iface_lan.name='/lan'
> 
> gluon.iface_lan.role='client' 'mesh'
> 
>   
> 
> Julian
> 
>   
> 
> On 17.05.23, 12:24, "Julian Zielke" <freifunk at databunker.eu> wrote:
> 
>   
> 
> Hallo,
> 
>   
> 
> der Freifunk Köln/Bonn hat ein Problem seit dem Bau von Gluon 2022, dass Mesh on Lan nicht mehr richtig funktioniert.
> 
>   
> 
> Bisweilen erschließt es sich uns nicht, was das genaue Problem ist. Ein Multicast-Ping auf einem CPE210 gegen das WAN-Interfaces eines nachgelagerten, baugleichen Gerätes funktioniert:
> 
> ping6 ff02::1%vx_mesh_uplink | grep -v fe80::8869:97ff:fe56:f020
> 
> PING ff02::1%vx_mesh_uplink (ff02::1%17): 56 data bytes
> 
> 64 bytes from fe80::7024:93ff:fe39:8a90: seq=0 ttl=64 time=1.482 ms (DUP!)
> 
>   
> 
> Ebenso bekomme ich einen SSH login prompt:
> 
> ffkbu-kalk-west /root $ ssh fe80::7024:93ff:fe39:8a90%vx_mesh_uplink
> 
> root at fe80::7024:93ff:fe39:8a90%vx_mesh_uplink's password:
> 
>   
> 
> Mesh on Lan ist auf dem ersten Knoten aktiv:
> 
>   
> 
> gluon.iface_lan.role='client' 'mesh'
> 
>   
> 
> Das gleiche Problem habe ich auch mit meinem Offloader in einer VM dahinter. Dieser mesht nur mit dem ersten Knoten, wenn dieser über das „WAN“-Interface auch die Mesh-Funktion aktiviert hat, also über einen Port alles abwickelt.
> 
>   
> 
> Kennt jemand das Problem oder kann mir erste Lösungs- bzw. Diagnoseansätze geben?
> 
>   
> 
> Julian
> 
> 

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : OpenPGP_signature
Dateityp    : application/pgp-signature
Dateigröße  : 840 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.kbu.freifunk.net/pipermail/freifunk-bonn/attachments/20230520/30d49108/attachment.sig>