Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Dec 2001 11:15:14 -0800
From:      Brooks Davis <brooks@one-eyed-alien.net>
To:        Eugene Grosbein <eugen@www.svzserv.kemerovo.su>
Cc:        stable@FreeBSD.ORG
Subject:   Re: buggy gif in 4.4-STABLE (2 November 2001)
Message-ID:  <20011221111514.A30629@Odin.AC.HMC.Edu>
In-Reply-To: <20011221143743.A68938@svzserv.kemerovo.su>; from eugen@www.svzserv.kemerovo.su on Fri, Dec 21, 2001 at 02:37:43PM %2B0700
References:  <20011221143743.A68938@svzserv.kemerovo.su>

next in thread | previous in thread | raw e-mail | index | archive | help

--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 21, 2001 at 02:37:43PM +0700, Eugene Grosbein wrote:
> 1. It is impossible to kldload if_gif.ko when kernel was compiled without=
 IPv6.=20

If you're building a custom kernel you should compile in your devices.
Due to poor design of the module build system, the modules will only
work reliably with kernels that are sufficently similar to GENERIC.  If
you really feel it's necessicary to do this you can edit
src/sys/modules/if_gif/Makefile and change the defintion of INET6 to 0.

>=20
> 2. Suppose we need IPv4 over IPv4 tunnel. We can use=20
> ifconfig gif0 create tunnel a.a.a.a b.b.b.b
> ifconfig gif0 inet ....
>=20
> If right route to b.b.b.b was 'default route' at gif0 creation time
> and than we add new record to routing table that makes route
> for b.b.b.b explicitly via another host, tunnel will be broken.
> Kernel will still pass tunneled packets to the default route instead of
> using new one. You must destroy gif0 completely:=20
> 'ifconfig gif0 down delete' is not enough,
> 'ifconfig gif0 deletetunnel' does not helps too,
> you must use 'ifconfig gif0 destroy' and then recreate gif0 and tunnel
> from scratch. This seems not to be right thing.

Um, don't do that. :-)  I'm not sure why this happens, but there
certaintly have been routing bugs related to gif in the past.  I can't
see why this situation would occure in normal operation anyway.

-- Brooks

--=20
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

--MGYHOYXEY6WxJCY8
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8I4pBXY6L6fI4GtQRAq7HAJ9DoyBlG/xw2CURQrUgpEb37jKrVQCgrrSX
TUovxlwc1IZ1TY0IwBD1/Ko=
=8I7q
-----END PGP SIGNATURE-----

--MGYHOYXEY6WxJCY8--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011221111514.A30629>