Re: autoip address set/reset loop

[Daniel Wagner <wagi@monom.org>]

On Thu, Nov 24, 2022 at 05:34:09PM +0100, Geoffrey Van Landeghem wrote:
> When you say that such gateway address is a bug, then do you mean in
> general? Because I'd think that in case of IPv4LL at least you need
> some default route. The RFC also speaks about using 0.0.0.0 for
> forwarding rules: https://datatracker.ietf.org/doc/rfc3927/

I completely forgot all details about IPv4LL and now I start to remember
why it is so broken. We have the problem that we activate IPv4LL on
default and for the VPN interface this causes troubles.

> Note sure how to proceed next, do you mean we should add an extra
> check if our IPv4 is LL? Something like this function found in acd.c:
> 
> #define LINKLOCAL_ADDR 0xa9fe0000
> static bool is_link_local(uint32_t ip)
> {
>     return (ip & LINKLOCAL_ADDR) == LINKLOCAL_ADDR;
> }

Not sure if this would help. So if we need a default route for an IPv4LL
interface we should do this. But I just saw we have also the multihome
routing problem but let's ignore this for now.

Changing the default not to enable IPv4LL is also not really nice, as it
breaks the current behavior and this might be something embedded systems
are relying on to be active.

This leaves us the option to disable IPv4LL for the VPN interfaces. With
this we could revert the patch. Either we need to pass this info from
the vpn daemon to the core daemon or we can figure the 'subtype' of the
interface and just ignore those we don't like...