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

[Peter]

Mir ist (im Moment) nichts bekannt (Umbenennung).

Das wurde nur versucht die Software zu aktualisieren, aktuell zu halten,...

Dann scheint das Problem relativ eingekreist zu sein, und bei der nächsten Möglichkeit eine aktuelle Firmware zu backen, die ich in den nächsten Tagen erwarte, kann ich wohl diese testen.

Ansonsten würde ich mich für eine testversion für meine CPE freuen, oder eine rückportierte Version von 2021...

Ich würde mich auch freuen wenn jemand mir an meinem Ubuntu per Fernwartung zeigen könnte wie ich einen Firmware Backautomaten installiere. Durchführen, zeigen, übernehmen, selber machen...

Je länger ich darüber nachdenke müsste es in der Version 2021 noch funktioniert haben... Aber auch diese Erinnerung ist ja jetzt fast absolet.

Am 17. Mai 2023 22:36:56 MESZ schrieb Julian Zielke <freifunk at databunker.eu>:
>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
>


Gruß Peter
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.kbu.freifunk.net/pipermail/freifunk-bonn/attachments/20230520/0d255e60/attachment.htm>