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

[edgar.soldin at web.de]

moin Julian,

brauchen wir diese link-local-prefix anpassung denn? würden die standard-regeln nicht genügen?

..sonnige aus HH, ede

On 19.05.2023 14:03, Julian Zielke wrote:
> Das habe ich bereits getan und außer einem anderen Link local prefix fc00::/64 anstatt fd00::/64 haben die Standardregeln zu unseren keinen Unterschied (außer dem, was ich jetzt gefixt hatte).
> 
> Julian
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *Von:* Freifunk-Bonn <freifunk-bonn-bounces at lists.kbu.freifunk.net> im Auftrag von edgar.soldin at web.de <edgar.soldin at web.de>
> *Gesendet:* Freitag, Mai 19, 2023 11:08 AM
> *An:* freifunk-bonn at lists.kbu.freifunk.net <freifunk-bonn at lists.kbu.freifunk.net>
> *Betreff:* Re: [Freifunk-Bonn] [gluon] Gluon Mesh on Lan Problem mit v2022.1.1
> ich werde die ganzen Firewallregeln trotzdem in der nä. beta mal rausschmeissen und mit den Standardregeln vergleichen. da alle Regeln einmal zu ersetzen riecht faulig und muss danebengehen sobald sich die Gluon-Defaults irgendwie ändern.
> 
> generell tendiere ich dazu das einfach mal sein zu lassen.
> 
> On 17.05.2023 22:45, Julian Zielke wrote:
>  > Fix: https://github.com/ff-kbu/gluon-special-packages/pull/2/commits <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 <mailto:freifunk-bonn-bounces at lists.kbu.freifunk.net> on behalf of freifunk at databunker.eu <mailto: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 <mailto: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_lanname='/lan'
>  >
>  > gluon.iface_lan.role='client' 'mesh'
>  >
>  > Julian
>  >
>  > On 17.05.23, 12:24, "Julian Zielke" <freifunk at databunker.eu <mailto: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
>  >
>  >
> 
> -- 
> _______________________________________________
> Freifunk-Bonn mailing list
> Freifunk-Bonn at lists.kbu.freifunk.net
> https://listskbu.freifunk.net/cgi-bin/mailman/listinfo/freifunk-bonn
>