Date: Wed, 19 Nov 2008 12:49:50 -0800 From: Julian Elischer <julian@elischer.org> To: Randall Stewart <rrs@lakerest.net> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: Thinking about UDP and tunneling Message-ID: <49247BEE.4040201@elischer.org> In-Reply-To: <B08E77C5-CF11-42EE-9F9A-5E428CECF284@lakerest.net> References: <D72E9703-C8E7-4A21-A71E-A4B4C2D7E8F4@lakerest.net> <49245EE3.2000700@elischer.org> <B08E77C5-CF11-42EE-9F9A-5E428CECF284@lakerest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49247BEE.4040201>