radvd sends out RAs to wrong interface

[petrus-lt]

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.

[reubenhwk]

Can you create a script which reproduces this?

On Tue, Apr 1, 2014 at 6:25 AM, petrus-lt notifications@github.com wrote:

Some more informations:

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

— Reply to this email directly or view it on GitHubhttps://github.com/reubenhwk/radvd/issues/25#issuecomment-39194677 .

[petrus-lt]

I've been able to reproduce the issue with the following steps:

# ip link add dev dummy0 type dummy
# ip address add 192.0.2.200/25 dev dummy0
# ip link add dev tap42 type gretap remote 192.0.2.20 local 192.0.2.200
# ip link set tap42 up
# ip address add 2001:db8:8081:3701::1/64 dev tap42

# cat << EOF > /etc/radvd.conf
> interface tap42
> {
>    AdvSendAdvert on;
>    AdvDefaultPreference high;
>    prefix 2001:db8:8081:3701::/64
>    {
>    };
> };
> EOF

# invoke-rc.d radvd start

We see RAs on the tap42 interface:

# tcpdump -v -i tap42 -s 65535  dst host ff02::1
09:12:20.640565 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 56) fe80::ecb1:57ff:fe13:4fc9 > 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:3701::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
          source link-address option (1), length 8 (1): ee:b1:57:13:4f:c9

(nothing on eth0)

As soon as tap42 goes down, we start to see RAs on eth0:

# ip link set tap42 down && sleep 1 && ip link set tap42 up

# tcpdump -v -i eth0 -s 65535  dst host ff02::1
09:14:33.716472 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:3701::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
          source link-address option (1), length 8 (1): ee:b1:57:13:4f:c9

• ee:b1:57:13:4f:c9 is tap42 mac address
• fe80::ecb1:57ff:fe13:4fc9/64 is tap42 LL address
• fe80::81:37/128 is one of eth0 LL address

I'm using radvd 1.8.5.

[zorun]

I can reproduce this bug with radvd 1.10.0.

Also note that my setup is slightly different: wlan0 is the main interface in use, eth0 is down and unused. By applying the steps described above, I can see RA on wlan0.

[zorun]

Also note that only one RA seems to be sent on wlan0: this happens at the moment the tap42 interface is brought up again (nothing special happens when the tap42 is brought down).

After this spurious RA on wlan0, all is back to normal again, RAs are correctly sent to tap42.

[reubenhwk]

If you would, can you also see if it's happening with the radvd-2 branch on github? There's been some significant changes in how interfaces are brought up, down, and checked in radvd-2. It would be good to know.

https://github.com/reubenhwk/radvd

Thanks in advance, Reuben

On Wed, Apr 2, 2014 at 4:48 AM, zorun notifications@github.com wrote:

Also note that only one RA seems to be sent on wlan0: this happens at the moment the tap42 interface is brought up again (nothing special happens when the tap42 is brought down).

After this spurious RA on wlan0, all is back to normal again, RAs are correctly sent to tap42.

— Reply to this email directly or view it on GitHubhttps://github.com/reubenhwk/radvd/issues/25#issuecomment-39310421 .

[reubenhwk]

I haven't been able to reproduce this in the master branch (1.10) or radvd-2. Here's the output I'm seeing.....

Terminal1: reuben@zoidberg:~$ sudo ip link set tap42 down && sleep 1 && sudo ip link set tap42 up reuben@zoidberg:~$ sudo ip link set tap42 down && sleep 1 && sudo ip link set tap42 up reuben@zoidberg:~$ sudo ip link set tap42 down && sleep 1 && sudo ip link set tap42 up reuben@zoidberg:~$ sudo ip link set tap42 down && sleep 1 && sudo ip link set tap42 up reuben@zoidberg:~$ sudo ip link set tap42 down && sleep 1 && sudo ip link set tap42 up reuben@zoidberg:~$

Terminal2: reuben@zoidberg:~$ sudo radvdump | grep ^interface interface tap42 interface tap42 interface tap42 interface tap42 interface tap42 interface tap42 interface tap42

Terminal3: reuben@zoidberg:~$ sudo tcpdump -v -i eth0 -s 65535 dst host ff02::1 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

Terminal4: reuben@zoidberg:~$ sudo tcpdump -v -i tap42 -s 65535 dst host ff02::1 tcpdump: WARNING: tap42: no IPv4 address assigned tcpdump: listening on tap42, link-type EN10MB (Ethernet), capture size 65535 bytes 21:16:46.184384 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 56) fe80::a49c:35ff:feb2:474 > 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:3701::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s source link-address option (1), length 8 (1): a6:9c:35:b2:04:74 21:16:50.452868 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 56) fe80::a49c:35ff:feb2:474 > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 56 hop limit 64, Flags [none], pref high, router lifetime 0s, reachable time 0s, retrans time 0s prefix info option (3), length 32 (4): 2001:db8:8081:3701::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s source link-address option (1), length 8 (1): a6:9c:35:b2:04:74 21:16:58.558816 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 56) fe80::a49c:35ff:feb2:474 > 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:3701::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s source link-address option (1), length 8 (1): a6:9c:35:b2:04:74 tcpdump: pcap_loop: The interface went down 3 packets captured 3 packets received by filter 0 packets dropped by kernel

Terminal5: [Apr 02 21:16:14] radvd: sending RA on tap42 [Apr 02 21:16:14] radvd: adding prefix 2001:db8:8081:3701:: to advert for tap42 with 86400 seconds(s) valid lifetime and 14400 seconds(s) preferred time [Apr 02 21:16:14] radvd: polling for 16 seconds. [Apr 02 21:16:14] radvd: recvmsg len=56 [Apr 02 21:16:14] radvd: if_index 7 [Apr 02 21:16:14] radvd: found Interface: tap42 [Apr 02 21:16:14] radvd: received RA from fe80::a49c:35ff:feb2:474 [Apr 02 21:16:14] radvd: polling for 16 seconds. [Apr 02 21:16:30] radvd: timer_handler called for tap42 [Apr 02 21:16:30] radvd: mtu for tap42 is 1462 [Apr 02 21:16:30] radvd: hardware type for tap42 is ARPHRD_ETHER [Apr 02 21:16:30] radvd: link layer token length for tap42 is 48 [Apr 02 21:16:30] radvd: prefix length for tap42 is 64 [Apr 02 21:16:30] radvd: sending RA on tap42 [Apr 02 21:16:30] radvd: adding prefix 2001:db8:8081:3701:: to advert for tap42 with 86400 seconds(s) valid lifetime and 14400 seconds(s) preferred time [Apr 02 21:16:30] radvd: polling for 16 seconds. .........

Let me know what else I should try to reproduce this problem... also, what kernel are you running and what type of hardware are your network interfaces (it may make a difference so it'd be good to know).

Thanks in advance, Reuben

On Wed, Apr 2, 2014 at 10:01 AM, Reuben Hawkins reubenhwk@gmail.com wrote:

If you would, can you also see if it's happening with the radvd-2 branch on github? There's been some significant changes in how interfaces are brought up, down, and checked in radvd-2. It would be good to know.

https://github.com/reubenhwk/radvd

Thanks in advance, Reuben

On Wed, Apr 2, 2014 at 4:48 AM, zorun notifications@github.com wrote:

Also note that only one RA seems to be sent on wlan0: this happens at the moment the tap42 interface is brought up again (nothing special happens when the tap42 is brought down).

After this spurious RA on wlan0, all is back to normal again, RAs are correctly sent to tap42.

— Reply to this email directly or view it on GitHubhttps://github.com/reubenhwk/radvd/issues/25#issuecomment-39310421 .

[andihofmeister]

I had the same problem.

Turns out that I tried to change the firewall mark on the packets via ip6tables. Apparently this causes the packets to be re-routed whereby the scope_id and in6_pktinfo get lost. After removing my marking rules, the problem was gone.

Environment was kernel 4.4.36, iptables 1.4.21 and radvd 2.15

Hope that helps Andi

[rozmansi]

I have been banging my head against the wall for the last few days trying to solve this problem too.

Thanks to @andihofmeister, I have found that an ip6tables -t mangle -A OUTPUT -p ipv6-icmp -j MARK --set-mark 0x1 causes all RAs to different subnets to be rerouted thru the same interface.

Kernel: 4.13.0, radvd: 2.16

[Neustradamus]

Any news?

[mm1ke]

For some days now I'm also trying to fix this issue on my firewall.

I have two physical interfaces: enp2s0 and enp1s0. On enp1s0 there are also 2 vlans configured: enp1s0.70 and enp1s0.80. For the interfaces enp1s0 and the two vlans I'm having a radvd config which provides these interfaces with IPv6. There are ULA's and GUA's addresses configured. The config looks as following:

interface enp1s0 {
        AdvSendAdvert on;
        MinRtrAdvInterval 3;
        MaxRtrAdvInterval 10;
        prefix fda1:1111:222:60::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };
        prefix 2a0a:4444:555:60::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };
};

interface enp1s0.70 {
        AdvSendAdvert on;
        MinRtrAdvInterval 3;
        MaxRtrAdvInterval 10;
        prefix fda1:1111:222:70::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };
        prefix 2a0a:4444:555:70::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };
};

interface enp1s0.80 {
        AdvSendAdvert on;
        MinRtrAdvInterval 3;
        MaxRtrAdvInterval 10;
        prefix fda1:1111:222:80::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };
        prefix 2a0a:4444:555:80::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };
};

Software: radvd-2.19 System: Linux s1 5.10.27-gentoo #2 SMP PREEMPT Fri Apr 30 15:54:12 CEST 2021 x86_64 AMD G-T40E Processor AuthenticAMD GNU/Linux

For the Clients in the Vlans the configuration seems to work as expected. However, Clients from the interface enp2s0 would get addresses from enp1s0 and vice versa (if i enable ipv6 there too). I've already tried many things like setting AdvRASrcAddress but with no success so far.

I also can reproduce it with android and windows clients very easy. However, interestingly with linux-clients it doesn't happen everywhere. While one wireless client also gets wrong ipv6 addresses, two other wired clients doesn't seem to be affected. Maybe this has something todo with the network-clients used by the clients? (The wireless uses NetworkManager, while the two wired uses netifrc - all are gentoo/openrc based clients)

There is also a firewall configured. However, instead of iptables I'm using nftables. I've already tried many config adaptations but with no success so far too. Even without any rules the behavior is the same. The networks are also completely separated, so there exists no firewall rules which allows any traffic between them.

@rozmansi @andihofmeister Any idea how i can find out if packet marks are being modified/added? I clearly doesn't have any rule in nft configured, but maybe something else modifies these packages..?

Would be great if someone could look into this. Right now i basically can't use ipv6 because of this.

[Neustradamus]

@robbat2: What do you think?

[broetchen]

similar issue here: prefix configured for eth0 is announced on eth0.99 - that makes ipv6 on eth0.99 unuseable, no workaround known.

edit: radvd -version Version: 2.19 uname -a Linux raspberrypi 5.10.63-v7+ #1488 SMP Thu Nov 18 16:14:44 GMT 2021 armv7l GNU/Linux

[robbat2]

I cannot reproduce this, even with the ip6tables command provided.

Running Linux bohr-int 5.14.5-x86_64 #88 SMP Fri Sep 17 22:30:09 PDT 2021 x86_64 AMD Ryzen 7 3700X 8-Core Processor AuthenticAMD GNU/Linux

@broetchen can you please run the attached setup.sh script. It depends on the teardown.sh and trigger.sh scripts, and will create the dummy0 and tap42 devices for testing. setup.sh.txt trigger.sh.txt teardown.sh.txt Rename them to .sh (because GitHub does not permit attachments otherwise), and give them chmod 755, run as root.

[mm1ke]

Some more information what i could fine out regarding this issue.

In my case it seems like there were 2 problems at hand, one of which i could fix.

First the wlan clients (android, etc): Initially i though that it might have something to do with the dhcp-client used by the clients. As mentioned my only laptop who uses networkmanager instead of openrc was also affected while the lan clients where not. However networkmanager wasn't the problem. Since i was also looking into my network devices it turned out that the wlan AP made the problems for the wlan clients. (it was an old tp-link ap). After changing the AP (this time a lancom ap), Android Clients and other wlan clients doesn't get IPv6 addresses from the wrong vlan anymore. I don't know what the AP did, but it seems his IPv6 stack was somehow buggy, which also leads me also to the windows Clients.

Windows Clients: While i could fix my wlan clients (which includes windows client here), windows clients which are physical connected to a port that also has other vlans tagged on it, still get ipv6 addresses from these vlans. However, this might not be a problem to only radvd as i found following information: https://community.arubanetworks.com/community-home/digestviewer/viewthread?MID=31121

I don't know what HP switches uses for dhcpv6 (maybe it uses radvd too?), but at least you'll get the same problem there too, and it seems only windows clients are affected. Seems like the ipv6 stack from windows is buggy too?

Personally i only have one windows client and since i knew what todo i either remove all tagged vlans from the port where it's connected or simple connect the client via wlan (which is the usual case anyway).

Hope this information helps someone.

Regards Michael

[broetchen]

after removing temporary switched off adv in config (so it does not announce a wrong addresse) radvd now does the correct advs. Cannot reproduce anymore :-/ sorry And to make it clear: no other changes were made. hmm

[stappersg]

Thanks for reporting the Cannot reproduce anymore.

This issue now waits again for how to reproduce information.

[robbat2]

@broetchen maybe you can still reproduce it, and capture good data?

My gut feeling is that what users have seen it actually a packet coming back from the switchgear, and that they didn't expect that. Plus tcpdump doesn't normally tell you which device & direction the packet was in, making it very easy to get confused.

The testing scripts I posted are very careful to log interfaces & packet directions.

[mcr]

tcpdump -i any -e will give you In/Out/Multicast tags, which can be useful here. The Linux Cooked Header is, however, missing other fields.

[Neustradamus]

@ all, do you reproduce this bug? If yes, can you add logs?

[robbat2]

No response for 6 months, closing.