[radvd-devel-l] radvd wrongly sends all subnets from all interfaces to the first interface

[Roman Mamedov]

On Wed, 27 Jun 2012 07:13:57 -0700
Reuben Hawkins <reubenhwk at gmail.com> wrote:

> Is this the bug where a prefix for interface Y is send out on interface X?
> 
> I'm not sure what's happening here.  I added a debug message which 
> verifies the interface before sending a packet and it appears to be 
> working correctly, but isn't.  I haven't been able to figure out if this 
> is some kind of bug with sendmsg or if radvd is just using it incorrectly.

As of now I have determined that in this particular case all the
advertisements which are supposed to go over VLANs (eth0.2, eth0.3, eth0.9
etc), ALSO seem to be sent over eth0 (i.e. without the VLAN tag).

I don't believe this is the same bug that has been posted some time ago, where
adverts intended for one interface were seen on a completely different and
unrelated one (that one was related to addition and removal of devices).

But regarding the VLAN issue, I have experienced a similar problem with ISC
DHCPD: it sees all DHCP requests sent by hosts on VLAN 2 (and to be received
on eth0.2) as though they come untagged to eth0. It turned out that it is
related to the use of SOCK_RAW, which doesn't seem to play well with VLANs:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643564
There's some kind of a patch available there.

In the radvd source code I noticed that it also uses SOCK_RAW. Maybe this is
where the problem lies? To reproduce, I suggest that you set up a test box
configuring VLANs on a radvd server (e.g. setting up a VLAN interface eth0.2
and configuring both eth0 and eth0.2 separately in radvd.conf), and see if your
clients on the LAN which have no VLAN set up also receive RAs that were
intended for eth0.2.

-- 
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/20120627/3e8c0372/attachment.pgp>