Thinking about UDP and tunneling

[Julian Elischer]

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 at trafmon1:grep transport_udp_input net*/*
root at 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 at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>
> 
> ------------------------------
> Randall Stewart
> 803-317-4952 (cell)
> 803-345-0391(direct)