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

Reuben Hawkins reubenhwk at gmail.com
Wed Feb 22 12:45:48 EST 2012


On Wed, Feb 22, 2012 at 1:56 AM, Roman Mamedov <rm at romanrm.ru> wrote:
> 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."
>
> --
> radvd-devel-l mailing list  :  radvd-devel-l at litech.org
> http://lists.litech.org/listinfo/radvd-devel-l


Hi Roman,

Can you send more debug info?  Run radvd like so and send in the output...

$ sudo radvd -m stderr -d 5 --nodaemon

Thanks,
Reuben



More information about the radvd-devel-l mailing list