Date: Fri, 12 Dec 2008 07:56:38 -0500 From: Randall Stewart <rrs@lakerest.net> To: Max Laier <max@love2party.net> Cc: freebsd-net@freebsd.org Subject: Re: Heads up --- Thinking about UDP and tunneling Message-ID: <11F9C4F4-E893-46DA-96C3-1984131159D6@lakerest.net> In-Reply-To: <200812111412.16757.max@love2party.net> References: <D72E9703-C8E7-4A21-A71E-A4B4C2D7E8F4@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <200812111412.16757.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > ------------------------------ 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?11F9C4F4-E893-46DA-96C3-1984131159D6>