Date: Wed, 19 Nov 2008 13:20:16 -0800 From: "Maksim Yevmenkin" <maksim.yevmenkin@gmail.com> To: "Randall Stewart" <rrs@lakerest.net>, "Julian Elischer" <julian@elischer.org> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: Thinking about UDP and tunneling Message-ID: <bb4a86c70811191320l261981b9yc108474189d1cfa3@mail.gmail.com> In-Reply-To: <49247BEE.4040201@elischer.org> References: <D72E9703-C8E7-4A21-A71E-A4B4C2D7E8F4@lakerest.net> <49245EE3.2000700@elischer.org> <B08E77C5-CF11-42EE-9F9A-5E428CECF284@lakerest.net> <49247BEE.4040201@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/19/08, Julian Elischer <julian@elischer.org> wrote: > 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.? i think it means: "other transport port header and data", that is take a complete sctp/etc. datagram and stuff in inside udp datagram as payload. > > > > > > > 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. that's right. basically, use ng_ksocket(4). that would be your tunnel (outer) endpoint which you would bind to udp protocol, given address and port. now everything that remote tunnel (outer) endpoint will send via udp (payload) will end up in ng_ksocket(4) node and will be sent out to ksocket's hook. you can connect whatever you want to that hook. either move payload back into userspace, or use another ng node, or just inject the data directly into sctp/etc. input routine. reverse path is the same. playload comes from the hook and gets sent out via udp > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70811191320l261981b9yc108474189d1cfa3>