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

[Julian Zielke]

Fix: https://github.com/ff-kbu/gluon-special-packages/pull/2/commits

 

On 17.05.23, 22:37, "Freifunk-Bonn on behalf of Julian Zielke" <freifunk-bonn-bounces at lists.kbu.freifunk.net on behalf of freifunk at databunker.eu> 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.

 

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

-- _______________________________________________ Freifunk-Bonn mailing list Freifunk-Bonn at lists.kbu.freifunk.net https://lists.kbu.freifunk.net/cgi-bin/mailman/listinfo/freifunk-bonn 

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.kbu.freifunk.net/pipermail/freifunk-bonn/attachments/20230517/02f200e4/attachment.htm>