From owner-freebsd-net Sun Aug 18 10:33:33 2002 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 A7DEE37B400 for ; Sun, 18 Aug 2002 10:33:31 -0700 (PDT) Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05D7B43E3B for ; Sun, 18 Aug 2002 10:33:31 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 20D543854A; Sun, 18 Aug 2002 19:33:29 +0200 (CEST) Date: Sun, 18 Aug 2002 19:33:29 +0200 From: Jesper Skriver To: "George V. Neville-Neil" Cc: JINMEI Tatuya / ??????????? , Julian Elischer , freebsd-net@FreeBSD.ORG Subject: Re: Error in UDP output processing? Message-ID: <20020818173329.GA26321@FreeBSD.org> References: <200208132101.g7DL1jxe024775@mail.meer.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200208132101.g7DL1jxe024775@mail.meer.net> User-Agent: Mutt/1.4i X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Aug 13, 2002 at 02:01:45PM -0700, George V. Neville-Neil wrote: > Yes, this is what I would consider the correct fix UNLESS someone > knows of a reason to leave the socket like that for some odd reason > that I do not fathom. > > Do I need to put in a PR? Yes, that way it won't get lost. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Senior network engineer @ AS3292, TDC Tele Danmark One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 18 11:32:35 2002 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 E16A137B400; Sun, 18 Aug 2002 11:32:33 -0700 (PDT) Received: from outboundx.mv.meer.net (outboundx.mv.meer.net [209.157.152.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17DE243E4A; Sun, 18 Aug 2002 11:32:33 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outboundx.mv.meer.net (8.11.6/8.11.6) with ESMTP id g7IIWLa55464; Sun, 18 Aug 2002 11:32:22 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from neville-neil.com ([209.157.133.226]) by mail.meer.net (8.12.2/8.12.1/meer) with ESMTP id g7IIWWi1033238; Sun, 18 Aug 2002 11:32:32 -0700 (PDT) Message-Id: <200208181832.g7IIWWi1033238@mail.meer.net> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Jesper Skriver Cc: freebsd-net@FreeBSD.org Subject: Re: Error in UDP output processing? In-Reply-To: Message from Jesper Skriver of "Sun, 18 Aug 2002 19:33:29 +0200." <20020818173329.GA26321@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 Aug 2002 11:32:32 -0700 From: "George V. Neville-Neil" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Yes, that way it won't get lost. Done, I'm waiting for the PR number. I included Jinmei Tatuya's patch and credited him in the message. BTW The same patch is necessary in both -CURRENT and -STABLE as stated in the PR. Later, George -- George V. Neville-Neil gnn@neville-neil.com Neville-Neil Consulting www.neville-neil.com "I learn only to be contented." inscription at Ryoan-ji in Kyoto, Japan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 8:16:30 2002 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 2ACF037B401 for ; Mon, 19 Aug 2002 08:16:26 -0700 (PDT) Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92F8143E70 for ; Mon, 19 Aug 2002 08:16:25 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id EB44038549; Mon, 19 Aug 2002 17:16:23 +0200 (CEST) Date: Mon, 19 Aug 2002 17:16:23 +0200 From: Jesper Skriver To: Jeff Behl Cc: net@freebsd.org Subject: Re: MTU not working? Message-ID: <20020819151623.GD48757@FreeBSD.org> References: <3D585310.8010709@expertcity.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D585310.8010709@expertcity.com> User-Agent: Mutt/1.4i X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Aug 12, 2002 at 05:30:08PM -0700, Jeff Behl wrote: > We're seeing something odd that is seriously impacting our service for > some clients. Even though a the box seems to have the correct MTU in > the routing table, it doesn't seem to follow it in all cases. > > dell350-12.snv#sysctl -a | grep mtu > net.inet.tcp.path_mtu_discovery: 1 > > dell350-12.snv#uname -a > FreeBSD dell350-12.snv 4.4-RELEASE FreeBSD 4.4-RELEASE #0: Fri Aug 2 > 03:24:36 PDT 2002 > root@dell350-12.snv:/usr/src/sys/compile/COMMS44-2 i386 > > > dell350-12.snv#netstat -rnal | grep 10.4.1.134 > 10.4.1.134 63.xxx.224.129 UGHW 1 2268 1420 fxp0 > > > but tcpdump shows: > > > 17:21:43.497275 63.xxx.224.154.80 > 10.4.1.134.2314: . 1:1461(1460) ack > 248 win 17520 (DF) > 17:21:51.497212 63.xxx.224.154.80 > 10.4.1.134.2314: . 1:1461(1460) ack > 248 win 17520 (DF) > 17:22:07.497065 63.xxx.224.154.80 > 10.4.1.134.2314: . 1:1461(1460) ack > 248 win 17520 (DF) > > > obviosly the packet isn't making it back to the client as it's too big. > any ideas? I don't see any bug reports on it. We believe the same > situation exsits with a 4.6 server but I haven't checked that thorougly > enough yet. It's most likely a firewall or router filter, that block the ICMP messages coming back to your server. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Senior network engineer @ AS3292, TDC Tele Danmark One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 9:52:35 2002 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 5B54937B400 for ; Mon, 19 Aug 2002 09:52:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id D42E743E6E for ; Mon, 19 Aug 2002 09:52:28 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (6zfkc49mvx8wfc3x@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g7JGqSG19478 for ; Mon, 19 Aug 2002 09:52:28 -0700 (PDT) Message-ID: <3D61224B.2020902@isi.edu> Date: Mon, 19 Aug 2002 09:52:27 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: net@freebsd.org Subject: Bridging when one interface has no carrier Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010508090509090407030209" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms010508090509090407030209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I've filed a PR (kern/41632, http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/41632) on the following problem: FreeBSD box with two Ethernet NICs, e.g. if0 with IP address A and if1 with IP address B, bridged together: net.link.ether.bridge_cfg: if0 if1 net.link.ether.bridge: 1 Interface if0 is plugged in (has carrier), if1 isn't (no carrier). Packets arriving on if0 for IP address B (or the broadcast address) are not received by processes running on the bridging machine. Any ideas? Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms010508090509090407030209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDgxOTE2NTIyN1owIwYJKoZIhvcNAQkEMRYEFJw0vxDAIrWF /7jQpPoGHfo9ikpIMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYB1Q3M5XK28Pww0br5z9CCEs2NidQjr3rkWp3A2imG3P4CQ pW5Gvx9rIazDY7uKCltEaJyMgcjnz1eONAGZ2GoR6iuZlDO8WFgngX1HzWgPYCvTDaCHWX3Q EZejedMdSPcFaMLC/xXFqTAJax4quTkvUk1tdcr2i2febYikkIMG9gAAAAAAAA== --------------ms010508090509090407030209-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 10:29:57 2002 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 853FB37B400 for ; Mon, 19 Aug 2002 10:29:52 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B81243E42 for ; Mon, 19 Aug 2002 10:29:52 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7JHTpIb038906; Mon, 19 Aug 2002 10:29:51 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7JHTpJ4038905; Mon, 19 Aug 2002 10:29:51 -0700 (PDT) (envelope-from rizzo) Date: Mon, 19 Aug 2002 10:29:51 -0700 From: Luigi Rizzo To: Lars Eggert Cc: net@FreeBSD.ORG Subject: Re: Bridging when one interface has no carrier Message-ID: <20020819102951.A38869@iguana.icir.org> References: <3D61224B.2020902@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D61224B.2020902@isi.edu>; from larse@ISI.EDU on Mon, Aug 19, 2002 at 09:52:27AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I guess the responsible of the problem is this part of code in sys/net/if_ethersubr.c:ether_demux(): /* Discard packet if interface is not up */ if ((ifp->if_flags & IFF_UP) == 0) { m_freem(m); return; } which is somewhat funny, because once we have the packet, we might as well process it. Now, one could bypass the test for the bridging case, or remove it altogether... I am not sure which one is the best approach. cheers luigi On Mon, Aug 19, 2002 at 09:52:27AM -0700, Lars Eggert wrote: > Hi, > > I've filed a PR (kern/41632, > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/41632) on the following > problem: > > FreeBSD box with two Ethernet NICs, e.g. if0 with IP address A and if1 > with IP address B, bridged together: > > net.link.ether.bridge_cfg: if0 if1 > net.link.ether.bridge: 1 > > Interface if0 is plugged in (has carrier), if1 isn't (no carrier). > Packets arriving on if0 for IP address B (or the broadcast address) are > not received by processes running on the bridging machine. > > Any ideas? > > Thanks, > Lars > -- > Lars Eggert USC Information Sciences Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 10:40:14 2002 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 502A537B489 for ; Mon, 19 Aug 2002 10:39:57 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6AE043E65 for ; Mon, 19 Aug 2002 10:39:56 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (t9443ug7f0v72ot1@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g7JHdt711038; Mon, 19 Aug 2002 10:39:55 -0700 (PDT) Message-ID: <3D612D6A.9020604@isi.edu> Date: Mon, 19 Aug 2002 10:39:54 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: Bridging when one interface has no carrier References: <3D61224B.2020902@isi.edu> <20020819102951.A38869@iguana.icir.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080000080603030904070609" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms080000080603030904070609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Luigi Rizzo wrote: > I guess the responsible of the problem is this part of code > in sys/net/if_ethersubr.c:ether_demux(): > > /* Discard packet if interface is not up */ > if ((ifp->if_flags & IFF_UP) == 0) { > m_freem(m); > return; > } > > which is somewhat funny, because once we have the packet, we > might as well process it. > > Now, one could bypass the test for the bridging case, > or remove it altogether... I am not sure which one is > the best approach. I like the first idea (bypass when bridging) better. Link layers usually follow the "strong host model" (see RFC 1122), where inbound packets are dropped unless they match the destination address of the inbound interface. (Compared to the "weak host model" of IP, which acceptes inbound packets when their destination address matches *any* local interface.) Disabling that test altogether might weaken that property? Lars -- Lars Eggert USC Information Sciences Institute --------------ms080000080603030904070609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDgxOTE3Mzk1NVowIwYJKoZIhvcNAQkEMRYEFJ+eUH6+oYpy 0L6xiExZf48YV9oOMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYCsxRWzRBcrZyfWMW/lKr/gHcdwujFOYW/shAebTIP8BQS9 b64yBalq2fpl2TkHloKn61eH8aacBwRQTme8q3hHxnjohbiinzJsOfn0ZGjNyGcg/axJkuYM S4JQthgEcvdSVvtFOb2Zz/0ReBk+6oAPP/QJ5CZrLHUzvW+q9+R8HwAAAAAAAA== --------------ms080000080603030904070609-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 11:19:23 2002 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 C428C37B400 for ; Mon, 19 Aug 2002 11:19:20 -0700 (PDT) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08FA643E4A for ; Mon, 19 Aug 2002 11:19:20 -0700 (PDT) (envelope-from barney@databus.com) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.5/8.12.5) with ESMTP id g7JIJJXr009295 for ; Mon, 19 Aug 2002 14:19:19 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.5/8.12.5/Submit) id g7JIJJHA009294 for net@freebsd.org; Mon, 19 Aug 2002 14:19:19 -0400 (EDT) Date: Mon, 19 Aug 2002 14:19:19 -0400 From: Barney Wolff To: net@freebsd.org Subject: Re: Bridging when one interface has no carrier Message-ID: <20020819181919.GA9000@tp.databus.com> References: <3D61224B.2020902@isi.edu> <20020819102951.A38869@iguana.icir.org> <3D612D6A.9020604@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D612D6A.9020604@isi.edu> User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I don't recall that FreeBSD has ever had the "strong host model" property and (as I just confirmed by test) it doesn't have it now. If anything, it would make sense to reverse the test, and only allow packets arriving on the "wrong" interface when the right interface is down. But I'd rather see it depend on net.inet.ip.forwarding, or just keep using the loose model. The test ifp->if_flags & IFF_UP would seem to be applied to the interface the frame was received on, not the interface matching the dest IP addr. That makes sense, as it's likely to be garbage if it came on an apparently down interface. Out of idle curiosity, why do interfaces have to have IPs assigned to do bridging? That's not how "real" bridges/switches work. (I should probably go search the archives, as this has surely been answered before.) On Mon, Aug 19, 2002 at 10:39:54AM -0700, Lars Eggert wrote: > > I like the first idea (bypass when bridging) better. Link layers usually > follow the "strong host model" (see RFC 1122), where inbound packets are > dropped unless they match the destination address of the inbound > interface. (Compared to the "weak host model" of IP, which acceptes > inbound packets when their destination address matches *any* local > interface.) Disabling that test altogether might weaken that property? -- Barney Wolff I'm available by contract or FT: http://www.databus.com/bwresume.pdf To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 11:24:11 2002 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id B358837B400; Mon, 19 Aug 2002 11:24:08 -0700 (PDT) Date: Mon, 19 Aug 2002 11:24:08 -0700 From: Juli Mallett To: net@FreeBSD.org Subject: log_in_vain does not format IPv6 addrs properly for how they are used... Message-ID: <20020819112408.A45895@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org See patch: http://people.freebsd.org/~jmallett/bracket-ipv6-tcp.diff When doing log_in_vain, IPv6 addrs are listed, colon seperated with a port, but not enclosed in brackets. This encloses them properly for TCP6, and I could do a similar diff for UDP6, if such code should/can be touched in this regard, further diverging from KAME. I'd like to commit later today some time, this is straightforward, but I'd like a little bit of review. jules. -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 11:41:53 2002 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 0DBC337B400; Mon, 19 Aug 2002 11:41:50 -0700 (PDT) Received: from cheer.mahoroba.org (flets19-007.kamome.or.jp [218.45.19.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0106D43E65; Mon, 19 Aug 2002 11:41:49 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from mille.mahoroba.org (IDENT:FnVMlrUF1IJXisv/vkcaOn1ygJ1Qi7tVd8CqG5cWVdh+DMOeZ5Xtwe4sjBKHdGVo@mille.mahoroba.org [IPv6:2001:200:301:0:202:2dff:fe0a:6bee]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.12.5/8.12.5) with ESMTP/inet6 id g7JIfgbQ027542 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 20 Aug 2002 03:41:46 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 20 Aug 2002 03:41:41 +0900 Message-ID: From: Hajimu UMEMOTO To: Juli Mallett Cc: net@FreeBSD.org Subject: Re: log_in_vain does not format IPv6 addrs properly for how they are used... In-Reply-To: <20020819112408.A45895@FreeBSD.org> References: <20020819112408.A45895@FreeBSD.org> User-Agent: xcite1.38> Wanderlust/2.9.14 (Unchained Melody) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 4.6-STABLE MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, >>>>> On Mon, 19 Aug 2002 11:24:08 -0700 >>>>> Juli Mallett said: jmallett> See patch: http://people.freebsd.org/~jmallett/bracket-ipv6-tcp.diff jmallett> When doing log_in_vain, IPv6 addrs are listed, colon seperated with a port, jmallett> but not enclosed in brackets. Yes. But, it doesn't use short form of IPv6 printable format, here. So, you can simply distinguish port number from IPv6 address. :-) jmallett> This encloses them properly for TCP6, and I jmallett> could do a similar diff for UDP6, if such code should/can be touched in this jmallett> regard, further diverging from KAME. Thank you for asking it. This patch is to tcp_input.c. tcp_input.c is FreeBSD specific part in KAME repo, and your change is specific to FreeBSD. So, your change doesn't affect merging KAME. Please go ahead. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 11:43:11 2002 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 B9C0137B400 for ; Mon, 19 Aug 2002 11:43:09 -0700 (PDT) Received: from server.rucus.ru.ac.za (server.rucus.ru.ac.za [146.231.115.1]) by mx1.FreeBSD.org (Postfix) with SMTP id AC5A343E72 for ; Mon, 19 Aug 2002 11:43:05 -0700 (PDT) (envelope-from drs@rucus.ru.ac.za) Received: (qmail 65549 invoked from network); 19 Aug 2002 18:42:59 -0000 Received: from bashir.dsl.ru.ac.za (146.231.113.19) by server.rucus.ru.ac.za with SMTP; 19 Aug 2002 18:42:59 -0000 Received: (qmail 572 invoked by uid 1001); 19 Aug 2002 18:42:59 -0000 Date: Mon, 19 Aug 2002 20:42:59 +0200 From: David =?iso-8859-1?Q?Sieb=F6rger?= To: net@freebsd.org Subject: Re: Bridging when one interface has no carrier Message-ID: <20020819184259.GA523@rucus.ru.ac.za> References: <3D61224B.2020902@isi.edu> <20020819102951.A38869@iguana.icir.org> <3D612D6A.9020604@isi.edu> <20020819181919.GA9000@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20020819181919.GA9000@tp.databus.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon 2002-08-19 (14:19), Barney Wolff wrote: > Out of idle curiosity, why do interfaces have to have IPs assigned > to do bridging? That's not how "real" bridges/switches work. (I > should probably go search the archives, as this has surely been > answered before.) They don't - they just have to be up'ed. bashir:~$ grep ifconfig /etc/rc.conf ifconfig_tx0="inet bashir/28" ifconfig_tx1="up" bashir:~$ grep bridge /etc/sysctl.conf net.link.ether.bridge=1 net.link.ether.bridge_cfg=tx0:0,tx1:0 net.link.ether.bridge_ipfw=1 -- David Siebörger drs@rucus.ru.ac.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 11:48: 8 2002 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 0955937B47E for ; Mon, 19 Aug 2002 11:47:59 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C67943E3B for ; Mon, 19 Aug 2002 11:47:58 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (2cn6t8e4nv7rd9ce@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g7JIlt722473; Mon, 19 Aug 2002 11:47:55 -0700 (PDT) Message-ID: <3D613D5B.10507@isi.edu> Date: Mon, 19 Aug 2002 11:47:55 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Barney Wolff Cc: net@freebsd.org Subject: Re: Bridging when one interface has no carrier References: <3D61224B.2020902@isi.edu> <20020819102951.A38869@iguana.icir.org> <3D612D6A.9020604@isi.edu> <20020819181919.GA9000@tp.databus.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080307060508070900030201" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms080307060508070900030201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Barney Wolff wrote: > I don't recall that FreeBSD has ever had the "strong host model" > property and (as I just confirmed by test) it doesn't have it now. For IP, it doesn't, and never has. Packets destined for any local IP address are accepted (by IP), no matter which interface the come in over. For Ethernet, it does. Your NIC will drop packets that don't match its MAC address or broadcast. Lars -- Lars Eggert USC Information Sciences Institute --------------ms080307060508070900030201 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDgxOTE4NDc1NVowIwYJKoZIhvcNAQkEMRYEFCF0WiBn/+If RC/hY/1F6XmNZQODMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYAcfvbnun46IuWLi5123sPyYCgba02O/JwDJH9/zeAnKJDY 2+ip6VrnNHmETEMzDBzICTUc+Jq/cAs7Ul5mtRAGoJKs+aH4kgJMMwJAslVnr27MlRyoRJ/R 58P/L2UOUATB8vbqxmj9A5sHUzN4bREXtg2EnKZWh6mmX7bIx/tSLwAAAAAAAA== --------------ms080307060508070900030201-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 11:50:52 2002 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 2A70937B400; Mon, 19 Aug 2002 11:50:49 -0700 (PDT) Date: Mon, 19 Aug 2002 11:50:49 -0700 From: Juli Mallett To: Hajimu UMEMOTO Cc: net@FreeBSD.org Subject: Re: log_in_vain does not format IPv6 addrs properly for how they are used... Message-ID: <20020819115048.A47313@FreeBSD.org> References: <20020819112408.A45895@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ume@mahoroba.org on Tue, Aug 20, 2002 at 03:41:41AM +0900 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * De: Hajimu UMEMOTO [ Data: 2002-08-19 ] [ Subjecte: Re: log_in_vain does not format IPv6 addrs properly for how they are used... ] > Hi, > > >>>>> On Mon, 19 Aug 2002 11:24:08 -0700 > >>>>> Juli Mallett said: > > jmallett> See patch: http://people.freebsd.org/~jmallett/bracket-ipv6-tcp.diff > > jmallett> When doing log_in_vain, IPv6 addrs are listed, colon seperated with a port, > jmallett> but not enclosed in brackets. > > Yes. But, it doesn't use short form of IPv6 printable format, here. > So, you can simply distinguish port number from IPv6 address. :-) Yeah, but it's still tough for readability, all those [0-9A-F:]+ > jmallett> This encloses them properly for TCP6, and I > jmallett> could do a similar diff for UDP6, if such code should/can be touched in this > jmallett> regard, further diverging from KAME. > > Thank you for asking it. This patch is to tcp_input.c. tcp_input.c > is FreeBSD specific part in KAME repo, and your change is specific to > FreeBSD. So, your change doesn't affect merging KAME. Please go > ahead. Okay, thanks. What about with a change to netinet6/udp6_usrreq.c to simply log() with brackets, like: - "Connection attempt to UDP %s:%d from %s:%d\n", + "Connection attempt to UDP [%s]:%d from [%s]:%d\n", If that's an OK change to make, too, then I will commit these changes. Thanks very much, juli. -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 12: 8:43 2002 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 4E16B37B400 for ; Mon, 19 Aug 2002 12:08:41 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADF3D43E70 for ; Mon, 19 Aug 2002 12:08:40 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7JJ8eIb039678; Mon, 19 Aug 2002 12:08:40 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7JJ8ev2039677; Mon, 19 Aug 2002 12:08:40 -0700 (PDT) (envelope-from rizzo) Date: Mon, 19 Aug 2002 12:08:40 -0700 From: Luigi Rizzo To: Barney Wolff Cc: net@FreeBSD.ORG Subject: Re: Bridging when one interface has no carrier Message-ID: <20020819120840.A39647@iguana.icir.org> References: <3D61224B.2020902@isi.edu> <20020819102951.A38869@iguana.icir.org> <3D612D6A.9020604@isi.edu> <20020819181919.GA9000@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020819181919.GA9000@tp.databus.com>; from barney@tp.databus.com on Mon, Aug 19, 2002 at 02:19:19PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Aug 19, 2002 at 02:19:19PM -0400, Barney Wolff wrote: ... > The test ifp->if_flags & IFF_UP would seem to be applied to the > interface the frame was received on, not the interface matching yes. In fact, i think my explaination was wrong. Will look at the problem in more detail later. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 12:10:33 2002 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 318ED37B400 for ; Mon, 19 Aug 2002 12:10:30 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD0EB43E42 for ; Mon, 19 Aug 2002 12:10:29 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7JJASIb039721; Mon, 19 Aug 2002 12:10:28 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7JJASgQ039720; Mon, 19 Aug 2002 12:10:28 -0700 (PDT) (envelope-from rizzo) Date: Mon, 19 Aug 2002 12:10:28 -0700 From: Luigi Rizzo To: =?iso-8859-1?Q?David_Sieb=F6rger?= Cc: net@FreeBSD.ORG Subject: Re: Bridging when one interface has no carrier Message-ID: <20020819121028.B39647@iguana.icir.org> References: <3D61224B.2020902@isi.edu> <20020819102951.A38869@iguana.icir.org> <3D612D6A.9020604@isi.edu> <20020819181919.GA9000@tp.databus.com> <20020819184259.GA523@rucus.ru.ac.za> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020819184259.GA523@rucus.ru.ac.za>; from drs@rucus.ru.ac.za on Mon, Aug 19, 2002 at 08:42:59PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Aug 19, 2002 at 08:42:59PM +0200, David Siebörger wrote: > On Mon 2002-08-19 (14:19), Barney Wolff wrote: > > Out of idle curiosity, why do interfaces have to have IPs assigned > > to do bridging? That's not how "real" bridges/switches work. (I yes they don't have to. But you complained because packets were not delivered to the applications running on the bridge machine, and without an IP address there is no way (except bpf) to pass them up in the stack. Even bpf complains, moderately, if the interface does not have an address ... cheers luigi > > should probably go search the archives, as this has surely been > > answered before.) > > They don't - they just have to be up'ed. > > bashir:~$ grep ifconfig /etc/rc.conf > ifconfig_tx0="inet bashir/28" > ifconfig_tx1="up" > bashir:~$ grep bridge /etc/sysctl.conf > net.link.ether.bridge=1 > net.link.ether.bridge_cfg=tx0:0,tx1:0 > net.link.ether.bridge_ipfw=1 > > > -- > David Siebörger > drs@rucus.ru.ac.za > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 12:40:27 2002 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 CCB8937B401; Mon, 19 Aug 2002 12:40:24 -0700 (PDT) Received: from cheer.mahoroba.org (flets19-007.kamome.or.jp [218.45.19.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B89343E42; Mon, 19 Aug 2002 12:40:22 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from mille.mahoroba.org (IDENT:CZKdMX+uSngLpAXa7UQmNHATgRwr7c5i6FIU2TDw/103u0azjLYZMHVdoVACnLkU@mille.mahoroba.org [IPv6:2001:200:301:0:202:2dff:fe0a:6bee]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.12.5/8.12.5) with ESMTP/inet6 id g7JJeJbQ093836 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 20 Aug 2002 04:40:19 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 20 Aug 2002 04:40:19 +0900 Message-ID: From: Hajimu UMEMOTO To: Juli Mallett Cc: net@FreeBSD.org Subject: Re: log_in_vain does not format IPv6 addrs properly for how they are used... In-Reply-To: <20020819115048.A47313@FreeBSD.org> References: <20020819112408.A45895@FreeBSD.org> User-Agent: xcite1.38> Wanderlust/2.9.14 (Unchained Melody) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 4.6-STABLE MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, >>>>> On Mon, 19 Aug 2002 11:50:49 -0700 >>>>> Juli Mallett said: jmallett> Yeah, but it's still tough for readability, all those [0-9A-F:]+ Yes, actually. jmallett> Okay, thanks. What about with a change to netinet6/udp6_usrreq.c to simply jmallett> log() with brackets, like: jmallett> - "Connection attempt to UDP %s:%d from %s:%d\n", jmallett> + "Connection attempt to UDP [%s]:%d from [%s]:%d\n", jmallett> If that's an OK change to make, too, then I will commit these changes. Though netinet6/udp6_usrreq.c is in common part of KAME repo., here is still FreeBSD specific part, and enclosed by #ifdef __FreeBSD__ ... #endif in KAME repo. So, please go ahead. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 13:33:28 2002 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 2C88937B400 for ; Mon, 19 Aug 2002 13:33:24 -0700 (PDT) Received: from web21411.mail.yahoo.com (web21411.mail.yahoo.com [216.136.232.80]) by mx1.FreeBSD.org (Postfix) with SMTP id C334C43E4A for ; Mon, 19 Aug 2002 13:33:23 -0700 (PDT) (envelope-from zopewiz@yahoo.com) Message-ID: <20020819203323.25886.qmail@web21411.mail.yahoo.com> Received: from [63.170.174.190] by web21411.mail.yahoo.com via HTTP; Mon, 19 Aug 2002 13:33:23 PDT Date: Mon, 19 Aug 2002 13:33:23 -0700 (PDT) From: Carlos Carnero Subject: Bandwidth throttling with dummynet(4) To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have a "lab" here where I'm testing (and learning) traffic shaping with dummynet(4). I have a Windows XP host computer and a couple of VMware virtual computers: one running FreeBSD 4.5-RELEASE-p18, with two virtual Ethernet adapters and other running NetBSD 1.5.2 with one adapter. My FreeBSD "box" is the router/gateway for the NetBSD box, providing firewalling and NAT. Pretty much a standard setup, and it works OK (you should see the double NATting ;) Anyway, I have compiled into the kernel both IP Filter and FreeBSD's own ipfw, with the purpose of traffic shaping/bandwidth throttling. But the numbers I get are not what I expect. For instance, my ipfw rules are like: pipe 1000 config bw 5KByte/s queue 50 pipe 1001 config bw 5KByte/s queue 50 add 50000 pipe 1000 tcp from 192.168.250.3/32 to any add 50001 pipe 1001 tcp from any to 192.168.250.3/32 (192.168.250.3 being the NetBSD "box") But when I transfer a file using FTP from the Windows host I get _almost_ 1 KByte. Note that I remove the pipes speeds reach ~800-900 KByte/s, almost saturating the "virtual" Ethernet interfaces. Changing the pipe bandwidth to, say 25KByte/s in both pipes yield an FTP speed of ~5-6 KByte/s. Is this OK or FTP is that inefficient? What other tests can I run to check the bandwidth _not_ using FTP? IP Filter's ruleset is currently set to pass everything as quickly as it can :) Thanks a lot, Carlos. PS. Posting from Yahoo! until I solve some reverse DNS bugs I inherited :| __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 15:41:47 2002 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 C681237B400 for ; Mon, 19 Aug 2002 15:41:42 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5568E43E42 for ; Mon, 19 Aug 2002 15:41:42 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7JMfgIb041112; Mon, 19 Aug 2002 15:41:42 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7JMfgS6041111; Mon, 19 Aug 2002 15:41:42 -0700 (PDT) (envelope-from rizzo) Date: Mon, 19 Aug 2002 15:41:42 -0700 From: Luigi Rizzo To: Carlos Carnero Cc: freebsd-net@FreeBSD.ORG Subject: Re: Bandwidth throttling with dummynet(4) Message-ID: <20020819154141.A41050@iguana.icir.org> References: <20020819203323.25886.qmail@web21411.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020819203323.25886.qmail@web21411.mail.yahoo.com>; from zopewiz@yahoo.com on Mon, Aug 19, 2002 at 01:33:23PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org dummynet pipes use timers heavily, and i suspect that the timer granularity in vmware might not be as good as you would want, resulting in a throughput which is a fraction of what you have configured in the pipes. Also, 5Kbytes/s is a very low bandwidth, which coupled with 50 queue slots (~75Kbytes with large packets) will result in very large RTTs which could in turn trigger useless retransmissions and timeouts. I would first check if timing is accurate by setting a delay-only pipe and seeing if ping times correspond to what you have configured. Secondly, i would reduce the queue size to something reasonable e.g. 10Kbytes to avoid the potentially huge RTTs. cheers luigi On Mon, Aug 19, 2002 at 01:33:23PM -0700, Carlos Carnero wrote: > Hi, > > I have a "lab" here where I'm testing (and learning) > traffic shaping with dummynet(4). I have a Windows XP > host computer and a couple of VMware virtual > computers: one running FreeBSD 4.5-RELEASE-p18, with > two virtual Ethernet adapters and other running NetBSD > 1.5.2 with one adapter. My FreeBSD "box" is the > router/gateway for the NetBSD box, providing > firewalling and NAT. Pretty much a standard setup, and > it works OK (you should see the double NATting ;) > > Anyway, I have compiled into the kernel both IP Filter > and FreeBSD's own ipfw, with the purpose of traffic > shaping/bandwidth throttling. But the numbers I get > are not what I expect. For instance, my ipfw rules are > like: > > pipe 1000 config bw 5KByte/s queue 50 > pipe 1001 config bw 5KByte/s queue 50 > > add 50000 pipe 1000 tcp from 192.168.250.3/32 to any > add 50001 pipe 1001 tcp from any to 192.168.250.3/32 > > (192.168.250.3 being the NetBSD "box") But when I > transfer a file using FTP from the Windows host I get > _almost_ 1 KByte. Note that I remove the pipes speeds > reach ~800-900 KByte/s, almost saturating the > "virtual" Ethernet interfaces. Changing the pipe > bandwidth to, say 25KByte/s in both pipes yield an FTP > speed of ~5-6 KByte/s. Is this OK or FTP is that > inefficient? What other tests can I run to check the > bandwidth _not_ using FTP? > > IP Filter's ruleset is currently set to pass > everything as quickly as it can :) > > Thanks a lot, > Carlos. > > PS. Posting from Yahoo! until I solve some reverse DNS > bugs I inherited :| > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 15:59:10 2002 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 AF08C37B400; Mon, 19 Aug 2002 15:59:05 -0700 (PDT) Received: from 66-162-33-178.gen.twtelecom.net (66-162-33-178.gen.twtelecom.net [66.162.33.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E19C43E3B; Mon, 19 Aug 2002 15:59:05 -0700 (PDT) (envelope-from sfrancis@expertcity.com) Received: from [10.4.2.41] (helo=expertcity.com) by 66-162-33-178.gen.twtelecom.net with esmtp (Exim 3.22 #4) id 17gvUG-0003GK-00; Mon, 19 Aug 2002 15:59:04 -0700 Message-ID: <3D617842.4020304@expertcity.com> Date: Mon, 19 Aug 2002 15:59:14 -0700 From: Steve Francis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Jesper Skriver Cc: Jeff Behl , net@freebsd.org Subject: Re: MTU not working? References: <3D585310.8010709@expertcity.com> <20020819151623.GD48757@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Allow me to respond for Jeff (we work at same place, and have both been looking this issue) ICMP's being blocked are the most common explanation for this - but this is not the case here. tcpdump run on the server system shows the ICMP fragmention required - DF bit set messages being received, and - the irrefutable proof that it is not an ICMP filtering issue -the FreeBSD system DOES lower the MTU for that host's cloned route to the value specified in the ICMP (1420 in the snippet below). New packets are segmented to sizes <= the new MTU, but it continues resend the original packet over and over, in the original 1500 byte size. So I still say FreeBSD has broken pMTU-D code. This is reproducible at will, so we can collect whatever info anyone wants. The ICMP's Jesper Skriver wrote: > > On Mon, Aug 12, 2002 at 05:30:08PM -0700, Jeff Behl wrote: > > We're seeing something odd that is seriously impacting our service for > > some clients. Even though a the box seems to have the correct MTU in > > the routing table, it doesn't seem to follow it in all cases. > > > > dell350-12.snv#sysctl -a | grep mtu > > net.inet.tcp.path_mtu_discovery: 1 > > > > dell350-12.snv#uname -a > > FreeBSD dell350-12.snv 4.4-RELEASE FreeBSD 4.4-RELEASE #0: Fri Aug 2 > > 03:24:36 PDT 2002 > > root@dell350-12.snv:/usr/src/sys/compile/COMMS44-2 i386 > > > > > > dell350-12.snv#netstat -rnal | grep 10.4.1.134 > > 10.4.1.134 63.xxx.224.129 UGHW 1 2268 1420 fxp0 > > > > > > but tcpdump shows: > > > > > > 17:21:43.497275 63.xxx.224.154.80 > 10.4.1.134.2314: . 1:1461(1460) ack > > 248 win 17520 (DF) > > 17:21:51.497212 63.xxx.224.154.80 > 10.4.1.134.2314: . 1:1461(1460) ack > > 248 win 17520 (DF) > > 17:22:07.497065 63.xxx.224.154.80 > 10.4.1.134.2314: . 1:1461(1460) ack > > 248 win 17520 (DF) > > > > > > obviosly the packet isn't making it back to the client as it's too big. > > any ideas? I don't see any bug reports on it. We believe the same > > situation exsits with a 4.6 server but I haven't checked that thorougly > > enough yet. > > It's most likely a firewall or router filter, that block the > ICMP messages coming back to your server. > > /Jesper > > -- > Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 > Senior network engineer @ AS3292, TDC Tele Danmark > > One Unix to rule them all, One Resolver to find them, > One IP to bring them all and in the zone to bind them. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 16:40:14 2002 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 2530537B401; Mon, 19 Aug 2002 16:40:09 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 943AC43E6E; Mon, 19 Aug 2002 16:40:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020819234008.VPVG1746.rwcrmhc51.attbi.com@InterJet.elischer.org>; Mon, 19 Aug 2002 23:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA48448; Mon, 19 Aug 2002 16:20:38 -0700 (PDT) Date: Mon, 19 Aug 2002 16:20:37 -0700 (PDT) From: Julian Elischer To: Steve Francis Cc: Jesper Skriver , Jeff Behl , net@freebsd.org Subject: Re: MTU not working? In-Reply-To: <3D617842.4020304@expertcity.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 19 Aug 2002, Steve Francis wrote: > Allow me to respond for Jeff (we work at same place, and have both been > looking this issue) > > ICMP's being blocked are the most common explanation for this - but > this is not the case here. > > tcpdump run on the server system shows the ICMP fragmention required - > DF bit set messages being received, and - the irrefutable proof that it > is not an ICMP filtering issue -the FreeBSD system DOES lower the MTU > for that host's cloned route to the value specified in the ICMP (1420 > in the snippet below). New packets are segmented to sizes <= the new > MTU, but it continues resend the original packet over and over, in the > original 1500 byte size. > > So I still say FreeBSD has broken pMTU-D code. > > This is reproducible at will, so we can collect whatever info anyone > wants. > > Yes tcp needs to forget it ever sent that data, and refactor the entire transmit window. I'd agree this is a bug if it's reproducible by others too. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 17:45:10 2002 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 4FDF137B400 for ; Mon, 19 Aug 2002 17:45:03 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABEE143E75 for ; Mon, 19 Aug 2002 17:45:02 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id RAA80180; Mon, 19 Aug 2002 17:44:54 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g7K0gWc92123; Mon, 19 Aug 2002 17:42:32 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200208200042.g7K0gWc92123@arch20m.dellroad.org> Subject: Re: Inconsistent connections when using WinXP and MPD 3.8 In-Reply-To: <3D5C90B4.9030705@blah.com> "from Krusty at Aug 15, 2002 10:42:12 pm" To: Krusty Date: Mon, 19 Aug 2002 17:42:32 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Krusty writes: > [pptp0] LCP: SendConfigReq #11 > ACFCOMP > PROTOCOMP > MRU 1500 > MAGICNUM 0217860f > AUTHPROTO CHAP MSOFTv2 > pptp0-0: ignoring SetLinkInfo > [pptp0] LCP: SendConfigReq #12 > ACFCOMP > PROTOCOMP > MRU 1500 > MAGICNUM 0217860f > AUTHPROTO CHAP MSOFTv2 > [pptp0] LCP: SendConfigReq #13 > ACFCOMP > PROTOCOMP > MRU 1500 > MAGICNUM 0217860f > AUTHPROTO CHAP MSOFTv2 > [pptp0] LCP: SendConfigReq #14 > ACFCOMP > PROTOCOMP > MRU 1500 > MAGICNUM 0217860f > AUTHPROTO CHAP MSOFTv2 What you're seeing is MPD doing all the transmitting and never receiving any PPP frames from the peer. Most likely you have a firewall in there somewhere blocking GRE packets (IP protocol #47). -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 18: 0: 6 2002 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 BA7B637B400; Mon, 19 Aug 2002 18:00:03 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23E9D43E42; Mon, 19 Aug 2002 18:00:03 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id RAA80237; Mon, 19 Aug 2002 17:47:49 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g7K0jRN92144; Mon, 19 Aug 2002 17:45:27 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200208200045.g7K0jRN92144@arch20m.dellroad.org> Subject: Re: MTU not working? In-Reply-To: "from Julian Elischer at Aug 19, 2002 04:20:37 pm" To: Julian Elischer Date: Mon, 19 Aug 2002 17:45:27 -0700 (PDT) Cc: Steve Francis , Jesper Skriver , Jeff Behl , net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian Elischer writes: > > This is reproducible at will, so we can collect whatever info anyone > > wants. > > Yes > tcp needs to forget it ever sent that data, and refactor the entire > transmit window. > > I'd agree this is a bug if it's reproducible by others too. "Me too"... I've seen this as well... FreeBSD simply ignoring the MTU on an interface and sending 1500 byte packets anyway... This was on a -stable'ish machine of some sort (don't remember). Could it have something to do with IPSec? That may have been going. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 18:36:40 2002 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 4EFA537B400 for ; Mon, 19 Aug 2002 18:36:35 -0700 (PDT) Received: from web21410.mail.yahoo.com (web21410.mail.yahoo.com [216.136.232.85]) by mx1.FreeBSD.org (Postfix) with SMTP id 1075743E42 for ; Mon, 19 Aug 2002 18:36:35 -0700 (PDT) (envelope-from zopewiz@yahoo.com) Message-ID: <20020820013634.3113.qmail@web21410.mail.yahoo.com> Received: from [63.170.174.190] by web21410.mail.yahoo.com via HTTP; Mon, 19 Aug 2002 18:36:34 PDT Date: Mon, 19 Aug 2002 18:36:34 -0700 (PDT) From: Carlos Carnero Subject: Re: Bandwidth throttling with dummynet(4) To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <20020819154141.A41050@iguana.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, > dummynet pipes use timers heavily, and i suspect > that the timer granularity in vmware might not be > as good as you would want yes, you're right. I changed some thing though: increased HZ in the kernel config from 1000 to 1500; and currently I'm running the virtual machine at a higher priority. Luckily I have a very fast host with lots of RAM. I did the timing (delay) checks and yes, it improved to a point that "almost" is where I want it to be (less than 5% dev :) > Also, 5Kbytes/s is a very low bandwidth, which > coupled with 50 queue slots (~75Kbytes with large > packets) will result in very large RTTs which could > in turn trigger useless retransmissions and > timeouts. I'll play more with the slots, but those speeds (~ 5KByte/s) are the ones that the real thing will use. I'm building a router for a friend that has to share a 256KBit/s link among 100 people :o I know that VMware is not exactly the best thing to test dummynet, but right now I have no other choice. It's an experience anyway. > cheers > luigi Thanks a lot, Carlos. > On Mon, Aug 19, 2002 at 01:33:23PM -0700, Carlos > Carnero wrote: > > Hi, > > > > I have a "lab" here where I'm testing (and > learning) > > traffic shaping with dummynet(4). I have a Windows > XP > > host computer and a couple of VMware virtual > > computers: one running FreeBSD 4.5-RELEASE-p18, > with > > two virtual Ethernet adapters and other running > NetBSD > > 1.5.2 with one adapter. My FreeBSD "box" is the > > router/gateway for the NetBSD box, providing > > firewalling and NAT. Pretty much a standard setup, > and > > it works OK (you should see the double NATting ;) > > > > Anyway, I have compiled into the kernel both IP > Filter > > and FreeBSD's own ipfw, with the purpose of > traffic > > shaping/bandwidth throttling. But the numbers I > get > > are not what I expect. For instance, my ipfw rules > are > > like: > > > > pipe 1000 config bw 5KByte/s queue 50 > > pipe 1001 config bw 5KByte/s queue 50 > > > > add 50000 pipe 1000 tcp from 192.168.250.3/32 to > any > > add 50001 pipe 1001 tcp from any to > 192.168.250.3/32 > > > > (192.168.250.3 being the NetBSD "box") But when I > > transfer a file using FTP from the Windows host I > get > > _almost_ 1 KByte. Note that I remove the pipes > speeds > > reach ~800-900 KByte/s, almost saturating the > > "virtual" Ethernet interfaces. Changing the pipe > > bandwidth to, say 25KByte/s in both pipes yield an > FTP > > speed of ~5-6 KByte/s. Is this OK or FTP is that > > inefficient? What other tests can I run to check > the > > bandwidth _not_ using FTP? > > > > IP Filter's ruleset is currently set to pass > > everything as quickly as it can :) > > > > Thanks a lot, > > Carlos. > > > > PS. Posting from Yahoo! until I solve some reverse > DNS > > bugs I inherited :| > > > > __________________________________________________ > > Do You Yahoo!? > > HotJobs - Search Thousands of New Jobs > > http://www.hotjobs.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 19 23:40:43 2002 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 6933A37B400 for ; Mon, 19 Aug 2002 23:40:38 -0700 (PDT) Received: from consult-scs.com (vpn.consult-scs.com [216.218.207.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1481C43E65 for ; Mon, 19 Aug 2002 23:40:38 -0700 (PDT) (envelope-from vulture@consult-scs.com) Received: from consult-scs.com (bigv.netvulture.com [192.168.2.2]) (authenticated bits=0) by consult-scs.com (8.12.3/8.12.3) with ESMTP id g7K6guV1027829 for ; Mon, 19 Aug 2002 23:42:56 -0700 (PDT) Message-ID: <3D61E468.3050308@consult-scs.com> Date: Mon, 19 Aug 2002 23:40:40 -0700 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: IPSEC IPv4 Tunnel Problem Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I just upgraded my firewall from 4.5-RELEASE to 4.6.2-RELEASE Now my ipsec implementation no longer works. I have multiple tunnels from my internal lan to other internal lans The IPSEC is working for encoding packets from my lan to the remote lans and I can see the encoded packets coming back in my external interface using tcpdump. But after that the packets seem to disappear. Any help would be great - Thanks Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 0:11:34 2002 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 0F8B437B400 for ; Tue, 20 Aug 2002 00:11:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 858BD43E75 for ; Tue, 20 Aug 2002 00:11:28 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (c1-vpn2.isi.edu [128.9.176.28]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g7K7BRU16896; Tue, 20 Aug 2002 00:11:27 -0700 (PDT) Message-ID: <3D61EB97.5090306@isi.edu> Date: Tue, 20 Aug 2002 00:11:19 -0700 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Feally Cc: freebsd-net@freebsd.org Subject: Re: IPSEC IPv4 Tunnel Problem References: <3D61E468.3050308@consult-scs.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090100050701000201070701" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms090100050701000201070701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jonathan Feally wrote: > The IPSEC is working for encoding packets from my lan to the remote lans > and I can see the encoded packets coming back in my external interface > using tcpdump. But after that the packets seem to disappear. Could you describe your configuration a bit more, e.g. topology, setkey, ifconfig, netstat -r, netstat -s output? It's hard to pinpoint specifics without more detailed information. Lars -- Lars Eggert USC Information Sciences Institute --------------ms090100050701000201070701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDgyMDA3MTEyMFowIwYJKoZIhvcNAQkEMRYEFK1izzv+ejyq zlIH2+KUscD3FTV0MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYBWeQc2qrRvollPBOKR87iFKNnEqgZI2dLHchEM9+X20QjX 4WuWEZBgGDNlkM//TM3Zc7l+NSnYVnFA9WpZ9I+XHpdsQ8ViMMtht6nc+W3893oy7wHsKH/a QFByq1XNh3LfH0BbZsdMM4HuFSZWm8IeN+pYjnLKSmSxMFCZJ5D1+AAAAAAAAA== --------------ms090100050701000201070701-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 0:38:22 2002 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 3D4B437B405 for ; Tue, 20 Aug 2002 00:38:19 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D24843E6E for ; Tue, 20 Aug 2002 00:38:18 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7K7cHIb044119; Tue, 20 Aug 2002 00:38:17 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7K7cG8G044118; Tue, 20 Aug 2002 00:38:16 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Aug 2002 00:38:16 -0700 From: Luigi Rizzo To: Carlos Carnero Cc: freebsd-net@FreeBSD.ORG Subject: Re: Bandwidth throttling with dummynet(4) Message-ID: <20020820003816.A44103@iguana.icir.org> References: <20020819154141.A41050@iguana.icir.org> <20020820013634.3113.qmail@web21410.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020820013634.3113.qmail@web21410.mail.yahoo.com>; from zopewiz@yahoo.com on Mon, Aug 19, 2002 at 06:36:34PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Aug 19, 2002 at 06:36:34PM -0700, Carlos Carnero wrote: > Hello, > > > dummynet pipes use timers heavily, and i suspect > > that the timer granularity in vmware might not be > > as good as you would want > > yes, you're right. I changed some thing though: > increased HZ in the kernel config from 1000 to 1500; > and currently I'm running the virtual machine at a > higher priority. Luckily I have a very fast host with > lots of RAM. 1500 vs 1000 won't help much -- events will be scheduled with the host system's timer granularity, which might well be low (100-128 or so for NT). Secondly, you are running two virtual machines, so i believe they will compete for resources causing the timing to be flaky. Anyways, on real boxes dummynet does work as expected at those rates. cheers luigi > > I'll play more with the slots, but those speeds (~ > 5KByte/s) are the ones that the real thing will use. > I'm building a router for a friend that has to share a > 256KBit/s link among 100 people :o > > I know that VMware is not exactly the best thing to > test dummynet, but right now I have no other choice. > It's an experience anyway. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 0:54:32 2002 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 B073137B400 for ; Tue, 20 Aug 2002 00:54:24 -0700 (PDT) Received: from pipenetworks.com (cartman.pipenetworks.com [202.4.251.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1408A43E75 for ; Tue, 20 Aug 2002 00:54:23 -0700 (PDT) (envelope-from steve@pipenetworks.com) Received: (from root@localhost) by pipenetworks.com (8.11.2/8.11.2) id g7K7rEe19662; Tue, 20 Aug 2002 17:53:14 +1000 From: Steve Baxter Received: from internal.pipenetworks.com (internal.pipenetworks.com [10.10.10.1]) by pipenetworks.com (8.11.2/8.11.2) with ESMTP id g7K7rD619631; Tue, 20 Aug 2002 17:53:13 +1000 Received: from internal (internal [10.10.10.1]) by internal.pipenetworks.com (8.11.2/8.11.2) with ESMTP id g7K7uxd19983; Tue, 20 Aug 2002 17:56:59 +1000 Date: Tue, 20 Aug 2002 17:56:59 +1000 (EST) To: , Subject: FreeBSD, netgraph, vtun, bridging and other tall tales Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-scanner: scanned by Inflex 1.0.12.3 - (http://pldaniels.com/inflex/) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [apologies, I cross posted this to the freebsd networking list as well] Hello, I am using vtun for bridging Ethernet using FreeBSD 4.5-RELEASE, vtun2.4 as distributed in the FreeBSD ports. I am presently using the software along with the script supplied with Netgrpaph in FreeBSD - /usr/share/examples/netgraph/ether.bridge IP NETWORK _-----------_ / \ / \_ / \ / \ +-----------+ +-----------+ | VTUN BOX 1| | VTUN BOX 2| +-----------+ +-----------+ | | | | | | | | | | | | | | LAN | LAN I run a vtun tunnel between box 1 and box two and it works very very well :-). Each box has two ethernet cards, one for the IP network and one for the LAN. Each box has a single bridge set up that bridges the tap device and the LAN facing Ethernet card. What I was wondering is it possible to do the following : |LAN | | +-----------+ ____/| VTUN BOX 3| ______/ +-----------+ ____/ IP NETWORK _-----------_ / \ / \_ / \ / \ +-----------+ +-----------+ | VTUN BOX 1| | VTUN BOX 2| +-----------+ +-----------+ | | | | | | | | | | | | | | LAN | LAN We want to be able to bridge in box 3 three to vtun box 2. Has anybody tried this where on vtun box 2 we would have to have a second netgraph bridge that shared a physical interface with another netgraph bridge ? 1st netgraph bridge: ==================== tap0 rl0 2nd netgraph bridge: =================== tap1 rl0 Will this produce any issues with netgraph or vtun that anybody is aware of ? -- Stephen Baxter Director - PIPE Networks phone : 07 3220 1100/ 0417 818 695 fax : 07 3220 1800 ______________________________________ This e-mail is intended for its recipients only. If this e-mail has been sent to you in error, please delete it and notify the sender by reply e-mail. The information contained in this message and/or its attachments may be confidential. Please do not read, save, forward, disclose, or copy the contents of this email. Any views expressed in this Communication are those of the individual sender, except where the sender specifically states them to be the views of PIPE Networks/IX Services Australia Pty Ltd. Except as required at law, PIPE Networks/IX Services Australia Pty Ltd does not represent, warrant and/or guarantee that the integrity of this communication has been maintained nor that the communication is free of errors, virus, interception or inference. If any quotations for work are included in this email then unless otherwsie stated the prices do not include GST, the quotation is only valid for 30 days unless otherwise stated, Megabyte means 1,000,000 bytes, 1 kilobyte means 1,000 bytes and kilobit means 1,000 bits. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 2:17: 0 2002 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 5CFB437B400 for ; Tue, 20 Aug 2002 02:16:57 -0700 (PDT) Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id C117043E42 for ; Tue, 20 Aug 2002 02:16:56 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 4A35D38531; Tue, 20 Aug 2002 11:16:55 +0200 (CEST) Date: Tue, 20 Aug 2002 11:16:55 +0200 From: Jesper Skriver To: Julian Elischer Cc: Steve Francis , Jeff Behl , net@freebsd.org Subject: Re: MTU not working? Message-ID: <20020820091655.GB76162@skriver.dk> References: <3D617842.4020304@expertcity.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Aug 19, 2002 at 04:20:37PM -0700, Julian Elischer wrote: > > > On Mon, 19 Aug 2002, Steve Francis wrote: > > > Allow me to respond for Jeff (we work at same place, and have both been > > looking this issue) > > > > ICMP's being blocked are the most common explanation for this - but > > this is not the case here. > > > > tcpdump run on the server system shows the ICMP fragmention required - > > DF bit set messages being received, and - the irrefutable proof that it > > is not an ICMP filtering issue -the FreeBSD system DOES lower the MTU > > for that host's cloned route to the value specified in the ICMP (1420 > > in the snippet below). New packets are segmented to sizes <= the new > > MTU, but it continues resend the original packet over and over, in the > > original 1500 byte size. > > > > So I still say FreeBSD has broken pMTU-D code. > > > > This is reproducible at will, so we can collect whatever info anyone > > wants. > > Yes > tcp needs to forget it ever sent that data, and refactor the entire > transmit window. Doesn't we do that allready ? src/sys/netinet/tcp_subr.c around line 1416 in tcp_mtudisc() we have a tp->snd_nxt = tp->snd_una; > I'd agree this is a bug if it's reproducible by others too. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Senior network engineer @ AS3292, TDC Tele Danmark One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 5:42:15 2002 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 9A80537B400; Tue, 20 Aug 2002 05:42:07 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A80543E4A; Tue, 20 Aug 2002 05:42:07 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7KCg6Ib046009; Tue, 20 Aug 2002 05:42:06 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7KCg6Au046008; Tue, 20 Aug 2002 05:42:06 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Aug 2002 05:42:06 -0700 From: Luigi Rizzo To: ipfw@freebsd.org Subject: ambiguity of filter expressions (tcpdump and ipfw2) Message-ID: <20020820054206.A45915@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [Bcc to -net, but please keep the discussion on -ipfw] Hi, we have the following issue (both in tcpdump and ipfw2): when you specify a match pattern that is not applicable to the packet being processed (e.g. "src-port 80" on an ICMP packet), the match will simply fail and the packet will not be selected. However, when you put in a "not" operator (as in "not src-port 80") there are really two ways to implement the operation: 1. the basic match fails, so its negation will succeed. This is the way tcpdump operates (try a "tcpdump not port 80" and see how it matches all sort of non-tcp traffic), and also ipfw2 does the same thing for consistency with tcpdump (that is the official excuse -- in reality, i did not think of the issue in the first place, maybe the same happened to the tcpdump/libpcap authors). 2. The match operator is "not applicable" so both the direct form and the negation will fail. Now, using the first approach in a firewall might be somewhat dangerous, in the sense that, yes, the rule does exactly what you write, but that might not be what you really want. E.g. consider ipfw add allow not src-port 80 which could be meant to pass all tcp traffic not coming from a web server -- however, this rule would also leak all non-tcp and non-udp packets. The correct way to express the rule is of course to to include a "proto tcp" match pattern, but sometimes this can escape. The second approach would prevent such mistakes, though it might be non-obvious to people used to tcpdump syntax (although, i suspect "not" operators are not widely used there either). So, what do we do ? Implementing the second behavior requires rather trivial changes in the kernel, and no changes in the kernel-user interface or in the userland programs. ipfw2 syntax is not yet widely used so changing between one mode and the other would not give too much trouble to people. It might even be possible to provide a sysctl variable to choose between the two behaviours, though i'd rather not do that because it has a little bit of impact on run-time performance, and also because having yet another tunable increases confusion. I'd be inclined to leave things as they are, surely remark the issue in the manpage, and maybe make ipfw2 print out a "Warning" message about the use of a potentially unsafe match pattern, same as the compiler does when you use a "gets". Opinions anyone ? cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 8:24:15 2002 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 8C5DF37B400 for ; Tue, 20 Aug 2002 08:24:12 -0700 (PDT) Received: from csmail.commserv.ucsb.edu (cspdc.commserv.ucsb.edu [128.111.251.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 294AD43E70 for ; Tue, 20 Aug 2002 08:24:12 -0700 (PDT) (envelope-from steve@expertcity.com) Received: from expertcity.com ([68.6.35.15]) by csmail.commserv.ucsb.edu (Netscape Messaging Server 3.62) with ESMTP id 114; Tue, 20 Aug 2002 08:24:10 -0700 Message-ID: <3D625F51.1080704@expertcity.com> Date: Tue, 20 Aug 2002 08:25:05 -0700 From: Steve Francis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: net@FreeBSD.ORG Cc: Steve Francis Subject: Re: MTU not working? References: <200208200045.g7K0jRN92144@arch20m.dellroad.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In my case, IPSec is running on the routers, hence the tunnel MTU of 1420 bytes (allowing for GRE and IPSec in transport mode, with the particular transforms we run.) IPSec is not running on the FreeBSD machines. Archie Cobbs wrote: >Julian Elischer writes: > >>>This is reproducible at will, so we can collect whatever info anyone >>>wants. >>> >>Yes >>tcp needs to forget it ever sent that data, and refactor the entire >>transmit window. >> >>I'd agree this is a bug if it's reproducible by others too. >> > >"Me too"... > >I've seen this as well... FreeBSD simply ignoring the MTU >on an interface and sending 1500 byte packets anyway... > >This was on a -stable'ish machine of some sort (don't remember). >Could it have something to do with IPSec? That may have been going. > >-Archie > >__________________________________________________________________________ >Archie Cobbs * Packet Design * http://www.packetdesign.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 9:20:10 2002 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 5163537B400 for ; Tue, 20 Aug 2002 09:20:07 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E6AB43E4A for ; Tue, 20 Aug 2002 09:20:06 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id MAA14086 for ; Tue, 20 Aug 2002 12:20:05 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g7KGJZM27239; Tue, 20 Aug 2002 12:19:35 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15714.27671.533860.408996@grasshopper.cs.duke.edu> Date: Tue, 20 Aug 2002 12:19:35 -0400 (EDT) To: freebsd-net@freebsd.org Subject: m_getcl and end-to-end performance X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The current code for stocking the mcl_pool is located in m_freem(). This is fine for forwarding, however the most commonly used receive path in soreceive() frees mbufs via m_free() (uipc_socket.c:868 in today's -stable). This means that on a machine which is an endpoint, rather than a forwarder, the mcl_pool will spend much of its time empty. Is there any reason why the mcl_pool is not stocked in m_free() rather than m_freem()? Speaking of m_free().. It looks like m_free() is the only consumer of the MFREE() macro, so why is the MFREE() macro still there? Thanks, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 9:39:43 2002 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 B038537B400 for ; Tue, 20 Aug 2002 09:39:41 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ED9E43E72 for ; Tue, 20 Aug 2002 09:39:41 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7KGddIb048746; Tue, 20 Aug 2002 09:39:39 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7KGddf0048745; Tue, 20 Aug 2002 09:39:39 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Aug 2002 09:39:39 -0700 From: Luigi Rizzo To: Andrew Gallatin Cc: freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance Message-ID: <20020820093939.B48541@iguana.icir.org> References: <15714.27671.533860.408996@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15714.27671.533860.408996@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Tue, Aug 20, 2002 at 12:19:35PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Aug 20, 2002 at 12:19:35PM -0400, Andrew Gallatin wrote: > > The current code for stocking the mcl_pool is located in m_freem(). > This is fine for forwarding, however the most commonly used receive > path in soreceive() frees mbufs via m_free() (uipc_socket.c:868 in > today's -stable). This means that on a machine which is an endpoint, > rather than a forwarder, the mcl_pool will spend much of its time > empty. > > Is there any reason why the mcl_pool is not stocked in m_free() > rather than m_freem()? a couple, both of which are probably rather weak: #1 my (mis)assumption that m_free() was mostly unused; #2 the assumption (this one possibly more correct) that the mbufs freed by the socket layer do not have M_PKTHDR set, so when it comes to initialize the mcl_pool from these ones you have more work to do. My impression is that it might be useful to do the following: + expand MFREE() in the body of m_freem() thus saving the extra function call at each iteration of m_freem() (which is a cost paid by all drivers); + rewrite m_free() in terms of m_freem(), either as a function or maybe a macro (for critical paths -- not sure how often it is used in critical paths); now if you have patches i'll be happy to have a look at them. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 10:48:52 2002 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 2393037B400 for ; Tue, 20 Aug 2002 10:48:49 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9302643E4A for ; Tue, 20 Aug 2002 10:48:48 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g7KHlwO26938 for freebsd-net@freebsd.org; Tue, 20 Aug 2002 13:47:58 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Tue, 20 Aug 2002 13:47:58 -0400 From: Bosko Milekic To: freebsd-net@freebsd.org Subject: [HEADS UP: PLEASE TEST] teaching net drivers about m_getcl() Message-ID: <20020820134758.A26879@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Recently, m_getcl(how, type, flags) has been introduced to both HEAD and RELENG_4. It does an all-or-nothing mbuf+cluster allocation in one shot. Both the HEAD and RELENG_4 implementations are optimized in their own way (the implementations are totally different but the interface is identical). Due to the optimizations, it is worthwhile to use the new interface for grouped all-or-nothing mbuf+cluster allocations whenever possible. I have started to teach a bunch of the net drivers sitting in src/sys/dev about this new interface. A patch is up here: http://people.freebsd.org/~bmilekic/code/net.diff The patch is to -CURRENT, although bits of it may very cleanly apply to -STABLE as well. I need both -STABLE and -CURRENT testers (of the SMP and non-SMP variety). It's very important that people who use the drivers that the patch affects test this stuff. PLEASE APPLY THIS AND TEST if you use one or more of the following: - dev/an - dev/ar - dev/awi - dev/bge - dev/cm - dev/cs - dev/ed - dev/em - dev/en - dev/ep - dev/fe - dev/fxp - dev/gem - dev/gx - dev/lmc - dev/lnc - dev/musycc - dev/my - dev/ray - dev/sbni - dev/sn - dev/sr - dev/tx - dev/txp - dev/usb/aue - dev/usb/cue - dev/usb/kue - dev/wi - dev/xe If you use any of that code, feel free to take the relevant bits from the patch above and apply them. Let me know how things are going, specifically if everything is fine. You can send me Email in private to bmilekic@FreeBSD.org with the topic: "m_getcl() RESULTS" Please include: -CURRENT or -STABLE (the patches are only guaranteed to apply to -CURRENT), whether or not you're running a SMP kernel, what device this is for (from the list above), and any other info/comments you have. This would be very appreciated. Thanks. Regards, -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 10:57: 1 2002 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 7481E37B400 for ; Tue, 20 Aug 2002 10:56:58 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDF7243E65 for ; Tue, 20 Aug 2002 10:56:57 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id NAA17374; Tue, 20 Aug 2002 13:56:56 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g7KHuQP27331; Tue, 20 Aug 2002 13:56:26 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15714.33482.820805.887447@grasshopper.cs.duke.edu> Date: Tue, 20 Aug 2002 13:56:26 -0400 (EDT) To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance In-Reply-To: <20020820093939.B48541@iguana.icir.org> References: <15714.27671.533860.408996@grasshopper.cs.duke.edu> <20020820093939.B48541@iguana.icir.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo writes: > On Tue, Aug 20, 2002 at 12:19:35PM -0400, Andrew Gallatin wrote: > > > > The current code for stocking the mcl_pool is located in m_freem(). > > This is fine for forwarding, however the most commonly used receive > > path in soreceive() frees mbufs via m_free() (uipc_socket.c:868 in > > today's -stable). This means that on a machine which is an endpoint, > > rather than a forwarder, the mcl_pool will spend much of its time > > empty. > > > > Is there any reason why the mcl_pool is not stocked in m_free() > > rather than m_freem()? > > a couple, both of which are probably rather weak: > > #1 my (mis)assumption that m_free() was mostly unused; > #2 the assumption (this one possibly more correct) that the mbufs > freed by the socket layer do not have M_PKTHDR set, so when it > comes to initialize the mcl_pool from these ones you have more > work to do. At least on the recv side, M_PKTHDR will still be set by the time that m_free{,m}() is called. Speaking of M_PKTHDR .. why is the pool optimization restricted to pkthdr mbufs? A legitimate way to allocate a jumbo frame is to allocate 4 clusters, only the first of which will have M_PKTHDR set. It seems like not limiting it to M_PKTHDR would be just as efficient, as you could avoid a compare in the critical path at the cost of changing mp->m_flags = M_PKTHDR|M_EXT to mp->m_flags = flags|M_EXT; On the free side, you add back the compare, though.. > My impression is that it might be useful to do the following: > + expand MFREE() in the body of m_freem() thus saving the extra > function call at each iteration of m_freem() (which is a cost > paid by all drivers); This makes a lot of sense. > + rewrite m_free() in terms of m_freem(), either as a function or > maybe a macro (for critical paths -- not sure how often it is > used in critical paths); I'm missing something here. Isn't m_freem() implemented in terms of m_free() now? > now if you have patches i'll be happy to have a look at them. Not yet.. I'm still fighting the pkthdr issue before I see how much (or even if) it helps.. BTW, I'm glad somebody else still cares about performance ;) Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 11:40:16 2002 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 9C6E037B401 for ; Tue, 20 Aug 2002 11:40:08 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09A8143E4A for ; Tue, 20 Aug 2002 11:40:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020820184007.SRFC13899.sccrmhc02.attbi.com@InterJet.elischer.org>; Tue, 20 Aug 2002 18:40:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA52299; Tue, 20 Aug 2002 11:29:12 -0700 (PDT) Date: Tue, 20 Aug 2002 11:29:11 -0700 (PDT) From: Julian Elischer To: Steve Baxter Cc: vtun-users-admin@lists.sourceforge.net, freebsd-net@freebsd.org Subject: Re: FreeBSD, netgraph, vtun, bridging and other tall tales In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 20 Aug 2002, Steve Baxter wrote: > > [apologies, I cross posted this to the freebsd networking list as well] > > Hello, > I run a vtun tunnel between box 1 and box two and it works very very well > :-). Each box has two ethernet cards, one for the IP network and one for > the LAN. Each box has a single bridge set up that bridges the tap device > and the LAN facing Ethernet card. > > What I was wondering is it possible to do the following : > I don't know about vtun, but you could do this all entirely using netgraph as well. you would hook the netgraph bridge to netgraph ksocket udp nodes and use ipsec to encrupt (transport mode) the intersite traffic. > > |LAN > | > | > +-----------+ > ____/| VTUN BOX 3| > ______/ +-----------+ > ____/ > IP NETWORK > _-----------_ > / \ > / \_ > / \ > / \ > +-----------+ +-----------+ > | VTUN BOX 1| | VTUN BOX 2| > +-----------+ +-----------+ > | | > | | > | | > | | > | | > | | > | | > LAN | > LAN > > > We want to be able to bridge in box 3 three to vtun box 2. ONLY to box 2? what abut box 1? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 12:17:59 2002 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 CE40437B423 for ; Tue, 20 Aug 2002 12:17:28 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01A88441D4 for ; Tue, 20 Aug 2002 12:00:36 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020820190019.IHTZ1746.rwcrmhc51.attbi.com@InterJet.elischer.org>; Tue, 20 Aug 2002 19:00:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA52369; Tue, 20 Aug 2002 11:46:25 -0700 (PDT) Date: Tue, 20 Aug 2002 11:46:24 -0700 (PDT) From: Julian Elischer To: Jesper Skriver Cc: Steve Francis , Jeff Behl , net@freebsd.org Subject: Re: MTU not working? In-Reply-To: <20020820091655.GB76162@skriver.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 20 Aug 2002, Jesper Skriver wrote: > > Doesn't we do that allready ? > > src/sys/netinet/tcp_subr.c > > around line 1416 in tcp_mtudisc() we have a > > tp->snd_nxt = tp->snd_una; > however if the packet that emerges is still large, then obviously something is stopping this from being effective.. hence the description "bug" :-) Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 12:37:17 2002 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 A0E7037B400 for ; Tue, 20 Aug 2002 12:37:11 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6C9843E81 for ; Tue, 20 Aug 2002 12:37:09 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id PAA21299; Tue, 20 Aug 2002 15:37:08 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g7KJacU27427; Tue, 20 Aug 2002 15:36:38 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15714.39494.661931.882244@grasshopper.cs.duke.edu> Date: Tue, 20 Aug 2002 15:36:38 -0400 (EDT) To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance In-Reply-To: <20020820093939.B48541@iguana.icir.org> References: <15714.27671.533860.408996@grasshopper.cs.duke.edu> <20020820093939.B48541@iguana.icir.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo writes: > > now if you have patches i'll be happy to have a look at them. Here's what I'm running with now. It removes the M_PKTHDR requirement, allowing me to use multiple m_getcl()'s to stock jumbo frames. The uicp_socket.c is just a cheesey hack to soreceive() so as to pretend we do mcl_pool restocking in m_free(). For a netperf UDP_STREAM, I see ~1,000 to ~2,000 packets/sec increase in throughput for sizes 256 through 2K. For large (8K) I see a ~20-30Mb/sec increase (but that's only a few hundred pkts/sec). Drew Index: uipc_mbuf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_mbuf.c,v retrieving revision 1.51.2.20 diff -u -r1.51.2.20 uipc_mbuf.c --- uipc_mbuf.c 12 Aug 2002 22:09:12 -0000 1.51.2.20 +++ uipc_mbuf.c 20 Aug 2002 19:08:38 -0000 @@ -569,20 +569,22 @@ int s = splimp(); struct mbuf *mp; + if (type == MT_DATA && mcl_pool) { + mp = mcl_pool; + mcl_pool = mp->m_nextpkt; + mcl_pool_now--; + splx(s); + mp->m_nextpkt = NULL; + mp->m_data = mp->m_ext.ext_buf; + mp->m_flags = flags|M_EXT; + mp->m_pkthdr.rcvif = NULL; + mp->m_pkthdr.csum_flags = 0; + mp->m_pkthdr.aux = NULL; + return mp; + } + if (flags & M_PKTHDR) { - if (type == MT_DATA && mcl_pool) { - mp = mcl_pool; - mcl_pool = mp->m_nextpkt; - mcl_pool_now--; - splx(s); - mp->m_nextpkt = NULL; - mp->m_data = mp->m_ext.ext_buf; - mp->m_flags = M_PKTHDR|M_EXT; - mp->m_pkthdr.rcvif = NULL; - mp->m_pkthdr.csum_flags = 0; - return mp; - } else - MGETHDR(mp, how, type); + MGETHDR(mp, how, type); } else MGET(mp, how, type); if (mp) { @@ -704,32 +706,36 @@ m_freem(m) struct mbuf *m; { + struct mbuf *m_tmp; int s = splimp(); /* * Try to keep a small pool of mbuf+cluster for quick use in * device drivers. A good candidate is a M_PKTHDR buffer with - * only one cluster attached. Other mbufs, or those exceeding + * at least one cluster attached. Other mbufs, or those exceeding * the pool size, are just m_free'd in the usual way. * The following code makes sure that m_next, m_type, * m_pkthdr.aux and m_ext.* are properly initialized. * Other fields in the mbuf are initialized in m_getcl() * upon allocation. */ - if (mcl_pool_now < mcl_pool_max && m && m->m_next == NULL && - (m->m_flags & (M_PKTHDR|M_EXT)) == (M_PKTHDR|M_EXT) && + if (mcl_pool_now < mcl_pool_max && m && + (m->m_flags & M_EXT) == M_EXT && m->m_type == MT_DATA && M_EXT_WRITABLE(m) ) { - if (m->m_pkthdr.aux) { + m_tmp = m->m_next; + m->m_next = NULL; + if ((m->m_flags & M_PKTHDR) == M_PKTHDR && + m->m_pkthdr.aux) { m_freem(m->m_pkthdr.aux); - m->m_pkthdr.aux = NULL; } m->m_nextpkt = mcl_pool; mcl_pool = m; mcl_pool_now++; - } else { - while (m) - m = m_free(m); - } + m = m_tmp; + } + while (m) + m = m_free(m); + splx(s); } Index: uipc_socket.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.68.2.21 diff -u -r1.68.2.21 uipc_socket.c --- uipc_socket.c 1 May 2002 03:27:35 -0000 1.68.2.21 +++ uipc_socket.c 20 Aug 2002 16:14:06 -0000 @@ -865,7 +865,13 @@ so->so_rcv.sb_mb = m = m->m_next; *mp = (struct mbuf *)0; } else { - so->so_rcv.sb_mb = m = m_free(m); + struct mbuf *m_tmp; + + m_tmp = m->m_next; + m->m_next = NULL; +/* so->so_rcv.sb_mb = m = m_free(m);*/ + m_freem (m); + so->so_rcv.sb_mb = m = m_tmp; } if (m) m->m_nextpkt = nextrecord; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 12:45:28 2002 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 1281437B400 for ; Tue, 20 Aug 2002 12:45:25 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35C3A43E65 for ; Tue, 20 Aug 2002 12:45:24 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g7KJiG027810; Tue, 20 Aug 2002 15:44:16 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Tue, 20 Aug 2002 15:44:16 -0400 From: Bosko Milekic To: Andrew Gallatin Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance Message-ID: <20020820154416.A27782@unixdaemons.com> References: <15714.27671.533860.408996@grasshopper.cs.duke.edu> <20020820093939.B48541@iguana.icir.org> <15714.39494.661931.882244@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15714.39494.661931.882244@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Tue, Aug 20, 2002 at 03:36:38PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Aug 20, 2002 at 03:36:38PM -0400, Andrew Gallatin wrote: > > Luigi Rizzo writes: > > > > now if you have patches i'll be happy to have a look at them. > > Here's what I'm running with now. It removes the M_PKTHDR > requirement, allowing me to use multiple m_getcl()'s to stock jumbo > frames. I forgot about something in Luigi's original patch: Does this stuff make sure to only stock the pool with mbufs+clusters and not mbufs+any_other_external_buffer? This requirement seems to be necessary in m_freem() because otherwise you could be getting an mbuf+something_other_than_a_cluster from m_getcl(), which is _not_ what the function is supposed to do. > The uicp_socket.c is just a cheesey hack to soreceive() so as to > pretend we do mcl_pool restocking in m_free(). > > For a netperf UDP_STREAM, I see ~1,000 to ~2,000 packets/sec increase > in throughput for sizes 256 through 2K. For large (8K) I see a > ~20-30Mb/sec increase (but that's only a few hundred pkts/sec). > > Drew -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 12:51:21 2002 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 CEBAB37B400 for ; Tue, 20 Aug 2002 12:51:18 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB08C43E65 for ; Tue, 20 Aug 2002 12:51:17 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id PAA21737; Tue, 20 Aug 2002 15:51:16 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g7KJojb27447; Tue, 20 Aug 2002 15:50:45 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15714.40341.115512.786712@grasshopper.cs.duke.edu> Date: Tue, 20 Aug 2002 15:50:45 -0400 (EDT) To: Bosko Milekic Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance In-Reply-To: <20020820154416.A27782@unixdaemons.com> References: <15714.27671.533860.408996@grasshopper.cs.duke.edu> <20020820093939.B48541@iguana.icir.org> <15714.39494.661931.882244@grasshopper.cs.duke.edu> <20020820154416.A27782@unixdaemons.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bosko Milekic writes: > > On Tue, Aug 20, 2002 at 03:36:38PM -0400, Andrew Gallatin wrote: > > > > Luigi Rizzo writes: > > > > > > now if you have patches i'll be happy to have a look at them. > > > > Here's what I'm running with now. It removes the M_PKTHDR > > requirement, allowing me to use multiple m_getcl()'s to stock jumbo > > frames. > > I forgot about something in Luigi's original patch: > > Does this stuff make sure to only stock the pool with mbufs+clusters > and not mbufs+any_other_external_buffer? This requirement seems to be Yes, it checks that M_EXT_WRITABLE(m) is true before adding it to the pool. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 13: 0:18 2002 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 8D7EA37B409 for ; Tue, 20 Aug 2002 13:00:14 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE1C343E75 for ; Tue, 20 Aug 2002 13:00:13 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020820200013.MQMK1746.rwcrmhc51.attbi.com@InterJet.elischer.org>; Tue, 20 Aug 2002 20:00:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA52663; Tue, 20 Aug 2002 12:54:45 -0700 (PDT) Date: Tue, 20 Aug 2002 12:54:44 -0700 (PDT) From: Julian Elischer To: Andrew Gallatin Cc: Bosko Milekic , Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance In-Reply-To: <15714.40341.115512.786712@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 20 Aug 2002, Andrew Gallatin wrote: > > Bosko Milekic writes: > > > > On Tue, Aug 20, 2002 at 03:36:38PM -0400, Andrew Gallatin wrote: > > > > > > Luigi Rizzo writes: > > > > > > > > now if you have patches i'll be happy to have a look at them. > > > > > > Here's what I'm running with now. It removes the M_PKTHDR > > > requirement, allowing me to use multiple m_getcl()'s to stock jumbo > > > frames. > > > > I forgot about something in Luigi's original patch: > > > > Does this stuff make sure to only stock the pool with mbufs+clusters > > and not mbufs+any_other_external_buffer? This requirement seems to be > > Yes, it checks that M_EXT_WRITABLE(m) is true before adding it to the pool. Are only Cluster mbufs writable? > > Drew > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 13: 7:47 2002 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 9B6DD37B400 for ; Tue, 20 Aug 2002 13:07:45 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3EF543E3B for ; Tue, 20 Aug 2002 13:07:44 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id QAA22357; Tue, 20 Aug 2002 16:07:44 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g7KK7EY27464; Tue, 20 Aug 2002 16:07:14 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15714.41330.135614.44197@grasshopper.cs.duke.edu> Date: Tue, 20 Aug 2002 16:07:14 -0400 (EDT) To: Julian Elischer Cc: freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance In-Reply-To: References: <15714.40341.115512.786712@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian Elischer writes: > > Yes, it checks that M_EXT_WRITABLE(m) is true before adding it to the pool. > > Are only Cluster mbufs writable? Yes. At least in -stable: #define M_EXT_WRITABLE(m) \ ((m)->m_ext.ext_free == NULL && mclrefcnt[mtocl((m)->m_ext.ext_buf)] == 1) Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 13:30: 3 2002 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 53B9937B400 for ; Tue, 20 Aug 2002 13:29:59 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 007CB43E3B for ; Tue, 20 Aug 2002 13:29:59 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7KKTvIb050209; Tue, 20 Aug 2002 13:29:57 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7KKTv0o050208; Tue, 20 Aug 2002 13:29:57 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Aug 2002 13:29:57 -0700 From: Luigi Rizzo To: Andrew Gallatin Cc: freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance Message-ID: <20020820132957.B49141@iguana.icir.org> References: <15714.27671.533860.408996@grasshopper.cs.duke.edu> <20020820093939.B48541@iguana.icir.org> <15714.39494.661931.882244@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15714.39494.661931.882244@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Tue, Aug 20, 2002 at 03:36:38PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Aug 20, 2002 at 03:36:38PM -0400, Andrew Gallatin wrote: ... > Here's what I'm running with now. It removes the M_PKTHDR > requirement, allowing me to use multiple m_getcl()'s to stock jumbo > frames. ok... there is a minor overhead in initializing m_pkthdr fields for non-pkthdr buffers, but i guess checking the flags bit to possibly skip the block would cost about the same. > For a netperf UDP_STREAM, I see ~1,000 to ~2,000 packets/sec increase > in throughput for sizes 256 through 2K. For large (8K) I see a hmmm... that seems to be in the noise (i assume you are dealing with a fast machine), but probably because there is a lot of per-packet overhead in userland. In my experiments with routing of 64-byte packets i saw the throughput bumping up from 360kpps to over 400kpps on a fast box with Gig-E card, and about 2-3kpps (20 to 22-23kpps) on the soekris box. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 13:36:55 2002 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 565A837B400 for ; Tue, 20 Aug 2002 13:36:52 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 029AD43E42 for ; Tue, 20 Aug 2002 13:36:52 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7KKaoIb050275; Tue, 20 Aug 2002 13:36:50 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7KKao6T050274; Tue, 20 Aug 2002 13:36:50 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Aug 2002 13:36:50 -0700 From: Luigi Rizzo To: Andrew Gallatin Cc: freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance Message-ID: <20020820133650.C49141@iguana.icir.org> References: <15714.27671.533860.408996@grasshopper.cs.duke.edu> <20020820093939.B48541@iguana.icir.org> <15714.33482.820805.887447@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15714.33482.820805.887447@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Tue, Aug 20, 2002 at 01:56:26PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Aug 20, 2002 at 01:56:26PM -0400, Andrew Gallatin wrote: ... > > My impression is that it might be useful to do the following: > > + expand MFREE() in the body of m_freem() thus saving the extra > > function call at each iteration of m_freem() (which is a cost > > paid by all drivers); > > This makes a lot of sense. > > > + rewrite m_free() in terms of m_freem(), either as a function or > > maybe a macro (for critical paths -- not sure how often it is > > used in critical paths); > > I'm missing something here. Isn't m_freem() implemented in terms of > m_free() now? yes, but that costs you an extra function call per mbuf in m_freem(). Because m_free() is just "free only the first mbuf", in many places (where the chain is guaranteed to be one buffer) you can just interchange them. Not long ago i even fixed a few places were m_free() was erroneously used instead of m_freem(). I guess the only places where m_free() makes sense is in the socket stack when you get rid of part of the chain after a successful uiomove(), in which case you could just temporarily save the m_next field for the last mbuf you want to free, and call m_freem() only once. In the end this should also save time, and maybe remove the need of m_free() altogether. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 13:42:14 2002 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 5700837B400 for ; Tue, 20 Aug 2002 13:42:13 -0700 (PDT) Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id C21C543E70 for ; Tue, 20 Aug 2002 13:42:12 -0700 (PDT) (envelope-from michael.harbour@btopenworld.com) Received: from host62-7-91-3.in-addr.btopenworld.com ([62.7.91.3] helo=localhost) by tungsten.btinternet.com with esmtp (Exim 3.22 #8) id 17hFpK-0004KS-00 for freebsd-net@FreeBSD.org; Tue, 20 Aug 2002 21:42:11 +0100 Date: Tue, 20 Aug 2002 21:41:37 +0000 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: NFS request from unpermitted port From: michael harbour To: freebsd-net@FreeBSD.org Content-Transfer-Encoding: 7bit Message-Id: <9AEB13D4-B485-11D6-9D28-0030657B06A4@btopenworld.com> X-Mailer: Apple Mail (2.482) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hello i'm trying to set up NFS networking between an iMac with MacOSX (as the client) and FreeBSD on a laptop (as the server) as far as i know, i've got the necessary daemons running on both machines, but when i try to connect to BSD it says NFS request from unprivileged port (192.167.1.157:49156) is the client or the server at fault ? is 49156 a silly port ? should the server be configured to recognise the port ? if so, how do i do this stuff? cheers for any help mike harbour To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 13:44: 2 2002 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 DC15D37B400 for ; Tue, 20 Aug 2002 13:43:59 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3179043E42 for ; Tue, 20 Aug 2002 13:43:59 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id QAA23545; Tue, 20 Aug 2002 16:43:58 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g7KKhSj27495; Tue, 20 Aug 2002 16:43:28 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15714.43504.493596.791872@grasshopper.cs.duke.edu> Date: Tue, 20 Aug 2002 16:43:28 -0400 (EDT) To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance In-Reply-To: <20020820132957.B49141@iguana.icir.org> References: <15714.27671.533860.408996@grasshopper.cs.duke.edu> <20020820093939.B48541@iguana.icir.org> <15714.39494.661931.882244@grasshopper.cs.duke.edu> <20020820132957.B49141@iguana.icir.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo writes: > > > For a netperf UDP_STREAM, I see ~1,000 to ~2,000 packets/sec increase > > in throughput for sizes 256 through 2K. For large (8K) I see a > > hmmm... that seems to be in the noise (i assume you are dealing > with a fast machine), but probably because there is a lot of > per-packet overhead in userland. In my experiments with routing of > 64-byte packets i saw the throughput bumping up from 360kpps to > over 400kpps on a fast box with Gig-E card, and about 2-3kpps (20 > to 22-23kpps) on the soekris box. This an SMP kernel using interrupts, not POLLING. And using the "-stable" version of our driver, which does *very* heavyweight interrupt processing and does not do any interrupt coalescing. There's a lot of overhead here, and much of it is ours. All of the is fixed in our "-current" driver.. Anyway, things max out at ~65K pkts/sec, so a few thousand pkts/second is a little better than in the noise. For a driver with lower overhead (fxp), I see ~12K pkts/sec improvemnt again, SMP and not POLLING) from ~90Kpkts/sec -> to 102Kpkts/sec for minimally tiny packets. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 13:57:41 2002 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 1A01A37B400 for ; Tue, 20 Aug 2002 13:57:38 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id B739D43E4A for ; Tue, 20 Aug 2002 13:57:37 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7KKvaIb050447; Tue, 20 Aug 2002 13:57:36 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7KKvaHs050446; Tue, 20 Aug 2002 13:57:36 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Aug 2002 13:57:36 -0700 From: Luigi Rizzo To: Andrew Gallatin Cc: freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance Message-ID: <20020820135736.A50369@iguana.icir.org> References: <15714.27671.533860.408996@grasshopper.cs.duke.edu> <20020820093939.B48541@iguana.icir.org> <15714.39494.661931.882244@grasshopper.cs.duke.edu> <20020820132957.B49141@iguana.icir.org> <15714.43504.493596.791872@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15714.43504.493596.791872@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Tue, Aug 20, 2002 at 04:43:28PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Aug 20, 2002 at 04:43:28PM -0400, Andrew Gallatin wrote: ... > For a driver with lower overhead (fxp), I see ~12K pkts/sec improvemnt > again, SMP and not POLLING) from ~90Kpkts/sec -> to 102Kpkts/sec for > minimally tiny packets. which gets you close to the max throughput for the chip (not the driver!) used by the "fxp" driver, which is: 103kpps with standard TxCB 113kpps with extended TxCB 127kpps if you know the above problem, so do not use buffer descriptors and copy (small) packets into the TxCB don't ask me why, i have no docs and no idea But this is not the only chip which does weird things. Even the 21143, which can go at full speed (148.8kpps), suddenly wastes an extra ~4us when a packet is split across two or more buffers in different descriptors (the "dc" driver has this problem, the "de" driver is slightly smarter and uses the two pointers in each descriptor to point to two buffers, so there you have the problem when you get to 3 buffers). Performance evaluation is a lot of fun :) cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 13:58:54 2002 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 2E27E37B400 for ; Tue, 20 Aug 2002 13:58:51 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDE9C43E70 for ; Tue, 20 Aug 2002 13:58:50 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7KKwnIb050465; Tue, 20 Aug 2002 13:58:49 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7KKwn2x050464; Tue, 20 Aug 2002 13:58:49 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Aug 2002 13:58:49 -0700 From: Luigi Rizzo To: Andrew Gallatin Cc: freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance Message-ID: <20020820135849.B50369@iguana.icir.org> References: <15714.27671.533860.408996@grasshopper.cs.duke.edu> <20020820093939.B48541@iguana.icir.org> <15714.39494.661931.882244@grasshopper.cs.duke.edu> <20020820132957.B49141@iguana.icir.org> <15714.43504.493596.791872@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15714.43504.493596.791872@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Tue, Aug 20, 2002 at 04:43:28PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Aug 20, 2002 at 04:43:28PM -0400, Andrew Gallatin wrote: ... > > hmmm... that seems to be in the noise (i assume you are dealing > > with a fast machine), but probably because there is a lot of ... > This an SMP kernel using interrupts, not POLLING. And using the ... > Anyway, things max out at ~65K pkts/sec, so a few thousand > pkts/second is a little better than in the noise. ok, i thought you had a lot higher packet rates. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 14: 7:47 2002 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 0988437B400 for ; Tue, 20 Aug 2002 14:07:46 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53D7343E3B for ; Tue, 20 Aug 2002 14:07:45 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id RAA24299; Tue, 20 Aug 2002 17:07:44 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g7KL7EP27522; Tue, 20 Aug 2002 17:07:14 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15714.44930.665246.141549@grasshopper.cs.duke.edu> Date: Tue, 20 Aug 2002 17:07:14 -0400 (EDT) To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance In-Reply-To: <20020820135849.B50369@iguana.icir.org> References: <15714.27671.533860.408996@grasshopper.cs.duke.edu> <20020820093939.B48541@iguana.icir.org> <15714.39494.661931.882244@grasshopper.cs.duke.edu> <20020820132957.B49141@iguana.icir.org> <15714.43504.493596.791872@grasshopper.cs.duke.edu> <20020820135849.B50369@iguana.icir.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo writes: > On Tue, Aug 20, 2002 at 04:43:28PM -0400, Andrew Gallatin wrote: > ... > > > hmmm... that seems to be in the noise (i assume you are dealing > > > with a fast machine), but probably because there is a lot of > ... > > This an SMP kernel using interrupts, not POLLING. And using the > ... > > Anyway, things max out at ~65K pkts/sec, so a few thousand > > pkts/second is a little better than in the noise. > > ok, i thought you had a lot higher packet rates. I seem to remember something like ~200K pkts/sec with our development branch code. Most are, naturally, dropped on the floor in an end-2-end configuration.. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 14:19:49 2002 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 7898C37B400 for ; Tue, 20 Aug 2002 14:19:47 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AF4243E3B for ; Tue, 20 Aug 2002 14:19:46 -0700 (PDT) (envelope-from marks@ripe.net) Received: from laptop.6bone.nl (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id g7KLJiF4029163; Tue, 20 Aug 2002 23:19:45 +0200 Received: (nullmailer pid 2778 invoked by uid 1000); Tue, 20 Aug 2002 21:19:33 -0000 Date: Tue, 20 Aug 2002 23:19:33 +0200 From: Mark Santcroos To: michael harbour Cc: freebsd-net@FreeBSD.ORG Subject: Re: NFS request from unpermitted port Message-ID: <20020820211933.GC753@laptop.6bone.nl> References: <9AEB13D4-B485-11D6-9D28-0030657B06A4@btopenworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9AEB13D4-B485-11D6-9D28-0030657B06A4@btopenworld.com> User-Agent: Mutt/1.4i X-Handles: MS6-6BONE, MS18417-RIPE X-RIPE-Spam-Status: NONE ; -1034 X-RIPE-Spam-Level: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Aug 20, 2002 at 09:41:37PM +0000, michael harbour wrote: > hello > i'm trying to set up NFS networking between an iMac with MacOSX (as the > client) and FreeBSD on a laptop (as the server) > as far as i know, i've got the necessary daemons running on both > machines, but when i try to connect to BSD it says > NFS request from unprivileged port (192.167.1.157:49156) > is the client or the server at fault ? is 49156 a silly port ? should > the server be configured to recognise the port ? if so, how do i do this > stuff? Do you have: nfs_reserved_port_only="YES" in your rc.conf? You should have not :) Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 14:21:45 2002 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 6379A37B400 for ; Tue, 20 Aug 2002 14:21:42 -0700 (PDT) Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id C90A843E42 for ; Tue, 20 Aug 2002 14:21:41 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 5334B38532; Tue, 20 Aug 2002 23:21:40 +0200 (CEST) Date: Tue, 20 Aug 2002 23:21:40 +0200 From: Jesper Skriver To: Julian Elischer Cc: Steve Francis , Jeff Behl , net@freebsd.org Subject: Re: MTU not working? Message-ID: <20020820212140.GB92474@skriver.dk> References: <20020820091655.GB76162@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Aug 20, 2002 at 11:46:24AM -0700, Julian Elischer wrote: > > > On Tue, 20 Aug 2002, Jesper Skriver wrote: > > > > > Doesn't we do that allready ? > > > > src/sys/netinet/tcp_subr.c > > > > around line 1416 in tcp_mtudisc() we have a > > > > tp->snd_nxt = tp->snd_una; > > > > however if the packet that emerges is still large, then obviously > something is stopping this from being effective.. hence the description > "bug" :-) Yes, I get that - I thought that you meant that we didn't even try. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Senior network engineer @ AS3292, TDC Tele Danmark One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 14:28:15 2002 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 3F0C137B407 for ; Tue, 20 Aug 2002 14:28:06 -0700 (PDT) Received: from web10408.mail.yahoo.com (web10408.mail.yahoo.com [216.136.130.110]) by mx1.FreeBSD.org (Postfix) with SMTP id 0798D43E42 for ; Tue, 20 Aug 2002 14:28:06 -0700 (PDT) (envelope-from opolyakov@yahoo.com) Message-ID: <20020820212805.58712.qmail@web10408.mail.yahoo.com> Received: from [67.112.212.200] by web10408.mail.yahoo.com via HTTP; Tue, 20 Aug 2002 14:28:05 PDT Date: Tue, 20 Aug 2002 14:28:05 -0700 (PDT) From: Oleg Polyakov Subject: Re: Initial congestion window increase To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Attached below revamped patches to introduce RFC 2414 - 'Increasing TCP's Initial Window' to FreeBSD. Patches add sysctl variable - net.inet.tcp.increased_initial_window which is turned off by now. They also change initial and restart congestion windows in accordance with RFC. The restart window value set to minimum between initial window and current congestion window. The change in tcp_subr.c for cwnd decreasing in case of MTU discovery lowering mss is about the same as in OpenBSD, which as far as I can tell implementing only that part of RFC 2414. Suggestions and opinions are appreciated. ---- Oleg --- tcp_input.c.orig Wed Jul 31 19:06:49 2002 +++ tcp_input.c Thu Aug 15 13:59:19 2002 @@ -121,6 +121,10 @@ &tcp_delack_enabled, 0, "Delay ACK to try and piggyback it onto a data packet"); +int inc_init_win = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, increased_initial_window, CTLFLAG_RW, + &inc_init_win, 1, "Increased initial window"); + #ifdef TCP_DROP_SYNFIN static int drop_synfin = 0; SYSCTL_INT(_net_inet_tcp, OID_AUTO, drop_synfin, CTLFLAG_RW, @@ -2492,6 +2496,7 @@ * of the interface), as we can't discover anything about intervening * gateways or networks. We also initialize the congestion/slow start * window to be a single segment if the destination isn't local. + * We may increase the congestion/slow start window in accordance with RFC2414. * While looking at the routing entry, we also initialize other path-dependent * parameters from pre-set or cached values in the routing entry. * @@ -2710,7 +2715,9 @@ #endif ) tp->snd_cwnd = mss * ss_fltsz_local; - else + else if (inc_init_win) + tp->snd_cwnd = min(4*mss, max(2*mss,4380)); + else tp->snd_cwnd = mss * ss_fltsz; if (rt->rt_rmx.rmx_ssthresh) { --- tcp_output.c.orig Thu Aug 15 13:55:52 2002 +++ tcp_output.c Fri Aug 16 13:24:40 2002 @@ -146,16 +146,22 @@ * Set the slow-start flight size depending on whether * this is a local network or not. */ - int ss = ss_fltsz; + if ( #ifdef INET6 - if (isipv6) { - if (in6_localaddr(&tp->t_inpcb->in6p_faddr)) - ss = ss_fltsz_local; - } else + (isipv6 && in6_localaddr(&tp->t_inpcb->in6p_faddr)) || + (!isipv6 && #endif /* INET6 */ - if (in_localaddr(tp->t_inpcb->inp_faddr)) - ss = ss_fltsz_local; - tp->snd_cwnd = tp->t_maxseg * ss; + in_localaddr(tp->t_inpcb->inp_faddr) +#ifdef INET6 + ) +#endif /* INET6 */ + ) + tp->snd_cwnd = tp->t_maxseg * ss_fltsz_local; + else if (inc_init_win) + tp->snd_cwnd = min(tp->snd_cwnd,min(4*tp->t_maxseg, + max(2*tp->t_maxseg,4380))); + else + tp->snd_cwnd = tp->t_maxseg * ss_fltsz; } tp->t_flags &= ~TF_LASTIDLE; if (idle) { --- tcp_subr.c.orig Thu Aug 1 03:54:43 2002 +++ tcp_subr.c Fri Aug 16 14:52:16 2002 @@ -1385,6 +1385,14 @@ #endif if (so->so_snd.sb_hiwat < mss) mss = so->so_snd.sb_hiwat; + /* + * Follow suggestion in RFC 2414 to reduce the congestion + * window by the ratio of the old segment size to the new + * segment size. + */ + if (mss < tp->t_maxseg) + tp->snd_cwnd = max((tp->snd_cwnd / tp->t_maxseg) * + mss, mss); tp->t_maxseg = mss; --- tcp_var.h.orig Mon Aug 12 15:53:19 2002 +++ tcp_var.h Fri Aug 16 15:44:57 2002 @@ -436,6 +436,7 @@ extern int path_mtu_discovery; extern int ss_fltsz; extern int ss_fltsz_local; +extern int inc_init_win; void tcp_canceltimers(struct tcpcb *); struct tcpcb * __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 20 20:53:15 2002 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 5910737B400 for ; Tue, 20 Aug 2002 20:53:05 -0700 (PDT) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BF7243E3B for ; Tue, 20 Aug 2002 20:53:04 -0700 (PDT) (envelope-from michael.harbour@btopenworld.com) Received: from host62-7-32-21.in-addr.btopenworld.com ([62.7.32.21] helo=localhost) by carbon with esmtp (Exim 3.22 #8) id 17hGks-0002mA-00 for freebsd-net@FreeBSD.org; Tue, 20 Aug 2002 22:41:39 +0100 Date: Tue, 20 Aug 2002 22:41:05 +0000 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: multipart/alternative; boundary=Apple-Mail-1-36458255 Subject: RE:NFS request from unpermitted port From: michael harbour To: freebsd-net@FreeBSD.org Message-Id: X-Mailer: Apple Mail (2.482) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --Apple-Mail-1-36458255 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Mark That did indeed hit the spot. Many thanks. Mike On Tue, Aug 20, 2002 at 09:41:37PM +0000, michael harbour wrote: > hello > i'm trying to set up NFS networking between an iMac with MacOSX (as the > client) and FreeBSD on a laptop (as the server) > as far as i know, i've got the necessary daemons running on both > machines, but when i try to connect to BSD it says > NFS request from unprivileged port (192.167.1.157:49156) > is the client or the server at fault ? is 49156 a silly port ? should > the server be configured to recognise the port ? if so, how do i do this > stuff? Do you have: nfs_reserved_port_only="YES" in your rc.conf? You should have not :) Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message --Apple-Mail-1-36458255 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII CourierMark That did indeed hit the spot. Many thanks. Mike On Tue, Aug 20, 2002 at 09:41:37PM +0000, michael harbour wrote: > hello > i'm trying to set up NFS networking between an iMac with MacOSX (as the > client) and FreeBSD on a laptop (as the server) > as far as i know, i've got the necessary daemons running on both > machines, but when i try to connect to BSD it says > NFS request from unprivileged port (192.167.1.157:49156) > is the client or the server at fault ? is 49156 a silly port ? should > the server be configured to recognise the port ? if so, how do i do this > stuff? Do you have: nfs_reserved_port_only="YES" in your rc.conf? You should have not :) Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message --Apple-Mail-1-36458255-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 21 4:23:34 2002 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 381AB37B400 for ; Wed, 21 Aug 2002 04:23:32 -0700 (PDT) Received: from web14609.mail.yahoo.com (web14609.mail.yahoo.com [216.136.224.241]) by mx1.FreeBSD.org (Postfix) with SMTP id 10C1B43E70 for ; Wed, 21 Aug 2002 04:23:32 -0700 (PDT) (envelope-from shubha_mr@yahoo.com) Message-ID: <20020821112332.21757.qmail@web14609.mail.yahoo.com> Received: from [12.151.32.25] by web14609.mail.yahoo.com via HTTP; Wed, 21 Aug 2002 12:23:32 BST Date: Wed, 21 Aug 2002 12:23:32 +0100 (BST) From: =?iso-8859-1?q?shubha=20mr?= Subject: VLAN in, ping gone! To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I configured a VALN including a windows machine and a FreBSD machine.After this,the ping between them does not work tho,arp query and response are there(This I made out by viewing pkts using a sniffer,etherpeek). Also it says,ARP: 08:00:59:1b:02:05 is on vlan1 but obtained a response on fxp0 .. (fxp0 is the parent device of vlan1). any idea to get the ping working? shubha __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 21 7:45:35 2002 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 AE0D537B400 for ; Wed, 21 Aug 2002 07:45:31 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A41EA43E86 for ; Wed, 21 Aug 2002 07:45:27 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id KAA16071 for ; Wed, 21 Aug 2002 10:45:27 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g7LEivW28884; Wed, 21 Aug 2002 10:44:57 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15715.42856.880954.303791@grasshopper.cs.duke.edu> Date: Wed, 21 Aug 2002 10:44:56 -0400 (EDT) To: freebsd-net@freebsd.org Subject: modern ethernet & IP references X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org An older collegue of mine recently sent me this request: I'd like to have a pointer to a reference, preferably not more than 200 pages, with a subtitle "Everything you ever wondered about Ethernet and IP and were afraid to ask." Let me note that, as someone who knew the people who invented ethernet and IP, and who has some passing familiarity with these standards and protocols; I'd like to bring myself up-to-date on the standards as practiced today. Is anybody familiar with a book or a concise on-line source which talks about the extensions made to ethernet and ip networking in the last decade or so (GigE, Channel bonding, VLANs, IPSec, etc). Most things that I've been able to find are scattered references all over the place, or are too old to cover the more modern things. Thanks, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 21 7:51:53 2002 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 D3AC337B400 for ; Wed, 21 Aug 2002 07:51:46 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79C4043E88 for ; Wed, 21 Aug 2002 07:51:46 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7LEpjIb057323; Wed, 21 Aug 2002 07:51:45 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7LEpj5U057322; Wed, 21 Aug 2002 07:51:45 -0700 (PDT) (envelope-from rizzo) Date: Wed, 21 Aug 2002 07:51:45 -0700 From: Luigi Rizzo To: Andre Song Cc: freebsd-net@FreeBSD.ORG Subject: fxp performance (was Re: m_getcl and end-to-end performance) Message-ID: <20020821075145.B57063@iguana.icir.org> References: <15714.27671.533860.408996@grasshopper.cs.duke.edu> <20020820093939.B48541@iguana.icir.org> <15714.39494.661931.882244@grasshopper.cs.duke.edu> <20020820132957.B49141@iguana.icir.org> <15714.43504.493596.791872@grasshopper.cs.duke.edu> <20020820135736.A50369@iguana.icir.org> <3D63A3C2.26A938D4@rdsk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D63A3C2.26A938D4@rdsk.net>; from song@rdsk.net on Wed, Aug 21, 2002 at 10:29:22PM +0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Aug 21, 2002 at 10:29:22PM +0800, Andre Song wrote: > Hi, Luigi > > Do you have any plan to publish these improvments (extended and > simplified > TxCB)? I'm very interesting in them. excended TxCB are already used by the driver in -current and -stable, if they are available on the hardware (apparently old chip revisions do not support them). The "simplified TxCB" is really just a trick to look good in benchmarks, but i do not plan to commit it -- it is just ugly and in the end it does not really help much, because the hardware seems unable to reach line speed anyways (and no, i am not running out of cpu, an "em" card on the same machine can push out almost 650kpps). Anyways, the code below should do -- you can enable/disable it at runtime with sysctl hw.fxp_tx_copy=1 cheers luigi > Regards, > song > > Luigi Rizzo wrote: > > > > > which gets you close to the max throughput for the chip (not the driver!) > > used by the "fxp" driver, which is: > > > > 103kpps with standard TxCB > > 113kpps with extended TxCB > > 127kpps if you know the above problem, so do not use buffer > > descriptors and copy (small) packets into the TxCB > > > > don't ask me why, i have no docs and no idea --- if_fxp.c Sun Aug 11 11:25:43 2002 +++ if_fxp.c.fast Fri Aug 9 03:50:47 2002 @@ -97,6 +97,9 @@ * (1536 bytes), if an underrun occurs. */ static int tx_threshold = 64; +static int tx_copy; +SYSCTL_INT(_hw, OID_AUTO, fxp_tx_copy, CTLFLAG_RW, + &tx_copy, 0, "fxp copy small bufs"); /* * The configuration byte map has several undefined fields which @@ -1046,6 +1051,22 @@ * the transmit buffer descriptors with the physical address * and size of the mbuf. */ +#if 1 + /* + * if it is small, use simple mode and put everything in + * the TxCB + */ + if (tx_copy && mb_head->m_next == NULL && mb_head->m_len < 128) { + int i = sc->flags & FXP_FLAG_EXT_TXCB ? 2 : 0; + + bcopy(mtod(mb_head, char *), + (char *)&(txp->tbd[i]), mb_head->m_len); + txp->byte_count = mb_head->m_len; + segment = 0; + txp->tbd_array_addr = 0xffffffff; + goto got_it; + } +#endif tbdinit: for (m = mb_head, segment = 0; m != NULL; m = m->m_next) { if (m->m_len != 0) { @@ -1086,16 +1107,24 @@ goto tbdinit; } + if (sc->flags & FXP_FLAG_EXT_TXCB) + txp->tbd_array_addr = vtophys(&txp->tbd[2]); + else + txp->tbd_array_addr = vtophys(&txp->tbd[0]); + txp->byte_count = 0; +got_it: txp->tbd_number = segment; txp->mb_head = mb_head; txp->cb_status = 0; if (sc->tx_queued != FXP_CXINT_THRESH - 1) { txp->cb_command = - FXP_CB_COMMAND_XMIT | FXP_CB_COMMAND_SF | + FXP_CB_COMMAND_XMIT | + (segment ? FXP_CB_COMMAND_SF:0) | FXP_CB_COMMAND_S; } else { txp->cb_command = - FXP_CB_COMMAND_XMIT | FXP_CB_COMMAND_SF | + FXP_CB_COMMAND_XMIT | + (segment ? FXP_CB_COMMAND_SF:0) | FXP_CB_COMMAND_S | FXP_CB_COMMAND_I; /* * Set a 5 second timer just in case we don't hear To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 21 9:38:16 2002 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 D94F437B400; Wed, 21 Aug 2002 09:38:14 -0700 (PDT) Received: from corbulon.video-collage.com (corbulon.video-collage.com [64.35.99.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CDB443E6E; Wed, 21 Aug 2002 09:38:14 -0700 (PDT) (envelope-from mi+mx@aldan.algebra.com) Received: from misha.murex.com (250-217.customer.cloud9.net [168.100.250.217]) by corbulon.video-collage.com (8.12.2/8.12.2) with ESMTP id g7LGcAe5062486 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 21 Aug 2002 12:38:12 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) X-Authentication-Warning: corbulon.video-collage.com: Host 250-217.customer.cloud9.net [168.100.250.217] claimed to be misha.murex.com Content-Type: text/plain; charset="us-ascii" From: Mikhail Teterin Organization: Virtual Estates, Inc. To: irc@FreeBSD.org, net@FreeBSD.org Subject: an IRC server with PAM or PostgreSQL authentication? Date: Wed, 21 Aug 2002 12:39:01 -0400 User-Agent: KMail/1.4.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208211239.01156.mi+mx@aldan.algebra.com> X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi! I run a "community" site and would like to add the standalone IRC server to the mix. My idea is, that anyone can join the channels, but to get an "op" one will have to authenticate. The site currently uses a small PostgreSQL database to keep track of the user profiles and e-mail addresses. The same DB is currently used for HTTP authentication (mod_auth_pgsql). Is there an IRC server that would support such a thing, or should I write my own bot, that will grant "ops" to those, who ask for it with the proper login/password? Ideally, the server will support SSL as well. Thank you! -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 21 13:40:36 2002 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 B199D37B400 for ; Wed, 21 Aug 2002 13:40:26 -0700 (PDT) Received: from web10408.mail.yahoo.com (web10408.mail.yahoo.com [216.136.130.110]) by mx1.FreeBSD.org (Postfix) with SMTP id 42DDF43E3B for ; Wed, 21 Aug 2002 13:40:26 -0700 (PDT) (envelope-from opolyakov@yahoo.com) Message-ID: <20020821204025.33297.qmail@web10408.mail.yahoo.com> Received: from [67.112.212.200] by web10408.mail.yahoo.com via HTTP; Wed, 21 Aug 2002 13:40:25 PDT Date: Wed, 21 Aug 2002 13:40:25 -0700 (PDT) From: Oleg Polyakov Subject: Re: Initial congestion window increase To: freebsd-net@FreeBSD.org In-Reply-To: <0H1500FJLZIPYE@mta6.snfc21.pbi.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --- Jeffrey Hsu wrote: > Your copy of -current is a little out of date. I removed that hideous > INET6 #ifdef last week. Here is updated diff. --- tcp_input.c.orig Mon Aug 19 19:47:11 2002 +++ tcp_input.c Wed Aug 21 11:12:24 2002 @@ -114,6 +114,10 @@ &tcp_delack_enabled, 0, "Delay ACK to try and piggyback it onto a data packet"); +int inc_init_win = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, increased_initial_window, CTLFLAG_RW, + &inc_init_win, 1, "Increased initial window"); + #ifdef TCP_DROP_SYNFIN static int drop_synfin = 0; SYSCTL_INT(_net_inet_tcp, OID_AUTO, drop_synfin, CTLFLAG_RW, @@ -2495,6 +2499,7 @@ * of the interface), as we can't discover anything about intervening * gateways or networks. We also initialize the congestion/slow start * window to be a single segment if the destination isn't local. + * We may increase the congestion/slow start window in accordance with RFC2414. * While looking at the routing entry, we also initialize other path-dependent * parameters from pre-set or cached values in the routing entry. * @@ -2686,7 +2691,9 @@ if ((isipv6 && in6_localaddr(&inp->in6p_faddr)) || (!isipv6 && in_localaddr(inp->inp_faddr))) tp->snd_cwnd = mss * ss_fltsz_local; - else + else if (inc_init_win) + tp->snd_cwnd = min(4*mss, max(2*mss,4380)); + else tp->snd_cwnd = mss * ss_fltsz; if (rt->rt_rmx.rmx_ssthresh) { --- tcp_output.c.orig Sat Aug 17 18:26:01 2002 +++ tcp_output.c Wed Aug 21 11:12:24 2002 @@ -146,16 +146,22 @@ * Set the slow-start flight size depending on whether * this is a local network or not. */ - int ss = ss_fltsz; + if ( #ifdef INET6 - if (isipv6) { - if (in6_localaddr(&tp->t_inpcb->in6p_faddr)) - ss = ss_fltsz_local; - } else + (isipv6 && in6_localaddr(&tp->t_inpcb->in6p_faddr)) || + (!isipv6 && #endif /* INET6 */ - if (in_localaddr(tp->t_inpcb->inp_faddr)) - ss = ss_fltsz_local; - tp->snd_cwnd = tp->t_maxseg * ss; + in_localaddr(tp->t_inpcb->inp_faddr) +#ifdef INET6 + ) +#endif /* INET6 */ + ) + tp->snd_cwnd = tp->t_maxseg * ss_fltsz_local; + else if (inc_init_win) + tp->snd_cwnd = min(tp->snd_cwnd,min(4*tp->t_maxseg, + max(2*tp->t_maxseg,4380))); + else + tp->snd_cwnd = tp->t_maxseg * ss_fltsz; } tp->t_flags &= ~TF_LASTIDLE; if (idle) { --- tcp_subr.c.orig Sat Aug 17 18:26:02 2002 +++ tcp_subr.c Wed Aug 21 11:12:24 2002 @@ -1408,6 +1408,14 @@ #endif if (so->so_snd.sb_hiwat < mss) mss = so->so_snd.sb_hiwat; + /* + * Follow suggestion in RFC 2414 to reduce the congestion + * window by the ratio of the old segment size to the new + * segment size. + */ + if (mss < tp->t_maxseg) + tp->snd_cwnd = max((tp->snd_cwnd / tp->t_maxseg) * + mss, mss); tp->t_maxseg = mss; --- tcp_var.h.orig Sat Aug 17 18:26:02 2002 +++ tcp_var.h Wed Aug 21 11:12:24 2002 @@ -442,6 +442,7 @@ extern int path_mtu_discovery; extern int ss_fltsz; extern int ss_fltsz_local; +extern int inc_init_win; void tcp_canceltimers(struct tcpcb *); struct tcpcb * __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 21 16:13:33 2002 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 BA6B637B400 for ; Wed, 21 Aug 2002 16:13:30 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CBCA43E7B for ; Wed, 21 Aug 2002 16:13:30 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020821231329.NYLN1186.rwcrmhc52.attbi.com@blossom.cjclark.org>; Wed, 21 Aug 2002 23:13:29 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g7LNDTJK075886; Wed, 21 Aug 2002 16:13:29 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g7LNDSaI075885; Wed, 21 Aug 2002 16:13:28 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Wed, 21 Aug 2002 16:13:28 -0700 From: "Crist J. Clark" To: Lars Eggert Cc: Barney Wolff , net@FreeBSD.org Subject: Re: Bridging when one interface has no carrier Message-ID: <20020821231328.GA74544@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <3D61224B.2020902@isi.edu> <20020819102951.A38869@iguana.icir.org> <3D612D6A.9020604@isi.edu> <20020819181919.GA9000@tp.databus.com> <3D613D5B.10507@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D613D5B.10507@isi.edu> User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Aug 19, 2002 at 11:47:55AM -0700, Lars Eggert wrote: > Barney Wolff wrote: > >I don't recall that FreeBSD has ever had the "strong host model" > >property and (as I just confirmed by test) it doesn't have it now. > > For IP, it doesn't, and never has. Packets destined for any local IP > address are accepted (by IP), no matter which interface the come in over. We have had, net.inet.ip.check_interface Which does, /* * XXX - Setting ip_checkinterface mostly implements the receive side of * the Strong ES model described in RFC 1122, but since the routing table * and transmit implementation do not implement the Strong ES model, * setting this to 1 results in an odd hybrid. * * XXX - ip_checkinterface currently must be disabled if you use ipnat * to translate the destination address to another local interface. * * XXX - ip_checkinterface must be disabled if you add IP aliases * to the loopback interface instead of the interface where the * packets for those addresses are received. */ For a while now. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 21 16:17:18 2002 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 B157837B400; Wed, 21 Aug 2002 16:17:14 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67A4D43E70; Wed, 21 Aug 2002 16:17:13 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (b0z9yeyaqm4cl3eu@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g7LNHCJ15062; Wed, 21 Aug 2002 16:17:12 -0700 (PDT) Message-ID: <3D641F78.90400@isi.edu> Date: Wed, 21 Aug 2002 16:17:12 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: "Crist J. Clark" Cc: Barney Wolff , net@FreeBSD.org Subject: Re: Bridging when one interface has no carrier References: <3D61224B.2020902@isi.edu> <20020819102951.A38869@iguana.icir.org> <3D612D6A.9020604@isi.edu> <20020819181919.GA9000@tp.databus.com> <3D613D5B.10507@isi.edu> <20020821231328.GA74544@blossom.cjclark.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020601020100030903070901" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms020601020100030903070901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Crist J. Clark wrote: > On Mon, Aug 19, 2002 at 11:47:55AM -0700, Lars Eggert wrote: > >>Barney Wolff wrote: >> >>>I don't recall that FreeBSD has ever had the "strong host model" >>>property and (as I just confirmed by test) it doesn't have it now. >> >>For IP, it doesn't, and never has. Packets destined for any local IP >>address are accepted (by IP), no matter which interface the come in over. > > > We have had, > > net.inet.ip.check_interface ... > For a while now. Must have missed it - I stand corrected. Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms020601020100030903070901 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDgyMTIzMTcxMlowIwYJKoZIhvcNAQkEMRYEFMI1o8p6Mx9h pG95tc6Spi2LdlyOMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYAnv2lhk8hrd3S1KK7WkmwQnT18dUfz5PWhUVDWkYUa/m8G XHvm46a5AoPMs1Rmo/7easLnPNE7LNGXZ5Cyz8BCLRPZvG+pLtsEaK1x8PwF3i8Qnag06z2o QX47t4L4E5bPdSXGWdE/3/tHOmLXzkT2n8ditB6kaSlahtm+EvKMkQAAAAAAAA== --------------ms020601020100030903070901-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 21 20:52:12 2002 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 68AF637B400 for ; Wed, 21 Aug 2002 20:52:09 -0700 (PDT) Received: from web14610.mail.yahoo.com (web14610.mail.yahoo.com [216.136.224.242]) by mx1.FreeBSD.org (Postfix) with SMTP id 09E5643E6E for ; Wed, 21 Aug 2002 20:52:09 -0700 (PDT) (envelope-from shubha_mr@yahoo.com) Message-ID: <20020822035208.28801.qmail@web14610.mail.yahoo.com> Received: from [12.151.32.25] by web14610.mail.yahoo.com via HTTP; Thu, 22 Aug 2002 04:52:08 BST Date: Thu, 22 Aug 2002 04:52:08 +0100 (BST) From: =?iso-8859-1?q?shubha=20mr?= Subject: ifconfig enhancement. To: freebsd-questions@FreeBSD.ORG Cc: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, If I need to add an option to ifconfig for my test purposes,how do I do it?Should I add code to the ifconfig src code or do I need to write a puedo device for the same.Also is it recommended to write a new tool itself (not ifconfig at all)for the purpose I mentioned?Also Is there any sample such a tool for me to refer to? Please help, Thanks and Regards, shubha To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 22 2:49:37 2002 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 9798737B400 for ; Thu, 22 Aug 2002 02:49:35 -0700 (PDT) Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 094C743E75 for ; Thu, 22 Aug 2002 02:49:35 -0700 (PDT) (envelope-from gabe@seul.org) Received: by moria.seul.org (Postfix, from userid 734) id 592151467F1; Thu, 22 Aug 2002 05:49:34 -0400 (EDT) Date: Thu, 22 Aug 2002 05:49:34 -0400 From: Gabriel Rocha To: freebsd-net@FreeBSD.ORG Subject: ipfw on gigabit ethernet Message-ID: <20020822054934.A20802@seul.org> Mail-Followup-To: freebsd-net@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Does anyone out there do ipfw on gigabit ethernet? What kind of throughput can I expect with something like that? What are suggested gigabit cards to use right now with fbsd? I realize these are relatively vague questons, but I am looking for as much info as possible on this one. Looking at proprietary solutions has led me to the sad conclusion that there is no way we can afford those and alternative solutions must be found. I Appreciate any replies. Thanks. --Gabe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 22 3:35:39 2002 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 E8D8837B400 for ; Thu, 22 Aug 2002 03:35:36 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E35A43E7B for ; Thu, 22 Aug 2002 03:35:36 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7MAZaIb066345; Thu, 22 Aug 2002 03:35:36 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7MAZaJ5066344; Thu, 22 Aug 2002 03:35:36 -0700 (PDT) (envelope-from rizzo) Date: Thu, 22 Aug 2002 03:35:36 -0700 From: Luigi Rizzo To: Gabriel Rocha Cc: freebsd-net@FreeBSD.ORG Subject: Re: ipfw on gigabit ethernet Message-ID: <20020822033536.A66166@iguana.icir.org> References: <20020822054934.A20802@seul.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020822054934.A20802@seul.org>; from gabe@seul.org on Thu, Aug 22, 2002 at 05:49:34AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org with "em" cards and a 1GHz P3 and ipfw2 and recent fixes (m_getcl()) i had a throughput of ~260kpps with a single accept rule, of course degrading as the ruleset size increases (i think around 230kpps with 10 rules but i could be mistaken). The CPU is a bottleneck there, though i do not know how fast CPUs you can get on systems with 64-bit PCI slots. I had good experience with the "em" cards and driver. cheers luigi On Thu, Aug 22, 2002 at 05:49:34AM -0400, Gabriel Rocha wrote: > Does anyone out there do ipfw on gigabit ethernet? What kind of > throughput can I expect with something like that? What are suggested > gigabit cards to use right now with fbsd? I realize these are relatively > vague questons, but I am looking for as much info as possible on this > one. Looking at proprietary solutions has led me to the sad conclusion > that there is no way we can afford those and alternative solutions must > be found. I Appreciate any replies. Thanks. --Gabe > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 22 21:13:10 2002 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 59E8137B401 for ; Thu, 22 Aug 2002 21:13:07 -0700 (PDT) Received: from web14610.mail.yahoo.com (web14610.mail.yahoo.com [216.136.224.242]) by mx1.FreeBSD.org (Postfix) with SMTP id D18CC43E86 for ; Thu, 22 Aug 2002 21:13:06 -0700 (PDT) (envelope-from shubha_mr@yahoo.com) Message-ID: <20020823041306.72216.qmail@web14610.mail.yahoo.com> Received: from [12.151.32.25] by web14610.mail.yahoo.com via HTTP; Fri, 23 Aug 2002 05:13:06 BST Date: Fri, 23 Aug 2002 05:13:06 +0100 (BST) From: =?iso-8859-1?q?shubha=20mr?= Subject: Networking implementation To: freebsd-net@FreeBSD.org Cc: freebsd-questions@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Could you please give me a referance book/online book/online tutorial for learning the networking implementation(protocol stack) in freeBSD. Please hep, Thanks and Regards shubha. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 22 21:33:33 2002 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 15A4437B400; Thu, 22 Aug 2002 21:33:28 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C95543E75; Thu, 22 Aug 2002 21:33:27 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g7N4XPwu029724; Thu, 22 Aug 2002 21:33:25 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g7N4XPBA029722; Thu, 22 Aug 2002 21:33:25 -0700 Date: Thu, 22 Aug 2002 21:33:25 -0700 From: Brooks Davis To: shubha mr Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Networking implementation Message-ID: <20020822213325.A19059@Odin.AC.HMC.Edu> References: <20020823041306.72216.qmail@web14610.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020823041306.72216.qmail@web14610.mail.yahoo.com>; from shubha_mr@yahoo.com on Fri, Aug 23, 2002 at 05:13:06AM +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 23, 2002 at 05:13:06AM +0100, shubha mr wrote: > Hi, > Could you please give me a referance book/online > book/online tutorial for learning the networking > implementation(protocol stack) in freeBSD. TCP/IP Ilustrated, Volume 2 by Richard Stevens and Gary Wright is probaly you best bet. It actually documents 4.4BSD and things have diverged a fair bit sense then, but with the source as a guide, you can learn quite a bit just by trying to figure out the differences. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9ZbsUXY6L6fI4GtQRArhqAJ9HRNv9EqRLry2fmNZoPGfb5ACL4gCgiKpS 5h626QVrW2V3f61srKAwbBY= =knaP -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 22 21:36:54 2002 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 3CB4937B400; Thu, 22 Aug 2002 21:36:51 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 683B643E70; Thu, 22 Aug 2002 21:36:49 -0700 (PDT) (envelope-from chunan.li@nokia.com) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7N4n6f18257; Fri, 23 Aug 2002 07:49:06 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 23 Aug 2002 07:36:47 +0300 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 23 Aug 2002 07:36:47 +0300 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 23 Aug 2002 12:36:27 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Networking implementation X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 23 Aug 2002 12:35:38 +0800 Message-ID: <4AE1AC3D692F55488F2D03518907B8AD61149E@beebe001.china.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Networking implementation Thread-Index: AcJKW9etOrotA2iCThqR1RCYcxee8AAAkxDA From: To: , Cc: X-OriginalArrivalTime: 23 Aug 2002 04:36:27.0209 (UTC) FILETIME=[A4CD3B90:01C24A5E] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi A good book I knew is TCP/IP Illustration Volumn 2 wrote by Stevens. BR ChunAn Li -----Original Message----- From: ext shubha mr [mailto:shubha_mr@yahoo.com] Sent: Friday, August 23, 2002 12:13 PM To: freebsd-net@FreeBSD.ORG Cc: freebsd-questions@FreeBSD.ORG Subject: Networking implementation Hi, Could you please give me a referance book/online book/online tutorial for learning the networking implementation(protocol stack) in freeBSD. Please hep, Thanks and Regards shubha. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 22 23:53:32 2002 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 AC47B37B400 for ; Thu, 22 Aug 2002 23:53:28 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BEFB43E4A for ; Thu, 22 Aug 2002 23:53:28 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7N6rRIb075304; Thu, 22 Aug 2002 23:53:27 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7N6rQBp075303; Thu, 22 Aug 2002 23:53:26 -0700 (PDT) (envelope-from rizzo) Date: Thu, 22 Aug 2002 23:53:26 -0700 From: Luigi Rizzo To: cmxu Cc: Gabriel Rocha , freebsd-net@FreeBSD.ORG Subject: Re: ipfw on gigabit ethernet Message-ID: <20020822235326.A75186@iguana.icir.org> References: <20020822033536.A66166@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cmxu@rdsk.net on Fri, Aug 23, 2002 at 02:36:27PM +0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Aug 23, 2002 at 02:36:27PM +0800, cmxu wrote: > Hello Luigi: > How about make em polling to gain more throughput? it's ready to commit. luigi > cmxu > > >with "em" cards and a 1GHz P3 and ipfw2 and recent fixes (m_getcl()) > >i had a throughput of ~260kpps with a single accept rule, of > >course degrading as the ruleset size increases (i think around 230kpps > >with 10 rules but i could be mistaken). > >The CPU is a bottleneck there, though i do not know how > >fast CPUs you can get on systems with 64-bit PCI slots. > > >I had good experience with the "em" cards and driver. > > > cheers > > luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 23 7:40:55 2002 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 AC20037B400 for ; Fri, 23 Aug 2002 07:40:51 -0700 (PDT) Received: from dragon.ichi.net (dragon.ichi.net [209.42.196.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DDB743E6E for ; Fri, 23 Aug 2002 07:40:50 -0700 (PDT) (envelope-from freebsd-net@ichi.net) Received: from coaster (localhost.localdomain [127.0.0.1]) by dragon.ichi.net (8.11.6/8.11.6) with ESMTP id g7NET8512110 for ; Fri, 23 Aug 2002 10:29:08 -0400 Content-Type: text/plain; charset="us-ascii" From: Ju Ichi To: freebsd-net@FreeBSD.ORG Subject: IPSec SPD limit? Date: Fri, 23 Aug 2002 10:39:26 -0400 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208231039.26675.freebsd-net@ichi.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org We are trying to setup a large IPSec SPD (in excess of 1000 SAs) on the following hardware/software config: Compaq DL360 with dual 1.4GHz processsors 2GB RAM 4GB swap space 4.6.1-RELEASE-p11 racoon-20020507a We get a "send: No buffer space available" when trying to read in the /etc/ipsec.conf file if it has more than about 1000 entries. Also, if we do a setkey -DP after trying to read in /etc/ipsec.conf we get "recv: Resource temporarily unavailable" after it lists some of the SAs. Several kernel tweaks have been tried. For example, we have tried setting MAXUSERS from 0 to 1024 on bit boundaries (0, 128, 256, 512, and 1024). FWIW, setting it to 1024 seems to be evil. ;-) We have also tried various settings in the kernel config file on NMBCLUSTERS, NMBUFS, NBUF, MAXDSIZ, MAXSSIZ, DFLDSIZ, and MAXFILES. In addition, we have tweaked kern.ipc.somaxconn, net.inet.tcp.sendspace, net.inet.tcp.recvspace, net.inet.udp.recvspace, and net.inet.udp.maxdgram after reading some performance tuning web pages. I can provide additional details as needed, but didn't want to make this initial request too long. Does anyone know of any limits on the number of entries the SPD can hold and if so how to make the limits higher? Thanks in advance, Ju To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 23 8: 9:57 2002 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 5017437B400 for ; Fri, 23 Aug 2002 08:09:51 -0700 (PDT) Received: from exchange.epx.com (exchange.epx.com [128.121.22.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E36943E42 for ; Fri, 23 Aug 2002 08:09:50 -0700 (PDT) (envelope-from freebsd@epx.com) Received: from ux340prd.epx.com (ux340prd.epx.com [192.168.12.94]) by exchange.epx.com (8.12.3/8.12.3) with ESMTP id g7NF9ebo005777 for ; Fri, 23 Aug 2002 11:09:40 -0400 (EDT) (envelope-from freebsd@epx.com) Content-Type: text/plain; charset="us-ascii" From: freebsd To: net@freebsd.org Subject: 100mb Nic w/ built in receive buffers, or driver/ifconfig tweaks? Date: Fri, 23 Aug 2002 11:09:40 -0400 X-Mailer: KMail [version 1.4] Organization: epx.com MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200208231109.40050.freebsd@epx.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I would like to know, and hope those that have worked with NIC drivers mi= ght=20 be able to tell me, if there are any commodity NIC cards that have onboar= d=20 receive buffers and are well suited to receiving lots and lots of traffic= =2E The application is SNORT on FreeBSD 4.6, so the traffic is all receive, t= here=20 is no IP assigned to this NIC card. And are there any other recommendations that anyone has on tweaking for l= arge=20 amounts of receive traffic, no xmit traffic. In a one hour this am, this interface received 1,816,114,954 bytes in=20 1,354,840 packets, and shows 15 Ierrs Also, would doing minor changes such as disabling ARP on this nic help th= ings? TIA for any help on this. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 23 23: 3:18 2002 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 8CBE037B400; Fri, 23 Aug 2002 23:03:16 -0700 (PDT) Received: from hotmail.com (f176.law9.hotmail.com [64.4.9.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55A4343E75; Fri, 23 Aug 2002 23:03:16 -0700 (PDT) (envelope-from soheil_h_y@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 23 Aug 2002 23:03:16 -0700 Received: from 62.217.112.191 by lw9fd.law9.hotmail.msn.com with HTTP; Sat, 24 Aug 2002 06:03:15 GMT X-Originating-IP: [62.217.112.191] From: "soheil h" To: freebsd-net@FreeBSD.ORG Cc: freebsd-questions@FreeBSD.ORG Subject: The kernel debugger Date: Sat, 24 Aug 2002 10:33:15 +0430 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Aug 2002 06:03:16.0130 (UTC) FILETIME=[EFF94020:01C24B33] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi list What is the best kernel debugger , that i can trace the kernel source codes with ? thanx _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 23 23: 8:27 2002 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 369AD37B400; Fri, 23 Aug 2002 23:08:24 -0700 (PDT) Received: from hotmail.com (f65.law9.hotmail.com [64.4.9.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id C54E843E65; Fri, 23 Aug 2002 23:08:23 -0700 (PDT) (envelope-from soheil_h_y@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 23 Aug 2002 23:08:23 -0700 Received: from 62.217.112.191 by lw9fd.law9.hotmail.msn.com with HTTP; Sat, 24 Aug 2002 06:08:23 GMT X-Originating-IP: [62.217.112.191] From: "soheil h" To: freebsd-net@FreeBSD.ORG Cc: freebsd-questions@FreeBSD.ORG Subject: Porting libc to kernel Date: Sat, 24 Aug 2002 10:38:23 +0430 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Aug 2002 06:08:23.0577 (UTC) FILETIME=[A739F090:01C24B34] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org HI list i want to know if we can port libc or zlib to 4.4 BSD kernel ? if yes , how ? thanx _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 23 23:20:19 2002 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 9FADA37B400; Fri, 23 Aug 2002 23:20:14 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE6B043E3B; Fri, 23 Aug 2002 23:20:10 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020824062010.ZRIA11061.sccrmhc01.attbi.com@InterJet.elischer.org>; Sat, 24 Aug 2002 06:20:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA71259; Fri, 23 Aug 2002 23:18:58 -0700 (PDT) Date: Fri, 23 Aug 2002 23:18:58 -0700 (PDT) From: Julian Elischer To: soheil h Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: The kernel debugger In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 24 Aug 2002, soheil h wrote: > > Hi list > > What is the best kernel debugger , that i can trace the kernel source codes > with ? to do that you need to have 2 comouters hooked together with a serial cable.. one to run, and one to run the debugger and read the sources.. with only one machine you can use the intoernal kernel debugger but you can not see sources. You CAN run a vmware machine and debug THAT if you only have one machine.. use the /dev/nmdm device to hook to it as if ou were using a serial cable.. slowish but works fine. > thanx > > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 23 23:40:16 2002 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 041B637B400; Fri, 23 Aug 2002 23:40:10 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D51F43E6A; Fri, 23 Aug 2002 23:40:09 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020824064009.HDNG14185.rwcrmhc51.attbi.com@InterJet.elischer.org>; Sat, 24 Aug 2002 06:40:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA71295; Fri, 23 Aug 2002 23:22:10 -0700 (PDT) Date: Fri, 23 Aug 2002 23:22:08 -0700 (PDT) From: Julian Elischer To: soheil h Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Porting libc to kernel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 24 Aug 2002, soheil h wrote: >=20 >=20 > HI list > i want to know if we can port libc or zlib to 4.4 BSD kernel ? > if yes , how ? 'no',,, um,,, "why?" But there are many functions in the kernel that are similar to libc.. actually there IS a libz functionality somewhere for the kernel as you can make it run compressed binaries. also check libkern (/sys/libkern) > thanx >=20 >=20 > _________________________________________________________________ > Join the world=92s largest e-mail service with MSN Hotmail.=20 > http://www.hotmail.com >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message