listening on new respondd multicast group

[anoymouserver]

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:

{
  "receiver": {
    "receivers": [
      {
        "module": "announced",
        "config": {
          "target": {
            "ip": "ff05::2:1001"
          }
        }
      }
    ],
    "ifaces": [
      "br-client"
    ]
  }
}

[T-X]

As remarked in nodejs/help#2073 (comment), too:

You can set a more specific multicast route for the multicast group and interface you want to send it to. Usually this should work:

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

Also see: https://stackoverflow.com/a/13149495

But if hopglass could add a configuration option to bind the network socket to a specific interface that would be the better solution. As that would allow multiple instances on the same host, too. (which the multicast route option probably will not work with)

Anyway, the getaddrinfo should only be called for "ff05::2:1001" and not "ff05::2:1001%br-client". A %<iface> is only granted to work for link-local addresses (ff02:... fe80:... etc.).

[T-X]

@anoymouserver: have you tried for "function retrieve()"
https://github.com/hopglass/hopglass-server/blob/master/modules/receiver/announced.js#L75

to change this:

collector.setMulticastInterface(ip + '%' + iface)
collector.send(req, 0, req.length, config.target.port, ip + '%' + iface, function (err) {

to this:

collector.setMulticastInterface('::%' + iface)
collector.send(req, 0, req.length, config.target.port, ip, function (err) {
...

[anoymouserver]

Your suggested adjustment works fine using the old address, but with the new address I can only reach the servers running ext-respondd.

[T-X]

@anoymouserver: Hm, this sounds strange. Which Gluon version are those nodes running?

[rubo77]

You can set a more specific multicast route for the multicast group and interface you want to send it to. Usually this should work:

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

so is this a valid solution? I don't understand the ip commands, and we don't have a bat0 interface on our hopglass server.

For an ip-n00b: What would be the command to make old (2018.2.x) and new (2019.1) nodes work with hopglass? And on which server would we have to apply that rule?

[Adorfer]

1. really problematic point are networks where there are (due to "autoupdater turned off by default"-policy in some communities) Gluon v2016-2019 at the same time and will be for a longer time
2. @rubo77 so far we have been adddressing ff02 via the individual "linklocal"-networks. So we did not explitly configure routing for the batman-interface(s).
   As we have map-servers working for multiple l2 domains at the same time, when we have now the same (non-linklocal)subnet on different interface: there will be the need of separated routing tables, since "normally" you can route one prefix just to one interface. and then the hopglass servers have to be started to work on just that individual routing table one interface.

[anoymouserver]

@T-X, most of the nodes are running gluon v2017.1.8, some newer version until v2019.1.

I've narrowed it down to the iptables rules used by gluon. They seem to block requests coming from 2a03: addresses. For some reason the data is requested using this global IP rather than the internal IP (which is used when requesting for ff02:).

[T-X]

That it uses a global multicast source address makes sense. Because it's a routable multicast destination the source needs to be / should be contactable over multiple hops.

The 2a03:, from which interface is it? Is it from br-wan or br-client?

[RalfJung]

We are also having trouble setting up the new multicast address on the hopglass server. I am not even sure if that's a hopglass thing; even just trying to use nc to send data to the new address fails:

$ nc -6 -q 3 -u "ff05::2:1001"%saarBR 1001
nc: getaddrinfo: Name or service not known

Doing the same with ff02 works fine. Seems like ff05 is a qualitatively different kind of multicast address and somehow it... doesn't exist here, or whatever that error message means?

EDIT:

so far we have been adddressing ff02 via the individual "linklocal"-networks. So we did not explitly configure routing for the batman-interface(s).

Ah, this sounds like ff05 indeed needs some amount of extra configuration. Would be good to link to some guide for this from the gluon nodes; IPv6 multicast is a mystery even though I am otherwise fairly familiar with IPv6.^^

Also, if this is not link-local any more, is there some guidance for how to handle the multi-domain case? Our plan was to have a single routing table for all our domains as they do not overlap. If this is a problem now, it seems like really gluon should support configuring that multicast address so that it can be deconflicted.

[RalfJung]

Actually in our case the only problem was that our hopglass-server was too old. After updating that to current master, the new address works just fine!

[ghost]

Actually in our case the only problem was that our hopglass-server was too old. After updating that to current master, the new address works just fine!

Did you perform any additional IP/route configuration on the host? Can you post your hopglass-server configuration? I can not reproduce it.

[rubo77]

In Kiel, I upgraded to the latest hopglass, but still no 2019 Knoten ;(

[RalfJung]

No I did not to any route configuration. Also the test here was whether after the address change, any nodes still reported updates -- we haven't rolled out 2019.1 yet so I can't say anything about those.

EDIT: The first few nodes updated to our experimental channel, and they also seem to work fine.

Our hopglass config template is

{
  "core": {},
  "receiver": {
    "receivers": [
      {
        "module": "announced",
        "config": {
          "target": {
            "ip": "ff05::2:1001"
          }
        }
      },
      {
        "module": "aliases",
        "overlay": true
      }
    ],
    "ifaces": [
{%- for domain in pillar.domains %}
      "{{ domain.name }}BR"
      {%- if not loop.last %},{% endif -%}
{%- endfor %}
    ]
  },
  "provider": {
    "metricsOfflineTime": 65
  }
}

[MTRNord]

Moin :) We currently have all kind of versions running in our network. We currently try using two announced receivers to have backward compatibility. But I am not sure if it is working. Do we need both? Is there any better way of listening to both?

[RalfJung]

For us, using the new address also worked with the old clients that we still had in the network -- but they were all on some 2018 version of gluon at least. How old are things in your network?

[MTRNord]

@RalfJung oldest is 2017.1.6, newest is 2019.X (newest available)

[wrosenauer]

I have just patched gluon to still work with the legacy address for the moment. So new firmwares listen on both and once (almost) all old firmwares are gone we could switch. No idea what we will consider as threshold and when that would be the case. We had no issues with collisions for the old adress so far. I also though about having to receivers but it also looks like this is harder than actually modifying the respondd rc script

[T-X]

@anoymouserver: @cuechan and I have noticed some firewall issues in Gluon at Freifunk Lübeck, too. I opened a ticket at Gluon (freifunk-gluon/gluon#1959), maybe this is the same issue as yours (and the workaround on the hopglass-server side mentioned in the ticket might work for you too).

[ohrensessel]

we were successful by applying the change suggestes by @T-X in this thread and the changes from #120
and ended up with the following: https://gist.github.com/ohrensessel/989962c46147cb89402c08639d6bafbb

It's late, maybe I'll make a pr from the suggestion by @T-X and wait for the merge of #120

[anoymouserver]

I'm trying to get the ff05 to work by trying the suggested ip route command but currently its not working that well.
The change from #107 (comment) works fine for both addresses so I've just applied it.