From owner-freebsd-net@FreeBSD.ORG Wed Oct 8 05:18:13 2003 Return-Path: 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 57C5616A4B3 for ; Wed, 8 Oct 2003 05:18:13 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3919A43F93 for ; Wed, 8 Oct 2003 05:18:12 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id B8825654DF; Wed, 8 Oct 2003 13:18:10 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 52800-03-5; Wed, 8 Oct 2003 13:18:10 +0100 (BST) Received: from saboteur.dek.spc.org (unknown [81.3.72.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id EFB72653B5; Wed, 8 Oct 2003 13:18:09 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 0275638; Wed, 8 Oct 2003 13:17:55 +0100 (BST) Date: Wed, 8 Oct 2003 13:17:55 +0100 From: Bruce M Simpson To: Peter Bozarov Message-ID: <20031008121755.GA83114@saboteur.dek.spc.org> Mail-Followup-To: Peter Bozarov , freebsd-net@freebsd.org References: <3F83E2A7.8070209@moniforce.com> <20031008101733.GI6524@saboteur.dek.spc.org> <3F83F37A.7020908@moniforce.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F83F37A.7020908@moniforce.com> cc: freebsd-net@freebsd.org Subject: Re: Recovery from mbuf cluster exhaustion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Oct 2003 12:18:13 -0000 On Wed, Oct 08, 2003 at 01:22:34PM +0200, Peter Bozarov wrote: > I'm using 4.7. I have three interfaces, rl0, xl0, and xl1. Support for 4.7 is very limited as we transition to 4.9, please be prepared to upgrade the box. Bear in mind we commit fixes for problems to HEAD first except in those cases where RELENG_4 is more appropriate. > The rl0 interface is a RealTek 8139 10/100BaseTX, the > xl* are two 3Com 3c905-TX Fast Etherlink XL cards. > This is what my routing tables look like. [snip] I spot only one possible inconsistency. (Well, two if you count the use of subnet-zero, but this is academic as nearly everybody follows RFC 950 these days). Did you add the 10.2.1.68 route manually? Note that there is code in if_ethersubr.c which should loopback a copy of a packet sent on an IFF_SIMPLEX interface automatically, so it shouldn't be required. For example, on my laptop: 192.168.1.68 00:04:76:5e:ec:7d UHLW 0 2 lo0 This route is created automatically by arp_rtrequest(). The RTF_WASCLONED (W) flag tells us this. Because ether_output() is calling if_simloop() to loopback the packets, the RTF_LLINFO (L) flag gets ignored. Try removing this route and see what happens. > My machine serves as a bridge between the 10.0.0.0/24 (xl0) and > the 10.2.1.0/24 networks (rl0). xl1 is not being used. I've made > a tcpdump of machines on the 10.2.1.0/24 network communicating > with the internet. Now, on the 10.0.0.0/24, I have a sniffer. I'm > trying to test the program by injecting the tcpdump file into > the 10.0.0.0/24 network. Apparently, since some of the outgoing > traffic on xl0 is originated on or is meant for the localhost > (10.2.1.68) the xl0 driver starts buffering/passing those segments > to the kernel (xl0 is in promiscuous mode). ^^^^^^^^^^^^^^^^^^^^^^^^^^ Are you using the bridging code to do this? If so, can you post the bridging configuration? I'm not at all familiar with the bridging code, but I am giving it a read just now, hopefully Luigi will step in. > How do I cause the driver (or whatever it is) that's hogging the > clusters to relinquish them? Unfortunately it doesn't quite work that way... you are exercising a leak somewhere and it needs to be tracked down. You should collate all the information as we track this thread and prepare to submit a PR. BMS