From owner-freebsd-net@FreeBSD.ORG Sun Jan 21 02:50:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C871916A400; Sun, 21 Jan 2007 02:50:23 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.freebsd.org (Postfix) with ESMTP id 957CB13C45B; Sun, 21 Jan 2007 02:50:23 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from impact.jinmei.org (shuttle.wide.toshiba.co.jp [2001:200:1b1::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2D88815267; Sun, 21 Jan 2007 11:28:55 +0900 (JST) Date: Sun, 21 Jan 2007 11:28:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bjoern A. Zeeb" In-Reply-To: <20070120214052.U82671@maildrop.int.zabbadoz.net> References: <20070120192807.GA1326@sandvine.com> <20070120214052.U82671@maildrop.int.zabbadoz.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, Ed Maste , Hajimu UMEMOTO Subject: Re: inet_pton and oddly-formatted addresses 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, 21 Jan 2007 02:50:23 -0000 >>>>> On Sat, 20 Jan 2007 21:42:44 +0000 (UTC), >>>>> "Bjoern A. Zeeb" said: emaste> I think an address like 1.002.3.4 is bizarre, but is our inet_pton incorrect emaste> in rejecting it? >> >> The change was taken from BIND9. The following is from BIND9's >> CHANGES: >> >> 935. [bug] inet_pton failed to reject leading zeros. > well, maybe they were wrong? How does one get in contact with their > bugs database these days? Is comp.protocols.dns.bind still a good > place to discuss these things? Or bind-users@isc.org. And yes, I'd ask the question at some BIND-specific list. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. 1.002.3.4 is "illegal" according to RFC3986, Section 3.2.2 (although it's specified in the context of a URI), so "what is legal" is probably a controversial issue. From owner-freebsd-net@FreeBSD.ORG Sun Jan 21 05:11:04 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4723016A400 for ; Sun, 21 Jan 2007 05:11:04 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id CCE6613C457 for ; Sun, 21 Jan 2007 05:11:01 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.6.102] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1H8Uyn3QaM-0006fF; Sun, 21 Jan 2007 06:11:00 +0100 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Sun, 21 Jan 2007 06:10:39 +0100 User-Agent: KMail/1.9.5 References: <20070120192807.GA1326@sandvine.com> <20070120214052.U82671@maildrop.int.zabbadoz.net> In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1462050.20htLLDccN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701210610.49958.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: "Bjoern A. Zeeb" , Ed Maste , Hajimu UMEMOTO , JINMEI Tatuya / =?utf-8?q?=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= Subject: Re: inet_pton and oddly-formatted addresses 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, 21 Jan 2007 05:11:04 -0000 --nextPart1462050.20htLLDccN Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 21 January 2007 03:28, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81= =94=E5=93=89 wrote: > >>>>> On Sat, 20 Jan 2007 21:42:44 +0000 (UTC), > >>>>> "Bjoern A. Zeeb" said: > > emaste> I think an address like 1.002.3.4 is bizarre, but is our > inet_pton incorrect emaste> in rejecting it? > > >> The change was taken from BIND9. The following is from BIND9's > >> CHANGES: > >> > >> 935. [bug] inet_pton failed to reject leading zeros. > > > > well, maybe they were wrong? How does one get in contact with their > > bugs database these days? Is comp.protocols.dns.bind still a good > > place to discuss these things? > > Or bind-users@isc.org. And yes, I'd ask the question at some > BIND-specific list. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > p.s. 1.002.3.4 is "illegal" according to RFC3986, Section 3.2.2 > (although it's specified in the context of a URI), so "what is legal" > is probably a controversial issue. Section 7.4 is rather clear about the scope of the definition of "dotted=20 notation" in 3.2.2. - i.e. it is limited to URIs. inet_aton gethostbyname=20 etc. are explicitly allowed to accept platform dependent representations. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1462050.20htLLDccN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFsvXZXyyEoT62BG0RAh/2AJ0RqT8TCimmwZ9f1eTjGO0tOmHUggCeNqMb /HTYhr5Dj7c8NrNC2p2+qLU= =jGYx -----END PGP SIGNATURE----- --nextPart1462050.20htLLDccN-- From owner-freebsd-net@FreeBSD.ORG Sun Jan 21 06:25:24 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C579616A400 for ; Sun, 21 Jan 2007 06:25:24 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 4E2FB13C428 for ; Sun, 21 Jan 2007 06:25:24 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 00B145A0657 for ; Sun, 21 Jan 2007 17:25:22 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 7F15B8C02 for ; Sun, 21 Jan 2007 17:25:20 +1100 (EST) Date: Sun, 21 Jan 2007 17:25:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: net@freebsd.org Message-ID: <20070121155510.C23922@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: slow writes on nfs with bge devices 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, 21 Jan 2007 06:25:24 -0000 nfs writes much less well with bge NICs than with other NICs (sk, fxp, xl, even rl). Sometimes writing a 20K source file from vi seems to take about 2 seconds instead of seeming to be instantaneous (this gets faster as the system warms up). Iozone shows the problem more reproducibly. E.g.: 100Mbps fxp server -> 1Gbps bge 5701 client, udp: %%% IOZONE: Performance Test of Sequential File I/O -- V1.16 (10/28/92) By Bill Norcott Operating System: FreeBSD -- using fsync() IOZONE: auto-test mode MB reclen bytes/sec written bytes/sec read 1 512 1516885 291918639 1 1024 1158783 491354263 1 2048 1573651 715694105 1 4096 1223692 917431957 1 8192 729513 1097929467 2 512 1694809 281196631 2 1024 1379228 507917189 2 2048 1659521 789608264 2 4096 4606056 1064567574 2 8192 1142288 1318131028 4 512 1242214 298269971 4 1024 1853545 492110628 4 2048 2120136 742888430 4 4096 1896792 1121799065 4 8192 850210 1441812403 8 512 1563847 281422325 8 1024 1480844 492749552 8 2048 1658649 850165954 8 4096 2105283 1211348180 8 8192 2098425 1554875506 16 512 1508821 296842294 16 1024 1966239 527850530 16 2048 2036609 842656736 16 4096 1666138 1200594889 16 8192 2293378 1620824908 Completed series of tests %%% Here bge barely reaches 10Mbps speeds (~1.2 MB/S) for writing. Reading is cached well and fast. 100Mbps xl on the same client with the same server goes at full 100Mbps speed (11.77 MB/S for all file sizes including larger ones since the disk is not the limit at 100Mbps). 1Gbps sk on a different client with the same server goes at full 100Nbps speed. Switching to tcp gives full 100 Mbps speed. However, when the bge link speed is reduced to 100Mbps, udp becomes about 10 times slower than the above and tcp becomes about as slow as the above (maybe a bit faster, but far below 11.77 MB/S). bge is also slow at nfs serving: 1Gbps bge 5701 server -> 1Gbps sk client: %%% IOZONE: Performance Test of Sequential File I/O -- V1.16 (10/28/92) By Bill Norcott Operating System: FreeBSD -- using fsync() IOZONE: auto-test mode MB reclen bytes/sec written bytes/sec read 1 512 36255350 242114472 1 1024 3051699 413319147 1 2048 22406458 632021710 1 4096 22447700 851162198 1 8192 3522493 1047562648 2 512 3270779 48125247 2 1024 28992179 46693718 2 2048 5956380 753318255 2 4096 27616650 1053311658 2 8192 5573338 48290208 4 512 9004770 47435659 4 1024 9576276 45601645 4 2048 30348874 85116667 4 4096 8635673 86150049 4 8192 9356773 47100031 8 512 9762446 46424146 8 1024 10054027 58344604 8 2048 9197430 60253061 8 4096 15934077 59476759 8 8192 8765470 47647937 16 512 5670225 46239891 16 1024 9425169 45950990 16 2048 9833515 46242945 16 4096 14812057 51313693 16 8192 9203742 47648722 Completed series of tests %%% Now the available bandwidth is 10 times larger and about 9/10 of it is still not used, with a high variance. For larger files, the variance is lower and the average speed is about 10MB/S. The disk can only do about 40MB/S and the slowest of the 1Gbps NICS (sk) can only sustain 80MB/S through udp and about 50MB/S through tcp (it is limited by the 33 MHz 32-bit PCI bus and by being less smart than the bge interface). When the bge NIC was on the system which is now the server with the fxp NIC, bge and nfs worked unsurprisingly, just slower than I would have liked. The write speed was 20-30MB/S for large files and 30-40MB/S for medium-sized files, with low variance. This is the only configuration in which nfs/bge worked as expected. The problem is very old and not very hardware dependent. Similar behaviour happens when some of the following are changed: OS -> FreeBSD-~5.2 or FreeBSD-6 hardware -> newer amd64 CPU (Turion X2) with 5705 (iozone output for this below) instead of old amd64 CPU with 5701. The newer amd64 normally runs an i386-SMP current kernel while the old amd64 was running an amd64-UP current kernel in the above tests, but normally runs ~5.2 amd64-UP and behaves similarly with that. The combination that seemed to work right was an AthlonXP for the server with the same 5701 and any kernel. The only strangeness with that was that current kernels gave a 5-10% slower nfs server despite giving a 30-90% larger packet rate for small packets. IOZONE: Performance Test of Sequential File I/O -- V1.16 (10/28/92) By Bill Norcott Operating System: FreeBSD -- using fsync() 100Mbps fxp server -> 1Gbps bge 5705 client: %%% IOZONE: auto-test mode MB reclen bytes/sec written bytes/sec read 1 512 2994400 185462027 1 1024 3074084 337817536 1 2048 2991691 576792985 1 4096 3074759 884740798 1 8192 3078019 1176892296 2 512 4262096 186709962 2 1024 2994468 339893080 2 2048 5112176 584846610 2 4096 4754187 909815165 2 8192 5100574 1212919611 4 512 5298715 187129017 4 1024 5302620 344445041 4 2048 4985597 590579630 4 4096 3703618 927711124 4 8192 5236177 1240896243 8 512 5142274 186899396 8 1024 6207933 345564808 8 2048 6162773 593088329 8 4096 6031445 936751120 8 8192 6072523 1224102288 16 512 5427113 186797193 16 1024 5065901 345544445 16 2048 5462338 595487384 16 4096 5256552 937013065 16 8192 5097101 1226320870 Completed series of tests %%% rl on a system with 1/20 as much CPU is faster than this. The problem doesn't seem to affect much besides writes on nfs. The bge 5701 works very well for most things. It has a much better bus interface than the 5705 and works even better after moving it to the old amd64 system (it can now saturate 1Gbps where on the AthlonXP it only got 3/4 of the way, while the 5705 only gets 1/4 of the way). I've been working on minimising network latency and maximising packet rate, and normally have very low network latency (60-80 uS for ping) and fairly high packet rates. The changes for this are not the caause of the bug :-), since the behaviour is not affected by running kernels without these changes or by sysctl''ing the changes to be null. However, the problem looks like ones caused by large latencies combined with non-streaming protocols. To write at just 11.77 MB/S, at least 8000 packets/second must be set from the client to the server. Working clients sustain this rate, but broken clients the rate is much lower and not sustained: Output from netstat -s 1 on server while writing a ~1GB file via 5701/udp: %%% input (Total) output packets errs bytes packets errs bytes colls 900 0 1513334 142 0 33532 0 1509 0 2564836 236 0 57368 0 1647 0 2295802 259 0 51106 0 1603 0 1502736 252 0 32926 0 1055 0 637014 163 0 13938 0 558 0 1542510 86 0 34340 0 984 0 989854 155 0 21816 0 864 0 1320786 135 0 38152 0 883 0 1558060 165 0 34340 0 1177 0 3780102 203 0 85850 0 2087 0 954212 331 0 21210 0 1187 0 1413568 190 0 31310 0 650 0 3320604 101 0 75346 0 1565 0 1706542 246 0 37976 0 2055 0 2360620 329 0 52318 0 1554 0 2416996 244 0 54226 0 1402 0 2579894 220 0 58176 0 1690 0 774488 267 0 16968 0 1323 0 3690650 209 0 83830 0 591 0 4519858 92 0 103110 0 %%% There is no sign of any packet loss or switch problems. Forcing 1000baseTX full-duplex has no effect. Forcing 100baseTX full-duplex makes the problem more obvious. The mtu is 1500 throughout since only bge-5701 and sk support jumbo frames and I want to use udp for nfs. 5705/udp is better: %%% input (Total) output packets errs bytes packets errs bytes colls 5209 0 6607758 846 0 151702 0 4763 0 6684546 773 0 153520 0 4758 0 6618498 769 0 151298 0 3582 0 7057568 576 0 162498 0 4935 0 5115068 800 0 116756 0 4924 0 6622026 798 0 152802 0 4095 0 6018462 657 0 137450 0 4647 0 5270442 751 0 120594 0 4673 0 5451948 758 0 123624 0 2340 0 6001986 372 0 138168 0 3750 0 6150610 604 0 140996 0 %%% sk/udp works right: %%% input (Total) output packets errs bytes packets errs bytes colls 8638 0 12384676 1440 0 293062 0 8636 0 12415646 1439 0 293708 0 8637 0 12415646 1441 0 293708 0 8637 0 12415646 1439 0 293708 0 8637 0 12417160 1440 0 293708 0 8636 0 12413162 1439 0 293506 0 8637 0 12414132 1439 0 293708 0 8636 0 12417160 1440 0 293708 0 8637 0 12415646 1439 0 293708 0 8636 0 12417160 1440 0 293708 0 8637 0 12414676 1439 0 293506 0 %%% sk is under ~5.2 with latency/throughput/efficiency optimizations that don't have much effect here. Bruce From owner-freebsd-net@FreeBSD.ORG Sun Jan 21 07:09:45 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6365916A401 for ; Sun, 21 Jan 2007 07:09:45 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id D7C9C13C428 for ; Sun, 21 Jan 2007 07:09:44 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.6.102] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1H8Wpb2P2E-0006eY; Sun, 21 Jan 2007 08:09:39 +0100 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Sun, 21 Jan 2007 08:09:19 +0100 User-Agent: KMail/1.9.5 References: <20070121155510.C23922@delplex.bde.org> In-Reply-To: <20070121155510.C23922@delplex.bde.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart16990224.mgHh93Ab6g"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701210809.27770.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Subject: Re: slow writes on nfs with bge devices 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, 21 Jan 2007 07:09:45 -0000 --nextPart16990224.mgHh93Ab6g Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 21 January 2007 07:25, Bruce Evans wrote: > nfs writes much less well with bge NICs than with other NICs (sk, fxp, Do you use hardware checksumming on the bge? There is an XXX in=20 bge_start_locked() that looks a bit suspicious to me. > xl, even rl). Sometimes writing a 20K source file from vi seems to > take about 2 seconds instead of seeming to be instantaneous (this gets > faster as the system warms up). Iozone shows the problem more > reproducibly. E.g.: > > 100Mbps fxp server -> 1Gbps bge 5701 client, udp: > %%% > IOZONE: Performance Test of Sequential File I/O -- V1.16 (10/28/92) > By Bill Norcott > > Operating System: FreeBSD -- using fsync() > > IOZONE: auto-test mode > > MB reclen bytes/sec written bytes/sec read > 1 512 1516885 291918639 > 1 1024 1158783 491354263 > 1 2048 1573651 715694105 > 1 4096 1223692 917431957 > 1 8192 729513 1097929467 > 2 512 1694809 281196631 > 2 1024 1379228 507917189 > 2 2048 1659521 789608264 > 2 4096 4606056 1064567574 > 2 8192 1142288 1318131028 > 4 512 1242214 298269971 > 4 1024 1853545 492110628 > 4 2048 2120136 742888430 > 4 4096 1896792 1121799065 > 4 8192 850210 1441812403 > 8 512 1563847 281422325 > 8 1024 1480844 492749552 > 8 2048 1658649 850165954 > 8 4096 2105283 1211348180 > 8 8192 2098425 1554875506 > 16 512 1508821 296842294 > 16 1024 1966239 527850530 > 16 2048 2036609 842656736 > 16 4096 1666138 1200594889 > 16 8192 2293378 1620824908 > Completed series of tests > %%% > > Here bge barely reaches 10Mbps speeds (~1.2 MB/S) for writing. Reading > is cached well and fast. 100Mbps xl on the same client with the same > server goes at full 100Mbps speed (11.77 MB/S for all file sizes > including larger ones since the disk is not the limit at 100Mbps). > 1Gbps sk on a different client with the same server goes at full > 100Nbps speed. > > Switching to tcp gives full 100 Mbps speed. However, when the bge link > speed is reduced to 100Mbps, udp becomes about 10 times slower than the > above and tcp becomes about as slow as the above (maybe a bit faster, > but far below 11.77 MB/S). > > bge is also slow at nfs serving: > > 1Gbps bge 5701 server -> 1Gbps sk client: > %%% > > IOZONE: Performance Test of Sequential File I/O -- V1.16 (10/28/92) > By Bill Norcott > > Operating System: FreeBSD -- using fsync() > > IOZONE: auto-test mode > > MB reclen bytes/sec written bytes/sec read > 1 512 36255350 242114472 > 1 1024 3051699 413319147 > 1 2048 22406458 632021710 > 1 4096 22447700 851162198 > 1 8192 3522493 1047562648 > 2 512 3270779 48125247 > 2 1024 28992179 46693718 > 2 2048 5956380 753318255 > 2 4096 27616650 1053311658 > 2 8192 5573338 48290208 > 4 512 9004770 47435659 > 4 1024 9576276 45601645 > 4 2048 30348874 85116667 > 4 4096 8635673 86150049 > 4 8192 9356773 47100031 > 8 512 9762446 46424146 > 8 1024 10054027 58344604 > 8 2048 9197430 60253061 > 8 4096 15934077 59476759 > 8 8192 8765470 47647937 > 16 512 5670225 46239891 > 16 1024 9425169 45950990 > 16 2048 9833515 46242945 > 16 4096 14812057 51313693 > 16 8192 9203742 47648722 > Completed series of tests > %%% > > Now the available bandwidth is 10 times larger and about 9/10 of it is > still not used, with a high variance. For larger files, the variance > is lower and the average speed is about 10MB/S. The disk can only do > about 40MB/S and the slowest of the 1Gbps NICS (sk) can only sustain > 80MB/S through udp and about 50MB/S through tcp (it is limited by the > 33 MHz 32-bit PCI bus and by being less smart than the bge interface). > When the bge NIC was on the system which is now the server with the fxp > NIC, bge and nfs worked unsurprisingly, just slower than I would have > liked. The write speed was 20-30MB/S for large files and 30-40MB/S for > medium-sized files, with low variance. This is the only configuration > in which nfs/bge worked as expected. > > The problem is very old and not very hardware dependent. Similar > behaviour happens when some of the following are changed: > > OS -> FreeBSD-~5.2 or FreeBSD-6 > hardware -> newer amd64 CPU (Turion X2) with 5705 (iozone output for > this below) instead of old amd64 CPU with 5701. The newer amd64 > normally runs an i386-SMP current kernel while the old amd64 was > running an amd64-UP current kernel in the above tests, but normally > runs ~5.2 amd64-UP and behaves similarly with that. The combination > that seemed to work right was an AthlonXP for the server with the same > 5701 and any kernel. The only strangeness with that was that current > kernels gave a 5-10% slower nfs server despite giving a 30-90% larger > packet rate for small packets. > > IOZONE: Performance Test of Sequential File I/O -- V1.16 (10/28/92) > By Bill Norcott > > Operating System: FreeBSD -- using fsync() > > 100Mbps fxp server -> 1Gbps bge 5705 client: > %%% > IOZONE: auto-test mode > > MB reclen bytes/sec written bytes/sec read > 1 512 2994400 185462027 > 1 1024 3074084 337817536 > 1 2048 2991691 576792985 > 1 4096 3074759 884740798 > 1 8192 3078019 1176892296 > 2 512 4262096 186709962 > 2 1024 2994468 339893080 > 2 2048 5112176 584846610 > 2 4096 4754187 909815165 > 2 8192 5100574 1212919611 > 4 512 5298715 187129017 > 4 1024 5302620 344445041 > 4 2048 4985597 590579630 > 4 4096 3703618 927711124 > 4 8192 5236177 1240896243 > 8 512 5142274 186899396 > 8 1024 6207933 345564808 > 8 2048 6162773 593088329 > 8 4096 6031445 936751120 > 8 8192 6072523 1224102288 > 16 512 5427113 186797193 > 16 1024 5065901 345544445 > 16 2048 5462338 595487384 > 16 4096 5256552 937013065 > 16 8192 5097101 1226320870 > Completed series of tests > %%% > > rl on a system with 1/20 as much CPU is faster than this. > > The problem doesn't seem to affect much besides writes on nfs. The > bge 5701 works very well for most things. It has a much better bus > interface than the 5705 and works even better after moving it to the > old amd64 system (it can now saturate 1Gbps where on the AthlonXP it > only got 3/4 of the way, while the 5705 only gets 1/4 of the way). > I've been working on minimising network latency and maximising packet > rate, and normally have very low network latency (60-80 uS for ping) > and fairly high packet rates. The changes for this are not the caause > of the bug :-), since the behaviour is not affected by running kernels > without these changes or by sysctl''ing the changes to be null.=20 > However, the problem looks like ones caused by large latencies combined > with non-streaming protocols. To write at just 11.77 MB/S, at least > 8000 packets/second must be set from the client to the server. Working > clients sustain this rate, but broken clients the rate is much lower > and not sustained: > > Output from netstat -s 1 on server while writing a ~1GB file via > 5701/udp: %%% > input (Total) output > packets errs bytes packets errs bytes colls > 900 0 1513334 142 0 33532 0 > 1509 0 2564836 236 0 57368 0 > 1647 0 2295802 259 0 51106 0 > 1603 0 1502736 252 0 32926 0 > 1055 0 637014 163 0 13938 0 > 558 0 1542510 86 0 34340 0 > 984 0 989854 155 0 21816 0 > 864 0 1320786 135 0 38152 0 > 883 0 1558060 165 0 34340 0 > 1177 0 3780102 203 0 85850 0 > 2087 0 954212 331 0 21210 0 > 1187 0 1413568 190 0 31310 0 > 650 0 3320604 101 0 75346 0 > 1565 0 1706542 246 0 37976 0 > 2055 0 2360620 329 0 52318 0 > 1554 0 2416996 244 0 54226 0 > 1402 0 2579894 220 0 58176 0 > 1690 0 774488 267 0 16968 0 > 1323 0 3690650 209 0 83830 0 > 591 0 4519858 92 0 103110 0 > %%% > > There is no sign of any packet loss or switch problems. Forcing > 1000baseTX full-duplex has no effect. Forcing 100baseTX full-duplex > makes the problem more obvious. The mtu is 1500 throughout since > only bge-5701 and sk support jumbo frames and I want to use udp for > nfs. > > 5705/udp is better: > %%% > input (Total) output > packets errs bytes packets errs bytes colls > 5209 0 6607758 846 0 151702 0 > 4763 0 6684546 773 0 153520 0 > 4758 0 6618498 769 0 151298 0 > 3582 0 7057568 576 0 162498 0 > 4935 0 5115068 800 0 116756 0 > 4924 0 6622026 798 0 152802 0 > 4095 0 6018462 657 0 137450 0 > 4647 0 5270442 751 0 120594 0 > 4673 0 5451948 758 0 123624 0 > 2340 0 6001986 372 0 138168 0 > 3750 0 6150610 604 0 140996 0 > %%% > > sk/udp works right: > %%% > input (Total) output > packets errs bytes packets errs bytes colls > 8638 0 12384676 1440 0 293062 0 > 8636 0 12415646 1439 0 293708 0 > 8637 0 12415646 1441 0 293708 0 > 8637 0 12415646 1439 0 293708 0 > 8637 0 12417160 1440 0 293708 0 > 8636 0 12413162 1439 0 293506 0 > 8637 0 12414132 1439 0 293708 0 > 8636 0 12417160 1440 0 293708 0 > 8637 0 12415646 1439 0 293708 0 > 8636 0 12417160 1440 0 293708 0 > 8637 0 12414676 1439 0 293506 0 > %%% > > sk is under ~5.2 with latency/throughput/efficiency optimizations > that don't have much effect here. > > Bruce > _______________________________________________ > 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" =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart16990224.mgHh93Ab6g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFsxGnXyyEoT62BG0RAnb8AJwKV9ZihIC9m3XiHwsJLrAcQBa6CQCdHrbD T/L2QEOgFi2qQe5Jte2vKbU= =iMtp -----END PGP SIGNATURE----- --nextPart16990224.mgHh93Ab6g-- From owner-freebsd-net@FreeBSD.ORG Sun Jan 21 08:05:34 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B26B016A400; Sun, 21 Jan 2007 08:05:34 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id 9CD2413C442; Sun, 21 Jan 2007 08:05:33 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 8EAE033C94; Sun, 21 Jan 2007 09:32:44 +0200 (SAST) Date: Sun, 21 Jan 2007 09:32:44 +0200 From: John Hay To: "Bruce A. Mah" Message-ID: <20070121073244.GA80811@zibbi.meraka.csir.co.za> References: <20070120162936.GA18104@tomcat.kitchenlab.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070120162936.GA18104@tomcat.kitchenlab.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-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: Sun, 21 Jan 2007 08:05:34 -0000 On Sat, Jan 20, 2007 at 08:29:36AM -0800, Bruce A. Mah wrote: > I'm observing a problem with IPv6 over gif(4) tunnels on 6.2-RELEASE > and recent 6-STABLE, namely that I can't seem to be able to pass > traffic over them. > > Essentially, when I configure a gif interface like this: > > # ifconfig gif0 inet6 aaaa:bbbb:cccc:dddd::1 aaaa:bbbb:cccc:dddd::2 prefixlen 128 > > the interface should add a host route to aaaa:bbbb:cccc:dddd::2 > through gif0. This is necessary to be able to pass traffic over the > tunnel, particularly since the source and destination addresses of the > link don't need to have any relationship to each other. I only have one IPv6 over IPv4/gif tunnel and ther I use only my side of the address, something like this: ifconfig gif0 inet6 2001:4200:ffff:5::2 prefixlen 64 And then bgp on top of this. It seems to work fine on -current built after my change. > However, this route doesn't get installed on recent 6-STABLE. > Therefore there is no way to get an IPv6 packet to the other end of > the tunnel because there's no route for the destination. The most > obvious symptom is that I try to ping the other tunnel endpoint and > get: > > ping6: UDP connect: No route to host > > I know this worked on RELENG_6 as of June 2006; my home firewall has > been running this code for months without a hitch. It doesn't work in > 6.2-RC2 or 6.2-RELEASE (fresh CD installs on i386, GENERIC kernels), > or this week's RELENG_6 (nanobsd on i386). > > I somewhat suspect revs. 1.48.2.15 and 1.48.2.14 to > src/sys/netinet/nd6.c. If I locally revert these two changes (see > diff below), IPv6 over gif(4) works again. > > There's another workaround for people stuck in this situation and who > aren't in a position to try this diff. That is to manually install > the host route like this: > > # route add -host -inet6 aaaa:bbbb:cccc:dddd::2 -interface gif0 -nostatic -llinfo > > Comments? Well it seems that even my stuff does not always work perfectly with that change (1.48.2.15), so maybe we should revert it and I will search for yet other ways to make FreeBSD's IPv6 code to actually work for our stuff. My "stuff" is a wireless IPv6 only network running in adhoc mode with olsrd as the routing protocol. The problem is that all nodes on a subnet cannot "see" each other, so olsrd needs to add routes to a node through another node. Sometimes, just to complicate matters a little more, you would want to have more than one network card in a host, all with the same subnet address. (For instance on a high site, with sector antennas.) The case that I found that still does not work reliably, is if olsrd add the route and route is not immediately used, then the nd code will time it out and remove it. So, I guess if you guys think I should revert my stuff, just say so. And if you have a solution for my problem, just say so too. :-) > > Bruce. > > Index: nd6.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet6/nd6.c,v > retrieving revision 1.48.2.16 > diff -u -r1.48.2.16 nd6.c > --- nd6.c 29 Nov 2006 14:00:29 -0000 1.48.2.16 > +++ nd6.c 20 Jan 2007 16:15:28 -0000 > @@ -1316,7 +1316,7 @@ > callout_init(&ln->ln_timer_ch, 0); > > /* this is required for "ndp" command. - shin */ > - if (req == RTM_ADD && (rt->rt_flags & RTF_STATIC)) { > + if (req == RTM_ADD) { > /* > * gate should have some valid AF_LINK entry, > * and ln->ln_expire should have some lifetime John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Sun Jan 21 10:53:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9223B16A400 for ; Sun, 21 Jan 2007 10:53:25 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.freebsd.org (Postfix) with ESMTP id 664D313C469 for ; Sun, 21 Jan 2007 10:53:25 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 21 Jan 2007 02:53:25 -0800 X-IronPort-AV: i="4.13,217,1167638400"; d="scan'208"; a="458714517:sNHT44923732" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0LArOlG016243; Sun, 21 Jan 2007 02:53:24 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0LArMUw013828; Sun, 21 Jan 2007 02:53:22 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 Jan 2007 02:53:21 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 Jan 2007 02:53:21 -0800 Message-ID: <45B345FD.7080001@cisco.com> Date: Sun, 21 Jan 2007 05:52:45 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Andrew Gallatin References: <45B0D2E3.9050203@cisco.com> <17841.6943.770698.707214@grasshopper.cs.duke.edu> In-Reply-To: <17841.6943.770698.707214@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2007 10:53:21.0582 (UTC) FILETIME=[5DE9B4E0:01C73D4A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=947; t=1169376804; x=1170240804; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20kern_mbuf.c=20patch |Sender:=20; bh=jK0Xfv0MqZ2fkNObyMBejLj71papNNTcqiK8r1Tc0aE=; b=bJMVakYCrCbOLZJTsMglOaDhVoDbPQkDgPBQMHxnS9XGBoWQ3TPUoBLxo0E+mC6WHH2aUZ2/ 3rDilHgQDYxfC3ZySVi0QVykQu0EDcA6vsxh674e6M9pHvx4TnowB1tN; Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); Cc: freebsd-net Subject: Re: kern_mbuf.c patch 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, 21 Jan 2007 10:53:25 -0000 Andrew Gallatin wrote: > Randall Stewart writes: > > nmbclusters = 1024 + maxusers * 64; > > + nmbjumbop = 100 + (maxusers * 4); > > The limit on page-size jumbos seems far too small. Since the socket > buffer code now uses page-sized jumbos, I'd expect to see its limit be > the same as nmbclusters. > > > Drew > Drew: Let me re-visit this .. I started real small on purpose.. so folks would complain ;-) How about if I calculate the number of pages the nmbclusters use (I will go look in the UMA structures) and then make it so the limit is the same number of pages (scaled like nmbclusters) for each of the larger clusters.. Does that sound about right... (for 4k it would mean you would have 1/2 as many as 2k... roughly.. depending on the o/h of the uma system of course.. need to go look at this). R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Sun Jan 21 12:25:44 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 522B616A402 for ; Sun, 21 Jan 2007 12:25:44 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 1C77B13C45A for ; Sun, 21 Jan 2007 12:25:44 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 826E66E2BF; Sun, 21 Jan 2007 23:25:40 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 002D58C06; Sun, 21 Jan 2007 23:25:41 +1100 (EST) Date: Sun, 21 Jan 2007 23:25:40 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Max Laier In-Reply-To: <200701210809.27770.max@love2party.net> Message-ID: <20070121215054.C24780@delplex.bde.org> References: <20070121155510.C23922@delplex.bde.org> <200701210809.27770.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: slow writes on nfs with bge devices 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, 21 Jan 2007 12:25:44 -0000 On Sun, 21 Jan 2007, Max Laier wrote: > On Sunday 21 January 2007 07:25, Bruce Evans wrote: >> nfs writes much less well with bge NICs than with other NICs (sk, fxp, > > Do you use hardware checksumming on the bge? There is an XXX in > bge_start_locked() that looks a bit suspicious to me. I use the default for that. Wouldn't checksum problems show up as errors somwhere? >>> [excessive quoting deleted] tcpdump shows a lot of intervals between nfs write requests of almost exactly 10 mS (even with HZ = 1000, but more obvious with HZ = 100) for the broken case, so the problem is apparently related to timeouts, or timeouts are masking a larger problem. (The average interval between write requests needs to be about 683 uS to avoid wasting any bandwith. fxp <-> fxp on the same network averages 708 uS. fxp <-> bge 5701 averages 3981.) Bruce From owner-freebsd-net@FreeBSD.ORG Sun Jan 21 19:33:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F5DC16A400 for ; Sun, 21 Jan 2007 19:33:56 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id B9B2F13C455 for ; Sun, 21 Jan 2007 19:33:55 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.6.102] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1H8iRo1z21-0005Fi; Sun, 21 Jan 2007 20:33:54 +0100 From: Max Laier Organization: FreeBSD To: Bruce Evans Date: Sun, 21 Jan 2007 20:32:58 +0100 User-Agent: KMail/1.9.5 References: <20070121155510.C23922@delplex.bde.org> <200701210809.27770.max@love2party.net> <20070121215054.C24780@delplex.bde.org> In-Reply-To: <20070121215054.C24780@delplex.bde.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1595927.pzSa1nX3oL"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701212033.34914.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-net@freebsd.org Subject: Re: slow writes on nfs with bge devices 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, 21 Jan 2007 19:33:56 -0000 --nextPart1595927.pzSa1nX3oL Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 21 January 2007 13:25, Bruce Evans wrote: > On Sun, 21 Jan 2007, Max Laier wrote: > > On Sunday 21 January 2007 07:25, Bruce Evans wrote: > >> nfs writes much less well with bge NICs than with other NICs (sk, > >> fxp, > > > > Do you use hardware checksumming on the bge? There is an XXX in > > bge_start_locked() that looks a bit suspicious to me. > > I use the default for that. Wouldn't checksum problems show up as > errors somwhere? Did you look at the code in question? It is concerned with fragmented=20 packet chains (which NFS over UDP usually generated) and only commits to=20 sending them, if there are enough descriptors available at once. This=20 can easily explain burstyness. Can you just try to disable the delayed checksums via "ifconfig -txcsum"? = =20 Should be an easy enough test. > >>> [excessive quoting deleted] > > tcpdump shows a lot of intervals between nfs write requests of almost > exactly 10 mS (even with HZ =3D 1000, but more obvious with HZ =3D 100) > for the broken case, so the problem is apparently related to timeouts, > or timeouts are masking a larger problem. (The average interval > between write requests needs to be about 683 uS to avoid wasting any > bandwith. fxp <-> fxp on the same network averages 708 uS. fxp <-> bge > 5701 averages 3981.) See above, I really think that there is something about that if_start loop= =20 that might be causing this. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1595927.pzSa1nX3oL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFs8AOXyyEoT62BG0RAhh5AJ9gf9+sPSC4Eur4cxo3Qnm1xPGmFgCdFZn7 yecaaZcGElSbDiPS6zx3USA= =4wpX -----END PGP SIGNATURE----- --nextPart1595927.pzSa1nX3oL-- From owner-freebsd-net@FreeBSD.ORG Sun Jan 21 20:35:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7CA516A401; Sun, 21 Jan 2007 20:35:18 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from springbank.echomania.com (springbank.echomania.com [82.94.255.114]) by mx1.freebsd.org (Postfix) with ESMTP id A1BDA13C455; Sun, 21 Jan 2007 20:35:18 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from localhost (localhost [127.0.0.1]) by springbank.echomania.com (Postfix) with ESMTP id 5EB69A70C0; Sun, 21 Jan 2007 21:17:24 +0100 (CET) Received: from springbank.echomania.com ([127.0.0.1]) by localhost (springbank.echomania.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27582-04-3; Sun, 21 Jan 2007 21:17:23 +0100 (CET) Received: from [192.168.0.3] (tensor.andric.com [213.154.244.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTP id 43474A707D; Sun, 21 Jan 2007 21:17:23 +0100 (CET) Message-ID: <45B3CA56.4040106@andric.com> Date: Sun, 21 Jan 2007 21:17:26 +0100 From: Dimitry Andric User-Agent: Thunderbird 2.0b1 (Windows/20070106) MIME-Version: 1.0 To: "Bruce A. Mah" References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121.020741.59649277.hrs@allbsd.org> <45B251A5.4000209@freebsd.org> In-Reply-To: <45B251A5.4000209@freebsd.org> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at echomania.com Cc: freebsd-net@freebsd.org, Hiroki Sato , freebsd-stable@freebsd.org, jhay@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-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: Sun, 21 Jan 2007 20:35:19 -0000 Bruce A. Mah wrote: >> I remember Dimitry Andric reported the same problem on -stable on 30 >> Dec, and after he reverted rev.1.48.2.16 it worked fine again. Do >> you have the symptom even on 6.2-RELEASE? Since RELENG_6_2_0_RELEASE >> did not have the change, I thought there was no problem. ... > On my 6-STABLE system (which appears to be working fine), I still have > the change from 1.48.2.16, I only backed out .15 and .14. I didn't try > my diff on the 6.2-RC2 and 6.2-RELEASE machines yet. > > Hmmm...I was looking for that bug report before, but I couldn't find it. > It's not clear to me how 1.48.2.16 is involved...hmmm... I originally reported this here: http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031809.html and later I found out it was caused by commit 1.48.2.16: http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.html I'll shoot in a regular PR later tonight... From owner-freebsd-net@FreeBSD.ORG Sun Jan 21 22:10:33 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E52116A4D1 for ; Sun, 21 Jan 2007 22:10:33 +0000 (UTC) (envelope-from wishmaster@velnet.ru) Received: from mail.velnet.ru (mail.velnet.ru [88.210.53.179]) by mx1.freebsd.org (Postfix) with ESMTP id D80A213C455 for ; Sun, 21 Jan 2007 22:10:32 +0000 (UTC) (envelope-from wishmaster@velnet.ru) Received: from [213.141.131.138] (helo=localhost) by mail.velnet.ru with esmtp (Exim 4.30; FreeBSD) id 1H8kzw-0001iY-Vf for freebsd-net@freebsd.org; Mon, 22 Jan 2007 01:17:13 +0300 Date: Mon, 22 Jan 2007 01:09:57 +0300 From: Wishmaster X-Mailer: The Bat! (v2.12.00) X-Priority: 3 (Normal) Message-ID: <1651695163.20070122010957@velnet.ru> To: freebsd-net@freebsd.org In-Reply-To: <45B28F37.7040100@delphij.net> References: <1458229821.20070120234257@velnet.ru> <45B28F37.7040100@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re[2]: reproducible watchdog timeout in bge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Wishmaster List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 22:10:33 -0000 Hello LI, Sunday, January 21, 2007, 12:52:55 AM, you wrote: LX> Wishmaster wrote: >> Hi, >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92090 LX> Have you tried this one? LX> http://people.freebsd.org/~delphij/misc/patch-bge-releng62 LX> Cheers, Yes, i tried, but have no effect. after reboot interface works, but if i try to ping with packet for example 1500 bytes and interval 0.01s it looks like answer answer answer .... ..... over 50 or less icmp answers then ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available in dmesg: bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP -- Best regards, Wishmaster mailto:wishmaster@velnet.ru From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 02:26:41 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21EFF16A400 for ; Mon, 22 Jan 2007 02:26:41 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.freebsd.org (Postfix) with ESMTP id B648D13C457 for ; Mon, 22 Jan 2007 02:26:40 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from [64.142.31.109] (phantom.kitchenlab.org [64.142.31.109]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l0M2QXhK009144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Jan 2007 18:26:39 -0800 Message-ID: <45B420D5.4040903@freebsd.org> Date: Sun, 21 Jan 2007 18:26:29 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: John Hay References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121073244.GA80811@zibbi.meraka.csir.co.za> In-Reply-To: <20070121073244.GA80811@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD15351770AADCEA6312F1D02" Cc: freebsd-net@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-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, 22 Jan 2007 02:26:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD15351770AADCEA6312F1D02 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, John Hay wrote: > On Sat, Jan 20, 2007 at 08:29:36AM -0800, Bruce A. Mah wrote: >> I'm observing a problem with IPv6 over gif(4) tunnels on 6.2-RELEASE >> and recent 6-STABLE, namely that I can't seem to be able to pass >> traffic over them. >> >> Essentially, when I configure a gif interface like this: >> >> # ifconfig gif0 inet6 aaaa:bbbb:cccc:dddd::1 aaaa:bbbb:cccc:dddd::2 pr= efixlen 128 >> >> the interface should add a host route to aaaa:bbbb:cccc:dddd::2 >> through gif0. This is necessary to be able to pass traffic over the >> tunnel, particularly since the source and destination addresses of the= >> link don't need to have any relationship to each other. >=20 > I only have one IPv6 over IPv4/gif tunnel and ther I use only my side > of the address, something like this: >=20 > ifconfig gif0 inet6 2001:4200:ffff:5::2 prefixlen 64 >=20 > And then bgp on top of this. It seems to work fine on -current built > after my change.=20 I believe the difference between your situation and mine is that your gif0 interface is setup with a prefixlen < 128, which doesn't specifically require a host route to the interface of the destination. This is actually handled specially in several parts of the IPv6 stack. > Well it seems that even my stuff does not always work perfectly with th= at > change (1.48.2.15), so maybe we should revert it and I will search for > yet other ways to make FreeBSD's IPv6 code to actually work for our stu= ff. > > My "stuff" is a wireless IPv6 only network running in adhoc mode with > olsrd as the routing protocol. The problem is that all nodes on a subne= t > cannot "see" each other, so olsrd needs to add routes to a node through= > another node. Sometimes, just to complicate matters a little more, you > would want to have more than one network card in a host, all with the s= ame > subnet address. (For instance on a high site, with sector antennas.) >=20 > The case that I found that still does not work reliably, is if olsrd ad= d > the route and route is not immediately used, then the nd code will time= > it out and remove it. >=20 > So, I guess if you guys think I should revert my stuff, just say so. >=20 > And if you have a solution for my problem, just say so too. :-) This sounds kind of interesting! I'm concerned that this bug seems (at least in my testing) to be present in 6.2-RELEASE. I'm not 100% sure what's the right thing to do at this point. Thanks, Bruce. --------------enigD15351770AADCEA6312F1D02 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.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFtCDZ2MoxcVugUsMRAg7+AKDv3pIMZjkW2N5A2LHEkmz8rrWN4ACfXKhz JJ0uwCW8VBWAOoLa8aSKh8E= =/jYq -----END PGP SIGNATURE----- --------------enigD15351770AADCEA6312F1D02-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 02:30:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E68516A400; Mon, 22 Jan 2007 02:30:48 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.freebsd.org (Postfix) with ESMTP id 5377E13C45B; Mon, 22 Jan 2007 02:30:48 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from [64.142.31.109] (phantom.kitchenlab.org [64.142.31.109]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l0M2Ujrf030953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Jan 2007 18:30:45 -0800 Message-ID: <45B421D4.2050008@freebsd.org> Date: Sun, 21 Jan 2007 18:30:44 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Dimitry Andric References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121.020741.59649277.hrs@allbsd.org> <45B251A5.4000209@freebsd.org> <45B3CA56.4040106@andric.com> In-Reply-To: <45B3CA56.4040106@andric.com> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDB6AE63A7FA61973A62DB677" Cc: freebsd-net@freebsd.org, Hiroki Sato , freebsd-stable@freebsd.org, jhay@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-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, 22 Jan 2007 02:30:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDB6AE63A7FA61973A62DB677 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Dimitry Andric wrote: > Bruce A. Mah wrote: >>> I remember Dimitry Andric reported the same problem on -stable on 30= >>> Dec, and after he reverted rev.1.48.2.16 it worked fine again. Do >>> you have the symptom even on 6.2-RELEASE? Since RELENG_6_2_0_RELEAS= E >>> did not have the change, I thought there was no problem. > ... >> On my 6-STABLE system (which appears to be working fine), I still have= >> the change from 1.48.2.16, I only backed out .15 and .14. I didn't tr= y >> my diff on the 6.2-RC2 and 6.2-RELEASE machines yet. >> >> Hmmm...I was looking for that bug report before, but I couldn't find i= t. >> It's not clear to me how 1.48.2.16 is involved...hmmm... >=20 > I originally reported this here: > http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031809.= html >=20 > and later I found out it was caused by commit 1.48.2.16: > http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.= html >=20 > I'll shoot in a regular PR later tonight... Hi Dimitry-- This isn't consistent with what I'm finding. For one thing, rev. 1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there anyways. Also, that's not the change I made to my local sources to get my gif(4) tunnel working. Are you sure about this? :-) Thanks! Bruce. --------------enigDB6AE63A7FA61973A62DB677 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.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFtCHU2MoxcVugUsMRAh2BAJ4ko8DJylWIz8Hv5cME5jThGyvbugCgsoIO o8WDZf7XNeRRO9ibZMwd2IA= =pPCU -----END PGP SIGNATURE----- --------------enigDB6AE63A7FA61973A62DB677-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 03:23:30 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F11316A400 for ; Mon, 22 Jan 2007 03:23:30 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 3727E13C442 for ; Mon, 22 Jan 2007 03:23:30 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id 8E5C46E2E9; Mon, 22 Jan 2007 14:23:26 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id D135227436; Mon, 22 Jan 2007 14:23:27 +1100 (EST) Date: Mon, 22 Jan 2007 14:23:26 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Max Laier In-Reply-To: <200701212033.34914.max@love2party.net> Message-ID: <20070122140144.R7272@besplex.bde.org> References: <20070121155510.C23922@delplex.bde.org> <200701210809.27770.max@love2party.net> <20070121215054.C24780@delplex.bde.org> <200701212033.34914.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: slow writes on nfs with bge devices 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, 22 Jan 2007 03:23:30 -0000 On Sun, 21 Jan 2007, Max Laier wrote: > On Sunday 21 January 2007 13:25, Bruce Evans wrote: >> On Sun, 21 Jan 2007, Max Laier wrote: >>> On Sunday 21 January 2007 07:25, Bruce Evans wrote: >>>> nfs writes much less well with bge NICs than with other NICs (sk, >>>> fxp, >>> >>> Do you use hardware checksumming on the bge? There is an XXX in >>> bge_start_locked() that looks a bit suspicious to me. >> >> I use the default for that. Wouldn't checksum problems show up as >> errors somwhere? > > Did you look at the code in question? It is concerned with fragmented > packet chains (which NFS over UDP usually generated) and only commits to > sending them, if there are enough descriptors available at once. This > can easily explain burstyness. > > Can you just try to disable the delayed checksums via "ifconfig -txcsum"? > Should be an easy enough test. I haven't looked closely at the bge checksum code, but tried turning off checksums (various combinations) yesterday. THis made no difference. >> tcpdump shows a lot of intervals between nfs write requests of almost >> exactly 10 mS (even with HZ = 1000, but more obvious with HZ = 100) >> for the broken case, so the problem is apparently related to timeouts, > > See above, I really think that there is something about that if_start loop > that might be causing this. I have some local changes in this area (much larger ifq length and watermark stuff to reduce tx interrupts). I think they make no difference, but will have to test an unchanged driver more carefully. I assume that the if_start loop always calls the interface if_start if there is something in the ifq and the interface is not marked as active. Bruce From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 07:44:24 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81FD816A401 for ; Mon, 22 Jan 2007 07:44:24 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id B6E0313C45A for ; Mon, 22 Jan 2007 07:44:23 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 208EE6E160; Mon, 22 Jan 2007 18:44:18 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 0C6178C19; Mon, 22 Jan 2007 18:44:17 +1100 (EST) Date: Mon, 22 Jan 2007 18:44:17 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Max Laier In-Reply-To: <20070122140144.R7272@besplex.bde.org> Message-ID: <20070122175630.I7870@besplex.bde.org> References: <20070121155510.C23922@delplex.bde.org> <200701210809.27770.max@love2party.net> <20070121215054.C24780@delplex.bde.org> <200701212033.34914.max@love2party.net> <20070122140144.R7272@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: slow writes on nfs with bge devices 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, 22 Jan 2007 07:44:24 -0000 On Mon, 22 Jan 2007, Bruce Evans wrote: > On Sun, 21 Jan 2007, Max Laier wrote: > >> On Sunday 21 January 2007 13:25, Bruce Evans wrote: >> Can you just try to disable the delayed checksums via "ifconfig -txcsum"? >> Should be an easy enough test. > > I haven't looked closely at the bge checksum code, but tried turning off > checksums (various combinations) yesterday. THis made no difference. (An old version of) tcpdump -vv reported bad checksums if hardware checksumming is on, but I assume that is because it can't see the hardware checksums. >>> tcpdump shows a lot of intervals between nfs write requests of almost >>> exactly 10 mS (even with HZ = 1000, but more obvious with HZ = 100) >>> for the broken case, so the problem is apparently related to timeouts, Driver-level timestamps make this even more obious. >> See above, I really think that there is something about that if_start loop >> that might be causing this. > > I have some local changes in this area (much larger ifq length and > watermark stuff to reduce tx interrupts). I think they make no > difference, but will have to test an unchanged driver more carefully. > I assume that the if_start loop always calls the interface if_start > if there is something in the ifq and the interface is not marked as > active. Tested again with almost pure RELENG_6. There was little difference. Here is some tcpdump output in case you can see the pattern better than me. Testing dd if=/dev/zero of=zz bs=1m count=100: % 16:41:12.410346 IP phiplex.bde.org.1735978418 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x0 % 16:41:12.410349 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.410350 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.410350 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.410351 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.410352 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.410379 IP phiplex.bde.org.1735978419 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x2000 % 16:41:12.410380 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.410381 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.410381 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.410382 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.410383 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.411318 IP besplex.bde.org.nfs > phiplex.bde.org.1735978418: reply ok 160 write [|nfs] This is normal for writing a 16K fs-block. Everything completes in < 1 mS. % 16:41:12.411368 IP phiplex.bde.org.1735978438 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x28000 And the next block is started not more than about 50 uS later. I don't know why the next block is out of order. Possibly related to it being near the first indirect block. % 16:41:12.411369 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.411369 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.411370 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.411371 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.411372 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.411941 IP besplex.bde.org.nfs > phiplex.bde.org.1735978419: reply ok 160 write [|nfs] % 16:41:12.411965 IP phiplex.bde.org.1735978439 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x2a000 % 16:41:12.411966 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.411967 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.411968 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.411969 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.411970 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.412627 IP besplex.bde.org.nfs > phiplex.bde.org.1735978438: reply ok 160 write [|nfs] % ... Things go at full speed with sequential blocks to 0x34000 until here. Then another sequential block: 16:41:12.416820 IP phiplex.bde.org.1735978446 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x38000 % 16:41:12.416821 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.416822 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.416823 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.416823 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.416824 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.417486 IP besplex.bde.org.nfs > phiplex.bde.org.1735978445: reply ok 160 write [|nfs] % 16:41:12.417506 IP phiplex.bde.org.1735978447 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x3a000 % 16:41:12.417507 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.417508 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.417509 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.417509 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.417510 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.417881 IP phiplex.bde.org.1735978420 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x4000 But before the reply for 0x38000, it got back to sending the second 16K-block. Still no speed problems. % 16:41:12.417882 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.417882 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.416820 IP phiplex.bde.org.1735978446 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x38000 % 16:41:12.417883 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.417884 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.417885 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.418187 IP besplex.bde.org.nfs > phiplex.bde.org.1735978446: reply ok 160 write [|nfs] % 16:41:12.418209 IP phiplex.bde.org.1735978448 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x3c000 % 16:41:12.418210 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.418211 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.418211 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.418212 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.418213 IP phiplex.bde.org > besplex.bde.org: udp Stalled here. Stalls seem to be related to out of order delivery. % 16:41:12.492327 IP besplex.bde.org.822 > phiplex.bde.org.login: . ack 151 win 33304 % 16:41:12.667862 IP phiplex.bde.org.1735978447 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x3a000 Now it's retrying 0x3a000. % 16:41:12.667863 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.667864 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.667864 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.667865 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.667866 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.668731 IP besplex.bde.org.nfs > phiplex.bde.org.1735978447: reply ok 160 write [|nfs] % 16:41:12.668754 IP phiplex.bde.org.1735978449 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x3e000 % 16:41:12.668755 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.668755 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.668756 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.668757 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.668758 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.669650 IP besplex.bde.org.nfs > phiplex.bde.org.1735978449: reply ok 160 write [|nfs] % ... Then it got to here with only relatively minor glitches: % 16:41:12.947085 IP phiplex.bde.org.1735978781 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x2d6000 % 16:41:12.947086 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.947087 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.947088 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.947089 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.947090 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.947861 IP phiplex.bde.org.1735978421 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x6000 It's having problems writing 0x6000. This is a retry. Just for unreported packet loss? Perhaps my switch or cable is the problem. % 16:41:12.947862 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.947862 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.947863 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.947864 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.947865 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.947956 IP besplex.bde.org.nfs > phiplex.bde.org.1735978781: reply ok 160 write [|nfs] % 16:41:12.948739 IP besplex.bde.org.nfs > phiplex.bde.org.1735978421: reply ok 160 write [|nfs] Now it has reached a state in which it ony tries to send 1 packet ever 10 mS. 10 mS is nfsclient's default tick interval. % 16:41:12.957853 IP phiplex.bde.org.1735978422 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x8000 % 16:41:12.957854 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.957855 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.957856 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.957857 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.957857 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.958723 IP besplex.bde.org.nfs > phiplex.bde.org.1735978422: reply ok 160 write [|nfs] % 16:41:12.967851 IP phiplex.bde.org.1735978424 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0xc000 % 16:41:12.967852 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.967853 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.967854 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.967854 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.967855 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.968802 IP besplex.bde.org.nfs > phiplex.bde.org.1735978424: reply ok 160 write [|nfs] In fact, it is (re?)trying most of the old blocks that were out of order after the first block. It's not even sending one fs-block per 10 mS, only one nfs-block = half of an fs-block. % 16:41:12.977862 IP phiplex.bde.org.1735978425 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0xe000 % 16:41:12.977863 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.977864 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.977864 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.977865 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.977866 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.978714 IP besplex.bde.org.nfs > phiplex.bde.org.1735978425: reply ok 160 write [|nfs] % 16:41:12.987850 IP phiplex.bde.org.1735978511 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0xba000 % 16:41:12.987851 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.987852 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.987853 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.987854 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.987855 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.988724 IP besplex.bde.org.nfs > phiplex.bde.org.1735978511: reply ok 160 write [|nfs] This is out of order but still spaced at 10 mS. % 16:41:12.997848 IP phiplex.bde.org.1735978427 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x12000 % 16:41:12.997849 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.997850 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.997850 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.997851 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.997852 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:12.998715 IP besplex.bde.org.nfs > phiplex.bde.org.1735978427: reply ok 160 write [|nfs] Back to early blocks. % 16:41:13.007849 IP phiplex.bde.org.1735978536 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0xec000 % 16:41:13.007850 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.007851 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.007852 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.007853 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.007854 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.008722 IP besplex.bde.org.nfs > phiplex.bde.org.1735978536: reply ok 160 write [|nfs] % 16:41:13.017847 IP phiplex.bde.org.1735978430 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x18000 % 16:41:13.017848 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.017849 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.017850 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.017851 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.017852 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.018715 IP besplex.bde.org.nfs > phiplex.bde.org.1735978430: reply ok 160 write [|nfs] % 16:41:13.027846 IP phiplex.bde.org.1735978561 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x11e000 % 16:41:13.027847 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.027848 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.027849 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.027850 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.027850 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.028723 IP besplex.bde.org.nfs > phiplex.bde.org.1735978561: reply ok 160 write [|nfs] % 16:41:13.037846 IP phiplex.bde.org.1735978594 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x160000 % 16:41:13.037847 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.037848 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.037849 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.037849 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.037850 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.038718 IP besplex.bde.org.nfs > phiplex.bde.org.1735978594: reply ok 160 write [|nfs] % 16:41:13.047845 IP phiplex.bde.org.1735978432 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x1c000 % 16:41:13.047846 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.047846 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.047847 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.047848 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.047849 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.048717 IP besplex.bde.org.nfs > phiplex.bde.org.1735978432: reply ok 160 write [|nfs] % 16:41:13.067845 IP phiplex.bde.org.1735978434 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x20000 % 16:41:13.067846 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.067847 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.067848 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.067848 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.067849 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.068712 IP besplex.bde.org.nfs > phiplex.bde.org.1735978434: reply ok 160 write [|nfs] 20 mS interval before above. % 16:41:13.077847 IP phiplex.bde.org.1735978619 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x192000 % 16:41:13.077849 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.077849 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.077850 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.077851 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.077852 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.078723 IP besplex.bde.org.nfs > phiplex.bde.org.1735978619: reply ok 160 write [|nfs] % 16:41:13.097842 IP phiplex.bde.org.1735978666 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x1f0000 % 16:41:13.097843 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.097844 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.097844 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.097845 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.097846 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.098713 IP besplex.bde.org.nfs > phiplex.bde.org.1735978666: reply ok 160 write [|nfs] % 16:41:13.107841 IP phiplex.bde.org.1735978436 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x24000 % 16:41:13.107842 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.107843 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.107844 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.107845 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.107846 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.108712 IP besplex.bde.org.nfs > phiplex.bde.org.1735978436: reply ok 160 write [|nfs] Even more 20 mS intervals. % 16:41:13.137840 IP phiplex.bde.org.1735978715 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x252000 % 16:41:13.137841 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.137842 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.137842 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.137843 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.137844 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.138712 IP besplex.bde.org.nfs > phiplex.bde.org.1735978715: reply ok 160 write [|nfs] 30 mS. % 16:41:13.147839 IP phiplex.bde.org.1735978473 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x6e000 % 16:41:13.147840 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.147841 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.147842 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.147843 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.147843 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.148709 IP besplex.bde.org.nfs > phiplex.bde.org.1735978473: reply ok 160 write [|nfs] 10 mS. % 16:41:13.177841 IP phiplex.bde.org.1735978763 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x2b2000 % 16:41:13.180371 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.180372 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.180372 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.180373 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.180374 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.181243 IP besplex.bde.org.nfs > phiplex.bde.org.1735978763: reply ok 160 write [|nfs] 30 mS. % 16:41:13.181270 IP phiplex.bde.org.1735978800 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x2fc000 % 16:41:13.181271 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.181272 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.181273 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.181274 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.181274 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.182194 IP besplex.bde.org.nfs > phiplex.bde.org.1735978800: reply ok 160 write [|nfs] % 16:41:13.182216 IP phiplex.bde.org.1735978801 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x2fe000 % 16:41:13.182217 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.182218 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.182219 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.182220 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.182221 IP phiplex.bde.org > besplex.bde.org: udp % 16:41:13.183070 IP besplex.bde.org.nfs > phiplex.bde.org.1735978801: reply ok 160 write [|nfs] Back to normal. Is this just what happens when nfs/udp loses packets? nfs/tcp may be better only because it has better retry algorthms. Bruce From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 10:16:51 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96D2F16A400; Mon, 22 Jan 2007 10:16:51 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from springbank.echomania.com (springbank.echomania.com [82.94.255.114]) by mx1.freebsd.org (Postfix) with ESMTP id 524A813C465; Mon, 22 Jan 2007 10:16:51 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from localhost (localhost [127.0.0.1]) by springbank.echomania.com (Postfix) with ESMTP id 97DA7A713D; Mon, 22 Jan 2007 11:16:49 +0100 (CET) Received: from springbank.echomania.com ([127.0.0.1]) by localhost (springbank.echomania.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16238-01; Mon, 22 Jan 2007 11:16:45 +0100 (CET) Received: from [192.168.0.3] (tensor.andric.com [213.154.244.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTP id 3E8A2A70C0; Mon, 22 Jan 2007 11:16:45 +0100 (CET) Message-ID: <45B48F0C.9090809@andric.com> Date: Mon, 22 Jan 2007 11:16:44 +0100 From: Dimitry Andric User-Agent: Thunderbird 2.0b1 (Windows/20070106) MIME-Version: 1.0 To: "Bruce A. Mah" References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121.020741.59649277.hrs@allbsd.org> <45B251A5.4000209@freebsd.org> <45B3CA56.4040106@andric.com> <45B421D4.2050008@freebsd.org> In-Reply-To: <45B421D4.2050008@freebsd.org> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at echomania.com Cc: freebsd-net@freebsd.org, Hiroki Sato , freebsd-stable@freebsd.org, jhay@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-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, 22 Jan 2007 10:16:51 -0000 Bruce A. Mah wrote: >> and later I found out it was caused by commit 1.48.2.16: >> http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.html > > This isn't consistent with what I'm finding. For one thing, rev. > 1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there > anyways. Also, that's not the change I made to my local sources to get > my gif(4) tunnel working. Are you sure about this? :-) I'm following -STABLE, and 1.48.2.16 is in there. Since it was committed on 29 Nov, I suspected it would end up in -RELEASE, but apparently not. :) I explicitly tried reverting just this one commit, and for me it solved the problem (i.e. the automagical addition of needed routing entries). So for you, reverting the combination of 1.48.2.14 and .15 works? Maybe there is something else involved too, for example the route command itself? I'll have to experiment a bit further, I guess. From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 10:50:54 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E91E16A402 for ; Mon, 22 Jan 2007 10:50:54 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id B298413C44B for ; Mon, 22 Jan 2007 10:50:53 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id 62B735A04D4; Mon, 22 Jan 2007 21:50:52 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 256E627403; Mon, 22 Jan 2007 21:50:51 +1100 (EST) Date: Mon, 22 Jan 2007 21:50:49 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Max Laier In-Reply-To: <20070122175630.I7870@besplex.bde.org> Message-ID: <20070122211609.M28527@delplex.bde.org> References: <20070121155510.C23922@delplex.bde.org> <200701210809.27770.max@love2party.net> <20070121215054.C24780@delplex.bde.org> <200701212033.34914.max@love2party.net> <20070122140144.R7272@besplex.bde.org> <20070122175630.I7870@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: slow writes on nfs with bge devices 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, 22 Jan 2007 10:50:54 -0000 On Mon, 22 Jan 2007, Bruce Evans wrote: > % ... > > Then it got to here with only relatively minor glitches: > > % 16:41:12.947085 IP phiplex.bde.org.1735978781 > besplex.bde.org.nfs: 1472 > write fh 1028,575312/94220 8192 bytes @ 0x2d6000 > % 16:41:12.947086 IP phiplex.bde.org > besplex.bde.org: udp > % 16:41:12.947087 IP phiplex.bde.org > besplex.bde.org: udp > % 16:41:12.947088 IP phiplex.bde.org > besplex.bde.org: udp > % 16:41:12.947089 IP phiplex.bde.org > besplex.bde.org: udp > % 16:41:12.947090 IP phiplex.bde.org > besplex.bde.org: udp > % 16:41:12.947861 IP phiplex.bde.org.1735978421 > besplex.bde.org.nfs: 1472 > write fh 1028,575312/94220 8192 bytes @ 0x6000 > > It's having problems writing 0x6000. This is a retry. Just for unreported > packet loss? Perhaps my switch or cable is the problem. Nevermind / 2. The switch or cable certain has problems. The only problem in FreeBSD or the bge driver, if any, may be that errors are not detected except as completely lost packets. Swapping cables gives the following strange behaviours: - fxp <-> bge (5705) works perfectly (at only 100 MBps of course) with a direct link (11.83e6 B/S), but not through the switch (cheap 1Gbps switch). - fxp <-> bge (5701) works better with a direct link, but imperfectly with the same cables that work for the 5705. nfs write speed increases from ~1 MB/S to ~8 MB/S. The link is autonegotiated correctly as 100baseTX full-duplex. With this configuration, errors seem to be detected correctly. nfs writes cause input errors (fxp -> bge at a an almost constant rate of almost exactly 1 per 500 packets. (500 may be significant since it the bge rx ring sizes is 512.) - on reconnecting the 5701 through the switch, no errors were detected when the link is autonegotited to 1000BaseTX full-duplex, but when it is manually configured to 100baseTX full-duplex, some input errors but at a highly variable rate not nearly as many as high 1 in 500. A few packet blasting tests on the 5701 didn't cause any input errors at 100baseTX. I haven't figured out the type of the input errors. No output errors were reported for any of this. - when the 5701 was in the server, exhaustive packet blasting tests at 1000basetX caused a large number of input errors whenever the rx interrupt moderation was configured to just a little more aggressively than the default, in condtions where the tx is very active. (The rx ring is supposed to have size 512, but had an effective size of only 20 under tx load, apparently due to misconfiguration of contention with tx resources.) Packets were just dropped on input. Bruce From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 11:08:40 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B958B16A547 for ; Mon, 22 Jan 2007 11:08:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id A879D13C461 for ; Mon, 22 Jan 2007 11:08:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l0MB8eKc037002 for ; Mon, 22 Jan 2007 11:08:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l0MB8dIb036998 for freebsd-net@FreeBSD.org; Mon, 22 Jan 2007 11:08:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Jan 2007 11:08:39 GMT Message-Id: <200701221108.l0MB8dIb036998@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 11:08:40 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit o kern/106722 net [net] [patch] ifconfig may not connect an interface to 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/106999 net [netgraph] [patch] ng_ksocket fails to clear multicast 10 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 12:59:42 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2C3216A401 for ; Mon, 22 Jan 2007 12:59:42 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6EADC13C428 for ; Mon, 22 Jan 2007 12:59:42 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so546940nzh for ; Mon, 22 Jan 2007 04:59:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ddEXZIXfSXMlvb85jYa2kBeLtI7hgBTLo4hj/qRCCJ4seJByIhNPF691ZWIqC4zEL5T+SvJ+mJ0qf28j5kcZ7figNoshSA5paglJyLufhhNWjjOJcG2snoOxoB/PYjxNz/VRFOn9gMkdSMSbnIKjVKAkkKWq4YPwxqXbA/HDzFE= Received: by 10.35.93.1 with SMTP id v1mr10412643pyl.1169469113061; Mon, 22 Jan 2007 04:31:53 -0800 (PST) Received: by 10.35.60.19 with HTTP; Mon, 22 Jan 2007 04:31:52 -0800 (PST) Message-ID: Date: Mon, 22 Jan 2007 20:31:52 +0800 From: MQ To: Wishmaster In-Reply-To: <1651695163.20070122010957@velnet.ru> MIME-Version: 1.0 References: <1458229821.20070120234257@velnet.ru> <45B28F37.7040100@delphij.net> <1651695163.20070122010957@velnet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Re[2]: reproducible watchdog timeout in bge 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, 22 Jan 2007 12:59:42 -0000 2007/1/22, Wishmaster : > > Hello LI, > > Sunday, January 21, 2007, 12:52:55 AM, you wrote: > > LX> Wishmaster wrote: > >> Hi, > >> > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92090 > > LX> Have you tried this one? > > LX> http://people.freebsd.org/~delphij/misc/patch-bge-releng62 > > LX> Cheers, > > Yes, i tried, but have no effect. > > after reboot interface works, but if i try to ping with packet for > example 1500 bytes and interval 0.01s it looks like > > answer > answer > answer > .... > ..... over 50 or less icmp answers then > ping: sendto: No buffer space available > ping: sendto: No buffer space available > ping: sendto: No buffer space available > ping: sendto: No buffer space available > ping: sendto: No buffer space available > ping: sendto: No buffer space available > ping: sendto: No buffer space available > > in dmesg: > bge0: watchdog timeout -- resetting > bge0: link state changed to DOWN > bge0: link state changed to UP > > -- > Best regards, > Wishmaster mailto:wishmaster@velnet.ru > > > _______________________________________________ > 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 > What about other NIC chips from Broadcom? And how about the packets other than icmp under the same load? From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 13:57:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA00B16A507 for ; Mon, 22 Jan 2007 13:57:03 +0000 (UTC) (envelope-from lists@qwirky.net) Received: from public.aci.on.ca (aci.on.ca [205.207.148.251]) by mx1.freebsd.org (Postfix) with ESMTP id 7C26013C428 for ; Mon, 22 Jan 2007 13:57:03 +0000 (UTC) (envelope-from lists@qwirky.net) Received: from (invalid client hostname: host address literal does not match remote client address)[127.0.0.1] (xtreme-156-171.dyn.aci.on.ca[69.17.156.171] port=1086) by public.aci.on.ca([205.207.148.252] port=25) via TCP with esmtp (3162 bytes) (sender: ) id for ; Mon, 22 Jan 2007 08:39:20 -0500 (EST) (Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2006-Feb-21) Message-ID: <45B4BE90.20602@qwirky.net> Date: Mon, 22 Jan 2007 08:39:28 -0500 From: Jeff Royle User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <1458229821.20070120234257@velnet.ru> <45B28F37.7040100@delphij.net> <1651695163.20070122010957@velnet.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0704-1, 22/01/2007), Outbound message X-Antivirus-Status: Clean Subject: Re: reproducible watchdog timeout in bge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@qwirky.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 13:57:03 -0000 MQ wrote: > 2007/1/22, Wishmaster : >> >> Hello LI, >> >> Sunday, January 21, 2007, 12:52:55 AM, you wrote: >> >> LX> Wishmaster wrote: >> >> Hi, >> >> >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92090 >> >> LX> Have you tried this one? >> >> LX> http://people.freebsd.org/~delphij/misc/patch-bge-releng62 >> >> LX> Cheers, >> >> Yes, i tried, but have no effect. >> >> after reboot interface works, but if i try to ping with packet for >> example 1500 bytes and interval 0.01s it looks like >> >> answer >> answer >> answer >> .... >> ..... over 50 or less icmp answers then >> ping: sendto: No buffer space available >> ping: sendto: No buffer space available >> ping: sendto: No buffer space available >> ping: sendto: No buffer space available >> ping: sendto: No buffer space available >> ping: sendto: No buffer space available >> ping: sendto: No buffer space available >> >> in dmesg: >> bge0: watchdog timeout -- resetting >> bge0: link state changed to DOWN >> bge0: link state changed to UP >> >> -- >> Best regards, >> Wishmaster mailto:wishmaster@velnet.ru >> > > What about other NIC chips from Broadcom? And how about the packets other > than icmp under the same load? > _______________________________________________ I have been unable to produce time outs with my current setup in 6.2-Release. bge0@pci3:0:0: class=0x020000 card=0x81491043 chip=0x165914e4 rev=0x11 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express' class = network subclass = ethernet Reading the PR, I attempted triggering this through CVSing and through the above mentioned ping tests. So far nothing. The only issue I have seen using these NICs in 6.2R is if I nail up the NIC at 100baseTX full-duplex I sometimes loose connectivity. Nothing in the logs indicate watchdog timeouts or any other issue. I simply brought the NIC back down to auto-neg and all seems fine. I am assuming this is a incompatibility between the BGE and my switch, RS8000. I have a Asus P5MT-S with dual BGE NIC's Cheers, Jeff From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 14:31:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9C1616A400 for ; Mon, 22 Jan 2007 14:31:22 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 6EDB713C448 for ; Mon, 22 Jan 2007 14:31:22 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id l0MEVKc2016612 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 22 Jan 2007 09:31:20 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l0MEVJRg002591; Mon, 22 Jan 2007 09:31:19 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17844.51894.773943.99076@grasshopper.cs.duke.edu> Date: Mon, 22 Jan 2007 09:31:18 -0500 (EST) To: Randall Stewart In-Reply-To: <45B345FD.7080001@cisco.com> References: <45B0D2E3.9050203@cisco.com> <17841.6943.770698.707214@grasshopper.cs.duke.edu> <45B345FD.7080001@cisco.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-net Subject: Re: kern_mbuf.c patch 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, 22 Jan 2007 14:31:22 -0000 Randall Stewart writes: > Andrew Gallatin wrote: > > Randall Stewart writes: > > > nmbclusters = 1024 + maxusers * 64; > > > + nmbjumbop = 100 + (maxusers * 4); > > > > The limit on page-size jumbos seems far too small. Since the socket > > buffer code now uses page-sized jumbos, I'd expect to see its limit be > > the same as nmbclusters. > > > > > > Drew > > > Drew: > > Let me re-visit this .. I started real small on purpose.. so > folks would complain ;-) > > How about if I calculate the number of pages the > nmbclusters use (I will go look in the UMA structures) and > then make it so the limit is the same number of pages > (scaled like nmbclusters) for each of the larger clusters.. That sounds reasonable to me, at least for nmbjumbop, but I'm not sure that the larger 9k and 16k clusters are used outside of drivers, so the nmbclusters limit may be too large for them. But I suppose some limit is better than none :) Drew From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 19:25:49 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAC7A16A401 for ; Mon, 22 Jan 2007 19:25:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outX.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id CEF1C13C4B7 for ; Mon, 22 Jan 2007 19:25:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 22 Jan 2007 10:51:07 -0800 Received: from [10.251.23.190] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 9369D125B5D; Mon, 22 Jan 2007 11:11:24 -0800 (PST) Message-ID: <45B50C5B.2080600@elischer.org> Date: Mon, 22 Jan 2007 11:11:23 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Steve Watt References: <200701221546.l0MFk27m081898@wattres.watt.com> In-Reply-To: <200701221546.l0MFk27m081898@wattres.watt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: andre@freebsd.org, Uwe Doering , net@freebsd.org Subject: Re: Interesting TCP issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 19:25:50 -0000 Steve Watt wrote: > On Jan 22, 9:15, Uwe Doering wrote: > } Subject: Re: Interesting TCP issue > } Steve Watt wrote: > } > In <459AD141.5010502@elischer.org>, Julian Elischer wrote: > } > > } > [ Snip discussion of symptoms of window scaling broken when > } > talking to at least the skype mail servers. ] > } > > } >> we have seen this since 4.x > } >> I think a fix may be in 7.0 but I'm not sure.. > } >> I thin kthere is a problem when the far end sets the window down to 1 > } >> but scales it by a factor of 2^{big number}. > } >> > } >> Andre, can you check out this problem and MFC the correct fix > } >> if it is indeed the same problem in 6.2? > } > > } > It is the same problem; I took the (one-line) fix as indicated by > } > > } >> http://cvs.ironport.com/cgi-bin/viewcvs.cgi/freebsd/src/sys/netinet/tcp_syncache.c.diff?r1=1.84&r2=1.85 > } > > } > (well, not cvs.ironport.com, which doesn't seem to exist at the moment), > } > and applied the diff from 1.84 to > } > 1.85 and to a 6.2-PRERELEASE box updated around 25 Dec 06. > } > It works like a charm. > } > > } > I would vote to MFC 1.85 now that 6.2 is out. > } > } I wonder whether it is that easy. As far as I can tell the commit to > } HEAD actually comprised changes to three files: > > I wonder as well, but that single diff fixes the problem I was running > into with the skype mail servers. > > } http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c.diff?r1=1.290&r2=1.291 > } http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_syncache.c.diff?r1=1.84&r2=1.85 > } http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h.diff?r1=1.127&r2=1.128 > } > } How about the modifications in 'tcp_input.c'? Are they relevant to the > } problem this thread is about? If so, assessing the correctness of an > } MFC might prove to be a little harder. That's why I asked Andre to look at it but he's not responding.. > > Looking at it, yeah, those probably need to be picked up in some form as > well. I didn't look closely at the tcpdump after, only observing that > it worked where it didn't before. > > Hmm. > From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 19:38:13 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 051D216A400 for ; Mon, 22 Jan 2007 19:38:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outN.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id E1F3313C4BD for ; Mon, 22 Jan 2007 19:38:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 22 Jan 2007 11:17:52 -0800 Received: from [10.251.23.190] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 32681125B9C; Mon, 22 Jan 2007 11:38:10 -0800 (PST) Message-ID: <45B512A0.5030502@elischer.org> Date: Mon, 22 Jan 2007 11:38:08 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Andre Oppermann References: <200701221546.l0MFk27m081898@wattres.watt.com> <45B50C5B.2080600@elischer.org> <45B50D87.2050208@freebsd.org> In-Reply-To: <45B50D87.2050208@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Steve Watt , Uwe Doering , net@freebsd.org Subject: Re: Interesting TCP issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 19:38:13 -0000 Andre Oppermann wrote: >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c.diff?r1=1.290&r2=1.291 >>> >>> } >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_syncache.c.diff?r1=1.84&r2=1.85 >>> >>> } >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h.diff?r1=1.127&r2=1.128 >>> >>> } } How about the modifications in 'tcp_input.c'? Are they relevant >>> to the } problem this thread is about? If so, assessing the >>> correctness of an } MFC might prove to be a little harder. >> >> >> >> That's why I asked Andre to look at it but he's not responding.. > > He's about to re-appear @freebsd. > great.. The TCP code is a bit like a house of cards.. Unless one is up-to-date and has it all 'loaded' into one's mental cache, it is all to easy to screw up function A by fixing code related to function B. As I'm not 'loaded' I'm loathe to just MFC the one patch without being sure what the other two are.. BTW Andre you might MFC to back to 5 and 4 too if you could.. Julian From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 19:43:07 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2493416A409 for ; Mon, 22 Jan 2007 19:43:07 +0000 (UTC) (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 8A73313C4A5 for ; Mon, 22 Jan 2007 19:43:06 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 84175 invoked from network); 22 Jan 2007 18:56:12 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Jan 2007 18:56:12 -0000 Message-ID: <45B50D87.2050208@freebsd.org> Date: Mon, 22 Jan 2007 20:16:23 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Julian Elischer References: <200701221546.l0MFk27m081898@wattres.watt.com> <45B50C5B.2080600@elischer.org> In-Reply-To: <45B50C5B.2080600@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Steve Watt , Uwe Doering , net@freebsd.org Subject: Re: Interesting TCP issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 19:43:07 -0000 Julian Elischer wrote: > Steve Watt wrote: >> On Jan 22, 9:15, Uwe Doering wrote: >> } Subject: Re: Interesting TCP issue >> } Steve Watt wrote: >> } > In <459AD141.5010502@elischer.org>, Julian Elischer wrote: >> } > } > [ Snip discussion of symptoms of window scaling broken when >> } > talking to at least the skype mail servers. ] >> } > } >> we have seen this since 4.x >> } >> I think a fix may be in 7.0 but I'm not sure.. >> } >> I thin kthere is a problem when the far end sets the window down >> to 1 } >> but scales it by a factor of 2^{big number}. >> } >> >> } >> Andre, can you check out this problem and MFC the correct fix >> } >> if it is indeed the same problem in 6.2? >> } > } > It is the same problem; I took the (one-line) fix as indicated by >> } > } >> >> http://cvs.ironport.com/cgi-bin/viewcvs.cgi/freebsd/src/sys/netinet/tcp_syncache.c.diff?r1=1.84&r2=1.85 >> >> } > } > (well, not cvs.ironport.com, which doesn't seem to exist at >> the moment), >> } > and applied the diff from 1.84 to >> } > 1.85 and to a 6.2-PRERELEASE box updated around 25 Dec 06. >> } > It works like a charm. >> } > } > I would vote to MFC 1.85 now that 6.2 is out. >> } } I wonder whether it is that easy. As far as I can tell the commit >> to } HEAD actually comprised changes to three files: >> >> I wonder as well, but that single diff fixes the problem I was running >> into with the skype mail servers. >> >> } >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c.diff?r1=1.290&r2=1.291 >> >> } >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_syncache.c.diff?r1=1.84&r2=1.85 >> >> } >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h.diff?r1=1.127&r2=1.128 >> >> } } How about the modifications in 'tcp_input.c'? Are they relevant >> to the } problem this thread is about? If so, assessing the >> correctness of an } MFC might prove to be a little harder. > > > > That's why I asked Andre to look at it but he's not responding.. He's about to re-appear @freebsd. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 19:43:17 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E15216A40F for ; Mon, 22 Jan 2007 19:43:17 +0000 (UTC) (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 E737513C4A5 for ; Mon, 22 Jan 2007 19:43:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 84481 invoked from network); 22 Jan 2007 19:23:03 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Jan 2007 19:23:03 -0000 Message-ID: <45B513D2.2060602@freebsd.org> Date: Mon, 22 Jan 2007 20:43:14 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Julian Elischer References: <200701221546.l0MFk27m081898@wattres.watt.com> <45B50C5B.2080600@elischer.org> <45B50D87.2050208@freebsd.org> <45B512A0.5030502@elischer.org> In-Reply-To: <45B512A0.5030502@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Steve Watt , Uwe Doering , net@freebsd.org Subject: Re: Interesting TCP issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 19:43:17 -0000 Julian Elischer wrote: > Andre Oppermann wrote: > >>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c.diff?r1=1.290&r2=1.291 >>>> >>>> } >>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_syncache.c.diff?r1=1.84&r2=1.85 >>>> >>>> } >>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h.diff?r1=1.127&r2=1.128 >>>> >>>> } } How about the modifications in 'tcp_input.c'? Are they relevant >>>> to the } problem this thread is about? If so, assessing the >>>> correctness of an } MFC might prove to be a little harder. >>> >>> >>> >>> That's why I asked Andre to look at it but he's not responding.. >> >> He's about to re-appear @freebsd. >> > > great.. The TCP code is a bit like a house of cards.. Unless one is > up-to-date and has it all 'loaded' into one's mental cache, it is > all to easy to screw up function A by fixing code related to function B. > As I'm not 'loaded' I'm loathe to just MFC the one patch without being > sure what the other two are.. Yes, it's a bit messy and there are many side effects. I've cleaned up some parts in my local tree but it's a tedious task because it's so inter- mingled all over. > BTW Andre you might MFC to back to 5 and 4 too if you could.. Will look at it. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 23:06:53 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 129C016A400 for ; Mon, 22 Jan 2007 23:06:53 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.freebsd.org (Postfix) with ESMTP id E32E513C448 for ; Mon, 22 Jan 2007 23:06:52 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 22 Jan 2007 15:06:52 -0800 X-IronPort-AV: i="4.13,221,1167638400"; d="scan'208"; a="104318098:sNHT44223822" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0MN6qNO006785; Mon, 22 Jan 2007 15:06:52 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0MN6nVG029498; Mon, 22 Jan 2007 15:06:52 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 15:06:51 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 15:06:51 -0800 Message-ID: <45B5436B.7090502@cisco.com> Date: Mon, 22 Jan 2007 18:06:19 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Andrew Gallatin References: <45B0D2E3.9050203@cisco.com> <17841.6943.770698.707214@grasshopper.cs.duke.edu> <45B345FD.7080001@cisco.com> <17844.51894.773943.99076@grasshopper.cs.duke.edu> In-Reply-To: <17844.51894.773943.99076@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jan 2007 23:06:51.0842 (UTC) FILETIME=[007C3220:01C73E7A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1278; t=1169507212; x=1170371212; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20kern_mbuf.c=20patch |Sender:=20; bh=DVqfuhElcksGwVPhjg64A63i70d40KsBjkMfuUJWl+0=; b=sXNodZh4phZBitj0K+u/g3JjLlFX94wjrMt7IZwzeKifFrH6m70PhFamEDvdrtHjIHnnG6iH fnq+OWqE6MaQR4q2VURAIDTNPvEUdcC/z+YM6ip4rIdPPJmneWusT6sD; Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); Cc: freebsd-net Subject: Re: kern_mbuf.c patch 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, 22 Jan 2007 23:06:53 -0000 Andrew Gallatin wrote: > Randall Stewart writes: > > Andrew Gallatin wrote: > > > Randall Stewart writes: > > > > nmbclusters = 1024 + maxusers * 64; > > > > + nmbjumbop = 100 + (maxusers * 4); > > > > > > The limit on page-size jumbos seems far too small. Since the socket > > > buffer code now uses page-sized jumbos, I'd expect to see its limit be > > > the same as nmbclusters. > > > > > > > > > Drew > > > > > Drew: > > > > Let me re-visit this .. I started real small on purpose.. so > > folks would complain ;-) > > > > How about if I calculate the number of pages the > > nmbclusters use (I will go look in the UMA structures) and > > then make it so the limit is the same number of pages > > (scaled like nmbclusters) for each of the larger clusters.. > > That sounds reasonable to me, at least for nmbjumbop, but I'm not sure > that the larger 9k and 16k clusters are used outside of drivers, so > the nmbclusters limit may be too large for them. But I suppose some > limit is better than none :) > > Drew > SCTP uses the best fit size for user data.. thus 16k gets used for large messages :-) R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 23:16:26 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1041416A401 for ; Mon, 22 Jan 2007 23:16:26 +0000 (UTC) (envelope-from wishmaster@velnet.ru) Received: from mail.velnet.ru (mail.velnet.ru [88.210.53.179]) by mx1.freebsd.org (Postfix) with ESMTP id C3C6413C457 for ; Mon, 22 Jan 2007 23:16:25 +0000 (UTC) (envelope-from wishmaster@velnet.ru) Received: from [213.141.131.138] (helo=localhost) by mail.velnet.ru with esmtp (Exim 4.30; FreeBSD) id 1H98VN-0001Zi-46 for freebsd-net@freebsd.org; Tue, 23 Jan 2007 02:23:13 +0300 Date: Mon, 22 Jan 2007 15:32:15 +0300 From: Wishmaster X-Mailer: The Bat! (v2.12.00) X-Priority: 3 (Normal) Message-ID: <1147284745.20070122153215@velnet.ru> To: freebsd-net@freebsd.org In-Reply-To: <45B42FD2.2000403@delphij.net> References: <1458229821.20070120234257@velnet.ru> <45B28F37.7040100@delphij.net> <2910709734.20070121043023@velnet.ru> <45B42FD2.2000403@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re[2]: reproducible watchdog timeout in bge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Wishmaster List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 23:16:26 -0000 Hello LI, Monday, January 22, 2007, 6:30:26 AM, you wrote: LX> Wishmaster wrote: >> Hello LI, >> >> Sunday, January 21, 2007, 12:52:55 AM, you wrote: >> >> LX> Wishmaster wrote: >>>> Hi, >>>> >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92090 >> >> LX> Have you tried this one? >> >> LX> http://people.freebsd.org/~delphij/misc/patch-bge-releng62 >> >> LX> Cheers, >> >> Yes, i tried, but have no effect. >> >> after reboot interface works, but if i try to ping with packet for >> example 1500 bytes and interval 0.01s it looks like LX> I see, so you have a different problem, which could indicate either LX> there is a different bug in the driver that makes it, or there is some LX> problem with your hardware :-( LX> Cheers, I have three different hardware configurations, and two different Freebsd releases on them (6.1/amd64 and 6.2/i386) all of them have the same problem. There is more detailed description of problem here (lat post by Wishmaster): http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92090 -- Best regards, Wishmaster mailto:wishmaster@velnet.ru From owner-freebsd-net@FreeBSD.ORG Mon Jan 22 23:35:31 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2323316A51C for ; Mon, 22 Jan 2007 23:35:31 +0000 (UTC) (envelope-from wishmaster@velnet.ru) Received: from mail.velnet.ru (mail.velnet.ru [88.210.53.179]) by mx1.freebsd.org (Postfix) with ESMTP id D557C13C4B7 for ; Mon, 22 Jan 2007 23:35:30 +0000 (UTC) (envelope-from wishmaster@velnet.ru) Received: from [213.141.131.138] (helo=localhost) by mail.velnet.ru with esmtp (Exim 4.30; FreeBSD) id 1H98nr-0002eH-2K for freebsd-net@freebsd.org; Tue, 23 Jan 2007 02:42:19 +0300 Date: Tue, 23 Jan 2007 02:34:58 +0300 From: Wishmaster X-Mailer: The Bat! (v2.12.00) X-Priority: 3 (Normal) Message-ID: <1106181498.20070123023458@velnet.ru> To: freebsd-net@freebsd.org In-Reply-To: <45B4BE90.20602@qwirky.net> References: <1458229821.20070120234257@velnet.ru> <45B28F37.7040100@delphij.net> <1651695163.20070122010957@velnet.ru> <45B4BE90.20602@qwirky.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re[2]: reproducible watchdog timeout in bge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Wishmaster List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 23:35:31 -0000 Hello Jeff, Monday, January 22, 2007, 4:39:28 PM, you wrote: JR> MQ wrote: >> 2007/1/22, Wishmaster : >>> >>> Hello LI, >>> >>> Sunday, January 21, 2007, 12:52:55 AM, you wrote: >>> >>> LX> Wishmaster wrote: >>> >> Hi, >>> >> >>> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92090 >>> >>> LX> Have you tried this one? >>> >>> LX> http://people.freebsd.org/~delphij/misc/patch-bge-releng62 >>> >>> LX> Cheers, >>> >>> Yes, i tried, but have no effect. >>> >>> after reboot interface works, but if i try to ping with packet for >>> example 1500 bytes and interval 0.01s it looks like >>> >>> answer >>> answer >>> answer >>> .... >>> ..... over 50 or less icmp answers then >>> ping: sendto: No buffer space available >>> ping: sendto: No buffer space available >>> ping: sendto: No buffer space available >>> ping: sendto: No buffer space available >>> ping: sendto: No buffer space available >>> ping: sendto: No buffer space available >>> ping: sendto: No buffer space available >>> >>> in dmesg: >>> bge0: watchdog timeout -- resetting >>> bge0: link state changed to DOWN >>> bge0: link state changed to UP >>> >>> -- >>> Best regards, >>> Wishmaster mailto:wishmaster@velnet.ru >>> >> >> What about other NIC chips from Broadcom? And how about the packets other >> than icmp under the same load? >> _______________________________________________ JR> I have been unable to produce time outs with my current setup in JR> 6.2-Release. JR> bge0@pci3:0:0: class=0x020000 card=0x81491043 chip=0x165914e4 rev=0x11 JR> hdr=0x00 JR> vendor = 'Broadcom Corporation' JR> device = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express' JR> class = network JR> subclass = ethernet JR> Reading the PR, I attempted triggering this through CVSing and through JR> the above mentioned ping tests. JR> So far nothing. JR> The only issue I have seen using these NICs in 6.2R is if I nail up the JR> NIC at 100baseTX full-duplex I sometimes loose connectivity. Nothing JR> in the logs indicate watchdog timeouts or any other issue. I simply JR> brought the NIC back down to auto-neg and all seems fine. I am JR> assuming this is a incompatibility between the BGE and my switch, RS8000. JR> I have a Asus P5MT-S with dual BGE NIC's JR> Cheers, JR> Jeff JR> _______________________________________________ JR> freebsd-net@freebsd.org mailing list JR> http://lists.freebsd.org/mailman/listinfo/freebsd-net JR> To unsubscribe, send any mail to JR> "freebsd-net-unsubscribe@freebsd.org" There are different types of broadcom chips on my hardware: bge0: mem 0xddef0000-0xddefffff irq 16 at device 0.0 on pci5 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:15:f2:cd:21:9a I don't have any other type of broadcom NIC to test but all other NICs, for example Intel works correctly. p.s. MB: ASUSTeK P5M2 /2GBL -- Best regards, Wishmaster mailto:wishmaster-velnet@yandex.ru From owner-freebsd-net@FreeBSD.ORG Tue Jan 23 15:29:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B53116A409 for ; Tue, 23 Jan 2007 15:29:47 +0000 (UTC) (envelope-from undelivery@le20news.com) Received: from ns34011.ovh.net (ns34011.ovh.net [213.251.169.25]) by mx1.freebsd.org (Postfix) with SMTP id 96B3713C474 for ; Tue, 23 Jan 2007 15:29:45 +0000 (UTC) (envelope-from undelivery@le20news.com) Received: (qmail 30596 invoked by uid 0); 23 Jan 2007 13:43:22 -0000 Message-ID: <20070123134322.23240.qmail@ns34011.ovh.net> To: freebsd-net@freebsd.org Date: Tue, 23 Jan 2007 14:10:12 +0100 From: "Emmanuel" X-Mailer-ListID: 45 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Soldes -60% - Volnay 1er Cru 1992 - LIVRAISON 24H GRATUITE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: infos@le20news.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 15:29:47 -0000 [1][logo_le20_MAJ.gif] [2][chrono_anim_soldes.gif] Si vous n'arrivez pas à lire ce message, [3]cliquez ici [4]accueil [5]qui sommes nous ? [6]nous contacter [7][header_soldes_230107.jpg] Nos meilleurs vins (Bourgogne, Vallée du Rhône, Champagne) [8]CHOREY-LES-BEAUNE - Pierre de Chabliseau prix par bouteille, vendu par 12 1999 Rouge Bourgogne 8,50 EUR prix public [DEL: :DEL] [DEL: 14,50 EUR :DEL] économisez 42% [9]BOURGOGNE Sang d'Anges - Ludovic Belin 2004 Rouge Bourgogne 9,50 EUR prix public [DEL: :DEL] [DEL: 12,00 EUR :DEL] [10]SANTENAY - Marc BOUTHENET prix par bouteille, vendu par 6 2001 Rouge Bourgogne 9,80 EUR prix public [DEL: :DEL] [DEL: 17,00 EUR :DEL] économisez 43% [11]CHABLIS - Jean-Claude FROMONT 2005 Blanc Bourgogne 9,95 EUR prix public [DEL: :DEL] [DEL: 13,00 EUR :DEL] [12]MARANGES 1er CRU - Pierre de Chabliseau prix par bouteille, vendu par 6 1995 Rouge Bourgogne 9,90 EUR prix public [DEL: :DEL] [DEL: 17,00 EUR :DEL] économisez 42% [13]AUXEY-DURESSES - FROMAGEOT-LECHENAULT [14]prix par bouteille, vendu par 6 1999 Rouge Bourgogne 9,95 EUR prix public [DEL: :DEL] [DEL: 17,00 EUR :DEL] économisez 42%[DEL: :DEL] [15]MONTAGNY 1er CRU - Jean-Pierre BERTHENET prix par bouteille, vendu par 6 2003 Blanc Bourgogne 12,40 EUR prix public [DEL: :DEL] [DEL: 17,00 EUR :DEL] [16]SAVIGNY-LES-BEAUNE - Manoir de le BRESSANDIERE 2002 Rouge Bourgogne 12,90 EUR prix public [DEL: :DEL] [DEL: 15,50 EUR :DEL] [17]Muscat Beaumes de Venise - Domaine de La Pigeade prix par bouteille, vendu par 2 2005 Blanc Vallée du Rhône 12,95 EUR prix public [DEL: :DEL] [DEL: 19,00 EUR :DEL] économisez 32% [18]SAVIGNY-LES-BEAUNE 1er Cru Aux clous - Louis CHENU prix par bouteille, vendu par 6 2001 Rouge Bourgogne 12,95 EUR prix public [DEL: :DEL] [DEL: 19,75 EUR :DEL] économisez 35% [19]MORGON - Pierre de Chabliseau 2004 Rouge Bourgogne 13,00 EUR prix public [DEL: :DEL] [DEL: 15,00 EUR :DEL] [20]SAVIGNY-LES-BEAUNE 1er CRU - Pierre de Chabliseau prix par bouteille, vendu par 6 2004 Rouge Bourgogne 13,75 EUR prix public [DEL: :DEL] [DEL: 18,50 EUR :DEL] [21]SAVIGNY-LES-BEAUNES - Domaine DELAGRANGE 1998 Blanc Bourgogne 14,00 EUR prix public [DEL: :DEL] [DEL: 22,00 EUR :DEL] économisez 37% [22]BEAUNE Au Renard - Domaine de la Combe 2004 Rouge Bourgogne 14,00 EUR prix public [DEL: :DEL] [DEL: 17,00 EUR :DEL] [23]MONTAGNY 1er CRU - Jean-Pierre BERTHENET 2003 Blanc Bourgogne 14,30 EUR prix public [DEL: :DEL] [DEL: 17,00 EUR :DEL] [24]VOLNAY - Nicolas Potel prix par bouteille, vendu par 6 2002 Rouge Bourgogne 14,60 EUR prix public [DEL: :DEL] [DEL: 25,00 EUR :DEL] économisez 42% [25]BEAUNE 1er CRU - Pierre de Chabliseau prix par bouteille, vendu par 3 2002 Rouge Bourgogne 14,70 EUR prix public [DEL: :DEL] [DEL: 25,00 EUR :DEL] économisez 42% [26]GEVREY-CHAMBERTIN - Jean-Claude FROMONT [27]prix par bouteille, vendu par 6 2001 Rouge Bourgogne 14,95 EUR prix public [DEL: :DEL] [DEL: 25,00 EUR :DEL] économisez 40% [DEL: :DEL] [28]BEAUNE Les Frévoles - Delagrange 1995 Rouge Bourgogne 15,00 EUR prix public [DEL: :DEL] [DEL: 21,00 EUR :DEL] [29]BEAUNE Vieilles Vignes - Domaine de la Combe 2004 Rouge Bourgogne 15,00 EUR prix public [DEL: :DEL] [DEL: 18,00 EUR :DEL] [30]BEAUNE Les Frévoles - Delagrange 1996 Rouge Bourgogne 15,00 EUR prix public [DEL: :DEL] [DEL: 21,00 EUR :DEL] [31]SAVIGNY-LES-BEAUNE Vieilles Vignes - Domaine Nicolas Potel prix par bouteille, vendu par 6 2003 Rouge Bourgogne 15,00 EUR prix public [DEL: :DEL] [DEL: 27,00 EUR :DEL] économisez 45% [32]GEVREY-CHAMBERTIN - Pierre de Chabliseau prix par bouteille, vendu par 6 2001 Rouge Bourgogne 15,50 EUR prix public [DEL: :DEL] [DEL: 25,00 EUR :DEL] économisez 38% [33]SANTENAY Vieilles Vignes - Nicolas Potel 1999 Rouge Bourgogne 16,00 EUR prix public [DEL: :DEL] [DEL: 22,00 EUR :DEL] [34]MONTHELIE - Alexandre GAUVIN prix par bouteille, vendu par 6 2004 Blanc Bourgogne 16,00 EUR prix public [DEL: :DEL] [DEL: 20,00 EUR :DEL] [35]Côtes du Rhône CAIRANNE - Antique Séminaros prix par bouteille, vendu par 6 1996 Rouge Vallée du Rhône 16,30 EUR prix public [DEL: :DEL] [DEL: 27,00 EUR :DEL] économisez 40% [36]VOLNAY-SANTENOTS 1er CRU - Domaine ROUGEOT prix par bouteille, vendu par 3 1991 Rouge Bourgogne 16,40 EUR prix public [DEL: :DEL] [DEL: 41,00 EUR :DEL] économisez 60% [37]VOLNAY-SANTENOTS 1er CRU - Domaine ROUGEOT prix par bouteille, vendu par 3 1992 Rouge Bourgogne 16,40 EUR prix public [DEL: :DEL] [DEL: 41,00 EUR :DEL] économisez 60% [38]ALOXE CORTON - CAVE DE NOLAY 2005 Rouge Bourgogne 16,60 EUR prix public [DEL: :DEL] [DEL: 22,00 EUR :DEL] [39]GEVREY-CHAMBERTIN - Pierre de Chabliseau 2001 Rouge Bourgogne 17,00 EUR prix public [DEL: :DEL] [DEL: 25,00 EUR :DEL] économisez 33% [40]CHABLIS 1ER CRU - Jean-Claude FROMONT 2005 Blanc Bourgogne 17,00 EUR prix public [DEL: :DEL] [DEL: 18,00 EUR :DEL] [41]SANTENAY 1er Cru - Jean-Claude FROMONT prix par bouteille, vendu par 6 1992 Rouge Bourgogne 17,00 EUR prix public [DEL: :DEL] [DEL: 21,00 EUR :DEL] [42]Châteauneuf-du-Pape - LES GRANDES SERRES prix par bouteille, vendu par 6 2000 Rouge Vallée du Rhône 17,50 EUR prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL] économisez 47% [43]BEAUNE 1er CRU LES SIZIES - Alexandre Gauvin 2004 Rouge Bourgogne 18,00 EUR prix public [DEL: :DEL] [DEL: 23,00 EUR :DEL] [44]VOSNE-ROMANEE - Alexandre GAUVIN 2002 Rouge Bourgogne 18,00 EUR prix public [DEL: :DEL] [DEL: 24,00 EUR :DEL] [45]CHABLIS 1ER Cru Mont de Milieu - Jean-Claude FROMONT 2005 Blanc Bourgogne 18,00 EUR prix public [DEL: :DEL] [DEL: 22,00 EUR :DEL] [46]PERNAND-VERGELESSES - Ludovic Belin prix par bouteille, vendu par 6 2003 Blanc Bourgogne 18,00 EUR prix public [DEL: :DEL] [DEL: 22,00 EUR :DEL] [47]MEURSAULT - Eric Boussey prix par bouteille, vendu par 6 1999 Blanc Bourgogne 19,00 EUR prix public [DEL: :DEL] [DEL: 31,00 EUR :DEL] économisez 39% [48]CÔTE DE NUITS-VILLAGES Le Vaucrain - Louis Jadot 1999 Rouge Bourgogne 19,00 EUR prix public [DEL: :DEL] [DEL: 22,00 EUR :DEL] [49]Côtes du Rhône CAIRANNE - Antique Séminaros prix par bouteille, vendu par 6 1998 Rouge Vallée du Rhône 19,28 EUR prix public [DEL: :DEL] [DEL: 27,00 EUR :DEL] [50]VOLNAY 1er CRU - Bernard Delagrange 2000 Rouge Bourgogne 20,00 EUR prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL] économisez 40% [51]PERNAND VERGELESSES - Ludovic Belin 2003 Blanc Bourgogne 20,00 EUR prix public [DEL: :DEL] [DEL: 22,00 EUR :DEL] [52]MEURSAULT - Jean-Claude FROMONT 2004 Blanc Bourgogne 20,00 EUR prix public [DEL: :DEL] [DEL: 28,00 EUR :DEL] [53]MEURSAULT - Delagrange 2002 Rouge Bourgogne 20,00 EUR prix public [DEL: :DEL] [DEL: 28,00 EUR :DEL] [54]PERNAND-VERGELESSES - Ludovic Belin 2002 Blanc Bourgogne 20,00 EUR prix public [DEL: :DEL] [DEL: 23,00 EUR :DEL] [55]SAVIGNY-LES-BEAUNES - Domaine DELAGRANGE 1990 Blanc Bourgogne 22,00 EUR prix public [DEL: :DEL] [DEL: 30,00 EUR :DEL] [56]MEURSAULT - Jean-Claude FROMONT 1996 Blanc Bourgogne 22,00 EUR prix public [DEL: :DEL] [DEL: 28,00 EUR :DEL] [57]MEURSAULT - Pierre de Chabliseau 2004 Blanc Bourgogne 22,00 EUR prix public [DEL: :DEL] [DEL: 28,00 EUR :DEL] [58]PULIGNY-MONTRACHET - Stéphan Maroslavac prix par bouteille, vendu par 6 1999 Blanc Bourgogne 22,00 EUR prix public [DEL: :DEL] [DEL: 27,00 EUR :DEL] [59]VOLNAY - Adamas 2003 Rouge Bourgogne 22,00 EUR prix public [DEL: :DEL] [DEL: 27,00 EUR :DEL] [60]MEURSAULT - Jean-Claude FROMONT 1995 Blanc Bourgogne 22,00 EUR prix public [DEL: :DEL] [DEL: 28,00 EUR :DEL] [61]Châteauneuf-du-Pape - LES GRANDES SERRES 2004 Blanc Vallée du Rhône 22,00 EUR prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL] économisez 34% [62]VOLNAY 1er Cru Vieilles vignes - Comte de Pernand 2003 Rouge Bourgogne 23,00 EUR prix public [DEL: :DEL] [DEL: 45,50 EUR :DEL] économisez 50% [63]POMMARD - Christophe Thilloux 1996 Rouge Bourgogne 23,00 EUR prix public [DEL: :DEL] [DEL: 26,00 EUR :DEL] [64]Champagne 1er Cru Brut extra Maison Brochet Dolet - Claude BROCHET Blanc Champagne 23,90 EUR prix public [DEL: :DEL] [DEL: 35,00 EUR :DEL] économisez 32% [65]ALOXE CORTON - B. DESCHAMPS-GORDO 1999 Rouge Bourgogne 24,00 EUR prix public [DEL: :DEL] [DEL: 34,00 EUR :DEL] économisez 30% [66]MEURSAULT - Adamas 2004 Blanc Bourgogne 24,00 EUR prix public [DEL: :DEL] [DEL: 28,00 EUR :DEL] [67]CHAMBOLLE-MUSIGNY - Mallard-Gaulin prix par bouteille, vendu par 3 2001 Rouge Bourgogne 24,00 EUR prix public [DEL: :DEL] [DEL: 35,00 EUR :DEL] économisez 32% [68]Châteauneuf-du-Pape - LES GRANDES SERRES 2003 Rouge Vallée du Rhône 24,00 EUR prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL] [69]PULIGNY-MONTRACHET 1er CRU Champs Gains - Stéphan Maroslavac prix par bouteille, vendu par 6 2001 Blanc Bourgogne 25,00 EUR prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL] [70]Châteauneuf-du-Pape - LES GRANDES SERRES 2001 Blanc Vallée du Rhône 25,00 EUR prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL] [71]MEURSAULT La Barre - Bernard Delagrange prix par bouteille, vendu par 3 1991 Blanc Bourgogne 25,00 EUR prix public [DEL: :DEL] [DEL: 45,00 EUR :DEL] économisez 45% [72]CHAMBOLLE-MUSIGNY - CAVE DE NOLAY 1996 Rouge Bourgogne 26,00 EUR prix public [DEL: :DEL] [DEL: 35,00 EUR :DEL] [73]POMMARD 1er Cru Fremiers - Christophe Thilloux 2001 Rouge Bourgogne 26,50 EUR prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL] [74]CORTON GRAND CRU - Jean-Claude FROMONT prix par bouteille, vendu par 3 2004 Rouge Bourgogne 26,90 EUR prix public [DEL: :DEL] [DEL: 47,00 EUR :DEL] économisez 43% [75]Châteauneuf-du-Pape - E. GUIGAL 2000 Rouge Vallée du Rhône 27,00 EUR prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL] [76]VOLNAY 1er Cru Les Mitans - Nicolas Potel prix par bouteille, vendu par 3 2003 Rouge Bourgogne 28,00 EUR prix public [DEL: :DEL] [DEL: 45,50 EUR :DEL] économisez 39% [77]Condrieu - Côte Chatillon - François GERARD prix par bouteille, vendu par 3 2004 Blanc Vallée du Rhône 28,70 EUR prix public [DEL: :DEL] [DEL: 45,00 EUR :DEL] économisez 37% [78]CORTON GRAND CRU Les Grandes Lolières - Ludovic Belin prix par bouteille, vendu par 3 2004 Rouge Bourgogne 32,50 EUR prix public [DEL: :DEL] [DEL: 65,00 EUR :DEL] économisez 50% [79]MEURSAULT 1er Cru Les Charmes - Mallard-Gaulin prix par bouteille, vendu par 3 2002 Blanc Bourgogne 33,00 EUR prix public [DEL: :DEL] [DEL: 41,00 EUR :DEL] [80]CORTON GRAND CRU - Mallard-Gaulin prix par bouteille, vendu par 3 2002 Rouge Bourgogne 33,00 EUR prix public [DEL: :DEL] [DEL: 49,00 EUR :DEL] économisez 33% [81]CORTON VERGENNES GRAND CRU - Comte Louis de Vernicourt prix par bouteille, vendu par 3 1994 Rouge Bourgogne 34,00 EUR prix public [DEL: :DEL] [DEL: 52,00 EUR :DEL] économisez 35% [82]NUITS SAINT GEORGES 1ER CRU Terres Blanches - Daniel RION et fils 2004 Blanc Bourgogne 35,00 EUR prix public [DEL: :DEL] [DEL: 52,00 EUR :DEL] économisez 33% [83]CÔTE-RÔTIE - Domaine de Rosiers prix par bouteille, vendu par 3 2003 Rouge Vallée du Rhône 35,00 EUR prix public [DEL: :DEL] [DEL: 48,00 EUR :DEL] [84]HERMITAGE - Les Miaux - Ferraton Père & Fils prix par bouteille, vendu par 3 2000 Rouge Vallée du Rhône 35,00 EUR prix public [DEL: :DEL] [DEL: 45,00 EUR :DEL] [85]BEAUNE - Gaston Boisseaux 1986 Rouge Bourgogne 36,00 EUR prix public [DEL: :DEL] [DEL: 50,00 EUR :DEL] [86]NUITS SAINT GEORGES 1er CRU Aux Argillats - Martin-Dufour 2003 Rouge Bourgogne 37,00 EUR prix public [DEL: :DEL] [DEL: 45,00 EUR :DEL] [87]BEAUNE - Gaston Boisseaux 1985 Rouge Bourgogne 37,00 EUR prix public [DEL: :DEL] [DEL: 50,00 EUR :DEL] [88]MAGNUM RULLY - Joseph Drouhin 2004 Blanc Bourgogne 38,00 EUR prix public [DEL: :DEL] [DEL: 49,00 EUR :DEL] [89]CHARMES-CHAMBERTIN - Jules Belin 2002 Rouge Bourgogne 38,00 EUR prix public [DEL: :DEL] [DEL: 76,00 EUR :DEL] économisez 50% [90]Châteauneuf-du-Pape - Château Cabrières 1995 Rouge Vallée du Rhône 38,00 EUR prix public [DEL: :DEL] [DEL: 55,00 EUR :DEL] économisez 31% [91]CÔTE-RÔTIE Côte Brune - Domaine de Bonserine 1994 Rouge Vallée du Rhône 39,00 EUR prix public [DEL: :DEL] [DEL: 48,00 EUR :DEL] [92]CÔTE-RÔTIE Côte Brune - Domaine de Bonserine 1994 Rouge Vallée du Rhône 39,00 EUR prix public [DEL: :DEL] [DEL: 48,00 EUR :DEL] [93]NUITS SAINT GEORGES 1er CRU Aux Argillats - Martin-Dufour 2001 Rouge Bourgogne 39,24 EUR prix public [DEL: :DEL] [DEL: 47,00 EUR :DEL] [94]PULIGNY-MONTRACHET 1er CRU Les Perrières - Jean-Claude FROMONT 1988 Blanc Bourgogne 39,95 EUR prix public [DEL: :DEL] [DEL: 65,00 EUR :DEL] économisez 39% [95]CORTON-CHARLEMAGNE GRAND CRU - Ludovic Belin prix par bouteille, vendu par 2 2004 Blanc Bourgogne 44,00 EUR prix public [DEL: :DEL] [DEL: 70,00 EUR :DEL] économisez 38% [96]CHARMES-CHAMBERTIN Grand Cru - Nicolas Potel prix par bouteille, vendu par 3 2002 Rouge Bourgogne 46,00 EUR prix public [DEL: :DEL] [DEL: 86,00 EUR :DEL] économisez 47% [97]Châteauneuf-du-Pape - Château Cabrières 1990 Rouge Vallée du Rhône 48,00 EUR prix public [DEL: :DEL] [DEL: 70,00 EUR :DEL] économisez 32% [98]Châteauneuf-du-Pape - Domaine du Haut des Terres Blanches 1977 Rouge Vallée du Rhône 51,00 EUR prix public [DEL: :DEL] [DEL: 70,00 EUR :DEL] [99]Châteauneuf-du-Pape - Château Cabrières 1986 Rouge Vallée du Rhône 54,00 EUR prix public [DEL: :DEL] [DEL: 90,00 EUR :DEL] économisez 41% [100]CHAMBOLLE-MUSIGNY - Jaboulet Verchère 1975 Rouge Bourgogne 55,00 EUR prix public [DEL: :DEL] [DEL: 72,00 EUR :DEL] [101]Châteauneuf-du-Pape - Domaine du Haut des Terres Blanches 1972 Rouge Vallée du Rhône 56,00 EUR prix public [DEL: :DEL] [DEL: 70,00 EUR :DEL] [102]Châteauneuf-du-Pape - Domaine du Haut des Terres Blanches 1971 Rouge Vallée du Rhône 56,00 EUR prix public [DEL: :DEL] [DEL: 70,00 EUR :DEL] [103]CHARMES-CHAMBERTIN - Camus Père et fils 1997 Rouge Bourgogne 60,00 EUR prix public [DEL: :DEL] [DEL: 96,00 EUR :DEL] économisez 38% [104]Châteauneuf-du-Pape - Château Cabrières 1984 Rouge Vallée du Rhône 62,00 EUR prix public [DEL: :DEL] [DEL: 90,00 EUR :DEL] économisez 32% [105]CLOS VOUGEOT Grand Cru - Daniel Rion et fils 2000 Rouge Bourgogne 73,00 EUR prix public [DEL: :DEL] [DEL: 125,00 EUR :DEL] économisez 42% [106]Châteauneuf-du-Pape - Château Cabrières 1981 Rouge Vallée du Rhône 75,00 EUR prix public [DEL: :DEL] [DEL: 90,00 EUR :DEL] [107]Châteauneuf-du-Pape - Château Cabrières 1979 Rouge Vallée du Rhône 85,00 EUR prix public [DEL: :DEL] [DEL: 110,00 EUR :DEL] [108]CHATEAU DE POMMARD - Jean-Louis Laplanche 1974 Rouge Bourgogne 90,00 EUR prix public [DEL: :DEL] [DEL: 110,00 EUR :DEL] [109]RICHEBOURG Grand Cru - Domaine Marc ROUGEOT-DUPIN 1991 Rouge Bourgogne 98,00 EUR prix public [DEL: :DEL] [DEL: 190,00 EUR :DEL] économisez 49% [110]ROMANEE SAINT-VIVANT Grand Cru - P. Misserey 1988 Rouge Bourgogne 98,00 EUR prix public [DEL: :DEL] [DEL: 170,00 EUR :DEL] économisez 43% [111]Champagne BOLLINGER R.D. - BOLLINGER 1981 Blanc Champagne 195,00 EUR prix public [DEL: :DEL] [DEL: 0,00 EUR :DEL] [112]Dom Ruinart Rosé - Ruinart 1976 Rosé Champagne 198,00 EUR prix public [DEL: :DEL] [DEL: 245,00 EUR :DEL] [113]Moët & Chandon Brut Impérial - Moët & Chandon 1971 Rosé Champagne 198,00 EUR prix public [DEL: :DEL] [DEL: 245,00 EUR :DEL] Offre valable dans la limite des stocks disponibles [footer_left_corner.gif] [114]Expéditions & retours [115]Remarques sur la confidentialité [116]Conditions d'utilisation [117]nous contacter [footer_right_corner.gif] "A tout moment, vous disposez d'un droit d'accès, de modification, de rectification et de suppression des données qui vous concernent" (art 34 de la loi Informatique et Libertés du 6 Janvier 1978). Pour vous désinscrire de nos mailing lists, [118]cliquez ici L'abus d'alcool est dangereux pour la santé, consommez avec modération. le20.fr - Copyright © 2005 le20.fr, 17 rue Berlier, 21000 DIJON - SARL AU CAPITAL DE 15 000 euros - RCS DIJON 480 509 769 [sendopen.php?MemberID=2857279&SendID=520&Type=Send] References Visible links 1. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3115 2. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3115 3. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3112 4. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3115 5. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3005 6. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3113 7. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3115 8. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3061 9. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3019 10. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3104 11. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3100 12. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3066 13. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3049 14. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3066 15. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3090 16. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3103 17. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3012 18. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3060 19. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3065 20. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3064 21. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3024 22. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3021 23. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3094 24. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3089 25. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3101 26. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3075 27. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3082 28. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3023 29. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3020 30. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3106 31. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3078 32. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3062 33. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3110 34. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3080 35. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3084 36. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3053 37. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3068 38. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3044 39. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3063 40. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3072 41. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3054 42. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3082 43. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3105 44. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3099 45. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3039 46. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3092 47. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3077 48. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3076 49. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3083 50. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3007 51. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3107 52. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3102 53. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3109 54. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3108 55. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3025 56. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3013 57. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3098 58. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3056 59. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3086 60. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3014 61. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3010 62. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3016 63. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3052 64. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3026 65. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3069 66. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3091 67. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3037 68. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3079 69. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3055 70. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3011 71. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3070 72. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3038 73. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3087 74. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3096 75. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3022 76. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3081 77. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3046 78. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3017 79. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3035 80. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3036 81. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3071 82. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3097 83. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3015 84. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3008 85. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3041 86. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3034 87. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3040 88. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3073 89. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3085 90. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3027 91. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3043 92. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3074 93. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3095 94. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3009 95. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3018 96. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3088 97. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3028 98. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3047 99. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3029 100. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3033 101. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3048 102. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3050 103. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3042 104. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3030 105. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3093 106. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3031 107. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3032 108. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3045 109. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3067 110. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3051 111. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3059 112. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3058 113. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3057 114. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3006 115. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3111 116. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3114 117. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3113 118. http://www.le20newsletters.com/users/unsub.php?Mem=2857279&ConfirmCode=bbdcb47bc8f2dd48a28dd559bff1fcf7 Hidden links: 119. mailto:infos@le20.fr 120. mailto:infos@le20.fr 121. mailto:infos@le20.fr 122. mailto:infos@le20.fr From owner-freebsd-net@FreeBSD.ORG Tue Jan 23 16:43:06 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4079C16A405 for ; Tue, 23 Jan 2007 16:43:06 +0000 (UTC) (envelope-from jhall@vandaliamo.net) Received: from trueband.net (trueband.net [216.163.120.10]) by mx1.freebsd.org (Postfix) with SMTP id C20FB13C4D3 for ; Tue, 23 Jan 2007 16:43:05 +0000 (UTC) (envelope-from jhall@vandaliamo.net) Received: (qmail 16071 invoked by uid 1006); 23 Jan 2007 16:15:04 -0000 Received: from jhall@vandaliamo.net by rs0 by uid 1003 with qmail-scanner-1.16 (spamassassin: 3.1.4. Clear:SA:0(1.0/100.0):. Processed in 1.910398 secs); 23 Jan 2007 16:15:04 -0000 X-Spam-Status: No, hits=1.0 required=100.0 X-Spam-Level: * Received: from unknown (HELO trueband.net) (172.16.0.12) by -v with SMTP; 23 Jan 2007 16:15:02 -0000 Received: (qmail 18384 invoked from network); 23 Jan 2007 16:15:02 -0000 Received: from unknown (HELO admintool.trueband.net) (127.0.0.1) by -v with SMTP; 23 Jan 2007 16:15:02 -0000 Received: from 65.117.48.154 (SquirrelMail authenticated user jhall@vandaliamo.net) by admintool.trueband.net with HTTP; Tue, 23 Jan 2007 16:15:02 -0000 (GMT) Message-ID: <1729.65.117.48.154.1169568902.squirrel@admintool.trueband.net> Date: Tue, 23 Jan 2007 16:15:02 -0000 (GMT) From: jhall@vandaliamo.net To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: VLANs and DHCP 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, 23 Jan 2007 16:43:06 -0000 I currently administer a system which has two DHCP servers on two different VLANs. Unfortunately, the two servers are not playing together well and some comptuers are receiving IP addresses on the wrong network. So, with our phone vendor's blessing, I am trying to move all of the DHCP services to the FreeBSD server. The computers on the network are supposed to receive an IP address on the default vlan and the phones are supposed to receive an IP address on their vlan. Essentially what happens when a phone is booted, the phone receives an IP address on the default VLAN, releases that address and then requests an IP address on the appropriate VLAN. How do I specify to FreeBSD which VLAN should be the default? I have read some information which seems to be conflicting. One article indicated vlan0 is the default vlan, and another seemed to indicate vlan1 was the default vlan. Or, have I just overcomplicated this? Thanks for your help. Jay From owner-freebsd-net@FreeBSD.ORG Tue Jan 23 16:48:09 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B3CF16A403; Tue, 23 Jan 2007 16:48:09 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE4E13C45D; Tue, 23 Jan 2007 16:48:09 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from [192.168.26.75] (64-84-9-2-sf-gw.ncircle.com [64.84.9.2]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l0NGm4XV016006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jan 2007 08:48:06 -0800 Message-ID: <45B63C3E.9010808@freebsd.org> Date: Tue, 23 Jan 2007 08:47:58 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Dimitry Andric References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121.020741.59649277.hrs@allbsd.org> <45B251A5.4000209@freebsd.org> <45B3CA56.4040106@andric.com> <45B421D4.2050008@freebsd.org> <45B48F0C.9090809@andric.com> In-Reply-To: <45B48F0C.9090809@andric.com> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3FD97F734167E6F5E0E2A499" Cc: freebsd-net@freebsd.org, Hiroki Sato , freebsd-stable@freebsd.org, jhay@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-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: Tue, 23 Jan 2007 16:48:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3FD97F734167E6F5E0E2A499 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Dimitry Andric wrote: > Bruce A. Mah wrote: >>> and later I found out it was caused by commit 1.48.2.16: >>> http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/03185= 3.html >> This isn't consistent with what I'm finding. For one thing, rev. >> 1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there >> anyways. Also, that's not the change I made to my local sources to ge= t >> my gif(4) tunnel working. Are you sure about this? :-) >=20 > I'm following -STABLE, and 1.48.2.16 is in there. Since it was > committed on 29 Nov, I suspected it would end up in -RELEASE, but > apparently not. :) >=20 > I explicitly tried reverting just this one commit, and for me it solved= > the problem (i.e. the automagical addition of needed routing entries). I tried this too and it didn't help. :-( Just to confirm, you're dealing with a gif(4) interface with an explicitly-configured destination address and a 128-bit prefixlen, yes? > So for you, reverting the combination of 1.48.2.14 and .15 works? Yep. BTW these two changes really go together, so it doesn't really make sense to revert just one of them (the commit logs implied that this would be fairly broken in other ways). > Maybe > there is something else involved too, for example the route command > itself? Not sure what you mean by this exactly...???... Here's what I've tested so far...in the table below, "work" means that the host route to the destination got installed correctly and "no work" means that it didn't. Base Local Patch Result ---- ----------- ------ 6.2-RELEASE Unmodified No work 6.2-RELEASE Revert nd6.c 1.48.2.{14,15} Work 6.2-STABLE Unmodified No work 6.2-STABLE Revert nd6.c 1.48.2.{14,15} Work 6.2-STABLE Revert nd6.c 1.48.2.16 No work I'm going to write up an entry for the 6.2-RELEASE errata notes documenting the existence of a problem and a workaround. We still need to figure out exactly what the right fix is. Testing results from other users (both 6.2-RELEASE and 6.2-STABLE) would be most welcome. Bruce. --------------enig3FD97F734167E6F5E0E2A499 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.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFtjw+2MoxcVugUsMRAtqCAKDLjhYA+KIyxLDcsWMPUqUPktHy1QCdG2pL a5DO4JF6QFuYE9xf+z7WNng= =YYxb -----END PGP SIGNATURE----- --------------enig3FD97F734167E6F5E0E2A499-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 23 17:52:40 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9906116A402 for ; Tue, 23 Jan 2007 17:52:40 +0000 (UTC) (envelope-from dc@dcoder.net) Received: from mail0.dcoder.net (ns0.dcoder.net [66.92.160.14]) by mx1.freebsd.org (Postfix) with ESMTP id 6DBAF13C441 for ; Tue, 23 Jan 2007 17:52:40 +0000 (UTC) (envelope-from dc@dcoder.net) Received: by mail0.dcoder.net (Postfix, from userid 1001) id 348941700D; Tue, 23 Jan 2007 12:27:12 -0500 (EST) Date: Tue, 23 Jan 2007 12:27:12 -0500 From: david coder To: freebsd-net@freebsd.org Message-ID: <20070123172712.GA40770@mail0.dcoder.net> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: Attansic ethernet controller 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, 23 Jan 2007 17:52:40 -0000 The Asus P5B-E motherboard on-board ethernet controller is the Attansic L1 PCI-E [copper] Gigabit LAN controller. I don't need the gigabit but I would like the 100MB. As far as I can see, 6.x doesn't support this controller. Am I wrong? Does anybody have a patch? Thx. Cheers, David Coder Network Engineer Emeritus, Verio/NTT Telluride, CO & Washington, DC From owner-freebsd-net@FreeBSD.ORG Tue Jan 23 21:30:07 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16E5B16A403; Tue, 23 Jan 2007 21:30:07 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [213.154.244.69]) by mx1.freebsd.org (Postfix) with ESMTP id BA4AA13C459; Tue, 23 Jan 2007 21:30:06 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [192.168.0.3] (kilgore.lan.dim [192.168.0.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTP id BA0A7B80E; Tue, 23 Jan 2007 21:57:06 +0100 (CET) Message-ID: <45B676A2.5090009@andric.com> Date: Tue, 23 Jan 2007 21:57:06 +0100 From: Dimitry Andric User-Agent: Thunderbird 3.0a1 (Windows/20070122) MIME-Version: 1.0 To: "Bruce A. Mah" References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121.020741.59649277.hrs@allbsd.org> <45B251A5.4000209@freebsd.org> <45B3CA56.4040106@andric.com> <45B421D4.2050008@freebsd.org> <45B48F0C.9090809@andric.com> <45B63C3E.9010808@freebsd.org> In-Reply-To: <45B63C3E.9010808@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Hiroki Sato , freebsd-stable@freebsd.org, jhay@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-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: Tue, 23 Jan 2007 21:30:07 -0000 Bruce A. Mah wrote: > Just to confirm, you're dealing with a gif(4) interface with an > explicitly-configured destination address and a 128-bit prefixlen, yes? Yes. The specific line in my rc.conf is: ipv6_ifconfig_gif0="2001:7b8:2ff:146::2 2001:7b8:2ff:146::1 prefixlen 128" >> Maybe >> there is something else involved too, for example the route command >> itself? > Not sure what you mean by this exactly...???... I mean that it may be that between -RELEASE and -STABLE, other things have changed, e.g. network rc scripts, /sbin/route itself, etc, which may also influence this behaviour. I'm sure more than only nd6.c changed. :) However, for me, with the whole system at -STABLE (as of Jan 11), I verified the following results again just now: nd6.c rev state --------- ----- 1.48.2.12 works 1.48.2.13 works 1.48.2.14 works 1.48.2.15 works 1.48.2.16 doesn't work > Here's what I've tested so far...in the table below, "work" means that > the host route to the destination got installed correctly and "no work" > means that it didn't. > > Base Local Patch Result > ---- ----------- ------ > 6.2-RELEASE Unmodified No work > 6.2-RELEASE Revert nd6.c 1.48.2.{14,15} Work > 6.2-STABLE Unmodified No work > 6.2-STABLE Revert nd6.c 1.48.2.{14,15} Work > 6.2-STABLE Revert nd6.c 1.48.2.16 No work So strangely, this is different from my results... I can't install 6.2-RELEASE on the specific box, alas. > I'm going to write up an entry for the 6.2-RELEASE errata notes > documenting the existence of a problem and a workaround. We still need > to figure out exactly what the right fix is. Testing results from other > users (both 6.2-RELEASE and 6.2-STABLE) would be most welcome. Just FYI, my initial alternative workaround was to use prefixlen 126, e.g.: ipv6_ifconfig_gif0="2001:7b8:2ff:146::2 prefixlen 126" Cheers, Dimitry From owner-freebsd-net@FreeBSD.ORG Wed Jan 24 00:28:30 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E74516A401 for ; Wed, 24 Jan 2007 00:28:30 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id DBD1913C442 for ; Wed, 24 Jan 2007 00:28:29 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.177.213] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1H9W020gPN-0004YP; Wed, 24 Jan 2007 01:28:27 +0100 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Wed, 24 Jan 2007 01:28:19 +0100 User-Agent: KMail/1.9.5 References: <20070123172712.GA40770@mail0.dcoder.net> In-Reply-To: <20070123172712.GA40770@mail0.dcoder.net> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2112153.pvrDaJQMWI"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701240128.25363.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 X-Provags-ID2: V01U2FsdGVkX1+PWMojqE1VD3Ftk174F+rYf0QDW4LFFKXYjaBULKKQxcq0pmoNt2Y5aAcATZqZNA5mf19ByMu+N3POSkTzxkgUsk3sbSHymjQuN2EEqxrXZA== Cc: david coder Subject: Re: Attansic ethernet controller 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, 24 Jan 2007 00:28:30 -0000 --nextPart2112153.pvrDaJQMWI Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 23 January 2007 18:27, david coder wrote: > The Asus P5B-E motherboard on-board ethernet controller is the Attansic > L1 PCI-E [copper] Gigabit LAN controller. I don't need the gigabit but > I would like the 100MB. As far as I can see, 6.x doesn't support this > controller. Am I wrong? Does anybody have a patch? Can you provide "pciconf -vl" of that box? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2112153.pvrDaJQMWI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFtqgpXyyEoT62BG0RAhoBAJ0QJQp1Eej0yKL9E1xWGTnJqB9bSgCggSgx 6LRqATiRQt66Z0W0pIM3IPM= =8soT -----END PGP SIGNATURE----- --nextPart2112153.pvrDaJQMWI-- From owner-freebsd-net@FreeBSD.ORG Wed Jan 24 01:16:24 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87B0A16A408 for ; Wed, 24 Jan 2007 01:16:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by mx1.freebsd.org (Postfix) with ESMTP id 5808113C4EC for ; Wed, 24 Jan 2007 01:16:18 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so27412wxc for ; Tue, 23 Jan 2007 17:16:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=Th1haaEORlEQqrX5kYT2QoG4m4UkJ+yXMxNEXHmLtK+4yXCBIKDHPHvWHbvsOuJBoVn8aqyWXH60heJp3zz/6G/FFJ9EJQt/qwmxtbn5xVUqoPG5tGLmWlXxQ2l4lDx8wPe0v284WI06nmAerdcXICYEcV6acXfY0a29ibqGX4c= Received: by 10.70.87.5 with SMTP id k5mr169594wxb.1169599726344; Tue, 23 Jan 2007 16:48:46 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 35sm207956wra.2007.01.23.16.48.44; Tue, 23 Jan 2007 16:48:45 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l0O0o6Ec037976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Jan 2007 09:50:06 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l0O0o6R1037975 for freebsd-net@freebsd.org; Wed, 24 Jan 2007 09:50:06 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 24 Jan 2007 09:50:06 +0900 From: Pyun YongHyeon To: freebsd-net@freebsd.org Message-ID: <20070124005006.GA37721@cdnetworks.co.kr> References: <20070123172712.GA40770@mail0.dcoder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070123172712.GA40770@mail0.dcoder.net> User-Agent: Mutt/1.4.2.1i Subject: Re: Attansic ethernet controller X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 01:16:24 -0000 On Tue, Jan 23, 2007 at 12:27:12PM -0500, david coder wrote: > The Asus P5B-E motherboard on-board ethernet controller is the Attansic > L1 PCI-E [copper] Gigabit LAN controller. I don't need the gigabit but I > would like the 100MB. As far as I can see, 6.x doesn't support this > controller. Am I wrong? Does anybody have a patch? > I think FreeBSD has no driver support for Attansic L1 Gigabit Ethernet. It seems that the Attansic L1 is used on onboard network devices(LOM) for Asus M2V, P5B-E and P5L-VM 1394 etc. I don't know there are publicly available documentations for the hardware but it seems that Linux already has an experimental driver for the hardware. I don't have the hardware so writing a driver for the hardware is not possible to me but other developers that have the hardware can help you. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Wed Jan 24 01:47:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9FF9216A400 for ; Wed, 24 Jan 2007 01:47:56 +0000 (UTC) (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 2447513C4C7 for ; Wed, 24 Jan 2007 01:47:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 10936 invoked by uid 399); 24 Jan 2007 01:21:13 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 24 Jan 2007 01:21:13 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <45B6B486.6030708@FreeBSD.org> Date: Tue, 23 Jan 2007 17:21:10 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: jhall@vandaliamo.net References: <1729.65.117.48.154.1169568902.squirrel@admintool.trueband.net> In-Reply-To: <1729.65.117.48.154.1169568902.squirrel@admintool.trueband.net> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: VLANs and DHCP 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, 24 Jan 2007 01:47:56 -0000 jhall@vandaliamo.net wrote: > I currently administer a system which has two DHCP servers on two > different VLANs. Unfortunately, the two servers are not playing together > well and some comptuers are receiving IP addresses on the wrong network. > So, with our phone vendor's blessing, I am trying to move all of the DHCP > services to the FreeBSD server. > > The computers on the network are supposed to receive an IP address on the > default vlan and the phones are supposed to receive an IP address on their > vlan. > > Essentially what happens when a phone is booted, the phone receives an IP > address on the default VLAN, releases that address and then requests an IP > address on the appropriate VLAN. > > How do I specify to FreeBSD which VLAN should be the default? I have read > some information which seems to be conflicting. One article indicated > vlan0 is the default vlan, and another seemed to indicate vlan1 was the > default vlan. > > Or, have I just overcomplicated this? You have a DHCP configuration problem, not a FreeBSD problem. You'd be better off posting to a DHCP list. What you want to investigate between now and then is whether the phones are sending a client identifier that you could ignore in your computer dhcp conf file, and/or explicitly listing the MAC addresses of whichever set of devices has the fewest members, and then giving every other client an address on the vlan that you configure in dhcp to be the default. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Wed Jan 24 02:18:39 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0062E16A404 for ; Wed, 24 Jan 2007 02:18:38 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail4out.barnet.com.au (mail4.barnet.com.au [202.83.178.125]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1BB13C44B for ; Wed, 24 Jan 2007 02:18:38 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail4out.barnet.com.au (Postfix, from userid 1001) id 7377E37B92A; Wed, 24 Jan 2007 13:00:28 +1100 (EST) X-Viruscan-Id: <45B6BDBC0000CA8E3A6A24@BarNet> Received: from mail4auth.barnet.com.au (mail4.barnet.com.au [202.83.178.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail4.barnet.com.au (Postfix) with ESMTP id 41E5D423B1E; Wed, 24 Jan 2007 13:00:28 +1100 (EST) Received: from k7.mavetju (k7.mavetju.org [10.251.1.18]) by mail4auth.barnet.com.au (Postfix) with ESMTP id F30AE37B913; Wed, 24 Jan 2007 13:00:27 +1100 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id DA095190; Wed, 24 Jan 2007 13:00:27 +1100 (EST) Date: Wed, 24 Jan 2007 13:00:27 +1100 From: Edwin Groothuis To: jhall@vandaliamo.net Message-ID: <20070124020027.GC90167@k7.mavetju> References: <1729.65.117.48.154.1169568902.squirrel@admintool.trueband.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1729.65.117.48.154.1169568902.squirrel@admintool.trueband.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: VLANs and DHCP 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, 24 Jan 2007 02:18:39 -0000 On Tue, Jan 23, 2007 at 04:15:02PM -0000, jhall@vandaliamo.net wrote: > I currently administer a system which has two DHCP servers on two > different VLANs. Unfortunately, the two servers are not playing together > well and some comptuers are receiving IP addresses on the wrong network. > So, with our phone vendor's blessing, I am trying to move all of the DHCP > services to the FreeBSD server. > > The computers on the network are supposed to receive an IP address on the > default vlan and the phones are supposed to receive an IP address on their > vlan. > > Essentially what happens when a phone is booted, the phone receives an IP > address on the default VLAN, releases that address and then requests an IP > address on the appropriate VLAN. Sounds like you're using Cisco phones and the isc-dhcp server (or relay-agent)... Try net/dhcprelay from the ports collection. Let it forward the DHCP requests to a central server, and all will be fine. The isc-dhcrelay is euhm... quite noisy. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://weblog.barnet.com.au/edwin/ From owner-freebsd-net@FreeBSD.ORG Wed Jan 24 03:21:53 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 885B816A400 for ; Wed, 24 Jan 2007 03:21:53 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mx1.freebsd.org (Postfix) with ESMTP id 629B113C47E for ; Wed, 24 Jan 2007 03:21:53 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 23 Jan 2007 19:21:53 -0800 X-IronPort-AV: i="4.13,227,1167638400"; d="2'?scan'208"; a="357541034:sNHT133767124" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0O3LqXS017290 for ; Tue, 23 Jan 2007 19:21:52 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0O3LgGs026543 for ; Tue, 23 Jan 2007 19:21:51 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 19:21:42 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 19:21:42 -0800 Message-ID: <45B679F3.3080407@cisco.com> Date: Tue, 23 Jan 2007 16:11:15 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: freebsd-net Content-Type: multipart/mixed; boundary="------------080208020809070508020709" X-OriginalArrivalTime: 24 Jan 2007 03:21:42.0052 (UTC) FILETIME=[C492D640:01C73F66] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6477; t=1169608912; x=1170472912; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20mbuf=20patch=20with=20sysctl=20suggestions=20too |Sender:=20; bh=FNcZlcIOvJ98pW41DmLAe1t47gH7+sSrwoobfwh40R8=; b=HKhAQo7qUp4iJY/hOJIpqo+Rlw7PpQILdKPAWoFJNSkpj67238wXalOAzFq1NTEy6OsotvJP HbHr1yKoIECCyJ/3SjxSjQLxFeoVhTfiN2C7y4bdl7W+jVct67mJ0iv0; Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); Subject: mbuf patch with sysctl suggestions too 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, 24 Jan 2007 03:21:53 -0000 This is a multi-part message in MIME format. --------------080208020809070508020709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all: Here is iteration 2 of the mbuf patch with limits I proposed. Also note the changes for sysctl stuff that Lugi suggested. Please let me know what you think :-) R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) --------------080208020809070508020709 Content-Type: text/plain; name="patch.mbuf.2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch.mbuf.2" Index: kern/kern_mbuf.c =================================================================== RCS file: /usr/FreeBSD/src/sys/kern/kern_mbuf.c,v retrieving revision 1.27 diff -u -r1.27 kern_mbuf.c --- kern/kern_mbuf.c 22 Oct 2006 11:52:13 -0000 1.27 +++ kern/kern_mbuf.c 23 Jan 2007 17:55:21 -0000 @@ -106,8 +106,19 @@ { /* This has to be done before VM init. */ - nmbclusters = 1024 + maxusers * 64; + nmbclusters = 1024 + (maxusers * 64); + nmbjumbop = 512 + (maxusers * 32); + /* 9k pages take 3 pages, so you get + * 1/3 of the limit of nmbjumbop. 16k + * pages take 4 pages, so you get + * 1/4 of the limit of nmbjumbop. + */ + nmbjumbo9 = nmbjumbop/3; + nmbjumbo16 = nmbjumbop/4; TUNABLE_INT_FETCH("kern.ipc.nmbclusters", &nmbclusters); + TUNABLE_INT_FETCH("kern.ipc.nmbjumbop", &nmbjumbop); + TUNABLE_INT_FETCH("kern.ipc.nmbjumbo9", &nmbjumbo9); + TUNABLE_INT_FETCH("kern.ipc.nmbjumbo16", &nmbjumbo16); } SYSINIT(tunable_mbinit, SI_SUB_TUNABLES, SI_ORDER_ANY, tunable_mbinit, NULL); @@ -118,26 +129,78 @@ int error, newnmbclusters; newnmbclusters = nmbclusters; - error = sysctl_handle_int(oidp, &newnmbclusters, sizeof(int), req); + error = sysctl_int_checked(oidp, &newnmbclusters, nmbclusters, + SYSCTL_NO_LIMIT, req); + if (error == 0 && req->newptr) { + nmbclusters = newnmbclusters; + uma_zone_set_max(zone_clust, nmbclusters); + EVENTHANDLER_INVOKE(nmbclusters_change); + } + return (error); +} + +static int +sysctl_nmbjclusters(SYSCTL_HANDLER_ARGS) +{ + int error, newnmbjclusters; + + newnmbjclusters = nmbjumbop; + error = sysctl_int_checked(oidp, &newnmbjclusters, nmbjumbop, + SYSCTL_NO_LIMIT, req); if (error == 0 && req->newptr) { - if (newnmbclusters > nmbclusters) { - nmbclusters = newnmbclusters; - uma_zone_set_max(zone_clust, nmbclusters); - EVENTHANDLER_INVOKE(nmbclusters_change); - } else - error = EINVAL; + nmbjumbop = newnmbjclusters; + uma_zone_set_max(zone_jumbop, nmbjumbop); } return (error); } + + +static int +sysctl_nmbj9clusters(SYSCTL_HANDLER_ARGS) +{ + int error, newnmbj9clusters; + + newnmbj9clusters = nmbjumbo9; + error = sysctl_int_checked(oidp, &newnmbj9clusters, nmbjumbo9, + SYSCTL_NO_LIMIT, req); + if (error == 0 && req->newptr) { + nmbjumbo9 = newnmbj9clusters; + uma_zone_set_max(zone_jumbo9, nmbjumbo9); + } + return (error); +} + +static int +sysctl_nmbj16clusters(SYSCTL_HANDLER_ARGS) +{ + int error, newnmbj16clusters; + + newnmbj16clusters = nmbjumbo16; + error = sysctl_int_checked(oidp, &newnmbj16clusters, nmbjumbo16, + SYSCTL_NO_LIMIT, req); + if (error == 0 && req->newptr) { + nmbjumbo16 = newnmbj16clusters; + uma_zone_set_max(zone_jumbo16, nmbjumbo16); + } + return (error); +} + SYSCTL_PROC(_kern_ipc, OID_AUTO, nmbclusters, CTLTYPE_INT|CTLFLAG_RW, &nmbclusters, 0, sysctl_nmbclusters, "IU", "Maximum number of mbuf clusters allowed"); -SYSCTL_INT(_kern_ipc, OID_AUTO, nmbjumbop, CTLFLAG_RW, &nmbjumbop, 0, + +SYSCTL_PROC(_kern_ipc, OID_AUTO, nmbjumbop, CTLTYPE_INT|CTLFLAG_RW, +&nmbjumbop, 0, sysctl_nmbjclusters, "IU", "Maximum number of mbuf page size jumbo clusters allowed"); -SYSCTL_INT(_kern_ipc, OID_AUTO, nmbjumbo9, CTLFLAG_RW, &nmbjumbo9, 0, + +SYSCTL_PROC(_kern_ipc, OID_AUTO, nmbjumbo9, CTLTYPE_INT|CTLFLAG_RW, +&nmbjumbo9, 0, sysctl_nmbj9clusters, "IU", "Maximum number of mbuf 9k jumbo clusters allowed"); -SYSCTL_INT(_kern_ipc, OID_AUTO, nmbjumbo16, CTLFLAG_RW, &nmbjumbo16, 0, + +SYSCTL_PROC(_kern_ipc, OID_AUTO, nmbjumbo16, CTLTYPE_INT|CTLFLAG_RW, +&nmbjumbo16, 0, sysctl_nmbj16clusters, "IU", "Maximum number of mbuf 16k jumbo clusters allowed"); + SYSCTL_STRUCT(_kern_ipc, OID_AUTO, mbstat, CTLFLAG_RD, &mbstat, mbstat, "Mbuf general information and statistics"); Index: kern/kern_sysctl.c =================================================================== RCS file: /usr/FreeBSD/src/sys/kern/kern_sysctl.c,v retrieving revision 1.172 diff -u -r1.172 kern_sysctl.c --- kern/kern_sysctl.c 6 Nov 2006 13:42:01 -0000 1.172 +++ kern/kern_sysctl.c 23 Jan 2007 17:44:39 -0000 @@ -826,6 +826,43 @@ } + +/* + * Handle an int, unsigned, but limited + * between min and max (unsigned) + * Two cases: + * a variable: point arg1 at it. + * a constant: pass it in arg2. + * + */ + +extern int nmbjumbo9; + +int +sysctl_int_checked(struct sysctl_oid *oidp, void *val, uint32_t min, uint32_t max, struct sysctl_req *req) +{ + uint32_t tmpout=0; + int error = 0; + + if(val == NULL) + return (EINVAL); + + tmpout = *(int *)val; + error = SYSCTL_OUT(req, &tmpout, sizeof(int)); + + if (error || !req->newptr) { + return (error); + } + error = SYSCTL_IN(req, (void *)&tmpout, sizeof(uint32_t)); + if ((tmpout < min) || (tmpout > max)) { + error = EINVAL; + return(error); + } + *((uint32_t *)val) = tmpout; + return (error); +} + + /* * Based on on sysctl_handle_int() convert milliseconds into ticks. */ Index: sys/sysctl.h =================================================================== RCS file: /usr/FreeBSD/src/sys/sys/sysctl.h,v retrieving revision 1.145 diff -u -r1.145 sysctl.h --- sys/sysctl.h 17 Sep 2006 20:00:35 -0000 1.145 +++ sys/sysctl.h 22 Jan 2007 18:04:42 -0000 @@ -167,6 +167,11 @@ #define SYSCTL_IN(r, p, l) (r->newfunc)(r, p, l) #define SYSCTL_OUT(r, p, l) (r->oldfunc)(r, p, l) +#define SYSCTL_NO_LIMIT 0xffffffff +int +sysctl_int_checked(struct sysctl_oid *, void *, uint32_t min, + uint32_t max, struct sysctl_req *); + int sysctl_handle_int(SYSCTL_HANDLER_ARGS); int sysctl_msec_to_ticks(SYSCTL_HANDLER_ARGS); int sysctl_handle_long(SYSCTL_HANDLER_ARGS); --------------080208020809070508020709-- From owner-freebsd-net@FreeBSD.ORG Wed Jan 24 04:22:08 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9405916A413 for ; Wed, 24 Jan 2007 04:22:08 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 5CF9B13C47E for ; Wed, 24 Jan 2007 04:22:08 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id 9F6855A7C3A; Wed, 24 Jan 2007 15:22:02 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id ECB2D27419; Wed, 24 Jan 2007 15:22:01 +1100 (EST) Date: Wed, 24 Jan 2007 15:22:00 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Randall Stewart In-Reply-To: <45B679F3.3080407@cisco.com> Message-ID: <20070124150524.P16439@besplex.bde.org> References: <45B679F3.3080407@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net Subject: Re: mbuf patch with sysctl suggestions too 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, 24 Jan 2007 04:22:08 -0000 On Tue, 23 Jan 2007, Randall Stewart wrote: > Here is iteration 2 of the mbuf patch with limits I > proposed. > > Also note the changes for sysctl stuff that Lugi suggested. > Please let me know what you think :-) It has a lot of style bugs (4 per line on so,me lines) (mainly weird whitespace starting with tab lossage). Bruce From owner-freebsd-net@FreeBSD.ORG Wed Jan 24 06:10:07 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95E1616A401 for ; Wed, 24 Jan 2007 06:10:07 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.freebsd.org (Postfix) with ESMTP id 5CE5313C44C for ; Wed, 24 Jan 2007 06:10:07 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 23 Jan 2007 22:10:07 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0O6A6GQ011011; Tue, 23 Jan 2007 22:10:06 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0O6A6Dk019768; Tue, 23 Jan 2007 22:10:06 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 22:10:06 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 22:10:05 -0800 Message-ID: <45B6F81C.6050802@cisco.com> Date: Wed, 24 Jan 2007 01:09:32 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Bruce Evans References: <45B679F3.3080407@cisco.com> <20070124150524.P16439@besplex.bde.org> In-Reply-To: <20070124150524.P16439@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2007 06:10:05.0898 (UTC) FILETIME=[4AEF62A0:01C73F7E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=792; t=1169619006; x=1170483006; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20mbuf=20patch=20with=20sysctl=20suggestions=20too |Sender:=20; bh=/LRSHl8f1rd4AvFZtjpcXRErsn+bCQKwZlmi8Sn+S4Q=; b=Q++HzgVdq/Oqogfa/++7XmPqg6F3Mh4F0gBzsLUf269E/r68SE66KwcEmFDFCpmKS0fi3rlK MqKt+TrZF4KiUqR45iRUWqaKh6D/nkXoqU+jg+otjCiJ7woMgrEFWZ4w; Authentication-Results: sj-dkim-5; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim5002 verified; ); Cc: freebsd-net Subject: Re: mbuf patch with sysctl suggestions too 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, 24 Jan 2007 06:10:07 -0000 Bruce Evans wrote: > On Tue, 23 Jan 2007, Randall Stewart wrote: > >> Here is iteration 2 of the mbuf patch with limits I >> proposed. >> >> Also note the changes for sysctl stuff that Lugi suggested. >> Please let me know what you think :-) > > It has a lot of style bugs (4 per line on so,me lines) (mainly weird > whitespace starting with tab lossage). > > Bruce > That has to do with me using emacs I think.. I will be running that section of code through the style9 (s9indent) stuff that George gave me... so that should take care of the space <-> tab issues and other stuff... I think Pyun is right though.. in adding the page size calculation to the init code.. R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Wed Jan 24 06:51:10 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C42616A400 for ; Wed, 24 Jan 2007 06:51:10 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id C81AA13C471 for ; Wed, 24 Jan 2007 06:51:09 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id A863F6E2E3; Wed, 24 Jan 2007 17:51:05 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 1172027417; Wed, 24 Jan 2007 17:51:06 +1100 (EST) Date: Wed, 24 Jan 2007 17:51:05 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Randall Stewart In-Reply-To: <45B6F81C.6050802@cisco.com> Message-ID: <20070124172119.P36500@delplex.bde.org> References: <45B679F3.3080407@cisco.com> <20070124150524.P16439@besplex.bde.org> <45B6F81C.6050802@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net Subject: Re: mbuf patch with sysctl suggestions too 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, 24 Jan 2007 06:51:10 -0000 On Wed, 24 Jan 2007, Randall Stewart wrote: > Bruce Evans wrote: >> It has a lot of style bugs (4 per line on so,me lines) (mainly weird >> whitespace starting with tab lossage). >> > That has to do with me using emacs I think.. I will be running that > section of code through the style9 (s9indent) stuff that George > gave me... so that should take care of the space <-> tab issues > and other stuff... I wouldn't trust an editor to get this right. indent(1) gets closer, but still gets so much wrong that every change that it wants to make must be reviewed manually. > I think Pyun is right though.. in adding the page size > calculation to the init code.. I forgot to mention the style bugs in the comment related to page sizes. IIRC, the comment has many hard-coded magic numbers which are only correct if the page size is 4K and the allocations start on page boundaries, but pages can be almost any size and are 8K on some supported arches, and I think allocations made by UMA are only aligned to a small power of 2. I think this allows a 9k buffer to be split across 4 4K-pages (e.g., 128+4096+4096+680) or across 3 8K-pages (128+8192+680). Hardware might not like this. Otherwise, non-page-aligned allocations should make the page size irrelevant. Bruce From owner-freebsd-net@FreeBSD.ORG Wed Jan 24 12:52:53 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C700E16A412 for ; Wed, 24 Jan 2007 12:52:53 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.freebsd.org (Postfix) with ESMTP id A12F113C46A for ; Wed, 24 Jan 2007 12:52:53 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 24 Jan 2007 04:52:53 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0OCqpP6028441; Wed, 24 Jan 2007 04:52:51 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0OCqoUw004494; Wed, 24 Jan 2007 04:52:51 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 04:52:50 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 04:52:50 -0800 Message-ID: <45B75680.9030809@cisco.com> Date: Wed, 24 Jan 2007 07:52:16 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Bruce Evans References: <45B679F3.3080407@cisco.com> <20070124150524.P16439@besplex.bde.org> <45B6F81C.6050802@cisco.com> <20070124172119.P36500@delplex.bde.org> In-Reply-To: <20070124172119.P36500@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2007 12:52:50.0286 (UTC) FILETIME=[8E0860E0:01C73FB6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1887; t=1169643171; x=1170507171; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20mbuf=20patch=20with=20sysctl=20suggestions=20too |Sender:=20; bh=0+W4qlBZUMkuCblT0GVZIZI+KWN8O+568r7GX63u6MA=; b=n4I8azR1za2ftPYxjBXDFyHtN8js5ek79RRKPJ8ApnJbp/kEAypa9JdXWSQ3S/ZnxDVDvpLS xeVU7Blasc5BFOR6pf2clDGfpL9QUMwgUyUb/F1kMUf5fGosKXiPcQ7A; Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); Cc: freebsd-net Subject: Re: mbuf patch with sysctl suggestions too 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, 24 Jan 2007 12:52:53 -0000 Bruce Evans wrote: > On Wed, 24 Jan 2007, Randall Stewart wrote: > >> Bruce Evans wrote: >>> It has a lot of style bugs (4 per line on so,me lines) (mainly weird >>> whitespace starting with tab lossage). >>> >> That has to do with me using emacs I think.. I will be running that >> section of code through the style9 (s9indent) stuff that George >> gave me... so that should take care of the space <-> tab issues >> and other stuff... > > I wouldn't trust an editor to get this right. indent(1) gets closer, > but still gets so much wrong that every change that it wants to make > must be reviewed manually. > >> I think Pyun is right though.. in adding the page size >> calculation to the init code.. > > I forgot to mention the style bugs in the comment related to page > sizes. IIRC, the comment has many hard-coded magic numbers which are > only correct if the page size is 4K and the allocations start on page > boundaries, but pages can be almost any size and are 8K on some supported > arches, and I think allocations made by UMA are only aligned to a small > power of 2. I think this allows a 9k buffer to be split across 4 > 4K-pages (e.g., 128+4096+4096+680) or across 3 8K-pages (128+8192+680). > Hardware might not like this. Otherwise, non-page-aligned allocations > should make the page size irrelevant. Hmm.. the one thing I thought of was to use the uk_ppera to do the calculation (besides what Pyun had mentioned). But I was concerned about using an internal Keg variable within another subsystem.... maybe if we made a access function... but Andre has asked to wait on this .. he has another idea.. so no hurry... its been "unlimited" this long... we can wait until Andre comes up with a better idea :-) R > > Bruce > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Wed Jan 24 13:10:51 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 542BB16A402 for ; Wed, 24 Jan 2007 13:10:51 +0000 (UTC) (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 41E5413C43E for ; Wed, 24 Jan 2007 13:10:51 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l0ODAo9H056267; Wed, 24 Jan 2007 05:10:50 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l0ODAoUg056266; Wed, 24 Jan 2007 05:10:50 -0800 (PST) (envelope-from rizzo) Date: Wed, 24 Jan 2007 05:10:50 -0800 From: Luigi Rizzo To: Randall Stewart Message-ID: <20070124051050.A56064@xorpc.icir.org> References: <45B679F3.3080407@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <45B679F3.3080407@cisco.com>; from rrs@cisco.com on Tue, Jan 23, 2007 at 04:11:15PM -0500 Cc: freebsd-net Subject: Re: mbuf patch with sysctl suggestions too 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, 24 Jan 2007 13:10:51 -0000 On Tue, Jan 23, 2007 at 04:11:15PM -0500, Randall Stewart wrote: > Hi all: > > Here is iteration 2 of the mbuf patch with limits I > proposed. > > Also note the changes for sysctl stuff that Lugi suggested. > Please let me know what you think :-) ... > + newnmbjclusters = nmbjumbop; > + error = sysctl_int_checked(oidp, &newnmbjclusters, nmbjumbop, > + SYSCTL_NO_LIMIT, req); A few things here: - i don't see much of a point in defining SYSCTL_NO_LIMIT; UINT32_MAX would do perfectly there, and i think it is easier to understand than SYSCTL_NO_LIMIT (which looks like a flag). - here and in other places you do not allow decresaing the value (by putting min = nmbjumbop etc.), and i am not sure why. I understand a reasonable lower bound, but i guess the worst that can happen, when you reduce the limit to something above the current allocation, is that nothing is allocated until you go again below the limit, right ? - given that you don't use the new value if error != 0, perhaps you can save the assignment newnmbjclusters = nmbjumbop; And below: > +/* > + * Handle an int, unsigned, but limited > + * between min and max (unsigned) > + * Two cases: > + * a variable: point arg1 at it. > + * a constant: pass it in arg2. > + * > + */ > + > +extern int nmbjumbo9; > + > +int > +sysctl_int_checked(struct sysctl_oid *oidp, void *val, uint32_t min, uint32_t max, struct sysctl_req *req) > +{ the comment refers to something else and should be fixed e.g. Handle an unsigned int variable with bound checking. Returns 0 (and updates *val) if min <= v <= max; returns EINVAL otherwhise (in which case *val is unchanged) cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Jan 24 13:28:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C69AC16A402 for ; Wed, 24 Jan 2007 13:28:28 +0000 (UTC) (envelope-from lists@swaggi.com) Received: from rusty.swaggy.net (rusty.swaggy.net [66.103.13.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7A3AE13C4D1 for ; Wed, 24 Jan 2007 13:28:28 +0000 (UTC) (envelope-from lists@swaggi.com) Received: from [127.0.0.1] (helo=swaggi.com) by rusty.swaggy.net with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H9hMy-0004Mz-60 for freebsd-net@freebsd.org; Wed, 24 Jan 2007 07:36:53 -0500 From: "Yuri Lukin" To: freebsd-net@freebsd.org Date: Wed, 24 Jan 2007 07:36:51 -0500 Message-Id: <20070124122525.M93545@swaggi.com> In-Reply-To: <20070124020027.GC90167@k7.mavetju> References: <1729.65.117.48.154.1169568902.squirrel@admintool.trueband.net> <20070124020027.GC90167@k7.mavetju> X-Mailer: swaggi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Subject: Re: VLANs and DHCP 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, 24 Jan 2007 13:28:28 -0000 On Tue, Jan 23, 2007 at 04:15:02PM -0000, jhall@vandaliamo.net wrote: > I currently administer a system which has two DHCP servers on two > different VLANs. Unfortunately, the two servers are not playing together > well and some comptuers are receiving IP addresses on the wrong network. > So, with our phone vendor's blessing, I am trying to move all of the DHCP > services to the FreeBSD server. > > The computers on the network are supposed to receive an IP address on the > default vlan and the phones are supposed to receive an IP address on their > vlan. > > Essentially what happens when a phone is booted, the phone receives an IP > address on the default VLAN, releases that address and then requests an IP > address on the appropriate VLAN. Just a thought but if your switch properly tags the packets from the voice and data Vlans, the broadcasts from the IP Phones should not cross over to the data Vlan. We have dozens of customers setup this way and they are not having any problems. Not sure what type of switches you are using but I would check your switchport configuration (assuming managed switch). Yuri From owner-freebsd-net@FreeBSD.ORG Wed Jan 24 13:46:40 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51AAF16A403 for ; Wed, 24 Jan 2007 13:46:40 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.freebsd.org (Postfix) with ESMTP id 2E71113C465 for ; Wed, 24 Jan 2007 13:46:40 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 24 Jan 2007 05:46:39 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0ODkc61014932; Wed, 24 Jan 2007 05:46:38 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0ODkaGk024347; Wed, 24 Jan 2007 05:46:36 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 05:46:36 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 05:46:36 -0800 Message-ID: <45B7631A.3070001@cisco.com> Date: Wed, 24 Jan 2007 08:46:02 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Luigi Rizzo References: <45B679F3.3080407@cisco.com> <20070124051050.A56064@xorpc.icir.org> In-Reply-To: <20070124051050.A56064@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2007 13:46:36.0302 (UTC) FILETIME=[10E35AE0:01C73FBE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2187; t=1169646398; x=1170510398; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20mbuf=20patch=20with=20sysctl=20suggestions=20too |Sender:=20; bh=JmglI4vnlLBiSC8bBUrCbGhFcjG3/jRYvA6w2BLMY4M=; b=WbMAIWPKujbtVHEk7az6r83ujNtIvnYVx8GlIDdKkk9yk+ybMbFfJrr7SxnzxBpBYSorO47F fCJTO/WA7F6Lxw/12TmDkfzf5FD4zJSDgknMtRTZP0MwaT/fHxZsPcY8; Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); Cc: freebsd-net Subject: Re: mbuf patch with sysctl suggestions too 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, 24 Jan 2007 13:46:40 -0000 Luigi Rizzo wrote: > On Tue, Jan 23, 2007 at 04:11:15PM -0500, Randall Stewart wrote: >> Hi all: >> >> Here is iteration 2 of the mbuf patch with limits I >> proposed. >> >> Also note the changes for sysctl stuff that Lugi suggested. >> Please let me know what you think :-) > > ... >> + newnmbjclusters = nmbjumbop; >> + error = sysctl_int_checked(oidp, &newnmbjclusters, nmbjumbop, >> + SYSCTL_NO_LIMIT, req); > > A few things here: > - i don't see much of a point in defining SYSCTL_NO_LIMIT; > UINT32_MAX would do perfectly there, and i think it is easier > to understand than SYSCTL_NO_LIMIT (which looks like a flag). > ok > - here and in other places you do not allow decresaing the value > (by putting min = nmbjumbop etc.), and i am not sure why. > I understand a reasonable lower bound, but i guess the worst > that can happen, when you reduce the limit to something above > the current allocation, is that nothing is allocated until > you go again below the limit, right ? Well.. no I believe someone (was in Lin) mentioned that you can get a live-lock if you allow a reduction.. and thus the mbuf clusters were NOT allowed to be reduced.. > > - given that you don't use the new value if error != 0, perhaps > you can save the assignment newnmbjclusters = nmbjumbop; > ok > And below: > >> +/* >> + * Handle an int, unsigned, but limited >> + * between min and max (unsigned) >> + * Two cases: >> + * a variable: point arg1 at it. >> + * a constant: pass it in arg2. >> + * >> + */ >> + >> +extern int nmbjumbo9; >> + >> +int >> +sysctl_int_checked(struct sysctl_oid *oidp, void *val, uint32_t min, uint32_t max, struct sysctl_req *req) >> +{ > > the comment refers to something else and should be fixed e.g. > > Handle an unsigned int variable with bound checking. > Returns 0 (and updates *val) if min <= v <= max; > returns EINVAL otherwhise (in which case *val is unchanged) > Cool.. but as I said, Andre wants me to wait on this.. so I will :-) R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Wed Jan 24 13:49:34 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5902D16A402 for ; Wed, 24 Jan 2007 13:49:34 +0000 (UTC) (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 4657013C4D1 for ; Wed, 24 Jan 2007 13:49:34 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l0ODnVAe056621; Wed, 24 Jan 2007 05:49:31 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l0ODnV2Q056620; Wed, 24 Jan 2007 05:49:31 -0800 (PST) (envelope-from rizzo) Date: Wed, 24 Jan 2007 05:49:31 -0800 From: Luigi Rizzo To: Randall Stewart Message-ID: <20070124054931.B56550@xorpc.icir.org> References: <45B679F3.3080407@cisco.com> <20070124051050.A56064@xorpc.icir.org> <45B7631A.3070001@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <45B7631A.3070001@cisco.com>; from rrs@cisco.com on Wed, Jan 24, 2007 at 08:46:02AM -0500 Cc: freebsd-net Subject: Re: mbuf patch with sysctl suggestions too 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, 24 Jan 2007 13:49:34 -0000 On Wed, Jan 24, 2007 at 08:46:02AM -0500, Randall Stewart wrote: > Luigi Rizzo wrote: > > On Tue, Jan 23, 2007 at 04:11:15PM -0500, Randall Stewart wrote: > >> Hi all: > >> > >> Here is iteration 2 of the mbuf patch with limits I > >> proposed. > >> > >> Also note the changes for sysctl stuff that Lugi suggested. > >> Please let me know what you think :-) > > > > ... > >> + newnmbjclusters = nmbjumbop; > >> + error = sysctl_int_checked(oidp, &newnmbjclusters, nmbjumbop, > >> + SYSCTL_NO_LIMIT, req); > > > > A few things here: > > - i don't see much of a point in defining SYSCTL_NO_LIMIT; > > UINT32_MAX would do perfectly there, and i think it is easier > > to understand than SYSCTL_NO_LIMIT (which looks like a flag). > > > > ok > > - here and in other places you do not allow decresaing the value > > (by putting min = nmbjumbop etc.), and i am not sure why. > > I understand a reasonable lower bound, but i guess the worst > > that can happen, when you reduce the limit to something above > > the current allocation, is that nothing is allocated until > > you go again below the limit, right ? > > Well.. no I believe someone (was in Lin) mentioned that > you can get a live-lock if you allow a reduction.. and > thus the mbuf clusters were NOT allowed to be reduced.. maybe... but then this is definitely worth putting a note explaining why. cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu Jan 25 01:18:42 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88C3216A404 for ; Thu, 25 Jan 2007 01:18:42 +0000 (UTC) (envelope-from kbyanc@posi.net) Received: from nlpi012.sbcis.sbc.com (nlpi012.sbcis.sbc.com [207.115.36.41]) by mx1.freebsd.org (Postfix) with ESMTP id 555E213C442 for ; Thu, 25 Jan 2007 01:18:42 +0000 (UTC) (envelope-from kbyanc@posi.net) X-ORBL: [71.141.251.198] Received: from gateway.posi.net (adsl-71-141-251-198.dsl.snfc21.pacbell.net [71.141.251.198]) by nlpi012.sbcis.sbc.com (8.13.8 out.dk.spool/8.13.8) with ESMTP id l0P12fv8031249; Wed, 24 Jan 2007 19:02:42 -0600 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (Postfix) with ESMTP id 4715275E002; Wed, 24 Jan 2007 17:02:36 -0800 (PST) Date: Wed, 24 Jan 2007 17:02:35 -0800 (PST) From: Kelly Yancey To: Max Laier In-Reply-To: <200701212033.34914.max@love2party.net> Message-ID: <20070124164949.P16327@gateway.posi.net> References: <20070121155510.C23922@delplex.bde.org> <200701210809.27770.max@love2party.net> <20070121215054.C24780@delplex.bde.org> <200701212033.34914.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: slow writes on nfs with bge devices 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, 25 Jan 2007 01:18:42 -0000 On Sun, 21 Jan 2007, Max Laier wrote: > On Sunday 21 January 2007 13:25, Bruce Evans wrote: > > On Sun, 21 Jan 2007, Max Laier wrote: > > > On Sunday 21 January 2007 07:25, Bruce Evans wrote: > > >> nfs writes much less well with bge NICs than with other NICs (sk, > > >> fxp, > > > > > > Do you use hardware checksumming on the bge? There is an XXX in > > > bge_start_locked() that looks a bit suspicious to me. > > > > I use the default for that. Wouldn't checksum problems show up as > > errors somwhere? > > Did you look at the code in question? It is concerned with fragmented > packet chains (which NFS over UDP usually generated) and only commits to > sending them, if there are enough descriptors available at once. This > can easily explain burstyness. > > Can you just try to disable the delayed checksums via "ifconfig -txcsum"? > Should be an easy enough test. > I realize that Bruce has already identified the problem as being with the cabling, however I wanted to add a warning that disabling hardware checksums for bge cards is not a good idea. You can find my analysis of data corruption bugs caused by using bge cards without checksum offloading in the archives: http://lists.freebsd.org/pipermail/freebsd-net/2004-January/002530.html Kelly -- Kelly Yancey - kbyanc@posi.net | kelly@nttmcl.com From owner-freebsd-net@FreeBSD.ORG Thu Jan 25 13:27:38 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD64116A406 for ; Thu, 25 Jan 2007 13:27:38 +0000 (UTC) (envelope-from frank@pinky.sax.de) Received: from pinky.frank-behrens.de (pinky.frank-behrens.de [82.139.199.24]) by mx1.freebsd.org (Postfix) with ESMTP id 2970413C465 for ; Thu, 25 Jan 2007 13:27:37 +0000 (UTC) (envelope-from frank@pinky.sax.de) Received: from [192.168.20.32] (sun.behrens [192.168.20.32]) by pinky.frank-behrens.de (8.13.8/8.13.8) with ESMTP id l0PD9S5W071724 for ; Thu, 25 Jan 2007 14:09:28 +0100 (CET) (envelope-from frank@pinky.sax.de) Message-Id: <200701251309.l0PD9S5W071724@pinky.frank-behrens.de> From: "Frank Behrens" To: freebsd-net@freebsd.org Date: Thu, 25 Jan 2007 14:09:28 +0100 MIME-Version: 1.0 Priority: normal X-mailer: Pegasus Mail for Windows (4.31, DE v4.31 R1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: When IPv6 temporary addresses are regenerated? 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, 25 Jan 2007 13:27:38 -0000 I have an IPv6 setup with temporary addresses (RFC3041). To switch this on I used "sysctl net.inet6.ip6.use_tempaddr=1". The temporary address is generated and meanwhile expired. Does anybody know, when this address is expected to be regenerated? My current interface configuration is vlan0: flags=8843 mtu 1500 inet xxx.xxx.xx.xx netmask 0xffffff00 broadcast xxx.xxx.xxx.xxx inet6 fe80::211:xxxx:xxxx:xxxx%vlan0 prefixlen 64 scopeid 0x5 inet6 2xxx:xxxx:xxxx:: prefixlen 64 anycast inet6 2xxx:xxxx:xxxx:0:211:2fff:xxxx:xxxx prefixlen 64 inet6 2xxx:xxxx:xxxx:0:54b:5960:xxxx:xxxx prefixlen 64 deprecated autoconf temporary pltime 0 vltime 509995 I use FreeBSD 6.2-PRERELEASE-200611090613. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From owner-freebsd-net@FreeBSD.ORG Thu Jan 25 16:34:56 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 180EA16A401; Thu, 25 Jan 2007 16:34:56 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.freebsd.org (Postfix) with ESMTP id 9611D13C459; Thu, 25 Jan 2007 16:34:55 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id l0PGOMFZ009041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jan 2007 19:24:22 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id l0PGOMY8009040; Thu, 25 Jan 2007 19:24:22 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 25 Jan 2007 19:24:22 +0300 From: Gleb Smirnoff To: bms@FreeBSD.org, rwatson@FreeBSD.org Message-ID: <20070125162422.GA7922@bestcom.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i Cc: net@FreeBSD.org Subject: rev. 1.94 of netinet/in.c broke CARP 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, 25 Jan 2007 16:34:56 -0000 Hello, colleagues! I've just discovered, that revision 1.94 of in.c has broke CARP. This change adds a code to in_ifdetach() that goes through the global list of all multicast instances and deletes all the instances, that are belonging to a particular interface. This is intended to avoid leaking multicast instances. Before this change, most of the subsystems, that allocated multicast membership instances had freed is theirselves. I don't know about others, but at least CARP is broken now. It attempts to free a memory, that already has been freed. The scenario is: ifconfig vlan0 create ifconfig vlan0 vlandev em0 vlan 1 10.0.0.1/24 ifconfig carp0 create ifconfig carp0 vhid 1 10.0.0.2/24 ifconfig vlan0 destroy The codepath is: if_detach(vlan0) event_handler_invoke() carp_ifdetach(vlan0) carpdetach(carp0) carp_multicast_cleanup(carp0) in_delmulti(a freed inm) That inm has been freed earlier in if_detach() before event handler has called its hooks. Bruce and Robert, I suppose you can tell me the correct way to deal with multicast memberships now, when there is a generic GC function for them. Should I just stop referencing the inms from CARP softc, and don't care about them? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Jan 25 16:35:12 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57C2C16A404 for ; Thu, 25 Jan 2007 16:35:12 +0000 (UTC) (envelope-from r.gruyters@yirdis.nl) Received: from mail.yirdis.nl (82-148-208-109.fiber.unet.nl [82.148.208.109]) by mx1.freebsd.org (Postfix) with ESMTP id C61BA13C448 for ; Thu, 25 Jan 2007 16:35:11 +0000 (UTC) (envelope-from r.gruyters@yirdis.nl) Received: from server.yirdis.net (localhost [127.0.0.1]) by mail.yirdis.nl (8.13.6/8.13.6) with ESMTP id l0PG5WSI036294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Jan 2007 17:05:32 +0100 (CET) (envelope-from r.gruyters@yirdis.nl) Received: (from www@localhost) by server.yirdis.net (8.13.6/8.13.6/Submit) id l0PG5WiZ036293 for freebsd-net@freebsd.org; Thu, 25 Jan 2007 17:05:32 +0100 (CET) (envelope-from r.gruyters@yirdis.nl) X-Authentication-Warning: server.yirdis.net: www set sender to r.gruyters@yirdis.nl using -f Received: from hp-xw4100-01.yirdis.nl (hp-xw4100-01.yirdis.nl [10.8.0.27]) by server.yirdis.net (Horde MIME library) with HTTP; Thu, 25 Jan 2007 17:05:32 +0100 Message-ID: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net> Date: Thu, 25 Jan 2007 17:05:32 +0100 From: Robin Gruyters To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) / FreeBSD-5.4 X-Virus-Scanned: OK Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] 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, 25 Jan 2007 16:35:12 -0000 On 13-Jan-2007 Oleg Bulyzhin wrote: > > > Could you please test attached patch? It should fix ierrs issue =20 > and should not > > break link events (would be fine to test it: unplug/plug cable, =20 > try to change > > media with ifconfig, change media on other end of wire). > > Hi ya, Just wondering will this patch/update be available for RELENG_6? I =20 have the same problems here with 3 of our servers. Here is dmesg from our development server: [...] Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #1: Mon Jan 15 15:34:19 CET 2007 root@server.yirdis.net:/data/obj/data/src_6_2/sys/YIRDIS Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3000.12-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf41 Stepping =3D 1 =20 Features=3D0xbfebfbff Features2=3D0x641d> AMD Features=3D0x20000000 Logical CPUs per core: 2 real memory =3D 2147430400 (2047 MB) avail memory =3D 2100547584 (2003 MB) ACPI APIC Table: Security auditing service present BSM auditing present ioapic1: Changing APIC ID to 9 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard ioapic3 irqs 72-95 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0 cpu0: on acpi0 pcib0: on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci13: on pcib1 pcib2: at device 4.0 on pci0 pci6: on pcib2 pcib3: at device 0.0 on pci6 pci7: on pcib3 pcib4: at device 0.2 on pci6 pci10: on pcib4 pcib5: at device 1.0 on pci10 pci11: on pcib5 ste0: port 0x5000-0x507f irq 72 at =20 device 4.0 on pci11 miibus0: on ste0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ste0: Ethernet address: 00:0d:88:fc:c8:cc ste1: port 0x5080-0x50ff irq 73 at =20 device 5.0 on pci11 miibus1: on ste1 ukphy1: on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ste1: Ethernet address: 00:0d:88:fc:c8:cd ste2: port 0x5400-0x547f irq 74 at =20 device 6.0 on pci11 miibus2: on ste2 ukphy2: on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ste2: Ethernet address: 00:0d:88:fc:c8:ce ste3: port 0x5480-0x54ff irq 75 at =20 device 7.0 on pci11 miibus3: on ste3 ukphy3: on miibus3 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ste3: Ethernet address: 00:0d:88:fc:c8:cf pcib6: at device 6.0 on pci0 pci3: on pcib6 pcib7: at device 28.0 on pci0 pci2: on pcib7 ciss0: port 0x4000-0x40ff mem =20 0xfdff0000-0xfdff1fff,0xfdf80000-0xfdfbffff irq 24 at device 1.0 on pci2 ciss0: [GIANT-LOCKED] bge0: mem =20 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 miibus4: on bge0 brgphy0: on miibus4 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, =20 1000baseTX-FDX, auto bge0: Ethernet address: 00:12:79:94:ed:12 bge1: mem =20 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 miibus5: on bge1 brgphy1: on miibus5 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, =20 1000baseTX-FDX, auto bge1: Ethernet address: 00:12:79:94:ed:11 pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.4 (no driver attached) pci0: at device 29.5 (no =20 driver attached) pci0: at device 29.7 (no driver attached) pcib8: at device 30.0 on pci0 pci1: on pcib8 pci1: at device 3.0 (no driver attached) pci1: at device 4.0 (no driver attached) pci1: at device 4.2 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port =20 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x500-0x50f irq 18 at device 31.1 =20 on pci0 ata0: on atapci0 ata1: on atapci0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem =20 0xc0000-0xc7fff,0xc8000-0xcbfff,0xee000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 3000124702 Hz quality 800 Timecounters tick every 1.000 msec acd0: CDROM at ata0-master PIO4 da0 at ciss0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 135.168MB/s transfers da0: 69459MB (142253280 512 byte sectors: 255H 32S/T 17433C) Trying to mount root from ufs:/dev/da0s1a Accounting enabled [...] And here the netstat interface statistics: [...] Name Mtu Network Address Ipkts Ierrs Opkts =20 Oerrs Coll ste0* 1500 00:0d:88:fc:c8:cc 0 0 0 =20 0 0 ste1* 1500 00:0d:88:fc:c8:cd 0 0 0 =20 0 0 ste2* 1500 00:0d:88:fc:c8:ce 0 0 0 =20 0 0 ste3* 1500 00:0d:88:fc:c8:cf 0 0 0 =20 0 0 bge0 1500 00:12:79:94:ed:12 11343768 2114510 20564242 =20 0 0 bge1* 1500 00:12:79:94:ed:11 0 0 0 =20 0 0 pflog 33208 0 0 0 =20 0 0 lo0 16384 60221421 0 60221421 =20 0 0 [...] If you have a patch for FreeBSD 6.2, i'm quite happily to test it on =20 our development server. Regards, Robin Gruyters From owner-freebsd-net@FreeBSD.ORG Thu Jan 25 18:13:13 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B531416A404 for ; Thu, 25 Jan 2007 18:13:13 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.freebsd.org (Postfix) with ESMTP id 7D28413C441 for ; Thu, 25 Jan 2007 18:13:13 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from impact.jinmei.org (shuttle.wide.toshiba.co.jp [IPv6:2001:200:1b1::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 096E273018; Fri, 26 Jan 2007 03:13:12 +0900 (JST) Date: Fri, 26 Jan 2007 03:13:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: John Hay In-Reply-To: <20070121073244.GA80811@zibbi.meraka.csir.co.za> References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121073244.GA80811@zibbi.meraka.csir.co.za> 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: "Bruce A. Mah" , freebsd-net@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-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: Thu, 25 Jan 2007 18:13:13 -0000 >>>>> On Sun, 21 Jan 2007 09:32:44 +0200, >>>>> John Hay said: >> There's another workaround for people stuck in this situation and who >> aren't in a position to try this diff. That is to manually install >> the host route like this: >> >> # route add -host -inet6 aaaa:bbbb:cccc:dddd::2 -interface gif0 -nostatic -llinfo >> >> Comments? > Well it seems that even my stuff does not always work perfectly with that > change (1.48.2.15), so maybe we should revert it and I will search for > yet other ways to make FreeBSD's IPv6 code to actually work for our stuff. > My "stuff" is a wireless IPv6 only network running in adhoc mode with > olsrd as the routing protocol. The problem is that all nodes on a subnet > cannot "see" each other, so olsrd needs to add routes to a node through > another node. Sometimes, just to complicate matters a little more, you > would want to have more than one network card in a host, all with the same > subnet address. (For instance on a high site, with sector antennas.) > The case that I found that still does not work reliably, is if olsrd add > the route and route is not immediately used, then the nd code will time > it out and remove it. I think I'm responsible for the troubles. I've been thinking about how to meet all the requests, and concluded that it's more complicated than I originally thought. I've come across an idea that may solve the problems, but I'll need more time to implement and test it. At the moment, I suggest reverting the 1.48.2.16 change for those who simply wanted a gif to work. Regarding the OLSRD stuff, I'd like to know more specific features that are sought. For example, - what should happen if link-layer address resolution fails? Should then entry be removed? Probably not according to your description above, but what would you expect the entry to become in this case? - once the link-layer address is resolved for the entry, should it be regarded as "permanent" without any ND state changes? For example, should NUD be performed on the cache? If yes, what should happen if NUD detects the neighbor is unreachable? Should the entry be removed? Again, probably not, but then what should it become? Keeping it with the same link-layer address? Keeping it with an empty link-layer address? Others? What if the neighbor is acting as a router (setting the router flag in NAs)? Should destination caches using the now-unreachable router be removed as described in the protocol spec? Or should the destination caches be intact? I have my own speculation on these points, but I'd like to know what the actual user(s) of these features want before taking any action based on the speculation. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Thu Jan 25 18:24:36 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DB7016A400; Thu, 25 Jan 2007 18:24:36 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5B213C468; Thu, 25 Jan 2007 18:24:36 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id BEC0E9763D; Thu, 25 Jan 2007 12:38:45 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Thu, 25 Jan 2007 12:38:45 -0500 X-Sasl-enc: j2+PKSGr0AEGO+mGlFuxncAxg1X3jNFh7D5V17V/zUxU 1169746725 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 300F3151A0; Thu, 25 Jan 2007 12:38:44 -0500 (EST) Message-ID: <45B8EB23.705@FreeBSD.org> Date: Thu, 25 Jan 2007 17:38:43 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Gleb Smirnoff References: <20070125162422.GA7922@bestcom.ru> In-Reply-To: <20070125162422.GA7922@bestcom.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: rwatson@FreeBSD.org, net@FreeBSD.org Subject: Re: rev. 1.94 of netinet/in.c broke CARP 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, 25 Jan 2007 18:24:36 -0000 Gleb, Good catch, thanks for tracking this down. Gleb Smirnoff wrote: > I've just discovered, that revision 1.94 of in.c has broke CARP. This > change adds a code to in_ifdetach() that goes through the global list > of all multicast instances and deletes all the instances, that are > belonging to a particular interface. This is intended to avoid leaking > multicast instances. > The irony of this of course is that I was working on two separate fixes; one to prevent the MROUTING code panicking when an interface was suddenly removed, and the other to prevent the netinet ifp detach path from panicking in the same circumstances. These are resource leaks which have been in BSD for years and years. I neglected to test them *together* however; carp(4) was being used in the test cases for both bugs. > Before this change, most of the subsystems, that allocated multicast > membership instances had freed is theirselves. I don't know about others, > but at least CARP is broken now. It attempts to free a memory, that > already has been freed. > I would suggest that the correct fix, for now, would be for carp(4) to now *not* perform its own cleanup for the IPv4 groups it joins on member interfaces. The symptom here is that carp(4) needs to join a multicast group on its member interface. When the interface goes away, the group membership is now destroyed, at the netinet global level, by the netinet detach path first. However, carp(4) is keeping its own imo_membership vector of the addresses it joined on its member interfaces (rather than using the one which netinet assigns to it in its attach path), and later tries to free these memberships. netinet6 does not have the same problem because in6 memberships are reference counted. The root problem is that we should be using consistent semantics for both the IPv4 and IPv6 paths, and the kernel APIs where soft-ifnets (such as carp(4)) and routing code (such as MROUTING) need to manipulate multicast group memberships. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Thu Jan 25 18:37:23 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88EA016A402; Thu, 25 Jan 2007 18:37:23 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.freebsd.org (Postfix) with ESMTP id 06A6913C44C; Thu, 25 Jan 2007 18:37:22 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id l0PIbK7r010265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jan 2007 21:37:20 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id l0PIbK6Z010264; Thu, 25 Jan 2007 21:37:20 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 25 Jan 2007 21:37:20 +0300 From: Gleb Smirnoff To: "Bruce M. Simpson" Message-ID: <20070125183720.GB7922@cell.sick.ru> References: <20070125162422.GA7922@bestcom.ru> <45B8EB23.705@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <45B8EB23.705@FreeBSD.org> User-Agent: Mutt/1.5.6i Cc: rwatson@FreeBSD.org, net@FreeBSD.org Subject: Re: rev. 1.94 of netinet/in.c broke CARP 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, 25 Jan 2007 18:37:23 -0000 Bruce, On Thu, Jan 25, 2007 at 05:38:43PM +0000, Bruce M. Simpson wrote: B> Gleb Smirnoff wrote: B> > I've just discovered, that revision 1.94 of in.c has broke CARP. This B> >change adds a code to in_ifdetach() that goes through the global list B> >of all multicast instances and deletes all the instances, that are B> >belonging to a particular interface. This is intended to avoid leaking B> >multicast instances. B> > B> The irony of this of course is that I was working on two separate fixes; B> one to prevent the MROUTING code panicking when an interface was B> suddenly removed, and the other to prevent the netinet ifp detach path B> from panicking in the same circumstances. B> B> These are resource leaks which have been in BSD for years and years. I B> neglected to test them *together* however; carp(4) was being used in the B> test cases for both bugs. Yes, I knew that we were leaking memory allocated for multicast purposes on interface detach. I was trying to fix this with Oleg and Yar, but failed. B> > Before this change, most of the subsystems, that allocated multicast B> >membership instances had freed is theirselves. I don't know about others, B> >but at least CARP is broken now. It attempts to free a memory, that B> >already has been freed. B> > B> I would suggest that the correct fix, for now, would be for carp(4) to B> now *not* perform its own cleanup for the IPv4 groups it joins on member B> interfaces. Unfortunately, this won't be a correct fix. In a scenario when the parent interface stays on its place, but you are creating, attaching and destroying a CARP interface, the multicast membership would not be left and memory won't be freed. So, after the following sequence ifconfig fxp0 10.0.0.1/24 ifconfig carp0 create ifconfig carp0 vhid 1 10.0.0.2/24 ifconfig carp0 destroy , we would still have a multicast membership on fxp0. B> The symptom here is that carp(4) needs to join a multicast group on its B> member interface. When the interface goes away, the group membership is B> now destroyed, at the netinet global level, by the netinet detach path B> first. B> B> However, carp(4) is keeping its own imo_membership vector of the B> addresses it joined on its member interfaces (rather than using the one B> which netinet assigns to it in its attach path), and later tries to free B> these memberships. B> B> netinet6 does not have the same problem because in6 memberships are B> reference counted. B> B> The root problem is that we should be using consistent semantics for B> both the IPv4 and IPv6 paths, and the kernel APIs where soft-ifnets B> (such as carp(4)) and routing code (such as MROUTING) need to manipulate B> multicast group memberships. Looks like we need refcounting in IPv4, too. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Jan 25 21:06:04 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0AD0B16A404; Thu, 25 Jan 2007 21:06:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9CFB013C44C; Thu, 25 Jan 2007 21:06:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 624134B89D; Thu, 25 Jan 2007 15:40:52 -0500 (EST) Date: Thu, 25 Jan 2007 20:40:52 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Gleb Smirnoff In-Reply-To: <20070125183720.GB7922@cell.sick.ru> Message-ID: <20070125203807.S13293@fledge.watson.org> References: <20070125162422.GA7922@bestcom.ru> <45B8EB23.705@FreeBSD.org> <20070125183720.GB7922@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Bruce M. Simpson" , net@FreeBSD.org Subject: Re: rev. 1.94 of netinet/in.c broke CARP 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, 25 Jan 2007 21:06:04 -0000 On Thu, 25 Jan 2007, Gleb Smirnoff wrote: > B> > Before this change, most of the subsystems, that allocated multicast > B> >membership instances had freed is theirselves. I don't know about others, > B> >but at least CARP is broken now. It attempts to free a memory, that > B> >already has been freed. > B> > > B> I would suggest that the correct fix, for now, would be for carp(4) to > B> now *not* perform its own cleanup for the IPv4 groups it joins on member > B> interfaces. > > Unfortunately, this won't be a correct fix. In a scenario when the parent > interface stays on its place, but you are creating, attaching and destroying > a CARP interface, the multicast membership would not be left and memory > won't be freed. So, after the following sequence > > ifconfig fxp0 10.0.0.1/24 > ifconfig carp0 create > ifconfig carp0 vhid 1 10.0.0.2/24 > ifconfig carp0 destroy > > , we would still have a multicast membership on fxp0. > > B> The symptom here is that carp(4) needs to join a multicast group on its > B> member interface. When the interface goes away, the group membership is > B> now destroyed, at the netinet global level, by the netinet detach path B> > first. B> B> However, carp(4) is keeping its own imo_membership vector of > the B> addresses it joined on its member interfaces (rather than using the > one B> which netinet assigns to it in its attach path), and later tries to > free B> these memberships. B> B> netinet6 does not have the same problem > because in6 memberships are B> reference counted. B> B> The root problem is > that we should be using consistent semantics for B> both the IPv4 and IPv6 > paths, and the kernel APIs where soft-ifnets B> (such as carp(4)) and > routing code (such as MROUTING) need to manipulate B> multicast group > memberships. Architecturally, the right fix is that CARP needs to have a handler for ifnet destruction that always runs before the multicast address garbage collection. I'm pretty preoccupied for the next few days due to an impending paper deadline, so can't investigate further currently, but one way or the other that ordering dependency needs to be expressed. If done properly, CARP will always have released its multicast address before they are forceably removed. Having the reference count is good too, but what I describe should be sufficient regardless of the refcount. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Thu Jan 25 21:23:13 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C441816A402; Thu, 25 Jan 2007 21:23:13 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.freebsd.org (Postfix) with ESMTP id 49ECB13C44B; Thu, 25 Jan 2007 21:23:13 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id l0PLNAA6011307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jan 2007 00:23:11 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id l0PLNALV011306; Fri, 26 Jan 2007 00:23:10 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 26 Jan 2007 00:23:10 +0300 From: Gleb Smirnoff To: Robert Watson Message-ID: <20070125212310.GG7922@cell.sick.ru> References: <20070125162422.GA7922@bestcom.ru> <45B8EB23.705@FreeBSD.org> <20070125183720.GB7922@cell.sick.ru> <20070125203807.S13293@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070125203807.S13293@fledge.watson.org> User-Agent: Mutt/1.5.6i Cc: "Bruce M. Simpson" , net@FreeBSD.org Subject: Re: rev. 1.94 of netinet/in.c broke CARP 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, 25 Jan 2007 21:23:13 -0000 On Thu, Jan 25, 2007 at 08:40:52PM +0000, Robert Watson wrote: R> Architecturally, the right fix is that CARP needs to have a handler for R> ifnet destruction that always runs before the multicast address garbage R> collection. I'm pretty preoccupied for the next few days due to an R> impending paper deadline, so can't investigate further currently, but one R> way or the other that ordering dependency needs to be expressed. If done R> properly, CARP will always have released its multicast address before they R> are forceably removed. Having the reference count is good too, but what I R> describe should be sufficient regardless of the refcount. This means removing usage of EVENTHANDLER(9) and going back to exporting carp_ifdetach() and calling it directly from if_detach(). This is back out revision 1.255 of net/if.c. Not sure what is a right way... I am worried about that CARP is not the only subsystem in kernel that can join a multicast group on an ifnet, and keep a pointer to the multicast instance. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Jan 25 21:33:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25EAF16A406; Thu, 25 Jan 2007 21:33:32 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.freebsd.org (Postfix) with ESMTP id A41B213C44B; Thu, 25 Jan 2007 21:33:31 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.51.18] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1HACDm3Rcc-0006zQ; Thu, 25 Jan 2007 22:33:31 +0100 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Thu, 25 Jan 2007 22:33:10 +0100 User-Agent: KMail/1.9.5 References: <20070125162422.GA7922@bestcom.ru> <20070125203807.S13293@fledge.watson.org> <20070125212310.GG7922@cell.sick.ru> In-Reply-To: <20070125212310.GG7922@cell.sick.ru> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1765310.oDHRGgHRZ9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701252233.17309.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 X-Provags-ID2: V01U2FsdGVkX19I08y7gk0V+ds24FUKxqS/FXgHHeSRgKlWJq21KERtIigRUE4Z0sTcQWjuDm3vgad7lUuPNnXz2O/LEImzMSwMpQ8I8jiQPNXZjXpMdH1Jdg== Cc: "Bruce M. Simpson" , Robert Watson Subject: Re: rev. 1.94 of netinet/in.c broke CARP 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, 25 Jan 2007 21:33:32 -0000 --nextPart1765310.oDHRGgHRZ9 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 25 January 2007 22:23, Gleb Smirnoff wrote: > On Thu, Jan 25, 2007 at 08:40:52PM +0000, Robert Watson wrote: > R> Architecturally, the right fix is that CARP needs to have a handler > for R> ifnet destruction that always runs before the multicast address > garbage R> collection. I'm pretty preoccupied for the next few days due > to an R> impending paper deadline, so can't investigate further > currently, but one R> way or the other that ordering dependency needs > to be expressed. If done R> properly, CARP will always have released > its multicast address before they R> are forceably removed. Having the > reference count is good too, but what I R> describe should be > sufficient regardless of the refcount. > > This means removing usage of EVENTHANDLER(9) and going back to > exporting carp_ifdetach() and calling it directly from if_detach(). > This is back out revision 1.255 of net/if.c. Not sure what is a right > way... > > I am worried about that CARP is not the only subsystem in kernel > that can join a multicast group on an ifnet, and keep a pointer > to the multicast instance. pfsync might, but from a quick glance at this thread and code it seems=20 non-related. I'll look more closely later. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1765310.oDHRGgHRZ9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFuSIdXyyEoT62BG0RAvYZAJ4sxF8FIAc8ujb9g/DQjaNTA39DWgCbBzR+ WiIpdnP9NU2kGp0noOIQ0mA= =ZF/B -----END PGP SIGNATURE----- --nextPart1765310.oDHRGgHRZ9-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 25 22:00:10 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9634216A402; Thu, 25 Jan 2007 22:00:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 03FFA13C455; Thu, 25 Jan 2007 22:00:09 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 691B049839; Thu, 25 Jan 2007 17:00:08 -0500 (EST) Date: Thu, 25 Jan 2007 22:00:08 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Gleb Smirnoff In-Reply-To: <20070125212310.GG7922@cell.sick.ru> Message-ID: <20070125214956.J13293@fledge.watson.org> References: <20070125162422.GA7922@bestcom.ru> <45B8EB23.705@FreeBSD.org> <20070125183720.GB7922@cell.sick.ru> <20070125203807.S13293@fledge.watson.org> <20070125212310.GG7922@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Bruce M. Simpson" , net@FreeBSD.org Subject: Re: rev. 1.94 of netinet/in.c broke CARP 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, 25 Jan 2007 22:00:11 -0000 On Fri, 26 Jan 2007, Gleb Smirnoff wrote: > On Thu, Jan 25, 2007 at 08:40:52PM +0000, Robert Watson wrote: > R> Architecturally, the right fix is that CARP needs to have a handler for > R> ifnet destruction that always runs before the multicast address garbage > R> collection. I'm pretty preoccupied for the next few days due to an > R> impending paper deadline, so can't investigate further currently, but one > R> way or the other that ordering dependency needs to be expressed. If done > R> properly, CARP will always have released its multicast address before they > R> are forceably removed. Having the reference count is good too, but what I > R> describe should be sufficient regardless of the refcount. > > This means removing usage of EVENTHANDLER(9) and going back to exporting > carp_ifdetach() and calling it directly from if_detach(). This is back out > revision 1.255 of net/if.c. Not sure what is a right way... > > I am worried about that CARP is not the only subsystem in kernel that can > join a multicast group on an ifnet, and keep a pointer to the multicast > instance. Alternatively, we move to having two event handlers: one for general stack consumers to use, and a second one to do low level address and protocol cleanup. CARP would use the former, multicast address stuff the latter... Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Thu Jan 25 22:46:01 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE76E16A415 for ; Thu, 25 Jan 2007 22:46:01 +0000 (UTC) (envelope-from wishmaster@velnet.ru) Received: from mail.velnet.ru (mail.velnet.ru [88.210.53.179]) by mx1.freebsd.org (Postfix) with ESMTP id 884F513C441 for ; Thu, 25 Jan 2007 22:46:01 +0000 (UTC) (envelope-from wishmaster@velnet.ru) Received: from [213.141.131.138] (helo=localhost) by mail.velnet.ru with esmtp (Exim 4.30; FreeBSD) id 1HADRa-000IpY-4C for freebsd-net@freebsd.org; Fri, 26 Jan 2007 01:51:46 +0300 Date: Fri, 26 Jan 2007 01:47:28 +0300 From: Wishmaster X-Mailer: The Bat! (v2.12.00) X-Priority: 3 (Normal) Message-ID: <1582899958.20070126014728@velnet.ru> To: freebsd-net@freebsd.org In-Reply-To: <45B4BE90.20602@qwirky.net> References: <1458229821.20070120234257@velnet.ru> <45B28F37.7040100@delphij.net> <1651695163.20070122010957@velnet.ru> <45B4BE90.20602@qwirky.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re[2]: reproducible watchdog timeout in bge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Wishmaster List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 22:46:01 -0000 Hello Jeff, Monday, January 22, 2007, 4:39:28 PM, you wrote: JR> I have been unable to produce time outs with my current setup in JR> 6.2-Release. JR> bge0@pci3:0:0: class=0x020000 card=0x81491043 chip=0x165914e4 rev=0x11 JR> hdr=0x00 JR> vendor = 'Broadcom Corporation' JR> device = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express' JR> class = network JR> subclass = ethernet JR> Reading the PR, I attempted triggering this through CVSing and through JR> the above mentioned ping tests. JR> So far nothing. JR> The only issue I have seen using these NICs in 6.2R is if I nail up the JR> NIC at 100baseTX full-duplex I sometimes loose connectivity. Nothing JR> in the logs indicate watchdog timeouts or any other issue. I simply JR> brought the NIC back down to auto-neg and all seems fine. I am JR> assuming this is a incompatibility between the BGE and my switch, RS8000. JR> I have a Asus P5MT-S with dual BGE NIC's JR> Cheers, JR> Jeff JR> _______________________________________________ JR> freebsd-net@freebsd.org mailing list JR> http://lists.freebsd.org/mailman/listinfo/freebsd-net JR> To unsubscribe, send any mail to JR> "freebsd-net-unsubscribe@freebsd.org" pciconf says: bge0@pci3:0:0: class=0x020000 card=0x81491043 chip=0x165914e4 rev=0x21 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express' class = network subclass = ethernet bge1@pci4:0:0: class=0x020000 card=0x81491043 chip=0x165914e4 rev=0x21 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express' class = network subclass = ethernet So, if you have no troubles can you tell do you have smp kernel with apic and what distribution you are using? On my configuration I have dual core intel xeon 30xx series with SMP and APIC kernel (i386 distribution). This issue appears just after system boots up. If you have non-smp kernel can you try to recompile it with smp and apic support? p.s. motherboard asus p5m2/2gbl -- Best regards, Wishmaster mailto:wishmaster-velnet@yandex.ru From owner-freebsd-net@FreeBSD.ORG Thu Jan 25 22:50:42 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7488616A401 for ; Thu, 25 Jan 2007 22:50:42 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail4out.barnet.com.au (mail4.barnet.com.au [202.83.178.125]) by mx1.freebsd.org (Postfix) with ESMTP id 38E9813C461 for ; Thu, 25 Jan 2007 22:50:42 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail4out.barnet.com.au (Postfix, from userid 1001) id 997B137BB47; Fri, 26 Jan 2007 09:50:41 +1100 (EST) X-Viruscan-Id: <45B93441000148209CDE5C@BarNet> Received: from mail4auth.barnet.com.au (mail4.barnet.com.au [202.83.178.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail4.barnet.com.au (Postfix) with ESMTP id 6C23B424A6D; Fri, 26 Jan 2007 09:50:41 +1100 (EST) Received: from k7.mavetju (k7.mavetju.org [10.251.1.18]) by mail4auth.barnet.com.au (Postfix) with ESMTP id 263AF37BB58; Fri, 26 Jan 2007 09:50:41 +1100 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id EFB961A0; Fri, 26 Jan 2007 09:50:40 +1100 (EST) Date: Fri, 26 Jan 2007 09:50:40 +1100 From: Edwin Groothuis To: Yuri Lukin Message-ID: <20070125225040.GD90167@k7.mavetju> References: <1729.65.117.48.154.1169568902.squirrel@admintool.trueband.net> <20070124020027.GC90167@k7.mavetju> <20070124122525.M93545@swaggi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070124122525.M93545@swaggi.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: VLANs and DHCP 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, 25 Jan 2007 22:50:42 -0000 On Wed, Jan 24, 2007 at 07:36:51AM -0500, Yuri Lukin wrote: > On Tue, Jan 23, 2007 at 04:15:02PM -0000, jhall@vandaliamo.net wrote: > > I currently administer a system which has two DHCP servers on two > > different VLANs. Unfortunately, the two servers are not playing together > > well and some comptuers are receiving IP addresses on the wrong network. > > So, with our phone vendor's blessing, I am trying to move all of the DHCP > > services to the FreeBSD server. > > > > The computers on the network are supposed to receive an IP address on the > > default vlan and the phones are supposed to receive an IP address on their > > vlan. > > > > Essentially what happens when a phone is booted, the phone receives an IP > > address on the default VLAN, releases that address and then requests an IP > > address on the appropriate VLAN. > > Just a thought but if your switch properly tags the packets from the voice and > data Vlans, the broadcasts from the IP Phones should not cross over to the > data Vlan. We have dozens of customers setup this way and they are not having > any problems. Not sure what type of switches you are using but I would check > your switchport configuration (assuming managed switch). Look at the behaviour of the ISC-dhcrelay. It's euhm... very interesting if you have multiple ethernet cards in the server. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://weblog.barnet.com.au/edwin/ From owner-freebsd-net@FreeBSD.ORG Thu Jan 25 23:36:16 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2427C16A402 for ; Thu, 25 Jan 2007 23:36:16 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id AC7F613C46A for ; Thu, 25 Jan 2007 23:36:15 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l0PNB6ks083115; Fri, 26 Jan 2007 00:11:06 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l0PNAqlL053940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jan 2007 00:10:53 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l0PNAqUL044939; Fri, 26 Jan 2007 00:10:52 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l0PNAqBV044938; Fri, 26 Jan 2007 00:10:52 +0100 (CET) (envelope-from ticso) Date: Fri, 26 Jan 2007 00:10:52 +0100 From: Bernd Walter To: freebsd-usb@freebsd.org, freebsd-net@freebsd.org Message-ID: <20070125231051.GE44259@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: Bernd Walter Subject: Anyone working on RTL8187 USB WLAN support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 23:36:16 -0000 Just as the subject says. Devices are a bit cheaper to get than ralink based. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-net@FreeBSD.ORG Fri Jan 26 03:18:09 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1116B16A703 for ; Fri, 26 Jan 2007 03:18:05 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id CE09713C483 for ; Fri, 26 Jan 2007 03:18:04 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 21AE26E2BA; Fri, 26 Jan 2007 14:18:01 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id B84F08C07; Fri, 26 Jan 2007 14:18:02 +1100 (EST) Date: Fri, 26 Jan 2007 14:18:01 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Robin Gruyters In-Reply-To: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net> Message-ID: <20070126141754.X7697@besplex.bde.org> References: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] 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, 26 Jan 2007 03:18:09 -0000 On Thu, 25 Jan 2007, Robin Gruyters wrote: > On 13-Jan-2007 Oleg Bulyzhin wrote: >> >> > Could you please test attached patch? It should fix ierrs issue and >> should not >> > break link events (would be fine to test it: unplug/plug cable, try to >> change >> > media with ifconfig, change media on other end of wire). > > Just wondering will this patch/update be available for RELENG_6? I have the > same problems here with 3 of our servers. > ... > And here the netstat interface statistics: > [...] > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs > Coll > ... > bge0 1500 00:12:79:94:ed:12 11343768 2114510 20564242 0 > 0 > bge1* 1500 00:12:79:94:ed:11 0 0 0 0 > 0 I think the bug fixed by the patch couldn't cause so many errors (unless Ipkts has overflowed and the uptime more than a week). Bruce From owner-freebsd-net@FreeBSD.ORG Fri Jan 26 06:47:16 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD21616A402 for ; Fri, 26 Jan 2007 06:47:16 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.freebsd.org (Postfix) with ESMTP id D2FC313C4B5 for ; Fri, 26 Jan 2007 06:47:15 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from impact.jinmei.org (unknown [IPv6:2001:200:1b1:1010:805d:f488:329:8dc5]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9903B73019; Fri, 26 Jan 2007 15:47:13 +0900 (JST) Date: Fri, 26 Jan 2007 15:47:08 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Frank Behrens" In-Reply-To: <200701251309.l0PD9S5W071724@pinky.frank-behrens.de> References: <200701251309.l0PD9S5W071724@pinky.frank-behrens.de> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: When IPv6 temporary addresses are regenerated? 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, 26 Jan 2007 06:47:16 -0000 >>>>> On Thu, 25 Jan 2007 14:09:28 +0100, >>>>> "Frank Behrens" said: > I have an IPv6 setup with temporary addresses (RFC3041). To switch this on I used "sysctl > net.inet6.ip6.use_tempaddr=1". The temporary address is generated and meanwhile expired. > Does anybody know, when this address is expected to be regenerated? As described in RFC3041 (and in its successor draft), When a temporary address becomes deprecated, a new one should be generated. (from section 3.4 of RFC3041). FreeBSD should behave that way (on my laptop running 6.2-PRERELEASE, I have two temporary addresses; one is preferred and the other is deprecated). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. if you want to get a useful answer, it's generally advisable not to hide details as in xxx.xxx.xx.xx, especially when you are not certain about some aspect of the matter - because such details are often a key to the answer. If you do not want to disclose your internal information but want to get an answer, I'd recommend you to reproduce the situation using prefixes for documentations/examples like 192.0.2.0/24 and 2001:db8::/32 and show every detail. > My current interface configuration is > vlan0: flags=8843 mtu 1500 > inet xxx.xxx.xx.xx netmask 0xffffff00 broadcast xxx.xxx.xxx.xxx > inet6 fe80::211:xxxx:xxxx:xxxx%vlan0 prefixlen 64 scopeid 0x5 > inet6 2xxx:xxxx:xxxx:: prefixlen 64 anycast > inet6 2xxx:xxxx:xxxx:0:211:2fff:xxxx:xxxx prefixlen 64 > inet6 2xxx:xxxx:xxxx:0:54b:5960:xxxx:xxxx prefixlen 64 deprecated autoconf temporary pltime 0 vltime 509995 From owner-freebsd-net@FreeBSD.ORG Fri Jan 26 07:59:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DEC3116A401 for ; Fri, 26 Jan 2007 07:59:22 +0000 (UTC) (envelope-from r.gruyters@yirdis.nl) Received: from mail.yirdis.nl (82-148-208-109.fiber.unet.nl [82.148.208.109]) by mx1.freebsd.org (Postfix) with ESMTP id 75D9C13C483 for ; Fri, 26 Jan 2007 07:59:21 +0000 (UTC) (envelope-from r.gruyters@yirdis.nl) Received: from server.yirdis.net (localhost [127.0.0.1]) by mail.yirdis.nl (8.13.6/8.13.6) with ESMTP id l0Q7xJZC028161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jan 2007 08:59:19 +0100 (CET) (envelope-from r.gruyters@yirdis.nl) Received: (from www@localhost) by server.yirdis.net (8.13.6/8.13.6/Submit) id l0Q7xI12028160; Fri, 26 Jan 2007 08:59:18 +0100 (CET) (envelope-from r.gruyters@yirdis.nl) X-Authentication-Warning: server.yirdis.net: www set sender to r.gruyters@yirdis.nl using -f Received: from hp-xw4100-01.yirdis.nl (hp-xw4100-01.yirdis.nl [10.8.0.27]) by webmail.yirdis.nl (Horde MIME library) with HTTP; Fri, 26 Jan 2007 08:59:18 +0100 Message-ID: <20070126085918.710xjsopz48kso4w@webmail.yirdis.nl> Date: Fri, 26 Jan 2007 08:59:18 +0100 From: Robin Gruyters To: Bruce Evans References: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net> <20070126141754.X7697@besplex.bde.org> In-Reply-To: <20070126141754.X7697@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) / FreeBSD-5.4 X-Virus-Scanned: OK Cc: freebsd-net@freebsd.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] 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, 26 Jan 2007 07:59:22 -0000 Quoting Bruce Evans : > On Thu, 25 Jan 2007, Robin Gruyters wrote: > >> On 13-Jan-2007 Oleg Bulyzhin wrote: >>> >>>> Could you please test attached patch? It should fix ierrs issue and >>> should not >>>> break link events (would be fine to test it: unplug/plug cable, try >>> to change >>>> media with ifconfig, change media on other end of wire). >> >> Just wondering will this patch/update be available for RELENG_6? I =20 >> have the same problems here with 3 of our servers. >> ... >> And here the netstat interface statistics: >> [...] >> Name Mtu Network Address Ipkts Ierrs Opkts =20 >> Oerrs Coll >> ... >> bge0 1500 00:12:79:94:ed:12 11343768 2114510 =20 >> 20564242 0 0 >> bge1* 1500 00:12:79:94:ed:11 0 0 0 0= 0 > > I think the bug fixed by the patch couldn't cause so many errors (unless > Ipkts has overflowed and the uptime more than a week). > The server was up almost for 11 days. [...] 8:56AM up 10 days, 17:13, 1 user, load averages: 0.03, 0.04, 0.02 [...] - Robin From owner-freebsd-net@FreeBSD.ORG Fri Jan 26 11:39:58 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EB0516A501 for ; Fri, 26 Jan 2007 11:39:58 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.166]) by mx1.freebsd.org (Postfix) with ESMTP id 8514E13C483 for ; Fri, 26 Jan 2007 11:39:56 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.13.8/8.13.8) with ESMTP id l0PIfkax060528 for ; Fri, 26 Jan 2007 01:41:46 +0700 (KRAT) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.13.8/8.13.8/Submit) id l0PIfknl060527 for net@freebsd.org; Fri, 26 Jan 2007 01:41:46 +0700 (KRAT) (envelope-from eugen) Date: Fri, 26 Jan 2007 01:41:46 +0700 From: Eugene Grosbein To: net@freebsd.org Message-ID: <20070125184146.GA60481@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: Subject: interface metric & quagga 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, 26 Jan 2007 11:39:58 -0000 Hi! 'route -n monitor' shows me that 'ifconfig up' command produces RTM_NEWADDR, RTM_ADD and RTM_IFINFO message. RTM_NEWADDR contains 'metric 0' regardless of interface metric value set with ifconfig before. quagga, since version 0.99.3, takes metric value from RTM_NEWADDR message and this value overrides right interface metric learned by quagga a milisecond before. Then it passes zero interface metric to ripd that uses interface metric as hop count increment for RIP-learned routes. This effectively breaks RIPv2 for FreeBSD (quagga-0.99.2 and older versions do not use metric from RTM_NEWADDR and work), perhaps RIPv1 too. Verified with RELENG_4 and RELENG_6. Is it kernel bug or quagga bug? I also suggest to include next patch to the Ports tree if no objections. It restores RIP support. --- zebra/kernel_socket.c.orig Fri Jan 26 01:10:06 2007 +++ zebra/kernel_socket.c Fri Jan 26 01:10:17 2007 @@ -585,8 +585,6 @@ if (ifnlen && strncmp (ifp->name, ifname, INTERFACE_NAMSIZ)) isalias = 1; - ifp->metric = ifam->ifam_metric; - /* Add connected address. */ switch (sockunion_family (&addr)) { Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Jan 26 11:44:52 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3BADD16A405; Fri, 26 Jan 2007 11:44:52 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.freebsd.org (Postfix) with ESMTP id 9F55913C481; Fri, 26 Jan 2007 11:44:51 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id l0QBinUL016534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jan 2007 14:44:49 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id l0QBini4016533; Fri, 26 Jan 2007 14:44:49 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 26 Jan 2007 14:44:49 +0300 From: Gleb Smirnoff To: Robert Watson Message-ID: <20070126114449.GM7922@cell.sick.ru> References: <20070125162422.GA7922@bestcom.ru> <45B8EB23.705@FreeBSD.org> <20070125183720.GB7922@cell.sick.ru> <20070125203807.S13293@fledge.watson.org> <20070125212310.GG7922@cell.sick.ru> <20070125214956.J13293@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070125214956.J13293@fledge.watson.org> User-Agent: Mutt/1.5.6i Cc: "Bruce M. Simpson" , net@FreeBSD.org Subject: Re: rev. 1.94 of netinet/in.c broke CARP 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, 26 Jan 2007 11:44:52 -0000 On Thu, Jan 25, 2007 at 10:00:08PM +0000, Robert Watson wrote: R> >On Thu, Jan 25, 2007 at 08:40:52PM +0000, Robert Watson wrote: R> >R> Architecturally, the right fix is that CARP needs to have a handler for R> >R> ifnet destruction that always runs before the multicast address garbage R> >R> collection. I'm pretty preoccupied for the next few days due to an R> >R> impending paper deadline, so can't investigate further currently, but R> >one R> >R> way or the other that ordering dependency needs to be expressed. If R> >done R> >R> properly, CARP will always have released its multicast address before R> >they R> >R> are forceably removed. Having the reference count is good too, but what R> >I R> >R> describe should be sufficient regardless of the refcount. R> > R> >This means removing usage of EVENTHANDLER(9) and going back to exporting R> >carp_ifdetach() and calling it directly from if_detach(). This is back out R> >revision 1.255 of net/if.c. Not sure what is a right way... R> > R> >I am worried about that CARP is not the only subsystem in kernel that can R> >join a multicast group on an ifnet, and keep a pointer to the multicast R> >instance. R> R> Alternatively, we move to having two event handlers: one for general stack R> consumers to use, and a second one to do low level address and protocol R> cleanup. CARP would use the former, multicast address stuff the latter... Well, I am just not sure that the new coding strategy, chosen by Bruce is correct. We used to have every subsystem to join multicast membership itself, and leave it itself. Due to bugs in the Ethernet layer (?) on interface detach some multicast memberships were not left and thus memory was leaking. Is adding a generic GC function a correct way or was it better to just fix the buggy layer, that forgot about its multicast memberships? ATM, I can fix the CARP in the following way: 1) Call multicast cleanup, if we are destroying carp interface itself. 2) Don't call multicast cleanup, if we are called through EVENTHANDLER(9) since parent is detaching. Would this fix be ok? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Jan 26 15:38:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 394D216A404 for ; Fri, 26 Jan 2007 15:38:18 +0000 (UTC) (envelope-from frank@pinky.sax.de) Received: from pinky.frank-behrens.de (pinky.frank-behrens.de [82.139.199.24]) by mx1.freebsd.org (Postfix) with ESMTP id 983D213C46E for ; Fri, 26 Jan 2007 15:38:15 +0000 (UTC) (envelope-from frank@pinky.sax.de) Received: from [192.168.20.32] (sun.behrens [192.168.20.32]) by pinky.frank-behrens.de (8.13.8/8.13.8) with ESMTP id l0QFcDNa002222 for ; Fri, 26 Jan 2007 16:38:13 +0100 (CET) (envelope-from frank@pinky.sax.de) Message-Id: <200701261538.l0QFcDNa002222@pinky.frank-behrens.de> From: "Frank Behrens" To: freebsd-net@freebsd.org Date: Fri, 26 Jan 2007 16:38:14 +0100 MIME-Version: 1.0 Priority: normal In-reply-to: <200701251309.l0PD9S5W071724@pinky.frank-behrens.de> X-mailer: Pegasus Mail for Windows (4.31, DE v4.31 R1) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT Content-description: Mail message body Subject: Re: When IPv6 temporary addresses are regenerated? 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, 26 Jan 2007 15:38:18 -0000 As nobody made a reply I will reply myself. ;-) Frank Behrens wrote on 25 Jan 2007 14:09: > I have an IPv6 setup with temporary addresses (RFC3041). To switch this on I used "sysctl > net.inet6.ip6.use_tempaddr=1". The temporary address is generated and meanwhile expired. > > Does anybody know, when this address is expected to be regenerated? Short answer after digging in the sources: A new temporary address is regenerated, when there is another address configured with flag "autoconf" (and temporary address is deprecated). The specification says, the temporary addresses should be generated for interfaces setup with stateless address autoconfiguration. What for a setup do I have? My FreeBSD router is connected via PPP, so I inserted the assigned _prefix_ in rc.conf. Now I have a half autoconfiguration, the prefix is assigned statically combined with IEEE identifiers. You see that in my current config: > inet6 2xxx:xxxx:xxxx:0:211:2fff:xxxx:xxxx prefixlen 64 > inet6 2xxx:xxxx:xxxx:0:54b:5960:xxxx:xxxx prefixlen 64 deprecated autoconf temporary pltime 0 vltime 509995 But we can change the autoconf interface attribute with the undocumented ifconfig(8) flag with same name. In that case all works as expected. To achieve this as simple as possible I changed my rc.conf from ipv6_prefix_vlan0="2xxx:xxx:xxxx:x" to ipv6_ifconfig_vlan0="2xxx:xxx:xxxx:x:: prefixlen 64 eui64 autoconf" The site effect is, that there is now no automatic assigment of a 64 bit anycast address for this interface, but that does not matter in my setup. So my problem is solved, maybe someone can document the behaviour. Gruß, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From owner-freebsd-net@FreeBSD.ORG Fri Jan 26 17:30:19 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1B2816A408 for ; Fri, 26 Jan 2007 17:30:18 +0000 (UTC) (envelope-from ericx@vineyard.net) Received: from smtp1.vineyard.net (a1.vineyard.net [204.17.195.95]) by mx1.freebsd.org (Postfix) with ESMTP id 9ED7313C4AD for ; Fri, 26 Jan 2007 17:30:18 +0000 (UTC) (envelope-from ericx@vineyard.net) Received: from localhost (loopback [127.0.0.1]) by smtp1.vineyard.net (Postfix) with ESMTP id BD8711581A7B for ; Fri, 26 Jan 2007 12:06:37 -0500 (EST) Received: from smtp1.vineyard.net ([127.0.0.1]) by localhost (ace1.vineyard.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10571-01-5 for ; Fri, 26 Jan 2007 12:06:32 -0500 (EST) Received: from [204.17.195.104] (fortiva.vineyard.net [204.17.195.104]) by smtp1.vineyard.net (Postfix) with ESMTP id 114D415818EA for ; Fri, 26 Jan 2007 11:47:20 -0500 (EST) Message-ID: <45BA3083.7020006@vineyard.net> Date: Fri, 26 Jan 2007 11:46:59 -0500 From: "Eric W. Bates" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-ace1 at Vineyard.NET Subject: About NAT Traversal 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, 26 Jan 2007 17:30:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Can someone please refer me to some documentation describing how to implement NAT Traversal? - -- Eric W. Bates ericx@vineyard.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFujCDD1roJTQ4LlERAsKOAKCQMNTdzlR/tW130s0hWKqb2j3wkgCgk4Sy 7+/Hv8jHZHj4dOcgNbbM+lE= =OpF/ -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri Jan 26 18:39:01 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B49C16A403 for ; Fri, 26 Jan 2007 18:39:01 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 6488C13C494 for ; Fri, 26 Jan 2007 18:38:59 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 0413E96850; Fri, 26 Jan 2007 13:38:58 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Fri, 26 Jan 2007 13:38:58 -0500 X-Sasl-enc: SOOqJi9tnDeX0j5QYuuUmH92w9/9nlEVVMvLt0zQ16kW 1169836737 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 22485165F0; Fri, 26 Jan 2007 13:38:56 -0500 (EST) Message-ID: <45BA4ABD.5040402@FreeBSD.org> Date: Fri, 26 Jan 2007 18:38:53 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Eugene Grosbein References: <20070125184146.GA60481@grosbein.pp.ru> In-Reply-To: <20070125184146.GA60481@grosbein.pp.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: interface metric & quagga 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, 26 Jan 2007 18:39:01 -0000 Eugene Grosbein wrote: > RTM_NEWADDR contains 'metric 0' regardless of interface metric > value set with ifconfig before. quagga, since version 0.99.3, > takes metric value from RTM_NEWADDR message and this value overrides > right interface metric learned by quagga a milisecond before. > Then it passes zero interface metric to ripd that uses interface > metric as hop count increment for RIP-learned routes. > This effectively breaks RIPv2 for FreeBSD (quagga-0.99.2 and older > versions do not use metric from RTM_NEWADDR and work), perhaps RIPv1 too. > It's a mixed issue. FreeBSD does not use the interface metric, so routing daemons shouldn't use that field. However, many routing implementations use a metric or distance of 0 to indicate a directly-connected route or interface route, so it has special meaning. We could deal with this situation better by explicitly setting the metric to an invalid value. If/when we implemented equal-cost multipath, or source address selection policies, then we should use this field. > Verified with RELENG_4 and RELENG_6. > Is it kernel bug or quagga bug? > > I also suggest to include next patch to the Ports tree > if no objections. It restores RIP support. > I'd rewrite the patch to wrap the assignment in #ifndef __FreeBSD__ so that it can be taken upstream more easily. If/when we do equal-cost multipath or source policy we can bump __FreeBSD_version. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Fri Jan 26 18:56:42 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75D1E16A406 for ; Fri, 26 Jan 2007 18:56:42 +0000 (UTC) (envelope-from phi@evilphi.com) Received: from mail.twinthornes.com (mail.twinthornes.com [65.75.198.147]) by mx1.freebsd.org (Postfix) with ESMTP id 582DF13C4A3 for ; Fri, 26 Jan 2007 18:56:42 +0000 (UTC) (envelope-from phi@evilphi.com) Received: from [10.9.70.4] (c-24-20-142-99.hsd1.or.comcast.net [24.20.142.99]) by mail.twinthornes.com (Postfix) with ESMTP id 0810249; Fri, 26 Jan 2007 10:34:08 -0800 (PST) Message-ID: <45BA499D.2060609@evilphi.com> Date: Fri, 26 Jan 2007 10:34:05 -0800 From: Darren Pilgrim User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Eric W. Bates" References: <45BA3083.7020006@vineyard.net> In-Reply-To: <45BA3083.7020006@vineyard.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: About NAT Traversal 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, 26 Jan 2007 18:56:42 -0000 Eric W. Bates wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Can someone please refer me to some documentation describing how to > implement NAT Traversal? In what context? The methods required to traverse a NAT are highly protocol-specific. -- Darren Pilgrim From owner-freebsd-net@FreeBSD.ORG Fri Jan 26 19:16:26 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E87B16A400 for ; Fri, 26 Jan 2007 19:16:26 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from arwen.teledomenet.gr (arwen.teledomenet.gr [213.142.128.58]) by mx1.freebsd.org (Postfix) with ESMTP id C732213C49D for ; Fri, 26 Jan 2007 19:16:25 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from iris ([192.168.1.71]) by arwen.teledomenet.gr (8.12.10/8.12.10) with ESMTP id l0QBwlm1024405 for ; Fri, 26 Jan 2007 13:58:47 +0200 From: Nikos Vassiliadis Date: Fri, 26 Jan 2007 14:01:09 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Disposition: inline To: net@freebsd.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200701261401.09832.nvass@teledomenet.gr> Cc: Subject: ng_pptpgre problems: tcp connections reset unexpectedly 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, 26 Jan 2007 19:16:26 -0000 Hello everybody, It seems that tcp connections over pptp reset unexpectedly. I have tried several things such as connecting from a FBSD-4 to a FBSD-6, connecting from a FBSD-[46] to a Cisco router(*). There are times which the client box gets from the other peer an echo-request msg, which is not supposed to happen while downloading. Perhaps it's relevant to this: 11:31:40.887739 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20702393:20703805(1412) ack 1 win 5792 11:31:40.887859 IP 134.76.12.3.56123 > 213.142.137.253.64016: P 20703805:20705217(1412) ack 1 win 5792 11:31:40.888005 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20705217:20706629(1412) ack 1 win 5792 11:31:40.888217 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20706629:20708041(1412) ack 1 win 5792 11:31:40.888352 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20708041:20709453(1412) ack 1 win 5792 11:31:40.888660 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20709453:20710865(1412) ack 1 win 5792 11:31:40.888966 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20710865:20712277(1412) ack 1 win 5792 (*) the result is always the same. What i have not tried, is a newer mpd, Alexander Motin seems to maintain mpd very actively, he sends a patch every 5 minutes or so:) I am using at the moment 6.2-PRE, just a few days before RELEASE, and mpd-3.18_4. Could you please help? any workarounds, tunables, suggestions? It's my connection to the internet and from time to time I need to download something bigger than a few megs... Thanks in advance, Nikos root:2:~/tst1# fetch ftp://ftp2.de.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-disc1.iso; date 6.2-RELEASE-i386-disc1.iso 3% of 573 MB 185 kBps 50m56s fetch: transfer timed out fetch: 6.2-RELEASE-i386-disc1.iso appears to be truncated: 20702208/601229312 bytes Fri Jan 26 11:31:40 EET 2007 netstat -m: 11:31:38 139/521/660 mbufs in use (current/cache/total) 65/291/356/17088 mbuf clusters in use (current/cache/total/max) 65/204 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 164K/712K/877K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/7/4528 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 2016 calls to protocol drain routines 11:31:39 141/519/660 mbufs in use (current/cache/total) 65/291/356/17088 mbuf clusters in use (current/cache/total/max) 65/204 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 165K/711K/877K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/7/4528 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 2016 calls to protocol drain routines 11:31:40 179/481/660 mbufs in use (current/cache/total) 65/291/356/17088 mbuf clusters in use (current/cache/total/max) 65/204 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 174K/702K/877K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/7/4528 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 2016 calls to protocol drain routines 11:31:41 70/590/660 mbufs in use (current/cache/total) 66/290/356/17088 mbuf clusters in use (current/cache/total/max) 66/203 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 149K/727K/877K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/7/4528 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 2016 calls to protocol drain routines tcpdump.ng0: 11:31:40.797285 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20695333:20696745(1412) ack 1 win 5792 11:31:40.797294 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20696745 win 32476 11:31:40.797697 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20696745:20698157(1412) ack 1 win 5792 11:31:40.797780 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20698157 win 33182 11:31:40.798589 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20698157:20699569(1412) ack 1 win 5792 11:31:40.798739 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20699569:20700981(1412) ack 1 win 5792 11:31:40.798748 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20700981 win 32476 11:31:40.798877 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20700981:20702393(1412) ack 1 win 5792 11:31:40.798924 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20702393 win 33182 11:31:40.859025 IP 213.142.137.253.64016 > 134.76.12.3.56123: R 1:1(0) ack 20702393 win 33182 11:31:40.887739 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20702393:20703805(1412) ack 1 win 5792 11:31:40.887859 IP 134.76.12.3.56123 > 213.142.137.253.64016: P 20703805:20705217(1412) ack 1 win 5792 11:31:40.888005 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20705217:20706629(1412) ack 1 win 5792 11:31:40.888217 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20706629:20708041(1412) ack 1 win 5792 11:31:40.888352 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20708041:20709453(1412) ack 1 win 5792 11:31:40.888660 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20709453:20710865(1412) ack 1 win 5792 11:31:40.888966 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20710865:20712277(1412) ack 1 win 5792 11:31:40.889120 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20712277:20713689(1412) ack 1 win 5792 11:31:40.889424 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20713689:20715101(1412) ack 1 win 5792 11:31:40.890062 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20715101:20716513(1412) ack 1 win 5792 11:31:40.890204 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20716513:20717925(1412) ack 1 win 5792 11:31:40.890488 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20717925:20719337(1412) ack 1 win 5792 11:31:40.890616 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20719337:20720749(1412) ack 1 win 5792 11:31:40.948622 IP 134.76.12.3.21 > 213.142.137.253.63090: P 3351:3387(36) ack 241 win 5792 11:31:40.948922 IP 213.142.137.253.63090 > 134.76.12.3.21: F 241:241(0) ack 3387 win 33182 11:31:41.038701 IP 134.76.12.3.21 > 213.142.137.253.63090: P 3387:3424(37) ack 242 win 5792 11:31:41.038728 IP 213.142.137.253.63090 > 134.76.12.3.21: R 1015843767:1015843767(0) win 0 11:31:41.039995 IP 134.76.12.3.21 > 213.142.137.253.63090: F 3424:3424(0) ack 242 win 5792 tcpdump.fxp0: 11:31:40.794914 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37741, ack 25863, length 24: IP [|ip] 11:31:40.795396 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.795399 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37742, ack 25863, length 24: IP [|ip] 11:31:40.795486 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25864, ack 37741, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20688273 win 32476 11:31:40.795684 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.795688 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37743, ack 25863, length 24: IP [|ip] 11:31:40.795782 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25865, ack 37742, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20689685 win 33182 11:31:40.795826 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.795830 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37744, ack 25863, length 24: IP [|ip] 11:31:40.795972 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.796003 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25866, ack 37744, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20692509 win 32476 11:31:40.796109 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37745, ack 25863, length 24: IP [|ip] 11:31:40.796604 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.796607 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37746, ack 25865, length 24: IP [|ip] 11:31:40.796757 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25867, ack 37745, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20693921 win 33182 11:31:40.796995 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.796999 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37747, ack 25865, length 24: IP [|ip] 11:31:40.797269 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.797272 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37748, ack 25866, length 24: IP [|ip] 11:31:40.797303 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25868, ack 37747, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20696745 win 32476 11:31:40.797679 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.797793 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25869, ack 37748, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20698157 win 33182 11:31:40.798073 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37749, ack 25868, length 24: IP [|ip] 11:31:40.798565 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.798568 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37750, ack 25868, length 24: IP [|ip] 11:31:40.798722 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.798726 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37751, ack 25868, length 24: IP [|ip] 11:31:40.798759 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25870, ack 37750, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20700981 win 32476 11:31:40.798864 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.798935 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25871, ack 37751, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20702393 win 33182 11:31:40.859053 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25872, length 56: IP 213.142.137.253.64016 > 134.76.12.3.56123: R 1:1(0) ack 20702393 win 33182 11:31:40.887217 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37752, ack 25872, length 24: IP [|ip] 11:31:40.887703 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.887706 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37753, ack 25872, length 24: IP [|ip] 11:31:40.887844 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.887846 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37754, ack 25872, length 24: IP [|ip] 11:31:40.887990 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.887993 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37755, ack 25872, length 24: IP [|ip] 11:31:40.888201 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.888204 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37756, ack 25872, length 24: IP [|ip] 11:31:40.888336 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.888340 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37757, ack 25872, length 24: IP [|ip] 11:31:40.888645 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.888647 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37758, ack 25872, length 24: IP [|ip] 11:31:40.888950 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.888954 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37759, ack 25872, length 24: IP [|ip] 11:31:40.889104 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.889108 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37760, ack 25872, length 24: IP [|ip] 11:31:40.889412 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.889554 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37761, ack 25872, length 24: IP [|ip] 11:31:40.890047 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.890050 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37762, ack 25872, length 24: IP [|ip] 11:31:40.890188 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.890191 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37763, ack 25872, length 24: IP [|ip] 11:31:40.890473 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.890476 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37764, ack 25872, length 24: IP [|ip] 11:31:40.890605 IP 10.1.1.233 > 192.168.1.71: gre 11:31:40.892035 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, ack 37764, no-payload, length 12 11:31:40.948594 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37765, ack 25872, length 108: IP 134.76.12.3.21 > 213.142.137.253.63090: P 3351:3387(36) ack 241 win 5792 11:31:40.948945 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25873, ack 37765, length 72: IP 213.142.137.253.63090 > 134.76.12.3.21: F 241:241(0) ack 3387 win 33182 11:31:40.966187 IP6 fe80::200:b4ff:fe93:32c1 > ff02::1:ff00:193: ICMP6, neighbor solicitation, who has 2001:610:240:0:53::193, length 32 11:31:41.038668 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37766, ack 25873, length 109: IP 134.76.12.3.21 > 213.142.137.253.63090: P 3387:3424(37) ack 242 win 5792 11:31:41.038747 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25874, ack 37766, length 60: IP 213.142.137.253.63090 > 134.76.12.3.21: R 1015843767:1015843767(0) win 0 11:31:41.039984 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37767, ack 25874, length 72: IP 134.76.12.3.21 > 213.142.137.253.63090: F 3424:3424(0) ack 242 win 5792 11:31:41.045027 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, ack 37767, no-payload, length 12 11:31:41.222816 802.1d config 8000.00:05:1a:b3:80:80.8018 root 8000.00:05:1a:b3:80:80 pathcost 0 age 0 max 20 hello 2 fdelay 15 From owner-freebsd-net@FreeBSD.ORG Fri Jan 26 23:30:51 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD91516A401 for ; Fri, 26 Jan 2007 23:30:51 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.freebsd.org (Postfix) with ESMTP id B2CD913C483 for ; Fri, 26 Jan 2007 23:30:51 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from [192.168.2.119] (hornet.kitchenlab.org [64.142.31.105]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l0QNUnNe020687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jan 2007 15:30:50 -0800 Message-ID: <45BA8F19.70807@freebsd.org> Date: Fri, 26 Jan 2007 15:30:33 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121073244.GA80811@zibbi.meraka.csir.co.za> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3DB7C2120A0DC897F9361150" Cc: freebsd-net@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-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: Fri, 26 Jan 2007 23:30:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3DB7C2120A0DC897F9361150 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If memory serves me right, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 wrote: >>>>>> On Sun, 21 Jan 2007 09:32:44 +0200,=20 >>>>>> John Hay said: >=20 >>> There's another workaround for people stuck in this situation and who= >>> aren't in a position to try this diff. That is to manually install >>> the host route like this: >>> >>> # route add -host -inet6 aaaa:bbbb:cccc:dddd::2 -interface gif0 -nost= atic -llinfo >>> >>> Comments? >=20 >> Well it seems that even my stuff does not always work perfectly with t= hat >> change (1.48.2.15), so maybe we should revert it and I will search for= >> yet other ways to make FreeBSD's IPv6 code to actually work for our st= uff. >=20 >> My "stuff" is a wireless IPv6 only network running in adhoc mode with >> olsrd as the routing protocol. The problem is that all nodes on a subn= et >> cannot "see" each other, so olsrd needs to add routes to a node throug= h >> another node. Sometimes, just to complicate matters a little more, you= >> would want to have more than one network card in a host, all with the = same >> subnet address. (For instance on a high site, with sector antennas.) >=20 >> The case that I found that still does not work reliably, is if olsrd a= dd >> the route and route is not immediately used, then the nd code will tim= e >> it out and remove it. >=20 > I think I'm responsible for the troubles. I've been thinking about > how to meet all the requests, and concluded that it's more complicated > than I originally thought. >=20 > I've come across an idea that may solve the problems, but I'll need > more time to implement and test it. >=20 > At the moment, I suggest reverting the 1.48.2.16 change for those who > simply wanted a gif to work. Based on these comments above, I've reverted rev. 1.67, 1.68, 1.69, and 1.70 of nd.c on HEAD. After a bunch more testing I've convinced myself that I think this will solve the problems that we have been seeing, and possibly why some other people's testing yielded counter-intitive results. I'll MFC to STABLE in 3 days. Commit message below... Bruce ----- bmah 2007-01-26 23:22:58 UTC FreeBSD src repository Modified files: sys/netinet6 nd6.c Log: Revert nd6.c revs. 1.67, 1.68, 1.69, 1.70 in an attempt to unbreak IPv6 over point-to-point gif(4) tunnels. These revisions caused a host route to the destination of a point-to-point gif(4) interface to not get installed when the interface= and destination addresses were assigned. This caused "no route to host" errors when trying to send traffic over the interface. The first packet arriving inbound over the tunnel, however, would cause the correct route to get installed, allowing subsequent outbound traffic to be routed correctly. gif(4) interfaces with prefix lengths of less than 128 bits (i.e. no explicit destination address assigned) were not affected by this bug. This bug fix is a possible candidate for a 6.2-RELEASE errata note. Approved by: jhay (original committer) Discussed with: jhay, JINMEI Tatuya MFC after: 3 days Revision Changes Path 1.74 +1 -1 src/sys/netinet6/nd6.c --------------enig3DB7C2120A0DC897F9361150 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.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFuo8f2MoxcVugUsMRAs0oAJ9zFL6y0GM0cv4pspAM2evTl0lzJACfXpR0 BieEAS33m9kJadCEd048LsQ= =eLoT -----END PGP SIGNATURE----- --------------enig3DB7C2120A0DC897F9361150-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 27 03:50:18 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E71816A4A6 for ; Sat, 27 Jan 2007 03:50:18 +0000 (UTC) (envelope-from mav@alkar.net) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0C99E13C48D for ; Sat, 27 Jan 2007 03:50:16 +0000 (UTC) (envelope-from mav@alkar.net) Received: from [195.248.178.122] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 20211520; Sat, 27 Jan 2007 04:50:15 +0200 Message-ID: <45BABDE2.4010503@alkar.net> Date: Sat, 27 Jan 2007 04:50:10 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nikos Vassiliadis References: <1169850194.00677461.1169839202@10.7.7.3> In-Reply-To: <1169850194.00677461.1169839202@10.7.7.3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: ng_pptpgre problems: tcp connections reset unexpectedly 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, 27 Jan 2007 03:50:18 -0000 Hi. Nikos Vassiliadis wrote: > It seems that tcp connections over pptp reset unexpectedly. I have > tried several things such as connecting from a FBSD-4 to a FBSD-6, > connecting from a FBSD-[46] to a Cisco router(*). There are times which > the client box gets from the other peer an echo-request msg, which is > not supposed to happen while downloading. Perhaps it's relevant to > this: > > (*) the result is always the same. > > What i have not tried, is a newer mpd, Alexander Motin seems to > maintain mpd very actively, he sends a patch every 5 minutes or so:) > I am using at the moment 6.2-PRE, just a few days before RELEASE, > and mpd-3.18_4. Actually I have spent so much time working on mpd4 that I dont like to even hear about some problems in ancient mpd3. :) There so much work was done in mpd4 that it is mostly pointless to debug something in mpd3. > Could you please help? any workarounds, tunables, suggestions? > It's my connection to the internet and from time to time I need > to download something bigger than a few megs... I do not use pptp actively, to say for sure, but you can try to play with such pptp options like delayed-ack, always-ack and windowing. > Thanks in advance, Nikos > > root:2:~/tst1# fetch ftp://ftp2.de.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-disc1.iso; date > 6.2-RELEASE-i386-disc1.iso 3% of 573 MB 185 kBps 50m56s > fetch: transfer timed out > fetch: 6.2-RELEASE-i386-disc1.iso appears to be truncated: 20702208/601229312 bytes > Fri Jan 26 11:31:40 EET 2007 > tcpdump.ng0: > 11:31:40.797285 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20695333:20696745(1412) ack 1 win 5792 > 11:31:40.797294 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20696745 win 32476 > 11:31:40.797697 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20696745:20698157(1412) ack 1 win 5792 > 11:31:40.797780 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20698157 win 33182 > 11:31:40.798589 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20698157:20699569(1412) ack 1 win 5792 > 11:31:40.798739 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20699569:20700981(1412) ack 1 win 5792 > 11:31:40.798748 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20700981 win 32476 > 11:31:40.798877 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20700981:20702393(1412) ack 1 win 5792 > 11:31:40.798924 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20702393 win 33182 > 11:31:40.859025 IP 213.142.137.253.64016 > 134.76.12.3.56123: R 1:1(0) ack 20702393 win 33182 > 11:31:40.887739 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20702393:20703805(1412) ack 1 win 5792 > 11:31:40.887859 IP 134.76.12.3.56123 > 213.142.137.253.64016: P 20703805:20705217(1412) ack 1 win 5792 > 11:31:40.888005 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20705217:20706629(1412) ack 1 win 5792 Looking here I can see that it is your local machine (213.142.137.253) sent "R" - Reset request just after normal acknowledge packet. I don't see the reason for such it's behaviour. Is it the same machine where fetch and tcpdump running? Wasn't there some kind of time synchronization or NAT restart or some other external event? -- Alexander Motin mav@alkar.net Optima Telecom From owner-freebsd-net@FreeBSD.ORG Sat Jan 27 05:09:02 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE2F416A402 for ; Sat, 27 Jan 2007 05:09:02 +0000 (UTC) (envelope-from ashoke@rocketmail.com) Received: from web51907.mail.yahoo.com (web51907.mail.yahoo.com [206.190.48.70]) by mx1.freebsd.org (Postfix) with SMTP id 8A34B13C484 for ; Sat, 27 Jan 2007 05:09:00 +0000 (UTC) (envelope-from ashoke@rocketmail.com) Received: (qmail 28519 invoked by uid 60001); 27 Jan 2007 05:08:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rocketmail.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=M71J1waxAS5L99kL2PabkmHDinYxKICsieH8YxqOUUkaS3AEsgoqTiZ7fAxlW3cTcvtR8G4v23FxkG/TnFWYAT7MnAqHx070ahN6R1BStZ5DhMxpFlauqafBqkyt1d0KcOWXKU5GQr88BbFMb+rx9biLAjGRuDoRLqP0heiHAeU=; X-YMail-OSG: JYPcR7IVM1lPxS7vxxG7g3vddAsktfwAxeQ3SKw9Cdv1N4xwN_3ny8e3oIIWGM6tXQ-- Received: from [61.2.178.73] by web51907.mail.yahoo.com via HTTP; Fri, 26 Jan 2007 21:08:59 PST Date: Fri, 26 Jan 2007 21:08:59 -0800 (PST) From: ashoke saha To: Darren Pilgrim , "Eric W. Bates" In-Reply-To: <45BA499D.2060609@evilphi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <816104.21070.qm@web51907.mail.yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: About NAT Traversal 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, 27 Jan 2007 05:09:03 -0000 basic kame (racoon) as NAT_T for IKE. It did not have kernel support till 6.0. you can take the patch from there. also NAT_T has moved from draft to RFC and do google for NAT_T to get get the RFC's and also read the code in the kernel patch and racoon. assuming you are talking about ipsec NAT_T. ashoke. --- Darren Pilgrim wrote: > Eric W. Bates wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Can someone please refer me to some documentation > describing how to > > implement NAT Traversal? > > In what context? The methods required to traverse a > NAT are highly > protocol-specific. > > -- > Darren Pilgrim > _______________________________________________ > 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" > ____________________________________________________________________________________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121 From owner-freebsd-net@FreeBSD.ORG Sat Jan 27 10:08:06 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F09D16A400; Sat, 27 Jan 2007 10:08:06 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 7294413C46C; Sat, 27 Jan 2007 10:08:05 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l0R9mTck020817; Sat, 27 Jan 2007 16:48:29 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l0R9mTPp020814; Sat, 27 Jan 2007 16:48:29 +0700 (KRAT) (envelope-from eugen) Date: Sat, 27 Jan 2007 16:48:29 +0700 From: Eugene Grosbein To: "Bruce M. Simpson" Message-ID: <20070127094829.GA20381@svzserv.kemerovo.su> References: <20070125184146.GA60481@grosbein.pp.ru> <45BA4ABD.5040402@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45BA4ABD.5040402@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: net@FreeBSD.org Subject: Re: interface metric & quagga 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, 27 Jan 2007 10:08:06 -0000 On Fri, Jan 26, 2007 at 06:38:53PM +0000, Bruce M. Simpson wrote: > >RTM_NEWADDR contains 'metric 0' regardless of interface metric > >value set with ifconfig before. quagga, since version 0.99.3, > >takes metric value from RTM_NEWADDR message and this value overrides > >right interface metric learned by quagga a milisecond before. > >Then it passes zero interface metric to ripd that uses interface > >metric as hop count increment for RIP-learned routes. > >This effectively breaks RIPv2 for FreeBSD (quagga-0.99.2 and older > >versions do not use metric from RTM_NEWADDR and work), perhaps RIPv1 too. > It's a mixed issue. > > FreeBSD does not use the interface metric, so routing daemons shouldn't > use that field. > > However, many routing implementations use a metric or distance of 0 to > indicate a directly-connected route or interface route, so it has > special meaning. > > We could deal with this situation better by explicitly setting the > metric to an invalid value. Quagga checks if metric is zero and changes zero to one for itself in first place. Sadly, it does not perform such sanity check in second place, when it processes RTM_NEWADDR. > If/when we implemented equal-cost multipath, or source address selection > policies, then we should use this field. > >Verified with RELENG_4 and RELENG_6. > >Is it kernel bug or quagga bug? > > > >I also suggest to include next patch to the Ports tree > >if no objections. It restores RIP support. > > > I'd rewrite the patch to wrap the assignment in #ifndef __FreeBSD__ so > that it can be taken upstream more easily. If/when we do equal-cost > multipath or source policy we can bump __FreeBSD_version. Here is version that does not need #ifndef __FreeBSD__ Now (ifam->ifam_metric) is always zero for all FreeBSD versions. --- zebra/kernel_socket.c.orig Fri Jan 26 10:55:03 2007 +++ zebra/kernel_socket.c Fri Jan 26 10:55:35 2007 @@ -585,6 +585,7 @@ if (ifnlen && strncmp (ifp->name, ifname, INTERFACE_NAMSIZ)) isalias = 1; + if (ifam->ifam_metric) ifp->metric = ifam->ifam_metric; /* Add connected address. */ I currently run this patch in production for relatively large RIPv2 network of FreeBSD routers (versions 4.11 and 6.x). Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sat Jan 27 14:31:50 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41C7416A403 for ; Sat, 27 Jan 2007 14:31:50 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.freebsd.org (Postfix) with ESMTP id 023F013C481 for ; Sat, 27 Jan 2007 14:31:49 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: by py-out-1112.google.com with SMTP id f47so505537pye for ; Sat, 27 Jan 2007 06:31:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Zm1miee6Y8rDKZcyOWud5cmfQyryMyVm/u4WBxgGrxjenlrJwhfaMkMRnRZ1L72nbzxu4LrBPVgD01Ob+VEJFOmXeg4q+JG3SqC19hrZnJcU/aatH/WKIx/kMNhALS2dv9mp9mIkMOVClCNodIocnzJmvS9vLlJmbQAQQiLJ2Zs= Received: by 10.35.80.20 with SMTP id h20mr8344393pyl.1169908309285; Sat, 27 Jan 2007 06:31:49 -0800 (PST) Received: by 10.35.60.19 with HTTP; Sat, 27 Jan 2007 06:31:49 -0800 (PST) Message-ID: Date: Sat, 27 Jan 2007 14:31:49 +0000 From: MQ To: Wishmaster In-Reply-To: <1582899958.20070126014728@velnet.ru> MIME-Version: 1.0 References: <1458229821.20070120234257@velnet.ru> <45B28F37.7040100@delphij.net> <1651695163.20070122010957@velnet.ru> <45B4BE90.20602@qwirky.net> <1582899958.20070126014728@velnet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Re[2]: reproducible watchdog timeout in bge 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, 27 Jan 2007 14:31:50 -0000 2007/1/25, Wishmaster : > > Hello Jeff, > > Monday, January 22, 2007, 4:39:28 PM, you wrote: > > > JR> I have been unable to produce time outs with my current setup in > JR> 6.2-Release. > > JR> bge0@pci3:0:0: class=0x020000 card=0x81491043 chip=0x165914e4 > rev=0x11 > JR> hdr=0x00 > JR> vendor = 'Broadcom Corporation' > JR> device = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express' > JR> class = network > JR> subclass = ethernet > > JR> Reading the PR, I attempted triggering this through CVSing and through > JR> the above mentioned ping tests. > > JR> So far nothing. > > JR> The only issue I have seen using these NICs in 6.2R is if I nail up > the > JR> NIC at 100baseTX full-duplex I sometimes loose connectivity. Nothing > JR> in the logs indicate watchdog timeouts or any other issue. I simply > JR> brought the NIC back down to auto-neg and all seems fine. I am > JR> assuming this is a incompatibility between the BGE and my switch, > RS8000. > > JR> I have a Asus P5MT-S with dual BGE NIC's > > JR> Cheers, > > JR> Jeff > JR> _______________________________________________ > JR> freebsd-net@freebsd.org mailing list > JR> http://lists.freebsd.org/mailman/listinfo/freebsd-net > JR> To unsubscribe, send any mail to > JR> "freebsd-net-unsubscribe@freebsd.org" > > > pciconf says: > bge0@pci3:0:0: class=0x020000 card=0x81491043 chip=0x165914e4 rev=0x21 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express' > class = network > subclass = ethernet > bge1@pci4:0:0: class=0x020000 card=0x81491043 chip=0x165914e4 rev=0x21 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express' > class = network > subclass = ethernet > > So, if you have no troubles can you tell do you have smp kernel with > apic and what distribution you are using? > > On my configuration I have dual core intel xeon 30xx series with > SMP and APIC kernel (i386 distribution). This issue appears just after > system boots up. > > If you have non-smp kernel can you try to recompile it with smp and > apic support? > > p.s. motherboard asus p5m2/2gbl > > -- > Best regards, > Wishmaster mailto:wishmaster-velnet@yandex.ru > > > _______________________________________________ > 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" > I have two boxes with onboard bge, one using 5780, the other 5701. Neither of them has your problem. I think there may be some problems with your software or hardware configuration. From owner-freebsd-net@FreeBSD.ORG Sat Jan 27 14:50:27 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E264916A402 for ; Sat, 27 Jan 2007 14:50:27 +0000 (UTC) (envelope-from wishmaster@velnet.ru) Received: from mail.velnet.ru (mail.velnet.ru [88.210.53.179]) by mx1.freebsd.org (Postfix) with ESMTP id 9E1C213C48C for ; Sat, 27 Jan 2007 14:50:27 +0000 (UTC) (envelope-from wishmaster@velnet.ru) Received: from [213.141.131.138] (helo=localhost) by mail.velnet.ru with esmtp (Exim 4.30; FreeBSD) id 1HAoyQ-000E4q-Qo for freebsd-net@freebsd.org; Sat, 27 Jan 2007 17:56:10 +0300 Date: Sat, 27 Jan 2007 17:51:57 +0300 From: Wishmaster X-Mailer: The Bat! (v2.12.00) X-Priority: 3 (Normal) Message-ID: <194684269.20070127175157@velnet.ru> To: freebsd-net@freebsd.org In-Reply-To: References: <1458229821.20070120234257@velnet.ru> <45B28F37.7040100@delphij.net> <1651695163.20070122010957@velnet.ru> <45B4BE90.20602@qwirky.net> <1582899958.20070126014728@velnet.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re[4]: reproducible watchdog timeout in bge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Wishmaster List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 14:50:28 -0000 Hello MQ, Saturday, January 27, 2007, 5:31:49 PM, you wrote: M> I have two boxes with onboard bge, one using 5780, the other M> 5701. Neither of them has your problem. I think there may be some M> problems with your software or hardware configuration. I don't think so. I have two different motherboards and two different freebsd distributions on them (6.1/amd64 and 6.2/i386). On both motherboards there are bcm5721 onboard network chips and both configurations have the same issue. Can you tell me do you have smp kernel? p.s. On both machines I have clear installation of freebsd. i.e. there is nothing except SMP in my kernel. -- Best regards, Wishmaster mailto:wishmaster@velnet.ru From owner-freebsd-net@FreeBSD.ORG Sat Jan 27 16:40:04 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1028D16A401 for ; Sat, 27 Jan 2007 16:40:04 +0000 (UTC) (envelope-from antonio.tommasi@unile.it) Received: from cabis.unile.it (cabis.unile.it [212.189.128.35]) by mx1.freebsd.org (Postfix) with ESMTP id B6D6313C4A3 for ; Sat, 27 Jan 2007 16:40:03 +0000 (UTC) (envelope-from antonio.tommasi@unile.it) Received: from localhost (cabis [127.0.0.1]) by cabis.unile.it (Postfix) with ESMTP id 4E32C22AF0C for ; Sat, 27 Jan 2007 17:20:49 +0100 (CET) X-Virus-Scanned: virus/spam checker at unile.it Received: from cabis.unile.it ([127.0.0.1]) by localhost (cabis.unile.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxKW7c1zbCfk for ; Sat, 27 Jan 2007 17:20:49 +0100 (CET) Received: from webmail.ilenic.unile.it (webmail.ilenic.unile.it [212.189.128.42]) by cabis.unile.it (Postfix) with ESMTP id F3B0622AED8 for ; Sat, 27 Jan 2007 17:20:48 +0100 (CET) Received: from 151.50.247.45 (SquirrelMail authenticated user atommasi) by webmail.ilenic.unile.it with HTTP; Sat, 27 Jan 2007 17:20:49 +0100 (CET) Message-ID: <10239.151.50.247.45.1169914849.squirrel@webmail.ilenic.unile.it> Date: Sat, 27 Jan 2007 17:20:49 +0100 (CET) From: antonio.tommasi@unile.it To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.6 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Filtering Bridge Traffic on layer IP 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, 27 Jan 2007 16:40:04 -0000 Hi to all, i've configured a freebsd box bridge. This machine have 2 ethernet card and i configure them with one ip address. I also configure firewalling with ipfw on this box. Is there a possibility to filter bridged traffic with ipfw on layer IP? I need to allow some machine with some ip to access to internet and the other not. I cannot implemet nat-firewalling because i need to not change actual ip configuration on my lan. Have you any suggestion? Thanks in advance Antonio From owner-freebsd-net@FreeBSD.ORG Sat Jan 27 16:52:02 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3DAEC16A400 for ; Sat, 27 Jan 2007 16:52:02 +0000 (UTC) (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 2AB3613C46C for ; Sat, 27 Jan 2007 16:52:02 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l0RGq1rH001881; Sat, 27 Jan 2007 08:52:01 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l0RGq11H001880; Sat, 27 Jan 2007 08:52:01 -0800 (PST) (envelope-from rizzo) Date: Sat, 27 Jan 2007 08:52:01 -0800 From: Luigi Rizzo To: antonio.tommasi@unile.it Message-ID: <20070127085201.A1868@xorpc.icir.org> References: <10239.151.50.247.45.1169914849.squirrel@webmail.ilenic.unile.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <10239.151.50.247.45.1169914849.squirrel@webmail.ilenic.unile.it>; from antonio.tommasi@unile.it on Sat, Jan 27, 2007 at 05:20:49PM +0100 Cc: freebsd-net@freebsd.org Subject: Re: Filtering Bridge Traffic on layer IP 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, 27 Jan 2007 16:52:02 -0000 On Sat, Jan 27, 2007 at 05:20:49PM +0100, antonio.tommasi@unile.it wrote: > Hi to all, > i've configured a freebsd box bridge. This machine have 2 ethernet card > and i configure them with one ip address. I also configure firewalling > with ipfw on this box. > Is there a possibility to filter bridged traffic with ipfw on layer IP? guarda http://info.iet.unipi.it/~luigi/ip_dummynet/ ciao luigi > I need to allow some machine with some ip to access to internet and the > other not. > I cannot implemet nat-firewalling because i need to not change actual ip > configuration on my lan. > Have you any suggestion? > Thanks in advance > Antonio > > _______________________________________________ > 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"