From owner-freebsd-net@FreeBSD.ORG Sun Nov 25 06:43:14 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7B6816A418; Sun, 25 Nov 2007 06:43:14 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8932613C442; Sun, 25 Nov 2007 06:43:14 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 6D788522FE; Sun, 25 Nov 2007 01:27:27 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 25 Nov 2007 01:27:27 -0500 X-Sasl-enc: 0BccsOsUVw0/WXR9QX1auRKS59oAyRkqtnu4um8MBFD5 1195972047 Received: from [192.168.1.235] (64-142-85-108.dsl.dynamic.sonic.net [64.142.85.108]) by mail.messagingengine.com (Postfix) with ESMTP id BBF1720357; Sun, 25 Nov 2007 01:27:26 -0500 (EST) Message-ID: <47491532.1050600@freebsd.org> Date: Sat, 24 Nov 2007 22:24:50 -0800 From: Darren Reed User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Max Laier References: <200711231232.04447.max@love2party.net> <20071123132453.W98338@fledge.watson.org> <200711242006.04753.max@love2party.net> In-Reply-To: <200711242006.04753.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson Subject: Re: Switch pfil(9) to rmlocks 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, 25 Nov 2007 06:43:14 -0000 Max Laier wrote: > On Friday 23 November 2007, Robert Watson wrote: > > On Fri, 23 Nov 2007, Max Laier wrote: > > > attached is a diff to switch the pfil(9) subsystem to rmlocks, which > > > are more suited for the task. I'd like some exposure before doing > > > the switch, but I don't expect any fallout. This email is going > > > through the patched pfil already - twice. > > > > Max, > > > > Have you done performance measurements that show rmlocks to be a win in > > this scenario? I did some patchs for UNIX domain sockets to replace > > the rwlock there but it appeared not to have a measurable impact on SQL > > benchmarks, presumbaly because the read/write blend wasn't right and/or > > that wasnt a significant source of overhead in the benchmark. I'd > > anticipate a much more measurable improvement for pfil, but would be > > interested in learning how much is seen? > > I had to roll an artificial benchmark in order to see a significant change > (attached - it's a hack!). > > Using 3 threads on a 4 CPU machine I get the following results: > null hook: ~13% +/- 2 > mtx hook: up to 40% [*] > rw hook: ~5% +/- 1 > rm hook: ~35% +/- 5 > Is that 13%/5%/35% faster or slower or improvement or degradation? If "rw hook" (using rwlock like we have today?) is 5%, whas is the baseline? I'm expecting that at least one of these should be a 0%... Darren From owner-freebsd-net@FreeBSD.ORG Sun Nov 25 09:46:35 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8076D16A420; Sun, 25 Nov 2007 09:46:35 +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 EB48813C465; Sun, 25 Nov 2007 09:46:34 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-066-008-048.pools.arcor-ip.net [88.66.8.48]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1IwE4L3d42-0003IA; Sun, 25 Nov 2007 10:46:30 +0100 From: Max Laier Organization: FreeBSD To: Darren Reed Date: Sun, 25 Nov 2007 10:47:37 +0100 User-Agent: KMail/1.9.7 References: <200711231232.04447.max@love2party.net> <200711242006.04753.max@love2party.net> <47491532.1050600@freebsd.org> In-Reply-To: <47491532.1050600@freebsd.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="nextPart10973900.OHRaPakIth"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711251047.44778.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/Pjn7Tepzmto0DnpfWOXKQLChmsDCcQ5gy/BK 6sWE88OcrueblRgYbSBcYn4OC9mpvpFy+EYOMoHbn2LWcUGn/S 3ZAVx2imT5S+Lzd8ZPIyfLo91pOnacXHqR6qsEozUc= Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson Subject: Re: Switch pfil(9) to rmlocks 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, 25 Nov 2007 09:46:35 -0000 --nextPart10973900.OHRaPakIth Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 25 November 2007, Darren Reed wrote: > Max Laier wrote: > > On Friday 23 November 2007, Robert Watson wrote: > > > On Fri, 23 Nov 2007, Max Laier wrote: > > > > attached is a diff to switch the pfil(9) subsystem to rmlocks, > > > > which are more suited for the task. I'd like some exposure > > > > before doing the switch, but I don't expect any fallout. This > > > > email is going through the patched pfil already - twice. > > > > > > Max, > > > > > > Have you done performance measurements that show rmlocks to be a > > > win in this scenario? I did some patchs for UNIX domain sockets to > > > replace the rwlock there but it appeared not to have a measurable > > > impact on SQL benchmarks, presumbaly because the read/write blend > > > wasn't right and/or that wasnt a significant source of overhead in > > > the benchmark. I'd anticipate a much more measurable improvement > > > for pfil, but would be interested in learning how much is seen? > > > > I had to roll an artificial benchmark in order to see a significant > > change (attached - it's a hack!). > > > > Using 3 threads on a 4 CPU machine I get the following results: > > null hook: ~13% +/- 2 > > mtx hook: up to 40% [*] > > rw hook: ~5% +/- 1 > > rm hook: ~35% +/- 5 > > Is that 13%/5%/35% faster or slower or improvement or degradation? > If "rw hook" (using rwlock like we have today?) is 5%, whas is the > baseline? > > I'm expecting that at least one of these should be a 0%... Sorry for the sparse explanation. All numbers above are gain with rmlocks= =20 i.e. rmlocks are faster in all scenarios. The test cases are different=20 hook functions. Every hook has a DELAY(1) and a lock/unlock call around=20 it of the respective lock type. read lock acquisitions for rw and rm. =20 Please look at the code I posted a bit later for more details. =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 --nextPart10973900.OHRaPakIth Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHSUTAXyyEoT62BG0RAgIyAJ9W1OBtLFLCX/wtiTxnfpOwyo6HeQCdEp+W NTn8ZfHcfE6DDb4oDvJZAmQ= =6v2D -----END PGP SIGNATURE----- --nextPart10973900.OHRaPakIth-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 25 12:07:10 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 974A116A417; Sun, 25 Nov 2007 12:07:10 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6ABA913C457; Sun, 25 Nov 2007 12:07:10 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 1D1DC54302; Sun, 25 Nov 2007 07:07:10 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 25 Nov 2007 07:07:10 -0500 X-Sasl-enc: qxXW6/3x0/kWlFI0Z3r2+jHvdVZ2Uwc0fn7xoJrLjuYr 1195992429 Received: from [192.168.1.235] (64-142-85-108.dsl.dynamic.sonic.net [64.142.85.108]) by mail.messagingengine.com (Postfix) with ESMTP id 2C28818CD9; Sun, 25 Nov 2007 07:07:09 -0500 (EST) Message-ID: <474964CF.90308@freebsd.org> Date: Sun, 25 Nov 2007 04:04:31 -0800 From: Darren Reed User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Max Laier References: <200711231232.04447.max@love2party.net> <200711242006.04753.max@love2party.net> <47491532.1050600@freebsd.org> <200711251047.44778.max@love2party.net> In-Reply-To: <200711251047.44778.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson Subject: Re: Switch pfil(9) to rmlocks 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, 25 Nov 2007 12:07:10 -0000 Max Laier wrote: > On Sunday 25 November 2007, Darren Reed wrote: > > Max Laier wrote: > > > On Friday 23 November 2007, Robert Watson wrote: > > > > On Fri, 23 Nov 2007, Max Laier wrote: > > > > > attached is a diff to switch the pfil(9) subsystem to rmlocks, > > > > > which are more suited for the task. I'd like some exposure > > > > > before doing the switch, but I don't expect any fallout. This > > > > > email is going through the patched pfil already - twice. > > > > > > > > Max, > > > > > > > > Have you done performance measurements that show rmlocks to be a > > > > win in this scenario? I did some patchs for UNIX domain sockets to > > > > replace the rwlock there but it appeared not to have a measurable > > > > impact on SQL benchmarks, presumbaly because the read/write blend > > > > wasn't right and/or that wasnt a significant source of overhead in > > > > the benchmark. I'd anticipate a much more measurable improvement > > > > for pfil, but would be interested in learning how much is seen? > > > > > > I had to roll an artificial benchmark in order to see a significant > > > change (attached - it's a hack!). > > > > > > Using 3 threads on a 4 CPU machine I get the following results: > > > null hook: ~13% +/- 2 > > > mtx hook: up to 40% [*] > > > rw hook: ~5% +/- 1 > > > rm hook: ~35% +/- 5 > > > > Is that 13%/5%/35% faster or slower or improvement or degradation? > > If "rw hook" (using rwlock like we have today?) is 5%, whas is the > > baseline? > > > > I'm expecting that at least one of these should be a 0%... > > Sorry for the sparse explanation. All numbers above are gain with rmlocks > i.e. rmlocks are faster in all scenarios. The test cases are different > hook functions. Every hook has a DELAY(1) and a lock/unlock call around > it of the respective lock type. read lock acquisitions for rw and rm. > Please look at the code I posted a bit later for more details. > Thanks for the clarification. That makes rmlocks very interesting. And the kind of lock that both ipf and ipfw could benefit from, especially since you're planning on changing the pfil locks to be this way. Are you (or is someone else?) intending on following up moving ipfw to them, where appropriate? I'm tempted to suggest them to other platforms...although I'd expect some amount nay-saying because of NIH, it would be good if others also picked up on them, if the benefits are this clear cut... Darren From owner-freebsd-net@FreeBSD.ORG Sun Nov 25 12:36:29 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 253E416A468; Sun, 25 Nov 2007 12:36:29 +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 A5B3C13C4EB; Sun, 25 Nov 2007 12:36:28 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-066-008-048.pools.arcor-ip.net [88.66.8.48]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1IwGiT1vxZ-0002z3; Sun, 25 Nov 2007 13:36:26 +0100 From: Max Laier Organization: FreeBSD To: Darren Reed Date: Sun, 25 Nov 2007 13:36:20 +0100 User-Agent: KMail/1.9.7 References: <200711231232.04447.max@love2party.net> <200711251047.44778.max@love2party.net> <474964CF.90308@freebsd.org> In-Reply-To: <474964CF.90308@freebsd.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="nextPart16846558.i6R9qJmlUT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711251336.28161.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18RS52xtco7cAiEwCXhR5q0ghA1ZVUr/V3LOV/ XRr8ZelUuE1ngrMgtnft/e06A4Aqq4s7vIolbV5LRf/Qtlx0vb wiXrtZX7sp0nYMJGP3wSpyZIEJGthYS+7ZgXCkFyc0= Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson Subject: Re: Switch pfil(9) to rmlocks 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, 25 Nov 2007 12:36:29 -0000 --nextPart16846558.i6R9qJmlUT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 25 November 2007, Darren Reed wrote: > Max Laier wrote: > > On Sunday 25 November 2007, Darren Reed wrote: > > > Max Laier wrote: > > > > On Friday 23 November 2007, Robert Watson wrote: > > > > > On Fri, 23 Nov 2007, Max Laier wrote: > > > > > > attached is a diff to switch the pfil(9) subsystem to > > > > > > rmlocks, which are more suited for the task. I'd like some > > > > > > exposure before doing the switch, but I don't expect any > > > > > > fallout. This email is going through the patched pfil > > > > > > already - twice. > > > > > > > > > > Max, > > > > > > > > > > Have you done performance measurements that show rmlocks to be > > > > > a win in this scenario? I did some patchs for UNIX domain > > > > > sockets to replace the rwlock there but it appeared not to have > > > > > a measurable impact on SQL benchmarks, presumbaly because the > > > > > read/write blend wasn't right and/or that wasnt a significant > > > > > source of overhead in the benchmark. I'd anticipate a much > > > > > more measurable improvement for pfil, but would be interested > > > > > in learning how much is seen? > > > > > > > > I had to roll an artificial benchmark in order to see a > > > > significant change (attached - it's a hack!). > > > > > > > > Using 3 threads on a 4 CPU machine I get the following results: > > > > null hook: ~13% +/- 2 > > > > mtx hook: up to 40% [*] > > > > rw hook: ~5% +/- 1 > > > > rm hook: ~35% +/- 5 > > > > > > Is that 13%/5%/35% faster or slower or improvement or degradation? > > > If "rw hook" (using rwlock like we have today?) is 5%, whas is the > > > baseline? > > > > > > I'm expecting that at least one of these should be a 0%... > > > > Sorry for the sparse explanation. All numbers above are gain with > > rmlocks i.e. rmlocks are faster in all scenarios. The test cases are > > different hook functions. Every hook has a DELAY(1) and a > > lock/unlock call around it of the respective lock type. read lock > > acquisitions for rw and rm. Please look at the code I posted a bit > > later for more details. > > Thanks for the clarification. > That makes rmlocks very interesting. > And the kind of lock that both ipf and ipfw could benefit from, > especially since you're planning on changing the pfil locks to be > this way. Are you (or is someone else?) intending on following > up moving ipfw to them, where appropriate? It's unclear yet, where they are appropriate. As the name suggests (read=20 mostly locks) they are for cases where you acquire a write lock only once=20 in a blue moon. As such the write lock acquisition is a very expensive=20 operation. This might be appropriate for some cases of IPFW rulesets,=20 but certainly not the general case. Things like address tables and=20 dynamic rules (states) take a lot of writes. It's not yet clear where=20 the balance for rmlocks really is and my benchmark doesn't answer that. =46or pfil the case is obvious as you hardly ever change the hooks. > I'm tempted to suggest them to other platforms...although I'd expect > some amount nay-saying because of NIH, it would be good if others > also picked up on them, if the benefits are this clear cut... Again ... only for a select set of cases. But they are really great for=20 cases where you don't want to use proper synchronization because of the=20 slow down and the relative small chance of ever hitting the race. Now we=20 have a tool to properly protect against these races without sacrificing=20 performance. =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 --nextPart16846558.i6R9qJmlUT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHSWxMXyyEoT62BG0RAhQkAJ9XuE5DZegAIh789220yZQ+ttkphQCfTv3R M1RvV1uZKZANACUGRq5feYE= =XyvE -----END PGP SIGNATURE----- --nextPart16846558.i6R9qJmlUT-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 25 12:55:27 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85ABB16A420 for ; Sun, 25 Nov 2007 12:55:27 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id D32CE13C458 for ; Sun, 25 Nov 2007 12:55:26 +0000 (UTC) (envelope-from peo@intersonic.se) X-Virus-Scanned: amavisd-new at inter-sonic.com Message-ID: <47496C5E.3010701@intersonic.se> Date: Sun, 25 Nov 2007 13:36:46 +0100 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Thunderbird 2.0.0.6 (X11/20071103) MIME-Version: 1.0 To: Andrea Venturoli References: <4748511C.1020707@netfence.it> In-Reply-To: <4748511C.1020707@netfence.it> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Latest Samba patches 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, 25 Nov 2007 12:55:27 -0000 Andrea Venturoli wrote: > After portupgrading two samba servers, I cannot connect any more to them > through mount_smbfs. Connecting from Windows works fine. > > Am I the only one who is experiencing this problem? No, we are at least two :-) From owner-freebsd-net@FreeBSD.ORG Sun Nov 25 13:41:14 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D56C16A418 for ; Sun, 25 Nov 2007 13:41:14 +0000 (UTC) (envelope-from ml@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id DB3A513C45B for ; Sun, 25 Nov 2007 13:41:13 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.ventu ([151.77.242.123]) (authenticated bits=128) by parrot.aev.net (8.14.1/8.13.8) with ESMTP id lAPDk1Ip042760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 25 Nov 2007 14:46:07 +0100 (CET) (envelope-from ml@netfence.it) Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.1/8.13.8) with ESMTP id lAPDhOla062469; Sun, 25 Nov 2007 14:43:25 +0100 (CET) (envelope-from ml@netfence.it) Message-ID: <47497B69.8080605@netfence.it> Date: Sun, 25 Nov 2007 14:40:57 +0100 From: Andrea Venturoli User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: Per olof Ljungmark References: <4748511C.1020707@netfence.it> <47496C5E.3010701@intersonic.se> In-Reply-To: <47496C5E.3010701@intersonic.se> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 212.31.247.179 Cc: freebsd-net@freebsd.org Subject: Re: Latest Samba patches 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, 25 Nov 2007 13:41:14 -0000 Per olof Ljungmark ha scritto: > Andrea Venturoli wrote: >> After portupgrading two samba servers, I cannot connect any more to >> them through mount_smbfs. Connecting from Windows works fine. >> >> Am I the only one who is experiencing this problem? > > No, we are at least two :-) > Ok, thanks. Any hint on when this will be fixed? Perhaps with the update to 3.0.27a? Not that I'm recriminating, I just need to plan either an upgrade in a short time or a downgrade. bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Sun Nov 25 14:07:07 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 382D416A41A; Sun, 25 Nov 2007 14:07:07 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id C404513C457; Sun, 25 Nov 2007 14:07:06 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 054E157009; Sun, 25 Nov 2007 09:07:02 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 25 Nov 2007 09:07:02 -0500 X-Sasl-enc: dsoNrn5gGwywFsMOs67ip84KLADAKnP7NPTuFybuNkef 1195999621 Received: from [192.168.1.235] (64-142-85-108.dsl.dynamic.sonic.net [64.142.85.108]) by mail.messagingengine.com (Postfix) with ESMTP id 1CC6A180E; Sun, 25 Nov 2007 09:07:01 -0500 (EST) Message-ID: <474980E8.5010305@freebsd.org> Date: Sun, 25 Nov 2007 06:04:24 -0800 From: Darren Reed User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Max Laier References: <200711231232.04447.max@love2party.net> <200711251047.44778.max@love2party.net> <474964CF.90308@freebsd.org> <200711251336.28161.max@love2party.net> In-Reply-To: <200711251336.28161.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson Subject: Re: Switch pfil(9) to rmlocks 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, 25 Nov 2007 14:07:07 -0000 Max Laier wrote: > On Sunday 25 November 2007, Darren Reed wrote: > > Max Laier wrote: > > > On Sunday 25 November 2007, Darren Reed wrote: > > > > Max Laier wrote: > > > > > On Friday 23 November 2007, Robert Watson wrote: > > > > > > On Fri, 23 Nov 2007, Max Laier wrote: > > > > > > > attached is a diff to switch the pfil(9) subsystem to > > > > > > > rmlocks, which are more suited for the task. I'd like some > > > > > > > exposure before doing the switch, but I don't expect any > > > > > > > fallout. This email is going through the patched pfil > > > > > > > already - twice. > > > > > > > > > > > > Max, > > > > > > > > > > > > Have you done performance measurements that show rmlocks to be > > > > > > a win in this scenario? I did some patchs for UNIX domain > > > > > > sockets to replace the rwlock there but it appeared not to have > > > > > > a measurable impact on SQL benchmarks, presumbaly because the > > > > > > read/write blend wasn't right and/or that wasnt a significant > > > > > > source of overhead in the benchmark. I'd anticipate a much > > > > > > more measurable improvement for pfil, but would be interested > > > > > > in learning how much is seen? > > > > > > > > > > I had to roll an artificial benchmark in order to see a > > > > > significant change (attached - it's a hack!). > > > > > > > > > > Using 3 threads on a 4 CPU machine I get the following results: > > > > > null hook: ~13% +/- 2 > > > > > mtx hook: up to 40% [*] > > > > > rw hook: ~5% +/- 1 > > > > > rm hook: ~35% +/- 5 > > > > > > > > Is that 13%/5%/35% faster or slower or improvement or degradation? > > > > If "rw hook" (using rwlock like we have today?) is 5%, whas is the > > > > baseline? > > > > > > > > I'm expecting that at least one of these should be a 0%... > > > > > > Sorry for the sparse explanation. All numbers above are gain with > > > rmlocks i.e. rmlocks are faster in all scenarios. The test cases are > > > different hook functions. Every hook has a DELAY(1) and a > > > lock/unlock call around it of the respective lock type. read lock > > > acquisitions for rw and rm. Please look at the code I posted a bit > > > later for more details. > > > > Thanks for the clarification. > > That makes rmlocks very interesting. > > And the kind of lock that both ipf and ipfw could benefit from, > > especially since you're planning on changing the pfil locks to be > > this way. Are you (or is someone else?) intending on following > > up moving ipfw to them, where appropriate? > > It's unclear yet, where they are appropriate. As the name suggests (read > mostly locks) they are for cases where you acquire a write lock only once > in a blue moon. As such the write lock acquisition is a very expensive > operation. This might be appropriate for some cases of IPFW rulesets, > but certainly not the general case. ... Which is along the lines of what I was thinking. Is there any documentation around on just how expensive the write is with these locks? And if the write is expensive, at what point of the write acquisition do reads get blocked? Darren From owner-freebsd-net@FreeBSD.ORG Sun Nov 25 16:40:59 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27AAC16A473 for ; Sun, 25 Nov 2007 16:40:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outZ.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 0262213C4EA for ; Sun, 25 Nov 2007 16:40:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sun, 25 Nov 2007 08:40:57 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 2F00F126AB0; Sun, 25 Nov 2007 08:40:56 -0800 (PST) Message-ID: <4749A597.5030304@elischer.org> Date: Sun, 25 Nov 2007 08:40:55 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Max Laier References: <200711231232.04447.max@love2party.net> <200711251047.44778.max@love2party.net> <474964CF.90308@freebsd.org> <200711251336.28161.max@love2party.net> In-Reply-To: <200711251336.28161.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Darren Reed , freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson Subject: Re: Switch pfil(9) to rmlocks 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, 25 Nov 2007 16:40:59 -0000 Max Laier wrote: > On Sunday 25 November 2007, Darren Reed wrote: >> Max Laier wrote: >>> On Sunday 25 November 2007, Darren Reed wrote: >>>> Max Laier wrote: >>>>> On Friday 23 November 2007, Robert Watson wrote: >>>>>> On Fri, 23 Nov 2007, Max Laier wrote: >>>>>>> attached is a diff to switch the pfil(9) subsystem to >>>>>>> rmlocks, which are more suited for the task. I'd like some >>>>>>> exposure before doing the switch, but I don't expect any >>>>>>> fallout. This email is going through the patched pfil >>>>>>> already - twice. >>>>>> Max, >>>>>> >>>>>> Have you done performance measurements that show rmlocks to be >>>>>> a win in this scenario? I did some patchs for UNIX domain >>>>>> sockets to replace the rwlock there but it appeared not to have >>>>>> a measurable impact on SQL benchmarks, presumbaly because the >>>>>> read/write blend wasn't right and/or that wasnt a significant >>>>>> source of overhead in the benchmark. I'd anticipate a much >>>>>> more measurable improvement for pfil, but would be interested >>>>>> in learning how much is seen? >>>>> I had to roll an artificial benchmark in order to see a >>>>> significant change (attached - it's a hack!). >>>>> >>>>> Using 3 threads on a 4 CPU machine I get the following results: >>>>> null hook: ~13% +/- 2 >>>>> mtx hook: up to 40% [*] >>>>> rw hook: ~5% +/- 1 >>>>> rm hook: ~35% +/- 5 >>>> Is that 13%/5%/35% faster or slower or improvement or degradation? >>>> If "rw hook" (using rwlock like we have today?) is 5%, whas is the >>>> baseline? >>>> >>>> I'm expecting that at least one of these should be a 0%... >>> Sorry for the sparse explanation. All numbers above are gain with >>> rmlocks i.e. rmlocks are faster in all scenarios. The test cases are >>> different hook functions. Every hook has a DELAY(1) and a >>> lock/unlock call around it of the respective lock type. read lock >>> acquisitions for rw and rm. Please look at the code I posted a bit >>> later for more details. >> Thanks for the clarification. >> That makes rmlocks very interesting. >> And the kind of lock that both ipf and ipfw could benefit from, >> especially since you're planning on changing the pfil locks to be >> this way. Are you (or is someone else?) intending on following >> up moving ipfw to them, where appropriate? > > It's unclear yet, where they are appropriate. As the name suggests (read > mostly locks) they are for cases where you acquire a write lock only once > in a blue moon. As such the write lock acquisition is a very expensive > operation. This might be appropriate for some cases of IPFW rulesets, > but certainly not the general case. Things like address tables and > dynamic rules (states) take a lot of writes. It's not yet clear where > the balance for rmlocks really is and my benchmark doesn't answer that. it's certainly feasible for the main ipfw lock. As for stats, I think there are other ways to solve that problem.. I've been playing around with per-cpu stats. it seems to work ok, but one does have to wonder about what happens on a 64 cpu machine. (*). I guess that we expect 64 cpu machines to have a LOT of memory. (*) yes I know we don't support > 32 right now. dynamic rules require more work, but not every rule is a keep-state, where every rule has stats. > > For pfil the case is obvious as you hardly ever change the hooks. > >> I'm tempted to suggest them to other platforms...although I'd expect >> some amount nay-saying because of NIH, it would be good if others >> also picked up on them, if the benefits are this clear cut... > > Again ... only for a select set of cases. But they are really great for > cases where you don't want to use proper synchronization because of the > slow down and the relative small chance of ever hitting the race. Now we > have a tool to properly protect against these races without sacrificing > performance. > From owner-freebsd-net@FreeBSD.ORG Sun Nov 25 21:29:29 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3841016A468 for ; Sun, 25 Nov 2007 21:29:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id C207A13C467 for ; Sun, 25 Nov 2007 21:29:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IwNy1-000F61-Sv for freebsd-net@freebsd.org; Sun, 25 Nov 2007 22:20:40 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id lAPKKbSH064050 for ; Sun, 25 Nov 2007 22:20:37 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lAPKKbKk064049 for freebsd-net@freebsd.org; Sun, 25 Nov 2007 22:20:37 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Nov 2007 22:20:37 +0200 From: Kostik Belousov To: freebsd-net@freebsd.org Message-ID: <20071125202037.GD78396@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bqPh76xD3yWylqqJ" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: a0e7373be156534abcc10f92c304d741 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1827 [Nov 24 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Subject: Panic with wlan when switching from adhoc to infrastructure 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, 25 Nov 2007 21:29:29 -0000 --bqPh76xD3yWylqqJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On the up-to-date RELENG_7 system, I have configured ath0 in the adhoc mode. After that, I tried to switch the interface into the hostap mode. I got the consistent error message "Interface not configured". After several attempts, I got the following page fault. The second argument to the ieee80211_ht_adjust_channel, chan, is NULL. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc2ed21c8 stack pointer = 0x28:0xd5da4a18 frame pointer = 0x28:0xd5da4a28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1418 (ifconfig) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c06f679d,d5da48ac,c04b8a1a,c06f4b26,c0759780,...) at 0xc044b256 = db_trace_self_wrapper+0x26 kdb_backtrace(c06f4b26,c0759780,c06edbd0,d5da48b8,d5da48b8,...) at 0xc04de839 = kdb_backtrace+0x29 panic(c06edbd0,c0711148,c34e2220,1,1,...) at 0xc04b8a1a = panic+0xaa trap_fatal(c31e9bc8,0,1,0,18d5,...) at 0xc06cce33 = trap_fatal+0x353 trap_pfault(369e99,0,c34e2000,0,c,...) at 0xc06cd09b = trap_pfault+0x25b trap(d5da49d8) at 0xc06cdac2 = trap+0x3d2 calltrap() at 0xc06b664b = calltrap+0x6 --- trap 0xc, eip = 0xc2ed21c8, esp = 0xd5da4a18, ebp = 0xd5da4a28 --- ieee80211_ht_adjust_channel(c2f4e22c,0,2,533,2,...) at 0xc2ed21c8 = ieee80211_ht_adjust_channel+0x38 adhoc_pick_bss(c2eee000,c2f4e22c,c2ed7538,1ec,c2f2b2a7,...) at 0xc2ef8f6f = adhoc_pick_bss+0x1ff ieee80211_check_scan(c2f4e22c,10002,7fffffff,1,c2f4f210,...) at 0xc2ed06c4 = ieee80211_check_scan+0x244 ieee80211_newstate(c2f4e22c,1,ffffffff,0,d5da4b10,...) at 0xc2ecef08 = ieee80211_newstate+0x508 ath_init(c2f4e000,0,c2f1300c,16dd,c35448e0,...) at 0xc2f0cb86 = ath_init+0x1a6 ath_ioctl(c29cdc00,80206910,c35448e0,c334e708,d5da4b8c,...) at 0xc2f118d8 = ath_ioctl+0x138 ifhwioctl(c34e1210,c330a18c,c10be238,c10416c8,85,...) at 0xc0548c97 = ifhwioctl+0x417 ifioctl(c330a18c,80206910,c35448e0,c34e1210,3,...) at 0xc054bb1c = ifioctl+0x3bc soo_ioctl(c2b0baf8,80206910,c35448e0,c3340500,c34e1210,...) at 0xc04f20f2 = soo_ioctl+0x5a2 kern_ioctl(c34e1210,3,80206910,c35448e0,8cbc,...) at 0xc04eac91 = kern_ioctl+0x351 ioctl(c34e1210,d5da4cfc,c,d5da4cb0,c06d786e,...) at 0xc04eadff = ioctl+0x13f syscall(d5da4d38) at 0xc06cd425 = syscall+0x365 Xint0x80_syscall() at 0xc06b66b0 = Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281697f3, esp = 0xbfbfe44c, ebp = 0xbfbfe488 --- Uptime: 55m50s (gdb) list *(ieee80211_ht_adjust_channel+0x38) 0x211c8 is in ieee80211_ht_adjust_channel (/usr/bsd/src/sys/modules/wlan/../../net80211/ieee80211_ht.c:818). 813 } else if (!IEEE80211_IS_CHAN_HT20(chan)) { 814 c = findhtchan(ic, chan, IEEE80211_CHAN_HT20); 815 if (c != NULL) 816 chan = c; 817 } 818 } else if (IEEE80211_IS_CHAN_HT(chan)) { 819 /* demote to legacy, HT use is disabled */ 820 c = ieee80211_find_channel(ic, chan->ic_freq, 821 chan->ic_flags &~ IEEE80211_CHAN_HT); 822 if (c != NULL) --bqPh76xD3yWylqqJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHSdkUC3+MBN1Mb4gRAhjkAJ4yRgBttNWfs0fU8vYFEChUwQfqDwCdFDch am2NCG3DThu1EjQalyWryT8= =Rbd8 -----END PGP SIGNATURE----- --bqPh76xD3yWylqqJ-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 02:29:43 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1BE216A41A; Mon, 26 Nov 2007 02:29:43 +0000 (UTC) (envelope-from jhealy@swin.edu.au) Received: from mailmonitor.cc.swin.edu.au (mailmonitor.cc.swin.edu.au [136.186.1.65]) by mx1.freebsd.org (Postfix) with ESMTP id 0B8F513C4E5; Mon, 26 Nov 2007 02:29:42 +0000 (UTC) (envelope-from jhealy@swin.edu.au) Received: from groupwise.swin.edu.au (Not Verified[136.186.3.197]) by mailmonitor.cc.swin.edu.au with MailMarshal (v6, 1, 4, 441) id ; Mon, 26 Nov 2007 13:09:07 +1100 Received: from [136.186.229.102] (jhealy.caia.swin.edu.au [136.186.229.102]) by groupwise.swin.edu.au with ESMTP; Mon, 26 Nov 2007 13:08:59 +1100 Message-ID: <474A2ABA.5020104@swin.edu.au> Date: Mon, 26 Nov 2007 13:08:58 +1100 From: James Healy User-Agent: Thunderbird 2.0.0.6 (X11/20071113) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------020409040702050006030506" Cc: Lawrence Stewart , freebsd-current@freebsd.org, grenville armitage Subject: SACK broken in HEAD/RELENG_7 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, 26 Nov 2007 02:29:44 -0000 This is a multi-part message in MIME format. --------------020409040702050006030506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While monitoring a data transfer between two 7-beta3 hosts with tcpdump and SIFTR[1] last week, we noticed that SACK was not being negotiated as expected. The SACK option was sent in the SYN, but the option wasn't sent back in the SYNACK, despite SACK being enabled on both hosts. The problem seems to have been caused during some refactoring of tcp_syncache.c back in march (r1.105), and is fixed by the single line patch attached. While investigating the issue, the comments relating to TOF_SACKPERM and TOF_SACK in tcp_var.h made it a little harder to understand what was going on. We interpreted the comment for TOF_SACK to imply that it was used during the handshake. The attached patch only fixes the code, but it might be worth tweaking these comments as well. Maybe something like: #define TOF_SACKPERM 0x0004 /* SACK permitted */ #define TOF_SACK 0x0080 /* SACK hole data */ In our opinion, it might also be worth renaming SCF_SACK to SCF_SACKPERM in tcp_syncache.c to semantically align it with the TOF defines in tcp_var.h. James Healy and Lawrence Stewart http://caia.swin.edu.au [1] http://caia.swin.edu.au/urp/newtcp/tools.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHSiq64oawkrbYo/kRAsX0AKCybMhaBxPaYtmKNrYF0+kkh4s/DgCfQK0W +79c+IH5nzG3r+6Nn/ji8L4= =TD4L -----END PGP SIGNATURE----- Swinburne University of Technology CRICOS Provider Code: 00111D NOTICE This e-mail and any attachments are confidential and intended only for the use of the addressee. They may contain information that is privileged or protected by copyright. If you are not the intended recipient, any dissemination, distribution, printing, copying or use is strictly prohibited. The University does not warrant that this e-mail and any attachments are secure and there is also a risk that it may be corrupted in transmission. It is your responsibility to check any attachments for viruses or defects before opening them. If you have received this transmission in error, please contact us on +61 3 9214 8000 and delete it immediately from your system. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. Please consider the environment before printing this email. --------------020409040702050006030506 Content-Type: text/x-patch; name="freebsd7beta3_syncache_sack_fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd7beta3_syncache_sack_fix.patch" --- tcp_syncache.c.orig +++ tcp_syncache.c @@ -1184,7 +1184,7 @@ if (to->to_flags & TOF_SIGNATURE) sc->sc_flags |= SCF_SIGNATURE; #endif - if (to->to_flags & TOF_SACK) + if (to->to_flags & TOF_SACKPERM) sc->sc_flags |= SCF_SACK; if (to->to_flags & TOF_MSS) sc->sc_peer_mss = to->to_mss; /* peer mss may be zero */ --------------020409040702050006030506-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 03:05:45 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59C1216A418 for ; Mon, 26 Nov 2007 03:05:45 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id 7D41013C455 for ; Mon, 26 Nov 2007 03:05:44 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 19834 invoked from network); 26 Nov 2007 02:39:03 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 26 Nov 2007 02:39:03 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 25 Nov 2007 20:39:04 -0600 (CST) From: Mike Silbersack To: James Healy In-Reply-To: <474A2ABA.5020104@swin.edu.au> Message-ID: <20071125203825.S7699@odysseus.silby.com> References: <474A2ABA.5020104@swin.edu.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, grenville armitage , Lawrence Stewart Subject: Re: SACK broken in HEAD/RELENG_7 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, 26 Nov 2007 03:05:45 -0000 On Mon, 26 Nov 2007, James Healy wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > While monitoring a data transfer between two 7-beta3 hosts with tcpdump > and SIFTR[1] last week, we noticed that SACK was not being negotiated as > expected. > James Healy and Lawrence Stewart Good detective work! I'll get this change commited in the next day or two. -Mike From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 03:12:51 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5E9316A417 for ; Mon, 26 Nov 2007 03:12:51 +0000 (UTC) (envelope-from moonshade@pnhz.kz) Received: from relay.pnhz.kz (relay.pnhz.kz [212.154.198.217]) by mx1.freebsd.org (Postfix) with ESMTP id 1E96F13C469 for ; Mon, 26 Nov 2007 03:12:50 +0000 (UTC) (envelope-from moonshade@pnhz.kz) Received: from [192.168.121.40] (abyss.pnhz.kz [192.168.121.40]) by relay.pnhz.kz with ESMTP id lAQ32Dor085740; Mon, 26 Nov 2007 09:02:13 +0600 (ALMT) (envelope-from moonshade@pnhz.kz) From: Denis Eremenko To: Andrea Venturoli In-Reply-To: <4748511C.1020707@netfence.it> References: <4748511C.1020707@netfence.it> Content-Type: text/plain; charset=KOI8-R Date: Mon, 26 Nov 2007 09:02:11 +0600 Message-Id: <1196046131.10874.7.camel@abyss.pnhz.kz> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Latest Samba patches 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, 26 Nov 2007 03:12:52 -0000 ÷ ÓÂ, 24/11/2007 × 17:28 +0100, Andrea Venturoli ÐÉÛÅÔ: > After portupgrading two samba servers, I cannot connect any more to them > through mount_smbfs. Connecting from Windows works fine. > > Am I the only one who is experiencing this problem? Did you portupgrade with CVE patches? See: grep CVE /usr/ports/net/samba3/distinfo If you did, that's ok :)... http://www.freebsd.org/cgi/query-pr.cgi?pr=118224 Samba bugzilla page, mentioned in PR, has a patch. From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 05:05:57 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1D9516A41A for ; Mon, 26 Nov 2007 05:05:56 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.224]) by mx1.freebsd.org (Postfix) with ESMTP id A358D13C45A for ; Mon, 26 Nov 2007 05:05:56 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so207134nzf for ; Sun, 25 Nov 2007 21:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=Ul1d0AJY6TqIuKQqnFT4i+VBrdxTdHm1NTX2iRTHY0k=; b=PfVntnFLLui7cNDq+CMPEoWDVsQ4btDLeuVP3IDb9eUqIZ10IgZE/gneMxfBKGdTKzWt5qBIchX3oMxVb4SDKrrwjbAMPmkKMnOdQmTxeVRWSEY/gETwRoPSfu3xtxyTEjoFk98y4bCj1+rtKQJXtd1MRdPm+IyTbB4ajO284is= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=cfB7z04en6lazXvUlQv3E3EgukUiojDordFx8NttOeUwML1RJpAbnKMk23Ra98NGWGhXfCV/RKgzWAtWKYaFogrg4aDfs26Hj6noM/zQ5/iyXGb7c5zy/n2fINmmBI/EKgjlTsD7NoMN/5d/HYfkgB19WRKhZAqvOms6AsmDfkk= Received: by 10.114.88.1 with SMTP id l1mr563274wab.1196053555379; Sun, 25 Nov 2007 21:05:55 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id m5sm3201873wag.2007.11.25.21.05.47 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Nov 2007 21:05:53 -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 lAQ53eu7002663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 14:03:40 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id lAQ53cA6002662; Mon, 26 Nov 2007 14:03:38 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 26 Nov 2007 14:03:38 +0900 From: Pyun YongHyeon To: supportsobaka@mail.ru Message-ID: <20071126050338.GB1025@cdnetworks.co.kr> References: <1452057316.20071124171853@mail.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="xgyAXRrhYN0wYx8y" Content-Disposition: inline In-Reply-To: <1452057316.20071124171853@mail.ru> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, davidch@freebsd.org Subject: Re: Broadcom NetXtreme II BMC5708 no carrier 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: Mon, 26 Nov 2007 05:05:57 -0000 --xgyAXRrhYN0wYx8y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Nov 24, 2007 at 05:18:53PM +0300, supportsobaka@mail.ru wrote: > Hello > > We have problem with Broadcom NetXtreme II BMC5708 on our blade > server. > > ifconfig bce0 report: > > bce0: flags=8847 mtu 1500 > options=3b > inet 172.0.0.199 netmask 0xffffff00 broadcast 172.0.0.255 > ether 00:1a:64:33:29:c7 > media: Ethernet autoselect (none) > status: no carrier > > > Try to set > #ifconfig bce0 media 1000baseSX mediaopt full-duplex > > bce0: flags=8847 mtu 1500 > options=3b > inet 172.0.0.199 netmask 0xffffff00 broadcast 172.0.0.255 > ether 00:1a:64:33:29:c7 > media: Ethernet 1000baseSX (none) > status: no carrier > > > Status don't want change to active, and nothing work :( > > FreeBSD 6.3-PRERELEASE (7.x have problem too) > > Is any idea? It seems that mii_ticks is not kicked at all in auto-negotiation phase. From the output of forced 1000baseSX media configuration I guess BRGPHY_BMSR_ACOMP bit in BRGPHY_MII_BMSR is not updated on 5708S. Mabe davidch know better what's going on 5708S. (CCed) How about attached patch? I don't have the hardware so it's just a guess work. -- Regards, Pyun YongHyeon --xgyAXRrhYN0wYx8y Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="brgphy.patch" Index: brgphy.c =================================================================== RCS file: /home/ncvs/src/sys/dev/mii/brgphy.c,v retrieving revision 1.70 diff -u -r1.70 brgphy.c --- brgphy.c 8 Jun 2007 02:34:44 -0000 1.70 +++ brgphy.c 26 Nov 2007 05:03:55 -0000 @@ -364,12 +364,10 @@ break; } -#if 0 /* Todo: Is this correct? */ /* Announce link loss right after it happens. */ if (sc->mii_ticks++ == 0) break; -#endif /* Only retry autonegotiation every mii_anegticks seconds. */ if (sc->mii_ticks <= sc->mii_anegticks) @@ -507,9 +505,12 @@ /* Autoneg is still in progress. */ if ((bmcr & BRGPHY_BMCR_AUTOEN) && (bmsr & BRGPHY_BMSR_ACOMP) == 0) { - /* Erg, still trying, I guess... */ - mii->mii_media_active |= IFM_NONE; - goto brgphy_status_exit; + /* XXX 5708S doesn't update BRGPHY_BMSR_ACOMP? */ + if ((bsc->serdes_flags & BRGPHY_5708S) == 0) { + /* Erg, still trying, I guess... */ + mii->mii_media_active |= IFM_NONE; + goto brgphy_status_exit; + } } /* Autoneg is enabled and complete, link should be up. */ --xgyAXRrhYN0wYx8y-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 11:07:03 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87BB416A46E for ; Mon, 26 Nov 2007 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7348113C478 for ; Mon, 26 Nov 2007 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lAQB73q8025507 for ; Mon, 26 Nov 2007 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lAQB72hd025503 for freebsd-net@FreeBSD.org; Mon, 26 Nov 2007 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Nov 2007 11:07:02 GMT Message-Id: <200711261107.lAQB72hd025503@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org 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, 26 Nov 2007 11:07:03 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/115360 net [ipv6] IPv6 address and if_bridge don't play well toge 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue f kern/62374 net panic: free: multiple frees s kern/81147 net [net] [patch] em0 reinitialization while adding aliase 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 s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi o kern/110959 net [ipsec] Filtering incoming packets with enc0 does not o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net IP v4 udp fragmented packet reject o kern/113457 net [ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net 6.2-STABLE panic during use of multi-cast networking c o kern/116172 net Network / ipv6 recursive mutex panic o kern/116185 net if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net ifconfig tunX destroy: panic o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net Duplicate IP on different interfaces o bin/117448 net [carp] 6.2 kernel crash o kern/117717 net Kernel panic with Bittorrent client. 29 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- 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] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling 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 conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/112654 net [pcn] Kernel panic upon if_pcn module load on a Netfin o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] fstat(1): add INET/INET6 socket details as in o bin/117339 net [patch] route(8): loading routing management commands 14 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 14:44:27 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90F9916A41A for ; Mon, 26 Nov 2007 14:44:27 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id C6F7D13C465 for ; Mon, 26 Nov 2007 14:44:26 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so689087nfb for ; Mon, 26 Nov 2007 06:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=SOdMqyzkrgimNXds0tfyhNU+2xYPY2vNj7K/ra8CCxQ=; b=SOGaCFpI9Pg7/tNx14ZLN5fSPyDZpbBKsznfGgzPhmm40eH8Dc054ZDw5BzrEw5bq3JEe1pAAhFU63fQJs8tGaSB6yy0zK1hxr/EvrRuITPqFVAsabv4b9/vIXuC9IVzWjU1Ge2zpmxZ4cQzNUBffnS+MIvrUD8ajcLeY5DhIqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=qbvA5yCZ9oIvazGAqYUHJyMJQSIEifgoFUXQKWQ3oZMCErvHdGFQ3DxpnwiaC99cuVflSiO3UUNiK0VFw4iddprpd6x5FIQcsAEEuhMxGsZoA67Wk31v/Lak53IYVx3VqZmH2xMvtNS+Bkrl+BAIqzfLNFFsvwfF4RHUbe+OFyo= Received: by 10.86.98.18 with SMTP id v18mr2749877fgb.1196088259290; Mon, 26 Nov 2007 06:44:19 -0800 (PST) Received: from ?172.17.14.157? ( [193.136.24.128]) by mx.google.com with ESMTPS id 3sm2264429fge.2007.11.26.06.44.17 (version=SSLv3 cipher=OTHER); Mon, 26 Nov 2007 06:44:18 -0800 (PST) Message-Id: <26032689-AD73-4836-8AA1-65915F1D2857@FreeBSD.org> From: Rui Paulo To: freebsd-net@freebsd.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 26 Nov 2007 14:44:15 +0000 References: X-Mailer: Apple Mail (2.915) Sender: Rui Paulo Subject: Re: TCP ECN patch for review X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2007 14:44:27 -0000 Ok, after two changes, the implementation seems ready. You can grab the new diff at the same location: http://people.freebsd.org/~rpaulo/tcp_ecn.diff I tested this on the netperf cluster using pf/altq as the "congested" router. The following configuration was used: altq on em0 bandwidth 3Mb cbq queue { dflt } queue dflt bandwidth 100% cbq(default,ecn) pass in on em0 from any to any keep state queue dflt pass out on em0 from any to any keep state queue dflt In theory, this should give us max 384KB/s, but 360KB/s was observed both with ECN enabled and without ECN (which shows that basically our TCP stack is aggressive enough). The gain with ECN was not in throughput (as it was with NetBSD) but in the number of lost packets and retransmissions (both 0 when ECN was enabled.) If you like throughput graphs :-), http://people.freebsd.org/~rpaulo/throughput-withecn.png http://people.freebsd.org/~rpaulo/throughput-withoutecn.png (generated by wireshark) As you can see, with ECN, the connection throughput seems to stabilize much more earlier than without ECN. tcpdumps are available on request. Next follows the tcptrace -lrW output for both scenarios. Regards. WITH ECN: ------------------------------------------------------------------------- 1 arg remaining, starting with 'tcpdump-withecn' Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004 29646 packets seen, 29646 TCP packets traced elapsed wallclock time: 0:00:00.075908, 390551 pkts/sec analyzed trace file elapsed time: 0:00:56.917292 TCP connection info: 1 TCP connection traced: TCP connection 1: host a: 192.168.5.108:57760 host b: 192.168.5.109:22 complete conn: yes first packet: Mon Nov 26 09:46:29.787719 2007 last packet: Mon Nov 26 09:47:26.705011 2007 elapsed time: 0:00:56.917292 total packets: 29646 filename: tcpdump-withecn a->b: b->a: total packets: 18642 total packets: 11004 ack pkts sent: 18641 ack pkts sent: 11004 pure acks sent: 21 pure acks sent: 10661 sack pkts sent: 0 sack pkts sent: 0 dsack pkts sent: 0 dsack pkts sent: 0 max sack blks/ack: 0 max sack blks/ ack: 0 unique bytes sent: 19993839 unique bytes sent: 17903 actual data pkts: 18619 actual data pkts: 341 actual data bytes: 19993839 actual data bytes: 17903 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 zwnd probe pkts: 0 zwnd probe pkts: 0 zwnd probe bytes: 0 zwnd probe bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 25 pushed data pkts: 341 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 req 1323 ws/ts: Y/Y req 1323 ws/ts: Y/Y adv wind scale: 3 adv wind scale: 3 req sack: Y req sack: N sacks sent: 0 sacks sent: 0 urgent data pkts: 0 pkts urgent data pkts: 0 pkts urgent data bytes: 0 bytes urgent data bytes: 0 bytes mss requested: 1460 bytes mss requested: 1460 bytes max segm size: 1448 bytes max segm size: 736 bytes min segm size: 1 bytes min segm size: 32 bytes avg segm size: 1073 bytes avg segm size: 52 bytes max win adv: 66608 bytes max win adv: 66608 bytes min win adv: 65872 bytes min win adv: 52128 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 66607 bytes avg win adv: 65010 bytes max owin: 2897 bytes max owin: 769 bytes min non-zero owin: 1 bytes min non-zero owin: 1 bytes avg owin: 1621 bytes avg owin: 15 bytes wavg owin: 1289 bytes wavg owin: 6 bytes initial window: 39 bytes initial window: 39 bytes initial window: 1 pkts initial window: 1 pkts ttl stream length: 19993839 bytes ttl stream length: 17903 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 19440399 bytes truncated data: 7673 bytes truncated packets: 18247 pkts truncated packets: 341 pkts data xmit time: 56.875 secs data xmit time: 56.875 secs idletime max: 1673.5 ms idletime max: 1779.3 ms throughput: 351279 Bps throughput: 315 Bps RTT samples: 9559 RTT samples: 322 RTT min: 0.0 ms RTT min: 0.2 ms RTT max: 99.8 ms RTT max: 99.6 ms RTT avg: 0.0 ms RTT avg: 46.4 ms RTT stdev: 1.5 ms RTT stdev: 11.3 ms RTT from 3WHS: 0.0 ms RTT from 3WHS: 0.2 ms RTT full_sz smpls: 5140 RTT full_sz smpls: 1 RTT full_sz min: 0.0 ms RTT full_sz min: 0.3 ms RTT full_sz max: 2.3 ms RTT full_sz max: 0.3 ms RTT full_sz avg: 0.0 ms RTT full_sz avg: 0.3 ms RTT full_sz stdev: 0.0 ms RTT full_sz stdev: 0.0 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 9062 segs cum acked: 21 duplicate acks: 1 duplicate acks: 1 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms WITHOUT ECN: ------------------------------------------------------------------------- 1 arg remaining, starting with 'tcpdump-withoutecn' Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004 26429 packets seen, 26429 TCP packets traced elapsed wallclock time: 0:00:00.070504, 374858 pkts/sec analyzed trace file elapsed time: 0:00:56.651240 TCP connection info: 1 TCP connection traced: TCP connection 1: host a: 192.168.5.108:50080 host b: 192.168.5.109:22 complete conn: yes first packet: Mon Nov 26 09:55:28.595502 2007 last packet: Mon Nov 26 09:56:25.246743 2007 elapsed time: 0:00:56.651240 total packets: 26429 filename: tcpdump-withoutecn a->b: b->a: total packets: 14948 total packets: 11481 ack pkts sent: 14947 ack pkts sent: 11481 pure acks sent: 15 pure acks sent: 11168 sack pkts sent: 0 sack pkts sent: 0 dsack pkts sent: 0 dsack pkts sent: 0 max sack blks/ack: 0 max sack blks/ ack: 0 unique bytes sent: 19992591 unique bytes sent: 16367 actual data pkts: 14931 actual data pkts: 311 actual data bytes: 19992591 actual data bytes: 16367 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 zwnd probe pkts: 0 zwnd probe pkts: 0 zwnd probe bytes: 0 zwnd probe bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 106 pushed data pkts: 311 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 req 1323 ws/ts: Y/Y req 1323 ws/ts: Y/Y adv wind scale: 3 adv wind scale: 3 req sack: Y req sack: N sacks sent: 0 sacks sent: 0 urgent data pkts: 0 pkts urgent data pkts: 0 pkts urgent data bytes: 0 bytes urgent data bytes: 0 bytes mss requested: 1460 bytes mss requested: 1460 bytes max segm size: 1448 bytes max segm size: 736 bytes min segm size: 1 bytes min segm size: 32 bytes avg segm size: 1338 bytes avg segm size: 52 bytes max win adv: 66608 bytes max win adv: 99376 bytes min win adv: 65872 bytes min win adv: 57920 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 66607 bytes avg win adv: 87736 bytes max owin: 9329 bytes max owin: 737 bytes min non-zero owin: 1 bytes min non-zero owin: 1 bytes avg owin: 2012 bytes avg owin: 25 bytes wavg owin: 1830 bytes wavg owin: 6 bytes initial window: 39 bytes initial window: 39 bytes initial window: 1 pkts initial window: 1 pkts ttl stream length: 19992591 bytes ttl stream length: 16367 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 19545650 bytes truncated data: 7037 bytes truncated packets: 14851 pkts truncated packets: 311 pkts data xmit time: 56.608 secs data xmit time: 56.608 secs idletime max: 1885.2 ms idletime max: 1991.3 ms throughput: 352906 Bps throughput: 289 Bps RTT samples: 7980 RTT samples: 306 RTT min: 0.0 ms RTT min: 0.2 ms RTT max: 99.7 ms RTT max: 175.3 ms RTT avg: 0.1 ms RTT avg: 97.8 ms RTT stdev: 1.6 ms RTT stdev: 46.8 ms RTT from 3WHS: 0.0 ms RTT from 3WHS: 0.2 ms RTT full_sz smpls: 6983 RTT full_sz smpls: 1 RTT full_sz min: 0.0 ms RTT full_sz min: 0.2 ms RTT full_sz max: 3.0 ms RTT full_sz max: 0.2 ms RTT full_sz avg: 0.0 ms RTT full_sz avg: 0.2 ms RTT full_sz stdev: 0.1 ms RTT full_sz stdev: 0.0 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 6953 segs cum acked: 7 duplicate acks: 1 duplicate acks: 1 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 15:09:10 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51A8916A41A for ; Mon, 26 Nov 2007 15:09:10 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from snipe.secure-computing.net (snipe.secure-computing.net [209.240.66.149]) by mx1.freebsd.org (Postfix) with ESMTP id 22B2813C44B for ; Mon, 26 Nov 2007 15:09:09 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from [10.0.0.14] (unknown [74.95.66.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ecrist@secure-computing.net) by snipe.secure-computing.net (Postfix) with ESMTP id AAB9E17043 for ; Mon, 26 Nov 2007 09:09:03 -0600 (CST) Message-Id: <44E698B8-B9D6-4770-93CF-FFF0C008F681@secure-computing.net> From: Eric F Crist To: freebsd-net@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 26 Nov 2007 09:09:01 -0600 X-Mailer: Apple Mail (2.915) Subject: 6.2+pf+CARP bandwidth issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2007 15:09:10 -0000 Happy monday folks! We have a couple of Dell PowerEdge 1650 systems in a CARP setup with pf as our firewall cluster. I've noticed that if I connect my laptop behind these systems, I can achieve about 600kbps down and about 1100kpbs upload. If I connect to the other side, bypassing these systems, I can achieve our entire bandwidth cap provided by our colocation company. What things should I look for as far as tuning goes? Any gotchas I should look out for? All the interfaces and switches in question are gigabit. Some interfaces are fxp, others are onboard em. Thanks for you replies! ----- Eric F Crist Secure Computing Networks From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 20:19:54 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16DE816A41B for ; Mon, 26 Nov 2007 20:19:54 +0000 (UTC) (envelope-from nick-lists@netability.ie) Received: from mail.acquirer.com (mail.acquirer.com [87.198.142.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8F72C13C44B for ; Mon, 26 Nov 2007 20:19:53 +0000 (UTC) (envelope-from nick-lists@netability.ie) X-Envelope-To: Received: from crumpet.foobar.org (vpn-251.int.inex.ie [193.242.111.251]) (authenticated bits=0) by mail.acquirer.com (8.13.6/8.13.8) with ESMTP id lAQJuZQX076734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Nov 2007 19:56:36 GMT (envelope-from nick-lists@netability.ie) Message-ID: <474B24F3.2030603@netability.ie> Date: Mon, 26 Nov 2007 19:56:35 +0000 From: Nick Hilliard User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on muffin.acquirer.com X-Virus-Scanned: ClamAV 0.91.2/4928/Mon Nov 26 18:10:39 2007 on muffin.acquirer.com X-Virus-Status: Clean Subject: tcp md5 checksums broken in 7.0-beta3 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, 26 Nov 2007 20:19:54 -0000 Hi, Are TCP MD5 checksums working at all in freebsd7.0-beta3? I've got two physically identical machines, one running 6.2 and the other 7.0-beta3. Both are running quagga 0.99.9 with the md5 patch. On the 6.2 box, packets are being correctly tagged, according to tcpdump (with the print-tcp.c memcmp() patch). > 19:42:30.937507 IP 193.242.111.8.57216 > 193.242.111.29.179: P 2720329801:2720329820(19) ack 1833960167 win 65535 : BGP, length: 19 However, on the 7.0 box, the checksum is ending up zeroed: > 19:32:30.996634 IP 193.242.111.9.55302 > 193.242.111.xx.179: S 1684595509:1684595509(0) win 65535 There is a SAD entry for this host: > 193.242.111.9 193.242.111.xx > tcp mode=any spi=4096(0x00001000) reqid=0(0x00000000) > A: tcp-md5 > seq=0x00000000 replay=0 flags=0x00000040 state=mature > created: Nov 26 19:30:00 2007 current: Nov 26 19:33:44 2007 > diff: 224(s) hard: 0(s) soft: 0(s) > last: Nov 26 19:32:30 2007 hard: 0(s) soft: 0(s) > current: 0(bytes) hard: 0(bytes) soft: 0(bytes) > allocated: 9 hard: 0 soft: 0 > sadb_seq=2 pid=1574 refcnt=1 Looks like collateral damage from some other change to the tcp code between 6.2 and 7.0. Nick From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 20:37:10 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E22E16A419; Mon, 26 Nov 2007 20:37: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 D9ECF13C458; Mon, 26 Nov 2007 20:37: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 3C83446F33; Mon, 26 Nov 2007 15:40:46 -0500 (EST) Date: Mon, 26 Nov 2007 20:37:02 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Max Laier In-Reply-To: <200711231232.04447.max@love2party.net> Message-ID: <20071126203514.X65286@fledge.watson.org> References: <200711231232.04447.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Switch pfil(9) to rmlocks 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, 26 Nov 2007 20:37:10 -0000 On Fri, 23 Nov 2007, Max Laier wrote: > attached is a diff to switch the pfil(9) subsystem to rmlocks, which are > more suited for the task. I'd like some exposure before doing the switch, > but I don't expect any fallout. This email is going through the patched > pfil already - twice. FYI, since people are experimenting with rmlocks as a substitute for rwlocks, I played with moving the global rwlock used to protect the name space and linkage of UNIX domain sockets to be an rmlock. Kris didn't see any measurable change in performance for his MySQL benchmarks, but I figured I'd post the patches as they give a sense of what change impact things like reader state management have on code. Attached below. I have no current plans to commit these changes as they appear not to offer benefit (either because the rwlock overhead was negigible compared to other costs in the benchmark, or because the read/write blend was too scewed towards writes -- I think probably the former rather than the latter). Robert N M Watson Computer Laboratory University of Cambridge ==== //depot/vendor/freebsd/src/sys/kern/uipc_usrreq.c#141 (text+ko) - //depot/user/rwatson/proto/src/sys/kern/uipc_usrreq.c#59 (text+ko) ==== content @@ -79,6 +79,7 @@ #include #include #include +#include #include #include #include @@ -196,6 +197,35 @@ * binding, both of which involve dropping UNIX domain socket locks in order * to perform namei() and other file system operations. */ + +#define USE_RMLOCKS +#ifdef USE_RMLOCKS + +static struct rmlock unp_global_rmlock; + +#define UNP_GLOBAL_LOCK_INIT() rm_init(&unp_global_rmlock, \ + "unp_global_rmlock", 0) + +#define UNP_GLOBAL_LOCK_ASSERT() /*rm_assert(&unp_global_rmlock, \ + RA_LOCKED) */ +#define UNP_GLOBAL_UNLOCK_ASSERT() /*rm_assert(&unp_global_rmlock, \ + RA_UNLOCKED) */ + +#define UNP_GLOBAL_WLOCK() rm_wlock(&unp_global_rmlock) +#define UNP_GLOBAL_WUNLOCK() rm_wunlock(&unp_global_rmlock) +#define UNP_GLOBAL_WLOCK_ASSERT() /*rm_assert(&unp_global_rmlock, \ + RA_WLOCKED) */ +#define UNP_GLOBAL_WOWNED() rm_wowned(&unp_global_rmlock) + +#define UNP_GLOBAL_RLOCK() rm_rlock(&unp_global_rmlock, &tr) +#define UNP_GLOBAL_RUNLOCK() rm_runlock(&unp_global_rmlock, &tr) +#define UNP_GLOBAL_RLOCK_ASSERT() /*rm_assert(&unp_global_rmlock, \ + RA_RLOCKED) */ + +#define RMLOCK_DECL struct rm_priotracker tr + +#else /* !USE_RMLOCKS */ + static struct rwlock unp_global_rwlock; #define UNP_GLOBAL_LOCK_INIT() rw_init(&unp_global_rwlock, \ @@ -217,6 +247,10 @@ #define UNP_GLOBAL_RLOCK_ASSERT() rw_assert(&unp_global_rwlock, \ RA_RLOCKED) +#define RMLOCK_DECL __unused struct rm_priotracker tr + +#endif /* !USE_RMLOCKS */ + #define UNP_PCB_LOCK_INIT(unp) mtx_init(&(unp)->unp_mtx, \ "unp_mtx", "unp_mtx", \ MTX_DUPOK|MTX_DEF|MTX_RECURSE) @@ -225,9 +259,11 @@ #define UNP_PCB_UNLOCK(unp) mtx_unlock(&(unp)->unp_mtx) #define UNP_PCB_LOCK_ASSERT(unp) mtx_assert(&(unp)->unp_mtx, MA_OWNED) + static int unp_connect(struct socket *, struct sockaddr *, - struct thread *); -static int unp_connect2(struct socket *so, struct socket *so2, int); + struct thread *, struct rm_priotracker *); +static int unp_connect2(struct socket *so, struct socket *so2, int, + struct rm_priotracker *); static void unp_disconnect(struct unpcb *unp, struct unpcb *unp2); static void unp_shutdown(struct unpcb *); static void unp_drop(struct unpcb *, int); @@ -295,6 +331,7 @@ { struct unpcb *unp, *unp2; const struct sockaddr *sa; + RMLOCK_DECL; /* * Pass back name of connected socket, if it was bound and we are @@ -493,10 +530,11 @@ uipc_connect(struct socket *so, struct sockaddr *nam, struct thread *td) { int error; + RMLOCK_DECL; KASSERT(td == curthread, ("uipc_connect: td != curthread")); UNP_GLOBAL_WLOCK(); - error = unp_connect(so, nam, td); + error = unp_connect(so, nam, td, &tr); UNP_GLOBAL_WUNLOCK(); return (error); } @@ -526,6 +564,7 @@ { struct unpcb *unp, *unp2; int error; + RMLOCK_DECL; UNP_GLOBAL_WLOCK(); unp = so1->so_pcb; @@ -534,7 +573,7 @@ unp2 = so2->so_pcb; KASSERT(unp2 != NULL, ("uipc_connect2: unp2 == NULL")); UNP_PCB_LOCK(unp2); - error = unp_connect2(so1, so2, PRU_CONNECT2); + error = unp_connect2(so1, so2, PRU_CONNECT2, &tr); UNP_PCB_UNLOCK(unp2); UNP_PCB_UNLOCK(unp); UNP_GLOBAL_WUNLOCK(); @@ -753,6 +792,7 @@ u_int mbcnt, sbcc; u_long newhiwat; int error = 0; + RMLOCK_DECL; unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_send: unp == NULL")); @@ -782,7 +822,7 @@ error = EISCONN; break; } - error = unp_connect(so, nam, td); + error = unp_connect(so, nam, td, &tr); if (error) break; unp2 = unp->unp_conn; @@ -836,7 +876,7 @@ if ((so->so_state & SS_ISCONNECTED) == 0) { if (nam != NULL) { UNP_GLOBAL_WLOCK_ASSERT(); - error = unp_connect(so, nam, td); + error = unp_connect(so, nam, td, &tr); if (error) break; /* XXX */ } else { @@ -938,6 +978,7 @@ { struct unpcb *unp, *unp2; struct socket *so2; + RMLOCK_DECL; unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_sense: unp == NULL")); @@ -1110,7 +1151,8 @@ } static int -unp_connect(struct socket *so, struct sockaddr *nam, struct thread *td) +unp_connect(struct socket *so, struct sockaddr *nam, struct thread *td, + struct rm_priotracker *tr) { struct sockaddr_un *soun = (struct sockaddr_un *)nam; struct vnode *vp; @@ -1249,7 +1291,7 @@ KASSERT(unp2 != NULL, ("unp_connect: unp2 == NULL")); UNP_PCB_LOCK(unp); UNP_PCB_LOCK(unp2); - error = unp_connect2(so, so2, PRU_CONNECT); + error = unp_connect2(so, so2, PRU_CONNECT, tr); UNP_PCB_UNLOCK(unp2); UNP_PCB_UNLOCK(unp); bad2: @@ -1273,7 +1315,8 @@ } static int -unp_connect2(struct socket *so, struct socket *so2, int req) +unp_connect2(struct socket *so, struct socket *so2, int req, + struct rm_priotracker *tr) { struct unpcb *unp; struct unpcb *unp2; @@ -1359,6 +1402,7 @@ struct xunpgen *xug; struct unp_head *head; struct xunpcb *xu; + RMLOCK_DECL; head = ((intptr_t)arg1 == SOCK_DGRAM ? &unp_dhead : &unp_shead); From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 22:15:34 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47B1816A41B for ; Mon, 26 Nov 2007 22:15:34 +0000 (UTC) (envelope-from supportsobaka@mail.ru) Received: from mx5.mail.ru (mx5.mail.ru [194.67.23.25]) by mx1.freebsd.org (Postfix) with ESMTP id 008BC13C455 for ; Mon, 26 Nov 2007 22:15:33 +0000 (UTC) (envelope-from supportsobaka@mail.ru) Received: from [212.176.204.213] (port=48992 helo=A) by mx5.mail.ru with asmtp id 1IwmEm-000EY2-00; Tue, 27 Nov 2007 01:15:32 +0300 Date: Tue, 27 Nov 2007 01:15:31 +0300 From: supportsobaka@mail.ru X-Mailer: The Bat! (v3.85.03) Professional Organization: supportsobaka@mail.ru X-Priority: 3 (Normal) Message-ID: <479954190.20071127011531@mail.ru> To: Pyun YongHyeon In-Reply-To: <20071126050338.GB1025@cdnetworks.co.kr> References: <1452057316.20071124171853@mail.ru> <20071126050338.GB1025@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, davidch@freebsd.org Subject: Re[2]: Broadcom NetXtreme II BMC5708 no carrier X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: supportsobaka@mail.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2007 22:15:34 -0000 Hello PY> It seems that mii_ticks is not kicked at all in auto-negotiation PY> phase. From the output of forced 1000baseSX media configuration I PY> guess BRGPHY_BMSR_ACOMP bit in BRGPHY_MII_BMSR is not updated on PY> 5708S. Mabe davidch know better what's going on 5708S. (CCed) PY> How about attached patch? I don't have the hardware so it's just a PY> guess work. Thank you Pyun for patch. Yesterday we applied benno's patch (here info http://www.freebsd.org/cgi/query-pr.cgi?pr=118238) with good result. After patching, autoselect was set half-duplex. We did some benchmarks for ethernet. if autoselected half-duplex, than errors on interface. But we use ifconfig mediaopt to set full-duplex. And no errors or collisions was founded, so we think it is possible to use on productions. But we will try your patch tomorrow too. From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 22:31:50 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6164816A418; Mon, 26 Nov 2007 22:31:50 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4E62213C4D9; Mon, 26 Nov 2007 22:31:50 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 44EAB1A4D7E; Mon, 26 Nov 2007 14:12:26 -0800 (PST) Date: Mon, 26 Nov 2007 14:12:26 -0800 From: Alfred Perlstein To: Robert Watson Message-ID: <20071126221226.GJ71382@elvis.mu.org> References: <200711231232.04447.max@love2party.net> <20071126203514.X65286@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071126203514.X65286@fledge.watson.org> User-Agent: Mutt/1.4.2.3i Cc: Max Laier , freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Switch pfil(9) to rmlocks 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, 26 Nov 2007 22:31:50 -0000 * Robert Watson [071126 12:37] wrote: > > On Fri, 23 Nov 2007, Max Laier wrote: > > >attached is a diff to switch the pfil(9) subsystem to rmlocks, which are > >more suited for the task. I'd like some exposure before doing the switch, > >but I don't expect any fallout. This email is going through the patched > >pfil already - twice. > > FYI, since people are experimenting with rmlocks as a substitute for > rwlocks, I played with moving the global rwlock used to protect the name > space and linkage of UNIX domain sockets to be an rmlock. Kris didn't see > any measurable change in performance for his MySQL benchmarks, but I > figured I'd post the patches as they give a sense of what change impact > things like reader state management have on code. Attached below. I have > no current plans to commit these changes as they appear not to offer > benefit (either because the rwlock overhead was negigible compared to other > costs in the benchmark, or because the read/write blend was too scewed > towards writes -- I think probably the former rather than the latter). I would track the read/write lock mix to get an idea of what the ratio is. -Alfred From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 23:18:54 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3EDE16A417 for ; Mon, 26 Nov 2007 23:18:54 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 8F26513C458 for ; Mon, 26 Nov 2007 23:18:53 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id F31C241C7A6; Tue, 27 Nov 2007 00:00:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id WWw-S9vDSSIy; Tue, 27 Nov 2007 00:00:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 82B0041C7A5; Tue, 27 Nov 2007 00:00:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 84B80444885; Mon, 26 Nov 2007 22:58:56 +0000 (UTC) Date: Mon, 26 Nov 2007 22:58:55 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Nick Hilliard In-Reply-To: <474B24F3.2030603@netability.ie> Message-ID: <20071126224649.C53707@maildrop.int.zabbadoz.net> References: <474B24F3.2030603@netability.ie> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: tcp md5 checksums broken in 7.0-beta3 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, 26 Nov 2007 23:18:54 -0000 On Mon, 26 Nov 2007, Nick Hilliard wrote: Hi, > Are TCP MD5 checksums working at all in freebsd7.0-beta3? I've got two > physically identical machines, one running 6.2 and the other 7.0-beta3. > Both are running quagga 0.99.9 with the md5 patch. On the 6.2 box, packets > are being correctly tagged, according to tcpdump (with the print-tcp.c > memcmp() patch). ... > Looks like collateral damage from some other change to the tcp code between > 6.2 and 7.0. not that this should fix your problem but you might want to start with this patch: http://sources.zabbadoz.net/freebsd/patchset/sys-netinet-tcp-syncache.c-20071126-01.diff I'll try to find your bug the next days (in case you find anything let me know). I don't know how much quagga does these days but policies are setup correctly on both machines and you are not finding any failed SADB lookup warninge in dmesg on the 7 machine? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 08:49:07 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E207416A46C for ; Tue, 27 Nov 2007 08:49:07 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id B790313C461 for ; Tue, 27 Nov 2007 08:49:07 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 1845257AC2; Tue, 27 Nov 2007 03:49:07 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 27 Nov 2007 03:49:07 -0500 X-Sasl-enc: Rs5gQ8611or97CGIDIMhJ+1h1H7IvNJFATfcX/P1JakS 1196153346 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id A1CC9A35A; Tue, 27 Nov 2007 03:49:06 -0500 (EST) Message-ID: <474BDA01.7050505@FreeBSD.org> Date: Tue, 27 Nov 2007 08:49:05 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: mosaic References: <910e7ff90711240859h722b6bf8jf294e3622f516fa@mail.gmail.com> In-Reply-To: <910e7ff90711240859h722b6bf8jf294e3622f516fa@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: plans for multiple routing tables 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, 27 Nov 2007 08:49:08 -0000 mosaic wrote: > I would like to ask, whether there are any plans to implement multiple > route tables, like OpenBSD did: > > http://archives.neohapsis.com/archives/openbsd/2006-10/2665.html > Yup, we're aware of these changes. [The feature you're referring to is actually the ability to have multiple choices for next-hops, not multiple routing tables -- that's just how the next-hops might conceptually be presented to the user.] > I'm well aware of fact that i can do policy routing via pf/ipf/ipfw as well of > > http://imunes.tel.fer.hr/virtnet/ > Again, not entirely the same thing. IMUNES is overkill for most people's requirements, and is about more than 'just' the forwarding plane; it is however a novel and interesting way of doing network simulation or virtualization. There are a whole bunch of potential issues with implementing multipath right. I would suggest, for now, that we just import the OpenBSD changes to the existing BSD FIB, as it is a relatively low change in terms of code. I've responded to Julian off-list about his plans as a number of groups and individuals have been looking at this issue. I would like to see this work out OK, but I do not have 'copious free time' in which to do this at the moment -- I gotta earn a living! regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 08:51:13 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2114B16A418 for ; Tue, 27 Nov 2007 08:51:13 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id E410C13C465 for ; Tue, 27 Nov 2007 08:51:12 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 7CB1056D21; Tue, 27 Nov 2007 03:51:12 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 27 Nov 2007 03:51:12 -0500 X-Sasl-enc: iR6H6DGIdB3UyRiAH6GZONvYqtPdzG5KgmzbcbBR1LKy 1196153472 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 02149153F8; Tue, 27 Nov 2007 03:51:11 -0500 (EST) Message-ID: <474BDA7F.3030608@FreeBSD.org> Date: Tue, 27 Nov 2007 08:51:11 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Rui Paulo References: <26032689-AD73-4836-8AA1-65915F1D2857@FreeBSD.org> In-Reply-To: <26032689-AD73-4836-8AA1-65915F1D2857@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: TCP ECN patch for review X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 08:51:13 -0000 I'm very pleased to see ECN finally being implemented in FreeBSD. Whilst I can't offer technical assistance in testing or review at this time, I would like to thank you for the clearly professional level of effort you have put into this. regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 09:55:39 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC12116A4A0; Tue, 27 Nov 2007 09:55:38 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id 392C913C447; Tue, 27 Nov 2007 09:55:37 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.14.2/8.14.1) with ESMTP id lAR9Xc5E036685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2007 12:33:38 +0300 (MSK) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.14.2/8.14.1/Submit) id lAR9Xbq9036684; Tue, 27 Nov 2007 12:33:37 +0300 (MSK) (envelope-from oleg) Date: Tue, 27 Nov 2007 12:33:37 +0300 From: Oleg Bulyzhin To: Pyun YongHyeon Message-ID: <20071127093337.GA36544@lath.rinet.ru> References: <1452057316.20071124171853@mail.ru> <20071126050338.GB1025@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071126050338.GB1025@cdnetworks.co.kr> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-net@freebsd.org, supportsobaka@mail.ru, davidch@freebsd.org Subject: Re: Broadcom NetXtreme II BMC5708 no carrier 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, 27 Nov 2007 09:55:39 -0000 On Mon, Nov 26, 2007 at 02:03:38PM +0900, Pyun YongHyeon wrote: > > It seems that mii_ticks is not kicked at all in auto-negotiation > phase. From the output of forced 1000baseSX media configuration I > guess BRGPHY_BMSR_ACOMP bit in BRGPHY_MII_BMSR is not updated on > 5708S. Mabe davidch know better what's going on 5708S. (CCed) > How about attached patch? I don't have the hardware so it's just a > guess work. > > -- > Regards, > Pyun YongHyeon I just want to confirm that removing mii_ticks increment was bad idea. -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 10:52:48 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27F8016A49C for ; Tue, 27 Nov 2007 10:52:48 +0000 (UTC) (envelope-from nick-lists@netability.ie) Received: from mail.acquirer.com (mail.acquirer.com [87.198.142.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9F94913C4D5 for ; Tue, 27 Nov 2007 10:52:46 +0000 (UTC) (envelope-from nick-lists@netability.ie) X-Envelope-To: freebsd-net@freebsd.org Received: from crumpet.foobar.org (vpn-251.int.inex.ie [193.242.111.251]) (authenticated bits=0) by mail.acquirer.com (8.13.6/8.13.8) with ESMTP id lARAqbWp041289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2007 10:52:39 GMT (envelope-from nick-lists@netability.ie) Message-ID: <474BF6F3.2070506@netability.ie> Date: Tue, 27 Nov 2007 10:52:35 +0000 From: Nick Hilliard User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <474B24F3.2030603@netability.ie> <20071126224649.C53707@maildrop.int.zabbadoz.net> In-Reply-To: <20071126224649.C53707@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on muffin.acquirer.com X-Virus-Scanned: ClamAV 0.91.2/4930/Tue Nov 27 09:03:33 2007 on muffin.acquirer.com X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: tcp md5 checksums broken in 7.0-beta3 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, 27 Nov 2007 10:52:48 -0000 Bjoern A. Zeeb wrote: > not that this should fix your problem but you might want to start with > this patch: > > http://sources.zabbadoz.net/freebsd/patchset/sys-netinet-tcp-syncache.c-20071126-01.diff No, probably not. But it may fix a bunch of spurious failed SADB lookup messages I've been seeing on the box in question. > I'll try to find your bug the next days (in case you find anything let > me know). > > I don't know how much quagga does these days but policies are setup > correctly on both machines and you are not finding any failed SADB > lookup warninge in dmesg on the 7 machine? The security policy is set up using setkey from config in /etc/ipsec.conf: > ferris# grep xx /etc/ipsec.conf > add 193.242.111.9 193.242.111.xx tcp 0x1000 -A tcp-md5 ""; No, there are no failed SADB lookup messages. The kernel code is being executed, because if I disable md5 from within quagga, the md5 checksum option completely disappears from the tcp headers. If it's enabled, the checksum is just zeros. Nick From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 14:12:00 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ED2216A419 for ; Tue, 27 Nov 2007 14:12:00 +0000 (UTC) (envelope-from w@wrzask.pl) Received: from mx.oak.pl (mx.oak.pl [217.96.108.251]) by mx1.freebsd.org (Postfix) with ESMTP id 4ABA613C46A for ; Tue, 27 Nov 2007 14:11:59 +0000 (UTC) (envelope-from w@wrzask.pl) Received: by oak.pl (Postfix, from userid 1002) id DFB7E1CD25; Tue, 27 Nov 2007 14:53:20 +0100 (CET) Date: Tue, 27 Nov 2007 14:53:20 +0100 From: Jan Srzednicki To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20071127135320.GJ2045@oak.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: connect() returns EADDRINUSE during massive host->host conn rate 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, 27 Nov 2007 14:12:00 -0000 Hello, I have a pair of hosts. One of them performs a massive amount of TCP connections to the other one, all to the same port. This setup mostly works fine, but from time to time (that varies, from once a minute to one a half an hour), the connect(2) syscall fails with EADDRINUSE. The connection rate tops to 50 connection initiations/second. The socket is non-blocking. It does standard job of creating the socket, setting up the relevant fields, setting SO_REUSEADDR and SO_KEEPALIVE, setting O_NONBLOCK on the descriptor. No bind(2) is performed. The connection is initiated from inside a jail (not sure if that implies a internal bind(2) to the jail's address). There are no connections from the other host to the first one. I've tried tuning the net.inet.ip.portrange variables: I've increased the available portrange to over 45000 ports (quite a lot, should be more than enough for just anything) and I've toggled net.inet.ip.portrange.randomized off, but that didn't change anything. The workaround on the application side - retrying on EADDRINUSE - works pretty well, but hey, from what I know from the Stevens book, that shouldn't be happening, though Google said all BSD had a bad habit of throwing out EADDRINUSE from time to time. This all happens on a 6.2-RELEASE system. The symptoms are easily reproducable in my environment. Is there any known fix for that? If there ain't, can it be fixed? :) -- Jan Srzednicki :: http://wrzask.pl/ "Remember, remember, the fifth of November" -- V for Vendetta From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 01:27:21 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E71716A420 for ; Wed, 28 Nov 2007 01:27:21 +0000 (UTC) (envelope-from nick-lists@netability.ie) Received: from mail.acquirer.com (mail.acquirer.com [87.198.142.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2745E13C448 for ; Wed, 28 Nov 2007 01:27:20 +0000 (UTC) (envelope-from nick-lists@netability.ie) X-Envelope-To: freebsd-net@freebsd.org Received: from crumpet.foobar.org (twinkie.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.acquirer.com (8.13.6/8.13.8) with ESMTP id lAS1R8nM038709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Nov 2007 01:27:14 GMT (envelope-from nick-lists@netability.ie) Message-ID: <474CC3EC.1010205@netability.ie> Date: Wed, 28 Nov 2007 01:27:08 +0000 From: Nick Hilliard User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <474B24F3.2030603@netability.ie> <20071126224649.C53707@maildrop.int.zabbadoz.net> In-Reply-To: <20071126224649.C53707@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on muffin.acquirer.com X-Virus-Scanned: ClamAV 0.91.2/4934/Tue Nov 27 23:17:17 2007 on muffin.acquirer.com X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: tcp md5 checksums broken in 7.0-beta3 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, 28 Nov 2007 01:27:21 -0000 Bjoern A. Zeeb wrote: > I'll try to find your bug the next days (in case you find anything let > me know). At the very least, this will be necessary: --- tcp_subr.c~ 2007-11-28 01:14:46.000000000 +0000 +++ tcp_subr.c 2007-11-28 01:14:46.000000000 +0000 @@ -1948,7 +1948,7 @@ /* * Step 4: Update MD5 hash with shared secret. */ - MD5Update(&ctx, _KEYBUF(sav->key_auth), _KEYLEN(sav->key_auth)); + MD5Update(&ctx, sav->key_auth->key_data, _KEYLEN(sav->key_auth)); MD5Final(buf, &ctx); key_sa_recordxfer(sav, m); But it doesn't fix the problem. Nick From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 06:30:07 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA09716A417 for ; Wed, 28 Nov 2007 06:30:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 88A7813C44B for ; Wed, 28 Nov 2007 06:30:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 1A88441C733; Wed, 28 Nov 2007 07:30:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id MA8FPsSryckM; Wed, 28 Nov 2007 07:30:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id BABDD41C71E; Wed, 28 Nov 2007 07:30:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 7BD42444885; Wed, 28 Nov 2007 06:26:16 +0000 (UTC) Date: Wed, 28 Nov 2007 06:26:15 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Nick Hilliard In-Reply-To: <474CC3EC.1010205@netability.ie> Message-ID: <20071128062332.E53707@maildrop.int.zabbadoz.net> References: <474B24F3.2030603@netability.ie> <20071126224649.C53707@maildrop.int.zabbadoz.net> <474CC3EC.1010205@netability.ie> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: tcp md5 checksums broken in 7.0-beta3 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, 28 Nov 2007 06:30:07 -0000 On Wed, 28 Nov 2007, Nick Hilliard wrote: Hi, > Bjoern A. Zeeb wrote: >> I'll try to find your bug the next days (in case you find anything let >> me know). > > At the very least, this will be necessary: > > --- tcp_subr.c~ 2007-11-28 01:14:46.000000000 +0000 > +++ tcp_subr.c 2007-11-28 01:14:46.000000000 +0000 > @@ -1948,7 +1948,7 @@ > /* > * Step 4: Update MD5 hash with shared secret. > */ > - MD5Update(&ctx, _KEYBUF(sav->key_auth), _KEYLEN(sav->key_auth)); > + MD5Update(&ctx, sav->key_auth->key_data, _KEYLEN(sav->key_auth)); > MD5Final(buf, &ctx); > > key_sa_recordxfer(sav, m); > > But it doesn't fix the problem. I stopped at the point validating the tcp header was correct last night somewhen after midnight. With your + my other patches (not posted yet) I have valid md5 sums again for all but the S/A case. Expect a patch soonish. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 06:55:06 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4B6F16A418 for ; Wed, 28 Nov 2007 06:55:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5628413C4D9 for ; Wed, 28 Nov 2007 06:55:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 8DC4F41C747; Wed, 28 Nov 2007 07:55:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Rh7hcpGmul+f; Wed, 28 Nov 2007 07:55:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 2C76841C736; Wed, 28 Nov 2007 07:55:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 24B95444885; Wed, 28 Nov 2007 06:50:50 +0000 (UTC) Date: Wed, 28 Nov 2007 06:50:50 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Nick Hilliard In-Reply-To: <20071128062332.E53707@maildrop.int.zabbadoz.net> Message-ID: <20071128064738.S53707@maildrop.int.zabbadoz.net> References: <474B24F3.2030603@netability.ie> <20071126224649.C53707@maildrop.int.zabbadoz.net> <474CC3EC.1010205@netability.ie> <20071128062332.E53707@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: tcp md5 checksums broken in 7.0-beta3 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, 28 Nov 2007 06:55:06 -0000 On Wed, 28 Nov 2007, Bjoern A. Zeeb wrote: > On Wed, 28 Nov 2007, Nick Hilliard wrote: > > Hi, > >> Bjoern A. Zeeb wrote: >>> I'll try to find your bug the next days (in case you find anything let >>> me know). >> >> At the very least, this will be necessary: >> >> --- tcp_subr.c~ 2007-11-28 01:14:46.000000000 +0000 >> +++ tcp_subr.c 2007-11-28 01:14:46.000000000 +0000 >> @@ -1948,7 +1948,7 @@ >> /* >> * Step 4: Update MD5 hash with shared secret. >> */ >> - MD5Update(&ctx, _KEYBUF(sav->key_auth), _KEYLEN(sav->key_auth)); >> + MD5Update(&ctx, sav->key_auth->key_data, _KEYLEN(sav->key_auth)); >> MD5Final(buf, &ctx); >> >> key_sa_recordxfer(sav, m); >> >> But it doesn't fix the problem. > > I stopped at the point validating the tcp header was correct last > night somewhen after midnight. With your + my other patches (not > posted yet) I have valid md5 sums again for all but the S/A case. > Expect a patch soonish. Ok. Last problem solved as well. foo# tcpdump -e -l -n -i lo0 -s 0 -M "aaaaaaaaaaaaaaaaaa" port 2345 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo0, link-type NULL (BSD loopback), capture size 65535 bytes 06:46:59.119952 AF IPv4 (2), length 84: 127.0.0.1.49991 > 127.0.0.1.2345: S 471076426:471076426(0) win 65535 06:46:59.119998 AF IPv4 (2), length 84: 127.0.0.1.2345 > 127.0.0.1.49991: S 2721608573:2721608573(0) ack 471076427 win 65535 06:46:59.120028 AF IPv4 (2), length 76: 127.0.0.1.49991 > 127.0.0.1.2345: . ack 1 win 8960 06:46:59.120073 AF IPv4 (2), length 102: 127.0.0.1.49991 > 127.0.0.1.2345: P 1:27(26) ack 1 win 8960 06:46:59.120103 AF IPv4 (2), length 76: 127.0.0.1.2345 > 127.0.0.1.49991: F 1:1(0) ack 27 win 8960 06:46:59.120147 AF IPv4 (2), length 76: 127.0.0.1.49991 > 127.0.0.1.2345: . ack 2 win 8960 06:46:59.120164 AF IPv4 (2), length 76: 127.0.0.1.49991 > 127.0.0.1.2345: F 27:27(0) ack 2 win 8960 06:46:59.120208 AF IPv4 (2), length 56: 127.0.0.1.2345 > 127.0.0.1.49991: . ack 28 win 8959 I have the to have one part of the patch reviewed before I can send it out... Will try to catch people the next hours. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 15:10:07 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF07E16A41A for ; Wed, 28 Nov 2007 15:10:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 86B8613C4D1 for ; Wed, 28 Nov 2007 15:10:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 1DC8041C74D; Wed, 28 Nov 2007 16:10:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 2h3bZoY2T3rA; Wed, 28 Nov 2007 16:10:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id AB00D41C747; Wed, 28 Nov 2007 16:10:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 88693444885; Wed, 28 Nov 2007 15:05:55 +0000 (UTC) Date: Wed, 28 Nov 2007 15:05:55 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Nick Hilliard In-Reply-To: <20071128064738.S53707@maildrop.int.zabbadoz.net> Message-ID: <20071128145744.G53707@maildrop.int.zabbadoz.net> References: <474B24F3.2030603@netability.ie> <20071126224649.C53707@maildrop.int.zabbadoz.net> <474CC3EC.1010205@netability.ie> <20071128062332.E53707@maildrop.int.zabbadoz.net> <20071128064738.S53707@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: tcp md5 checksums broken in 7.0-beta3 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, 28 Nov 2007 15:10:07 -0000 On Wed, 28 Nov 2007, Bjoern A. Zeeb wrote: Hi, > On Wed, 28 Nov 2007, Bjoern A. Zeeb wrote: > >> On Wed, 28 Nov 2007, Nick Hilliard wrote: >> >> Hi, >> >>> Bjoern A. Zeeb wrote: >>>> I'll try to find your bug the next days (in case you find anything let >>>> me know). >>> >>> At the very least, this will be necessary: >>> >>> --- tcp_subr.c~ 2007-11-28 01:14:46.000000000 +0000 >>> +++ tcp_subr.c 2007-11-28 01:14:46.000000000 +0000 >>> @@ -1948,7 +1948,7 @@ >>> /* >>> * Step 4: Update MD5 hash with shared secret. >>> */ >>> - MD5Update(&ctx, _KEYBUF(sav->key_auth), _KEYLEN(sav->key_auth)); >>> + MD5Update(&ctx, sav->key_auth->key_data, _KEYLEN(sav->key_auth)); >>> MD5Final(buf, &ctx); >>> >>> key_sa_recordxfer(sav, m); >>> >>> But it doesn't fix the problem. That fix was committed to HEAD. Thanks! In addition to that can you try this patch: http://sources.zabbadoz.net/freebsd/patchset/patch-20071128-03-tcp-md5.diff I have to admit, I haven't tried it after my last merges so I hope I got the merges right;-) -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 17:35:36 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58C0E16A418 for ; Wed, 28 Nov 2007 17:35:36 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id E16A713C447 for ; Wed, 28 Nov 2007 17:35:35 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1921453uge for ; Wed, 28 Nov 2007 09:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=+Iv0woY5sPaM3wGhhVAYz2uYtRGNSxK4IOqgBXbYOHA=; b=QGKl9OUDrr/EiEd8YHd76B/w6d9OnZsF05LyJTBjxThSWTO6ViaXMPBzmxUZxfYp3HDehY6seUl3cDodqK0CQFlUTtRtH5hmdukHUhMf0GOKHBIjjBQozm+HUgnKp8sDl5OxYm3f2tJtoMKXVVTIaZmtrkZ/9yU3LkvApy52KBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=s7u5zCeuY2y37D8HE56QlaZYvb5G2R3v29S/swbmq0FjtRp+Ndx6Vlb+ETFyFr7wEp+8AwfggL9lnCxQPxRjWJIQnq0bK8YSWFWHK/mWCX1CFB6aZUPhJcEkqVNchg4P/9eVKM01MzXI0ffmU7Fekk0KYrlGj2+C1D2UAKNuypk= Received: by 10.78.176.20 with SMTP id y20mr5815978hue.1196269814154; Wed, 28 Nov 2007 09:10:14 -0800 (PST) Received: by 10.78.39.6 with HTTP; Wed, 28 Nov 2007 09:10:13 -0800 (PST) Message-ID: Date: Wed, 28 Nov 2007 20:10:13 +0300 From: pluknet To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Sleeping on "iwiioctl" with the non-sleepable locks 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, 28 Nov 2007 17:35:36 -0000 Hello. i've got this on 7.0-BETA3 i386 (as of Nov 21) when starting dhclient iwi0 (well, actually network card is switched off via Fn-key). Kernel is built with debugging options. iwi0@pci0:1:3:0: class=0x028000 card=0x27228086 chip=0x42208086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/Wireless 2200BG Network Connection' class = network iwi0: flags=8843 metric 0 mtu 1500 ether 00:0e:35:be:77:df inet 192.168.70.65 netmask 0xffffff00 broadcast 192.168.70.255 media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid plip channel 6 (2437 Mhz 11g) bssid 00:80:c8:01:15:d9 authmode WPA privacy ON deftxkey UNDEF txpowmax 100 bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 14 roam:rate11g 5 protmode CTS roaming MANUAL bintval 100 iwi0: radio turned off Sleeping on "iwiioctl" with the following non-sleepable locks held: exclusive sleep mutex in_multi_mtx r = 0 (0xc084792c) locked @ /media/src/sys/netinet/in.c:508 KDB: stack backtrace: db_trace_self_wrapper(c077db7b,e636da8c,c056b55d,c077df31,e636daa0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c077df31,e636daa0,4,1,0,...) at kdb_backtrace+0x29 witness_warn(5,c3bc5418,c077ba3b,c0902e4f,c3bc5418,...) at witness_warn+0x1cd _sleep(c3bc4000,c3bc5418,0,c0902e4f,3e8,...) at _sleep+0x5f iwi_ioctl(c3c20c00,80206932,0,9c6,c46257c0,...) at iwi_ioctl+0x64 if_delmulti_ifma(c422c5c0,c07ca740,c078c3d1,1b5) at if_delmulti_ifma+0xe9 in_delmulti_locked(c46257c0,0,c078c2fc,1fd,c07873a6,...) at in_delmulti_locked+0xe6 in_control(c4412948,80206919,c422c3c0,c3c20c00,c3f89420,...) at in_control+0x105a ifioctl(c4412948,80206919,c422c3c0,c3f89420,c3f89420,...) at ifioctl+0x333 soo_ioctl(c3e16c60,80206919,c422c3c0,c452f600,c3f89420,...) at soo_ioctl+0x3e2 kern_ioctl(c3f89420,3,80206919,c422c3c0,c422c3c0,...) at kern_ioctl+0x253 ioctl(c3f89420,e636dcfc,c,c07a5174,c07b8830,...) at ioctl+0x13f syscall(e636dd38) at syscall+0x2f3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2817c793, esp = 0xbfbfe63c, ebp = 0xbfbfe668 --- iwi0: radio turned off wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 18:17:27 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E001016A418; Wed, 28 Nov 2007 18:17:27 +0000 (UTC) (envelope-from w@wrzask.pl) Received: from mx.oak.pl (mx.oak.pl [217.96.108.251]) by mx1.freebsd.org (Postfix) with ESMTP id 9271613C44B; Wed, 28 Nov 2007 18:17:27 +0000 (UTC) (envelope-from w@wrzask.pl) Received: by oak.pl (Postfix, from userid 1002) id 919041CD1E; Wed, 28 Nov 2007 19:17:25 +0100 (CET) Date: Wed, 28 Nov 2007 19:17:25 +0100 From: Jan Srzednicki To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20071128181725.GP2045@oak.pl> References: <20071127135320.GJ2045@oak.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071127135320.GJ2045@oak.pl> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: connect() returns EADDRINUSE during massive host->host conn rate 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, 28 Nov 2007 18:17:28 -0000 On Tue, Nov 27, 2007 at 02:53:20PM +0100, Jan Srzednicki wrote: > Hello, > > setting up the relevant fields, setting SO_REUSEADDR and SO_KEEPALIVE, > setting O_NONBLOCK on the descriptor. No bind(2) is performed. The > connection is initiated from inside a jail (not sure if that implies a > internal bind(2) to the jail's address). There are no connections from > the other host to the first one. And some additional info: subsequent connect()s on the same keep returning EADDRINUSE as well. In order to establish a connection, the application must create a brand new socket and then retry connect(). -- Jan Srzednicki :: http://wrzask.pl/ "Remember, remember, the fifth of November" -- V for Vendetta From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 18:22:17 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7167A16A46D for ; Wed, 28 Nov 2007 18:22:17 +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 CB80B13C4EE for ; Wed, 28 Nov 2007 18:22:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 28 Nov 2007 10:22:15 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 04C2F126B25; Wed, 28 Nov 2007 10:22:14 -0800 (PST) Message-ID: <474DB1D0.3010100@elischer.org> Date: Wed, 28 Nov 2007 10:22:08 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jan Srzednicki References: <20071127135320.GJ2045@oak.pl> In-Reply-To: <20071127135320.GJ2045@oak.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: connect() returns EADDRINUSE during massive host->host conn rate 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, 28 Nov 2007 18:22:17 -0000 Jan Srzednicki wrote: > Hello, > > I have a pair of hosts. One of them performs a massive amount of > TCP connections to the other one, all to the same port. This setup > mostly works fine, but from time to time (that varies, from once a > minute to one a half an hour), the connect(2) syscall fails with > EADDRINUSE. The connection rate tops to 50 connection so, what does netstat -aAn show? > initiations/second. > > The socket is non-blocking. It does standard job of creating the socket, > setting up the relevant fields, setting SO_REUSEADDR and SO_KEEPALIVE, > setting O_NONBLOCK on the descriptor. No bind(2) is performed. The > connection is initiated from inside a jail (not sure if that implies a > internal bind(2) to the jail's address). There are no connections from > the other host to the first one. > > I've tried tuning the net.inet.ip.portrange variables: I've increased > the available portrange to over 45000 ports (quite a lot, should be more > than enough for just anything) and I've toggled > net.inet.ip.portrange.randomized off, but that didn't change anything. > > The workaround on the application side - retrying on EADDRINUSE - works > pretty well, but hey, from what I know from the Stevens book, that > shouldn't be happening, though Google said all BSD had a bad habit of > throwing out EADDRINUSE from time to time. > > This all happens on a 6.2-RELEASE system. The symptoms are easily > reproducable in my environment. > > Is there any known fix for that? If there ain't, can it be fixed? :) > From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 18:30:06 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5168616A477; Wed, 28 Nov 2007 18:30:06 +0000 (UTC) (envelope-from w@wrzask.pl) Received: from mx.oak.pl (mx.oak.pl [217.96.108.251]) by mx1.freebsd.org (Postfix) with ESMTP id F36FE13C45B; Wed, 28 Nov 2007 18:30:03 +0000 (UTC) (envelope-from w@wrzask.pl) Received: by oak.pl (Postfix, from userid 1002) id 0B3721CD1E; Wed, 28 Nov 2007 19:30:02 +0100 (CET) Date: Wed, 28 Nov 2007 19:30:01 +0100 From: Jan Srzednicki To: Julian Elischer Message-ID: <20071128183001.GQ2045@oak.pl> References: <20071127135320.GJ2045@oak.pl> <474DB1D0.3010100@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <474DB1D0.3010100@elischer.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: connect() returns EADDRINUSE during massive host->host conn rate 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, 28 Nov 2007 18:30:06 -0000 On Wed, Nov 28, 2007 at 10:22:08AM -0800, Julian Elischer wrote: > Jan Srzednicki wrote: >> Hello, >> I have a pair of hosts. One of them performs a massive amount of >> TCP connections to the other one, all to the same port. This setup >> mostly works fine, but from time to time (that varies, from once a >> minute to one a half an hour), the connect(2) syscall fails with >> EADDRINUSE. The connection rate tops to 50 connection > > so, what does netstat -aAn show? How can I get any usable information from netstat? It shows a bunch of connections, of course, but since connect(2) failed, I have no idea what local port I was trying to use. And, what I forgot to mention, it's a SMP box, which could matter in case of some race condition. -- Jan Srzednicki :: http://wrzask.pl/ "Remember, remember, the fifth of November" -- V for Vendetta From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 18:43:05 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8992116A46E for ; Wed, 28 Nov 2007 18:43:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id E8DE413C4EF for ; Wed, 28 Nov 2007 18:43:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 28 Nov 2007 10:43:00 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 1524F126B23; Wed, 28 Nov 2007 10:43:00 -0800 (PST) Message-ID: <474DB6B3.1020202@elischer.org> Date: Wed, 28 Nov 2007 10:42:59 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jan Srzednicki References: <20071127135320.GJ2045@oak.pl> <474DB1D0.3010100@elischer.org> <20071128183001.GQ2045@oak.pl> In-Reply-To: <20071128183001.GQ2045@oak.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: connect() returns EADDRINUSE during massive host->host conn rate 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, 28 Nov 2007 18:43:05 -0000 Jan Srzednicki wrote: > On Wed, Nov 28, 2007 at 10:22:08AM -0800, Julian Elischer wrote: >> Jan Srzednicki wrote: >>> Hello, >>> I have a pair of hosts. One of them performs a massive amount of >>> TCP connections to the other one, all to the same port. This setup >>> mostly works fine, but from time to time (that varies, from once a >>> minute to one a half an hour), the connect(2) syscall fails with >>> EADDRINUSE. The connection rate tops to 50 connection >> so, what does netstat -aAn show? > > How can I get any usable information from netstat? It shows a bunch of > connections, of course, but since connect(2) failed, I have no idea what > local port I was trying to use. but you can get an idea of the local socket distribution, and what state all the sockets are in (TIME_WAIT etc). > > And, what I forgot to mention, it's a SMP box, which could matter in > case of some race condition. hopefully not. > From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 19:28:48 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 637CD16A41B; Wed, 28 Nov 2007 19:28:48 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2ABC713C43E; Wed, 28 Nov 2007 19:28:47 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id lASJGSJS001908; Wed, 28 Nov 2007 14:16:28 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Wed, 28 Nov 2007 14:16:28 -0500 (EST) Date: Wed, 28 Nov 2007 14:16:27 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Ivan Voras In-Reply-To: Message-ID: References: <20071127135320.GJ2045@oak.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: connect() returns EADDRINUSE during massive host->host conn rate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2007 19:28:48 -0000 On Wed, 28 Nov 2007, Ivan Voras wrote: > Jan Srzednicki wrote: >> Hello, >> >> I have a pair of hosts. One of them performs a massive amount of >> TCP connections to the other one, all to the same port. This setup >> mostly works fine, but from time to time (that varies, from once a >> minute to one a half an hour), the connect(2) syscall fails with >> EADDRINUSE. The connection rate tops to 50 connection >> initiations/second. > > This looks like the old (and probably well known) problem "ab" has. > ("ab" is "apache benchmark", a utility which is bundled with apache and > which does repeated connections to the specified address, does > transactions and computes some statistics). AFAIK this behaviour was > present since at least 5.2, maybe earlier. No known fixes. Could it have anything to do with the listen backlog on the server end? -- DE From owner-freebsd-net@FreeBSD.ORG Thu Nov 29 08:19:03 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB12716A417 for ; Thu, 29 Nov 2007 08:19:03 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id B6CBB13C4EC for ; Thu, 29 Nov 2007 08:19:03 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 3844957B93; Thu, 29 Nov 2007 03:19:03 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 29 Nov 2007 03:19:03 -0500 X-Sasl-enc: ZH7EDsohPY84O5sgwN6UPqILN0sVGCcuXk2DQc52XhYg 1196324342 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 9578A1B29A; Thu, 29 Nov 2007 03:19:02 -0500 (EST) Message-ID: <474E75F5.80307@FreeBSD.org> Date: Thu, 29 Nov 2007 08:19:01 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <474B24F3.2030603@netability.ie> <20071126224649.C53707@maildrop.int.zabbadoz.net> <474CC3EC.1010205@netability.ie> <20071128062332.E53707@maildrop.int.zabbadoz.net> <20071128064738.S53707@maildrop.int.zabbadoz.net> <20071128145744.G53707@maildrop.int.zabbadoz.net> In-Reply-To: <20071128145744.G53707@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Nick Hilliard Subject: Re: tcp md5 checksums broken in 7.0-beta3 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, 29 Nov 2007 08:19:03 -0000 Bjoern, Thanks very much for tracking down and fixing this regression. When I originally worked on tcp-md5 around 4 years ago, I didn't have the luxury of fast enough machines to run VMs, and open source VMs were considerably less mature. One idea that's occurred to me, working on my current project, is to be able to run FreeBSD in a virtual machine type emulator (such as QEMU or Bochs) as part of a battery of regression tests. This has the advantage that no invasive changes are needed to regression test the networking code, other than customising the kernel config for the tests, and hooking up the appropriate software 'test probes' to the kernel under test. It has the disadvantage that some form of temporary store for the root filesystem needs to be presented to the kernel under test. I guess this could be dealt with by using some kind of NFS server -- again, this also has the disadvantage that it goes through the networking code, so being able to slap together a very minimal root fs image file would be useful here. Thanks again... BMS From owner-freebsd-net@FreeBSD.ORG Thu Nov 29 10:05:32 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5413616A417 for ; Thu, 29 Nov 2007 10:05:32 +0000 (UTC) (envelope-from nick-lists@netability.ie) Received: from mail.acquirer.com (mail.acquirer.com [87.198.142.10]) by mx1.freebsd.org (Postfix) with ESMTP id E3A9F13C467 for ; Thu, 29 Nov 2007 10:05:31 +0000 (UTC) (envelope-from nick-lists@netability.ie) X-Envelope-To: freebsd-net@freebsd.org Received: from crumpet.foobar.org (twinkie.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.acquirer.com (8.13.6/8.13.8) with ESMTP id lATA5IuQ048896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2007 10:05:25 GMT (envelope-from nick-lists@netability.ie) Message-ID: <474E8EDC.9050809@netability.ie> Date: Thu, 29 Nov 2007 10:05:16 +0000 From: Nick Hilliard User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <474B24F3.2030603@netability.ie> <20071126224649.C53707@maildrop.int.zabbadoz.net> <474CC3EC.1010205@netability.ie> <20071128062332.E53707@maildrop.int.zabbadoz.net> <20071128064738.S53707@maildrop.int.zabbadoz.net> <20071128145744.G53707@maildrop.int.zabbadoz.net> In-Reply-To: <20071128145744.G53707@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on muffin.acquirer.com X-Virus-Scanned: ClamAV 0.91.2/4950/Thu Nov 29 08:49:26 2007 on muffin.acquirer.com X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: tcp md5 checksums broken in 7.0-beta3 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, 29 Nov 2007 10:05:32 -0000 > In addition to that can you try this patch: > http://sources.zabbadoz.net/freebsd/patchset/patch-20071128-03-tcp-md5.diff > > I have to admit, I haven't tried it after my last merges so I hope I > got the merges right;-) I've manually patched a 7.0 kernel with these changes, and it seems to work well. thanks! Nick From owner-freebsd-net@FreeBSD.ORG Fri Nov 30 09:36:30 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 132E016A417; Fri, 30 Nov 2007 09:36:30 +0000 (UTC) (envelope-from w@wrzask.pl) Received: from mx.oak.pl (mx.oak.pl [217.96.108.251]) by mx1.freebsd.org (Postfix) with ESMTP id 933B613C457; Fri, 30 Nov 2007 09:36:29 +0000 (UTC) (envelope-from w@wrzask.pl) Received: by oak.pl (Postfix, from userid 1002) id 72A3F1CCD9; Fri, 30 Nov 2007 10:36:28 +0100 (CET) Date: Fri, 30 Nov 2007 10:36:28 +0100 From: Jan Srzednicki To: Julian Elischer Message-ID: <20071130093628.GS2045@oak.pl> References: <20071127135320.GJ2045@oak.pl> <474DB1D0.3010100@elischer.org> <20071128183001.GQ2045@oak.pl> <474DB6B3.1020202@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <474DB6B3.1020202@elischer.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: connect() returns EADDRINUSE during massive host->host conn rate 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, 30 Nov 2007 09:36:30 -0000 On Wed, Nov 28, 2007 at 10:42:59AM -0800, Julian Elischer wrote: > Jan Srzednicki wrote: >> On Wed, Nov 28, 2007 at 10:22:08AM -0800, Julian Elischer wrote: >> How can I get any usable information from netstat? It shows a bunch of >> connections, of course, but since connect(2) failed, I have no idea what >> local port I was trying to use. > but you can get an idea of the local socket distribution, and what state > all the sockets are in (TIME_WAIT etc). Most of the relevant sockets (that is, between the two host mentioned) are in the ESTABLISHED state (200-400 of those). Only 20-40 are in TIME_WAIT state (these tend to be from a more ephemeric POP3 service). Most of the EADDRINUSE happen for the IMAP4 service. -- Jan Srzednicki :: http://wrzask.pl/ "Remember, remember, the fifth of November" -- V for Vendetta From owner-freebsd-net@FreeBSD.ORG Fri Nov 30 10:54:28 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3C8F16A417 for ; Fri, 30 Nov 2007 10:54:28 +0000 (UTC) (envelope-from adrian.chadd@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 564C413C45A for ; Fri, 30 Nov 2007 10:54:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so4826878pyb for ; Fri, 30 Nov 2007 02:54:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=76Jwf1kiw3PaR/8huV4De74eEIj26uXSTM60tUviAsc=; b=v3cT6I4JLLxjRvi7g/h4tF6IFVQQ8IuiwHkY1uNpGLOgcsIZFyV6FxWmlaE+l4wLa1otfxzULLizg9OW6QLc+VmNJSdCGh1P8f8SrtYPsLplsbURtnTp7rBNUmdJQJ6Jl4dupTowyRVAer5Kp/jrM8ThUALB3gXNuUrQiq1GxWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Vh4hc+MpqTkjfP3FKcPmvwsCSh03IVZUrOLk9RzCiRkNZqwjAwW5GaiofnnN5WKRT8kgeI4hL5h7zbz8xLlze6WoWfUqbxxVlSn4rXtObLfsRGn3UE94uj7RgfJrwux50QVIF2r5VdMhEYhGxj7NjleUoVSHFwJOYJXppJo9UeY= Received: by 10.65.242.7 with SMTP id u7mr507745qbr.1196418374623; Fri, 30 Nov 2007 02:26:14 -0800 (PST) Received: by 10.65.155.16 with HTTP; Fri, 30 Nov 2007 02:26:14 -0800 (PST) Message-ID: Date: Fri, 30 Nov 2007 19:26:14 +0900 From: "Adrian Chadd" Sender: adrian.chadd@gmail.com To: "Jan Srzednicki" In-Reply-To: <20071130093628.GS2045@oak.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071127135320.GJ2045@oak.pl> <474DB1D0.3010100@elischer.org> <20071128183001.GQ2045@oak.pl> <474DB6B3.1020202@elischer.org> <20071130093628.GS2045@oak.pl> X-Google-Sender-Auth: ef1752d998247e30 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Julian Elischer Subject: Re: connect() returns EADDRINUSE during massive host->host conn rate 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, 30 Nov 2007 10:54:28 -0000 On 30/11/2007, Jan Srzednicki wrote: > Most of the relevant sockets (that is, between the two host mentioned) > are in the ESTABLISHED state (200-400 of those). Only 20-40 are in > TIME_WAIT state (these tend to be from a more ephemeric POP3 service). Most > of the EADDRINUSE happen for the IMAP4 service. I'd probably start by patching the places in the tcp code (src/sys/netinet/tcp_usrreq.c) which returns this error (Its returned in other places but that seems to me to be the most likely from your description.) Insert some code to print out information about the current socket and the "oinp" value returned from in_pcbconnect_setup() (if this is the place where the error occured.) Finding out more about the socket thats been created and what its clashing with might help. I'd do it myself but I'm not sure how to duplicate the issue. Adrian -- Adrian Chadd - adrian@freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Nov 30 11:09:02 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE7B516A421 for ; Fri, 30 Nov 2007 11:09:02 +0000 (UTC) (envelope-from buddy@telenet.ru) Received: from postman.telenet.ru (k66.ru [87.224.128.21]) by mx1.freebsd.org (Postfix) with ESMTP id 79FCD13C46A for ; Fri, 30 Nov 2007 11:09:02 +0000 (UTC) (envelope-from buddy@telenet.ru) Received: by postman.telenet.ru (Postfix, from userid 58) id 5F3661FA; Fri, 30 Nov 2007 15:51:15 +0500 (YEKT) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on postman.telenet.ru X-Spam-Level: X-Spam-Status: No, score=-12.0 required=5.0 Received: from machine.hq.telenet.ru (off.telenet.ru [87.224.188.131]) by postman.telenet.ru (Postfix) with ESMTP id 0A2B41F0 for ; Fri, 30 Nov 2007 15:51:15 +0500 (YEKT) Date: Fri, 30 Nov 2007 15:50:32 +0500 From: Andrew Alcheyev X-Mailer: The Bat! (v3.80.06) Professional Organization: Telenet-Service Ltd. X-Priority: 3 (Normal) Message-ID: <1736192477.20071130155032@telenet.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: per-socket keep-alive options for TCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Alcheyev List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2007 11:09:02 -0000 Hello everybody. I have recently examined the keep-alive mechanism in FreeBSD's TCP stack and found out that it has no tunable variables for keep-alive on a per-socket basis. Is anyone interested in a patch like this one? http://mail-index.netbsd.org/tech-net/2007/06/19/0001.html Alternatively, a patch for FreeBSD may introduce a new kernel option. I would appreciate any suggestions. From owner-freebsd-net@FreeBSD.ORG Fri Nov 30 12:52:24 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1E1816A418 for ; Fri, 30 Nov 2007 12:52:24 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 9114313C478 for ; Fri, 30 Nov 2007 12:52:24 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 392655666D; Fri, 30 Nov 2007 07:52:24 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 30 Nov 2007 07:52:24 -0500 X-Sasl-enc: y3cKF7fmaH0uM1NWz+NbGyPZ0nxud7gyCp5z2hyMgko+ 1196427143 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id B9D932DA5; Fri, 30 Nov 2007 07:52:23 -0500 (EST) Message-ID: <47500786.9050902@FreeBSD.org> Date: Fri, 30 Nov 2007 12:52:22 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Andrew Alcheyev References: <1736192477.20071130155032@telenet.ru> In-Reply-To: <1736192477.20071130155032@telenet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: per-socket keep-alive options for TCP 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, 30 Nov 2007 12:52:24 -0000 Andrew Alcheyev wrote: > I have recently examined the keep-alive mechanism in FreeBSD's TCP > stack and found out that it has no tunable variables for keep-alive on > a per-socket basis. > Is anyone interested in a patch like this one? > http://mail-index.netbsd.org/tech-net/2007/06/19/0001.html > > Alternatively, a patch for FreeBSD may introduce a new kernel option. > I would appreciate any suggestions. > Seems reasonable. This thread talks about the Solaris implementation and the general background to keep-alives: http://jj.tingiris.net/archives/6-TCP_KEEPALIVE-and-SO_KEEPALIVE-on-Solaris.html And this thread mentions its use in PostgreSQL: http://qaix.com/postgresql-database-development/336-230-re-implement-support-for-tcp-keepcnt-tcp-keepidle-tcp-keepintvl-read.shtml I'm a bit wary of importing new features into a sensitive and heavily used module like TCP without regression tests, though, and it should probably default to the current sysctl defaults in use (default to keepalives on for each new tcp socket) for traversing stateful firewalls on the path. However in this case we are merely introducing new knobs for fine-tuning the keep-alive behaviour, so no big worry here. Being able to tune on a per-socket basis is *somewhat* useful, however what would be useful in the bigger picture is the ability to tune TCP behaviour based on path selection, where the path currently chosen has radically different characteristics from the general case (e.g. GPRS, UMTS, satellite systems). Cheers, BMS From owner-freebsd-net@FreeBSD.ORG Fri Nov 30 19:04:41 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E945E16A41B; Fri, 30 Nov 2007 19:04:41 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C989413C458; Fri, 30 Nov 2007 19:04:41 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lAUJ4fmv067308; Fri, 30 Nov 2007 19:04:41 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lAUJ4fqu067304; Fri, 30 Nov 2007 19:04:41 GMT (envelope-from remko) Date: Fri, 30 Nov 2007 19:04:41 GMT Message-Id: <200711301904.lAUJ4fqu067304@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/106438: hme0: Interface unable to do tx and rx checksumming when using ipfilter. 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, 30 Nov 2007 19:04:42 -0000 Old Synopsis: [ipfilter] keep state does not seem to allow replies in on spar64 (and maybe others) New Synopsis: hme0: Interface unable to do tx and rx checksumming when using ipfilter. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Fri Nov 30 19:03:15 UTC 2007 Responsible-Changed-Why: Reassign to -net, this seems like a problem with the hme driver I can reproduce this on 8-CURRENT on my sparc64, after issueing a ifconfig hme0 -rxcsum and -txcsum the problem vanished and I could connect again (ipfilter stopped the packets since they had bad data included). http://www.freebsd.org/cgi/query-pr.cgi?pr=106438 From owner-freebsd-net@FreeBSD.ORG Fri Nov 30 19:10:03 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D5E916A41B for ; Fri, 30 Nov 2007 19:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 022E813C45A for ; Fri, 30 Nov 2007 19:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lAUJA2JU067502 for ; Fri, 30 Nov 2007 19:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lAUJA2K4067501; Fri, 30 Nov 2007 19:10:02 GMT (envelope-from gnats) Date: Fri, 30 Nov 2007 19:10:02 GMT Message-Id: <200711301910.lAUJA2K4067501@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Remko Lodder Cc: Subject: Re: kern/106438: ipfilter: keep state does not seem to allow replies in on spar64 (and maybe others) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Remko Lodder List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2007 19:10:03 -0000 The following reply was made to PR kern/106438; it has been noted by GNATS. From: Remko Lodder To: Manuel Tobias Schiller Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/106438: ipfilter: keep state does not seem to allow replies in on spar64 (and maybe others) Date: Fri, 30 Nov 2007 20:03:31 +0100 Manuel Tobias Schiller wrote: > Hello, > > I've gathered the information you have asked for, see the attachment. > I hope it helps us to get an idea of what's going wrong. Any help with > this would be appreciated. > > Thanks in advance. > > Manuel > > P.S. I did the | grep hme3 in the attachment to not clutter the output > with irrelevant stuff. All other rules are bound to their respective > interface (hme0, hme1, hme2, le0) and should not influence hme3. > Besides, there's a lot of traffic going on on le0 which does not need to > be mentioned in the ipfstat output because the machine in question is > headless and can only be reached with a serial line (with a laptop down > in the cellar) or a dedicated network interface (le0, for which I > need to have rules that pass everything). > > On Thu, Dec 07, 2006 at 10:16:19AM +0100, Remko Lodder wrote: >> Hello, >> >> >> First of all thanks for using FreeBSD! >> >> If you run ipmon, what kind of details do you see in the log? It mentions where it is blocked and you >> can review that rule with ipfstat -hion (list everything in out, do not resolve and show the amount >> of hits on the rule) >> >> Thanks in advance >> >> -- >> Kind regards, >> >> Remko Lodder ** remko@elvandar.org >> FreeBSD ** remko@FreeBSD.org >> >> /* Quis custodiet ipsos custodes */ >> > Dear Manuel, It took a lot of time for me to set this up properly, but I managed to work this out; actually this is not a ipfilter problem but it seems that hme0 is not capable of doing incoming and outgoing checksumming. I faced the same problem, and by issueing a ifconfig hme0 -txcsum -rxcsum I resolved the problem. The ipfilter errors vanished after that. I'll try to have a look at the intel gigabit card in the machine (manually added) and see whether that has a similiar issue.. Cheers remko -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Fri Nov 30 19:34:53 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F70D16A468 for ; Fri, 30 Nov 2007 19:34:53 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.184]) by mx1.freebsd.org (Postfix) with ESMTP id E0B3813C4EA for ; Fri, 30 Nov 2007 19:34:52 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by mu-out-0910.google.com with SMTP id i10so8524mue for ; Fri, 30 Nov 2007 11:34:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; bh=TMwNcX0A2hu2XibLQ/HGicmKRXjQ2SBxAbO8iTacuDs=; b=GlrZuE46QUaFfZVbnJcGGokX/v2WuB+BXxKF3w7w/k/IF8v7g1r4JEfgtS6l2JNT+NpD6Ij+uWuGE8cNlQ5FiuDB04JOpUvINsTKUgClGmXs/2A8tqYrM7aUO62v2+Cp4eSL1uQUxv5xPeMbIlMlERFmdik16XkBBzJi0Uv7wKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=QpDrBnJE8s1Ylw2a+hxbD6+Jy5IJc4VKvwaLVZxMzugdNj5yCirqblg+fY5Il5hIO3OQL8b2T0SqMCoG2POa4IKLrP8zYY4m4z+4ohRUoSaSLyaBoIygOibaP+DwKHGOk4x1kxw4rh/ReiIu3tKHVvG/s4yMW+oGK8z1EY0G6JA= Received: by 10.82.146.14 with SMTP id t14mr1903121bud.1196451291026; Fri, 30 Nov 2007 11:34:51 -0800 (PST) Received: from epsilon.local ( [83.144.140.64]) by mx.google.com with ESMTPS id y34sm7030956iky.2007.11.30.11.34.49 (version=SSLv3 cipher=RC4-MD5); Fri, 30 Nov 2007 11:34:50 -0800 (PST) Message-ID: <475049A7.8090808@FreeBSD.org> Date: Fri, 30 Nov 2007 17:34:31 +0000 From: Rui Paulo User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <26032689-AD73-4836-8AA1-65915F1D2857@FreeBSD.org> <474BDA7F.3030608@FreeBSD.org> In-Reply-To: <474BDA7F.3030608@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Rui Paulo Cc: freebsd-net@freebsd.org Subject: Re: TCP ECN patch for review X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2007 19:34:53 -0000 Bruce M. Simpson wrote: > I'm very pleased to see ECN finally being implemented in FreeBSD. > > Whilst I can't offer technical assistance in testing or review at this > time, I would like to thank you for the clearly professional level of > effort you have put into this. Thanks! Much appreciated! -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Fri Nov 30 23:55:07 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AE6516A418 for ; Fri, 30 Nov 2007 23:55:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0678113C448 for ; Fri, 30 Nov 2007 23:55:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 2D58041C752; Sat, 1 Dec 2007 00:55:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id nG3VoRivNp3t; Sat, 1 Dec 2007 00:55:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id AC8B241C71E; Sat, 1 Dec 2007 00:55:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 126934448EC; Fri, 30 Nov 2007 23:50:17 +0000 (UTC) Date: Fri, 30 Nov 2007 23:50:17 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Nick Hilliard In-Reply-To: <474E8EDC.9050809@netability.ie> Message-ID: <20071130234736.Y53707@maildrop.int.zabbadoz.net> References: <474B24F3.2030603@netability.ie> <20071126224649.C53707@maildrop.int.zabbadoz.net> <474CC3EC.1010205@netability.ie> <20071128062332.E53707@maildrop.int.zabbadoz.net> <20071128064738.S53707@maildrop.int.zabbadoz.net> <20071128145744.G53707@maildrop.int.zabbadoz.net> <474E8EDC.9050809@netability.ie> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: tcp md5 checksums broken in 7.0-beta3 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, 30 Nov 2007 23:55:07 -0000 On Thu, 29 Nov 2007, Nick Hilliard wrote: Hi, >> In addition to that can you try this patch: >> http://sources.zabbadoz.net/freebsd/patchset/patch-20071128-03-tcp-md5.diff >> >> I have to admit, I haven't tried it after my last merges so I hope I >> got the merges right;-) > > I've manually patched a 7.0 kernel with these changes, and it seems to work > well. I have just comitted a slightly less intrusive version (no unneeded whitespace change and that) to HEAD and will try to get them MFCed beginning of next week. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 01:28:47 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF4DF16A46C for ; Sat, 1 Dec 2007 01:28:47 +0000 (UTC) (envelope-from prvs=julian=848774d93@elischer.org) Received: from c60-outbound.ironport.com (c60-outbound.ironport.com [63.251.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id CC8E813C461 for ; Sat, 1 Dec 2007 01:28:47 +0000 (UTC) (envelope-from prvs=julian=848774d93@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by c60-outbound.ironport.com with ESMTP; 30 Nov 2007 17:00:27 -0800 Message-ID: <4750B229.6070507@elischer.org> Date: Fri, 30 Nov 2007 17:00:25 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: dup code in in6.c 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, 01 Dec 2007 01:28:48 -0000 The following diff removes some (whart looks to me to be) duplicate code. Anyone care to comment before I commit it? (I'm trying to imagine a case where it does something useful to do this twice but not really succeeding). Index: in6.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6.c,v retrieving revision 1.73 diff -u -r1.73 in6.c --- in6.c 5 Jul 2007 16:29:39 -0000 1.73 +++ in6.c 1 Dec 2007 00:56:25 -0000 @@ -1113,32 +1113,6 @@ */ rt = rtalloc1((struct sockaddr *)&mltaddr, 0, 0UL); if (rt) { - if (memcmp(&mltaddr.sin6_addr, - &((struct sockaddr_in6 *)rt_key(rt))->sin6_addr, - MLTMASK_LEN)) { - RTFREE_LOCKED(rt); - rt = NULL; - } - } - if (!rt) { - /* XXX: we need RTF_CLONING to fake nd6_rtrequest */ - error = rtrequest(RTM_ADD, (struct sockaddr *)&mltaddr, - (struct sockaddr *)&ia->ia_addr, - (struct sockaddr *)&mltmask, RTF_UP | RTF_CLONING, - (struct rtentry **)0); - if (error) - goto cleanup; - } else - RTFREE_LOCKED(rt); - - /* - * XXX: do we really need this automatic routes? - * We should probably reconsider this stuff. Most applications - * actually do not need the routes, since they usually specify - * the outgoing interface. - */ - rt = rtalloc1((struct sockaddr *)&mltaddr, 0, 0UL); - if (rt) { /* XXX: only works in !SCOPEDROUTING case. */ if (memcmp(&mltaddr.sin6_addr, &((struct sockaddr_in6 *)rt_key(rt))->sin6_addr, @@ -1148,6 +1122,7 @@ } } if (!rt) { + /* XXX: we need RTF_CLONING to fake nd6_rtrequest */ error = rtrequest(RTM_ADD, (struct sockaddr *)&mltaddr, (struct sockaddr *)&ia->ia_addr, (struct sockaddr *)&mltmask, RTF_UP | RTF_CLONING, From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 04:21:09 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4371716A417 for ; Sat, 1 Dec 2007 04:21:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 1035013C46E for ; Sat, 1 Dec 2007 04:21:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so3448526waf for ; Fri, 30 Nov 2007 20:21:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=H33YEHt+/Zom9hV0/wcspK5sWFhAZ+6UcnRND9mRuUU=; b=bK/y1ujYYr4JzWJwoDwIcE4cNLV9tXe2rutxzAZHBtezuuouz9zmDVz3jjOEC+RgPTeOuHEKvNQAEm7D7rorqPXhzvwxjEZeyLwqPWScdozru1xb+wKwm7SiWukvgNb0+xz+evIF7L68SvTL1+toBC7djrtsMCVgDTYNuwmQKI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=St4rTYGvtgIyfEtxXXSxDfENJvPkr61cgDbOtYOFxI4dRXaioP9PAc4zI5kFt6WuA5b3A9QVwiM8vMUqxfkpCvMJSowJhl6PZwrG47KCUSX3WFwGXOPBCcHA9wGm4VLLpTvV9Arm9WBPr21s90csCQJeWwjOPXqxLsih85oOdsA= Received: by 10.114.78.1 with SMTP id a1mr70249wab.1196482867492; Fri, 30 Nov 2007 20:21:07 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id m24sm2462276waf.2007.11.30.20.21.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Nov 2007 20:21:05 -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 lB14K2GY023862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Dec 2007 13:20:02 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id lB14K1uY023861; Sat, 1 Dec 2007 13:20:01 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 1 Dec 2007 13:20:01 +0900 From: Pyun YongHyeon To: remko@FreeBSD.org Message-ID: <20071201042001.GB23527@cdnetworks.co.kr> References: <200711301904.lAUJ4fqu067304@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200711301904.lAUJ4fqu067304@freefall.freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/106438: hme0: Interface unable to do tx and rx checksumming when using ipfilter. 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: Sat, 01 Dec 2007 04:21:09 -0000 On Fri, Nov 30, 2007 at 07:04:41PM +0000, remko@FreeBSD.org wrote: > Old Synopsis: [ipfilter] keep state does not seem to allow replies in on spar64 (and maybe others) > New Synopsis: hme0: Interface unable to do tx and rx checksumming when using ipfilter. > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: remko > Responsible-Changed-When: Fri Nov 30 19:03:15 UTC 2007 > Responsible-Changed-Why: > Reassign to -net, this seems like a problem with the hme driver > I can reproduce this on 8-CURRENT on my sparc64, after issueing > a ifconfig hme0 -rxcsum and -txcsum the problem vanished and > I could connect again (ipfilter stopped the packets since they > had bad data included). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=106438 I didn't know hme(4) have checksum offload related issues. When I tried the same rule as PR I also noticed that Rx UDP packet was dropped. However I couldn't reproduce it with pf. You can easily use identical rule with small modification(flags S/SA instead of flags S). I'm not familiar with ipf internals so I'm not sure what caused the issue. Given that pf works well I guess there would be somthing in ipf that needs more attention. Remko, would you retry it with pf on sparc64? -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 10:30:07 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 327DB16A418 for ; Sat, 1 Dec 2007 10:30:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2D81D13C459 for ; Sat, 1 Dec 2007 10:30:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lB1AU6Mn032839 for ; Sat, 1 Dec 2007 10:30:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lB1AU6ZF032836; Sat, 1 Dec 2007 10:30:06 GMT (envelope-from gnats) Date: Sat, 1 Dec 2007 10:30:06 GMT Message-Id: <200712011030.lB1AU6ZF032836@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Manuel Tobias Schiller Cc: Subject: Re: kern/106438: ipfilter: keep state does not seem to allow replies in on spar64 (and maybe others) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manuel Tobias Schiller List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2007 10:30:07 -0000 The following reply was made to PR kern/106438; it has been noted by GNATS. From: Manuel Tobias Schiller To: Remko Lodder Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/106438: ipfilter: keep state does not seem to allow replies in on spar64 (and maybe others) Date: Sat, 1 Dec 2007 11:11:00 +0100 On Fri, 30 Nov 2007 20:03:31 +0100 Remko Lodder wrote: > Manuel Tobias Schiller wrote: > > Hello, > > > > I've gathered the information you have asked for, see the > > attachment. I hope it helps us to get an idea of what's going > > wrong. Any help with this would be appreciated. > > > > Thanks in advance. > > > > Manuel > > > > P.S. I did the | grep hme3 in the attachment to not clutter the > > output with irrelevant stuff. All other rules are bound to their > > respective interface (hme0, hme1, hme2, le0) and should not > > influence hme3. Besides, there's a lot of traffic going on on le0 > > which does not need to be mentioned in the ipfstat output because > > the machine in question is headless and can only be reached with a > > serial line (with a laptop down in the cellar) or a dedicated > > network interface (le0, for which I need to have rules that pass > > everything). > > > > On Thu, Dec 07, 2006 at 10:16:19AM +0100, Remko Lodder wrote: > >> Hello, > >> > >> > >> First of all thanks for using FreeBSD! > >> > >> If you run ipmon, what kind of details do you see in the > >> log? It mentions where it is blocked and you can review that rule > >> with ipfstat -hion (list everything in out, do not resolve and > >> show the amount of hits on the rule) > >> > >> Thanks in advance > >> > >> -- > >> Kind regards, > >> > >> Remko Lodder ** remko@elvandar.org > >> FreeBSD ** remko@FreeBSD.org > >> > >> /* Quis custodiet ipsos custodes */ > >> > > > > Dear Manuel, > > It took a lot of time for me to set this up properly, but I managed to > work this out; actually this is not a ipfilter problem but it seems > that hme0 is not capable of doing incoming and outgoing checksumming. > > I faced the same problem, and by issueing a ifconfig hme0 -txcsum > -rxcsum I resolved the problem. > > The ipfilter errors vanished after that. I'll try to have a look at > the intel gigabit card in the machine (manually added) and see > whether that has a similiar issue.. > > Cheers > remko Dear Remko, it's great to hear from you again - I thought everybody had forgotten about this... Well, I have switched to pf in the meantime, as it's a production machine, but I may have time over christmas to test things out with ipfilter, as I like it very much. By the way, why did things work with hme and ipfilter in earlier FreeBSD versions? Did hme not have the checksumming feature at all or different defaults? This puzzles me a little, I must confess. Anyway, thanks a lot for your help! Cheers, Manuel -- Homepage: http://www.hinterbergen.de/mala OpenPGP: 0xA330353E (DSA) or 0xD87D188C (RSA) From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 21:33:04 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EACF16A419 for ; Sat, 1 Dec 2007 21:33:04 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 0406F13C447 for ; Sat, 1 Dec 2007 21:33:03 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 20A282C2B9B for ; Sat, 1 Dec 2007 15:04:29 -0600 (CST) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xTPc2T2FY97o; Sat, 1 Dec 2007 15:04:28 -0600 (CST) Received: from [216.63.78.18] (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 299592C2AD3; Sat, 1 Dec 2007 15:04:28 -0600 (CST) Message-ID: <4751CC5B.3080402@cs.rice.edu> Date: Sat, 01 Dec 2007 15:04:27 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070805 X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Content-Type: multipart/mixed; boundary="------------020500040502090607020205" Cc: Alan Cox Subject: physically contiguous jumbo frames 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, 01 Dec 2007 21:33:04 -0000 This is a multi-part message in MIME format. --------------020500040502090607020205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The reimplementation of contigmalloc(9) in HEAD and RELENG_7 makes the allocation of physically contiguous jumbo frames a real possibility. If you're using jumbo frames, please test the attached patch. Andrew Gallatin has already tested this patch with mxge and asked that I bump __FreeBSD_version. Thanks, Alan --------------020500040502090607020205 Content-Type: text/plain; name="jumbo_contig.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="jumbo_contig.patch" Index: kern/kern_mbuf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_mbuf.c,v retrieving revision 1.34 diff -p -u -r1.34 kern_mbuf.c --- kern/kern_mbuf.c 26 Oct 2007 16:33:47 -0000 1.34 +++ kern/kern_mbuf.c 27 Nov 2007 11:25:59 -0000 @@ -166,6 +166,10 @@ static void mb_zfini_pack(void *, int); static void mb_reclaim(void *); static void mbuf_init(void *); +static void *mbuf_jumbo_alloc(uma_zone_t, int, u_int8_t *, int); +static void mbuf_jumbo_free(void *, int, u_int8_t); + +static MALLOC_DEFINE(M_JUMBOFRAME, "jumboframes", "mbuf jumbo frame buffers"); /* Ensure that MSIZE doesn't break dtom() - it must be a power of 2 */ CTASSERT((((MSIZE - 1) ^ MSIZE) + 1) >> 1 == MSIZE); @@ -226,6 +230,8 @@ mbuf_init(void *dummy) UMA_ALIGN_PTR, UMA_ZONE_REFCNT); if (nmbjumbo9 > 0) uma_zone_set_max(zone_jumbo9, nmbjumbo9); + uma_zone_set_allocf(zone_jumbo9, mbuf_jumbo_alloc); + uma_zone_set_freef(zone_jumbo9, mbuf_jumbo_free); zone_jumbo16 = uma_zcreate(MBUF_JUMBO16_MEM_NAME, MJUM16BYTES, mb_ctor_clust, mb_dtor_clust, @@ -237,6 +243,8 @@ mbuf_init(void *dummy) UMA_ALIGN_PTR, UMA_ZONE_REFCNT); if (nmbjumbo16 > 0) uma_zone_set_max(zone_jumbo16, nmbjumbo16); + uma_zone_set_allocf(zone_jumbo16, mbuf_jumbo_alloc); + uma_zone_set_freef(zone_jumbo16, mbuf_jumbo_free); zone_ext_refcnt = uma_zcreate(MBUF_EXTREFCNT_MEM_NAME, sizeof(u_int), NULL, NULL, @@ -274,6 +282,31 @@ mbuf_init(void *dummy) } /* + * UMA backend page allocator for the jumbo frame zones. + * + * Allocates kernel virtual memory that is backed by contiguous physical + * pages. + */ +static void * +mbuf_jumbo_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) +{ + + *flags = UMA_SLAB_PRIV; + return (contigmalloc(bytes, M_JUMBOFRAME, wait, (vm_paddr_t)0, + ~(vm_paddr_t)0, 1, 0)); +} + +/* + * UMA backend page deallocator for the jumbo frame zones. + */ +static void +mbuf_jumbo_free(void *mem, int size, u_int8_t flags) +{ + + contigfree(mem, size, M_JUMBOFRAME); +} + +/* * Constructor for Mbuf master zone. * * The 'arg' pointer points to a mb_args structure which Index: sys/param.h =================================================================== RCS file: /home/ncvs/src/sys/sys/param.h,v retrieving revision 1.315 diff -p -u -r1.315 param.h --- sys/param.h 28 Nov 2007 21:54:46 -0000 1.315 +++ sys/param.h 30 Nov 2007 18:34:29 -0000 @@ -57,7 +57,7 @@ * is created, otherwise 1. */ #undef __FreeBSD_version -#define __FreeBSD_version 800004 /* Master, propagated to newvers */ +#define __FreeBSD_version 800005 /* Master, propagated to newvers */ #ifndef LOCORE #include --------------020500040502090607020205--