From owner-freebsd-net@FreeBSD.ORG Sun Feb 12 06:58:29 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D89E616A420 for ; Sun, 12 Feb 2006 06:58:29 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C75943D48 for ; Sun, 12 Feb 2006 06:58:29 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 54F521A3C1B; Sat, 11 Feb 2006 22:58:29 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 737B75152B; Sun, 12 Feb 2006 01:58:28 -0500 (EST) Date: Sun, 12 Feb 2006 01:58:28 -0500 From: Kris Kennaway To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20060212065828.GA56138@xor.obsecurity.org> References: <20060116004438.GA27901@xor.obsecurity.org> <20060207054502.GA18560@xor.obsecurity.org> <20060211035025.GA77114@xor.obsecurity.org> <20060211071411.GA82302@xor.obsecurity.org> <20060211073123.AA7002E35A@impact.jinmei.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <20060211073123.AA7002E35A@impact.jinmei.org> User-Agent: Mutt/1.4.2.1i Cc: net@FreeBSD.org, Kris Kennaway Subject: Re: Changing time causes ipv6 panics X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2006 06:58:30 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 11, 2006 at 04:31:23PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Sat, 11 Feb 2006 02:14:11 -0500,=20 > >>>>> Kris Kennaway said: >=20 > >> >> Sorry, not really (we've not got a test environment to reproduce it= ). > >> >> But from a quick review of nd6.c, there seems to be one thing that = is > >> >> obviously wrong. The possible bug has been there since rev. 1.19 > >> >> committed in April 2002. We've been probably just lucky so far... > >> >>=20 > >> >> Could you try the patch attached below? We'll probably also need to > >> >> apply this fix to 4.X and 5.X. > >>=20 > >> > The patch did not fix the panic. > >>=20 > >> Hmm, but this time the point where the panic happened should be > >> different. Can you identify where it was? >=20 > > I reduced the hw.physmem size and was able to get a dump: >=20 > > (kgdb) frame 10 >=20 > > #10 0xffffffff80333a86 in nd6_timer (ignored_arg=3D0xffffffff8059ab60) = at ../../../netinet6/nd6.c:585 > > 585 ia6->ia6_flags |=3D IN6_IFF_DEPRECATED; >=20 > Are you sure you applied the patch? In the 'patched' version of > nd6.c, line 585 is blank, so at least it doesn't match the above > backtrace. Sorry, you're right - what was happening was that I'd apply the patch, then go to build the kernel and realise the time was still wrong, then run ntpdate and it would panic again, and because of soft updates the patch hadn't been synced yet and it would be gone when I rebooted again. In fact I cannot seem to reproduce the panic with the patch successfully applied. Next I'll test David's patch. Kris --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD7tyTWry0BWjoQKURAt7AAJ90BhTZLHnUwIV8ZaFUaIjNEqARfACgla8f bFm3hAxwlZspp5Y9g/5cTn8= =j9Mt -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- From owner-freebsd-net@FreeBSD.ORG Sun Feb 12 07:11:40 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3579916A420 for ; Sun, 12 Feb 2006 07:11:40 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id C947343D45 for ; Sun, 12 Feb 2006 07:11:39 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from impact.jinmei.org (unknown [2001:200:0:8002:f80e:26e5:a011:664b]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 96A0A15231; Sun, 12 Feb 2006 16:11:38 +0900 (JST) Date: Sun, 12 Feb 2006 16:11:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Kris Kennaway In-Reply-To: <20060212065828.GA56138@xor.obsecurity.org> References: <20060116004438.GA27901@xor.obsecurity.org> <20060207054502.GA18560@xor.obsecurity.org> <20060211035025.GA77114@xor.obsecurity.org> <20060211071411.GA82302@xor.obsecurity.org> <20060211073123.AA7002E35A@impact.jinmei.org> <20060212065828.GA56138@xor.obsecurity.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: net@FreeBSD.org Subject: Re: Changing time causes ipv6 panics X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2006 07:11:40 -0000 >>>>> On Sun, 12 Feb 2006 01:58:28 -0500, >>>>> Kris Kennaway said: >> Are you sure you applied the patch? In the 'patched' version of >> nd6.c, line 585 is blank, so at least it doesn't match the above >> backtrace. > Sorry, you're right - what was happening was that I'd apply the patch, > then go to build the kernel and realise the time was still wrong, then > run ntpdate and it would panic again, and because of soft updates the > patch hadn't been synced yet and it would be gone when I rebooted > again. > In fact I cannot seem to reproduce the panic with the patch > successfully applied. Okay, glad to hear that. Thanks for reporting the problem and testing the patch. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Sun Feb 12 12:51:34 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A2F816A420 for ; Sun, 12 Feb 2006 12:51:34 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBBF143D70 for ; Sun, 12 Feb 2006 12:51:28 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 90331D9; Sun, 12 Feb 2006 07:51:49 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 30E8CCE42; Sun, 12 Feb 2006 07:51:48 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8GhI-0005J6-VM; Sun, 12 Feb 2006 12:51:24 +0000 Date: Sun, 12 Feb 2006 12:51:24 +0000 From: Brian Candler To: GiZmen Message-ID: <20060212125124.GA20369@uk.tiscali.com> References: <20060211163533.GA87353@blurp.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060211163533.GA87353@blurp.pl> User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: fastforward problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2006 12:51:34 -0000 On Sat, Feb 11, 2006 at 05:35:33PM +0100, GiZmen wrote: > I would like to use fastforward option on my freebsd 6.0-stable > box. But i have strange problem with it. My box is a router for LAN > with IP visible to internet. I am managinc C class network. > When i turn on fastforward option any of the computers in my network > can't open google.com page. This option is quite good because i have > quite a lot interrupts and this option lower this about half. > Could anyone tell me why i can't open google.com page ? > I have tested different pages and i don't have such problem only with > google. Just saying "I can't see google.com" is not a good diagnosis of the problem. If it's your job to manage a router, then you need to be able to do lower- level tests to isolate the problem. Check each of the components in turn: (1) can my client resolve google.com in the DNS? If the client is some sort of Unix then try $ nslookup google.com You should see a response such as: Non-authoritative answer: Name: google.com Address: 72.14.207.99 Name: google.com Address: 64.233.187.99 Name: google.com Address: 64.233.167.99 (2) can my client ping these addresses? That is, is there layer 3 network reachability between my network and theirs? $ ping 72.14.207.99 PING 72.14.207.99 (72.14.207.99): 56 data bytes 64 bytes from 72.14.207.99: icmp_seq=1 ttl=238 time=133.730 ms 64 bytes from 72.14.207.99: icmp_seq=2 ttl=237 time=133.179 ms 64 bytes from 72.14.207.99: icmp_seq=3 ttl=238 time=133.316 ms 64 bytes from 72.14.207.99: icmp_seq=4 ttl=237 time=133.396 ms ^C --- 72.14.207.99 ping statistics --- 5 packets transmitted, 4 packets received, 20% packet loss round-trip min/avg/max/stddev = 133.179/133.405/133.730/0.203 ms (3) what happens when I open a TCP/IP connection to port 80, and manually fetch a HTTP page? $ telnet 72.14.207.99 80 Trying 72.14.207.99... Connected to 72.14.207.99. Escape character is '^]'. GET / HTTP/1.0 Host: google.com <<<<< end with a blank line HTTP/1.0 301 Moved Permanently Location: http://www.google.com/ Set-Cookie: PREF=ID=f811e9355f349c08:TM=1139748428:LM=1139748428:S=UhZOEU98p2mnw_H0; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com Content-Type: text/html Server: GWS/2.1 Content-Length: 219 Date: Sun, 12 Feb 2006 12:47:08 GMT Connection: Keep-Alive 301 Moved

301 Moved

The document has moved here. Connection closed by foreign host. OK, that's fine. google.com has redirected me to www.google.com. So try the whole process again with www.google.com instead of google.com Brian. From owner-freebsd-net@FreeBSD.ORG Sun Feb 12 15:38:44 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC20A16A420 for ; Sun, 12 Feb 2006 15:38:44 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 337EB43D45 for ; Sun, 12 Feb 2006 15:38:40 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:d+GUw8x8fITieYgY7k16MsU+nDuazgkT4xJm060y7AzOLRpcBOD7kh+1PRZbLqCb@kasuga-iwi.mahoroba.org [IPv6:3ffe:501:185b:8010:212:f0ff:fe52:6ac]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.4/8.13.4) with ESMTP/inet6 id k1CFcXA0066176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2006 00:38:33 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 13 Feb 2006 00:38:33 +0900 Message-ID: From: Hajimu UMEMOTO To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: References: <20060116004438.GA27901@xor.obsecurity.org> <20060207054502.GA18560@xor.obsecurity.org> <20060211035025.GA77114@xor.obsecurity.org> <20060211071411.GA82302@xor.obsecurity.org> <20060211073123.AA7002E35A@impact.jinmei.org> <20060212065828.GA56138@xor.obsecurity.org> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.1) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.1-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.1.3 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Mon, 13 Feb 2006 00:38:35 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on ameno.mahoroba.org Cc: net@FreeBSD.org, Kris Kennaway Subject: Re: Changing time causes ipv6 panics X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2006 15:38:44 -0000 Hi, >>> Sun, 12 Feb 2006 16:11:28 +0900 $B$N9o$K!V(Bjinmei$B!W!"$9$J$o$A(B >>> JINMEI Tatuya / $B?@L@C#:H(B $B;a[)$/(B >>>>> On Sun, 12 Feb 2006 01:58:28 -0500, >>>>> Kris Kennaway said: >> Are you sure you applied the patch? In the 'patched' version of >> nd6.c, line 585 is blank, so at least it doesn't match the above >> backtrace. > Sorry, you're right - what was happening was that I'd apply the patch, > then go to build the kernel and realise the time was still wrong, then > run ntpdate and it would panic again, and because of soft updates the > patch hadn't been synced yet and it would be gone when I rebooted > again. > In fact I cannot seem to reproduce the panic with the patch > successfully applied. jinmei> Okay, glad to hear that. Thanks for reporting the problem and testing jinmei> the patch. I've just committed it into HEAD. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Sun Feb 12 19:31:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73B8C16A422 for ; Sun, 12 Feb 2006 19:31:26 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F87243D62 for ; Sun, 12 Feb 2006 19:31:17 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) From: Nate Nielsen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Dowse , "freebsd-net@FreeBSD.org" References: <200602121448.aa27129@nowhere.iedowse.com> Content-Type: multipart/mixed; boundary="------------020405020406030808060806" Message-Id: <20060212193948.82865DCA997@mail.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Sun, 12 Feb 2006 19:39:50 +0000 (GMT) Cc: Subject: Re: Panic Kernel Dump to umass device? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nielsen@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2006 19:31:26 -0000 This is a multi-part message in MIME format. --------------020405020406030808060806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ian Dowse wrote: > In message <20060212051359.EB6FEDCA995@mail.npubs.com>, Nate Nielsen writes: > >>Thanks, that helps. It works nicely with a uhci USB controller. >> >>However when the ohci driver is in use, we crash somewhere in >>usb_transfer_complete. I'll look into this further. > > You could try updating to the latest 6-stable usb code, which might > possibly help the ohci case. There were a number of quite severe > ohci issues fixed since 6.0-release that might trigger more easily > when using polling. In particular, these revisions may be of interest: > > ohci.c 1.154.2.1 > ohcivar.h 1.40.2.1 > usbdi.c 1.91.2.1 Yes, since I last posted, I saw those fixes in CVS and patched them in, this helps fix the usb_transfer_complete problem I was describing. However, I'm still running into trouble. Attached are two files of debug messages. These debug messages were produced using 'options USB_DEBUG' and 'sysctl hw.usb.ohci.debug = 9' In the first (normal-transfer.txt) are the messages from writing 512 bytes to a USB drive via dd (and obviously dd does more than just open(), write(), close()...). In the second file (umass-ohci-dump.txt) are the messages from of a failed kernel dump. Something goes awry with the descriptor lists, and there's a panic (triggered directly by the code): panic: ohci_add_done: addr 0x00161d20 not found BTW, thanks for the help so far... Cheers, Nate --------------020405020406030808060806 Content-Type: text/plain; name="normal-transfer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="normal-transfer.txt" test-link:~ # dd if=/dev/zero of=/dev/da0 bs=512 count=1 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f60 headflags=161f60 headp=0x00161f60 nexted=0x00000000 TD(0xc0aedf60) at 00161f60: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f90 be=0x05ca5f5e TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x26(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0abf800 len=8 isread=1 flags=4 endpt=129 ohci_alloc_std_chain: start len=8 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=8 curlen=8 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0340000 td_cbp=0x05ca5f40 td_be=0x05ca5f47 ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161ed0 headflags=161ed2 headp=0x00161ed2 nexted=0x00135780 TD(0xc0aeded0) at 00161ed0: f0340000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f47 TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f60 headflags=161f60 headp=0x00161f60 nexted=0x00135780 TD(0xc0aedf60) at 00161f60: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161ed0 be=0x05ca5f4c TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f90 headflags=161f92 headp=0x00161f92 nexted=0x00000000 TD(0xc0aedf90) at 00161f90: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f5e TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161ed0 headflags=161ed2 headp=0x00161ed2 nexted=0x00135780 TD(0xc0aeded0) at 00161ed0: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f90 be=0x05ca5f4c TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f60 headflags=161f60 headp=0x00161f60 nexted=0x00000000 TD(0xc0aedf60) at 00161f60: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161ed0 be=0x05ca5f5e TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0abf800 len=32 isread=1 flags=4 endpt=129 ohci_alloc_std_chain: start len=32 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=32 curlen=32 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0340000 td_cbp=0x05ca5f40 td_be=0x05ca5f5f ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f90 headflags=161f90 headp=0x00161f90 nexted=0x00135780 TD(0xc0aedf90) at 00161f90: f0340000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f5f TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f60 headflags=161f62 headp=0x00161f62 nexted=0x00135780 TD(0xc0aedf60) at 00161f60: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f90 be=0x05ca5f4c TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161ed0 headflags=161ed2 headp=0x00161ed2 nexted=0x00000000 TD(0xc0aeded0) at 00161ed0: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f5e TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0abf800 len=512 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=512 ohci_alloc_std_chain: dataphys=0x00191000 len=512 curlen=512 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x00191000 td_be=0x001911ff ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f60 headflags=161f60 headp=0x00161f60 nexted=0x00000000 TD(0xc0aedf60) at 00161f60: f0280000 delay=1 ec=0 cc=15 cbp=0x00191000 nexttd=0x00161ed0 be=0x001911ff TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f90 headflags=161f90 headp=0x00161f90 nexted=0x00135780 TD(0xc0aedf90) at 00161f90: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f4c TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 1+0 records in 1+0 records out 512 bytes transfoerred in 2.52394h0 secs (203 bytecs/sec) i_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161ed0 headflags=161ed0 headp=0x00161ed0 nexted=0x00000000 TD(0xc0aeded0) at 00161ed0: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f90 be=0x05ca5f5e TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f60 headflags=161f62 headp=0x00161f62 nexted=0x00135780 TD(0xc0aedf60) at 00161f60: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161ed0 be=0x05ca5f4c TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f90 headflags=161f92 headp=0x00161f92 nexted=0x00000000 TD(0xc0aedf90) at 00161f90: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f5e TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161ed0 headflags=161ed0 headp=0x00161ed0 nexted=0x00135780 TD(0xc0aeded0) at 00161ed0: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f90 be=0x05ca5f4c TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f60 headflags=161f60 headp=0x00161f60 nexted=0x00000000 TD(0xc0aedf60) at 00161f60: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161ed0 be=0x05ca5f5e TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0abf800 len=8 isread=1 flags=4 endpt=129 ohci_alloc_std_chain: start len=8 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=8 curlen=8 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0340000 td_cbp=0x05ca5f40 td_be=0x05ca5f47 ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f90 headflags=161f92 headp=0x00161f92 nexted=0x00135780 TD(0xc0aedf90) at 00161f90: f0340000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f47 TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f60 headflags=161f60 headp=0x00161f60 nexted=0x00135780 TD(0xc0aedf60) at 00161f60: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f90 be=0x05ca5f4c TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161ed0 headflags=161ed2 headp=0x00161ed2 nexted=0x00000000 TD(0xc0aeded0) at 00161ed0: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f5e TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f90 headflags=161f92 headp=0x00161f92 nexted=0x00135780 TD(0xc0aedf90) at 00161f90: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161ed0 be=0x05ca5f4c TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f60 headflags=161f60 headp=0x00161f60 nexted=0x00000000 TD(0xc0aedf60) at 00161f60: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f90 be=0x05ca5f5e TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0abf800 len=32 isread=1 flags=4 endpt=129 ohci_alloc_std_chain: start len=32 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=32 curlen=32 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0340000 td_cbp=0x05ca5f40 td_be=0x05ca5f5f ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161ed0 headflags=161ed0 headp=0x00161ed0 nexted=0x00135780 TD(0xc0aeded0) at 00161ed0: f0340000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f5f TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f60 headflags=161f62 headp=0x00161f62 nexted=0x00135780 TD(0xc0aedf60) at 00161f60: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161ed0 be=0x05ca5f4c TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f90 headflags=161f92 headp=0x00161f92 nexted=0x00000000 TD(0xc0aedf90) at 00161f90: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f5e TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x26(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0abf800 len=512 isread=1 flags=4 endpt=129 ohci_alloc_std_chain: start len=512 ohci_alloc_std_chain: dataphys=0x00191000 len=512 curlen=512 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0340000 td_cbp=0x00191000 td_be=0x001911ff ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161ed0 headflags=161ed0 headp=0x00161ed0 nexted=0x00135780 TD(0xc0aeded0) at 00161ed0: f0340000 delay=1 ec=0 cc=15 cbp=0x00191000 nexttd=0x00161f90 be=0x001911ff TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f90 headflags=161f90 headp=0x00161f90 nexted=0x00135780 TD(0xc0aedf90) at 00161f90: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161ed0 be=0x05ca5f4c TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f60 headflags=161f60 headp=0x00161f60 nexted=0x00000000 TD(0xc0aedf60) at 00161f60: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f90 be=0x05ca5f5e TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161ed0 headflags=161ed2 headp=0x00161ed2 nexted=0x00135780 TD(0xc0aeded0) at 00161ed0: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f4c TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f90 headflags=161f92 headp=0x00161f92 nexted=0x00000000 TD(0xc0aedf90) at 00161f90: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161ed0 be=0x05ca5f5e TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f60 headflags=161f60 headp=0x00161f60 nexted=0x00135780 TD(0xc0aedf60) at 00161f60: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f90 be=0x05ca5f4c TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161ed0 headflags=161ed0 headp=0x00161ed0 nexted=0x00000000 TD(0xc0aeded0) at 00161ed0: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f5e TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0abf800 len=8 isread=1 flags=4 endpt=129 ohci_alloc_std_chain: start len=8 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=8 curlen=8 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0340000 td_cbp=0x05ca5f40 td_be=0x05ca5f47 ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f90 headflags=161f92 headp=0x00161f92 nexted=0x00135780 TD(0xc0aedf90) at 00161f90: f0340000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161ed0 be=0x05ca5f47 TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161ed0 headflags=161ed0 headp=0x00161ed0 nexted=0x00135780 TD(0xc0aeded0) at 00161ed0: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f90 be=0x05ca5f4c TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f60 headflags=161f62 headp=0x00161f62 nexted=0x00000000 TD(0xc0aedf60) at 00161f60: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161ed0 be=0x05ca5f5e TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f90 headflags=161f92 headp=0x00161f92 nexted=0x00135780 TD(0xc0aedf90) at 00161f90: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f4c TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161ed0 headflags=161ed0 headp=0x00161ed0 nexted=0x00000000 TD(0xc0aeded0) at 00161ed0: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f90 be=0x05ca5f5e TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0abf800 len=32 isread=1 flags=4 endpt=129 ohci_alloc_std_chain: start len=32 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=32 curlen=32 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0340000 td_cbp=0x05ca5f40 td_be=0x05ca5f5f ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f60 headflags=161f60 headp=0x00161f60 nexted=0x00135780 TD(0xc0aedf60) at 00161f60: f0340000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161ed0 be=0x05ca5f5f TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161ed0 headflags=161ed2 headp=0x00161ed2 nexted=0x00135780 TD(0xc0aeded0) at 00161ed0: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f4c TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f90 headflags=161f92 headp=0x00161f92 nexted=0x00000000 TD(0xc0aedf90) at 00161f90: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161ed0 be=0x05ca5f5e TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0abf800 len=512 isread=1 flags=4 endpt=129 ohci_alloc_std_chain: start len=512 ohci_alloc_std_chain: dataphys=0x00191000 len=512 curlen=512 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0340000 td_cbp=0x00191000 td_be=0x001911ff ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f60 headflags=161f60 headp=0x00161f60 nexted=0x00135780 TD(0xc0aedf60) at 00161f60: f0340000 delay=1 ec=0 cc=15 cbp=0x00191000 nexttd=0x00161f90 be=0x001911ff TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f90 headflags=161f90 headp=0x00161f90 nexted=0x00135780 TD(0xc0aedf90) at 00161f90: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f4c TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161ed0 headflags=161ed0 headp=0x00161ed0 nexted=0x00000000 TD(0xc0aeded0) at 00161ed0: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f90 be=0x05ca5f5e TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0abf800 len=512 isread=1 flags=4 endpt=129 ohci_alloc_std_chain: start len=512 ohci_alloc_std_chain: dataphys=0x00191000 len=512 curlen=512 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0340000 td_cbp=0x00191000 td_be=0x001911ff ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f60 headflags=161f62 headp=0x00161f62 nexted=0x00135780 TD(0xc0aedf60) at 00161f60: f0340000 delay=1 ec=0 cc=15 cbp=0x00191000 nexttd=0x00161ed0 be=0x001911ff TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161ed0 headflags=161ed2 headp=0x00161ed2 nexted=0x00135780 TD(0xc0aeded0) at 00161ed0: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f4c TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f90 headflags=161f92 headp=0x00161f92 nexted=0x00000000 TD(0xc0aedf90) at 00161f90: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161ed0 be=0x05ca5f5e TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f60 headflags=161f60 headp=0x00161f60 nexted=0x00135780 TD(0xc0aedf60) at 00161f60: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f90 be=0x05ca5f4c TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161ed0 headflags=161ed0 headp=0x00161ed0 nexted=0x00000000 TD(0xc0aeded0) at 00161ed0: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f5e TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f90 headflags=161f92 headp=0x00161f92 nexted=0x00135780 TD(0xc0aedf90) at 00161f90: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161ed0 be=0x05ca5f4c TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 --------------020405020406030808060806 Content-Type: text/plain; name="umass-ohci-dump.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="umass-ohci-dump.txt" test-link:~ # kldload crash Crash Mod KLD loaded. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc0cdd412 stack pointer = 0x28:0xc705cc1c frame pointer = 0x28:0xc705cc24 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 639 (kldload) [thread pid 639 tid 100070 ] Stopped at crash_loader+0x22: movb $0x61,0 db> panic panic: from debugger Uptime: 2h54m56s Dumping 95 MB (2 chunks) ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f90 headflags=161f90 headp=0x00161f90 nexted=0x00000000 TD(0xc0aedf90) at 00161f90: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161ed0 be=0x05ca5f5e TD(0xc0aeded0) at 00161ed0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x26(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0abf800 len=512 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=512 ohci_alloc_std_chain: dataphys=0x00191000 len=512 curlen=512 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x00191000 td_be=0x001911ff ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161ed0 headflags=161ed2 headp=0x00161ed2 nexted=0x00000000 TD(0xc0aeded0) at 00161ed0: f0280000 delay=1 ec=0 cc=15 cbp=0x00191000 nexttd=0x00161f90 be=0x001911ff TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_device_bulk_start: xfer=0xc0abf800 len=512 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=512 ohci_alloc_std_chain: dataphys=0x00191000 len=512 curlen=512 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x00191000 td_be=0x001911ff ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f90 headflags=161f92 headp=0x00161f92 nexted=0x00000000 TD(0xc0aedf90) at 00161f90: f0280000 delay=1 ec=0 cc=15 cbp=0x00191000 nexttd=0x00161fc0 be=0x001911ff TD(0xc0aedfc0) at 00161fc0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f60 headflags=161f62 headp=0x00161f62 nexted=0x00135780 TD(0xc0aedf60) at 00161f60: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f90 be=0x05ca5f4c TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161fc0 headflags=161fc2 headp=0x00161fc2 nexted=0x00000000 TD(0xc0aedfc0) at 00161fc0: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f60 be=0x05ca5f5e TD(0xc0aedf60) at 00161f60: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0abf800 len=512 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=512 ohci_alloc_std_chain: dataphys=0x00191000 len=512 curlen=512 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x00191000 td_be=0x001911ff ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f60 headflags=161f60 headp=0x00161f60 nexted=0x00000000 TD(0xc0aedf60) at 00161f60: f0280000 delay=1 ec=0 cc=15 cbp=0x00191000 nexttd=0x00161fc0 be=0x001911ff TD(0xc0aedfc0) at 00161fc0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_device_bulk_start: xfer=0xc0abf800 len=512 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=512 ohci_alloc_std_chain: dataphys=0x00191000 len=512 curlen=512 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x00191000 td_be=0x001911ff ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161fc0 headflags=161fc0 headp=0x00161fc0 nexted=0x00000000 TD(0xc0aedfc0) at 00161fc0: f0280000 delay=1 ec=0 cc=15 cbp=0x00191000 nexttd=0x00161f00 be=0x001911ff TD(0xc0aedf00) at 00161f00: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161f90 headflags=161f90 headp=0x00161f90 nexted=0x00135780 TD(0xc0aedf90) at 00161f90: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161fc0 be=0x05ca5f4c TD(0xc0aedfc0) at 00161fc0: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 chunk 0: 1MB (159 pages)ohci_device_bulk_start: xfer=0xc0ae6700 len=31 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=31 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=31 curlen=31 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0280000 td_cbp=0x05ca5f40 td_be=0x05ca5f5e ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f00 headflags=161f00 headp=0x00161f00 nexted=0x00000000 TD(0xc0aedf00) at 00161f00: f0280000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161f90 be=0x05ca5f5e TD(0xc0aedf90) at 00161f90: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0abf800 len=65536 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=65536 ohci_alloc_std_chain: dataphys=0x05be6000 len=65536 curlen=8192 ohci_alloc_std_chain: dataphys=0x05be8000 len=57344 curlen=8192 ohci_alloc_std_chain: dataphys=0x05bea000 len=49152 curlen=8192 ohci_alloc_std_chain: dataphys=0x05bec000 len=40960 curlen=8192 ohci_alloc_std_chain: dataphys=0x05bee000 len=32768 curlen=8192 ohci_alloc_std_chain: dataphys=0x05bf0000 len=24576 curlen=8192 ohci_alloc_std_chain: dataphys=0x05bf2000 len=16384 curlen=8192 ohci_alloc_std_chain: dataphys=0x05bf4000 len=8192 curlen=8192 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0c80000 td_cbp=0x05be6000 td_be=0x05be7fff ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161f90 headflags=161f92 headp=0x00161f92 nexted=0x00000000 TD(0xc0aedf90) at 00161f90: f0c80000 delay=6 ec=0 cc=15 cbp=0x05be6000 nexttd=0x00161f00 be=0x05be7fff TD(0xc0aedf00) at 00161f00: f0c80000 delay=6 ec=0 cc=15 cbp=0x05be8000 nexttd=0x00161ea0 be=0x05be9fff TD(0xc0aedea0) at 00161ea0: f0c80000 delay=6 ec=0 cc=15 cbp=0x05bea000 nexttd=0x00161e70 be=0x05bebfff TD(0xc0aede70) at 00161e70: f0c80000 delay=6 ec=0 cc=15 cbp=0x05bec000 nexttd=0x00161e40 be=0x05bedfff TD(0xc0aede40) at 00161e40: f0c80000 delay=6 ec=0 cc=15 cbp=0x05bee000 nexttd=0x00161e10 be=0x05beffff TD(0xc0aede10) at 00161e10: f0c80000 delay=6 ec=0 cc=15 cbp=0x05bf0000 nexttd=0x00161de0 be=0x05bf1fff TD(0xc0aedde0) at 00161de0: f0c80000 delay=6 ec=0 cc=15 cbp=0x05bf2000 nexttd=0x00161db0 be=0x05bf3fff TD(0xc0aeddb0) at 00161db0: f0280000 delay=1 ec=0 cc=15 cbp=0x05bf4000 nexttd=0x00161d80 be=0x05bf5fff TD(0xc0aedd80) at 00161d80: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_device_bulk_start: xfer=0xc0abf800 len=65536 isread=0 flags=0 endpt=2 ohci_alloc_std_chain: start len=65536 ohci_alloc_std_chain: dataphys=0x05be6000 len=65536 curlen=8192 ohci_alloc_std_chain: dataphys=0x05be8000 len=57344 curlen=8192 ohci_alloc_std_chain: dataphys=0x05bea000 len=49152 curlen=8192 ohci_alloc_std_chain: dataphys=0x05bec000 len=40960 curlen=8192 ohci_alloc_std_chain: dataphys=0x05bee000 len=32768 curlen=8192 ohci_alloc_std_chain: dataphys=0x05bf0000 len=24576 curlen=8192 ohci_alloc_std_chain: dataphys=0x05bf2000 len=16384 curlen=8192 ohci_alloc_std_chain: dataphys=0x05bf4000 len=8192 curlen=8192 ohci_device_bulk_start: ed_flags=0x00400102 td_flags=0xf0c80000 td_cbp=0x05be6000 td_be=0x05be7fff ED(0xc0ac1780) at 0x00135780: addr=2 endpt=2 maxp=64 flags=400102 tailp=0x00161d80 headflags=161d82 headp=0x00161d82 nexted=0x00000000 TD(0xc0aedd80) at 00161d80: f0c80000 delay=6 ec=0 cc=15 cbp=0x05be6000 nexttd=0x00161d50 be=0x05be7fff TD(0xc0aedd50) at 00161d50: f0c80000 delay=6 ec=0 cc=15 cbp=0x05be8000 nexttd=0x00161d20 be=0x05be9fff TD(0xc0aedd20) at 00161d20: f0c80000 delay=6 ec=0 cc=15 cbp=0x05bea000 nexttd=0x00161cf0 be=0x05bebfff TD(0xc0aedcf0) at 00161cf0: f0c80000 delay=6 ec=0 cc=15 cbp=0x05bec000 nexttd=0x00161cc0 be=0x05bedfff TD(0xc0aedcc0) at 00161cc0: f0c80000 delay=6 ec=0 cc=15 cbp=0x05bee000 nexttd=0x00161c90 be=0x05beffff TD(0xc0aedc90) at 00161c90: f0c80000 delay=6 ec=0 cc=15 cbp=0x05bf0000 nexttd=0x00161c60 be=0x05bf1fff TD(0xc0aedc60) at 00161c60: f0c80000 delay=6 ec=0 cc=15 cbp=0x05bf2000 nexttd=0x00161c30 be=0x05bf3fff TD(0xc0aedc30) at 00161c30: f0280000 delay=1 ec=0 cc=15 cbp=0x05bf4000 nexttd=0x00161c00 be=0x05bf5fff TD(0xc0aedc00) at 00161c00: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 ohci_device_bulk_start: xfer=0xc0ae6900 len=13 isread=1 flags=0 endpt=129 ohci_alloc_std_chain: start len=13 ohci_alloc_std_chain: dataphys=0x05ca5f40 len=13 curlen=13 ohci_device_bulk_start: ed_flags=0x00400082 td_flags=0xf0300000 td_cbp=0x05ca5f40 td_be=0x05ca5f4c ED(0xc0ac1760) at 0x00135760: addr=2 endpt=1 maxp=64 flags=400082 tailp=0x00161fc0 headflags=161fc2 headp=0x00161fc2 nexted=0x00135780 TD(0xc0aedfc0) at 00161fc0: f0300000 delay=1 ec=0 cc=15 cbp=0x05ca5f40 nexttd=0x00161c30 be=0x05ca5f4c TD(0xc0aedc30) at 00161c30: 0 delay=0 ec=0 cc=0 cbp=0x00000000 nexttd=0x00000000 be=0x00000000 ohci_intr: sc=0xc0ac4000 intrs=0x6(0x0) eintrs=0x2 usb0: ohci_hash_find_td: addr 0x00161d20 not found panic: ohci_add_done: addr 0x00161d20 not found KDB: enter: panic [thread pid 639 tid 100070 ] Stopped at kdb_enter+0x2b: nop db> --------------020405020406030808060806-- From owner-freebsd-net@FreeBSD.ORG Sun Feb 12 20:19:05 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6089A16A420 for ; Sun, 12 Feb 2006 20:19:05 +0000 (GMT) (envelope-from misho@interbgc.com) Received: from mail.interbgc.com (mx03.interbgc.com [217.9.224.229]) by mx1.FreeBSD.org (Postfix) with SMTP id BC63E43D6D for ; Sun, 12 Feb 2006 20:18:54 +0000 (GMT) (envelope-from misho@interbgc.com) Received: (qmail 94173 invoked from network); 12 Feb 2006 20:18:52 -0000 Received: from misho@interbgc.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(0.0/8.0):. Processed in 0.658186 secs); 12 Feb 2006 20:18:52 -0000 X-Spam-Status: No, hits=0.0 required=8.0 Received: from topilapi-wlan.ddns.cablebg.net (HELO misho) (85.130.23.254) by mx03.interbgc.com with SMTP; 12 Feb 2006 20:18:51 -0000 Message-ID: <003a01c63011$8a050580$fe178255@misho> From: "Mihail Balikov" To: "GiZmen" , References: <20060211163533.GA87353@blurp.pl> Date: Sun, 12 Feb 2006 22:18:51 +0200 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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Cc: Subject: Re: fastforward problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mihail Balikov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2006 20:19:05 -0000 Are you using ipnat ? ----- Original Message ----- From: "GiZmen" To: Sent: Saturday, February 11, 2006 6:35 PM Subject: fastforward problem > Hi, > > I would like to use fastforward option on my freebsd 6.0-stable > box. But i have strange problem with it. My box is a router for LAN > with IP visible to internet. I am managinc C class network. > When i turn on fastforward option any of the computers in my network > can't open google.com page. This option is quite good because i have > quite a lot interrupts and this option lower this about half. > Could anyone tell me why i can't open google.com page ? > I have tested different pages and i don't have such problem only with > google. > > THANKS for any comments > > -- > Best Regards: > GiZmen > > UNIX is user-friendly; it's just picky about its friends > UNIX is simple; it just takes a genius to understand its simplicity > _______________________________________________ > 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" > > > __________ NOD32 1.1403 (20060210) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > From owner-freebsd-net@FreeBSD.ORG Sun Feb 12 20:54:01 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47CC216A422 for ; Sun, 12 Feb 2006 20:54:01 +0000 (GMT) (envelope-from gizmen@blurp.t2.ds.pwr.wroc.pl) Received: from blurp.t2.ds.pwr.wroc.pl (blurp.t2.ds.pwr.wroc.pl [156.17.224.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 524A643D6D for ; Sun, 12 Feb 2006 20:53:55 +0000 (GMT) (envelope-from gizmen@blurp.t2.ds.pwr.wroc.pl) Received: from localhost (localhost [127.0.0.1]) by blurp.t2.ds.pwr.wroc.pl (Postfix) with ESMTP id ADA3E741 for ; Sun, 12 Feb 2006 21:53:45 +0100 (CET) Received: from blurp.t2.ds.pwr.wroc.pl ([127.0.0.1]) by localhost (blurp.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40878-01 for ; Sun, 12 Feb 2006 21:53:45 +0100 (CET) Received: by blurp.t2.ds.pwr.wroc.pl (Postfix, from userid 1001) id 1C27A72E; Sun, 12 Feb 2006 21:53:44 +0100 (CET) Date: Sun, 12 Feb 2006 21:53:44 +0100 From: GiZmen To: net@freebsd.org Message-ID: <20060212205344.GA40941@blurp.pl> References: <20060211163533.GA87353@blurp.pl> <20060212125124.GA20369@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060212125124.GA20369@uk.tiscali.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at blurp.pl Cc: Subject: Re: fastforward problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2006 20:54:01 -0000 > On Sat, Feb 11, 2006 at 05:35:33PM +0100, GiZmen wrote: > > I would like to use fastforward option on my freebsd 6.0-stable > > box. But i have strange problem with it. My box is a router for LAN > > with IP visible to internet. I am managinc C class network. > > When i turn on fastforward option any of the computers in my network > > can't open google.com page. This option is quite good because i have > > quite a lot interrupts and this option lower this about half. > > Could anyone tell me why i can't open google.com page ? > > I have tested different pages and i don't have such problem only with > > (1) can my client resolve google.com in the DNS? > > If the client is some sort of Unix then try > > $ nslookup google.com Yes that is true that i should give more information so: this is from client inside LAN: Non-authoritative answer: Name: google.com Address: 64.233.187.99 Name: google.com Address: 72.14.207.99 Name: google.com Address: 64.233.167.99 > (2) can my client ping these addresses? That is, is there layer 3 network > reachability between my network and theirs? Yes, clients can ping google IPs. ping 64.233.187.99 PING 64.233.187.99 (64.233.187.99): 56 data bytes 64 bytes from 64.233.187.99: icmp_seq=0 ttl=238 time=155.613 ms 64 bytes from 64.233.187.99: icmp_seq=1 ttl=238 time=152.681 ms PING 72.14.207.99 (72.14.207.99): 56 data bytes 64 bytes from 72.14.207.99: icmp_seq=0 ttl=237 time=142.530 ms 64 bytes from 72.14.207.99: icmp_seq=1 ttl=237 time=143.632 ms 64 bytes from 72.14.207.99: icmp_seq=2 ttl=237 time=143.517 ms > (3) what happens when I open a TCP/IP connection to port 80, and manually > fetch a HTTP page? When i try connect by telnet i have smth like this. telnet 64.233.167.99 80 Trying 64.233.167.99... Connected to 64.233.167.99. Escape character is '^]'. GET / HTTP/1.0 Host: google.com Connection closed by foreign host. There is nothing happening after pressing enter couple times the connection is closing by foreigh host. > OK, that's fine. google.com has redirected me to www.google.com. So try the > whole process again with www.google.com instead of google.com I have tested 3 IP that indicates google.com domain and it is the same every time. What is wrong with this ? -- Best Regards: GiZmen UNIX is user-friendly; it's just picky about its friends UNIX is simple; it just takes a genius to understand its simplicity From owner-freebsd-net@FreeBSD.ORG Sun Feb 12 20:56:28 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BC5816A420 for ; Sun, 12 Feb 2006 20:56:28 +0000 (GMT) (envelope-from gizmen@blurp.t2.ds.pwr.wroc.pl) Received: from blurp.t2.ds.pwr.wroc.pl (blurp.t2.ds.pwr.wroc.pl [156.17.224.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBCEC43D6D for ; Sun, 12 Feb 2006 20:56:23 +0000 (GMT) (envelope-from gizmen@blurp.t2.ds.pwr.wroc.pl) Received: from localhost (localhost [127.0.0.1]) by blurp.t2.ds.pwr.wroc.pl (Postfix) with ESMTP id 4126D743 for ; Sun, 12 Feb 2006 21:56:15 +0100 (CET) Received: from blurp.t2.ds.pwr.wroc.pl ([127.0.0.1]) by localhost (blurp.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40878-02 for ; Sun, 12 Feb 2006 21:56:15 +0100 (CET) Received: by blurp.t2.ds.pwr.wroc.pl (Postfix, from userid 1001) id 1213A72E; Sun, 12 Feb 2006 21:56:15 +0100 (CET) Date: Sun, 12 Feb 2006 21:56:15 +0100 From: GiZmen To: net@freebsd.org Message-ID: <20060212205615.GB40941@blurp.pl> References: <20060211163533.GA87353@blurp.pl> <003a01c63011$8a050580$fe178255@misho> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003a01c63011$8a050580$fe178255@misho> User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at blurp.pl Cc: Subject: Re: fastforward problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2006 20:56:28 -0000 > Are you using ipnat ? > > > I would like to use fastforward option on my freebsd 6.0-stable > > box. But i have strange problem with it. My box is a router for LAN > > with IP visible to internet. I am managinc C class network. > > When i turn on fastforward option any of the computers in my network > > can't open google.com page. This option is quite good because i have > > quite a lot interrupts and this option lower this about half. > > Could anyone tell me why i can't open google.com page ? > > I have tested different pages and i don't have such problem only with > > google. No i am not. I am using PF as my packet filter but i do not make any NAT on this router. My IP class is visible on internet. -- Best Regards: GiZmen UNIX is user-friendly; it's just picky about its friends UNIX is simple; it just takes a genius to understand its simplicity From owner-freebsd-net@FreeBSD.ORG Sun Feb 12 22:56:49 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C06716A420 for ; Sun, 12 Feb 2006 22:56:49 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 07F6843D45 for ; Sun, 12 Feb 2006 22:56:48 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 86369 invoked by uid 399); 12 Feb 2006 22:56:46 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 12 Feb 2006 22:56:46 -0000 Message-ID: <43EFBD2C.2070108@FreeBSD.org> Date: Sun, 12 Feb 2006 14:56:44 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: net@FreeBSD.org References: <20060116004438.GA27901@xor.obsecurity.org> <20060207054502.GA18560@xor.obsecurity.org> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kris Kennaway Subject: Re: Changing time causes ipv6 panics X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2006 22:56:49 -0000 JINMEI Tatuya / $B?@L@C#:H wrote: > Could you try the patch attached below? I probably should have mentioned this earlier, but I started testing this patch on HEAD and RELENG_6 shortly after you sent it, and I haven't been able to reproduce the panic I was seeing, either accidentally or on purpose. :) hth, Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Sun Feb 12 23:28:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5742516A420 for ; Sun, 12 Feb 2006 23:28:43 +0000 (GMT) (envelope-from lukem@cse.unsw.edu.au) Received: from tone.orchestra.cse.unsw.EDU.AU (tone.orchestra.cse.unsw.EDU.AU [129.94.242.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 850BE43D48 for ; Sun, 12 Feb 2006 23:28:42 +0000 (GMT) (envelope-from lukem@cse.unsw.edu.au) Received: From wagner.orchestra.cse.unsw.EDU.AU ([129.94.242.19]) (ident-user root) By tone With Smtp ; Mon, 13 Feb 2006 10:28:39 +1100 Received: From wagner With LocalMail ; Mon, 13 Feb 2006 10:28:38 +1100 From: lukem.freebsd@cse.unsw.edu.au Sender: lukem@cse.unsw.edu.au To: dima <_pppp@mail.ru> Date: Mon, 13 Feb 2006 10:28:38 +1100 (EST) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Marcos Bedinelli , freebsd-net@freebsd.org Subject: Re: Network performance in a dual CPU system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2006 23:28:43 -0000 On Sat, 11 Feb 2006, dima wrote: > There are several software (FreeBSD specific) options though: > 1. You should surely try polling(4). 50kpps mean 50000 interrupts and > the same amount of context switches, which are quite expensive. While this was true in the 80's, it is blatantly wrong for any decent modern network interface. Every gigabit card I've used has had some form of interrupt mitigation. Usually this takes the form of one or more timers which limit the maximum interrupt rate. -- Luke From owner-freebsd-net@FreeBSD.ORG Mon Feb 13 05:14:27 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9018C16A420 for ; Mon, 13 Feb 2006 05:14:27 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 0DECE43D45 for ; Mon, 13 Feb 2006 05:14:26 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 92710 invoked by uid 399); 13 Feb 2006 05:14:26 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 13 Feb 2006 05:14:26 -0000 Message-ID: <43F015AD.50303@FreeBSD.org> Date: Sun, 12 Feb 2006 21:14:21 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: GiZmen References: <20060211163533.GA87353@blurp.pl> <20060212125124.GA20369@uk.tiscali.com> <20060212205344.GA40941@blurp.pl> In-Reply-To: <20060212205344.GA40941@blurp.pl> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: fastforward problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2006 05:14:27 -0000 GiZmen wrote: >> (3) what happens when I open a TCP/IP connection to port 80, and manually >> fetch a HTTP page? > > When i try connect by telnet i have smth like this. > > telnet 64.233.167.99 80 > Trying 64.233.167.99... > Connected to 64.233.167.99. > Escape character is '^]'. > GET / HTTP/1.0 > Host: google.com > > > Connection closed by foreign host. > > There is nothing happening after pressing enter couple times the connection > is closing by foreigh host. So, the next step is tcpdump from various points in your network to find out where the packets are going, and not going. Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Mon Feb 13 11:02:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC69616A420 for ; Mon, 13 Feb 2006 11:02:38 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E5D943D48 for ; Mon, 13 Feb 2006 11:02:38 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k1DB2cl9067357 for ; Mon, 13 Feb 2006 11:02:38 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k1DB2bq5067351 for freebsd-net@freebsd.org; Mon, 13 Feb 2006 11:02:37 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 13 Feb 2006 11:02:37 GMT Message-Id: <200602131102.k1DB2bq5067351@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 Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2006 11:02:38 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2006/01/30] kern/92552 net A serious bug in most network drivers fro 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Feb 13 12:31:38 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6989C16A420 for ; Mon, 13 Feb 2006 12:31:38 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96DAE43D5E for ; Mon, 13 Feb 2006 12:31:36 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id A6DA5616F6; Mon, 13 Feb 2006 07:31:35 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 63C8916712; Mon, 13 Feb 2006 07:31:34 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8crc-0006HU-St; Mon, 13 Feb 2006 12:31:33 +0000 Date: Mon, 13 Feb 2006 12:31:32 +0000 From: Brian Candler To: GiZmen Message-ID: <20060213123132.GA24126@uk.tiscali.com> References: <20060211163533.GA87353@blurp.pl> <20060212125124.GA20369@uk.tiscali.com> <20060212205344.GA40941@blurp.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060212205344.GA40941@blurp.pl> User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: fastforward problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2006 12:31:38 -0000 On Sun, Feb 12, 2006 at 09:53:44PM +0100, GiZmen wrote: > Yes, clients can ping google IPs. > > ping 64.233.187.99 > PING 64.233.187.99 (64.233.187.99): 56 data bytes > 64 bytes from 64.233.187.99: icmp_seq=0 ttl=238 time=155.613 ms > 64 bytes from 64.233.187.99: icmp_seq=1 ttl=238 time=152.681 ms > > PING 72.14.207.99 (72.14.207.99): 56 data bytes > 64 bytes from 72.14.207.99: icmp_seq=0 ttl=237 time=142.530 ms > 64 bytes from 72.14.207.99: icmp_seq=1 ttl=237 time=143.632 ms > 64 bytes from 72.14.207.99: icmp_seq=2 ttl=237 time=143.517 ms > > > (3) what happens when I open a TCP/IP connection to port 80, and manually > > fetch a HTTP page? > > When i try connect by telnet i have smth like this. > > telnet 64.233.167.99 80 > Trying 64.233.167.99... > Connected to 64.233.167.99. > Escape character is '^]'. > GET / HTTP/1.0 > Host: google.com > > > Connection closed by foreign host. > > There is nothing happening after pressing enter couple times the connection > is closing by foreigh host. Next: in another window, do # tcpdump -i fxp0 -n -s1500 -X (replace fxp0 with your external interface name). Then at the same time, have one of the clients do the same test (3). If you see too much tcpdump output, then try # tcpdump -i fxp0 -n -s1500 -X host 64.233.167.99 or icmp What you're looking for is the connection being closed, and what device is closing it (Google? Perhaps some upstream device?) I can only guess at a few causes. (1) Broken DNS. Your IP address maps to host.example.com but host.example.com does not map back to the same IP address. Since you've not said your client's IP address, I can't check this for you. I'd expect the server to drop the connection immediately in this case, but it's still worth checking. (2) Upstream from you is some sort of transparent HTTP proxy/cache, which is broken. To test this theory, try # telnet 1.1.1.1 80 Does this connect? Or does it time out after 75 seconds? If it connects, there's almost certainly a transparent cache upstream. (3) You have some sort of path MTU issue. I don't know why. Perhaps your upstream link is running PPPoE or something which is not clear for 1500-byte packets. If so, it ought to work, but bad filtering of ICMP or bad use of NAT can cause problems. Try to run a tcpdump as far up the upstream path as possible, to see what's going on. Brian. From owner-freebsd-net@FreeBSD.ORG Mon Feb 13 14:48:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9339916A420 for ; Mon, 13 Feb 2006 14:48:01 +0000 (GMT) (envelope-from mt@smtp.top.net.ua) Received: from smtp.top.net.ua (smtp.top.net.ua [88.81.254.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4D3843D5A for ; Mon, 13 Feb 2006 14:48:00 +0000 (GMT) (envelope-from mt@smtp.top.net.ua) Received: from smtp.top.net.ua (localhost [127.0.0.1]) by smtp.top.net.ua (Postfix) with ESMTP id DFA2C608B55 for ; Mon, 13 Feb 2006 16:38:15 +0200 (EET) Received: by smtp.top.net.ua (Postfix, from userid 1012) id 8CC44608B6B; Mon, 13 Feb 2006 16:38:15 +0200 (EET) Date: Mon, 13 Feb 2006 16:38:15 +0200 From: Maxim Tuliuk To: freebsd-net@freebsd.org Message-ID: <20060213143815.GA22437@top.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV using ClamSMTP Subject: weirdness with vlans & sk on 5.4-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2006 14:48:01 -0000 Hello! I'm having some troubles with "sk" netcard in 5.4-RELEASE: config info: > part of dmesg boot: FreeBSD 5.4-RELEASE-p2 #1: Tue Jun 28 16:10:16 EEST 2005 skc0: <3Com 3C940 Gigabit Ethernet> port 0xd400-0xd4ff mem 0xfeae8000-0xfeaebfff irq 22 at device 5.0 on pci2 skc0: 3Com Gigabit LOM (3C940) rev. (0x1) sk0: on skc0 sk0: Ethernet address: 00:0c:6e:52:2e:5b miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto > ifconfig vlan0 vlan0: flags=8843 mtu 1496 inet 10.49.3.13 netmask 0xffffff00 broadcast 10.49.3.255 ether 00:0c:6e:52:2e:5b media: Ethernet autoselect (100baseTX ) status: active vlan: 9 parent interface: sk0 > ifconfig sk0 sk0: flags=8843 mtu 1500 inet 10.49.0.7 netmask 0xffffff00 broadcast 10.49.0.255 ether 00:0c:6e:52:2e:5b media: Ethernet autoselect (100baseTX ) status: active addional info: 10.49.3.13 - the host with "broken" sk 10.49.3.10 - the nfs server host tcpdump output: > tcpdump -n -i vlan0 host 10.49.3.10 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan0, link-type EN10MB (Ethernet), capture size 96 bytes 16:31:17.890049 IP 10.49.3.13.557961704 > 10.49.3.10.2049: 156 readdir [|nfs] 16:31:17.891576 IP 10.49.3.10 > 10.49.3.13: udp 16:31:19.919736 IP 10.49.3.13.557961704 > 10.49.3.10.2049: 156 readdir [|nfs] 16:31:19.921189 IP 10.49.3.10 > 10.49.3.13: udp 16:31:23.969108 IP 10.49.3.13.557961704 > 10.49.3.10.2049: 156 readdir [|nfs] 16:31:23.970438 IP 10.49.3.10 > 10.49.3.13: udp > tcpdump -n -i sk0 vlan 9 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on sk0, link-type EN10MB (Ethernet), capture size 96 bytes 16:32:53.875178 IP 10.49.3.13.557961704 > 10.49.3.10.2049: 156 readdir [|nfs] 16:32:53.876145 IP 10.49.3.10.2049 > 10.49.3.13.557961704: reply ok 1472 readdir16:32:53.876578 IP 10.49.3.10 > 10.49.3.13: udp 16:32:55.904865 IP 10.49.3.13.557961704 > 10.49.3.10.2049: 156 readdir [|nfs] 16:32:55.905811 IP 10.49.3.10.2049 > 10.49.3.13.557961704: reply ok 1472 readdir16:32:55.906246 IP 10.49.3.10 > 10.49.3.13: udp 16:32:59.954278 IP 10.49.3.13.557961704 > 10.49.3.10.2049: 156 readdir [|nfs] 16:32:59.955651 IP 10.49.3.10.2049 > 10.49.3.13.557961704: reply ok 1472 readdir16:32:59.956078 IP 10.49.3.10 > 10.49.3.13: udp as you can see above, sk0 interface receives udp packet but vlan0 doesn't... Any suggestions? -- Maxim Tuliuk WWW: http://primats.org.ua/~mt/ ICQ: 21134222 Bike is the freedom of moving From owner-freebsd-net@FreeBSD.ORG Mon Feb 13 15:05:13 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CD1416A420 for ; Mon, 13 Feb 2006 15:05:13 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 668DA43D48 for ; Mon, 13 Feb 2006 15:05:10 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id AFAB11FFEFA; Mon, 13 Feb 2006 16:05:08 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 1704D1FFEF1; Mon, 13 Feb 2006 16:05:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id A4F2544487E; Mon, 13 Feb 2006 15:00:18 +0000 (UTC) Date: Mon, 13 Feb 2006 15:00:18 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Maxim Tuliuk In-Reply-To: <20060213143815.GA22437@top.net.ua> Message-ID: <20060213145828.W74458@maildrop.int.zabbadoz.net> References: <20060213143815.GA22437@top.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-net@freebsd.org Subject: Re: weirdness with vlans & sk on 5.4-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2006 15:05:13 -0000 On Mon, 13 Feb 2006, Maxim Tuliuk wrote: > Hello! > I'm having some troubles with "sk" netcard in 5.4-RELEASE: ... > as you can see above, sk0 interface receives udp packet but vlan0 doesn't... > > Any suggestions? apart from the special problem sk(4) in 5.4-RELEASE had bugs. You should update. sk(4) as in HEAD, RELENG_6 and RELENG_5 still has problems but there is a patch to come to address them. Mostly watchdog timeouts and problems with >4GB of memory. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Mon Feb 13 15:13:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A181216A420 for ; Mon, 13 Feb 2006 15:13:51 +0000 (GMT) (envelope-from bedinelli@madhaus.cns.utoronto.ca) Received: from madhaus.cns.utoronto.ca (madhaus.cns.utoronto.ca [128.100.103.10]) by mx1.FreeBSD.org (Postfix) with SMTP id 2B69543D48 for ; Mon, 13 Feb 2006 15:13:50 +0000 (GMT) (envelope-from bedinelli@madhaus.cns.utoronto.ca) Received: (qmail 11316 invoked by uid 31014); 13 Feb 2006 15:13:50 -0000 Received: from [128.100.103.148] (HELO [128.100.103.148]) (128.100.103.148) by madhaus.cns.utoronto.ca (qpsmtpd/0.30) with ESMTP; Mon, 13 Feb 2006 10:13:50 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcos Bedinelli Date: Mon, 13 Feb 2006 10:13:48 -0500 To: dima <_pppp@mail.ru> X-Mailer: Apple Mail (2.623) Cc: freebsd-net@freebsd.org Subject: Re: Network performance in a dual CPU system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2006 15:13:51 -0000 Hi, On 10-Feb-06, at 16:39, dima wrote: > The second CPU wouldn't help you for sure. There's only one [swi1: > net] kernel thread which deals with all the kernel traffic. The option > of per-CPU [swi: net] threads was discussed on freebsd-arch@ several > months ago, but it wouldn't be implemented soon. > So, the only hardware option is installing the fastest CPU possible. Ok, the statement above answers my first question clearly and concisely (although I must confess I am a bit confused after reading Robert Watson's message). > There are several software (FreeBSD specific) options though: > 1. You should surely try polling(4). 50kpps mean 50000 interrupts and > the same amount of context switches, which are quite expensive. > 2. FastForwarding. It's the most suitable for you. As I know, Quagga > inserts its dynamic routes to the system routing table. And > FastForwarding is aware of routing table and firewall rules. And the > most exciting: you can switch it on/off without reboot: > # sysctl net.inet.ip.fastforwarding=1 This morning a tried suggestion number 2. I had HOST-A running a ping session to HOST-B. Between hosts A and B there was the heavily loaded FreeBSD machine in question. As soon as I entered 'sysctl net.inet.ip.fastforwarding=1' the ping session died. Switching fastforwarding back to 0 resumed the session. It's very unfortunate we can't afford to have that machine down, even for a couple of minutes, during daytime. I guess I'll have to read more about polling and the net.inet.ip.fastforwarding option, before giving it another try (probably around 3 a.m.) Thanks for your reply. Regards, -- Marcos From owner-freebsd-net@FreeBSD.ORG Mon Feb 13 17:30:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2D3116A420; Mon, 13 Feb 2006 17:30:18 +0000 (GMT) (envelope-from anders@FreeBSD.org) Received: from totem.fix.no (totem.fix.no [80.91.36.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 129BB43D73; Mon, 13 Feb 2006 17:30:10 +0000 (GMT) (envelope-from anders@FreeBSD.org) Received: by totem.fix.no (Postfix, from userid 1000) id B2B528DB14D; Mon, 13 Feb 2006 18:30:08 +0100 (CET) Date: Mon, 13 Feb 2006 18:30:08 +0100 From: Anders Nordby To: Gleb Smirnoff , freebsd-net@freebsd.org, demon@freebsd.org, harti@freebsd.org, kuriyama@freebsd.org Message-ID: <20060213173008.GA14643@totem.fix.no> References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060207141131.GU877@FreeBSD.org> X-PGP-Key: http://anders.fix.no/pgp/ X-PGP-Key-FingerPrint: 1E0F C53C D8DF 6A8F EAAD 19C5 D12A BC9F 0083 5956 User-Agent: Mutt/1.5.11 Cc: Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2006 17:30:19 -0000 Hi, On Tue, Feb 07, 2006 at 05:11:31PM +0300, Gleb Smirnoff wrote: >> Is there any way to have 64-bit SNMP counters in FreeBSD? Especially for >> ifInOctets/ifOutOctets. It seems the built-in bsnmpd only has >> Counter32, and net-snmpd the same (--enable-mfd-rewrites, which is >> supposed to help, seems to only work in Linux). > Extended counters live in a separate subtree and bsnmpd supports them: > >> snmpwalk -v 2c host community ifMIB.ifMIBObjects.ifXTable.ifXEntry Running FreeBSD 6.0-RELEASE and using net-snmp 5.2.2 to walk the tree, I get: # snmpwalk -v 2c -c XXXYYY localhost ifMIB.ifMIBObjects.ifXTable.ifXEntry IF-MIB::ifName.1 = STRING: bge0 IF-MIB::ifName.2 = STRING: bge1 IF-MIB::ifName.3 = STRING: lo0 IF-MIB::ifInMulticastPkts.1 = Counter32: 3430126 IF-MIB::ifInMulticastPkts.2 = Counter32: 0 IF-MIB::ifInMulticastPkts.3 = Counter32: 0 IF-MIB::ifInBroadcastPkts.1 = Counter32: 0 IF-MIB::ifInBroadcastPkts.2 = Counter32: 0 IF-MIB::ifInBroadcastPkts.3 = Counter32: 0 IF-MIB::ifOutMulticastPkts.1 = Counter32: 0 IF-MIB::ifOutMulticastPkts.2 = Counter32: 0 IF-MIB::ifOutMulticastPkts.3 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.1 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.2 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.3 = Counter32: 0 IF-MIB::ifLinkUpDownTrapEnable.1 = INTEGER: enabled(1) IF-MIB::ifLinkUpDownTrapEnable.2 = INTEGER: enabled(1) IF-MIB::ifLinkUpDownTrapEnable.3 = INTEGER: disabled(2) IF-MIB::ifHighSpeed.1 = Gauge32: 10 IF-MIB::ifHighSpeed.2 = Gauge32: 10 IF-MIB::ifHighSpeed.3 = Gauge32: 0 IF-MIB::ifPromiscuousMode.1 = INTEGER: false(2) IF-MIB::ifPromiscuousMode.2 = INTEGER: false(2) IF-MIB::ifPromiscuousMode.3 = INTEGER: false(2) IF-MIB::ifConnectorPresent.1 = INTEGER: true(1) IF-MIB::ifConnectorPresent.2 = INTEGER: true(1) IF-MIB::ifConnectorPresent.3 = INTEGER: false(2) IF-MIB::ifAlias.1 = STRING: IF-MIB::ifAlias.2 = STRING: IF-MIB::ifAlias.3 = STRING: IF-MIB::ifCounterDiscontinuityTime.1 = Timeticks: (0) 0:00:00.00 IF-MIB::ifCounterDiscontinuityTime.2 = Timeticks: (0) 0:00:00.00 IF-MIB::ifCounterDiscontinuityTime.3 = Timeticks: (0) 0:00:00.00 It seems ifHCInOctets and ifHCOutOctets are missing. How come? Do I need to use SNMP v3? Another query tool? Bye, -- Anders. From owner-freebsd-net@FreeBSD.ORG Mon Feb 13 18:22:09 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 189A416A420 for ; Mon, 13 Feb 2006 18:22:09 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A309D43D46 for ; Mon, 13 Feb 2006 18:22:08 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id k1DILwFx005700 for ; Mon, 13 Feb 2006 19:21:59 +0100 (MET) Message-ID: <43F0CE40.5040800@fer.hr> Date: Mon, 13 Feb 2006 19:21:52 +0100 From: Ivan Voras User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: TCP Performance advice needed [long!] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2006 18:22:09 -0000 I'm writing a simple client-server application and I think I have a performance problem. The basic communication between the server and the client is like this: the server sends messages at most MAX_SIZE in length, one by one, and waits until the client acknowleges each message before sending the next one. Messages of maximum length (MAX_SIZE) make about 75% or more of total messages. Client responses are small and of fixed size (<10 bytes). I have TCP_NODELAY turned on on both. All sends are done with a blocking send() call of required size. Client's response processing time doesn't depend notably on the message size. I've done some simple benchmarks and I'm puzzled about the results. In the benchmarks, the MAX_SIZE is periodically increased from 256 to 65536 in power-of-2 steps. In the benchmark setup the server and client are connected directly via 100Mbps connection without transmission problems (FTP pushes ~12MB/s in both directions). Problem: It seems that the packets-per-second rate sent by the server increases from 1000 at MAX_SIZE=256 to 2500 at MAX_SIZE=4096, then sharply drops to 400 at MAX_SIZE=8192 and above. Remembering a discussion on Samba performance, I tried disabling tcp.inflight.enable, and the results for large packet sizes became very good, about 4000pps, until MAX_SIZE=32768, where it drops to 400 again. What does tcp.inflight do, and can it be done without changing sysctls? Another problem: the starting rates, e.g. ~1000pps at MAX_SIZE=256, seem too low to me - this pushes only 256kB/s. This is a problem because in real usage such small sizes could be common. Looking at netstat, packet rates seem to vary randomly. Here's netstat log for session with MAX_SIZE=512: 1 0 66 1 0 178 0 378 0 27956 378 0 132192 0 1405 0 103962 1405 0 488770 0 1193 0 88274 1193 0 414994 0 1093 0 80874 1093 0 380194 0 1010 0 74732 1011 0 351658 0 930 0 68812 930 0 323732 0 797 0 58970 796 0 276576 0 95 0 7022 95 0 32890 0 input (Total) output packets errs bytes packets errs bytes colls 201 0 14866 201 0 69778 0 495 0 36622 495 0 172202 0 739 0 54678 739 0 257002 0 1291 0 95526 1292 0 449728 0 1134 0 83908 1133 0 394094 0 1026 0 75916 1026 0 356616 0 987 0 73030 987 0 343306 0 873 0 64594 873 0 303634 0 855 0 63262 855 0 297370 0 360 0 26632 360 0 125372 0 1002 0 74140 1002 0 348264 0 1166 0 86276 1166 0 405860 0 1056 0 78136 1056 0 367056 0 937 0 69330 937 0 325906 0 753 0 55714 753 0 261874 0 111 0 8206 111 0 38458 0 143 0 10566 144 0 49692 0 1 0 66 1 0 178 0 1 0 66 1 0 178 0 Here's for MAX_SIZE=8192: input (Total) output packets errs bytes packets errs bytes colls 1082 0 74292 1438 0 1580040 0 1287 0 88366 1701 0 1885062 0 1403 0 96342 1867 0 2044074 0 1763 0 121046 2346 0 2578684 0 1532 0 105208 2026 0 2236048 0 1866 0 128124 2463 0 2726554 0 2401 0 164874 3192 0 3508384 0 2797 0 192058 3719 0 4095824 0 2791 0 191646 3714 0 4070142 0 2773 0 190410 3692 0 4052512 0 2583 0 177358 3438 0 3780296 0 2947 0 202358 3927 0 4307032 0 2963 0 203462 3943 0 4324596 0 2946 0 202292 3926 0 4307032 0 2965 0 203594 3946 0 4341638 0 2989 0 205242 3977 0 4359552 0 2928 0 201056 3898 0 4289006 0 2995 0 205654 3983 0 4368192 0 2965 0 203594 3945 0 4333018 0 2983 0 204830 3973 0 4359598 0 2978 0 204484 3968 0 4359380 0 input (Total) output packets errs bytes packets errs bytes colls 2986 0 205028 3976 0 4359910 0 2979 0 204566 3969 0 4359578 0 2123 0 145790 2827 0 3089432 0 It seems that the transmission for MAX_SIZE=8192 has slow start but I don't know how to disable it? Help on any of these points, or suggestions where to investigate further will be appreciated! From owner-freebsd-net@FreeBSD.ORG Mon Feb 13 19:14:11 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 925EC16A420; Mon, 13 Feb 2006 19:14:11 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C944F43D5C; Mon, 13 Feb 2006 19:14:09 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id k1DJE6ch055774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2006 22:14:07 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id k1DJE697055773; Mon, 13 Feb 2006 22:14:06 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 13 Feb 2006 22:14:06 +0300 From: Gleb Smirnoff To: Anders Nordby Message-ID: <20060213191406.GB86448@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Anders Nordby , freebsd-net@FreeBSD.org, demon@FreeBSD.org, harti@FreeBSD.org, kuriyama@FreeBSD.org References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> <20060213173008.GA14643@totem.fix.no> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060213173008.GA14643@totem.fix.no> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org, harti@FreeBSD.org, kuriyama@FreeBSD.org, demon@FreeBSD.org Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2006 19:14:12 -0000 On Mon, Feb 13, 2006 at 06:30:08PM +0100, Anders Nordby wrote: A> On Tue, Feb 07, 2006 at 05:11:31PM +0300, Gleb Smirnoff wrote: A> >> Is there any way to have 64-bit SNMP counters in FreeBSD? Especially for A> >> ifInOctets/ifOutOctets. It seems the built-in bsnmpd only has A> >> Counter32, and net-snmpd the same (--enable-mfd-rewrites, which is A> >> supposed to help, seems to only work in Linux). A> > Extended counters live in a separate subtree and bsnmpd supports them: A> > A> >> snmpwalk -v 2c host community ifMIB.ifMIBObjects.ifXTable.ifXEntry Actually, I've misinformed you. On 32-bit platforms HC counters exist, but overflow as bad as old 32 bit counters. The fix has been committed by Harti today to HEAD (BEGEMOT vendor branch). A> Running FreeBSD 6.0-RELEASE and using net-snmp 5.2.2 to walk the tree, I A> get: bsnmpd doesn't create HC MIB branch for interfaces with slow speed. Are your interfaces negotiated to 10 Mbit/s? A> # snmpwalk -v 2c -c XXXYYY localhost A> ifMIB.ifMIBObjects.ifXTable.ifXEntry A> IF-MIB::ifName.1 = STRING: bge0 A> IF-MIB::ifName.2 = STRING: bge1 A> IF-MIB::ifName.3 = STRING: lo0 A> IF-MIB::ifInMulticastPkts.1 = Counter32: 3430126 A> IF-MIB::ifInMulticastPkts.2 = Counter32: 0 A> IF-MIB::ifInMulticastPkts.3 = Counter32: 0 A> IF-MIB::ifInBroadcastPkts.1 = Counter32: 0 A> IF-MIB::ifInBroadcastPkts.2 = Counter32: 0 A> IF-MIB::ifInBroadcastPkts.3 = Counter32: 0 A> IF-MIB::ifOutMulticastPkts.1 = Counter32: 0 A> IF-MIB::ifOutMulticastPkts.2 = Counter32: 0 A> IF-MIB::ifOutMulticastPkts.3 = Counter32: 0 A> IF-MIB::ifOutBroadcastPkts.1 = Counter32: 0 A> IF-MIB::ifOutBroadcastPkts.2 = Counter32: 0 A> IF-MIB::ifOutBroadcastPkts.3 = Counter32: 0 A> IF-MIB::ifLinkUpDownTrapEnable.1 = INTEGER: enabled(1) A> IF-MIB::ifLinkUpDownTrapEnable.2 = INTEGER: enabled(1) A> IF-MIB::ifLinkUpDownTrapEnable.3 = INTEGER: disabled(2) A> IF-MIB::ifHighSpeed.1 = Gauge32: 10 A> IF-MIB::ifHighSpeed.2 = Gauge32: 10 A> IF-MIB::ifHighSpeed.3 = Gauge32: 0 A> IF-MIB::ifPromiscuousMode.1 = INTEGER: false(2) A> IF-MIB::ifPromiscuousMode.2 = INTEGER: false(2) A> IF-MIB::ifPromiscuousMode.3 = INTEGER: false(2) A> IF-MIB::ifConnectorPresent.1 = INTEGER: true(1) A> IF-MIB::ifConnectorPresent.2 = INTEGER: true(1) A> IF-MIB::ifConnectorPresent.3 = INTEGER: false(2) A> IF-MIB::ifAlias.1 = STRING: A> IF-MIB::ifAlias.2 = STRING: A> IF-MIB::ifAlias.3 = STRING: A> IF-MIB::ifCounterDiscontinuityTime.1 = Timeticks: (0) 0:00:00.00 A> IF-MIB::ifCounterDiscontinuityTime.2 = Timeticks: (0) 0:00:00.00 A> IF-MIB::ifCounterDiscontinuityTime.3 = Timeticks: (0) 0:00:00.00 A> A> It seems ifHCInOctets and ifHCOutOctets are missing. How come? Do I need A> to use SNMP v3? Another query tool? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 07:46:10 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F031716A420 for ; Tue, 14 Feb 2006 07:46:10 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2697843D45 for ; Tue, 14 Feb 2006 07:46:09 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id k1E7k7Ov066135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2006 10:46:07 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id k1E7k6D0066134; Tue, 14 Feb 2006 10:46:06 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 14 Feb 2006 10:46:06 +0300 From: Gleb Smirnoff To: Marcos Bedinelli Message-ID: <20060214074606.GH86448@FreeBSD.org> Mail-Followup-To: Gleb Smirnoff , Marcos Bedinelli , freebsd-net@freebsd.org References: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org Subject: Re: Network performance in a dual CPU system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 07:46:11 -0000 On Fri, Feb 10, 2006 at 08:46:00AM -0500, Marcos Bedinelli wrote: M> We have a 2.4GHz Intel Xeon machine running FreeBSD 6.0-RELEASE-p2. Due M> to heavy network traffic, CPU utilization on that machine is 100%: M> M> === M> M> mull [~]$top -S M> last pid: 94989; load averages: 3.69, 4.02, 4.36 up M> 25+07:21:34 14:51:43 M> 105 processes: 2 running, 46 sleeping, 57 waiting M> CPU states: 0.0% user, 0.0% nice, 0.3% system, 99.4% interrupt, M> 0.3% idle M> Mem: 20M Active, 153M Inact, 84M Wired, 4K Cache, 60M Buf, 237M Free M> Swap: 999M Total, 999M Free M> M> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND M> 60 root 1 -44 -163 0K 8K WAIT 355.6H 72.17% swi1: M> net M> 39 root 1 -68 -187 0K 8K WAIT 52.3H 5.22% irq28: M> bge0 M> 40 root 1 -68 -187 0K 8K WAIT 28.3H 2.25% irq29: M> bge1 M> 11 root 1 171 52 0K 8K RUN 166.6H 0.00% idle M> 63 root 1 -16 0 0K 8K - 121:55 0.00% yarrow M> 61 root 1 -32 -151 0K 8K WAIT 46:21 0.00% swi4: M> clock sio M> [...] You didn't described what the box is actually. According to top(1) output, looks like your system is routing between bge0 and bge1. If this is true, then you should try: sysctl net.inet.ip.fastforwarding=1 This will split the work into the ithreads and also this will use a faster code path. The performance will improve, and obtaining a second CPU will give you a benefit, since you will have two heavy loaded threads. You should also try upgrade to 6.1, since bge(4) driver has undergone some improvements. If my guess was incorrect, and you aren't routing traffic, then you should follow Robert's advice and try: sysctl net.isr.direct=1 And see whether load is splitted betweeen processes. If it is, then purchase second CPU. M> Does anyone know whether a dual CPU system can help us improve the M> situation? I was wondering if the software interrupt threads would be M> divided between the two processors. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 08:07:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5C4116A420; Tue, 14 Feb 2006 08:07:43 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CDDB43D46; Tue, 14 Feb 2006 08:07:42 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 09:07:41 +0100 Date: Tue, 14 Feb 2006 09:07:42 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Anders Nordby In-Reply-To: <20060213173008.GA14643@totem.fix.no> Message-ID: <20060214090531.X5083@beagle.kn.op.dlr.de> References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> <20060213173008.GA14643@totem.fix.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 14 Feb 2006 08:07:41.0373 (UTC) FILETIME=[BA396ED0:01C6313D] Cc: freebsd-net@freebsd.org, Gleb Smirnoff , kuriyama@freebsd.org, demon@freebsd.org Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 08:07:44 -0000 On Mon, 13 Feb 2006, Anders Nordby wrote: AN>Hi, AN> AN>On Tue, Feb 07, 2006 at 05:11:31PM +0300, Gleb Smirnoff wrote: AN>>> Is there any way to have 64-bit SNMP counters in FreeBSD? Especially for AN>>> ifInOctets/ifOutOctets. It seems the built-in bsnmpd only has AN>>> Counter32, and net-snmpd the same (--enable-mfd-rewrites, which is AN>>> supposed to help, seems to only work in Linux). AN>> Extended counters live in a separate subtree and bsnmpd supports them: AN>> AN>>> snmpwalk -v 2c host community ifMIB.ifMIBObjects.ifXTable.ifXEntry AN> AN>Running FreeBSD 6.0-RELEASE and using net-snmp 5.2.2 to walk the tree, I AN>get: AN> AN># snmpwalk -v 2c -c XXXYYY localhost AN>ifMIB.ifMIBObjects.ifXTable.ifXEntry AN>IF-MIB::ifName.1 = STRING: bge0 AN>IF-MIB::ifName.2 = STRING: bge1 AN>IF-MIB::ifName.3 = STRING: lo0 AN>IF-MIB::ifInMulticastPkts.1 = Counter32: 3430126 AN>IF-MIB::ifInMulticastPkts.2 = Counter32: 0 AN>IF-MIB::ifInMulticastPkts.3 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.1 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.2 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.3 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.1 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.2 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.3 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.1 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.2 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.3 = Counter32: 0 AN>IF-MIB::ifLinkUpDownTrapEnable.1 = INTEGER: enabled(1) AN>IF-MIB::ifLinkUpDownTrapEnable.2 = INTEGER: enabled(1) AN>IF-MIB::ifLinkUpDownTrapEnable.3 = INTEGER: disabled(2) AN>IF-MIB::ifHighSpeed.1 = Gauge32: 10 AN>IF-MIB::ifHighSpeed.2 = Gauge32: 10 AN>IF-MIB::ifHighSpeed.3 = Gauge32: 0 AN>IF-MIB::ifPromiscuousMode.1 = INTEGER: false(2) AN>IF-MIB::ifPromiscuousMode.2 = INTEGER: false(2) AN>IF-MIB::ifPromiscuousMode.3 = INTEGER: false(2) AN>IF-MIB::ifConnectorPresent.1 = INTEGER: true(1) AN>IF-MIB::ifConnectorPresent.2 = INTEGER: true(1) AN>IF-MIB::ifConnectorPresent.3 = INTEGER: false(2) AN>IF-MIB::ifAlias.1 = STRING: AN>IF-MIB::ifAlias.2 = STRING: AN>IF-MIB::ifAlias.3 = STRING: AN>IF-MIB::ifCounterDiscontinuityTime.1 = Timeticks: (0) 0:00:00.00 AN>IF-MIB::ifCounterDiscontinuityTime.2 = Timeticks: (0) 0:00:00.00 AN>IF-MIB::ifCounterDiscontinuityTime.3 = Timeticks: (0) 0:00:00.00 AN> AN>It seems ifHCInOctets and ifHCOutOctets are missing. How come? Do I need AN>to use SNMP v3? Another query tool? 10 bits/seconds seems utterly wrong for bge interfaces :-) The HC counters appear only for speeds >= 20Mbit/sec according to the RFC. harti From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 08:30:13 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3AE616A420; Tue, 14 Feb 2006 08:30:13 +0000 (GMT) (envelope-from anders@FreeBSD.org) Received: from totem.fix.no (totem.fix.no [80.91.36.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 355D843D48; Tue, 14 Feb 2006 08:30:13 +0000 (GMT) (envelope-from anders@FreeBSD.org) Received: by totem.fix.no (Postfix, from userid 1000) id 6EDEE8DB14E; Tue, 14 Feb 2006 09:30:10 +0100 (CET) Date: Tue, 14 Feb 2006 09:30:10 +0100 From: Anders Nordby To: Harti Brandt Message-ID: <20060214083010.GB41864@totem.fix.no> References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> <20060213173008.GA14643@totem.fix.no> <20060214090531.X5083@beagle.kn.op.dlr.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060214090531.X5083@beagle.kn.op.dlr.de> X-PGP-Key: http://anders.fix.no/pgp/ X-PGP-Key-FingerPrint: 1E0F C53C D8DF 6A8F EAAD 19C5 D12A BC9F 0083 5956 User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Gleb Smirnoff , kuriyama@freebsd.org, demon@freebsd.org Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 08:30:13 -0000 On Tue, Feb 14, 2006 at 09:07:42AM +0100, Harti Brandt wrote: >>It seems ifHCInOctets and ifHCOutOctets are missing. How come? Do I need >>to use SNMP v3? Another query tool? > 10 bits/seconds seems utterly wrong for bge interfaces :-) The HC counters > appear only for speeds >= 20Mbit/sec according to the RFC. I have two servers running bsnmpd in FreeBSD 6.0-RELEASE here now. Both have bge gigabit interfaces. 1) A HP Proliant DL 380 G4 (FreeBSD/i386), with (forced) 100baseTX full-duplex link: # ifconfig bge0 bge0: flags=8843 mtu 1500 options=1a inet X.X.X.X netmask 0xfffffff0 broadcast 80.91.38.111 ether 00:14:c2:61:5c:95 media: Ethernet 100baseTX status: active # snmpwalk -v 2c -c XXXXXX localhost:163 ifMIB.ifMIBObjects.ifXTable.ifXEntry IF-MIB::ifName.1 = STRING: bge0 IF-MIB::ifName.2 = STRING: bge1 IF-MIB::ifName.3 = STRING: lo0 IF-MIB::ifInMulticastPkts.1 = Counter32: 3430507 IF-MIB::ifInMulticastPkts.2 = Counter32: 0 IF-MIB::ifInMulticastPkts.3 = Counter32: 0 IF-MIB::ifInBroadcastPkts.1 = Counter32: 0 IF-MIB::ifInBroadcastPkts.2 = Counter32: 0 IF-MIB::ifInBroadcastPkts.3 = Counter32: 0 IF-MIB::ifOutMulticastPkts.1 = Counter32: 0 IF-MIB::ifOutMulticastPkts.2 = Counter32: 0 IF-MIB::ifOutMulticastPkts.3 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.1 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.2 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.3 = Counter32: 0 IF-MIB::ifLinkUpDownTrapEnable.1 = INTEGER: enabled(1) IF-MIB::ifLinkUpDownTrapEnable.2 = INTEGER: enabled(1) IF-MIB::ifLinkUpDownTrapEnable.3 = INTEGER: disabled(2) IF-MIB::ifHighSpeed.1 = Gauge32: 10 IF-MIB::ifHighSpeed.2 = Gauge32: 10 IF-MIB::ifHighSpeed.3 = Gauge32: 0 IF-MIB::ifPromiscuousMode.1 = INTEGER: false(2) IF-MIB::ifPromiscuousMode.2 = INTEGER: false(2) IF-MIB::ifPromiscuousMode.3 = INTEGER: false(2) IF-MIB::ifConnectorPresent.1 = INTEGER: true(1) IF-MIB::ifConnectorPresent.2 = INTEGER: true(1) IF-MIB::ifConnectorPresent.3 = INTEGER: false(2) IF-MIB::ifAlias.1 = STRING: IF-MIB::ifAlias.2 = STRING: IF-MIB::ifAlias.3 = STRING: IF-MIB::ifCounterDiscontinuityTime.1 = Timeticks: (0) 0:00:00.00 IF-MIB::ifCounterDiscontinuityTime.2 = Timeticks: (0) 0:00:00.00 IF-MIB::ifCounterDiscontinuityTime.3 = Timeticks: (0) 0:00:00.00 2) A HP Proliant DL 385 G1 (FreeBSD/amd64), with gigabit link: # ifconfig bge0 bge0: flags=8843 mtu 1500 options=1a inet X.X.X.X netmask 0xffffffe0 broadcast 80.91.39.159 ether 00:13:21:b3:01:f6 media: Ethernet autoselect (1000baseTX ) status: active # snmpwalk -v 2c -c XXXXXX localhost:163 ifMIB.ifMIBObjects.ifXTable.ifXEntry IF-MIB::ifName.1 = STRING: bge0 IF-MIB::ifName.2 = STRING: bge1 IF-MIB::ifName.3 = STRING: lo0 IF-MIB::ifInMulticastPkts.1 = Counter32: 13303 IF-MIB::ifInMulticastPkts.2 = Counter32: 0 IF-MIB::ifInMulticastPkts.3 = Counter32: 0 IF-MIB::ifInBroadcastPkts.1 = Counter32: 0 IF-MIB::ifInBroadcastPkts.2 = Counter32: 0 IF-MIB::ifInBroadcastPkts.3 = Counter32: 0 IF-MIB::ifOutMulticastPkts.1 = Counter32: 0 IF-MIB::ifOutMulticastPkts.2 = Counter32: 0 IF-MIB::ifOutMulticastPkts.3 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.1 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.2 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.3 = Counter32: 0 IF-MIB::ifLinkUpDownTrapEnable.1 = INTEGER: enabled(1) IF-MIB::ifLinkUpDownTrapEnable.2 = INTEGER: enabled(1) IF-MIB::ifLinkUpDownTrapEnable.3 = INTEGER: disabled(2) IF-MIB::ifHighSpeed.1 = Gauge32: 10 IF-MIB::ifHighSpeed.2 = Gauge32: 10 IF-MIB::ifHighSpeed.3 = Gauge32: 0 IF-MIB::ifPromiscuousMode.1 = INTEGER: false(2) IF-MIB::ifPromiscuousMode.2 = INTEGER: false(2) IF-MIB::ifPromiscuousMode.3 = INTEGER: false(2) IF-MIB::ifConnectorPresent.1 = INTEGER: true(1) IF-MIB::ifConnectorPresent.2 = INTEGER: true(1) IF-MIB::ifConnectorPresent.3 = INTEGER: false(2) IF-MIB::ifAlias.1 = STRING: IF-MIB::ifAlias.2 = STRING: IF-MIB::ifAlias.3 = STRING: IF-MIB::ifCounterDiscontinuityTime.1 = Timeticks: (0) 0:00:00.00 IF-MIB::ifCounterDiscontinuityTime.2 = Timeticks: (0) 0:00:00.00 IF-MIB::ifCounterDiscontinuityTime.3 = Timeticks: (0) 0:00:00.00 I changed port to 163 cause I am actually using net-snmp snmpd on port 161 still. Anyway, it seems bsnmpd insists these are 10 mbps interfaces? Why so? Cheers, -- Anders. From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 08:39:05 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A71616A420; Tue, 14 Feb 2006 08:39:05 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9862C43D48; Tue, 14 Feb 2006 08:39:04 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 09:39:00 +0100 Date: Tue, 14 Feb 2006 09:39:00 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Anders Nordby In-Reply-To: <20060214083010.GB41864@totem.fix.no> Message-ID: <20060214093513.F5083@beagle.kn.op.dlr.de> References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> <20060213173008.GA14643@totem.fix.no> <20060214090531.X5083@beagle.kn.op.dlr.de> <20060214083010.GB41864@totem.fix.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 14 Feb 2006 08:39:00.0220 (UTC) FILETIME=[1A1ABBC0:01C63142] Cc: freebsd-net@freebsd.org, Gleb Smirnoff , kuriyama@freebsd.org, demon@freebsd.org Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 08:39:05 -0000 On Tue, 14 Feb 2006, Anders Nordby wrote: AN>On Tue, Feb 14, 2006 at 09:07:42AM +0100, Harti Brandt wrote: AN>>>It seems ifHCInOctets and ifHCOutOctets are missing. How come? Do I need AN>>>to use SNMP v3? Another query tool? AN>> 10 bits/seconds seems utterly wrong for bge interfaces :-) The HC counters AN>> appear only for speeds >= 20Mbit/sec according to the RFC. AN> AN>I have two servers running bsnmpd in FreeBSD 6.0-RELEASE here now. Both AN>have bge gigabit interfaces. AN> AN>1) A HP Proliant DL 380 G4 (FreeBSD/i386), with (forced) 100baseTX AN>full-duplex link: AN> AN># ifconfig bge0 AN>bge0: flags=8843 mtu 1500 AN> options=1a AN> inet X.X.X.X netmask 0xfffffff0 broadcast 80.91.38.111 AN> ether 00:14:c2:61:5c:95 AN> media: Ethernet 100baseTX AN> status: active AN># snmpwalk -v 2c -c XXXXXX localhost:163 AN>ifMIB.ifMIBObjects.ifXTable.ifXEntry AN>IF-MIB::ifName.1 = STRING: bge0 AN>IF-MIB::ifName.2 = STRING: bge1 AN>IF-MIB::ifName.3 = STRING: lo0 AN>IF-MIB::ifInMulticastPkts.1 = Counter32: 3430507 AN>IF-MIB::ifInMulticastPkts.2 = Counter32: 0 AN>IF-MIB::ifInMulticastPkts.3 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.1 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.2 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.3 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.1 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.2 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.3 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.1 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.2 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.3 = Counter32: 0 AN>IF-MIB::ifLinkUpDownTrapEnable.1 = INTEGER: enabled(1) AN>IF-MIB::ifLinkUpDownTrapEnable.2 = INTEGER: enabled(1) AN>IF-MIB::ifLinkUpDownTrapEnable.3 = INTEGER: disabled(2) AN>IF-MIB::ifHighSpeed.1 = Gauge32: 10 AN>IF-MIB::ifHighSpeed.2 = Gauge32: 10 AN>IF-MIB::ifHighSpeed.3 = Gauge32: 0 AN>IF-MIB::ifPromiscuousMode.1 = INTEGER: false(2) AN>IF-MIB::ifPromiscuousMode.2 = INTEGER: false(2) AN>IF-MIB::ifPromiscuousMode.3 = INTEGER: false(2) AN>IF-MIB::ifConnectorPresent.1 = INTEGER: true(1) AN>IF-MIB::ifConnectorPresent.2 = INTEGER: true(1) AN>IF-MIB::ifConnectorPresent.3 = INTEGER: false(2) AN>IF-MIB::ifAlias.1 = STRING: AN>IF-MIB::ifAlias.2 = STRING: AN>IF-MIB::ifAlias.3 = STRING: AN>IF-MIB::ifCounterDiscontinuityTime.1 = Timeticks: (0) 0:00:00.00 AN>IF-MIB::ifCounterDiscontinuityTime.2 = Timeticks: (0) 0:00:00.00 AN>IF-MIB::ifCounterDiscontinuityTime.3 = Timeticks: (0) 0:00:00.00 AN> AN>2) A HP Proliant DL 385 G1 (FreeBSD/amd64), with gigabit link: AN> AN># ifconfig bge0 AN>bge0: flags=8843 mtu 1500 AN> options=1a AN> inet X.X.X.X netmask 0xffffffe0 broadcast 80.91.39.159 AN> ether 00:13:21:b3:01:f6 AN> media: Ethernet autoselect (1000baseTX ) AN> status: active AN># snmpwalk -v 2c -c XXXXXX localhost:163 AN>ifMIB.ifMIBObjects.ifXTable.ifXEntry AN>IF-MIB::ifName.1 = STRING: bge0 AN>IF-MIB::ifName.2 = STRING: bge1 AN>IF-MIB::ifName.3 = STRING: lo0 AN>IF-MIB::ifInMulticastPkts.1 = Counter32: 13303 AN>IF-MIB::ifInMulticastPkts.2 = Counter32: 0 AN>IF-MIB::ifInMulticastPkts.3 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.1 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.2 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.3 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.1 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.2 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.3 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.1 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.2 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.3 = Counter32: 0 AN>IF-MIB::ifLinkUpDownTrapEnable.1 = INTEGER: enabled(1) AN>IF-MIB::ifLinkUpDownTrapEnable.2 = INTEGER: enabled(1) AN>IF-MIB::ifLinkUpDownTrapEnable.3 = INTEGER: disabled(2) AN>IF-MIB::ifHighSpeed.1 = Gauge32: 10 AN>IF-MIB::ifHighSpeed.2 = Gauge32: 10 AN>IF-MIB::ifHighSpeed.3 = Gauge32: 0 AN>IF-MIB::ifPromiscuousMode.1 = INTEGER: false(2) AN>IF-MIB::ifPromiscuousMode.2 = INTEGER: false(2) AN>IF-MIB::ifPromiscuousMode.3 = INTEGER: false(2) AN>IF-MIB::ifConnectorPresent.1 = INTEGER: true(1) AN>IF-MIB::ifConnectorPresent.2 = INTEGER: true(1) AN>IF-MIB::ifConnectorPresent.3 = INTEGER: false(2) AN>IF-MIB::ifAlias.1 = STRING: AN>IF-MIB::ifAlias.2 = STRING: AN>IF-MIB::ifAlias.3 = STRING: AN>IF-MIB::ifCounterDiscontinuityTime.1 = Timeticks: (0) 0:00:00.00 AN>IF-MIB::ifCounterDiscontinuityTime.2 = Timeticks: (0) 0:00:00.00 AN>IF-MIB::ifCounterDiscontinuityTime.3 = Timeticks: (0) 0:00:00.00 AN> AN>I changed port to 163 cause I am actually using net-snmp snmpd on port AN>161 still. Anyway, it seems bsnmpd insists these are 10 mbps interfaces? AN>Why so? The driver reports a speed of 10Mbits/sec. ifHighSpeed is ifi_baudrate divided by 10^6 (and rounded). This is the default set by ether_ifattach() if the driver did not set another value. It seems that bge never sets that value so you end up with the default. This looks like a bug. harti From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 08:45:03 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BCAB16A422; Tue, 14 Feb 2006 08:45:03 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3665F43D60; Tue, 14 Feb 2006 08:45:00 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id k1E8ixB3067318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2006 11:45:00 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id k1E8ixEv067317; Tue, 14 Feb 2006 11:44:59 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 14 Feb 2006 11:44:59 +0300 From: Gleb Smirnoff To: Harti Brandt Message-ID: <20060214084459.GL86448@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Harti Brandt , Anders Nordby , freebsd-net@freebsd.org, demon@freebsd.org, kuriyama@freebsd.org References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> <20060213173008.GA14643@totem.fix.no> <20060214090531.X5083@beagle.kn.op.dlr.de> <20060214083010.GB41864@totem.fix.no> <20060214093513.F5083@beagle.kn.op.dlr.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <20060214093513.F5083@beagle.kn.op.dlr.de> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org, Anders Nordby , kuriyama@FreeBSD.org, demon@FreeBSD.org Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 08:45:03 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Tue, Feb 14, 2006 at 09:39:00AM +0100, Harti Brandt wrote: H> AN>I changed port to 163 cause I am actually using net-snmp snmpd on port H> AN>161 still. Anyway, it seems bsnmpd insists these are 10 mbps interfaces? H> AN>Why so? H> H> The driver reports a speed of 10Mbits/sec. ifHighSpeed is ifi_baudrate H> divided by 10^6 (and rounded). This is the default set by ether_ifattach() H> if the driver did not set another value. It seems that bge never sets that H> value so you end up with the default. This looks like a bug. Harti, we are thinking in parallel :) Andres, pls try the attached patch. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --FCuugMFkClbJLl1L Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="if_bge.baudr" Index: if_bge.c =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.118 diff -u -r1.118 if_bge.c --- if_bge.c 30 Jan 2006 13:45:55 -0000 1.118 +++ if_bge.c 14 Feb 2006 08:43:24 -0000 @@ -2192,6 +2192,7 @@ ifp->if_snd.ifq_drv_maxlen = BGE_TX_RING_CNT - 1; IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); IFQ_SET_READY(&ifp->if_snd); + ifp->if_baudrate = IF_Gbps(1); ifp->if_hwassist = BGE_CSUM_FEATURES; ifp->if_capabilities = IFCAP_HWCSUM | IFCAP_VLAN_HWTAGGING | IFCAP_VLAN_MTU | IFCAP_VLAN_HWCSUM; --FCuugMFkClbJLl1L-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 08:51:00 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 186F416A420; Tue, 14 Feb 2006 08:51:00 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE85C43D5E; Tue, 14 Feb 2006 08:50:56 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 09:50:55 +0100 Date: Tue, 14 Feb 2006 09:50:58 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Gleb Smirnoff In-Reply-To: <20060214084459.GL86448@cell.sick.ru> Message-ID: <20060214094812.T5083@beagle.kn.op.dlr.de> References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> <20060213173008.GA14643@totem.fix.no> <20060214090531.X5083@beagle.kn.op.dlr.de> <20060214083010.GB41864@totem.fix.no> <20060214093513.F5083@beagle.kn.op.dlr.de> <20060214084459.GL86448@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 14 Feb 2006 08:50:55.0632 (UTC) FILETIME=[C485F100:01C63143] Cc: freebsd-net@FreeBSD.org, Anders Nordby , kuriyama@FreeBSD.org, demon@FreeBSD.org Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 08:51:00 -0000 On Tue, 14 Feb 2006, Gleb Smirnoff wrote: GS>On Tue, Feb 14, 2006 at 09:39:00AM +0100, Harti Brandt wrote: GS>H> AN>I changed port to 163 cause I am actually using net-snmp snmpd on port GS>H> AN>161 still. Anyway, it seems bsnmpd insists these are 10 mbps interfaces? GS>H> AN>Why so? GS>H> GS>H> The driver reports a speed of 10Mbits/sec. ifHighSpeed is ifi_baudrate GS>H> divided by 10^6 (and rounded). This is the default set by ether_ifattach() GS>H> if the driver did not set another value. It seems that bge never sets that GS>H> value so you end up with the default. This looks like a bug. GS> GS>Harti, we are thinking in parallel :) :-) GS>Andres, pls try the attached patch. I wonder however, whether this could be done somewhere in mii? When setting ifmedia also the speed could be set. In this case SNMP would report the actual current speed. harti From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 08:52:34 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CA8C16A420; Tue, 14 Feb 2006 08:52:34 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id B102543D5C; Tue, 14 Feb 2006 08:52:32 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id k1E8qUYs067511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2006 11:52:31 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id k1E8qUDR067510; Tue, 14 Feb 2006 11:52:30 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 14 Feb 2006 11:52:30 +0300 From: Gleb Smirnoff To: Harti Brandt Message-ID: <20060214085230.GO86448@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Harti Brandt , Anders Nordby , freebsd-net@freebsd.org, demon@freebsd.org, kuriyama@freebsd.org References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> <20060213173008.GA14643@totem.fix.no> <20060214090531.X5083@beagle.kn.op.dlr.de> <20060214083010.GB41864@totem.fix.no> <20060214093513.F5083@beagle.kn.op.dlr.de> <20060214084459.GL86448@cell.sick.ru> <20060214094812.T5083@beagle.kn.op.dlr.de> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060214094812.T5083@beagle.kn.op.dlr.de> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org, Anders Nordby , kuriyama@FreeBSD.org, demon@FreeBSD.org Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 08:52:34 -0000 On Tue, Feb 14, 2006 at 09:50:58AM +0100, Harti Brandt wrote: H> GS>On Tue, Feb 14, 2006 at 09:39:00AM +0100, Harti Brandt wrote: H> GS>H> AN>I changed port to 163 cause I am actually using net-snmp snmpd on port H> GS>H> AN>161 still. Anyway, it seems bsnmpd insists these are 10 mbps interfaces? H> GS>H> AN>Why so? H> GS>H> H> GS>H> The driver reports a speed of 10Mbits/sec. ifHighSpeed is ifi_baudrate H> GS>H> divided by 10^6 (and rounded). This is the default set by ether_ifattach() H> GS>H> if the driver did not set another value. It seems that bge never sets that H> GS>H> value so you end up with the default. This looks like a bug. H> GS> H> GS>Harti, we are thinking in parallel :) H> H> :-) H> H> GS>Andres, pls try the attached patch. H> H> I wonder however, whether this could be done somewhere in mii? When H> setting ifmedia also the speed could be set. In this case SNMP would H> report the actual current speed. Yes, this should be next step. Afaik, no driver currently does this. I'll look at this. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 09:24:59 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AD5C16A426 for ; Tue, 14 Feb 2006 09:24:59 +0000 (GMT) (envelope-from opolyakov@yahoo.com) Received: from web35309.mail.mud.yahoo.com (web35309.mail.mud.yahoo.com [66.163.179.103]) by mx1.FreeBSD.org (Postfix) with SMTP id E022C43D5A for ; Tue, 14 Feb 2006 09:24:56 +0000 (GMT) (envelope-from opolyakov@yahoo.com) Received: (qmail 97710 invoked by uid 60001); 14 Feb 2006 09:24:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=53K+hWX+oIO09SLrF8U7V16YWtJjUNWI+bX2H1YydqQqc8pBwzEUcMwi0KSBcPvEI7eji9a3ykYeK7/yb+PxMSVZFfsEbBiHqxtgwI31SnsLLlmo7G8Ge/flEkDjC/SpAum1AiYIZD1bWhlPkjOC8DJLTDMf1Crjbkg78InMRjI= ; Message-ID: <20060214092456.97708.qmail@web35309.mail.mud.yahoo.com> Received: from [69.228.89.153] by web35309.mail.mud.yahoo.com via HTTP; Tue, 14 Feb 2006 01:24:56 PST Date: Tue, 14 Feb 2006 01:24:56 -0800 (PST) From: Oleg Polyakov To: Gleb Smirnoff , Harti Brandt In-Reply-To: <20060214084459.GL86448@cell.sick.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-852782144-1139909096=:97443" Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org, Anders Nordby , kuriyama@FreeBSD.org, demon@FreeBSD.org Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 09:24:59 -0000 --0-852782144-1139909096=:97443 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Id: Content-Disposition: inline --- Gleb Smirnoff wrote: > On Tue, Feb 14, 2006 at 09:39:00AM +0100, Harti Brandt wrote: > H> AN>I changed port to 163 cause I am actually using net-snmp snmpd on port > H> AN>161 still. Anyway, it seems bsnmpd insists these are 10 mbps > interfaces? > H> AN>Why so? > H> > H> The driver reports a speed of 10Mbits/sec. ifHighSpeed is ifi_baudrate > H> divided by 10^6 (and rounded). This is the default set by ether_ifattach() > > H> if the driver did not set another value. It seems that bge never sets that > > H> value so you end up with the default. This looks like a bug. > > Harti, we are thinking in parallel :) Parallel, yes ;) Here is the attached patch written just yesterday, not tested yet. It takes care of different bge adapters - some of them Fast Ethernets. --- Oleg > Andres, pls try the attached patch. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > > Index: if_bge.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v > retrieving revision 1.118 > diff -u -r1.118 if_bge.c > --- if_bge.c 30 Jan 2006 13:45:55 -0000 1.118 > +++ if_bge.c 14 Feb 2006 08:43:24 -0000 > @@ -2192,6 +2192,7 @@ > ifp->if_snd.ifq_drv_maxlen = BGE_TX_RING_CNT - 1; > IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); > IFQ_SET_READY(&ifp->if_snd); > + ifp->if_baudrate = IF_Gbps(1); > ifp->if_hwassist = BGE_CSUM_FEATURES; > ifp->if_capabilities = IFCAP_HWCSUM | IFCAP_VLAN_HWTAGGING | > IFCAP_VLAN_MTU | IFCAP_VLAN_HWCSUM; > > _______________________________________________ > 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" __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-852782144-1139909096=:97443 Content-Type: text/plain; name="if_bge.c.diff.txt" Content-Description: 2950440673-if_bge.c.diff.txt Content-Disposition: inline; filename="if_bge.c.diff.txt" --- if_bge.c.orig Tue Feb 14 00:52:58 2006 +++ if_bge.c Tue Feb 14 00:54:42 2006 @@ -2183,6 +2183,12 @@ } ifp->if_softc = sc; if_initname(ifp, device_get_name(dev), device_get_unit(dev)); + if ((pci_get_vendor(dev) == BCOM_VENDORID) && + ((pci_get_device(dev) == BCOM_DEVICEID_BCM5901) || + (pci_get_device(dev) == BCOM_DEVICEID_BCM5901A2))) { + ifp->if_baudrate = 100000000; + } + else ifp->if_baudrate = 1000000000; ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; ifp->if_ioctl = bge_ioctl; ifp->if_start = bge_start; --0-852782144-1139909096=:97443-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 09:29:00 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0B4516A420; Tue, 14 Feb 2006 09:29:00 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BE5E43D48; Tue, 14 Feb 2006 09:28:59 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 10:28:58 +0100 Date: Tue, 14 Feb 2006 10:28:59 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Oleg Polyakov In-Reply-To: <20060214092456.97708.qmail@web35309.mail.mud.yahoo.com> Message-ID: <20060214102735.U5083@beagle.kn.op.dlr.de> References: <20060214092456.97708.qmail@web35309.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 14 Feb 2006 09:28:58.0644 (UTC) FILETIME=[154DED40:01C63149] Cc: freebsd-net@FreeBSD.org, Anders Nordby , Gleb Smirnoff , kuriyama@FreeBSD.org, demon@FreeBSD.org Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 09:29:01 -0000 On Tue, 14 Feb 2006, Oleg Polyakov wrote: OP>--- Gleb Smirnoff wrote: OP> OP>> On Tue, Feb 14, 2006 at 09:39:00AM +0100, Harti Brandt wrote: OP>> H> AN>I changed port to 163 cause I am actually using net-snmp snmpd on port OP>> H> AN>161 still. Anyway, it seems bsnmpd insists these are 10 mbps OP>> interfaces? OP>> H> AN>Why so? OP>> H> OP>> H> The driver reports a speed of 10Mbits/sec. ifHighSpeed is ifi_baudrate OP>> H> divided by 10^6 (and rounded). This is the default set by ether_ifattach() OP>> OP>> H> if the driver did not set another value. It seems that bge never sets that OP>> OP>> H> value so you end up with the default. This looks like a bug. OP>> OP>> Harti, we are thinking in parallel :) OP> OP>Parallel, yes ;) Wow! Seems the massive introduction of dual-core CPUs and multiprocessor machines starts to give results :-) And all that without mutexes and locks. harti From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 09:30:06 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75A6716A420 for ; Tue, 14 Feb 2006 09:30:06 +0000 (GMT) (envelope-from raglon@packetfront.com) Received: from mail.packetfront.com (mail.packetfront.com [212.247.6.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id B89E443D48 for ; Tue, 14 Feb 2006 09:30:05 +0000 (GMT) (envelope-from raglon@packetfront.com) Received: from localhost (localhost [127.0.0.1]) by mail.packetfront.com (Postfix) with ESMTP id 9BCA6A348B; Tue, 14 Feb 2006 10:30:05 +0100 (CET) Received: from mail.packetfront.com ([127.0.0.1]) by localhost (mail.packetfront.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03330-03; Tue, 14 Feb 2006 10:30:05 +0100 (CET) Received: from [192.168.1.137] (unknown [192.168.1.137]) by mail.packetfront.com (Postfix) with ESMTP id 260E2A348A; Tue, 14 Feb 2006 10:30:05 +0100 (CET) Message-ID: <43F1A2D1.7040402@packetfront.com> Date: Tue, 14 Feb 2006 10:28:49 +0100 From: Ragnar Lonn User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan Voras References: <43F0CE40.5040800@fer.hr> In-Reply-To: <43F0CE40.5040800@fer.hr> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at packetfront.com Cc: net@freebsd.org Subject: Re: TCP Performance advice needed [long!] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 09:30:06 -0000 I don't know what tcp.inflight does but I know that this type of application protocol, that expects a reply before sending the next piece of data, will always be completely dependent upon roundtrip times for its throughput - the roundtrip time for the exchange "transmit-reply" will limit the possible throughput you can get so if you want higher performance, either change the protocol so it works more like TCP with a "window" of data that is being sent. I.e. send several packets at once without waiting for replies in between. Or...use several concurrent TCP streams to speed things up (like NNTP servers do, for instance). Maybe this isn't what you wanted to know, but I thought I'd write it anyhow :) /Ragnar Ivan Voras wrote: > I'm writing a simple client-server application and I think I have a > performance problem. The basic communication between the server and > the client is like this: the server sends messages at most MAX_SIZE in > length, one by one, and waits until the client acknowleges each > message before sending the next one. Messages of maximum length > (MAX_SIZE) make about 75% or more of total messages. Client responses > are small and of fixed size (<10 bytes). I have TCP_NODELAY turned on > on both. All sends are done with a blocking send() call of required > size. Client's response processing time doesn't depend notably on the > message size. > > I've done some simple benchmarks and I'm puzzled about the results. In > the benchmarks, the MAX_SIZE is periodically increased from 256 to > 65536 in power-of-2 steps. In the benchmark setup the server and > client are connected directly via 100Mbps connection without > transmission problems (FTP pushes ~12MB/s in both directions). > > Problem: It seems that the packets-per-second rate sent by the server > increases from 1000 at MAX_SIZE=256 to 2500 at MAX_SIZE=4096, then > sharply drops to 400 at MAX_SIZE=8192 and above. Remembering a > discussion on Samba performance, I tried disabling > tcp.inflight.enable, and the results for large packet sizes became > very good, about 4000pps, until MAX_SIZE=32768, where it drops to 400 > again. What does tcp.inflight do, and can it be done without changing > sysctls? > > Another problem: the starting rates, e.g. ~1000pps at MAX_SIZE=256, > seem too low to me - this pushes only 256kB/s. This is a problem > because in real usage such small sizes could be common. Looking at > netstat, packet rates seem to vary randomly. Here's netstat log for > session with MAX_SIZE=512: > > > 1 0 66 1 0 178 0 > 378 0 27956 378 0 132192 0 > 1405 0 103962 1405 0 488770 0 > 1193 0 88274 1193 0 414994 0 > 1093 0 80874 1093 0 380194 0 > 1010 0 74732 1011 0 351658 0 > 930 0 68812 930 0 323732 0 > 797 0 58970 796 0 276576 0 > 95 0 7022 95 0 32890 0 > input (Total) output > packets errs bytes packets errs bytes colls > 201 0 14866 201 0 69778 0 > 495 0 36622 495 0 172202 0 > 739 0 54678 739 0 257002 0 > 1291 0 95526 1292 0 449728 0 > 1134 0 83908 1133 0 394094 0 > 1026 0 75916 1026 0 356616 0 > 987 0 73030 987 0 343306 0 > 873 0 64594 873 0 303634 0 > 855 0 63262 855 0 297370 0 > 360 0 26632 360 0 125372 0 > 1002 0 74140 1002 0 348264 0 > 1166 0 86276 1166 0 405860 0 > 1056 0 78136 1056 0 367056 0 > 937 0 69330 937 0 325906 0 > 753 0 55714 753 0 261874 0 > 111 0 8206 111 0 38458 0 > 143 0 10566 144 0 49692 0 > 1 0 66 1 0 178 0 > 1 0 66 1 0 178 0 > > Here's for MAX_SIZE=8192: > > input (Total) output > packets errs bytes packets errs bytes colls > 1082 0 74292 1438 0 1580040 0 > 1287 0 88366 1701 0 1885062 0 > 1403 0 96342 1867 0 2044074 0 > 1763 0 121046 2346 0 2578684 0 > 1532 0 105208 2026 0 2236048 0 > 1866 0 128124 2463 0 2726554 0 > 2401 0 164874 3192 0 3508384 0 > 2797 0 192058 3719 0 4095824 0 > 2791 0 191646 3714 0 4070142 0 > 2773 0 190410 3692 0 4052512 0 > 2583 0 177358 3438 0 3780296 0 > 2947 0 202358 3927 0 4307032 0 > 2963 0 203462 3943 0 4324596 0 > 2946 0 202292 3926 0 4307032 0 > 2965 0 203594 3946 0 4341638 0 > 2989 0 205242 3977 0 4359552 0 > 2928 0 201056 3898 0 4289006 0 > 2995 0 205654 3983 0 4368192 0 > 2965 0 203594 3945 0 4333018 0 > 2983 0 204830 3973 0 4359598 0 > 2978 0 204484 3968 0 4359380 0 > input (Total) output > packets errs bytes packets errs bytes colls > 2986 0 205028 3976 0 4359910 0 > 2979 0 204566 3969 0 4359578 0 > 2123 0 145790 2827 0 3089432 0 > > It seems that the transmission for MAX_SIZE=8192 has slow start but I > don't know how to disable it? > > Help on any of these points, or suggestions where to investigate > further will be appreciated! > _______________________________________________ > 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 Feb 14 09:49:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98D3016A420 for ; Tue, 14 Feb 2006 09:49:51 +0000 (GMT) (envelope-from digitaltrix@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34A5943D4C for ; Tue, 14 Feb 2006 09:49:51 +0000 (GMT) (envelope-from digitaltrix@gmail.com) Received: by wproxy.gmail.com with SMTP id i11so1205705wra for ; Tue, 14 Feb 2006 01:49:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=hJw4fSLCjBJMFoj/crWCnSg09DgoCjAfWn+7KwoZzP7momWauv2+hykis1eEuFcTjIuQWvYbk/y4f+RhlJ/JNztpvr09UoAVA06AkLNRY3MFm/rUOGclp2cF3gdzoWjwmAPmihW874jG6cx+N0/s0M/IdYOgdcOIfP2AiplE7TE= Received: by 10.54.124.2 with SMTP id w2mr2171630wrc; Tue, 14 Feb 2006 01:49:49 -0800 (PST) Received: by 10.54.135.4 with HTTP; Tue, 14 Feb 2006 01:49:49 -0800 (PST) Message-ID: <7571f1f60602140149y5e13c8e5j9f7dc3b9c8b5e807@mail.gmail.com> Date: Tue, 14 Feb 2006 15:19:49 +0530 From: Murugan To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Help - PPPoE Server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 09:49:51 -0000 Hi i need a sample(working) configuration files to set up a PPPoE server in FreeBSD 4.9. From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 10:20:28 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 048EE16A420 for ; Tue, 14 Feb 2006 10:20:28 +0000 (GMT) (envelope-from opolyakov@yahoo.com) Received: from web35305.mail.mud.yahoo.com (web35305.mail.mud.yahoo.com [66.163.179.99]) by mx1.FreeBSD.org (Postfix) with SMTP id A1CB443D5C for ; Tue, 14 Feb 2006 10:20:24 +0000 (GMT) (envelope-from opolyakov@yahoo.com) Received: (qmail 97800 invoked by uid 60001); 14 Feb 2006 10:20:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bEGidy+UwHqpuoFztOTxnP5h7USXnrS2Zyl1/NL5Iv9xUmU83yn6oTTefAbDpc5fx3mSg7kPBD0HjlSoSD8oVxhgZ6LgHDSI8TYO6tZZdQLSrRVKCsl4U7gyZGXbkHrLC8iwDLUBtp8QR7cuVjogFAtnG9FJ+ioID8rPI6ak6cs= ; Message-ID: <20060214102023.97798.qmail@web35305.mail.mud.yahoo.com> Received: from [69.228.89.153] by web35305.mail.mud.yahoo.com via HTTP; Tue, 14 Feb 2006 02:20:23 PST Date: Tue, 14 Feb 2006 02:20:23 -0800 (PST) From: Oleg Polyakov To: Gleb Smirnoff , Harti Brandt In-Reply-To: <20060214092456.97708.qmail@web35309.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org, Anders Nordby , kuriyama@FreeBSD.org, demon@FreeBSD.org Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 10:20:28 -0000 --- Oleg Polyakov wrote: > --- Gleb Smirnoff wrote: > > > On Tue, Feb 14, 2006 at 09:39:00AM +0100, Harti Brandt wrote: > > H> AN>I changed port to 163 cause I am actually using net-snmp snmpd on > port > > H> AN>161 still. Anyway, it seems bsnmpd insists these are 10 mbps > > interfaces? > > H> AN>Why so? > > H> > > H> The driver reports a speed of 10Mbits/sec. ifHighSpeed is ifi_baudrate > > H> divided by 10^6 (and rounded). This is the default set by > ether_ifattach() > > > > H> if the driver did not set another value. It seems that bge never sets > that > > > > H> value so you end up with the default. This looks like a bug. > > > > Harti, we are thinking in parallel :) > > Parallel, yes ;) > Here is the attached patch written just yesterday, not tested yet. It has been tested: # snmpwalk -v 1 -c pub localhost:161 | grep Speed IF-MIB::ifSpeed.1 = Gauge32: 1000000000 IF-MIB::ifSpeed.2 = Gauge32: 1000000000 IF-MIB::ifSpeed.3 = Gauge32: 0 IF-MIB::ifSpeed.4 = Gauge32: 0 IF-MIB::ifHighSpeed.1 = Gauge32: 1000 IF-MIB::ifHighSpeed.2 = Gauge32: 1000 IF-MIB::ifHighSpeed.3 = Gauge32: 0 IF-MIB::ifHighSpeed.4 = Gauge32: 0 And adapters are: # dmesg | grep bge bge0: mem 0xd0200000-0xd020ffff irq 18 at device 0.0 on pci4 miibus0: on bge0 bge0: Ethernet address: 00:30:48:82:12:44 bge1: mem 0xd0300000-0xd030ffff irq 19 at device 0.0 on pci5 miibus1: on bge1 bge1: Ethernet address: 00:30:48:82:12:45 bge0: link state changed to UP # ifconfig -l bge0 bge1 plip0 lo0 > It takes care of different bge adapters - some of them Fast Ethernets. > > > --- > Oleg > > > Andres, pls try the attached patch. > > > > -- > > Totus tuus, Glebius. > > GLEBIUS-RIPN GLEB-RIPE > > > Index: if_bge.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v > > retrieving revision 1.118 > > diff -u -r1.118 if_bge.c > > --- if_bge.c 30 Jan 2006 13:45:55 -0000 1.118 > > +++ if_bge.c 14 Feb 2006 08:43:24 -0000 > > @@ -2192,6 +2192,7 @@ > > ifp->if_snd.ifq_drv_maxlen = BGE_TX_RING_CNT - 1; > > IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); > > IFQ_SET_READY(&ifp->if_snd); > > + ifp->if_baudrate = IF_Gbps(1); > > ifp->if_hwassist = BGE_CSUM_FEATURES; > > ifp->if_capabilities = IFCAP_HWCSUM | IFCAP_VLAN_HWTAGGING | > > IFCAP_VLAN_MTU | IFCAP_VLAN_HWCSUM; > > > _______________________________________________ > > 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" > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > --- if_bge.c.orig Tue Feb 14 00:52:58 2006 > +++ if_bge.c Tue Feb 14 00:54:42 2006 > @@ -2183,6 +2183,12 @@ > } > ifp->if_softc = sc; > if_initname(ifp, device_get_name(dev), device_get_unit(dev)); > + if ((pci_get_vendor(dev) == BCOM_VENDORID) && > + ((pci_get_device(dev) == BCOM_DEVICEID_BCM5901) || > + (pci_get_device(dev) == BCOM_DEVICEID_BCM5901A2))) { > + ifp->if_baudrate = 100000000; > + } > + else ifp->if_baudrate = 1000000000; > ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; > ifp->if_ioctl = bge_ioctl; > ifp->if_start = bge_start; > > _______________________________________________ > 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" __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 10:37:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5DA916A420; Tue, 14 Feb 2006 10:37:25 +0000 (GMT) (envelope-from anders@FreeBSD.org) Received: from totem.fix.no (totem.fix.no [80.91.36.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 662B043D45; Tue, 14 Feb 2006 10:37:25 +0000 (GMT) (envelope-from anders@FreeBSD.org) Received: by totem.fix.no (Postfix, from userid 1000) id 72E5C8DB14A; Tue, 14 Feb 2006 11:37:23 +0100 (CET) Date: Tue, 14 Feb 2006 11:37:23 +0100 From: Anders Nordby To: Gleb Smirnoff , Harti Brandt , freebsd-net@freebsd.org Message-ID: <20060214103723.GA45138@totem.fix.no> References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> <20060213173008.GA14643@totem.fix.no> <20060214090531.X5083@beagle.kn.op.dlr.de> <20060214083010.GB41864@totem.fix.no> <20060214093513.F5083@beagle.kn.op.dlr.de> <20060214084459.GL86448@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060214084459.GL86448@cell.sick.ru> X-PGP-Key: http://anders.fix.no/pgp/ X-PGP-Key-FingerPrint: 1E0F C53C D8DF 6A8F EAAD 19C5 D12A BC9F 0083 5956 User-Agent: Mutt/1.5.11 Cc: Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 10:37:26 -0000 Hi, On Tue, Feb 14, 2006 at 11:44:59AM +0300, Gleb Smirnoff wrote: > H> The driver reports a speed of 10Mbits/sec. ifHighSpeed is ifi_baudrate > H> divided by 10^6 (and rounded). This is the default set by ether_ifattach() > H> if the driver did not set another value. It seems that bge never sets that > H> value so you end up with the default. This looks like a bug. > > Harti, we are thinking in parallel :) > > Andres, pls try the attached patch. > > Index: if_bge.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v > retrieving revision 1.118 > diff -u -r1.118 if_bge.c > --- if_bge.c 30 Jan 2006 13:45:55 -0000 1.118 > +++ if_bge.c 14 Feb 2006 08:43:24 -0000 > @@ -2192,6 +2192,7 @@ > ifp->if_snd.ifq_drv_maxlen = BGE_TX_RING_CNT - 1; > IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); > IFQ_SET_READY(&ifp->if_snd); > + ifp->if_baudrate = IF_Gbps(1); > ifp->if_hwassist = BGE_CSUM_FEATURES; > ifp->if_capabilities = IFCAP_HWCSUM | IFCAP_VLAN_HWTAGGING | > IFCAP_VLAN_MTU | IFCAP_VLAN_HWCSUM; The patches gives me ifHighSpeed = 1000 on bge interfaces, also where the interface is forced to 100baseTX. In any case I get ifHCOutOctets and ifHCInOctets, which was what I was originally looking for. Making bsnmpd report actual speed seems sensible, yes. I should make a list of "what bsnmpd needs" to be more usable, in case Harti is interested. ;-P Mvh, -- Anders. From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 10:38:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F6A116A420 for ; Tue, 14 Feb 2006 10:38:14 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8852343D46 for ; Tue, 14 Feb 2006 10:38:13 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8xbJ-0005Aq-Gl for freebsd-net@freebsd.org; Tue, 14 Feb 2006 18:40:06 +0800 Message-ID: <43F1B283.6000307@micom.mng.net> Date: Tue, 14 Feb 2006 18:35:47 +0800 From: Ganbold User-Agent: Thunderbird 1.5 (X11/20060202) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <6.2.1.2.2.20051107141043.03b34eb0@202.179.0.80> <015201c5e379$2f021220$0402a8c0@inet.lan> <6.2.1.2.2.20051114150835.0483b400@202.179.0.80> <00ce01c5e8eb$d27552b0$0402a8c0@inet.lan> In-Reply-To: <00ce01c5e8eb$d27552b0$0402a8c0@inet.lan> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Internet billing using mpd, traffic accounting, limiting etc X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 10:38:14 -0000 Hi all, I'm looking for Internet billing and traffic accounting software based on mpd in FreeBSD. I found abills, netams and freenibs. Can somebody advise me regarding these? Basically I need free billing which has traffic accounting, Session-Timeout attribute support, Outgoing Traffic limiting and traffic quota, time based login support for LAN users, web reporting and graphing, and database support. Which one is best from above three software? Is there any other software that I should try? thanks in advance, Ganbold From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 10:39:05 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2DEA16A420; Tue, 14 Feb 2006 10:39:04 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3981543D46; Tue, 14 Feb 2006 10:39:03 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id k1EAd14K069904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2006 13:39:01 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id k1EAd1KO069903; Tue, 14 Feb 2006 13:39:01 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 14 Feb 2006 13:39:01 +0300 From: Gleb Smirnoff To: Anders Nordby Message-ID: <20060214103901.GB68308@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Anders Nordby , Harti Brandt , freebsd-net@FreeBSD.org References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> <20060213173008.GA14643@totem.fix.no> <20060214090531.X5083@beagle.kn.op.dlr.de> <20060214083010.GB41864@totem.fix.no> <20060214093513.F5083@beagle.kn.op.dlr.de> <20060214084459.GL86448@cell.sick.ru> <20060214103723.GA45138@totem.fix.no> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060214103723.GA45138@totem.fix.no> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org, Harti Brandt Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 10:39:05 -0000 On Tue, Feb 14, 2006 at 11:37:23AM +0100, Anders Nordby wrote: A> I should make a list of "what bsnmpd needs" to be more usable, in case A> Harti is interested. ;-P Where is such list? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 10:48:26 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 192E116A42D; Tue, 14 Feb 2006 10:48:26 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72F1D43D45; Tue, 14 Feb 2006 10:48:24 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 11:48:23 +0100 Date: Tue, 14 Feb 2006 11:48:26 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Gleb Smirnoff In-Reply-To: <20060214103901.GB68308@cell.sick.ru> Message-ID: <20060214114651.J5083@beagle.kn.op.dlr.de> References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> <20060213173008.GA14643@totem.fix.no> <20060214090531.X5083@beagle.kn.op.dlr.de> <20060214083010.GB41864@totem.fix.no> <20060214093513.F5083@beagle.kn.op.dlr.de> <20060214084459.GL86448@cell.sick.ru> <20060214103723.GA45138@totem.fix.no> <20060214103901.GB68308@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 14 Feb 2006 10:48:23.0984 (UTC) FILETIME=[2DAB1B00:01C63154] Cc: freebsd-net@FreeBSD.org, Anders Nordby Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 10:48:26 -0000 On Tue, 14 Feb 2006, Gleb Smirnoff wrote: GS>On Tue, Feb 14, 2006 at 11:37:23AM +0100, Anders Nordby wrote: GS>A> I should make a list of "what bsnmpd needs" to be more usable, in case GS>A> Harti is interested. ;-P GS> GS>Where is such list? I was thinking to setup such a list on my FreeBSD WiKi page for some time now, just never came around to do it. I can do it when I come back from lunch :-) harti From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 10:58:23 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7D6716A420; Tue, 14 Feb 2006 10:58:23 +0000 (GMT) (envelope-from anders@FreeBSD.org) Received: from totem.fix.no (totem.fix.no [80.91.36.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F02D43D55; Tue, 14 Feb 2006 10:58:23 +0000 (GMT) (envelope-from anders@FreeBSD.org) Received: by totem.fix.no (Postfix, from userid 1000) id 7BD528DB148; Tue, 14 Feb 2006 11:58:21 +0100 (CET) Date: Tue, 14 Feb 2006 11:58:21 +0100 From: Anders Nordby To: Gleb Smirnoff , Harti Brandt , freebsd-net@FreeBSD.org Message-ID: <20060214105821.GA47035@totem.fix.no> References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> <20060213173008.GA14643@totem.fix.no> <20060214090531.X5083@beagle.kn.op.dlr.de> <20060214083010.GB41864@totem.fix.no> <20060214093513.F5083@beagle.kn.op.dlr.de> <20060214084459.GL86448@cell.sick.ru> <20060214103723.GA45138@totem.fix.no> <20060214103901.GB68308@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060214103901.GB68308@cell.sick.ru> X-PGP-Key: http://anders.fix.no/pgp/ X-PGP-Key-FingerPrint: 1E0F C53C D8DF 6A8F EAAD 19C5 D12A BC9F 0083 5956 User-Agent: Mutt/1.5.11 Cc: demon@FreeBSD.org, kuriyama@FreeBSD.org Subject: Re: bsnmpd (was: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 10:58:24 -0000 Hi, On Tue, Feb 14, 2006 at 01:39:01PM +0300, Gleb Smirnoff wrote: > A> I should make a list of "what bsnmpd needs" to be more usable, in case > A> Harti is interested. ;-P > Where is such list? Some things popping off my mind: - Ability to run as a different user. I suppose we should add a snmp user to the base system. Running as root is not OK, when it is not necessary (net-snmp snmpd can run as a different user, it has a related -r option to not exit if it has privilege problems). - Ability to chroot itself (yes please, for security). - Ability to execute programs and return values on given OIDs, and also cache their results so that the programs doesn't have to be run for every time. It's necessary to cache values to avoid running resource intensive scripts/programs more than necessary. I am using net-snmp snmpd mostly currently, but consider switching as I now can get my 64-bit counters from bsnmpd. It seems net-snmp snmpd can not give ifHCInOctets/ifHCOutOctets (Counter64) in FreeBSD yet. At least the exec issue above must be resolved for me to switch to bsnmpd. Oh, and a couple of questions. If I only want read access enabled, is commenting "write :=" and "trap :=" out all that is necessary? If not, how do I do it? Normally, I only want to read from my SNMP agents. I would prefer to have trap/write disabled completely. Another thing. The trap support in bsnmpd, it's only for forwarding traps? Does bsnmpd have, or will it ever get an ability to generate traps upon failures in FreeBSD? Cheers, -- Anders. From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 11:02:20 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C58316A422; Tue, 14 Feb 2006 11:02:20 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA30C43D45; Tue, 14 Feb 2006 11:02:19 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id k1EB2Hgb070517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2006 14:02:18 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id k1EB2HXb070516; Tue, 14 Feb 2006 14:02:17 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 14 Feb 2006 14:02:17 +0300 From: Gleb Smirnoff To: Oleg Polyakov Message-ID: <20060214110217.GD68308@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Oleg Polyakov , Harti Brandt , freebsd-net@FreeBSD.org, Anders Nordby , kuriyama@FreeBSD.org, demon@FreeBSD.org References: <20060214092456.97708.qmail@web35309.mail.mud.yahoo.com> <20060214102023.97798.qmail@web35305.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: <20060214102023.97798.qmail@web35305.mail.mud.yahoo.com> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org, Anders Nordby , Harti Brandt , kuriyama@FreeBSD.org, demon@FreeBSD.org Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 11:02:20 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Oleg, Anders, can you please remove all your changes to if_bge.c and test the attached patch. Awaiting for feedback and thanks. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --jI8keyz6grp/JLjh Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="baudrate.diff" Index: net/if_media.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_media.c,v retrieving revision 1.22 diff -u -r1.22 if_media.c --- net/if_media.c 25 Dec 2005 23:28:23 -0000 1.22 +++ net/if_media.c 14 Feb 2006 09:51:09 -0000 @@ -385,6 +385,28 @@ return match; } +/* + * Compute the interface `baudrate' from the media, for the interface + * metrics (used by routing daemons). + */ +static const struct ifmedia_baudrate ifmedia_baudrate_descriptions[] = + IFM_BAUDRATE_DESCRIPTIONS; + +uint64_t +ifmedia_baudrate(int mword) +{ + int i; + + for (i = 0; ifmedia_baudrate_descriptions[i].ifmb_word != 0; i++) { + if ((mword & (IFM_NMASK|IFM_TMASK)) == + ifmedia_baudrate_descriptions[i].ifmb_word) + return (ifmedia_baudrate_descriptions[i].ifmb_baudrate); + } + + /* Not known. */ + return (0); +} + #ifdef IFMEDIA_DEBUG struct ifmedia_description ifm_type_descriptions[] = IFM_TYPE_DESCRIPTIONS; Index: net/if_media.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_media.h,v retrieving revision 1.30 diff -u -r1.30 if_media.h --- net/if_media.h 22 Feb 2005 13:04:03 -0000 1.30 +++ net/if_media.h 14 Feb 2006 10:29:59 -0000 @@ -104,6 +104,9 @@ int ifmedia_ioctl(struct ifnet *ifp, struct ifreq *ifr, struct ifmedia *ifm, u_long cmd); +/* Compute baudrate for a given media. */ +uint64_t ifmedia_baudrate(int); + #endif /*_KERNEL */ /* @@ -138,8 +141,8 @@ #define IFM_1000_CX 15 /* 1000baseCX - 150ohm STP */ #define IFM_1000_T 16 /* 1000baseT - 4 pair cat 5 */ #define IFM_HPNA_1 17 /* HomePNA 1.0 (1Mb/s) */ -#define IFM_10GBASE_SR 18 /* 10GBASE-SR 850nm Multi-mode Fiber */ -#define IFM_10GBASE_LR 19 /* 10GBASE-LR 1310nm Single-mode Fiber */ +#define IFM_10G_LR 18 /* 10GBase-LR 1310nm Single-mode */ +#define IFM_10G_SR 19 /* 10GBase-SR 850nm Multi-mode */ /* note 31 is the max! */ @@ -543,4 +546,59 @@ { 0, NULL }, \ } +/* + * Baudrate descriptions for the various media types. + */ +struct ifmedia_baudrate { + int ifmb_word; /* media word */ + uint64_t ifmb_baudrate; /* corresponding baudrate */ +}; + +#define IFM_BAUDRATE_DESCRIPTIONS { \ + { IFM_ETHER | IFM_10_T, IF_Mbps(10) }, \ + { IFM_ETHER | IFM_10_2, IF_Mbps(10) }, \ + { IFM_ETHER | IFM_10_5, IF_Mbps(10) }, \ + { IFM_ETHER | IFM_100_TX, IF_Mbps(100) }, \ + { IFM_ETHER | IFM_100_FX, IF_Mbps(100) }, \ + { IFM_ETHER | IFM_100_T4, IF_Mbps(100) }, \ + { IFM_ETHER | IFM_100_VG, IF_Mbps(100) }, \ + { IFM_ETHER | IFM_100_T2, IF_Mbps(100) }, \ + { IFM_ETHER | IFM_1000_SX, IF_Mbps(1000) }, \ + { IFM_ETHER | IFM_10_STP, IF_Mbps(10) }, \ + { IFM_ETHER | IFM_10_FL, IF_Mbps(10) }, \ + { IFM_ETHER | IFM_1000_LX, IF_Mbps(1000) }, \ + { IFM_ETHER | IFM_1000_CX, IF_Mbps(1000) }, \ + { IFM_ETHER | IFM_1000_T, IF_Mbps(1000) }, \ + { IFM_ETHER | IFM_HPNA_1, IF_Mbps(1) }, \ + { IFM_ETHER | IFM_10G_LR, IF_Gbps(10ULL) }, \ + \ + { IFM_TOKEN | IFM_TOK_STP4, IF_Mbps(4) }, \ + { IFM_TOKEN | IFM_TOK_STP16, IF_Mbps(16) }, \ + { IFM_TOKEN | IFM_TOK_UTP4, IF_Mbps(4) }, \ + { IFM_TOKEN | IFM_TOK_UTP16, IF_Mbps(16) }, \ + \ + { IFM_FDDI | IFM_FDDI_SMF, IF_Mbps(100) }, \ + { IFM_FDDI | IFM_FDDI_MMF, IF_Mbps(100) }, \ + { IFM_FDDI | IFM_FDDI_UTP, IF_Mbps(100) }, \ + \ + { IFM_IEEE80211 | IFM_IEEE80211_FH1, IF_Mbps(1) }, \ + { IFM_IEEE80211 | IFM_IEEE80211_FH2, IF_Mbps(2) }, \ + { IFM_IEEE80211 | IFM_IEEE80211_DS2, IF_Mbps(2) }, \ + { IFM_IEEE80211 | IFM_IEEE80211_DS5, IF_Kbps(5500) }, \ + { IFM_IEEE80211 | IFM_IEEE80211_DS11, IF_Mbps(11) }, \ + { IFM_IEEE80211 | IFM_IEEE80211_DS1, IF_Mbps(1) }, \ + { IFM_IEEE80211 | IFM_IEEE80211_DS22, IF_Mbps(22) }, \ + { IFM_IEEE80211 | IFM_IEEE80211_OFDM6, IF_Mbps(6) }, \ + { IFM_IEEE80211 | IFM_IEEE80211_OFDM9, IF_Mbps(9) }, \ + { IFM_IEEE80211 | IFM_IEEE80211_OFDM12, IF_Mbps(12) }, \ + { IFM_IEEE80211 | IFM_IEEE80211_OFDM18, IF_Mbps(18) }, \ + { IFM_IEEE80211 | IFM_IEEE80211_OFDM24, IF_Mbps(24) }, \ + { IFM_IEEE80211 | IFM_IEEE80211_OFDM36, IF_Mbps(36) }, \ + { IFM_IEEE80211 | IFM_IEEE80211_OFDM48, IF_Mbps(48) }, \ + { IFM_IEEE80211 | IFM_IEEE80211_OFDM54, IF_Mbps(54) }, \ + { IFM_IEEE80211 | IFM_IEEE80211_OFDM72, IF_Mbps(72) }, \ + \ + { 0, 0 }, \ +} + #endif /* _NET_IF_MEDIA_H_ */ Index: dev/mii/mii.c =================================================================== RCS file: /home/ncvs/src/sys/dev/mii/mii.c,v retrieving revision 1.26 diff -u -r1.26 mii.c --- dev/mii/mii.c 11 Jun 2005 00:20:38 -0000 1.26 +++ dev/mii/mii.c 14 Feb 2006 10:24:21 -0000 @@ -240,9 +240,20 @@ miibus_statchg(device_t dev) { device_t parent; + struct mii_data *mii; + struct ifnet *ifp; parent = device_get_parent(dev); MIIBUS_STATCHG(parent); + + mii = device_get_softc(dev); + + /* + * Note that each NIC's softc must start with an ifnet pointer. + * XXX: EVIL HACK! + */ + ifp = *(struct ifnet **)device_get_softc(parent); + ifp->if_baudrate = ifmedia_baudrate(mii->mii_media_active); return; } --jI8keyz6grp/JLjh-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 11:04:44 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 433E116A420 for ; Tue, 14 Feb 2006 11:04:44 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.net (mail.yazzy.net [217.8.140.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACC3E43D4C for ; Tue, 14 Feb 2006 11:04:42 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.witelcom.com ([84.247.144.144] helo=marcin) by mail.yazzy.net with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1F8xyX-0005Dv-Sn; Tue, 14 Feb 2006 12:04:06 +0100 Date: Tue, 14 Feb 2006 12:04:39 +0100 From: Marcin Jessa To: Ganbold Message-Id: <20060214120439.400a7707.lists@yazzy.org> In-Reply-To: <43F1B283.6000307@micom.mng.net> References: <6.2.1.2.2.20051107141043.03b34eb0@202.179.0.80> <015201c5e379$2f021220$0402a8c0@inet.lan> <6.2.1.2.2.20051114150835.0483b400@202.179.0.80> <00ce01c5e8eb$d27552b0$0402a8c0@inet.lan> <43F1B283.6000307@micom.mng.net> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.11; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) Cc: freebsd-net@freebsd.org Subject: Re: Internet billing using mpd, traffic accounting, limiting etc X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 11:04:44 -0000 On Tue, 14 Feb 2006 18:35:47 +0800 Ganbold wrote: > Hi all, > > I'm looking for Internet billing and traffic accounting software based > on mpd in FreeBSD. > I found abills, netams and freenibs. Can somebody advise me regarding > these? Basically I need free billing which has traffic accounting, > Session-Timeout attribute support, Outgoing Traffic limiting and > traffic quota, time based login support for LAN users, web reporting > and graphing, and database support. > Which one is best from above three software? Is there any other > software that I should try? Install freeradius with sql backend. You can use dialupadmin for the billing/accounting part. From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 12:27:12 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 186AB16A420; Tue, 14 Feb 2006 12:27:12 +0000 (GMT) (envelope-from anders@FreeBSD.org) Received: from totem.fix.no (totem.fix.no [80.91.36.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 603A343D49; Tue, 14 Feb 2006 12:27:11 +0000 (GMT) (envelope-from anders@FreeBSD.org) Received: by totem.fix.no (Postfix, from userid 1000) id E67018DB14A; Tue, 14 Feb 2006 13:27:08 +0100 (CET) Date: Tue, 14 Feb 2006 13:27:08 +0100 From: Anders Nordby To: Gleb Smirnoff , Oleg Polyakov , Harti Brandt , freebsd-net@FreeBSD.org, kuriyama@FreeBSD.org, demon@FreeBSD.org Message-ID: <20060214122708.GA51048@totem.fix.no> References: <20060214092456.97708.qmail@web35309.mail.mud.yahoo.com> <20060214102023.97798.qmail@web35305.mail.mud.yahoo.com> <20060214110217.GD68308@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060214110217.GD68308@cell.sick.ru> X-PGP-Key: http://anders.fix.no/pgp/ X-PGP-Key-FingerPrint: 1E0F C53C D8DF 6A8F EAAD 19C5 D12A BC9F 0083 5956 User-Agent: Mutt/1.5.11 Cc: Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 12:27:12 -0000 Hi, Done. On system with bge and 100 mbps link speed, I get: IF-MIB::ifName.1 = STRING: bge0 IF-MIB::ifName.2 = STRING: bge1 IF-MIB::ifName.3 = STRING: lo0 IF-MIB::ifHighSpeed.1 = Gauge32: 100 IF-MIB::ifHighSpeed.2 = Gauge32: 0 IF-MIB::ifHighSpeed.3 = Gauge32: 0 On system with bge and gigabit link speed, I get: IF-MIB::ifName.1 = STRING: bge0 IF-MIB::ifName.2 = STRING: bge1 IF-MIB::ifName.3 = STRING: lo0 IF-MIB::ifHighSpeed.1 = Gauge32: 1000 IF-MIB::ifHighSpeed.2 = Gauge32: 0 IF-MIB::ifHighSpeed.3 = Gauge32: 0 The second NIC, bge1, is not configured. Seems fine to me. I still get ifHCInOctets/ifHCOutOctets for both systems mentioned. On Tue, Feb 14, 2006 at 02:02:17PM +0300, Gleb Smirnoff wrote: > Oleg, Anders, > > can you please remove all your changes to if_bge.c and test the > attached patch. Awaiting for feedback and thanks. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > Index: net/if_media.c > =================================================================== > RCS file: /home/ncvs/src/sys/net/if_media.c,v > retrieving revision 1.22 > diff -u -r1.22 if_media.c > --- net/if_media.c 25 Dec 2005 23:28:23 -0000 1.22 > +++ net/if_media.c 14 Feb 2006 09:51:09 -0000 > @@ -385,6 +385,28 @@ > return match; > } > > +/* > + * Compute the interface `baudrate' from the media, for the interface > + * metrics (used by routing daemons). > + */ > +static const struct ifmedia_baudrate ifmedia_baudrate_descriptions[] = > + IFM_BAUDRATE_DESCRIPTIONS; > + > +uint64_t > +ifmedia_baudrate(int mword) > +{ > + int i; > + > + for (i = 0; ifmedia_baudrate_descriptions[i].ifmb_word != 0; i++) { > + if ((mword & (IFM_NMASK|IFM_TMASK)) == > + ifmedia_baudrate_descriptions[i].ifmb_word) > + return (ifmedia_baudrate_descriptions[i].ifmb_baudrate); > + } > + > + /* Not known. */ > + return (0); > +} > + > #ifdef IFMEDIA_DEBUG > struct ifmedia_description ifm_type_descriptions[] = > IFM_TYPE_DESCRIPTIONS; > Index: net/if_media.h > =================================================================== > RCS file: /home/ncvs/src/sys/net/if_media.h,v > retrieving revision 1.30 > diff -u -r1.30 if_media.h > --- net/if_media.h 22 Feb 2005 13:04:03 -0000 1.30 > +++ net/if_media.h 14 Feb 2006 10:29:59 -0000 > @@ -104,6 +104,9 @@ > int ifmedia_ioctl(struct ifnet *ifp, struct ifreq *ifr, > struct ifmedia *ifm, u_long cmd); > > +/* Compute baudrate for a given media. */ > +uint64_t ifmedia_baudrate(int); > + > #endif /*_KERNEL */ > > /* > @@ -138,8 +141,8 @@ > #define IFM_1000_CX 15 /* 1000baseCX - 150ohm STP */ > #define IFM_1000_T 16 /* 1000baseT - 4 pair cat 5 */ > #define IFM_HPNA_1 17 /* HomePNA 1.0 (1Mb/s) */ > -#define IFM_10GBASE_SR 18 /* 10GBASE-SR 850nm Multi-mode Fiber */ > -#define IFM_10GBASE_LR 19 /* 10GBASE-LR 1310nm Single-mode Fiber */ > +#define IFM_10G_LR 18 /* 10GBase-LR 1310nm Single-mode */ > +#define IFM_10G_SR 19 /* 10GBase-SR 850nm Multi-mode */ > > /* note 31 is the max! */ > > @@ -543,4 +546,59 @@ > { 0, NULL }, \ > } > > +/* > + * Baudrate descriptions for the various media types. > + */ > +struct ifmedia_baudrate { > + int ifmb_word; /* media word */ > + uint64_t ifmb_baudrate; /* corresponding baudrate */ > +}; > + > +#define IFM_BAUDRATE_DESCRIPTIONS { \ > + { IFM_ETHER | IFM_10_T, IF_Mbps(10) }, \ > + { IFM_ETHER | IFM_10_2, IF_Mbps(10) }, \ > + { IFM_ETHER | IFM_10_5, IF_Mbps(10) }, \ > + { IFM_ETHER | IFM_100_TX, IF_Mbps(100) }, \ > + { IFM_ETHER | IFM_100_FX, IF_Mbps(100) }, \ > + { IFM_ETHER | IFM_100_T4, IF_Mbps(100) }, \ > + { IFM_ETHER | IFM_100_VG, IF_Mbps(100) }, \ > + { IFM_ETHER | IFM_100_T2, IF_Mbps(100) }, \ > + { IFM_ETHER | IFM_1000_SX, IF_Mbps(1000) }, \ > + { IFM_ETHER | IFM_10_STP, IF_Mbps(10) }, \ > + { IFM_ETHER | IFM_10_FL, IF_Mbps(10) }, \ > + { IFM_ETHER | IFM_1000_LX, IF_Mbps(1000) }, \ > + { IFM_ETHER | IFM_1000_CX, IF_Mbps(1000) }, \ > + { IFM_ETHER | IFM_1000_T, IF_Mbps(1000) }, \ > + { IFM_ETHER | IFM_HPNA_1, IF_Mbps(1) }, \ > + { IFM_ETHER | IFM_10G_LR, IF_Gbps(10ULL) }, \ > + \ > + { IFM_TOKEN | IFM_TOK_STP4, IF_Mbps(4) }, \ > + { IFM_TOKEN | IFM_TOK_STP16, IF_Mbps(16) }, \ > + { IFM_TOKEN | IFM_TOK_UTP4, IF_Mbps(4) }, \ > + { IFM_TOKEN | IFM_TOK_UTP16, IF_Mbps(16) }, \ > + \ > + { IFM_FDDI | IFM_FDDI_SMF, IF_Mbps(100) }, \ > + { IFM_FDDI | IFM_FDDI_MMF, IF_Mbps(100) }, \ > + { IFM_FDDI | IFM_FDDI_UTP, IF_Mbps(100) }, \ > + \ > + { IFM_IEEE80211 | IFM_IEEE80211_FH1, IF_Mbps(1) }, \ > + { IFM_IEEE80211 | IFM_IEEE80211_FH2, IF_Mbps(2) }, \ > + { IFM_IEEE80211 | IFM_IEEE80211_DS2, IF_Mbps(2) }, \ > + { IFM_IEEE80211 | IFM_IEEE80211_DS5, IF_Kbps(5500) }, \ > + { IFM_IEEE80211 | IFM_IEEE80211_DS11, IF_Mbps(11) }, \ > + { IFM_IEEE80211 | IFM_IEEE80211_DS1, IF_Mbps(1) }, \ > + { IFM_IEEE80211 | IFM_IEEE80211_DS22, IF_Mbps(22) }, \ > + { IFM_IEEE80211 | IFM_IEEE80211_OFDM6, IF_Mbps(6) }, \ > + { IFM_IEEE80211 | IFM_IEEE80211_OFDM9, IF_Mbps(9) }, \ > + { IFM_IEEE80211 | IFM_IEEE80211_OFDM12, IF_Mbps(12) }, \ > + { IFM_IEEE80211 | IFM_IEEE80211_OFDM18, IF_Mbps(18) }, \ > + { IFM_IEEE80211 | IFM_IEEE80211_OFDM24, IF_Mbps(24) }, \ > + { IFM_IEEE80211 | IFM_IEEE80211_OFDM36, IF_Mbps(36) }, \ > + { IFM_IEEE80211 | IFM_IEEE80211_OFDM48, IF_Mbps(48) }, \ > + { IFM_IEEE80211 | IFM_IEEE80211_OFDM54, IF_Mbps(54) }, \ > + { IFM_IEEE80211 | IFM_IEEE80211_OFDM72, IF_Mbps(72) }, \ > + \ > + { 0, 0 }, \ > +} > + > #endif /* _NET_IF_MEDIA_H_ */ > Index: dev/mii/mii.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/mii/mii.c,v > retrieving revision 1.26 > diff -u -r1.26 mii.c > --- dev/mii/mii.c 11 Jun 2005 00:20:38 -0000 1.26 > +++ dev/mii/mii.c 14 Feb 2006 10:24:21 -0000 > @@ -240,9 +240,20 @@ > miibus_statchg(device_t dev) > { > device_t parent; > + struct mii_data *mii; > + struct ifnet *ifp; > > parent = device_get_parent(dev); > MIIBUS_STATCHG(parent); > + > + mii = device_get_softc(dev); > + > + /* > + * Note that each NIC's softc must start with an ifnet pointer. > + * XXX: EVIL HACK! > + */ > + ifp = *(struct ifnet **)device_get_softc(parent); > + ifp->if_baudrate = ifmedia_baudrate(mii->mii_media_active); > return; > } > > _______________________________________________ > 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" -- Anders. From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 14:57:03 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C318116A422; Tue, 14 Feb 2006 14:57:03 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3057F43D5F; Tue, 14 Feb 2006 14:56:56 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 15:56:54 +0100 Date: Tue, 14 Feb 2006 15:56:55 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Anders Nordby In-Reply-To: <20060214105821.GA47035@totem.fix.no> Message-ID: <20060214154833.I5083@beagle.kn.op.dlr.de> References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> <20060213173008.GA14643@totem.fix.no> <20060214090531.X5083@beagle.kn.op.dlr.de> <20060214083010.GB41864@totem.fix.no> <20060214093513.F5083@beagle.kn.op.dlr.de> <20060214084459.GL86448@cell.sick.ru> <20060214103723.GA45138@totem.fix.no> <20060214103901.GB68308@cell.sick.ru> <20060214105821.GA47035@totem.fix.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 14 Feb 2006 14:56:54.0614 (UTC) FILETIME=[E518AF60:01C63176] Cc: freebsd-net@FreeBSD.org, Gleb Smirnoff , kuriyama@FreeBSD.org, demon@FreeBSD.org Subject: Re: bsnmpd (was: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 14:57:03 -0000 On Tue, 14 Feb 2006, Anders Nordby wrote: AN>On Tue, Feb 14, 2006 at 01:39:01PM +0300, Gleb Smirnoff wrote: AN>> A> I should make a list of "what bsnmpd needs" to be more usable, in case AN>> A> Harti is interested. ;-P AN>> Where is such list? AN> AN>Some things popping off my mind: AN> AN>- Ability to run as a different user. I suppose we should add a snmp AN>user to the base system. Running as root is not OK, when it is not AN>necessary (net-snmp snmpd can run as a different user, it has a related AN>-r option to not exit if it has privilege problems). AN> AN>- Ability to chroot itself (yes please, for security). I don't have enough rc-foo for this. Perhaps someone can jump in here? AN>- Ability to execute programs and return values on given OIDs, and also AN>cache their results so that the programs doesn't have to be run for AN>every time. It's necessary to cache values to avoid running resource AN>intensive scripts/programs more than necessary. Sounds interesting and is certainly doable. AN>I am using net-snmp snmpd mostly currently, but consider switching as I AN>now can get my 64-bit counters from bsnmpd. It seems net-snmp snmpd can AN>not give ifHCInOctets/ifHCOutOctets (Counter64) in FreeBSD yet. At least AN>the exec issue above must be resolved for me to switch to bsnmpd. AN> AN>Oh, and a couple of questions. If I only want read access enabled, is AN>commenting "write :=" and "trap :=" out all that is necessary? If not, AN>how do I do it? Normally, I only want to read from my SNMP agents. I AN>would prefer to have trap/write disabled completely. Two or three weeks ago I committed a patch that sets the default communities to NULL and comments out the corresponding lines in the config file. In this configuration the daemon ignores all incoming messages. If you then just set the read community, it gets read-only. You definitely need rev 1.1.1.11 or later of snmpd/main.c. The trap community is only for outgoing traps. AN>Another thing. The trap support in bsnmpd, it's only for forwarding AN>traps? Does bsnmpd have, or will it ever get an ability to generate AN>traps upon failures in FreeBSD? No, trap support is only for sending traps. There is a begemotTrapSinkTable where you configure all trap destinations. The distributed config file populates just one row of it. Each trap is then send to all destinations. Currently the only traps that are ever sent are: - authentication traps (if enabled) sent by the daemon itself - linkUp and linkDown traps from snmp_mibII harti From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 15:54:39 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0EB916A449 for ; Tue, 14 Feb 2006 15:54:38 +0000 (GMT) (envelope-from bedinelli@madhaus.cns.utoronto.ca) Received: from madhaus.cns.utoronto.ca (madhaus.cns.utoronto.ca [128.100.103.10]) by mx1.FreeBSD.org (Postfix) with SMTP id 2E15243D4C for ; Tue, 14 Feb 2006 15:54:37 +0000 (GMT) (envelope-from bedinelli@madhaus.cns.utoronto.ca) Received: (qmail 11634 invoked by uid 31014); 14 Feb 2006 15:54:36 -0000 Received: from [128.100.103.148] (HELO [128.100.103.148]) (128.100.103.148) by madhaus.cns.utoronto.ca (qpsmtpd/0.30) with ESMTP; Tue, 14 Feb 2006 10:54:36 -0500 In-Reply-To: <20060214074606.GH86448@FreeBSD.org> References: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> <20060214074606.GH86448@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <858977c4a80306329f68021200154126@madhaus.cns.utoronto.ca> Content-Transfer-Encoding: 7bit From: Marcos Bedinelli Date: Tue, 14 Feb 2006 10:54:34 -0500 To: Gleb Smirnoff X-Mailer: Apple Mail (2.623) Cc: freebsd-net@FreeBSD.org, andre@FreeBSD.org Subject: Re: Network performance in a dual CPU system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 15:54:40 -0000 Gleb, thanks again for looking into this and for your suggestions. Unfortunately Alpha/Beta/release candidate/pre-release/test versions of software is a "no go" on that machine. Our short term solution will be to upgrade the CPU to a faster model. After that, I will be able to assemble a dual processor system from spare parts and also play with fastforwarding. I will be glad to post the results of my tests to the mailing list, but it may take awhile. Cheers! On 14-Feb-06, at 9:52, Gleb Smirnoff wrote: > On Tue, Feb 14, 2006 at 09:27:46AM -0500, Marcos Bedinelli wrote: > M> >M> I tried the 'sysctl net.inet.ip.fastforwarding=1' yesterday > morning > M> >M> and, as soon as I entered the command, the machine stopped > M> >forwarding > M> >M> packets. Unfortunately I was unable to spend time > troubleshooting > M> >the > M> >M> problem because the machine is in production and can't be down > for > M> >not > M> >M> even a couple of minutes. > M> > > M> >This is strange. Can you please show output of 'ifconfig'? Are you > M> >using > M> >any packet filters or other additional processing of forwarded > packets? > M> >Did the router generated any ICMP errors or just silently dropped > M> >packets? > M> > M> > M> The machine is running Quagga (OSPF and BGP). OSPF runs on bge0. BGP > M> runs on bge1. It also runs IPFW and basic SNMP. > M> > M> I suspect the problem I experienced yesterday is related to the IPFW > M> ruleset. Although it's mainly used for blocking, there are two rules > M> that forward packets to another machine: > M> > M> [...] > M> 07700 fwd a.b.c.d ip from w.x.y.z/16 to any in recv bge0 > M> [...] > M> 15300 fwd a.b.c.d ip from any to any out xmit disc0 > M> > M> > M> Rule 7700 is doing policy-based routing: if the source IP belongs to > M> network w.x.y.z/16, the packet is forwarded to host a.b.c.d > M> > M> I am suspicious about rule 15300. Virtual interface disc0 is our > M> default route. In other words, the routing table is updated by both > M> OSPF and BGP. Packets that don't match a specific entry on the > routing > M> table are sent to disc0. Rule 15300 will catch those packets and > send > M> them to host a.b.c.d as well. > > I understood the problem. The fastforwarding code refuses to forward > packet if it is routed to interface w/o IFF_DRV_RUNNING flag. The disc0 > interface in 6.0-RELEASE doesn't have IFF_DRV_RUNNING flag. > > That's why I added this flag to disc(4) in 6.0-STABLE, to satisfy fast > forwarding: > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if_disc.c.diff? > r1=1.48&r2=1.48.2.1 > > Actually, it is incorrect that upper netowork layer looks into > if_drv_flags. > > You can either apply the above patch, or upgrade your system to > 6.1-BETA. As I > said before bge(4) driver has undergone some improvements, and I'll > appreciate > if you try to upgrade and provide any feedback. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE -- Marcos From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 16:07:26 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A555616A420; Tue, 14 Feb 2006 16:07:26 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F51E43D5E; Tue, 14 Feb 2006 16:07:20 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id k1EG7I2e077038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2006 19:07:19 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id k1EG7Isu077037; Tue, 14 Feb 2006 19:07:18 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 14 Feb 2006 19:07:18 +0300 From: Gleb Smirnoff To: Marcos Bedinelli Message-ID: <20060214160718.GQ68308@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Marcos Bedinelli , andre@FreeBSD.org, freebsd-net@FreeBSD.org References: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> <20060214074606.GH86448@FreeBSD.org> <858977c4a80306329f68021200154126@madhaus.cns.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <858977c4a80306329f68021200154126@madhaus.cns.utoronto.ca> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org, andre@FreeBSD.org Subject: Re: Network performance in a dual CPU system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 16:07:26 -0000 On Tue, Feb 14, 2006 at 10:54:34AM -0500, Marcos Bedinelli wrote: M> Gleb, M> M> thanks again for looking into this and for your suggestions. M> M> Unfortunately Alpha/Beta/release candidate/pre-release/test versions of M> software is a "no go" on that machine. Our short term solution will be M> to upgrade the CPU to a faster model. After that, I will be able to M> assemble a dual processor system from spare parts and also play with M> fastforwarding. M> M> I will be glad to post the results of my tests to the mailing list, but M> it may take awhile. Adding a one line patch is "no go", too? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 16:44:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D772E16A420 for ; Tue, 14 Feb 2006 16:44:48 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp109.rog.mail.re2.yahoo.com (smtp109.rog.mail.re2.yahoo.com [68.142.225.207]) by mx1.FreeBSD.org (Postfix) with SMTP id 490BB43D48 for ; Tue, 14 Feb 2006 16:44:48 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 48187 invoked from network); 14 Feb 2006 16:44:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Iz1ZIq5ssjzd2t2MZ+yBsLjr+5rHmFu+weRoCu5U03ZMcCDjlh4cAaWCXSV64N8S5lnZnGf1EIZSCkMhpuLszRouBEnnkAzRnVyANaR51CELsPDMssdI2Qp9P8RERZ4AfBAnq53b8B0mBM4Qpi00IEmOatAyyw/75DUui+syjeo= ; Received: from unknown (HELO ?70.30.133.184?) (mikej@rogers.com@70.30.133.184 with plain) by smtp109.rog.mail.re2.yahoo.com with SMTP; 14 Feb 2006 16:44:47 -0000 Message-ID: <43F20917.80102@rogers.com> Date: Tue, 14 Feb 2006 11:45:11 -0500 From: Mike Jakubik User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Murugan References: <7571f1f60602140149y5e13c8e5j9f7dc3b9c8b5e807@mail.gmail.com> In-Reply-To: <7571f1f60602140149y5e13c8e5j9f7dc3b9c8b5e807@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Help - PPPoE Server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 16:44:49 -0000 Murugan wrote: > Hi > i need a sample(working) configuration files to set up a PPPoE server > in FreeBSD 4.9. > www.google.com From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 17:49:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25CBE16A422 for ; Tue, 14 Feb 2006 17:49:46 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.net (mail.yazzy.net [217.8.140.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id B955C43D46 for ; Tue, 14 Feb 2006 17:49:45 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from lapdance.yazzy.net (unknown [192.168.99.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yazzy.net (Postfix) with ESMTP id 8C73B3982E; Tue, 14 Feb 2006 18:50:51 +0100 (CET) Date: Tue, 14 Feb 2006 17:48:39 +0000 From: Marcin Jessa To: Murugan Message-Id: <20060214174839.27c121f9.lists@yazzy.org> In-Reply-To: <7571f1f60602140149y5e13c8e5j9f7dc3b9c8b5e807@mail.gmail.com> References: <7571f1f60602140149y5e13c8e5j9f7dc3b9c8b5e807@mail.gmail.com> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Help - PPPoE Server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 17:49:46 -0000 On Tue, 14 Feb 2006 15:19:49 +0530 Murugan wrote: > Hi > i need a sample(working) configuration files to set up a PPPoE server > in FreeBSD 4.9. http://www.hpi.net/whitepapers/warta/ From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 21:15:50 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69A0016A420 for ; Tue, 14 Feb 2006 21:15:50 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id BDF8943D55 for ; Tue, 14 Feb 2006 21:15:47 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 32712 invoked by uid 399); 14 Feb 2006 21:15:46 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 14 Feb 2006 21:15:46 -0000 Message-ID: <43F24880.3040208@FreeBSD.org> Date: Tue, 14 Feb 2006 13:15:44 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: Harti Brandt References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> <20060213173008.GA14643@totem.fix.no> <20060214090531.X5083@beagle.kn.op.dlr.de> <20060214083010.GB41864@totem.fix.no> <20060214093513.F5083@beagle.kn.op.dlr.de> <20060214084459.GL86448@cell.sick.ru> <20060214103723.GA45138@totem.fix.no> <20060214103901.GB68308@cell.sick.ru> <20060214105821.GA47035@totem.fix.no> <20060214154833.I5083@beagle.kn.op.dlr.de> In-Reply-To: <20060214154833.I5083@beagle.kn.op.dlr.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, Anders Nordby , Gleb Smirnoff , kuriyama@FreeBSD.org, demon@FreeBSD.org Subject: Re: bsnmpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 21:15:50 -0000 Harti Brandt wrote: > On Tue, 14 Feb 2006, Anders Nordby wrote: > AN>- Ability to chroot itself (yes please, for security). > > I don't have enough rc-foo for this. Perhaps someone can jump in here? This actually isn't all that hard. Basically you set $name_chroot to the directory it should chroot too. It's also a good idea to include that directory in required_dirs. If the bsnmpd binary has it's own chroot command line option, take a look at how rc.d/named does it in HEAD. Otherwise, there are notes in /etc/rc.subr and, the freebsd-rc@ list stands ready to help. :) Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 21:41:36 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88F3E16A420 for ; Tue, 14 Feb 2006 21:41:36 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from lara.cc.fer.hr (lara.cc.fer.hr [161.53.72.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id C67AF43D6B for ; Tue, 14 Feb 2006 21:41:35 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [127.0.0.1] (localhost.cc.fer.hr [127.0.0.1]) by lara.cc.fer.hr (8.13.4/8.13.4) with ESMTP id k1ELfIea018786; Tue, 14 Feb 2006 22:41:19 +0100 (CET) (envelope-from ivoras@fer.hr) Message-ID: <43F24E7E.4060503@fer.hr> Date: Tue, 14 Feb 2006 22:41:18 +0100 From: Ivan Voras User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ragnar Lonn References: <43F0CE40.5040800@fer.hr> <43F1A2D1.7040402@packetfront.com> In-Reply-To: <43F1A2D1.7040402@packetfront.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: TCP Performance advice needed [long!] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 21:41:36 -0000 Ragnar Lonn wrote: > I don't know what tcp.inflight does but I know that this type of > application > protocol, that expects a reply before sending the next piece of data, will > always be completely dependent upon roundtrip times for its throughput - > the roundtrip time for the exchange "transmit-reply" will limit the > possible throughput you can get so if you want higher performance, either I understand this bottleneck, and know (at least in theory :) ) how it could be solved, but my problems are not directly related to that: - For small (but consistent in size) packet sizes, I get randomly varying round-trip times, and much lower packets-per-second ratio then with big packets (consistent in size) with the exact same lock-step protocol. Packet generation and processing are not CPU intensive. - When using big packets (actually, when switching back and forth from small packets to big packets), the PPS performance starts low and climbs to "normal" levels, and I'd like to avoid this. This is a local network with 0 errors. (if you like it, replace the word "packets" with "messages" in the above explanation :) ) I think the above problems are not directly related to the protocol (which could be better, I agree, but it won't happen at least until I understand what is happening with this version) but on fine-tuning of the network or socket options. From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 21:52:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EDA216A420; Tue, 14 Feb 2006 21:52:34 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E0DC43D48; Tue, 14 Feb 2006 21:52:34 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k1ELqXE6023836; Tue, 14 Feb 2006 13:52:33 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k1ELqX2D023835; Tue, 14 Feb 2006 13:52:33 -0800 Date: Tue, 14 Feb 2006 13:52:33 -0800 From: Brooks Davis To: Doug Barton Message-ID: <20060214215233.GA23444@odin.ac.hmc.edu> References: <20060213173008.GA14643@totem.fix.no> <20060214090531.X5083@beagle.kn.op.dlr.de> <20060214083010.GB41864@totem.fix.no> <20060214093513.F5083@beagle.kn.op.dlr.de> <20060214084459.GL86448@cell.sick.ru> <20060214103723.GA45138@totem.fix.no> <20060214103901.GB68308@cell.sick.ru> <20060214105821.GA47035@totem.fix.no> <20060214154833.I5083@beagle.kn.op.dlr.de> <43F24880.3040208@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <43F24880.3040208@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Anders Nordby , Harti Brandt , kuriyama@freebsd.org, freebsd-net@freebsd.org, demon@freebsd.org Subject: Re: bsnmpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 21:52:34 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 14, 2006 at 01:15:44PM -0800, Doug Barton wrote: > Harti Brandt wrote: > > On Tue, 14 Feb 2006, Anders Nordby wrote: >=20 > > AN>- Ability to chroot itself (yes please, for security). > >=20 > > I don't have enough rc-foo for this. Perhaps someone can jump in here? >=20 > This actually isn't all that hard. Basically you set $name_chroot to the > directory it should chroot too. It's also a good idea to include that > directory in required_dirs. If the bsnmpd binary has it's own chroot comm= and > line option, take a look at how rc.d/named does it in HEAD. Otherwise, th= ere > are notes in /etc/rc.subr and, the freebsd-rc@ list stands ready to help.= :) and don't follow the example in /etc/rc.d/ntpd since it can't work with modern versions of devfs. -- 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 --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFD8lEgXY6L6fI4GtQRAs1aAJ9MeEWWAogEjbU/QC+wjjhwNziWJgCeMosP Y2b4pvQYJTkEDRzUL+hyboo= =heZp -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 15 06:19:45 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 319C116A422 for ; Wed, 15 Feb 2006 06:19:45 +0000 (GMT) (envelope-from opolyakov@yahoo.com) Received: from web35302.mail.mud.yahoo.com (web35302.mail.mud.yahoo.com [66.163.179.96]) by mx1.FreeBSD.org (Postfix) with SMTP id 1F6A643D48 for ; Wed, 15 Feb 2006 06:19:43 +0000 (GMT) (envelope-from opolyakov@yahoo.com) Received: (qmail 50786 invoked by uid 60001); 15 Feb 2006 06:19:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HJ+oJPQfFoVLsLHYdWSb4bSjSgmYiDsgrrz7VyC96AePk/kTEvS1/UvNXbpCTQKChW9RDptjlR6m8T5nhXepAkiE0+isOLWXF3cWyc3SfbQhukqCh/73ap5o/PSLtVHZl745BVZeQ1fqqDJhum/gTlboNGX/WHgddu6MlDYcy6c= ; Message-ID: <20060215061942.50784.qmail@web35302.mail.mud.yahoo.com> Received: from [69.228.89.153] by web35302.mail.mud.yahoo.com via HTTP; Tue, 14 Feb 2006 22:19:42 PST Date: Tue, 14 Feb 2006 22:19:42 -0800 (PST) From: Oleg Polyakov To: Gleb Smirnoff In-Reply-To: <20060214110217.GD68308@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org, Anders Nordby , Harti Brandt , kuriyama@FreeBSD.org, demon@FreeBSD.org Subject: Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2006 06:19:45 -0000 --- Gleb Smirnoff wrote: > Oleg, Anders, > > can you please remove all your changes to if_bge.c and test the > attached patch. Awaiting for feedback and thanks. It works fine - bge0 connected to GIGE switch, bge1 is not connected # snmpget -c pub -v 1 localhost ifSpeed.1 IF-MIB::ifSpeed.1 = Gauge32: 1000000000 # snmpget -c pub -v 1 localhost ifHighSpeed.1 IF-MIB::ifHighSpeed.1 = Gauge32: 1000 # ifconfig bge1 up # ifconfig bge1 media auto # snmpget -c pub -v 1 localhost ifSpeed.2 IF-MIB::ifSpeed.2 = Gauge32: 0 # snmpget -c pub -v 1 localhost ifHighSpeed.2 IF-MIB::ifHighSpeed.2 = Gauge32: 0 # ifconfig bge1 media 10baseT/UTP # snmpget -c pub -v 1 localhost ifSpeed.2 IF-MIB::ifSpeed.2 = Gauge32: 10000000 # snmpget -c pub -v 1 localhost ifHighSpeed.2 IF-MIB::ifHighSpeed.2 = Gauge32: 10 # ifconfig bge1 media 100baseTX # snmpget -c pub -v 1 localhost ifSpeed.2 IF-MIB::ifSpeed.2 = Gauge32: 100000000 # snmpget -c pub -v 1 localhost ifHighSpeed.2 IF-MIB::ifHighSpeed.2 = Gauge32: 100 It might be not important, but if adapter is in DOWN state snmp may show different media: 1. Adapter is Down. ifconfig shows - media: Ethernet autoselect (none) Snmp shows ifSpeed 0. 2. # ifconfig bge1 media 100baseTX. ifconfig shows - media: Ethernet 100baseTX (none) Snmp still shows ifSpeed 0. 3. # ifconfig bge1 up ifconfig shows - media: Ethernet 100baseTX (none) snmp shows ifSpeed 100000000 4. # ifconfig bge1 down snmp still shows ifSpeed 100000000 after running "ifconfig bge1" snmp shows ifSpeed 0 So sometimes ifconfig helps to change baudrate if adapter in DOWN state. Thanks, Oleg > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Wed Feb 15 09:12:42 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65F1616A420 for ; Wed, 15 Feb 2006 09:12:42 +0000 (GMT) (envelope-from raglon@packetfront.com) Received: from mail.packetfront.com (mail.packetfront.com [212.247.6.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7C5D43D45 for ; Wed, 15 Feb 2006 09:12:41 +0000 (GMT) (envelope-from raglon@packetfront.com) Received: from localhost (localhost [127.0.0.1]) by mail.packetfront.com (Postfix) with ESMTP id 52B2EA3436; Wed, 15 Feb 2006 10:12:42 +0100 (CET) Received: from mail.packetfront.com ([127.0.0.1]) by localhost (mail.packetfront.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00961-03; Wed, 15 Feb 2006 10:12:42 +0100 (CET) Received: from [192.168.1.137] (unknown [192.168.1.137]) by mail.packetfront.com (Postfix) with ESMTP id 0DEC1A3425; Wed, 15 Feb 2006 10:12:42 +0100 (CET) Message-ID: <43F2F03D.90603@packetfront.com> Date: Wed, 15 Feb 2006 10:11:25 +0100 From: Ragnar Lonn User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan Voras References: <43F0CE40.5040800@fer.hr> <43F1A2D1.7040402@packetfront.com> <43F24E7E.4060503@fer.hr> In-Reply-To: <43F24E7E.4060503@fer.hr> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at packetfront.com Cc: net@freebsd.org Subject: Re: TCP Performance advice needed [long!] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2006 09:12:42 -0000 Ivan Voras wrote: > I understand this bottleneck, and know (at least in theory :) ) how it > could be solved, but my problems are not directly related to that: > > - For small (but consistent in size) packet sizes, I get randomly > varying round-trip times, and much lower packets-per-second ratio then > with big packets (consistent in size) with the exact same lock-step > protocol. Packet generation and processing are not CPU intensive. > > - When using big packets (actually, when switching back and forth from > small packets to big packets), the PPS performance starts low and > climbs to "normal" levels, and I'd like to avoid this. This is a local > network with 0 errors. My guess would be that it's an effect of how TCP works. The slow start, for instance (but I saw you had tried setting TCP_NODELAY). Maybe you should experiement with UDP as the transport protocol instead. Of course, it requires more work if you need reliable and in-order delivery. But if you want low roundtrip times, use UDP. There isn't an online action game today that uses TCP, because it's not suited for applications which need fast response times. Cheers, /Ragnar From owner-freebsd-net@FreeBSD.ORG Wed Feb 15 09:15:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA95A16A420 for ; Wed, 15 Feb 2006 09:15:10 +0000 (GMT) (envelope-from girgen@pingpong.net) Received: from rambutan.pingpong.net (81.milagro.bahnhof.net [195.178.168.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3280F43D49 for ; Wed, 15 Feb 2006 09:15:05 +0000 (GMT) (envelope-from girgen@pingpong.net) Received: from localhost (localhost [127.0.0.1]) by rambutan.pingpong.net (8.13.4/8.13.4) with ESMTP id k1F9F3Hb001120 for ; Wed, 15 Feb 2006 10:15:03 +0100 (CET) (envelope-from girgen@pingpong.net) Date: Wed, 15 Feb 2006 10:15:03 +0100 From: Palle Girgensohn To: freebsd-net@freebsd.org Message-ID: X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: NFS file locking problem, rpc.lockd seems to be leaking ports? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2006 09:15:10 -0000 Hi! I'm having a problem with rpc.lockd Clients are mainly FreeBSD 5.4-stable, server is FreeBSD-4.11-RELEASE-p13. /home is nfs mounted via amd. rpc.statd and rpc.lockd is on for both clients and server Since we started using eclipse (which requires file locking to operate) we get problems where the number of open priviledged UDP ports on the server are exhausted. running sockstat | grep rpc.lock show over 400 lines like this: root rpc.lock 174 440 udp4 *:580 *:* The default setting for FreeBSD-4.11 seems to be a portrange of 400 ports, I've bumped this by lowering net.inet.ip.portrange.lowlast from 600 -> 500, but eventually they will all be in use too. I have not found good way to free them properly apart from rebooting the server. All nfs traffic is UDP only, perhaps that is a problem? nfsiod -n 4 on all clients nfs_server_flags="-u -n 12" on the server, perhaps it is too low? There are only six workstations attached to the server. Each have about ten rpc.lockd sockets open, while the server has about 400, so it seems to be a leakage in the server? I have lived with this, planning an upgrade of the server to freebsd-6, hoping it will fix it, but now I've upgraded one of the workstations to freebsd-6, and nfs file locking does not work at all for this client. I have to turn if off completely to even get firefox, or a a buildworld with src nfs-mounted (local objdir), to work, and it is not a problem of "out of ports" on the server, there are enough left. It seems nfs locking with -6 client and -4.11 server is broken? Will an upgrade of the server help? Has anyone else seen this problem? Regards, Palle From owner-freebsd-net@FreeBSD.ORG Wed Feb 15 09:33:06 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F2DE16A420; Wed, 15 Feb 2006 09:33:06 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40E3A43D46; Wed, 15 Feb 2006 09:33:05 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id k1F9X2cp093499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2006 12:33:03 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id k1F9X2JA093498; Wed, 15 Feb 2006 12:33:02 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 15 Feb 2006 12:33:02 +0300 From: Gleb Smirnoff To: Anders Nordby Message-ID: <20060215093302.GV68308@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Anders Nordby , Harti Brandt , freebsd-net@FreeBSD.org, kuriyama@FreeBSD.org, demon@FreeBSD.org References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> <20060213173008.GA14643@totem.fix.no> <20060214090531.X5083@beagle.kn.op.dlr.de> <20060214083010.GB41864@totem.fix.no> <20060214093513.F5083@beagle.kn.op.dlr.de> <20060214084459.GL86448@cell.sick.ru> <20060214103723.GA45138@totem.fix.no> <20060214103901.GB68308@cell.sick.ru> <20060214105821.GA47035@totem.fix.no> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060214105821.GA47035@totem.fix.no> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org, Harti Brandt , kuriyama@FreeBSD.org, demon@FreeBSD.org Subject: Re: bsnmpd (was: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2006 09:33:06 -0000 On Tue, Feb 14, 2006 at 11:58:21AM +0100, Anders Nordby wrote: A> Some things popping off my mind: - A SMUX interface, allowing a process to provide a MIB branch available via bsnmpd. May be in future I will have time to make a SNMP branch in mpd, that will allow to manage a PPP access concetrator via SNMP. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Feb 15 09:58:26 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7B1E16A42D; Wed, 15 Feb 2006 09:58:26 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1658E43D46; Wed, 15 Feb 2006 09:58:25 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 10:58:23 +0100 Date: Wed, 15 Feb 2006 10:58:25 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Gleb Smirnoff In-Reply-To: <20060215093302.GV68308@cell.sick.ru> Message-ID: <20060215104923.J5083@beagle.kn.op.dlr.de> References: <20060206092443.GA61116@totem.fix.no> <20060207141131.GU877@FreeBSD.org> <20060213173008.GA14643@totem.fix.no> <20060214090531.X5083@beagle.kn.op.dlr.de> <20060214083010.GB41864@totem.fix.no> <20060214093513.F5083@beagle.kn.op.dlr.de> <20060214084459.GL86448@cell.sick.ru> <20060214103723.GA45138@totem.fix.no> <20060214103901.GB68308@cell.sick.ru> <20060214105821.GA47035@totem.fix.no> <20060215093302.GV68308@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 15 Feb 2006 09:58:23.0857 (UTC) FILETIME=[5BDDCE10:01C63216] Cc: freebsd-net@FreeBSD.org, Anders Nordby , kuriyama@FreeBSD.org, demon@FreeBSD.org Subject: Re: bsnmpd (was: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2006 09:58:26 -0000 On Wed, 15 Feb 2006, Gleb Smirnoff wrote: GS>On Tue, Feb 14, 2006 at 11:58:21AM +0100, Anders Nordby wrote: GS>A> Some things popping off my mind: GS> GS>- A SMUX interface, allowing a process to provide a MIB branch GS> available via bsnmpd. May be in future I will have time to GS> make a SNMP branch in mpd, that will allow to manage a PPP GS> access concetrator via SNMP. Actually an agentx interface would be nice, but that's non-trivial, to put it mild. Currently I use shared memory in all projects where the daemon needs to communicate with other programs. SMUX might be a starting point though. I'll put it on the list as soon as I get my login-name/password recovered for the WiKi :-) harti From owner-freebsd-net@FreeBSD.ORG Wed Feb 15 16:42:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A7C516A420 for ; Wed, 15 Feb 2006 16:42:17 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDB8143D55 for ; Wed, 15 Feb 2006 16:42:16 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id C02811A3C20; Wed, 15 Feb 2006 08:42:16 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 210AD51432; Wed, 15 Feb 2006 11:42:16 -0500 (EST) Date: Wed, 15 Feb 2006 11:42:16 -0500 From: Kris Kennaway To: Palle Girgensohn Message-ID: <20060215164215.GA49908@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: NFS file locking problem, rpc.lockd seems to be leaking ports? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2006 16:42:17 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 15, 2006 at 10:15:03AM +0100, Palle Girgensohn wrote: > I have lived with this, planning an upgrade of the server to freebsd-6,= =20 > hoping it will fix it, but now I've upgraded one of the workstations to= =20 > freebsd-6, and nfs file locking does not work at all for this client. I= =20 Talk to kuriyama@ about this, he is currently investigating it. Kris --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD81nnWry0BWjoQKURAntCAKDO0kvHBjj3gxEJ/y4NqbUtgJnPqgCg6Xqt dRxcIAL3DkOIQQkih7BSEl8= =y+t6 -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 15 19:43:23 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A920316A420 for ; Wed, 15 Feb 2006 19:43:23 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5A7443D62 for ; Wed, 15 Feb 2006 19:43:16 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 81119 invoked from network); 15 Feb 2006 19:39:29 -0000 Received: from c00l3r.networx.ch (HELO freebsd.org) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Feb 2006 19:39:29 -0000 Message-ID: <43F3846E.846ED620@freebsd.org> Date: Wed, 15 Feb 2006 20:43:42 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ivan Voras References: <43F0CE40.5040800@fer.hr> <43F1A2D1.7040402@packetfront.com> <43F24E7E.4060503@fer.hr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Ragnar Lonn , net@freebsd.org Subject: Re: TCP Performance advice needed [long!] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2006 19:43:23 -0000 Ivan Voras wrote: > > Ragnar Lonn wrote: > > I don't know what tcp.inflight does but I know that this type of > > application > > protocol, that expects a reply before sending the next piece of data, will > > always be completely dependent upon roundtrip times for its throughput - > > the roundtrip time for the exchange "transmit-reply" will limit the > > possible throughput you can get so if you want higher performance, either > > I understand this bottleneck, and know (at least in theory :) ) how it > could be solved, but my problems are not directly related to that: > > - For small (but consistent in size) packet sizes, I get randomly > varying round-trip times, and much lower packets-per-second ratio then > with big packets (consistent in size) with the exact same lock-step > protocol. Packet generation and processing are not CPU intensive. This is because of the Nagle algo which tries to accumulate some more data in packets and to piggyback ACKs to replies. Enable TCP_NODELAY on the socket and it should go away. Disabling delayed ACKs may help in your case too. > - When using big packets (actually, when switching back and forth from > small packets to big packets), the PPS performance starts low and climbs > to "normal" levels, and I'd like to avoid this. This is a local network > with 0 errors. > > (if you like it, replace the word "packets" with "messages" in the above > explanation :) ) > > I think the above problems are not directly related to the protocol > (which could be better, I agree, but it won't happen at least until I > understand what is happening with this version) but on fine-tuning of > the network or socket options. This is 'normal' TCP socket behaviour which is obviously not good with your application. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Feb 15 20:19:40 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6ECD16A423 for ; Wed, 15 Feb 2006 20:19:40 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF2C043D45 for ; Wed, 15 Feb 2006 20:19:39 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 81394 invoked from network); 15 Feb 2006 20:15:52 -0000 Received: from c00l3r.networx.ch (HELO freebsd.org) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Feb 2006 20:15:52 -0000 Message-ID: <43F38CF5.71C326C1@freebsd.org> Date: Wed, 15 Feb 2006 21:20:05 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Max Laier References: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> <711b7ec873f31bc5be50ce477313fac3@madhaus.cns.utoronto.ca> <43ECEF7C.2090101@elischer.org> <200602110002.21275.max@love2party.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Marcos Bedinelli , freebsd-net@freebsd.org, Julian Elischer Subject: Re: Network performance in a dual CPU system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2006 20:19:41 -0000 Max Laier wrote: > > On Friday 10 February 2006 20:54, Julian Elischer wrote: > > Marcos Bedinelli wrote: > > > Hello all, > > > > > > thanks for the replies. Most of you have suggested that I turn on > > > polling and give it a try. The machine is in production, hence I need > > > to schedule downtime for that. > > > > > > The system is mainly being used as a dedicated router. It runs OSPF, > > > BGP and IPFW (around 150 rules). OSPF and BGP are managed by Quagga. > > > The box has 2 gigabit interfaces that handle on average 200Mbp/s - 50K > > > packets/s (inbound and outbound combined), each one of them. > > > > I have found that most people can optimise there ipfw rulests considerably. > > > > for example: a first rule of: > > 1 allow ip from any to any in recv {inside interfacfe} > > 2 allow ip from any to any out xmit {inside interface} > > will cut your ipfw load by 50% immediatly. > > (you should only be filterring on one interface usually) > > > > use 'skipto' rules to immediatly send incoming and outgoing data to > > different rules sets. > > FWIW, pf does some of those optimizations automatically called "skip steps" > and "pfctl -o" restructures the ruleset so that often matching rules are > moved to the top. I know that this does not map directly to IPFW, but it > might still be interesting to have a look at it. >From my profiling with the Agilent tester there seem to be two areas where the packet filters (ipfw in my test case) burn a lot of CPU per packet. That is a) setup of lots of packet variables unconditionally at the entry of ip_fw_chk() no matter whether they get looked at later or not, and b) the switch() going through all the packet inspection options is for some reason not optimized by the compiler and burns even more CPU. Some sort of JIT (as in the new bpf code) which replaces the case testing and jumps directly to the proper place in the switch statement would go a long way of making it way more performant. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Feb 15 20:27:36 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FDEB16A420 for ; Wed, 15 Feb 2006 20:27:36 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AAEC43D6D for ; Wed, 15 Feb 2006 20:27:26 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 81452 invoked from network); 15 Feb 2006 20:23:25 -0000 Received: from c00l3r.networx.ch (HELO freebsd.org) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Feb 2006 20:23:25 -0000 Message-ID: <43F38EBA.F96DE9C5@freebsd.org> Date: Wed, 15 Feb 2006 21:27:38 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov References: <20060210221415.GC33588@ip.net.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org Subject: Re: [FIX] dummynet breaks IP reassembly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2006 20:27:36 -0000 Ruslan Ermilov wrote: > > Hi Andre, > > If I'm not mistaken, *you* converted ipfw to use pfil(9). > During the conversion, the following bug was introduced. > > When forwarding fragmented packets through a dummynet pipe > (ip_input -> ip_forward -> ip_output -> pipe -> ip_output) > the last ip_output() in the chain that does the actual IP > delivery sets ip_id of all fragments to different values, > making it impossible to reassemble the packet at receive > side. > > Example of forwarding a fragmented IP datagram from em0 > to xl0: > > # tcpdump -nvi em0 net 192.168.2 > tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes > 00:04:35.170994 IP (tos 0x0, ttl 64, id 2186, offset 0, flags [+], proto: ICMP (1), length: 1500) 192.168.1.3 > 192.168.2.1: ICMP echo request, id 2819, seq 0, length 1480 > 00:04:35.171242 IP (tos 0x0, ttl 64, id 2186, offset 1480, flags [none], proto: ICMP (1), length: 548) 192.168.1.3 > 192.168.2.1: icmp > > # tcpdump -nvi xl0 net 192.168.2 > tcpdump: listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes > 00:04:35.171028 IP (tos 0x0, ttl 63, id 10560, offset 0, flags [+], proto: ICMP (1), length: 1500) 192.168.1.3 > 192.168.2.1: ICMP echo request, id 2819, seq 0, length 1480 > 00:04:35.171266 IP (tos 0x0, ttl 63, id 10561, offset 1480, flags [none], proto: ICMP (1), length: 548) 192.168.1.3 > 192.168.2.1: icmp > > Note that IDs were rewritten from the original 2186 and > worse, they are different. > > In 4,x, the "flags" field (see the patch below) was used > to keep the IP_FORWARDING bit passed to ip_output() by > ip_forward(). This bit was kept in the dummynet packet > tag (in the "flags" field) and later passed to the second > ip_output() call, causing the latter to NOT touch the IP > header again. This feature was lost, resulting in a bug. > > Since dummynet never calls ip_output() with unfilled > header, it's safe to always call ip_output() from dummynet > with the IP_FORWARDING bit set, to indicate it's forwarded > from another ip_output() and so it shouldn't attempt to > modify the header. That is correct. > Surprisingly, it "seemed" to work for packets exceeding > MTU and originating from the dummynetting host, mainly > because the packet wasn't fragmented while in dummynet. > Yet, the ip_id field was always incremented in my tests > (pipe with no bandwidth limitation), comparing it before > and after the dummynet processing. Now, the ip_id is > always preserved. Packets that originated on the dummynetting host don't get fragmented until they actually hit the if_output() in ip_output(). The entire over-sized packet stays intact while in dummynet and only get fragmented later. > # tcpdump -nvi em0 net 192.168.2 > tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes > 00:12:04.654669 IP (tos 0x0, ttl 64, id 2192, offset 0, flags [+], proto: ICMP (1), length: 1500) 192.168.1.3 > 192.168.2.1: ICMP echo request, id 7939, seq 0, length 1480 > 00:12:04.654917 IP (tos 0x0, ttl 64, id 2192, offset 1480, flags [none], proto: ICMP (1), length: 548) 192.168.1.3 > 192.168.2.1: icmp > > # tcpdump -nvi xl0 net 192.168.2 > tcpdump: listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes > 00:12:04.654703 IP (tos 0x0, ttl 63, id 2192, offset 0, flags [+], proto: ICMP (1), length: 1500) 192.168.1.3 > 192.168.2.1: ICMP echo request, id 7939, seq 0, length 1480 > 00:12:04.654939 IP (tos 0x0, ttl 63, id 2192, offset 1480, flags [none], proto: ICMP (1), length: 548) 192.168.1.3 > 192.168.2.1: icmp > > (Note the ip_id is preserved when forwarding.) > > I'm not sure about the IPv6 portion but it's consistent > with the normal forwarding path so I believe it's correct. > Comments? Looks correct. Dunno about the effect on IPv6. IIRC IPv6 doesn't support fragmenting packets and always has to do PMTU discovery. Thanks for tracking down and fixing this bug. -- Andre > %%% > Index: ip_dummynet.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_dummynet.c,v > retrieving revision 1.98 > diff -u -p -r1.98 ip_dummynet.c > --- ip_dummynet.c 3 Feb 2006 11:38:19 -0000 1.98 > +++ ip_dummynet.c 10 Feb 2006 21:20:59 -0000 > @@ -769,7 +769,7 @@ dummynet_send(struct mbuf *m) > pkt = dn_tag_get(m); > switch (pkt->dn_dir) { > case DN_TO_IP_OUT: > - ip_output(m, NULL, NULL, pkt->flags, NULL, NULL); > + ip_output(m, NULL, NULL, IP_FORWARDING, NULL, NULL); > break ; > case DN_TO_IP_IN : > ip = mtod(m, struct ip *); > @@ -783,7 +783,7 @@ dummynet_send(struct mbuf *m) > break; > > case DN_TO_IP6_OUT: > - ip6_output(m, NULL, NULL, pkt->flags, NULL, NULL, NULL); > + ip6_output(m, NULL, NULL, IPV6_FORWARDING, NULL, NULL, NULL); > break; > #endif > case DN_TO_IFB_FWD: > @@ -1129,7 +1129,6 @@ locate_pipe(int pipe_nr) > * ifp the 'ifp' parameter from the caller. > * NULL in ip_input, destination interface in ip_output, > * rule matching rule, in case of multiple passes > - * flags flags from the caller, only used in ip_output > * > */ > static int > @@ -1213,8 +1212,6 @@ dummynet_io(struct mbuf *m, int dir, str > pkt->dn_dir = dir ; > > pkt->ifp = fwa->oif; > - if (dir == DN_TO_IP_OUT || dir == DN_TO_IP6_OUT) > - pkt->flags = fwa->flags; > > if (q->head == NULL) > q->head = m; > Index: ip_dummynet.h > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_dummynet.h,v > retrieving revision 1.38 > diff -u -p -r1.38 ip_dummynet.h > --- ip_dummynet.h 29 Nov 2005 00:11:01 -0000 1.38 > +++ ip_dummynet.h 10 Feb 2006 21:13:45 -0000 > @@ -130,7 +130,6 @@ struct dn_pkt_tag { > > dn_key output_time; /* when the pkt is due for delivery */ > struct ifnet *ifp; /* interface, for ip_output */ > - int flags ; /* flags, for ip_output (IPv6 ?) */ > struct _ip6dn_args ip6opt; /* XXX ipv6 options */ > }; > #endif /* _KERNEL */ > Index: ip_fw.h > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_fw.h,v > retrieving revision 1.103 > diff -u -p -r1.103 ip_fw.h > --- ip_fw.h 13 Dec 2005 12:16:02 -0000 1.103 > +++ ip_fw.h 10 Feb 2006 21:15:41 -0000 > @@ -510,8 +510,6 @@ struct ip_fw_args { > struct ip_fw *rule; /* matching rule */ > struct ether_header *eh; /* for bridged packets */ > > - int flags; /* for dummynet */ > - > struct ipfw_flow_id f_id; /* grabbed from IP header */ > u_int32_t cookie; /* a cookie depending on rule action */ > struct inpcb *inp; > %%% > > Cheers, > -- > Ruslan Ermilov > ru@FreeBSD.org > FreeBSD committer > > -------------------------------------------------------------------------------- > Part 1.2Type: application/pgp-signature From owner-freebsd-net@FreeBSD.ORG Wed Feb 15 20:31:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 192E316A420; Wed, 15 Feb 2006 20:31:10 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id B672743D7F; Wed, 15 Feb 2006 20:30:47 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k1FKUhVL029619; Wed, 15 Feb 2006 12:30:43 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k1FKUhoe029618; Wed, 15 Feb 2006 12:30:43 -0800 (PST) (envelope-from rizzo) Date: Wed, 15 Feb 2006 12:30:43 -0800 From: Luigi Rizzo To: Andre Oppermann Message-ID: <20060215123043.A29559@xorpc.icir.org> References: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> <711b7ec873f31bc5be50ce477313fac3@madhaus.cns.utoronto.ca> <200602110002.21275.max@love2party.net> <43F38CF5.71C326C1@freebsd.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: <43F38CF5.71C326C1@freebsd.org>; from andre@freebsd.org on Wed, Feb 15, 2006 at 09:20:05PM +0100 Cc: Marcos Bedinelli , Max Laier , Julian Elischer , freebsd-net@freebsd.org Subject: Re: Network performance in a dual CPU system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2006 20:31:10 -0000 On Wed, Feb 15, 2006 at 09:20:05PM +0100, Andre Oppermann wrote: ... > >From my profiling with the Agilent tester there seem to be two areas where > the packet filters (ipfw in my test case) burn a lot of CPU per packet. > That is a) setup of lots of packet variables unconditionally at the entry > of ip_fw_chk() no matter whether they get looked at later or not, and b) > the switch() going through all the packet inspection options is for some > reason not optimized by the compiler and burns even more CPU. Some sort > of JIT (as in the new bpf code) which replaces the case testing and jumps > directly to the proper place in the switch statement would go a long way > of making it way more performant. i was expecting some overhead in the initial setting of variables but the cost of the switch() surprises me a bit. did you look at the assembly code produced, or otherwise could you explain a bit more how you think the switch affects performance ? Maybe one could make it cheaper through an indirect function call ? (in the end, instructions are already indexes for a jump table). cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Feb 15 21:00:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B4B616A420 for ; Wed, 15 Feb 2006 21:00:42 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5547A43D45 for ; Wed, 15 Feb 2006 21:00:41 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 81755 invoked from network); 15 Feb 2006 20:56:53 -0000 Received: from c00l3r.networx.ch (HELO freebsd.org) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Feb 2006 20:56:53 -0000 Message-ID: <43F39692.7A3228BA@freebsd.org> Date: Wed, 15 Feb 2006 22:01:06 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo References: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> <711b7ec873f31bc5be50ce477313fac3@madhaus.cns.utoronto.ca> <200602110002.21275.max@love2party.net> <43F38CF5.71C326C1@freebsd.org> <20060215123043.A29559@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Marcos Bedinelli , Max Laier , Julian Elischer , freebsd-net@freebsd.org Subject: Re: Network performance in a dual CPU system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2006 21:00:42 -0000 Luigi Rizzo wrote: > > On Wed, Feb 15, 2006 at 09:20:05PM +0100, Andre Oppermann wrote: > ... > > >From my profiling with the Agilent tester there seem to be two areas where > > the packet filters (ipfw in my test case) burn a lot of CPU per packet. > > That is a) setup of lots of packet variables unconditionally at the entry > > of ip_fw_chk() no matter whether they get looked at later or not, and b) > > the switch() going through all the packet inspection options is for some > > reason not optimized by the compiler and burns even more CPU. Some sort > > of JIT (as in the new bpf code) which replaces the case testing and jumps > > directly to the proper place in the switch statement would go a long way > > of making it way more performant. > > i was expecting some overhead in the initial setting of > variables but the cost of the switch() surprises me a bit. > did you look at the assembly code produced, or otherwise > could you explain a bit more how you think the switch > affects performance ? > Maybe one could make it cheaper through an indirect function call ? > (in the end, instructions are already indexes for a jump table). I didn't look at the assembler code as I can't do assembler. In my testing (on UP) the peak forwarding rate on this particular hardware with fastforwarding enabled dropped from 580kpps to 476kpps (ipfw allow all) to 357kpps (30 non-matching rules on IP address). The number of CPU instructions and branches per packet is as follows: maxkpps instr. branch mispred dcache icfetch icmiss fastfwd 580 2238 300 3.8 1429 812 0.06 fastfwd+ipfw 476 2573 329 17.2 1721 1005 4.31 fastfwd+ipfw30 357 3493 508 15.2 2129 1500 3.35 The setup of the packet variables only happens once per packet. The overhead thus must come from the micro-op evaluation. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Feb 16 11:03:40 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F98D16A420; Thu, 16 Feb 2006 11:03:40 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D4A143D55; Thu, 16 Feb 2006 11:03:39 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.4/8.13.4) with ESMTP id k1GB3b9h045765; Thu, 16 Feb 2006 14:03:37 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 16 Feb 2006 14:03:37 +0300 (MSK) From: Dmitry Morozovsky To: freebsd-net@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <20060216135805.K91053@woozle.rinet.ru> X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (woozle.rinet.ru [0.0.0.0]); Thu, 16 Feb 2006 14:03:37 +0300 (MSK) Cc: ume@FreeBSD.org Subject: hosts.allow default behaviour: IPv6 on its own lines X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2006 11:03:40 -0000 Dear colleagues, at least rpcbind brokes on parsing hosts.allow file when built with NO_INET6: Feb 16 13:55:41 ... rpcbind: error: /etc/hosts.allow, line 42: missing option name Feb 16 13:55:41 ... rpcbind: connect from 127.0.0.1 to getport/addr(mountd): request from unauthorized host Maybe split default line to simplify commenting second one out? Index: hosts.allow =================================================================== RCS file: /home/ncvs/src/etc/hosts.allow,v retrieving revision 1.19 diff -u -r1.19 hosts.allow --- hosts.allow 3 Aug 2004 08:58:34 -0000 1.19 +++ hosts.allow 16 Feb 2006 10:58:00 -0000 @@ -36,7 +36,9 @@ # Allow anything from localhost. Note that an IP address (not a host # name) *MUST* be specified for rpcbind(8). -ALL : localhost 127.0.0.1 [::1] : allow +ALL : localhost 127.0.0.1 : allow +# Comment out next line if you use kernel without IPv6. +ALL : [::1] : allow ALL : my.machine.example.com 192.0.2.35 : allow # To use IPv6 addresses you must enclose them in []'s Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Thu Feb 16 15:03:42 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20CE316A420; Thu, 16 Feb 2006 15:03:42 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AE4B43D69; Thu, 16 Feb 2006 15:03:37 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:aziGr3ibybTdQT3E1OfBTQPLMH2NfofsyT8TWwCCs8l6nrOXCBbsz8rTWyxrSAy/@kasuga-iwi.mahoroba.org [IPv6:3ffe:501:185b:8010:212:f0ff:fe52:6ac]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.4/8.13.4) with ESMTP/inet6 id k1GF3Tiu084298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2006 00:03:29 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Fri, 17 Feb 2006 00:03:28 +0900 Message-ID: From: Hajimu UMEMOTO To: Dmitry Morozovsky In-Reply-To: <20060216135805.K91053@woozle.rinet.ru> References: <20060216135805.K91053@woozle.rinet.ru> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.1) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.1-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.1.3 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Fri, 17 Feb 2006 00:03:29 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on ameno.mahoroba.org Cc: freebsd-net@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: hosts.allow default behaviour: IPv6 on its own lines X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2006 15:03:42 -0000 Hi, >>>>> On Thu, 16 Feb 2006 14:03:37 +0300 (MSK) >>>>> Dmitry Morozovsky said: marck> at least rpcbind brokes on parsing hosts.allow file when built with NO_INET6: marck> Feb 16 13:55:41 ... rpcbind: error: /etc/hosts.allow, line 42: missing option name marck> Feb 16 13:55:41 ... rpcbind: connect from 127.0.0.1 to getport/addr(mountd): request from unauthorized host marck> Maybe split default line to simplify commenting second one out? Thanks, I've committed it into HEAD. marck> +# Comment out next line if you use kernel without IPv6. It is not kernel thing but just libwrap thing. So, I modified the comment slightly. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Thu Feb 16 20:15:16 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 576AD16A420 for ; Thu, 16 Feb 2006 20:15:16 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2331043D49 for ; Thu, 16 Feb 2006 20:15:16 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 009E11A3C25 for ; Thu, 16 Feb 2006 12:15:16 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5CC925152B; Thu, 16 Feb 2006 15:15:14 -0500 (EST) Date: Thu, 16 Feb 2006 15:15:14 -0500 From: Kris Kennaway To: net@FreeBSD.org Message-ID: <20060216201514.GA25470@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: deadc0de panic in fxp driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2006 20:15:16 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Peter Holm's stress test gave me this on an SMP machine running fresh 7.0: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xdeadc0de fault code = supervisor write, page not present instruction pointer = 0x20:0xc0681633 stack pointer = 0x28:0xf3bbeb88 frame pointer = 0x28:0xf3bbeb88 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 24 (irq17: fxp0) [thread pid 24 tid 100020 ] Stopped at trash_dtor+0x10: movl $0xdeadc0de,0(%edx) db> wh Tracing pid 24 tid 100020 td 0xcc47b1a0 trash_dtor(deadc0de,800,0,f3bbebb8,c05295bb) at trash_dtor+0x10 trash_init(deadc0de,800,1,7f,35) at trash_init+0x20 mb_zinit_pack(ccb7e100,100,1,85f,f3bbebec) at mb_zinit_pack+0x50 uma_zalloc_bucket(c1057000,1,c073d432,75d,0) at uma_zalloc_bucket+0x1f1 uma_zalloc_arg(c1057000,f3bbec4c,1,1,c072a086) at uma_zalloc_arg+0x38e fxp_add_rfabuf(cc546000,cc54604c,2,61a,cc546014) at fxp_add_rfabuf+0x35 fxp_intr_body(cc546000,cc53c000,40,ffffffff,cc53c000) at fxp_intr_body+0x115 fxp_intr(cc546000,f3bbecdc,c052aa10,c07f5c90,1) at fxp_intr+0xcf ithread_execute_handlers(cc4cccd8,cc477700,c0725a19,2f9,cc47b1a0) at ithread_execute_handlers+0x10e ithread_loop(cc539960,f3bbed38,c0725807,31a,cc539960) at ithread_loop+0x78 fork_exit(c051cdfa,cc539960,f3bbed38) at fork_exit+0xc5 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xf3bbed6c, ebp = 0 --- db> I can leave it in DDB for a little while (can't dump) in case someone needs additional debugging, but not forever. Kris --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD9N1RWry0BWjoQKURAmLRAKDMARIAe2Ow/jli0lIDoxOBtVRLdQCgnMui YloRSZ7mH2Nlcy8jIZ5nR7s= =k23V -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 16 21:15:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8A7816A420; Thu, 16 Feb 2006 21:15:41 +0000 (GMT) (envelope-from joe@joeholden.co.uk) Received: from elise.rewt.org.uk (elise.rewt.org.uk [82.152.108.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8F0543D6B; Thu, 16 Feb 2006 21:15:37 +0000 (GMT) (envelope-from joe@joeholden.co.uk) Received: from [82.152.108.166] (im.a.raver.not.a.fucking.drug-addict.be [82.152.108.166]) (authenticated bits=0) by elise.rewt.org.uk (8.13.5/8.13.4) with ESMTP id k1GLFdH2011193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2006 21:15:39 GMT (envelope-from joe@joeholden.co.uk) Message-ID: <43F4EB72.5090702@joeholden.co.uk> Date: Thu, 16 Feb 2006 21:15:30 +0000 From: Joe Holden User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: freebsd-isp@freebsd.org, freebsd-net@freebsd.org X-Enigmail-Version: 0.94.0.0 OpenPGP: id=13A6D1E7; url=http://www.joeholden.co.uk/pubkey.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig44DD52E44DE515495371D51B" Cc: Subject: (no subject) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joe@joeholden.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2006 21:15:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig44DD52E44DE515495371D51B Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello list! Sorry for posting this to both, however I wasn't sure which it applied to= =2E I'm looking at creating an intrusion detection system, similiar to=20 portsentry, however using bpf/tcpdump to monitor all traffic, without=20 needing to listen on those ports, it will be run on a border router, and = as such will need to check for incoming packets destined for other=20 machines too, and blackhole/add ipfw rules as needed. Are there any=20 tools like this currently available, or a number of tools I can put=20 together to create something like this? --=20 With thanks, Joe Holden Freelance Network Engineer / Consultant FreeBSD Port Maintainer http://www.joeholden.co.uk Pub Key: http://www.joeholden.co.uk/pubkey.asc Contact: Finger me! --------------enig44DD52E44DE515495371D51B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD9OtydQJXshOm0ecRAtNuAKCWBQK2J0/zq4GwlfgkzQlwPH16OQCffgxx XU9/nQjToqZTgL2W9kxCOXs= =HG5Q -----END PGP SIGNATURE----- --------------enig44DD52E44DE515495371D51B-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 16 22:28:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B846616A420; Thu, 16 Feb 2006 22:28:08 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56CA543D45; Thu, 16 Feb 2006 22:28:08 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id k1GMPthj012302; Thu, 16 Feb 2006 15:25:55 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 16 Feb 2006 15:25:55 -0700 (MST) Message-Id: <20060216.152555.71099274.imp@bsdimp.com> To: marck@rinet.ru From: Warner Losh In-Reply-To: <20060216135805.K91053@woozle.rinet.ru> References: <20060216135805.K91053@woozle.rinet.ru> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 16 Feb 2006 15:25:55 -0700 (MST) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, ume@freebsd.org Subject: Re: hosts.allow default behaviour: IPv6 on its own lines X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2006 22:28:08 -0000 From: Dmitry Morozovsky Subject: hosts.allow default behaviour: IPv6 on its own lines Date: Thu, 16 Feb 2006 14:03:37 +0300 (MSK) > Dear colleagues, > > at least rpcbind brokes on parsing hosts.allow file when built with NO_INET6: > > Feb 16 13:55:41 ... rpcbind: error: /etc/hosts.allow, line 42: missing option name > Feb 16 13:55:41 ... rpcbind: connect from 127.0.0.1 to getport/addr(mountd): request from unauthorized host > > Maybe split default line to simplify commenting second one out? > > Index: hosts.allow > =================================================================== > RCS file: /home/ncvs/src/etc/hosts.allow,v > retrieving revision 1.19 > diff -u -r1.19 hosts.allow > --- hosts.allow 3 Aug 2004 08:58:34 -0000 1.19 > +++ hosts.allow 16 Feb 2006 10:58:00 -0000 > @@ -36,7 +36,9 @@ > > # Allow anything from localhost. Note that an IP address (not a host > # name) *MUST* be specified for rpcbind(8). > -ALL : localhost 127.0.0.1 [::1] : allow > +ALL : localhost 127.0.0.1 : allow > +# Comment out next line if you use kernel without IPv6. > +ALL : [::1] : allow > ALL : my.machine.example.com 192.0.2.35 : allow > > # To use IPv6 addresses you must enclose them in []'s The comment isn't quite right. If the kernel doesn't have IPv6, then it is fine. It is only if userland is compiled with NO_IPV6 that there's a problem. From owner-freebsd-net@FreeBSD.ORG Fri Feb 17 00:07:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8E9E16A420; Fri, 17 Feb 2006 00:07:00 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C18943D46; Fri, 17 Feb 2006 00:07:00 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout10/MantshX 4.0) with ESMTP id k1H06xsK026706; Thu, 16 Feb 2006 16:07:00 -0800 (PST) Received: from [192.168.1.3] (pool-68-161-67-103.ny325.east.verizon.net [68.161.67.103]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id k1H06jf7029094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2006 16:06:59 -0800 (PST) Message-ID: <43F51396.5000302@mac.com> Date: Thu, 16 Feb 2006 19:06:46 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: joe@joeholden.co.uk References: <43F4EB72.5090702@joeholden.co.uk> In-Reply-To: <43F4EB72.5090702@joeholden.co.uk> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-isp@freebsd.org, freebsd-net@freebsd.org Subject: Re: (no subject) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2006 00:07:00 -0000 Joe Holden wrote: [ ... ] > I'm looking at creating an intrusion detection system, similiar to > portsentry, however using bpf/tcpdump to monitor all traffic, without > needing to listen on those ports, it will be run on a border router, and > as such will need to check for incoming packets destined for other > machines too, and blackhole/add ipfw rules as needed. Are there any > tools like this currently available, or a number of tools I can put > together to create something like this? Check out /usr/ports/net/honeyd and the Honeynet project... -- -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Feb 17 09:39:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 313A616A420 for ; Fri, 17 Feb 2006 09:39:14 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E31543D53 for ; Fri, 17 Feb 2006 09:39:13 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.9.8] (gw1.arcticwireless.no [80.203.184.14]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.4/8.13.4) with ESMTP id k1H9dC4G015315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 17 Feb 2006 10:39:12 +0100 Message-ID: <43F599BF.7080004@wm-access.no> Date: Fri, 17 Feb 2006 10:39:11 +0100 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.94.0.0 OpenPGP: id=D6F56A9B Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5BE40B45B965F67B7653FF24" Subject: ATH max packet size? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2006 09:39:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5BE40B45B965F67B7653FF24 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I am still waiting for my PCI -> MiniPCI bridge for my CM9 card so i am=20 unable to test this, and even though i read the source i am still=20 unsure, so i was hoping a kind generous soul would answer my question; What is the max packet size (mtu) available using the ath driver? The reason i ask is, i want to setup a tunnel between two units and=20 optimally not have to deal with any fragmentation issues. --=20 Sten Daniel S=F8rsdal --------------enig5BE40B45B965F67B7653FF24 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD9Zm/MvOF8Nb1apsRAobgAJwNgleBm2MdRETJ7PWDA8HFP0LMMQCeOB5a aa1ajFfxz84KqRP9yHedWQE= =wNdA -----END PGP SIGNATURE----- --------------enig5BE40B45B965F67B7653FF24-- From owner-freebsd-net@FreeBSD.ORG Fri Feb 17 16:31:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFC3316A420 for ; Fri, 17 Feb 2006 16:31:10 +0000 (GMT) (envelope-from tpeixoto@widesoft.com.br) Received: from smtp-gw.widesoft.com.br (carbono.widesoft.com.br [200.246.206.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id C31EF43D64 for ; Fri, 17 Feb 2006 16:31:07 +0000 (GMT) (envelope-from tpeixoto@widesoft.com.br) Received: from www.widemail.com.br (grants.widesoft.com.br [172.26.100.1]) by smtp-gw.widesoft.com.br (Postfix) with ESMTP id 46CA71168C; Fri, 17 Feb 2006 14:28:24 -0200 (BRST) Received: from 200.230.201.250 (SquirrelMail authenticated user tpeixoto) by www.widemail.com.br with HTTP; Fri, 17 Feb 2006 14:52:30 -0200 (BRST) Message-ID: <59893.200.230.201.250.1140195150.squirrel@www.widemail.com.br> Date: Fri, 17 Feb 2006 14:52:30 -0200 (BRST) From: tpeixoto@widesoft.com.br To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: bind9 + host command issue in FreeBSD-5.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2006 16:31:10 -0000 Hello all! I am not sure if this is the right place to discuss this issue but I am experiencing strange behaviour with bind9 + host command with some domains that bind are _not_ authoritative as the following example: # uname -a FreeBSD server2.mydomain.com.br 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Wed Feb 1 22:18:04 BRST 2006 root@server2.mydomain.com.br:/usr/src/sys/i386/compile/SERVER2 i386 # named -v BIND 9.3.1 # host -t mx unibanco.com.br unibanco.com.br mail is handled by 10 cauexcnt001smtp.unibanco.com.br. Ok, fine so far. # host cauexcnt001smtp.unibanco.com.br. cauexcnt001smtp.unibanco.com.br has address 200.174.81.116 Host cauexcnt001smtp.unibanco.com.br not found: 2(SERVFAIL) That's the problem! host command replies with SERVFAIL. This also causes sendmail to raise "host name lookup failure" and not deliver the messages. The strange thing is that nslookup and dig work correctly: # nslookup cauexcnt001smtp.unibanco.com.br. Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: cauexcnt001smtp.unibanco.com.br Address: 200.174.81.116 # dig cauexcnt001smtp.unibanco.com.br. ; <<>> DiG 9.3.1 <<>> cauexcnt001smtp.unibanco.com.br. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4512 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;cauexcnt001smtp.unibanco.com.br. IN A ;; ANSWER SECTION: cauexcnt001smtp.unibanco.com.br. 0 IN A 200.155.107.243 ;; AUTHORITY SECTION: cauexcnt001smtp.unibanco.com.br. 1322 IN NS ubblp01.unibanco.com.br. cauexcnt001smtp.unibanco.com.br. 1322 IN NS ubblp02.unibanco.com.br. ;; Query time: 250 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Feb 17 13:46:18 2006 ;; MSG SIZE rcvd: 109 I also have another server with the same FreeBSD and bind version and the problem is the same. On the other hand, a server with FreeBSD-4.8 and bind 8.3.4-REL works ok: # host cauexcnt001smtp.unibanco.com.br cauexcnt001smtp.unibanco.com.br has address 200.174.81.243 I've tried several things, looked into google the entire morning, but no success. It's not firewall. "ipfw add 1 allow ip from any to any" didn't help. Ports bind 9.3.2 also didn't work. Any help would be greatly appreciated. Thank you in advance, Tobias. From owner-freebsd-net@FreeBSD.ORG Fri Feb 17 17:56:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6829D16A420 for ; Fri, 17 Feb 2006 17:56:59 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 080A143D45 for ; Fri, 17 Feb 2006 17:56:57 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id k1HHuto7022981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2006 09:56:57 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <43F60F13.6000805@errno.com> Date: Fri, 17 Feb 2006 09:59:47 -0800 From: Sam Leffler User-Agent: Thunderbird 1.5 (X11/20060210) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= References: <43F599BF.7080004@wm-access.no> In-Reply-To: <43F599BF.7080004@wm-access.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: ATH max packet size? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2006 17:56:59 -0000 Sten Daniel Sørsdal wrote: > I am still waiting for my PCI -> MiniPCI bridge for my CM9 card so i am > unable to test this, and even though i read the source i am still > unsure, so i was hoping a kind generous soul would answer my question; > > What is the max packet size (mtu) available using the ath driver? > > The reason i ask is, i want to setup a tunnel between two units and > optimally not have to deal with any fragmentation issues. > From net80211/ieee80211.h: /* * Maximum acceptable MTU is: * IEEE80211_MAX_LEN - WEP overhead - CRC - * QoS overhead - RSN/WPA overhead * Min is arbitrarily chosen > IEEE80211_MIN_LEN. The default * mtu is Ethernet-compatible; it's set by ether_ifattach. */ #define IEEE80211_MTU_MAX 2290 #define IEEE80211_MTU_MIN 32 ath can actually handle very large packets (64K I believe) but the current driver won't chain rx descriptors together so it's limited to an mbuf cluster (2K). Sam From owner-freebsd-net@FreeBSD.ORG Fri Feb 17 21:04:12 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56F0116A420 for ; Fri, 17 Feb 2006 21:04:12 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCBCB43D67 for ; Fri, 17 Feb 2006 21:04:10 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id AD7D21A3C1C for ; Fri, 17 Feb 2006 13:04:10 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 15F3152AC0; Fri, 17 Feb 2006 16:04:10 -0500 (EST) Date: Fri, 17 Feb 2006 16:04:09 -0500 From: Kris Kennaway To: Kris Kennaway Message-ID: <20060217210409.GA72104@xor.obsecurity.org> References: <20060216201514.GA25470@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: <20060216201514.GA25470@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Cc: net@FreeBSD.org Subject: Re: deadc0de panic in fxp driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2006 21:04:12 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2006 at 03:15:14PM -0500, Kris Kennaway wrote: > Peter Holm's stress test gave me this on an SMP machine running fresh > 7.0: >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0xdeadc0de > fault code =3D supervisor write, page not present > instruction pointer =3D 0x20:0xc0681633 > stack pointer =3D 0x28:0xf3bbeb88 > frame pointer =3D 0x28:0xf3bbeb88 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 24 (irq17: fxp0) > [thread pid 24 tid 100020 ] > Stopped at trash_dtor+0x10: movl $0xdeadc0de,0(%edx) > db> wh > Tracing pid 24 tid 100020 td 0xcc47b1a0 > trash_dtor(deadc0de,800,0,f3bbebb8,c05295bb) at trash_dtor+0x10 > trash_init(deadc0de,800,1,7f,35) at trash_init+0x20 > mb_zinit_pack(ccb7e100,100,1,85f,f3bbebec) at mb_zinit_pack+0x50 > uma_zalloc_bucket(c1057000,1,c073d432,75d,0) at uma_zalloc_bucket+0x1f1 > uma_zalloc_arg(c1057000,f3bbec4c,1,1,c072a086) at uma_zalloc_arg+0x38e > fxp_add_rfabuf(cc546000,cc54604c,2,61a,cc546014) at fxp_add_rfabuf+0x35 > fxp_intr_body(cc546000,cc53c000,40,ffffffff,cc53c000) at fxp_intr_body+0x= 115 > fxp_intr(cc546000,f3bbecdc,c052aa10,c07f5c90,1) at fxp_intr+0xcf > ithread_execute_handlers(cc4cccd8,cc477700,c0725a19,2f9,cc47b1a0) at ithr= ead_execute_handlers+0x10e > ithread_loop(cc539960,f3bbed38,c0725807,31a,cc539960) at ithread_loop+0x78 > fork_exit(c051cdfa,cc539960,f3bbed38) at fork_exit+0xc5 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip =3D 0, esp =3D 0xf3bbed6c, ebp =3D 0 --- > db> Peter Holm has also seen this panic involving the fxp driver: http://people.freebsd.org/~pho/stress/log/cons186.html When I ran the stress test on two machines with em they did not panic after about twice as long under load. Kris --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD9jpJWry0BWjoQKURAsYnAKCIyie+wqVbM2MxlEj3cxr1NSRZhgCg6ysB 017cPMT2dJkxsomybP6FBXw= =XAuT -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- From owner-freebsd-net@FreeBSD.ORG Sat Feb 18 06:24:32 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDE1D16A420 for ; Sat, 18 Feb 2006 06:24:32 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 4AAB243D45 for ; Sat, 18 Feb 2006 06:24:32 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 27351 invoked by uid 399); 18 Feb 2006 06:24:31 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 18 Feb 2006 06:24:31 -0000 Message-ID: <43F6BD9D.9080500@FreeBSD.org> Date: Fri, 17 Feb 2006 22:24:29 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: tpeixoto@widesoft.com.br References: <59893.200.230.201.250.1140195150.squirrel@www.widemail.com.br> In-Reply-To: <59893.200.230.201.250.1140195150.squirrel@www.widemail.com.br> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: bind9 + host command issue in FreeBSD-5.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2006 06:24:32 -0000 tpeixoto@widesoft.com.br wrote: > Hello all! > > I am not sure if this is the right place to discuss this issue For future reference, the bind-users list at ISC is probably a better forum, but this is as good as any. :) > but I am > experiencing strange behaviour with bind9 + host command with some domains > that bind are _not_ authoritative I assume you mean domains for which you are not authoritative, in other words, domains you have no control over. > as the following example: > > # uname -a > FreeBSD server2.mydomain.com.br 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Wed > Feb 1 22:18:04 BRST 2006 > root@server2.mydomain.com.br:/usr/src/sys/i386/compile/SERVER2 i386 > > # named -v > BIND 9.3.1 When 5.5-RELEASE comes out (or better yet, 6.1-RELEASE) you should seriously consider upgrading. If you are doing anything mission critical that depends on DNS, BIND 9.3.2 is going to be an improvement for you. > # host cauexcnt001smtp.unibanco.com.br. > cauexcnt001smtp.unibanco.com.br has address 200.174.81.116 > Host cauexcnt001smtp.unibanco.com.br not found: 2(SERVFAIL) The second line is caused because there is no AAAA record for that hostname, and by default host always queries for one. You can see that things are fine with the hostname itself by using 'host -t a', or by using dig as you did below. FYI, if you need to do any kind of serious DNS debugging, dig is always the best tool to use. The host command is best for simple lookups when you just need the answer. > That's the problem! host command replies with SERVFAIL. This also causes > sendmail to raise "host name lookup failure" and not deliver the messages. sendmail does not use the host command. The most likely cause for this failure is that the A record for cauexcnt001smtp.unibanco.com.br has a 0 second TTL, which is not only stupid, it's extremely unfriendly. It's also possible that your system has IPv6 support enabled, but you don't have IPv6 connectivity, and/or your sendmail is configured to use (or prefer) IPv6 addresses. Also, if you have any input into the operation of this zone, suggest that they increase the TTL, and add an MX record for that hostname (even if it points to itself). > The strange thing is that nslookup and dig work correctly: The reason that the other versions you tried don't show that error is that they do not have the same "aggressive" search for AAAA records that BIND 9.3.x does. Whether this is a good thing or not, and what should be printed if there is no record is up for debate. That would be a topic for the bind-users list. Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Sat Feb 18 12:25:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49E4E16A420 for ; Sat, 18 Feb 2006 12:25:08 +0000 (GMT) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (mp.cs.niu.edu [131.156.145.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0E3A43D46 for ; Sat, 18 Feb 2006 12:25:07 +0000 (GMT) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (bennett@localhost [127.0.0.1]) by mp.cs.niu.edu (8.13.5/8.13.5/d) with ESMTP id k1ICO7JZ004213; Sat, 18 Feb 2006 06:24:07 -0600 (CST) Date: Sat, 18 Feb 2006 06:24:07 -0600 (CST) From: Scott Bennett Message-Id: <200602181224.k1ICO70x004212@mp.cs.niu.edu> To: tpeixoto@widesoft.com.br Cc: freebsd-net@freebsd.org Subject: Re: bind9 + host command issue in FreeBSD-5.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2006 12:25:08 -0000 On Fri, 17 Feb 2006 22:24:29 -0800 Doug Barton wrote: >tpeixoto@widesoft.com.br wrote: >> Hello all! >> >> I am not sure if this is the right place to discuss this issue > >For future reference, the bind-users list at ISC is probably a better forum, >but this is as good as any. :) > >> but I am >> experiencing strange behaviour with bind9 + host command with some domains >> that bind are _not_ authoritative > >I assume you mean domains for which you are not authoritative, in other >words, domains you have no control over. > >> as the following example: >> >> # uname -a >> FreeBSD server2.mydomain.com.br 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Wed >> Feb 1 22:18:04 BRST 2006 >> root@server2.mydomain.com.br:/usr/src/sys/i386/compile/SERVER2 i386 >> >> # named -v >> BIND 9.3.1 > >When 5.5-RELEASE comes out (or better yet, 6.1-RELEASE) you should seriously >consider upgrading. If you are doing anything mission critical that depends >on DNS, BIND 9.3.2 is going to be an improvement for you. > >> # host cauexcnt001smtp.unibanco.com.br. >> cauexcnt001smtp.unibanco.com.br has address 200.174.81.116 >> Host cauexcnt001smtp.unibanco.com.br not found: 2(SERVFAIL) > >The second line is caused because there is no AAAA record for that hostname, >and by default host always queries for one. You can see that things are fine >with the hostname itself by using 'host -t a', or by using dig as you did >below. FYI, if you need to do any kind of serious DNS debugging, dig is >always the best tool to use. The host command is best for simple lookups >when you just need the answer. > >> That's the problem! host command replies with SERVFAIL. This also causes >> sendmail to raise "host name lookup failure" and not deliver the messages. > >sendmail does not use the host command. The most likely cause for this >failure is that the A record for cauexcnt001smtp.unibanco.com.br has a 0 >second TTL, which is not only stupid, it's extremely unfriendly. It's also >possible that your system has IPv6 support enabled, but you don't have IPv6 >connectivity, and/or your sendmail is configured to use (or prefer) IPv6 >addresses. Also, if you have any input into the operation of this zone, >suggest that they increase the TTL, and add an MX record for that hostname >(even if it points to itself). > Another point to keep in mind is that sendmail requires authoritative answers. It ignores non-authoritative responses. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-net@FreeBSD.ORG Sat Feb 18 17:21:40 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 377D616A420; Sat, 18 Feb 2006 17:21:40 +0000 (GMT) (envelope-from flag@longino.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9C3143D45; Sat, 18 Feb 2006 17:21:39 +0000 (GMT) (envelope-from flag@longino.wired.org) Received: from longino.wired.org (ip-114-46.sn1.eutelia.it [62.94.114.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id 89FB611AE93; Sat, 18 Feb 2006 18:21:39 +0100 (CET) Received: from longino.wired.org (localhost [127.0.0.1]) by longino.wired.org (8.13.4/8.13.4) with ESMTP id k1IHLY6X004195; Sat, 18 Feb 2006 18:21:34 +0100 (CET) (envelope-from flag@longino.wired.org) Received: (from flag@localhost) by longino.wired.org (8.13.4/8.13.4/Submit) id k1IHLY1F004194; Sat, 18 Feb 2006 18:21:34 +0100 (CET) (envelope-from flag) Date: Sat, 18 Feb 2006 18:21:34 +0100 From: Paolo Pisati To: FreeBSD_Hackers , FreeBSD_Net Message-ID: <20060218172134.GA4146@tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: Subject: [patch] Redirect and LSNAT support in ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2006 17:21:40 -0000 Hi, as a continuation of my Summer of Code project "Improve libalias" i just decided to release a new version with: 1) dinamyc address support via interface name (ipfw nat 111 config if tun0) 2) redirect and LSNAT support in ipfw following closely the natd syntax. The only difference with natd is that i changed the syntax from redirect_[addr|port|proto] to redir_[addr|port|proto]. See natd man page for details about redirect and LSNAT. 3) patches for ppp and natd to use libalias modules (see libalias/patch/) 4) many bugfixes and improvements here and there as always, it supports 4.x, 5.x, 6.x and 7.x Everything was tested on 6.x, but it compiles fine on 4.x and 7.x too. I don't have any 5.x box, so i just made the diffs for it. Project wiki page: http://wikitest.freebsd.org/moin.cgi/PaoloPisati Download link: http://ubi8.imc.pi.cnr.it/~flag/libalias/libalias.tgz There's a detailed readme.txt inside the archive that explains pretty much all you want to know: from installtion process to internals, so read it. Enjoy. -- Paolo From owner-freebsd-net@FreeBSD.ORG Sat Feb 18 18:06:53 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9D8216A420 for ; Sat, 18 Feb 2006 18:06:53 +0000 (GMT) (envelope-from rosti.bsd@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 058FD43D48 for ; Sat, 18 Feb 2006 18:06:52 +0000 (GMT) (envelope-from rosti.bsd@gmail.com) Received: by uproxy.gmail.com with SMTP id u40so394790ugc for ; Sat, 18 Feb 2006 10:06:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:x-mailer:mime-version:content-type:content-transfer-encoding; b=dDXZTmSMkV2t+/hDVY2wssFsjVEK9skfLRWIji8NaRW9Dys9XME7JTzCsS5uFTR0Y3QGR5oVezhP92nNcMbz56ICpe9xXvN/QygI1QVmo6L14s1DM7rjNsm+y6YA2JatD21RZWZ/ZqghxZwx9pJvbwM89C2QRnlYNLhhOf0xe9o= Received: by 10.66.250.9 with SMTP id x9mr1805898ugh; Sat, 18 Feb 2006 10:06:40 -0800 (PST) Received: from saturn.lan ( [212.143.154.227]) by mx.gmail.com with ESMTP id k1sm2050166ugf.2006.02.18.10.06.26; Sat, 18 Feb 2006 10:06:40 -0800 (PST) Date: Sat, 18 Feb 2006 20:05:34 +0200 From: Rostislav Krasny To: freebsd-net@freebsd.org Message-Id: <20060218200534.7e6bc04b.rosti.bsd@gmail.com> X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: RES_DFLRETRY in resolv.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2006 18:06:53 -0000 Hi, According to resolver(5) manual page the number of times the resolver will send a query to each of its name servers before giving up and returning an error to the calling application is a RES_DFLRETRY defined in resolv.h. For years FreeBSD had no RES_DFLRETRY macro defined in resolv.h and had used a hardcoded constant, until Yar Tikhiy fixed it: http://docs.freebsd.org/cgi/mid.cgi?200409091739.i89HdlwM019548 http://docs.freebsd.org/cgi/mid.cgi?200409091742.i89HgIan019681 http://docs.freebsd.org/cgi/mid.cgi?200409091719.i89HJRGu019026 Other systems and BIND9's internal resolver define the RES_DFLRETRY as 2, but in FreeBSD that macro is 4. Why it's so big? I think it had been inherited from old BIND4's resolver. Could the RES_DFLRETRY be decreased from 4 to 2 ? Current value of RES_DFLRETRY can make host unreachable. Read a bin/62139 PR and "SSH login takes very long time...sometimes" threads on freebsd-stable mailing list. Thanks