falsche SSID Hood Fichtelgebirge-Nord -- Salzach - Gateway nue2-gw4?
WBR-Tec
wbr-tec at ich-will-net.de
Mo Okt 3 10:33:46 CEST 2022
Guten Morgen,
ich kann zumindest für fichtelgebirge.nord bestätigen, dass es aktuell
funktioniert.
Soweit ich das noch nachvollziehen kann, ist mir das im Juli das
erstemal aufgefallen (aber weil nur der experimentelle GL-AR150, wars
halt egal....). In der vergangenen Woche waren dann alleine bei mir
schon 5 unterschiedliche Geräte betroffen.
Gruß
Jürgen
(und danke Adrian!)
Am 03.10.22 um 01:22 schrieb Adrian Schmutzler:
>
> Hallo,
>
> die Konfiguration ist korrekt, und die fehlenden Interfaces
> resultieren offenbar aus einer Art Race-Condition:
>
> Stand Christian:
>
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342
> redir ports 2345
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2343
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2350
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2346
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2347
>
> Neustart ….
>
> Chain PREROUTING (policy ACCEPT)
>
> target prot opt source destination
>
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2346
>
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2347
>
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2348
>
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2344
>
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2345
>
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2350
>
> Neustart ….
>
> Chain PREROUTING (policy ACCEPT)
>
> target prot opt source destination
>
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2343
>
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2347
>
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2349
>
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2350
>
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2344
>
> Auf meinem eigenen Gateway mit mehr Interfaces sind aber alle da.
>
> Das syslog sieht auch recht rot aus; hat jemand aus der Hüfte eine
> Idee, sonst werde ich wohl irgendwann mal Config 1:1 vergleichen
> müssen und ggf. umbauen.
>
> Ich habe die im Moment fehlenden Regeln mal von Hand reingeklopft,
> aber nach dem nächsten Neustart ist das natürlich wieder weg.
>
> Wenn ich wieder Zeit habe, schau ich mal genauer …
>
> Beste Grüße
>
> Adrian
>
> *From:*franken [mailto:franken-bounces at freifunk.net] *On Behalf Of
> *Christian Dresel
> *Sent:* Samstag, 1. Oktober 2022 07:45
> *To:* Robert Langhammer <rlanghammer at web.de>; franken at freifunk.net
> *Cc:* as at lists.f3netze.de
> *Subject:* Re: falsche SSID Hood Fichtelgebirge-Nord -- Salzach -
> Gateway nue2-gw4?
>
> Hallo
>
> Da sich den Problem keiner annimmt hab ich mal eben über das F3N
> Gateway geguckt
>
> Ich glaube dort fehlen ein paar ip6tables rules um vom richtigen
> eingehenden Interface auf den richtigen Apache Port zu landen. Wir
> haben Port 2342-2450 in Verwendung, die ip6tables nat rules sehen so aus:
>
> root at fff-nue2-gw4:/etc/network/interfaces.d#
> <mailto:root at fff-nue2-gw4:/etc/network/interfaces.d> ip6tables -t nat
> --list
> Chain PREROUTING (policy ACCEPT)
> target prot opt source destination
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2345
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2343
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2350
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2346
> REDIRECT tcp anywhere fe80::1 tcp dpt:2342 redir
> ports 2347
> Das ist leider alles ¯\_(ツ)_/¯
>
> folgende Hoods sind demnach mit folgenden Status auf dem Gateway
>
> Port | Hood | Status
> 2342 Salzach (braucht keinen forward weil der Port eh stimmt)
> 2343 Chiemgau (funktioniert)
> 2344 Fichtelberg (DEFEKT!)
> 2345 Fichtelfleckl (funktioniert)
> 2346 FichtelNeubau (funktioniert)
> 2347 FichtelOst (funktioniert)
> 2348 FichtWest (DEFEKT!)
> 2349 FichtNord (DEFEKT!)
> 2350 FichtSüd (funktioniert)
>
> Ich bin mir nicht sicher wer es betreut, gebe es aber direkt mal in
> die f3n-agas weiter, die dafür zuständig sein sollte. Ich selbst bin
> da schon zu lange raus um das zu fixen.
>
> Gruß
>
> Christian
>
> Am 25.09.22 um 16:50 schrieb Robert Langhammer:
>
> Hallo,
>
> klingt so, als ob das Gateway das falsche Hoodfile ausliefert.
>
> Viele Grüße
> Robert
>
> Am 25. September 2022 09:34:39 UTC schrieb WBR-Tec
> <wbr-tec at ich-will-net.de> <mailto:wbr-tec at ich-will-net.de>:
>
> Servus,
>
> habe hier jetzt schon den zweiten Router (Node) der Freifunk-Salzach
>
> anstatt Fichtelgebirge-Nord ausstrahlt.
>
> Aufgefallen ist mir das schon vor längerem mit meinem GL-150, der immer
>
> wieder von Fichtelgebirge-Nord zu Freifunk-Salzach wechselte. Und
>
> natürlich mesht er dann nicht mehr und ich hab darüber kein Netz.
>
> War mir bei dem egal, ist nur experimentell.
>
> Jetzt ist das aber bei einem TP-Link 1043 aufgetreten und das ist
>
> schlecht....
>
> Gemeinsamkeit: Beide Router waren vorher länger offline / ausgeschaltet)
>
> Die Firmware-Version wirds wohl nicht sein, auf dem 1043er ist noch die
>
> (alte) FW von Adrian drauf, bei meinem GL-150 habe ich das Update auf
>
> die aktuelle FFF-Version gemacht - keine Änderung. Die Positionsdaten
>
> sind auch korrekt, und auch neu eintragen hilft hier nix.
>
> Das Monitoring gibt dazu nix her - abgesehen von der (grünen) Verbindung
>
> zum Gateway. Der Fehler tritt scheinbar nur auf, wenn die Verbindung zum
>
> fff-nue2-gw4 besteht. Der bedient wohl auch Salzach.....
>
> Jemand ne Idee? Liegts doch am Gateway?
>
> GL-150:
>
> https://monitoring.freifunk-franken.de/mac/e4956e429625
>
> 1043:
>
> https://monitoring.freifunk-franken.de/mac/b04e26b0a97c
>
> Beste Grüße
>
> Jürgen
>
Mehr Informationen über die Mailingliste franken