Gluon 2019.1.x Knoten erscheinen nicht in der Map (respondd)

anon68922371 · 30. August 2019 um 18:31

Gluon Master Stand 20.08.2019

Mein R6120 taucht sowohl mit eigenem VPN Uplink als auch über WiFi Mesh nicht in der Map und auch nicht auf der Statusseite auf.

Erst seitdem er via LAN mit einem Er-X meshed ist er auf beiden zu finden.

Hat da jemand einen Tipp?

FW:
http://0.gw.iz.freifunknord.de/firmware/testing/

site.conf

adorfer · 30. August 2019 um 19:45

Ich tippe mal blind auf
https://github.com/freifunk-gluon/gluon/issues/1758

anon68922371 · 30. August 2019 um 19:49

Hmpf.

Ok aber wir nutzen ja yanic

adorfer · 30. August 2019 um 20:13

Du musst die Adressen nur dann auch auf dem entsprechenden Interfaces (des Mapserver/Collector-Nodes) routbar machen.
Das ist -so wie ich verstanden habe- kein „Selbstläufer“ wie bei „ff02…%br0“

anon68922371 · 30. August 2019 um 20:40

Ich merk das gerade.

Mal eben ist das nicht getan.

Ach ich hasse sowas …

adorfer · 30. August 2019 um 21:29

Ich habe vorgeschlagen, das konfigurierbar zu machen.
Es wurde abgelehnt von den Maintainern.
Also wieder mal ein kleiner breaking change.

hexa · 30. August 2019 um 22:35

Diese Änderung gilt erst ab v2019.1 und wird auch in den Release Notes Erwähnung finden.

anon68922371 · 31. August 2019 um 07:16

Was ich hier nicht nachvollziehen kann ist, dass man diese Änderung nun für Babel benötigt.

Warum wird das nicht auch mit dem babel Packet verknüpft. Wenn Babel dann fd05 wenn batman fd02. fertig.

anon68922371 · 31. August 2019 um 08:04

Wie hast du denn das gelöst?

Ich hab gestern yanic so wie im issue angepasst was nicht funktionierte.

Dann hab ich:

ip -6 route add ff05::2/128 dev eth0 table local

Ausgeführt Fehlanzeige.

Derzeit denke ich drüber nach das wieder auf fd02 zu ändern…

hexa · 31. August 2019 um 08:07

 # multicast address to destination of respondd
 # (optional - without definition used batman default ff02::2:1001)
-#multicast_address = "ff05::2:1001"
+multicast_address = "ff05::2:1001"

Hier war glaube ich wirklich nur einkommentieren nötig.

anon68922371 · 31. August 2019 um 13:44

Wo hast du den Schnippsel her? Kann das nicht zuordnen.

hexa · 1. September 2019 um 02:09

github.com

FreifunkBremen/yanic/blob/main/config_example.toml#L31-L33

    
      
          # interface that has an IP in your mesh network
          [[respondd.interfaces]]
          # name of interface on which this collector is running

rubo77 · 30. September 2019 um 13:26

das selbe problem bei hopglass-server statt yanic, wie löst man das problem da? bzw. ist das bekannt?

btw: vielleicht mal den titel umbenennen in „2019.1.x Router …“

anon68922371 · 30. September 2019 um 13:28

Bei Yanic war ich bisher nicht in der Lage das Problem zu lösen.

Ich werde daher auch den rhein-sieg Patch einbauen.

steneu · 30. September 2019 um 15:51

vielleicht kann @PetaByteBoy da einen Tipp geben

adorfer · 30. September 2019 um 16:24

Nein. Kann er nicht.

github.com/hopglass/hopglass-server

listening on new respondd multicast group

opened 12:03PM - 24 May 19 UTC

anoymouserver

enhancement help wanted

I can't get the new repondd multicast address `ff05::2:1001` to work, but I don'…t know if it's nodejs or the network configuration. The other mcast address `ff02::2:1001` works without a problem. ``` { Error: getaddrinfo ENOTFOUND ff05::2:1001%br-client at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:56:26) errno: 'ENOTFOUND', code: 'ENOTFOUND', syscall: 'getaddrinfo', hostname: 'ff05::2:1001%br-client' } ``` Excerpt of my (not working) config: ```json { "receiver": { "receivers": [ { "module": "announced", "config": { "target": { "ip": "ff05::2:1001" } } } ], "ifaces": [ "br-client" ] } } ```

Das ganze wird nicht einfacher in Map-Setups, die auf mehreren Batman-Interfaces in unterschiedlichen L2-Domains hängen.
Ich gehe davon aus, dass man nun um getrennte Routingtabellen (plus tagging der Pakete) nicht mehr herumkommen wird.
Ist vermutlich trivial, es muss nur jemand tun.

awlnx · 30. September 2019 um 16:55

Ich verstehe gerade das Problem nicht, wir haben yanic mit 12 batman Interfaces und ff05::2:1001 am Laufen von Anfang an seitdem wir die neuen Gateways haben.

Unser Config für ein Interface sieht zum Beispiel so aus:

[[respondd.interfaces]]
ifname = "br-muc_cty"
port = 45124

[[respondd.interfaces]]
ifname = "br-muc_nord"
port = 45124

Diesen Config Eintrag kann man beliebig oft und für jedes Interface wiederholen.

Auch auf unseren Gateways ist der respondd entsprechend eingestellt.

github.com

FreifunkMUC/ext-respondd/blob/master/ext-respondd.py#L23

    
      
          parser.add_argument('-v', '--verbose', action='store_true', help='Verbose Output', required=False)
          parser.add_argument('-t', '--dry-run', action='store_true', help='Dry Run', required=False)
          
          
args = parser.parse_args()
          options = vars(args)
          
          
config = {
            'bridge': 'br-client',
            'batman': 'bat0',
            'port': 1001,
            'addr': 'ff05::2:1001',
            'caching': 5,
            'rate_limit': 30,
            'rate_limit_burst': 10
          }
          
          
try:
            with open("config.json", 'r') as fh:
              config = lib.helper.merge(config, json.load(fh))
          except IOError:
            print('no config.json, use defaults')

PetaByteBoy · 30. September 2019 um 17:28

In Gluon gab es eine Änderung der Adresse, und die neue Adresse ist keine link-local multicast-Adresse, wodurch die Adresse nicht mehr so verwendet werden kann wie die alte(n). Was genau nötig ist weiss ich nicht.

awlnx · 30. September 2019 um 17:35

Scheinbar aber nichts, was nicht vorher bei uns auch schon so war.

Das Node taucht sauber auf der Karte auf mit unserem Setup.
https://map.ffmuc.net/#!/en/map/18e829c0aaae

PetaByteBoy · 30. September 2019 um 17:39

Und was ist das für ein Backend?