Heads up --- Thinking about UDP and tunneling

Randall Stewart rrs at lakerest.net
Fri Dec 12 04:56:41 PST 2008


On Dec 11, 2008, at 8:12 AM, Max Laier wrote:

> On Thursday 11 December 2008 13:50:39 Randall Stewart wrote:
>> All:
>>
>> Ok here is what I have come up with.. going along the
>> lines of Max's suggestion.. its pretty clean I think.
>>
>> Comments would be most welcome..
>>
>> The only thing possibly a bit dodgy is that
>>
>> 1) UDP has no per-protocol block.
>> 2) Instead of creating one, I am using the block pointer in the inp
>>    as the function pointer for the tunneling.
>>
>> What this means if we EVERY did add a per protocol structure for
>> UDP we would need to move the function pointer in there..
>>
>> The nice thing it does is make it so we have no structural changes to
>> the code... i.e. complete compatibility... no changes to inp or
>> other UDP structures :-)
>>
>>
>> Here is the patch.. please send comments ;-D
>
> I like it, though I have no idea what the implications of using the  
> block
> pointer might be.
>
> One thing about the patch:  What about the multi-/broadcast cases?   
> I think if
> we introduce this, we want to make sure it works there as well - no?

Hmm.. Well I don't know if I like the idea of the broadcast/ 
multicast... for
tunneling.. Then again.. you may be right.. thinking on this DCCP can do
multicast as well.. so let me go look at it.


>
>
> And finally, is there a potential race with setting the function and  
> data
> arriving at the socket - should udp_set_kernel_tunneling maybe check  
> that the
> socket isn't bound yet?

Yep, in fact I figured that out as I started trying to get SCTP to
use this. We HAVE to have it un-bound when you do the  
set_kernel_tunneling
function... that way you can make sure no packets have arrived for
you BEFORE you bind.

So I have removed the bind restriction.

Another thing... kinda weird.. when I have this thing working with  
SCTP and I
let the SCTP stack try to initialize the socket right away.. I get bogus
results. The port is actually binding.. but yet it cant be sent to. If I
unbind i.e. close the socket that got created.. then do a sysctl to re- 
add
the same port.. all works fine.

For now I am going to make SCTP NOT do this.. and have to add it to the
sysctl's in /etc/sysctl.conf to add UDP tunneling.

Only other solution would be a timer in the transport after startup to
do this binding...

I was wondering if I would see a race in the protocol stack  
initialization.. basically
my guess is SCTP initializes ahead of UDP.. so its actually a wonder I  
did not crash ;-D

R

>
>
> -- 
> /"\  Best regards,                      | mlaier at freebsd.org
> \ /  Max Laier                          | ICQ #67774661
> X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
> / \  ASCII Ribbon Campaign              | Against HTML Mail and News
> _______________________________________________
> 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)



More information about the freebsd-net mailing list