Date: Wed, 19 Nov 2008 16:30:27 -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: <905A5B58-54D2-4B79-A1B4-44C6D5136691@lakerest.net> 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 Nov 19, 2008, at 3:49 PM, Julian Elischer 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.? Of course... full transport layer header.. for sctp its port port vtag checksum first-chunk header etc.. > > > >> 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. Sounds interesting... two questions: 1) And how do we configure netgraph to do this? (pointers to doco's is fine) 2) Is netgraph in the GENERIC... I would like to see this work out of the box.. > > >> 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? Its not new, its the same ip header.. Its just you go into the mbuf chain and take out the udp header... > > >> 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. Hmm sounds plausible.. R > > >> 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) > > _______________________________________________ > 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?905A5B58-54D2-4B79-A1B4-44C6D5136691>