From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 21:40:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 679CA1065675 for ; Wed, 19 Nov 2008 21:40:39 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id 36A058FC1A for ; Wed, 19 Nov 2008 21:40:39 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so129775rvf.43 for ; Wed, 19 Nov 2008 13:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=7GrqorTzU98aItaVTVSKHcjePZHZkHs45iodo20aLTU=; b=IufsdnPO9zCi5yGxUFhNYRKVbPAM01Tg8IdtXUjy72Mf8HcMJCTJ68HlEamr8CPGU9 d1KRwtG8KiEbn7HzvCtSnZiF52j/n3RbGGPfROhHgypJzYZF/9NlL90nZmW5n4C5Qznu IZ19857ioLFA2wIvrisHcmxEKrsZagN7N9YHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=IqyLswr/Ppmn1kMVRNQGoYeJW2hn0aXa1b5r5Lo1/BOb0fd8yBfSKoCiH3911DuTx9 OP0XOK1QHwZuFcW09xZU9Ayo98QFAjaSN1HlQs/+5XkV9f+8JoPnsHiOJOrzTtNfZERQ SIOO9t7ZxB3ocTa4odOBjpY596xJEzI134NNM= Received: by 10.140.170.21 with SMTP id s21mr807037rve.205.1227129616403; Wed, 19 Nov 2008 13:20:16 -0800 (PST) Received: by 10.140.199.20 with HTTP; Wed, 19 Nov 2008 13:20:16 -0800 (PST) Message-ID: Date: Wed, 19 Nov 2008 13:20:16 -0800 From: "Maksim Yevmenkin" To: "Randall Stewart" , "Julian Elischer" In-Reply-To: <49247BEE.4040201@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49245EE3.2000700@elischer.org> <49247BEE.4040201@elischer.org> Cc: freebsd-net Subject: Re: Thinking about UDP and tunneling X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 21:40:39 -0000 On 11/19/08, 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.? i think it means: "other transport port header and data", that is take a complete sctp/etc. datagram and stuff in inside udp datagram as payload. > > > > > > > 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. > > > > > > What you want in this case is the whole mbuf chain to be sent > > to the transport_udp_input(m, offset) function > > > > cd /sys > root@trafmon1:grep transport_udp_input net*/* > root@trafmon1: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? > > > > > > 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. that's right. basically, use ng_ksocket(4). that would be your tunnel (outer) endpoint which you would bind to udp protocol, given address and port. now everything that remote tunnel (outer) endpoint will send via udp (payload) will end up in ng_ksocket(4) node and will be sent out to ksocket's hook. you can connect whatever you want to that hook. either move payload back into userspace, or use another ng node, or just inject the data directly into sctp/etc. input routine. reverse path is the same. playload comes from the hook and gets sent out via udp > > > > seems to me easier to bind a kernel level socket with some option > > to call an input function.... > > > > R > > > > > > > > > > > > > > > > > > > > > That also reminds me.. who owns the ipfw code.. we actually > > > > have SCTP nat support that Jason But has done that we need to > > > > get in... > > > > I would be more than glad to shepherd this in if the owner > > > > of the code does not have the time... > > > > R