Disable neighbour acquisition

[MisterDA]

Hi!
This is a prototype for disabling neighbour acquisition in babeld, as suggested in #58. I’m currently testing it ;-)
The first patch adds a global option, neighbour-acquisition, that is true by default, and when disabled will prevent babeld from sending multicast hellos (that may or may not be suitable, if that’s a bad idea, I’ll remove the feature) and prevents babeld from ever creating neighbours.
The second patch adds a way to add and flush neighbours from the configuration interface.

[jech]

I assume this is about Wireguard support? Did you try to find out what exactly is needed in order to get babeld to work with Wireguard with minimal configuration?

First, I don't think that neighbour-acquisition should be a global option — it should be per-interface.

Second, what prevents a statically-configured neighbour from timing out? I think we need a static flag that prevents such neighbours from expiring.

Third, the function flush_neigbour2 duplicates code. Why not do

neigh = find_neighbour(...);
if(neigh != NULL)
    flush_neighbour(neigh);

[MisterDA]

I assume this is about Wireguard support?

Yes.

Did you try to find out what exactly is needed in order to get babeld to work with Wireguard with minimal configuration?

Not yet.

First, I don't think that neighbour-acquisition should be a global option — it should be per-interface.

Ok. Do we need an option to disable multicast hellos?

Second, what prevents a statically-configured neighbour from timing out? I think we need a `static` flag that prevents such neighbours from expiring.

I assumed that the lower-layer, essentially the VPN, would also lose connectivity to the peer and flush it, but yes, a static flag is a good thing.

Third, the function `flush_neigbour2` duplicates code. Why not do ```c neigh = find_neighbour(...); if(neigh != NULL) flush_neighbour(neigh); ```

I agree it’s simpler, but we’re walking the linked-list twice here. I thought it’d be more efficient to do the search and the removal in one round, but I guess it doesn't really matter here.

[jech]

> Did you try to find out what exactly is needed in order to get babeld to work > with Wireguard with minimal configuration? Not yet.

I'm afraid that we might be doing useless work, then. We really need to set up a Wireguard network first and gain some experience with it.

Do we need an option to disable multicast hellos?

I'd say yes, but before we decide, we need to check how Wireguard reacts to multicast hellos.

I assumed that the lower-layer, essentially the VPN, would also lose connectivity to the peer and flush it, but yes, a static flag is a good thing.

What if it's a temporary glitch?

I agree it’s simpler, but we’re walking the linked-list twice here.

So? Write the naive code first, optimise it later if it appears on actual profiles. Which I doubt.

[snh]

What WireGuard topology do you have in mind for this?

The reason I ask is that a simple two peer WireGuard topology with 0.0.0.0/0 and/or ::/0 as the WireGuard AllowedIPs in both directions works fine with babeld with no tweaks required.

As a result, a common scenario when using babeld with WireGuard is to have a separate WireGuard internface/tunnel per host pair.

Anything more complex is likely to be constrained by WireGuard's cryptokey routing unless babeld was to dynamically adjust the WireGuard AllowedIPs on the fly, as peers on the same WireGuard interface cannot use overlapping AllowedIPs due to the fundamental way the routing works in WireGuard.

[MisterDA]

Hi! There’s a lot to the subject that I haven’t yet understood, I’m withdrawing these patches. Sorry for the noise and the wasted time.