Date: Thu, 17 Oct 2002 13:47:06 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Vincent Jardin <vjardin@wanadoo.fr> Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Netgraph TCP/IP Message-ID: <3DAF21CA.60031059@mindspring.com> References: <20021017110456.G15035@sjt-u10.cisco.com> <3DAF087C.7B148341@mindspring.com> <20021017200111.E98171503A0@venus.vincentjardin.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Vincent Jardin wrote:
> I do not think that you need a raw IP netgraph node. Something similar
> already exists. Why not use the ng_ksocket in order to open a raw IP socket
> under your TCP node ?
Because the packet will never get to your protocol processing, unless
you turn of standard TCP altogether, and even then, the pr_input will
not do the right thing for chaining the data up to a Netgraph node.
ip_input.c:
...
if (args.next_hop && ip->ip_p == IPPROTO_TCP) {
/* TCP needs IPFORWARD info if available */
struct m_hdr tag;
tag.mh_type = MT_TAG;
tag.mh_flags = PACKET_TAG_IPFORWARD;
tag.mh_data = (caddr_t)args.next_hop;
tag.mh_next = m;
(*inetsw[ip_protox[ip->ip_p]].pr_input)(
(struct mbuf *)&tag, hlen);
} else
(*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen);
...
For this to work, you have to have a pr_input that glues into a
Netgraph entry point, so that IP packets of a specific protocol
type captured by the Netgraph node get passed to it.
There is also the m_pullup() issue of the TCP protocol that is
being passed IP datagrams which may be frags of TCP packets, in
order to get the full TCP header, with options.
Minimally, the approach has to be a seperate TCP stack, which is
given a different protocol number for the purposes of experiment,
so that you can have a duplicate TCP stack on both sides using
the normal mechanism, and replace it on one side with the Netgraph
version equivalen.
See the LRP implementation from Rice University, or the updated
port by Duke University. They both use this approach to run a
stack, and other primitives, in paralell on the system. That is
also why the code, as it sits in their source bases, would take
some work to integrate fully into FreeBSD (license issues aside)
as the default protocol processing path. Actually, it would take
much longer now that the SYN cache and the polling code has
obfuscated things.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DAF21CA.60031059>