From owner-freebsd-net@FreeBSD.ORG Sun Oct 15 05:22:15 2006 Return-Path: X-Original-To: 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 0F9DA16A407 for ; Sun, 15 Oct 2006 05:22:15 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D40743D53 for ; Sun, 15 Oct 2006 05:22:14 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.176.222] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1GYyRv14eU-0002jX; Sun, 15 Oct 2006 07:22:11 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Sun, 15 Oct 2006 07:22:03 +0200 User-Agent: KMail/1.9.4 References: <20061014071416.64065.qmail@web56508.mail.re3.yahoo.com> In-Reply-To: <20061014071416.64065.qmail@web56508.mail.re3.yahoo.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3769149.ZUTpy8zbdG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200610150722.09919.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Dan b Subject: Re: reset netstat statistics 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: Sun, 15 Oct 2006 05:22:15 -0000 --nextPart3769149.ZUTpy8zbdG Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 14 October 2006 09:14, Dan b wrote: > I searched the archives for this and was unable to > find anything relevant. I have a machine that is > being used as a NAT Router with IPFW and IPNAT running > 5.3-RELEASE. I'm only using IPFW to keep track of > traffic, no actual packet filtering is going on. I recommend that you use pf for that. A simple pfctl -e with no ruleset=20 will get you 64bit packet and byte counters for all interfaces using=20 pfctl -vvsI or for a specific interface with: > 7:14 [~]amd64# pfctl -vvsI -i fxp0 > fxp0 (instance, attached) > Cleared: Fri Sep 29 23:24:37 2006 > References: [ States: 0 Rules: 15 ] > In4/Pass: [ Packets: 46986037 Bytes: 28315507365 ] > In4/Block: [ Packets: 0 Bytes: 0 ] > Out4/Pass: [ Packets: 43460700 Bytes: 40071770000 ] > Out4/Block: [ Packets: 0 Bytes: 0 ] > In6/Pass: [ Packets: 9982 Bytes: 3320321 ] > In6/Block: [ Packets: 0 Bytes: 0 ] > Out6/Pass: [ Packets: 5259 Bytes: 418780 ] > Out6/Block: [ Packets: 3 Bytes: 192 ] > The problem is that the statistics reported by netstat > seem to reset themselves intermittently. Last night I > ran netstat -ib and got an Ibytes stat of around 2.1GB > on my sis0 adapter. Today I ran netstat -ib and got > an Ibytes stat of around 600MB on my sis0 adapter. > The system has around 29 days of uptime, and I have > run ipfw zero a few times, but have not run netstat -z > at all. Let me know if you have any ideas about this. This is because the numbers reported by netstat are based on (signed)=20 32bit counters. Either you sample these numbers at a high enough rate or=20 you use other 64bit counters (see above). =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3769149.ZUTpy8zbdG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFMcWBXyyEoT62BG0RAtfnAJ9PSgQq+d/NCd2heAAy9VsktCbwygCePoxU jTNU8z3EXFZvtB8NxmHs7Ak= =6NHp -----END PGP SIGNATURE----- --nextPart3769149.ZUTpy8zbdG-- From owner-freebsd-net@FreeBSD.ORG Sun Oct 15 11:03:52 2006 Return-Path: X-Original-To: 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 1B09516A40F for ; Sun, 15 Oct 2006 11:03:52 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from slimak.dkm.cz (slimak.dkm.cz [62.24.64.34]) by mx1.FreeBSD.org (Postfix) with SMTP id 2C8BF43D46 for ; Sun, 15 Oct 2006 11:03:50 +0000 (GMT) (envelope-from 000.fbsd@quip.cz) Received: (qmail 81567 invoked by uid 0); 15 Oct 2006 11:03:49 -0000 Received: from grimm.quip.cz (HELO ?192.168.1.2?) (213.220.192.218) by slimak.dkm.cz with SMTP; 15 Oct 2006 11:03:49 -0000 Message-ID: <45321595.1010106@quip.cz> Date: Sun, 15 Oct 2006 13:03:49 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, en, cs, en-us MIME-Version: 1.0 To: Dan b References: <20061014071416.64065.qmail@web56508.mail.re3.yahoo.com> In-Reply-To: <20061014071416.64065.qmail@web56508.mail.re3.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: reset netstat statistics 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: Sun, 15 Oct 2006 11:03:52 -0000 Dan b wrote: > Hello, > > I searched the archives for this and was unable to > find anything relevant. I have a machine that is > being used as a NAT Router with IPFW and IPNAT running > 5.3-RELEASE. I'm only using IPFW to keep track of > traffic, no actual packet filtering is going on. > > The problem is that the statistics reported by netstat > seem to reset themselves intermittently. Last night I > ran netstat -ib and got an Ibytes stat of around 2.1GB > on my sis0 adapter. Today I ran netstat -ib and got > an Ibytes stat of around 600MB on my sis0 adapter. > The system has around 29 days of uptime, and I have > run ipfw zero a few times, but have not run netstat -z > at all. Let me know if you have any ideas about this. Counter resets itself after 4GB (it is not a bug, it is feature of 32bit counter as mentioned by Max Laier) Miroslav Lachman From owner-freebsd-net@FreeBSD.ORG Sun Oct 15 23:43:07 2006 Return-Path: X-Original-To: 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 B225D16A5AE for ; Sun, 15 Oct 2006 23:43:07 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt13.ihug.co.nz (grunt13.ihug.co.nz [203.109.254.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33E4E43D73 for ; Sun, 15 Oct 2006 23:43:00 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt13.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1GZFdD-00043d-00; Mon, 16 Oct 2006 12:42:59 +1300 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 36F7E1CC23; Mon, 16 Oct 2006 12:42:59 +1300 (NZDT) Date: Mon, 16 Oct 2006 12:42:59 +1300 From: Andrew Thompson To: freebsd-net@freebsd.org Message-ID: <20061015234259.GB1264@heff.fud.org.nz> References: <20061012111106.GH2566@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061012111106.GH2566@heff.fud.org.nz> User-Agent: Mutt/1.5.11 Subject: Re: RSTP code for test/review 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: Sun, 15 Oct 2006 23:43:07 -0000 On Fri, Oct 13, 2006 at 12:11:06AM +1300, Andrew Thompson wrote: > Hi, > > > Attached is a patch that brings in rapid spanning tree (802.1w) > support. I would appreciate any testing or code review. The states will > be printed out at the moment as packets are transfered and the topo is > calculated, these should stop when it becomes stable. Is there anyone using STP/RSTP in their network who is interested in testing this? The rapid spanning tree protocol will quickly transition ports to forwarding (around 1 second) compared to the 30 seconds for STP. http://people.freebsd.org/~thompsa/bridge_rstp.20061012.diff cheers, Andrew From owner-freebsd-net@FreeBSD.ORG Mon Oct 16 00:48:17 2006 Return-Path: X-Original-To: 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 70BF816A4B3 for ; Mon, 16 Oct 2006 00:48:17 +0000 (UTC) (envelope-from fwun@bigpond.net.au) Received: from imta08sl.mx.bigpond.com (imta08sl.mx.bigpond.com [144.140.93.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB8A843D45 for ; Mon, 16 Oct 2006 00:48:16 +0000 (GMT) (envelope-from fwun@bigpond.net.au) Received: from web08sl ([144.140.91.185]) by imta08sl.mx.bigpond.com with ESMTP id <20061016004814.JEYF10389.imta08sl.mx.bigpond.com@web08sl> for ; Mon, 16 Oct 2006 00:48:14 +0000 Received: Message-ID: <5945271.1160959694724.JavaMail.root@web08sl> Date: Mon, 16 Oct 2006 10:48:14 +1000 From: To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) Sensitivity: Normal Subject: Static route & NAT 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: Mon, 16 Oct 2006 00:48:17 -0000 Hi, I am wondering how to implement a freebsd router without NAT enbaled? There are 3 subnets connected to this freebsd router. all of them need to access the Internet. Thanks S From owner-freebsd-net@FreeBSD.ORG Mon Oct 16 06:13:01 2006 Return-Path: X-Original-To: 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 9E78C16A403 for ; Mon, 16 Oct 2006 06:13:01 +0000 (UTC) (envelope-from wagnerr@zoomtown.com) Received: from smtp2.fuse.net (mail-out2.fuse.net [216.68.8.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1710D43D55 for ; Mon, 16 Oct 2006 06:13:00 +0000 (GMT) (envelope-from wagnerr@zoomtown.com) Received: from gx6.fuse.net ([72.49.91.97]) by smtp2.fuse.net (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20061016061255.CBYI29181.smtp2.fuse.net@gx6.fuse.net> for ; Mon, 16 Oct 2006 02:12:55 -0400 Received: from raymond2 ([72.49.91.97]) by gx6.fuse.net (InterMail vG.1.02.00.02 201-2136-104-102-20041210) with ESMTP id <20061016061255.CNQK10743.gx6.fuse.net@raymond2> for ; Mon, 16 Oct 2006 02:12:55 -0400 From: "Raymond Wagner" To: Date: Mon, 16 Oct 2006 02:12:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Thread-Index: Acbw6hoJ/qxyYPHgRDuQpjPcDgQxRA== Message-Id: <20061016061255.CNQK10743.gx6.fuse.net@raymond2> Subject: Virtual Network Interfaces 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: Mon, 16 Oct 2006 06:13:01 -0000 My ISP provides me up to 5 dynamically assigned addresses out of a /20 block. I have more than 5 machines on my network, so I have no choice but to run NAT, however I would like to force two of those machines onto their own external addresses. If I had static addresses, I could simply alias the addresses into the external interface and then use "binat" in pf to redirect the traffic. However, the addresses have to be requested from the DHCP server, and expire after 4 hours. I can get this to work by running the NAT function under QEMU and just giving the virtual machine several interfaces bridged to the physical external interface. Running a VM is far from ideal. Is there any way I could set up a virtual network interface that could be bridged to the true interface and grab its own DHCP address? Thanks, Raymond Wagner From owner-freebsd-net@FreeBSD.ORG Mon Oct 16 09:39:16 2006 Return-Path: X-Original-To: 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 9377E16A403 for ; Mon, 16 Oct 2006 09:39:16 +0000 (UTC) (envelope-from spadge@fromley.net) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id A28FD43D4C for ; Mon, 16 Oct 2006 09:39:14 +0000 (GMT) (envelope-from spadge@fromley.net) Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20061016093913.TDDW1865.mtaout03-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com> for ; Mon, 16 Oct 2006 10:39:13 +0100 Received: from tobermory.home ([86.0.166.176]) by aamtaout02-winn.ispmail.ntl.com with ESMTP id <20061016093913.HZMF23938.aamtaout02-winn.ispmail.ntl.com@tobermory.home> for ; Mon, 16 Oct 2006 10:39:13 +0100 Received: from webmail.fromley.net (localhost.home [127.0.0.1]) by tobermory.home (Postfix) with ESMTP id 7854DA713D for ; Mon, 16 Oct 2006 10:39:10 +0100 (BST) Received: from 213.123.179.188 (SquirrelMail authenticated user spadge) by webmail.fromley.net with HTTP; Mon, 16 Oct 2006 10:39:10 +0100 (BST) Message-ID: <34229.213.123.179.188.1160991550.squirrel@webmail.fromley.net> In-Reply-To: <5945271.1160959694724.JavaMail.root@web08sl> References: <5945271.1160959694724.JavaMail.root@web08sl> Date: Mon, 16 Oct 2006 10:39:10 +0100 (BST) From: "Spadge Fromley" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Static route & NAT 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: Mon, 16 Oct 2006 09:39:16 -0000 > Hi, > > I am wondering how to implement a freebsd router without NAT enbaled? > There are 3 subnets connected to this freebsd router. all of them need to > access the Internet. > I have to admit to not being entirely sure what it is you're asking. Does ipfw not just handle it? I suspect the easiest way may be to have one NIC per subnet in the fbsd router, and use natd. -- Spadge 'Intoccabile' From owner-freebsd-net@FreeBSD.ORG Mon Oct 16 10:15:17 2006 Return-Path: X-Original-To: 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 1DB6316A407; Mon, 16 Oct 2006 10:15:17 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60F7643D49; Mon, 16 Oct 2006 10:15:15 +0000 (GMT) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from [192.168.2.10] ([192.168.2.10]) by mail1.cil.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Oct 2006 12:15:13 +0200 Message-ID: <45335BB1.6050809@ide.resurscentrum.se> Date: Mon, 16 Oct 2006 12:15:13 +0200 From: Jon Otterholm User-Agent: Thunderbird 1.5 (X11/20060204) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2006 10:15:13.0616 (UTC) FILETIME=[F81C0D00:01C6F10B] Subject: If_bridge behaving as HUB 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: Mon, 16 Oct 2006 10:15:17 -0000 Hi. I have a bridge setup with a number of vlan IF's as members. After a while traffic destined for one member IF are sent to all member IF's. From man if_bridge: A bridge works like a hub, forwarding traffic from one interface to another. Multicast and broadcast packets are always forwarded to all interfaces that are part of the bridge. For unicast traffic, the bridge learns which MAC addresses are associated with which interfaces and will forward the traffic selectively. Has anyone else got this problem? How do I debug this? Info: su-2.05b# uname -a FreeBSD hostname.domain.com 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #2: Fri Sep 15 13:26:01 CEST 2006 user@:/usr/obj/usr/src/sys/GENERIC i386 /Jon From owner-freebsd-net@FreeBSD.ORG Mon Oct 16 11:08:29 2006 Return-Path: X-Original-To: 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 D6DCE16A5C0 for ; Mon, 16 Oct 2006 11:08:29 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08DB143D60 for ; Mon, 16 Oct 2006 11:08:29 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k9GB8S3V028225 for ; Mon, 16 Oct 2006 11:08:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k9GB8Rrt028221 for freebsd-net@FreeBSD.org; Mon, 16 Oct 2006 11:08:27 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Oct 2006 11:08:27 GMT Message-Id: <200610161108.k9GB8Rrt028221@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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: Mon, 16 Oct 2006 11:08:29 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/52585 net [netinet] [patch] Kernel panic with ipfw2 and syncooki o kern/92552 net A serious bug in most network drivers from 5.X to 6.X f kern/93220 net [inet6] nd6_lookup: failed to add route for a neighbor s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n 9 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 16 11:25:48 2006 Return-Path: X-Original-To: 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 4419E16A415 for ; Mon, 16 Oct 2006 11:25:48 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BB3F43D5D for ; Mon, 16 Oct 2006 11:25:22 +0000 (GMT) (envelope-from shteryana@gmail.com) Received: by nz-out-0102.google.com with SMTP id o37so347250nzf for ; Mon, 16 Oct 2006 04:25:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=rkxxcCP6rLo9MEONhFFmhvcRnQYdTNcVMuaW9UljMA2sCOZ1h1t7/L+oRqkjFu1qb8bokaoO9mBev2HIrAZVEF4/t7YUH2ziU/hqBAGVvN9F0UH6zNMexsYDGCVUYX4uKGpE4VlAGRmsnmjOrNAN7nQOXwOt3Dzt4aNA50w/Zt8= Received: by 10.65.234.3 with SMTP id l3mr9832055qbr; Mon, 16 Oct 2006 04:25:19 -0700 (PDT) Received: by 10.65.121.10 with HTTP; Mon, 16 Oct 2006 04:25:19 -0700 (PDT) Message-ID: <61b573980610160425x556f83a3obff10ae0e6e75991@mail.gmail.com> Date: Mon, 16 Oct 2006 14:25:19 +0300 From: "Shteryana Shopova" Sender: shteryana@gmail.com To: "Jon Otterholm" In-Reply-To: <61b573980610160412j7db5e2feief7998cc1ccc074a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45335BB1.6050809@ide.resurscentrum.se> <61b573980610160412j7db5e2feief7998cc1ccc074a@mail.gmail.com> X-Google-Sender-Auth: 65ae80c8939df46b Cc: freebsd-net@freebsd.org Subject: Re: If_bridge behaving as HUB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: syrinx@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2006 11:25:48 -0000 On 10/16/06, Shteryana Shopova wrote: > On 10/16/06, Jon Otterholm wrote: > > Hi. > > > > I have a bridge setup with a number of vlan IF's as members. After a > > while traffic destined for one member IF are sent to all member IF's. > > > > From man if_bridge: > > > > A bridge works like a hub, forwarding traffic from one interface to > > another. Multicast and broadcast packets are always forwarded to all > > interfaces that are part of the bridge. For unicast traffic, the > > bridge > > learns which MAC addresses are associated with which interfaces and > > will > > forward the traffic selectively. > > > > Has anyone else got this problem? How do I debug this? > > > > #ifconfig bridge0 addr > will show the addresses learnt on the bridge - the destination MACs of > the packets you're sending should be present in the address table, > learnt on the interface you want the packets switched to. Are you > running STP on the bridge? Could it be that the bridge address table > was not properly flushed on a link up/down? > Could be aslo you're exceeding the max number of entries in bridge table (100 by default) - (you can change that with #ifconfig bridge0 maxaddr N) Shteryana From owner-freebsd-net@FreeBSD.ORG Mon Oct 16 16:36:14 2006 Return-Path: X-Original-To: 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 7367016A407 for ; Mon, 16 Oct 2006 16:36:14 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt7.ihug.co.nz (grunt7.ihug.co.nz [203.109.254.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A00543D5A for ; Mon, 16 Oct 2006 16:36:14 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt7.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1GZVRi-0000qs-00; Tue, 17 Oct 2006 05:36:10 +1300 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 4DC651CC23; Tue, 17 Oct 2006 05:36:10 +1300 (NZDT) Date: Tue, 17 Oct 2006 05:36:10 +1300 From: Andrew Thompson To: Jon Otterholm Message-ID: <20061016163610.GA93501@heff.fud.org.nz> References: <45335BB1.6050809@ide.resurscentrum.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45335BB1.6050809@ide.resurscentrum.se> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: If_bridge behaving as HUB 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: Mon, 16 Oct 2006 16:36:14 -0000 On Mon, Oct 16, 2006 at 12:15:13PM +0200, Jon Otterholm wrote: > Hi. > > I have a bridge setup with a number of vlan IF's as members. After a > while traffic destined for one member IF are sent to all member IF's. > > From man if_bridge: > > A bridge works like a hub, forwarding traffic from one interface to > another. Multicast and broadcast packets are always forwarded to all > interfaces that are part of the bridge. For unicast traffic, the > bridge > learns which MAC addresses are associated with which interfaces and > will > forward the traffic selectively. > > Has anyone else got this problem? How do I debug this? > You should run 'ifconfig bridge0 addr' to print out the forwarding table, check if the mac address is listed on the correct port. cheers, Andrew From owner-freebsd-net@FreeBSD.ORG Mon Oct 16 22:19:59 2006 Return-Path: X-Original-To: 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 7F50D16A47C for ; Mon, 16 Oct 2006 22:19:59 +0000 (UTC) (envelope-from dan.krejsa@windriver.com) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B90C43D78 for ; Mon, 16 Oct 2006 22:19:56 +0000 (GMT) (envelope-from dan.krejsa@windriver.com) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id k9GMJuJM016885 for ; Mon, 16 Oct 2006 15:19:56 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Oct 2006 15:19:55 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPP IPv6 prefix length and stateless autoconfiguration? Thread-Index: AcbxcTVelj3tiji6QFeG+wubd+b7VQ== From: "Krejsa, Dan" To: Subject: PPP IPv6 prefix length and stateless autoconfiguration? 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: Mon, 16 Oct 2006 22:19:59 -0000 Hi, Some code in the in6_update_ifa() function in netinet6/in6.c enforces that if an IPv6 destination address is specified for an interface address, the interface must be point-to-point or loopback (fine), and the corresponding prefix length must be exactly 128 bits. The latter seems (at least naively) to conflict with=20 the definition in http://www.ietf.org/internet-drafts/draft-ietf-ipv6-over-ppp-v2-02.txt that the interface identifier length for PPP interfaces is 64 bits, and correspondingly prefixes accepted from a router advertisement must also be 64 bits long; see section 5.5.3 in http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2462bis-08.txt There's code in nd6_rtr.c's in6_ifadd() function which requires the prefix length associated with the link local in6_ifaddr (found by in6ifa_ifpforlinklocal()) to agree with the prefix length from the router advertisement prefix info option before adding an autoconfigured address. They won't match if the in6_ifaddr has prefix length 128. This would seem to prevent autoconfiguring global IPv6 addresses on PPP links. Or is there a way this is worked around elsewhere in the code? - Dan From owner-freebsd-net@FreeBSD.ORG Tue Oct 17 02:40:09 2006 Return-Path: X-Original-To: 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 15C5316A403 for ; Tue, 17 Oct 2006 02:40:09 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E43A43D55 for ; Tue, 17 Oct 2006 02:40:08 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from impact.jinmei.org (unknown [2001:200:1b1:1010:b097:da8d:93a2:25d3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C0ADB15218; Tue, 17 Oct 2006 11:40:06 +0900 (JST) Date: Tue, 17 Oct 2006 11:40:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Krejsa, Dan" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: PPP IPv6 prefix length and stateless autoconfiguration? 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: Tue, 17 Oct 2006 02:40:09 -0000 >>>>> On Mon, 16 Oct 2006 15:19:55 -0700, >>>>> "Krejsa, Dan" said: > Some code in the in6_update_ifa() function in netinet6/in6.c > enforces that if an IPv6 destination address is specified for > an interface address, the interface must be point-to-point or > loopback (fine), and the corresponding prefix length must be > exactly 128 bits. > The latter seems (at least naively) to conflict with > the definition in > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-over-ppp-v2-02.txt > that the interface identifier length for PPP interfaces is 64 bits, and > correspondingly prefixes accepted from a router advertisement > must also be 64 bits long; see section 5.5.3 in > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2462bis-08.txt So shouldn't you simply specify the prefix length of 64 without specifying the *destination* address of the p2p link? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Tue Oct 17 06:03:41 2006 Return-Path: X-Original-To: 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 7467A16A47C for ; Tue, 17 Oct 2006 06:03:41 +0000 (UTC) (envelope-from chenxiaochen@emcite.com) Received: from smtp04.east.net (smtp04.east.net [202.108.59.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id A599443D5F for ; Tue, 17 Oct 2006 06:03:37 +0000 (GMT) (envelope-from chenxiaochen@emcite.com) Received: (qmail 5413 invoked from network); 17 Oct 2006 14:03:57 +0800 Received: from unknown (HELO tmc-xiaolang) (Authenticated?user:?chenxiaochen@emcite.com@[219.239.97.5]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 17 Oct 2006 14:03:57 +0800 Date: Tue, 17 Oct 2006 14:03:33 -0700 From: "chenxiaochen" To: "freebsd-net" Message-ID: <200610171403325411545@emcite.com> X-mailer: Foxmail 6, 5, 104, 21 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Subject: How to set value of DupAddrDetectTransmits on FreeBSD? & How to set ethernet card mode? 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: Tue, 17 Oct 2006 06:03:41 -0000 Dear All, 1. Do you know how to set value of DupAddrDetectTransmits on FreeBSD? 2. Somebody told me that: "Well, there is a bug in FreeBSD's kernel which prevents DAD being sent. You have to force ethernet card into any mode rather than auto-select before it is activated, by modifying rc.network" Do you know how to set modify the rc.network? Thank you very much. Best Regards! Chen Xiaochen -------------- company: TMC of MII email: chenxiaochen@emcite.com address: Haidian District zip: 100083 city: beijing country: China phone: 0086-10-62303288-2094 From owner-freebsd-net@FreeBSD.ORG Tue Oct 17 07:04:16 2006 Return-Path: X-Original-To: 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 4058116A415 for ; Tue, 17 Oct 2006 07:04:16 +0000 (UTC) (envelope-from aburke@nullplusone.net) Received: from alpha.nullplusone.net (sub25-168.member.dsl-only.net [63.105.25.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1AAF43D45 for ; Tue, 17 Oct 2006 07:04:15 +0000 (GMT) (envelope-from aburke@nullplusone.net) Received: from leda (leda.int.nullplusone.net [192.168.10.242]) by alpha.nullplusone.net (8.12.9/8.12.9) with ESMTP id k9H74729058791; Tue, 17 Oct 2006 00:04:08 -0700 (PDT) (envelope-from aburke@nullplusone.net) From: "Aaron Burke" To: "Spadge Fromley" , Date: Tue, 17 Oct 2006 00:06:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <34229.213.123.179.188.1160991550.squirrel@webmail.fromley.net> Cc: Subject: RE: Static route & NAT 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: Tue, 17 Oct 2006 07:04:16 -0000 I much of this is from http://www.irbs.net/FreeBSD/FAQ/networking.html . > > I am wondering how to implement a freebsd router without NAT enbaled? > > There are 3 subnets connected to this freebsd router. all of > them need to > > access the Internet. Due to the lack of NAT, I assume that they all use public interfaces. You may want to look into the installation of routed. > I have to admit to not being entirely sure what it is you're asking. I am not either, but I hope to provide some good info. > Does ipfw not just handle it? It can, but doing so requires that special rules be put in place. Every rule that is processed accumulates additional delay. There is an easier way to forward packets from each network. Simply change 'net.inet.ip.forwarding = 0' to 'net.inet.ip.forwarding = 1' via sysctl. You can also enable this in rc.conf via 'gateway_enable="YES"'. > > I suspect the easiest way may be to have one NIC per subnet in the fbsd > router, and use natd. More than one nic is not required, but if you have the slots available, it can save some increadible headaches. It is possible (however extreemly unwise) to run all 3 of them in via a single NIC. SNIP -- Aaron From owner-freebsd-net@FreeBSD.ORG Tue Oct 17 07:06:31 2006 Return-Path: X-Original-To: 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 8ABB316A412 for ; Tue, 17 Oct 2006 07:06:31 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE57243D64 for ; Tue, 17 Oct 2006 07:06:26 +0000 (GMT) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from [192.168.2.10] ([192.168.2.10]) by mail1.cil.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 17 Oct 2006 09:06:26 +0200 Message-ID: <453480F2.40604@ide.resurscentrum.se> Date: Tue, 17 Oct 2006 09:06:26 +0200 From: Jon Otterholm User-Agent: Thunderbird 1.5 (X11/20060204) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <45335BB1.6050809@ide.resurscentrum.se> <20061016163610.GA93501@heff.fud.org.nz> In-Reply-To: <20061016163610.GA93501@heff.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2006 07:06:26.0212 (UTC) FILETIME=[C2DD1E40:01C6F1BA] Subject: Re: If_bridge behaving as HUB 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: Tue, 17 Oct 2006 07:06:31 -0000 Andrew Thompson wrote: > On Mon, Oct 16, 2006 at 12:15:13PM +0200, Jon Otterholm wrote: > >> Hi. >> >> I have a bridge setup with a number of vlan IF's as members. After a >> while traffic destined for one member IF are sent to all member IF's. >> >> From man if_bridge: >> >> A bridge works like a hub, forwarding traffic from one interface to >> another. Multicast and broadcast packets are always forwarded to all >> interfaces that are part of the bridge. For unicast traffic, the >> bridge >> learns which MAC addresses are associated with which interfaces and >> will >> forward the traffic selectively. >> >> Has anyone else got this problem? How do I debug this? >> >> > > You should run 'ifconfig bridge0 addr' to print out the forwarding > table, check if the mac address is listed on the correct port. > > > cheers, > Andrew > They are listed on the correct port but when I read man if_bridge I get confused: From man if_bridge: discover interface Mark an interface as a ``discovering'' interface. When the bridge has no address cache entry (either dynamic or static) for the destination address of a packet, the bridge will forward the packet to all member interfaces marked as ``discovering''. This is the default for all interfaces added to a bridge. Ie if my router doesnt know where to send the traffic all IF's with discover enabled gets the traffic? -discover interface Clear the ``discovering'' attribute on a member interface. For packets without the ``discovering'' attribute, the only packets forwarded on the interface are broadcast or multicast packets and packets for which the destination address is known to be on the interface's segment. If i set this on customer IF's it allmost works. learn interface Mark an interface as a ``learning'' interface. When a packet arrives on such an interface, the source address of the packet is entered into the address cache as being a destination address on the interface's segment. This is the default for all interfaces added to a bridge. -learn interface Clear the ``learning'' attribute on a member interface. As I understand this: I would be able to set "-discover" and "learn" on all member IF's and everything would work. Unicast traffic with non known destination would not travel to wrong IF's and the bridge fdb would be updated with new customer mac's. This is almost the case - but sometimes customers connection fails because the bridge fdb doesn't get updated. It seems that when a customer connects (ie starts his computer) with no active DHCP-lease and the client sends out a DHCPREQUEST (broadcast) it works like a charm until the bridge fdb entry expires. This could be solved by setting timeout to 0 - but then I would get a polluted fdb. For most customers it works all the time but for some it stops working when the fdb entry expires. I would like to know how the "learn"-function works and why it doesn't work with unicast traffic. /Jon From owner-freebsd-net@FreeBSD.ORG Tue Oct 17 09:14:19 2006 Return-Path: X-Original-To: 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 9B25C16A415 for ; Tue, 17 Oct 2006 09:14:19 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt5.ihug.co.nz (grunt5.ihug.co.nz [203.109.254.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AF1B43D68 for ; Tue, 17 Oct 2006 09:14:18 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt5.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1GZl1a-0003aN-00; Tue, 17 Oct 2006 22:14:14 +1300 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 55FCD1CC23; Tue, 17 Oct 2006 22:14:14 +1300 (NZDT) Date: Tue, 17 Oct 2006 22:14:14 +1300 From: Andrew Thompson To: Jon Otterholm Message-ID: <20061017091414.GA98609@heff.fud.org.nz> References: <45335BB1.6050809@ide.resurscentrum.se> <20061016163610.GA93501@heff.fud.org.nz> <453480F2.40604@ide.resurscentrum.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <453480F2.40604@ide.resurscentrum.se> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: If_bridge behaving as HUB 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: Tue, 17 Oct 2006 09:14:19 -0000 On Tue, Oct 17, 2006 at 09:06:26AM +0200, Jon Otterholm wrote: > Andrew Thompson wrote: > >On Mon, Oct 16, 2006 at 12:15:13PM +0200, Jon Otterholm wrote: > > > >>Hi. > >> > >>I have a bridge setup with a number of vlan IF's as members. After a > >>while traffic destined for one member IF are sent to all member IF's. > >You should run 'ifconfig bridge0 addr' to print out the forwarding > >table, check if the mac address is listed on the correct port. > > > They are listed on the correct port but when I read man if_bridge I get > confused: > > From man if_bridge: > > discover interface > Mark an interface as a ``discovering'' interface. When the > bridge has no address cache entry (either dynamic or static) for > the destination address of a packet, the bridge will forward the > packet to all member interfaces marked as ``discovering''. This > is the default for all interfaces added to a bridge. > > Ie if my router doesnt know where to send the traffic all IF's with > discover enabled gets the traffic? Yes, thats correct. > > -discover interface > Clear the ``discovering'' attribute on a member interface. For > packets without the ``discovering'' attribute, the only packets > forwarded on the interface are broadcast or multicast packets > and packets for which the destination address is known to be on > the interface's segment. > > If i set this on customer IF's it allmost works. > > learn interface > Mark an interface as a ``learning'' interface. When a packet > arrives on such an interface, the source address of the packet > is entered into the address cache as being a destination address > on the interface's segment. This is the default for all > interfaces added to a bridge. > > -learn interface > Clear the ``learning'' attribute on a member interface. > > As I understand this: I would be able to set "-discover" and "learn" on > all member IF's and everything would work. Unicast traffic with non > known destination would not travel to wrong IF's and the bridge fdb > would be updated with new customer mac's. This is almost the case - but > sometimes customers connection fails because the bridge fdb doesn't get > updated. > > It seems that when a customer connects (ie starts his computer) with no > active DHCP-lease and the client sends out a DHCPREQUEST (broadcast) it > works like a charm until the bridge fdb entry expires. This could be > solved by setting timeout to 0 - but then I would get a polluted fdb. > For most customers it works all the time but for some it stops working > when the fdb entry expires. Yes, you will either need regular packets to update the fdb, a long timeout or no timeout at all. Its hard to tell but when you say the fdb entry expires, is that during a period of no activity? By default the entries will be pruged after 20 mins if not updated. Rather than no timeout you could always set it to something greater than the DHCP ack time (1/2 lease time IIRC) and then it should always stay active and old entries will slowly be purged. Another option is when a customer as sucessfully identified themselves to you in some way, then have a script take their fdb entry and reinsert it as static. > > I would like to know how the "learn"-function works and why it doesn't > work with unicast traffic. The learn flag just controls the ability to add dynamic entries to the fdb. When its turned off then your bridge will either behave like a hub (with discover enabled) or you will need to maintain a static table (with discover disabled). I hope this helps. If your bridge is not behaving as above, like active entries being incorrectly purged, then send in a PR. regards, Andrew From owner-freebsd-net@FreeBSD.ORG Tue Oct 17 09:39:36 2006 Return-Path: X-Original-To: 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 A7A8B16A415 for ; Tue, 17 Oct 2006 09:39:36 +0000 (UTC) (envelope-from spadge@fromley.net) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC45F43D49 for ; Tue, 17 Oct 2006 09:39:34 +0000 (GMT) (envelope-from spadge@fromley.net) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20061017093933.GYYG27023.mtaout02-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Tue, 17 Oct 2006 10:39:33 +0100 Received: from tobermory.home ([86.0.166.176]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20061017093932.BSWS644.aamtaout01-winn.ispmail.ntl.com@tobermory.home>; Tue, 17 Oct 2006 10:39:32 +0100 Received: from webmail.fromley.net (localhost.home [127.0.0.1]) by tobermory.home (Postfix) with ESMTP id 9583DA6C5D; Tue, 17 Oct 2006 10:39:30 +0100 (BST) Received: from 213.123.179.188 (SquirrelMail authenticated user spadge) by webmail.fromley.net with HTTP; Tue, 17 Oct 2006 10:39:30 +0100 (BST) Message-ID: <33180.213.123.179.188.1161077970.squirrel@webmail.fromley.net> In-Reply-To: References: Date: Tue, 17 Oct 2006 10:39:30 +0100 (BST) From: "Spadge Fromley" To: "Aaron Burke" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-net@freebsd.org, fwun@bigpond.net.au Subject: RE: Static route & NAT 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: Tue, 17 Oct 2006 09:39:36 -0000 > I much of this is from http://www.irbs.net/FreeBSD/FAQ/networking.html . > >> > I am wondering how to implement a freebsd router without NAT enbaled? >> > There are 3 subnets connected to this freebsd router. all of >> them need to >> > access the Internet. > Due to the lack of NAT, I assume that they all use public interfaces. I'm not so brave. > You may want to look into the installation of routed That would have been my 'Plan B' :) > >> I have to admit to not being entirely sure what it is you're asking. > I am not either, but I hope to provide some good info. > >> Does ipfw not just handle it? > It can, but doing so requires that special rules be put in place. Every > rule that is processed accumulates additional delay. Yeah, but if you're just passing packets to and from three subnets, then you can get away with less than a handful of rules to cover it. > > There is an easier way to forward packets from each network. Simply change > 'net.inet.ip.forwarding = 0' to 'net.inet.ip.forwarding = 1' via sysctl. > You can also enable this in rc.conf via 'gateway_enable="YES"'. Totally, but if you have a firewall in place, you're still going to need to allow the traffic to pass through in either direction. > >> >> I suspect the easiest way may be to have one NIC per subnet in the fbsd >> router, and use natd. > More than one nic is not required, but if you have the slots available, it > can save some increadible headaches. It is possible (however extreemly > unwise) to run all 3 of them in via a single NIC. Hence "easiest way" :) I've added the original poster to the CC list. I'm no routing expert, so I'm learning as I type. -- Spadge 'Intoccabile' From owner-freebsd-net@FreeBSD.ORG Tue Oct 17 15:30:21 2006 Return-Path: X-Original-To: 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 1598F16A4A7 for ; Tue, 17 Oct 2006 15:30:21 +0000 (UTC) (envelope-from vcn_design3@hotmail.com) Received: from bay0-omc2-s5.bay0.hotmail.com (bay0-omc2-s5.bay0.hotmail.com [65.54.246.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id E233743DF7 for ; Tue, 17 Oct 2006 15:29:47 +0000 (GMT) (envelope-from vcn_design3@hotmail.com) Received: from hotmail.com ([64.4.22.58]) by bay0-omc2-s5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 08:29:29 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 17 Oct 2006 08:29:26 -0700 Message-ID: Received: from 209.193.77.154 by by23fd.bay23.hotmail.msn.com with HTTP; Tue, 17 Oct 2006 15:29:22 GMT X-Originating-IP: [209.193.77.154] X-Originating-Email: [vcn_design3@hotmail.com] X-Sender: vcn_design3@hotmail.com From: "Sean Kennedy" To: freebsd-net@freebsd.org Date: Tue, 17 Oct 2006 15:29:22 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 17 Oct 2006 15:29:26.0462 (UTC) FILETIME=[07B1CDE0:01C6F201] Subject: Multiple DHCP Pools (ppp) 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: Tue, 17 Oct 2006 15:30:21 -0000 Hello, Is there anyway to somehow specify multiple IP subnet pools in the "set ifaddr" option in ppp.conf? I'm setting up a pppoed server and I need to be able to use more than one subnet once the first gets filled up with users. Thanks. _________________________________________________________________ Get today's hot entertainment gossip http://movies.msn.com/movies/hotgossip?icid=T002MSN03A07001 From owner-freebsd-net@FreeBSD.ORG Tue Oct 17 17:03:09 2006 Return-Path: X-Original-To: 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 DEDD016A5B4 for ; Tue, 17 Oct 2006 17:03:09 +0000 (UTC) (envelope-from dan.krejsa@windriver.com) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8675743D64 for ; Tue, 17 Oct 2006 17:03:09 +0000 (GMT) (envelope-from dan.krejsa@windriver.com) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id k9HH36GI008279; Tue, 17 Oct 2006 10:03:06 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Oct 2006 10:03:05 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPP IPv6 prefix length and stateless autoconfiguration? Thread-Index: AcbxlZcm2oZb4k4hQqCmNlUR3KYbngAde7ZQ From: "Krejsa, Dan" To: "JINMEI Tatuya / ????" Cc: freebsd-net@freebsd.org Subject: RE: PPP IPv6 prefix length and stateless autoconfiguration? 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: Tue, 17 Oct 2006 17:03:10 -0000 Hi Jinmei, Thanks for your reply! I'm actually working on an OS which uses a FreeBSD and Kame-derived stack, very similar in its IPv6 code to the current FreeBSD. The PPP code is of a different derivation, however. It specifies a 128-bit subnet mask and sets a destination address for PPP/IPv6 interfaces, and we consequently saw an issue with IPv6 autoconfiguration. As a workaround, I did exactly what you suggest, changed the code to configure the interface with a 64-bit prefix without a destination address (actually, the code tried but failed to set the destination address, but I didn't notice it at first). This appears to make the autoconfiguration work fine, and I encountered no other connectivity issues in brief testing; but a coworker of mine noticed that ifconfig no longer showed the destination address, and I investigated and found the 128-bit enforcement in in6_update_ifa(). This makes me somewhat nervous; but if configuring a PPP/IPv6 interface without an IPv6 destination address is the intended method of use, I'd be more comfortable with this. Is that the standard way of doing things? Thanks, - Dan -----Original Message----- From: JINMEI Tatuya / ???? [mailto:jinmei@isl.rdc.toshiba.co.jp]=20 Sent: Monday, October 16, 2006 7:40 PM To: Krejsa, Dan Cc: freebsd-net@freebsd.org Subject: Re: PPP IPv6 prefix length and stateless autoconfiguration? >>>>> On Mon, 16 Oct 2006 15:19:55 -0700,=20 >>>>> "Krejsa, Dan" said: > Some code in the in6_update_ifa() function in netinet6/in6.c > enforces that if an IPv6 destination address is specified for > an interface address, the interface must be point-to-point or > loopback (fine), and the corresponding prefix length must be > exactly 128 bits. > The latter seems (at least naively) to conflict with=20 > the definition in > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-over-ppp-v2-02.txt > that the interface identifier length for PPP interfaces is 64 bits, and > correspondingly prefixes accepted from a router advertisement > must also be 64 bits long; see section 5.5.3 in > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2462bis-08.txt So shouldn't you simply specify the prefix length of 64 without specifying the *destination* address of the p2p link? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Tue Oct 17 17:07:41 2006 Return-Path: X-Original-To: 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 AF40416A49E for ; Tue, 17 Oct 2006 17:07:41 +0000 (UTC) (envelope-from tobias@netconsultoria.com.br) Received: from srv1.netconsultoria.com.br (srv1.netconsultoria.com.br [200.230.201.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12FED43DB4 for ; Tue, 17 Oct 2006 17:07:07 +0000 (GMT) (envelope-from tobias@netconsultoria.com.br) Received: from [172.16.16.100] (mailgw.netconsultoria.com.br [200.230.201.249]) (authenticated bits=0) by srv1.netconsultoria.com.br (8.13.8/8.13.3) with ESMTP id k9HH6pc6079227 for ; Tue, 17 Oct 2006 14:06:51 -0300 (BRT) (envelope-from tobias@netconsultoria.com.br) Message-ID: <45350DAB.3020408@netconsultoria.com.br> Date: Tue, 17 Oct 2006 14:06:51 -0300 From: "Tobias P. Santos" User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2039/Tue Oct 17 13:49:28 2006 on srv1.netconsultoria.com.br X-Virus-Status: Clean Subject: rl driver and 4GB RAM 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: Tue, 17 Oct 2006 17:07:41 -0000 Hello! We recently bought a Dell Server with 4GB RAM. Then, we installed FreeBSD 6.1/i386 but it only detects 3.5GB of RAM. So we recompiled the kernel with PAE option and now we have 4GB available. Onboard NIC (em0) works fine both with GENERIC and PAE kernel, but as we need a second 100 Mbit NIC, we plugged a Realtek 8139D board, but it doesn't work with PAE kernel (GENERIC is fine). If you do a tcpdump, you can see packets and arp requests on the network, but we can't ping anything. It seems that we can only "listen" on rl0 but not "speak". Once we reboot the server with GENERIC kernel, the NIC works fine. We also tried 5.4/amd64, but the behaviour is the same as we have with PAE. Any suggestions? Could it be a driver related problem, so if we change to another NIC it may work? Thank you in advance, Tobias. From owner-freebsd-net@FreeBSD.ORG Tue Oct 17 17:18:50 2006 Return-Path: X-Original-To: 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 67BA416A40F for ; Tue, 17 Oct 2006 17:18:50 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F37243D93 for ; Tue, 17 Oct 2006 17:18:39 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpout.mac.com (Xserve/8.12.11/smtpout03/MantshX 4.0) with ESMTP id k9HHKNYA005203; Tue, 17 Oct 2006 10:20:23 -0700 (PDT) Received: from [17.214.13.96] (a17-214-13-96.apple.com [17.214.13.96]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id k9HHIZEC023068; Tue, 17 Oct 2006 10:18:37 -0700 (PDT) In-Reply-To: <45350DAB.3020408@netconsultoria.com.br> References: <45350DAB.3020408@netconsultoria.com.br> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <216C6008-6F46-494B-80EE-36EE8F84E18F@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Tue, 17 Oct 2006 10:18:26 -0700 To: "Tobias P. Santos" X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: freebsd-net@freebsd.org Subject: Re: rl driver and 4GB RAM 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: Tue, 17 Oct 2006 17:18:50 -0000 On Oct 17, 2006, at 10:06 AM, Tobias P. Santos wrote: > We recently bought a Dell Server with 4GB RAM. > Then, we installed FreeBSD 6.1/i386 but it only detects 3.5GB of > RAM. So we recompiled the kernel with PAE option and now we have > 4GB available. It might be reasonable to simply live with getting 3.5GB of RAM out of the system. > Onboard NIC (em0) works fine both with GENERIC and PAE kernel, but > as we need a second 100 Mbit NIC, we plugged a Realtek 8139D board, > but it doesn't work with PAE kernel (GENERIC is fine). I'm not too surprised-- that Realtek chipset is among the worst 10/100 NICs on the market. Bin it. > If you do a tcpdump, you can see packets and arp requests on the > network, but we can't ping anything. It seems that we can only > "listen" on rl0 but not "speak". Once we reboot the server with > GENERIC kernel, the NIC works fine. > We also tried 5.4/amd64, but the behaviour is the same as we have > with PAE. > > Any suggestions? Could it be a driver related problem, so if we > change to another NIC it may work? Oh, yes-- try adding an Intel 10/100 fxp NIC, or maybe a DEC 21x4x "Tulip" dc NIC instead. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 00:51:48 2006 Return-Path: X-Original-To: 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 616AC16A412 for ; Wed, 18 Oct 2006 00:51:48 +0000 (UTC) (envelope-from chenxiaochen@emcite.com) Received: from smtp04.east.net (smtp04.east.net [202.108.59.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2D7B43D45 for ; Wed, 18 Oct 2006 00:51:45 +0000 (GMT) (envelope-from chenxiaochen@emcite.com) Received: (qmail 9932 invoked from network); 18 Oct 2006 08:52:08 +0800 Received: from unknown (HELO tmc-xiaolang) (Authenticated?user:?chenxiaochen@emcite.com@[219.239.97.5]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 18 Oct 2006 08:52:08 +0800 Date: Wed, 18 Oct 2006 08:51:40 -0700 From: "chenxiaochen" To: "freebsd-net@freebsd.org" Message-ID: <200610180851384063926@emcite.com> X-mailer: Foxmail 6, 5, 104, 21 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Cc: liangbing Subject: Where is pim6dd and pim6sd in FreeBSD6.1? 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, 18 Oct 2006 00:51:48 -0000 Dear all: In release note of 5.0R,it is said that pim6dd and pim6sd have been removed due to restrictive licensing conditions. These programs are available in the ports collection as net/pim6dd and net/pim6sd. I can find the ports of pim6dd and pim6sd in FreeBSD 5.4, but none in FreeBSD 6.1. Do you know where is pim6dd and pim6sd in FreeBSD6.1? Best Regards! -------------- Chen Xiaochen From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 01:18:44 2006 Return-Path: X-Original-To: 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 A7FA216A403 for ; Wed, 18 Oct 2006 01:18:44 +0000 (UTC) (envelope-from suz@alaxala.net) Received: from pc1.alaxala.net (pc1.alaxala.net [203.178.142.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37DC043D5D for ; Wed, 18 Oct 2006 01:18:43 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from localhost (localhost [127.0.0.1]) by pc1.alaxala.net (Postfix) with ESMTP id 5FC7BB936; Wed, 18 Oct 2006 10:18:42 +0900 (JST) X-Virus-Scanned: amavisd-new at alaxala.net Received: from pc1.alaxala.net ([127.0.0.1]) by localhost (pc1.alaxala.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJg+4Nks0Izk; Wed, 18 Oct 2006 10:18:37 +0900 (JST) Received: from flora220.uki-uki.net (pc2.alaxala.net [203.178.142.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pc1.alaxala.net (Postfix) with ESMTP id 659E1B82F; Wed, 18 Oct 2006 10:18:36 +0900 (JST) Date: Wed, 18 Oct 2006 10:18:33 +0900 Message-ID: From: SUZUKI Shinsuke To: chenxiaochen@emcite.com X-cite: xcite 1.33 In-Reply-To: <200610180851384063926@emcite.com> References: <200610180851384063926@emcite.com> User-Agent: Wanderlust/2.15.1 (Almost Unreal) Emacs/22.0 Mule/5.0 (SAKAKI) Organization: Networking Technology Development Dept., ALAXALA Networks Corporation MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, liangbing@emcite.com Subject: Re: Where is pim6dd and pim6sd in FreeBSD6.1? 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, 18 Oct 2006 01:18:44 -0000 Hello, >>>>> On Wed, 18 Oct 2006 08:51:40 -0700 >>>>> chenxiaochen@emcite.com("chenxiaochen") said: > In release note of 5.0R,it is said that pim6dd and pim6sd have been > removed due to restrictive licensing conditions. These programs are > available in the ports collection as net/pim6dd and net/pim6sd. > I can find the ports of pim6dd and pim6sd in FreeBSD 5.4, but none > in FreeBSD 6.1. Do you know where is pim6dd and pim6sd in > FreeBSD6.1? they're moved to net/mcast-tools Thanks, ---- SUZUKI, Shinsuke @ KAME Project From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 11:09:12 2006 Return-Path: X-Original-To: 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 AAAED16A407 for ; Wed, 18 Oct 2006 11:09:12 +0000 (UTC) (envelope-from chenxiaochen@emcite.com) Received: from smtp04.east.net (smtp04.east.net [202.108.59.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id C72B843D49 for ; Wed, 18 Oct 2006 11:09:06 +0000 (GMT) (envelope-from chenxiaochen@emcite.com) Received: (qmail 17955 invoked from network); 18 Oct 2006 19:09:29 +0800 Received: from unknown (HELO tmc-xiaolang) (Authenticated?user:?chenxiaochen@emcite.com@[219.239.97.5]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 18 Oct 2006 19:09:29 +0800 Date: Wed, 18 Oct 2006 19:08:57 -0800 From: "chenxiaochen" To: "freebsd-net" Message-ID: <200610181908570311458@emcite.com> X-mailer: Foxmail 6, 5, 104, 21 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Cc: liangbing Subject: Problems under test of IPv6 Ready Logo Program Phase-2 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, 18 Oct 2006 11:09:12 -0000 Dear all, This is my second letter here, I am beginning to love here for there are many kindly friends, such as SUZUKI Shinsuke :) Ok,questions follows... Does someone do research on IPv6 Ready Logo Program? Now I am doing IPv6 conformance test under TAHI platform and I meet some problems. My test setup is below: -+-----------------------+- Link1 | | | | |rl0 | rl1 TN NUT |bge0 | rl0 | | | | -+-----------------------+- Link0 TN:IBM desktop PC,OS is FreeBSD6.1; NUT:IBM desktop PC,OS is FreeBSD6.1 --- rl0,rl1,bge0 stand for the NICs of TN and NUT. My test software is v6eval-3.0.10 and package are Self_Test_1-4-2 and v6eval-remotes-3.0. 1. Section 5: RFC 2463 - ICMPv6 "case 11 Part B: Multicast Destination" --- fail After TN send Echo Request to global multicast address(ff1e::1:2), the following words appear on NUT's screen-----rl1:discard oversize frame (ether type 86dd flags 3 len 1514 > max 1294 ) However, "case 10 Part A: Unicast Destination" passes. 2. Section 2: RFC 2461 - Neighbor Discovery for IPv6 "127 Part C: Sending Unsolicited RA (Min Values)" --- fail After NUT excutes rtadvd, TN says "Could't observe RA". The corresponding rtadvd.conf is ------------------------------------------------- default:\ :maxinterval#4:\ :mininterval#3:\ :chlim#0:\ :rltime#0:\ :rtime#0:\ :retrans#0:\ :vltime#0:\ :pltime#0: ether:\ :mtu#0:tc=default: rl0:\ :tc=ether: -------------------------------------------------- But when I use Ethereal to capture the IP package, I get RA about 6 seconds later after rtadvd is excuted. The captured RA's parameters are: cur hop limit--64 router lifetime--1800 reachable tiem--0 retrans time--0 valid lifetime--0x00278d00 preferred lifetime--0x00093a80 3. Section 3: RFC 2462 - IPv6 Stateless Address Autoconfiguration All cases fail Reason----TN can't observe DAD process. I can't capture DAD packages by Ethereal in the network start process. But I can get DAD packages on IBM T43(NIC is bge0, OS is FreeBSD 6.1) and T30(NIC is fxp0, OS is FreeBSD 5.4) when the network start( host test). Someone ever told me that --- "there is a bug in FreeBSD's kernel which prevents DAD being sent. You have to force ethernet card into any mode rather than auto-select before it is activated, by modifying rc.network" As if rc.network has been change to netstart in FreeBSD 6.1. But I don't know how to modify it. I am eager to get some suggestions about the problems above. Your reply will be my biggest joy:) By the way, these is a bug I found about IPv6 Ready Logo Program Phase-2 auotmatic test. Hope this informaiton below will be useful to you. 1.install v6eval-remotes-3.0 2.# cd /usr/local/v6eval/bin/freebsd-i386/ 3.# ee racontrol.rmt -------------------------------------------------------------------------------------- line 288 "\t:rtime#$rOpt_retrans:" should be changed into "\t:retrans#$rOpt_retrans:" -------------------------------------------------------------------------------------- Well, good luck to evryone, thank you very much! Best Regards! Chen Xiaochen -------------- chenxiaochen@emcite.com 2006-10-18 From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 15:46:16 2006 Return-Path: X-Original-To: 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 A6F3B16A416 for ; Wed, 18 Oct 2006 15:46:16 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from rackman.netvulture.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE46443D5A for ; Wed, 18 Oct 2006 15:45:36 +0000 (GMT) (envelope-from vulture@netvulture.com) Received: from [192.168.2.243] (host73.netvulture.com [208.201.244.73]) (authenticated bits=0) by rackman.netvulture.com (8.13.5/8.13.5) with ESMTP id k9IFgxI3036279; Wed, 18 Oct 2006 08:43:01 -0700 (PDT) Message-ID: <45364B82.9050409@netvulture.com> Date: Wed, 18 Oct 2006 08:42:58 -0700 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@FreeBSD.org, rizzo@icir.org References: <452FC336.6060504@netvulture.com> <20061014014441.D96390@fledge.watson.org> In-Reply-To: <20061014014441.D96390@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-netvulture_com-MailScanner-Information: Please contact the ISP for more information X-netvulture_com-MailScanner: Found to be clean X-netvulture_com-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (timed out) X-netvulture_com-MailScanner-From: vulture@netvulture.com X-Spam-Status: No Cc: Subject: Re: Problems with 6.2-PRE and udp applications - dhcpd and named - ipfw stateful issue? 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, 18 Oct 2006 15:46:16 -0000 OK - It did it again. named locked up - wait chan was select. But I was able to kill the process this time and restart it. However I was still not able to do any query's. I added a quick ipfw add 1 allow ip from any to any and that solved the query problem. I then proceeded to inspect my ipfw rules. All outbound dnsquery's are using the following rule: allow udp from any to any dst-port 53 keep-state. I then tried to utilize some of my other keep-state rules with no luck. It would seem as if the firewall stack simply doesn't want to do stateful after a while. I also tried flushing all the rules and reloading them - that still did not work. I can live for today with out stateful, so if anyone can help me with it today/tpnight troubleshooting that would be great. I don't want to reboot the machine until somebody can help me diagnose the problem - especially since I'm running what is going to be 6.2-RELEASE. Looking back at the mailing list - I see that there was a change to ipfw.c that deals with dynamic rule timeout, perhaps this is to blame? I am willing to give ssh access to debug this problem. -Jon Robert Watson wrote: > > On Fri, 13 Oct 2006, Jonathan Feally wrote: > >> I have a P4 2.8 box running on an intel MB with a em0 acting as a >> firewall. The em0 has multiple tagged vlans on it, no ip assigned to >> main interface. Almost clockwork now, 6-7 days after bootup named or >> dhcpd completly locks up. I can't even kill -9 the apps. I have >> recompiled both apps since upgrading. I have only made two changes to >> this system around the same time. 1. Removed 2nd em nic that had >> only 1 network connected not vlan tagged. 2. Upgraded to 6.2-PRE >> >> Has anyone else had these problems? I am going to try running the >> system with the internet connection not tagged to see if that helps. > > > I've not seen this on any boxes. The usual debugging path here is to: > > (1) Look at the process wait channel in ps axl. > > (2) Compile KDB/DDB into the kernel, and do a kernel stack trace of the > process. > > Once you know what the kernel thread associated with the process is > doing, we can attempt to figure out why it's doing it. > > Robert N M Watson > Computer Laboratory > University of Cambridge > From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 16:33:54 2006 Return-Path: X-Original-To: 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 C238316A412 for ; Wed, 18 Oct 2006 16:33:54 +0000 (UTC) (envelope-from brent.marsh@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3776743D6A for ; Wed, 18 Oct 2006 16:33:53 +0000 (GMT) (envelope-from brent.marsh@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so193060uge for ; Wed, 18 Oct 2006 09:33:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=uKckUQAMt148OxYIUKZIG9ICrP28nuskJ0sS32Hnel4guHWCbQA26qcUDGJRgGmEUZwkfissqoEx5DrGKu6oQG0zdNrkSxIYaO5JxBXbK6hSRSxFVrcBSL5HgYnfYAuBAVlFguClmaDEHidxv2AjggPpO6sAQQtsP2UQOrHiRyA= Received: by 10.82.135.13 with SMTP id i13mr2371434bud; Wed, 18 Oct 2006 09:33:42 -0700 (PDT) Received: by 10.78.122.11 with HTTP; Wed, 18 Oct 2006 09:33:42 -0700 (PDT) Message-ID: <6170c1110610180933g10a600dbu98cd1d7aab60e987@mail.gmail.com> Date: Wed, 18 Oct 2006 12:33:42 -0400 From: "Brent Marsh" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Networking newbie 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, 18 Oct 2006 16:33:54 -0000 Hello, I've been working with FreeBSD machines on and off for several years now. I am looking to set up my first network. First for home, and second for an office environment. I want to make sure I follow 'industry standards' so my network will have everything that any network in corporate America might have, with no corners cut. As a total networking newbie, I'm looking for step-by-step instructions. I know the network topology, but don't know how to make them 'work'. Do I need to 'define' a domain? What is it that makes my network a cohesive unit? If someone could point me to a step-by-step document, that'd be great. The FreeBSD handbook has all of the components (I suspect) but not the actual concepts of getting it all to work. Thanks! -Brent From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 17:24:45 2006 Return-Path: X-Original-To: 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 9BB9116A412 for ; Wed, 18 Oct 2006 17:24:45 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D7F143D46 for ; Wed, 18 Oct 2006 17:24:45 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpout.mac.com (Xserve/8.12.11/smtpout02/MantshX 4.0) with ESMTP id k9IHOjEF014281; Wed, 18 Oct 2006 10:24:45 -0700 (PDT) Received: from [17.214.13.96] (a17-214-13-96.apple.com [17.214.13.96]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id k9IHOhMs009880; Wed, 18 Oct 2006 10:24:44 -0700 (PDT) In-Reply-To: <6170c1110610180933g10a600dbu98cd1d7aab60e987@mail.gmail.com> References: <6170c1110610180933g10a600dbu98cd1d7aab60e987@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88D784E1-C661-4B03-B412-653CE9EF09AB@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Wed, 18 Oct 2006 10:24:42 -0700 To: Brent Marsh X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: freebsd-net@freebsd.org Subject: Re: Networking newbie 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, 18 Oct 2006 17:24:45 -0000 On Oct 18, 2006, at 9:33 AM, Brent Marsh wrote: > I've been working with FreeBSD machines on and off for several > years now. I > am looking to set up my first network. First for home, and second > for an > office environment. I want to make sure I follow 'industry > standards' so my > network will have everything that any network in corporate America > might > have, with no corners cut. Actually, it isn't hard to do significantly better than the average corporate network, even if you do cut corners. > As a total networking newbie, I'm looking for step-by-step > instructions. This is impractical without knowing the details about your network, hardware resources, services and users, etc. Given adequate information, it turns into work that people normally bill one for. :-) > I know the network topology, but don't know how to make them > 'work'. Do I > need to 'define' a domain? What is it that makes my network a > cohesive > unit? For your network to be a cohesive unit, it needs to be managed. This means that it needs a network admin responsible for the network to organize the resources available, implement and maintain the services needed by the users of the network, provide documentation and policies for these users so that they know what services are available (such as email, filesharing, Internet WWW access, printing, etc), and how to set them up or get help doing so. It's possible for a complete novice or newbie to learn how to configure and maintain a network by doing so, but you're not going to learn everything needed in a day (or even in a decade)-- working with a skilled network admin will bring most people up to speed much more rapidly via their example than self-learning. > If someone could point me to a step-by-step document, that'd be > great. The > FreeBSD handbook has all of the components (I suspect) but not the > actual > concepts of getting it all to work. Unless your office is entirely FreeBSD-based, you will need to think about and deal with other operating systems; the FreeBSD handbook is a good reference for setting up many services, but it does not discuss the care and feeding of Windows clients (or Mac clients, or Linux clients, etc). -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 17:46:35 2006 Return-Path: X-Original-To: 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 DEA4716A407 for ; Wed, 18 Oct 2006 17:46:34 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DAA043D77 for ; Wed, 18 Oct 2006 17:46:32 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by nz-out-0102.google.com with SMTP id o37so124834nzf for ; Wed, 18 Oct 2006 10:46:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=bfu8S0HZFDRkm3qjMddmutidtDTFR0R/hWb22GavR1Qq8MH5xLPlpMg+kBpyl6BFd3u5TEo/nzbhtp5klhWlYmd/2HDoLDRlcQ3eLb4jGZnFjXDreVu1KSSGN+66fuBkN9w9UhXL4A3/BfADQhGdzAXkXf9RJpZesXIYI2xOj+k= Received: by 10.35.31.14 with SMTP id i14mr18228462pyj; Wed, 18 Oct 2006 10:46:30 -0700 (PDT) Received: by 10.35.119.1 with HTTP; Wed, 18 Oct 2006 10:46:30 -0700 (PDT) Message-ID: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> Date: Wed, 18 Oct 2006 10:46:30 -0700 From: "Jack Vogel" To: freebsd-net , freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: em network issues 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, 18 Oct 2006 17:46:35 -0000 I think there may be a few different problems going on with the em driver on 6.2 that are being lumped under the general description of network hangs. In order to solve these I need a reproducible failure, either on a system here at Intel, or someone who is willing to be a remote guinea pig :) I need detailed reports, meaning EXACT system data, if its an OEM box, what model, what addons, a pciconf list, description of the network, and anything special that is connected with the problem occurence. OH, and if you have a 'before and after' situation, then please give driver deltas that worked, and which failed. I know that there are systems out there that have management hardware that can interfere on the network, it grabs certain packets as being 'management' and doesnt pass them on to the OS. Specifically packets for port 623 and 664 get 'eaten' by this hardware. There is a fix for this, you tell the portmapper to not use ports below 665, in particular: sysctl net.inet.ip.portrange.lowlast 665 (default is 600) So, if you have IPMI or AMT hardware, you should try this change and see if it fixes hangs. There is also a hardware eeprom issue on systems with an 82573 type NIC on SOME systems. There is a utility to fix that, if you have a problem, and have that NIC email me and I can send that out to you. Lastly, our Linux crew have long believed that there are lurking issues on some AMD based systems, we have problems with these because we dont have easy access to this hardware (as you can imagine :). But we now have evidence that SOMETIMES completion on transmit descriptors is not being written back, and this causes hangs. They (the linux team) have a modified transmit cleanup algorithm that does not use the DONE bit, instead it just using the head and tail pointers. If I can get a case where someone has this kind of hardware and has hangs AND is willing to test then perhaps I can try coding something similar up. Also, remember to let everyone know if something gets fixed :) Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 18:21:06 2006 Return-Path: X-Original-To: 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 A7FC716A40F for ; Wed, 18 Oct 2006 18:21:06 +0000 (UTC) (envelope-from newroswell@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04B4143DEB for ; Wed, 18 Oct 2006 18:16:40 +0000 (GMT) (envelope-from newroswell@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so216927uge for ; Wed, 18 Oct 2006 11:16:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fde6PDsfNOMsxyQSla8UtMQ6eX3wdpsqXZpcnATB6IXYiTTJmv4VhSYkeyxRNrlkiXTy2spjIigLeelLs3Ur3Uu1nMQwQ5XDUF1x33VrpPF4FN/j3NIiCH28cIzYxKPSlLepLo8CwEOazOLloLPmYOHhH+n0/nsb5KTWjnp8P2U= Received: by 10.78.128.11 with SMTP id a11mr10436202hud; Wed, 18 Oct 2006 11:16:22 -0700 (PDT) Received: by 10.78.192.15 with HTTP; Wed, 18 Oct 2006 11:16:22 -0700 (PDT) Message-ID: <375baf50610181116yc967876tb65d8a31e460ab77@mail.gmail.com> Date: Wed, 18 Oct 2006 11:16:22 -0700 From: "Kevin Sanders" To: "Yuri Lukin" , freebsd-net@freebsd.org In-Reply-To: <1160580727.91199@swaggi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1160580727.91199@swaggi.com> Cc: Subject: Re: Intel PRO 3945ABG Wireless 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, 18 Oct 2006 18:21:06 -0000 On 10/11/06, Yuri Lukin wrote: > I dont know the OS internals and don't have any real programming > experience. Perhaps some basic guidance could set people > like myself on the right path? I'm not asking for hand-holding, > just something to start with. Learn to program in C. Read "The Design and Implementation of the FreeBSD Operating System" from front to back (probably more than once). If there are topics you don't understand, research them futher. If you haven't written code, and don't know the OS, you have a long road ahead, and writing a device driver probably isn't going to be your first successful project. So get busy. Kevin From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 22:30:51 2006 Return-Path: X-Original-To: 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 7A73A16A417 for ; Wed, 18 Oct 2006 22:30:51 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C5EC43D80 for ; Wed, 18 Oct 2006 22:30:41 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by hu-out-0506.google.com with SMTP id 34so1746537hui for ; Wed, 18 Oct 2006 15:30:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Lxyr9qSxlhvQzTKkXtQ8OSyrXWChfIxBP1J+zVHvFtImL1HZLQKitBFYLO4M6V0F5OvdPgtyGXzCyzMXmC5OHFEg7hJfPDDKbiua68UCCx/JizN2uTGxzfMcuPj1V2JJAq4pvlufOJBFT68hksQlSeiNOVJQj7cG9yiDopDsv10= Received: by 10.82.126.5 with SMTP id y5mr2634964buc; Wed, 18 Oct 2006 15:23:48 -0700 (PDT) Received: by 10.82.191.20 with HTTP; Wed, 18 Oct 2006 15:23:48 -0700 (PDT) Message-ID: Date: Wed, 18 Oct 2006 15:23:48 -0700 From: "Kip Macy" To: "Jack Vogel" In-Reply-To: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> Cc: freebsd-net , freebsd-stable@freebsd.org Subject: Re: em network issues 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, 18 Oct 2006 22:30:51 -0000 I have a Sun T2000 that I generally run with the em driver from as of July in order to avoid watchdog timeouts. One trivial scenario that reproduces the problem with 100% consistency is running the ghc configure script (a 20kloc shell script) over NFS. As the T2000 doesn't exactly represent "typical" PC hardware it may not be the most desirable test platform. Nonetheless, let me know if you're interested. Thanks for looking into this issue. -Kip On 10/18/06, Jack Vogel wrote: > I think there may be a few different problems going on with the em driver > on 6.2 that are being lumped under the general description of network > hangs. In order to solve these I need a reproducible failure, either on a > system here at Intel, or someone who is willing to be a remote guinea > pig :) > > I need detailed reports, meaning EXACT system data, if its an OEM > box, what model, what addons, a pciconf list, description of the > network, and anything special that is connected with the problem > occurence. OH, and if you have a 'before and after' situation, then > please give driver deltas that worked, and which failed. > > I know that there are systems out there that have management > hardware that can interfere on the network, it grabs certain packets > as being 'management' and doesnt pass them on to the OS. > Specifically packets for port 623 and 664 get 'eaten' by this > hardware. There is a fix for this, you tell the portmapper to > not use ports below 665, in particular: > > sysctl net.inet.ip.portrange.lowlast 665 (default is 600) > > So, if you have IPMI or AMT hardware, you should try this > change and see if it fixes hangs. > > There is also a hardware eeprom issue on systems with an 82573 > type NIC on SOME systems. There is a utility to fix that, if you > have a problem, and have that NIC email me and I can send that > out to you. > > Lastly, our Linux crew have long believed that there are lurking > issues on some AMD based systems, we have problems with > these because we dont have easy access to this hardware (as > you can imagine :). But we now have evidence that SOMETIMES > completion on transmit descriptors is not being written back, and > this causes hangs. They (the linux team) have a modified transmit > cleanup algorithm that does not use the DONE bit, instead it just > using the head and tail pointers. If I can get a case where someone > has this kind of hardware and has hangs AND is willing to test > then perhaps I can try coding something similar up. > > Also, remember to let everyone know if something gets fixed :) > > Cheers, > > Jack > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 22:31:55 2006 Return-Path: X-Original-To: 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 0698516A417 for ; Wed, 18 Oct 2006 22:31:55 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CD5143D4C for ; Wed, 18 Oct 2006 22:31:54 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so551573pye for ; Wed, 18 Oct 2006 15:31:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XQ4X9IYGmQcqmoPcrXIE4bmiAfrLmqp7a4nMpUwNoeF9vLbVqTI8Jw09nPxykvzWpLoO4cloZWjqKdKC3B1lxnVR8HOJWIxEjU9wZ/Ma728d0uX+5hYAe2fkYFw4bjM6MlH84EEElg713gT0baXq9CZm8IjFGszy4spB8n+PqU0= Received: by 10.35.88.18 with SMTP id q18mr18748007pyl; Wed, 18 Oct 2006 15:31:53 -0700 (PDT) Received: by 10.35.119.1 with HTTP; Wed, 18 Oct 2006 15:31:53 -0700 (PDT) Message-ID: <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> Date: Wed, 18 Oct 2006 15:31:53 -0700 From: "Jack Vogel" To: "Kip Macy" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> Cc: freebsd-net , freebsd-stable@freebsd.org Subject: Re: em network issues 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, 18 Oct 2006 22:31:55 -0000 On 10/18/06, Kip Macy wrote: > I have a Sun T2000 that I generally run with the em driver from as of > July in order to avoid watchdog timeouts. One trivial scenario that > reproduces the problem with 100% consistency is running the ghc > configure script (a 20kloc shell script) over NFS. As the T2000 > doesn't exactly represent "typical" PC hardware it may not be the most > desirable test platform. Nonetheless, let me know if you're > interested. > Thanks for looking into this issue. > > -Kip I'm a bit confused from the way you worded this, do you have watchdogs with em, or you use em to avoid them? If you have problems when running NFS then thats a clue, is it TCP or UDP based NFS? I am interested, give me details about the setup please. I have one of the engineers in our test organization trying to repro symptoms on a system installed with BETA2, it has shared interrupts between em and usb. Any additional stuff he could run would be helpful. Thanks, Jack From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 22:42:48 2006 Return-Path: X-Original-To: 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 CF03916A417; Wed, 18 Oct 2006 22:42:48 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF7AF43D7F; Wed, 18 Oct 2006 22:42:34 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 296D11A3C19; Wed, 18 Oct 2006 15:42:34 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8C4ED51872; Wed, 18 Oct 2006 18:42:33 -0400 (EDT) Date: Wed, 18 Oct 2006 18:42:33 -0400 From: Kris Kennaway To: Jack Vogel Message-ID: <20061018224233.GA1632@xor.obsecurity.org> References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> User-Agent: Mutt/1.4.2.2i Cc: Kip Macy , freebsd-stable@freebsd.org, freebsd-net Subject: Re: em network issues 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, 18 Oct 2006 22:42:48 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 18, 2006 at 03:31:53PM -0700, Jack Vogel wrote: > On 10/18/06, Kip Macy wrote: > >I have a Sun T2000 that I generally run with the em driver from as of > >July in order to avoid watchdog timeouts. One trivial scenario that > >reproduces the problem with 100% consistency is running the ghc > >configure script (a 20kloc shell script) over NFS. As the T2000 > >doesn't exactly represent "typical" PC hardware it may not be the most > >desirable test platform. Nonetheless, let me know if you're > >interested. > >Thanks for looking into this issue. > > > > -Kip >=20 > I'm a bit confused from the way you worded this, do you have watchdogs > with em, or you use em to avoid them? >=20 > If you have problems when running NFS then thats a clue, is it TCP or > UDP based NFS? I am interested, give me details about the setup please. >=20 > I have one of the engineers in our test organization trying to repro=20 > symptoms > on a system installed with BETA2, it has shared interrupts between em and > usb. Any additional stuff he could run would be helpful. I have been working with someone's system that has em shared with fxp, and a simple fetch over the em (e.g. of a 10 GB file of zeroes) is enough to produce watchdog timeouts after a few seconds. As previously mentioned, changing the INTR_FAST to INTR_MPSAFE in the driver avoids this problem. However, others are seeing sporadic watchdog timeouts at higher system load on non-shared em systems too. This is in addition to the hardware instances you already know about where the em driver has not worked going back to 5.x. Kris --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFNq3ZWry0BWjoQKURAiPQAKCpkojPf1a5JdBEsMrEpK65UQ/02ACeO4DN +5ON1GttnrVHCaXPWE2fGkY= =puGc -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 22:53:34 2006 Return-Path: X-Original-To: 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 27E1D16A403 for ; Wed, 18 Oct 2006 22:53:34 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9373643D6B for ; Wed, 18 Oct 2006 22:53:33 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from wlan-a-206-118.corp.yahoo.com.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k9IMqmI4026900; Wed, 18 Oct 2006 15:52:49 -0700 (PDT) Date: Wed, 18 Oct 2006 15:52:48 -0700 Message-ID: From: gnn@freebsd.org To: "chenxiaochen" In-Reply-To: <200610181908570311458@emcite.com> References: <200610181908570311458@emcite.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.7.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net , liangbing Subject: Re: Problems under test of IPv6 Ready Logo Program Phase-2 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, 18 Oct 2006 22:53:34 -0000 At Wed, 18 Oct 2006 19:08:57 -0800, chenxiaochen wrote: > > Dear all, This is my second letter here, I am beginning to love here > for there are many kindly friends, such as SUZUKI > Shinsuke :) Ok,questions follows... Does someone > do research on IPv6 Ready Logo Program? Now I am doing IPv6 > conformance test under TAHI platform and I meet some problems. Though some of us are using TAHI I do not believe the project itself is going for the Logo Program. I am working on IPv6 and IPSec and using TAHI regularly. > My test setup is below: > -+-----------------------+- Link1 > | | > | | > |rl0 | rl1 > TN NUT > |bge0 | rl0 > | | > | | > -+-----------------------+- Link0 > TN:IBM desktop PC,OS is FreeBSD6.1; > NUT:IBM desktop PC,OS is FreeBSD6.1 > --- rl0,rl1,bge0 stand for the NICs of TN and NUT. > My test software is v6eval-3.0.10 and package are Self_Test_1-4-2 and v6eval-remotes-3.0. > > 1. Section 5: RFC 2463 - ICMPv6 > "case 11 Part B: Multicast Destination" --- fail > After TN send Echo Request to global multicast address(ff1e::1:2), the following words appear on NUT's screen-----rl1:discard oversize frame (ether type 86dd flags 3 len 1514 > max 1294 ) > However, "case 10 Part A: Unicast Destination" passes. > > 2. Section 2: RFC 2461 - Neighbor Discovery for IPv6 > "127 Part C: Sending Unsolicited RA (Min Values)" --- fail > After NUT excutes rtadvd, TN says "Could't observe RA". > The corresponding rtadvd.conf is I don't believe that you need to run your own RA. TAHI is usually self contained. > But when I use Ethereal to capture the IP package, I get RA about 6 seconds later after rtadvd is excuted. > The captured RA's parameters are: > cur hop limit--64 > router lifetime--1800 > reachable tiem--0 > retrans time--0 > valid lifetime--0x00278d00 > preferred lifetime--0x00093a80 > You shoudl check if this "just works" without the RA. > 3. Section 3: RFC 2462 - IPv6 Stateless Address Autoconfiguration > All cases fail > Reason----TN can't observe DAD process. > I can't capture DAD packages by Ethereal in the network start process. > > But I can get DAD packages on IBM T43(NIC is bge0, OS is FreeBSD > 6.1) and T30(NIC is fxp0, OS is FreeBSD 5.4) when the network > start( host test). Someone ever told me that --- "there is a bug > in FreeBSD's kernel which prevents DAD being sent. You have to > force ethernet card into any mode rather than auto-select before > it is activated, by modifying rc.network" As if rc.network has > been change to netstart in FreeBSD 6.1. But I don't know how to > modify it. I have not heard of this and don't have that hardware so can't check it. > By the way, these is a bug I found about IPv6 Ready Logo Program > Phase-2 auotmatic test. Hope this informaiton below will be useful > to you. > > 1.install v6eval-remotes-3.0 > 2.# cd /usr/local/v6eval/bin/freebsd-i386/ > 3.# ee racontrol.rmt > -------------------------------------------------------------------------------------- > line 288 > "\t:rtime#$rOpt_retrans:" should be changed into "\t:retrans#$rOpt_retrans:" > -------------------------------------------------------------------------------------- > Best, George From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 23:03:50 2006 Return-Path: X-Original-To: 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 8B2B016A412; Wed, 18 Oct 2006 23:03:50 +0000 (UTC) (envelope-from jas@math.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id A692743D4C; Wed, 18 Oct 2006 23:03:49 +0000 (GMT) (envelope-from jas@math.jussieu.fr) Received: from riemann.math.jussieu.fr (riemann.math.jussieu.fr [134.157.13.3]) by shiva.jussieu.fr (8.13.7/jtpda-5.4) with ESMTP id k9IN3lGR052650 ; Thu, 19 Oct 2006 01:03:47 +0200 (CEST) X-Ids: 168 Received: from cantor.math.jussieu.fr (cantor.math.jussieu.fr [134.157.13.2]) by riemann.math.jussieu.fr (8.13.8/jtpda-5.4) with ESMTP id k9IN3j9F051948 ; Thu, 19 Oct 2006 01:03:45 +0200 (CEST) Received: from cantor.math.jussieu.fr (jas@localhost [127.0.0.1]) by cantor.math.jussieu.fr (8.13.1/jtpda-5.4) with ESMTP id k9IN3jLZ045438 ; Thu, 19 Oct 2006 01:03:45 +0200 (CEST) Received: (from jas@localhost) by cantor.math.jussieu.fr (8.13.1/8.13.1/Submit) id k9IN3ego045437; Thu, 19 Oct 2006 01:03:40 +0200 (CEST) (envelope-from jas) Date: Thu, 19 Oct 2006 01:03:40 +0200 From: Albert Shih To: Jack Vogel Message-ID: <20061018230340.GA28465@math.jussieu.fr> References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> User-Agent: Mutt/1.5.11 X-Spam-Score: 0.001 () UNPARSEABLE_RELAY X-Scanned-By: MIMEDefang 2.57 on 134.157.13.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (shiva.jussieu.fr [134.157.0.168]); Thu, 19 Oct 2006 01:03:47 +0200 (CEST) X-Virus-Scanned: ClamAV 0.88.2/2041/Wed Oct 18 08:29:52 2006 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 4536B2D3.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Cc: freebsd-net , freebsd-stable@freebsd.org Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shih@math.jussieu.fr List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2006 23:03:50 -0000 Le 18/10/2006 10:46:30-0700, Jack Vogel a écrit > I think there may be a few different problems going on with the em driver > on 6.2 that are being lumped under the general description of network > hangs. In order to solve these I need a reproducible failure, either on a > system here at Intel, or someone who is willing to be a remote guinea > pig :) > > I need detailed reports, meaning EXACT system data, if its an OEM > box, what model, what addons, a pciconf list, description of the > network, and anything special that is connected with the problem > occurence. OH, and if you have a 'before and after' situation, then > please give driver deltas that worked, and which failed. Well.... BOX : HP Proliant ML350 G4 All addons is HP Here the network config em0: flags=8843 mtu 1500 options=b media: Ethernet autoselect (1000baseTX ) status: active em1: flags=8843 mtu 1500 options=b media: Ethernet autoselect (1000baseTX ) status: active fxp0: flags=8843 mtu 1500 options=8 media: Ethernet autoselect (100baseTX ) status: active fxp1: flags=8843 mtu 1500 options=8 media: Ethernet autoselect (100baseTX ) status: active bge0: flags=8843 mtu 1500 options=1b media: Ethernet autoselect (100baseTX ) status: active The pciconf -l [root@nfs3 ~]# pciconf -l hostb0@pci0:0:0: class=0x060000 card=0x32000e11 chip=0x35908086 rev=0x0c hdr=0x00 pcib1@pci0:2:0: class=0x060400 card=0x00000050 chip=0x35958086 rev=0x0c hdr=0x01 pcib4@pci0:4:0: class=0x060400 card=0x00000050 chip=0x35978086 rev=0x0c hdr=0x01 pcib5@pci0:6:0: class=0x060400 card=0x00000050 chip=0x35998086 rev=0x0c hdr=0x01 pcib6@pci0:28:0: class=0x060400 card=0x00000050 chip=0x25ae8086 rev=0x02 hdr=0x01 none0@pci0:29:0: class=0x0c0300 card=0x32010e11 chip=0x25a98086 rev=0x02 hdr=0x00 none1@pci0:29:1: class=0x0c0300 card=0x32010e11 chip=0x25aa8086 rev=0x02 hdr=0x00 none2@pci0:29:4: class=0x088000 card=0x32010e11 chip=0x25ab8086 rev=0x02 hdr=0x00 none3@pci0:29:5: class=0x080020 card=0x32010e11 chip=0x25ac8086 rev=0x02 hdr=0x00 none4@pci0:29:7: class=0x0c0320 card=0x32010e11 chip=0x25ad8086 rev=0x02 hdr=0x00 pcib8@pci0:30:0: class=0x060400 card=0x00000000 chip=0x244e8086 rev=0x0a hdr=0x01 isab0@pci0:31:0: class=0x060100 card=0x00000000 chip=0x25a18086 rev=0x02 hdr=0x00 atapci0@pci0:31:1: class=0x01018a card=0x32010e11 chip=0x25a28086 rev=0x02 hdr=0x00 pcib2@pci5:0:0: class=0x060400 card=0x00000044 chip=0x03298086 rev=0x09 hdr=0x01 pcib3@pci5:0:2: class=0x060400 card=0x00000044 chip=0x032a8086 rev=0x09 hdr=0x01 isp0@pci6:1:0: class=0x0c0400 card=0x01000e11 chip=0x23121077 rev=0x02 hdr=0x00 em0@pci9:1:0: class=0x020000 card=0x00db0e11 chip=0x10108086 rev=0x01 hdr=0x00 em1@pci9:1:1: class=0x020000 card=0x00db0e11 chip=0x10108086 rev=0x01 hdr=0x00 ciss0@pci9:2:0: class=0x010400 card=0x409a0e11 chip=0x00460e11 rev=0x01 hdr=0x00 pcib7@pci2:2:0: class=0x060400 card=0x000000dc chip=0xb1548086 rev=0x00 hdr=0x01 mpt0@pci2:3:0: class=0x010000 card=0x00da0e11 chip=0x00301000 rev=0x08 hdr=0x00 mpt1@pci2:3:1: class=0x010000 card=0x00da0e11 chip=0x00301000 rev=0x08 hdr=0x00 fxp0@pci3:4:0: class=0x020000 card=0xb1630e11 chip=0x12298086 rev=0x08 hdr=0x00 fxp1@pci3:5:0: class=0x020000 card=0xb1630e11 chip=0x12298086 rev=0x08 hdr=0x00 bge0@pci1:2:0: class=0x020000 card=0x00e30e11 chip=0x165414e4 rev=0x03 hdr=0x00 none5@pci1:3:0: class=0x030000 card=0x001e0e11 chip=0x47521002 rev=0x27 hdr=0x00 none6@pci1:4:0: class=0x088000 card=0x00d70e11 chip=0x00d70e11 rev=0x01 hdr=0x00 [root@nfs3 ~]# This server has only one purpose : nfsd. There are a MSA1000 (disk array) connected in FC with Qlogic FC card. History of my problem : The server is buy on january 2006 (in replacement of old HP) only the server is news, the MSA1000 is the old one. I've install FreeBSD 6.x on this server. Because I've 0 problem with the old server, I directly put my server in production (I known bad idea...) After some weeks the problem begin with lost em interface (watchdog), sometime it's fxp (but very rarely). When this append nothing can fix (without reboot). I make many cvs, to swapp on 6-Stable, but nothing change. After some weeks the server just hang-on or the network em is on watchdog status. In ~march 2006 someone on this mailing list tel me I can put the interface on polling mode with no SMP. This thing work very fine until september 2006. Without any change on my server (no cvs, no buildkernel, no reboot), no change on the nfs clients (linux/FreebSD) the problem come again. The first crash is the server hang-on. I've make cvsup/buildworld/buildkernel. After some day the server hang-on again. When we are in polling mode I don't have the message «em* watchdog», but the server just hang-on (event on the console). When I make no polling I've got the em* watchdog message. Now I run (from yeasterday) in this mode : no-SMP no-polling the patch http://lists.freebsd.org/pipermail/freebsd-stable/2006-October/029224.html and I build a kernel without USB (because I've got many IRQ on usb). Of course it's to short to tell if the problem is solve. > hardware. There is a fix for this, you tell the portmapper to > not use ports below 665, in particular: > > sysctl net.inet.ip.portrange.lowlast 665 (default is 600) > > So, if you have IPMI or AMT hardware, you should try this > change and see if it fixes hangs. I don't known if I've AMT but I put this on my sysctl.conf. > > There is also a hardware eeprom issue on systems with an 82573 > type NIC on SOME systems. There is a utility to fix that, if you and on HP ? I'm sorry for : 1/ My bad english 2/ The server is on production ... I can make many change or test but if I can help.... Thanks for all_FB_dev Regards. -- Albert SHIH Universite de Paris 7 (Denis DIDEROT) U.F.R. de Mathematiques. 7 ième étage, plateau D, bureau 10 Heure local/Local time: Thu Oct 19 00:43:39 CEST 2006 From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 23:09:03 2006 Return-Path: X-Original-To: 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 4CCC216A412; Wed, 18 Oct 2006 23:09:03 +0000 (UTC) (envelope-from jas@math.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBE1043D7D; Wed, 18 Oct 2006 23:07:16 +0000 (GMT) (envelope-from jas@math.jussieu.fr) Received: from riemann.math.jussieu.fr (riemann.math.jussieu.fr [134.157.13.3]) by shiva.jussieu.fr (8.13.7/jtpda-5.4) with ESMTP id k9IN790F082343 ; Thu, 19 Oct 2006 01:07:09 +0200 (CEST) X-Ids: 164 Received: from cantor.math.jussieu.fr (cantor.math.jussieu.fr [134.157.13.2]) by riemann.math.jussieu.fr (8.13.8/jtpda-5.4) with ESMTP id k9IN77Ij055153 ; Thu, 19 Oct 2006 01:07:08 +0200 (CEST) Received: from cantor.math.jussieu.fr (jas@localhost [127.0.0.1]) by cantor.math.jussieu.fr (8.13.1/jtpda-5.4) with ESMTP id k9IN77QI047563 ; Thu, 19 Oct 2006 01:07:07 +0200 (CEST) Received: (from jas@localhost) by cantor.math.jussieu.fr (8.13.1/8.13.1/Submit) id k9IN77m1047562; Thu, 19 Oct 2006 01:07:07 +0200 (CEST) (envelope-from jas) Date: Thu, 19 Oct 2006 01:07:07 +0200 From: Albert Shih Message-ID: <20061018230707.GB28465@math.jussieu.fr> References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <20061018230340.GA28465@math.jussieu.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20061018230340.GA28465@math.jussieu.fr> User-Agent: Mutt/1.5.11 X-Spam-Score: 0.884 () UNDISC_RECIPS,UNPARSEABLE_RELAY X-Scanned-By: MIMEDefang 2.57 on 134.157.13.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (shiva.jussieu.fr [134.157.0.164]); Thu, 19 Oct 2006 01:07:09 +0200 (CEST) X-Virus-Scanned: ClamAV 0.88.2/2041/Wed Oct 18 08:29:52 2006 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 4536B39D.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shih@math.jussieu.fr List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2006 23:09:03 -0000 Le 19/10/2006 01:03:40+0200, Albert Shih a écrit > Le 18/10/2006 10:46:30-0700, Jack Vogel a écrit > > I think there may be a few different problems going on with the em driver > > on 6.2 that are being lumped under the general description of network > > hangs. In order to solve these I need a reproducible failure, either on a > > system here at Intel, or someone who is willing to be a remote guinea > > pig :) > > > > I need detailed reports, meaning EXACT system data, if its an OEM > > box, what model, what addons, a pciconf list, description of the > > network, and anything special that is connected with the problem > > occurence. OH, and if you have a 'before and after' situation, then > > please give driver deltas that worked, and which failed. > > Well.... > > BOX : HP Proliant ML350 G4 > All addons is HP > > Here the network config > > em0: flags=8843 mtu 1500 > options=b > media: Ethernet autoselect (1000baseTX ) > status: active > em1: flags=8843 mtu 1500 > options=b > media: Ethernet autoselect (1000baseTX ) > status: active > fxp0: flags=8843 mtu 1500 > options=8 > media: Ethernet autoselect (100baseTX ) > status: active > fxp1: flags=8843 mtu 1500 > options=8 > media: Ethernet autoselect (100baseTX ) > status: active > bge0: flags=8843 mtu 1500 > options=1b > media: Ethernet autoselect (100baseTX ) > status: active > > The pciconf -l > > [root@nfs3 ~]# pciconf -l > hostb0@pci0:0:0: class=0x060000 card=0x32000e11 chip=0x35908086 rev=0x0c hdr=0x00 > pcib1@pci0:2:0: class=0x060400 card=0x00000050 chip=0x35958086 rev=0x0c hdr=0x01 > pcib4@pci0:4:0: class=0x060400 card=0x00000050 chip=0x35978086 rev=0x0c hdr=0x01 > pcib5@pci0:6:0: class=0x060400 card=0x00000050 chip=0x35998086 rev=0x0c hdr=0x01 > pcib6@pci0:28:0: class=0x060400 card=0x00000050 chip=0x25ae8086 rev=0x02 hdr=0x01 > none0@pci0:29:0: class=0x0c0300 card=0x32010e11 chip=0x25a98086 rev=0x02 hdr=0x00 > none1@pci0:29:1: class=0x0c0300 card=0x32010e11 chip=0x25aa8086 rev=0x02 hdr=0x00 > none2@pci0:29:4: class=0x088000 card=0x32010e11 chip=0x25ab8086 rev=0x02 hdr=0x00 > none3@pci0:29:5: class=0x080020 card=0x32010e11 chip=0x25ac8086 rev=0x02 hdr=0x00 > none4@pci0:29:7: class=0x0c0320 card=0x32010e11 chip=0x25ad8086 rev=0x02 hdr=0x00 > pcib8@pci0:30:0: class=0x060400 card=0x00000000 chip=0x244e8086 rev=0x0a hdr=0x01 > isab0@pci0:31:0: class=0x060100 card=0x00000000 chip=0x25a18086 rev=0x02 hdr=0x00 > atapci0@pci0:31:1: class=0x01018a card=0x32010e11 chip=0x25a28086 rev=0x02 hdr=0x00 > pcib2@pci5:0:0: class=0x060400 card=0x00000044 chip=0x03298086 rev=0x09 hdr=0x01 > pcib3@pci5:0:2: class=0x060400 card=0x00000044 chip=0x032a8086 rev=0x09 hdr=0x01 > isp0@pci6:1:0: class=0x0c0400 card=0x01000e11 chip=0x23121077 rev=0x02 hdr=0x00 > em0@pci9:1:0: class=0x020000 card=0x00db0e11 chip=0x10108086 rev=0x01 hdr=0x00 > em1@pci9:1:1: class=0x020000 card=0x00db0e11 chip=0x10108086 rev=0x01 hdr=0x00 > ciss0@pci9:2:0: class=0x010400 card=0x409a0e11 chip=0x00460e11 rev=0x01 hdr=0x00 > pcib7@pci2:2:0: class=0x060400 card=0x000000dc chip=0xb1548086 rev=0x00 hdr=0x01 > mpt0@pci2:3:0: class=0x010000 card=0x00da0e11 chip=0x00301000 rev=0x08 hdr=0x00 > mpt1@pci2:3:1: class=0x010000 card=0x00da0e11 chip=0x00301000 rev=0x08 hdr=0x00 > fxp0@pci3:4:0: class=0x020000 card=0xb1630e11 chip=0x12298086 rev=0x08 hdr=0x00 > fxp1@pci3:5:0: class=0x020000 card=0xb1630e11 chip=0x12298086 rev=0x08 hdr=0x00 > bge0@pci1:2:0: class=0x020000 card=0x00e30e11 chip=0x165414e4 rev=0x03 hdr=0x00 > none5@pci1:3:0: class=0x030000 card=0x001e0e11 chip=0x47521002 rev=0x27 hdr=0x00 > none6@pci1:4:0: class=0x088000 card=0x00d70e11 chip=0x00d70e11 rev=0x01 hdr=0x00 > [root@nfs3 ~]# > I forgot : [root@nfs3 ~]# vmstat -i interrupt total rate irq1: atkbd0 717 0 irq4: sio0 92430 2 irq6: fdc0 87 0 irq15: ata1 47 0 irq17: bge0 5812600 139 irq24: mpt0 29 0 irq25: mpt1 17 0 irq26: fxp0 fxp1 2663253 64 irq48: isp0 3898376 93 irq72: ciss0 164341 3 irq76: em0 50269177 1209 irq77: em1 5608732 134 cpu0: timer 83015825 1997 Total 151525631 3646 [root@nfs3 ~]# Regards. -- Albert SHIH Universite de Paris 7 (Denis DIDEROT) U.F.R. de Mathematiques. 7 ième étage, plateau D, bureau 10 Heure local/Local time: Thu Oct 19 01:05:53 CEST 2006 From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 23:52:08 2006 Return-Path: X-Original-To: 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 CA93016A407 for ; Wed, 18 Oct 2006 23:52:08 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D62D43D62 for ; Wed, 18 Oct 2006 23:52:07 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so573964pye for ; Wed, 18 Oct 2006 16:51:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fTXExjbrFWk+Iu3If/mI0Cy4V5eihINQXcp1C+Wf7hqsfOqu2BRT3xQQWkT2F95Ah9d5u4WiWDuydBIUM3M9FxSz3tEI0yHtTjA/U9Pi1Etrx0l91Zaf0Ipurdt35+Iqixmwb9OreOlA3yerdpEB9YsSV3Wk7fLQBG/yK7pgSko= Received: by 10.35.121.9 with SMTP id y9mr18863237pym; Wed, 18 Oct 2006 16:51:32 -0700 (PDT) Received: by 10.35.119.1 with HTTP; Wed, 18 Oct 2006 16:51:32 -0700 (PDT) Message-ID: <2a41acea0610181651k3d7ec1f9iac5f0e452a1cec5b@mail.gmail.com> Date: Wed, 18 Oct 2006 16:51:32 -0700 From: "Jack Vogel" To: shih@math.jussieu.fr In-Reply-To: <20061018230707.GB28465@math.jussieu.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <20061018230340.GA28465@math.jussieu.fr> <20061018230707.GB28465@math.jussieu.fr> Cc: freebsd-net , freebsd-stable@freebsd.org Subject: Re: em network issues 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, 18 Oct 2006 23:52:08 -0000 Awesome, this is the kind of data that will help. I'll see what I can do to get something repro'd. Jack On 10/18/06, Albert Shih wrote: > Le 19/10/2006 01:03:40+0200, Albert Shih a =E9crit > > Le 18/10/2006 10:46:30-0700, Jack Vogel a =E9crit > > > I think there may be a few different problems going on with the em dr= iver > > > on 6.2 that are being lumped under the general description of network > > > hangs. In order to solve these I need a reproducible failure, either = on a > > > system here at Intel, or someone who is willing to be a remote guinea > > > pig :) > > > > > > I need detailed reports, meaning EXACT system data, if its an OEM > > > box, what model, what addons, a pciconf list, description of the > > > network, and anything special that is connected with the problem > > > occurence. OH, and if you have a 'before and after' situation, then > > > please give driver deltas that worked, and which failed. > > > > Well.... > > > > BOX : HP Proliant ML350 G4 > > All addons is HP > > > > Here the network config > > > > em0: flags=3D8843 mtu 1500 > > options=3Db > > media: Ethernet autoselect (1000baseTX ) > > status: active > > em1: flags=3D8843 mtu 1500 > > options=3Db > > media: Ethernet autoselect (1000baseTX ) > > status: active > > fxp0: flags=3D8843 mtu 1500 > > options=3D8 > > media: Ethernet autoselect (100baseTX ) > > status: active > > fxp1: flags=3D8843 mtu 1500 > > options=3D8 > > media: Ethernet autoselect (100baseTX ) > > status: active > > bge0: flags=3D8843 mtu 1500 > > options=3D1b > > media: Ethernet autoselect (100baseTX ) > > status: active > > > > The pciconf -l > > > > [root@nfs3 ~]# pciconf -l > > hostb0@pci0:0:0: class=3D0x060000 card=3D0x32000e11 chip=3D0x359= 08086 rev=3D0x0c hdr=3D0x00 > > pcib1@pci0:2:0: class=3D0x060400 card=3D0x00000050 chip=3D0x35958086 re= v=3D0x0c hdr=3D0x01 > > pcib4@pci0:4:0: class=3D0x060400 card=3D0x00000050 chip=3D0x35978086 re= v=3D0x0c hdr=3D0x01 > > pcib5@pci0:6:0: class=3D0x060400 card=3D0x00000050 chip=3D0x35998086 re= v=3D0x0c hdr=3D0x01 > > pcib6@pci0:28:0: class=3D0x060400 card=3D0x00000050 chip=3D0x25a= e8086 rev=3D0x02 hdr=3D0x01 > > none0@pci0:29:0: class=3D0x0c0300 card=3D0x32010e11 chip=3D0x25a= 98086 rev=3D0x02 hdr=3D0x00 > > none1@pci0:29:1: class=3D0x0c0300 card=3D0x32010e11 chip=3D0x25a= a8086 rev=3D0x02 hdr=3D0x00 > > none2@pci0:29:4: class=3D0x088000 card=3D0x32010e11 chip=3D0x25a= b8086 rev=3D0x02 hdr=3D0x00 > > none3@pci0:29:5: class=3D0x080020 card=3D0x32010e11 chip=3D0x25a= c8086 rev=3D0x02 hdr=3D0x00 > > none4@pci0:29:7: class=3D0x0c0320 card=3D0x32010e11 chip=3D0x25a= d8086 rev=3D0x02 hdr=3D0x00 > > pcib8@pci0:30:0: class=3D0x060400 card=3D0x00000000 chip=3D0x244= e8086 rev=3D0x0a hdr=3D0x01 > > isab0@pci0:31:0: class=3D0x060100 card=3D0x00000000 chip=3D0x25a= 18086 rev=3D0x02 hdr=3D0x00 > > atapci0@pci0:31:1: class=3D0x01018a card=3D0x32010e11 chip=3D0x25a= 28086 rev=3D0x02 hdr=3D0x00 > > pcib2@pci5:0:0: class=3D0x060400 card=3D0x00000044 chip=3D0x03298086 re= v=3D0x09 hdr=3D0x01 > > pcib3@pci5:0:2: class=3D0x060400 card=3D0x00000044 chip=3D0x032a8086 re= v=3D0x09 hdr=3D0x01 > > isp0@pci6:1:0: class=3D0x0c0400 card=3D0x01000e11 chip=3D0x23121077 re= v=3D0x02 hdr=3D0x00 > > em0@pci9:1:0: class=3D0x020000 card=3D0x00db0e11 chip=3D0x10108086 re= v=3D0x01 hdr=3D0x00 > > em1@pci9:1:1: class=3D0x020000 card=3D0x00db0e11 chip=3D0x10108086 re= v=3D0x01 hdr=3D0x00 > > ciss0@pci9:2:0: class=3D0x010400 card=3D0x409a0e11 chip=3D0x00460e11 re= v=3D0x01 hdr=3D0x00 > > pcib7@pci2:2:0: class=3D0x060400 card=3D0x000000dc chip=3D0xb1548086 re= v=3D0x00 hdr=3D0x01 > > mpt0@pci2:3:0: class=3D0x010000 card=3D0x00da0e11 chip=3D0x00301000 re= v=3D0x08 hdr=3D0x00 > > mpt1@pci2:3:1: class=3D0x010000 card=3D0x00da0e11 chip=3D0x00301000 re= v=3D0x08 hdr=3D0x00 > > fxp0@pci3:4:0: class=3D0x020000 card=3D0xb1630e11 chip=3D0x12298086 re= v=3D0x08 hdr=3D0x00 > > fxp1@pci3:5:0: class=3D0x020000 card=3D0xb1630e11 chip=3D0x12298086 re= v=3D0x08 hdr=3D0x00 > > bge0@pci1:2:0: class=3D0x020000 card=3D0x00e30e11 chip=3D0x165414e4 re= v=3D0x03 hdr=3D0x00 > > none5@pci1:3:0: class=3D0x030000 card=3D0x001e0e11 chip=3D0x47521002 re= v=3D0x27 hdr=3D0x00 > > none6@pci1:4:0: class=3D0x088000 card=3D0x00d70e11 chip=3D0x00d70e11 re= v=3D0x01 hdr=3D0x00 > > [root@nfs3 ~]# > > > > I forgot : > > [root@nfs3 ~]# vmstat -i > interrupt total rate > irq1: atkbd0 717 0 > irq4: sio0 92430 2 > irq6: fdc0 87 0 > irq15: ata1 47 0 > irq17: bge0 5812600 139 > irq24: mpt0 29 0 > irq25: mpt1 17 0 > irq26: fxp0 fxp1 2663253 64 > irq48: isp0 3898376 93 > irq72: ciss0 164341 3 > irq76: em0 50269177 1209 > irq77: em1 5608732 134 > cpu0: timer 83015825 1997 > Total 151525631 3646 > [root@nfs3 ~]# > > > Regards. > > > -- > Albert SHIH > Universite de Paris 7 (Denis DIDEROT) > U.F.R. de Mathematiques. > 7 i=E8me =E9tage, plateau D, bureau 10 > Heure local/Local time: > Thu Oct 19 01:05:53 CEST 2006 > From owner-freebsd-net@FreeBSD.ORG Wed Oct 18 23:54:17 2006 Return-Path: X-Original-To: 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 6205216A416 for ; Wed, 18 Oct 2006 23:54:17 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0B1143D62 for ; Wed, 18 Oct 2006 23:54:14 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so574748pye for ; Wed, 18 Oct 2006 16:54:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kfmd1s2XrZYWCcNGSnUGMgMtuvgE55KURoddC49Oc5hoy4Cxttp1xSPlqla7osMNKc9Ugd1kokpMSMB1QI7hLkK3eUi92VsL9XYMzpaR8caODd8xlt1xlmVZYN6y+rPe8msSXVW7t1aUBXJtG8NZ5tDid0qUlbqEdjz0u50MY68= Received: by 10.35.121.2 with SMTP id y2mr18870879pym; Wed, 18 Oct 2006 16:54:13 -0700 (PDT) Received: by 10.35.119.1 with HTTP; Wed, 18 Oct 2006 16:54:13 -0700 (PDT) Message-ID: <2a41acea0610181654h42a5f794q7e06966fe1ae66c9@mail.gmail.com> Date: Wed, 18 Oct 2006 16:54:13 -0700 From: "Jack Vogel" To: shih@math.jussieu.fr In-Reply-To: <20061018230340.GA28465@math.jussieu.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <20061018230340.GA28465@math.jussieu.fr> Cc: freebsd-net , freebsd-stable@freebsd.org Subject: Re: em network issues 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, 18 Oct 2006 23:54:17 -0000 On 10/18/06, Albert Shih wrote: > > > > There is also a hardware eeprom issue on systems with an 82573 > > type NIC on SOME systems. There is a utility to fix that, if you > > and on HP ? your system does not have 573 NICs, (what you show are 546) do you have others that are? Jack From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 00:26:14 2006 Return-Path: X-Original-To: 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 86AC616A407; Thu, 19 Oct 2006 00:26:14 +0000 (UTC) (envelope-from kmacy@fsmware.com) Received: from demos.bsdclusters.com (demos.bsdclusters.com [69.55.225.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 512BF43D73; Thu, 19 Oct 2006 00:26:09 +0000 (GMT) (envelope-from kmacy@fsmware.com) Received: from demos.bsdclusters.com (demos [69.55.225.36]) by demos.bsdclusters.com (8.12.8p1/8.12.8) with ESMTP id k9J0Q9lZ009510; Wed, 18 Oct 2006 17:26:09 -0700 (PDT) (envelope-from kmacy@fsmware.com) Received: from localhost (kmacy@localhost) by demos.bsdclusters.com (8.12.8p1/8.12.8/Submit) with ESMTP id k9J0Q9kU009507; Wed, 18 Oct 2006 17:26:09 -0700 (PDT) X-Authentication-Warning: demos.bsdclusters.com: kmacy owned process doing -bs Date: Wed, 18 Oct 2006 17:26:09 -0700 (PDT) From: Kip Macy X-X-Sender: kmacy@demos.bsdclusters.com To: Jack Vogel In-Reply-To: <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> Message-ID: <20061018171704.A3851@demos.bsdclusters.com> References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net , freebsd-stable@freebsd.org Subject: Re: em network issues 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: Thu, 19 Oct 2006 00:26:14 -0000 On Wed, 18 Oct 2006, Jack Vogel wrote: > On 10/18/06, Kip Macy wrote: > > I have a Sun T2000 that I generally run with the em driver from as of > > July in order to avoid watchdog timeouts. One trivial scenario that > > reproduces the problem with 100% consistency is running the ghc > > configure script (a 20kloc shell script) over NFS. As the T2000 > > doesn't exactly represent "typical" PC hardware it may not be the most > > desirable test platform. Nonetheless, let me know if you're > > interested. > > Thanks for looking into this issue. > > > > -Kip > > I'm a bit confused from the way you worded this, do you have watchdogs > with em, or you use em to avoid them? I have watchdogs with the current (post vendor update) em driver, but not with an older (pre vendor update) version of it. > > If you have problems when running NFS then thats a clue, is it TCP or > UDP based NFS? I am interested, give me details about the setup please. Its UDP: 192.168.1.100:/usr/flatstor/freebsd/7.x/sparc64 / nfs bg,intr,rw 0 0 192.168.1.100:/usr/flatstor/shared /shared nfs bg,intr,rw,nfsv3 0 0 Running ./configure --help in /shared/ghc-6.4.2/ triggers it 100% consistently. > > I have one of the engineers in our test organization trying to repro symptoms > on a system installed with BETA2, it has shared interrupts between em and > usb. Any additional stuff he could run would be helpful. > Let me know what else you need. %ifconfig -a em0: flags=8843 mtu 1500 options=18b inet 192.168.1.5 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:03:ba:d9:20:ae media: Ethernet autoselect (1000baseTX ) status: active em1: flags=8802 mtu 1500 options=18b ether 00:03:ba:d9:20:af media: Ethernet autoselect status: no carrier em2: flags=8802 mtu 1500 options=18b ether 00:03:ba:d9:20:b0 media: Ethernet autoselect status: no carrier em3: flags=8802 mtu 1500 options=18b ether 00:03:ba:d9:20:b1 media: Ethernet autoselect status: no carrier lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 %pciconf -l pcib1@pci2:0:0: class=0x060400 card=0x00000040 chip=0x853210b5 rev=0xaa hdr=0x01 pcib2@pci3:1:0: class=0x060400 card=0x00000040 chip=0x853210b5 rev=0xaa hdr=0x01 pcib3@pci3:2:0: class=0x060400 card=0x00000040 chip=0x853210b5 rev=0xaa hdr=0x01 pcib4@pci3:8:0: class=0x060400 card=0x00000040 chip=0x853210b5 rev=0xaa hdr=0x01 pcib5@pci3:9:0: class=0x060400 card=0x00000040 chip=0x853210b5 rev=0xaa hdr=0x01 em0@pci4:0:0: class=0x020000 card=0x105e108e chip=0x105e8086 rev=0x06 hdr=0x00 em1@pci4:0:1: class=0x020000 card=0x105e108e chip=0x105e8086 rev=0x06 hdr=0x00 pcib7@pci2:0:0: class=0x060400 card=0x00000040 chip=0x853210b5 rev=0xaa hdr=0x01 pcib8@pci3:1:0: class=0x060400 card=0x00000040 chip=0x853210b5 rev=0xaa hdr=0x01 pcib11@pci3:2:0: class=0x060400 card=0x00000040 chip=0x853210b5 rev=0xaa hdr=0x01 pcib12@pci3:8:0: class=0x060400 card=0x00000040 chip=0x853210b5 rev=0xaa hdr=0x01 pcib13@pci3:9:0: class=0x060400 card=0x00000040 chip=0x853210b5 rev=0xaa hdr=0x01 pcib9@pci4:0:0: class=0x060400 card=0x00000044 chip=0x03408086 rev=0x09 hdr=0x01 pcib10@pci4:0:2: class=0x060400 card=0x00000044 chip=0x03418086 rev=0x09 hdr=0x01 none0@pci5:2:0: class=0x060100 card=0x153310b9 chip=0x153310b9 rev=0x00 hdr=0x00 none1@pci5:5:0: class=0x0c0310 card=0x00000000 chip=0x523710b9 rev=0x03 hdr=0x00 none2@pci5:6:0: class=0x0c0310 card=0x00000000 chip=0x523710b9 rev=0x03 hdr=0x00 none3@pci5:8:0: class=0x0101ff card=0x00000000 chip=0x522910b9 rev=0xc4 hdr=0x00 none4@pci6:1:0: class=0x0c0400 card=0x01001077 chip=0x23121077 rev=0x02 hdr=0x00 none5@pci6:2:0: class=0x010000 card=0x30f01000 chip=0x00501000 rev=0x02 hdr=0x00 em2@pci7:0:0: class=0x020000 card=0x105e108e chip=0x105e8086 rev=0x06 hdr=0x00 em3@pci7:0:1: class=0x020000 card=0x105e108e chip=0x105e8086 rev=0x06 hdr=0x00 %vmstat -i interrupt total rate vec1941: em0 18533 91 Total 18533 91 From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 00:53:37 2006 Return-Path: X-Original-To: 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 42A8C16A415; Thu, 19 Oct 2006 00:53:37 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95A3743D64; Thu, 19 Oct 2006 00:53:33 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.185.124] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1GaMA32oDP-0004MH; Thu, 19 Oct 2006 02:53:30 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Thu, 19 Oct 2006 02:53:15 +0200 User-Agent: KMail/1.9.4 References: <200610181908570311458@emcite.com> In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6136024.jociGyvc8A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200610190253.26560.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: gnn@freebsd.org, chenxiaochen , liangbing Subject: Re: Problems under test of IPv6 Ready Logo Program Phase-2 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: Thu, 19 Oct 2006 00:53:37 -0000 --nextPart6136024.jociGyvc8A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 19 October 2006 00:52, gnn@freebsd.org wrote: > At Wed, 18 Oct 2006 19:08:57 -0800, > > chenxiaochen wrote: > > Dear all, This is my second letter here, I am beginning to love here > > for there are many kindly friends, such as SUZUKI > > Shinsuke :) Ok,questions follows... Does someone > > do research on IPv6 Ready Logo Program? Now I am doing IPv6 > > conformance test under TAHI platform and I meet some problems. > > Though some of us are using TAHI I do not believe the project itself > is going for the Logo Program. > > I am working on IPv6 and IPSec and using TAHI regularly. > > > My test setup is below: > > -+-----------------------+- Link1 > > > > |rl0 | rl1 > > > > TN NUT > > > > |bge0 | rl0 > > > > -+-----------------------+- Link0 > > TN:IBM desktop PC,OS is FreeBSD6.1; > > NUT:IBM desktop PC,OS is FreeBSD6.1 > > --- rl0,rl1,bge0 stand for the NICs of TN and NUT. > > My test software is v6eval-3.0.10 and package are Self_Test_1-4-2 and > > v6eval-remotes-3.0. > > > > 1. Section 5: RFC 2463 - ICMPv6 > > "case 11 Part B: Multicast Destination" --- fail > > After TN send Echo Request to global multicast address(ff1e::1:2), > > the following words appear on NUT's screen-----rl1:discard oversize > > frame (ether type 86dd flags 3 len 1514 > max 1294 ) However, "case > > 10 Part A: Unicast Destination" passes. > > > > 2. Section 2: RFC 2461 - Neighbor Discovery for IPv6 > > "127 Part C: Sending Unsolicited RA (Min Values)" --- fail > > After NUT excutes rtadvd, TN says "Could't observe RA". > > The corresponding rtadvd.conf is > > I don't believe that you need to run your own RA. TAHI is usually > self contained. /me too. > > But when I use Ethereal to capture the IP package, I get RA about > > 6 seconds later after rtadvd is excuted. The captured RA's parameters > > are: > > cur hop limit--64 > > router lifetime--1800 > > reachable tiem--0 > > retrans time--0 > > valid lifetime--0x00278d00 > > preferred lifetime--0x00093a80 > > You shoudl check if this "just works" without the RA. > > > 3. Section 3: RFC 2462 - IPv6 Stateless Address Autoconfiguration > > All cases fail > > Reason----TN can't observe DAD process. > > I can't capture DAD packages by Ethereal in the network start > > process. > > > > But I can get DAD packages on IBM T43(NIC is bge0, OS is FreeBSD > > 6.1) and T30(NIC is fxp0, OS is FreeBSD 5.4) when the network > > start( host test). Someone ever told me that --- "there is a bug > > in FreeBSD's kernel which prevents DAD being sent. You have to > > force ethernet card into any mode rather than auto-select before > > it is activated, by modifying rc.network" As if rc.network has > > been change to netstart in FreeBSD 6.1. But I don't know how to > > modify it. > > I have not heard of this and don't have that hardware so can't check > it. What's your setting for the net.inet6.ip6.dad_count sysctl? I know for a=20 fact that FreeBSD does send out DAD as it has been killing me in MIP6=20 simulations. I just tested with a recent 6.2-pre and it does too send out DAD packets=20 and prevents me from configureing a duplicate on an interface=20 yelling: "bge0: DAD detected duplicate IPv6 address ..." This is a X41=20 bge0 vs. an fxp0 onboard a tyan mobo, btw. Does manual address configuration yield DAD packets? > > By the way, these is a bug I found about IPv6 Ready Logo Program > > Phase-2 auotmatic test. Hope this informaiton below will be useful > > to you. > > > > 1.install v6eval-remotes-3.0 > > 2.# cd /usr/local/v6eval/bin/freebsd-i386/ > > 3.# ee racontrol.rmt > > --------------------------------------------------------------------- > >----------------- line 288 > > "\t:rtime#$rOpt_retrans:" should be changed into=20 > > "\t:retrans#$rOpt_retrans:" > > --------------------------------------------------------------------- > >----------------- > > Best, > George =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart6136024.jociGyvc8A Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFNsyGXyyEoT62BG0RAuQcAJ9OILDK3+F99Olm8wg8Ym8k3UahqQCfQVqc ikuJ9V7RWupt3OQYrY9/mTw= =6oDw -----END PGP SIGNATURE----- --nextPart6136024.jociGyvc8A-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 02:16:52 2006 Return-Path: X-Original-To: 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 D861B16A407; Thu, 19 Oct 2006 02:16:52 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 300FB43D8E; Thu, 19 Oct 2006 02:16:27 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 9AF4C24D07E; Thu, 19 Oct 2006 12:16:25 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id AB7508C0F; Thu, 19 Oct 2006 12:16:23 +1000 (EST) Date: Thu, 19 Oct 2006 12:16:22 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Kris Kennaway In-Reply-To: <20061018224233.GA1632@xor.obsecurity.org> Message-ID: <20061019110950.X75878@delplex.bde.org> References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> <20061018224233.GA1632@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kip Macy , freebsd-stable@freebsd.org, Jack Vogel , freebsd-net Subject: Re: em network issues 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: Thu, 19 Oct 2006 02:16:53 -0000 On Wed, 18 Oct 2006, Kris Kennaway wrote: > I have been working with someone's system that has em shared with fxp, > and a simple fetch over the em (e.g. of a 10 GB file of zeroes) is > enough to produce watchdog timeouts after a few seconds. > > As previously mentioned, changing the INTR_FAST to INTR_MPSAFE in the > driver avoids this problem. However, others are seeing sporadic > watchdog timeouts at higher system load on non-shared em systems too. em_intr_fast() has no locking whatsoever. I would be very surprised if it even seemed to work for SMP. For UP, masking of CPU interrupts (as is automatic in fast interrupt handlers) might provide sufficient locking, but for many drivers fast wth interrupt handlers, whatever locking is used by the fast interrupt handler must be used all over the driver to protect data strutures that are or might be accessed by the fast interrupt handler. That means lots of intr_disable/enable()s if the UP case is micro-optimized and lots of mtx_lock/unlock_spin()s for the general case. But em has no references to spinlocks or CPU interrupt disabling. em_intr() starts with EM_LOCK(), so it isn't obviously broken near its first statement. Very few operations are valid in fast interrupt handlers. Locking and fastness must be considered for every operation, not only in the interrupt handler but in all data structures shared by the interrupt handler. For just the interrupt handler in em: % static void % em_intr_fast(void *arg) % { % struct adapter *adapter = arg; This is safe because it has no side effects and doesn't take long. % struct ifnet *ifp; % uint32_t reg_icr; % % ifp = adapter->ifp; % This is safe provided other parts of the driver ensure that the interrupt handler is not reached after adapter->ifp goes away. Similarly for other long-lived almost-const parts of *adapter. % reg_icr = E1000_READ_REG(&adapter->hw, ICR); % This is safe provided reading the register doesn't change it. % /* Hot eject? */ % if (reg_icr == 0xffffffff) % return; % % /* Definitely not our interrupt. */ % if (reg_icr == 0x0) % return; % These are safe since we don't do anything with the result. % /* % * Starting with the 82571 chip, bit 31 should be used to % * determine whether the interrupt belongs to us. % */ % if (adapter->hw.mac_type >= em_82571 && % (reg_icr & E1000_ICR_INT_ASSERTED) == 0) % return; % This is safe, as above. % /* % * Mask interrupts until the taskqueue is finished running. This is % * cheap, just assume that it is needed. This also works around the % * MSI message reordering errata on certain systems. % */ % em_disable_intr(adapter); Now that we start doing things, we have various races. The above races to disable interrupts with other entries to this interrupt handler, and may race with other parts of the driver. After we disable driver interrupts. There should be no more races with other entries to this handler. However, reg_icr may be stale at this point even if we handled the race correctly. The other entries may have partly or completely handled the interrupt when we get back here (we should have locked just before here, and then if the lock blocked waiting for the other entries (which can only happen in the SMP case), we should reread the status register to see if we still have anything to do, or more importantly to see what we have to do now (extrascheduling of the SWI handler would just wake time, but missing scheduling would break things). % taskqueue_enqueue(adapter->tq, &adapter->rxtx_task); % Safe provided the API is correctly implemented. (AFAIK, the API only has huge design errors.) % /* Link status change */ % if (reg_icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) % taskqueue_enqueue(taskqueue_fast, &adapter->link_task); % As above, plus might miss this call if the status changed underneath us. % if (reg_icr & E1000_ICR_RXO) % adapter->rx_overruns++; Race updating the counter. Generally, fast interrupt handlers should avoid book-keeping like this, since correct locking for it would poison large parts of the driver with the locking required for the fast interrupt handler. Perhaps similarly for important things. It's safe to read the status register provided reading it doesn't change it. Then it is safe to schedule tasks based on the contents of the register provided we don't do anything else and schedule enough tasks. But don't disable interrupts -- leave that to the task and make the task do nothing if it handled everything for a previous scheduling. This would result in the task usually being scheduled when the interrupt is for us but not if it is for another device. The above doesn't try to do much more than this. However, a fast interrupt handler needs to handle the usual case to be worth having except on systems where there are lots of shared interrupts. % } Bruce From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 03:21:11 2006 Return-Path: X-Original-To: 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 4CB5716A40F for ; Thu, 19 Oct 2006 03:21:11 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFEFB43D68 for ; Thu, 19 Oct 2006 03:21:10 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k9J3L1gu019202; Wed, 18 Oct 2006 21:21:08 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4536EF19.2060201@samsco.org> Date: Wed, 18 Oct 2006 21:20:57 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Bruce Evans References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> <20061018224233.GA1632@xor.obsecurity.org> <20061019110950.X75878@delplex.bde.org> In-Reply-To: <20061019110950.X75878@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Kip Macy , freebsd-net , Jack Vogel , Kris Kennaway Subject: Re: em network issues 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: Thu, 19 Oct 2006 03:21:11 -0000 Bruce Evans wrote: > On Wed, 18 Oct 2006, Kris Kennaway wrote: > >> I have been working with someone's system that has em shared with fxp, >> and a simple fetch over the em (e.g. of a 10 GB file of zeroes) is >> enough to produce watchdog timeouts after a few seconds. >> >> As previously mentioned, changing the INTR_FAST to INTR_MPSAFE in the >> driver avoids this problem. However, others are seeing sporadic >> watchdog timeouts at higher system load on non-shared em systems too. > > em_intr_fast() has no locking whatsoever. I would be very surprised > if it even seemed to work for SMP. For UP, masking of CPU interrupts > (as is automatic in fast interrupt handlers) might provide sufficient > locking, but for many drivers fast wth interrupt handlers, whatever > locking is used by the fast interrupt handler must be used all over > the driver to protect data strutures that are or might be accessed by > the fast interrupt handler. That means lots of intr_disable/enable()s > if the UP case is micro-optimized and lots of mtx_lock/unlock_spin()s > for the general case. But em has no references to spinlocks or CPU > interrupt disabling. > > em_intr() starts with EM_LOCK(), so it isn't obviously broken near its > first statement. > > Very few operations are valid in fast interrupt handlers. Locking > and fastness must be considered for every operation, not only in > the interrupt handler but in all data structures shared by the > interrupt handler. For just the interrupt handler in em: > > % static void > % em_intr_fast(void *arg) > % { > % struct adapter *adapter = arg; > > This is safe because it has no side effects and doesn't take long. > > % struct ifnet *ifp; > % uint32_t reg_icr; > % % ifp = adapter->ifp; > % > > This is safe provided other parts of the driver ensure that the interrupt > handler is not reached after adapter->ifp goes away. Similarly for other > long-lived almost-const parts of *adapter. > > % reg_icr = E1000_READ_REG(&adapter->hw, ICR); > % > > This is safe provided reading the register doesn't change it. > > % /* Hot eject? */ > % if (reg_icr == 0xffffffff) > % return; > % % /* Definitely not our interrupt. */ > % if (reg_icr == 0x0) > % return; > % > > These are safe since we don't do anything with the result. > > % /* > % * Starting with the 82571 chip, bit 31 should be used to > % * determine whether the interrupt belongs to us. > % */ > % if (adapter->hw.mac_type >= em_82571 && > % (reg_icr & E1000_ICR_INT_ASSERTED) == 0) > % return; > % > > This is safe, as above. > > % /* > % * Mask interrupts until the taskqueue is finished running. This is > % * cheap, just assume that it is needed. This also works around the > % * MSI message reordering errata on certain systems. > % */ > % em_disable_intr(adapter); > > Now that we start doing things, we have various races. > > The above races to disable interrupts with other entries to this interrupt > handler, and may race with other parts of the driver. > > After we disable driver interrupts. There should be no more races with > other entries to this handler. However, reg_icr may be stale at this > point even if we handled the race correctly. The other entries may have > partly or completely handled the interrupt when we get back here (we > should have locked just before here, and then if the lock blocked waiting > for the other entries (which can only happen in the SMP case), we should > reread the status register to see if we still have anything to do, or > more importantly to see what we have to do now (extrascheduling of the > SWI handler would just wake time, but missing scheduling would break > things). > > % taskqueue_enqueue(adapter->tq, &adapter->rxtx_task); > % > > Safe provided the API is correctly implemented. (AFAIK, the API only > has huge design errors.) > > % /* Link status change */ > % if (reg_icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) > % taskqueue_enqueue(taskqueue_fast, &adapter->link_task); > % > > As above, plus might miss this call if the status changed underneath us. > > % if (reg_icr & E1000_ICR_RXO) > % adapter->rx_overruns++; > > Race updating the counter. > > Generally, fast interrupt handlers should avoid book-keeping like this, > since correct locking for it would poison large parts of the driver > with the locking required for the fast interrupt handler. This should be an atomic add. It doesn't require any extra synchronization beyond that. It is, however, only an informational counter, and one that I forgot to fix. > Perhaps > similarly for important things. It's safe to read the status register > provided reading it doesn't change it. Then it is safe to schedule > tasks based on the contents of the register provided we don't do > anything else and schedule enough tasks. But don't disable interrupts > -- leave that to the task and make the task do nothing if it handled > everything for a previous scheduling. There is no other way to quiet the interrupt line from the device. Some devices will quiet their interrupt if you read the ISR or write back to the ISR. The e1000 chip doesn't seem to be like this, and instead relies on waiting for you to clear the rx and tx rings. i.e. it won't clear until you do real work, and you can't do real work in the INTR_FAST handler. So, if you remove the em_disable_intr, you'll get an interrupt storm in between this handler running and the taskqueue completing. That obviously won't work. If there is a better way to quiet the interrupt here, please let me know. My conversation with Intel about this 9 months ago lead me to believe that my method here is correct (modulo what I'll say below). Note that the other INTR_FAST drivers I've done, namely aac and uhci, have hardware that does allow you to silence the interrupt from the handler without having to do expensive work. > This would result in the task > usually being scheduled when the interrupt is for us but not if it is > for another device. The above doesn't try to do much more than this. > However, a fast interrupt handler needs to handle the usual case to > be worth having except on systems where there are lots of shared > interrupts. The performance measurements that Andre and I did early this year showed that the INTR_FAST handler provided a very large benefit. However, there are 2 things that I need to fix here: 1) The unprotected bookkeeping in the handler. Like I said above, this is informational only, and can be protected just fine with a single atomic add. 2) Protect top-half threads that want to call em_intr_disable/enable from the interrupt handler and taskqueue. IIRC, linux does this with a simple semaphore-like count. That means extra atomic ops and probably spinlocks, neither of which would be very good for this driver in FreeBSD. My plan here instead is to have the top-half callers set a 'paused' flag and drain the taskqueue before calling em_disable_intr. That way they know that there are no tasks scheduled or waiting on a lock release or in progress, and thus no chance that em_enable_intr will be called behind their back. I know that there is still a tricky race here, so I haven't implemented it yet. In any case, quiescing the interrupt and taskqueue is expensive, but it only needs to be done for fairly expensive and infrequent conditions (ioctls, unload/detach). (2) is the biggest flaw with the current INTR_FAST implementation. However, the biggest effect of it would be an extra interrupt during an ioctl operation, and it's unclear whether this actually poses a problem. The unlead/detach case already drains the taskqueue, though in a different spot, so it's not a big problem there either. The problem you pointed out with the cached copy of the interrupt status possibly going stale is a calculated risk. If a new condition happens, the chip will continue to signal an interrupt until it is handled. That will generate an interrupt on the CPU after the taskqueue calls em_enable_intr(), in which case it'll get handled. So, it's a lazy, but safe, handling of an edge case. Scott From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 04:02:19 2006 Return-Path: X-Original-To: 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 B0E8016A416; Thu, 19 Oct 2006 04:02:19 +0000 (UTC) (envelope-from suz@alaxala.net) Received: from pc1.alaxala.net (pc1.alaxala.net [203.178.142.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C3ED43D4C; Thu, 19 Oct 2006 04:02:18 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from localhost (localhost [127.0.0.1]) by pc1.alaxala.net (Postfix) with ESMTP id 92BF9B936; Thu, 19 Oct 2006 13:02:17 +0900 (JST) X-Virus-Scanned: amavisd-new at alaxala.net Received: from pc1.alaxala.net ([127.0.0.1]) by localhost (pc1.alaxala.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Suexi-P66H7u; Thu, 19 Oct 2006 13:02:09 +0900 (JST) Received: from flora220.uki-uki.net (pc2.alaxala.net [203.178.142.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pc1.alaxala.net (Postfix) with ESMTP id BA279B82C; Thu, 19 Oct 2006 13:02:09 +0900 (JST) Date: Thu, 19 Oct 2006 13:02:08 +0900 Message-ID: From: SUZUKI Shinsuke To: chenxiaochen@emcite.com,gnn@freebsd.org X-cite: xcite 1.33 In-Reply-To: References: <200610181908570311458@emcite.com> User-Agent: Wanderlust/2.15.1 (Almost Unreal) Emacs/22.0 Mule/5.0 (SAKAKI) Organization: Networking Technology Development Dept., ALAXALA Networks Corporation MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, liangbing@emcite.com Subject: Re: Problems under test of IPv6 Ready Logo Program Phase-2 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: Thu, 19 Oct 2006 04:02:19 -0000 Hello, Here's my comment based on my IPv6Ready Logo(Ph.2) work in KAME Project. >>>>> On Wed, 18 Oct 2006 15:52:48 -0700 >>>>> gnn@freebsd.org said: > Though some of us are using TAHI I do not believe the project itself > is going for the Logo Program. TAHI Project is one of the major member of the Logo program. (TAHI provides a automatic testing tool for the Logo program) Please see the following pages for further detail. http://www.ipv6ready.org/about_logo_program.html > > 1. Section 5: RFC 2463 - ICMPv6 > > "case 11 Part B: Multicast Destination" --- fail > > After TN send Echo Request to global multicast > > address(ff1e::1:2), the following words appear on NUT's > > screen-----rl1:discard oversize frame (ether type 86dd flags 3 > > len 1514 > max 1294 ) > > However, "case 10 Part A: Unicast Destination" passes. Judging from the above message and the source code, it seems like you've configured rl1's MTU as 1280 and send a 1500-byte packet on rl1. You should send the packet on rl0 (where its MTU is 1500). > > 2. Section 2: RFC 2461 - Neighbor Discovery for IPv6 > > "127 Part C: Sending Unsolicited RA (Min Values)" --- fail > > After NUT excutes rtadvd, TN says "Could't observe RA". #This is a test item to see the interval of the RA messages. So NUT #must run rtadvd (by hand or automatic operation by TAHI-tool) This message appears even when TN receives an RA (with an unexpected parameter). You should carefully check the log of the self-test tool to see what is an unexpected parameter. > > 3. Section 3: RFC 2462 - IPv6 Stateless Address Autoconfiguration > > All cases fail > > Reason----TN can't observe DAD process. > > I can't capture DAD packages by Ethereal in the network start process. (snip) > I have not heard of this and don't have that hardware so can't check it. I've encountered the same phenomenon sometimes. It seems like there's a short amount of time where IFF_UP bit changes from off to on, but the hardware is not ready to send a packet. (appears like an ethernet auto-negotiation has not been completely finished) Since DAD process is kicked just after link-local address configuration (normally when IFF_UP bit changes from OFF to ON), it is inevitable in such drivers. My recommendation is either of the following two. (only to pass the IPv6-Ready Logo testing) - set net.inet6.ip6.auto_linklocal to 0 - manually configures a link-local address after the auto-negotiation has been completely finished or - disable auto-negotiation or (to make all the freebsd users happy:-)) - hack the device driver to make IFF_UP on after the hardware is ready to send a packet Thanks, ---- SUZUKI, Shinsuke @ KAME Project From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 06:20:58 2006 Return-Path: X-Original-To: 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 2136316A415 for ; Thu, 19 Oct 2006 06:20:58 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3552843D4C for ; Thu, 19 Oct 2006 06:20:57 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id 14EB95BFFB9; Thu, 19 Oct 2006 16:20:14 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 7590B27403; Thu, 19 Oct 2006 16:20:11 +1000 (EST) Date: Thu, 19 Oct 2006 16:20:10 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Scott Long In-Reply-To: <4536EF19.2060201@samsco.org> Message-ID: <20061019141748.Y76352@delplex.bde.org> References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> <20061018224233.GA1632@xor.obsecurity.org> <20061019110950.X75878@delplex.bde.org> <4536EF19.2060201@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kip Macy , freebsd-net , Jack Vogel , Kris Kennaway Subject: Re: em network issues 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: Thu, 19 Oct 2006 06:20:58 -0000 On Wed, 18 Oct 2006, Scott Long wrote: [too much quoted; much deleted] > Bruce Evans wrote: >> On Wed, 18 Oct 2006, Kris Kennaway wrote: >> >>> I have been working with someone's system that has em shared with fxp, >>> and a simple fetch over the em (e.g. of a 10 GB file of zeroes) is >>> enough to produce watchdog timeouts after a few seconds. >>> >>> As previously mentioned, changing the INTR_FAST to INTR_MPSAFE in the >>> driver avoids this problem. However, others are seeing sporadic >>> watchdog timeouts at higher system load on non-shared em systems too. >> >> em_intr_fast() has no locking whatsoever. I would be very surprised >> if it even seemed to work for SMP. For UP, masking of CPU interrupts >> (as is automatic in fast interrupt handlers) might provide sufficient >> locking, ... I barely noticed the point about it being shared. With sharing, and probably especially with fast and normal interrupt handlers sharing an IRQ, locking is more needed. There are many possibilities for races. One likely one is: - em interrupt task running. Device interrupts are disabled, so the task thinks it won't be interfered with by the em interrupt handler. - shared fxp interrupt. The em interrupt handler is called. Without any explicit synchonization, bad things may happen and apparently do. In the UP case, there is some implicit synchronization which may help but is hard to understand. >> This is safe, as above. >> >> % /* >> % * Mask interrupts until the taskqueue is finished running. This is >> % * cheap, just assume that it is needed. This also works around the >> % * MSI message reordering errata on certain systems. >> % */ >> % em_disable_intr(adapter); >> >> Now that we start doing things, we have various races. >> >> The above races to disable interrupts with other entries to this interrupt >> handler, and may race with other parts of the driver. >> >> After we disable driver interrupts. There should be no more races with >> other entries to this handler. However, reg_icr may be stale at this >> point even if we handled the race correctly. The other entries may have >> partly or completely handled the interrupt when we get back here (we >> should have locked just before here, and then if the lock blocked waiting >> for the other entries (which can only happen in the SMP case), we should >> reread the status register to see if we still have anything to do, or >> more importantly to see what we have to do now (extrascheduling of the >> SWI handler would just wake time, but missing scheduling would break >> things). >> >> % taskqueue_enqueue(adapter->tq, &adapter->rxtx_task); >> % >> >> Safe provided the API is correctly implemented. (AFAIK, the API only >> has huge design errors.) >> >> % /* Link status change */ >> % if (reg_icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) >> % taskqueue_enqueue(taskqueue_fast, &adapter->link_task); >> % >> >> As above, plus might miss this call if the status changed underneath us. >> >> % if (reg_icr & E1000_ICR_RXO) >> % adapter->rx_overruns++; >> >> Race updating the counter. >> >> Generally, fast interrupt handlers should avoid book-keeping like this, >> since correct locking for it would poison large parts of the driver >> with the locking required for the fast interrupt handler. > > This should be an atomic add. It doesn't require any extra > synchronization beyond that. It is, however, only an informational > counter, and one that I forgot to fix. It should be under the same locking that you've already paid for. Mutex spinlocking is (relatively) cheap. Not cheap enough for me though -- part of my gripe about the API above is that its implementation requires lots of locking, so it cannot be implemented very efficiently. >> Perhaps >> similarly for important things. It's safe to read the status register >> provided reading it doesn't change it. Then it is safe to schedule >> tasks based on the contents of the register provided we don't do >> anything else and schedule enough tasks. But don't disable interrupts >> -- leave that to the task and make the task do nothing if it handled >> everything for a previous scheduling. > > There is no other way to quiet the interrupt line from the device. Some Oops, the interrupt must be quieted somwhere before the task is reached. One other way is to not use tasks but turn the interrupt handler into a non-fast one if it decides that it has more to do that the fast part of it can do. This can be implemented more efficiently than the above, but has the disadvantage that shared IRQs remain disabled for all other devices. > devices will quiet their interrupt if you read the ISR or write back to > the ISR. The e1000 chip doesn't seem to be like this, and instead > relies on waiting for you to clear the rx and tx rings. i.e. it won't > clear until you do real work, and you can't do real work in the > INTR_FAST handler. So, if you remove the em_disable_intr, you'll get an > interrupt storm in between this handler running and the taskqueue > completing. That obviously won't work. > > If there is a better way to quiet the interrupt here, please let me > know. My conversation with Intel about this 9 months ago lead me to > believe that my method here is correct (modulo what I'll say below). > Note that the other INTR_FAST drivers I've done, namely aac and uhci, > have hardware that does allow you to silence the interrupt from the > handler without having to do expensive work. I think there would be little difference if the hardware disabled interrupts automatically on read of the status. The read+side effect should be atomic, but the status may be changed underneath you immediately by the em task running concurrently, and later the problem of reenabling the interrupt is exactly the same. >> This would result in the task >> usually being scheduled when the interrupt is for us but not if it is >> for another device. The above doesn't try to do much more than this. >> However, a fast interrupt handler needs to handle the usual case to >> be worth having except on systems where there are lots of shared >> interrupts. > > The performance measurements that Andre and I did early this year showed > that the INTR_FAST handler provided a very large benefit. However, > there are 2 things that I need to fix here: I see how the taskqueue might win by often handling multiple interrupts for a single invocation of the taskqueue function. I'm surprised that this happens for em. If this is what is happening, then using a normal interrupt handler kicking a task queue should give almost the same benefits -- a normal interrupt handler takes a few uS longer but with enough coalescing to give a large benefits there won't be many interrupts. > ... > 2) Protect top-half threads that want to call em_intr_disable/enable from the > interrupt handler and taskqueue. IIRC, linux does this with > a simple semaphore-like count. That means extra atomic ops and probably > spinlocks, neither of which would be very good for this driver in FreeBSD. > My plan here instead is to have the top-half callers set a 'paused' flag and > drain the taskqueue before calling em_disable_intr. > That way they know that there are no tasks scheduled or waiting on a lock > release or in progress, and thus no chance that em_enable_intr will > be called behind their back. I know that there is still a tricky race > here, so I haven't implemented it yet. In any case, quiescing the > interrupt and taskqueue is expensive, but it only needs to be done for > fairly expensive and infrequent conditions (ioctls, unload/detach). You put the task scheduling after the interrupt disabling. That should be enough to ensure that the task runs later and reenables the interrupt. Apparently, it isn't. Now I can't see any problems except this not working. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 06:30:54 2006 Return-Path: X-Original-To: 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 20F0516A403 for ; Thu, 19 Oct 2006 06:30:54 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D05F43D5A for ; Thu, 19 Oct 2006 06:30:53 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k9J6UkGW021216; Thu, 19 Oct 2006 00:30:51 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <45371B91.5090507@samsco.org> Date: Thu, 19 Oct 2006 00:30:41 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Bruce Evans References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> <20061018224233.GA1632@xor.obsecurity.org> <20061019110950.X75878@delplex.bde.org> <4536EF19.2060201@samsco.org> <20061019141748.Y76352@delplex.bde.org> In-Reply-To: <20061019141748.Y76352@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Kip Macy , freebsd-net , Jack Vogel , Kris Kennaway Subject: Re: em network issues 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: Thu, 19 Oct 2006 06:30:54 -0000 Bruce Evans wrote: > On Wed, 18 Oct 2006, Scott Long wrote: > > [too much quoted; much deleted] > >> Bruce Evans wrote: >>> On Wed, 18 Oct 2006, Kris Kennaway wrote: >>> >>>> I have been working with someone's system that has em shared with fxp, >>>> and a simple fetch over the em (e.g. of a 10 GB file of zeroes) is >>>> enough to produce watchdog timeouts after a few seconds. >>>> >>>> As previously mentioned, changing the INTR_FAST to INTR_MPSAFE in the >>>> driver avoids this problem. However, others are seeing sporadic >>>> watchdog timeouts at higher system load on non-shared em systems too. >>> >>> em_intr_fast() has no locking whatsoever. I would be very surprised >>> if it even seemed to work for SMP. For UP, masking of CPU interrupts >>> (as is automatic in fast interrupt handlers) might provide sufficient >>> locking, ... > > I barely noticed the point about it being shared. With sharing, and > probably especially with fast and normal interrupt handlers sharing an > IRQ, locking is more needed. There are many possibilities for races. > One likely one is: > - em interrupt task running. Device interrupts are disabled, so the > task thinks it won't be interfered with by the em interrupt handler. What interference are you talking about? em_intr_fast changes no state in the driver softc (aside from the silly bookkeeping). It only reads from one register, and writes to no registers or shared memory. > - shared fxp interrupt. The em interrupt handler is called. Without > any explicit synchonization, bad things may happen and apparently do. > In the UP case, there is some implicit synchronization which may help > but is hard to understand. Can you be more specific as to the 'bad things'? Scott From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 07:07:09 2006 Return-Path: X-Original-To: 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 6856916A492 for ; Thu, 19 Oct 2006 07:07:09 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id B534E43D5F for ; Thu, 19 Oct 2006 07:07:08 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id 74FAE5DFCFF; Thu, 19 Oct 2006 17:07:07 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 21E042741F; Thu, 19 Oct 2006 17:07:06 +1000 (EST) Date: Thu, 19 Oct 2006 17:07:02 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Scott Long In-Reply-To: <45371B91.5090507@samsco.org> Message-ID: <20061019164814.L76712@delplex.bde.org> References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> <20061018224233.GA1632@xor.obsecurity.org> <20061019110950.X75878@delplex.bde.org> <4536EF19.2060201@samsco.org> <20061019141748.Y76352@delplex.bde.org> <45371B91.5090507@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kip Macy , freebsd-net , Jack Vogel , Kris Kennaway Subject: Re: em network issues 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: Thu, 19 Oct 2006 07:07:09 -0000 On Thu, 19 Oct 2006, Scott Long wrote: > Bruce Evans wrote: >>>> On Wed, 18 Oct 2006, Kris Kennaway wrote: >>>>> I have been working with someone's system that has em shared with fxp, >>>>> and a simple fetch over the em (e.g. of a 10 GB file of zeroes) is >>>>> enough to produce watchdog timeouts after a few seconds. >>>> >>>> em_intr_fast() has no locking whatsoever. I would be very surprised >>>> if it even seemed to work for SMP. For UP, masking of CPU interrupts >>>> (as is automatic in fast interrupt handlers) might provide sufficient >>>> locking, ... >> >> I barely noticed the point about it being shared. With sharing, and >> probably especially with fast and normal interrupt handlers sharing an >> IRQ, locking is more needed. There are many possibilities for races. >> One likely one is: >> - em interrupt task running. Device interrupts are disabled, so the >> task thinks it won't be interfered with by the em interrupt handler. > > What interference are you talking about? em_intr_fast changes no state > in the driver softc (aside from the silly bookkeeping). It only reads > from one register, and writes to no registers or shared memory. It disables interrupts. To do that, it calls em_disable_intr(). The hardware is simple enough for em_disable_intr() not to have to make many state changes, but it certainly has to make at least 1 to work. It uses several layers of macros which I think ends up doing a write to 1 register in bus space. >> - shared fxp interrupt. The em interrupt handler is called. Without >> any explicit synchonization, bad things may happen and apparently do. >> In the UP case, there is some implicit synchronization which may help >> but is hard to understand. > > Can you be more specific as to the 'bad things'? Not very. Maybe interrupts don't get reenabled as intended. Then the symptoms get mutated by watchdog timeouts. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 07:10:15 2006 Return-Path: X-Original-To: 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 15A7116A415 for ; Thu, 19 Oct 2006 07:10:15 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DA2143D5F for ; Thu, 19 Oct 2006 07:10:13 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k9J7A7F0021835; Thu, 19 Oct 2006 01:10:12 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <453724CA.8070609@samsco.org> Date: Thu, 19 Oct 2006 01:10:02 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Bruce Evans References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> <20061018224233.GA1632@xor.obsecurity.org> <20061019110950.X75878@delplex.bde.org> <4536EF19.2060201@samsco.org> <20061019141748.Y76352@delplex.bde.org> <45371B91.5090507@samsco.org> <20061019164814.L76712@delplex.bde.org> In-Reply-To: <20061019164814.L76712@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Kip Macy , freebsd-net , Jack Vogel , Kris Kennaway Subject: Re: em network issues 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: Thu, 19 Oct 2006 07:10:15 -0000 Bruce Evans wrote: > On Thu, 19 Oct 2006, Scott Long wrote: > >> Bruce Evans wrote: > >>>>> On Wed, 18 Oct 2006, Kris Kennaway wrote: >>>>>> I have been working with someone's system that has em shared with >>>>>> fxp, >>>>>> and a simple fetch over the em (e.g. of a 10 GB file of zeroes) is >>>>>> enough to produce watchdog timeouts after a few seconds. >>>>> >>>>> em_intr_fast() has no locking whatsoever. I would be very surprised >>>>> if it even seemed to work for SMP. For UP, masking of CPU interrupts >>>>> (as is automatic in fast interrupt handlers) might provide sufficient >>>>> locking, ... >>> >>> I barely noticed the point about it being shared. With sharing, and >>> probably especially with fast and normal interrupt handlers sharing an >>> IRQ, locking is more needed. There are many possibilities for races. >>> One likely one is: >>> - em interrupt task running. Device interrupts are disabled, so the >>> task thinks it won't be interfered with by the em interrupt handler. >> >> What interference are you talking about? em_intr_fast changes no state >> in the driver softc (aside from the silly bookkeeping). It only reads >> from one register, and writes to no registers or shared memory. > > It disables interrupts. To do that, it calls em_disable_intr(). The > hardware is simple enough for em_disable_intr() not to have to make > many state changes, but it certainly has to make at least 1 to work. > It uses several layers of macros which I think ends up doing a write > to 1 register in bus space. > >>> - shared fxp interrupt. The em interrupt handler is called. Without >>> any explicit synchonization, bad things may happen and apparently do. >>> In the UP case, there is some implicit synchronization which may help >>> but is hard to understand. >> >> Can you be more specific as to the 'bad things'? > > Not very. Maybe interrupts don't get reenabled as intended. Then the > symptoms get mutated by watchdog timeouts. > > Bruce Then yes, I'm already thinking of a better way to do the interrupt enable/disable thing. I am still very surprised that the hardware cannot be silenced by doing a read and/or write of a status register, like most other hardware. If that were possible, this would be a very simple problem. Scott From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 09:30:51 2006 Return-Path: X-Original-To: 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 D7FF516A415 for ; Thu, 19 Oct 2006 09:30:51 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E6FD43D4C for ; Thu, 19 Oct 2006 09:30:51 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id B48905A0C46; Thu, 19 Oct 2006 19:30:49 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 8A26B2740A; Thu, 19 Oct 2006 19:30:48 +1000 (EST) Date: Thu, 19 Oct 2006 19:30:47 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Scott Long In-Reply-To: <453724CA.8070609@samsco.org> Message-ID: <20061019192654.U77123@delplex.bde.org> References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> <20061018224233.GA1632@xor.obsecurity.org> <20061019110950.X75878@delplex.bde.org> <4536EF19.2060201@samsco.org> <20061019141748.Y76352@delplex.bde.org> <45371B91.5090507@samsco.org> <20061019164814.L76712@delplex.bde.org> <453724CA.8070609@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kip Macy , freebsd-net , Jack Vogel , Kris Kennaway Subject: Re: em network issues 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: Thu, 19 Oct 2006 09:30:51 -0000 On Thu, 19 Oct 2006, Scott Long wrote: > Bruce Evans wrote: >> On Thu, 19 Oct 2006, Scott Long wrote: >>> Can you be more specific as to the 'bad things'? >> >> Not very. Maybe interrupts don't get reenabled as intended. Then the >> symptoms get mutated by watchdog timeouts. > > Then yes, I'm already thinking of a better way to do the interrupt > enable/disable thing. I am still very surprised that the hardware > cannot be silenced by doing a read and/or write of a status register, > like most other hardware. If that were possible, this would be a very > simple problem. Er, what is it that em_disable_intr() disables? The problem might go the other way, being that em_enable_intr() doesn't always work due to the device not liking high frequency toggling of the interrupt mask register. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 18:17:23 2006 Return-Path: X-Original-To: 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 E78D716A4EF; Thu, 19 Oct 2006 18:17:23 +0000 (UTC) (envelope-from remko@freebsd.org) Received: from caelis.elvandar.org (caelis.elvandar.org [217.148.169.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBB9043D69; Thu, 19 Oct 2006 18:17:02 +0000 (GMT) (envelope-from remko@freebsd.org) Received: from localhost (caelis.elvandar.org [217.148.169.59]) by caelis.elvandar.org (Postfix) with ESMTP id CA90692FDBE; Thu, 19 Oct 2006 20:16:48 +0200 (CEST) Received: from caelis.elvandar.org ([217.148.169.59]) by localhost (caelis.elvandar.org [217.148.169.59]) (amavisd-new, port 10024) with ESMTP id 72911-09; Thu, 19 Oct 2006 20:16:48 +0200 (CEST) Received: from [10.0.2.125] (evilcoder.xs4all.nl [195.64.94.120]) by caelis.elvandar.org (Postfix) with ESMTP id 5ED0E92FCE9; Thu, 19 Oct 2006 20:16:48 +0200 (CEST) Message-ID: <4537C126.5000207@FreeBSD.org> Date: Thu, 19 Oct 2006 20:17:10 +0200 From: Remko Lodder User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Kip Macy References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> <20061018171704.A3851@demos.bsdclusters.com> In-Reply-To: <20061018171704.A3851@demos.bsdclusters.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by the elvandar.org maildomain Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: remko@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2006 18:17:24 -0000 Kip Macy wrote: > > On Wed, 18 Oct 2006, Jack Vogel wrote: >> I'm a bit confused from the way you worded this, do you have watchdogs >> with em, or you use em to avoid them? > > I have watchdogs with the current (post vendor update) em driver, but > not with an older (pre vendor update) version of it. > Same here! Didn't had the problem prior to the update, after the update it started doing watchdog timeouts, occassionaly the interface goes up/down after the watchdog error. I did not spot this on my other servers yet, but the traffic passing the if_em interface is not that much (just normal webtraffic, mail traffic etc). cheers, remko -- Kind regards, Remko Lodder ** remko@elvandar.org FreeBSD ** remko@FreeBSD.org /* Quis custodiet ipsos custodes */ From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 18:57:31 2006 Return-Path: X-Original-To: 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 CFD5A16A4AB for ; Thu, 19 Oct 2006 18:57:31 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACE2943DBE for ; Thu, 19 Oct 2006 18:57:03 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so921526pye for ; Thu, 19 Oct 2006 11:57:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rMsFNw6+7G/7CyEcadlEo0bAEBKpAQVgR5U/gsq6HdVqdCGeWYbG+/sf++9Cm5VH8A11bmbFg0cIVSY+BMIXrhh4yv3m+RK0+PiFem2aDmjnF6Zbi68mrxix58ARjj7AsQpXsKl2RkOjODNmb6UgQxhBPqr567PcgZhMiuHUBnw= Received: by 10.35.48.15 with SMTP id a15mr381065pyk; Thu, 19 Oct 2006 11:40:16 -0700 (PDT) Received: by 10.35.119.1 with HTTP; Thu, 19 Oct 2006 11:40:16 -0700 (PDT) Message-ID: <2a41acea0610191140j13d43e12q72fc7697652e222a@mail.gmail.com> Date: Thu, 19 Oct 2006 11:40:16 -0700 From: "Jack Vogel" To: remko@freebsd.org In-Reply-To: <4537C126.5000207@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> <20061018171704.A3851@demos.bsdclusters.com> <4537C126.5000207@FreeBSD.org> Cc: freebsd-net , Kip Macy , freebsd-stable@freebsd.org Subject: Re: em network issues 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: Thu, 19 Oct 2006 18:57:31 -0000 On 10/19/06, Remko Lodder wrote: > Kip Macy wrote: > > > > On Wed, 18 Oct 2006, Jack Vogel wrote: > >> I'm a bit confused from the way you worded this, do you have watchdogs > >> with em, or you use em to avoid them? > > > > I have watchdogs with the current (post vendor update) em driver, but > > not with an older (pre vendor update) version of it. > > > > Same here! > > Didn't had the problem prior to the update, after the update it > started doing watchdog timeouts, occassionaly the interface goes > up/down after the watchdog error. I did not spot this on my other > servers yet, but the traffic passing the if_em interface is not that > much (just normal webtraffic, mail traffic etc). > > cheers, > remko LOL, you arent helping, i need to know WHAT CVS deltas work vs dont, in other words, which delta in the REL_ENG_6 stream broke things?? If you quantify what 'the update' means that might help me, was this the 6.2 BETA or what? Thanks, Jack From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 19:44:50 2006 Return-Path: X-Original-To: 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 6815D16A415; Thu, 19 Oct 2006 19:44:50 +0000 (UTC) (envelope-from remko@freebsd.org) Received: from caelis.elvandar.org (caelis.elvandar.org [217.148.169.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79E0043D90; Thu, 19 Oct 2006 19:44:13 +0000 (GMT) (envelope-from remko@freebsd.org) Received: from localhost (caelis.elvandar.org [217.148.169.59]) by caelis.elvandar.org (Postfix) with ESMTP id EEA3B92FDBF; Thu, 19 Oct 2006 21:44:11 +0200 (CEST) Received: from caelis.elvandar.org ([217.148.169.59]) by localhost (caelis.elvandar.org [217.148.169.59]) (amavisd-new, port 10024) with ESMTP id 84452-01; Thu, 19 Oct 2006 21:44:11 +0200 (CEST) Received: from [10.0.2.125] (evilcoder.xs4all.nl [195.64.94.120]) by caelis.elvandar.org (Postfix) with ESMTP id 476EE92FCD3; Thu, 19 Oct 2006 21:44:11 +0200 (CEST) Message-ID: <4537D5A0.6090004@FreeBSD.org> Date: Thu, 19 Oct 2006 21:44:32 +0200 From: Remko Lodder User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> <20061018171704.A3851@demos.bsdclusters.com> <4537C126.5000207@FreeBSD.org> <2a41acea0610191140j13d43e12q72fc7697652e222a@mail.gmail.com> In-Reply-To: <2a41acea0610191140j13d43e12q72fc7697652e222a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by the elvandar.org maildomain Cc: freebsd-net , Kip Macy , freebsd-stable@freebsd.org Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: remko@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2006 19:44:50 -0000 Jack Vogel wrote: > On 10/19/06, Remko Lodder wrote: >> Kip Macy wrote: >> > >> > On Wed, 18 Oct 2006, Jack Vogel wrote: >> >> I'm a bit confused from the way you worded this, do you have watchdogs >> >> with em, or you use em to avoid them? >> > >> > I have watchdogs with the current (post vendor update) em driver, but >> > not with an older (pre vendor update) version of it. >> > >> >> Same here! >> >> Didn't had the problem prior to the update, after the update it >> started doing watchdog timeouts, occassionaly the interface goes >> up/down after the watchdog error. I did not spot this on my other >> servers yet, but the traffic passing the if_em interface is not that >> much (just normal webtraffic, mail traffic etc). >> >> cheers, >> remko > > LOL, you arent helping, i need to know WHAT CVS deltas work vs dont, > in other words, which delta in the REL_ENG_6 stream broke things?? > If you quantify what 'the update' means that might help me, was this > the 6.2 BETA or what? > > Thanks, > > Jack It wasn't 6.2-BETA it was after the new driver import, around 2 months ago if I remember correctly. It appears to be only on machines with some data traffic. I updated to the 6-STABLE when the new intel driver was imported, after that the problems started , so my best guess is that it has something to do with that driver update. Hope this helps some more (see pciconf for more details about my cards) pciconf: em0@pci0:9:0: class=0x020000 card=0x11138086 chip=0x10768086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82547EI Gigabit Ethernet Controller' class = network subclass = ethernet em1@pci0:10:0: class=0x020000 card=0x11138086 chip=0x10768086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82547EI Gigabit Ethernet Controller' class = network subclass = ethernet -- Kind regards, Remko Lodder ** remko@elvandar.org FreeBSD ** remko@FreeBSD.org /* Quis custodiet ipsos custodes */ From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 22:08:05 2006 Return-Path: X-Original-To: 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 21E5116A403 for ; Thu, 19 Oct 2006 22:08:05 +0000 (UTC) (envelope-from lists@visionsix.com) Received: from peace.visionsix.com (mail.visionsix.com [206.113.65.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id B063043D45 for ; Thu, 19 Oct 2006 22:08:04 +0000 (GMT) (envelope-from lists@visionsix.com) Received: from vsis169 (unverified [206.113.65.14]) by peace.visionsix.com (Vircom SMTPRS 4.35.480.0) with SMTP id for ; Thu, 19 Oct 2006 17:08:05 -0500 X-Modus-BlackList: 206.113.65.14=OK;lists@visionsix.com=OK X-Modus-Trusted: 206.113.65.14=YES Message-ID: <01f901c6f3cb$19027560$de0a0a0a@visionsix.com> From: "Lewis Watson" To: References: <6170c1110610180933g10a600dbu98cd1d7aab60e987@mail.gmail.com> Date: Thu, 19 Oct 2006 17:08:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Subject: Re: Networking newbie 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: Thu, 19 Oct 2006 22:08:05 -0000 > As a total networking newbie, I'm looking for step-by-step > instructions. I > know the network topology, but don't know how to make them 'work'. Do > I > need to 'define' a domain? What is it that makes my network a cohesive > unit? > > If someone could point me to a step-by-step document, that'd be great. > The > FreeBSD handbook has all of the components (I suspect) but not the > actual > concepts of getting it all to work. > > Thanks! > -Brent Hi Brent, I believe you will find there is not so much a step-by-step document, but rather several protocols and technologies that you can use to achive the network configuration that will match the needs and critera of your network. One of the best resources I have found for basic and advanced networking concepts is cisco.com. The documents there will introduce you to | standardized | concepts of LAN and WAN, as well as routing, bridging, network management, etc etc. Here are a couple of starting points... http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/index.htm http://www.cisco.com/univercd/cc/td/doc/cisintwk/idg4/index.htm Good luck, Lewis Watson From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 22:24:37 2006 Return-Path: X-Original-To: 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 BD1AC16A417 for ; Thu, 19 Oct 2006 22:24:37 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB9F243D58 for ; Thu, 19 Oct 2006 22:24:34 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.6/8.13.6) with ESMTP id k9JMOXQO018217; Thu, 19 Oct 2006 15:24:34 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <4536EF19.2060201@samsco.org> Date: Thu, 19 Oct 2006 15:24:33 -0700 (PDT) From: John Polstra To: Scott Long Cc: freebsd-net Subject: Re: em network issues 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: Thu, 19 Oct 2006 22:24:37 -0000 On 19-Oct-2006 Scott Long wrote: > The performance measurements that Andre and I did early this year showed > that the INTR_FAST handler provided a very large benefit. I'm trying to understand why that's the case. Is it because an INTR_FAST interrupt doesn't have to be masked and unmasked in the APIC? I can't see any other reason for much of a performance difference in that driver. With or without INTR_FAST, you've got the bulk of the work being done in a background thread -- either the ithread or the taskqueue thread. It's not clear to me that it's any cheaper to run a task than it is to run an ithread. A difference might show up if you had two or more em devices sharing the same IRQ. Then they'd share one ithread, but would each get their own taskqueue thread. But sharing an IRQ among multiple gigabit NICs would be avoided by anyone who cared about performance, so it's not a very interesting case. Besides, when you first committed this stuff, INTR_FAST interrupts were not sharable. Another change you made in the same commit (if_em.c revision 1.98) greatly reduced the number of PCI writes made to the RX ring consumer pointer register. That would yield a significant performance improvement. Did you see gains from INTR_FAST even without this independent change? John From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 23:42:15 2006 Return-Path: X-Original-To: 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 BFF0816A412 for ; Thu, 19 Oct 2006 23:42:15 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3351443D49 for ; Thu, 19 Oct 2006 23:42:15 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id 7887F149005; Fri, 20 Oct 2006 09:42:13 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 847DE2741B; Fri, 20 Oct 2006 09:42:12 +1000 (EST) Date: Fri, 20 Oct 2006 09:42:11 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John Polstra In-Reply-To: Message-ID: <20061020090022.V79425@delplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net , Scott Long Subject: Re: em network issues 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: Thu, 19 Oct 2006 23:42:15 -0000 On Thu, 19 Oct 2006, John Polstra wrote: > On 19-Oct-2006 Scott Long wrote: >> The performance measurements that Andre and I did early this year showed >> that the INTR_FAST handler provided a very large benefit. > > I'm trying to understand why that's the case. Is it because an > INTR_FAST interrupt doesn't have to be masked and unmasked in the > APIC? I can't see any other reason for much of a performance > difference in that driver. With or without INTR_FAST, you've got > the bulk of the work being done in a background thread -- either the > ithread or the taskqueue thread. It's not clear to me that it's any > cheaper to run a task than it is to run an ithread. It's very unlikely to be because masking in the APIC is slow. The APIC is fast compared with the PIC, and even with the PIC it takes a very high interrupt rate (say 20 KHz) for the PIC overhead to become noticeable (say 5-10%), Such interrupt rates may occur, but if they do you've probably already lost. Previously I said that the difference might be due to interrupts coalescing but that I wouldn't expect that to happen. Now I see how it can happen on loaded systems: the system might be so loaded that it often doesn't get around to running the task before a new device interrupt would occur if device interrupts weren't turned off. The scheduling of the task might accidentally be best or good enough. A task might work better than a software ithread accidentally because it has lower priority, and similarly, a software ithread might work better than a hardware ithread. The lower-priority threads can also be preempted, at least with PREEMPTION configured. This is bad for them but good for whatever preempts them. Apart from this, it's _more_ expensive to run a task plus an interrupt handler (even if the interrupt handler is fast) than to run a single interrupt handler, and more expensive to switch between the handlers, and more expensive again if PREEMPTION actually has much effect -- then more switches occur. > A difference might show up if you had two or more em devices sharing > the same IRQ. Then they'd share one ithread, but would each get their > own taskqueue thread. But sharing an IRQ among multiple gigabit NICs > would be avoided by anyone who cared about performance, so it's not a > very interesting case. Besides, when you first committed this > stuff, INTR_FAST interrupts were not sharable. Sharing an IRQ among a single gigabit NIC and other slower devices is even less interesting :-). It can be hard to measure performance, especially when there are a lot of threads or a lot of fast interrupts handlers. If the performance benefits are due to accidental scheduling then they might vanish under different loads. Bruce From owner-freebsd-net@FreeBSD.ORG Fri Oct 20 00:01:52 2006 Return-Path: X-Original-To: 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 B0A1C16A403 for ; Fri, 20 Oct 2006 00:01:52 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46ADE43D45 for ; Fri, 20 Oct 2006 00:01:51 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k9K01iXI040325; Thu, 19 Oct 2006 18:01:49 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <453811E4.9010304@samsco.org> Date: Thu, 19 Oct 2006 18:01:40 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: John Polstra References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net Subject: Re: em network issues 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: Fri, 20 Oct 2006 00:01:52 -0000 John Polstra wrote: > On 19-Oct-2006 Scott Long wrote: >> The performance measurements that Andre and I did early this year showed >> that the INTR_FAST handler provided a very large benefit. > > I'm trying to understand why that's the case. Is it because an > INTR_FAST interrupt doesn't have to be masked and unmasked in the > APIC? I can't see any other reason for much of a performance > difference in that driver. With or without INTR_FAST, you've got > the bulk of the work being done in a background thread -- either the > ithread or the taskqueue thread. It's not clear to me that it's any > cheaper to run a task than it is to run an ithread. > > A difference might show up if you had two or more em devices sharing > the same IRQ. Then they'd share one ithread, but would each get their > own taskqueue thread. But sharing an IRQ among multiple gigabit NICs > would be avoided by anyone who cared about performance, so it's not a > very interesting case. Besides, when you first committed this > stuff, INTR_FAST interrupts were not sharable. Interrupt sharing is one consideration. And sometimes sharing can't be avoided; I'm working with a product that has 2 dual port e1000 cards, 4 dual port FC cards, and an onboard dual port e1000 chip and dual port SCSI chip. All of those devices are only on 2 PCI buses. So, sharing is inevitable. MSI might help mitigate this, once it becomes a reality in FreeBSD. The cost of the APIC operation can be a factor. There is a single spinlock for all APICs, so you can get contention with multiple CPUs servicing interrupts and colliding on the APIC lock. When there isn't much contention, the cost of the APIC spinlock is no more than the cost of the taskqueue lock, and the scheduling locks are about the same. > > Another change you made in the same commit (if_em.c revision 1.98) > greatly reduced the number of PCI writes made to the RX ring consumer > pointer register. That would yield a significant performance > improvement. Did you see gains from INTR_FAST even without this > independent change? PCI writes are store-and-forward so they are practically free, unlike PCI reads. There was speculation that interrupting the chip less with fewer writes might be a benefit, but I don't think that this was ever tested by itself. The big win came from moving the locking outside of the basic interrupt handler. The handler can now run completely free of any other driver or stack contention. False interrupts (especially for the shared case) can be handled without blocking the rest of the driver. Since there is no ithread sharing, there is also a fairly deterministic amount of time to get to the interrupt handler now; so the chance of rx overflows goes down. Even if one thread is stuck in a tight loop doing tx or tx-complete operations, the taskqueue can run the rx path without any contention. Also, in the non-shared case, the amount of time needed to do the register read in the handler no longer delays the upper or lower half of the driver. Andre measured about a 20% gain with just this, IIRC. I then took the next step and pushed locking out of the RX path. That dramatically increased forwarding performance, as the rx path of one driver could drive the tx path of the other driver without any contention from either driver. We came close to getting 1mpps in the fast-forward case, and we suspect that the only reason that we didn't reach the 1m mark is because prefetching was turned off accidentally on the chip. This last change brought the overall performance gain to about 50% more than the unmodified driver. I certainly don't attribute that all to the INTR_FAST change, but like I stated above, a good portion of it is. Note that I started the work on if_em not to improve performance, but to prototype a way to eliminate the interrupt aliasing that was happening on the Intel chipsets. I only asked Andre and others to test it for performance because I didn't want it to be a pessimization. Once we discovered that it helped, I went the extra steps with optimizing the rx path. Scott From owner-freebsd-net@FreeBSD.ORG Fri Oct 20 00:35:18 2006 Return-Path: X-Original-To: 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 516B916A4A0 for ; Fri, 20 Oct 2006 00:35:18 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E3CE43D5D for ; Fri, 20 Oct 2006 00:35:15 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k9K0K2gU040705; Thu, 19 Oct 2006 18:20:12 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4538162E.1050006@samsco.org> Date: Thu, 19 Oct 2006 18:19:58 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Bruce Evans References: <20061020090022.V79425@delplex.bde.org> In-Reply-To: <20061020090022.V79425@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , John Polstra Subject: Re: em network issues 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: Fri, 20 Oct 2006 00:35:18 -0000 Bruce Evans wrote: > On Thu, 19 Oct 2006, John Polstra wrote: > >> On 19-Oct-2006 Scott Long wrote: >>> The performance measurements that Andre and I did early this year showed >>> that the INTR_FAST handler provided a very large benefit. >> >> I'm trying to understand why that's the case. Is it because an >> INTR_FAST interrupt doesn't have to be masked and unmasked in the >> APIC? I can't see any other reason for much of a performance >> difference in that driver. With or without INTR_FAST, you've got >> the bulk of the work being done in a background thread -- either the >> ithread or the taskqueue thread. It's not clear to me that it's any >> cheaper to run a task than it is to run an ithread. > > It's very unlikely to be because masking in the APIC is slow. The > APIC is fast compared with the PIC, and even with the PIC it takes a > very high interrupt rate (say 20 KHz) for the PIC overhead to become > noticeable (say 5-10%), Such interrupt rates may occur, but if they > do you've probably already lost. > > Previously I said that the difference might be due to interrupts > coalescing but that I wouldn't expect that to happen. Now I see how > it can happen on loaded systems: the system might be so loaded that > it often doesn't get around to running the task before a new device > interrupt would occur if device interrupts weren't turned off. The > scheduling of the task might accidentally be best or good enough. A > task might work better than a software ithread accidentally because > it has lower priority, and similarly, a software ithread might work > better than a hardware ithread. The lower-priority threads can also > be preempted, at least with PREEMPTION configured. This is bad for > them but good for whatever preempts them. Apart from this, it's _more_ > expensive to run a task plus an interrupt handler (even if the interrupt > handler is fast) than to run a single interrupt handler, and more > expensive to switch between the handlers, and more expensive again if > PREEMPTION actually has much effect -- then more switches occur. > That's all fine and good, but the em task thread runs at the same priority as a PI_NET ithread. The whole taskqueue thing was just a prototype for getting to ifilters. I've demonstrated positive results with it for aac, em, and mpt drivers. Scott >> A difference might show up if you had two or more em devices sharing >> the same IRQ. Then they'd share one ithread, but would each get their >> own taskqueue thread. But sharing an IRQ among multiple gigabit NICs >> would be avoided by anyone who cared about performance, so it's not a >> very interesting case. Besides, when you first committed this >> stuff, INTR_FAST interrupts were not sharable. > > Sharing an IRQ among a single gigabit NIC and other slower devices is > even less interesting :-). > > It can be hard to measure performance, especially when there are a lot > of threads or a lot of fast interrupts handlers. If the performance > benefits are due to accidental scheduling then they might vanish under > different loads. > It's easy to measure performance when you have a Smartbits. More kpps means more kpps. Thanks again to Andre for making this resource available. Scott From owner-freebsd-net@FreeBSD.ORG Fri Oct 20 18:43:19 2006 Return-Path: X-Original-To: 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 5C3A316A403 for ; Fri, 20 Oct 2006 18:43:19 +0000 (UTC) (envelope-from brian@tnetus.com) Received: from k2smtpout03-01.prod.mesa1.secureserver.net (k2smtpout03-01.prod.mesa1.secureserver.net [64.202.189.171]) by mx1.FreeBSD.org (Postfix) with SMTP id E58E943D7D for ; Fri, 20 Oct 2006 18:43:12 +0000 (GMT) (envelope-from brian@tnetus.com) Received: (qmail 22323 invoked from network); 20 Oct 2006 18:43:11 -0000 Received: from unknown (HELO tnetus.com) (68.178.207.93) by k2smtpout03-01.prod.mesa1.secureserver.net (64.202.189.171) with SMTP; 20 Oct 2006 18:43:11 -0000 Received: from [192.168.1.3] ([85.105.19.185]) by tnetus.com with hMailServer ; Fri, 20 Oct 2006 11:43:05 -0700 Message-ID: <45391895.8010507@tnetus.com> Date: Fri, 20 Oct 2006 21:42:29 +0300 From: Brian Hawk User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: 7bit Subject: Gateway problem 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: Fri, 20 Oct 2006 18:43:19 -0000 I'm having a strange situation for quite sometime. I have two external interfaces one of which is an ADSL interface tun0 and obtains IP address dynamically and the other is a (xl1) leased line which has a static global IP address, lets say 212.64.212.180. Both interfaces access internet without any problem. Recently I've configured qmail on this system to send out email thru xl1 interface and use ADSL only for web traffic. It used to work quite good for a while but recently I noticed TCP packets have been going out from tun0 and responses coming in thru xl1. tun0 and ADSL is the default gateway. But the TCP packets are bound to 212.64.212.180 IP address which should send them out thru xl1. But it doesn't. For the test, I did these tcpdump -nt -i xl1 tcp & telnet -s 212.64.212.180 smtp.tnet.com 25 connection establishes but I can see only the TCP response packets coming from xl1, like the following x.y.z.t > 212.64.212.180 x.y.z.t > 212.64.212.180 All from external IPs to my xl1 int. No packets going out from xl1 they all go thru default gateway even if TCP connections are bound to xl1's IP address. I'd like to know if anybody knows why this happened and I can I turn things back the way they were. Any help would be much appreciated. My configuration is like this; FreeBSD 5.4-RELEASE ipf: IP Filter: v3.4.35 (336) Kernel: IP Filter: v3.4.35 ipfw has no rules; allow ip from any to any there's also a transparent proxy setup for squid #~>netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 88.234.8.1 UGS 0 78722302 tun0 10/24 link#1 UC 0 0 rl0 => 10 10.1.1.222 UGS 0 26233 xl0 10.0.0.99 link#1 UHLW 0 4 rl0 10.1.1/24 link#2 UC 0 0 xl0 10.1.1.13 00:50:8d:ed:88:94 UHLW 0 1876 xl0 1118 10.1.1.222 00:01:02:df:c1:19 UHLW 1 689 lo0 10.1.1.225 00:b0:d0:20:b7:9e UHLW 0 96690 xl0 706 88.234.8.1 88.234.14.26 UH 1 0 tun0 127.0.0.1 127.0.0.1 UH 0 2305904 lo0 192.168.0/16 link#3 UCS 0 0 xl1 212.64.212.176 ff:ff:ff:ff:ff:ff UHLWb 0 15 xl1 => 212.64.212.176/29 link#3 UC 0 0 xl1 212.64.212.180 00:04:76:9b:3d:f8 UHLW 0 125 lo0 From owner-freebsd-net@FreeBSD.ORG Fri Oct 20 22:57:52 2006 Return-Path: X-Original-To: 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 713B516A412 for ; Fri, 20 Oct 2006 22:57:52 +0000 (UTC) (envelope-from prvs=julian=441c3ccac@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4151643D5A for ; Fri, 20 Oct 2006 22:57:52 +0000 (GMT) (envelope-from prvs=julian=441c3ccac@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 20 Oct 2006 15:57:52 -0700 Message-ID: <4539546F.6070705@elischer.org> Date: Fri, 20 Oct 2006 15:57:51 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: PFIL hooks etc. 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: Fri, 20 Oct 2006 22:57:52 -0000 I'm looking at some changes to the pfil and ipfw code. I notice that the pfil changes for link layer and bridge based filtering have not been completed yet.. (by which I mean that ipfw is still called directly from those places rather than via pfil. Is anyone working on this? I have been playing around with filtering bridges and notice that there is no way for pfil to tell the called modules (e.g. ipfw) that it was called from a bridge as opposed to having been called from the ethernet framework. I see two possible ways this could be done. 1/ adding a filter list head with a different KEY/KEYTYPE for example adding a third keytype: #define PFIL_TYPE_AF 1 /* key is AF_* type */ #define PFIL_TYPE_IFNET 2 /* key is ifnet pointer */ #define PFIL_TYPE_BRIDGE 3 /* key is ignored. Used for bridging */ and making a special filter list for bridging. It would be possible to use the ifnet associated with the bridge I guess but it would be hard to find the right queue if you didn't know where the ifnet for the bridge was. Possibly another way would be to extend the flags sent with each packet do contain more than just the direction: #define PFIL_OUT 0x00000002 #define PFIL_WAITOK 0x00000004 #define PFIL_ALL (PFIL_IN|PFIL_OUT) +#define PFIL_DIR (PFIL_IN|PFIL_OUT) +#define PFIL_IPSTACK 0x00000010 +#define PFIL_BRIDGE 0x00000020 +#define PFIL_LINK 0x00000030 +#define PFIL_CALLER 0x000000F0 thus (flags & PFIL_CALLER) can be tested to see who called you. and (flags & PFIL_DIR) can be tested to get the direction. thoughts? Julian From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 01:05:49 2006 Return-Path: X-Original-To: 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 CCB5616A412; Sat, 21 Oct 2006 01:05:49 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 184E443D58; Sat, 21 Oct 2006 01:05:44 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.179.70] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1Gb5Ij3t1j-0002jf; Sat, 21 Oct 2006 03:05:38 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Sat, 21 Oct 2006 03:07:19 +0200 User-Agent: KMail/1.9.4 References: <4539546F.6070705@elischer.org> In-Reply-To: <4539546F.6070705@elischer.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1523085.bxqrzBJcI8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200610210307.25911.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: andre@freebsd.org, Julian Elischer Subject: Re: PFIL hooks etc. 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: Sat, 21 Oct 2006 01:05:49 -0000 --nextPart1523085.bxqrzBJcI8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 21 October 2006 00:57, Julian Elischer wrote: > I'm looking at some changes to the pfil and ipfw code. > > I notice that the pfil changes for link layer and bridge based > filtering have not been completed yet.. > (by which I mean that ipfw is still called directly > from those places rather than via pfil. Is anyone working on this? > I have been playing around with filtering bridges and > notice that there is no way for pfil to tell the > called modules (e.g. ipfw) that it was called from a bridge as opposed > to having been called from the ethernet framework. > > I see two possible ways this could be done. > 1/ adding a filter list head with a different KEY/KEYTYPE > for example > adding a third keytype: > > #define PFIL_TYPE_AF 1 /* key is AF_* type */ > #define PFIL_TYPE_IFNET 2 /* key is ifnet pointer */ > #define PFIL_TYPE_BRIDGE 3 /* key is ignored. Used for bridging > */ > > and making a special filter list for bridging. It would be possible > to use the ifnet associated with the bridge I guess but it would be > hard to find the right queue if you didn't know where the ifnet > for the bridge was. > > Possibly another way would be to extend the flags sent > with each packet do contain more than just the direction: > > #define PFIL_OUT 0x00000002 > #define PFIL_WAITOK 0x00000004 > #define PFIL_ALL (PFIL_IN|PFIL_OUT) > +#define PFIL_DIR (PFIL_IN|PFIL_OUT) > +#define PFIL_IPSTACK 0x00000010 > +#define PFIL_BRIDGE 0x00000020 > +#define PFIL_LINK 0x00000030 > +#define PFIL_CALLER 0x000000F0 > > > thus (flags & PFIL_CALLER) can be tested to see who called you. > and (flags & PFIL_DIR) can be tested to get the direction. > > thoughts? Andre has a WIP for this. I'll let him speak. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1523085.bxqrzBJcI8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFOXLNXyyEoT62BG0RAnSSAJ9WwNi0SKGgHlbadCkQsAVTV0z+CgCaAmn6 fOhDjoE1ljBUVHYL13DlUFg= =F+6E -----END PGP SIGNATURE----- --nextPart1523085.bxqrzBJcI8-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 01:17:45 2006 Return-Path: X-Original-To: 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 7FD1516A47C for ; Sat, 21 Oct 2006 01:17:45 +0000 (UTC) (envelope-from lists@codeangels.com) Received: from mail.codeangels.com (monkey.codeangels.com [62.2.169.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0086C43D53 for ; Sat, 21 Oct 2006 01:17:42 +0000 (GMT) (envelope-from lists@codeangels.com) Received: (qmail-ldap/ctrl 15337 invoked from network); 21 Oct 2006 01:17:40 -0000 Received: from monkey.codeangels.com (HELO www.codeangels.com) (nglvdz@[192.168.5.6]) (envelope-sender ) by monkey.codeangels.com (qmail-ldap-1.03) with SMTP for ; 21 Oct 2006 01:17:40 -0000 Message-ID: <2108.192.168.1.6.1161393460.squirrel@www.codeangels.com> Date: Sat, 21 Oct 2006 03:17:40 +0200 (CEST) From: "Kirill Ponazdyr" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/Codeangels_GEN MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Subject: Gigabit performance test X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@codeangels.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2006 01:17:45 -0000 Hello, I am preparing a test of different FreeBSD firewalls in our lab, before doing so I am trying to push maximum 2 gbps of traffic through the machine with a simple routed on it in the most optimal way. The lab setup is as following: 4 x traffic generators machines: Dual Opteron, generic FreeBSD 6.1 / AMD64 kernel + iperf 2.02. The iperf between the machines directly is almost always around ~930 megabit, which is fine (See table referenced later for detailed results). 1 x Firewall machine, which is a Dell 2650 Server, for detailed specs please see: dmesg: http://www.codeangels.com/misc/fwtest/first/fw_dmesg.txt pciconf: http://www.codeangels.com/misc/fwtest/first/fw_pciconf.txt sysctl: http://www.codeangels.com/misc/fwtest/first/fw_sysctl.txt kernel: http://www.codeangels.com/misc/fwtest/first/fw_kern.txt HZ and Pooling values in those config files have been changed by me during test several times as you will see in results table. The kernels have pf compiled in but it is not turned on at this time. The network topo is: http://www.codeangels.com/misc/fwtest/first/topo.gif And here are the results: http://www.codeangels.com/misc/fwtest/first/results.htm My questions are: * Single stream / single thread is always slower then in direct machine to machine communication, full throughput is reached only with multiple threads. Why? * In polling mode, there seems to be a "magic wall" between 1.3 and 1.7gbps where INT CPU usage suddenly jumps up from almost nothing to over 45+ and throughput stops there, Why? Can this be changed? * Any other ideas on improving performance of this box? Thanks ahead for help! Kirill From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 01:28:42 2006 Return-Path: X-Original-To: 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 D71BE16A403 for ; Sat, 21 Oct 2006 01:28:42 +0000 (UTC) (envelope-from prvs=julian=442ad5a4a@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAF7C43D46 for ; Sat, 21 Oct 2006 01:28:42 +0000 (GMT) (envelope-from prvs=julian=442ad5a4a@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 20 Oct 2006 18:28:42 -0700 Message-ID: <453977CA.8020807@elischer.org> Date: Fri, 20 Oct 2006 18:28:42 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: more on pfil and bridging 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: Sat, 21 Oct 2006 01:28:42 -0000 The more I look at this the more I think that it is broken. Instead of the bridge registering a separate filter queue for itself, it is using the queues set up by the IP stack. It should register its own stack and each filter type should register their own filter functions for that level on the stack. is there a reason that this is not done? If the answer is simply ENOTIME then I will volunteer to go through it and do it properly. suggested changes: I propose to create filter queues for if_ethersubr.c and if_bridge.c distinguished by slightly different keys. I also propose to rename inet_pfil_hook to be inet_pfil_head (or inet_pfil_hooks). I would also look at following the documentation by seeing whether we shouldn't be using a DLT/KEY instead of PFIL_AF and AF_INET as the key type/key. The Direction argument should be expanded to be a generic 'flags' argument where two of the flags are direction. Other flags can be: WAIT_OK: (It's already defined to be there) HOST_ORDER: Fields in the header have been swapped to host order. The ipfw code would supply different entry points for bridge and Ethernet supplied packets. the ipfw args struct should grow a 'flags' field that can indicate (for example) that the IP header fields have not been put in host order (or have) and that the packet is from a bridge rather than just being layer2. ipfw would grow a 'bridge' keyword to check that flag. Julian From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 01:37:43 2006 Return-Path: X-Original-To: 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 6428116A416; Sat, 21 Oct 2006 01:37:43 +0000 (UTC) (envelope-from prvs=julian=442ad5a4a@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id F406D43DAF; Sat, 21 Oct 2006 01:37:12 +0000 (GMT) (envelope-from prvs=julian=442ad5a4a@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 20 Oct 2006 18:37:07 -0700 Message-ID: <453979C2.10606@elischer.org> Date: Fri, 20 Oct 2006 18:37:06 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Max Laier References: <4539546F.6070705@elischer.org> <200610210307.25911.max@love2party.net> In-Reply-To: <200610210307.25911.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, andre@freebsd.org Subject: Re: PFIL hooks etc. 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: Sat, 21 Oct 2006 01:37:43 -0000 Max Laier wrote: > > > Andre has a WIP for this. I'll let him speak. It doesn't appear to be in P4 that I have spotted.. I'll wait to hear from him but now I see how pfil works I can see what needs to be done and can do it if required. From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 01:57:16 2006 Return-Path: X-Original-To: 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 92E2A16A494 for ; Sat, 21 Oct 2006 01:57:16 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE3C043D67 for ; Sat, 21 Oct 2006 01:57:13 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.179.70] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1Gb66l0Yld-0004XP; Sat, 21 Oct 2006 03:57:07 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Sat, 21 Oct 2006 03:58:45 +0200 User-Agent: KMail/1.9.4 References: <453977CA.8020807@elischer.org> In-Reply-To: <453977CA.8020807@elischer.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2503953.XBPBfYAH3M"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200610210358.51403.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Julian Elischer Subject: Re: more on pfil and bridging 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: Sat, 21 Oct 2006 01:57:16 -0000 --nextPart2503953.XBPBfYAH3M Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 21 October 2006 03:28, Julian Elischer wrote: > The more I look at this the more I think that it is broken. > > Instead of the bridge registering a separate filter queue for itself, > it is using the queues set up by the IP stack. > > It should register its own stack and each filter type should > register their own filter functions for that level on the stack. > > is there a reason that this is not done? If the answer is simply > ENOTIME then I will volunteer to go through it and do it properly. I guess so. > suggested changes: > > I propose to create filter queues for if_ethersubr.c and if_bridge.c > distinguished by slightly different keys. I also propose to rename > inet_pfil_hook to be inet_pfil_head (or inet_pfil_hooks). > > I would also look at following the documentation by seeing whether > we shouldn't be using a DLT/KEY instead of PFIL_AF and AF_INET > as the key type/key. I think if_ethersubr.c and if_bridge.c should pass to the same pfil hook. = =20 And I'd vote for the current - very sophisticated - if_bridge.c filtering=20 to stay, at least as opt-in. Otherwise it will be tricky to support=20 stateful filtering in pf on transparent bridges. > The Direction argument should be expanded to be a generic 'flags' > argument where two of the flags are direction. > Other flags can be: > WAIT_OK: (It's already defined to be there) > HOST_ORDER: Fields in the header have been swapped to host order. > > The ipfw code would supply different entry points for bridge > and Ethernet supplied packets. > > the ipfw args struct should grow a 'flags' field that can > indicate (for example) that the IP header fields have not been > put in host order (or have) and that the packet is from a bridge > rather than just being layer2. > > ipfw would grow a 'bridge' keyword to check that flag. I don't think that is necessary. Right now we also have a mode to pass=20 bridged packets as "normal" L2 packets. ipfw doesn't discriminate=20 between packets from if_ethersubr.c and if_bridge.c - and I don't see why=20 it should. If discrimination is required one can still fall back on the=20 L3decap in if_bridge.c - see above. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2503953.XBPBfYAH3M Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFOX7bXyyEoT62BG0RAq4ZAJ9M4R3acqj1oPTUwQ3/KIr9qf1ZfACeINM8 Apx/qC1ZwJHrk+QuNj1fJYI= =dWYb -----END PGP SIGNATURE----- --nextPart2503953.XBPBfYAH3M-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 05:06:38 2006 Return-Path: X-Original-To: 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 10F2716A403 for ; Sat, 21 Oct 2006 05:06:38 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A608E43D4C for ; Sat, 21 Oct 2006 05:06:37 +0000 (GMT) (envelope-from mike@sentex.net) Received: from BLUELAPIS.sentex.ca (cage.simianscience.com [64.7.134.1]) by smarthost2.sentex.ca (8.13.8/8.13.8) with SMTP id k9L56RLB099267; Sat, 21 Oct 2006 01:06:27 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: "Kirill Ponazdyr" Date: Sat, 21 Oct 2006 01:06:35 -0400 Message-ID: References: <2108.192.168.1.6.1161393460.squirrel@www.codeangels.com> In-Reply-To: <2108.192.168.1.6.1161393460.squirrel@www.codeangels.com> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Gigabit performance test 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: Sat, 21 Oct 2006 05:06:38 -0000 On Sat, 21 Oct 2006 03:17:40 +0200 (CEST), in sentex.lists.freebsd.net you wrote: > >dmesg: http://www.codeangels.com/misc/fwtest/first/fw_dmesg.txt >pciconf: http://www.codeangels.com/misc/fwtest/first/fw_pciconf.txt >sysctl: http://www.codeangels.com/misc/fwtest/first/fw_sysctl.txt >kernel: http://www.codeangels.com/misc/fwtest/first/fw_kern.txt Are you using amd64 or i386 kernel ? the config implies you are using i386 > >HZ and Pooling values in those config files have been changed by me = during >test several times as you will see in results table. >The kernels have pf compiled in but it is not turned on at this time. > >The network topo is: = http://www.codeangels.com/misc/fwtest/first/topo.gif >And here are the results: >http://www.codeangels.com/misc/fwtest/first/results.htm > >* Any other ideas on improving performance of this box? I found=20 kern.polling.idle_poll=3D1 to improve performance in polling. Also, try updating the box to 6.2 first as there are quite a few improvements to the em driver You can also fiddle with assigning less to userspace with=20 kern.polling.user_frac=3D30 Don remember for sure, but ipfw seemed to be a bit faster that pf. Also with no firewall loaded there seemed to be quite a bit more throughput... However, that kind of defeats the purpose of a firewall. Also, did you try without polling in the kernel ? The way the updated em driver works should negate the need for kernel polling as well. Also if you dont use INET6 or ipsec, I would remove them from the kernel ---Mike -------------------------------------------------------- Mike Tancsa, Sentex communications http://www.sentex.net Providing Internet Access since 1994 mike@sentex.net, (http://www.tancsa.com) From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 06:48:23 2006 Return-Path: X-Original-To: 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 95C6A16A412 for ; Sat, 21 Oct 2006 06:48:23 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF23443D46 for ; Sat, 21 Oct 2006 06:48:22 +0000 (GMT) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id AAA01737 for ; Sat, 21 Oct 2006 00:48:15 -0600 (MDT) Message-Id: <200610210648.AAA01737@lariat.net> X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 21 Oct 2006 00:47:54 -0600 To: net@freebsd.org From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-516E617 Cc: Subject: Avoiding natd overhead 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: Sat, 21 Oct 2006 06:48:23 -0000 I'm working with a FreeBSD-based router that's using IPFW for policy routing, traffic shaping, and transparent proxying and natd for network address translation. IPFW does these things pretty well (in fact, I don't know if another firewall, like pf, could even do some of these things I'm doing with IPFW), but natd is by far the most CPU-intensive process on the system and is causing it to crumple like a wet towel under heavy loads. How can I replace just the functionality of natd without moving to an entirely new firewall? Can I still select which packets are routed to the NAT engine, and when this occurs during the processing of the packet? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 09:38:41 2006 Return-Path: X-Original-To: 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 4614E16A403 for ; Sat, 21 Oct 2006 09:38:41 +0000 (UTC) (envelope-from baldur@foo.is) Received: from gremlin.foo.is (gremlin.foo.is [194.105.250.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A332443D6B for ; Sat, 21 Oct 2006 09:38:40 +0000 (GMT) (envelope-from baldur@foo.is) Received: from 127.0.0.1 (localhost.foo.is [127.0.0.1]) by injector.foo.is (Postfix) with SMTP id 3C3F8DA8DE; Sat, 21 Oct 2006 09:38:39 +0000 (GMT) Received: by gremlin.foo.is (Postfix, from userid 1000) id 51C1FDA87F; Sat, 21 Oct 2006 09:38:35 +0000 (GMT) Date: Sat, 21 Oct 2006 09:38:35 +0000 From: Baldur Gislason To: Brett Glass Message-ID: <20061021093835.GY804@gremlin.foo.is> References: <200610210648.AAA01737@lariat.net> In-Reply-To: <200610210648.AAA01737@lariat.net> User-Agent: Mutt/1.4.2.1i X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on gremlin.foo.is X-Spam-Level: X-Spam-Status: No, score=-5.9 required=6.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Sanitizer: Foo MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Cc: net@freebsd.org Subject: Re: Avoiding natd overhead 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: Sat, 21 Oct 2006 09:38:41 -0000 In that situation I have used IPFW for filtering and IPF for doing NAT. But NAT is in it's nature a very processor and memory intensive process, I wouldn't recommend to anyone to run NAT if they have more than 10Mb bandwidth and more than 100 nodes on their network. Baldur On Sat, Oct 21, 2006 at 12:47:54AM -0600, Brett Glass wrote: > I'm working with a FreeBSD-based router that's using IPFW for > policy routing, traffic shaping, and transparent proxying and natd > for network address translation. IPFW does these things pretty well > (in fact, I don't know if another firewall, like pf, could even do > some of these things I'm doing with IPFW), but natd is by far the > most CPU-intensive process on the system and is causing it to > crumple like a wet towel under heavy loads. How can I replace just > the functionality of natd without moving to an entirely new > firewall? Can I still select which packets are routed to the NAT > engine, and when this occurs during the processing of the packet? > > --Brett Glass > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 09:54:58 2006 Return-Path: X-Original-To: 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 60E4416A403 for ; Sat, 21 Oct 2006 09:54:58 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E681B43D6A for ; Sat, 21 Oct 2006 09:54:57 +0000 (GMT) (envelope-from vova@sw.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GbDZ8-0000fy-Cd; Sat, 21 Oct 2006 13:54:54 +0400 From: Vladimir Grebenschikov To: Brett Glass In-Reply-To: <200610210648.AAA01737@lariat.net> References: <200610210648.AAA01737@lariat.net> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Sat, 21 Oct 2006 13:54:53 +0400 Message-Id: <1161424493.1489.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: net@freebsd.org Subject: Re: Avoiding natd overhead X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2006 09:54:58 -0000 =F7 =D3=C2, 21/10/2006 =D7 00:47 -0600, Brett Glass =D0=C9=DB=C5=D4: > I'm working with a FreeBSD-based router that's using IPFW for=20 > policy routing, traffic shaping, and transparent proxying and natd=20 > for network address translation. IPFW does these things pretty well=20 > (in fact, I don't know if another firewall, like pf, could even do=20 > some of these things I'm doing with IPFW), but natd is by far the=20 > most CPU-intensive process on the system and is causing it to=20 > crumple like a wet towel under heavy loads. How can I replace just=20 > the functionality of natd without moving to an entirely new=20 > firewall? Can I still select which packets are routed to the NAT=20 > engine, and when this occurs during the processing of the packet? Problem is in location of natd functionality. So, every packet which goes through nat should jump from kernel to user-space and back. It is really takes a lot of resources. Solutions: 1. use PF for nat - it does aliasing in kernel space 2. use in-kernel libalias implementation=20 (I guess man-page for ng_nat(4) will help) > --Brett Glass >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 09:58:11 2006 Return-Path: X-Original-To: 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 83BC716A403; Sat, 21 Oct 2006 09:58:11 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from optimus.centralmiss.com (ns.centralmiss.com [206.156.254.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3D9143D70; Sat, 21 Oct 2006 09:58:10 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by optimus.centralmiss.com (Postfix) with ESMTP id 6A8792842F; Sat, 21 Oct 2006 04:58:09 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id D865661C52; Sat, 21 Oct 2006 04:58:08 -0500 (CDT) Date: Sat, 21 Oct 2006 04:58:08 -0500 From: "Matthew D. Fuller" To: Brett Glass Message-ID: <20061021095808.GH75501@over-yonder.net> References: <200610210648.AAA01737@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610210648.AAA01737@lariat.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.3 Cc: piso@freebsd.org, net@freebsd.org Subject: Re: Avoiding natd overhead 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: Sat, 21 Oct 2006 09:58:11 -0000 On Sat, Oct 21, 2006 at 12:47:54AM -0600 I heard the voice of Brett Glass, and lo! it spake thus: > > How can I replace just the functionality of natd without moving to > an entirely new firewall? Can I still select which packets are > routed to the NAT engine, and when this occurs during the processing > of the packet? Paolo Pisati's 2005 SoC work on integrating libalias into ipfw might fit here. It should move the NAT'ing into the kernel and save all the context switches and copies, and (what has me more interested) make it much easier to change port forwarding and other rules. The worst thing about natd for me isn't performance, it's that I have to blow away all the state to change anything. I think some of the support has been brought in, at least to -CURRENT, but I'm not sure, and I'm pretty sure it isn't in RELENG_6 or earlier. Paolo? -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 10:50:44 2006 Return-Path: X-Original-To: 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 46A4516A407 for ; Sat, 21 Oct 2006 10:50:44 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail.classis.ru (classis.ru [213.248.60.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAA5443D45 for ; Sat, 21 Oct 2006 10:50:43 +0000 (GMT) (envelope-from citrin@citrin.ru) Received: from [192.168.1.34] (ppp85-141-212-17.pppoe.mtu-net.ru [85.141.212.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: citrin.citrin.ru) by mail.classis.ru (Postfix) with ESMTP id 714D81229EE7 for ; Sat, 21 Oct 2006 14:50:41 +0400 (MSD) Date: Sat, 21 Oct 2006 14:50:31 +0400 From: Anton Yuzhaninov X-Mailer: The Bat! (v3.62.14) Professional Organization: Rambler X-Priority: 3 (Normal) Message-ID: <1238798379.20061021145031@citrin.ru> To: "Matthew D. Fuller" In-Reply-To: <20061021095808.GH75501@over-yonder.net> References: <200610210648.AAA01737@lariat.net> <20061021095808.GH75501@over-yonder.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="----------C412E16C1FFDF27" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re[2]: Avoiding natd overhead 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: Sat, 21 Oct 2006 10:50:44 -0000 This is a cryptographically signed message in MIME format. ------------C412E16C1FFDF27 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Saturday, October 21, 2006, 1:58:08 PM, Matthew D. Fuller wrote: MDF> On Sat, Oct 21, 2006 at 12:47:54AM -0600 I heard the voice of MDF> Brett Glass, and lo! it spake thus: >> >> How can I replace just the functionality of natd without moving to >> an entirely new firewall? Can I still select which packets are >> routed to the NAT engine, and when this occurs during the processing >> of the packet? MDF> Paolo Pisati's 2005 SoC work on integrating libalias into ipfw might MDF> fit here. It should move the NAT'ing into the kernel and save all the MDF> context switches and copies, and (what has me more interested) make it MDF> much easier to change port forwarding and other rules. The worst MDF> thing about natd for me isn't performance, it's that I have to blow MDF> away all the state to change anything. libalis still have big overhead comparing to ipnat: 1. libalias allocate memory for create each new entry in NAT table. libalias use linear search in linked list to find entry in table. It very slow when you have thousands simultaneous connections via nat 2. ipnat allocate all memory at startup. It better. ipnat uses hash table to fine entry in nat table - it mach faster in heavy loaded case. An next. As I can se libalias not limit maximum size of used memory. When users generate many simultaneous connections (e. g. worm or net scan), libalias may exhaust all kernel memory and so trigger panic. --=20 WBR, Anton Yuzhaninov ------------C412E16C1FFDF27-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 13:29:32 2006 Return-Path: X-Original-To: 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 4EA2A16A407 for ; Sat, 21 Oct 2006 13:29:32 +0000 (UTC) (envelope-from chrishome@austin.rr.com) Received: from ms-smtp-02.texas.rr.com (ms-smtp-02.texas.rr.com [24.93.47.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD8BA43D5D for ; Sat, 21 Oct 2006 13:29:30 +0000 (GMT) (envelope-from chrishome@austin.rr.com) Received: from [10.200.0.85] (cpe-72-177-39-197.austin.res.rr.com [72.177.39.197]) by ms-smtp-02.texas.rr.com (8.13.6/8.13.6) with ESMTP id k9LDTSTJ026088; Sat, 21 Oct 2006 08:29:29 -0500 (CDT) X-Nat-Received: 10.200.0.85 Message-ID: <453A20B5.9010108@austin.rr.com> Date: Sat, 21 Oct 2006 08:29:25 -0500 From: Chris Bowman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brett Glass References: <200610210648.AAA01737@lariat.net> In-Reply-To: <200610210648.AAA01737@lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: net@freebsd.org Subject: Re: Avoiding natd overhead 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: Sat, 21 Oct 2006 13:29:32 -0000 I see this question come up now and then on the lists, so, I'll share what I've learned about natd and performance! First, if your running natd on a processor which supports more functions than just a standard 386, ie a Pentium, Athlon, etc. Then I've found compiling natd with make flags for that processor, and with O3 optimizations will make your jaw drop in comparison to the default installed version of natd. You can find if you have the sources downloaded for FreeBSD the natd source in /usr/src/sbin/natd , just recompile natd itself, or when you re-build world for your system, make sure you have make flags set in make.conf so everything will rebuild with optimized flags, however I don't recomend O3 at all for a build world, will almost definately break something, for natd itself, it works fine. That's about it! Very simple, but I think it's often overlooked, and of course there are a few variables with NAT and performance, number of hosts, number of connections each host is using simulataneously (Torrents *cough). You don't want to overload NATd itself, 65535 TCP, UDP ports, keep that in mind. If your doing nat for a large number of hosts, break down your ip range into sections and run natd multiple times to help balance the load. Thanks! Chris Bowman Brett Glass wrote: > I'm working with a FreeBSD-based router that's using IPFW for policy > routing, traffic shaping, and transparent proxying and natd for > network address translation. IPFW does these things pretty well (in > fact, I don't know if another firewall, like pf, could even do some of > these things I'm doing with IPFW), but natd is by far the most > CPU-intensive process on the system and is causing it to crumple like > a wet towel under heavy loads. How can I replace just the > functionality of natd without moving to an entirely new firewall? Can > I still select which packets are routed to the NAT engine, and when > this occurs during the processing of the packet? > > --Brett Glass > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 13:38:27 2006 Return-Path: X-Original-To: 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 9B96616A403 for ; Sat, 21 Oct 2006 13:38:27 +0000 (UTC) (envelope-from daiyon.fbsd@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id E949E43D4C for ; Sat, 21 Oct 2006 13:38:26 +0000 (GMT) (envelope-from daiyon.fbsd@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so1754172nfc for ; Sat, 21 Oct 2006 06:38:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=McrkLZroE8LLKWafVJaFTj5d6PpKxH04x0vCroPLkOuRMTzlZGCr/Nrr15k3cIXxzl5zKwQN32xLp2ZEWbCQJE+fqx63YJYjCx4ilFv86eu+zG+p8+Akys6n3mOvCtdfU0tA+5+h9a4c8trnml3XE0KGCmxU1Q4XzGztZZ0msfs= Received: by 10.78.178.5 with SMTP id a5mr3854291huf; Sat, 21 Oct 2006 06:38:25 -0700 (PDT) Received: by 10.78.139.13 with HTTP; Sat, 21 Oct 2006 06:38:25 -0700 (PDT) Message-ID: Date: Sat, 21 Oct 2006 08:38:25 -0500 From: "Chris Bowman" To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Avoiding natd overhead 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: Sat, 21 Oct 2006 13:38:27 -0000 I see this question come up now and then on the lists, so, I'll share what I've learned about natd and performance! First, if your running natd on a processor which supports more functions than just a standard 386, ie a Pentium, Athlon, etc. Then I've found compiling natd with make flags for that processor, and with O3 optimizations will make your jaw drop in comparison to the default installed version of natd. You can find if you have the sources downloaded for FreeBSD the natd source in /usr/src/sbin/natd , just recompile natd itself, copy the new binary you compile to wherever your current natd binary is installed, /sbin/natd likely. just recompile natd itself, or when you re-build world for your system, make sure you have make flags set in make.conf so everything will rebuild with optimized flags, however I don't recomend O3 at all for a build world, will almost definately break something, for natd itself, it works fine. Just to note, make sure if you only recompile natd itself, and don't rebuild world, that you download sources for the version which you are currently running, nothing newer. That's about it! Very simple, but I think it's often overlooked, and of course there are a few variables with NAT and performance, number of hosts, number of connections each host is using simulataneously (Torrents *cough). You don't want to overload NATd itself, 65535 TCP, UDP ports, keep that in mind. If your doing nat for a large number of hosts, break down your ip range into sections and run natd multiple times to help balance the load. Thanks! Chris Bowman From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 13:41:06 2006 Return-Path: X-Original-To: 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 A6E0E16A40F for ; Sat, 21 Oct 2006 13:41:06 +0000 (UTC) (envelope-from spadge@fromley.net) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFC1243D45 for ; Sat, 21 Oct 2006 13:41:04 +0000 (GMT) (envelope-from spadge@fromley.net) Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20061021134103.HXNG1865.mtaout03-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Sat, 21 Oct 2006 14:41:03 +0100 Received: from tobermory.home ([86.0.166.176]) by aamtaout02-winn.ispmail.ntl.com with ESMTP id <20061021134103.VBNY23938.aamtaout02-winn.ispmail.ntl.com@tobermory.home>; Sat, 21 Oct 2006 14:41:03 +0100 Received: from [192.168.124.185] (jupiter.home [192.168.124.185]) by tobermory.home (Postfix) with ESMTP id AA604A713D; Sat, 21 Oct 2006 14:41:00 +0100 (BST) Message-ID: <453A236E.1000205@fromley.net> Date: Sat, 21 Oct 2006 14:41:02 +0100 From: Spadge User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Chris Bowman References: <200610210648.AAA01737@lariat.net> <453A20B5.9010108@austin.rr.com> In-Reply-To: <453A20B5.9010108@austin.rr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brett Glass , net@freebsd.org Subject: Re: Avoiding natd overhead 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: Sat, 21 Oct 2006 13:41:06 -0000 Chris Bowman wrote: > I see this question come up now and then on the lists, so, I'll share > what I've learned about natd and performance! First, if your running > natd on a processor which supports more functions than just a standard > 386, ie a Pentium, Athlon, etc. Then I've found compiling natd with > make flags for that processor, and with O3 optimizations will make your > jaw drop in comparison to the default installed version of natd. You > can find if you have the sources downloaded for FreeBSD the natd source > in /usr/src/sbin/natd , just recompile natd itself, or when you re-build > world for your system, make sure you have make flags set in make.conf so > everything will rebuild with optimized flags, however I don't recomend > O3 at all for a build world, will almost definately break something, for > natd itself, it works fine. This is pretty interesting stuff, and something I'm going to have to look into. Could I be incredibly presumptious and ask you for some more info to get me started on my way? Where would I start looking for info on what make flags are available for natd and my CPUs? I'm not seeing anything helpful in the README and my Makefile is very short. Thanks for any help. -- Spadge "Intoccabile" www.fromley.com From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 14:06:19 2006 Return-Path: X-Original-To: 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 1A7E616A403 for ; Sat, 21 Oct 2006 14:06:19 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84C4043D45 for ; Sat, 21 Oct 2006 14:06:18 +0000 (GMT) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan [127.0.0.1]) by aldan.algebra.com (8.13.8/8.13.7) with ESMTP id k9LE6H3H035712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Oct 2006 10:06:17 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by aldan.algebra.com (8.13.8/8.13.7/Submit) id k9LE6HqF035711; Sat, 21 Oct 2006 10:06:17 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) From: Mikhail Teterin To: net@freebsd.org Date: Sat, 21 Oct 2006 10:06:16 -0400 User-Agent: KMail/1.9.1 X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" Cc: freebsdnic@mailbox.cps.intel.com Subject: 6.2 becomes unresponsive under high traffic 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: Sat, 21 Oct 2006 14:06:19 -0000 Hello! The system is a dual Opteron 244 running today's FreeBSD-6.2/amd64. em-interface connects it to the switch (in gigabit mode). When I direct 2 database dumps at the machine in parallel (the arriving data is getting compressed and written to local disk), the "system" component of the load (as reported by systat and top) goes up to 99-100% and stays there for many minutes at a time. Accessing the box via console remains speedy, but remote connections stall for minutes during which the box is not even pingable... What appears to wake it up, though, is hitting a (local) keyboard button... Switching em0 to polling mode did not help... "netstat -m" does not show any rejections of buffer requests. It uses the BSD4-scheduler, as is the default. Earlier, in the single-CPU configuration, the box had no problems dealing with such 2 data streams for hours, backing up all our databases. We added another processor and updated the world/kernel from 6.1 to 6.2, hoping to halve the dump times -- and it is barely crowling now... Please, advise. Thanks! -mi From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 14:10:40 2006 Return-Path: X-Original-To: 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 C145416A494 for ; Sat, 21 Oct 2006 14:10:40 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id B07A343DBA for ; Sat, 21 Oct 2006 14:10:17 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 26351 invoked from network); 21 Oct 2006 14:10:15 -0000 Received: from unknown (HELO localhost) (775067@[217.50.142.179]) (envelope-sender ) by smtprelay04.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 21 Oct 2006 14:10:15 -0000 Date: Sat, 21 Oct 2006 16:09:57 +0200 From: Fabian Keil To: freebsd-net@freebsd.org Message-ID: <20061021160957.13cceaeb@localhost> In-Reply-To: <453A20B5.9010108@austin.rr.com> References: <200610210648.AAA01737@lariat.net> <453A20B5.9010108@austin.rr.com> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.10.6; i386-portbld-freebsd6.2) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_ilQuS=KB0VqxiwlYuoXMJ/k"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: Re: Avoiding natd overhead 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: Sat, 21 Oct 2006 14:10:40 -0000 --Sig_ilQuS=KB0VqxiwlYuoXMJ/k Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Chris Bowman wrote: > I see this question come up now and then on the lists, so, I'll share=20 > what I've learned about natd and performance! First, if your running=20 > natd on a processor which supports more functions than just a standard=20 > 386, ie a Pentium, Athlon, etc. Then I've found compiling natd with=20 > make flags for that processor, and with O3 optimizations will make your=20 > jaw drop in comparison to the default installed version of natd. I've learned that if you care about NAT overhead you just don't use natd. I run two jailed Tor nodes on a Intel Celeron 2.40GHz. With PF disabled and NAT done with natd, natd uses something between 20 and 30% of the cpu time. With PF (filtering, NAT, queueing) enabled I don't see a measurable increase of cpu usage at all. I haven't tried recompiling natd with customized flags, but I doubt that it helps enough to overlook the context switch penalty. Fabian --=20 http://www.fabiankeil.de/ --Sig_ilQuS=KB0VqxiwlYuoXMJ/k Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFOio/BYqIVf93VJ0RAoikAJ0Qdswoo2ahiZ57vmKJHp8frZn+YgCeM/gI StNziirBpJ2IBA2/VSE/Oxg= =QLgn -----END PGP SIGNATURE----- --Sig_ilQuS=KB0VqxiwlYuoXMJ/k-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 14:24:12 2006 Return-Path: X-Original-To: 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 75E3816A4B3 for ; Sat, 21 Oct 2006 14:24:12 +0000 (UTC) (envelope-from chrishome@austin.rr.com) Received: from ms-smtp-01.texas.rr.com (ms-smtp-01.texas.rr.com [24.93.47.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94CE643D94 for ; Sat, 21 Oct 2006 14:23:57 +0000 (GMT) (envelope-from chrishome@austin.rr.com) Received: from [10.200.0.87] (cpe-72-177-39-197.austin.res.rr.com [72.177.39.197]) by ms-smtp-01.texas.rr.com (8.13.6/8.13.6) with ESMTP id k9LENsHW005383; Sat, 21 Oct 2006 09:23:55 -0500 (CDT) X-Nat-Received: 10.200.0.87 From: Chris Bowman To: Spadge In-Reply-To: <453A236E.1000205@fromley.net> References: <200610210648.AAA01737@lariat.net> <453A20B5.9010108@austin.rr.com> <453A236E.1000205@fromley.net> Content-Type: text/plain Organization: Home Date: Sat, 21 Oct 2006 09:23:53 -0500 Message-Id: <1161440633.20944.31.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: Brett Glass , net@freebsd.org Subject: Re: Avoiding natd overhead X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chrishome@austin.rr.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2006 14:24:12 -0000 First, sorry for the double post, received a message saying the first one was rejected by a spam filter, however I now see it's on the list! ;) Of course you may ask for more help! First, take advantage of what's out there, people have written some absolutely great documentation, including the FreeBSD handbook, a reference which I have out near 24/7. Specifically for the problem at hand though, read up on the following : FreeBSD Handbook chapter 21, man make.conf , man make , and http://pages.silverwraith.com/papers/6/ . If you have the correct sources synced, refer to chapter 21 in the handbook again if not sure. Then take the following out for a test drive. cd /usr/src/sbin/natd make -DCPUTYPE=pentium4 <== I happen to have a p4, insert your correct cpu type. Now, make a backup of your existing natd binary, cp /usr/sbin/natd to the location of your choice maybe /home/username/ from /usr/src/sbin/natd now type make install do a ls -lah /usr/sbin/natd you should see a new natd binary with the date / time you compiled it, ie recent. Restart natd, or start it if it's not, and see how it goes! If something goes wrong, you can always copy your backup to /sbin/natd . This should get you started, theres some more optimizing you can do, but I figure start here without adding to many variables to the mix. And just adding the CPU type to the make flags as shown above, seems to be the single largest factor in making natd run as you would expect. Thanks! Chris Bowman On Sat, 2006-10-21 at 14:41 +0100, Spadge wrote: > Chris Bowman wrote: > > I see this question come up now and then > on the lists, so, I'll share > > what I've learned about natd and performance! First, if your running > > natd on a processor which supports more functions than just a standard > > 386, ie a Pentium, Athlon, etc. Then I've found compiling natd with > > make flags for that processor, and with O3 optimizations will make your > > jaw drop in comparison to the default installed version of natd. You > > can find if you have the sources downloaded for FreeBSD the natd source > > in /usr/src/sbin/natd , just recompile natd itself, or when you re-build > > world for your system, make sure you have make flags set in make.conf so > > everything will rebuild with optimized flags, however I don't recomend > > O3 at all for a build world, will almost definately break something, for > > natd itself, it works fine. > > This is pretty interesting stuff, and something I'm going to have to > look into. > > Could I be incredibly presumptious and ask you for some more info to get > me started on my way? > > Where would I start looking for info on what make flags are available > for natd and my CPUs? I'm not seeing anything helpful in the README and > my Makefile is very short. > > Thanks for any help. > > From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 14:24:30 2006 Return-Path: X-Original-To: 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 3122716A518 for ; Sat, 21 Oct 2006 14:24:30 +0000 (UTC) (envelope-from net@dino.sk) Received: from bsd.dino.sk (bsd.dino.sk [213.215.72.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0E8843D4C for ; Sat, 21 Oct 2006 14:24:26 +0000 (GMT) (envelope-from net@dino.sk) Received: from [192.168.16.241] (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by bsd.dino.sk with esmtp; Sat, 21 Oct 2006 16:26:50 +0200 id 000000FB.453A2E2A.0000CD52 From: Milan Obuch To: freebsd-net@freebsd.org Date: Sat, 21 Oct 2006 16:18:10 +0200 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610211618.11472.net@dino.sk> Subject: Somewhat weird net behavior 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: Sat, 21 Oct 2006 14:24:30 -0000 Hi, I am seeing something strange on couple of our routers. All are WRAP based on 6.1-RELEASE-p6, easiest description is: # ping PING : 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available ^C --- ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss # ifconfig sis0 up # ping PING : 56 data bytes 64 bytes from : icmp_seq=0 ttl=64 time=2.310 ms ^C --- ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.310/2.310/2.310/0.000 ms I know this is really minimum information here, but I need just an idea what to look for. It is strange for me - is it some memory leak? How could it be cleared with simple ifconfig up? Did anyone seen something similar? Regards, Milan -- This address is used only for mailing list response. Do not send any personal messages to it. From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 14:31:28 2006 Return-Path: X-Original-To: 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 3367C16A412 for ; Sat, 21 Oct 2006 14:31:28 +0000 (UTC) (envelope-from chris@korcett.com) Received: from smtpout08-04.prod.mesa1.secureserver.net (smtpout08-04.prod.mesa1.secureserver.net [64.202.165.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 098AB43D77 for ; Sat, 21 Oct 2006 14:31:22 +0000 (GMT) (envelope-from chris@korcett.com) Received: (qmail 20612 invoked from network); 21 Oct 2006 14:31:22 -0000 Received: from unknown (72.177.39.197) by smtpout08-04.prod.mesa1.secureserver.net (64.202.165.12) with ESMTP; 21 Oct 2006 14:31:21 -0000 From: Chris Bowman To: Spadge In-Reply-To: <1161440633.20944.31.camel@localhost> References: <200610210648.AAA01737@lariat.net> <453A20B5.9010108@austin.rr.com> <453A236E.1000205@fromley.net> <1161440633.20944.31.camel@localhost> Content-Type: text/plain Organization: KHI Date: Sat, 21 Oct 2006 09:31:20 -0500 Message-Id: <1161441080.20944.34.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit Cc: Brett Glass , net@freebsd.org Subject: Re: Avoiding natd overhead X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chris@korcett.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2006 14:31:28 -0000 Correction! I apologize, only noticed after I sent, obviously. Anywhere I typed /usr/sbin please replace with /sbin only in this case..Sorry ;) Namely where I said /usr/sbin/natd should be /sbin/natd ... On Sat, 2006-10-21 at 09:23 -0500, Chris Bowman wrote: > First, sorry for the double post, received a message saying the first > one was rejected by a spam filter, however I now see it's on the > list! ;) > > Of course you may ask for more help! First, take advantage of what's > out there, people have written some absolutely great documentation, > including the FreeBSD handbook, a reference which I have out near 24/7. > Specifically for the problem at hand though, read up on the following : > FreeBSD Handbook chapter 21, man make.conf , man make , and > http://pages.silverwraith.com/papers/6/ . > > If you have the correct sources synced, refer to chapter 21 in the > handbook again if not sure. Then take the following out for a test > drive. > > cd /usr/src/sbin/natd > > make -DCPUTYPE=pentium4 <== I happen to have a p4, insert your correct > cpu type. > > Now, make a backup of your existing natd binary, cp /usr/sbin/natd to > the location of your choice maybe /home/username/ > > from /usr/src/sbin/natd now type make install > > do a ls -lah /usr/sbin/natd you should see a new natd binary with the > date / time you compiled it, ie recent. > > Restart natd, or start it if it's not, and see how it goes! > > If something goes wrong, you can always copy your backup > to /sbin/natd . > > > This should get you started, theres some more optimizing you can do, but > I figure start here without adding to many variables to the mix. And > just adding the CPU type to the make flags as shown above, seems to be > the single largest factor in making natd run as you would expect. > > Thanks! > > Chris Bowman > > > > > > > > On Sat, 2006-10-21 at 14:41 +0100, Spadge wrote: > > Chris Bowman wrote: > > > I see this question come up now and then > > on the lists, so, I'll share > > > what I've learned about natd and performance! First, if your running > > > natd on a processor which supports more functions than just a standard > > > 386, ie a Pentium, Athlon, etc. Then I've found compiling natd with > > > make flags for that processor, and with O3 optimizations will make your > > > jaw drop in comparison to the default installed version of natd. You > > > can find if you have the sources downloaded for FreeBSD the natd source > > > in /usr/src/sbin/natd , just recompile natd itself, or when you re-build > > > world for your system, make sure you have make flags set in make.conf so > > > everything will rebuild with optimized flags, however I don't recomend > > > O3 at all for a build world, will almost definately break something, for > > > natd itself, it works fine. > > > > This is pretty interesting stuff, and something I'm going to have to > > look into. > > > > Could I be incredibly presumptious and ask you for some more info to get > > me started on my way? > > > > Where would I start looking for info on what make flags are available > > for natd and my CPUs? I'm not seeing anything helpful in the README and > > my Makefile is very short. > > > > Thanks for any help. > > > > -- Chris Bowman Vice President of Engineering O: 512-419-7419 x202 C: 512-417-6273 F: 512-419-7680 AIM: RRTXChris chris@korcett.com www.korcett.com From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 14:42:33 2006 Return-Path: X-Original-To: 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 8B4C616A415 for ; Sat, 21 Oct 2006 14:42:33 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6F7C43D76 for ; Sat, 21 Oct 2006 14:42:27 +0000 (GMT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id k9LEgFef019095; Sat, 21 Oct 2006 22:42:15 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id k9LEgFKd019093; Sat, 21 Oct 2006 22:42:15 +0800 (KRAST) (envelope-from eugen) Date: Sat, 21 Oct 2006 22:42:15 +0800 From: Eugene Grosbein To: Anton Yuzhaninov Message-ID: <20061021144215.GA14654@svzserv.kemerovo.su> References: <200610210648.AAA01737@lariat.net> <20061021095808.GH75501@over-yonder.net> <1238798379.20061021145031@citrin.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1238798379.20061021145031@citrin.ru> User-Agent: Mutt/1.4.2.1i Cc: "Matthew D. Fuller" Subject: Re: Avoiding natd overhead 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: Sat, 21 Oct 2006 14:42:33 -0000 On Sat, Oct 21, 2006 at 02:50:31PM +0400, Anton Yuzhaninov wrote: > 1. libalias allocate memory for create each new entry in NAT table. > libalias use linear search in linked list to find entry in table. > It very slow when you have thousands simultaneous connections via > nat In RELENG_4 libalias uses hash table, not linear search. Are you sure it switched to linear search? And why? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 15:01:00 2006 Return-Path: X-Original-To: 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 E58ED16A407 for ; Sat, 21 Oct 2006 15:01:00 +0000 (UTC) (envelope-from spadge@fromley.net) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA27843D49 for ; Sat, 21 Oct 2006 15:00:58 +0000 (GMT) (envelope-from spadge@fromley.net) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20061021150057.JNRX1865.mtaout03-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Sat, 21 Oct 2006 16:00:57 +0100 Received: from tobermory.home ([86.0.166.176]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20061021150057.ZIOH644.aamtaout01-winn.ispmail.ntl.com@tobermory.home>; Sat, 21 Oct 2006 16:00:57 +0100 Received: from [192.168.124.185] (jupiter.home [192.168.124.185]) by tobermory.home (Postfix) with ESMTP id A6EF7A6C5D; Sat, 21 Oct 2006 16:00:55 +0100 (BST) Message-ID: <453A3629.3020609@fromley.net> Date: Sat, 21 Oct 2006 16:00:57 +0100 From: Spadge User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: chris@korcett.com References: <200610210648.AAA01737@lariat.net> <453A20B5.9010108@austin.rr.com> <453A236E.1000205@fromley.net> <1161440633.20944.31.camel@localhost> <1161441080.20944.34.camel@localhost> In-Reply-To: <1161441080.20944.34.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brett Glass , net@freebsd.org Subject: Re: Avoiding natd overhead 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: Sat, 21 Oct 2006 15:01:01 -0000 Chris Bowman wrote: > Correction! I apologize, only noticed after I sent, obviously. Anywhere > I typed /usr/sbin please replace with /sbin only in this case..Sorry ;) > Namely where I said /usr/sbin/natd should be /sbin/natd ... Fantastic, this seems to have not hurt any ;) Thanks for the info. New P3 natd now up and running. It may be worth mentioning that if you're the kind of person who patches fbsd fairly regularly, and rebuilds world when that happens, starting off with a 'make clean' in /usr/src/sbin/natd' may be called for. As for the other optimisations, I'm not a rabid OS ricer so I don't know if spending hours for that last 1% performance increase is really worth my while. A little streamlining goes a long way. Again, thanks for the info on natd. -- Spadge "Intoccabile" www.fromley.com From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 15:28:01 2006 Return-Path: X-Original-To: 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 9F62E16A47E for ; Sat, 21 Oct 2006 15:28:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57C9243D55 for ; Sat, 21 Oct 2006 15:28:01 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id CABD646CB8; Sat, 21 Oct 2006 11:28:00 -0400 (EDT) Date: Sat, 21 Oct 2006 16:28:00 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Milan Obuch In-Reply-To: <200610211618.11472.net@dino.sk> Message-ID: <20061021162630.I2879@fledge.watson.org> References: <200610211618.11472.net@dino.sk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Somewhat weird net behavior 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: Sat, 21 Oct 2006 15:28:01 -0000 On Sat, 21 Oct 2006, Milan Obuch wrote: > I know this is really minimum information here, but I need just an idea what > to look for. It is strange for me - is it some memory leak? How could it be > cleared with simple ifconfig up? Did anyone seen something similar? It is pretty minimal information :-). ifconfig down / up will cause the device driver to be reset, the link to be re-negotiated, etc. The buffer full error from ping means that the outbound interface queue has filled, and if the error doesn't go away, it means it's likely wedged (no longer being processed). This could reflect a bug in the device driver, a problem with the switch, etc. In the "wedged" state, what does ifconfig report about link negotiation? When you reset the interface, does the negotiated link type change? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 15:39:13 2006 Return-Path: X-Original-To: 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 6155616A416 for ; Sat, 21 Oct 2006 15:39:13 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D14143D58 for ; Sat, 21 Oct 2006 15:39:13 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id AEBB81A3C1A; Sat, 21 Oct 2006 08:39:12 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 998C5515B7; Sat, 21 Oct 2006 11:39:09 -0400 (EDT) Date: Sat, 21 Oct 2006 11:39:09 -0400 From: Kris Kennaway To: Mikhail Teterin Message-ID: <20061021153909.GA8705@xor.obsecurity.org> References: <200610211006.17003@aldan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <200610211006.17003@aldan> User-Agent: Mutt/1.4.2.2i Cc: freebsdnic@mailbox.cps.intel.com, net@freebsd.org Subject: Re: 6.2 becomes unresponsive under high traffic 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: Sat, 21 Oct 2006 15:39:13 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 21, 2006 at 10:06:16AM -0400, Mikhail Teterin wrote: > Hello! >=20 > The system is a dual Opteron 244 running today's FreeBSD-6.2/amd64. >=20 > em-interface connects it to the switch (in gigabit mode). >=20 > When I direct 2 database dumps at the machine in parallel (the arriving d= ata=20 > is getting compressed and written to local disk), the "system" component = of=20 > the load (as reported by systat and top) goes up to 99-100% and stays the= re=20 > for many minutes at a time. Accessing the box via console remains speedy,= but=20 > remote connections stall for minutes during which the box is not even=20 > pingable... >=20 > What appears to wake it up, though, is hitting a (local) keyboard button.= .. >=20 > Switching em0 to polling mode did not help... >=20 > "netstat -m" does not show any rejections of buffer requests. >=20 > It uses the BSD4-scheduler, as is the default. >=20 > Earlier, in the single-CPU configuration, the box had no problems dealing= with=20 > such 2 data streams for hours, backing up all our databases. We added ano= ther=20 > processor and updated the world/kernel from 6.1 to 6.2, hoping to halve t= he=20 > dump times -- and it is barely crowling now... >=20 > Please, advise. Thanks! We've been discussing em issues for several weeks now, so it would be great if you could get yourself up to speed - please review the discussion on freebsd-stable and freebsd-net (start with posts by Scott Long, myself, and Jack Vogel). Kris --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFOj8cWry0BWjoQKURAt3BAJsEYU85MxxY/lz0urv/nNxUQCbjfgCfbwBo MS/kE/O/KWLBx7R+7+d0lcg= =jSAM -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 16:37:12 2006 Return-Path: X-Original-To: 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 87F3716A407 for ; Sat, 21 Oct 2006 16:37:12 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFDBB43D70 for ; Sat, 21 Oct 2006 16:37:11 +0000 (GMT) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan [127.0.0.1]) by aldan.algebra.com (8.13.8/8.13.7) with ESMTP id k9LGbAO9036285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Oct 2006 12:37:10 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by aldan.algebra.com (8.13.8/8.13.7/Submit) id k9LGbAvk036284; Sat, 21 Oct 2006 12:37:10 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) From: Mikhail Teterin To: Kris Kennaway Date: Sat, 21 Oct 2006 12:37:09 -0400 User-Agent: KMail/1.9.1 References: <200610211006.17003@aldan> <20061021153909.GA8705@xor.obsecurity.org> In-Reply-To: <20061021153909.GA8705@xor.obsecurity.org> X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" Cc: freebsdnic@mailbox.cps.intel.com, net@freebsd.org Subject: Re: 6.2 becomes unresponsive under high traffic 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: Sat, 21 Oct 2006 16:37:12 -0000 On Saturday 21 October 2006 11:39, Kris Kennaway wrote: = We've been discussing em issues for several weeks now, so it would be = great if you could get yourself up to speed - please review the = discussion on freebsd-stable and freebsd-net (start with posts by = Scott Long, myself, and Jack Vogel). Thanks for the pointer. Ok, so it would appear, from Bruce's http://docs.freebsd.org/cgi/mid.cgi?20061019110950.X75878 that in the SMP case, the em-driver is not even currently supposed to work with INTR_FAST, which, apparently, is the default... How do I switch to INTR_MPSAFE? Scott states, that it is much slower, than FAST, but I can only compress the data at about 25-30 Mb/s anyway... This close to 6.2-RELEASE, should not MPSAFE be forced by the SMP (with em(4) stating as much)? Thanks! -mi From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 16:58:47 2006 Return-Path: X-Original-To: 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 3F4B116A407 for ; Sat, 21 Oct 2006 16:58:47 +0000 (UTC) (envelope-from net@dino.sk) Received: from bsd.dino.sk (bsd.dino.sk [213.215.72.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53FA043D64 for ; Sat, 21 Oct 2006 16:58:45 +0000 (GMT) (envelope-from net@dino.sk) Received: from [192.168.16.241] (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by bsd.dino.sk with esmtp; Sat, 21 Oct 2006 19:07:12 +0200 id 00000030.453A53C0.0000CFF7 From: Milan Obuch To: freebsd-net@freebsd.org Date: Sat, 21 Oct 2006 18:58:29 +0200 User-Agent: KMail/1.9.4 References: <200610211618.11472.net@dino.sk> <20061021162630.I2879@fledge.watson.org> In-Reply-To: <20061021162630.I2879@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610211858.30338.net@dino.sk> Subject: Re: Somewhat weird net behavior 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: Sat, 21 Oct 2006 16:58:47 -0000 On Saturday 21 October 2006 17:28, Robert Watson wrote: > On Sat, 21 Oct 2006, Milan Obuch wrote: > > I know this is really minimum information here, but I need just an idea > > what to look for. It is strange for me - is it some memory leak? How > > could it be cleared with simple ifconfig up? Did anyone seen something > > similar? > > It is pretty minimal information :-). > Agreed. I need some help in my investigation. I have no ide what to look for. > ifconfig down / up will cause the device driver to be reset, the link to be > re-negotiated, etc. The buffer full error from ping means that the > outbound interface queue has filled, and if the error doesn't go away, it > means it's likely wedged (no longer being processed). This could reflect a > bug in the device driver, a problem with the switch, etc. In the "wedged" > state, what does ifconfig report about link negotiation? When you reset > the interface, does the negotiated link type change? > I did only ifconfig up, not down/up sequence. That's a bit weird for me. Anyway, on next ocasion, I will do ifconfig before/after ifconfig up. Could there be some interesting information in some netstat output too? It happens once - twice a week, so I would rather be a bit prepared beforehand. Thanks for help. Regards, Milan -- This address is used only for mailing list response. Do not send any personal messages to it. From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 17:00:32 2006 Return-Path: X-Original-To: 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 7867816A4EF; Sat, 21 Oct 2006 17:00:32 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B07143D92; Sat, 21 Oct 2006 17:00:10 +0000 (GMT) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan [127.0.0.1]) by aldan.algebra.com (8.13.8/8.13.7) with ESMTP id k9LH09oZ036386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Oct 2006 13:00:09 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by aldan.algebra.com (8.13.8/8.13.7/Submit) id k9LH09Mv036385; Sat, 21 Oct 2006 13:00:09 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) From: Mikhail Teterin To: freebsd-stable@freebsd.org Date: Sat, 21 Oct 2006 13:00:08 -0400 User-Agent: KMail/1.9.1 X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" Cc: freebsd-net@freebsd.org Subject: Re: em network issues 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: Sat, 21 Oct 2006 17:00:32 -0000 = I'd appreciate if people who are observing the problem will report = whether adding DEVICE_POLLING option to kernel config helps them = or not. This will help to tell whether the problem is in the above = quote or in the import of new versions from vendor. I tried this yesterday -- before writing to net@. I saw the "system" component of the total load being rather high and then enabled polling. Again, I did not wait long enough to check, whether the system will cease communicating completely before enabling polling on em, but the "system" load was shooting way up upon starting my backup procedure even when I switched to DEVICE_POLLING-using kernel. -mi From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 17:05:47 2006 Return-Path: X-Original-To: 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 39FCB16A403 for ; Sat, 21 Oct 2006 17:05:47 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66BC343D6B for ; Sat, 21 Oct 2006 17:05:46 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0651A46CA6; Sat, 21 Oct 2006 13:05:46 -0400 (EDT) Date: Sat, 21 Oct 2006 18:05:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Milan Obuch In-Reply-To: <200610211858.30338.net@dino.sk> Message-ID: <20061021180452.Y2879@fledge.watson.org> References: <200610211618.11472.net@dino.sk> <20061021162630.I2879@fledge.watson.org> <200610211858.30338.net@dino.sk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Somewhat weird net behavior 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: Sat, 21 Oct 2006 17:05:47 -0000 On Sat, 21 Oct 2006, Milan Obuch wrote: > On Saturday 21 October 2006 17:28, Robert Watson wrote: >> On Sat, 21 Oct 2006, Milan Obuch wrote: >>> I know this is really minimum information here, but I need just an idea >>> what to look for. It is strange for me - is it some memory leak? How >>> could it be cleared with simple ifconfig up? Did anyone seen something >>> similar? >> >> It is pretty minimal information :-). > > Agreed. I need some help in my investigation. I have no ide what to look > for. FYI, I couldn't deliver e-mail to your e-mail address, but I guess you got it through the list. >> ifconfig down / up will cause the device driver to be reset, the link to be >> re-negotiated, etc. The buffer full error from ping means that the >> outbound interface queue has filled, and if the error doesn't go away, it >> means it's likely wedged (no longer being processed). This could reflect a >> bug in the device driver, a problem with the switch, etc. In the "wedged" >> state, what does ifconfig report about link negotiation? When you reset >> the interface, does the negotiated link type change? > > I did only ifconfig up, not down/up sequence. That's a bit weird for me. > Anyway, on next ocasion, I will do ifconfig before/after ifconfig up. Could > there be some interesting information in some netstat output too? It happens > once - twice a week, so I would rather be a bit prepared beforehand. The output of "ifconfig" with no arguments is probably a useful start. That will tell us about link negotiation, the OACTIVE flag, and so on. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 17:34:10 2006 Return-Path: X-Original-To: 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 A837516A407; Sat, 21 Oct 2006 17:34:10 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E11A643D9E; Sat, 21 Oct 2006 17:34:08 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k9LHXwsi078188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Oct 2006 21:33:58 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k9LHXwEG078187; Sat, 21 Oct 2006 21:33:58 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 21 Oct 2006 21:33:58 +0400 From: Gleb Smirnoff To: Mikhail Teterin Message-ID: <20061021173358.GC75694@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Mikhail Teterin , freebsd-stable@freebsd.org, freebsd-net@freebsd.org References: <200610211300.09476@aldan> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200610211300.09476@aldan> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: em network issues 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: Sat, 21 Oct 2006 17:34:10 -0000 On Sat, Oct 21, 2006 at 01:00:08PM -0400, Mikhail Teterin wrote: M> = I'd appreciate if people who are observing the problem will report M> = whether adding DEVICE_POLLING option to kernel config helps them M> = or not. This will help to tell whether the problem is in the above M> = quote or in the import of new versions from vendor. M> M> I tried this yesterday -- before writing to net@. I saw the "system" component M> of the total load being rather high and then enabled polling. M> M> Again, I did not wait long enough to check, whether the system will cease M> communicating completely before enabling polling on em, but the "system" load M> was shooting way up upon starting my backup procedure even when I switched to M> DEVICE_POLLING-using kernel. We aren't currently speaking about performance, we need to know whether kernel with DEVICE_POLLING option makes NIC work stable. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 20:12:59 2006 Return-Path: X-Original-To: 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 EE0DC16A412 for ; Sat, 21 Oct 2006 20:12:59 +0000 (UTC) (envelope-from lists@codeangels.com) Received: from mail.codeangels.com (monkey.codeangels.com [62.2.169.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95E9C43D55 for ; Sat, 21 Oct 2006 20:12:57 +0000 (GMT) (envelope-from lists@codeangels.com) Received: (qmail-ldap/ctrl 13585 invoked from network); 21 Oct 2006 20:12:55 -0000 Received: from monkey.codeangels.com (HELO www.codeangels.com) (jsmcud@[192.168.5.6]) (envelope-sender ) by monkey.codeangels.com (qmail-ldap-1.03) with SMTP for ; 21 Oct 2006 20:12:55 -0000 Message-ID: <1355.192.168.1.6.1161461575.squirrel@www.codeangels.com> In-Reply-To: References: <2108.192.168.1.6.1161393460.squirrel@www.codeangels.com> Date: Sat, 21 Oct 2006 22:12:55 +0200 (CEST) From: "Kirill Ponazdyr" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/Codeangels_GEN MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Subject: Re: Gigabit performance test X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@codeangels.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2006 20:13:00 -0000 > Are you using amd64 or i386 kernel ? the config implies you are using > i386 On firewall, i386 > > I found > kern.polling.idle_poll=1 > to improve performance in polling. Oh, that does it! Excellent! Performance jumped to 930mbit in single thread instantly. > Also, try updating the box to 6.2 > first as there are quite a few improvements to the em driver Done, it seems like CPU usage is less now > You can also fiddle with assigning less to userspace with > kern.polling.user_frac=30 > Don remember for sure, but ipfw seemed to be a bit faster that pf. > Also with no firewall loaded there seemed to be quite a bit more > throughput... However, that kind of defeats the purpose of a firewall. ;) Now the actual firewall test comes. pv vs ipf vs ipfw vs SonicWall 5060. Stay tuned for results. Thanks! Kirill From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 21:54:23 2006 Return-Path: X-Original-To: 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 3846516A47B; Sat, 21 Oct 2006 21:54:23 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3154F43D8B; Sat, 21 Oct 2006 21:54:22 +0000 (GMT) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id PAA11668; Sat, 21 Oct 2006 15:54:12 -0600 (MDT) Message-Id: <200610212154.PAA11668@lariat.net> X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 21 Oct 2006 15:54:06 -0600 To: "Matthew D. Fuller" From: Brett Glass In-Reply-To: <20061021095808.GH75501@over-yonder.net> References: <200610210648.AAA01737@lariat.net> <20061021095808.GH75501@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-avg-checked=avg-ok-516E617 Cc: piso@freebsd.org, net@freebsd.org Subject: Re: Avoiding natd overhead 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: Sat, 21 Oct 2006 21:54:23 -0000 At 03:58 AM 10/21/2006, Matthew D. Fuller wrote: >Paolo Pisati's 2005 SoC work on integrating libalias into ipfw might >fit here. It should move the NAT'ing into the kernel and save all the >context switches and copies, and (what has me more interested) make it >much easier to change port forwarding and other rules. That would be excellent. NAT really belongs in the kernel, with a userland control and monitoring utility similar to the ones that manage kernel PPP in many UNIX-like OSes. >The worst >thing about natd for me isn't performance, it's that I have to blow >away all the state to change anything. Agreed. Also, more than once I've locked myself out of a machine when trying to restart NAT with a different configuration; it would be nice to be able to change just the parameters I needed to change. I'd love to be able to look at the translations that are generated on the fly in the same way that one can look at other dynamic rules. This is especially true for some of the more arcane forms of NAT (e.g. PPTP passthrough, in which PPTP session numbers are mapped to avoid collisions) which can be hard to debug when something goes worng. --Brett From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 22:00:09 2006 Return-Path: X-Original-To: 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 0F35916A4A0 for ; Sat, 21 Oct 2006 22:00:08 +0000 (UTC) (envelope-from peter@pean.org) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAE9343D88 for ; Sat, 21 Oct 2006 22:00:07 +0000 (GMT) (envelope-from peter@pean.org) Received: from ironport.bredband.com ([195.54.107.82] [195.54.107.82]) by mxfep01.bredband.com with ESMTP id <20061021220006.LFMN953.mxfep01.bredband.com@ironport.bredband.com> for ; Sun, 22 Oct 2006 00:00:06 +0200 Received: from c-3ada72d5.07-172-73746f44.cust.bredbandsbolaget.se (HELO [172.25.1.24]) ([213.114.218.58]) by ironport.bredband.com with ESMTP; 22 Oct 2006 00:00:06 +0200 Message-ID: <453A9851.4070101@pean.org> Date: Sat, 21 Oct 2006 23:59:45 +0200 From: =?ISO-8859-1?Q?Peter_Ankerst=E5l?= User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Sub-interfaces. 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: Sat, 21 Oct 2006 22:00:09 -0000 I've looked all over the web for some tutorials on how to create sub-interfaces i FreeBSD.. Something like fxp0.1 Should I use ng_ ? From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 22:08:35 2006 Return-Path: X-Original-To: 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 DF59A16A403 for ; Sat, 21 Oct 2006 22:08:35 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2857243D5F for ; Sat, 21 Oct 2006 22:08:35 +0000 (GMT) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id QAA11801; Sat, 21 Oct 2006 16:08:21 -0600 (MDT) Message-Id: <200610212208.QAA11801@lariat.net> X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 21 Oct 2006 16:08:14 -0600 To: vova@fbsd.ru From: Brett Glass In-Reply-To: <1161424493.1489.10.camel@localhost> References: <200610210648.AAA01737@lariat.net> <1161424493.1489.10.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-avg-checked=avg-ok-516E617 Cc: net@freebsd.org Subject: Re: Avoiding natd overhead 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: Sat, 21 Oct 2006 22:08:36 -0000 At 03:54 AM 10/21/2006, Vladimir Grebenschikov wrote: > 1. use PF for nat - it does aliasing in kernel space True, but it doesn't let me translate the packets and then continue processing within the firewall -- which is necessary if you want to catch unregistered destination addresses BEFORE translation and then unregistered source addresses AFTER translation. > 2. use in-kernel libalias implementation > (I guess man-page for ng_nat(4) will help) Same problem. I don't know how I could send packets through a Netgraph node in the middle of processing by IPFW and then bring them back at the next rule. I suppose that one solution might be, for lack of a better term, a "kernel divert socket," which would pass packets through a kernel module rather than a user process. (This could actually be used to speed up many things for which the current "userland" divert sockets are now used.) It would then be possible to make a "nat.ko" module, and either provide a utility to control it or roll that functionality into ipfw(8). --Brett From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 22:14:10 2006 Return-Path: X-Original-To: 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 D3EF916A40F; Sat, 21 Oct 2006 22:14:10 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from optimus.centralmiss.com (ns.centralmiss.com [206.156.254.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5767743D4C; Sat, 21 Oct 2006 22:14:07 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by optimus.centralmiss.com (Postfix) with ESMTP id 1876B2842F; Sat, 21 Oct 2006 17:14:07 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 7EB4061C52; Sat, 21 Oct 2006 17:14:06 -0500 (CDT) Date: Sat, 21 Oct 2006 17:14:06 -0500 From: "Matthew D. Fuller" To: Brett Glass Message-ID: <20061021221406.GP75501@over-yonder.net> References: <200610210648.AAA01737@lariat.net> <20061021095808.GH75501@over-yonder.net> <200610212154.PAA11668@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610212154.PAA11668@lariat.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.3 Cc: piso@freebsd.org, net@freebsd.org Subject: Re: Avoiding natd overhead 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: Sat, 21 Oct 2006 22:14:10 -0000 On Sat, Oct 21, 2006 at 03:54:06PM -0600 I heard the voice of Brett Glass, and lo! it spake thus: > > Also, more than once I've locked myself out of a machine when trying > to restart NAT with a different configuration; The trick I've adopted for this is to have allow rules for port 22 both directions BEFORE the divert rule for natd. That way even if it's down, I can still talk ssh. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 22:52:59 2006 Return-Path: X-Original-To: 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 4D1EF16A47B for ; Sat, 21 Oct 2006 22:52:59 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail.classis.ru (classis.ru [213.248.60.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 611F143D55 for ; Sat, 21 Oct 2006 22:52:58 +0000 (GMT) (envelope-from citrin@citrin.ru) Received: from [192.168.1.34] (ppp85-141-212-138.pppoe.mtu-net.ru [85.141.212.138]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: citrin.citrin.ru) by mail.classis.ru (Postfix) with ESMTP id DB2871229D8C; Sun, 22 Oct 2006 02:52:56 +0400 (MSD) Date: Sun, 22 Oct 2006 02:52:47 +0400 From: Anton Yuzhaninov X-Mailer: The Bat! (v3.62.14) Professional Organization: Rambler X-Priority: 3 (Normal) Message-ID: <947391277.20061022025247@citrin.ru> To: Eugene Grosbein In-Reply-To: <20061021144215.GA14654@svzserv.kemerovo.su> References: <200610210648.AAA01737@lariat.net> <20061021095808.GH75501@over-yonder.net> <1238798379.20061021145031@citrin.ru> <20061021144215.GA14654@svzserv.kemerovo.su> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="----------D02A19C972D699" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: net@freebsd.org Subject: Re[2]: Avoiding natd overhead 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: Sat, 21 Oct 2006 22:52:59 -0000 This is a cryptographically signed message in MIME format. ------------D02A19C972D699 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Saturday, October 21, 2006, 6:42:15 PM, Eugene Grosbein wrote: >> 1. libalias allocate memory for create each new entry in NAT table. >> libalias use linear search in linked list to find entry in table. >> It very slow when you have thousands simultaneous connections via >> nat EG> In RELENG_4 libalias uses hash table, not linear search. EG> Are you sure it switched to linear search? And why? Yes, I was mistaken. libalis use lookup tables linkTableOut and linkTableIn --=20 WBR, Anton Yuzhaninov ------------D02A19C972D699--