Date: Tue, 18 Jan 2005 11:10:28 GMT From: Gleb Smirnoff <glebius@freebsd.org> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/75121: Wrong behaviour of IFF_LINK2 bit in 6in6 gifs? Message-ID: <200501181110.j0IBASOL090436@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/75121; it has been noted by GNATS. From: Gleb Smirnoff <glebius@freebsd.org> To: Antonio Tapiador del Dujo <atapiador@dit.upm.es> Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/75121: Wrong behaviour of IFF_LINK2 bit in 6in6 gifs? Date: Tue, 18 Jan 2005 13:57:51 +0300 Antonio, On Wed, Dec 15, 2004 at 07:22:00PM +0100, Antonio Tapiador del Dujo wrote: A> >Description: A> I'm researching on IPv6 multihoming. A> I need a generic 6in6 tunnel interface that accepts packets from any source, so I tried with the IFF_LINK2 as said in gif(4), but it didn't work. A> Looking at the code, I found out the address checks are done regardless of the IFF_LINK2 (netinet6/in6_gif.c, line 318) A> Shouldn't these checks take into account the IFF_LINK2? A> Moving them inside the next if works as I expected. No they shouldn't. Perhaps you have some misconfiguration with your tunnels. If you have tunnel configured as X <-> Y on machine A, then you MUST have tunnel configured Y <-> X on machine B. This is requirement for gif protocol. Otherwise you will have odd and undefined behavior, when multiple tunnels terminate on one box. The IFF_LINK2 means that incoming tunnel packets may come from interface different to interface we use for sending out tunnel packets. If you don't mind, I close the PR. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501181110.j0IBASOL090436>