Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No RAs on dummy device with "::/64" #46

Closed
ivilata opened this issue Oct 8, 2015 · 4 comments

Comments

@ivilata
Copy link

commented Oct 8, 2015

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!

@ivilata

This comment has been minimized.

Copy link
Author

commented Oct 8, 2015

BTW, I see an entry in the changelog:

2014/05/30  add disable_ipv6_autoconfig function so an interface radvd
                    is using won't autoconfig itself using its own advert

I found no such function in the current code, maybe it was removed or somehow rewritten later.

@reubenhwk

This comment has been minimized.

Copy link
Owner

commented Oct 8, 2015

I'm not sure. I'll look into it when I get a chance.

On Thu, Oct 8, 2015 at 10:01 AM, ivilata notifications@github.com wrote:

BTW, I see an entry in the changelog:

2014/05/30 add disable_ipv6_autoconfig function so an interface radvd
is using won't autoconfig itself using its own advert

I found no such function in the current code, maybe it was removed or
somehow rewritten later.


Reply to this email directly or view it on GitHub
#46 (comment).

@ivilata

This comment has been minimized.

Copy link
Author

commented Apr 10, 2016

Hi! After more testing, I think I found the reason why this doesn't work. I enabled debugging with version 2.13 and saw the following message (as I mentioned above):

dummy0 does not support multicast, forcing UnicastOnly

which I traced to send.c:send_ra_forall(), and also this new message:

no client list, no destination, unicast only...doing nothing

which I traced to device-common.c:check_device(). Manually disabling the conditions that fired these messages and rebuilding resulted in radvd sending announcements on dummy0.

I was somehow confused since multicast pings like ping6 ff02::1%dummy0 worked as expected, but I realised in the output of ifconfig dummy0 (<UP,BROADCAST,RUNNING,NOARP>) that the MULTICAST flag wasn't enabled (maybe it's the default behaviour for Linux). After deconfiguring dummy0 and stopping radvd, running ip link set multicast on dev dummy0, and then putting dummy0 back up and starting the (not modified) radvd, it had no problem in sending announcements to that interface.

As I mentioned in the first comment, this setup worked with radvd 1.9.1 without setting the multicast flag, but maybe its checks were too weak and the new behaviour is actually intended, so feel free to close the issue. I'm glad anyway to have solved the mystery finally.:)

Thanks!

@reubenhwk

This comment has been minimized.

Copy link
Owner

commented Apr 10, 2016

Well, if it worked in v1.9.1, but not in v2.13, without changing the
settings on your device, seems like maybe v2.13+ should do the same as
v1.9.1. I'll look into it to see if there's a good reason why it stopped
working...

On Sun, Apr 10, 2016 at 11:42 AM, Ivan Vilata-i-Balaguer <
notifications@github.com> wrote:

Hi! After more testing, I think I found the reason why this doesn't work.
I enabled debugging with version 2.13 and saw the following message (as I
mentioned above):

dummy0 does not support multicast, forcing UnicastOnly

which I traced to send.c:send_ra_forall(), and also this new message:

no client list, no destination, unicast only...doing nothing

which I traced to device-common.c:check_device(). Manually disabling the
conditions that fired these messages and rebuilding resulted in radvd
sending announcements on dummy0.

I was somehow confused since multicast pings like ping6 ff02::1%dummy0
worked as expected, but I realised in the output of ifconfig dummy0 (
<UP,BROADCAST,RUNNING,NOARP>) that the MULTICAST flag wasn't enabled
(maybe it's the default behaviour for Linux). After deconfiguring dummy0
and stopping radvd, running ip link set multicast on dev dummy0, and then
putting dummy0 back up and starting the (not modified) radvd, it had no
problem in sending announcements to that interface.

As I mentioned in the first comment, this setup worked with radvd 1.9.1
without setting the multicast flag, but maybe its checks were too weak and
the new behaviour is actually intended, so feel free to close the issue.
I'm glad anyway to have solved the mystery finally.:)

Thanks!


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#46 (comment)

@reubenhwk reubenhwk closed this Jul 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.