Randall Stewart wrote:
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..
yes, well I don't know what is loaded by default.
What you want in this case is the whole mbuf chain to be sent
to the transport_udp_input(m, offset) function
cd /sys
[EMAIL PROTECTED]:grep transport_udp_input net*/*
[EMAIL PROTECTED]: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...
well you can't do that at the socket buffer becasue you've discarded
the IP header. It may not even be in the mbufs you have. (though it's
unlikely). After you've processed the UDP part the IP part is gone so
you'd need to intercept the packet way earlier and then do your
own UDP processing, (or maybe attach the IP header onto it with a
tag).
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..
what you are suggesting is UDP header injection, between the existing
IP header and existing SCTP header, then on reception, stripping it out.
We'd have to do a bit of hacking to do that.. it's kind of 'unusual'
in-kernel UDP encapsulation is easy but we don't have header injection..
I can see how one would do it
but I was wrong before, you'd need to do some work.
R
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
