Date: Thu, 17 Oct 2002 16:03:12 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Vincent Jardin <vjardin@wanadoo.fr>, freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Netgraph TCP/IP Message-ID: <Pine.BSF.4.21.0210171450440.2971-100000@InterJet.elischer.org> In-Reply-To: <3DAF21CA.60031059@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 17 Oct 2002, Terry Lambert wrote:
> 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);
>
> ...
This has been changed with the addition of the new OOB tag metadata
methods committed by sam Leffler a few days ago. This were specifically
designed to co-operate with the netgraph OOB data requirements. I will
be modifying netgraph over the next few weeks (I hope) to use the new
scheme. This will allow seamless flow of metadata between netgaph and
other networking components. (e.g. the 'fwd' info above)
>
> 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.
it will all "fall into place" with the new scheme, once I
have converted netgraph to use 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.
The tcp code should handle this anyway.
>
> 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.
Not necessarily.. if each stack can 'reject' a packet.. ("not mine").
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?Pine.BSF.4.21.0210171450440.2971-100000>