From owner-freebsd-net@FreeBSD.ORG Sun Sep 24 00:38:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B001316A407 for ; Sun, 24 Sep 2006 00:38:03 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C4DE43D4C for ; Sun, 24 Sep 2006 00:38:03 +0000 (GMT) (envelope-from bmah@freebsd.org) Received: from [192.168.2.119] (hornet.kitchenlab.org [64.142.31.105]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k8O0c2uV004773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Sep 2006 17:38:03 -0700 Message-ID: <4515D360.6020600@freebsd.org> Date: Sat, 23 Sep 2006 17:37:52 -0700 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Bruce M Simpson References: <45159D63.2090108@incunabulum.net> In-Reply-To: <45159D63.2090108@incunabulum.net> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9502DDD050FA0F10E99B23C8" Cc: freebsd-net@freebsd.org Subject: Re: De-orbitting tcpslice 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, 24 Sep 2006 00:38:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9502DDD050FA0F10E99B23C8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Bruce M Simpson wrote: > We have tcpslice maintained in ports. We have ancient tcpslice in base = > system. We have PRs about it. >=20 > I'd like to nuke it in HEAD. >=20 > How does everyone else feel about that before I go off and do it? +1 Bruce. --------------enig9502DDD050FA0F10E99B23C8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFFdNl2MoxcVugUsMRAitaAKCPvIdGOohjdXOP6k//UXLGzqYSEwCfX9fA SFZ8piWt6jaKBgb4mxIuS4g= =i1MG -----END PGP SIGNATURE----- --------------enig9502DDD050FA0F10E99B23C8-- From owner-freebsd-net@FreeBSD.ORG Sun Sep 24 08:57:31 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82C7C16A403; Sun, 24 Sep 2006 08:57:31 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E9F343D46; Sun, 24 Sep 2006 08:57:31 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k8O8vV9b034835; Sun, 24 Sep 2006 08:57:31 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k8O8vV6H034831; Sun, 24 Sep 2006 08:57:31 GMT (envelope-from bms) Date: Sun, 24 Sep 2006 08:57:31 GMT From: Bruce M Simpson Message-Id: <200609240857.k8O8vV6H034831@freefall.freebsd.org> To: bms@FreeBSD.org, freebsd-net@FreeBSD.org, gnn@FreeBSD.org Cc: Subject: Re: kern/65616: IPSEC can't detunnel GRE packets after real ESP encryption 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, 24 Sep 2006 08:57:31 -0000 Synopsis: IPSEC can't detunnel GRE packets after real ESP encryption Responsible-Changed-From-To: freebsd-net->gnn Responsible-Changed-By: bms Responsible-Changed-When: Sun Sep 24 08:57:20 UTC 2006 Responsible-Changed-Why: by request http://www.freebsd.org/cgi/query-pr.cgi?pr=65616 From owner-freebsd-net@FreeBSD.ORG Sun Sep 24 08:57:52 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8151016A403; Sun, 24 Sep 2006 08:57:52 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 406F943D46; Sun, 24 Sep 2006 08:57:51 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k8O8vpU5034882; Sun, 24 Sep 2006 08:57:51 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k8O8vpVl034878; Sun, 24 Sep 2006 08:57:51 GMT (envelope-from bms) Date: Sun, 24 Sep 2006 08:57:51 GMT From: Bruce M Simpson Message-Id: <200609240857.k8O8vpVl034878@freefall.freebsd.org> To: bms@FreeBSD.org, freebsd-net@FreeBSD.org, gnn@FreeBSD.org Cc: Subject: Re: kern/56233: IPsec tunnel (ESP) over IPv6: MTU computation is wrong 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, 24 Sep 2006 08:57:52 -0000 Synopsis: IPsec tunnel (ESP) over IPv6: MTU computation is wrong Responsible-Changed-From-To: freebsd-net->gnn Responsible-Changed-By: bms Responsible-Changed-When: Sun Sep 24 08:57:37 UTC 2006 Responsible-Changed-Why: by request http://www.freebsd.org/cgi/query-pr.cgi?pr=56233 From owner-freebsd-net@FreeBSD.ORG Sun Sep 24 14:54:02 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B18E16A403 for ; Sun, 24 Sep 2006 14:54:02 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE80743D53 for ; Sun, 24 Sep 2006 14:54:01 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from mail.ninth-nine.com ([IPv6:2001:3e0:4cf:1:d2:ff:fe23:1b4]) (authenticated bits=0) by sakura.ninth-nine.com (8.13.6/8.13.6/NinthNine) with ESMTP id k8OErsmT055889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Sep 2006 23:54:00 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sun, 24 Sep 2006 23:53:53 +0900 From: Norikatsu Shigemura To: Larry Baird Message-Id: <20060924235353.3adaa23d.nork@FreeBSD.org> In-Reply-To: <20060914093034.A83805@gta.com> References: <20060914093034.A83805@gta.com> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [IPv6:2001:3e0:4cf:0:230:48ff:fe41:2455]); Sun, 24 Sep 2006 23:54:00 +0900 (JST) Cc: freebsd-net@FreeBSD.org Subject: Re: FAST_IPSEC NAT-T support 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, 24 Sep 2006 14:54:02 -0000 On Thu, 14 Sep 2006 09:30:34 -0400 Larry Baird wrote: > Please find attached two patches for adding FAST_IPSEC NAT-T support to > FreeBSD 6.x. The patch "freebsd6-fastipsec-natt.diff" is dependent > upon Yvan's IPSEC NAT-T patch "freebsd6-natt.diff" which can be found at > http://ipsec-tools.cvs.sourceforge.net/ipsec-tools/htdocs/. The second > patch "freebsd6-ipsec-fastipsec-natt.diff" is a cumulative patch > combining both patches together. Thanks for your great works! I'm testing IPSec NAT-T BETWEEN 6.2-PRERELEASE with freebsd6- ipsec-fastipsec-natt.diff + nokey.diff AND Windows XP like following environment: The Internet -------------+----------------------------------+--------------- | ipfw but throw | no firewall | | no ipfw | | WAN | 219.127.74.120 WAN | A.A.A.A +------------+-------------+ +--------------+--------------+ | FreeBSD 4-stable NAT BOX | |FreeBSD 6-stable IPSec Router| +------------+-------------+ +-----------------------------+ LAN | 192.168.36.1 | | 192.168.36.6 +------------+-------------+ | Windows XP Professional | +--------------------------+ kernel configuration: options FAST_IPSEC options IPSEC_NAT_T And already make buildworld buildkernel && make installworld installkernel && shutdown -r now # uname -a FreeBSD AAAA 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #54: Sun Sep 24 22:41:00 JST 2006 root@AAAA:/usr/obj/usr/src/sys/AAAA i386 # pkg_info | grep ipsec ipsec-tools-0.6.6 KAME racoon IKE daemon, ipsec-tools version (some customized version:-) # cat /var/db/ports/ipsec-tools/options # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for ipsec-tools-0.6.6 _OPTIONS_READ=ipsec-tools-0.6.6 WITHOUT_DEBUG=true WITH_IPV6=true WITH_ADMINPORT=true WITH_STATS=true WITH_DPD=true WITH_NATT=true WITH_FRAG=true WITHOUT_HYBRID=true WITHOUT_PAM=true WITHOUT_GSSAPI=true WITHOUT_RADIUS=true WITHOUT_SAUNSPEC=true WITHOUT_RC5=true WITHOUT_IDEA=true I couldn't dial-up VPN from Windows XP by some reason. And I don't know what's happen:-(. Please teach me a hint! 1. Windows XP didn't provide any identifier. racoon will handle only REMOTE-IP. But Windows machines cannot dial-up VPN anywhere:-(. So I make a quite ad-hoc patch. Do you have any idea? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --- src/racoon/oakley.c.orig Tue Oct 4 18:54:27 2005 +++ src/racoon/oakley.c Sun Sep 24 18:45:33 2006 @@ -2383,8 +2383,11 @@ */ iph1->authstr = getpskbyaddr(iph1->remote); if (iph1->authstr == NULL) { + iph1->authstr = privsep_getpsk("(*dialup*)", 10); + } + if (iph1->authstr == NULL) { plog(LLV_ERROR, LOCATION, iph1->remote, - "couldn't find the pskey for %s.\n", + "couldn't find the pskey for %s or '(*dialup*)'.\n", saddrwop2str(iph1->remote)); goto end; } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2. main mode with pre-shared key doesn't handle FQDN. I don't know why Windows XP provides IPSECDOI_ID_FQDN. But ipsecdoi_checkid1 in ipsec_doi.c doesn't complete:-(. So I make a ad-hoc patch:-(. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --- src/racoon/ipsec_doi.c.orig Thu Feb 2 23:37:17 2006 +++ src/racoon/ipsec_doi.c Sun Sep 24 23:28:42 2006 @@ -3277,10 +3277,9 @@ iph1->approval->authmethod == OAKLEY_ATTR_AUTH_METHOD_PSKEY) { if (id_b->type != IPSECDOI_ID_IPV4_ADDR && id_b->type != IPSECDOI_ID_IPV6_ADDR) { - plog(LLV_ERROR, LOCATION, NULL, + plog(LLV_WARNING, LOCATION, NULL, "Expecting IP address type in main mode, " "but %s.\n", s_ipsecdoi_ident(id_b->type)); - return ISAKMP_NTYPE_INVALID_ID_INFORMATION; } } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 3. I don't know why no communication between FreeBSD and Windows. Between 23:02:18 and 23:02:53, Windows XP re-sent some packets. But FreeBSD didn't response them. So Windows XP gave up. /var/log/racoon.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sep 24 22:59:42 AAAA racoon: INFO: @(#)ipsec-tools 0.6.6 (http://ipsec-tools.sourceforge.net) Sep 24 22:59:42 AAAA racoon: INFO: @(#)This product linked OpenSSL 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/) Sep 24 22:59:42 AAAA racoon: INFO: A.A.A.A[4500] used as isakmp port (fd=8) Sep 24 22:59:42 AAAA racoon: INFO: A.A.A.A[4500] used for NAT-T Sep 24 22:59:42 AAAA racoon: INFO: A.A.A.A[500] used as isakmp port (fd=9) Sep 24 22:59:42 AAAA racoon: INFO: A.A.A.A[500] used for NAT-T Sep 24 23:02:18 AAAA racoon: INFO: respond new phase 1 negotiation: A.A.A.A[500]<=>219.127.74.120[500] Sep 24 23:02:18 AAAA racoon: INFO: begin Identity Protection mode. Sep 24 23:02:18 AAAA racoon: INFO: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY Sep 24 23:02:18 AAAA racoon: INFO: received Vendor ID: FRAGMENTATION Sep 24 23:02:18 AAAA racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 Sep 24 23:02:18 AAAA racoon: INFO: Selected NAT-T version: draft-ietf-ipsec-nat-t-ike-02 Sep 24 23:02:18 AAAA racoon: phase1(ident R msg1): 0.001648 Sep 24 23:02:18 AAAA racoon: INFO: Hashing A.A.A.A[500] with algo #2 Sep 24 23:02:18 AAAA racoon: INFO: NAT-D payload #0 verified Sep 24 23:02:18 AAAA racoon: INFO: Hashing 219.127.74.120[500] with algo #2 Sep 24 23:02:18 AAAA racoon: INFO: NAT-D payload #1 doesn't match Sep 24 23:02:18 AAAA racoon: INFO: NAT detected: PEER Sep 24 23:02:18 AAAA racoon: oakley_dh_generate(MODP1024): 0.016724 Sep 24 23:02:18 AAAA racoon: INFO: Hashing 219.127.74.120[500] with algo #2 Sep 24 23:02:18 AAAA racoon: INFO: Hashing A.A.A.A[500] with algo #2 Sep 24 23:02:18 AAAA racoon: INFO: Adding remote and local NAT-D payloads. Sep 24 23:02:18 AAAA racoon: oakley_dh_compute(MODP1024): 0.019675 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=36): 0.000079 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=145): 0.000020 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=165): 0.000019 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=165): 0.000019 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=1): 0.000017 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=20): 0.000017 Sep 24 23:02:18 AAAA racoon: phase1(ident R msg2): 0.044966 Sep 24 23:02:18 AAAA racoon: INFO: NAT-T: ports changed to: 219.127.74.120[4500]<->A.A.A.A[4500] Sep 24 23:02:18 AAAA racoon: INFO: KA list add: A.A.A.A[4500]->219.127.74.120[4500] Sep 24 23:02:18 AAAA racoon: alg_oakley_encdef_decrypt(3des klen=192 size=40): 0.000114 Sep 24 23:02:18 AAAA racoon: WARNING: Expecting IP address type in main mode, but FQDN. Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=479): 0.000039 Sep 24 23:02:18 AAAA racoon: oakley_validate_auth(pre-shared key): 0.000094 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=476): 0.000025 Sep 24 23:02:18 AAAA racoon: alg_oakley_encdef_encrypt(3des klen=192 size=40): 0.000018 Sep 24 23:02:18 AAAA racoon: phase1(ident R msg3): 0.000617 Sep 24 23:02:18 AAAA racoon: phase1(Identity Protection): 0.187999 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=32): 0.000017 Sep 24 23:02:18 AAAA racoon: alg_oakley_encdef_encrypt(3des klen=192 size=56): 0.000020 Sep 24 23:02:18 AAAA racoon: INFO: ISAKMP-SA established A.A.A.A[4500]-219.127.74.120[4500] spi:fbb6e583624f6f16:dff5c9f16fb555d6 Sep 24 23:02:18 AAAA racoon: INFO: respond new phase 2 negotiation: A.A.A.A[4500]<=>219.127.74.120[4500] Sep 24 23:02:18 AAAA racoon: alg_oakley_encdef_decrypt(3des klen=192 size=272): 0.000047 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=251): 0.000027 Sep 24 23:02:18 AAAA racoon: INFO: no policy found, try to generate the policy : 219.127.74.120/32[4500] A.A.A.A/32[1701] proto=udp dir=in Sep 24 23:02:18 AAAA racoon: INFO: Adjusting my encmode UDP-Transport->Transport Sep 24 23:02:18 AAAA racoon: INFO: Adjusting peer's encmode UDP-Transport(61444)->Transport(2) Sep 24 23:02:18 AAAA racoon: WARNING: trns_id mismatched: my:AES peer:3DES Sep 24 23:02:18 AAAA last message repeated 2 times Sep 24 23:02:18 AAAA racoon: WARNING: trns_id mismatched: my:BLOWFISH peer:3DES Sep 24 23:02:18 AAAA last message repeated 2 times Sep 24 23:02:18 AAAA racoon: WARNING: trns_id mismatched: my:CAST peer:3DES Sep 24 23:02:18 AAAA last message repeated 2 times Sep 24 23:02:18 AAAA racoon: WARNING: authtype mismatched: my:hmac-sha256 peer:hmac-md5 Sep 24 23:02:18 AAAA racoon: WARNING: authtype mismatched: my:hmac-sha peer:hmac-md5 Sep 24 23:02:18 AAAA racoon: phase2(???): 0.000984 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=135): 0.000019 Sep 24 23:02:18 AAAA racoon: alg_oakley_encdef_encrypt(3des klen=192 size=136): 0.000039 Sep 24 23:02:18 AAAA racoon: phase2(quick R msg1): 0.006437 Sep 24 23:02:18 AAAA racoon: alg_oakley_encdef_decrypt(3des klen=192 size=24): 0.000032 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=41): 0.000031 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=41): 0.000017 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=61): 0.000018 Sep 24 23:02:18 AAAA last message repeated 2 times Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=41): 0.000016 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=61): 0.000017 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=61): 0.000017 Sep 24 23:02:18 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=61): 0.000018 Sep 24 23:02:18 AAAA racoon: phase2(???): 0.000755 Sep 24 23:02:18 AAAA racoon: INFO: IPsec-SA established: ESP/Transport 219.127.74.120[4500]->A.A.A.A[4500] spi=74428117(0x46faed5) Sep 24 23:02:18 AAAA racoon: phase2(quick): 1159106538.353179 Sep 24 23:02:18 AAAA racoon: INFO: IPsec-SA established: ESP/Transport A.A.A.A[4500]->219.127.74.120[4500] spi=106731081(0x65c9649) Sep 24 23:02:18 AAAA racoon: ERROR: such policy does not already exist: "219.127.74.120/32[4500] A.A.A.A/32[1701] proto=udp dir=in" Sep 24 23:02:18 AAAA racoon: ERROR: such policy does not already exist: "A.A.A.A/32[1701] 219.127.74.120/32[4500] proto=udp dir=out" (sleep about 45sec) Sep 24 23:02:53 AAAA racoon: alg_oakley_encdef_decrypt(3des klen=192 size=40): 0.000041 Sep 24 23:02:53 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=20): 0.000029 Sep 24 23:02:53 AAAA racoon: INFO: generated policy, deleting it. Sep 24 23:02:53 AAAA racoon: INFO: purged IPsec-SA proto_id=ESP spi=106731081. Sep 24 23:02:53 AAAA racoon: ERROR: pfkey X_SPDDELETE failed: Invalid argument Sep 24 23:02:53 AAAA racoon: ERROR: pfkey X_SPDDELETE failed: Invalid argument Sep 24 23:02:53 AAAA racoon: alg_oakley_encdef_decrypt(3des klen=192 size=56): 0.000034 Sep 24 23:02:53 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=32): 0.000023 Sep 24 23:02:53 AAAA racoon: INFO: purging ISAKMP-SA spi=fbb6e583624f6f16:dff5c9f16fb555d6. Sep 24 23:02:53 AAAA racoon: INFO: purged IPsec-SA spi=74428117. Sep 24 23:02:53 AAAA racoon: INFO: purged ISAKMP-SA spi=fbb6e583624f6f16:dff5c9f16fb555d6. Sep 24 23:02:54 AAAA racoon: INFO: ISAKMP-SA deleted A.A.A.A[4500]-219.127.74.120[4500] spi:fbb6e583624f6f16:dff5c9f16fb555d6 Sep 24 23:02:54 AAAA racoon: INFO: KA remove: A.A.A.A[4500]->219.127.74.120[4500] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - my racoon.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - path pre_shared_key "/usr/local/etc/racoon/psk.txt"; listen { isakmp A.A.A.A[500]; isakmp_natt A.A.A.A[4500]; } timer { natt_keepalive 10 sec; } remote anonymous { exchange_mode main; nat_traversal on; generate_policy on; proposal_check obey; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group modp1024; } } sainfo anonymous { pfs_group modp1024; lifetime time 28800 sec; encryption_algorithm aes,blowfish,cast128,3des; authentication_algorithm hmac_sha256,hmac_sha1,hmac_md5; compression_algorithm deflate; } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From owner-freebsd-net@FreeBSD.ORG Sun Sep 24 15:57:31 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF00F16A412; Sun, 24 Sep 2006 15:57:31 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6183543D49; Sun, 24 Sep 2006 15:57:31 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from [87.240.16.199] (helo=[192.168.0.4]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1GRWMD-000CuA-Hx; Sun, 24 Sep 2006 19:57:29 +0400 Message-ID: <4516AADD.2050108@FreeBSD.org> Date: Sun, 24 Sep 2006 19:57:17 +0400 From: Sergey Matveychuk User-Agent: Thunderbird 1.5.0.5 (X11/20060902) MIME-Version: 1.0 To: freebsd-mobile@FreeBSD.org Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: iwi bricks my T43 on boot 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, 24 Sep 2006 15:57:31 -0000 I have IBM T43 notebook with this wireless internal card: iwi0: mem 0xa8401000-0xa8401fff irq 11 at device 2.0 on pci4 The problem is FreeBSD bricks my notebook on boot sometime. After I've turned rc.d debugging on I see it hangs after ifconfig_up: iwi0 operation. It happens quite rarely when I use a power supply and very often when my notebook boots on battery. The problem has appeared when a new driver for ipw/iwi was introduced. A fresh CURRENT here. When the problem was firstly arised it was 6.0. Because my notebook bricked I can't get a core dump or a debugger. Any hints please how can I get more info on this? -- Dixi. Sem. From owner-freebsd-net@FreeBSD.ORG Sun Sep 24 18:45:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC90D16A415; Sun, 24 Sep 2006 18:45:22 +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 1AF4443D49; Sun, 24 Sep 2006 18:45:17 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.186.78] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1GRYya2yXs-0007fB; Sun, 24 Sep 2006 20:45:16 +0200 From: Max Laier Organization: FreeBSD To: Sergey Matveychuk Date: Sun, 24 Sep 2006 20:45:08 +0200 User-Agent: KMail/1.9.4 References: <4516AADD.2050108@FreeBSD.org> In-Reply-To: <4516AADD.2050108@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="nextPart2234291.MziykGeSRY"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200609242045.15648.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-net@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: iwi bricks my T43 on boot 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, 24 Sep 2006 18:45:23 -0000 --nextPart2234291.MziykGeSRY Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 24 September 2006 17:57, Sergey Matveychuk wrote: > I have IBM T43 notebook with this wireless internal card: > > iwi0: mem 0xa8401000-0xa8401fff irq 11 > at device 2.0 on pci4 > > The problem is FreeBSD bricks my notebook on boot sometime. After I've > turned rc.d debugging on I see it hangs after ifconfig_up: iwi0 > operation. It happens quite rarely when I use a power supply and very > often when my notebook boots on battery. This rather sound like a hardware problem - a power consumption spike the=20 battery can't provide anymore or something, but let's see ... > The problem has appeared when a new driver for ipw/iwi was introduced. > > A fresh CURRENT here. When the problem was firstly arised it was 6.0. The new driver has never been in 6.0. > Because my notebook bricked I can't get a core dump or a debugger. > > Any hints please how can I get more info on this? Can you make sure you have a complete debugging kernel with WITNESS=20 enabled? Setting debug.iwi could also reveal what's going on. =20 Unfortunately it's only a sysctl, not a tuneable, so you'd have to change=20 the default in sys/dev/iwi/if_iwi.c line 88 by hand and recompile your=20 kernel/module. By the way, are you using iwi built in or as a module? =20 Do you load it via loader.conf or on demand from rc.d/*? =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 --nextPart2234291.MziykGeSRY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFFtI7XyyEoT62BG0RAhfBAJ4rJsdDkRwz0YiRjURENjj+LdH9agCeNThc HWmwmcb2j561KpN2a7i76Eo= =JDPq -----END PGP SIGNATURE----- --nextPart2234291.MziykGeSRY-- From owner-freebsd-net@FreeBSD.ORG Sun Sep 24 18:55:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA36716A416 for ; Sun, 24 Sep 2006 18:55:34 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from leia.fdn.fr (ns0.fdn.org [80.67.169.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 316B243D53 for ; Sun, 24 Sep 2006 18:55:33 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by leia.fdn.fr (8.13.3/8.13.3/FDN) with ESMTP id k8OItVYG018382 for ; Sun, 24 Sep 2006 20:55:32 +0200 Received: from jayce.zen.inc (jayce.zen.inc [192.168.1.7]) by smtp.zeninc.net (smtpd) with ESMTP id CE2D43F17 for ; Sun, 24 Sep 2006 20:55:25 +0200 (CEST) Received: by jayce.zen.inc (Postfix, from userid 1000) id 3411E2E211; Sun, 24 Sep 2006 20:55:28 +0200 (CEST) Date: Sun, 24 Sep 2006 20:55:27 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20060924185527.GA2230@jayce.zen.inc> References: <20060914093034.A83805@gta.com> <20060924235353.3adaa23d.nork@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060924235353.3adaa23d.nork@FreeBSD.org> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: FAST_IPSEC NAT-T support 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, 24 Sep 2006 18:55:35 -0000 On Sun, Sep 24, 2006 at 11:53:53PM +0900, Norikatsu Shigemura wrote: [....] Hi. > I'm testing IPSec NAT-T BETWEEN 6.2-PRERELEASE with freebsd6- > ipsec-fastipsec-natt.diff + nokey.diff AND Windows XP like > following environment: > [.....] > > I couldn't dial-up VPN from Windows XP by some reason. And I > don't know what's happen:-(. Please teach me a hint! > [....] > > 2. main mode with pre-shared key doesn't handle FQDN. > I don't know why Windows XP provides IPSECDOI_ID_FQDN. But > ipsecdoi_checkid1 in ipsec_doi.c doesn't complete:-(. So > I make a ad-hoc patch:-(. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > --- src/racoon/ipsec_doi.c.orig Thu Feb 2 23:37:17 2006 > +++ src/racoon/ipsec_doi.c Sun Sep 24 23:28:42 2006 > @@ -3277,10 +3277,9 @@ > iph1->approval->authmethod == OAKLEY_ATTR_AUTH_METHOD_PSKEY) { > if (id_b->type != IPSECDOI_ID_IPV4_ADDR > && id_b->type != IPSECDOI_ID_IPV6_ADDR) { > - plog(LLV_ERROR, LOCATION, NULL, > + plog(LLV_WARNING, LOCATION, NULL, > "Expecting IP address type in main mode, " > "but %s.\n", s_ipsecdoi_ident(id_b->type)); > - return ISAKMP_NTYPE_INVALID_ID_INFORMATION; > } > } Main mode with Preshared key can only use Adresses as IDs, as explained in RFC 2409.... > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > 3. I don't know why no communication between FreeBSD and Windows. > Between 23:02:18 and 23:02:53, Windows XP re-sent some packets. > But FreeBSD didn't response them. So Windows XP gave up. > > > /var/log/racoon.log > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [....] > Sep 24 23:02:18 AAAA racoon: INFO: Adjusting my encmode UDP-Transport->Transport > Sep 24 23:02:18 AAAA racoon: INFO: Adjusting peer's encmode UDP-Transport(61444)->Transport(2) Warning: NAT-T support for transport mode is very partial, and won't work for TCP sessions. If you are trying to setup L2TP/IPSec sessions, it may work as L2TP uses UDP. [.....] > Sep 24 23:02:18 AAAA racoon: INFO: IPsec-SA established: ESP/Transport 219.127.74.120[4500]->A.A.A.A[4500] spi=74428117(0x46faed5) > Sep 24 23:02:18 AAAA racoon: phase2(quick): 1159106538.353179 > Sep 24 23:02:18 AAAA racoon: INFO: IPsec-SA established: ESP/Transport A.A.A.A[4500]->219.127.74.120[4500] spi=106731081(0x65c9649) > Sep 24 23:02:18 AAAA racoon: ERROR: such policy does not already exist: "219.127.74.120/32[4500] A.A.A.A/32[1701] proto=udp dir=in" > Sep 24 23:02:18 AAAA racoon: ERROR: such policy does not already exist: "A.A.A.A/32[1701] 219.127.74.120/32[4500] proto=udp dir=out" Looks like the IPSec SAs are negociated. > (sleep about 45sec) > > Sep 24 23:02:53 AAAA racoon: alg_oakley_encdef_decrypt(3des klen=192 size=40): 0.000041 > Sep 24 23:02:53 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=20): 0.000029 > Sep 24 23:02:53 AAAA racoon: INFO: generated policy, deleting it. > Sep 24 23:02:53 AAAA racoon: INFO: purged IPsec-SA proto_id=ESP spi=106731081. > Sep 24 23:02:53 AAAA racoon: ERROR: pfkey X_SPDDELETE failed: Invalid argument > Sep 24 23:02:53 AAAA racoon: ERROR: pfkey X_SPDDELETE failed: Invalid argument > Sep 24 23:02:53 AAAA racoon: alg_oakley_encdef_decrypt(3des klen=192 size=56): 0.000034 > Sep 24 23:02:53 AAAA racoon: alg_oakley_hmacdef_one(hmac_sha1 size=32): 0.000023 > Sep 24 23:02:53 AAAA racoon: INFO: purging ISAKMP-SA spi=fbb6e583624f6f16:dff5c9f16fb555d6. > Sep 24 23:02:53 AAAA racoon: INFO: purged IPsec-SA spi=74428117. > Sep 24 23:02:53 AAAA racoon: INFO: purged ISAKMP-SA spi=fbb6e583624f6f16:dff5c9f16fb555d6. > Sep 24 23:02:54 AAAA racoon: INFO: ISAKMP-SA deleted A.A.A.A[4500]-219.127.74.120[4500] spi:fbb6e583624f6f16:dff5c9f16fb555d6 > Sep 24 23:02:54 AAAA racoon: INFO: KA remove: A.A.A.A[4500]->219.127.74.120[4500] Ok. I really guess you are using the VPN client shipped with Windows, which will try to setup an L2TP session through the IPSec transport. As you probably don't have an L2TP server on your FreeBSD side, Windows gives up and probably sends a DELETE_SA. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Sun Sep 24 19:59:28 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBDD316A415; Sun, 24 Sep 2006 19:59:28 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D66043D46; Sun, 24 Sep 2006 19:59:28 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from [87.240.16.199] (helo=[192.168.0.4]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1GRa8M-000GxU-RE; Sun, 24 Sep 2006 23:59:27 +0400 Message-ID: <4516E395.8090208@FreeBSD.org> Date: Sun, 24 Sep 2006 23:59:17 +0400 From: Sergey Matveychuk User-Agent: Thunderbird 1.5.0.5 (X11/20060902) MIME-Version: 1.0 To: Max Laier References: <4516AADD.2050108@FreeBSD.org> <200609242045.15648.max@love2party.net> In-Reply-To: <200609242045.15648.max@love2party.net> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: iwi bricks my T43 on boot 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, 24 Sep 2006 19:59:29 -0000 Max Laier wrote: > >> The problem has appeared when a new driver for ipw/iwi was introduced. >> >> A fresh CURRENT here. When the problem was firstly arised it was 6.0. > > The new driver has never been in 6.0. Well, I'm not quite sure here. May be it was CURRENT that time. > >> Because my notebook bricked I can't get a core dump or a debugger. >> >> Any hints please how can I get more info on this? > > Can you make sure you have a complete debugging kernel with WITNESS > enabled? Setting debug.iwi could also reveal what's going on. > Unfortunately it's only a sysctl, not a tuneable, so you'd have to change > the default in sys/dev/iwi/if_iwi.c line 88 by hand and recompile your > kernel/module. By the way, are you using iwi built in or as a module? > Do you load it via loader.conf or on demand from rc.d/*? > I have WITNESS in my kernel. I'll try with debug.iwi. I have iwi-firmware-kmod-3.0_1 port installed. -- Dixi. Sem. From owner-freebsd-net@FreeBSD.ORG Mon Sep 25 06:51:57 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEAD916A407 for ; Mon, 25 Sep 2006 06:51:57 +0000 (UTC) (envelope-from ilya_nikitin@migtel.ru) Received: from mail.migtel.ru (mail.migtel.ru [80.240.208.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB39E43D4C for ; Mon, 25 Sep 2006 06:51:56 +0000 (GMT) (envelope-from ilya_nikitin@migtel.ru) Received: from mail.migtel.ru (free.migtel.ru [80.240.208.45]) by mail.migtel.ru (Postfix) with ESMTP id 57D484C0224; Mon, 25 Sep 2006 10:51:54 +0400 (MSD) Received: from [80.240.216.5] (unknown [80.240.216.5]) by mail.migtel.ru (Postfix) with ESMTP; Mon, 25 Sep 2006 10:51:54 +0400 (MSD) From: Ilya Nikitin Organization: MIG-Telecom To: freebsd-net@freebsd.org Date: Mon, 25 Sep 2006 10:51:54 +0400 User-Agent: KMail/1.8.2 References: <787bbe1c0609130609l33fb29dawc465b7bcfb2f430e@mail.gmail.com> <20060921114602.GG27667@cell.sick.ru> <787bbe1c0609210838s28b7bd20ye7599ba074052428@mail.gmail.com> In-Reply-To: <787bbe1c0609210838s28b7bd20ye7599ba074052428@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200609251051.55049.ilya_nikitin@migtel.ru> X-Virus-Scanned: ClamAV using ClamSMTP on Free.migtel.ru Cc: Slawek Zak Subject: Re: Rapid link state changes on bge(4) interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ilya_nikitin@migtel.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2006 06:51:58 -0000 > On 9/21/06, Gleb Smirnoff wrote: > > No change. The link state is still floating. > > /S I've solved this problem by using bge drivers from 6.2-BETA1. There aren't = bge=20 flapping now !!! =2D------------------------------------------------------------------- Ilya Nikitin, System administrator Mig-Telecom, Russia =D4=C5=CC. +7 495 775 7676 From owner-freebsd-net@FreeBSD.ORG Mon Sep 25 09:57:57 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C75C16A407; Mon, 25 Sep 2006 09:57:57 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FE1843D88; Mon, 25 Sep 2006 09:57:45 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (3t55est8alq91ii9@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8P9vjEQ087117; Mon, 25 Sep 2006 02:57:45 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8P9vjVV087116; Mon, 25 Sep 2006 02:57:45 -0700 (PDT) (envelope-from jmg) Date: Mon, 25 Sep 2006 02:57:45 -0700 From: John-Mark Gurney To: current@FreeBSD.org, net@FreeBSD.org Message-ID: <20060925095745.GA80527@funkthat.com> Mail-Followup-To: current@FreeBSD.org, net@FreeBSD.org, Andre Oppermann , mohans@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Andre Oppermann , mohans@FreeBSD.org Subject: odd TCP rtt/retransmit timeout issue... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2006 09:57:57 -0000 I was brining up another interface that I just added to /etc/rc.conf and ran the command /etc/rc.d/netif start to initalize it... But then my connection never came back.... I found that the shell was still active as I could type commands like sleep 5, and another session's w would see sleep 5 run on the session... even filling up the send-q w/ 32k of data didn't get the HEAD box to send any data to the client... With the help of silby, I managed to find that the t_rxtcur value in the tcpcb was getting a very large value. The session that hung had a retransmit timeout of 19 days... This led us to find that the TCPT_RANGESET macro was letting very large tvmin values override the more sane tvmax values due to an extra else. I have added that so we shouldn't see any more multi day timeouts, but we still apparently have a problem where the rtt value calculated is wildly incorrect... It appears that each connection will get a different "random" rtt values... From a few connections to my machine: (kgdb) print ((struct tcpcb *)0xc3a34af8)->t_rxtcur $3 = 64000 (kgdb) print ((struct tcpcb *)0xc3a3457c)->t_rxtcur $6 = 1662654093 (kgdb) print ((struct tcpcb *)0xc3a343a8)->t_rxtcur $12 = 1358 (kgdb) print ((struct tcpcb *)0xc3a9e1d4)->t_rxtcur $17 = 203 (kgdb) print ((struct tcpcb *)0xc3a9e000)->t_rxtcur $19 = 284155863 most connections are stable around the "picked" value, though I have seen some connections oscillate between 64000 and a really large value.. I was trying to track this down, and a kernel as of 9/17 exhibits the problem, but I managed to track it down to a RELENG_6 commit (which obviously would effect HEAD) when I realized that each connection got a different value, and my older tests I was getting lucky in not having a bad timeout... To obtain these values, I used kgdb kernel /dev/mem, and put the value returned by netstat -Aanfinet's first column in as the tcpcb pointer above.. (Why is the columned named Socket, when it's the control block struct and not the socket struct?) Anyone want to track down why we are getting such large values in there? I'll try to back track farther to see how old this issue is.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Mon Sep 25 11:08:43 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F1B416A55F for ; Mon, 25 Sep 2006 11:08:43 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2AFB43D86 for ; Mon, 25 Sep 2006 11:08:25 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k8PB8Oef090624 for ; Mon, 25 Sep 2006 11:08:24 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k8PB8NmN090620 for freebsd-net@FreeBSD.org; Mon, 25 Sep 2006 11:08:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Sep 2006 11:08:23 GMT Message-Id: <200609251108.k8PB8NmN090620@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2006 11:08:43 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/52585 net [netinet] [patch] Kernel panic with ipfw2 and syncooki o kern/92552 net A serious bug in most network drivers from 5.X to 6.X f kern/93220 net [inet6] nd6_lookup: failed to add route for a neighbor 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102607 net [if_bridge] don't generate random L2 address 9 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 25 14:55:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56FD716A40F for ; Mon, 25 Sep 2006 14:55:22 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from smtp1.utdallas.edu (smtp1.utdallas.edu [129.110.10.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB96743D46 for ; Mon, 25 Sep 2006 14:55:21 +0000 (GMT) (envelope-from pauls@utdallas.edu) Received: from utd59514.utdallas.edu (utd59514.utdallas.edu [129.110.3.28]) by smtp1.utdallas.edu (Postfix) with ESMTP id 1E2C8388CFA for ; Mon, 25 Sep 2006 09:55:19 -0500 (CDT) Date: Mon, 25 Sep 2006 09:51:48 -0500 From: Paul Schmehl To: freebsd-net@freebsd.org Message-ID: In-Reply-To: <200609251051.55049.ilya_nikitin@migtel.ru> References: <787bbe1c0609130609l33fb29dawc465b7bcfb2f430e@mail.gmail.com> <20060921114602.GG27667@cell.sick.ru> <787bbe1c0609210838s28b7bd20ye7599ba074052428@mail.gmail.com> <200609251051.55049.ilya_nikitin@migtel.ru> X-Mailer: Mulberry/4.0.6 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========9113105B637BD627D0E0==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Rapid link state changes on bge(4) interface 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, 25 Sep 2006 14:55:22 -0000 --==========9113105B637BD627D0E0========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Monday, September 25, 2006 10:51:54 +0400 Ilya Nikitin=20 wrote: >> On 9/21/06, Gleb Smirnoff wrote: > >> >> No change. The link state is still floating. >> >> /S > > I've solved this problem by using bge drivers from 6.2-BETA1. There > aren't bge flapping now !!! > Which driver version is that? I had to update the if_bce.c file from=20 version 0.9.5 to 0.9.6 to correct a problem with the NIC ceasing to pass=20 traffic and requiring a reboot to restore connectivity. (I'm running 6.1=20 RELEASE.) Is this a newer version? Paul Schmehl (pauls@utdallas.edu) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/ --==========9113105B637BD627D0E0==========-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 25 15:20:30 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 284DC16A417 for ; Mon, 25 Sep 2006 15:20:30 +0000 (UTC) (envelope-from ilya_nikitin@migtel.ru) Received: from mail.migtel.ru (mail.migtel.ru [80.240.208.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id B24E543D72 for ; Mon, 25 Sep 2006 15:20:24 +0000 (GMT) (envelope-from ilya_nikitin@migtel.ru) Received: from mail.migtel.ru (free.migtel.ru [80.240.208.45]) by mail.migtel.ru (Postfix) with ESMTP id CC8F54BEF6C; Mon, 25 Sep 2006 19:20:23 +0400 (MSD) Received: from [80.240.216.5] (unknown [80.240.216.5]) by mail.migtel.ru (Postfix) with ESMTP; Mon, 25 Sep 2006 19:20:23 +0400 (MSD) From: Ilya Nikitin Organization: Mig-Telecom To: freebsd-net@freebsd.org Date: Mon, 25 Sep 2006 19:20:22 +0400 User-Agent: KMail/1.8.2 References: <787bbe1c0609130609l33fb29dawc465b7bcfb2f430e@mail.gmail.com> <200609251051.55049.ilya_nikitin@migtel.ru> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609251920.22478.ilya_nikitin@migtel.ru> X-Virus-Scanned: ClamAV using ClamSMTP on Free.migtel.ru Cc: pauls@utdallas.edu Subject: Re: Rapid link state changes on bge(4) interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ilya_nikitin@migtel.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2006 15:20:30 -0000 > > Which driver version is that? I had to update the if_bce.c file from > version 0.9.5 to 0.9.6 to correct a problem with the NIC ceasing to pass > traffic and requiring a reboot to restore connectivity. (I'm running 6.1 > RELEASE.) > > Is this a newer version? Yes, it's strongly newer: if_bge.c version: 1.91.2.17 2006/09/07 if_bge.h version: 1.36.2.7 2006/08/10 -------------------------------------------------------------------- Ilya Nikitin, System administrator, Mig-Telecom tel. +7 495 775 7676 From owner-freebsd-net@FreeBSD.ORG Mon Sep 25 15:47:05 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8581516A416; Mon, 25 Sep 2006 15:47:05 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C01843D7D; Mon, 25 Sep 2006 15:47:00 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.6/8.13.6) id k8PFkxMn093354; Mon, 25 Sep 2006 10:46:59 -0500 (CDT) (envelope-from dan) Date: Mon, 25 Sep 2006 10:46:59 -0500 From: Dan Nelson To: current@FreeBSD.org, net@FreeBSD.org, Andre Oppermann , mohans@FreeBSD.org Message-ID: <20060925154659.GE73717@dan.emsphone.com> References: <20060925095745.GA80527@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060925095745.GA80527@funkthat.com> X-OS: FreeBSD 6.1-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: odd TCP rtt/retransmit timeout issue... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2006 15:47:05 -0000 In the last episode (Sep 25), John-Mark Gurney said: > I was brining up another interface that I just added to /etc/rc.conf > and ran the command /etc/rc.d/netif start to initalize it... But > then my connection never came back.... I found that the shell was > still active as I could type commands like sleep 5, and another > session's w would see sleep 5 run on the session... even filling up > the send-q w/ 32k of data didn't get the HEAD box to send any data to > the client... > > With the help of silby, I managed to find that the t_rxtcur value in > the tcpcb was getting a very large value. The session that hung had > a retransmit timeout of 19 days... This led us to find that the > TCPT_RANGESET macro was letting very large tvmin values override the > more sane tvmax values due to an extra else. I have added that so we > shouldn't see any more multi day timeouts, but we still apparently > have a problem where the rtt value calculated is wildly incorrect... > > It appears that each connection will get a different "random" rtt > values... From a few connections to my machine: > (kgdb) print ((struct tcpcb *)0xc3a34af8)->t_rxtcur > $3 = 64000 > (kgdb) print ((struct tcpcb *)0xc3a3457c)->t_rxtcur > $6 = 1662654093 > (kgdb) print ((struct tcpcb *)0xc3a343a8)->t_rxtcur > $12 = 1358 > (kgdb) print ((struct tcpcb *)0xc3a9e1d4)->t_rxtcur > $17 = 203 > (kgdb) print ((struct tcpcb *)0xc3a9e000)->t_rxtcur > $19 = 284155863 Do you have net.inet.tcp.inflight.enable=1 ? You might be hitting something related to kern/75122. You'll want to pull the raw gnats repository file to read it; the query-pr.cgi web interface doesn't parse the file right and it loses all the replies. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-net@FreeBSD.ORG Mon Sep 25 15:57:06 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACA2416A412; Mon, 25 Sep 2006 15:57:06 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A00543D5C; Mon, 25 Sep 2006 15:57:04 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (r3g7vgsxq9i7sknu@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8PFuw6g094553; Mon, 25 Sep 2006 08:56:59 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8PFuw1h094552; Mon, 25 Sep 2006 08:56:58 -0700 (PDT) (envelope-from jmg) Date: Mon, 25 Sep 2006 08:56:58 -0700 From: John-Mark Gurney To: Dan Nelson Message-ID: <20060925155658.GB80527@funkthat.com> Mail-Followup-To: Dan Nelson , current@FreeBSD.org, net@FreeBSD.org, Andre Oppermann , mohans@FreeBSD.org References: <20060925095745.GA80527@funkthat.com> <20060925154659.GE73717@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060925154659.GE73717@dan.emsphone.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: mohans@FreeBSD.org, Andre Oppermann , current@FreeBSD.org, net@FreeBSD.org Subject: Re: odd TCP rtt/retransmit timeout issue... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2006 15:57:06 -0000 Dan Nelson wrote this message on Mon, Sep 25, 2006 at 10:46 -0500: > In the last episode (Sep 25), John-Mark Gurney said: > > I was brining up another interface that I just added to /etc/rc.conf > > and ran the command /etc/rc.d/netif start to initalize it... But > > then my connection never came back.... I found that the shell was > > still active as I could type commands like sleep 5, and another > > session's w would see sleep 5 run on the session... even filling up > > the send-q w/ 32k of data didn't get the HEAD box to send any data to > > the client... > > > > With the help of silby, I managed to find that the t_rxtcur value in > > the tcpcb was getting a very large value. The session that hung had > > a retransmit timeout of 19 days... This led us to find that the > > TCPT_RANGESET macro was letting very large tvmin values override the > > more sane tvmax values due to an extra else. I have added that so we > > shouldn't see any more multi day timeouts, but we still apparently > > have a problem where the rtt value calculated is wildly incorrect... > > > > It appears that each connection will get a different "random" rtt > > values... From a few connections to my machine: > > (kgdb) print ((struct tcpcb *)0xc3a34af8)->t_rxtcur > > $3 = 64000 > > (kgdb) print ((struct tcpcb *)0xc3a3457c)->t_rxtcur > > $6 = 1662654093 > > (kgdb) print ((struct tcpcb *)0xc3a343a8)->t_rxtcur > > $12 = 1358 > > (kgdb) print ((struct tcpcb *)0xc3a9e1d4)->t_rxtcur > > $17 = 203 > > (kgdb) print ((struct tcpcb *)0xc3a9e000)->t_rxtcur > > $19 = 284155863 > > Do you have net.inet.tcp.inflight.enable=1 ? You might be hitting Yes. > something related to kern/75122. You'll want to pull the raw gnats > repository file to read it; the query-pr.cgi web interface doesn't > parse the file right and it loses all the replies. Doesn't look like it... I just disabled inflight, and my first connection got: (kgdb) print ((struct tcpcb *)0xc3a4857c)->t_rxtcur $1 = 921479340 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Mon Sep 25 16:23:54 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5017E16A407 for ; Mon, 25 Sep 2006 16:23:54 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from smtp1.utdallas.edu (smtp1.utdallas.edu [129.110.10.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 156CA43D5A for ; Mon, 25 Sep 2006 16:23:46 +0000 (GMT) (envelope-from pauls@utdallas.edu) Received: from utd59514.utdallas.edu (utd59514.utdallas.edu [129.110.3.28]) by smtp1.utdallas.edu (Postfix) with ESMTP id 7464D388D3E for ; Mon, 25 Sep 2006 11:23:44 -0500 (CDT) Date: Mon, 25 Sep 2006 11:20:13 -0500 From: Paul Schmehl To: freebsd-net@freebsd.org Message-ID: In-Reply-To: <200609251920.22478.ilya_nikitin@migtel.ru> References: <787bbe1c0609130609l33fb29dawc465b7bcfb2f430e@mail.gmail.com> <200609251051.55049.ilya_nikitin@migtel.ru> <200609251920.22478.ilya_nikitin@migtel.ru> X-Mailer: Mulberry/4.0.6 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========3228235175841D523B2E==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Rapid link state changes on bge(4) interface 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, 25 Sep 2006 16:23:54 -0000 --==========3228235175841D523B2E========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Monday, September 25, 2006 19:20:22 +0400 Ilya Nikitin=20 wrote: >> >> Which driver version is that? I had to update the if_bce.c file from >> version 0.9.5 to 0.9.6 to correct a problem with the NIC ceasing to pass >> traffic and requiring a reboot to restore connectivity. (I'm running = 6.1 >> RELEASE.) >> >> Is this a newer version? > > Yes, it's strongly newer: > > if_bge.c version: 1.91.2.17 2006/09/07 > if_bge.h version: 1.36.2.7 2006/08/10 > That's the development branch. I'm talking about the driver version.=20 Inside the if_bce.c file, you will find this: /***************************************************************************= */ /* BCE Driver Version=20 */ /***************************************************************************= */ char bce_driver_version[] =3D "v0.9.6"; Is that the version you installed? Paul Schmehl (pauls@utdallas.edu) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/ --==========3228235175841D523B2E==========-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 26 02:17:31 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 258EA16A501; Tue, 26 Sep 2006 02:17:31 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAAE843D58; Tue, 26 Sep 2006 02:17:30 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (40k502h2yaiwryjm@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8Q2HU4C006489; Mon, 25 Sep 2006 19:17:30 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8Q2HUve006488; Mon, 25 Sep 2006 19:17:30 -0700 (PDT) (envelope-from jmg) Date: Mon, 25 Sep 2006 19:17:29 -0700 From: John-Mark Gurney To: current@FreeBSD.org, net@FreeBSD.org, Andre Oppermann , mohans@FreeBSD.org Message-ID: <20060926021729.GD80527@funkthat.com> Mail-Followup-To: current@FreeBSD.org, net@FreeBSD.org, Andre Oppermann , mohans@FreeBSD.org References: <20060925095745.GA80527@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060925095745.GA80527@funkthat.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Subject: Re: odd TCP rtt/retransmit timeout issue... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 02:17:31 -0000 John-Mark Gurney wrote this message on Mon, Sep 25, 2006 at 02:57 -0700: > Anyone want to track down why we are getting such large values in > there? I'll try to back track farther to see how old this issue is.. Managed to track it down: jmg 2006-09-26 01:21:47 UTC FreeBSD src repository Modified files: sys/netinet tcp_input.c Log: fix calculating to_tsecr... This prevents the rtt calculations from going all wonky... Revision Changes Path 1.309 +1 -1 src/sys/netinet/tcp_input.c ~12 days old for those who need to figure out if they need to upgrade or not... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Tue Sep 26 06:25:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6CAF16A403 for ; Tue, 26 Sep 2006 06:25:51 +0000 (UTC) (envelope-from ilya_nikitin@migtel.ru) Received: from mail.migtel.ru (mail.migtel.ru [80.240.208.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 331BE43D49 for ; Tue, 26 Sep 2006 06:25:50 +0000 (GMT) (envelope-from ilya_nikitin@migtel.ru) Received: from mail.migtel.ru (free.migtel.ru [80.240.208.45]) by mail.migtel.ru (Postfix) with ESMTP id D50164C1959 for ; Tue, 26 Sep 2006 10:25:49 +0400 (MSD) Received: from [80.240.216.5] (unknown [80.240.216.5]) by mail.migtel.ru (Postfix) with ESMTP for ; Tue, 26 Sep 2006 10:25:49 +0400 (MSD) From: Ilya Nikitin Organization: Mig-Telecom To: freebsd-net@freebsd.org Date: Tue, 26 Sep 2006 10:25:48 +0400 User-Agent: KMail/1.8.2 References: <787bbe1c0609130609l33fb29dawc465b7bcfb2f430e@mail.gmail.com> <200609251920.22478.ilya_nikitin@migtel.ru> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609261025.48645.ilya_nikitin@migtel.ru> X-Virus-Scanned: ClamAV using ClamSMTP on Free.migtel.ru Subject: Re: Rapid link state changes on bge(4) interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ilya_nikitin@migtel.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 06:25:51 -0000 > That's the development branch. I'm talking about the driver version. > Inside the if_bce.c file, you will find this: > > /************************************************************************** >**/ /* BCE Driver Version > */ > /************************************************************************** >**/ char bce_driver_version[] = "v0.9.6"; > > Is that the version you installed? > Sorry, I'm not a developer and I can do mistakes: BCE Driver Version is older than your one: bce_driver_version[] = "v0.9.5"; But I should remark, that previous brach was about bge driver (not bce) Best regards, -------------------------------------------------------------------- Ilya Nikitin, System administrator Mig-Telecom, Russia tel. +7 495 775 7676 From owner-freebsd-net@FreeBSD.ORG Tue Sep 26 07:13:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63FD516A412; Tue, 26 Sep 2006 07:13:42 +0000 (UTC) (envelope-from sivakumar.subramani@wipro.com) Received: from wip-ectls-mx3.wipro.com (wip-ectls-mx3.wipro.com [203.91.193.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86CAA43D79; Tue, 26 Sep 2006 07:13:27 +0000 (GMT) (envelope-from sivakumar.subramani@wipro.com) Received: from wip-ectls-mx3.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BA1DC224512; Tue, 26 Sep 2006 12:43:25 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ectls-mx3.wipro.com (Postfix) with ESMTP id ADBCD22401A; Tue, 26 Sep 2006 12:43:25 +0530 (IST) Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 12:43:25 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Sep 2006 12:43:31 +0530 Message-ID: <956E7FA2615F3B4595FC5F22870A72210C56FF@blr-m3-msg.wipro.com> In-Reply-To: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TSO patch for current Thread-Index: AcbOGRNQM5pSEkCVTd6avle0S8tfTQTIh5og From: To: , , X-OriginalArrivalTime: 26 Sep 2006 07:13:25.0602 (UTC) FILETIME=[422A3420:01C6E13B] Cc: Subject: RE: TSO patch for current 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, 26 Sep 2006 07:13:42 -0000 Is the TSO patch is checked in to the current? Thanks, ~Siva -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Jack Vogel Sent: Saturday, September 02, 2006 4:21 AM To: freebsd-net; freebsd-current Subject: RFC: TSO patch for current This is a patch for the stack and the em driver to enable TSO on CURRENT. Previously I had problems getting it to work, but this is functional. I should note that CURRENT is being a pain right now, when I comment out em in the config the kernel panics coming up, so I had to substitute this code into the tree. Rather bizarre :) I have this functionality running on a 6.1 based system, and our test group is already testing against that driver, so far things are looking good. I have designed it so the driver can continue to be built without support. There is also a sysctl in the stack code so you can set net.inet.tcp.tso_enable on or off and compare. I know there may be some refinements to add in, but I would like to get this into CURRENT as a start. Comments? Jack The information contained in this electronic message and any attachments to= this message are intended for the exclusive use of the addressee(s) and= may contain proprietary, confidential or privileged information. If you= are not the intended recipient, you should not disseminate, distribute or= copy this e-mail. Please notify the sender immediately and destroy all= copies of this message and any attachments.=0D WARNING: Computer viruses can be transmitted via email. The recipient= should check this email and any attachments for the presence of viruses.= The company accepts no liability for any damage caused by any virus= transmitted by this email. =0D www.wipro.com From owner-freebsd-net@FreeBSD.ORG Tue Sep 26 07:33:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8ECB16A40F for ; Tue, 26 Sep 2006 07:33:48 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 651D743D55 for ; Tue, 26 Sep 2006 07:33:48 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GS7Rr-0006b7-EH for freebsd-net@freebsd.org; Tue, 26 Sep 2006 10:33:47 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Sep 2006 10:33:47 +0300 From: Danny Braniss Message-ID: Subject: IPMI & portrange 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, 26 Sep 2006 07:33:48 -0000 Hi, This keeps bitting me every other upgrade, IPMI on some hosts, if enabled, will steal packets to port 623 or 664, so the current solution is either set net.inet.ip.portrange.lowlast to 664, (for some reason this does not seem to work if done via loader.conf) or change it in sys/netinet/in.h. So, is there some way to blacklist some ports, instead of increasing portrange.lowlast? danny From owner-freebsd-net@FreeBSD.ORG Tue Sep 26 08:28:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C99D16A403 for ; Tue, 26 Sep 2006 08:28:08 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0981243D73 for ; Tue, 26 Sep 2006 08:28:01 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 44270 invoked from network); 26 Sep 2006 08:29:52 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 26 Sep 2006 08:29:52 -0000 Message-ID: <4518E491.5060008@freebsd.org> Date: Tue, 26 Sep 2006 10:28:01 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: sivakumar.subramani@wipro.com References: <956E7FA2615F3B4595FC5F22870A72210C56FF@blr-m3-msg.wipro.com> In-Reply-To: <956E7FA2615F3B4595FC5F22870A72210C56FF@blr-m3-msg.wipro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, jfvogel@gmail.com Subject: Re: TSO patch for current 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, 26 Sep 2006 08:28:08 -0000 sivakumar.subramani@wipro.com wrote: > Is the TSO patch is checked in to the current? Yes, but a different one. -- Andre > Thanks, > ~Siva > > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Jack Vogel > Sent: Saturday, September 02, 2006 4:21 AM > To: freebsd-net; freebsd-current > Subject: RFC: TSO patch for current > > This is a patch for the stack and the em driver to enable TSO > on CURRENT. Previously I had problems getting it to work, but > this is functional. > > I should note that CURRENT is being a pain right now, when > I comment out em in the config the kernel panics coming up, > so I had to substitute this code into the tree. Rather bizarre :) > > I have this functionality running on a 6.1 based system, and > our test group is already testing against that driver, so far > things are looking good. > > I have designed it so the driver can continue to be built > without support. There is also a sysctl in the stack code > so you can set net.inet.tcp.tso_enable on or off and > compare. > > I know there may be some refinements to add in, but I > would like to get this into CURRENT as a start. > > Comments? > > Jack > > > The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. > > > WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. > > > www.wipro.com > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Tue Sep 26 18:29:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C35A16A415 for ; Tue, 26 Sep 2006 18:29:58 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (shrew.net [200.46.204.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52A9643D97 for ; Tue, 26 Sep 2006 18:29:45 +0000 (GMT) (envelope-from mgrooms@shrew.net) Received: from localhost (unknown [200.46.208.251]) by shrew.net (Postfix) with ESMTP id 0AF46D5799E for ; Tue, 26 Sep 2006 13:29:40 -0500 (CDT) Received: from shrew.net ([200.46.204.197]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 49432-07 for ; Tue, 26 Sep 2006 15:29:39 -0300 (ADT) Received: from hole.shrew.net (24-155-109-240.dyn.grandenetworks.net [24.155.109.240]) by shrew.net (Postfix) with ESMTP id 40487D57994 for ; Tue, 26 Sep 2006 13:29:39 -0500 (CDT) Received: from [10.22.200.21] ([10.22.200.21]) by hole.shrew.net (8.13.6/8.13.6) with ESMTP id k8QBVV16000951 for ; Tue, 26 Sep 2006 11:31:31 GMT (envelope-from mgrooms@shrew.net) Message-ID: <45197099.8060406@shrew.net> Date: Tue, 26 Sep 2006 13:25:29 -0500 From: Matthew Grooms User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Bundled SAs and ESP/IPCOMP support ... 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, 26 Sep 2006 18:29:58 -0000 All, I have been working on ipsec-tools development a bit and am currently scratching my head over issues related to esp and ipcomp. Since I do most of my testing with FreeBSD, I tried both the kame ipsec and fast ipsec support but have had no success to date. Here are the SPD entries being generated with the kame ipsec stack compiled into the kernel ... 10.2.1.128[any] 10.1.1.2[any] any in ipsec ipcomp/tunnel/10.22.200.119-10.22.200.1/unique:3 esp/transport//unique:3 created: Sep 26 11:01:42 2006 lastused: Sep 26 11:01:42 2006 lifetime: 3600(s) validtime: 0(s) spid=16483 seq=1 pid=886 refcnt=1 10.1.1.2[any] 10.2.1.128[any] any out ipsec ipcomp/tunnel/10.22.200.1-10.22.200.119/unique:3 esp/transport//unique:3 created: Sep 26 11:01:42 2006 lastused: Sep 26 11:01:42 2006 lifetime: 3600(s) validtime: 0(s) spid=16484 seq=0 pid=886 refcnt=1 ... and here are the SAD entries being generated ... 10.22.200.1 10.22.200.119 ipcomp mode=tunnel spi=2480390087(0x93d7bfc7) reqid=4(0x00000004) C: deflate seq=0x00000000 replay=0 flags=0x00000080 state=mature created: Sep 26 11:01:42 2006 current: Sep 26 11:02:07 2006 diff: 25(s) hard: 3600(s) soft: 2880(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=3 pid=889 refcnt=1 10.22.200.1 10.22.200.119 esp mode=transport spi=3351238547(0xc7bfd793) reqid=3(0x00000003) E: 3des-cbc 7380862e 482939f0 9f4753d8 9b97ab37 b13e4412 82a151ba A: hmac-md5 cb0829bf 4a51917e 6a023484 b9ea96d7 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Sep 26 11:01:42 2006 current: Sep 26 11:02:07 2006 diff: 25(s) hard: 3600(s) soft: 2880(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=2 pid=889 refcnt=1 10.22.200.119 10.22.200.1 ipcomp mode=tunnel spi=20406(0x00004fb6) reqid=4(0x00000004) C: deflate seq=0x00000000 replay=0 flags=0x00000080 state=mature created: Sep 26 11:01:42 2006 current: Sep 26 11:02:07 2006 diff: 25(s) hard: 3600(s) soft: 2880(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=1 pid=889 refcnt=1 10.22.200.119 10.22.200.1 esp mode=transport spi=13587562(0x00cf546a) reqid=3(0x00000003) E: 3des-cbc 89f5c6b5 8598b99d feea7460 2f59c9b4 c21e1280 20c02c1d A: hmac-md5 2a293fed 7e02d586 f3f42012 8923582a seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Sep 26 11:01:42 2006 current: Sep 26 11:02:07 2006 diff: 25(s) hard: 3600(s) soft: 2880(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=889 refcnt=1 ... With fast ipsec compiled into the kernel, I can see the outbound esp transport SAD entry increase the current byte count but the ipcomp entry shows nothing to indicate its use. It seems strange that the kernel will send acquire messages via PF_KEY as a pre-requisite to performing the required security processing but doesn't use them once they are added by the key daemon. I have heard reports from NetBSD developers that it doesn't work on their platform either. I have no idea about OpenBSD. It is reported to work correctly with the Linux 2.6 kernel but I haven't had a chance to verify yet. So, has anyone had any success with esp/ipcomp bundled SAs? Is this a known issue and is anyone working to correct the problem? Thanks in advance, -Matthew From owner-freebsd-net@FreeBSD.ORG Tue Sep 26 18:30:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7D4116A518; Tue, 26 Sep 2006 18:30:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96D4543D5E; Tue, 26 Sep 2006 18:29:47 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8QITYwW050196; Tue, 26 Sep 2006 14:29:35 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 26 Sep 2006 14:19:51 -0400 User-Agent: KMail/1.9.1 References: <4511B9B1.2000903@freebsd.org> <17683.63162.919620.114649@grasshopper.cs.duke.edu> In-Reply-To: <17683.63162.919620.114649@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609261419.52303.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 26 Sep 2006 14:29:35 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1946/Tue Sep 26 09:18:37 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: alc@freebsd.org, freebsd-net@freebsd.org, Andre Oppermann , Andrew Gallatin , tegge@freebsd.org Subject: Re: Much improved sendfile(2) kernel implementation 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, 26 Sep 2006 18:30:08 -0000 On Friday 22 September 2006 10:44, Andrew Gallatin wrote: > > Between TSO and your sendfile changes, things are looking up! > > Here are some Myri10GbE 1500 byte results from a 1.8GHz UP > FreeBSD/amd64 machine (AMD Athlon(tm) 64 Processor 3000+) sending to a > 2.0GHz SMP Linux/x86_64 machine (AMD Athlon(tm) 64 X2 Dual Core Processor > 3800+) running 26.17.7smp and our 1.1.0 Myri10GE driver (with LRO). > I used a linux receiver because LRO is the only way to receive > standard frames at line rate (without a TOE). > > These tests are all for sendfile of a 10MB file in /var/tmp: > > % netperf242 -Hrome-my -tTCP_SENDFILE -F /var//tmp/zot -T,1 -c -C -- -s393216 > > The -T,1 is required to force the netserver to use a different core > than the interrupt handler is bound to on the linux machine. BTW, > it would be really nice if FreeBSD supported CPU affinity for processes > and interrupt handlers.. You can get some of that with www.freebsd.org/~jhb/patches/intr_bind.patch That binds interrupt threads to the CPUs the IDT vector is bound to and adds a sysarch() so you can move them around. I had a simple test program to do that but don't have access to it currently. I've tested this on i386 and amd64, but haven't benchmarked it. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Sep 26 20:54:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86C7D16A412 for ; Tue, 26 Sep 2006 20:54:00 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DDBE43D5A for ; Tue, 26 Sep 2006 20:53:58 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.6/8.13.6) with ESMTP id k8QKriTm068505; Tue, 26 Sep 2006 13:53:45 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 26 Sep 2006 13:53:44 -0700 (PDT) From: John Polstra To: Danny Braniss Cc: freebsd-net@freebsd.org Subject: RE: IPMI & portrange 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, 26 Sep 2006 20:54:00 -0000 On 26-Sep-2006 Danny Braniss wrote: > This keeps bitting me every other upgrade, IPMI on some > hosts, if enabled, will steal packets to port 623 or 664, so > the current solution is either set net.inet.ip.portrange.lowlast > to 664, (for some reason this does not seem to work if done via > loader.conf) or change it in sys/netinet/in.h. > > So, is there some way to blacklist some ports, instead > of increasing portrange.lowlast? You could use your favorite scripting language to create a socket, bind it to the port, listen on it, and just sit there doing nothing -- for each port you want to blacklist. That would keep the ports from being used by anything else. John From owner-freebsd-net@FreeBSD.ORG Tue Sep 26 21:28:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83FC916A403 for ; Tue, 26 Sep 2006 21:28:14 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08B5643D49 for ; Tue, 26 Sep 2006 21:28:13 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20060926212811m9100sldc7e>; Tue, 26 Sep 2006 21:28:11 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id k8QLRxXu053488; Tue, 26 Sep 2006 16:28:00 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id k8QLRrS2053487; Tue, 26 Sep 2006 16:27:53 -0500 (CDT) (envelope-from brooks) Date: Tue, 26 Sep 2006 16:27:52 -0500 From: Brooks Davis To: John Polstra Message-ID: <20060926212751.GA53219@lor.one-eyed-alien.net> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: Danny Braniss , freebsd-net@freebsd.org Subject: Re: IPMI & portrange 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, 26 Sep 2006 21:28:14 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 26, 2006 at 01:53:44PM -0700, John Polstra wrote: > On 26-Sep-2006 Danny Braniss wrote: > > This keeps bitting me every other upgrade, IPMI on some > > hosts, if enabled, will steal packets to port 623 or 664, so > > the current solution is either set net.inet.ip.portrange.lowlast > > to 664, (for some reason this does not seem to work if done via > > loader.conf) or change it in sys/netinet/in.h. > >=20 > > So, is there some way to blacklist some ports, instead > > of increasing portrange.lowlast? >=20 > You could use your favorite scripting language to create a socket, > bind it to the port, listen on it, and just sit there doing nothing > -- for each port you want to blacklist. That would keep the ports > from being used by anything else. Extending the internal service functionality of inetd might be a good approach for this sort of thing. The current method of service matching based on port and protocol could be augmented with the ability to connect arbitrary "internal" services to arbitrary ports, perhaps via arguments to the "internal" command. Then you could hook discard to ports you don't want to use. -- Brooks --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFGZtXXY6L6fI4GtQRAlIsAKDUuhz58u+zLBAjBIaEcyu/lr/4qwCffAQK d2ZamQ29W0JMoS1cbhnbEis= =OXNX -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 26 22:23:15 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C97A16A415 for ; Tue, 26 Sep 2006 22:23:15 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (shrew.net [200.46.204.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id D33AF43D6E for ; Tue, 26 Sep 2006 22:23:10 +0000 (GMT) (envelope-from mgrooms@shrew.net) Received: from localhost (unknown [200.46.204.128]) by shrew.net (Postfix) with ESMTP id DDE4BD5799E for ; Tue, 26 Sep 2006 17:23:10 -0500 (CDT) Received: from shrew.net ([200.46.204.197]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 98735-03 for ; Tue, 26 Sep 2006 22:23:10 +0000 (UTC) Received: from hole.shrew.net (24-155-109-240.dyn.grandenetworks.net [24.155.109.240]) by shrew.net (Postfix) with ESMTP id CCE7CD57994 for ; Tue, 26 Sep 2006 17:23:09 -0500 (CDT) Received: from [10.22.200.21] ([10.22.200.21]) by hole.shrew.net (8.13.6/8.13.6) with ESMTP id k8QFP1j5000850 for ; Tue, 26 Sep 2006 15:25:01 GMT (envelope-from mgrooms@shrew.net) Message-ID: <4519A754.3000109@shrew.net> Date: Tue, 26 Sep 2006 17:19:00 -0500 From: Matthew Grooms User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <45197099.8060406@shrew.net> In-Reply-To: <45197099.8060406@shrew.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Bundled SAs and ESP/IPCOMP support ... 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, 26 Sep 2006 22:23:15 -0000 Matthew Grooms wrote: > All, > > With fast ipsec compiled into the kernel, I can see the outbound esp > transport SAD entry increase the current byte count but the ipcomp entry > shows nothing to indicate its use. It seems strange that the kernel will > send acquire messages via PF_KEY as a pre-requisite to performing the > required security processing but doesn't use them once they are added by > the key daemon. > So, I tracked down the problem I was seeing to here ... /usr/src/sys/netinet6/ipcomp_output.c:145 /* grab parameters */ algo = ipcomp_algorithm_lookup(sav->alg_enc); if ((ntohl(sav->spi) & ~0xffff) != 0 || !algo) { stat->out_inval++; m_freem(m); return EINVAL; } ... The SPI which gets interpreted as the CPI had a value larger than 0xffff. If IPCOMP will always fail with an CPI that isn't contained within 16 bits, should this be treated as an error condition when the key daemon attempts to add the SAD entry? Then there would be error feedback as opposed to silently dropping the packet in the outbound path. Thanks, -Matthew From owner-freebsd-net@FreeBSD.ORG Tue Sep 26 23:15:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD0AF16A51A for ; Tue, 26 Sep 2006 23:15:01 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DF5943D4C for ; Tue, 26 Sep 2006 23:15:01 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so3100366pye for ; Tue, 26 Sep 2006 16:15:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Ty0irQ7KqdiHn1RSpGpPAYWMCyAqBKRCuIpmf5/Z18Obgc6LrlGzm9sjryUItk4tkiv0TM0InOJWmQx2ualJI0lha2iURT16pJLvxN0g4Vvgn9evX/b7BctKpjiE6cKW2s3Zh6dB4RMyjl38pFirNS6W11CfA/YMzWeNKUf0igE= Received: by 10.35.62.19 with SMTP id p19mr106253pyk; Tue, 26 Sep 2006 16:15:00 -0700 (PDT) Received: by 10.35.119.14 with HTTP; Tue, 26 Sep 2006 16:15:00 -0700 (PDT) Message-ID: <2a41acea0609261615j18437fd9yc5e9ca823f2aab38@mail.gmail.com> Date: Tue, 26 Sep 2006 16:15:00 -0700 From: "Jack Vogel" To: freebsd-net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Bug or Design limitation?? 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, 26 Sep 2006 23:15:02 -0000 Our test group just ran into something I hadnt noticed before. Take a system and put in two different multiport NIC boards, one older (PCI-X) and one new PCI-E board. Load a driver that only recognizes the first board. It will show em0, em1, em2, em3, the new ports will be none's. Unload that driver and then load a newer one that recognizes both boards. What you'd expect to see is em0....em7. But what you actually see is two sets of em0 - em3! Our test lead noticed this because it broke some scripts of his. Now, 'ifconfig' gets it right and still presents you with 0-7. If you load the newer driver first then of course all is correct. So, the question is, is this a bug? Clearly the enumerated data from the older driver loaded is staying around. I do not know how this kernel data is handled, so could/should it be removed and isnt or what? Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Tue Sep 26 23:32:15 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A49E16A407 for ; Tue, 26 Sep 2006 23:32:15 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id B292143D53 for ; Tue, 26 Sep 2006 23:32:14 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (azxgeebxa18adhp2@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8QNWD6T035167; Tue, 26 Sep 2006 16:32:13 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8QNWCKs035165; Tue, 26 Sep 2006 16:32:12 -0700 (PDT) (envelope-from jmg) Date: Tue, 26 Sep 2006 16:32:12 -0700 From: John-Mark Gurney To: Jack Vogel Message-ID: <20060926233212.GF80527@funkthat.com> Mail-Followup-To: Jack Vogel , freebsd-net References: <2a41acea0609261615j18437fd9yc5e9ca823f2aab38@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0609261615j18437fd9yc5e9ca823f2aab38@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-net Subject: Re: Bug or Design limitation?? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 23:32:15 -0000 Jack Vogel wrote this message on Tue, Sep 26, 2006 at 16:15 -0700: > Our test group just ran into something I hadnt noticed before. > Take a system and put in two different multiport NIC boards, > one older (PCI-X) and one new PCI-E board. > > Load a driver that only recognizes the first board. It will show > em0, em1, em2, em3, the new ports will be none's. > > Unload that driver and then load a newer one that recognizes > both boards. What you'd expect to see is em0....em7. But > what you actually see is two sets of em0 - em3! Could you post a dmesg? The unit numbers should be provided by the newbus framework, which doesn't allow this... a devinfo would also help.. > Our test lead noticed this because it broke some scripts of > his. Now, 'ifconfig' gets it right and still presents you with 0-7. ifconfig -a dumps the names properly? > If you load the newer driver first then of course all is correct. > > So, the question is, is this a bug? Clearly the enumerated > data from the older driver loaded is staying around. I do > not know how this kernel data is handled, so could/should > it be removed and isnt or what? There really shouldn't be any data around, and even if it was, the data the was around would either a) force the new stuff to use a different unit number, or b) fail to attach due to that unit number already being in use... Hmmm... Thinking about this, it might be because of different devclass's that both have the same name... though the first devclass shouldn't be hanging around anymore since it was part of the first module... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Tue Sep 26 23:47:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDF5116A407 for ; Tue, 26 Sep 2006 23:47:19 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58EB843D4C for ; Tue, 26 Sep 2006 23:47:19 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so5168pye for ; Tue, 26 Sep 2006 16:47:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=U4CFSHmRMK80rV0mzcbdVrPe152oxYyLEFHaMCKiS578n78ETYOcQvD2qlm5FHku9IfjEgzwJTO7ArF8UpeRFAT9DZGBjCAKqkh9KBJkfSkDS9cniuQMWU4sIBm/lJtb3an68LvEZWWLT7qfsbhNgqDCbwux0qymymDg4ktH21o= Received: by 10.35.117.5 with SMTP id u5mr95111pym; Tue, 26 Sep 2006 16:47:18 -0700 (PDT) Received: by 10.35.119.14 with HTTP; Tue, 26 Sep 2006 16:47:18 -0700 (PDT) Message-ID: <2a41acea0609261647t1a5bb839o954e9287ae173d5c@mail.gmail.com> Date: Tue, 26 Sep 2006 16:47:18 -0700 From: "Jack Vogel" To: "John-Mark Gurney" , "Jack Vogel" , freebsd-net In-Reply-To: <20060926233212.GF80527@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0609261615j18437fd9yc5e9ca823f2aab38@mail.gmail.com> <20060926233212.GF80527@funkthat.com> Cc: Subject: Re: Bug or Design limitation?? 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, 26 Sep 2006 23:47:19 -0000 Yes, ifconfig dumps the names correctly. This isnt my machine, so I will have to go get the tester to get me the dmesg, I'll send along when I have it. Jack On 9/26/06, John-Mark Gurney wrote: > Jack Vogel wrote this message on Tue, Sep 26, 2006 at 16:15 -0700: > > Our test group just ran into something I hadnt noticed before. > > Take a system and put in two different multiport NIC boards, > > one older (PCI-X) and one new PCI-E board. > > > > Load a driver that only recognizes the first board. It will show > > em0, em1, em2, em3, the new ports will be none's. > > > > Unload that driver and then load a newer one that recognizes > > both boards. What you'd expect to see is em0....em7. But > > what you actually see is two sets of em0 - em3! > > Could you post a dmesg? The unit numbers should be provided by > the newbus framework, which doesn't allow this... a devinfo would > also help.. > > > Our test lead noticed this because it broke some scripts of > > his. Now, 'ifconfig' gets it right and still presents you with 0-7. > > ifconfig -a dumps the names properly? > > > If you load the newer driver first then of course all is correct. > > > > So, the question is, is this a bug? Clearly the enumerated > > data from the older driver loaded is staying around. I do > > not know how this kernel data is handled, so could/should > > it be removed and isnt or what? > > There really shouldn't be any data around, and even if it was, the > data the was around would either a) force the new stuff to use a > different unit number, or b) fail to attach due to that unit number > already being in use... > > Hmmm... Thinking about this, it might be because of different > devclass's that both have the same name... though the first > devclass shouldn't be hanging around anymore since it was part > of the first module... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > From owner-freebsd-net@FreeBSD.ORG Wed Sep 27 06:03:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6970216A403 for ; Wed, 27 Sep 2006 06:03:38 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A72B743D4C for ; Wed, 27 Sep 2006 06:03:37 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GSSW7-000L4K-Em; Wed, 27 Sep 2006 09:03:35 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Brooks Davis In-reply-to: <20060926212751.GA53219@lor.one-eyed-alien.net> References: <20060926212751.GA53219@lor.one-eyed-alien.net> Comments: In-reply-to Brooks Davis message dated "Tue, 26 Sep 2006 16:27:52 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Sep 2006 09:03:35 +0300 From: Danny Braniss Message-ID: Cc: freebsd-net@freebsd.org, John Polstra Subject: Re: IPMI & portrange 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, 27 Sep 2006 06:03:38 -0000 > On Tue, Sep 26, 2006 at 01:53:44PM -0700, John Polstra wrote: > > On 26-Sep-2006 Danny Braniss wrote: > > > This keeps bitting me every other upgrade, IPMI on some > > > hosts, if enabled, will steal packets to port 623 or 664, so > > > the current solution is either set net.inet.ip.portrange.lowlast > > > to 664, (for some reason this does not seem to work if done via > > > loader.conf) or change it in sys/netinet/in.h. > > >=20 > > > So, is there some way to blacklist some ports, instead > > > of increasing portrange.lowlast? > >=20 > > You could use your favorite scripting language to create a socket, > > bind it to the port, listen on it, and just sit there doing nothing > > -- for each port you want to blacklist. That would keep the ports > > from being used by anything else. > > Extending the internal service functionality of inetd might be a good > approach for this sort of thing. The current method of service matching > based on port and protocol could be augmented with the ability to > connect arbitrary "internal" services to arbitrary ports, perhaps via > arguments to the "internal" command. Then you could hook discard to > ports you don't want to use. > > -- Brooks Some ip traffic is generated earlier, tfpt/dhcp/dns/nfs, which ruins my initial thaught of putting the list in loader.rc or something - in a diskless environment there is a chicken and egg problem. danny From owner-freebsd-net@FreeBSD.ORG Wed Sep 27 08:25:05 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E199716A407 for ; Wed, 27 Sep 2006 08:25:05 +0000 (UTC) (envelope-from marko.lerota@claresco.hr) Received: from mxout2.iskon.hr (mxout2.iskon.hr [213.191.128.81]) by mx1.FreeBSD.org (Postfix) with SMTP id 0FF2043D5F for ; Wed, 27 Sep 2006 08:25:02 +0000 (GMT) (envelope-from marko.lerota@claresco.hr) Received: (qmail 18390 invoked from network); 27 Sep 2006 10:25:00 +0200 X-Remote-IP: 213.191.142.124 Received: from unknown (HELO mx.iskon.hr) (213.191.142.124) by mxout2.iskon.hr with SMTP; 27 Sep 2006 10:25:00 +0200 Received: (qmail 25853 invoked from network); 27 Sep 2006 10:25:00 +0200 X-Remote-IP: 213.191.139.213 Received: from tirnanog.iskon.hr (213.191.139.213) by mx.iskon.hr with SMTP; 27 Sep 2006 10:25:00 +0200 Received: (qmail 20408 invoked by uid 1001); 27 Sep 2006 08:24:53 -0000 To: freebsd-net@freebsd.org Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWgnbRLVpRNVY9jMRPh s21jSlEyNVX45Mv4zI+sbUclFAtMVpT8V0lFAAACZ0lEQVR4nG3Tv2vbQBQHcFMogWyeNeVK BLXGl5j6xnABOaNTuXFGmWpwtw519yj4soW6AatT4GKD3+aDZrl/rt/Tr9qlGiz7Pn7v3bsf HVc/NrIiSfElqH53GgijcCqzk/+AmBF5cN0DsFlIRGMh/oHuqxkTM6VlzB4EoZEs2aSZOASb EQJYZpweQshE697GTDndBXtgp9LIT9+OpDGHEfb9knk+nx+jfN1JCVZMCl6XwFm0a2EXztZD 3s4fj47ZbKI2VeBmJImeEfGLJ+M9sDPilX7IB5rN6sdfcGhuoHU+LC4nxfnI7YOJtdb95Gb+ fbgJ2uJ2ZgaA++f5ZzBqNCCYfMTd5q0BfBVNqm7I8gUjQ+YtXotRW6PH9AEj+dKs/KuNQAl5 o/NY+QkonW8aQAl0oXMYPvRiXIM4pRJifbXytnhTA8alBx/jefG2ar3DBlt34/PXz9M+nMVN iNaPUdCApJc2ItejOmLGoK1qQLV9pJmXBnL10DYoBA5aHNfj8ZNwZa5O4CzgTJeilKJmrQJs IHIt1/7/Sg2p3iq/Hz0/5W05rq4M9aN2B5FLohUP4ylVyfxhEIjAs8J4PhIJ9U+CEroogib5 BXAf7bB4vkfAzgPFt1tM9sJZAOH+lCexhwswuNtim4QTZdokqo4o89LkH7V6iFxICeqfp+Wh fmUuGPunLj2Meti6Cn4DjJ/UReROqR+aqawAi/JkfgKE64rrfkhjU8MtT8ivR4S5n6Yo08A7 HvgAlHDWRSGlNSDxwK9HtXy4FS2I60EdUIJM+Ut9OZNJG4CpbEQW1VBQoQoPuBw2EVa4P0u0 TgzQF+VoAAAAAElFTkSuQmCC Organization: *BSD Users - Fanatics Dept. X-Request-PGP: X-GNUPG-Fingerprint: CF5E 6862 2777 A471 5D2E 0015 8DA6 D56D 17E5 2A51 From: Marko Lerota Date: Wed, 27 Sep 2006 10:24:53 +0200 Message-ID: <86d59h4syy.fsf@sparrow.local> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: problem with routnig 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, 27 Sep 2006 08:25:06 -0000 I have gateway machine that doesn't work. Here is a setup: rc.conf ################################################################# defaultrouter="192.168.1.1" gateway_enable="YES" network_interfaces="xl0 fxp0" ifconfig_xl0="inet 192.168.1.70 netmask 255.255.255.0" ifconfig_fxp0="inet 192.168.2.71 netmask 255.255.255.0" static_routes="lan2" route_lan2="-net 192.168.2.0 -netmask 255.255.255.0 -iface xl0" ################################################################ The hosts on network 192.168.2.0/24 are connected to fxp0 and they can't go anywhere. I can't find the problem. I tried with following static route but it didn't help route_lan2="-net 192.168.2.0 -netmask 255.255.255.0 192.168.1.1" here is netstat Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.1 UGS 0 1 xl0 127.0.0.1 127.0.0.1 UH 0 0 lo0 192.168.1 link#1 UC 0 0 xl0 192.168.1.1 00:09:f3:78:48:2e UHLW 2 0 xl0 1197 192.168.1.67 00:17:31:bc:0a:3d UHLW 1 26 xl0 1192 192.168.2 link#2 UC 0 0 fxp0 192.168.2.64 00:0d:60:fd:7c:2f UHLW 1 3 fxp0 1192 This is FreeBSD 6.1-RELEASE #0 -- One cannot sell the earth upon which the people walk Tacunka Witco From owner-freebsd-net@FreeBSD.ORG Wed Sep 27 13:00:08 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F74B16A40F for ; Wed, 27 Sep 2006 13:00:08 +0000 (UTC) (envelope-from infofarmer@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 AFDDC43D45 for ; Wed, 27 Sep 2006 13:00:07 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so260446pye for ; Wed, 27 Sep 2006 06:00:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=V2KokmjFTJrekO3zQdY8vOJwJOYeMR4TLmsCrNJYG3Aw4YEJjkCDhbXPQhmCMDBvcs4ngcm2mKzpW65aEKHphNSM74hY0hP0c2Tpykh9ZcYqKs/1vyfz5DDJiNn5PK83Sn8MvEkyFRUZ+uur8H7M/gw5vs7cDwWkWow2Gn4C3QA= Received: by 10.35.93.1 with SMTP id v1mr799012pyl; Wed, 27 Sep 2006 06:00:06 -0700 (PDT) Received: by 10.35.119.12 with HTTP; Wed, 27 Sep 2006 06:00:06 -0700 (PDT) Message-ID: Date: Wed, 27 Sep 2006 17:00:06 +0400 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 684f1bb02f05f6d4 Cc: Subject: Polling + fxp = input errors 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, 27 Sep 2006 13:00:08 -0000 FWIW, enabling polling on 6.1-RELEASE with fxp interfaces resulted in input errors, visible through "netstat -w1 -Ifxp0". Moreover, today I had to restart the interface (down-up) after it hanged somehow. We've got hz=500 on this box. Once I disabled polling the errors disappeared altogether and performance rose considerably. fxp0@pci0:7:0: class=0x020000 card=0x10098086 chip=0x12298086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet From owner-freebsd-net@FreeBSD.ORG Wed Sep 27 13:18:23 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FCD616A40F; Wed, 27 Sep 2006 13:18:23 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6731E43D49; Wed, 27 Sep 2006 13:18:22 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k8RDIF3J070566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Sep 2006 17:18:16 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k8RDIEOq070565; Wed, 27 Sep 2006 17:18:14 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 27 Sep 2006 17:18:14 +0400 From: Gleb Smirnoff To: David Christensen Message-ID: <20060927131814.GK59833@FreeBSD.org> References: <20060823161649.GE76666@cell.sick.ru> <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="v9Ux+11Zm5mwPlX6" Content-Disposition: inline In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mutt/1.5.6i Cc: brad@openbsd.org, oleg@FreeBSD.org, net@FreeBSD.org Subject: Re: bge(4) one packet wedge 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, 27 Sep 2006 13:18:23 -0000 --v9Ux+11Zm5mwPlX6 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote: D> This "lost interrupt" type of problem is addressed by the use of the D> status_tag D> field in the status block. (Listed as bge_rsvd0 in the bge_status_block D> structure). D> Everytime the status block is updated a new tag value is written to the D> status block. D> When the ISR starts the driver should record the status_tag value. At D> the end D> of the ISR, the driver should compare the current status_tag value is D> the status D> block with the value recorded on entry to the ISR. If the values are D> the same D> then no additional status block updates have occurred so there shouldn't D> be D> any packets hanging around. If the values are different then additional D> packets D> or completions are waiting around so the ISR should loop around again. D> At the D> end of the ISR the driver will write the status_tag value it last D> handled to a D> mailbox register, letting the hardware know the last status block update D> handled. D> If necessary the hardware will generate a new interrupt and start the D> process over D> again. D> D> This entire process should be included in the Linux driver, I don't see D> it being D> used in the bge driver (bge_intr()). Finally I got a NIC that has a chip that does tagged status block - 5701. I've prepared a patch, that mimics Linux. If a chip can do status tag, then we write it to mailbox register at end of ISR, as you have described. If the chip can't, then we force coalescing once per second. This should fix the problem correctly on the chips that support status tag, and it is an ugly fix for chips that does not. Unfortunately, the attached patch doesn't fix the problem on 5701. The wedge occurs as before. And I see status tag updated, while the netperf test has wedged: (kgdb) p $sc->bge_last_tag $45 = 239 (kgdb) p $sc->bge_last_tag $46 = 240 (kgdb) p $sc->bge_last_tag $47 = 241 (kgdb) p $sc->bge_last_tag $48 = 242 I have no idea. :( May be you have one? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --v9Ux+11Zm5mwPlX6 Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="bge.status_tag" Index: if_bge.c =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.149 diff -u -p -r1.149 if_bge.c --- if_bge.c 23 Sep 2006 18:55:49 -0000 1.149 +++ if_bge.c 27 Sep 2006 12:14:15 -0000 @@ -1094,7 +1094,7 @@ bge_chipinit(struct bge_softc *sc) int i; /* Set endianness before we access any non-PCI registers. */ - pci_write_config(sc->bge_dev, BGE_PCI_MISC_CTL, BGE_INIT, 4); + pci_write_config(sc->bge_dev, BGE_PCI_MISC_CTL, sc->bge_misc_ctl, 4); /* * Check the 'ROM failed' bit on the RX CPU to see if @@ -2104,6 +2104,70 @@ bge_dma_alloc(device_t dev) return (0); } +static void +bge_recognize(struct bge_softc *sc) +{ + device_t dev = sc->bge_dev; + uint32_t misccfg; + + /* Save ASIC rev. */ + sc->bge_chipid = + pci_read_config(dev, BGE_PCI_MISC_CTL, 4) & + BGE_PCIMISCCTL_ASICREV; + sc->bge_asicrev = BGE_ASICREV(sc->bge_chipid); + sc->bge_chiprev = BGE_CHIPREV(sc->bge_chipid); + + sc->bge_misc_ctl = (BGE_HIF_SWAP_OPTIONS | + BGE_PCIMISCCTL_CLEAR_INTA | + BGE_PCIMISCCTL_MASK_PCI_INTR | + BGE_PCIMISCCTL_INDIRECT_ACCESS); + sc->bge_hcc_mode = 0; + + /* + * XXX: Broadcom Linux driver. Not in specs or eratta. + * PCI-Express? + */ + if (BGE_IS_5705_OR_BEYOND(sc)) { + uint32_t v; + + v = pci_read_config(dev, BGE_PCI_MSI_CAPID, 4); + if (((v >> 8) & 0xff) == BGE_PCIE_CAPID_REG) { + v = pci_read_config(dev, BGE_PCIE_CAPID_REG, 4); + if ((v & 0xff) == BGE_PCIE_CAPID) + sc->bge_flags |= BGE_FLAG_PCIE; + } + } + + /* + * PCI-X? + */ + if ((pci_read_config(sc->bge_dev, BGE_PCI_PCISTATE, 4) & + BGE_PCISTATE_PCI_BUSMODE) == 0) + sc->bge_flags |= BGE_FLAG_PCIX; + + misccfg = CSR_READ_4(sc, BGE_MISC_CFG) & BGE_MISCCFG_BOARD_ID_MASK; + if (sc->bge_asicrev == BGE_ASICREV_BCM5705 && + (misccfg == BGE_MISCCFG_BOARD_ID_5788 || + misccfg == BGE_MISCCFG_BOARD_ID_5788M)) + sc->bge_flags |= BGE_FLAG_5788; + + if (sc->bge_chiprev != BGE_CHIPREV_5700_AX && + sc->bge_chiprev != BGE_CHIPREV_5700_BX) + sc->bge_hcc_mode |= BGE_STATBLKSZ_32BYTE; + + /* + * 5788 and 5700 does not support tagging the status block. + * This is workarounded in bge_tick_locked(). + */ + if (!(sc->bge_flags & BGE_FLAG_5788) && + sc->bge_asicrev != BGE_ASICREV_BCM5700) { + sc->bge_flags |= BGE_FLAG_STATUSTAG; + sc->bge_hcc_mode |= (BGE_HCCMODE_CLRTICK_RXBD | + BGE_HCCMODE_CLRTICK_TXBD); + sc->bge_misc_ctl |= BGE_PCIMISCCTL_TAGGED_STATUS; + } +} + static int bge_attach(device_t dev) { @@ -2150,35 +2214,8 @@ bge_attach(device_t dev) BGE_LOCK_INIT(sc, device_get_nameunit(dev)); - /* Save ASIC rev. */ - - sc->bge_chipid = - pci_read_config(dev, BGE_PCI_MISC_CTL, 4) & - BGE_PCIMISCCTL_ASICREV; - sc->bge_asicrev = BGE_ASICREV(sc->bge_chipid); - sc->bge_chiprev = BGE_CHIPREV(sc->bge_chipid); - - /* - * XXX: Broadcom Linux driver. Not in specs or eratta. - * PCI-Express? - */ - if (BGE_IS_5705_OR_BEYOND(sc)) { - uint32_t v; - - v = pci_read_config(dev, BGE_PCI_MSI_CAPID, 4); - if (((v >> 8) & 0xff) == BGE_PCIE_CAPID_REG) { - v = pci_read_config(dev, BGE_PCIE_CAPID_REG, 4); - if ((v & 0xff) == BGE_PCIE_CAPID) - sc->bge_flags |= BGE_FLAG_PCIE; - } - } - - /* - * PCI-X ? - */ - if ((pci_read_config(sc->bge_dev, BGE_PCI_PCISTATE, 4) & - BGE_PCISTATE_PCI_BUSMODE) == 0) - sc->bge_flags |= BGE_FLAG_PCIX; + /* Fill in bge_flags, recognize features/bugs.*/ + bge_recognize(sc); /* Try to reset the chip. */ if (bge_reset(sc)) { @@ -2866,16 +2903,13 @@ bge_poll(struct ifnet *ifp, enum poll_cm static void bge_intr(void *xsc) { - struct bge_softc *sc; - struct ifnet *ifp; + struct bge_softc *sc = xsc; + struct ifnet *ifp = sc->bge_ifp; + struct bge_status_block *sblock = sc->bge_ldata.bge_status_block; uint32_t statusword; - sc = xsc; - BGE_LOCK(sc); - ifp = sc->bge_ifp; - #ifdef DEVICE_POLLING if (ifp->if_capenable & IFCAP_POLLING) { BGE_UNLOCK(sc); @@ -2883,6 +2917,15 @@ bge_intr(void *xsc) } #endif + if ((((sc->bge_flags & BGE_FLAG_STATUSTAG) && + (sc->bge_last_tag == sblock->bge_tag)) || + !(sblock->bge_status & BGE_STATUS_UPDATED)) && + (pci_read_config(sc->bge_dev, BGE_PCI_PCISTATE, 4) & + BGE_PCISTATE_INTR_STATE)) { + /* Not our interrupt? */ + BGE_UNLOCK(sc); + return; + } /* * Do the mandatory PCI flush as well as get the link status. */ @@ -2911,7 +2954,13 @@ bge_intr(void *xsc) } /* Re-enable interrupts. */ - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); + if (sc->bge_flags & BGE_FLAG_STATUSTAG) { + sc->bge_last_tag = sblock->bge_tag; + CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, (sc->bge_last_tag << 24)); + } else { + sblock->bge_status &= ~BGE_STATUS_UPDATED; + CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); + } if (ifp->if_drv_flags & IFF_DRV_RUNNING && !IFQ_DRV_IS_EMPTY(&ifp->if_snd)) @@ -2974,6 +3023,16 @@ bge_tick_locked(struct bge_softc *sc) bge_asf_driver_up(sc); + if (!(sc->bge_flags & BGE_FLAG_STATUSTAG)) { + struct bge_status_block *sblock = sc->bge_ldata.bge_status_block; + + if (sblock->bge_status & BGE_STATUS_UPDATED) + BGE_SETBIT(sc, BGE_MISC_LOCAL_CTL, BGE_MLC_INTR_SET); + else + CSR_WRITE_4(sc, BGE_HCC_MODE, BGE_HCCMODE_ENABLE | + BGE_HCCMODE_COAL_NOW); + } + callout_reset(&sc->bge_stat_ch, hz, bge_tick, sc); } Index: if_bgereg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v retrieving revision 1.55 diff -u -p -r1.55 if_bgereg.h --- if_bgereg.h 9 Sep 2006 03:36:57 -0000 1.55 +++ if_bgereg.h 27 Sep 2006 12:15:12 -0000 @@ -210,6 +210,7 @@ #define BGE_PCIMISCCTL_CLOCKCTL_RW 0x00000020 #define BGE_PCIMISCCTL_REG_WORDSWAP 0x00000040 #define BGE_PCIMISCCTL_INDIRECT_ACCESS 0x00000080 +#define BGE_PCIMISCCTL_TAGGED_STATUS 0x00000200 #define BGE_PCIMISCCTL_ASICREV 0xFFFF0000 #define BGE_HIF_SWAP_OPTIONS (BGE_PCIMISCCTL_ENDIAN_WORDSWAP) @@ -223,10 +224,6 @@ BGE_MODECTL_BYTESWAP_DATA|BGE_MODECTL_WORDSWAP_DATA #endif -#define BGE_INIT \ - (BGE_HIF_SWAP_OPTIONS|BGE_PCIMISCCTL_CLEAR_INTA| \ - BGE_PCIMISCCTL_MASK_PCI_INTR|BGE_PCIMISCCTL_INDIRECT_ACCESS) - #define BGE_CHIPID_TIGON_I 0x40000000 #define BGE_CHIPID_TIGON_II 0x60000000 #define BGE_CHIPID_BCM5700_A0 0x70000000 @@ -1195,6 +1192,8 @@ #define BGE_STATBLKSZ_FULL 0x00000000 #define BGE_STATBLKSZ_64BYTE 0x00000080 #define BGE_STATBLKSZ_32BYTE 0x00000100 +#define BGE_HCCMODE_CLRTICK_RXBD 0x00000200 +#define BGE_HCCMODE_CLRTICK_TXBD 0x00000400 /* Host coalescing status register */ #define BGE_HCCSTAT_ERROR 0x00000004 @@ -1690,6 +1689,9 @@ /* Misc. config register */ #define BGE_MISCCFG_RESET_CORE_CLOCKS 0x00000001 #define BGE_MISCCFG_TIMER_PRESCALER 0x000000FE +#define BGE_MISCCFG_BOARD_ID_MASK 0x0001e000 +#define BGE_MISCCFG_BOARD_ID_5788 0x00010000 +#define BGE_MISCCFG_BOARD_ID_5788M 0x00018000 #define BGE_32BITTIME_66MHZ (0x41 << 1) @@ -1939,7 +1941,10 @@ struct bge_sts_idx { struct bge_status_block { uint32_t bge_status; - uint32_t bge_rsvd0; +#define BGE_STATUS_UPDATED 0x00000001 +#define BGE_STATUS_LINKEV 0x00000002 +#define BGE_STATUS_ERROR 0x00000004 + uint32_t bge_tag; #if BYTE_ORDER == LITTLE_ENDIAN uint16_t bge_rx_jumbo_cons_idx; uint16_t bge_rx_std_cons_idx; @@ -2463,6 +2468,8 @@ struct bge_softc { #define BGE_FLAG_NO3LED 0x00000008 #define BGE_FLAG_PCIX 0x00000010 #define BGE_FLAG_PCIE 0x00000020 +#define BGE_FLAG_5788 0x00000040 +#define BGE_FLAG_STATUSTAG 0x00000080 uint32_t bge_chipid; uint8_t bge_asicrev; uint8_t bge_chiprev; @@ -2470,6 +2477,7 @@ struct bge_softc { uint8_t bge_asf_count; struct bge_ring_data bge_ldata; /* rings */ struct bge_chain_data bge_cdata; /* mbufs */ + uint32_t bge_last_tag; uint16_t bge_tx_saved_considx; uint16_t bge_rx_saved_considx; uint16_t bge_ev_saved_considx; @@ -2488,6 +2496,9 @@ struct bge_softc { int bge_link; /* link state */ int bge_link_evt; /* pending link event */ struct callout bge_stat_ch; + /* Masks/values for some registers. */ + uint32_t bge_hcc_mode; /* BGE_HCC_MODE */ + uint32_t bge_misc_ctl; /* BGE_PCI_MISC_CTL */ char *bge_vpd_prodname; char *bge_vpd_readonly; u_long bge_rx_discards; --v9Ux+11Zm5mwPlX6-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 27 13:19:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56B7D16A403 for ; Wed, 27 Sep 2006 13:19:16 +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 0447D43D53 for ; Wed, 27 Sep 2006 13:19:15 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 0CF35DA9298; Wed, 27 Sep 2006 09:19:15 -0400 (EDT) Received: from heartbeat1.internal ([10.202.2.160]) by frontend3.internal (MEProxy); Wed, 27 Sep 2006 09:19:17 -0400 X-Sasl-enc: wd4kI0pmO3mCAR9i+x1JT8CFDDZI5d3Y9BTn0HxDbPvN 1159363157 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 2E59714C0D; Wed, 27 Sep 2006 09:19:16 -0400 (EDT) Message-ID: <451A7A50.7090803@FreeBSD.org> Date: Wed, 27 Sep 2006 14:19:12 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: Marko Lerota References: <86d59h4syy.fsf@sparrow.local> In-Reply-To: <86d59h4syy.fsf@sparrow.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: problem with routnig 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, 27 Sep 2006 13:19:16 -0000 Marko Lerota wrote: > route_lan2="-net 192.168.2.0 -netmask 255.255.255.0 -iface xl0" > route_lan2="-net 192.168.2.0 -netmask 255.255.255.0 192.168.1.1" > Neither of these subnet routes should be necessary as 192.168.2.0/24 is already directly connected via fxp0. Do you still see the problem without this route installed? The netstat output you posted contains the directly-connected subnet route 192.168.2.0/24 which is automatically added when you configure the interface address. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Sep 27 14:08:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71FEC16A4AB for ; Wed, 27 Sep 2006 14:08:41 +0000 (UTC) (envelope-from marko.lerota@claresco.hr) Received: from mxout2.iskon.hr (mxout2.iskon.hr [213.191.128.81]) by mx1.FreeBSD.org (Postfix) with SMTP id 07C9643D98 for ; Wed, 27 Sep 2006 14:08:10 +0000 (GMT) (envelope-from marko.lerota@claresco.hr) Received: (qmail 26217 invoked from network); 27 Sep 2006 16:08:09 +0200 X-Remote-IP: 213.191.142.124 Received: from unknown (HELO mx.iskon.hr) (213.191.142.124) by mxout2.iskon.hr with SMTP; 27 Sep 2006 16:08:09 +0200 Received: (qmail 6288 invoked from network); 27 Sep 2006 16:08:09 +0200 X-Remote-IP: 213.191.139.213 Received: from tirnanog.iskon.hr (213.191.139.213) by mx.iskon.hr with SMTP; 27 Sep 2006 16:08:08 +0200 Received: (qmail 21221 invoked by uid 1001); 27 Sep 2006 14:08:03 -0000 To: "Bruce M. Simpson" Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWgnbRLVpRNVY9jMRPh s21jSlEyNVX45Mv4zI+sbUclFAtMVpT8V0lFAAACZ0lEQVR4nG3Tv2vbQBQHcFMogWyeNeVK BLXGl5j6xnABOaNTuXFGmWpwtw519yj4soW6AatT4GKD3+aDZrl/rt/Tr9qlGiz7Pn7v3bsf HVc/NrIiSfElqH53GgijcCqzk/+AmBF5cN0DsFlIRGMh/oHuqxkTM6VlzB4EoZEs2aSZOASb EQJYZpweQshE697GTDndBXtgp9LIT9+OpDGHEfb9knk+nx+jfN1JCVZMCl6XwFm0a2EXztZD 3s4fj47ZbKI2VeBmJImeEfGLJ+M9sDPilX7IB5rN6sdfcGhuoHU+LC4nxfnI7YOJtdb95Gb+ fbgJ2uJ2ZgaA++f5ZzBqNCCYfMTd5q0BfBVNqm7I8gUjQ+YtXotRW6PH9AEj+dKs/KuNQAl5 o/NY+QkonW8aQAl0oXMYPvRiXIM4pRJifbXytnhTA8alBx/jefG2ar3DBlt34/PXz9M+nMVN iNaPUdCApJc2ItejOmLGoK1qQLV9pJmXBnL10DYoBA5aHNfj8ZNwZa5O4CzgTJeilKJmrQJs IHIt1/7/Sg2p3iq/Hz0/5W05rq4M9aN2B5FLohUP4ylVyfxhEIjAs8J4PhIJ9U+CEroogib5 BXAf7bB4vkfAzgPFt1tM9sJZAOH+lCexhwswuNtim4QTZdokqo4o89LkH7V6iFxICeqfp+Wh fmUuGPunLj2Meti6Cn4DjJ/UReROqR+aqawAi/JkfgKE64rrfkhjU8MtT8ivR4S5n6Yo08A7 HvgAlHDWRSGlNSDxwK9HtXy4FS2I60EdUIJM+Ut9OZNJG4CpbEQW1VBQoQoPuBw2EVa4P0u0 TgzQF+VoAAAAAElFTkSuQmCC In-Reply-To: <451A7A50.7090803@FreeBSD.org> (Bruce M. Simpson's message of "Wed, 27 Sep 2006 14:19:12 +0100") References: <86d59h4syy.fsf@sparrow.local> <451A7A50.7090803@FreeBSD.org> Organization: *BSD Users - Fanatics Dept. X-Request-PGP: X-GNUPG-Fingerprint: CF5E 6862 2777 A471 5D2E 0015 8DA6 D56D 17E5 2A51 From: Marko Lerota Date: Wed, 27 Sep 2006 16:08:03 +0200 Message-ID: <8664f94d30.fsf@sparrow.local> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org Subject: Re: problem with routnig 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, 27 Sep 2006 14:08:41 -0000 "Bruce M. Simpson" writes: > Marko Lerota wrote: >> route_lan2="-net 192.168.2.0 -netmask 255.255.255.0 -iface xl0" >> route_lan2="-net 192.168.2.0 -netmask 255.255.255.0 192.168.1.1" >> > Neither of these subnet routes should be necessary as 192.168.2.0/24 > is already directly connected via fxp0. > > Do you still see the problem without this route installed? Yes I'm trying to do this FreeBSD BOX LAN 192.168.2.0/24 ---> switch0 ---> fxp0 192.168.2.71 xl0 192.168.1.70 ---> switch1 ---> GW 192.168.1.1 I want to intercept every packet from network, and don't allow LAN users to go directly to gateway. Gateway is phisically removed from LAN users. The only link is through FreeBSD box. Maybe this is, how they call it "transparent proxy or Intercepting proxy" ? -- One cannot sell the earth upon which the people walk Tacunka Witco From owner-freebsd-net@FreeBSD.ORG Wed Sep 27 14:18:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49FE116A412; Wed, 27 Sep 2006 14:18:03 +0000 (UTC) (envelope-from joost@jodocus.org) Received: from bps.jodocus.org (a198193.upc-a.chello.nl [62.163.198.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E88643DC4; Wed, 27 Sep 2006 14:17:36 +0000 (GMT) (envelope-from joost@jodocus.org) Received: from jodocus.org (localhost [IPv6:::1]) by bps.jodocus.org (8.13.6/8.13.6) with ESMTP id k8REHYf2061496; Wed, 27 Sep 2006 16:17:34 +0200 (CEST) (envelope-from joost@jodocus.org) Received: from 194.151.119.137 (SquirrelMail authenticated user joost) by jodocus.org with HTTP; Wed, 27 Sep 2006 16:17:35 +0200 (CEST) Message-ID: <51270.194.151.119.137.1159366655.squirrel@jodocus.org> In-Reply-To: <8664f94d30.fsf@sparrow.local> References: <86d59h4syy.fsf@sparrow.local> <451A7A50.7090803@FreeBSD.org> <8664f94d30.fsf@sparrow.local> Date: Wed, 27 Sep 2006 16:17:35 +0200 (CEST) From: "Joost Bekkers" To: "Marko Lerota" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-2.0.2 (bps.jodocus.org [IPv6:::1]); Wed, 27 Sep 2006 16:17:35 +0200 (CEST) X-Virus-Scanned: ClamAV 0.88.3/1947/Wed Sep 27 02:46:56 2006 on bps.jodocus.org X-Virus-Status: Clean Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: problem with routnig 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, 27 Sep 2006 14:18:03 -0000 On Wed, September 27, 2006 16:08, Marko Lerota wrote: > "Bruce M. Simpson" writes: > > FreeBSD BOX > LAN 192.168.2.0/24 ---> switch0 ---> fxp0 192.168.2.71 > xl0 192.168.1.70 ---> switch1 ---> GW > 192.168.1.1 > You have set the default gateway on the 192.168.2.0/24 clients to 192.168.2.71, right? Just making sure. greetz, Joost From owner-freebsd-net@FreeBSD.ORG Wed Sep 27 14:30:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80ECC16A47E for ; Wed, 27 Sep 2006 14:30:02 +0000 (UTC) (envelope-from marko.lerota@claresco.hr) Received: from mxout2.iskon.hr (mxout2.iskon.hr [213.191.128.81]) by mx1.FreeBSD.org (Postfix) with SMTP id 4861D43D8C for ; Wed, 27 Sep 2006 14:29:39 +0000 (GMT) (envelope-from marko.lerota@claresco.hr) Received: (qmail 19751 invoked from network); 27 Sep 2006 16:29:38 +0200 X-Remote-IP: 213.191.142.123 Received: from unknown (HELO mx.iskon.hr) (213.191.142.123) by mxout2.iskon.hr with SMTP; 27 Sep 2006 16:29:38 +0200 Received: (qmail 13917 invoked from network); 27 Sep 2006 16:29:38 +0200 X-Remote-IP: 213.191.139.213 Received: from tirnanog.iskon.hr (213.191.139.213) by mx.iskon.hr with SMTP; 27 Sep 2006 16:29:38 +0200 Received: (qmail 21278 invoked by uid 1001); 27 Sep 2006 14:29:32 -0000 To: "Joost Bekkers" Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWgnbRLVpRNVY9jMRPh s21jSlEyNVX45Mv4zI+sbUclFAtMVpT8V0lFAAACZ0lEQVR4nG3Tv2vbQBQHcFMogWyeNeVK BLXGl5j6xnABOaNTuXFGmWpwtw519yj4soW6AatT4GKD3+aDZrl/rt/Tr9qlGiz7Pn7v3bsf HVc/NrIiSfElqH53GgijcCqzk/+AmBF5cN0DsFlIRGMh/oHuqxkTM6VlzB4EoZEs2aSZOASb EQJYZpweQshE697GTDndBXtgp9LIT9+OpDGHEfb9knk+nx+jfN1JCVZMCl6XwFm0a2EXztZD 3s4fj47ZbKI2VeBmJImeEfGLJ+M9sDPilX7IB5rN6sdfcGhuoHU+LC4nxfnI7YOJtdb95Gb+ fbgJ2uJ2ZgaA++f5ZzBqNCCYfMTd5q0BfBVNqm7I8gUjQ+YtXotRW6PH9AEj+dKs/KuNQAl5 o/NY+QkonW8aQAl0oXMYPvRiXIM4pRJifbXytnhTA8alBx/jefG2ar3DBlt34/PXz9M+nMVN iNaPUdCApJc2ItejOmLGoK1qQLV9pJmXBnL10DYoBA5aHNfj8ZNwZa5O4CzgTJeilKJmrQJs IHIt1/7/Sg2p3iq/Hz0/5W05rq4M9aN2B5FLohUP4ylVyfxhEIjAs8J4PhIJ9U+CEroogib5 BXAf7bB4vkfAzgPFt1tM9sJZAOH+lCexhwswuNtim4QTZdokqo4o89LkH7V6iFxICeqfp+Wh fmUuGPunLj2Meti6Cn4DjJ/UReROqR+aqawAi/JkfgKE64rrfkhjU8MtT8ivR4S5n6Yo08A7 HvgAlHDWRSGlNSDxwK9HtXy4FS2I60EdUIJM+Ut9OZNJG4CpbEQW1VBQoQoPuBw2EVa4P0u0 TgzQF+VoAAAAAElFTkSuQmCC In-Reply-To: <51270.194.151.119.137.1159366655.squirrel@jodocus.org> (Joost Bekkers's message of "Wed, 27 Sep 2006 16:17:35 +0200 (CEST)") References: <86d59h4syy.fsf@sparrow.local> <451A7A50.7090803@FreeBSD.org> <8664f94d30.fsf@sparrow.local> <51270.194.151.119.137.1159366655.squirrel@jodocus.org> Organization: *BSD Users - Fanatics Dept. X-Request-PGP: X-GNUPG-Fingerprint: CF5E 6862 2777 A471 5D2E 0015 8DA6 D56D 17E5 2A51 From: Marko Lerota Date: Wed, 27 Sep 2006 16:29:32 +0200 Message-ID: <86zmcl2xir.fsf@sparrow.local> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: problem with routnig 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, 27 Sep 2006 14:30:02 -0000 "Joost Bekkers" writes: > On Wed, September 27, 2006 16:08, Marko Lerota wrote: >> "Bruce M. Simpson" writes: >> >> FreeBSD BOX >> LAN 192.168.2.0/24 ---> switch0 ---> fxp0 192.168.2.71 >> xl0 192.168.1.70 ---> switch1 ---> GW >> 192.168.1.1 >> > > You have set the default gateway on the 192.168.2.0/24 clients to > 192.168.2.71, right? > > Just making sure. Yes, they can ping 191.168.2.71. But FreeBSD box can't go to 192.168.1.1 from source address 191.168.2.71. #ping -S 192.168.2.71 192.168.1.1 PING 192.168.1.1 (192.168.1.1) from 192.168.2.71: 56 data bytes ^C --- 192.168.1.1 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss -- One cannot sell the earth upon which the people walk Tacunka Witco From owner-freebsd-net@FreeBSD.ORG Wed Sep 27 14:36:31 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3B6216A407; Wed, 27 Sep 2006 14:36:31 +0000 (UTC) (envelope-from zec@fer.hr) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 558AB43D62; Wed, 27 Sep 2006 14:36:30 +0000 (GMT) (envelope-from zec@fer.hr) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id F24A59B653; Wed, 27 Sep 2006 16:36:27 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.1 Received: from [192.168.200.106] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 259229B64F; Wed, 27 Sep 2006 16:36:16 +0200 (CEST) From: Marko Zec To: freebsd-net@freebsd.org Date: Wed, 27 Sep 2006 16:36:11 +0200 User-Agent: KMail/1.9.1 References: <86d59h4syy.fsf@sparrow.local> <51270.194.151.119.137.1159366655.squirrel@jodocus.org> <86zmcl2xir.fsf@sparrow.local> In-Reply-To: <86zmcl2xir.fsf@sparrow.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609271636.11598.zec@fer.hr> Cc: Joost Bekkers , Marko Lerota , "Bruce M. Simpson" Subject: Re: problem with routnig 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, 27 Sep 2006 14:36:32 -0000 On Wednesday 27 September 2006 16:29, Marko Lerota wrote: > "Joost Bekkers" writes: > > On Wed, September 27, 2006 16:08, Marko Lerota wrote: > >> "Bruce M. Simpson" writes: > >> > >> FreeBSD BOX > >> LAN 192.168.2.0/24 ---> switch0 ---> fxp0 192.168.2.71 > >> xl0 192.168.1.70 ---> switch1 ---> > >> GW 192.168.1.1 > > > > You have set the default gateway on the 192.168.2.0/24 clients to > > 192.168.2.71, right? > > > > Just making sure. > > Yes, they can ping 191.168.2.71. But FreeBSD box can't go to 192.168.1.1 > from source address 191.168.2.71. Could it be tahat 192.168.1.1 doesn't have a route to 192.168.2.0/24? Marko > #ping -S 192.168.2.71 192.168.1.1 > PING 192.168.1.1 (192.168.1.1) from 192.168.2.71: 56 data bytes > ^C > --- 192.168.1.1 ping statistics --- > 2 packets transmitted, 0 packets received, 100% packet loss From owner-freebsd-net@FreeBSD.ORG Wed Sep 27 14:47:30 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF29016A416 for ; Wed, 27 Sep 2006 14:47:30 +0000 (UTC) (envelope-from marko.lerota@claresco.hr) Received: from mxout2.iskon.hr (mxout2.iskon.hr [213.191.128.81]) by mx1.FreeBSD.org (Postfix) with SMTP id 1B3F543D45 for ; Wed, 27 Sep 2006 14:47:17 +0000 (GMT) (envelope-from marko.lerota@claresco.hr) Received: (qmail 12426 invoked from network); 27 Sep 2006 16:47:16 +0200 X-Remote-IP: 213.191.142.122 Received: from unknown (HELO mx.iskon.hr) (213.191.142.122) by mxout2.iskon.hr with SMTP; 27 Sep 2006 16:47:16 +0200 Received: (qmail 1968 invoked from network); 27 Sep 2006 16:47:16 +0200 X-Remote-IP: 213.191.139.213 Received: from tirnanog.iskon.hr (213.191.139.213) by mx.iskon.hr with SMTP; 27 Sep 2006 16:47:15 +0200 Received: (qmail 21323 invoked by uid 1001); 27 Sep 2006 14:47:10 -0000 To: Marko Zec Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWgnbRLVpRNVY9jMRPh s21jSlEyNVX45Mv4zI+sbUclFAtMVpT8V0lFAAACZ0lEQVR4nG3Tv2vbQBQHcFMogWyeNeVK BLXGl5j6xnABOaNTuXFGmWpwtw519yj4soW6AatT4GKD3+aDZrl/rt/Tr9qlGiz7Pn7v3bsf HVc/NrIiSfElqH53GgijcCqzk/+AmBF5cN0DsFlIRGMh/oHuqxkTM6VlzB4EoZEs2aSZOASb EQJYZpweQshE697GTDndBXtgp9LIT9+OpDGHEfb9knk+nx+jfN1JCVZMCl6XwFm0a2EXztZD 3s4fj47ZbKI2VeBmJImeEfGLJ+M9sDPilX7IB5rN6sdfcGhuoHU+LC4nxfnI7YOJtdb95Gb+ fbgJ2uJ2ZgaA++f5ZzBqNCCYfMTd5q0BfBVNqm7I8gUjQ+YtXotRW6PH9AEj+dKs/KuNQAl5 o/NY+QkonW8aQAl0oXMYPvRiXIM4pRJifbXytnhTA8alBx/jefG2ar3DBlt34/PXz9M+nMVN iNaPUdCApJc2ItejOmLGoK1qQLV9pJmXBnL10DYoBA5aHNfj8ZNwZa5O4CzgTJeilKJmrQJs IHIt1/7/Sg2p3iq/Hz0/5W05rq4M9aN2B5FLohUP4ylVyfxhEIjAs8J4PhIJ9U+CEroogib5 BXAf7bB4vkfAzgPFt1tM9sJZAOH+lCexhwswuNtim4QTZdokqo4o89LkH7V6iFxICeqfp+Wh fmUuGPunLj2Meti6Cn4DjJ/UReROqR+aqawAi/JkfgKE64rrfkhjU8MtT8ivR4S5n6Yo08A7 HvgAlHDWRSGlNSDxwK9HtXy4FS2I60EdUIJM+Ut9OZNJG4CpbEQW1VBQoQoPuBw2EVa4P0u0 TgzQF+VoAAAAAElFTkSuQmCC In-Reply-To: <200609271636.11598.zec@fer.hr> (Marko Zec's message of "Wed, 27 Sep 2006 16:36:11 +0200") References: <86d59h4syy.fsf@sparrow.local> <51270.194.151.119.137.1159366655.squirrel@jodocus.org> <86zmcl2xir.fsf@sparrow.local> <200609271636.11598.zec@fer.hr> Organization: *BSD Users - Fanatics Dept. X-Request-PGP: X-GNUPG-Fingerprint: CF5E 6862 2777 A471 5D2E 0015 8DA6 D56D 17E5 2A51 From: Marko Lerota Date: Wed, 27 Sep 2006 16:47:10 +0200 Message-ID: <86u02t2wpd.fsf@sparrow.local> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" , Joost Bekkers Subject: Re: problem with routnig 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, 27 Sep 2006 14:47:30 -0000 Marko Zec writes: > Could it be tahat 192.168.1.1 doesn't have a route to 192.168.2.0/24? > > Marko Yes, that's it. !@##$%#$$%#$% me stupid horse #$@#%!@!@# -- One cannot sell the earth upon which the people walk Tacunka Witco From owner-freebsd-net@FreeBSD.ORG Wed Sep 27 17:56:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF15C16A403 for ; Wed, 27 Sep 2006 17:56:08 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D1E143D49 for ; Wed, 27 Sep 2006 17:56:08 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so359053pye for ; Wed, 27 Sep 2006 10:56:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=YC2z1ZcLe55jelZGA2wv87dGRGiJ0O8C33Bjg72X6loFYCzqBouXkiOVovplYrF8l8sVf2sd4In1Zp6P3fMct0u9aa46fDFCkp6+MSSRlZf8LeD4CN/ZqUcP8Rqw5q2hxSgqdTfxGCyXkhkipFW0qpoSAHIGDCi7vdbH21fIz6E= Received: by 10.35.97.17 with SMTP id z17mr1909289pyl; Wed, 27 Sep 2006 10:56:07 -0700 (PDT) Received: by 10.35.119.14 with HTTP; Wed, 27 Sep 2006 10:56:07 -0700 (PDT) Message-ID: <2a41acea0609271056y22f7a935n5540268134581a5f@mail.gmail.com> Date: Wed, 27 Sep 2006 10:56:07 -0700 From: "Jack Vogel" To: "John-Mark Gurney" , "Jack Vogel" , freebsd-net In-Reply-To: <2a41acea0609261647t1a5bb839o954e9287ae173d5c@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_35792_14674644.1159379767381" References: <2a41acea0609261615j18437fd9yc5e9ca823f2aab38@mail.gmail.com> <20060926233212.GF80527@funkthat.com> <2a41acea0609261647t1a5bb839o954e9287ae173d5c@mail.gmail.com> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Bug or Design limitation?? 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, 27 Sep 2006 17:56:08 -0000 ------=_Part_35792_14674644.1159379767381 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/26/06, Jack Vogel wrote: > Yes, ifconfig dumps the names correctly. This isnt my machine, so > I will have to go get the tester to get me the dmesg, I'll send along > when I have it. > > Jack OK, here is the output of dmesg, devinfo, and pciconf from the system displaying this issue John. Cheers, Jack ------=_Part_35792_14674644.1159379767381-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 27 20:03:32 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7163616A403 for ; Wed, 27 Sep 2006 20:03:32 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD04843D45 for ; Wed, 27 Sep 2006 20:03:31 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (tfcybeyd3kf90a6d@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8RK3VpC058536; Wed, 27 Sep 2006 13:03:31 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8RK3ULL058535; Wed, 27 Sep 2006 13:03:30 -0700 (PDT) (envelope-from jmg) Date: Wed, 27 Sep 2006 13:03:30 -0700 From: John-Mark Gurney To: Jack Vogel Message-ID: <20060927200330.GG80527@funkthat.com> Mail-Followup-To: Jack Vogel , freebsd-net References: <2a41acea0609261615j18437fd9yc5e9ca823f2aab38@mail.gmail.com> <20060926233212.GF80527@funkthat.com> <2a41acea0609261647t1a5bb839o954e9287ae173d5c@mail.gmail.com> <2a41acea0609271056y22f7a935n5540268134581a5f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0609271056y22f7a935n5540268134581a5f@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-net Subject: Re: Bug or Design limitation?? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 20:03:32 -0000 Jack Vogel wrote this message on Wed, Sep 27, 2006 at 10:56 -0700: > On 9/26/06, Jack Vogel wrote: > >Yes, ifconfig dumps the names correctly. This isnt my machine, so > >I will have to go get the tester to get me the dmesg, I'll send along > >when I have it. > > OK, here is the output of dmesg, devinfo, and pciconf from the > system displaying this issue John. So, it appears that pciconf is the only one returning bogus data, as devinfo and dmesg both appear to return sane information.. Correct? We'll have to look at why pciconf is getting confused... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Wed Sep 27 21:56:32 2006 Return-Path: X-Original-To: net@hub.freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85C5C16A40F; Wed, 27 Sep 2006 21:56:32 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A8E343D72; Wed, 27 Sep 2006 21:56:32 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k8RLuVsR033707; Wed, 27 Sep 2006 21:56:31 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k8RLuV03033703; Wed, 27 Sep 2006 21:56:31 GMT (envelope-from bms) Date: Wed, 27 Sep 2006 21:56:31 GMT From: Bruce M Simpson Message-Id: <200609272156.k8RLuV03033703@freefall.freebsd.org> To: johan@nocrew.org, bms@FreeBSD.org, bms@FreeBSD.org, net@FreeBSD.org Cc: Subject: Re: kern/95665: [if_tun] "ping: sendto: No buffer space available" with TUN interface (easily reproducable with test program) 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, 27 Sep 2006 21:56:32 -0000 Synopsis: [if_tun] "ping: sendto: No buffer space available" with TUN interface (easily reproducable with test program) State-Changed-From-To: feedback->suspended State-Changed-By: bms State-Changed-When: Wed Sep 27 21:56:02 UTC 2006 State-Changed-Why: Back to the free pool (can't reproduce) Responsible-Changed-From-To: bms->net Responsible-Changed-By: bms Responsible-Changed-When: Wed Sep 27 21:56:02 UTC 2006 Responsible-Changed-Why: Back to the free pool (can't reproduce) http://www.freebsd.org/cgi/query-pr.cgi?pr=95665 From owner-freebsd-net@FreeBSD.ORG Thu Sep 28 00:27:05 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25A0E16A417; Thu, 28 Sep 2006 00:27:05 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F14143D46; Thu, 28 Sep 2006 00:27:04 +0000 (GMT) (envelope-from davidch@broadcom.com) Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Wed, 27 Sep 2006 17:26:38 -0700 X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 242E22AE; Wed, 27 Sep 2006 17:26:38 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id DAFDC2AF; Wed, 27 Sep 2006 17:26:37 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EGA54914; Wed, 27 Sep 2006 17:26:37 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 3885869CA3; Wed, 27 Sep 2006 17:26:37 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Sep 2006 17:26:35 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD90302084F5F@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <20060927131814.GK59833@FreeBSD.org> Thread-Topic: bge(4) one packet wedge Thread-Index: AcbiN3BMYynPLuh4TCyfqr6SkXgbMgAXIdig From: "David Christensen" To: "Gleb Smirnoff" X-TMWD-Spam-Summary: TS=20060928002643; SEV=2.0.2; DFV=A2006092710; IFV=2.0.4,4.0-8; RPD=4.00.0004; ENG=IBF; RPDID=303030312E30413031303230352E34353142313441322E303031442D412D; CAT=NONE; CON=NONE X-MMS-Spam-Filter-ID: A2006092710_4.00.0004_4.0-8 X-WSS-ID: 6905C9342304624691-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: brad@openbsd.org, oleg@FreeBSD.org, net@FreeBSD.org Subject: RE: bge(4) one packet wedge 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, 28 Sep 2006 00:27:05 -0000 > Finally I got a NIC that has a chip that does tagged status=20 > block - 5701. >=20 > I've prepared a patch, that mimics Linux. If a chip can do status tag, > then we write it to mailbox register at end of ISR, as you have > described. If the chip can't, then we force coalescing once=20 > per second. > This should fix the problem correctly on the chips that support > status tag, and it is an ugly fix for chips that does not. >=20 > Unfortunately, the attached patch doesn't fix the problem on 5701. The > wedge occurs as before. And I see status tag updated, while=20 > the netperf > test has wedged: >=20 > (kgdb) p $sc->bge_last_tag > $45 =3D 239 > (kgdb) p $sc->bge_last_tag > $46 =3D 240 > (kgdb) p $sc->bge_last_tag > $47 =3D 241 > (kgdb) p $sc->bge_last_tag > $48 =3D 242 >=20 > I have no idea. :( May be you have one? What's happening to the status block consumer/producer indices at this time? Are they advancing? Do they match the driver maintained consumer/producer indices? I forget if this was a send or receive problem, is the packet sitting in the send or receive return ring? Dave From owner-freebsd-net@FreeBSD.ORG Thu Sep 28 09:50:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DB3216A415 for ; Thu, 28 Sep 2006 09:50:19 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyadd226.zyxel.com.tw (zyadd226.zyxel.com.tw [61.222.65.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id B185143D49 for ; Thu, 28 Sep 2006 09:50:15 +0000 (GMT) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by smtp.zyxel.com.tw with InterScan Messaging Security Suite; Thu, 28 Sep 2006 17:49:46 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 17:50:01 +0800 Received: from [172.23.17.43] ([172.23.17.43]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 17:50:01 +0800 Message-ID: <451B9ACC.6020005@zyxel.com.tw> Date: Thu, 28 Sep 2006 17:50:04 +0800 From: Blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2006 09:50:01.0676 (UTC) FILETIME=[777CD0C0:01C6E2E3] Subject: Does mpd (multi-link PPP daemon) support IPv6? 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, 28 Sep 2006 09:50:19 -0000 Hi, all: I want to know whether mpd (multi-link PPP daemon) could possibly support IPv6. When I want to establish a PPTP connection with a PPTP server running mpd, could I use IPv6CP instead of IPv4CP to set up the PPP? If it supports, how could I configure the related parameters in the configuration files? I could only find the ipcp syntax. Best regards, blue From owner-freebsd-net@FreeBSD.ORG Thu Sep 28 09:55:37 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98B2616A417; Thu, 28 Sep 2006 09:55:37 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECB4743D49; Thu, 28 Sep 2006 09:55:31 +0000 (GMT) (envelope-from bms@incunabulum.net) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id ED900DAE50F; Thu, 28 Sep 2006 05:55:30 -0400 (EDT) Received: from heartbeat1.internal ([10.202.2.160]) by frontend3.internal (MEProxy); Thu, 28 Sep 2006 05:55:33 -0400 X-Sasl-enc: 0eOLKkCXoiIF5YsZXXWUXIvuv6aByGvv8UAIbKuBcUnS 1159437333 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 15B0672E9; Thu, 28 Sep 2006 05:55:32 -0400 (EDT) Message-ID: <451B9C11.2030901@incunabulum.net> Date: Thu, 28 Sep 2006 10:55:29 +0100 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: fenner@FreeBSD.org Subject: De-orbitting mrouted 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, 28 Sep 2006 09:55:37 -0000 Hi, I think it would be a good idea if we de-orbit /usr/sbin/mrouted in 7-CURRENT. Several reasons: 1. DVMRP is not specified for any new multicast installations; PIM is the de-facto standard now. 2. The code generates warnings during a buildworld (see bin/71633) 3. Given point (1) it probably doesn't belong in the base system; there is more interest in multicast these days because of things like zeroconf, however, DVMRP no longer belongs in a PIM world. What say thee? Regards, BMS From owner-freebsd-net@FreeBSD.ORG Thu Sep 28 10:27:49 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 368DD16A492 for ; Thu, 28 Sep 2006 10:27:49 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2C6443DBC for ; Thu, 28 Sep 2006 10:27:37 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 77602 invoked from network); 28 Sep 2006 10:29:05 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 28 Sep 2006 10:29:05 -0000 Message-ID: <451BA398.10302@freebsd.org> Date: Thu, 28 Sep 2006 12:27:36 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Bruce M Simpson References: <451B9C11.2030901@incunabulum.net> In-Reply-To: <451B9C11.2030901@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, fenner@FreeBSD.org Subject: Re: De-orbitting mrouted 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, 28 Sep 2006 10:27:49 -0000 Bruce M Simpson wrote: > Hi, > > I think it would be a good idea if we de-orbit /usr/sbin/mrouted in > 7-CURRENT. Several reasons: > > 1. DVMRP is not specified for any new multicast installations; PIM is > the de-facto standard now. > 2. The code generates warnings during a buildworld (see bin/71633) > 3. Given point (1) it probably doesn't belong in the base system; there > is more interest in multicast these days because of things like > zeroconf, however, DVMRP no longer belongs in a PIM world. > > What say thee? Let it vaporize upon reentry into the atmosphere! -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Sep 28 10:54:27 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F67216A412 for ; Thu, 28 Sep 2006 10:54:27 +0000 (UTC) (envelope-from lytboris@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id B68BE43D72 for ; Thu, 28 Sep 2006 10:54:14 +0000 (GMT) (envelope-from lytboris@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so139137uge for ; Thu, 28 Sep 2006 03:54:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:x-mailer:organization:x-priority:message-id:to:cc:subject:resent-from:mime-version:content-type:content-transfer-encoding; b=F8bvMjpzxRxgxOGTnOKX/sUvhXe0BImvT+6/vC+OUVWMdNCHmej5fHtnh5tN004eTtj2SwMF3ZyQS0E3f3t4yQ4yP5B4PHdSBndxWnrjoJG1jM8RhEEs52o2ncoLplyiF6PL3AJZaS9efj5tpELinvkx5ruLlzSePA+BQNQqmxI= Received: by 10.67.119.13 with SMTP id w13mr1613723ugm; Thu, 28 Sep 2006 03:54:12 -0700 (PDT) Received: from ?192.168.200.2? ( [85.140.232.163]) by mx.gmail.com with ESMTP id g30sm1462013ugd.2006.09.28.03.54.09; Thu, 28 Sep 2006 03:54:11 -0700 (PDT) Date: Thu, 28 Sep 2006 14:54:12 +0400 From: Lytochkin Boris X-Mailer: The Bat! (v3.72.12 (Beta)) Professional Organization: MSU X-Priority: 3 (Normal) Message-ID: <841264397.20060928145412@gmail.com> To: piso@FreeBSD.org Resent-from: Lytochkin Boris MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-Id: <20060928105414.B68BE43D72@mx1.FreeBSD.org> Resent-Date: Thu, 28 Sep 2006 10:54:14 +0000 (GMT) Cc: tarc@tarc.po.cs.msu.su, net@freebsd.org Subject: [ng_nat]bug w/ traceroute? 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, 28 Sep 2006 10:54:27 -0000 Hello! I have a router configured for NAT using ng_nat & ipfw. >ipfw: >01050 allow ip from me to any >01100 netgraph 60 ip from 192.168.90.0/24 to not 192.168.0.0/16 out via rl0 >01101 netgraph 61 ip from any to 193.232.121.245 in via rl0 >01200 allow ip from any to any >/etc/ngctl.conf: >mkpeer ipfw: nat 60 out >name ipfw:60 nat_cars >connect ipfw: nat_cars: 61 in >msg nat_cars: setaliasaddr 193.232.121.245 There is a very strange situation on the NAT'ing server: >traceroute -P icmp -z 500 -w 2 -q 1 194.87.0.50 traceroute to 194.87.0.50 (194.87.0.50), 64 hops max, 60 byte packets 1 * 2 * 3 * 4 * 5 * 6 * 7 www.ru (194.87.0.50) 14.582 ms The problem can be eliminated deleting 1101 rule: >traceroute -P icmp -z 500 -w 2 -q 1 194.87.0.50 traceroute to 194.87.0.50 (194.87.0.50), 64 hops max, 60 byte packets 1 knogw.phys.msu.ru (193.232.121.129) 2.809 ms 2 phsw3550.phys.msu.ru (193.232.122.1) 3.959 ms 3 MSU-PHYS.ATM2-0.122.HQ-R1.msu.net (193.232.127.77) 577.372 ms 4 CAMPUS-M9.ATM9-0-0.10.CAMPUS.msu.net (193.232.127.82) 9.012 ms 5 M9-IX-1G.Demos.net (193.232.244.35) 11.258 ms 6 iki-1-vl10.Demos.net (194.87.0.83) 7.151 ms 7 www.ru (194.87.0.50) 7.976 ms NAT using pf or ipfw_natd seems to work properly in this situation. The problem is reproduced on both my servers and this behaviour can be seen _only_ on the server: clients that are NATed using this config can traceroute correctly. >uname -a FreeBSD torrent 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #13: Sat Sep 16 16:16:16 MSD 2006 root@torrent:/usr/obj/usr/src/sys/TORRENT i386 -- Best regards, Lytochkin mailto:lytboris@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Sep 28 11:56:29 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21FB016A494; Thu, 28 Sep 2006 11:56:29 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F13943D5D; Thu, 28 Sep 2006 11:56:27 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5D3A9.dip.t-dialin.net [84.165.211.169]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k8SBVOUp080163; Thu, 28 Sep 2006 13:31:25 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (webmail.Leidinger.net [192.168.1.102]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k8SBuLHp034901; Thu, 28 Sep 2006 13:56:21 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 28 Sep 2006 13:55:50 +0200 Message-ID: <20060928135550.ul08h5elgkccgsgw@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 28 Sep 2006 13:55:50 +0200 From: Alexander Leidinger To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-Virus-Scanned: by amavisd-new Cc: joel@freebsd.org Subject: Porting the NetBSD ECN SoC project to FreeBSD 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, 28 Sep 2006 11:56:29 -0000 Hi, will someone port the NetBSD SoC project which implemented ECN to FreeBSD? If not, could someone please write up a nice text with some pointers for our ideas list? Bye, Alexander. -- Any sufficiently advanced bug becomes a feature. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-net@FreeBSD.ORG Thu Sep 28 12:38:02 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2CA416A412; Thu, 28 Sep 2006 12:38:02 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ACA843D79; Thu, 28 Sep 2006 12:38:00 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id CD0D233C94; Thu, 28 Sep 2006 14:37:55 +0200 (SAST) Date: Thu, 28 Sep 2006 14:37:55 +0200 From: John Hay To: Bruce M Simpson Message-ID: <20060928123755.GA34073@zibbi.meraka.csir.co.za> References: <451B9C11.2030901@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <451B9C11.2030901@incunabulum.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@FreeBSD.org, fenner@FreeBSD.org Subject: Re: De-orbitting mrouted 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, 28 Sep 2006 12:38:03 -0000 On Thu, Sep 28, 2006 at 10:55:29AM +0100, Bruce M Simpson wrote: > Hi, > > I think it would be a good idea if we de-orbit /usr/sbin/mrouted in > 7-CURRENT. Several reasons: > > 1. DVMRP is not specified for any new multicast installations; PIM is > the de-facto standard now. > 2. The code generates warnings during a buildworld (see bin/71633) > 3. Given point (1) it probably doesn't belong in the base system; there > is more interest in multicast these days because of things like > zeroconf, however, DVMRP no longer belongs in a PIM world. > > What say thee? Well what is there to do ipv4 multicast routing then? For ipv6 I have been using the net/mcast-tools package with pim6sd and pim6dd, but it seems that we are a bit thin in the ipv4 field... net/xorp maybe, although it looks like an overkill... I haven't tried it myself though. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Thu Sep 28 12:54:37 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 449C716A403; Thu, 28 Sep 2006 12:54:37 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF63C43D82; Thu, 28 Sep 2006 12:54:36 +0000 (GMT) (envelope-from bms@incunabulum.net) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 9B002DAE1CE; Thu, 28 Sep 2006 08:54:35 -0400 (EDT) Received: from heartbeat1.internal ([10.202.2.160]) by frontend3.internal (MEProxy); Thu, 28 Sep 2006 08:54:38 -0400 X-Sasl-enc: YM7G5BuiP2t57BWTrhdS53FnGpXOkRsH1TT6+XhtcDke 1159448077 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 4A0356E20; Thu, 28 Sep 2006 08:54:33 -0400 (EDT) Message-ID: <451BC605.2090401@incunabulum.net> Date: Thu, 28 Sep 2006 13:54:29 +0100 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: John Hay References: <451B9C11.2030901@incunabulum.net> <20060928123755.GA34073@zibbi.meraka.csir.co.za> In-Reply-To: <20060928123755.GA34073@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, fenner@FreeBSD.org Subject: Re: De-orbitting mrouted 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, 28 Sep 2006 12:54:37 -0000 John Hay wrote: > Well what is there to do ipv4 multicast routing then? For ipv6 I have > been using the net/mcast-tools package with pim6sd and pim6dd, but it > seems that we are a bit thin in the ipv4 field... net/xorp maybe, > although it looks like an overkill... I haven't tried it myself though. > mrouted could be shifted into ports, the code is located here: ftp://ftp.research.att.com/dist/fenner/mrouted/ So much to make happen.. juggle juggle juggle! Regards, BMS From owner-freebsd-net@FreeBSD.ORG Thu Sep 28 13:38:55 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F99D16A47E; Thu, 28 Sep 2006 13:38:55 +0000 (UTC) (envelope-from fenner@research.att.com) Received: from mail-red.research.att.com (mail-red.research.att.com [192.20.225.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id D625D43D46; Thu, 28 Sep 2006 13:38:30 +0000 (GMT) (envelope-from fenner@research.att.com) Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id F15A9147E4E; Thu, 28 Sep 2006 09:38:20 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11.20060308/8.12.10/Submit) id k8SDcKN5018206; Thu, 28 Sep 2006 06:38:20 -0700 From: Bill Fenner Message-Id: <200609281338.k8SDcKN5018206@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Bruce M Simpson Date: Thu, 28 Sep 2006 06:38:20 -0700 Versions: dmail (linux) 2.7/makemail 2.14 Cc: freebsd-net@FreeBSD.org, fenner@FreeBSD.org Subject: Re: De-orbitting mrouted 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, 28 Sep 2006 13:38:55 -0000 >I think it would be a good idea if we de-orbit /usr/sbin/mrouted in >7-CURRENT. Do it. Maybe consider making a port if anyone cares to continue to use it. (Gee, I suppose I could do that part ;-) Bill From owner-freebsd-net@FreeBSD.ORG Thu Sep 28 17:30:20 2006 Return-Path: X-Original-To: net@hub.freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1AAE16A407; Thu, 28 Sep 2006 17:30:20 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D96943D45; Thu, 28 Sep 2006 17:30:20 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k8SHUKAu066518; Thu, 28 Sep 2006 17:30:20 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k8SHUKbB066514; Thu, 28 Sep 2006 17:30:20 GMT (envelope-from bms) Date: Thu, 28 Sep 2006 17:30:20 GMT From: Bruce M Simpson Message-Id: <200609281730.k8SHUKbB066514@freefall.freebsd.org> To: bms@FreeBSD.org, freebsd-bugs@FreeBSD.org, net@FreeBSD.org Cc: Subject: Re: kern/95277: [netinet] IP Encapsulation mask_match() returns wrong results 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, 28 Sep 2006 17:30:20 -0000 Synopsis: [netinet] IP Encapsulation mask_match() returns wrong results Responsible-Changed-From-To: freebsd-bugs->net Responsible-Changed-By: bms Responsible-Changed-When: Thu Sep 28 17:30:09 UTC 2006 Responsible-Changed-Why: over to net for more discussion http://www.freebsd.org/cgi/query-pr.cgi?pr=95277 From owner-freebsd-net@FreeBSD.ORG Thu Sep 28 17:40:29 2006 Return-Path: X-Original-To: net@hub.freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95DFC16A52E for ; Thu, 28 Sep 2006 17:40:29 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D69543D45 for ; Thu, 28 Sep 2006 17:40:28 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k8SHeSkU068376 for ; Thu, 28 Sep 2006 17:40:28 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k8SHeSCh068375; Thu, 28 Sep 2006 17:40:28 GMT (envelope-from gnats) Date: Thu, 28 Sep 2006 17:40:28 GMT Message-Id: <200609281740.k8SHeSCh068375@freefall.freebsd.org> To: net@FreeBSD.org From: Bruce M Simpson Cc: Subject: Re: kern/95277: [netinet] IP Encapsulation mask_match() returns wrong results X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce M Simpson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2006 17:40:29 -0000 The following reply was made to PR kern/95277; it has been noted by GNATS. From: Bruce M Simpson To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/95277: [netinet] IP Encapsulation mask_match() returns wrong results Date: Thu, 28 Sep 2006 18:22:46 +0100 This is a multi-part message in MIME format. --------------080009040700000209070407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I guess a patch for the desired behaviour would look something like this? More detail needed... --------------080009040700000209070407 Content-Type: text/x-patch; name="maskmatch.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="maskmatch.diff" ==== //depot/user/bms/nethead/sys/netinet/ip_encap.c#1 - /home/bms/fp4/nethead/sys/netinet/ip_encap.c ==== --- /tmp/tmp.41786.0 Thu Sep 28 18:21:51 2006 +++ /home/bms/fp4/nethead/sys/netinet/ip_encap.c Thu Sep 28 18:21:09 2006 @@ -403,6 +403,7 @@ const struct sockaddr *sp; const struct sockaddr *dp; { + const int hdrlen = offsetof(struct sockaddr, sa_data); struct sockaddr_storage s; struct sockaddr_storage d; int i; @@ -419,32 +420,28 @@ matchlen = 0; - p = (const u_int8_t *)sp; - q = (const u_int8_t *)&ep->srcmask; - r = (u_int8_t *)&s; - for (i = 0 ; i < sp->sa_len; i++) { + p = (const u_int8_t *)&sp->sa_data; + q = (const u_int8_t *)&ep->srcmask + hdrlen; + r = (u_int8_t *)&s + hdrlen; + for (i = 0 ; i < sp->sa_len - hdrlen; i++) { r[i] = p[i] & q[i]; /* XXX estimate */ matchlen += (q[i] ? 8 : 0); } - p = (const u_int8_t *)dp; - q = (const u_int8_t *)&ep->dstmask; - r = (u_int8_t *)&d; - for (i = 0 ; i < dp->sa_len; i++) { + p = (const u_int8_t *)&dp->sa_data; + q = (const u_int8_t *)&ep->dstmask + hdrlen; + r = (u_int8_t *)&d + hdrlen; + for (i = 0 ; i < dp->sa_len - hdrlen; i++) { r[i] = p[i] & q[i]; /* XXX rough estimate */ matchlen += (q[i] ? 8 : 0); } - /* need to overwrite len/family portion as we don't compare them */ - s.ss_len = sp->sa_len; - s.ss_family = sp->sa_family; - d.ss_len = dp->sa_len; - d.ss_family = dp->sa_family; - - if (bcmp(&s, &ep->src, ep->src.ss_len) == 0 && - bcmp(&d, &ep->dst, ep->dst.ss_len) == 0) { + if (bcmp((u_int8_t *)&s + hdrlen, (const u_int8_t *)&ep->src + hdrlen, + ep->src.ss_len - hdrlen) == 0 && + bcmp((u_int8_t *)&d + hdrlen, (const u_int8_t *)&ep->dst + hdrlen, + ep->dst.ss_len - hdrlen) == 0) { return matchlen; } else return 0; --------------080009040700000209070407-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 28 17:54:51 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3FBC16A407; Thu, 28 Sep 2006 17:54:51 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AFD843D49; Thu, 28 Sep 2006 17:54:47 +0000 (GMT) (envelope-from bms@incunabulum.net) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 4EC7EDADFF2; Thu, 28 Sep 2006 13:54:46 -0400 (EDT) Received: from heartbeat1.internal ([10.202.2.160]) by frontend3.internal (MEProxy); Thu, 28 Sep 2006 13:54:49 -0400 X-Sasl-enc: pNKxGR7M8hr/wULoH8TTTIErVXvmxKEwOre4WiLnZN5U 1159466088 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 6ADBB14D8F; Thu, 28 Sep 2006 13:54:47 -0400 (EDT) Message-ID: <451C0C64.704@incunabulum.net> Date: Thu, 28 Sep 2006 18:54:44 +0100 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: Bill Fenner References: <200609281338.k8SDcKN5018206@bright.research.att.com> In-Reply-To: <200609281338.k8SDcKN5018206@bright.research.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, fenner@FreeBSD.org Subject: Re: De-orbitting mrouted 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, 28 Sep 2006 17:54:52 -0000 Bill Fenner wrote: >> I think it would be a good idea if we de-orbit /usr/sbin/mrouted in >> 7-CURRENT. >> > Do it. Maybe consider making a port if anyone cares to continue to > use it. (Gee, I suppose I could do that part ;-) > I count +3 votes in favour. As soon as I get some spare cycles (juggling dinner-plates) this will happen; a port will happen first. BMS From owner-freebsd-net@FreeBSD.ORG Thu Sep 28 22:10:27 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B35216A40F for ; Thu, 28 Sep 2006 22:10:27 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23C3A43D55 for ; Thu, 28 Sep 2006 22:10:25 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 86885 invoked from network); 28 Sep 2006 22:11:47 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 28 Sep 2006 22:11:47 -0000 Message-ID: <451C4850.5030302@freebsd.org> Date: Fri, 29 Sep 2006 00:10:24 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, gallatin@cs.duke.edu Subject: Much improved sosend_*() functions 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, 28 Sep 2006 22:10:27 -0000 The recent addition of TSO (TCP Segmentation Offload) has highlighted some shortcommings in our sosend_*() kernel implementation. The current code uses a sosend_copyin() function that loops over the supplied struct uio and does interleaved mbuf allocations and uiomove() calls. I have rewritten m_getm() to be simpler and to allocate PAGE_SIZE sized jumbo mbuf clusters (4k on most architectures) as well as m_uiotombuf() to use the new m_getm() to obtain all mbuf space in one go. It then loops over it an copies the data into the mbufs by using uiomove(). sosend_dgram() and sosend_generic() are change to use m_uiotombuf() instead of sosend_copyin(). Looking at the benchmarks we see some very nice improvements (95% confidence): 66% less cpu (or 2.9 times better) with new sosend vs. old sosend (non-TSO) 65% less cpu (or 2.8 times better) with new sosend vs. old sosend (TSO) The sender is an AMD Opteron 852 (2.6GHz) with em(4) PCI-X-133 interface and the receiver is a DELL Poweredge SC1425 P-IV Xeon 3.2GHz with em(4) LOM connected back to back at 1000Base-TX full duplex. The patch is available here: http://people.freebsd.org/~andre/sosend+m_uiotombuf-20060928.diff Any testing and heavy (code) beating and reviews welcome. -- Andre Here are the raw numbers (netperf at 95% confidence, +-2.5% error margin, the cpu load reported by netperf is different from the one reported by time(1), all performance references are made based on time(1) output, netperf 2.4.2 used): a) is old sosend kernel implementation b) is new sosend kernel implementation 1) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s32K -S32K [non-TSO] 2) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s32K -S32K [TSO] 3) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s64K -S64K [non-TSO] 4) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s64K -S64K [TSO] 5) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s128K -S128K [non-TSO] 6) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s128K -S128K [TSO] Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Send Recv Send Recv Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. 10^6bits/s % C % C us/KB us/KB 1a) 32768 32768 32768 10.00 921.28 28.42 32.48 2.527 2.888 0.007u 1.747s 0:10.00 17.4% 99+5252k 0+0io 0pf+0w 1b) 32768 32768 32768 10.00 921.39 24.51 31.50 2.179 2.801 0.028u 0.768s 0:10.00 7.8% 78+4210k 0+0io 0pf+0w 2a) 32768 32768 32768 10.00 897.63 24.29 37.74 2.216 3.445 0.000u 1.359s 0:10.02 13.4% 96+5152k 5+0io 3pf+0w 2b) 32768 32768 32768 10.00 919.71 15.64 33.01 1.393 2.940 0.008u 0.528s 0:10.00 5.2% 90+4830k 0+0io 0pf+0w 3a) 65536 65536 65536 10.00 941.60 30.90 32.01 2.689 2.785 0.000u 1.827s 0:10.00 18.2% 96+5180k 0+0io 0pf+0w 3b) 65536 65536 65536 10.00 941.59 26.39 32.03 2.296 2.787 0.014u 0.617s 0:10.00 6.2% 101+5362k 0+0io 0pf+0w 4a) 65536 65536 65536 10.00 921.98 26.09 39.47 2.318 3.507 0.000u 1.467s 0:10.02 14.5% 93+5028k 3+0io 0pf+0w 4b) 65536 65536 65536 10.00 938.44 16.24 34.29 1.418 2.993 0.000u 0.511s 0:10.00 5.1% 91+4851k 0+0io 0pf+0w 5a) 131072 131072 131072 10.00 941.62 33.81 33.68 2.941 2.930 0.000u 2.158s 0:10.00 21.5% 97+5247k 0+0io 0pf+0w 5b) 131072 131072 131072 10.00 941.60 28.55 31.65 2.484 2.754 0.000u 0.676s 0:10.00 6.7% 95+5132k 0+0io 0pf+0w 6a) 131072 131072 131072 10.00 922.92 28.72 40.80 2.549 3.621 0.000u 1.713s 0:10.00 17.1% 93+5016k 1+0io 0pf+0w 6b) 131072 131072 131072 10.00 939.14 18.20 34.44 1.587 3.004 0.000u 0.587s 0:10.00 5.8% 78+4197k 1+0io 0pf+0w From owner-freebsd-net@FreeBSD.ORG Thu Sep 28 22:42:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 081D216A407; Thu, 28 Sep 2006 22:42:03 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA57643D68; Thu, 28 Sep 2006 22:41:50 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id k8SMflrN008859 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 28 Sep 2006 18:41:47 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k8SMff0N060572; Thu, 28 Sep 2006 18:41:41 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17692.20389.476272.588061@grasshopper.cs.duke.edu> Date: Thu, 28 Sep 2006 18:41:41 -0400 (EDT) To: Andre Oppermann In-Reply-To: <451C4850.5030302@freebsd.org> References: <451C4850.5030302@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Much improved sosend_*() functions 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, 28 Sep 2006 22:42:03 -0000 Andre Oppermann writes: > I have rewritten m_getm() to be simpler and to allocate PAGE_SIZE sized > jumbo mbuf clusters (4k on most architectures) as well as m_uiotombuf() > to use the new m_getm() to obtain all mbuf space in one go. It then loops > over it an copies the data into the mbufs by using uiomove(). sosend_dgram() > and sosend_generic() are change to use m_uiotombuf() instead of sosend_copyin(). Hurray! Thank you for doing this. I'll try to check it out with mxge soon, but it might be until next week. Drew From owner-freebsd-net@FreeBSD.ORG Thu Sep 28 23:29:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AA4916A412 for ; Thu, 28 Sep 2006 23:29:55 +0000 (UTC) (envelope-from silby@silby.com) Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 2DBF443D77 for ; Thu, 28 Sep 2006 23:29:54 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 55573 invoked by uid 3193); 28 Sep 2006 23:29:53 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Sep 2006 23:29:53 -0000 Date: Thu, 28 Sep 2006 19:29:52 -0400 (EDT) From: Mike Silbersack X-X-Sender: silby@niwun.pair.com To: Andre Oppermann In-Reply-To: <451C4850.5030302@freebsd.org> Message-ID: References: <451C4850.5030302@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions 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, 28 Sep 2006 23:29:55 -0000 On Fri, 29 Sep 2006, Andre Oppermann wrote: > over it an copies the data into the mbufs by using uiomove(). sosend_dgram() > and sosend_generic() are change to use m_uiotombuf() instead of sosend_copyin(). Can you do some UDP testing with 512b, 1K, 2K, 4K, 8K, and 16K packets to see if performance changes there as well? How about local sockets? Impressive improvements for TCP, in any case! Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 00:08:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 855A416A47E for ; Fri, 29 Sep 2006 00:08:38 +0000 (UTC) (envelope-from stapleton.41@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43C0643D53 for ; Fri, 29 Sep 2006 00:08:26 +0000 (GMT) (envelope-from stapleton.41@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so212500uge for ; Thu, 28 Sep 2006 17:08:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=IT/Spm6rLP5zNovyHqgAZAQdtbwjVFTnYFIzH93NPT9kgL7xrRiGK5mDeMAQGByrBlzXLCTUUjSu6Fd0ExyHtd7MRZglspzeHtDlBy4RIIC1LLEi4JP+hCBVQkHcDGQhbmRlaHVaVy55MiA4f2Ef0RpbgVcGB4fhLsSvofC1E+w= Received: by 10.66.222.9 with SMTP id u9mr1847913ugg; Thu, 28 Sep 2006 17:08:25 -0700 (PDT) Received: by 10.67.86.4 with HTTP; Thu, 28 Sep 2006 17:08:25 -0700 (PDT) Message-ID: <80f4f2b20609281708l56991844p6a17263d784f7545@mail.gmail.com> Date: Thu, 28 Sep 2006 20:08:25 -0400 From: "Jim Stapleton" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ndis troubles - what's my next debugging step? 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, 29 Sep 2006 00:08:38 -0000 First of all, I appologize if this is the wrong place, an earlier request on -questions had no hits, and I need to get this working soon if possible. Although it's mostly internals stuff that's well over my head, I saw a couple driver related questions in the archive, and no one complained, so I am guessing this is the right place. System: Toshiba Satellite A105-4001 (Intel Core Solo 1.66Ghz, 512MB memory, i945GM graphics, IP 3945ABG wireless [NOT USED]). Since the 3945ABG doesn't have drivers now, and the project looks well and good halted for now, I found out that a linksys WPC54G card works (at least version 3) with NDIS throught this site: http://taosecurity.blogspot.com/2006/02/linksys-wpc54g-with-freebsd-yesterday.html I followed the instructions, and everything loads fine, but the card doesn't show up. I have inserted the card. The status light on it blinks green then goes off. I ran ndis and generated the driver as specified, kldload'ed the wlan_wep module, followed by ndis, followed by the card driver. After that I checked dmesg - the card did not appear (nothing with ndis or the card driver name). No errors came from kldload, and there was no ndis entry in /dev or /dev/net. Another site suggested pciconf -la to determine what cards are found, and I didn't see anything recognizable there. What's the next step in diagnostics? I'm runing FreeBSD 6.1 on i386. Please cc a copy of the reply to me as well as the newsgroup, as I am not a member. Thanks, -Jim Stapleton From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 08:35:32 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52CE216A403; Fri, 29 Sep 2006 08:35:32 +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 5419643D77; Fri, 29 Sep 2006 08:35:31 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C4BBC46B04; Fri, 29 Sep 2006 04:35:25 -0400 (EDT) Date: Fri, 29 Sep 2006 09:35:25 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <451C4850.5030302@freebsd.org> Message-ID: <20060929092813.U73166@fledge.watson.org> References: <451C4850.5030302@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 08:35:32 -0000 On Fri, 29 Sep 2006, Andre Oppermann wrote: > The patch is available here: > http://people.freebsd.org/~andre/sosend+m_uiotombuf-20060928.diff I like the concept of these changes in principle -- this is the reason I broke out sosend_copyin(), so that we could start plugging bits of the send routines more easily for optimization. However, I think we need to review this really carefully. A casual glance brought up one question, and I hope to get a chance to review this in detail in the next few days. The question is with regard to the 'space' variable. When breaking out sosend_copyin(), I originally simply passed space in as an argument, which is what you do currently. However, I found I had to change it to pass in the variable by reference so that it could be updated, as later portions of sosend() depend on it being updated in order to figure out what flags to pass to pru_send() with respect to PRUS_MORETOCOME, as well as for the (resid && space > 0) condition for the main loop. In your revised version, 'space' isn't updated in sosend() after calling m_uiotombuf(), which on a casual read, suggests that PRUS_MORETOCOME will no longer get set on the last pass into pru_send(), and that the loop may go an extra time and pass more data into TCP than there is room in the socket send buffer. I may be reading wrong, I've not had time to look in any detail, but that was my experience, so you may find you need to pass send by reference, as I do in sosend_copyin(), for the same reason. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 09:28:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D747916A403 for ; Fri, 29 Sep 2006 09:28:20 +0000 (UTC) (envelope-from chirisum@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 446C043D46 for ; Fri, 29 Sep 2006 09:28:20 +0000 (GMT) (envelope-from chirisum@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so965802nfc for ; Fri, 29 Sep 2006 02:28:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=bgFB9r0aKOod8VxXnEK5lKYNC/qVHGWRnpKo7Ejj1GjNvU19SpKmNZpa4KweWAilA0KeyJkQo2CYiDIdMwAG6pR9gw+RRw1DXFNY8Vz8tz81737ovLA4mFgAh/RM03YdgnooK95ev6bvhu9ZK1hX0ETyJPI4Q4lfukMVgVXiV1g= Received: by 10.78.128.11 with SMTP id a11mr187309hud; Fri, 29 Sep 2006 02:28:18 -0700 (PDT) Received: by 10.78.160.15 with HTTP; Fri, 29 Sep 2006 02:28:18 -0700 (PDT) Message-ID: Date: Fri, 29 Sep 2006 14:58:18 +0530 From: "Srini vasa" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: TCP SACK query 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, 29 Sep 2006 09:28:20 -0000 Hi, Is there a document discussing the implementation of SACK in freeBSD TCPIP stack?? I am going through the code and have a few doubts regarding certain aspects of the code. thanks, Chiri From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 09:55:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F56516A4DE for ; Fri, 29 Sep 2006 09:55:24 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A47943D6E for ; Fri, 29 Sep 2006 09:55:16 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 91893 invoked from network); 29 Sep 2006 09:56:32 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Sep 2006 09:56:32 -0000 Message-ID: <451CED83.8070505@freebsd.org> Date: Fri, 29 Sep 2006 11:55:15 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Srini vasa References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: TCP SACK query 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, 29 Sep 2006 09:55:24 -0000 Srini vasa wrote: > Hi, > > Is there a document discussing the implementation of SACK in freeBSD TCPIP > stack?? I am going through the code and have a few doubts regarding certain > aspects of the code. We don't have a document detailing SACK in FreeBSD. If you have any questions or bug reports please report them mohans@freebsd.org and/or andre@freebsd.org. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 10:46:52 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF5DE16A40F; Fri, 29 Sep 2006 10:46:52 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8564843D76; Fri, 29 Sep 2006 10:46:47 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k8TAkidT089615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Sep 2006 14:46:45 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k8TAkiuY089614; Fri, 29 Sep 2006 14:46:44 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 29 Sep 2006 14:46:43 +0400 From: Gleb Smirnoff To: Bruce M Simpson Message-ID: <20060929104643.GQ59833@FreeBSD.org> References: <200609272156.k8RLuV03033703@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200609272156.k8RLuV03033703@freefall.freebsd.org> User-Agent: Mutt/1.5.6i Cc: johan@nocrew.org, net@FreeBSD.org Subject: Re: kern/95665: [if_tun] "ping: sendto: No buffer space available" with TUN interface (easily reproducable with test program) 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, 29 Sep 2006 10:46:52 -0000 Bruce, On Wed, Sep 27, 2006 at 09:56:31PM +0000, Bruce M Simpson wrote: B> Synopsis: [if_tun] "ping: sendto: No buffer space available" with TUN interface (easily reproducable with test program) B> B> State-Changed-From-To: feedback->suspended B> State-Changed-By: bms B> State-Changed-When: Wed Sep 27 21:56:02 UTC 2006 B> State-Changed-Why: B> Back to the free pool (can't reproduce) B> B> B> Responsible-Changed-From-To: bms->net B> Responsible-Changed-By: bms B> Responsible-Changed-When: Wed Sep 27 21:56:02 UTC 2006 B> Responsible-Changed-Why: B> Back to the free pool (can't reproduce) You didn't took it from free pool, but from me, w/o informing me about it before. Okay. Now, you gave up on the PR quite quickly, why aren't you returning it back to me? You kept the PR in feedback state for 11 hours, and then you suspend the PR! Are you expecting our users to reply immediately? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 11:30:33 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE14616A403; Fri, 29 Sep 2006 11:30:33 +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 61B3F43D45; Fri, 29 Sep 2006 11:30:33 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 7ED91DAE120; Fri, 29 Sep 2006 07:30:32 -0400 (EDT) Received: from heartbeat1.internal ([10.202.2.160]) by frontend3.internal (MEProxy); Fri, 29 Sep 2006 07:30:35 -0400 X-Sasl-enc: gXucx9+552lMCLY9+KdLl0LICG8/ILG+cosYbZz8TM8N 1159529433 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 256151734D; Fri, 29 Sep 2006 07:30:32 -0400 (EDT) Message-ID: <451D03D5.5070809@FreeBSD.org> Date: Fri, 29 Sep 2006 12:30:29 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: Gleb Smirnoff References: <200609272156.k8RLuV03033703@freefall.freebsd.org> <20060929104643.GQ59833@FreeBSD.org> In-Reply-To: <20060929104643.GQ59833@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: johan@nocrew.org, net@FreeBSD.org Subject: Re: kern/95665: [if_tun] "ping: sendto: No buffer space available" with TUN interface (easily reproducable with test program) 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, 29 Sep 2006 11:30:33 -0000 Gleb Smirnoff wrote: > You didn't took it from free pool, but from me, w/o informing > me about it before. Okay. Now, you gave up on the PR quite > quickly, why aren't you returning it back to me? > Sorry! I have been trying to push forward on things and the PR formerly being assigned to you got lost in the noise. > You kept the PR in feedback state for 11 hours, and then you > suspend the PR! Are you expecting our users to reply immediately? > > The user responded saying they could not reproduce the problem further as they no longer had a FreeBSD system installed. Despite my best efforts I could not reproduce the problem with the test case given on RELENG_6_1 and HEAD, as I documented in the PR. Apologies for any confusion caused. Best regards, BMS From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 11:35:04 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 286D916A407; Fri, 29 Sep 2006 11:35:04 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFB7A43D4C; Fri, 29 Sep 2006 11:35:02 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k8TBZ0gB089925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Sep 2006 15:35:01 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k8TBZ0EE089924; Fri, 29 Sep 2006 15:35:00 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 29 Sep 2006 15:35:00 +0400 From: Gleb Smirnoff To: "Bruce M. Simpson" Message-ID: <20060929113500.GR59833@cell.sick.ru> References: <200609272156.k8RLuV03033703@freefall.freebsd.org> <20060929104643.GQ59833@FreeBSD.org> <451D03D5.5070809@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <451D03D5.5070809@FreeBSD.org> User-Agent: Mutt/1.5.6i Cc: johan@nocrew.org, net@FreeBSD.org Subject: Re: kern/95665: [if_tun] "ping: sendto: No buffer space available" with TUN interface (easily reproducable with test program) 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, 29 Sep 2006 11:35:04 -0000 Bruce, On Fri, Sep 29, 2006 at 12:30:29PM +0100, Bruce M. Simpson wrote: B> >You kept the PR in feedback state for 11 hours, and then you B> >suspend the PR! Are you expecting our users to reply immediately? B> > B> The user responded saying they could not reproduce the problem further B> as they no longer had a FreeBSD system installed. Ohh, people again aren't adding neither bug-followup@ nor freebsd-gnats-submit@ to the Cc of their replies. B> Despite my best B> efforts I could not reproduce the problem with the test case given on B> RELENG_6_1 and HEAD, as I documented in the PR. The subject problem has been reported several times on the mailing lists, and I've also observed it myself in the past. There is definitely a bug that brings tun(4) to a state when nothing can be transmitted. B> Apologies for any confusion caused. No problem. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 13:01:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D1E616A523 for ; Fri, 29 Sep 2006 13:01:19 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCEE143D55 for ; Fri, 29 Sep 2006 13:01:17 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 93219 invoked from network); 29 Sep 2006 13:02:32 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Sep 2006 13:02:32 -0000 Message-ID: <451D191C.2050307@freebsd.org> Date: Fri, 29 Sep 2006 15:01:16 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Robert Watson References: <451C4850.5030302@freebsd.org> <20060929092813.U73166@fledge.watson.org> In-Reply-To: <20060929092813.U73166@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 13:01:19 -0000 Robert Watson wrote: > > On Fri, 29 Sep 2006, Andre Oppermann wrote: > >> The patch is available here: >> http://people.freebsd.org/~andre/sosend+m_uiotombuf-20060928.diff > > I like the concept of these changes in principle -- this is the reason I > broke out sosend_copyin(), so that we could start plugging bits of the > send routines more easily for optimization. However, I think we need to > review this really carefully. A casual glance brought up one question, > and I hope to get a chance to review this in detail in the next few > days. The question is with regard to the 'space' variable. When > breaking out sosend_copyin(), I originally simply passed space in as an > argument, which is what you do currently. However, I found I had to > change it to pass in the variable by reference so that it could be > updated, as later portions of sosend() depend on it being updated in > order to figure out what flags to pass to pru_send() with respect to > PRUS_MORETOCOME, as well as for the (resid && space > 0) condition for > the main loop. In your revised version, 'space' isn't updated in > sosend() after calling m_uiotombuf(), which on a casual read, suggests > that PRUS_MORETOCOME will no longer get set on the last pass into > pru_send(), and that the loop may go an extra time and pass more data > into TCP than there is room in the socket send buffer. I may be reading > wrong, I've not had time to look in any detail, but that was my > experience, so you may find you need to pass send by reference, as I do > in sosend_copyin(), for the same reason. Your observation is correct. The variable 'space' is no longer updated with my changes. For sosend_dgram() this is of no consequence as PRUS_ MORETOCOME can't ever be true. For datagrams the uio must not contain more data than we have space left in the socket buffer. Otherwise we fail with EMSGSIZE. For sosend_generic() PRUS_MORETOCOME is no longer correctly set with my changes. For TCP this is of no consequence either as TCP doesn't care about it. For correctness I'll change my patch to update 'space' in sosend_generic() and remove the PRUS_MORETOCOME flag from sosend_dgram() completely. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 13:07:27 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDBC716A40F; Fri, 29 Sep 2006 13:07:27 +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 5B0D043D4C; Fri, 29 Sep 2006 13:07:27 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E391946D0B; Fri, 29 Sep 2006 09:07:26 -0400 (EDT) Date: Fri, 29 Sep 2006 14:07:26 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <451D191C.2050307@freebsd.org> Message-ID: <20060929140545.L66510@fledge.watson.org> References: <451C4850.5030302@freebsd.org> <20060929092813.U73166@fledge.watson.org> <451D191C.2050307@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 13:07:28 -0000 On Fri, 29 Sep 2006, Andre Oppermann wrote: >> I like the concept of these changes in principle -- this is the reason I >> broke out sosend_copyin(), so that we could start plugging bits of the send >> routines more easily for optimization. However, I think we need to review >> this really carefully. A casual glance brought up one question, and I hope >> to get a chance to review this in detail in the next few days. The >> question is with regard to the 'space' variable. When breaking out >> sosend_copyin(), I originally simply passed space in as an argument, which >> is what you do currently. However, I found I had to change it to pass in >> the variable by reference so that it could be updated, as later portions of >> sosend() depend on it being updated in order to figure out what flags to >> pass to pru_send() with respect to PRUS_MORETOCOME, as well as for the >> (resid && space > 0) condition for the main loop. In your revised version, >> 'space' isn't updated in sosend() after calling m_uiotombuf(), which on a >> casual read, suggests that PRUS_MORETOCOME will no longer get set on the >> last pass into pru_send(), and that the loop may go an extra time and pass >> more data into TCP than there is room in the socket send buffer. I may be >> reading wrong, I've not had time to look in any detail, but that was my >> experience, so you may find you need to pass send by reference, as I do in >> sosend_copyin(), for the same reason. > > Your observation is correct. The variable 'space' is no longer updated with > my changes. For sosend_dgram() this is of no consequence as PRUS_ > MORETOCOME can't ever be true. For datagrams the uio must not contain more > data than we have space left in the socket buffer. Otherwise we fail with > EMSGSIZE. For sosend_generic() PRUS_MORETOCOME is no longer correctly set > with my changes. For TCP this is of no consequence either as TCP doesn't > care about it. For correctness I'll change my patch to update 'space' in > sosend_generic() and remove the PRUS_MORETOCOME flag from sosend_dgram() > completely. Are you sure TCP doesn't care? I thought it used PRUS_MORETOCOME as a hint to determine whether to immediately output or wait for small segments, but admit to never having read the code in detail. Also, 'space' is not just about PRUS_MORETOCOME, it's also about the loop terminating at the right time. I'll try to give your revised patch a closer reading this weekend. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 20:37:34 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DED0116A47B; Fri, 29 Sep 2006 20:37:34 +0000 (UTC) (envelope-from johan@nocrew.org) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A47D43D45; Fri, 29 Sep 2006 20:37:33 +0000 (GMT) (envelope-from johan@nocrew.org) Received: from ironport.bredband.com ([195.54.107.82] [195.54.107.82]) by mxfep02.bredband.com with ESMTP id <20060929203732.JNQM21247.mxfep02.bredband.com@ironport.bredband.com>; Fri, 29 Sep 2006 22:37:32 +0200 Received: from c-c7aae255.027-12-67626717.cust.bredbandsbolaget.se (HELO six.nocrew.org) ([85.226.170.199]) by ironport.bredband.com with ESMTP; 29 Sep 2006 22:37:32 +0200 Received: from matilda (matilda [10.0.0.4]) by six.nocrew.org (Postfix) with ESMTP id 20AC515AEF; Fri, 29 Sep 2006 22:37:36 +0200 (CEST) From: Johan =?iso-8859-1?q?Bolmsj=F6?= To: Gleb Smirnoff Date: Fri, 29 Sep 2006 22:40:55 +0200 User-Agent: KMail/1.9.1 References: <200609272156.k8RLuV03033703@freefall.freebsd.org> <451D03D5.5070809@FreeBSD.org> <20060929113500.GR59833@cell.sick.ru> In-Reply-To: <20060929113500.GR59833@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609292240.55291.johan@nocrew.org> Cc: "Bruce M. Simpson" , net@freebsd.org Subject: Re: kern/95665: [if_tun] "ping: sendto: No buffer space available" with TUN interface (easily reproducable with test program) 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, 29 Sep 2006 20:37:35 -0000 On Friday 29 September 2006 13:35, Gleb Smirnoff wrote: > Bruce, > > On Fri, Sep 29, 2006 at 12:30:29PM +0100, Bruce M. Simpson wrote: > B> >You kept the PR in feedback state for 11 hours, and then you > B> >suspend the PR! Are you expecting our users to reply immediately? > B> > > B> The user responded saying they could not reproduce the problem further > B> as they no longer had a FreeBSD system installed. > > Ohh, people again aren't adding neither bug-followup@ nor > freebsd-gnats-submit@ to the Cc of their replies. > > B> Despite my best > B> efforts I could not reproduce the problem with the test case given on > B> RELENG_6_1 and HEAD, as I documented in the PR. > > The subject problem has been reported several times on the mailing > lists, and I've also observed it myself in the past. There is definitely > a bug that brings tun(4) to a state when nothing can be transmitted. > > B> Apologies for any confusion caused. > > No problem. Hello, I'm the one who wrote the bug :-) I submitted it because I had found others (via googling) who had had what I could see similar mbuf problems with many different network cards (and no real solution presented). I thought I had a foolproof way to reproduce it so I thought it might be helpfull. Anyway my system I was running this test on is a AMD X2 (dual core). Could it be SMP related? I have no idea myself.. As said before, I don't have freebsd on this box any more otherwise I would have helped to test again with a later FreeBSD version. BR, Johan From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 20:56:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E19516A412; Fri, 29 Sep 2006 20:56:25 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91F9043D4C; Fri, 29 Sep 2006 20:56:23 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 29 Sep 2006 13:56:20 -0700 X-IronPort-AV: i="4.09,238,1157353200"; d="scan'208"; a="326731250:sNHT1277491074" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TKuKjs005208; Fri, 29 Sep 2006 13:56:20 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k8TKuKif028081; Fri, 29 Sep 2006 13:56:20 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 13:56:19 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 13:56:19 -0700 Message-ID: <451D884F.1030807@cisco.com> Date: Fri, 29 Sep 2006 16:55:43 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Silbersack References: <451C4850.5030302@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 20:56:19.0284 (UTC) FILETIME=[B6697140:01C6E409] DKIM-Signature: a=rsa-sha1; q=dns; l=1339; t=1159563380; x=1160427380; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Much=20improved=20sosend_*()=20functions; X=v=3Dcisco.com=3B=20h=3DVUE9hWftOvPULvUJ9EhsWe/RDnk=3D; b=aBOdPqw/QULXevX7mWrz3kp1PRqkab5wHl0lALAfMFK5I6ttMWMfmqf9i5/cTmAWym5u0BJQ NpyNNks9qZ7sqJ3+0e/88PgaRxr/8H5K3IoEIo49tUgF/AWc/ZdWMv+d; Authentication-Results: sj-dkim-8.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 20:56:25 -0000 Mike Silbersack wrote: > On Fri, 29 Sep 2006, Andre Oppermann wrote: > > >>over it an copies the data into the mbufs by using uiomove(). sosend_dgram() >>and sosend_generic() are change to use m_uiotombuf() instead of sosend_copyin(). > > > Can you do some UDP testing with 512b, 1K, 2K, 4K, 8K, and 16K packets to > see if performance changes there as well? Hmm.. I would think 512b and 1K will not show any improvement.. since they would probably end up either in an mbuf chain.. or a single 2k (or maybe 4k) cluster.. ... quite a waste.. now if we had 512b and 1k clusters that would be cool... In fact I have always thought we should: a) have no data portion in an mbuf.. just pointers i.e. always an EXT b) Have a 256/512 and 1k cluster too.. This would allow copy by reference no matter what size si being sent... But of course .. thats just me :-) R > > How about local sockets? > > Impressive improvements for TCP, in any case! > > Mike "Silby" Silbersack > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 21:08:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E395916A551 for ; Fri, 29 Sep 2006 21:08:08 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1936243D66 for ; Fri, 29 Sep 2006 21:08:02 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 97450 invoked from network); 29 Sep 2006 21:09:14 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Sep 2006 21:09:14 -0000 Message-ID: <451D8B32.9010204@freebsd.org> Date: Fri, 29 Sep 2006 23:08:02 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Randall Stewart References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> In-Reply-To: <451D884F.1030807@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 21:08:09 -0000 Randall Stewart wrote: > Mike Silbersack wrote: >> On Fri, 29 Sep 2006, Andre Oppermann wrote: >> >> >>> over it an copies the data into the mbufs by using uiomove(). >>> sosend_dgram() >>> and sosend_generic() are change to use m_uiotombuf() instead of >>> sosend_copyin(). >> >> Can you do some UDP testing with 512b, 1K, 2K, 4K, 8K, and 16K packets to >> see if performance changes there as well? > > Hmm.. I would think 512b and 1K will not show any > improvement.. since they would probably end up either > in an mbuf chain.. or a single 2k (or maybe 4k) cluster.. > ... quite a waste.. now if we had 512b and 1k clusters that > would be cool... > > In fact I have always thought we should: > > a) have no data portion in an mbuf.. just pointers i.e. always > an EXT > > b) Have a 256/512 and 1k cluster too.. > > This would allow copy by reference no matter what size si > being sent... > > But of course .. thats just me :-) Well, people tell me to "profile, not speculate". So I'm doing it now with quite some success. Lets file your little rant here into the same category. ;-) -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 21:16:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB4E016A40F for ; Fri, 29 Sep 2006 21:16:01 +0000 (UTC) (envelope-from silby@silby.com) Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 6355143D4C for ; Fri, 29 Sep 2006 21:16:00 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 24239 invoked by uid 3193); 29 Sep 2006 21:15:59 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Sep 2006 21:15:59 -0000 Date: Fri, 29 Sep 2006 17:15:58 -0400 (EDT) From: Mike Silbersack X-X-Sender: silby@niwun.pair.com To: Randall Stewart In-Reply-To: <451D884F.1030807@cisco.com> Message-ID: References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 21:16:01 -0000 On Fri, 29 Sep 2006, Randall Stewart wrote: > Hmm.. I would think 512b and 1K will not show any > improvement.. since they would probably end up either > in an mbuf chain.. or a single 2k (or maybe 4k) cluster.. I know, I just want to make sure that it doesn't somehow cause performance loss for those cases! > In fact I have always thought we should: > > a) have no data portion in an mbuf.. just pointers i.e. always > an EXT > > b) Have a 256/512 and 1k cluster too.. Implement and benchmark it. :) Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 21:32:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C47A16A415; Fri, 29 Sep 2006 21:32:56 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0467943D49; Fri, 29 Sep 2006 21:32:55 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Sep 2006 14:32:56 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TLWt85001369; Fri, 29 Sep 2006 14:32:55 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8TLWtQV009745; Fri, 29 Sep 2006 14:32:55 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 14:32:12 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 14:32:12 -0700 Message-ID: <451D90B8.8060202@cisco.com> Date: Fri, 29 Sep 2006 17:31:36 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Silbersack References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 21:32:12.0168 (UTC) FILETIME=[B9A17880:01C6E40E] DKIM-Signature: a=rsa-sha1; q=dns; l=832; t=1159565575; x=1160429575; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Much=20improved=20sosend_*()=20functions; X=v=3Dcisco.com=3B=20h=3DVUE9hWftOvPULvUJ9EhsWe/RDnk=3D; b=jp58XQpYoGSn/hrJFXGDH1pe/l6EJL4OU6kK99w3v2ZBi0gAaaXOU2LoL1sWkb6PQ5Xt72mR 1lzszthHQmaSuygZPWTNB/SNH77RYN4vLwFKA41CgMebFuBGDTqTYRdt; Authentication-Results: sj-dkim-3.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 21:32:56 -0000 Mike Silbersack wrote: > On Fri, 29 Sep 2006, Randall Stewart wrote: > > >>Hmm.. I would think 512b and 1K will not show any >>improvement.. since they would probably end up either >>in an mbuf chain.. or a single 2k (or maybe 4k) cluster.. > > > I know, I just want to make sure that it doesn't somehow cause performance > loss for those cases! > > >>In fact I have always thought we should: >> >>a) have no data portion in an mbuf.. just pointers i.e. always >> an EXT >> >>b) Have a 256/512 and 1k cluster too.. Hmm.. I could do that.. maybe I will when my plate clears off a bit.. but then again.. that may be never :-0 R > > > Implement and benchmark it. :) > > Mike "Silby" Silbersack > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 21:37:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3731016A407; Fri, 29 Sep 2006 21:37:46 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 080A643D64; Fri, 29 Sep 2006 21:37:41 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (dcv25qxoqk31iw4t@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8TLbQ7L035392; Fri, 29 Sep 2006 14:37:26 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8TLbNJM035391; Fri, 29 Sep 2006 14:37:23 -0700 (PDT) (envelope-from jmg) Date: Fri, 29 Sep 2006 14:37:22 -0700 From: John-Mark Gurney To: Randall Stewart Message-ID: <20060929213722.GR80527@funkthat.com> Mail-Followup-To: Randall Stewart , Mike Silbersack , freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <451D884F.1030807@cisco.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 21:37:46 -0000 Randall Stewart wrote this message on Fri, Sep 29, 2006 at 16:55 -0400: > Mike Silbersack wrote: > >On Fri, 29 Sep 2006, Andre Oppermann wrote: > > > > > >>over it an copies the data into the mbufs by using uiomove(). > >>sosend_dgram() > >>and sosend_generic() are change to use m_uiotombuf() instead of > >>sosend_copyin(). > > > > > >Can you do some UDP testing with 512b, 1K, 2K, 4K, 8K, and 16K packets to > >see if performance changes there as well? > > Hmm.. I would think 512b and 1K will not show any > improvement.. since they would probably end up either > in an mbuf chain.. or a single 2k (or maybe 4k) cluster.. > ... quite a waste.. now if we had 512b and 1k clusters that > would be cool... > > In fact I have always thought we should: > > a) have no data portion in an mbuf.. just pointers i.e. always > an EXT > > b) Have a 256/512 and 1k cluster too.. > > This would allow copy by reference no matter what size si > being sent... IMO it's quite a waste of memory the way we have thigns now, though w/ TSO it'll change things... w/ 512 byte mbuf and a 2k cluster just to store just 1514 bytes of data, that's only 60% effeciency wrt to memory usage... so, we currently waste 40% of memory allocated to mbufs+clusters... Even reducing mbufs back to 128 or 256 would be a big help, though IPSEC I believe would have issues... Hmmm.. If we switched clusters to 1536 bytes in size, we'd be able to fit 8 in 12k (though I guess for 8k page boxes we'd do 16 in 24k)... The only issue w/ that would be that a few of the clusters would possibly split page boundaries... How much this would effect performance would be an interesting question to answer... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 21:47:28 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 697E316A416; Fri, 29 Sep 2006 21:47:28 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 315B143D49; Fri, 29 Sep 2006 21:47:19 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 29 Sep 2006 14:47:19 -0700 X-IronPort-AV: i="4.09,238,1157353200"; d="scan'208"; a="326743810:sNHT2388261358" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TLlHt9022220; Fri, 29 Sep 2006 14:47:17 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k8TLlHid014772; Fri, 29 Sep 2006 14:47:17 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Sep 2006 14:47:17 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 14:47:16 -0700 Message-ID: <451D9440.6060105@cisco.com> Date: Fri, 29 Sep 2006 17:46:40 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John-Mark Gurney References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> In-Reply-To: <20060929213722.GR80527@funkthat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 21:47:16.0995 (UTC) FILETIME=[D4F31D30:01C6E410] DKIM-Signature: a=rsa-sha1; q=dns; l=1747; t=1159566438; x=1160430438; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Much=20improved=20sosend_*()=20functions; X=v=3Dcisco.com=3B=20h=3DVUE9hWftOvPULvUJ9EhsWe/RDnk=3D; b=LaxrvinT243oWFgRmCNNcaJnU63/9+vkyO8qPMShp04FDcO4ciaNtNfyJ+NnBwNYRYP2Yi8X sNWZBNVJFH4VKxKyig2ITr/Q1y+QeJGEys147anRqcLeOilrhJeyRfol; Authentication-Results: sj-dkim-5.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 21:47:28 -0000 John-Mark Gurney wrote: > IMO it's quite a waste of memory the way we have thigns now, though > w/ TSO it'll change things... > > w/ 512 byte mbuf and a 2k cluster just to store just 1514 bytes of data, I did not know we were at 512 byte mbufs.. I thought they were 256 bytes.. of course I have not checked recently :-0 > that's only 60% effeciency wrt to memory usage... so, we currently > waste 40% of memory allocated to mbufs+clusters... Even reducing > mbufs back to 128 or 256 would be a big help, though IPSEC I believe > would have issues... Ahh.. thats probably why they grew and I did not realize it.. Hmm. at 512 bytes it seems to me even more worthwhile to make everything an EXT.. but thats just me (its not a rant... at least I don't think so).. just something I think would be cool and MAY gain some efficency.. I know it would for SCTP.. not sure about TCP.. and UDP is not so big of deal since the packet is sent to driver land after copy anyway.. no need to retransmit ;-) > > Hmmm.. If we switched clusters to 1536 bytes in size, we'd be able to > fit 8 in 12k (though I guess for 8k page boxes we'd do 16 in 24k)... The > only issue w/ that would be that a few of the clusters would possibly > split page boundaries... How much this would effect performance would > be an interesting question to answer... That is a good point.. 1536 is a good size for network things...vs 2k... Of course 2 - 2k fits nicely in a page.. Maybe I will make some time shortly to play with this.. change 2k - 1536 and make and reshape mbufs to always have clusters... see what my box would do then ;-D R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 21:59:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E76B16A403 for ; Fri, 29 Sep 2006 21:59:36 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF6DE43D7B for ; Fri, 29 Sep 2006 21:59:25 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 97872 invoked from network); 29 Sep 2006 22:00:36 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Sep 2006 22:00:36 -0000 Message-ID: <451D973C.8070004@freebsd.org> Date: Fri, 29 Sep 2006 23:59:24 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: John-Mark Gurney References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> In-Reply-To: <20060929213722.GR80527@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Randall Stewart , freebsd-current@freebsd.org, gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 21:59:36 -0000 John-Mark Gurney wrote: > Randall Stewart wrote this message on Fri, Sep 29, 2006 at 16:55 -0400: > >>Mike Silbersack wrote: >> >>>On Fri, 29 Sep 2006, Andre Oppermann wrote: >>> >>> >>> >>>>over it an copies the data into the mbufs by using uiomove(). >>>>sosend_dgram() >>>>and sosend_generic() are change to use m_uiotombuf() instead of >>>>sosend_copyin(). >>> >>> >>>Can you do some UDP testing with 512b, 1K, 2K, 4K, 8K, and 16K packets to >>>see if performance changes there as well? >> >>Hmm.. I would think 512b and 1K will not show any >>improvement.. since they would probably end up either >>in an mbuf chain.. or a single 2k (or maybe 4k) cluster.. >>... quite a waste.. now if we had 512b and 1k clusters that >>would be cool... >> >>In fact I have always thought we should: >> >>a) have no data portion in an mbuf.. just pointers i.e. always >> an EXT >> >>b) Have a 256/512 and 1k cluster too.. >> >>This would allow copy by reference no matter what size si >>being sent... > > > IMO it's quite a waste of memory the way we have thigns now, though > w/ TSO it'll change things... Receive path != send path. > w/ 512 byte mbuf and a 2k cluster just to store just 1514 bytes of data, > that's only 60% effeciency wrt to memory usage... so, we currently > waste 40% of memory allocated to mbufs+clusters... Even reducing > mbufs back to 128 or 256 would be a big help, though IPSEC I believe > would have issues... mbufs are 256 bytes. > Hmmm.. If we switched clusters to 1536 bytes in size, we'd be able to > fit 8 in 12k (though I guess for 8k page boxes we'd do 16 in 24k)... The > only issue w/ that would be that a few of the clusters would possibly > split page boundaries... How much this would effect performance would > be an interesting question to answer... Splitting page boundaries is not an option as it may not be physically contigous. Just don't overengineer the stuff. Mbufs are only used temporarily and a bit theoretical waste is not much a problem (so far at least). -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 22:06:04 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C742316A40F; Fri, 29 Sep 2006 22:06:04 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7F2843D55; Fri, 29 Sep 2006 22:06:00 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id k8TM60LP023391 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 29 Sep 2006 18:06:00 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k8TM5t7A061952; Fri, 29 Sep 2006 18:05:55 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17693.39106.950631.742167@grasshopper.cs.duke.edu> Date: Fri, 29 Sep 2006 18:05:54 -0400 (EDT) To: Andre Oppermann In-Reply-To: <451D9440.6060105@cisco.com> References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D9440.6060105@cisco.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 22:06:04 -0000 Andre, I meant to ask: Did you try 16KB jumbos? Did they perform any better than page-sized jumbos? Also, if we're going to change how mbufs work, let's add something like Linux's skb_frag_t frags[MAX_SKB_FRAGS]; In FreeBSD parlence, this embeds something like an array of sf_bufs pointers in mbuf. The big difference to a chain of M_EXT mbufs is that you need to allocate only one mbuf wrapper, rather than one for each item in the list. Also, the reference is kept in the page (or sf_buf) itself, and the data offset is kept in the skbbuf (or mbuf). This allows us to do cool things like allocate a single page, and use both halves of it for 2 separate 1500 byte frames. This allows us to achieve *amazing* results in combination with LRO, because it allows us to do, on average, many fewer allocations per byte. Especially in combination with Linux's "high order" page allocations. Using order-2 allocations and LRO, I've actually seen 10GbE line rate receives on a wimpy 2.0GHz Athlon64. Drew From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 22:07:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38E4216A407; Fri, 29 Sep 2006 22:07:46 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6027943D46; Fri, 29 Sep 2006 22:07:45 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 29 Sep 2006 15:07:45 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TM7jk0019611; Fri, 29 Sep 2006 15:07:45 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8TM7j1E001425; Fri, 29 Sep 2006 15:07:45 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 15:07:44 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 15:07:44 -0700 Message-ID: <451D990A.8080504@cisco.com> Date: Fri, 29 Sep 2006 18:07:06 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D973C.8070004@freebsd.org> In-Reply-To: <451D973C.8070004@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 22:07:44.0495 (UTC) FILETIME=[B098BFF0:01C6E413] DKIM-Signature: a=rsa-sha1; q=dns; l=1032; t=1159567665; x=1160431665; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Much=20improved=20sosend_*()=20functions; X=v=3Dcisco.com=3B=20h=3DVUE9hWftOvPULvUJ9EhsWe/RDnk=3D; b=sATMwkUjdA/+tRHC9tK3MPk72tolcUkSM6GiE5w4O0dr+wG1HyYnNcqkWfE0DX2eX+c4NJYY Xm6ToVGPS50jnfbw1B7JOXygNW4sYWgN3xsDOqTXTlCwmQRb9Whzq9Cw; Authentication-Results: sj-dkim-1.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org, John-Mark Gurney , freebsd-current@freebsd.org, gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 22:07:46 -0000 Andre Oppermann wrote: > John-Mark Gurney wrote: > > mbufs are 256 bytes. Thats what I had thought :-) > >> Hmmm.. If we switched clusters to 1536 bytes in size, we'd be able to >> fit 8 in 12k (though I guess for 8k page boxes we'd do 16 in 24k)... The >> only issue w/ that would be that a few of the clusters would possibly >> split page boundaries... How much this would effect performance would >> be an interesting question to answer... > > > Splitting page boundaries is not an option as it may not be physically > contigous. That can be rather hazardous :-) > > Just don't overengineer the stuff. Mbufs are only used temporarily and > a bit theoretical waste is not much a problem (so far at least). > Yes, but I think a combination of less copying and a bit better use of space could help overall.. but I guess as they say the "proof is in the pudding" so I will have to play a bit.. R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 22:29:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23B0A16A40F for ; Fri, 29 Sep 2006 22:29:48 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39FCD43D53 for ; Fri, 29 Sep 2006 22:29:47 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 98113 invoked from network); 29 Sep 2006 22:30:57 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Sep 2006 22:30:57 -0000 Message-ID: <451D9E59.9050000@freebsd.org> Date: Sat, 30 Sep 2006 00:29:45 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Andrew Gallatin References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D9440.6060105@cisco.com> <17693.39106.950631.742167@grasshopper.cs.duke.edu> In-Reply-To: <17693.39106.950631.742167@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 22:29:48 -0000 Andrew Gallatin wrote: > Andre, > > I meant to ask: Did you try 16KB jumbos? Did they perform > any better than page-sized jumbos? No, I didn't try 16K jumbos. The problem with anything larger than page size is that it may look contigous in kernel memory but isn't in physical memory. Thus you need the same number of descriptors for the network card as with page sized (4K) clusters. > Also, if we're going to change how mbufs work, let's add something > like Linux's skb_frag_t frags[MAX_SKB_FRAGS]; In FreeBSD parlence, > this embeds something like an array of sf_bufs pointers in mbuf. The > big difference to a chain of M_EXT mbufs is that you need to allocate > only one mbuf wrapper, rather than one for each item in the list. > Also, the reference is kept in the page (or sf_buf) itself, and the > data offset is kept in the skbbuf (or mbuf). We are not going to change how mbufs work. > This allows us to do cool things like allocate a single page, and use > both halves of it for 2 separate 1500 byte frames. This allows us to > achieve *amazing* results in combination with LRO, because it allows > us to do, on average, many fewer allocations per byte. Especially in > combination with Linux's "high order" page allocations. Using order-2 > allocations and LRO, I've actually seen 10GbE line rate receives on a > wimpy 2.0GHz Athlon64. I have just started tackling the receive path. Lets see what comes out of it first before we jump to conclusions. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 22:45:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D250D16A494; Fri, 29 Sep 2006 22:45:34 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E059943D76; Fri, 29 Sep 2006 22:45:31 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id k8TMjSLL000487 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 29 Sep 2006 18:45:28 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k8TMjNdL062030; Fri, 29 Sep 2006 18:45:23 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17693.41475.778558.381395@grasshopper.cs.duke.edu> Date: Fri, 29 Sep 2006 18:45:23 -0400 (EDT) To: Andre Oppermann In-Reply-To: <451D9E59.9050000@freebsd.org> References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D9440.6060105@cisco.com> <17693.39106.950631.742167@grasshopper.cs.duke.edu> <451D9E59.9050000@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 22:45:34 -0000 Andre Oppermann writes: > Andrew Gallatin wrote: > > Andre, > > > > I meant to ask: Did you try 16KB jumbos? Did they perform > > any better than page-sized jumbos? > > No, I didn't try 16K jumbos. The problem with anything larger than > page size is that it may look contigous in kernel memory but isn't > in physical memory. Thus you need the same number of descriptors > for the network card as with page sized (4K) clusters. But it would allow you to do one copyin, rather than 4. I don't know how much this would help, but it might be worth looking at. > > Also, if we're going to change how mbufs work, let's add something > > like Linux's skb_frag_t frags[MAX_SKB_FRAGS]; In FreeBSD parlence, > > this embeds something like an array of sf_bufs pointers in mbuf. The > > big difference to a chain of M_EXT mbufs is that you need to allocate > > only one mbuf wrapper, rather than one for each item in the list. > > Also, the reference is kept in the page (or sf_buf) itself, and the > > data offset is kept in the skbbuf (or mbuf). > > We are not going to change how mbufs work. > > > This allows us to do cool things like allocate a single page, and use > > both halves of it for 2 separate 1500 byte frames. This allows us to > > achieve *amazing* results in combination with LRO, because it allows > > us to do, on average, many fewer allocations per byte. Especially in > > combination with Linux's "high order" page allocations. Using order-2 > > allocations and LRO, I've actually seen 10GbE line rate receives on a > > wimpy 2.0GHz Athlon64. > > I have just started tackling the receive path. Lets see what comes out > of it first before we jump to conclusions. It could be mbufs are cheaper to get than skbs and pages on linux, but I doubt it. FWIW, linux has an skb chaining mechanism (frag_list). My first LRO experiment was based on allocating "normal" skbs and chaining them. That maxed out at around 5.2Gb/s (on the same hardware I see line rate on). Drew From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 22:54:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 443EE16A587 for ; Fri, 29 Sep 2006 22:54:49 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6CBF43D95 for ; Fri, 29 Sep 2006 22:54:36 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so1383537pye for ; Fri, 29 Sep 2006 15:54:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f5ptTLcu8N51NGb5QMifqQmB9tvjPg7/sdvCRRDyhIWCKkoRCnjJHOFruK9ymtBZl/rVsELQtg1W+jXO18fNAHhmV9KkPIaCxFB5k0bCSt+SrZHSU0djReZWBAMFPAMLAjxqifTVJJJM+N4iXSd7eqxk0qDmF5rwH5Szevn7zcI= Received: by 10.35.103.1 with SMTP id f1mr1404059pym; Fri, 29 Sep 2006 15:54:35 -0700 (PDT) Received: by 10.35.119.14 with HTTP; Fri, 29 Sep 2006 15:54:35 -0700 (PDT) Message-ID: <2a41acea0609291554g528f83d1ofaf35f7a4ea5ac28@mail.gmail.com> Date: Fri, 29 Sep 2006 15:54:35 -0700 From: "Jack Vogel" To: "Andrew Gallatin" In-Reply-To: <17693.41475.778558.381395@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D9440.6060105@cisco.com> <17693.39106.950631.742167@grasshopper.cs.duke.edu> <451D9E59.9050000@freebsd.org> <17693.41475.778558.381395@grasshopper.cs.duke.edu> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 22:54:49 -0000 On 9/29/06, Andrew Gallatin wrote: > > Andre Oppermann writes: > > Andrew Gallatin wrote: > > > Andre, > > > > > > I meant to ask: Did you try 16KB jumbos? Did they perform > > > any better than page-sized jumbos? > > > > No, I didn't try 16K jumbos. The problem with anything larger than > > page size is that it may look contigous in kernel memory but isn't > > in physical memory. Thus you need the same number of descriptors > > for the network card as with page sized (4K) clusters. > > But it would allow you to do one copyin, rather than 4. I > don't know how much this would help, but it might be worth > looking at. There is another limitation, due to hardware FIFO size, TSO must never have more than 4K per descriptor. But as Andrew says, that needn't limit you up above, it will just get parceled up in the driver. Jack From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 23:10:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D86816A415; Fri, 29 Sep 2006 23:10:22 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA5CA43D70; Fri, 29 Sep 2006 23:10:11 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (1getp7ac4kr9olq0@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8TNA8Nr037297; Fri, 29 Sep 2006 16:10:08 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8TNA7i3037296; Fri, 29 Sep 2006 16:10:07 -0700 (PDT) (envelope-from jmg) Date: Fri, 29 Sep 2006 16:10:07 -0700 From: John-Mark Gurney To: Andre Oppermann Message-ID: <20060929231007.GS80527@funkthat.com> Mail-Followup-To: Andre Oppermann , freebsd-net@freebsd.org, Randall Stewart , freebsd-current@freebsd.org, Mike Silbersack , gallatin@cs.duke.edu References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D973C.8070004@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <451D973C.8070004@freebsd.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-net@freebsd.org, Randall Stewart , freebsd-current@freebsd.org, gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 23:10:22 -0000 Andre Oppermann wrote this message on Fri, Sep 29, 2006 at 23:59 +0200: > >w/ 512 byte mbuf and a 2k cluster just to store just 1514 bytes of data, > >that's only 60% effeciency wrt to memory usage... so, we currently > >waste 40% of memory allocated to mbufs+clusters... Even reducing > >mbufs back to 128 or 256 would be a big help, though IPSEC I believe > >would have issues... > > mbufs are 256 bytes. Hmmm.. I keep getting this confused... maybe because there was discussion about increasing this a few years back... or maybe because NOTES has it as 512.. :) > >Hmmm.. If we switched clusters to 1536 bytes in size, we'd be able to > >fit 8 in 12k (though I guess for 8k page boxes we'd do 16 in 24k)... The > >only issue w/ that would be that a few of the clusters would possibly > >split page boundaries... How much this would effect performance would > >be an interesting question to answer... > > Splitting page boundaries is not an option as it may not be physically > contigous. unless we do something strange like allocate them contigously... though that introduces another set of issues.... > Just don't overengineer the stuff. Mbufs are only used temporarily and > a bit theoretical waste is not much a problem (so far at least). Well, I beg to differ... most gige cards grab mbuf+cluster for every single ring buffer they have.. which is usually 512... so every gige interface for the most part consumes 1meg of memory that is not reusable... because if we run out of mbuf+clusters to replace in the receive ring, we will not tap into the 1meg of mbuf+clusters available to us... so, if you have a quad gige, that's 4megs wasted, plus w/ the fact that we could only use ~65% of that memory, that's a lot of memory wasted... Yeh, everyone says you have gigs of memory, but do we really want to be known as the wasteful OS? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 23:11:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 187AB16A40F; Fri, 29 Sep 2006 23:11:02 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 953B443D6E; Fri, 29 Sep 2006 23:10:48 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 29 Sep 2006 16:10:49 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TNAmad020013; Fri, 29 Sep 2006 16:10:48 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8TNAm1E002493; Fri, 29 Sep 2006 16:10:48 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 16:10:48 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 16:10:47 -0700 Message-ID: <451DA7D4.8020609@cisco.com> Date: Fri, 29 Sep 2006 19:10:12 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Gallatin References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D9440.6060105@cisco.com> <17693.39106.950631.742167@grasshopper.cs.duke.edu> <451D9E59.9050000@freebsd.org> <17693.41475.778558.381395@grasshopper.cs.duke.edu> In-Reply-To: <17693.41475.778558.381395@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 23:10:48.0047 (UTC) FILETIME=[7FC4F7F0:01C6E41C] DKIM-Signature: a=rsa-sha1; q=dns; l=3066; t=1159571448; x=1160435448; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Much=20improved=20sosend_*()=20functions; X=v=3Dcisco.com=3B=20h=3DVUE9hWftOvPULvUJ9EhsWe/RDnk=3D; b=y+8iQMsAwHjX3/hVFa2gmkETnLnTAY9ShpyIHn8YCOwcn9AejGSfhIcaA83FYacAstz3KEtC IFScwUU92DBHV9hTg5VHjK37zPDFKXpJt1uGUxWQkPQ+ZZsXrrvJpk8V; Authentication-Results: sj-dkim-2.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 23:11:02 -0000 Andrew Gallatin wrote: > Andre Oppermann writes: > > Andrew Gallatin wrote: > > > Andre, > > > > > > I meant to ask: Did you try 16KB jumbos? Did they perform > > > any better than page-sized jumbos? > > > > No, I didn't try 16K jumbos. The problem with anything larger than > > page size is that it may look contigous in kernel memory but isn't > > in physical memory. Thus you need the same number of descriptors > > for the network card as with page sized (4K) clusters. > > But it would allow you to do one copyin, rather than 4. I > don't know how much this would help, but it might be worth > looking at. It helped the SCTP code quite a bit when I optimized it to use this... can't remember how much of a boost it got.. (I started using all the frames at one time).. and of course it only helps when the msg size being sent is > 9k... But it was a help... at least on the copy-in side for sending down.. > > > > Also, if we're going to change how mbufs work, let's add something > > > like Linux's skb_frag_t frags[MAX_SKB_FRAGS]; In FreeBSD parlence, > > > this embeds something like an array of sf_bufs pointers in mbuf. The > > > big difference to a chain of M_EXT mbufs is that you need to allocate > > > only one mbuf wrapper, rather than one for each item in the list. > > > Also, the reference is kept in the page (or sf_buf) itself, and the > > > data offset is kept in the skbbuf (or mbuf). > > > > We are not going to change how mbufs work. > > > > > This allows us to do cool things like allocate a single page, and use > > > both halves of it for 2 separate 1500 byte frames. This allows us to > > > achieve *amazing* results in combination with LRO, because it allows > > > us to do, on average, many fewer allocations per byte. Especially in > > > combination with Linux's "high order" page allocations. Using order-2 > > > allocations and LRO, I've actually seen 10GbE line rate receives on a > > > wimpy 2.0GHz Athlon64. > > > > I have just started tackling the receive path. Lets see what comes out > > of it first before we jump to conclusions. > > It could be mbufs are cheaper to get than skbs and pages on linux, > but I doubt it. FWIW, linux has an skb chaining mechanism > (frag_list). My first LRO experiment was based on allocating "normal" > skbs and chaining them. That maxed out at around 5.2Gb/s (on the same > hardware I see line rate on). This would be a drastic set of changes.. a bit more than the simple add a few more sizes and get rid of data inside the mbuf... which would shrink the mbuf size considerable... of course one would need always a data EXT... R > > Drew > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 23:12:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6214C16A407; Fri, 29 Sep 2006 23:12:46 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DF1E43D8A; Fri, 29 Sep 2006 23:12:36 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 29 Sep 2006 16:12:33 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TNCXCA029019; Fri, 29 Sep 2006 16:12:33 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8TNCW1E003174; Fri, 29 Sep 2006 16:12:32 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 16:12:32 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 16:12:32 -0700 Message-ID: <451DA83C.4050808@cisco.com> Date: Fri, 29 Sep 2006 19:11:56 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John-Mark Gurney References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D973C.8070004@freebsd.org> <20060929231007.GS80527@funkthat.com> In-Reply-To: <20060929231007.GS80527@funkthat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 23:12:32.0346 (UTC) FILETIME=[BDEFBBA0:01C6E41C] DKIM-Signature: a=rsa-sha1; q=dns; l=2158; t=1159571553; x=1160435553; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Much=20improved=20sosend_*()=20functions; X=v=3Dcisco.com=3B=20h=3DVUE9hWftOvPULvUJ9EhsWe/RDnk=3D; b=SW2mOXpPB6lMuG3nFobwJGfZ1GztAodblcNhw4PziNJ/rSBtM6mpmmCLwG/aZYCRcZ8V3n0Z OP7F12zIZrfjREa8RRRHyWwpQTBJxLqeZXpEOsXAs99RrtVUeXnpqKPa; Authentication-Results: sj-dkim-4.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 23:12:46 -0000 John-Mark Gurney wrote: > Andre Oppermann wrote this message on Fri, Sep 29, 2006 at 23:59 +0200: > >>>w/ 512 byte mbuf and a 2k cluster just to store just 1514 bytes of data, >>>that's only 60% effeciency wrt to memory usage... so, we currently >>>waste 40% of memory allocated to mbufs+clusters... Even reducing >>>mbufs back to 128 or 256 would be a big help, though IPSEC I believe >>>would have issues... >> >>mbufs are 256 bytes. > > > Hmmm.. I keep getting this confused... maybe because there was discussion > about increasing this a few years back... or maybe because NOTES has > it as 512.. :) > > >>>Hmmm.. If we switched clusters to 1536 bytes in size, we'd be able to >>>fit 8 in 12k (though I guess for 8k page boxes we'd do 16 in 24k)... The >>>only issue w/ that would be that a few of the clusters would possibly >>>split page boundaries... How much this would effect performance would >>>be an interesting question to answer... >> >>Splitting page boundaries is not an option as it may not be physically >>contigous. > > > unless we do something strange like allocate them contigously... though > that introduces another set of issues.... > > >>Just don't overengineer the stuff. Mbufs are only used temporarily and >>a bit theoretical waste is not much a problem (so far at least). > > > Well, I beg to differ... most gige cards grab mbuf+cluster for every > single ring buffer they have.. which is usually 512... so every gige > interface for the most part consumes 1meg of memory that is not > reusable... because if we run out of mbuf+clusters to replace in the > receive ring, we will not tap into the 1meg of mbuf+clusters available > to us... so, if you have a quad gige, that's 4megs wasted, plus w/ the > fact that we could only use ~65% of that memory, that's a lot of memory > wasted... > > Yeh, everyone says you have gigs of memory, but do we really want to > be known as the wasteful OS? > Let me try to find some cycles (somewhere) and play with this :-) R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-net@FreeBSD.ORG Fri Sep 29 23:30:28 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D462916A40F for ; Fri, 29 Sep 2006 23:30:28 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F11543D70 for ; Fri, 29 Sep 2006 23:30:25 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 98644 invoked from network); 29 Sep 2006 23:31:35 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Sep 2006 23:31:35 -0000 Message-ID: <451DAC8F.7030309@freebsd.org> Date: Sat, 30 Sep 2006 01:30:23 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andre Oppermann , freebsd-net@freebsd.org, Randall Stewart , freebsd-current@freebsd.org, Mike Silbersack , gallatin@cs.duke.edu References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D973C.8070004@freebsd.org> <20060929231007.GS80527@funkthat.com> In-Reply-To: <20060929231007.GS80527@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Much improved sosend_*() functions 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, 29 Sep 2006 23:30:28 -0000 John-Mark Gurney wrote: > Andre Oppermann wrote this message on Fri, Sep 29, 2006 at 23:59 +0200: >> Just don't overengineer the stuff. Mbufs are only used temporarily and >> a bit theoretical waste is not much a problem (so far at least). > > Well, I beg to differ... most gige cards grab mbuf+cluster for every > single ring buffer they have.. which is usually 512... so every gige > interface for the most part consumes 1meg of memory that is not > reusable... because if we run out of mbuf+clusters to replace in the > receive ring, we will not tap into the 1meg of mbuf+clusters available > to us... so, if you have a quad gige, that's 4megs wasted, plus w/ the > fact that we could only use ~65% of that memory, that's a lot of memory > wasted... The problem is the network cards again. Only a few allow different rx rings to be used (for example bge(4)) where you can have multiple mbuf (+cluster) sizes and the card choses the smallest fit at receive time. > Yeh, everyone says you have gigs of memory, but do we really want to > be known as the wasteful OS? -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Sep 30 11:56:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D85816A407; Sat, 30 Sep 2006 11:56:16 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13F5943D46; Sat, 30 Sep 2006 11:56:16 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 679CC61FF88; Sat, 30 Sep 2006 21:56:15 +1000 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id k8UBuC9d012947; Sat, 30 Sep 2006 21:56:13 +1000 Date: Sat, 30 Sep 2006 21:56:11 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: John-Mark Gurney In-Reply-To: <20060929231007.GS80527@funkthat.com> Message-ID: <20060930215218.V1683@epsplex.bde.org> References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D973C.8070004@freebsd.org> <20060929231007.GS80527@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Randall Stewart , freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions 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, 30 Sep 2006 11:56:16 -0000 On Fri, 29 Sep 2006, John-Mark Gurney wrote: > Andre Oppermann wrote this message on Fri, Sep 29, 2006 at 23:59 +0200: >> mbufs are 256 bytes. > > Hmmm.. I keep getting this confused... maybe because there was discussion > about increasing this a few years back... or maybe because NOTES has > it as 512.. :) It would be a bug if NOTES had the default size. Notes is supposed to alter defaults so that non-default code paths get tested. It often uses the default plus 1 or the default times 2 (the latter when the value must be a power of 2). Bruce From owner-freebsd-net@FreeBSD.ORG Sat Sep 30 18:54:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9860816A403 for ; Sat, 30 Sep 2006 18:54:10 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BAA143D67 for ; Sat, 30 Sep 2006 18:54:08 +0000 (GMT) (envelope-from mav@mavhome.dp.ua) X-Spam-Level: 2 [X] Received: from [195.248.178.122] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 16972343; Sat, 30 Sep 2006 21:54:08 +0300 Message-ID: <451EBD4B.1090602@mavhome.dp.ua> Date: Sat, 30 Sep 2006 21:54:03 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: lucky.freebsd.net To: Blue References: <1159449782.00609045.1159437602@10.7.7.3> In-Reply-To: <1159449782.00609045.1159437602@10.7.7.3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Does mpd (multi-link PPP daemon) support IPv6? 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, 30 Sep 2006 18:54:10 -0000 Hi. At this time mpd does not yet support IPv6CP. Blue wrote: > I want to know whether mpd (multi-link PPP daemon) could possibly > support IPv6. When I want to establish a PPTP connection with a PPTP > server running mpd, could I use IPv6CP instead of IPv4CP to set up the > PPP? If it supports, how could I configure the related parameters in the > configuration files? I could only find the ipcp syntax.