On Nov 19, 2008, at 5:33 PM, Julian Elischer wrote:
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).
One would definitely have to do some work in udp_input() not a lot from
what I can tell... but it would take some work.
Maybe good course is to use the socket(9) stuff, but add an option
that can set a "by-pass function" if the socket is udp... right
after you establish the INP the packet goes to, if the function is
set, you engage the bypass...
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'
You need to take a look at some of the activities in tsvwg and the
transport area
open area meeting in the IETF. Not counting Jonathan's Rosenburgs IAB
presentation
an IETF or two ago claiming that "all new transports must tunnel via
UDP". This
seems to be a more and more common theme in the IETF.
Now I personally do not agree that new transports cannot be deployed
without UDP
tunneling.. however there will always be the need for this IMO.. since
you will
often have NAT's that don't know about the new transport "yet"...
Jonathan (and others
claims is that the "yet" is really a "never".. here I disagree).
Having infrastructure so we can do UDP tunneling of a new transport
easily is IMO
a good idea.
Netgraph, looks interesting.. but I am afraid is not in GENERIC.. so
you end up with
a solution that only sometimes works. What I am thinking is a clean
way to have
kernel sockets(9) extended a bit so that we can better support
tunneling input...
Let me chew on this a while and come up with a working solution ...
using socket(9) as
much as possible... I think a couple of tweaks will be needed.. but I
think its quite
feasible and will be a benefit for not just SCTP but also DCCP and
some of the other
transports on the horizon...
R
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
------------------------------
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 "[EMAIL PROTECTED]"
