From owner-freebsd-net@FreeBSD.ORG Sun Apr 11 02:27:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86F5E16A4CE for ; Sun, 11 Apr 2004 02:27:09 -0700 (PDT) Received: from kogut3.o2.pl (kogut3.go2.pl [212.126.20.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id A20DF43D1D for ; Sun, 11 Apr 2004 02:27:08 -0700 (PDT) (envelope-from knockefreebsd@o2.pl) Received: from ALFA (rekin7.go2.pl [212.126.20.19]) by kogut3.o2.pl (Postfix) with ESMTP id 9EC1477D0B for ; Sun, 11 Apr 2004 11:27:06 +0200 (CEST) Message-ID: <003101c41fa7$2cb9cc70$df5561d9@ALFA> From: "Knocke" To: References: <001901c41eee$3f09c0b0$df5561d9@ALFA> <20040410120027.GC710@empiric.dek.spc.org> <003901c41f02$b31ec3b0$df5561d9@ALFA> <4077FE82.7040308@netli.com> Date: Sun, 11 Apr 2004 11:27:11 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: [nwebe] How to track TCP socket variables? (cwnd, ssthresh) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2004 09:27:09 -0000 > Yes, the application must use setsockopt() call to enable socket debugging. > If an application does not turn it on, you can create a simple library > which would substitute socket() with socket()+setsockopt(SO_DEBUG) pair, > and attach it to the application via LD_PRELOAD. uhmm, ok. I'd like to check it first on any socket, do you know any network programms (aplications, benchmarks etc) to open sockets with debug option, or give a '-'switch to do that? trpt on my system keeps on saying : % trpt: /boot/kernel/kernel: no namelist so probably no sockets are currently SO_DEBUG ready. hk From owner-freebsd-net@FreeBSD.ORG Sun Apr 11 02:31:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1561A16A4CF; Sun, 11 Apr 2004 02:31:25 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E08FE43D2F; Sun, 11 Apr 2004 02:31:24 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i3B9VOgd084179; Sun, 11 Apr 2004 02:31:24 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i3B9VO8f084178; Sun, 11 Apr 2004 02:31:24 -0700 (PDT) (envelope-from rizzo) Date: Sun, 11 Apr 2004 02:31:24 -0700 From: Luigi Rizzo To: Ruslan Ermilov Message-ID: <20040411023124.A83988@xorpc.icir.org> References: <20040410222112.GA23046@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040410222112.GA23046@ip.net.ua>; from ru@freebsd.org on Sun, Apr 11, 2004 at 01:21:12AM +0300 cc: net@freebsd.org Subject: Re: Per-interface polling(4) status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2004 09:31:25 -0000 more or less i am fine with your proposed change. I believe you could add something to state the capability of the hw/driver (polling-capable, like checksum-offloading). For capabilities such as checksum offloading, 'xl' reports them as 'options' rather than 'flags', but other capabilities such as MULTICAST and SIMPLEX are instead reported as 'flags' (well you could think of MULTICAST as a capability that is always enabled so it makes sense to report it as a 'flag'). Actual settings (PROMISC, UP, POLLING, NOARP) are always reported as flags. I'd love if we could sort out this confusion and have capabilities clearly marked/reported in some ifconfig field (e.g. "options"). POLA would suggest to set IFF_POLLING by default on all drivers which support it. You still need the global sysctl to enable it. Finally, while you are at it (and before we branch 6.0), maybe you could store the 'IFF_CANTCHANGE' flags in a separate place from user-configured ones, so one wouldn't have to apply the mask all the times. cheers luigi On Sun, Apr 11, 2004 at 01:21:12AM +0300, Ruslan Ermilov wrote: > Dear networkers, > > Like I mumbled in another email, I've started working on a small > project that (when done) will allow for a per-interface polling(4) > status to be changed in run-time. Attached is a proof of the > concept patch, that currently has support for the dc(4) driver > only (basically because I have this card plugged into my notebook). From owner-freebsd-net@FreeBSD.ORG Sun Apr 11 07:04:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 260ED16A4CE; Sun, 11 Apr 2004 07:04:50 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34EA643D48; Sun, 11 Apr 2004 07:04:49 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i3BE9O4O079080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Apr 2004 17:09:26 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i3BE4j8U038127; Sun, 11 Apr 2004 17:04:45 +0300 (EEST) (envelope-from ru) Date: Sun, 11 Apr 2004 17:04:45 +0300 From: Ruslan Ermilov To: Luigi Rizzo Message-ID: <20040411140445.GA38033@ip.net.ua> References: <20040410222112.GA23046@ip.net.ua> <20040411023124.A83988@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <20040411023124.A83988@xorpc.icir.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@freebsd.org Subject: Re: Per-interface polling(4) status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2004 14:04:50 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 11, 2004 at 02:31:24AM -0700, Luigi Rizzo wrote: > more or less i am fine with your proposed change. >=20 OK. > I believe you could add something to state the capability of the=20 > hw/driver (polling-capable, like checksum-offloading). >=20 I have no idea why I haven't thought about interface capabilities, but that's certainly what I was looking for, thanks! Since this was very easy to implement, and it also didn't require change to basic polling code (the IFF_POLLING has the old meaning and semantics), I went ahead and committed my updated changes to HEAD. > POLA would suggest to set IFF_POLLING by default on all drivers which > support it. You still need the global sysctl to enable it. > =20 The new IFCAP_POLLING will be set by default in enabled capabilities list, except probably in the rl(4) driver. ;) > Finally, while you are at it (and before we branch 6.0), maybe you=20 > could store the 'IFF_CANTCHANGE' flags in a separate place from=20 > user-configured ones, so one wouldn't have to apply the mask all > the times. >=20 Is it really "all the time"? The use of IFF_CANTCHANGE is currently limited to only two files in sys/net/, if I'm not terribly mistaken. Anyway, let's continue discussion of this item in a separate thread. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAeVB9Ukv4P6juNwoRAmVbAJ9CR6ncq5NiIZ0I9V8OfsvEJkrWCQCeL1m6 SNya+RbYGNIe8oudOnU1JCc= =cWz8 -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 11 07:46:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD71016A4CE; Sun, 11 Apr 2004 07:46:31 -0700 (PDT) Received: from palle.girgensohn.se (1-2-8-5a.asp.sth.bostream.se [82.182.157.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EE4A43D39; Sun, 11 Apr 2004 07:46:30 -0700 (PDT) (envelope-from girgen@pingpong.net) Received: from localhost.girgensohn.se (localhost.girgensohn.se [127.0.0.1]) by palle.girgensohn.se (8.12.11/8.12.11) with ESMTP id i3BEkV1r000872; Sun, 11 Apr 2004 16:46:32 +0200 (CEST) (envelope-from girgen@pingpong.net) Date: Sun, 11 Apr 2004 16:38:02 +0200 From: Palle Girgensohn To: Ruslan Ermilov , Bruce Evans Message-ID: <4670000.1081694282@palle.girgensohn.se> In-Reply-To: <20040408193618.GA1919@ip.net.ua> References: <20240000.1079394807@palle.girgensohn.se> <3810000.1081299464@palle.girgensohn.se> <20040407235838.K11719@gamplex.bde.org> <20040408193618.GA1919@ip.net.ua> X-Mailer: Mulberry/3.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: current@FreeBSD.org cc: net@FreeBSD.org Subject: Re: sk ethernet driver: watchdog timeout X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2004 14:46:31 -0000 Hi again, I just tried FreeBSD RELENG_5_2 on one of our boxes having sk0, and the demsg during boot is very noisy when trying to load driver for sk0... Perhaps these dmesg rows can help. It stops every so often on 5.2 as well, the interface is unusable. :( Is there any point in trying any of the patches from this thread? /Palle skc0: port 0x9000-0x90ff mem 0xe8000000-0xe8003fff irq 5 at device 4.0 on pci1 skc0: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter sk0: on skc0 malloc() of "512" with the following non-sleepable locks held: exclusive sleep mutex skc0 (network driver) r = 0 (0xc62311c0) locked @ /4/usr/5src/sys/pci/if_sk.c:1368 Stack backtrace: backtrace(c094bc3c,c0c219a4,116,1,c08bf820) at backtrace+0x17 witness_warn(5,0,c087566d,c082122f,55) at witness_warn+0x193 uma_zalloc_arg(c1038e00,0,102,20,c0864b62) at uma_zalloc_arg+0xa9 malloc(110,c08bf820,102,0,180) at malloc+0xcf if_attach(c6232000,c623200c,10,c0864b62,0) at if_attach+0x240 ether_ifattach(c6232000,c62321d4,0,0,ffffffff) at ether_ifattach+0x22 sk_attach(c6231080,c61ba84c,c0886510,c0c21ab0,c062b75f) at sk_attach+0x359 device_probe_and_attach(c6231080,c620b700,c0c21b04,c0a3d797,c620b180) at device_probe_and_attach+0xa9 bus_generic_attach(c620b180,11a,1,c0c21af0,ffffffff) at bus_generic_attach+0x19 skc_attach(c620b180,c61b984c,c0886510,0,e) at skc_attach+0x7d7 device_probe_and_attach(c620b180,1,c0c21b68,c05873f1,c620b700) at device_probe_and_attach+0xa9 bus_generic_attach(c620b700,1,78,c0c21b58,1) at bus_generic_attach+0x19 pci_attach(c620b700,c620b700,c0877468,1,c6161800) at pci_attach+0xa1 device_probe_and_attach(c620b700,c6161800,c0c21bbc,c0589356,c6161800) at device_probe_and_attach+0xa9 bus_generic_attach(c6161800,c0877468,1,c6161800,c0c21be8) at bus_generic_attach+0x19 pcib_attach(c6161800,c61e704c,c0886510,0,c6161a00) at pcib_attach+0x46 device_probe_and_attach(c6161800,0,c0c21c20,c05873f1,c6207780) at device_probe_and_attach+0xa9 bus_generic_attach(c6207780,0,78,c0c21c10,0) at bus_generic_attach+0x19 pci_attach(c6207780,c618684c,c0886510,0,0) at pci_attach+0xa1 device_probe_and_attach(c6207780,0,c0c21c84,c07f6ccd,c6207800) at device_probe_and_attach+0xa9 bus_generic_attach(c6207800,c0877468,0,c0c21c74,0) at bus_generic_attach+0x19 legacy_pcib_attach(c6207800,c61e884c,c0886510,c2262ce0,c6207900) at legacy_pcib_attach+0x9d device_probe_and_attach(c6207800,c6207900,c0c21ce0,c07e169b,c6207900) at device_probe_and_attach+0xa9 bus_generic_attach(c6207900,c0c21ce0,c0654aeb,c08f7228,c6207900) at bus_generic_attach+0x19 legacy_attach(c6207900,c61d284c,c0886510,0,c08faec0) at legacy_attach+0x1b device_probe_and_attach(c6207900,c6207a00,c0c21d2c,c07e98fc,c6207a00) at device_probe_and_attach+0xa9 bus_generic_attach(c6207a00,c6207a00,c0c21d58,c0650489,c6207a00) at bus_generic_attach+0x19 nexus_attach(c6207a00,c61de04c,c0886510,0,c226ea40) at nexus_attach+0x1c device_probe_and_attach(c6207a00,c226ea40,c0c21d7c,c07d7319,c2282a00) at device_probe_and_attach+0xa9 root_bus_configure(c2282a00,c087914c,0,c0c21d98,c060fb49) at root_bus_configure+0x1b configure(0,c1ec00,c1e000,c1ec00,c1e000) at configure+0x29 mi_startup() at mi_startup+0x99 begin() at begin+0x2c sk0: Ethernet address: 00:0e:a6:2b:d5:17 miibus1: on sk0 e1000phy0: on miibus1 lock order reversal 1st 0xc62311c0 skc0 (network driver) @ /4/usr/5src/sys/pci/if_sk.c:672 2nd 0xc091aaa0 kernel environment (kernel environment) @ /4/usr/5src/sys/kern/kern_environment.c:288 Stack backtrace: backtrace(c085f834,c091aaa0,c0859523,c0859523,c08594fb) at backtrace+0x17 witness_checkorder(c091aaa0,1,c08594fb,120,c096d000) at witness_checkorder+0x6f6 _sx_slock(c091aaa0,c08594fb,120,c08f6700,a) at _sx_slock+0x8e getenv(c0841e7e,0,c0651084,28,c6230f00) at getenv+0x3b getenv_quad(c0841e7e,c0c21950,c6230f00,c0c2196c,c0c21980) at getenv_quad+0x1a getenv_int(c0841e7e,c09124e8,c6230f00,c0c21980,c0654aeb) at getenv_int+0x18 e1000phy_attach(c6230f00,c61ea84c,c0886510,c06510d1,c086a855) at e1000phy_attach+0x1d device_probe_and_attach(c6230f00,c6231000,c0c219dc,c0561149,c6231000) at device_probe_and_attach+0xa9 bus_generic_attach(c6231000,f0000000,c0a3c610,c0a3c650,c6231000) at bus_generic_attach+0x19 miibus_attach(c6231000,c6231000,2b3,1,0) at miibus_attach+0x59 device_probe_and_attach(c6231000,0,c0c21a38,c056152a,c6231080) at device_probe_and_attach+0xa9 bus_generic_attach(c6231080,0,1,0,c6232000) at bus_generic_attach+0x19 mii_phy_probe(c6231080,c62321e4,c0a3c610,c0a3c650,ffffffff) at mii_phy_probe+0x10a sk_attach(c6231080,c61ba84c,c0886510,c0c21ab0,c062b75f) at sk_attach+0x3a2 device_probe_and_attach(c6231080,c620b700,c0c21b04,c0a3d797,c620b180) at device_probe_and_attach+0xa9 bus_generic_attach(c620b180,11a,1,c0c21af0,ffffffff) at bus_generic_attach+0x19 skc_attach(c620b180,c61b984c,c0886510,0,e) at skc_attach+0x7d7 device_probe_and_attach(c620b180,1,c0c21b68,c05873f1,c620b700) at device_probe_and_attach+0xa9 bus_generic_attach(c620b700,1,78,c0c21b58,1) at bus_generic_attach+0x19 pci_attach(c620b700,c620b700,c0877468,1,c6161800) at pci_attach+0xa1 device_probe_and_attach(c620b700,c6161800,c0c21bbc,c0589356,c6161800) at device_probe_and_attach+0xa9 bus_generic_attach(c6161800,c0877468,1,c6161800,c0c21be8) at bus_generic_attach+0x19 pcib_attach(c6161800,c61e704c,c0886510,0,c6161a00) at pcib_attach+0x46 device_probe_and_attach(c6161800,0,c0c21c20,c05873f1,c6207780) at device_probe_and_attach+0xa9 bus_generic_attach(c6207780,0,78,c0c21c10,0) at bus_generic_attach+0x19 pci_attach(c6207780,c618684c,c0886510,0,0) at pci_attach+0xa1 device_probe_and_attach(c6207780,0,c0c21c84,c07f6ccd,c6207800) at device_probe_and_attach+0xa9 bus_generic_attach(c6207800,c0877468,0,c0c21c74,0) at bus_generic_attach+0x19 legacy_pcib_attach(c6207800,c61e884c,c0886510,c2262ce0,c6207900) at legacy_pcib_attach+0x9d device_probe_and_attach(c6207800,c6207900,c0c21ce0,c07e169b,c6207900) at device_probe_and_attach+0xa9 bus_generic_attach(c6207900,c0c21ce0,c0654aeb,c08f7228,c6207900) at bus_generic_attach+0x19 legacy_attach(c6207900,c61d284c,c0886510,0,c08faec0) at legacy_attach+0x1b device_probe_and_attach(c6207900,c6207a00,c0c21d2c,c07e98fc,c6207a00) at device_probe_and_attach+0xa9 bus_generic_attach(c6207a00,c6207a00,c0c21d58,c0650489,c6207a00) at bus_generic_attach+0x19 nexus_attach(c6207a00,c61de04c,c0886510,0,c226ea40) at nexus_attach+0x1c device_probe_and_attach(c6207a00,c226ea40,c0c21d7c,c07d7319,c2282a00) at device_probe_and_attach+0xa9 bus_generic_attach(c6207a00,c6207a00,c0c21d58,c0650489,c6207a00) at bus_generic_attach+0x19 nexus_attach(c6207a00,c61de04c,c0886510,0,c226ea40) at nexus_attach+0x1c device_probe_and_attach(c6207a00,c226ea40,c0c21d7c,c07d7319,c2282a00) at device_probe_and_attach+0xa9 root_bus_configure(c2282a00,c087914c,0,c0c21d98,c060fb49) at root_bus_configure+0x1b configure(0,c1ec00,c1e000,c1ec00,c1e000) at configure+0x29 mi_startup() at mi_startup+0x99 begin() at begin+0x2c sk0: Ethernet address: 00:0e:a6:2b:d5:17 miibus1: on sk0 e1000phy0: on miibus1 lock order reversal 1st 0xc62311c0 skc0 (network driver) @ /4/usr/5src/sys/pci/if_sk.c:672 2nd 0xc091aaa0 kernel environment (kernel environment) @ /4/usr/5src/sys/kern/kern_environment.c:288 Stack backtrace: backtrace(c085f834,c091aaa0,c0859523,c0859523,c08594fb) at backtrace+0x17 witness_checkorder(c091aaa0,1,c08594fb,120,c096d000) at witness_checkorder+0x6f6 _sx_slock(c091aaa0,c08594fb,120,c08f6700,a) at _sx_slock+0x8e getenv(c0841e7e,0,c0651084,28,c6230f00) at getenv+0x3b getenv_quad(c0841e7e,c0c21950,c6230f00,c0c2196c,c0c21980) at getenv_quad+0x1a getenv_int(c0841e7e,c09124e8,c6230f00,c0c21980,c0654aeb) at getenv_int+0x18 e1000phy_attach(c6230f00,c61ea84c,c0886510,c06510d1,c086a855) at e1000phy_attach+0x1d device_probe_and_attach(c6230f00,c6231000,c0c219dc,c0561149,c6231000) at device_probe_and_attach+0xa9 bus_generic_attach(c6231000,f0000000,c0a3c610,c0a3c650,c6231000) at bus_generic_attach+0x19 miibus_attach(c6231000,c6231000,2b3,1,0) at miibus_attach+0x59 device_probe_and_attach(c6231000,0,c0c21a38,c056152a,c6231080) at device_probe_and_attach+0xa9 bus_generic_attach(c6231080,0,1,0,c6232000) at bus_generic_attach+0x19 mii_phy_probe(c6231080,c62321e4,c0a3c610,c0a3c650,ffffffff) at mii_phy_probe+0x10a sk_attach(c6231080,c61ba84c,c0886510,c0c21ab0,c062b75f) at sk_attach+0x3a2 device_probe_and_attach(c6231080,c620b700,c0c21b04,c0a3d797,c620b180) at device_probe_and_attach+0xa9 bus_generic_attach(c620b180,11a,1,c0c21af0,ffffffff) at bus_generic_attach+0x19 skc_attach(c620b180,c61b984c,c0886510,0,e) at skc_attach+0x7d7 device_probe_and_attach(c620b180,1,c0c21b68,c05873f1,c620b700) at device_probe_and_attach+0xa9 bus_generic_attach(c620b700,1,78,c0c21b58,1) at bus_generic_attach+0x19 pci_attach(c620b700,c620b700,c0877468,1,c6161800) at pci_attach+0xa1 device_probe_and_attach(c620b700,c6161800,c0c21bbc,c0589356,c6161800) at device_probe_and_attach+0xa9 bus_generic_attach(c6161800,c0877468,1,c6161800,c0c21be8) at bus_generic_attach+0x19 pcib_attach(c6161800,c61e704c,c0886510,0,c6161a00) at pcib_attach+0x46 device_probe_and_attach(c6161800,0,c0c21c20,c05873f1,c6207780) at device_probe_and_attach+0xa9 bus_generic_attach(c6207780,0,78,c0c21c10,0) at bus_generic_attach+0x19 pci_attach(c6207780,c618684c,c0886510,0,0) at pci_attach+0xa1 device_probe_and_attach(c6207780,0,c0c21c84,c07f6ccd,c6207800) at device_probe_and_attach+0xa9 bus_generic_attach(c6207800,c0877468,0,c0c21c74,0) at bus_generic_attach+0x19 legacy_pcib_attach(c6207800,c61e884c,c0886510,c2262ce0,c6207900) at legacy_pcib_attach+0x9d device_probe_and_attach(c6207800,c6207900,c0c21ce0,c07e169b,c6207900) at device_probe_and_attach+0xa9 bus_generic_attach(c6207900,c0c21ce0,c0654aeb,c08f7228,c6207900) at bus_generic_attach+0x19 legacy_attach(c6207900,c61d284c,c0886510,0,c08faec0) at legacy_attach+0x1b device_probe_and_attach(c6207900,c6207a00,c0c21d2c,c07e98fc,c6207a00) at device_probe_and_attach+0xa9 bus_generic_attach(c6207a00,c6207a00,c0c21d58,c0650489,c6207a00) at bus_generic_attach+0x19 nexus_attach(c6207a00,c61de04c,c0886510,0,c226ea40) at nexus_attach+0x1c device_probe_and_attach(c6207a00,c226ea40,c0c21d7c,c07d7319,c2282a00) at device_probe_and_attach+0xa9 root_bus_configure(c2282a00,c087914c,0,c0c21d98,c060fb49) at root_bus_configure+0x1b configure(0,c1ec00,c1e000,c1ec00,c1e000) at configure+0x29 mi_startup() at mi_startup+0x99 begin() at begin+0x2c e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto skc0: [GIANT-LOCKED] --On torsdag, april 08, 2004 22.36.18 +0300 Ruslan Ermilov wrote: > On Thu, Apr 08, 2004 at 12:17:06AM +1000, Bruce Evans wrote: > [...] >> The following patch reduces the problem on A7V8X-E a little. It limits >> the tx queue to 1 packet and fixes handling of the timeout on txeof. >> The first part probably makes the second part a no-op. Without this, >> my A7V8X-E hangs on even light nfs activity (e.g., copying a 1MB file >> to nfs). With it, it takes heavier nfs activity to hang (makeworld >> never completes, and a flood ping always hangs). >> >> I first suspected an interrupt-related bug, but the bug seems to be >> more hardware-specific. Examination of the output queues shows that >> the tx sometimes just stops before processing all packets. Resetting >> in sk_watchdog() doesn't always fix the problem, and the timeout usually >> stops firing after a couple of unsuccessful resets, giving a completely >> hung device. But the problem may be related to interrupt timing, since >> it is much smaller under RELENG_4. RELENG_4 hangs about as often >> without this hack as -current does with it. >> >> nv0 hangs similarly. fxp0 just works. >> >> %%% >> Index: if_sk.c >> =================================================================== >> RCS file: /home/ncvs/src/sys/pci/if_sk.c,v >> retrieving revision 1.78 >> diff -u -2 -r1.78 if_sk.c >> --- if_sk.c 31 Mar 2004 12:35:51 -0000 1.78 >> +++ if_sk.c 1 Apr 2004 07:33:58 -0000 >> @@ -1830,4 +1830,9 @@ >> SK_IF_LOCK(sc_if); >> >> + if (sc_if->sk_cdata.sk_tx_cnt > 0) { >> + SK_IF_UNLOCK(sc_if); >> + return; >> + } >> + >> idx = sc_if->sk_cdata.sk_tx_prod; >> >> @@ -1853,4 +1858,5 @@ >> */ >> BPF_MTAP(ifp, m_head); >> + break; >> } >> >> @@ -2000,5 +2031,4 @@ >> sc_if->sk_cdata.sk_tx_cnt--; >> SK_INC(idx, SK_TX_RING_CNT); >> - ifp->if_timer = 0; >> } >> >> @@ -2007,4 +2037,6 @@ >> if (cur_tx != NULL) >> ifp->if_flags &= ~IFF_OACTIVE; >> + >> + ifp->if_timer = (sc_if->sk_cdata.sk_tx_cnt == 0) ? 0 : 5; >> >> return; >> %%% >> > Always recharging the timer to 5 when there's some TX work still > left is a bug. With DEVICE_POLLING (yes, I have plans to add > polling(4) support for sk(4) too), sk_txeof() will be called > periodically, and if the card gets stuck, the if_timer will > never downgrade to zero, and sk_watchdog() will never be called. > Without DEVICE_POLLING, recharging it back to 5 even when > if_timer reaches 0 is still pointless, because when if_timer is > 0 while in the sk_txeof(), it means it's called by sk_watchdog() > which will reinit the card and both RX and TX lists, making them > empty, so having the if_timer with the value of 5 _after_ > executing the watchdog cleaning and having _no_ TX activity at > all may cause a second (false) watchdog. My version of the > TX fixes (which also fixes resetting of IFF_OACTIVE): > > %%% > Index: if_sk.c > =================================================================== > RCS file: /home/ncvs/src/sys/pci/if_sk.c,v > retrieving revision 1.78 > diff -u -p -r1.78 if_sk.c > --- if_sk.c 31 Mar 2004 12:35:51 -0000 1.78 > +++ if_sk.c 8 Apr 2004 19:10:50 -0000 > @@ -1998,14 +1998,14 @@ sk_txeof(sc_if) > sc_if->sk_cdata.sk_tx_chain[idx].sk_mbuf = NULL; > } > sc_if->sk_cdata.sk_tx_cnt--; > + ifp->if_flags &= ~IFF_OACTIVE; > SK_INC(idx, SK_TX_RING_CNT); > - ifp->if_timer = 0; > } > > sc_if->sk_cdata.sk_tx_cons = idx; > > - if (cur_tx != NULL) > - ifp->if_flags &= ~IFF_OACTIVE; > + if (sc_if->sk_cdata.sk_tx_cnt == 0) > + ifp->if_timer = 0; > > return; > } > %%% > > We have been running the 3COM 3C940 card on 4.9 (and from today > on 4.10-BETA) without any problems and under a heavy TX load. > > > Cheers, > -- > Ruslan Ermilov > ru@FreeBSD.org > FreeBSD committer From owner-freebsd-net@FreeBSD.ORG Sun Apr 11 08:13:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF7C216A4CE; Sun, 11 Apr 2004 08:13:04 -0700 (PDT) Received: from out007.verizon.net (out007pub.verizon.net [206.46.170.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 567E743D2F; Sun, 11 Apr 2004 08:13:04 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.160.247.127]) by out007.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040411151303.QXZZ28276.out007.verizon.net@mac.com>; Sun, 11 Apr 2004 10:13:03 -0500 Message-ID: <40796061.1020200@mac.com> Date: Sun, 11 Apr 2004 11:12:33 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <20040410222112.GA23046@ip.net.ua> In-Reply-To: <20040410222112.GA23046@ip.net.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out007.verizon.net from [68.160.247.127] at Sun, 11 Apr 2004 10:13:03 -0500 cc: net@FreeBSD.org Subject: Re: Per-interface polling(4) status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2004 15:13:04 -0000 Ruslan Ermilov wrote: [ ... ] > Points I'm not sure about, and would like to hear the comments on: > > - Should the initial polling status be on or off, on interfaces > that support it? The current version of the patch makes it > off by default. Given that polling will only take place if kern.polling.enable is set, IFF_POLLING can be enabled by default safely and changing the global sysctl will enable or disable all polling-capable interfaces, which retains the current behavior. > - Should I add the code to ether_poll_register() to sanity check > that the interface doesn't attempt to register itself more > than once? Sure. I don't see how having an interface registered multiple times will do any good....? -- -Chuck From owner-freebsd-net@FreeBSD.ORG Sun Apr 11 09:14:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CC4B16A4CF; Sun, 11 Apr 2004 09:14:58 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCE2343D54; Sun, 11 Apr 2004 09:14:57 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i3BGEvgd012010; Sun, 11 Apr 2004 09:14:57 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i3BGEveV012009; Sun, 11 Apr 2004 09:14:57 -0700 (PDT) (envelope-from rizzo) Date: Sun, 11 Apr 2004 09:14:57 -0700 From: Luigi Rizzo To: Ruslan Ermilov Message-ID: <20040411091457.B10991@xorpc.icir.org> References: <20040409164724.GD2461@ip.net.ua> <20040409105503.A35357@xorpc.icir.org> <20040409183117.GA3431@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040409183117.GA3431@ip.net.ua>; from ru@freebsd.org on Fri, Apr 09, 2004 at 09:31:17PM +0300 cc: net@freebsd.org Subject: Re: polling(4) and rl(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2004 16:14:58 -0000 On Fri, Apr 09, 2004 at 09:31:17PM +0300, Ruslan Ermilov wrote: ... > Do you mean it would be okay if I just trimmed the polling support > in rl(4) to the RX part only? I actually considered doing this, > just wasn't sure if it is good. ;) maybe it's a bit tricky. You'd have to disable rx interrupts, but keep the tx ones... which makes the call to poll_register check a few more conditions. cheers luigi > > Cheers, > -- > Ruslan Ermilov > ru@FreeBSD.org > FreeBSD committer From owner-freebsd-net@FreeBSD.ORG Sun Apr 11 09:18:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D00816A4CE; Sun, 11 Apr 2004 09:18:14 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5263143D45; Sun, 11 Apr 2004 09:18:13 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i3BGMnTQ081492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Apr 2004 19:22:51 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i3BGI9Cd039376; Sun, 11 Apr 2004 19:18:09 +0300 (EEST) (envelope-from ru) Date: Sun, 11 Apr 2004 19:18:09 +0300 From: Ruslan Ermilov To: Luigi Rizzo Message-ID: <20040411161809.GC38313@ip.net.ua> References: <20040409164724.GD2461@ip.net.ua> <20040409105503.A35357@xorpc.icir.org> <20040409183117.GA3431@ip.net.ua> <20040411091457.B10991@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hOcCNbCCxyk/YU74" Content-Disposition: inline In-Reply-To: <20040411091457.B10991@xorpc.icir.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@freebsd.org Subject: Re: polling(4) and rl(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2004 16:18:14 -0000 --hOcCNbCCxyk/YU74 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 11, 2004 at 09:14:57AM -0700, Luigi Rizzo wrote: > On Fri, Apr 09, 2004 at 09:31:17PM +0300, Ruslan Ermilov wrote: > ... > > Do you mean it would be okay if I just trimmed the polling support > > in rl(4) to the RX part only? I actually considered doing this, > > just wasn't sure if it is good. ;) >=20 > maybe it's a bit tricky. You'd have to disable rx interrupts, > but keep the tx ones... which makes the call to poll_register > check a few more conditions. >=20 Well, for what I need from rl(4), the per-interface polling(4) control is enough. ;) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --hOcCNbCCxyk/YU74 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAeW/BUkv4P6juNwoRArcCAJ0doHP3RJdDh7T7N6xdXa2A59CwWwCgiCB8 /BfXvIcHOzhKS5oBjXqP0Fo= =g3Wi -----END PGP SIGNATURE----- --hOcCNbCCxyk/YU74-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 11 11:09:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE95C16A4CE; Sun, 11 Apr 2004 11:09:00 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3D1E43D41; Sun, 11 Apr 2004 11:08:59 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i3BIDaLX084413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Apr 2004 21:13:37 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i3BI8i61000860; Sun, 11 Apr 2004 21:08:44 +0300 (EEST) (envelope-from ru) Date: Sun, 11 Apr 2004 21:08:44 +0300 From: Ruslan Ermilov To: Palle Girgensohn Message-ID: <20040411180844.GC746@ip.net.ua> References: <20240000.1079394807@palle.girgensohn.se> <3810000.1081299464@palle.girgensohn.se> <20040407235838.K11719@gamplex.bde.org> <20040408193618.GA1919@ip.net.ua> <4670000.1081694282@palle.girgensohn.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aT9PWwzfKXlsBJM1" Content-Disposition: inline In-Reply-To: <4670000.1081694282@palle.girgensohn.se> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: current@freebsd.org cc: net@freebsd.org Subject: Re: sk ethernet driver: watchdog timeout X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2004 18:09:00 -0000 --aT9PWwzfKXlsBJM1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 11, 2004 at 04:38:02PM +0200, Palle Girgensohn wrote: > Hi again, >=20 > I just tried FreeBSD RELENG_5_2 on one of our boxes having sk0, and the= =20 > demsg during boot is very noisy when trying to load driver for sk0...=20 > Perhaps these dmesg rows can help. It stops every so often on 5.2 as well= ,=20 > the interface is unusable. :( >=20 > Is there any point in trying any of the patches from this thread? >=20 Hmm, the verbose output you see is probably from the yesterday's "PCI omnibus" commit by Warner into HEAD, not RELENG_5_2 (please correct me if I'm wrong). Also, I don't have a free sk(4) card at the moment available for testing under 5-CURRENT, or I would definitely do it -- all sk(4) cards I have are running nicely in production under a constant high load on 4.9-STABLE boxes. I'll see if I can order one from our local store; I'd like to add the polling(4) support into the driver anyway... Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --aT9PWwzfKXlsBJM1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAeYmsUkv4P6juNwoRAldEAJwIcw+U+wg7y8XkLlUyZ03vuQn6PgCdFB13 a9SGfJI/WqstCsxtymn67qU= =jVLe -----END PGP SIGNATURE----- --aT9PWwzfKXlsBJM1-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 11 17:47:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6E9916A4CE; Sun, 11 Apr 2004 17:47:41 -0700 (PDT) Received: from palle.girgensohn.se (1-2-8-5a.asp.sth.bostream.se [82.182.157.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7142D43D48; Sun, 11 Apr 2004 17:47:40 -0700 (PDT) (envelope-from girgen@pingpong.net) Received: from localhost.girgensohn.se (localhost.girgensohn.se [127.0.0.1]) by palle.girgensohn.se (8.12.11/8.12.11) with ESMTP id i3C0lfex033187; Mon, 12 Apr 2004 02:47:42 +0200 (CEST) (envelope-from girgen@pingpong.net) Date: Mon, 12 Apr 2004 02:47:41 +0200 From: Palle Girgensohn To: Ruslan Ermilov Message-ID: <134690000.1081730861@palle.girgensohn.se> In-Reply-To: <20040411180844.GC746@ip.net.ua> References: <20240000.1079394807@palle.girgensohn.se> <3810000.1081299464@palle.girgensohn.se> <20040407235838.K11719@gamplex.bde.org> <20040408193618.GA1919@ip.net.ua> <4670000.1081694282@palle.girgensohn.se> <20040411180844.GC746@ip.net.ua> X-Mailer: Mulberry/3.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline cc: current@freebsd.org cc: net@freebsd.org Subject: Re: sk ethernet driver: watchdog timeout X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 00:47:42 -0000 --On s=F6ndag, april 11, 2004 21.08.44 +0300 Ruslan Ermilov = =20 wrote: > On Sun, Apr 11, 2004 at 04:38:02PM +0200, Palle Girgensohn wrote: >> Hi again, >> >> I just tried FreeBSD RELENG_5_2 on one of our boxes having sk0, and the >> demsg during boot is very noisy when trying to load driver for sk0... >> Perhaps these dmesg rows can help. It stops every so often on 5.2 as >> well, the interface is unusable. :( >> >> Is there any point in trying any of the patches from this thread? >> > Hmm, the verbose output you see is probably from the yesterday's > "PCI omnibus" commit by Warner into HEAD, not RELENG_5_2 (please > correct me if I'm wrong). Hmm, yes, you're right of course, it is HEAD. Mea culpa! > Also, I don't have a free sk(4) card > at the moment available for testing under 5-CURRENT, or I would > definitely do it -- all sk(4) cards I have are running nicely in > production under a constant high load on 4.9-STABLE boxes. I'll > see if I can order one from our local store; I'd like to add the > polling(4) support into the driver anyway... This NIC is integrated on an ASUS motherboard, "A7N8X-e deluxe". Just=20 bought half a dozen of these mobos, and they all show the same problem,=20 both on 4.9-STABLE and 5-CURRENT. On 5-CURRENT, I never get a watchdog=20 timeout warning, it just stops responding. If you where in Stockholm, you could pop by and borrow one, but I guess=20 you're not? ;^) Cheers, Palle From owner-freebsd-net@FreeBSD.ORG Sun Apr 11 23:49:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B74D216A4CE for ; Sun, 11 Apr 2004 23:49:34 -0700 (PDT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE11E43D1D for ; Sun, 11 Apr 2004 23:49:33 -0700 (PDT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i3C6l9iG020535 for net@FreeBSD.org.checked; (8.12.8/vak/2.1) Mon, 12 Apr 2004 10:47:09 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i3C6imcd020375; (8.12.8/vak/2.1) Mon, 12 Apr 2004 10:44:48 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <407A3AD5.50508@cronyx.ru> Date: Mon, 12 Apr 2004 10:44:37 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <20040409164724.GD2461@ip.net.ua> In-Reply-To: <20040409164724.GD2461@ip.net.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: net@FreeBSD.org Subject: Re: polling(4) and rl(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 06:49:34 -0000 Ruslan Ermilov wrote: >As an aside, I've started working on the ``[-]polling'' option for >ifconfig(8) that, when done, will allow changing the polling status >of individual interfaces in run-time, e.g., the following command >will disable polling on nge0: > > ifconfig nge0 -polling > > Just a thought, what if iface is not hardware? Netgraph for example? :-) rik From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 00:58:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC29D16A4CE; Mon, 12 Apr 2004 00:58:59 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 214D043D48; Mon, 12 Apr 2004 00:58:59 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i3C83c4h016256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Apr 2004 11:03:39 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i3C7wnEC018110; Mon, 12 Apr 2004 10:58:49 +0300 (EEST) (envelope-from ru) Date: Mon, 12 Apr 2004 10:58:49 +0300 From: Ruslan Ermilov To: Roman Kurakin Message-ID: <20040412075849.GF17656@ip.net.ua> References: <20040409164724.GD2461@ip.net.ua> <407A3AD5.50508@cronyx.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HKEL+t8MFpg/ASTE" Content-Disposition: inline In-Reply-To: <407A3AD5.50508@cronyx.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: Luigi Rizzo cc: net@FreeBSD.org Subject: Re: polling(4) and rl(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 07:59:00 -0000 --HKEL+t8MFpg/ASTE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 12, 2004 at 10:44:37AM +0400, Roman Kurakin wrote: > Ruslan Ermilov wrote: >=20 > >As an aside, I've started working on the ``[-]polling'' option for > >ifconfig(8) that, when done, will allow changing the polling status > >of individual interfaces in run-time, e.g., the following command > >will disable polling on nge0: > > > > ifconfig nge0 -polling > >=20 > > > Just a thought, what if iface is not hardware? Netgraph for example? :-) >=20 I can only think of ng_eiface(4) here, and I don't see how it would benefit at all from having the DEVICE_POLLING support, nor I can see how such a support would fit into the driver, as the driver doesn't have any RX/TX queues. But it can be done of course. ;) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --HKEL+t8MFpg/ASTE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAekw5Ukv4P6juNwoRAh3sAJ0UghZGOxiqgn603YV8vwAilTg8wwCfX0QE t2uxxzFf+ZdzIf/NeEmqr88= =/0Ka -----END PGP SIGNATURE----- --HKEL+t8MFpg/ASTE-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 02:03:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3195416A4CE; Mon, 12 Apr 2004 02:03:17 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E487543D46; Mon, 12 Apr 2004 02:03:15 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i3C97v3q018152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Apr 2004 12:07:59 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i3C937md000447; Mon, 12 Apr 2004 12:03:07 +0300 (EEST) (envelope-from ru) Date: Mon, 12 Apr 2004 12:03:07 +0300 From: Ruslan Ermilov To: net@FreeBSD.org Message-ID: <20040412090307.GA378@ip.net.ua> References: <20040410222112.GA23046@ip.net.ua> <20040411023124.A83988@xorpc.icir.org> <20040411140445.GA38033@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <20040411140445.GA38033@ip.net.ua> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: stable@FreeBSD.org Subject: Re: Per-interface polling(4) controls X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 09:03:17 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear -STABLE users, I've backported my patches that implement per-interface polling(4) controls. The RELENG_4 patchset for testing is available here: http://people.FreeBSD.org/~ru/patches/polling.patch The patchset also includes an updated vr(4) driver with polling(4) support. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAeltLUkv4P6juNwoRAt7kAJ9if68QlEd8XK9GJhIXq+2oDdiwmgCgh/AS IJz+38u6RyG+HnR6QRV64HM= =F2X1 -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 03:04:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D650516A4CE for ; Mon, 12 Apr 2004 03:04:25 -0700 (PDT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0055E43D2F for ; Mon, 12 Apr 2004 03:04:24 -0700 (PDT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i3CA3FoF031040 for net@FreeBSD.org.checked; (8.12.8/vak/2.1) Mon, 12 Apr 2004 14:03:15 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i3C9xdlx030769; (8.12.8/vak/2.1) Mon, 12 Apr 2004 13:59:40 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <407A6882.3080807@cronyx.ru> Date: Mon, 12 Apr 2004 13:59:30 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <20040409164724.GD2461@ip.net.ua> <407A3AD5.50508@cronyx.ru> <20040412075849.GF17656@ip.net.ua> In-Reply-To: <20040412075849.GF17656@ip.net.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: net@FreeBSD.org Subject: Re: polling(4) and rl(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 10:04:26 -0000 Ruslan Ermilov wrote: >On Mon, Apr 12, 2004 at 10:44:37AM +0400, Roman Kurakin wrote: > > >>Ruslan Ermilov wrote: >> >> >> >>>As an aside, I've started working on the ``[-]polling'' option for >>>ifconfig(8) that, when done, will allow changing the polling status >>>of individual interfaces in run-time, e.g., the following command >>>will disable polling on nge0: >>> >>> ifconfig nge0 -polling >>> >>> >>Just a thought, what if iface is not hardware? Netgraph for example? :-) >> >> >I can only think of ng_eiface(4) here, and I don't see how it would >benefit at all from having the DEVICE_POLLING support, nor I can see >how such a support would fit into the driver, as the driver doesn't >have any RX/TX queues. But it can be done of course. ;) > > I am about devices that might have hardware layer that supports polling but doesn't end with iface itself ... Though it was just some thought ;-) rik From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 07:33:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6699A16A4CE for ; Mon, 12 Apr 2004 07:33:44 -0700 (PDT) Received: from mail-in-02.arcor-online.net (mail-in-02.arcor-online.net [151.189.21.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D7C943D3F for ; Mon, 12 Apr 2004 07:33:43 -0700 (PDT) (envelope-from mailnull@mips.inka.de) Received: from kemoauc.mips.inka.de (dsl-082-082-078-046.arcor-ip.net [82.82.78.46]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id 782DCB74112 for ; Mon, 12 Apr 2004 16:33:41 +0200 (CEST) Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.12.11/8.12.10) with ESMTP id i3CEXe6i052421 for ; Mon, 12 Apr 2004 16:33:40 +0200 (CEST) (envelope-from mailnull@kemoauc.mips.inka.de) Received: (from mailnull@localhost) by kemoauc.mips.inka.de (8.12.11/8.12.11/Submit) id i3CEXeAU052420 for freebsd-net@freebsd.org; Mon, 12 Apr 2004 16:33:40 +0200 (CEST) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Mon, 12 Apr 2004 14:33:39 +0000 (UTC) Message-ID: Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-net@freebsd.org Subject: re(4): puzzling netperf result X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 14:33:44 -0000 I just did some quick and dirty checks with netperf and noticed a somewhat surprising result. Machine A: Alpha PC164, FreeBSD 5.2-CURRENT, re(4), 1000Base-T Machine B: Alpha PC164SX, OpenBSD 3.5, de(4), 100Base-TX Switch: StarChip SGS-1008 (10/100/1000Base-T) Running netperf -t UDP_STREAM on machine A with target B reports a throughput of ~200(!) Mbit/s. How does the machine get the idea it is pushing 200 Mbit/s down a 100 Mbit/s link? -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 07:34:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB77416A4CE; Mon, 12 Apr 2004 07:34:08 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id D161E43D3F; Mon, 12 Apr 2004 07:34:06 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id F2DB315214; Mon, 12 Apr 2004 23:34:04 +0900 (JST) Date: Mon, 12 Apr 2004 23:34:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Luigi Rizzo In-Reply-To: <20040409042720.A99087@xorpc.icir.org> References: <20040409042720.A99087@xorpc.icir.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: andre@freebsd.org cc: current@freebsd.org cc: core@kame.net cc: net@freebsd.org cc: ume@freebsd.org Subject: Re: suggested patches for netinet6/ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 14:34:09 -0000 (cc'ing to core@kame.net) >>>>> On Fri, 9 Apr 2004 04:27:20 -0700, >>>>> Luigi Rizzo said: > While adapting to ipv6 the new arp table code I am developing > following Andre's ideas, i hit a few places that would deserve a > fix independently of that: > + nd6_nud_hint() is only called as nd6_nud_hint(NULL, NULL, 0); > in some cases from netinet/tcp_input.c > With these args, the routine is a NOP. I propose to remove it > (and the associated field, ln_byhint, in struct llinfo_nd6) Hmm, it seems that the first argument was changed to NULL in rev. 1.216 of tcp_input.c with the introduction of TCP host cache. We have been passing a meaningful argument by then, and I suspect the change was really made with confidence. So, I guess the correct approach would be to provide an appropriate value with nd6_nud_hint with the logic of TCP host cache, rather than to remove it. (At the same time, however, I'm personally skeptical about the effectiveness of such a hint from a higher layer to ND. In that sense, it may make sense to purge it...) > + In a couple of places, the logic to compute 'olladdr' and 'llchange' > is rather convoluted, and it could be greatly simplified (see below) I'm not sure if this is that trivial. In particular, I don't understand (at least from the patch) why we can replace - olladdr = (sdl->sdl_alen) ? 1 : 0; with + olladdr = ln->ln_state >= ND6_LLINFO_REACHABLE; Could be a bit more specific about the rationale? > + nd6_output() contains a tail-recursive call which certainly can be > removed by using a 'goto' near the beginning of the function > (or maybe in a better way!) Looks okay, but I'm wondering if we also need to reset 'ifp' to 'rt->rt_ifp' before going back. (As commented, this logic was derived from ether_output() in 4.4 BSD, so if my guess is correct, it means the old ether_output() had a bug.) > Also: > + in nd6_na_input() we are responding to an nd6 message on interface 'ifp', > so i guess in the routine rt->rt_ifp == ifp, and we can use the latter > when needed instead of rt->rt_ifp ? I think you're correct. According to nd6_nbr.c in the latest KAME snap, rt->rt_ifp == ifp is assured by the call to nd6_lookup() in nd6_na_input(). > + is it ok to remove the __P() from the header files, ANSIfy > the function declarations and make them static as appropriate ? > Of course this ought to be done as a separate step. I myself do not have a strong opinion on this. However, these files would also be shared with other BSDs via KAME snaps, and if this change is not accepted by other BSDs, I'd like to keep it for future synchronization between KAME and BSDs. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp > I am attaching the relevant snippets of the diff... Can anyone comment ? > Any objection if i commit the trivial fixes to the first 3 issues above ? > What about the style changes ? > cheers > luigi Index: nd6.c =================================================================== - olladdr = (sdl->sdl_alen) ? 1 : 0; - if (olladdr && lladdr) { - if (bcmp(lladdr, LLADDR(sdl), ifp->if_addrlen)) - llchange = 1; - else - llchange = 0; - } else - llchange = 0; + olladdr = ln->ln_state >= ND6_LLINFO_REACHABLE; + llchange = olladdr && lladdr && bcmp(lladdr, &ln->ll_addr, ifp->if_addrlen); @@ -1844,11 +1836,8 @@ nd6_output(ifp, origifp, m0, dst, rt0) +again: /* * next hop determination. This routine is derived from ether_outpout. */ if (rt) { if ((rt->rt_flags & RTF_UP) == 0) { rt0 = rt = rtalloc1((struct sockaddr *)dst, 1, 0UL); if (rt != NULL) { RT_REMREF(rt); RT_UNLOCK(rt); - if (rt->rt_ifp != ifp) { - /* XXX: loop care? */ - return nd6_output(ifp, origifp, m0, - dst, rt); - } + if (rt->rt_ifp != ifp) + goto again; /* rt has changed. */ } else senderr(EHOSTUNREACH); } Index: nd6_nbr.c =================================================================== @@ -653,17 +650,9 @@ nd6_na_input(m, off, icmp6len) /* * Check if the link-layer address has changed or not. */ - if (!lladdr) - llchange = 0; - else { - if (sdl->sdl_alen) { - if (bcmp(lladdr, LLADDR(sdl), ifp->if_addrlen)) - llchange = 1; - else - llchange = 0; - } else - llchange = 1; - } + llchange = lladdr && + ( (ln->ln_state < ND6_LLINFO_REACHABLE) || + bcmp(lladdr, &ln->l3_addr, ifp->if_addrlen) ); @@ -744,7 +728,7 @@ nd6_na_input(m, off, icmp6len) * context. However, we keep it just for safety. */ s = splnet(); - dr = defrouter_lookup(in6, rt->rt_ifp); + dr = defrouter_lookup(&ln->l3_addr, ifp); if (dr) defrtrlist_del(dr); else if (!ip6_forwarding && ip6_accept_rtadv) { @@ -755,21 +739,25 @@ nd6_na_input(m, off, icmp6len) * (e.g. redirect case). So we must * call rt6_flush explicitly. */ - rt6_flush(&ip6->ip6_src, rt->rt_ifp); + rt6_flush(&ip6->ip6_src, ifp); } splx(s); } ln->ln_router = is_router; } From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 07:42:38 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F379016A4CE for ; Mon, 12 Apr 2004 07:42:37 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED41243D55 for ; Mon, 12 Apr 2004 07:42:35 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i3CElCbW029582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Apr 2004 17:47:14 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i3CEgLup001441; Mon, 12 Apr 2004 17:42:21 +0300 (EEST) (envelope-from ru) Date: Mon, 12 Apr 2004 17:42:21 +0300 From: Ruslan Ermilov To: Christian Weisgerber Message-ID: <20040412144221.GA1420@ip.net.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-net@FreeBSD.org Subject: Re: re(4): puzzling netperf result X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 14:42:38 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 12, 2004 at 02:33:39PM +0000, Christian Weisgerber wrote: > I just did some quick and dirty checks with netperf and noticed a > somewhat surprising result. >=20 > Machine A: Alpha PC164, FreeBSD 5.2-CURRENT, re(4), 1000Base-T > Machine B: Alpha PC164SX, OpenBSD 3.5, de(4), 100Base-TX > Switch: StarChip SGS-1008 (10/100/1000Base-T) >=20 > Running netperf -t UDP_STREAM on machine A with target B reports a > throughput of ~200(!) Mbit/s. >=20 > How does the machine get the idea it is pushing 200 Mbit/s down a > 100 Mbit/s link? >=20 Does ``netstat -I re0 -w 1'' show the same numbers while you're running the UDP_STREAM test? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAeqrNUkv4P6juNwoRAkDlAKCHWkq7lzJ0yH4USci7ATOoNkOR6QCffwbG N/cUuzdjnnQpdIVXLWyxhho= =EDTP -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 07:56:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0B2C16A4CF; Mon, 12 Apr 2004 07:56:47 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7D3343D4C; Mon, 12 Apr 2004 07:56:47 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i3CEujgd071918; Mon, 12 Apr 2004 07:56:45 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i3CEucLY071896; Mon, 12 Apr 2004 07:56:38 -0700 (PDT) (envelope-from rizzo) Date: Mon, 12 Apr 2004 07:56:38 -0700 From: Luigi Rizzo To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Message-ID: <20040412075638.B67293@xorpc.icir.org> References: <20040409042720.A99087@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Mon, Apr 12, 2004 at 11:34:04PM +0900 cc: ume@freebsd.org cc: core@kame.net cc: andre@freebsd.org cc: current@freebsd.org cc: net@freebsd.org Subject: Re: suggested patches for netinet6/ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 14:56:48 -0000 On Mon, Apr 12, 2004 at 11:34:04PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > (cc'ing to core@kame.net) [thanks for the cc] > > + nd6_nud_hint() is only called as nd6_nud_hint(NULL, NULL, 0); > > in some cases from netinet/tcp_input.c > > With these args, the routine is a NOP. I propose to remove it > > (and the associated field, ln_byhint, in struct llinfo_nd6) ... > (At the same time, however, I'm personally skeptical about the > effectiveness of such a hint from a higher layer to ND. In that > sense, it may make sense to purge it...) not knowing much about ipv6 i cannot comment, however if this is just a performance optimization it can be [re]introduced later. > > + In a couple of places, the logic to compute 'olladdr' and 'llchange' > > is rather convoluted, and it could be greatly simplified (see below) > > I'm not sure if this is that trivial. In particular, I don't > understand (at least from the patch) why we can replace > > - olladdr = (sdl->sdl_alen) ? 1 : 0; > > with > > + olladdr = ln->ln_state >= ND6_LLINFO_REACHABLE; sorry, that included a bit from my new arp code (basically, if you have a MAC address stored for the node then both sdl->sdl_alen !=0 and ln->ln_state >= ND6_LLINFO_REACHABLE. The second form is more appealing to me because with the new arp code there are no more host route entries generated by cloning, and the MAC address resides elsewhere...) Leave olladdr as it was, the rest of the patch just tried to replace the conditional statements with boolean expressions. > > > + nd6_output() contains a tail-recursive call which certainly can be > > removed by using a 'goto' near the beginning of the function > > (or maybe in a better way!) > > Looks okay, but I'm wondering if we also need to reset 'ifp' to > 'rt->rt_ifp' before going back. (As commented, this logic was derived > from ether_output() in 4.4 BSD, so if my guess is correct, it means > the old ether_output() had a bug.) > > > Also: > > + in nd6_na_input() we are responding to an nd6 message on interface 'ifp', > > so i guess in the routine rt->rt_ifp == ifp, and we can use the latter > > when needed instead of rt->rt_ifp ? > > I think you're correct. According to nd6_nbr.c in the latest KAME > snap, rt->rt_ifp == ifp is assured by the call to nd6_lookup() in > nd6_na_input(). ok thanks... once again using ifp eases my task because the new arp code does not have route entries associated with MAC addresses so we need to grab the relevant info elsewhere. > > + is it ok to remove the __P() from the header files, ANSIfy > > the function declarations and make them static as appropriate ? > > Of course this ought to be done as a separate step. > > I myself do not have a strong opinion on this. However, these files > would also be shared with other BSDs via KAME snaps, and if this > change is not accepted by other BSDs, I'd like to keep it for future > synchronization between KAME and BSDs. ok, I am just unclear if we periodically import KAME sources in the tree and then reapply freebsd changes (trying to keep the latter as small as possible) or someone from time to time looks at relevant changes in the KAME tree and patches the freebsd version accordingly. In the latter case, ANSIfying the code would have little impact on the people porting back the patches, yet would help a lot in using stricter compiler checks. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 08:01:53 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3726716A4D1 for ; Mon, 12 Apr 2004 08:01:53 -0700 (PDT) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB8CF43D3F for ; Mon, 12 Apr 2004 08:01:52 -0700 (PDT) (envelope-from naddy@mips.inka.de) Received: from kemoauc.mips.inka.de (dsl-082-082-078-046.arcor-ip.net [82.82.78.46]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 6E08BA65E6F for ; Mon, 12 Apr 2004 17:01:51 +0200 (CEST) Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.12.11/8.12.10) with ESMTP id i3CF1oCS053065 for ; Mon, 12 Apr 2004 17:01:50 +0200 (CEST) (envelope-from naddy@kemoauc.mips.inka.de) Received: (from naddy@localhost) by kemoauc.mips.inka.de (8.12.11/8.12.11/Submit) id i3CF1onk053064 for freebsd-net@FreeBSD.org; Mon, 12 Apr 2004 17:01:50 +0200 (CEST) (envelope-from naddy) Date: Mon, 12 Apr 2004 17:01:50 +0200 From: Christian Weisgerber To: freebsd-net@FreeBSD.org Message-ID: <20040412150150.GA52818@kemoauc.mips.inka.de> References: <20040412144221.GA1420@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040412144221.GA1420@ip.net.ua> User-Agent: Mutt/1.4.2.1i Subject: Re: re(4): puzzling netperf result X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 15:01:53 -0000 Ruslan Ermilov: > > How does the machine get the idea it is pushing 200 Mbit/s down a > > 100 Mbit/s link? > > Does ``netstat -I re0 -w 1'' show the same numbers while you're > running the UDP_STREAM test? Yes, it does (~26000000 bytes). I have two further GigE-equipped OpenBSD boxes on the LAN and they top out at a plausible ~95Mbit/s when UDP streaming to the same target. However, netperf also reports a large number of errors (dropped packets?) in their case--but actual netstat interface figures again concur with the throughput. Alas, I have no further FreeBSD boxes to test this. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 09:06:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED39C16A4CE for ; Mon, 12 Apr 2004 09:06:07 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52CF343D39 for ; Mon, 12 Apr 2004 09:06:07 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id A379C653FF; Mon, 12 Apr 2004 17:06:05 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10079-01-2; Mon, 12 Apr 2004 17:06:05 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 348C6653F9; Mon, 12 Apr 2004 17:06:05 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 7A4F960EE; Mon, 12 Apr 2004 17:06:04 +0100 (BST) Date: Mon, 12 Apr 2004 17:06:04 +0100 From: Bruce M Simpson To: Knocke Message-ID: <20040412160604.GH710@empiric.dek.spc.org> Mail-Followup-To: Knocke , freebsd-net@freebsd.org References: <001901c41eee$3f09c0b0$df5561d9@ALFA> <20040410120027.GC710@empiric.dek.spc.org> <003901c41f02$b31ec3b0$df5561d9@ALFA> <4077FE82.7040308@netli.com> <003101c41fa7$2cb9cc70$df5561d9@ALFA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003101c41fa7$2cb9cc70$df5561d9@ALFA> cc: freebsd-net@freebsd.org Subject: Re: [nwebe] How to track TCP socket variables? (cwnd, ssthresh) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 16:06:08 -0000 On Sun, Apr 11, 2004 at 11:27:11AM +0200, Knocke wrote: > trpt on my system keeps on saying : > > % trpt: /boot/kernel/kernel: no namelist > > so probably no sockets are currently SO_DEBUG ready. You probably need to recompile your kernel with makeoptions TCPDEBUG. Diffing up something simple like netcat for SO_DEBUG support shouldn't be too difficult for a beginning C hacker. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 11:01:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 338F016A4CE for ; Mon, 12 Apr 2004 11:01:32 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15B7C43D48 for ; Mon, 12 Apr 2004 11:01:32 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i3CI1Vbv084431 for ; Mon, 12 Apr 2004 11:01:31 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i3CI1VjN084407 for freebsd-net@freebsd.org; Mon, 12 Apr 2004 11:01:31 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 12 Apr 2004 11:01:31 -0700 (PDT) Message-Id: <200404121801.i3CI1VjN084407@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 18:01:32 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net NFS root configurations without dynamic p 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 15:11:38 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7559016A4CE for ; Mon, 12 Apr 2004 15:11:38 -0700 (PDT) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7742243D31 for ; Mon, 12 Apr 2004 15:11:37 -0700 (PDT) (envelope-from mailnull@mips.inka.de) Received: from kemoauc.mips.inka.de (dsl-213-023-054-248.arcor-ip.net [213.23.54.248]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 57C98A64B75 for ; Tue, 13 Apr 2004 00:11:35 +0200 (CEST) Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.12.11/8.12.10) with ESMTP id i3CLgZBc063563 for ; Mon, 12 Apr 2004 23:42:35 +0200 (CEST) (envelope-from mailnull@kemoauc.mips.inka.de) Received: (from mailnull@localhost) by kemoauc.mips.inka.de (8.12.11/8.12.11/Submit) id i3CLgZeo063562 for freebsd-net@freebsd.org; Mon, 12 Apr 2004 23:42:35 +0200 (CEST) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Mon, 12 Apr 2004 21:42:34 +0000 (UTC) Message-ID: References: Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-net@freebsd.org Subject: Re: re(4): puzzling netperf result X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 22:11:38 -0000 Christian Weisgerber wrote: > Running netperf -t UDP_STREAM on machine A with target B reports a > throughput of ~200(!) Mbit/s. By popular request: naddy@kemoauc[~] /usr/local/netperf/netperf -H bardioc -t UDP_STREAM UDP UNIDIRECTIONAL SEND TEST to bardioc : histogram Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.01 26335 0 194.03 41600 10.01 385 2.84 -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 20:10:45 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A9BC16A4CE; Mon, 12 Apr 2004 20:10:45 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2564D43D49; Mon, 12 Apr 2004 20:10:43 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E234D1521A; Tue, 13 Apr 2004 12:10:39 +0900 (JST) Date: Tue, 13 Apr 2004 12:10:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Luigi Rizzo In-Reply-To: <20040412075638.B67293@xorpc.icir.org> References: <20040409042720.A99087@xorpc.icir.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: ume@freebsd.org cc: core@kame.net cc: andre@freebsd.org cc: current@freebsd.org cc: net@freebsd.org Subject: Re: suggested patches for netinet6/ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 03:10:45 -0000 >>>>> On Mon, 12 Apr 2004 07:56:38 -0700, >>>>> Luigi Rizzo said: >> > + nd6_nud_hint() is only called as nd6_nud_hint(NULL, NULL, 0); >> > in some cases from netinet/tcp_input.c >> > With these args, the routine is a NOP. I propose to remove it >> > (and the associated field, ln_byhint, in struct llinfo_nd6) > ... >> (At the same time, however, I'm personally skeptical about the >> effectiveness of such a hint from a higher layer to ND. In that >> sense, it may make sense to purge it...) > not knowing much about ipv6 i cannot comment, however > if this is just a performance optimization it can be [re]introduced > later. This is also a protocol compliance issue, since RFC2461 clearly mentions the use of such a hint (though the requirement level is not very clear; no RFC2119 keywords are used here). Also, I don't think the logic of "we can reintroduce it later" is reasonable. We originally provided working implementation, which was then broken by other changes. In general, what should be fixed (modified) is the "other changes", not the original code. So, as a compromise, I'd propose to keep the source code even if it is not effective. Perhaps it may make sense to comment out this part with a note that the part is temporarily broken and will be fixed later. >> > + In a couple of places, the logic to compute 'olladdr' and 'llchange' >> > is rather convoluted, and it could be greatly simplified (see below) >> >> I'm not sure if this is that trivial. In particular, I don't >> understand (at least from the patch) why we can replace >> >> - olladdr = (sdl->sdl_alen) ? 1 : 0; >> >> with >> >> + olladdr = ln->ln_state >= ND6_LLINFO_REACHABLE; > sorry, that included a bit from my new arp code (basically, > if you have a MAC address stored for the node then both sdl->sdl_alen !=0 > and ln->ln_state >= ND6_LLINFO_REACHABLE. Strictly speaking, this reasoning cannot justify the change, logic-wise. The original code should read "if sdl->sdl_alen is non 0, then you have a MAC address stored". It's a different proposition than "if you have a MAC address stored for the node then (sdl_alen is non 0 and) ln_state >= ND6_LLINFO_REACHABLE." What we should prove to justify the above change is that "if ln_state >= ND6_LLINFO_REACHABLE then you have a MAC address stored". I'm still not sure if this statement holds. > The second form is more > appealing to me because with the new arp code there are no > more host route entries generated by cloning, and the MAC > address resides elsewhere...) > Leave olladdr as it was, the rest of the patch just tried to > replace the conditional statements with boolean expressions. So are you now proposing to keep the code for olladdr as it was (perhaps with some modifications along with the new arp code?) and to replace the other conditions with boolean expressions? If so, I don't oppose to it, though I'd rather personally prefer, e.g., - if (olladdr && lladdr) { - if (bcmp(lladdr, LLADDR(sdl), ifp->if_addrlen)) - llchange = 1; - else - llchange = 0; - } else - llchange = 0; than + llchange = olladdr && lladdr && bcmp(lladdr, &ln->ll_addr, ifp->if_addrlen); because the intention is clearer in the former, particularly when we check the logic comparing to the protocol specification. (In other words, IMO it's compiler's business to perform this kind of "simplification"). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 22:49:40 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30C2416A4CE; Mon, 12 Apr 2004 22:49:40 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [221.249.121.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id D062043D5E; Mon, 12 Apr 2004 22:49:39 -0700 (PDT) (envelope-from itojun@itojun.org) Received: by coconut.itojun.org (Postfix, from userid 1001) id 645E848; Tue, 13 Apr 2004 14:49:38 +0900 (JST) To: jinmei@isl.rdc.toshiba.co.jp In-Reply-To: Your message of "Tue, 13 Apr 2004 12:10:40 +0900" References: X-Mailer: Cue version 0.6 (040307-1118/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040413054938.645E848@coconut.itojun.org> Date: Tue, 13 Apr 2004 14:49:38 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) cc: andre@freebsd.org cc: ume@freebsd.org cc: rizzo@icir.org cc: core@kame.net cc: net@freebsd.org cc: current@freebsd.org Subject: Re: suggested patches for netinet6/ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 05:49:40 -0000 > >> > + nd6_nud_hint() is only called as nd6_nud_hint(NULL, NULL, 0); > >> > in some cases from netinet/tcp_input.c > >> > With these args, the routine is a NOP. I propose to remove it > >> > (and the associated field, ln_byhint, in struct llinfo_nd6) on other OSes we call nd6_nud_hint() in a useful way. please do not remove it. (more diffs between OSes = more pain for us) itojun From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 23:16:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC07E16A4CE; Mon, 12 Apr 2004 23:16:55 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C9CB43D48; Mon, 12 Apr 2004 23:16:55 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id ADCB015210; Tue, 13 Apr 2004 15:16:54 +0900 (JST) Date: Tue, 13 Apr 2004 15:16:55 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Luigi Rizzo In-Reply-To: <20040412075638.B67293@xorpc.icir.org> References: <20040409042720.A99087@xorpc.icir.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: ume@freebsd.org cc: core@kame.net cc: andre@freebsd.org cc: current@freebsd.org cc: net@freebsd.org Subject: Re: suggested patches for netinet6/ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 06:16:55 -0000 >>>>> On Mon, 12 Apr 2004 07:56:38 -0700, >>>>> Luigi Rizzo said: >> > + is it ok to remove the __P() from the header files, ANSIfy >> > the function declarations and make them static as appropriate ? >> > Of course this ought to be done as a separate step. >> >> I myself do not have a strong opinion on this. However, these files >> would also be shared with other BSDs via KAME snaps, and if this >> change is not accepted by other BSDs, I'd like to keep it for future >> synchronization between KAME and BSDs. > ok, I am just unclear if we periodically import KAME sources in the > tree and then reapply freebsd changes (trying to keep the latter > as small as possible) or someone from time to time looks at > relevant changes in the KAME tree and patches the freebsd version > accordingly. In the latter case, ANSIfying the code would have little > impact on the people porting back the patches, yet would help a lot > in using stricter compiler checks. Out of curiosity (as a novice compiler user), could you be more specific on how it helps with stricter compiler checks to remove __P()? For example, what kind of checks does interfere with __P()? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 23:36:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7A7516A4CE; Mon, 12 Apr 2004 23:36:14 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5CE343D4C; Mon, 12 Apr 2004 23:36:14 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i3D6aEgd048150; Mon, 12 Apr 2004 23:36:14 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i3D6aBgU048149; Mon, 12 Apr 2004 23:36:11 -0700 (PDT) (envelope-from rizzo) Date: Mon, 12 Apr 2004 23:36:11 -0700 From: Luigi Rizzo To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Message-ID: <20040412233611.A46933@xorpc.icir.org> References: <20040409042720.A99087@xorpc.icir.org> <20040412075638.B67293@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Tue, Apr 13, 2004 at 03:16:55PM +0900 cc: net@freebsd.org cc: core@kame.net cc: andre@freebsd.org cc: ume@freebsd.org cc: current@freebsd.org Subject: Re: suggested patches for netinet6/ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 06:36:14 -0000 On Tue, Apr 13, 2004 at 03:16:55PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: ... > >> > + is it ok to remove the __P() from the header files, ANSIfy > >> > the function declarations and make them static as appropriate ? > >> > Of course this ought to be done as a separate step. ... > Out of curiosity (as a novice compiler user), could you be more > specific on how it helps with stricter compiler checks to remove > __P()? For example, what kind of checks does interfere with __P()? __P() macros only affect readability (and are useless once you ANSIfy the code) but i can live with that in the interest of reducing diffs. Making functions static as much as possible, requiring prototypes to be present, putting 'const' where possibe, enables the compiler to flag unused code, misused variables, bad arguments, and so on. Once again i am not proposing to sweep all the netinet6/ code for a gratuitous change, just suggesting that where we touch bits of code in FreeBSD to add locking, change the ARP/ND6 table implementation and so on, we might as well take the chance to request a bit more help from the compiler. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 01:47:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C90E16A4CE for ; Tue, 13 Apr 2004 01:47:21 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E86F43D2D for ; Tue, 13 Apr 2004 01:47:21 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i3D8lKgd060667; Tue, 13 Apr 2004 01:47:20 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i3D8lKEg060666; Tue, 13 Apr 2004 01:47:20 -0700 (PDT) (envelope-from rizzo) Date: Tue, 13 Apr 2004 01:47:20 -0700 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20040413014720.A57543@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: multiple definitions of ROUNDUP macro X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 08:47:21 -0000 The ROUNDUP macro, used to account for the space occupied by a sockaddr when passed through a routing socket, is defined in a zillion places: src/usr.sbin/IPXrouted/startup.c:#define ROUNDUP(a) \ src/usr.sbin/arp/arp.c:#define ROUNDUP(a) \ src/usr.sbin/ndp/ndp.c:#define ROUNDUP(a) \ src/usr.sbin/ppp/defs.h:#define ROUNDUP(x) ((x) ? (1 + (((x) - 1) | (sizeof(longsrc/usr.sbin/route6d/route6d.c:#define ROUNDUP(a) \ src/usr.sbin/rwhod/rwhod.c:#define ROUNDUP(a) \ src/sys/net/route.c.orig:#define ROUNDUP(a) (a>0 ? (1 + (((a) - 1) | (sizeof(lonsrc/sys/net/rtsock.c:#define ROUNDUP(a) \ A similar macro, ADVANCE, has similar problems. This is confusing at best, and a likely source of trouble. If there are no objections I would like to replace it with a centralised macro (possibly with a suitable name) which takes a sockaddr * as argument and returns the rounded-up size of the object as a result. BTW, i notice that the rounding is to multiples of "sizeof(long)", and i wonder if this is intentional, especially on 64-bit architectures. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 03:29:39 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38B8216A4CE for ; Tue, 13 Apr 2004 03:29:39 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71CF343D5D for ; Tue, 13 Apr 2004 03:29:38 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i3DAYQtm067207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2004 13:34:27 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i3DATUqj043257; Tue, 13 Apr 2004 13:29:30 +0300 (EEST) (envelope-from ru) Date: Tue, 13 Apr 2004 13:29:30 +0300 From: Ruslan Ermilov To: Luigi Rizzo Message-ID: <20040413102930.GJ35262@ip.net.ua> References: <20040413014720.A57543@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r4QXMf6/kyF/FvJJ" Content-Disposition: inline In-Reply-To: <20040413014720.A57543@xorpc.icir.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@freebsd.org Subject: Re: multiple definitions of ROUNDUP macro X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 10:29:39 -0000 --r4QXMf6/kyF/FvJJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 13, 2004 at 01:47:20AM -0700, Luigi Rizzo wrote: > The ROUNDUP macro, used to account for the space occupied by a sockaddr = =20 > when passed through a routing socket, is defined in a zillion places: >=20 > src/usr.sbin/IPXrouted/startup.c:#define ROUNDUP(a) \ > src/usr.sbin/arp/arp.c:#define ROUNDUP(a) \ > src/usr.sbin/ndp/ndp.c:#define ROUNDUP(a) \ > src/usr.sbin/ppp/defs.h:#define ROUNDUP(x) ((x) ? (1 + (((x) - 1) | (size= of(longsrc/usr.sbin/route6d/route6d.c:#define ROUNDUP(a) \ > src/usr.sbin/rwhod/rwhod.c:#define ROUNDUP(a) \ > src/sys/net/route.c.orig:#define ROUNDUP(a) (a>0 ? (1 + (((a) - 1) | (siz= eof(lonsrc/sys/net/rtsock.c:#define ROUNDUP(a) \ >=20 You forgot ifconfig(8) and route(8), my favourite reference utils, when it comes to routing. ;) > A similar macro, ADVANCE, has similar problems. > This is confusing at best, and a likely source of trouble. >=20 > If there are no objections I would like to replace it with a > centralised macro (possibly with a suitable name) which takes > a sockaddr * as argument and returns the rounded-up size of the > object as a result. >=20 Yes, please! I wanted to do it long ago, but couldn't come up with good names for them. > BTW, i notice that the rounding is to multiples of "sizeof(long)", > and i wonder if this is intentional, especially on 64-bit > architectures. >=20 It would probably be OK to round-up to an int, but it's too late to change it now -- many off-tree tools that work with routing sockets would break on machines with sizeof(int) !=3D sizeof(long). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --r4QXMf6/kyF/FvJJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAe8EKUkv4P6juNwoRAtyUAJ4v3BmVGmctlk7sk5w0UeIXRTl2DwCfTRnd Xz/PRVq67FZz1FR+BwKwg1Y= =4uxg -----END PGP SIGNATURE----- --r4QXMf6/kyF/FvJJ-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 07:56:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C09E16A4CE for ; Mon, 12 Apr 2004 07:56:51 -0700 (PDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by mx1.FreeBSD.org (Postfix) with SMTP id 2A05A43D31 for ; Mon, 12 Apr 2004 07:56:51 -0700 (PDT) (envelope-from eickeaf@yahoo.com.br) Received: from unknown (HELO eicke) (eickeaf@200.162.114.126 with login) by smtp011.mail.yahoo.com with SMTP; 12 Apr 2004 14:56:50 -0000 Message-ID: <003b01c4209d$cb4186c0$0905a8c0@alellyxbr.com.br> From: "Eicke Felipe" To: "FreeBSD_Net" Date: Mon, 12 Apr 2004 11:52:34 -0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailman-Approved-At: Tue, 13 Apr 2004 05:01:33 -0700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Double ISP Links X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 14:56:51 -0000 Hi folks, I have a server configured with one ISP link. The server runs IPFW and = NATD. I need to attach a new ethernet card and configure another ISP link in = this server.=20 How can I make this and, if possible, configure it with load balance. Thanks and regards. Eicke. From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 08:02:35 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DB5C16A4CE for ; Tue, 13 Apr 2004 08:02:35 -0700 (PDT) Received: from webmail.emre.de (webmail.emre.de [194.8.203.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52B3743D6E for ; Tue, 13 Apr 2004 08:02:34 -0700 (PDT) (envelope-from info@emre.de) Received: by webmail.emre.de (Postfix, from userid 80) id 819253A23E; Tue, 13 Apr 2004 17:02:31 +0200 (CEST) Received: from sys-125.netcologne.de (sys-125.netcologne.de [194.8.193.125]) by webmail.emre.de (Horde) with HTTP for ; Tue, 13 Apr 2004 17:02:30 +0200 Message-ID: <1081868550.3f2e268094821@webmail.emre.de> Date: Tue, 13 Apr 2004 17:02:30 +0200 From: Emre Bastuz To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) 4.0-cvs Subject: NAT issue - answer packets not sent to default gateway X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 15:02:35 -0000 Hi, I have a FreeBSD box with four interfaces (actually four VLAN interfaces ove= r one trunk). Packets from arbitrary IP addresses are supposed to arrive through interface= s 1-3 and the answer to those requests is supposed to be sent out on interface= 4 (which is the default gateway). Main goal is to create some kind of forced portal. To achieve this I=B4ve be= en testing NAT rules, mainly this one: rdr vlan220 0/0 port 80 -> 127.0.0.1 port 80 tcp The translation itself works as expected so every http request is being forc= ed to the proxy machine itself: bash-2.05b# ipnat -l List of active sessions: RDR 127.0.0.1 80 <- -> 198.133.219.25 80 [some.source.add.res 1= 098] When the PC with the IP some.source.add.res fires up the browser and request= s http://www.cisco.com/ I would expect a different page to show up, namely the index.html the Apache on 127.0.0.1 is configured to show. However this does not happen as long a I do not have a host route for the requesting PC on my proxy machine such as this: bash-2.05b# route add -host some.source.add.res 192.168.0.1 (where 192.168.0.1 is the "other" side of a point to point link on one of th= e interfaces 1-3). Am I missing something? This is driving me nuts. Honestly. TIA, Emre P.S.: net.inet.ip.forwarding=3D1 -- http://www.emre.de UIN: 561260 PGP Key ID: 0xAFAC77FD I don't see why some people even HAVE cars. -- Calvin ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 08:26:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89C2C16A4CE for ; Tue, 13 Apr 2004 08:26:47 -0700 (PDT) Received: from mailbox.wingercom.dk (mailbox.easyspeedy.dk [81.19.240.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1B7443D5E for ; Tue, 13 Apr 2004 08:26:46 -0700 (PDT) (envelope-from per@xterm.dk) Received: from mailbox.wingercom.dk (localhost.wingercom.dk [127.0.0.1]) by mailbox.wingercom.dk (Postfix) with SMTP id 2258A93216; Tue, 13 Apr 2004 17:31:03 +0200 (CEST) Received: from 62.242.151.142 (SquirrelMail authenticated user per) by mailbox.wingercom.dk with HTTP; Tue, 13 Apr 2004 17:31:03 +0200 (CEST) Message-ID: <35654.62.242.151.142.1081870263.squirrel@mailbox.wingercom.dk> Date: Tue, 13 Apr 2004 17:31:03 +0200 (CEST) From: "Per Engelbrecht" To: In-Reply-To: <003b01c4209d$cb4186c0$0905a8c0@alellyxbr.com.br> References: <003b01c4209d$cb4186c0$0905a8c0@alellyxbr.com.br> X-Mailer: SquirrelMail (version 1.2.5) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org Subject: Re: Double ISP Links X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 15:26:47 -0000 Hi Eicke What you're talking about is a multi-homed router. My best advice to you is Zebra (/usr/ports/net/zebra [v. 0.94]) and also have a look at www.zebra.org Zebra is a routing tool that can handle RIP, OSPF and BGP It shares the same (almost) syntax as Cisco's IOS. Zebra is build in modules, each with it's own .conf file i.e. you can configure one part without touching the other - on the fly! Next version will include MPLS as well. If you're new to routing, expect some reading. Keep both your ISP's informed and ask them for advice when in doubt. respectfully /per per@xterm.dk > Hi folks, > > I have a server configured with one ISP link. The server runs IPFW > and NATD. I need to attach a new ethernet card and configure > another ISP link in this server. How can I make this and, if > possible, configure it with load balance. > > Thanks and regards. > Eicke. > _______________________________________________ > 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 Tue Apr 13 08:35:38 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E1D316A4CE for ; Tue, 13 Apr 2004 08:35:38 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id E765643D69 for ; Tue, 13 Apr 2004 08:35:37 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i3DFZ9kS023502; Tue, 13 Apr 2004 08:35:09 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i3DFZ9In023496; Tue, 13 Apr 2004 08:35:09 -0700 Date: Tue, 13 Apr 2004 08:35:08 -0700 From: Brooks Davis To: Luigi Rizzo Message-ID: <20040413153508.GB20550@Odin.AC.HMC.Edu> References: <20040413014720.A57543@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ftEhullJWpWg/VHq" Content-Disposition: inline In-Reply-To: <20040413014720.A57543@xorpc.icir.org> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: net@freebsd.org Subject: Re: multiple definitions of ROUNDUP macro X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 15:35:38 -0000 --ftEhullJWpWg/VHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 13, 2004 at 01:47:20AM -0700, Luigi Rizzo wrote: > The ROUNDUP macro, used to account for the space occupied by a sockaddr = =20 > when passed through a routing socket, is defined in a zillion places: >=20 > src/usr.sbin/IPXrouted/startup.c:#define ROUNDUP(a) \ > src/usr.sbin/arp/arp.c:#define ROUNDUP(a) \ > src/usr.sbin/ndp/ndp.c:#define ROUNDUP(a) \ > src/usr.sbin/ppp/defs.h:#define ROUNDUP(x) ((x) ? (1 + (((x) - 1) | (size= of(longsrc/usr.sbin/route6d/route6d.c:#define ROUNDUP(a) \ > src/usr.sbin/rwhod/rwhod.c:#define ROUNDUP(a) \ > src/sys/net/route.c.orig:#define ROUNDUP(a) (a>0 ? (1 + (((a) - 1) | (siz= eof(lonsrc/sys/net/rtsock.c:#define ROUNDUP(a) \ >=20 > A similar macro, ADVANCE, has similar problems. > This is confusing at best, and a likely source of trouble. >=20 > If there are no objections I would like to replace it with a > centralised macro (possibly with a suitable name) which takes > a sockaddr * as argument and returns the rounded-up size of the > object as a result. Sounds good. BDE suggested the roundup/roundup2 macros in sys/param.h when I was removing some macros from net/if.c. > BTW, i notice that the rounding is to multiples of "sizeof(long)", > and i wonder if this is intentional, especially on 64-bit > architectures. Our wordsize is long on all architectures so that makes sense to me. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --ftEhullJWpWg/VHq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAfAirXY6L6fI4GtQRAiSkAJwJ2CfTBzw9Fi7f0umyc22c7g/hMQCfZnnB ne5+EeTuB3baiMLk1Of2gzs= =gRgG -----END PGP SIGNATURE----- --ftEhullJWpWg/VHq-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 14 05:37:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC62316A4CE; Wed, 14 Apr 2004 05:37:34 -0700 (PDT) Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id C221B43D5C; Wed, 14 Apr 2004 05:37:33 -0700 (PDT) (envelope-from c.prevotaux@hexanet.fr) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (Postfix) with SMTP id 45E0E4C963; Wed, 14 Apr 2004 14:37:32 +0200 (CEST) Date: Wed, 14 Apr 2004 14:37:32 +0200 From: Christophe Prevotaux To: hardware@freebsd.org, net@freebsd.org Message-Id: <20040414143732.3b13b54e.c.prevotaux@hexanet.fr> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386-portbld-freebsd4.9) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: 4Gbps in PCI-X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 12:37:34 -0000 Hi, Is anyone working or planning to work on these babies support for FreeBSD ? http://www.astutenetworks.com/content/product/superhba.htm -- =============================================================== Christophe Prevotaux =============================================================== From owner-freebsd-net@FreeBSD.ORG Wed Apr 14 06:13:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 398AE16A4CF for ; Wed, 14 Apr 2004 06:13:24 -0700 (PDT) Received: from www.freshx.de (freshx.de [80.190.100.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE67C43D41 for ; Wed, 14 Apr 2004 06:13:23 -0700 (PDT) (envelope-from kai@freshx.de) Received: from localhost (unknown [127.0.0.1]) by www.freshx.de (Postfix) with ESMTP id 0698715E37A for ; Wed, 14 Apr 2004 15:13:22 +0200 (CEST) Received: from localhost (unknown [127.0.0.1]) by www.freshx.de (Postfix) with ESMTP id BA1E515E357 for ; Wed, 14 Apr 2004 15:13:20 +0200 (CEST) Received: from 127.0.0.1 ( [127.0.0.1]) as user dust0005@localhost by localhost with HTTP; Wed, 14 Apr 2004 15:13:20 +0200 Message-ID: <1081948400.407d38f081851@localhost> Date: Wed, 14 Apr 2004 15:13:20 +0200 From: Kai Mosebach To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Virus-Scanned: by AMaViS 0.3.12 Subject: Bridging problems on 5.2-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 13:13:24 -0000 Dear list, recently i tried to setup a wireless bridge onto my freebsd 5.2 server. i followed the instructions on the ath manpage and set the bridge up with : ifconfig ath0 inet up sysctl net.link.ether.bridge.enable=1 sysctl net.link.ether.bridge.config="ath0 xl0" sysctl net.inet.ip.forwarding=1 the ath interface has no ip adress, but xl0 has. now i can ping all of my lan-clients from the wireless, excepting the bridge itself. i saw some reports about problems in the bridge module of 4.x so i build my kernel with options BRIDGE, but no changes. the second problem is, that i have a DSL router on my cabled segment, which is pingable from wireless, but setting it as default gw and DNS server on the wireless client is not working, internet access is not possible. any ideas ? best Kai From owner-freebsd-net@FreeBSD.ORG Wed Apr 14 08:48:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AE0C16A4CE for ; Wed, 14 Apr 2004 08:48:27 -0700 (PDT) Received: from smtp106.mail.sc5.yahoo.com (smtp106.mail.sc5.yahoo.com [66.163.169.226]) by mx1.FreeBSD.org (Postfix) with SMTP id D95CF43D58 for ; Wed, 14 Apr 2004 08:48:26 -0700 (PDT) (envelope-from eickeaf@yahoo.com.br) Received: from unknown (HELO eicke) (eickeaf@200.162.114.126 with login) by smtp106.mail.sc5.yahoo.com with SMTP; 14 Apr 2004 15:28:56 -0000 Message-ID: <00e201c42234$9b6ad490$0905a8c0@alellyxbr.com.br> From: "Eicke Felipe" To: "FreeBSD_Net" Date: Wed, 14 Apr 2004 12:24:35 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Imapd Quota X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 15:48:27 -0000 Hi folks I have a server 4.8 that runs Postfix 2.0.16 I need to enable IMAP quota to squirrelmail quota plugin. The imapd informations are the following: #imtest -a eicke -m login -p imap localhost C: C01 CAPABILITY S: * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS AUTH=LOGIN] localhost.xy.com.br IMAP4rev1 2001.315 at Wed, 14 Apr 2004 12:18:06 -0300 (EST) S: * CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND LOGIN-REFERRALS AUTH=LOGIN S: C01 OK CAPABILITY completed How can I update my imap server capability to enable quota? Thanks and regards. Eicke. From owner-freebsd-net@FreeBSD.ORG Wed Apr 14 08:52:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA32E16A4CE for ; Wed, 14 Apr 2004 08:52:27 -0700 (PDT) Received: from smtp-out4.xs4all.nl (smtp-out4.xs4all.nl [194.109.24.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19FD743D4C for ; Wed, 14 Apr 2004 08:52:27 -0700 (PDT) (envelope-from rene+fbsd@canyon.xs4all.nl) Received: from zion.canyon.xs4all.nl (canyon.xs4all.nl [80.126.75.53]) by smtp-out4.xs4all.nl (8.12.10/8.12.10) with ESMTP id i3EFqNCY036181; Wed, 14 Apr 2004 17:52:23 +0200 (CEST) Received: from zion.canyon.xs4all.nl (localhost [127.0.0.1]) by localhost.canyon.xs4all.nl (Postfix) with ESMTP id 42AF88432; Wed, 14 Apr 2004 17:52:19 +0200 (CEST) Received: from [IPv6:2001:888:181b:1:230:65ff:fe1e:e03d] (meandrix.canyon.xs4all.nl [IPv6:2001:888:181b:1:230:65ff:fe1e:e03d]) by zion.canyon.xs4all.nl (Postfix) with ESMTP id 04CA98430; Wed, 14 Apr 2004 17:52:18 +0200 (CEST) In-Reply-To: <200404062256.XAA14667@starburst.demon.co.uk> References: <200404062256.XAA14667@starburst.demon.co.uk> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Rene de Vries Date: Wed, 14 Apr 2004 17:52:25 +0200 To: Brandon Erhart X-Mailer: Apple Mail (2.613) cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 15:52:28 -0000 Brandon, Maybe I am missing something, but why not set SO_LINGER to 0 (zero).=20 This should have the effect of instantaniously cleaning up after a=20 close. With the disadvantage that there will be no FIN but a simple=20 RST. Rene On Apr 7, 2004, at 0:56, Richard Wendland wrote: >> They are not timing out after 2MSL. I set my MSL to the lowest=20 >> possible >> setting (10) as to make TIME_WAIT connections disappear. The=20 >> FIN_WAIT_[1,2] >> and LAST_ACK seem to be sticking around for a while. > >>> Do the FIN_WAIT_1|2 and LAST_ACK time out after 2MSL or do they = stick >>> around forever? If they stick around forever, then there is=20 >>> something >>> broken. > > I see quite a lot of connections `stuck' in FIN_WAIT_2 from talking > to some particular web servers/OSs, and can reproduce the problem. > The FreeBSD stack isn't broken, the far end is just acting strangely. > > In the cases I see it is simply that the remote web-server thread has > become confused or stuck and won't close the TCP connection after my > FreeBSD client has sent a FIN. My connection is stuck in FIN_WAIT_2 > awaiting a FIN from the server to go into CLOSING state, but the far=20= > TCP > (crazily) is sending keepalives about every 10 minutes. > > Essentially the problem is the strange server behaviour; I don't think > much can be done about this particular case in the FreeBSD client with > the socket API. > > FreeBSD has the traditional Berkeley non-standard TCP behaviour of > forcing idle FIN_WAIT_2 connections into the CLOSING state after 11m > 15sec, as described on page 246 of TCP Illus. Vol 1 (by setting the > tcp_timer_2msl timer in "case TCPS_FIN_WAIT_1:" in tcp_input.c and > later calling tcp_close() for idle connections in tcp_timer_2msl()). > The 10 mins keep-alive prevents this from happening. > > NB it doesn't matter that the FreeBSD client process has terminated, > the socket is already closed so process termination does nothing = extra. > > A possible improvement on the traditional Berkeley behaviour would be > to require some actual data transfer rather than simply non-idleness = to > prevent FIN_WAIT_2 being forced into CLOSING state. But I doubt this > problem is serious enough to make such a change. > > I can reproduce this with Novell-HTTP-Server (running on NetWare I=20 > think), > by connecting and closing immediately without sending a method = request. > This seems to confuse the web server thread, and it doesn't respond=20 > with > a FIN as you'd expect. This is probably not the only way to cause = this > confusion, but it serves for reproducing the problem. > > Here's a tcpdump of what happens on FreeBSD 4.9-PRERELEASE: > > 20:57:26.987078 fbsd.4613 > novell.80: S 675591727:675591727(0) win=20 > 32768 (DF) > 20:57:27.114442 novell.80 > fbsd.4613: S 4258048106:4258048106(0) ack=20= > 675591728 win 1460 (DF) > 20:57:27.114472 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 20:57:31.396853 fbsd.4613 > novell.80: F 1:1(0) ack 1 win 33580 (DF) > 20:57:31.521313 novell.80 > fbsd.4613: . ack 2 win 6143 (DF) > # novell.80 doesn't respond with a FIN as expected, > # instead sends a keep-alive ever 10 mins: > 21:07:24.883771 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 21:07:24.883786 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 21:17:20.404002 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 21:17:20.404014 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 21:27:15.357954 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 21:27:15.357966 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 21:37:14.357869 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 21:37:14.357881 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 21:47:06.875293 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 21:47:06.875318 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 21:57:02.118544 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 21:57:02.118556 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 22:06:53.237910 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 22:06:53.237930 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 22:16:45.884856 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 22:16:45.884871 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 22:26:38.595193 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 22:26:38.595206 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > ... stuck in FIN_WAIT_2, usually until reboot > > Richard > --=20 > Richard Wendland richard@wendland.org.uk > _______________________________________________ > 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 Ren=E9 de Vries Tunix Internet Security & Training From owner-freebsd-net@FreeBSD.ORG Wed Apr 14 09:24:49 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6180716A4D1 for ; Wed, 14 Apr 2004 09:24:49 -0700 (PDT) Received: from hotmail.com (bay14-f20.bay14.hotmail.com [64.4.49.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DDE443D31 for ; Wed, 14 Apr 2004 09:24:49 -0700 (PDT) (envelope-from monicadomingues@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 14 Apr 2004 09:24:49 -0700 Received: from 193.137.232.102 by by14fd.bay14.hotmail.msn.com with HTTP; Wed, 14 Apr 2004 16:24:49 GMT X-Originating-IP: [193.137.232.102] X-Originating-Email: [monicadomingues@hotmail.com] X-Sender: monicadomingues@hotmail.com From: "Mónica Domingues" To: freebsd-net@freebsd.org Date: Wed, 14 Apr 2004 16:24:49 +0000 Message-ID: X-OriginalArrivalTime: 14 Apr 2004 16:24:49.0314 (UTC) FILETIME=[01E1C820:01C4223D] MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: pim6sd Installation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 16:24:49 -0000 I download the port pim6sd and install them in my pc but in I do man pim6sd I see the following message: no manual entry for pim6sd I can I know if pim6sd if correctly install in my pc. Thanks for the attention. Mónica Domingues _________________________________________________________________ Tired of spam? Get [1]advanced junk mail protection with MSN 8. References 1. http://g.msn.com/8HMAEN/2734??PS= From owner-freebsd-net@FreeBSD.ORG Wed Apr 14 21:32:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B83816A4CE for ; Wed, 14 Apr 2004 21:32:27 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB9AB43D1F for ; Wed, 14 Apr 2004 21:32:26 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id EF72215214; Thu, 15 Apr 2004 13:32:24 +0900 (JST) Date: Thu, 15 Apr 2004 13:32:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: =?ISO-2022-JP?B?Ik0bJEIidRsoQm5pY2EgRG9taW5ndWVzIg==?= In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable cc: freebsd-net@freebsd.org Subject: Re: pim6sd Installation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 04:32:27 -0000 >>>>> On Wed, 14 Apr 2004 16:24:49 +0000,=20 >>>>> "M=F3nica Domingues" said: > I download the port pim6sd and install them in my pc but in I do > man pim6sd > I see the following message: > no manual entry for pim6sd > I can I know if pim6sd if correctly install in my pc. > Thanks for the attention. I just tried to install pim6sd using the latest FreeBSD port (ports/net/pim6sd) without having any troubles (on FreeBSD 4.8p16). The man pages were installed under /usr/local/man/man8/ . I suspect you missed something in the installation procedure or your environment for man(1) does not have /usr/local/man in the search path. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Thu Apr 15 00:22:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC34716A4CE for ; Thu, 15 Apr 2004 00:22:02 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4C52E43D46 for ; Thu, 15 Apr 2004 00:22:01 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 67365 invoked from network); 15 Apr 2004 07:22:00 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 15 Apr 2004 07:22:00 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 15 Apr 2004 02:30:24 -0500 (CDT) From: Mike Silbersack To: Kai Mosebach In-Reply-To: <1081948400.407d38f081851@localhost> Message-ID: <20040415022517.X84867@odysseus.silby.com> References: <1081948400.407d38f081851@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Bridging problems on 5.2-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 07:22:02 -0000 On Wed, 14 Apr 2004, Kai Mosebach wrote: > Dear list, > > recently i tried to setup a wireless bridge onto my freebsd 5.2 server. > > i followed the instructions on the ath manpage and set the bridge up with : > > ifconfig ath0 inet up > sysctl net.link.ether.bridge.enable=1 > sysctl net.link.ether.bridge.config="ath0 xl0" > sysctl net.inet.ip.forwarding=1 > > the ath interface has no ip adress, but xl0 has. I'm using a similar setup on 4.x (with wi in place of ath), and it works reasonably well. The one difference is that I did assign an IP address to the wireless interface, although I always communicate with the LAN IP address. Note that one problem the FreeBSD arp code has (as of now) is that it isn't really multi-interface aware; you'll see lots of messages on the wireless client where it sees the lan IP moving back and forth between the MAC addresses of the wireless and LAN cards. Is it possible that this behavior is confusing your client somehow? > now i can ping all of my lan-clients from the wireless, excepting the bridge > itself. i saw some reports about problems in the bridge module of 4.x so i > build my kernel with options BRIDGE, but no changes. I had problems with the module under 4.x, so I am using BRIDGE in the kernel config as well. > the second problem is, that i have a DSL router on my cabled segment, which is > pingable from wireless, but setting it as default gw and DNS server on the > wireless client is not working, internet access is not possible. > > any ideas ? > > best Kai Maybe the second problem is part of the first problem manifesting itself in a different way. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Thu Apr 15 00:57:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EDB016A4CE for ; Thu, 15 Apr 2004 00:57:50 -0700 (PDT) Received: from vanish.yandex.ru (vanish.yandex.ru [213.180.200.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A19343D3F for ; Thu, 15 Apr 2004 00:57:49 -0700 (PDT) (envelope-from sbakalyas@yandex.ru) Received: from ip-16-21.tagiltelecom.ru ([217.114.16.21]:31246 "EHLO techotdel1" smtp-auth: "sbakalyas") by mail.yandex.ru with ESMTP id ; Thu, 15 Apr 2004 11:57:37 +0400 Date: Thu, 15 Apr 2004 13:56:10 +0600 From: stepan X-Mailer: The Bat! (v2.00.6) Business Organization: =?Windows-1251?B?0uDj6Osg0uXr5eru7A==?= X-Priority: 3 (Normal) Message-ID: <97615037984.20040415135610@yandex.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: 8bit Subject: bge0 FreeBSD-4.7 and Cisco827 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: stepan List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 07:57:50 -0000 Hello all! old router - PC with fxp NIC, new router HP Proliant DL320 with bge NIC. We try to move interface of connection CIsco827 from PC to HP. In combination Cisco 827 - fxp intel Ethernet adapter problems were not. At replacement of Router PC on HP Proliant there was a problem - bge (Broadcom 7502 Network Ethernet Controller) does not perceive arp-reply from Cisco 827. version Freebsd-4.7. In what there can be a problem? The similar question of compatibility is with Cisco Catalyst 2950 and bge. -=-=-=- Regards, Stepan mailto:sbakalyas@yandex.ru From owner-freebsd-net@FreeBSD.ORG Thu Apr 15 02:54:38 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97B3516A4CE for ; Thu, 15 Apr 2004 02:54:38 -0700 (PDT) Received: from foehn.cmo-tlse.shom.fr (foehn.cmo-tlse.shom.fr [217.167.202.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02D0143D41 for ; Thu, 15 Apr 2004 02:54:37 -0700 (PDT) (envelope-from landry.brunel@cmo-tlse.shom.fr) Received: by foehn.cmo-tlse.shom.fr; id JAA26977; Thu, 15 Apr 2004 09:54:35 GMT Message-Id: <200404150954.JAA26977@foehn.cmo-tlse.shom.fr> Date: Thu, 15 Apr 2004 11:52:03 +0200 From: Landry Brunel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.6) Gecko/20040113 X-Accept-Language: fr, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: TCP/UDP dynamic port range X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 09:54:38 -0000 Does someone knows how to change the dynamic TCP/UDP port range. I'd like to tune it like on sparc/solaris : 32768->65535 . Thank's a lot, Landry. From owner-freebsd-net@FreeBSD.ORG Thu Apr 15 03:01:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB8E516A4CE for ; Thu, 15 Apr 2004 03:01:00 -0700 (PDT) Received: from mail.icomag.de (ns.icomag.de [195.227.115.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD92443D53 for ; Thu, 15 Apr 2004 03:00:59 -0700 (PDT) (envelope-from bgd@icomag.de) Received: from localhost (localhost [127.0.0.1]) by mail.icomag.de (Postfix) with ESMTP id DD7B022E3B; Thu, 15 Apr 2004 12:00:57 +0200 (CEST) Received: by mail.icomag.de (Postfix, from userid 1019) id 2308922E40; Thu, 15 Apr 2004 12:00:48 +0200 (CEST) Date: Thu, 15 Apr 2004 12:00:48 +0200 From: Bogdan TARU To: Landry Brunel Message-ID: <20040415100048.GB65263@icomag.de> Mail-Followup-To: Landry Brunel , freebsd-net@freebsd.org References: <200404150954.JAA26977@foehn.cmo-tlse.shom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404150954.JAA26977@foehn.cmo-tlse.shom.fr> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by AMaViS cc: freebsd-net@freebsd.org Subject: Re: TCP/UDP dynamic port range X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 10:01:01 -0000 Hi Landry, You might wanna check the following sysctls: net.inet.ip.portrange.hifirst net.inet.ip.portrange.hilast Regards, bogdan On Thu, Apr 15, 2004 at 11:52:03AM +0200, Landry Brunel wrote: > > Does someone knows how to change the dynamic TCP/UDP port range. > I'd like to tune it like on sparc/solaris : 32768->65535 . > > Thank's a lot, > Landry. > > > _______________________________________________ > 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 Thu Apr 15 05:00:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B42A16A4CE for ; Thu, 15 Apr 2004 05:00:14 -0700 (PDT) Received: from www.freshx.de (freshx.de [80.190.100.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C5F143D31 for ; Thu, 15 Apr 2004 05:00:13 -0700 (PDT) (envelope-from kai@freshx.de) Received: from localhost (unknown [127.0.0.1]) by www.freshx.de (Postfix) with ESMTP id A0DB815E350; Thu, 15 Apr 2004 14:00:12 +0200 (CEST) Received: from localhost (unknown [127.0.0.1]) by www.freshx.de (Postfix) with ESMTP id 4D57715E33F; Thu, 15 Apr 2004 14:00:12 +0200 (CEST) Received: from 127.0.0.1 ( [127.0.0.1]) as user dust0005@localhost by localhost with HTTP; Thu, 15 Apr 2004 14:00:12 +0200 Message-ID: <1082030412.407e794c3ece3@localhost> Date: Thu, 15 Apr 2004 14:00:12 +0200 From: Kai Mosebach To: Mike Silbersack References: <1081948400.407d38f081851@localhost> <20040415022517.X84867@odysseus.silby.com> In-Reply-To: <20040415022517.X84867@odysseus.silby.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Virus-Scanned: by AMaViS 0.3.12 cc: freebsd-net@freebsd.org cc: Kai Mosebach Subject: Re: Bridging problems on 5.2-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 12:00:14 -0000 Hello Mike, That helped, Thanks! even though it seems a litte odd to me :), especially because xl0 is the "main" network, and the wireless one is only an "addon" ... up to now, i dont see any MAC-addr-toggle-warnings. Best Kai > > On Wed, 14 Apr 2004, Kai Mosebach wrote: > > > Dear list, > > > > recently i tried to setup a wireless bridge onto my freebsd 5.2 server. > > > > i followed the instructions on the ath manpage and set the bridge up with > : > > > > ifconfig ath0 inet up > > sysctl net.link.ether.bridge.enable=1 > > sysctl net.link.ether.bridge.config="ath0 xl0" > > sysctl net.inet.ip.forwarding=1 > > > > the ath interface has no ip adress, but xl0 has. > > I'm using a similar setup on 4.x (with wi in place of ath), and it works > reasonably well. The one difference is that I did assign an IP address to > the wireless interface, although I always communicate with the LAN IP > address. > > Note that one problem the FreeBSD arp code has (as of now) is that it > isn't really multi-interface aware; you'll see lots of messages on the > wireless client where it sees the lan IP moving back and forth between the > MAC addresses of the wireless and LAN cards. Is it possible that this > behavior is confusing your client somehow? > > > now i can ping all of my lan-clients from the wireless, excepting the > bridge > > itself. i saw some reports about problems in the bridge module of 4.x so i > > build my kernel with options BRIDGE, but no changes. > > I had problems with the module under 4.x, so I am using BRIDGE in the > kernel config as well. > > > the second problem is, that i have a DSL router on my cabled segment, which > is > > pingable from wireless, but setting it as default gw and DNS server on the > > wireless client is not working, internet access is not possible. > > > > any ideas ? > > > > best Kai > > Maybe the second problem is part of the first problem manifesting itself > in a different way. > > Mike "Silby" Silbersack > > > From owner-freebsd-net@FreeBSD.ORG Thu Apr 15 05:35:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5407816A4CE for ; Thu, 15 Apr 2004 05:35:06 -0700 (PDT) Received: from hotmail.com (bay14-f14.bay14.hotmail.com [64.4.49.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 337D943D54 for ; Thu, 15 Apr 2004 05:35:04 -0700 (PDT) (envelope-from monicadomingues@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 15 Apr 2004 05:35:04 -0700 Received: from 193.137.232.15 by by14fd.bay14.hotmail.msn.com with HTTP; Thu, 15 Apr 2004 12:35:03 GMT X-Originating-IP: [193.137.232.15] X-Originating-Email: [monicadomingues@hotmail.com] X-Sender: monicadomingues@hotmail.com From: "Mónica Domingues" To: freebsd-net@freebsd.org Date: Thu, 15 Apr 2004 12:35:03 +0000 Message-ID: X-OriginalArrivalTime: 15 Apr 2004 12:35:04.0135 (UTC) FILETIME=[13B02570:01C422E6] MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: pim6sd configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 12:35:06 -0000 Hi, I'am configuring a SSM multicast router, for that I'am using pim6sd. So, I'am FreeBSD with kame snap kit and I had install pim6sd. At the moment, Itrying to configure the routing daemon and I'am having some difficulties... So, in file /etc/rc.conf I have: mroute6d_enable ="YES" mroute6d_program="usr/local/v6/sbin/pim6sd" In file /etc/pim6sd.conf I have: phyint xl1 mld_version 2; When I open pim6sd.log I don't have any log, is this normal? I'am I doing this the right way? Thank's for the attention. Waiting for reply. Mónica Domingues _________________________________________________________________ The new [1]MSN 8: smart spam protection and 2 months FREE* References 1. http://g.msn.com/8HMBEN/2737??PS= From owner-freebsd-net@FreeBSD.ORG Thu Apr 15 05:39:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED7E916A4CE for ; Thu, 15 Apr 2004 05:39:56 -0700 (PDT) Received: from hotmail.com (bay13-dav66.bay13.hotmail.com [64.4.31.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFD1B43D48 for ; Thu, 15 Apr 2004 05:39:56 -0700 (PDT) (envelope-from naga_raju_@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 15 Apr 2004 05:39:57 -0700 Received: from 203.200.20.226 by bay13-dav66.bay13.hotmail.com with DAV; Thu, 15 Apr 2004 12:39:57 +0000 X-Originating-IP: [203.200.20.226] X-Originating-Email: [naga_raju_@hotmail.com] X-Sender: naga_raju_@hotmail.com From: "Nagaraju" To: References: <20040414190205.7AE6516A4D1@hub.freebsd.org> Date: Thu, 15 Apr 2004 18:04:46 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: X-OriginalArrivalTime: 15 Apr 2004 12:39:57.0447 (UTC) FILETIME=[C2840170:01C422E6] Subject: How do tt_timerq and tmerq manage tcp syncache? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 12:39:57 -0000 Hi, In FreeBSD 4.9, tcp_syncache implements a hash table with buckets, where an entry is created on SYN request. Function syncache_timer takes care of SYN-ACK retransmissions and removing old entries from syncache. It uses two variables timerq (array of link lists) and tt_timerq (array of callouts). Size of both arrays is SYNCACHE_MAXREXMTS+1. (SYNCACHE_MAXREXMTS = 3) Can someone explain, how these two variable do manage, required functionality (removing old entries and retransmitting SYN-ACK etc)? Thanks&Regards, Nagaraju. From owner-freebsd-net@FreeBSD.ORG Thu Apr 15 07:25:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0674A16A4CE for ; Thu, 15 Apr 2004 07:25:24 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D95F43D41 for ; Thu, 15 Apr 2004 07:25:21 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i3FEPKFC021208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Apr 2004 10:25:21 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i3FEPFAs062441; Thu, 15 Apr 2004 10:25:15 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16510.39755.286235.774704@grasshopper.cs.duke.edu> Date: Thu, 15 Apr 2004 10:25:15 -0400 (EDT) To: Christophe Prevotaux In-Reply-To: <20040414143732.3b13b54e.c.prevotaux@hexanet.fr> References: <20040414143732.3b13b54e.c.prevotaux@hexanet.fr> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: net@freebsd.org Subject: Re: 4Gbps in PCI-X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 14:25:24 -0000 Christophe Prevotaux writes: > Hi, > > Is anyone working or planning to work on these babies support > for FreeBSD ? > > http://www.astutenetworks.com/content/product/superhba.htm Not that I know of, but if you need 4Gb/sec, have you considered Myrinet? I do the driver support for FreeBSD at Myricom. We've supported FreeBSD for quite some time. Our latest PCIXE PCI-X host interfaces support full duplex 4Gb/sec operation. For ethernet encapsulation, you get a big fat pipe that can do 3.85Gb/sec for a single TCP stream (as measured by netperf by me on hosts running 4.8-STABLE). This acts like a normal ethernet interface, and can interect with normal ethernet hosts (assuming approprite protocol conversion in the middle, which we also sell). If you're willing to program to a different API (GM, or MX), you can make use of OS-bypass operation, which reduces host cpu load to near zero at the cost of using a non-sockets API. See our web site for more details. http://www.myri.com/ Currently, our main customer base is large linux clusters that use the OS-bypass side of our nics. It would be nice to get more FreeBSD users. It would certainly make it easier to for me to justify time spent on our FreeBSD drivers ;) Drew From owner-freebsd-net@FreeBSD.ORG Thu Apr 15 10:22:16 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D86216A4CE for ; Thu, 15 Apr 2004 10:22:16 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id B094F43D4C for ; Thu, 15 Apr 2004 10:22:15 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 65909 invoked from network); 15 Apr 2004 17:22:15 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 15 Apr 2004 17:22:15 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 15 Apr 2004 12:45:42 -0500 (CDT) From: Mike Silbersack To: Bogdan TARU In-Reply-To: <20040415100048.GB65263@icomag.de> Message-ID: <20040415124451.K81022@odysseus.silby.com> References: <200404150954.JAA26977@foehn.cmo-tlse.shom.fr> <20040415100048.GB65263@icomag.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Landry Brunel cc: freebsd-net@freebsd.org Subject: Re: TCP/UDP dynamic port range X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 17:22:16 -0000 On Thu, 15 Apr 2004, Bogdan TARU wrote: > Hi Landry, > > You might wanna check the following sysctls: > > net.inet.ip.portrange.hifirst > net.inet.ip.portrange.hilast > > Regards, > bogdan net.inet.ip.portrange.last and net.inet.ip.portrange.first are what he really wants to change; hifirst and hilist are only used by a small subset of applications, first and last are used by most applications. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Fri Apr 16 02:52:48 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85BF616A4CE for ; Fri, 16 Apr 2004 02:52:48 -0700 (PDT) Received: from kogut3.o2.pl (kogut3.go2.pl [212.126.20.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BFBB43D2D for ; Fri, 16 Apr 2004 02:52:45 -0700 (PDT) (envelope-from knockefreebsd@o2.pl) Received: from ALFA (rekin7.go2.pl [212.126.20.19]) by kogut3.o2.pl (Postfix) with ESMTP id 721E977E52 for ; Fri, 16 Apr 2004 11:52:40 +0200 (CEST) Message-ID: <013e01c42398$92d8cf20$03ce8f0a@ALFA> From: "Knocke" To: References: <001901c41eee$3f09c0b0$df5561d9@ALFA> <20040410120027.GC710@empiric.dek.spc.org> <003901c41f02$b31ec3b0$df5561d9@ALFA> <4077FE82.7040308@netli.com> <003101c41fa7$2cb9cc70$df5561d9@ALFA> <20040412160604.GH710@empiric.dek.spc.org> <003001c420ab$b56925c0$df5561d9@ALFA> <20040412164116.GI710@empiric.dek.spc.org> Date: Fri, 16 Apr 2004 11:52:37 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: [nwebe] How to track TCP socket variables? (cwnd, ssthresh) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2004 09:52:48 -0000 > SO_DEBUG collection only happens if it's enabled as a socket option. so its ok for the production system? I've experienced problems with TCPDEBUG on FreeBSD 5-2Curr (on 4-9 it works already thanks to your suggestions :) - kernel TCPDEBUG, sockets are open with SO_DEBUG, but trtp can't see any track records. Is there a systctl variable needed to turn it on? hk From owner-freebsd-net@FreeBSD.ORG Fri Apr 16 17:48:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A892C16A4CE for ; Fri, 16 Apr 2004 17:48:47 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 1AD7243D3F for ; Fri, 16 Apr 2004 17:48:47 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 86833 invoked from network); 17 Apr 2004 00:48:45 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 17 Apr 2004 00:48:45 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 16 Apr 2004 20:13:52 -0500 (CDT) From: Mike Silbersack To: Kai Mosebach In-Reply-To: <1082030412.407e794c3ece3@localhost> Message-ID: <20040416201147.U5751@odysseus.silby.com> References: <1081948400.407d38f081851@localhost> <20040415022517.X84867@odysseus.silby.com> <1082030412.407e794c3ece3@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Bridging problems on 5.2-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2004 00:48:47 -0000 On Thu, 15 Apr 2004, Kai Mosebach wrote: > Hello Mike, > > That helped, Thanks! even though it seems a litte odd to me :), especially > because xl0 is the "main" network, and the wireless one is only an "addon" ... > > up to now, i dont see any MAC-addr-toggle-warnings. > > Best Kai Hm, interesting. I know that Andre and Luigi have been making some changes to the routing code and are now targetting the arp code for an update. Perhaps changes in 5.x relative to 4.x have fixed the mac address switching problem already. Mike "Silby" Silbersack