Can radvd please include and (optionally) install a systemd service?

Many distros are using systemd (such as Debian, Ubuntu, and Fedora) and others are supporting but not necessarily using it by default (Gentoo). Currently, each one of these distributions has to create and distribute their own systemd service for radvd, even though they're all (virtually) identical, with the only differences being inadvertent or unnecessary. One of the goals of systemd is "to unify the boot and service management between distributions with systemd." I think everyone agrees that it's bad if every distribution patched the radvd source... so this situation is also less than ideal. Besides making life easier for distributions and users, upstreaming a systemd service also helps radvd out in another way - it makes things more consistent, which eases maintainability.

Here's the systemd unit I propose, using what's in Gentoo and Fedora as a baseline:

[Unit]
Description=Router advertisement daemon for IPv6
Documentation=man:radvd(8)
After=network.target

[Service]
User=radvd
Group=radvd
Type=forking
ExecStartPre=/usr/sbin/radvd --configtest
ExecStart=/usr/sbin/radvd --logmethod stderr --debug 0
ExecReload=/usr/sbin/radvd --configtest ; \
           /bin/kill -HUP $MAINPID
CPUSchedulingPolicy=idle
PIDFile=/run/radvd/radvd.pid
RuntimeDirectory=radvd
CapabilityBoundingSet=CAP_NET_BIND_SERVICE  CAP_NET_RAW
AmbientCapabilities=CAP_NET_BIND_SERVICE  CAP_NET_RAW
PrivateTmp=yes
PrivateDevices=yes
ProtectSystem=full
ProtectHome=yes
NoNewPrivileges=yes

[Install]
WantedBy=multi-user.target

The de facto way to handle systemd unit is with the flags --without-systemduserunitdir (which doesn't install the unit) and --with-systemduserunitdir=[path] (which installs the unit to the given path).

It would be nice to split all the interface configs up into individual tiles in a conf directory like this...

/etc/radvd.d/eth0

...so when a single interface changes, there's no need to reload the whole config file.

I just closed issue #75 after concluding it was never a radvd issue, but one could argue it is.

Issue #75 describes a problem caused by sysctl setting /proc/sys/net/ipv6/conf/all/forwarding to 1
but leaving /proc/sys/net/ipv6/conf/enp31s0f0/forwarding at 0.

In this case, the kernel will forward IPv6 traffic from and to enp31s0f0, but Neighbor
Advertisements sent from this interface will have the "router" flag set to 0.

When using radvd on this interface, radvd will advertise its address as a router nonetheless.

This will cause Windows hosts to add a route each time a router advertisement is received,
and to drop that route each time a neighbor advertisement is received from that address.
Eventually, Windows hosts will permanently drop the route, and start ignoring all router
advertisements until the network link is dropped or the host is restarted.

radvd does check whether the system is actually a router, by checking the value of
/proc/sys/net/ipv6/conf/all/forwarding. If radvd would check forwarding for the specific
interface, here /proc/sys/net/ipv6/conf/enp31s0f0/forwarding, this issue could have
been prevented.

The way RADVD works now, all the prefixes that can be sent are generated from the config file parser when the config file is parsed. This is a problem with some type of automatic prefix is selected, ::/64, Base6Interface, Base6to4Interface.

The problem is when that interface comes up, radvd doesn't know to check new prefixes on that interface unless it reparses the config file.

What need to be done is to migrate logic from the parser into the send_ra code.

get_v4addr is likely not going to be needed in v2.0. Check to see if it's being used and remove it if it isn't.

When we get a message on an interface, we search for it linearly by index. This seems like a good candidate for a hash table for better efficiency. Other options are storing the interface list in a sorted array and binary searching.

I've got an interface named clients. The according config line does not parse correctly:

interface clients {
    ...
};

It results in the following error:

/etc/radvd.conf:1 error: syntax error, unexpected T_CLIENTS, expecting STRING

As far as I've seen, there is no way to quote the interface name. The parser should be extended to allow quoted strings to solve this problem.

Hello,

I got the following bug report https://bugs.archlinux.org/task/40724, because the 1.12 tarball is no more available at your website : http://www.litech.org/radvd/dist/radvd-1.12.tar.xz

Regards,

I'm using radvd on an openvpn tap interface. When the vpn server is restarted, the tap interface goes down and up, and radvd starts advertising on the lan interface:

root@host:~# radvdump
#
# radvd configuration generated by radvdump 1.8.5
# based on Router Advertisement from fe80::81:37
# received by interface eth0
#
interface eth0
{
        AdvSendAdvert on;
        # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
        AdvManagedFlag off;
        AdvOtherConfigFlag off;
        AdvReachableTime 0;
        AdvRetransTimer 0;
        AdvCurHopLimit 64;
        AdvDefaultLifetime 1800;
        AdvHomeAgentFlag off;
        AdvDefaultPreference high;
        AdvSourceLLAddress on;

        prefix 2001:db8:8081:3701::/64
        {
                AdvValidLifetime 86400;
                AdvPreferredLifetime 14400;
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr off;
        }; # End of prefix definition

}; # End of interface definition

tcpdump -i eth0 confirms this:

08:30:11.987462 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 56) fe80::81:37 > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 56
        hop limit 64, Flags [none], pref high, router lifetime 1800s, reachable time 0s, retrans time 0s
          prefix info option (3), length 32 (4): 2001:db8:8081:3700::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
          source link-address option (1), length 8 (1): fa:c7:02:73:4a:1e

The radvd config contains only the openvpn interface:

# cat /etc/radvd.conf
interface tap-vpn
{
   AdvSendAdvert on;
   AdvDefaultPreference high;
   prefix 2001:db8:8081:3701::/64
   {
   };
};

The monitoring confirms that the issue appeared at the exact moment when the vpn server was restarted.

My openvpn config has the 'persist-tun' option, so the tap interface is in fact not destroyed but goes down.

Hello,

During the test to push radvd 2.1 on archlinux, I discovered that my hosts have loosed their ipv6 gateway since the upgrade from 1.4[1] to 2.1[2].

I'm using the following config file

# vim:set ts=2 sw=2 ft=perl noet :

interface brlan
{
    AdvSendAdvert on;
    AdvSourceLLAddress on;

    MinRtrAdvInterval 10;
    MaxRtrAdvInterval 30;

    # Disable Mobile IPv6 support
    AdvHomeAgentFlag off;


    prefix 2a01:240:fe00:8205::/64
    {
        AdvOnLink on;
        AdvAutonomous on;
    };

  RDNSS 2a01:240:fe00:8205::1
  {
                    # advised by logs to be <= 2*MaxRtrAdvInterval
          AdvRDNSSLifetime 45;
  };

  DNSSL h.seblu.net
  {
          AdvDNSSLLifetime 45;
  };


};

I have the following output from systemd when I run radvd 1.4

# systemctl status radvd         
● radvd.service - IPv6 Router Advertisement Daemon
   Loaded: loaded (/usr/lib/systemd/system/radvd.service; enabled)
   Active: active (running) since lun. 2014-07-28 15:35:15 CEST; 826ms ago
 Main PID: 12249 (radvd)
   CGroup: /system.slice/radvd.service
           ├─12249 /usr/bin/radvd --nodaemon --logmethod=stderr
           └─12250 /usr/bin/radvd --nodaemon --logmethod=stderr

juil. 28 15:35:15 slice.seblu.net radvd[12249]: [Jul 28 15:35:15] radvd (12249): version 2.1 started
juil. 28 15:35:15 slice.seblu.net radvd[12249]: [Jul 28 15:35:15] radvd (12249): zero length option in RA on brlan from fe80::201:c0ff:fe08:af7a

This is a tcpdump output from a linux guest when radvd 2.1 is running on the network.

# tcpdump -lvvni eth0 icmp6 
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:37:27.526230 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 136) fe80::201:c0ff:fe08:af7a > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 136
    hop limit 64, Flags [none], pref medium, router lifetime 0s, reachable time 0s, retrans time 0s
      prefix info option (3), length 32 (4): 2a01:240:fe00:8205::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
        0x0000:  40c0 0001 5180 0000 3840 0000 0000 2a01
        0x0010:  0240 fe00 8205 0000 0000 0000 0000
      rdnss option (25), length 24 (3):  lifetime 0s, addr: 2a01:240:fe00:8205::1
        0x0000:  0000 0000 0000 2a01 0240 fe00 8205 0000
        0x0010:  0000 0000 0001[ndp opt]
15:37:27.547544 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 136) fe80::201:c0ff:fe08:af7a > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 136
    hop limit 64, Flags [none], pref medium, router lifetime 90s, reachable time 0s, retrans time 0s
      prefix info option (3), length 32 (4): 2a01:240:fe00:8205::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
        0x0000:  40c0 0001 5180 0000 3840 0000 0000 2a01
        0x0010:  0240 fe00 8205 0000 0000 0000 0000
      rdnss option (25), length 24 (3):  lifetime 45s, addr: 2a01:240:fe00:8205::1
        0x0000:  0000 0000 002d 2a01 0240 fe00 8205 0000
        0x0010:  0000 0000 0001[ndp opt]
# ip -6 r
2a01:240:fe00:8205::/64 dev eth0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 

This is a tcpdump output from a linux guest when radvd 1.4 is running on the network.

# tcpdump -lvvni eth0 icmp6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:39:00.625981 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 136) fe80::201:c0ff:fe08:af7a > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 136
    hop limit 64, Flags [none], pref medium, router lifetime 0s, reachable time 0s, retrans time 0s
      prefix info option (3), length 32 (4): 2a01:240:fe00:8205::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
        0x0000:  40c0 0001 5180 0000 3840 0000 0000 2a01
        0x0010:  0240 fe00 8205 0000 0000 0000 0000
      rdnss option (25), length 24 (3):  lifetime 0s, addr: 2a01:240:fe00:8205::1
        0x0000:  0000 0000 0000 2a01 0240 fe00 8205 0000
        0x0010:  0000 0000 0001[ndp opt]
15:39:00.803657 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 104) fe80::201:c0ff:fe08:af7a > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 104
    hop limit 64, Flags [none], pref medium, router lifetime 90s, reachable time 0s, retrans time 0s
      prefix info option (3), length 32 (4): 2a01:240:fe00:8205::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
        0x0000:  40c0 0001 5180 0000 3840 0000 0000 2a01
        0x0010:  0240 fe00 8205 0000 0000 0000 0000
      rdnss option (25), length 24 (3):  lifetime 45s, addr: 2a01:240:fe00:8205::1
        0x0000:  0000 0000 002d 2a01 0240 fe00 8205 0000
        0x0010:  0000 0000 0001
      dnssl option (31), length 24 (3):  lifetime 45s, domain(s): h.seblu.net.
        0x0000:  0000 0000 002d 0168 0573 6562 6c75 036e
        0x0010:  6574 0000 0000
      source link-address option (1), length 8 (1): 00:01:c0:08:af:7a
        0x0000:  0001 c008 af7a
# ip -6 r
2a01:240:fe00:8205::/64 dev eth0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
default via fe80::201:c0ff:fe08:af7a dev eth0  proto ra  metric 1024  expires 76sec

[1] https://www.archlinux.org/packages/community/i686/radvd/
[2] https://www.archlinux.org/packages/community-testing/x86_64/radvd/

Hello,

My current /etc/radvd.conf looks like this:

interface eth0.4004 {
AdvSendAdvert on;
IgnoreIfMissing on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
prefix fde1:53ba:e9a0:de24::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};

I have 2 centos running on arm machines which are connected.
Radvd is ON on first m/c and OFF on second.

1. Radvd is being used to receive the prefix values to be set. However I find that I am not able to control the MinRtrAdvInterval and MaxRtrAdvInterval of the router advertisements. I can control them only when AdvAutonomous is turned OFF.
2. When I turn OFF AdvAutonomous, I see that the router advertisement prefix value is not. (but if I turn AdvAutonomous ON,prefix values are set. Is there a way I could have the AdvAutonomous OFF and still be able to set set the prefix ip6 values ?

Thanks,
Athreya

I have an issue with radvd 2.4 (and 2.3, did not test it with earlier 2.x builds yet) on Gentoo that it will not work on a bridge interface, however version 1.15 will work just fine.

Jul 31 20:37:45 [radvd] version 2.4 started
Jul 31 20:37:45 [radvd] ioctl(SIOCGIFFLAGS) succeeded for br0
Jul 31 20:37:45 [radvd] interface br0 is up
Jul 31 20:37:45 [radvd] interface br0 is running
Jul 31 20:37:45 [radvd] interface br0 supports multicast
Jul 31 20:37:59 [radvd] ioctl(SIOCGIFFLAGS) succeeded for br0
Jul 31 20:37:59 [radvd] interface br0 is up
Jul 31 20:37:59 [radvd] interface br0 is running
Jul 31 20:37:59 [radvd] interface br0 supports multicast
Jul 31 20:37:59 [radvd] received RS or RA on br0 but br0 is not ready and setup_iface failed
Jul 31 20:38:03 [radvd] ioctl(SIOCGIFFLAGS) succeeded for br0
Jul 31 20:38:03 [radvd] interface br0 is up
Jul 31 20:38:03 [radvd] interface br0 is running
Jul 31 20:38:03 [radvd] interface br0 supports multicast
Jul 31 20:38:03 [radvd] received RS or RA on br0 but br0 is not ready and setup_iface failed
Jul 31 20:38:07 [radvd] ioctl(SIOCGIFFLAGS) succeeded for br0
Jul 31 20:38:07 [radvd] interface br0 is up
Jul 31 20:38:07 [radvd] interface br0 is running
Jul 31 20:38:07 [radvd] interface br0 supports multicast
Jul 31 20:38:07 [radvd] received RS or RA on br0 but br0 is not ready and setup_iface failed
Jul 31 20:38:19 [radvd] poll returned early: Interrupted system call
Jul 31 20:38:19 [radvd] Exiting, 1 sigterm(s) received.
Jul 31 20:38:19 [radvd] sending stop adverts
Jul 31 20:38:19 [radvd] ioctl(SIOCGIFFLAGS) succeeded for br0
Jul 31 20:38:19 [radvd] interface br0 is up
Jul 31 20:38:19 [radvd] interface br0 is running
Jul 31 20:38:19 [radvd] interface br0 supports multicast
Jul 31 20:38:19 [radvd] removing /var/run/radvd/radvd.pid
Jul 31 20:38:19 [radvd] returning from radvd main
Jul 31 20:38:19 [radvd] Exiting, privsep_read_loop had readn return 0 bytes
Jul 31 20:38:19 [radvd] Exiting, privsep_read_loop is complete.

However the interface is ready and working.
ip addr show
gives this (replaced some part of the IPv6 addr..)

9: br0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 64:66:b3:1e:d1:07 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.254/24 brd 192.168.0.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 xxx:xxx:xxx:xxx::1/128 scope global home nodad 
       valid_lft forever preferred_lft forever
    inet6 xxx:xxx:xxx:xxx:be5f:f4ff:fe5a:45da/64 scope global deprecated nodad 
       valid_lft forever preferred_lft 0sec
    inet6 xxx:xxx:xxx:xxx::2/128 scope global deprecated nodad 
       valid_lft forever preferred_lft 0sec
    inet6 fe80::be5f:f4ff:fe5a:45da/64 scope link 
       valid_lft forever preferred_lft forever

my /etc/radvd.conf

interface br0
{
   IgnoreIfMissing on;
   AdvSendAdvert on;
   AdvLinkMTU 1280;
   prefix xxx:xxx:xxx:xxx::/64
   {
   };

   RDNSS xxx:xxx:xxx:xxx::1
   {
   };

};

Using poll, or select, and signals is a race condition. Use ppoll, or pselect, and set the signal mask.

It's important to tell the compiler not to assume strict aliasing rules instead of just not printing out the warning.

Downstream bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=1045179

More information on -Wno-strict-aliasing and -fno-strict-aliasing

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487310

http://ubuntuforums.org/showthread.php?t=1300782

i keep getting these error messages when running radvd 1.10.0 on my dd-wrt router..

can u tell me why? radvd is still working fine..

@reubenhwk Hi Rueben,

I'm a developer on AstLinux and we have been using 1.9.x for some time and figured now is a good time to move to 2.1 .

In my testing if radvd 2.1 is started with a configured interface not connected (link down), using...

IgnoreIfMissing on;

when the link goes up, that interface does not work until radvd is restarted. I'm using Linux.

Enclosed is a patch that appears to fix the problem.

The primary change is in radvd.c, function setup_iface() swap the occurrence of calling check_device() and update_device_index(), calling update_device_index() first always creates a 'slot' that can be indexed later when the link goes up.

The second change is to set in netlink.c, iface->state_info.ready = 0 when the link goes up or down so the process() function can later call setup_iface(). Also send.c expects iface->state_info.ready to be properly set for netlink.

Lonnie

==================
--- radvd-2.1/netlink.c.orig    2014-07-27 14:16:13.000000000 -0500
+++ radvd-2.1/netlink.c 2014-07-27 14:19:20.000000000 -0500
@@ -79,6 +79,7 @@
            /* Reinit the interfaces which needs it. */
            struct Interface *iface = find_iface_by_index(ifaces, ifinfo->ifi_index);
            if (iface) {
+               iface->state_info.ready = 0;
                iface->state_info.racount = 0;
                reschedule_iface(iface, 0);
            }
--- radvd-2.1/radvd.c.orig  2014-07-27 16:15:51.000000000 -0500
+++ radvd-2.1/radvd.c   2014-07-27 16:24:30.000000000 -0500
@@ -553,12 +553,12 @@
 {
    iface->state_info.ready = 0;

-   /* Check IFF_UP, IFF_RUNNING and IFF_MULTICAST */
-   if (check_device(sock, iface) < 0) {
+   if (update_device_index(iface) < 0) {
        return -1;
    }

-   if (update_device_index(iface) < 0) {
+   /* Check IFF_UP, IFF_RUNNING and IFF_MULTICAST */
+   if (check_device(sock, iface) < 0) {
        return -1;
    }

==================

Original report: https://bugs.gentoo.org/637958

There is at least two issues in radvd WRT endianness:

1. add_ra_option_lowpanco() and add_ra_option_abro() do not normalize 16-bit field into networking order:

+++ b/send.c
@@ -621,7 +621,7 @@ static void add_ra_option_lowpanco(struct safe_buffer *sb, struct AdvLowpanCo co
        co.nd_opt_6co_context_len = lowpanco->ContextLength;
        co.nd_opt_6co_c = lowpanco->ContextCompressionFlag;
        co.nd_opt_6co_cid = lowpanco->AdvContextID;
-       co.nd_opt_6co_valid_lifetime = lowpanco->AdvLifeTime;
+       co.nd_opt_6co_valid_lifetime = htons(lowpanco->AdvLifeTime);
        co.nd_opt_6co_con_prefix = lowpanco->AdvContextPrefix;

        safe_buffer_append(sb, &co, sizeof(co));
@@ -635,9 +635,9 @@ static void add_ra_option_abro(struct safe_buffer *sb, struct AdvAbro const *abr

        abro.nd_opt_abro_type = ND_OPT_ABRO;
        abro.nd_opt_abro_len = 3;
-       abro.nd_opt_abro_ver_low = abroo->Version[1];
-       abro.nd_opt_abro_ver_high = abroo->Version[0];
-       abro.nd_opt_abro_valid_lifetime = abroo->ValidLifeTime;
+       abro.nd_opt_abro_ver_low = htons(abroo->Version[1]);
+       abro.nd_opt_abro_ver_high = htons(abroo->Version[0]);
+       abro.nd_opt_abro_valid_lifetime = htons(abroo->ValidLifeTime);
        abro.nd_opt_abro_6lbr_address = abroo->LBRaddress;

        safe_buffer_append(sb, &abro, sizeof(abro));

2. struct nd_opt_6co has sub-byte bit fields that I think are not stable across endianness
   because patch aboge does not stabilize output completely.

struct nd_opt_6co {
        uint8_t nd_opt_6co_type;
        uint8_t nd_opt_6co_len;
        uint8_t nd_opt_6co_context_len;
        uint8_t nd_opt_6co_res : 3; // <---
        uint8_t nd_opt_6co_c : 1;  // <---
        uint8_t nd_opt_6co_cid : 4; // <---
        uint16_t nd_opt_6co_reserved;
        uint16_t nd_opt_6co_valid_lifetime;
        struct in6_addr nd_opt_6co_con_prefix;
};

Sometimes we need autogenerated some configurations, which are going to be combined with user defined ones. However, it seems very hard to do this job under the current implementation, mainly two restrictions,

1. Currently all configurations are put into a single file.
2. The structured configuration file disallows duplicating interface definitions.

With the restriction 1, it is not easy to separate different configurations, autogenerated or user defined.
With the restriction 2, one interface's configuration must be defined in one place and no modifications or additions are possible with simple file concatenations, nor can priority based configuration be implemented.

So is there any plan to make some changes on these restrictions? I may contribute some code if this is in your plan.

review the code around memory allocation to ensure error checking

Originally reported to Debian at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508466

Interfaces can occasionally change MAC addresses in-flght. The most common example are Linux bridges, that are created using a random MAC and then change the MAC address to the first interface added to the bridge.

If radvd is started before the first interface is added, it learns the old MAC address of the bridge and continues to advertise it in the LL addr option, overwriting the entry in the client's neighbor cache at every advertisement. This creates blackhole periods of about 10-20 seconds each time.

The bug is at least present in 1.8.5. I'm going to test 1.9 later, but since there is nothing in the changes suggesting a fix I assume it is still affected.

If a route or prefix option in the configuration has more bits specified than the address length mask, Radvd should:

• warn or error.
• forcing the non-network bits to zero.
• collapse now duplicate prefix/routes.

Specifications:

https://tools.ietf.org/html/rfc4861#section-4.6.2 page 30:

      Prefix         An IP address or a prefix of an IP address.  The
                     Prefix Length field contains the number of valid
                     leading bits in the prefix.  The bits in the prefix
                     after the prefix length are reserved and MUST be
                     initialized to zero by the sender and ignored by
                     the receiver.  

Emphasis: The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender.

https://tools.ietf.org/html/rfc4191#section-2.3 page 5:

   Routers MUST NOT include two Route Information Options with the same
   Prefix and Prefix Length in the same Router Advertisement.

Splitting options in this case between two immediately sequential Router Advertisements should be considered as a case of a single long RA (of a link with infinite MTU).

Sample configuration input:

    prefix fd3c:b2e8:93df:1:2::/64 { };
    prefix fd3c:b2e8:93df:1:3::/64 { };
    route fd3c:b2e8:93df:cafe:f0fe::/64 { };
    route fd3c:b2e8:93df:cafe:f0ff::/64 { };

actual tcpdump:

prefix info option (3), length 32 (4): fd3c:b2e8:93df:1:2::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
prefix info option (3), length 32 (4): fd3c:b2e8:93df:1:3::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
route info option (24), length 24 (3):  fd3c:b2e8:93df:cafe:f0fe::/64, pref=medium, lifetime=5400s
route info option (24), length 24 (3):  fd3c:b2e8:93df:cafe:f0ff::/64, pref=medium, lifetime=5400s

expected tcpdump:

prefix info option (3), length 32 (4): fd3c:b2e8:93df:1::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
route info option (24), length 24 (3):  fd3c:b2e8:93df:cafe::/64, pref=medium, lifetime=5400s

Problems to discuss:

• What happens when the route/prefixes in the configuration have DIFFERENT parameters? How should Radvd handle it?

At the ETSI (IETF94-colocated) plugfest, I was trying to get ABROs emitted at the 6lo plugfest that can be consumed by RIOT-OS. (which we were able to do). It worked, btw.

The config I was using looked like:

abro fe80::216:3ead:fd4:1165/64 {                                          
      AdvVersionLow 10;                                                    
      AdvVersionHigh 2;                                                    
      AdvValidLifeTime 2;                                                  
};                                                                         

The IP address part is copied into the ABRO block, but what's the / prefix-length part about? I don't think it belongs at all. I suggest modifying the grammar not to require it.

sysctl has fallen out of favor and will likely be removed. /proc/sys is the new sysctl and sysctl may be implemented using /proc/sys anyway.

A number of changes are possibly made to an interface by radvd and radvd doesn't restore those values when it exits.

Add some values to the iface structure to save the original values set on the iface and restore those values on exit.

One example value is set in privsep_set_autoconfig.

I have 2 radvds on my home network.
One is DD-WRT with old kernel and it provides the default route.
The other is my desktop computer (kernel 3.16.3, radvd 2.5) and it provides a different /64 route (for a network of virtual machines)

The second host has to accept RA (IP address and default route) in routing mode so I wrote "2" into /proc/sys/net/ipv6/conf/br0/accept_ra (br0 is the LAN interface)

The problem occurs when I start radvd on the desktop:

1. "0" is written to /proc/sys/net/ipv6/conf/br0/autoconf
2. after the old RA-generated IP address on br0 expires, it becomes marked as deprecated and then auto-deleted
3. If I manually write "1" to autoconf, it is cleared again after a while.

This is my config:

interface br1
{
        AdvSendAdvert on;
        IgnoreIfMissing on;
        MinRtrAdvInterval 30;
        MaxRtrAdvInterval 100;
        prefix fd2a:90cb:ea7e:92f0::/64
        {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr off;
        };
};
interface br0
{
        AdvSendAdvert on;
        AdvDefaultLifetime 0;
        IgnoreIfMissing on;
        MinRtrAdvInterval 30;
        MaxRtrAdvInterval 100;
        route fd2a:90cb:ea7e:92f0::/64
        {
                AdvRouteLifetime 600;
        };
};

send.c generates the same packets every time. Experiment with generating the packet after the config file is parsed so the memory can just be passed directly to sendmsg each time.

radvd recognizes (and immediately sends out an advertisement) a new prefix that gets configured on an interface. But when using the special configuration prefix ::/64, it still announces the prefixes that were present when starting radvd.
Sending a SIGHUP causes to reread the configuration. After that the new prefix gets announced, too.

It seems that deleting an address doesn't remove it from following announcements, too.

[process.c:373]: (warning) Invalid test for overflow 'label_len>label_len+2'. Condition is always false unless there is overflow, and overflow is Undefined Behaviour.

Source code is

label_len > label_len + 2

Suggest cast out to larger integer type, then compare.

Hi Reuben,

originally I noticed this problem when I wanted to do ssh router service radvd restart after I had upgraded the router to Debian stretch, which ships radvd v2.15: the ssh connection wouldn't close, and just sit there forever. I was able to reproduce this behavior without any scripts involved by directly running what the init script would eventually call: ssh router radvd -u radvd -p /var/run/radvd/radvd.pid

This worked fine on jessie (v1.9-something).

git-bisect'ing revealed the culprit as 5294e6f. Before that commit, radvd would fork and let the ssh connection terminate properly...

Cheers
Daniel

Hello,

This issue is a continuation of the second part of the discussion we made in issue #36. And issue #39 is related
Currently, radvd is able to be notified of an address prefix being added or removed from an interface, but I'm still interested that its clients receive a RA to deprecate the prefix being removed from the interface, which radvd doesn't do.

Here's my radvd.conf

interface enp0s8
{
    AdvSendAdvert on;
    AdvManagedFlag off;
    AdvOtherConfigFlag on;

    prefix ::/64
    {
	AdvOnLink on;
	AdvAutonomous on;
	AdvRouterAddr on;
	DeprecatePrefix on;
    };
};

After years and years of smooth operation, suddenly, after an upgrade of Fedora 25 to Fedora 26, we started getting serious issues with IPv6 auto configuration. See my bugzilla report.

Note that both Fedora 25 and Fedora 26 ship radvd 2.14.

The issue is that all our Windows hosts that use IPv6 autoconfiguration lose their default gateway after a while, usually within 24 hours. An error is recorded in the Windows System event log, Event 4205, source "tcpip", message:

"Autoconfigured route limit has been reached. No further autoconfigured routes will be added until the interface is reconnected".

Indeed, a short disconnect of the (virtual) ethernet cable will make the default route return. For a while. So will a reboot.

Windows forums aren't very helpful in solving this issue. The best answer they can think of is try to disable IPv6, Oh well.

On Bugzilla I wrote the problem went away after a while. It did, but somehow it returned after a power surge, where the Fedora box needed rebooting several times. It led me to believe that restarting radvd might be the issue here, rather than version upgrading.

I built an RPM using radvd 2.17 which I am running now, and the issue is still there.

On top of that, I noticed that Windows hosts using autoconfiguration are experiencing packet loss when pinged from outside the subnet. Manual IPv6 configuration fixes that.

Linux hosts in the same test are not losing packets regardless of configuration method.

I checked for rogue RA's. They don't appear to be there,

I tried all sorts of configurations. Currently it is like this.
Perhaps I should advertise an explicit route to ::/0 ?

# main network
interface enp31s0f0
{
        AdvSendAdvert on;
        AdvDefaultPreference high;
        AdvDefaultLifetime 3600;
        MaxRtrAdvInterval 60;
        prefix xxxx:yyyy:zzzz:fff0::/64 {};
        RDNSS xxxx:yyyy:zzzz:fff0::1 xxxx:yyyy:zzzz:fff0:221:5eff:fe6b:b9e0 {};
        DNSSL example.nl {};
};

radvd is mostly untested. Flesh out automake's make check facility.

Version:
radvd 2.10

I have a "WAN" interface (eth1), which gets 64-Bit-prefix IPv6 address via RA from telecom provider. I want to announce the 64-Bit-prefix of this "WAN" IPv6 address on my "LAN" interface (br0), since I do want to have my linux box between, since I do not trust the telecom router and want to have full control over my "LAN" network.

So I have this config:

interface br0 {
    AdvSendAdvert on;
    AdvLinkMTU 1280;

    prefix ::/64 {
        Base6Interface eth1;
        # Very short lifetimes in seconds for dynamic addresses
        AdvValidLifetime 600;
        AdvPreferredLifetime 300;
    };

};

But I get the following message:

# /etc/init.d/radvd start
 * Enabling IPv6 forwarding ...                                                               [ ok ]
[Feb 12 10:51:17] radvd (24810): no auto-selected prefix on interface br0, disabling advertisements
[Feb 12 10:51:17] radvd (24810): config file, /etc/radvd.conf, syntax ok
 * Starting IPv6 Router Advertisement Daemon ... 

And br0 does not get an IPv6 address, indeed.

How can I achieve my goal?

Hi,

in the early days of 6lowpan support, there was 802.15.4 6LoWPAN only.
It is still in an experimental state, but was completely unusable in these days.
We changed now the ARPHRD from ARPHRD_IEEE802154 to ARPHRD_6LOWPAN.
Because it was in a very poor state when it was ARPHRD_IEEE802154, I am fine when it will be replaced by ARPHRD_6LOWPAN. I highly not recommend kernel versions which has still ARPHRD_IEEE802154 for the 802.15.4 6LoWPAN interface.

Nevertheless I am also fine to make some backwards compability:

case ARPHRD_IEEE802154:
case ARPHRD_6LOWPAN:
/* do stuff */

Also please add:

ifndef ARPHRD_6LOWPAN

define ARPHRD_6LOWPAN 825 /* IPv6 over LoWPAN */

endif

to make it available if somebody use old kernel header versions.
The ARPHRD_6LOWPAN will be used by all 6LoWPAN interfaces now. Currently we have support for 802.15.4 and BTLE 6LoWPAN. Both use currently an EUI64 address as link address. (We still need support for 802.15.4 short address, but this is another issue).

Also please note ARPHRD_IEEE802154 is here wrong. This type is still used by the wpan interfaces which don't has IPv6 functionality (MTU < 1280).

send_ra_inc_len is easy to use improperly. It should be called before writing any data to the out buffer, but there's no way to enforce that.

Come up with a new interface to build the packets which is hard to use incorrectly. Maybe something like this...

p = new_packet();
push_back(p, uint8, value);

Expected result:
If a UnicastOnly=no instance with a fixed client list gets a RS, it should only respond to that client.

Actual result:
The instance sends RAs to every single client.

Effects:
Hosts that did not solicit the RA are flooded by RAs when not needed.

Host setup:

modprobe dummy
ifconfig dummy0 up multicast
ip -6 addr add  fe80::1/64 dev dummy0
ip -6 addr add  fe80::2/64 dev dummy0

radvd.conf:

interface dummy0 {
  AdvSendAdvert on;
  AdvRASrcAddress { fe80::1; };
  route 2001:db8:f001::/64 { };
  UnicastOnly off;
  clients { fe80::2; fe80::3; fe80::4; fe80::5; fe80::6; fe80::7; fe80::8; };
};

Test trigger:

# rdisc6 dummy0
Soliciting ff02::2 (ff02::2) on dummy0...

Hop limit                 :           64 (      0x40)
Stateful address conf.    :           No
Stateful other conf.      :           No
Mobile home agent         :           No
Router preference         :       medium
Neighbor discovery proxy  :           No
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :  unspecified (0x00000000)
Retransmit time           :  unspecified (0x00000000)
 Route                    : 2001:db8:f001::/64
  Route preference        :       medium
  Route lifetime          :         1800 (0x00000708) seconds
 Source link-layer address: 96:29:9A:3F:1A:A6
 from fe80::1

debug=5 logging

[Nov 18 17:43:12] radvd (16547): dummy0 recvmsg len=8
[Nov 18 17:43:12] radvd (16547): dummy0 received a packet
[Nov 18 17:43:12] radvd (16547): dummy0 received RS from: fe80::2
[Nov 18 17:43:12] radvd (16547): sending RA to fe80::8 on dummy0 (fe80::1)
[Nov 18 17:43:12] radvd (16547): sending RA to fe80::7 on dummy0 (fe80::1)
[Nov 18 17:43:12] radvd (16547): sending RA to fe80::6 on dummy0 (fe80::1)
[Nov 18 17:43:12] radvd (16547): sending RA to fe80::5 on dummy0 (fe80::1)
[Nov 18 17:43:12] radvd (16547): sending RA to fe80::4 on dummy0 (fe80::1)
[Nov 18 17:43:12] radvd (16547): sending RA to fe80::3 on dummy0 (fe80::1)
[Nov 18 17:43:12] radvd (16547): sending RA to fe80::2 on dummy0 (fe80::1)
[Nov 18 17:43:12] radvd (16547): dummy0 next scheduled RA in 496.716 second(s)
[Nov 18 17:43:12] radvd (16547): dummy0 processed an RS
[Nov 18 17:43:12] radvd (16547): polling for 496.716 second(s), next iface is dummy0
[Nov 18 17:43:12] radvd (16547): dummy0 recvmsg len=48
[Nov 18 17:43:12] radvd (16547): dummy0 received a packet
[Nov 18 17:43:12] radvd (16547): dummy0 received RA from: fe80::1
[Nov 18 17:43:12] radvd (16547): processed RA on dummy0

Network capture:

17:43:12.500909 IP6 fe80::2 > ff02::2: ICMP6, router solicitation, length 8
17:43:12.501121 IP6 fe80::1 > fe80::8: ICMP6, router advertisement, length 48
17:43:12.501170 IP6 fe80::1 > fe80::7: ICMP6, router advertisement, length 48
17:43:12.501201 IP6 fe80::1 > fe80::6: ICMP6, router advertisement, length 48
17:43:12.501233 IP6 fe80::1 > fe80::5: ICMP6, router advertisement, length 48
17:43:12.501265 IP6 fe80::1 > fe80::4: ICMP6, router advertisement, length 48
17:43:12.501313 IP6 fe80::1 > fe80::3: ICMP6, router advertisement, length 48
17:43:12.501343 IP6 fe80::1 > fe80::2: ICMP6, router advertisement, length 48

hi,

would it possible to add support for configuring a ipv6 ip which is advertised as router by the radvd service? This would it make possible to run radvd on system in the network if you have an device as gateway which don't support router advertisment.

Also if you run vrrp like keepalived for router redundancy on your connection tracking firewalls, it would be very helpfull only advertise only the service ip to avoid asyncron routing which brakes connection tracking.

Placeholder bug for development of RA-splitting functionality.

Builds on top of my RA source configuration.

Implements:
RFC4861 6.2.3
RFC6980 - Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
RFC7772 - Reducing Energy Consumption of Router Advertisements (scheduling placeholder functions so far)

Submitting for early review

Hello. I have the following radvd.conf file:

interface eth0
{
        AdvSendAdvert on;
        MinRtrAdvInterval 30;
        MaxRtrAdvInterval 100;
        route 2000:e000:0:2::/64
        {
                AdvRoutePreference low;
        };
};

interface tap_tap
{
        AdvSendAdvert on;
        MinRtrAdvInterval 30;
        MaxRtrAdvInterval 100;
        prefix 2000:e000:0:2::/64
        {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };

        route 2000:e000:0:1::/64
        {
                AdvRouteLifetime infinity;
                AdvRoutePreference high;
        };

};

The idea is to have a eth0 interface facing an internal network and a tap interface which will have people connected from VPNs. On the eth0 interface I want to advertise routes so everyone in the internal network can see the VPN clients, the problem is that the eth0 advertisement gets picked up by other interfaces such as eth1 and that messes up the whole routing:

# radvd configuration generated by radvdump 1.9.2
# based on Router Advertisement from fe80::b076:c0ff:fe83:d38a
# received by interface eth1
#

interface eth1
{
        AdvSendAdvert on;
        # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
        AdvManagedFlag off;
        AdvOtherConfigFlag off;
        AdvReachableTime 0;
        AdvRetransTimer 0;
        AdvCurHopLimit 64;
        AdvDefaultLifetime 300;
        AdvHomeAgentFlag off;
        AdvDefaultPreference medium;
        AdvSourceLLAddress on;

        route 2000:e000:0:2::/64
        {
                AdvRoutePreference low;
                AdvRouteLifetime 300;
        }; # End of route definition

}; # End of interface definition
#
# radvd configuration generated by radvdump 1.9.2
# based on Router Advertisement from fe80::b076:c0ff:fe83:d38a
# received by interface eth0
#

interface eth0
{
        AdvSendAdvert on;
        # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
        AdvManagedFlag off;
        AdvOtherConfigFlag off;
        AdvReachableTime 0;
        AdvRetransTimer 0;
        AdvCurHopLimit 64;
        AdvDefaultLifetime 300;
        AdvHomeAgentFlag off;
        AdvDefaultPreference medium;
        AdvSourceLLAddress on;

        route 2000:e000:0:2::/64
        {
                AdvRoutePreference low;
                AdvRouteLifetime 300;
        }; # End of route definition

}; # End of interface definition

The weird thing is that I've succesfully used this exact same setup in some environments, for some reason in some environments this happens out of nowhere, is there anything that I'm missing?

Thank you!

/*
 * this function extracts the link local address and interface index
 * from PATH_PROC_NET_IF_INET6.  Note: 'sock' unused in Linux.
 */
int setup_linklocal_addr(struct Interface *iface)

This function opens a file, PATH_PROC_NET_IF_INET6, reading each line until it collects the link local and interface index for the interface. There must be a direct way to do this...

once the testing feature is completed, use it to create a gcov/lcov website.

radvd crashes when a prefix is removed from the interface that's being monitored by radvd or when radvd starts and the interface doesn't have an assigned prefix. The issue affects all versions of radvd, 1.x and 2.x. It has been reported on Debian's bug tracker

I can reproduce the crash with the latest radvd version, build by me from the official 2.8 sources, on Debian 8.0 beta2 x86. Below is a radvd.conf sample, to help you reproduce the issue. You just need to make sure the network interface doesn't have a prefix assigned and you need to uncomment the desired option (DeprecatePrefix or DecrementLifetimes):

    interface eth0
    {
            AdvSendAdvert on;
            AdvManagedFlag off;
            AdvOtherConfigFlag on;
            AdvLinkMTU 1492;

            prefix ::/64
            {
                    AdvOnLink on;
                    AdvAutonomous on;
                    AdvRouterAddr on;
                    DeprecatePrefix on;
                    #DecrementLifetimes on;
            };
    };

Hi, I have a Debian Sid setup with a dummy interface which is manually configured with a deprecated, fixed address before radvd is started, so that the daemon can use a ::/64 prefix and announce on that interface. Autoconfiguration is then used in the interface to get temporary privacy addresses. This is the relevant stanza in /etc/network/interfaces:

auto dummy0
iface dummy0 inet6 auto
    pre-up  ip addr add W:X:Y:Z::1/64 dev $IFACE preferred_lft 0
    privext  2

And this is the full /etc/radvd.conf:

interface dummy0 {
    AdvSendAdvert on;
    prefix ::/64 {};
};

This used to work perfectly with radvd 1.9.1 (1.9.1-1.3 from Debian), but with 2.11 (2.11-1) the interface never gets temporary addresses. Using radvdump and a sniffer I see that RAs are sent on dummy0 with 1.9.1, but no RAs are seen with 2.11.

I have tried enabling UnicastOnly (since radvd complains that the interface doesn't support multicast) and IgnoreIfMissing just in case, but no luck. Are there any other options I can test if the behaviour has changed from 1.x? Thanks!

Hi,

apparently radvd's configure script accepts both bison and byacc but doesn't build with byacc because of wrong command-line arguments. In my opinion, if bison is a hard dependency, the configure script should catch its absence, not make.

Cheers,

Pavel

A non-zero AdvDefaultLifetime should not be permitted if sending a an explicit route of 0::/0 with zero lifetime, as it causes a default route flap event on the nodes receiving the RA.

This was a corner case found in further testing of RA-splitting, and reproduced it without the splitting code, I think the best way to handle it is during config file validation.

Proposed solution:

• If exactly one of route 0::/0 AdvRouteLifetime and AdvDefaultLifetime are is zero, but both are present, fail config file validation.
• If both are non-zero, pass.

Config file for old radvd:

AdvDefaultLifetime 1800;
route 0::/0 { AdvRouteLifetime 0; };

When arriving at another node (in a single RA), leads to the following events in the kernel (from ip -6 monitor ro)

Timestamp: Sat Nov 19 19:18:27 2016 730425 usec
default via fe80::5054:ff:fe1b:2f1f dev eth0  proto ra  metric 1024 
Timestamp: Sat Nov 19 19:18:27 2016 730500 usec
Deleted default via fe80::5054:ff:fe1b:2f1f dev eth0  proto ra  metric 1024  expires 1800sec

For 75us, there was an additional default route (that could have gotten traffic depending on other default routes present).

Using the new codebase, you can put in LOTS of routes, which take non-trivial time to send and process:
Config file for showing the problem further:

AdvDefaultLifetime 1800;
# LOTS of routes or options in the middle
# I used X=0..65535 "route 2001:db8:XXXX::/64 {};"
route 0::/0 { AdvRouteLifetime 0; };

The AdvDefaultLifetime is present on every RA, but the explicit route only goes out MUCH later.

This lead to the default route being altered for ~250ms in my test environment (deliberately slow VM with rate-limited network to represent a mobile device).

The config file doesn't change name from start to finish, but the permissions and uid of radvd can. Open the config file, but never close it. Test changing the file, and re-reading it. Test changing permissions in an insecure way and make sure radvd fails and exits.

On my system, radvd frequently dies because of broken default permissions.

Nov 05 08:02:19 netz UNKNOWN[27217]: attempting to reread config file
Nov 05 08:02:19 netz UNKNOWN[27217]: can't open /etc/radvd.conf: Permission denied
Nov 05 08:02:19 netz radvd[27215]: Exiting, privsep_read_loop had readn return 0 bytes

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728787

According to the getifaddrs manpage ifa_addr can be NULL, which it is on my system, which causes a crash upon send.c:293 if (ifa->ifa_addr->sa_family != AF_INET6)

Hi, I encountered a weird problem about my radvd-2.11 on a linux box being used as a router. It has two interfaces,enp4s0 is used as WAN and receives pd from my ISP and radvd runs on enp6s0 (LAN).

root@debian:~# ip -6 addr show enp6s0 | grep fe80
inet6 fe80::230:18ff:fec7:acae/64 scope link 

The following is my radvd.conf

interface enp6s0 # LAN interface
{
    AdvManagedFlag off; 
    AdvOtherConfigFlag off; 
    AdvSendAdvert on;
    MinRtrAdvInterval 300;
    MaxRtrAdvInterval 600;
    AdvDefaultPreference high;
    AdvDefaultLifetime 7200;
    AdvLinkMTU 1280;

    prefix ::/64
    {
        AdvOnLink on;
        AdvAutonomous on;
        AdvValidLifetime 36000;
        AdvPreferredLifetime 36000;
    };
};

However tcpdump on enp6s0 shows that it is sending ra every second despite of this config:

root@debian:~# tcpdump -i enp6s0 icmp6 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp6s0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:22:57.963326 IP6 fe80::230:18ff:fec7:acae > ip6-allnodes: ICMP6, router advertisement, length 64
00:22:58.965028 IP6 fe80::230:18ff:fec7:acae > ip6-allnodes: ICMP6, router advertisement, length 64
00:22:59.967183 IP6 fe80::230:18ff:fec7:acae > ip6-allnodes: ICMP6, router advertisement, length 64
00:23:00.969545 IP6 fe80::230:18ff:fec7:acae > ip6-allnodes: ICMP6, router advertisement, length 64
00:23:01.971727 IP6 fe80::230:18ff:fec7:acae > ip6-allnodes: ICMP6, router advertisement, length 64
00:23:02.973771 IP6 fe80::230:18ff:fec7:acae > ip6-allnodes: ICMP6, router advertisement, length 64

Could use a priority queue for better efficiency.

Hi,

radvd 2.0 apparently doesn't distribute all files necessary to perform 'make check' using the source tarball.

See:

https://kojipkgs.fedoraproject.org//work/tasks/6188/7156188/build.log