Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Nov 2008 12:37:47 -0500
From:      Randall Stewart <rrs@lakerest.net>
To:        Max Laier <max@love2party.net>
Cc:        freebsd-net@freebsd.org, Julian Elischer <julian@elischer.org>
Subject:   Re: Thinking about UDP and tunneling
Message-ID:  <C38C5016-D263-42A9-9D90-2363B2EA64DE@lakerest.net>
In-Reply-To: <200811201450.30016.max@love2party.net>
References:  <D72E9703-C8E7-4A21-A71E-A4B4C2D7E8F4@lakerest.net> <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On Nov 20, 2008, at 8:50 AM, Max Laier wrote:

> On Thursday 20 November 2008 14:00:11 Randall Stewart wrote:
>> 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 =20
>>> it's
>>> unlikely). After you've processed the UDP part the IP part is gone =20=

>>> 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 =20=

>> 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...
>
> This sounds reasonable.  One would only have to replace calls to =20
> udp_append in
> udp_input with the by-pass function et voila.  Should be clean =20
> enough.  There
> might be some problems with holding the socket lock, though.
>
> For the record, I don't like all the UDP-tunneling madness either, =20
> but it
> seems that we are stuck with it ... so we should at least try to =20
> come up with
> a somewhat reasonable implementation for this hackery.

Max:

This was along the lines of what I was thinking exactly.. one side
note. I am told by my colleague in SCTP crime (Michael T=FCxen) that =
Apple
has this functional by-pass interface. He has already got the UDP =20
tunneling
code working in the MAC version of our stack :-)

I will start working on this when I get back from the IETF. I need to =20=

finish
up the NAT support stuff (almost done) and then I will start looking at
the locking issues that this may bring...

R


>
>
> --=20
> /"\  Best regards,                      | mlaier@freebsd.org
> \ /  Max Laier                          | ICQ #67774661
> X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
> / \  ASCII Ribbon Campaign              | Against HTML Mail and News
>

------------------------------
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?C38C5016-D263-42A9-9D90-2363B2EA64DE>