From owner-freebsd-net@FreeBSD.ORG  Tue Nov 23 10:14:04 2004
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 616D916A4CE; Tue, 23 Nov 2004 10:14:04 +0000 (GMT)
Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id E5AB243D2D; Tue, 23 Nov 2004 10:14:02 +0000 (GMT)
	(envelope-from on@cs.ait.ac.th)
Received: from mail.cs.ait.ac.th (localhost.cs.ait.ac.th [127.0.0.1])
	by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id iANAE0s2098976
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Nov 2004 17:14:00 +0700 (ICT)
Received: (from on@localhost)
	by mail.cs.ait.ac.th (8.12.11/8.12.11/Submit) id iANAE07p098973;
	Tue, 23 Nov 2004 17:14:00 +0700 (ICT)
Date: Tue, 23 Nov 2004 17:14:00 +0700 (ICT)
Message-Id: <200411231014.iANAE07p098973@mail.cs.ait.ac.th>
From: Olivier Nicole <on@cs.ait.ac.th>
To: rwatson@freebsd.org
In-reply-to: <Pine.NEB.3.96L.1041123093708.66539K-100000@fledge.watson.org>
	(message from Robert Watson on Tue, 23 Nov 2004 10:00:55 +0000 (GMT))
X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/)
cc: net@freebsd.org
Subject: Re: Running into an mbuf leak with bridging and tap
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Nov 2004 10:14:04 -0000

> I'm running an ethernet over TCP bridge using a combination of the native
> ethernet bridge support and the tap driver.  Basically, a daemon sits on
> /dev/tapX and bridges ethernet frames using a small header over a TCP

Yup i think I have seen the same thing while I was using a combination
of vtun (IP over IP tunnelling), tap and bridge.

As it was a one day only experiment that was not critical and I just
incresed mbuf.

Olivier