From owner-freebsd-hackers Tue Mar 9 8:53:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id B8C8E14E1D for ; Tue, 9 Mar 1999 08:53:28 -0800 (PST) (envelope-from terry@ppsl.demon.co.uk) Received: from [158.152.16.214] (helo=yeoman.ppsl.co.uk) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 10KPki-0005F7-0B for freebsd-hackers@freebsd.org; Tue, 9 Mar 1999 16:53:08 +0000 Date: Tue, 9 Mar 99 16:52:52 GMT Message-Id: <9903091652.AA04146@ppsl.demon.co.uk> From: Terry Glanfield To: freebsd-hackers@freebsd.org Subject: Tunnel loopback Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I've been trying to use a FreeBSD (3.0-RELEASE and 3.1-RELEASE) tunnel device (/dev/tunN) to push packets back onto the IP stack[1] with some success. Firstly I redirect all packets on one interface (ed0) to the tunnel using IPFilter: pass in quick on ed0 to tun0 all Then with a simple read/write loop attached to /dev/tun0 I can bounce all packets back in again. This works up to a point. I'm finding that a single icmp packet send into tun0 results in thousands of packets entering my read/write loop before one packet finally finds its way out again. If I insert a short sleep between the read and write calls the number of packets are reduced but the overall time taken remains constant (~1 second). Hacking the loopback into the kernel (if_tun.c) results in a similar time scale but hundreds of thousands of packets being bounced around. I get the feeling I'm missing something obvious. Short-term state information or optimisations maybe? Any pointers would be much appreciated. Regards, Terry. [1] The idea is to mix NAT and SKIP on the same box by doing the SKIP encryption on a different interface before it hits NAT. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message