From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 20:50:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BF2110656F2 for ; Wed, 19 Nov 2008 20:50:14 +0000 (UTC) (envelope-from prvs=julian=202b42db1@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 219668FC17 for ; Wed, 19 Nov 2008 20:50:13 +0000 (UTC) (envelope-from prvs=julian=202b42db1@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.75]) by smtp-outbound.ironport.com with ESMTP; 19 Nov 2008 12:49:52 -0800 Message-ID: <49247BEE.4040201@elischer.org> Date: Wed, 19 Nov 2008 12:49:50 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Randall Stewart References: <49245EE3.2000700@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: Thinking about UDP and tunneling X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 20:50:14 -0000 Randall Stewart wrote: > > On Nov 19, 2008, at 1:45 PM, Julian Elischer wrote: > >> Randall Stewart wrote: >>> Dear All: >>> I have been contemplating UDP and tunneling. One of the >>> things that is a nice feature in MacOS is the ability of >>> a kernel module/extension to open a kernel level socket >>> and have the mbuf chain that arrives for that port be passed >>> in via a function. >> >> define "kernel level" and "mbuf chain that arrives [...] passed in via >> a function" >> >> >> >>> We use this in our MacOS version of the SCTP stack to do the >>> UDP de-tunneling of SCTP packets. This is becoming a more and >>> more common thing i.e. having transport protocols like SCTP and DCCP >>> be tunneled over UDP to get by NAT's.... this actually sucks that >>> this is necessary .. but it is what it is.... >> >> I do that using netgraph.. >> set a point ot point ng_iface and hook the other end to >> a netgraph ksocket which is bound/connaected where you want. >> >> "just works" >> >>> So, I am contemplating adding a similar sort of feature... basically >>> provide an interface in UDP that a consumer (such as SCTP or DCCP) could >>> use to "bind" a port and get UDP packets directly. >>> What do you all think of the idea? >> >> Well netgraph allows you to do it already > > > Not sure what netgraph does... what is wanted is this in comes > > > +-----+ > | IP | > +-----+ > | UDP | > +-----+ > | Oth | > | tra | > | por | > | t h | > | ead | > | er | > | and | > | dat | > | a. | > +-----+ Othtra port header and data.? > > > Ideally it runs into UDP via ip_input() > and comes down to where it would append() to the socket. At this point, netgraph grabs it and passes the mbufs wherever you tell it to pass them. > > What you want in this case is the whole mbuf chain to be sent > to the transport_udp_input(m, offset) function cd /sys root@trafmon1:grep transport_udp_input net*/* root@trafmon1:grep transport_udp_input net*/*/* > > This changes the above to > +-----+ > | IP | > +-----+ > | Oth | > | tra | > | por | > | t h | > | ead | > | er | > | and | > | dat | > | a. | > +-----+ where does the new IP header information come from? > > And sends it into the transport_input() (same one called by ip_input). > > This then makes a clean and easy way to have "tunneled UDP" transport > protocols > work in kernel. The input side looks the same. Output is pretty easy.. > easy to > drop a UDP header in out output... > > > Netgraph would have to be watching every UDP packet always.. just those that go to that ksocket. we hook on at the socketbuf point. > > seems to me easier to bind a kernel level socket with some option > to call an input function.... > > R > > > >> >> >>> That also reminds me.. who owns the ipfw code.. we actually >>> have SCTP nat support that Jason But has done that we need to >>> get in... >>> I would be more than glad to shepherd this in if the owner >>> of the code does not have the time... >>> R >>> ------------------------------ >>> Randall Stewart >>> 803-317-4952 (cell) >>> 803-345-0391(direct) >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > 803-345-0391(direct)