Silently exits / crashes with AdvLinkMTU 9000, if interface has smaller mtu set

[baryluk]

I use vyos , but even when massaging config file and debug options manually, I am getting same issue.

radvd 2.20-rc1-23-gf2de476

Linux, amd64

2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1900 qdisc mq state UP group default qlen 1000
    link/ether e4:3d:11:11:22:10 brd ff:ff:ff:ff:ff:ff
    altname enp1s0f0np0
    inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
       valid_lft forever preferred_lft forever
    inet6 2a02:123:3344:3::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 2a02:123:3344:2::1/56 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::aabb:ccdd:1122:1110/64 scope link 
       valid_lft forever preferred_lft forever

interface eth2 {
    IgnoreIfMissing off;
    AdvDefaultPreference high;
    MaxRtrAdvInterval 10;
    AdvReachableTime 900000;
    AdvIntervalOpt on;
    AdvSendAdvert on;
    AdvDefaultLifetime 300;
    AdvLinkMTU 9000;
    AdvOtherConfigFlag off;
    AdvRetransTimer 0;
    AdvCurHopLimit 64;
    prefix ::/64 {
        AdvAutonomous on;
        AdvValidLifetime 2592000;
        AdvOnLink on;
        AdvPreferredLifetime 14400;
        DeprecatePrefix off;
        DecrementLifetimes off;
    };
    RDNSS 2606:4700:4700::1111 {
    };
};

It then just crashes without telling me way.

Aug 10 23:54:11 vyos systemd[1]: Starting Router advertisement daemon for IPv6...
Aug 10 23:54:11 vyos radvd[1169860]: config file, /run/radvd/radvd.conf, syntax ok
Aug 10 23:54:11 vyos radvd[1169861]: [Aug 10 23:54:11] radvd (1169861): version 2.20_rc1 started
Aug 10 23:54:11 vyos radvd[1169861]: [Aug 10 23:54:11] radvd (1169861): eth2 interface definition ok
Aug 10 23:54:11 vyos radvd[1169861]: [Aug 10 23:54:11] radvd (1169861): config file, /run/radvd/radvd.conf, syntax ok
Aug 10 23:54:11 vyos radvd[1169861]: [Aug 10 23:54:11] radvd (1169861): radvd startup PID is 1169861
Aug 10 23:54:11 vyos radvd[1169861]: [Aug 10 23:54:11] radvd (1169861): opened pid file /run/radvd/radvd.pid
Aug 10 23:54:11 vyos radvd[1169861]: [Aug 10 23:54:11] radvd (1169861): locked pid file /run/radvd/radvd.pid
Aug 10 23:54:11 vyos radvd[1169862]: [Aug 10 23:54:11] radvd (1169862): opened pid file /run/radvd/radvd.pid
Aug 10 23:54:11 vyos radvd[1169862]: [Aug 10 23:54:11] radvd (1169862): radvd PID is 1169862
Aug 10 23:54:11 vyos radvd[1169862]: [Aug 10 23:54:11] radvd (1169862): wrote pid 1169862 to pid file: /run/radvd/radvd.pid
Aug 10 23:54:11 vyos radvd[1169861]: [Aug 10 23:54:11] radvd (1169861): child signaled pid file written: 1169862
Aug 10 23:54:11 vyos radvd[1169861]: [Aug 10 23:54:11] radvd (1169861): Freeing Interfaces
Aug 10 23:54:11 vyos radvd[1169861]: [Aug 10 23:54:11] radvd (1169861): freeing interface eth2
Aug 10 23:54:11 vyos systemd[1]: Started Router advertisement daemon for IPv6.
Aug 10 23:54:11 vyos systemd[1]: radvd.service: Main process exited, code=exited, status=1/FAILURE
Aug 10 23:54:11 vyos systemd[1]: radvd.service: Failed with result 'exit-code'.

This is with debug level 5:

/usr/sbin/radvd --logmethod stderr --config /run/radvd/radvd.conf --pidfile /run/radvd/radvd.pid --debug 5

If I set IgnoreIfMissing on; then it runs, but does not advertise (it basically does nothing, silently).

I think radvd should just emit a warning if the AdvLinkMTU 9000 is wrong, and still send RA as instructed. (this might be useful for example when the router itself has MTU 1500, but all the other hosts on the network should communicate with each other using MTU 9000). AFAIK there is nothing wrong with this and that is not an error.

Removing AdvLinkMTU 9000; made radvd start and send RAs. Similarly keeping AdvLinkMTU 9000; and setting mtu on the interface to 9000 made it also work. (my Linux client does ignore this MTU hint at the moment, because I think when both IPv4 DHCP, and IPv6 SLAAC is in use, this is basically ignored, and kernel does not change MTU based on RAs).

[robbat2]

There's a few concerns I have here:

1. If the RA has many options; it may need to be split over multiple packets - specifically with the actual MTU rather than the advertised MTU.
2. Clients may send large packets to the router, but the router then drops them.

With that said, making it a warning instead of failing to send seems reasonable to me. PR welcome