From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 21:51:25 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 A78511065679 for ; Wed, 19 Nov 2008 21:51:25 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 77D638FC18 for ; Wed, 19 Nov 2008 21:51:25 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so141256rvb.1 for ; Wed, 19 Nov 2008 13:51:25 -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=BOFYqXV/QEphEpolRPkaiqqpkt5KAN+UcMJ/aq0pwJk=; b=qExo3mg120fDIjeklRdttYCkyfzKciRAHeLVAUXifJe7QC9byLVl2JEoFQ0Gl/Ptpi eotOQsvszmQwe/kvCMerlamd7TZfix2OGYraN0xTYS9r/t4nizGgtEwbMaKyAXkrZYoW Hb20Q+UK3VsxpVgCjBvi+BXF8k70+LQ8HkQGk= 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=SF8R4kp7UEqW1ip5Oki1PiZQCVJ9L/xz00siLjUfxJO7eNa7YJLR7P5g9EHZyP5MjO BGgIgPWOLfpyEMLWNz/MoWtIYkrs/p340TnXZ8WXjQDp/P2zCAyYfg/3TZOqLv9PrnzI H9BRimWDh4oJ/G7DpFAhvPS40oZWA4HD1wb+w= Received: by 10.141.5.17 with SMTP id h17mr826449rvi.165.1227131485244; Wed, 19 Nov 2008 13:51:25 -0800 (PST) Received: by 10.140.199.20 with HTTP; Wed, 19 Nov 2008 13:51:25 -0800 (PST) Message-ID: Date: Wed, 19 Nov 2008 13:51:25 -0800 From: "Maksim Yevmenkin" To: "Randall Stewart" In-Reply-To: <0252A647-464E-46A7-94E9-A0639083B5AE@lakerest.net> 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> <0252A647-464E-46A7-94E9-A0639083B5AE@lakerest.net> Cc: freebsd-net , Julian Elischer 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:51:25 -0000 [...] > > > 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 > > > > > Ok, let me go read the ng_ man.. > > I would not use the reverse path.. the ability to send > encap'd udp packets is already in sctp.. after all all you > are doing is dropping an extra header on it.. SCTP (and other > transports) will want to control the way the IP header looks.. at > least if they are multi-homed... so I don't think one would > want to do output via ng.. just getting the data in is all > thats missing in FreeBSD.. in this case its even easier. if you do not need reverse path, then all you need to do is to write a very small ng_ node that would 1) connect to the ng_ksocket(4) node's hook; and 2) inject received data into sctp/etc. input path so, you graph would look like [ng_ksocket] <- inet/dgram/udp -> [ng_sctp_injector] you might need an injector node do decouple netgraph from the rest of the sctp/etc. stack. alternatively, you may wish to provide netgraph hooks into sctp/etc. stack. > As long as netgraph is in generic this may work.. it is generic to some degree. if inner protocol (i.e. sctp etc.) is not aware of netgraph, then you will need to write an injector node specific to each inner protocol (basically that knows how to inject data into the stack). since injector node is simple, you could teach it to deal with multiple inner transports. for example, you could have an injector node that have multiple input hooks, one for each supported inner transport, named "sctp", etc. the idea would be that everything received from "sctp" hook will be injected into sctp stack, etc. then you could have only one injector node that could deal with multiple ng_ksockets for different inner transports. thanks, max