Date: Wed, 19 Nov 2008 15:30:29 -0500 From: Randall Stewart <rrs@lakerest.net> To: Julian Elischer <julian@elischer.org> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: Thinking about UDP and tunneling Message-ID: <B08E77C5-CF11-42EE-9F9A-5E428CECF284@lakerest.net> In-Reply-To: <49245EE3.2000700@elischer.org> References: <D72E9703-C8E7-4A21-A71E-A4B4C2D7E8F4@lakerest.net> <49245EE3.2000700@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. | +-----+ Ideally it runs into UDP via ip_input() and comes down to where it would append() to the socket. What you want in this case is the whole mbuf chain to be sent to the transport_udp_input(m, offset) function This changes the above to +-----+ | IP | +-----+ | Oth | | tra | | por | | t h | | ead | | er | | and | | dat | | a. | +-----+ 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.. 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B08E77C5-CF11-42EE-9F9A-5E428CECF284>