Multicast node discovery for fastd

[hwundram]

This patch series implements multicast discovery for fastd nodes on a multicast enabled base network. Hosts broadcast undirected type1 Handshake messages in configurable intervals, and nodes receiving the multicast connect back to the corresponding node to initiate the connection.

To enable multicast, use a bind statement of the form in the configuration:

bind [multicastaddr] port [port] [interface "[multicast interface]"] [source [unicast sourceaddr]] [interval [seconds]];

The corresponding generated socket listens on a wildcard bind to receive all packets destined for the multicast group and the unicast target. Generally, the unicast address used for the outgoing packets is decided by the routing engine, but can be explicitly configured through source. For IPv4 multicast, either a source address or an interface must be specified (to join the multicast group on), for IPv6, an interface must be specified (to join the multicast group on), and a source may additionally be specified. The configured interval defines the interval in which to send handshake type 1 packets on this socket in seconds, and must at least be one second or greater.

All other configuration should remain semantically similar to the standard implementation, with the exception that IPv6 sockets (with IPv4-mapped addresses) are now preferred even for IPv4 binds/IPv4 peers; this allows IPV6_RECVPKTINFO for IPv4 networks to be used in case that IP_PKTINFO is not available.

The patch is against v18 due to the fact that OpenWRT and Debian currently come with v18 in their stable distribution, but as the functionality was originally developed against v20, the migration to master should be simple. I can gladly provide the corresponding patch if required.

[neocturne]

Thanks for the PR, but for me to be able to review this (and decide whether the added complexity is acceptable), I really need something that applies to the fastd master without conflicts. fastd v21 is available in Debian backports, and can be added to an OpenWrt 19.07 feed without trouble (see https://github.com/freifunk-gluon/gluon/tree/c273f1a2c9b6b7fcecdeb5d8047c5ca5f2e24348/patches/packages/packages for example), so there is really no reason to work with an outdated fastd version.

[ecsv]

The patch is against v18 due to the fact that OpenWRT and Debian currently come with v18 in their stable distribution,

This is not helpful at all. Debian (or to be more specific: I) will not suddenly port this patchset to the stable version. Only important fixes (CVE fixes, ...) will be accepted by the Debian release team.

And the normal Debian process is: Only the newest released version will be uploaded to either experimental or unstable. And if it was migrated successfully from unstable to testing then it might be ported manually to buster-backports (currently v21) for interested stable users. Only on Debian major release dates, testing packages will be moved to the stable distribution. But at no point, v18 will be receiving this patchset.

Besides this, I don't find any information about the "why" in this PR.

[hwundram]

As to the why of the PR (which I thought was basically self-explanatory, seems like I'm wrong on that): multicast node discovery allows building local overlay networks between attached devices on a LAN segment, i.e. for example to have IOT devices being able to access a central configuration system in a LAN without having to resort to a node discovery protocol in the IOT protocol itself.

Have one master node which advertises itself, with a specific key, and clients (configured with only this peer) listening on the multicast address to connect to the (known) server on an unknown local address which is autodiscovered, which even works over ll6 addressing with a corresponding IPv6 ll multicast address (i.e. use ff12::xxxx for the multicast, and configure source as ll6, that's why I implemented the explicit ll6 identifier for automatically configuring the source addres). Basically, this allows plug and play configuration of the overlay network, if the master has a corresponding "on verify" trigger, and allows the actual IP addressing of the IOT software to be statically configured without having to worry about the uplink network (or worrying about overlaying a different IP address space on the uplink network). You even get verification of the master on top, if you configure the tunnel appropriately (i.e., the clients can be sure that they're talking to a specific master).

Concerning AP meshing (if you're talking about something like BATMAN adv): use link-local discovery of peers with an appropriate on verify-trigger on all nodes to initialize a LAN mesh interface automatically, tunneled via fastd, without explicitly configuring it. Same goes for distributing a concentrator to APs on a local network (configuration would probably be similar to the above IOT example), without having the local network have to manage with "foreign" packets or having to implement a secondary physical network. Of course, transport via fastd has a performance penalty in this case, so I don't know if this is relevant.

Those were both use-cases that I could come up with immediately (I'm using it for the first, i.e. IOT discovery), and it made my life a lot easier with the actual IOT implementation. But, possibly that's just me.

As I already wrote in the base PR, I implemented this initially on top of fastd-v20, but backported it to v18 (with some additional functionality, i.e. ll6 discovery) due to the fact that policy forces me to use the source packages from the distributions that I use implementing this. But, please see above, I explicitly wrote that I'm in the process of forward porting it to current and can supply the corresponding PR if interest is there. I'll just leave it at that for the moment and reopen with the relevant PR based on v21.