Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Jul 2001 16:21:12 -0700
From:      Brooks Davis <brooks@one-eyed-alien.net>
To:        Julian Elischer <julian@elischer.org>
Cc:        net@freebsd.org
Subject:   Re: error in ip_checkinterface code?
Message-ID:  <20010724162111.A14440@Odin.AC.HMC.Edu>
In-Reply-To: <3B5CE50D.D57F5E72@elischer.org>; from julian@elischer.org on Mon, Jul 23, 2001 at 08:01:33PM -0700
References:  <20010723184418.B28097@Odin.AC.HMC.Edu> <3B5CE50D.D57F5E72@elischer.org>

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

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

On Mon, Jul 23, 2001 at 08:01:33PM -0700, Julian Elischer wrote:
> Brooks Davis wrote:
> >=20
> > I just ran into what appears to be a bug in the ip_checkinterface code.
> > The problem is that is assumes m->m_pkthdr.rcvif is non-NULL.
> > Apparently this is normally true, but I have some netgraph code that
> > processes it's processes in such a way that they lose their interface
> > pointer which means that when I stick them back into the ip_stack get a
> > panic.  A quick patch that fixes the problem is included below.  Is
> > this fix correct?
>=20
> another possibility is to assign an incoming interface to the reinjected =
packet
> :-)

The problem with that is I'd basicaly just have to invent one because
at that point I have no easy way of knowing where the packet came from.
The other place ip_input() looks at the interface, it check that it
exists first so there is some precident.

> (what are you using netgraph for?)

I'm using it to direct traffic from a number of agents through a userland
network simulator.  Each agent sits at the end of an IP over IP tunnel
connected to a gif interface.  I've written part of an ng_gif module
based on ng_ether to provide access to all packets arriving over the
interface.  An ng_gif_demux module allows me to take all the inet
packets off of each interface.  An ng_one2many node is used to
consolidate packets from these interfaces and feed them into an ng_split
node which currently feeds them to the userland via an ng_socket node.
On return from the simulator (currently, "nghook -l -n -a split:
mixed"), the split node passes the packet to an ng_ip_input node which
simply accepts packets, shoves them onto the ip input queue and
schedules an ip soft interupt.  This is where the current ip_input()
gets into trouble because the mbuf created by ng_socket does not contain
an interface pointer.

In the final version, there will be a small address translator between the
ng_split and ng_socket nodes handling a hack which will allow multiple
agents to exist on the same host and still be forced to talk through
the simulator without significant code modifications.

There's a somewhat inaccurate picture at:

http://people.freebsd.org/~brooks/tnt-netgraph.ps

Assuming our funding for this didn't just totally vanish, I'm hoping to
have a paper to present on this for BSDCon.

-- 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

--opJtzjQTFsWo+cga
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

iD8DBQE7XgLmXY6L6fI4GtQRAhsdAKDc2semulMxBC6vH/X0Bky7pTbOogCgramJ
XJLXPNBmbxaWd3evg8G5/rM=
=fdFf
-----END PGP SIGNATURE-----

--opJtzjQTFsWo+cga--

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




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