[radvd-devel-l] RADVD gets confused when interfaces appear and disappear, sends RA into wrong interfaces

[Roman Mamedov]

Hello,

I have the following fragment in my radvd.conf:

interface tap-work {
    AdvSendAdvert on;
    IgnoreIfMissing on;
    AdvDefaultLifetime 0;
    prefix fd00:97bc:6311::1/64 { };
    route 2002:xxxx:xxxx::/52 { };
    route fd8e:ffad:f447::/64 { };
};

interface tap-yume {
    AdvSendAdvert on;
    IgnoreIfMissing on;
    prefix 2002:xxxx:xxxx:4::1/64 { };
    RDNSS fd8e:ffad:f447::100:53a { };
    DNSSL romanrm.ru version6.ru { };
};

When OpenVPN restarts, you can see what happens:

Feb 22 15:40:53 natsu ovpn-tap-yume[5493]: Inactivity timeout (--ping-restart), restarting
Feb 22 15:40:53 natsu radvd[11505]: attempting to reread config file
Feb 22 15:40:53 natsu radvd[11505]: resuming normal operation
Feb 22 15:40:53 natsu radvd[11505]: attempting to reread config file
Feb 22 15:40:53 natsu radvd[11505]: ioctl(SIOCGIFMTU) failed for tap-yume: No such device
Feb 22 15:40:53 natsu radvd[11505]: no linklocal address configured for tap-yume
Feb 22 15:40:53 natsu radvd[11505]: resuming normal operation
Feb 22 15:40:53 natsu ovpn-tap-yume[5493]: SIGUSR1[soft,ping-restart] received, process restarting
Feb 22 15:40:55 natsu ovpn-tap-yume[5493]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Feb 22 15:40:55 natsu ovpn-tap-yume[5493]: LZO compression initialized
Feb 22 15:40:55 natsu ovpn-tap-yume[5493]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1360)
Feb 22 15:40:55 natsu radvd[11505]: attempting to reread config file
Feb 22 15:40:55 natsu radvd[11505]: no linklocal address configured for tap-yume
Feb 22 15:40:55 natsu radvd[11505]: resuming normal operation
Feb 22 15:40:55 natsu ovpn-tap-yume[5493]: TUN/TAP device tap-yume opened
Feb 22 15:40:55 natsu ovpn-tap-yume[5493]: tap.sh tap-yume 1360 1437   init
Feb 22 15:40:55 natsu radvd[11505]: attempting to reread config file
Feb 22 15:40:55 natsu radvd[11505]: no linklocal address configured for tap-yume
Feb 22 15:40:55 natsu radvd[11505]: resuming normal operation
Feb 22 15:40:55 natsu radvd[11505]: attempting to reread config file
Feb 22 15:40:55 natsu radvd[11505]: no linklocal address configured for tap-yume
Feb 22 15:40:55 natsu radvd[11505]: resetting ipv6-allrouters membership on tap-yume
Feb 22 15:40:55 natsu radvd[11505]: resuming normal operation
Feb 22 15:40:55 natsu radvd[11505]: RDNSS address fd8e:ffad:f447::100:53a received on tap-work from fe80::9a:12ff:febe:5ebb is not advertised by us
Feb 22 15:40:55 natsu radvd[11505]: DNSSL suffix romanrm.ru received on tap-work from fe80::9a:12ff:febe:5ebb is not advertised by us
Feb 22 15:40:55 natsu radvd[11505]: DNSSL suffix version6.ru received on tap-work from fe80::9a:12ff:febe:5ebb is not advertised by us
Feb 22 15:40:55 natsu radvd[11505]: attempting to reread config file
Feb 22 15:40:55 natsu radvd[11505]: resuming normal operation

1) radvd somehow receives the DNS parameters it was supposed to send from one interface, on another.

2) What's much worse, in its "resuming normal operation" it proceeds to announce the 2002:xxxx:xxxx:4::1/64 prefix
and the default route into the wrong device (tap-work)!!!, sending at least one such RA into there, before returning
to sending normal ones as defined in the config. However this is enough for the client to configure an address out
of that prefix, add the incorrect default route, and via that completely break my connectivity.

-- 
With respect,
Roman

~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.litech.org/pipermail/radvd-devel-l/attachments/20120222/8055ec81/attachment.pgp>