From owner-freebsd-net Sun May 12 15:26:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from spontoon.braithwaite.net (spontoon.braithwaite.net [207.135.122.130]) by hub.freebsd.org (Postfix) with ESMTP id ADE5137B403 for ; Sun, 12 May 2002 15:26:54 -0700 (PDT) Received: from dogberry.braithwaite.net (foo82.dsl.alink.net [207.135.112.82]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "dogberry.braithwaite.net", Issuer "Braithwaite's Certifying Authority" (verified OK)) by spontoon.braithwaite.net (Postfix) with ESMTP id 557FE7DF01; Sun, 12 May 2002 15:26:53 -0700 (PDT) Received: by dogberry.braithwaite.net (Postfix, from userid 1001) id 2534E924F; Sun, 12 May 2002 15:26:51 -0700 (PDT) From: Matthew Braithwaite To: Matthew Braithwaite Cc: Archie Cobbs , dgilbert@velocet.ca, freebsd-net@FreeBSD.ORG Subject: Re: mpd-netgraph problem. (SOLVED) References: <200205092357.g49Nvb204332@arch20m.dellroad.org> <86bsbo6696.fsf@limekiller.braithwaite.net> Date: 12 May 2002 15:26:51 -0700 In-Reply-To: <86bsbo6696.fsf@limekiller.braithwaite.net> Message-ID: <86r8khypck.fsf_-_@limekiller.braithwaite.net> Lines: 39 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 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 I solved my problem, but I need to retract a few things I said about it earlier: 1. Although I was told (by the folks who operate my VPN server) that I had to negotiate 128-bit encryption, I've succeeded with 40-bit encryption, using the ``LAN Manager'' hash. 2. Therefore, this whole business about MSCHAPv1/MSCHAPv2 is totally irrelevant, since the LAN Manager hash depends only on my password. 3. I have an alternate method of getting into my private network; I used that to ping the address I was assigned by the VPN server. When I did this I noticed that mpd was able to decrypt those pings successfully. In other words, only my transmit direction was broken: I could receive MPPE just fine. This test may be very useful for others who encounter the same symptoms, since the symptoms seem to have many possible causes. Anyway, the solution was to change the following function in ng_ppp.c (note, part of the kernel, not mpd) by removing the marked lines: static struct mbuf * ng_ppp_addproto(struct mbuf *m, int proto, int compOK) { - if (compOK && PROT_COMPRESSABLE(proto)) { - u_char pbyte = (u_char)proto; - - return ng_ppp_prepend(m, &pbyte, 1); - } else { u_int16_t pword = htons((u_int16_t)proto); return ng_ppp_prepend(m, &pword, 2); - } } If I had to make a wild-ass guess about why this works, it'd be that mpd supports MPPE but doesn't know how to do MPPC compression, so the peer isn't expecting the protocol field to be compressed. I don't care; it works now. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 13 4:14:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from www.example.org (dhcp-nic-val-26-84.cisco.com [64.103.26.84]) by hub.freebsd.org (Postfix) with SMTP id 4061237B400 for ; Mon, 13 May 2002 04:14:23 -0700 (PDT) Received: (qmail 24199 invoked by uid 1000); 13 May 2002 11:14:19 -0000 Message-ID: <20020513111419.24198.qmail@cobweb.example.org> Date: Mon, 13 May 2002 13:14:19 +0200 From: Marco Molteni To: freebsd-net@freebsd.org Subject: [OT] symbology for network elements? X-Mailer: Sylpheed version 0.7.5 (GTK+ 1.2.10; i386-portbld-freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Hi all, sorry for the off-topic question. Suggestions for a better place to ask are welcome. Are you aware of any "standard" network symbology? By this I mean having a graphical symbol for each network component, in the same spirit of the symbols of the various electronics components. If you look at RFCs and IDs each uses its own symbology to mean node, router, host, link, tunnel and so on. I would be interested in both ASCII art and real graphical symbols. thanks marco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 14 5:30:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from atropos.snu.ac.kr (atropos.snu.ac.kr [147.46.106.37]) by hub.freebsd.org (Postfix) with ESMTP id 06E3A37B400 for ; Tue, 14 May 2002 05:30:49 -0700 (PDT) Received: (from redjade@localhost) by atropos.snu.ac.kr (8.11.6/8.11.6) id g4ECUYB07778; Tue, 14 May 2002 21:30:34 +0900 (KST) Date: Tue, 14 May 2002 21:30:34 +0900 From: Kyunghwan Kim To: freebsd-net@freebsd.org Subject: Bandwidth reservation? Message-ID: <20020514213034.A7529@atropos.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.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've used dummynet bridge for bandwidth manangement in my company. Dummynet provides bandwidth management service by limiting specified traffic. Maybe limiting ability of dummynet is derived from its origin of network delay simulator. But I really want to use (or implement if I can) is bandwidth reservation. (I'm not sure it is appropriate term for that.) Assume that bandwidth is reserved for some traffic. If there is no traffic in specified traffic, then other kinds of traffic should be able to use the bandwidth. When the specified traffic occurs, reserved bandwidth should be guaranteed. In other words, bandwidth guarantee by reserving not by limiting. How should dummynet be modified to meet the need? If there is related works or papers, please let me know. -- Kyunghwan Kim redjade@atropos.snu.ac.kr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 14 8:35:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from flint.asdis.com (flint.asdis.com [212.222.145.99]) by hub.freebsd.org (Postfix) with ESMTP id 280B637B406 for ; Tue, 14 May 2002 08:35:23 -0700 (PDT) Received: from sarek.itp.asdis.de ([10.63.192.115]) by flint.asdis.com with esmtp (Exim 3.22 #1) id 177eKg-000DbR-00 for freebsd-net@freebsd.org; Tue, 14 May 2002 17:35:22 +0200 Received: from castillo.w2k.asdis.de ([10.63.193.193] helo=asdis.de) by sarek.itp.asdis.de with esmtp (Exim 3.33 #1) id 177drj-000514-00 for freebsd-net@freebsd.org; Tue, 14 May 2002 17:05:27 +0200 Message-ID: <3CE12EB9.8030508@asdis.de> Date: Tue, 14 May 2002 17:35:21 +0200 From: Matthias Kranz Organization: ASDIS Software AG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: de-DE MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Enabling Directed Broadcasts 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 Hi! We try to start a PC in a different subnet through using a WakeOnLan. The packet is addressed to the broadcast address of the client PC net. The FreeBSD router in between does not forward this packet. I read that FreeBSD is not supporting directed broadcasts since 2.2.5. Is there any parameter for chanching this behaviour? Any help is very much appreciated. Thank you, Matthias -- matthias kranz____________________phone: +49 30 20631418 consultant________________________mobile: +49 172 3843414 asdis software ag_________________fax: +49 30 20631199 neue gruenstrasse 25______________mailto: mkranz@asdis.de 10179 berlin-mitte____________________http://www.asdis.de http://www.stadtplandienst.de/query;ORT=b;LL=13.406735x52.512448;GR=3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 14 16:50:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 26D3537B407 for ; Tue, 14 May 2002 16:50:30 -0700 (PDT) Received: from isi.edu (2vdr11luai8pqlgo@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4ENoTF06342; Tue, 14 May 2002 16:50:29 -0700 (PDT) Message-ID: <3CE1A2C0.8050201@isi.edu> Date: Tue, 14 May 2002 16:50:24 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: net@freebsd.org, snap-users@kame.net Subject: tun device & IPv6 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070805020908090809060708" 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. --------------ms070805020908090809060708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, could someone with more knowledge of the tun device please take a look at the code around line 387 in net/if_tun.c? It looks like tunoutput() drops all packets here that aren't of the AF_INET family - most notably, it drops IPv6 packets. We hacked around this with the simple fix below, but I'm not sure if there are any drawbacks... --- if_tun.c.old Tue May 14 15:40:30 2002 +++ if_tun.c Tue May 14 15:48:15 2002 @@ -384,7 +384,7 @@ *(u_int32_t *)m0->m_data = htonl(dst->sa_family); } else { #ifdef INET - if (dst->sa_family != AF_INET) + if (dst->sa_family != AF_INET && dst->sa_family != AF_INET6) #endif { m_freem(m0); Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms070805020908090809060708 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC 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+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDUxNDIzNTAyNFowIwYJKoZIhvcNAQkEMRYEFF7ad57HcBITqFLm3C/Dc9HkE7HdMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYBSxh1xBp4xjrNuMW2WYR/jtI8xJdf0iO/ucaJHVes+IiYPuNuRwQWerMNbjq3uh95M IXZpYrM3Texo0DWM/yVtAi5hWkn0TjDeAQQs21BlicekrAYQ7X0Dbc0THP7nlGjzk5YCsE+0 hcz/AYfats0++DKiun1jh0uoGcWvLju1awAAAAAAAA== --------------ms070805020908090809060708-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 14 17: 4:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 6C22F37B403 for ; Tue, 14 May 2002 17:04:48 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 592D24B22; Wed, 15 May 2002 09:04:46 +0900 (JST) To: snap-users@kame.net Cc: net@freebsd.org In-reply-to: larse's message of Tue, 14 May 2002 16:50:24 MST. <3CE1A2C0.8050201@isi.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: tun device & IPv6 From: itojun@iijlab.net Date: Wed, 15 May 2002 09:04:46 +0900 Message-ID: <29485.1021421086@itojun.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 >could someone with more knowledge of the tun device please take a look >at the code around line 387 in net/if_tun.c? It looks like tunoutput() >drops all packets here that aren't of the AF_INET family - most notably, >it drops IPv6 packets. just to make sure, which platform? from cc: it seems to be freebsd, but which revision? itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 14 17:14:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 1B97337B400 for ; Tue, 14 May 2002 17:14:45 -0700 (PDT) Received: from isi.edu (22d8k2oe1oeprqmn@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4F0C0F19935; Tue, 14 May 2002 17:12:00 -0700 (PDT) Message-ID: <3CE1A7CE.4070205@isi.edu> Date: Tue, 14 May 2002 17:11:58 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: snap-users@kame.net Cc: net@freebsd.org Subject: Re: (KAME-snap 6382) Re: tun device & IPv6 References: <29485.1021421086@itojun.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010205020100070405080300" 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. --------------ms010205020100070405080300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit itojun@iijlab.net wrote: >>could someone with more knowledge of the tun device please take a look >>at the code around line 387 in net/if_tun.c? It looks like tunoutput() >>drops all packets here that aren't of the AF_INET family - most notably, >>it drops IPv6 packets. > > > just to make sure, which platform? from cc: it seems to be freebsd, > but which revision? Sorry, yes, FreeBSD-4.5, but from looking at the CVS tree, it also seems to be present in -CURRENT still. Lars -- Lars Eggert USC Information Sciences Institute --------------ms010205020100070405080300 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC 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+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDUxNTAwMTIwMFowIwYJKoZIhvcNAQkEMRYEFM2o+7KjzEdsAFADE/MtYVh3RdvLMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYAdsLE7jHUhbCvYDF6Qm0pt1QNlp0TCpgsbAXc+7i0o/TagrvCFHZDImyUhjM2i6Ace T0PbTCGYYHx6VEJqZuMJyR7lSHjaqDlRbI3qO+rwiKmYgEmG2NtKFHWOGxwtIeVDOUfqw/5O 5qTYI+CkH4mv5b8rfCWFGy8tE4sQbETqzAAAAAAAAA== --------------ms010205020100070405080300-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 14 18:29: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 2091437B405 for ; Tue, 14 May 2002 18:28:47 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F1SifK089637; Wed, 15 May 2002 02:28:44 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F1Sf20006584; Wed, 15 May 2002 02:28:41 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200205150128.g4F1Sf20006584@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: snap-users@kame.net Cc: net@freebsd.org Subject: Re: (KAME-snap 6381) tun device & IPv6 In-Reply-To: Message from Lars Eggert of "Tue, 14 May 2002 16:50:24 PDT." <3CE1A2C0.8050201@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6579.1021426120.1@hak.lan.Awfulhak.org> Date: Wed, 15 May 2002 02:28:41 +0100 From: Brian Somers 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 someone with more knowledge of the tun device please take a look > at the code around line 387 in net/if_tun.c? It looks like tunoutput() > drops all packets here that aren't of the AF_INET family - most notably, > it drops IPv6 packets. > > We hacked around this with the simple fix below, but I'm not sure if > there are any drawbacks... > > --- if_tun.c.old Tue May 14 15:40:30 2002 > +++ if_tun.c Tue May 14 15:48:15 2002 > @@ -384,7 +384,7 @@ > *(u_int32_t *)m0->m_data = htonl(dst->sa_family); > } else { > #ifdef INET > - if (dst->sa_family != AF_INET) > + if (dst->sa_family != AF_INET && dst->sa_family != AF_INET6) > #endif > { > m_freem(m0); > > Thanks, > Lars > -- > Lars Eggert USC Information Sciences Institute If you look at the larger picture.... if (tp->tun_flags & TUN_IFHEAD) { /* Prepend the address family */ M_PREPEND(m0, 4, M_DONTWAIT); /* if allocation failed drop packet */ if (m0 == NULL) { ifp->if_iqdrops++; ifp->if_oerrors++; return (ENOBUFS); } else *(u_int32_t *)m0->m_data = htonl(dst->sa_family); } else { #ifdef INET if (dst->sa_family != AF_INET) #endif { m_freem(m0); return (EAFNOSUPPORT); } } The tun device, when given the TUNSIFHEAD ioctl, will prepend the address family. If TUNSIFHEAD is turned off, it will drop non IPv4 packets. This was done for backwards compatibility. To use IPv6 with tun, you must use the TUNSIFHEAD ioctl and prepend/strip the address family on the front of each packet (see bundle_Create() in src/usr.sbin/ppp/bundle.c). -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 14 18:48:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id BD51237B406 for ; Tue, 14 May 2002 18:48:22 -0700 (PDT) Received: from isi.edu (cq3i3xw1q7oi0tqa@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4F1jeF07750; Tue, 14 May 2002 18:45:40 -0700 (PDT) Message-ID: <3CE1BDBC.4010609@isi.edu> Date: Tue, 14 May 2002 18:45:32 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: snap-users@kame.net Cc: net@freebsd.org Subject: Re: (KAME-snap 6384) Re: tun device & IPv6 References: <200205150128.g4F1Sf20006584@hak.lan.Awfulhak.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010003040500070001040100" 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. --------------ms010003040500070001040100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Brian Somers wrote: > The tun device, when given the TUNSIFHEAD ioctl, will prepend the > address family. If TUNSIFHEAD is turned off, it will drop non IPv4 > packets. > > This was done for backwards compatibility. To use IPv6 with tun, you > must use the TUNSIFHEAD ioctl and prepend/strip the address family on > the front of each packet (see bundle_Create() in > src/usr.sbin/ppp/bundle.c). Ah, that makes sense. The tag is so the tun device knows who to toss the packet to when it comes back from the process? Guess I'll have to patch vtund, then... Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms010003040500070001040100 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC 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+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDUxNTAxNDUzNVowIwYJKoZIhvcNAQkEMRYEFOFMvRedWga8Nz7wOdx4Bf5lgWJMMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYCsupp1bJna/E4Rm4uuJtKaLXmVrAxcqXOdmP9Af93T68KNdKM1U1NC7QOOZOuTxmum 54diYeUEEqi3PVnZBN4cusU/qSafLwdvBZ69Ds6KbGF7a8jcNCQ2otQSRr6Mr29G9XzGvFb1 iJtmOwGDFIVofdozppEx+yzWqhSHltEauQAAAAAAAA== --------------ms010003040500070001040100-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 14 19:45:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id BFC6337B406; Tue, 14 May 2002 19:45:48 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F2jdfK090241; Wed, 15 May 2002 03:45:39 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F2ja20007959; Wed, 15 May 2002 03:45:36 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200205150245.g4F2ja20007959@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Baldur Gislason Cc: Dan Protich , freebsd-gnats-submit@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: misc/37696: Virtual hosts broken In-Reply-To: Message from Baldur Gislason of "Fri, 03 May 2002 13:37:39 -0000." <20020503133856.9D6DD2744@tesla.foo.is> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 May 2002 03:45:36 +0100 From: Brian Somers 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 > Problem exists between keyboard and chair. > The reason why ifconfig complains is that you're assigning a point-to-point > address to an ethernet interface and both addresses have the same > point-to-point address. > > This is how you add ips to an interface: > ifconfig xl0 192.168.1.1 netmask 255.255.255.0 # this is the primary > ifconfig xl0 add 192.168.1.254 netmask 255.255.255.255 # All extra addresses You forgot ``alias''. > within the same subnet MUST have netmask 0xffffffff or 255.255.255.255 to > prevent routing problems. No, they must have a non-conflicting IP/mask combination. A netmask of 0xffffffff will make it non-conflicting, and is usually what you mean, but it's also possible to ifconfig xl0 192.168.1.1 netmask 255.255.255.0 ifconfig xl0 add 192.168.1.254 netmask 255.255.255.128 alias which means that data sent to (say) 192.168.1.200 will go with a source IP of 192.168.1.254, and not 192.168.1.1. > Baldur > > On Friday 03 May 2002 05:39, you wrote: > > >Number: 37696 > > >Category: misc > > >Synopsis: Virtual hosts broken > > >Confidential: no > > >Severity: serious > > >Priority: high > > >Responsible: freebsd-bugs > > >State: open > > >Quarter: > > >Keywords: > > >Date-Required: > > >Class: sw-bug > > >Submitter-Id: current-users > > >Arrival-Date: Thu May 02 22:40:01 PDT 2002 > > >Closed-Date: > > >Last-Modified: > > >Originator: Dan Protich > > >Release: 4.6-PRERELEASE > > >Organization: > > > > Shell-box Computers Inc. > > > > >Environment: > > > > bash-2.05a$ uname -a > > FreeBSD sinister.shell-box.com 4.6-PRERELEASE FreeBSD 4.6-PRERELEASE #0: > > Sat Mar 2 02:32:42 EST 2002 > > root@sinister.shell-box.com:/usr/obj/usr/src/sys/GENERIC i386 bash-2.05a$ > > > > >Description: > > > > Thought that i would upgrade freebsd box and main dns server was on it only > > accepted 1 virtual host and not a 2nd and wouldnt allow manual add of vhost > > rc.conf network information wouldn't accept did a upgrade from 4.5-release > > also kernel upgrade. > > > > >How-To-Repeat: > > > > sinister# ifconfig vr0 66.118.153.201 66.118.153.255 alias > > sinister# ifconfig vr0 66.118.153.254 66.118.153.255 alias > > ifconfig: ioctl (SIOCAIFADDR): File exists > > sinister# > > doesn't exist? > > sinister# ifconfig > > vr0: flags=8843 mtu 1500 > > inet 66.118.153.66 netmask 0xffffff00 broadcast 66.118.153.255 > > inet6 fe80::207:95ff:fea8:153b%vr0 prefixlen 64 scopeid 0x1 > > inet 66.118.153.201 netmask 0xff000000 broadcast 66.118.153.255 > > ether 00:07:95:a8:15:3b > > media: Ethernet autoselect (100baseTX ) > > status: active > > lp0: flags=8810 mtu 1500 > > sl0: flags=c010 mtu 552 > > faith0: flags=8002 mtu 1500 > > lo0: flags=8049 mtu 16384 > > inet6 ::1 prefixlen 128 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > > inet 127.0.0.1 netmask 0xff000000 > > ppp0: flags=8010 mtu 1500 > > sinister# > > > > >Fix: > > > > > >Release-Note: > > >Audit-Trail: > > >Unformatted: -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 14 19:55:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 7533E37B404 for ; Tue, 14 May 2002 19:55:36 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F2tZfK090268; Wed, 15 May 2002 03:55:35 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F2tW20008086; Wed, 15 May 2002 03:55:32 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200205150255.g4F2tW20008086@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "ipver4" Cc: freebsd-net@FreeBSD.ORG Subject: Re: CCP does not work between Linux ppp client and FreeBSD ppp server In-Reply-To: Message from "ipver4" of "Mon, 29 Apr 2002 23:27:29 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 May 2002 03:55:32 +0100 From: Brian Somers 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, You're correct. The linux machine should not REQ the compression schemes that were REJected. > (This is a PPP related question.) > > It seems the RedHat Linux 7.2 PPP client does not work with the FreeBSD = > 4.5 PPP server in the CCP (Compression Control Protocol) negotiation. = > Briefly, the problem looks like the following: > > Linux ---> CCP conf request (with 3 compression schemes, A, B and C) --> = > PPP server > Linux <-- CCP conf reject (schemes, B and C) <-- PPP server > (That is, the PPP server picked the compression scheme A, and rejected = > the rest.) > > Linux ---> CCP conf request (with 3 compression schemes, A, B and C) --> = > PPP server > Linux <-- CCP conf reject (schemes, B and C) <-- PPP server > (repeat may times without progress.) > > It seems the Linux client did not follow the PPP protocol and ignored = > the CCP reject messages. > The correct message exchange should look like the following: > > Linux ---> CCP conf request (with 3 compression schemes, A, B and C) --> = > PPP server > Linux <-- CCP conf reject (schemes, B and C) <-- PPP server > ---> CCP conf request (scheme A) --> PPP server > <--- CCP conf ACK (scheme A) <-- PPP server > > Comments? > > P.S. I am using PPPoE for the testing. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 14 19:58:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 99A4937B40C for ; Tue, 14 May 2002 19:58:25 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F2wNfK090278; Wed, 15 May 2002 03:58:23 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F2wJ20008115; Wed, 15 May 2002 03:58:19 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200205150258.g4F2wJ20008115@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Larry Baird Cc: freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: PPPoE performance difference In-Reply-To: Message from Larry Baird of "Tue, 30 Apr 2002 16:32:37 EDT." <20020430163237.A71846@gta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 May 2002 03:58:19 +0100 From: Brian Somers 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, The performance problem here is due to deflate compression being used. Compression is quite expensive (more so than decompression) and the slow machine is losing out here. If you ``disable deflate pred1 mppe'' and ``deny deflate pred1 mppe'' you should see better results. > I had a friend that was claiming that they were seeing poor PPPoE > performance from FreeBSD 4.4 as compared to Win2K. Since he is in > Japan and I am in the US its a bit difficult to do hands on trouble > shooting. So I decided to set up my on PPPoE server and see if I > could reduplicate any of his claims. > > I setup a 4.5-RELEASE box as my PPPoE server and a 4.5-STABLE box as > my PPPoE client. Both hosts are using Intel Pro 10/100 (fxp) nics. > The client is a relatively fast 999.72-MHz 686-class CPU. The server > is a slow 133.27-MHz 586-class CPU. > > I am seeing a performance difference that I can't explain. Coping of > a large file (2.6MB) using scp to the server from the client takes > about 7 seconds. Coping the same file from the server to the client > takes 14 seconds. Any body have any idea why the two directions are > so different? > > BTW, copying the file over ethernet (not PPPoE) takes 3 seconds in > both directions between the same hosts using the same nics. > > The ppp.conf file for the server is: > default: > # set log Phase Chat LCP IPCP CCP tun command > enable mssfixup > set log error > ident user-ppp VERSION (built COMPILATIONDATE) > set dns 10.10.1.7 10.10.1.9 > accept dns > allow users > enable chap > enable pap > set timeout 0 > enable lqr > accept lqr > enable sroutes > > gta3: > allow mode direct > set mru 1492 > set mtu 1492 > set speed sync > set ifaddr 10.199.2.1 10.199.2.110-10.199.2.200 255.255.255.255 > > For the client I used the following ppp.conf > default: > set socket none > > PPP0: > set redial 0 0 > set timeout 0 > set reconnect 20 50000 > set ifaddr 0.0.0.0/0 0.0.0.0/0 > accept chap > disable pap > set authname testuser3 > set authkey testpass > set ctsrts off > enable dns > set dns 10.0.0.1 10.0.0.2 > resolv readonly > enable lqr > set lqrperiod 20 > accept lqr > accept acfcomp > accept protocomp > accept pred1 > accept vjcomp > set log error > set openmode active > enable mssfixup > set device PPPoE:fxp0:gta3 > set speed sync > set dial > set cd 10 > set login > set mru 1492 > set mtu 1492 > > > Thanks for your time, > Larry > > > -- > ------------------------------------------------------------------------ > Larry Baird | http://www.gnatbox.com > Global Technology Associates, Inc. | Orlando, FL > Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 15 1:46:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.engr.ucsb.edu (mail.engr.ucsb.edu [128.111.27.5]) by hub.freebsd.org (Postfix) with ESMTP id 0143D37B408 for ; Wed, 15 May 2002 01:46:31 -0700 (PDT) Received: from ecipc056.engr.ucsb.edu ([128.111.53.119]) by mail.engr.ucsb.edu with esmtp (Exim 3.11 #2) id 177uQX-0002yd-00 for freebsd-net@freebsd.org; Wed, 15 May 2002 01:46:29 -0700 Date: Wed, 15 May 2002 01:45:47 -0700 (PDT) From: Anshuman Kanwar X-X-Sender: To: Subject: 4.4 route add default problem 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 Summary: -------- The -ifp option in route add default does not seem to have any effect, and it is impossible to set a default route in certain conditions. Is there a work around for route in 4.4 ? Details -------- I have 2 interfaces (fxp0 and 1) on my FreeBSD box. Initially only one of the interfaces is UP. I am trying to write a high availability script that automatically flops over to the 2nd interface, when the active interface fails. Here is (roughly) what I am doing: # Bring failed interface down ifconfig $old_intf down # Clear ARP cache arp -a -d # Fail Over to Other Interface ifconfig $new_intf inet xx.xx.xx.xxx netmask 255.255.255.224 broadcast xx.xx.xxx.xxx # Delete old route route delete default # Bring new interface up ifconfig $new_intf up # Add new route route add -ifp $new_intf default $DEF_ROUTE <<<<<< (1) PROBLEM ------- After the interface fails over, the default route (1 above) still points out through the $old_intf. Here is a listing of netstat and ifconfig before and after the switch: before -------- Destination Gateway Flags Refs Use Netif Expire default 61.74.4.193 UGSc 4 487 fxp0 61.74.4.192/27 link#1 UC 1 0 fxp0 61.74.4.193 0:0:ac:7:ac:a4 UHLW 4 112 fxp0 955 127.0.0.1 127.0.0.1 UH 1 6 lo0 #ifconfig -a fxp0: flags=8843 mtu 1500 inet 61.74.4.212 netmask 0xffffffe0 broadcast 61.74.4.223 ether 00:02:b3:87:35:f2 media: Ethernet autoselect (100baseTX ) status: active fxp1: flags=8802 mtu 1500 inet 61.74.4.212 netmask 0xffffffe0 broadcast 61.74.4.223 ether 00:02:b3:87:35:f3 media: Ethernet autoselect (none) after ------- dell350-6# netstat -rn Destination Gateway Flags Refs Use Netif Expire default 64.74.4.193 UGSc 4 24 fxp0 <<<<< 61.74.4.192/27 link#2 UC 1 0 fxp1 61.74.4.193 0:0:c:7:ac:a4 UHLW 4 2 fxp1 1189 127.0.0.1 127.0.0.1 UH 1 6 lo0 # ifconfig -a fxp0: flags=8802 mtu 1500 inet 61.74.4.212 netmask 0xffffffe0 broadcast 61.74.4.223 ether 00:02:b3:87:35:f2 media: Ethernet autoselect (none) status: no carrier fxp1: flags=8843 mtu 1500 inet 61.74.4.212 netmask 0xffffffe0 broadcast 61.74.4.223 ether 00:02:b3:87:35:f3 media: Ethernet autoselect (100baseTX ) status: active In the second listing notice that the default route STILL points to the fxp0 interface which is down. I googled the topic but not of much avail. Does anyone have any idea what is happening and how to set the proper route? My system is: # uname -a FreeBSD host.nyc 4.4-RELEASE FreeBSD 4.4-RELEASE #0: Thu Apr 11 14:38:21 PDT 2002 Thanks for your time. -ansh. P.S. I am not on the list so please cc you reply. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 15 3:31:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail2.rol.it (mail2.rol.it [193.41.7.204]) by hub.freebsd.org (Postfix) with SMTP id 57C0437B408 for ; Wed, 15 May 2002 03:31:52 -0700 (PDT) From: subscribe_verba@logos.net To: freebsd-net@freebsd.org Subject: Verba Volant Message-Id: <20020515103152.57C0437B408@hub.freebsd.org> Date: Wed, 15 May 2002 03:31:52 -0700 (PDT) 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 following email address, "freebsd-net@freebsd.org" has been removed from the Verba Volant Newsletter list. If you did not cancel your email address or you wish to continue receiving Verba Volant, please send an e-mail to subscribe_verba@logos.net Thank you and best regards, Verba Volant To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 15 9: 6: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mighty.grot.org (mighty.grot.org [204.182.56.120]) by hub.freebsd.org (Postfix) with ESMTP id 8694637B400 for ; Wed, 15 May 2002 09:05:55 -0700 (PDT) Received: by mighty.grot.org (Postfix, from userid 515) id 1C0B05E7E; Wed, 15 May 2002 09:05:50 -0700 (PDT) Date: Wed, 15 May 2002 09:05:50 -0700 From: Aditya To: Anshuman Kanwar Cc: freebsd-net@freebsd.org Subject: Re: 4.4 route add default problem Message-ID: <20020515160549.GA37073@mighty.grot.org> Reply-To: Aditya References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.grot.org/pubkey.asc X-PGP-Key-ID: 0x6405D8D5 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, May 15, 2002 at 01:45:47AM -0700, Anshuman Kanwar wrote: > # Bring failed interface down > ifconfig $old_intf down why not move the route delete default here rather than later? > # Delete old route > route delete default > > # Clear ARP cache > arp -a -d > > # Fail Over to Other Interface > ifconfig $new_intf inet xx.xx.xx.xxx netmask 255.255.255.224 > broadcast xx.xx.xxx.xxx > > # Bring new interface up > ifconfig $new_intf up > > # Add new route > route add -ifp $new_intf default $DEF_ROUTE <<<<<< (1) and why do you need -ifp $new_intf here? Adi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 15 11:51:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from moab.cs.utah.edu (moab.cs.utah.edu [155.99.212.88]) by hub.freebsd.org (Postfix) with ESMTP id 7025537B40B for ; Wed, 15 May 2002 11:51:15 -0700 (PDT) Received: from localhost (bwhite@localhost) by moab.cs.utah.edu (8.9.1/8.9.1) with ESMTP id MAA28251; Wed, 15 May 2002 12:51:09 -0600 (MDT) Date: Wed, 15 May 2002 12:51:09 -0600 (MDT) From: Brian White To: mark tinguely Cc: freebsd-net@FreeBSD.ORG Subject: Re: FBSD 4.3 New Reno Fast Retransmit Behavior In-Reply-To: <200205061641.g46GfCX78428@web.cs.ndsu.nodak.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 I've been comparing simple ns drop experiments with FreeBSD. Based on your explanation (below), I've accounted for one difference and switched to FreeBSD 4.5. I'm seeing another discrepancy and would like to verify that it is intended behavior. Though this is related to my original questioning of False Fast Retransmit, I don't believe the explanation below covers it. I unearthed the Dec 2001 thread in -net you refer to which was either over my head or addresses a separate problem. Based on the code, the following reflects my understanding: After beginning a Fast Retransmit phase, FreeBSD will only send retransmissions while dupacks >= tcprextmthresh. Fast retransmissions occur in tcp_newreno, which is guarded by this conditional. Once a new ACK arrives during Fast Retransmit, dupacks is set to zero. Further, FreeBSD implements a False Fast Retransmit suppression algorithm, triggered when ++tp->t_dupacks == tcprexmtthresh and the current ACK is less than snd_recover. This algorithm sets dupacks to zero, ensuring that tcp_newreno can not fire. Therefore, no more Fast Retransmissions will occur until the Fast Retransmit phase ends. I believe this is consistent with Janey Hoe's discussion of False Fast Retransmits in section 3.2 of the SIGCOMM'96 paper. But is inconsistent with ns, which does not guard the tcp_newreno-equivalent partialnewack_helper. Thanks again. Brian On Mon, 6 May 2002, mark tinguely wrote: > > There seem to be two problematic cases. In the first, _both_ of these > > conditions fire in tcp_input.c: > > > > else if (++tp->t_dupacks == tcprexmtthresh) { > > > > and > > > > if (tcp_do_newreno && SEQ_LT(th->th_ack, > > tp->snd_recover)) { > > yes, this is a problem because FreeBSD 4.[34 and before?] did not > always initialized tp->snd_recover on the session startup and > presented a problem when the initial segment sequence is greater > than 0x7fffffff. > > The only other way to tigger this error is if you went half way > through the sequence without a duplicate ack. We talked about this > a little on -net and decided the prevention would have more overhead > than it would effectively cure. > > FreeBSD 4.5 and greater fixed the initialization of snd_recover with the > addition of the "syncache" code. > > FreeBSD 4.5 also fixed some serious socket errors that would cause more > even greater performance problems. I suggest you upgrade. > > --mark tinguely. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 15 12: 6:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from morphy.iki.fi (baana-pppoes-213-139-166-84.suomi.net [213.139.166.84]) by hub.freebsd.org (Postfix) with SMTP id 2276D37B40C for ; Wed, 15 May 2002 12:05:48 -0700 (PDT) Received: (qmail 14097 invoked by uid 1000); 15 May 2002 19:05:41 -0000 Date: Wed, 15 May 2002 22:05:41 +0300 From: Mikko Hyvarinen To: Lars Eggert Cc: net@freebsd.org, snap-users@kame.net Subject: Re: tun device & IPv6 Message-ID: <20020515220541.C95759@morphy.iki.fi> References: <3CE1A2C0.8050201@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: <3CE1A2C0.8050201@isi.edu>; from larse@ISI.EDU on Tue, May 14, 2002 at 04:50:24PM -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 Tue, May 14, 2002 at 04:50:24PM -0700, Lars Eggert wrote: > Hi, > > could someone with more knowledge of the tun device please take a look > at the code around line 387 in net/if_tun.c? It looks like tunoutput() > drops all packets here that aren't of the AF_INET family - most notably, > it drops IPv6 packets. > > We hacked around this with the simple fix below, but I'm not sure if > there are any drawbacks... > [clip] Is there a specific reason why you are not using the "multi-af" mode? IPv6 works just nicely with /usr/sbin/ppp (PPPoE), which uses if_tun in "multi-af" mode. Regards, Mikko -- All opinions expressed above are mine alone and do not express the views of my employer or any other organizations that I am affiliated with. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 15 13:23:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 5F19237B406 for ; Wed, 15 May 2002 13:23:01 -0700 (PDT) Received: from isi.edu (1f835yum9sb2nilf@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4FKMvF01536; Wed, 15 May 2002 13:22:57 -0700 (PDT) Message-ID: <3CE2C39A.2010803@isi.edu> Date: Wed, 15 May 2002 13:22:50 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Mikko Hyvarinen Cc: net@freebsd.org, snap-users@kame.net Subject: Re: tun device & IPv6 References: <3CE1A2C0.8050201@isi.edu> <20020515220541.C95759@morphy.iki.fi> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030207000104030401080906" 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. --------------ms030207000104030401080906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mikko Hyvarinen wrote: >>could someone with more knowledge of the tun device please take a look >>at the code around line 387 in net/if_tun.c? It looks like tunoutput() >>drops all packets here that aren't of the AF_INET family - most notably, >>it drops IPv6 packets. >> >>We hacked around this with the simple fix below, but I'm not sure if >>there are any drawbacks... >> > Is there a specific reason why you are not using the "multi-af" mode? > IPv6 works just nicely with /usr/sbin/ppp (PPPoE), which uses if_tun in > "multi-af" mode. The specific reason was that I didn't know about it :-) I'm currently patching net/vtund so it uses multi-af mode. Lars -- Lars Eggert USC Information Sciences Institute --------------ms030207000104030401080906 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC 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+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDUxNTIwMjI1MlowIwYJKoZIhvcNAQkEMRYEFFVRn4sJY7hrYGPNPFijfq6A63xaMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYBmv4Ea0vSrNN2sGE0CpT1FjUbOY1kQsCF//X+gBPYdGif1SZsyZa2dfkPMHQ9Yk+K4 6PQNCWc0G6Zs7gaPdQf+dHmRGYOeOn2JXUxUeQXlHz4SzHGrUiQ2kZBoCx3Gl965gsNgJXmW vtMHzxeCxR+Lm45j9QyUi1wZE80TgkIQdgAAAAAAAA== --------------ms030207000104030401080906-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 15 17:45: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by hub.freebsd.org (Postfix) with ESMTP id DFD1337B404 for ; Wed, 15 May 2002 17:44:57 -0700 (PDT) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.3/8.12.2) with ESMTP id g4G0iop7059218; Wed, 15 May 2002 20:44:50 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.3/8.12.3/Submit) id g4G0inis059217; Wed, 15 May 2002 20:44:49 -0400 (EDT) Date: Wed, 15 May 2002 20:44:49 -0400 From: Barney Wolff To: Anshuman Kanwar Cc: freebsd-net@FreeBSD.ORG Subject: Re: 4.4 route add default problem Message-ID: <20020515204449.A59148@tp.databus.com> References: 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 akanwar@engineering.ucsb.edu on Wed, May 15, 2002 at 01:45:47AM -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 If you want a stupid hack that I believe will work, do ifconfig fxp0 1.1.1.1 instead of downing it. That will delete the default route, as the address will not be reachable. You can then bring up fxp1 and add back the default route, which should be reachable through it. -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 16 5: 4:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp.completel.fr (smtp.completel.fr [213.244.0.12]) by hub.freebsd.org (Postfix) with ESMTP id 3AD9E37B404; Thu, 16 May 2002 05:04:06 -0700 (PDT) Received: from netasq.com (unknown [213.30.137.178]) by smtp.completel.fr (Postfix) with ESMTP id 45FD7179E71; Thu, 16 May 2002 14:03:58 +0200 (CEST) Received: from netasq.com by completel.fr (8.10.1/8.10.1) with ESMTP id g4GCAqJ01947; Thu, 16 May 2002 14:10:52 +0200 (CEST) Date: Thu, 16 May 2002 14:03:52 +0200 From: Fabien THOMAS X-Mailer: The Bat! (v1.60c) Organization: NETASQ X-Priority: 3 (Normal) Message-ID: <10168589031.20020516140352@netasq.com> To: freebsd-stable@freebsd.org Cc: freebsd-net@freebsd.org Subject: bge drivers does not work for 3COM 3C996-SX / 3C996B-T MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="----------F715B11A13651A97" 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. ------------F715B11A13651A97 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've some problems with bge driver with 3COM 3C996-SX fiber card and 3C996B-T copper card under -stable: The fiber card is detected correctly but the link does not go up (i've tested the same card between two Win2K and it works well). The copper card is detected but the link goes up/down and sometimes lock the machine (reboot is needed to restart) when i start a 'ping -i0 -q'. Does someone experienced the same problems ? for the missing splx: i think i've found a new one in bge_init: static void bge_init(xsc) void *xsc; { struct bge_softc *sc = xsc; struct ifnet *ifp; u_int16_t *m; int s; s = splimp(); ifp = &sc->arpcom.ac_if; if (ifp->if_flags & IFF_RUNNING) --> missing splx ? return; Fabien ------------F715B11A13651A97 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIGRgYJKoZIhvcNAQcCoIIGNzCCBjMCAQMxCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBHEw ggRtMIIDVaADAgECAgEEMA0GCSqGSIb3DQEBBQUAMIGRMQswCQYDVQQGEwJGUjENMAsGA1UECBME Tm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2ZSBkJ0FzY3ExLjAsBgNVBAoTJU5FVEFTUSAtIFNlY3Vy ZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkxJzAlBgNVBAsTHk5FVEFTUSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTAeFw0wMjAyMTkxNDQ4NDRaFw0wMzAyMTkxNDQ4NDRaMIHSMQswCQYDVQQGEwJGUjEN MAsGA1UECBMETm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2ZSBkJ0FzY3ExLjAsBgNVBAoTJU5ldEFz cSAtIFNlY3VyZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkxJzAlBgNVBAsTHk5ldEFzcSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTEWMBQGA1UEAxMNRmFiaWVuIFRIT01BUzEnMCUGCSqGSIb3DQEJARYY ZmFiaWVuLnRob21hc0BuZXRhc3EuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDnmO6H h5Nm3OOE7+k3zSP3/cWDBGbxVh5PInSwQeKW43cKKE0MH8Y5erHIhVVchaMRsvxBfJrB6T8s2vGN l+ZRnFVP2Ug8+xLYFFJONlkY1YnHTZJ/VGx/lsf2ZDR7ZKqgcnuvbrLra4Np062oED1xwEpzbJnT emmbOGTqscUvcwIDAQABo4IBDzCCAQswCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwHQYDVR0OBBYE FLJEqzTrOFxg8EONNUey1yGm2kWjMIG+BgNVHSMEgbYwgbOAFCcq6x3ZRNo6F3NqCSAgySWo+X+y oYGXpIGUMIGRMQswCQYDVQQGEwJGUjENMAsGA1UECBMETm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2 ZSBkJ0FzY3ExLjAsBgNVBAoTJU5FVEFTUSAtIFNlY3VyZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkx JzAlBgNVBAsTHk5FVEFTUSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBADARBglghkgBhvhCAQEE BAMCBaAwDQYJKoZIhvcNAQEFBQADggEBAERHjAkf5L/cZH/n0GTKyptbyr4ro7aGfOFyvyTCxeDN kL3v4gtD2itXx88JbThmsAHAiECjWhI8AUTBRsEpcPa9zbbQEnQqX+cdLnvgaZjCpAErSbrR3TN1 ToSahIFXYc5Ao+1K0fwMdZSmjbPS7J0gZPWdqLLFf214qOmMxAaw3zGRnSmcMUbwKGbfcyMT0KsK 7u82raxnKSgk/VzUzS26aXPbRHW4RguHOY40RLyyZJDjG883uBeOaOLvmmov5eFpcdkHlGav4wun 0ARGo1N/PUo+UntWkzPNWD1EXRxOE0iz3n7Bb8NwlS6A339TSi5lw14SfvbCg28QTfVGFKMxggGd MIIBmQIBATCBlzCBkTELMAkGA1UEBhMCRlIxDTALBgNVBAgTBE5vcmQxGjAYBgNVBAcTEVZpbGxl bmV1dmUgZCdBc2NxMS4wLAYDVQQKEyVORVRBU1EgLSBTZWN1cmUgSW50ZXJuZXQgQ29ubmVjdGl2 aXR5MScwJQYDVQQLEx5ORVRBU1EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAQQwCQYFKw4DAhoF AKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwIwYJKoZIhvcNAQkEMRYEFAV2hiawCrly/jwe dir/SCFrmJobMBwGCSqGSIb3DQEJBTEPFw0wMjA1MTYxMjAzNTJaMA0GCSqGSIb3DQEBAQUABIGA fAL2Kwhj+2A1b+VoG+JaR8AA5i0NY114rHKbqUnPNgjNExvZWXEmEGGUt/11qK+z7JOyQbdkHRgz lxWOIp1ZH3E+cBsFhOTx7YO3yaJ3MsXepp39kAjR7VRHDnJL2QCpS0yUWCHYfXQF/Fvq7nxdqywX AEzBXdYPCt5UMdFeh4c= ------------F715B11A13651A97-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 16 9:33: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from hottub.hottub.org (hottub.org [66.60.164.74]) by hub.freebsd.org (Postfix) with ESMTP id 2255B37B408 for ; Thu, 16 May 2002 09:32:58 -0700 (PDT) Received: by hottub.hottub.org (Postfix, from userid 1100) id E0B1E213BC; Thu, 16 May 2002 09:30:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hottub.hottub.org (Postfix) with ESMTP id D301B213BB for ; Thu, 16 May 2002 09:30:58 -0700 (PDT) Date: Thu, 16 May 2002 09:30:58 -0700 (PDT) From: Matthew Zahorik X-X-Sender: matt@hottub To: freebsd-net@freebsd.org Subject: IPsec and dynamically assigned IPs 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 All: I am unclear regarding spdadd arguments and my VPN setup. I'm attempting to replace Nortel's Contivity Extranet Client on Windows with a racoon/ipsec solution. I'm unsure if this is a "tunnel" or "transport" connection. I contact a fixed server at 205.173.93.x. This is a contivity switch. My client is an IP address assigned by RoadRunner. During IKE (user w/ SecureID hard token, aggressive mode) another IP address is assigned (3.179.89.x) by the contivity. How do I express this in spdadd so that I can fire off racoon? [client] 66.67.157.x (RoadRunner IP, dynamic, known at spdadd time) | [tunnel? endpoint] 3.179.89.x (dynamic, assigned during/after IKE) | { Internet } | [tunnel? endpoint] ?.?.?.? (fixed, traceroute shows 3.179.68.x 1st hop) | [server] 205.173.93.x (fixed, known at spdadd time) Thanks! - Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 16 16:20: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from ady.warpnet.ro (ady.warpnet.ro [217.156.25.2]) by hub.freebsd.org (Postfix) with ESMTP id 1501837B406; Thu, 16 May 2002 16:19:50 -0700 (PDT) Received: from localhost (ady@localhost) by ady.warpnet.ro (8.9.3/8.9.3) with ESMTP id CAA30507; Fri, 17 May 2002 02:17:45 +0300 (EEST) (envelope-from ady@freebsd.ady.ro) X-RAV-AntiVirus: This e-mail has been scanned for viruses on host: ady.warpnet.ro Date: Fri, 17 May 2002 02:17:45 +0300 (EEST) From: Adrian Penisoara X-Sender: ady@ady.warpnet.ro To: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: HEADS UP: ALTQ integration developer preview 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 We have started a "ALTQ integration in FreeBSD" project which is headed towards integrating Mr. Kejiro's ALTQ framework into FreeBSD 5.0-current (and perhaps 4-stable later). The FreeBSD Core Team has been advised and we have received on principle approval. We are looking for help with committing these bits to the CVS tree. Please have a look at the proposed ALTQ package for 5.0-current, which is found here: http://www.rofug.ro/projects/freebsd-altq/altq-freebsd-5.0-current-May14.tar.gz Installation details are found in the README file; for further details consult the documentation referenced below. Please send us any comments you have, your feedback is valuable. ALTQ integration implies some changes in the network drivers code and in the design of the the network queues management. Here is a summary of the ALTQ design document: The BSD systems need better output queueing abstraction to support packet scheduling (e.g., CBQ) or active queue management (e.g., RED). To introduce a new model, we need to convert the existing code to be conformant to the new model. But the problem is that there are too many drivers to convert all at once. This is a proposal that allows incremental transition to the new model. (If we are going to modify the existing drivers, we need to get it right.) The model is designed for ALTQ but it is general enough for other implementations so that we can make the driver conversion once and for all. The new model removes direct references to the fields within ifp->if_snd, and defines the following macros to manipulate ifp->if_snd: IFQ_ENQUEUE(ifq, m, err) IFQ_DEQUEUE(ifq, m) IFQ_POLL(ifq, m) IFQ_PURGE(ifq) IFQ_IS_EMPTY(ifq) The new model also enforces some rules regarding how to use these macros. Another requirement for a driver is to work under rate-limiting. - IFQ_DEQUEUE() could return NULL even when IFQ_IS_EMPTY() is FALSE under rate-limiting. a driver should always check if (m == NULL). - a driver is supposed to call if_start from the tx complete interrupt under late-limiting (in order to trigger the next dequeue). For most drivers, it is a simple task of replacing old-style lines by the corresponding new-style lines, and usually just a few lines need to be modified. But some drivers need more than that. The old-style drivers still work with the original FIFO queue but they cannot take advantage of new queueing disciplines. For locking an output queue to support SMP, ALTQ uses the same model as in FreeBSD-5.0. One restriction is that, if a driver uses poll-and-dequeue, the driver needs to explicitly lock the queue between the poll operation and the dequeue operation. You can find more details here: http://www.csl.sony.co.jp/person/kjc/kjc/software/altq-new-design.txt http://www.csl.sony.co.jp/person/kjc/kjc/software.html#ALTQ Current development is headed by Kenjiro Cho and myself. If you want to join our efforts please subscribe to our mailing list by sending "subscribe" in the body of a message to freebsd-altq-request@rofug.ro. Adrian Penisoara Ady (@freebsd.ady.ro, @rofug.ro) _______________________________________________________________________ | Programming in BASIC causes brain damage. | | (Edsger Wybe Dijkstra) | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 16 17:22:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from stono.cs.cofc.edu (stono.cs.cofc.edu [153.9.17.3]) by hub.freebsd.org (Postfix) with ESMTP id B4DA337B40A for ; Thu, 16 May 2002 17:22:30 -0700 (PDT) Received: from [153.9.17.27] (burton.cs.cofc.edu [153.9.17.27]) by stono.cs.cofc.edu (8.11.6/8.11.6) with ESMTP id g4H0JfG14302 for ; Thu, 16 May 2002 20:19:41 -0400 Mime-Version: 1.0 X-Sender: jimmy@stono.cs.cofc.edu Message-Id: Date: Thu, 16 May 2002 20:24:45 -0400 To: freebsd-net@freebsd.org From: "James B. Wilkinson" Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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've got to teach a new graduate course in networking this fall. I'm looking at using vol 1 and maybe vol 2 of "TCP/IP Illustrated" by Richard Stevens. The basic premise of the book seems to be to do experiments on a working network in order to learn about the protocols. One thing that I thought about doing is to have them do that sort of thing here as well as to read about what he did to do the book. It seemed useful to me to have some of the machines set up with a version of FreeBSD that let you fool around with what the IP and TCP layers were doing. E.g. introduce delays in the transmission of ack's so that packets get retransmitted or so that you can watch the RTT estimate catch up. Maybe pick out particular TCP segments and lose them. When I started looking at how one might do this, it seemed like it might be hard. So I got to wondering if somebody had already done it so that I don't have to. I have no idea how to do a Google search for something like that. Do any of you guys know about any software like that. I spose it would have to be a hacked version of a kernel. Thanks -- ------------------------------------------------------------- Jimmy Wilkinson | Perfesser of Computer Science jimmy@cs.CofC.edu | The College of Charleston (843) 953-8160 | Charleston SC 29424 If there is one word to describe me, that word would have to be "profectionist". Any form of incompitence is an athema to me. Metathesis??? Don't ax me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 16 20:34:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from cc.kmu.edu.tw (cc.kmu.edu.tw [163.15.154.1]) by hub.freebsd.org (Postfix) with ESMTP id 90E0737B40B for ; Thu, 16 May 2002 20:34:16 -0700 (PDT) Received: from cc.kmu.edu.tw (c198.cc.kmu.edu.tw [163.15.154.198]) by cc.kmu.edu.tw (8.11.6/8.11.6) with ESMTP id g4H3XvQ91848 for ; Fri, 17 May 2002 11:33:58 +0800 (CST) (envelope-from cch@cc.kmu.edu.tw) Message-ID: <3CE47A2B.70807@cc.kmu.edu.tw> Date: Fri, 17 May 2002 11:34:03 +0800 From: Chih-Chang Hsieh Reply-To: cch@cc.kmu.edu.tw Organization: KMU Computer Center User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc2) Gecko/20020514 X-Accept-Language: zh-tw, en-us MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Subject: A question about racoon with multi-homed IPSec box Content-Type: text/plain; charset=Big5 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 We are setting up two tunneled-IPSec VPN boxes. One of the boxes has 2 IPs, and another one (plus firewall functions) has 3. Could someone tell us how to assign a local address for racoon to bind? Because the 3-IP box's outgoing interface is assigned by a private IP which connects to a router. But we want racoon to bind the public IP. Thanks in advance! -- Chih-Chang Hsieh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 16 20:43: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from garple.migus.org (pcp243391pcs.howard01.md.comcast.net [68.55.83.143]) by hub.freebsd.org (Postfix) with ESMTP id 238DC37B409 for ; Thu, 16 May 2002 20:42:53 -0700 (PDT) Received: from ganyopa (ganyopa.migus.org [192.168.4.2]) by garple.migus.org (8.12.2/8.12.2) with SMTP id g4H3h4cq014421 for ; Thu, 16 May 2002 23:43:04 -0400 (EDT) From: "Adam Migus" To: Subject: RE: Date: Thu, 16 May 2002 23:42:40 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal 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 James, You could use dummynet(4) to introduce delays, limit throughput, etc. You could also play with the various sysctl(8) variables. net.inet.ip.rtexpire net.inet.ip.rtminexpire net.inet.ip.rtmaxcache net.inet.tcp.delacktime net.inet.tcp.delayed_ack Just to name a few. Trying doing: sysctl -A | grep "net.inet" You can even mess around with some of the ipc related variables: sysctl -A | grep "kern.ipc" You should be able to manipulate the stack enough with that but there is always the source. :-) -- Adam Migus (adam@migus.org) (amigus@FreeBSD.org) FreeBSD (http://www.freebsd.org) | The Power to Serve -----Original Message----- From: owner-freebsd-net@FreeBSD.ORG [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of James B. Wilkinson Sent: Thursday, May 16, 2002 8:25 PM To: freebsd-net@FreeBSD.ORG Subject: I've got to teach a new graduate course in networking this fall. I'm looking at using vol 1 and maybe vol 2 of "TCP/IP Illustrated" by Richard Stevens. The basic premise of the book seems to be to do experiments on a working network in order to learn about the protocols. One thing that I thought about doing is to have them do that sort of thing here as well as to read about what he did to do the book. It seemed useful to me to have some of the machines set up with a version of FreeBSD that let you fool around with what the IP and TCP layers were doing. E.g. introduce delays in the transmission of ack's so that packets get retransmitted or so that you can watch the RTT estimate catch up. Maybe pick out particular TCP segments and lose them. When I started looking at how one might do this, it seemed like it might be hard. So I got to wondering if somebody had already done it so that I don't have to. I have no idea how to do a Google search for something like that. Do any of you guys know about any software like that. I spose it would have to be a hacked version of a kernel. Thanks -- ------------------------------------------------------------- Jimmy Wilkinson | Perfesser of Computer Science jimmy@cs.CofC.edu | The College of Charleston (843) 953-8160 | Charleston SC 29424 If there is one word to describe me, that word would have to be "profectionist". Any form of incompitence is an athema to me. Metathesis??? Don't ax me. 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 May 16 21: 9:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 9D82C37B40B for ; Thu, 16 May 2002 21:09:02 -0700 (PDT) Received: from keg (c1-vpn1.isi.edu [128.9.176.27]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4H492F23608; Thu, 16 May 2002 21:09:02 -0700 (PDT) From: "Lars Eggert" To: "'Matthew Zahorik'" , Subject: RE: IPsec and dynamically assigned IPs Date: Thu, 16 May 2002 21:08:58 -0700 Organization: USC Information Sciences Institute MIME-Version: 1.0 Message-ID: <001501c1fd58$91abf680$b27ba8c0@isi.edu> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0010_01C1FD1D.E484EC80" In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 multi-part message in MIME format. ------=_NextPart_000_0010_01C1FD1D.E484EC80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > I'm attempting to replace Nortel's Contivity Extranet > Client on Windows with a racoon/ipsec solution. > > I'm unsure if this is a "tunnel" or "transport" connection. I can't help you with the racoon part, but as for tunnel vs. transport mode: If it isn't end-to-end, it's tunnel mode. Transport mode is allowed between a host pair only. Lars -- Lars Eggert USC Information Sciences Institute ------=_NextPart_000_0010_01C1FD1D.E484EC80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJFzCCArUw ggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEPMA0GA1UEBBMGRWdnZXJ0 MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFy c2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0AvLBsD78nxcUHeHkaMgl3b4 qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD11uZDy4CNNJUu3gKxKSb+zRV70O+lkwwf tuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcUSF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEA AaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREE ETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQ A8zI7U2K1ZIAl11j0a1DKxnp3GtTvOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2 OhB+jeKEqY7IDAJE4/fI0e+d6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4 fdcOo1S34r4wggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5WjCB kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y 8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtU ihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN AQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONnt UPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2 lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqADAgECAgEAMA0GCSqGSIb3DQEBBAUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x GjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcN MjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1 KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZ FKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMwETAPBgNVHRMB Af8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVc CM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx +NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMYIDaTCCA2UCAQEwgZow gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93 bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggIkMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDUxNzA0MDg1N1owIwYJ KoZIhvcNAQkEMRYEFAFFBGXeGmdvlZDm4JuUpbb1etp0MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwBwYFKw4DAhowDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMG VGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkG A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYD VQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJz b25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEBBQAEgYBL6Mz64iOV aFIwCfeR9t06eEJKkmLWQiBsaBvy2tHPgk/HnaGgSW0mlTiSCi9xvHxFMt5NQpRp++3H3gC+7lUA ZLkjIUKxrGVpirTD8qF6tYJwI2Ti3Wn7LLU00/bAE7X64yV6H5d6vidydd6BYKwirECvDm0ZflL2 Wf0v1knj/AAAAAAAAA== ------=_NextPart_000_0010_01C1FD1D.E484EC80-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 16 22:30:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id A8A9637B406 for ; Thu, 16 May 2002 22:30:18 -0700 (PDT) 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 WAA35123; Thu, 16 May 2002 22:16:10 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g4H5Fqe36428; Thu, 16 May 2002 22:15:52 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205170515.g4H5Fqe36428@arch20m.dellroad.org> Subject: Re: A question about racoon with multi-homed IPSec box In-Reply-To: <3CE47A2B.70807@cc.kmu.edu.tw> "from Chih-Chang Hsieh at May 17, 2002 11:34:03 am" To: cch@cc.kmu.edu.tw Date: Thu, 16 May 2002 22:15:52 -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 Chih-Chang Hsieh writes: > Could someone tell us how to assign a local address for > racoon to bind? Because the 3-IP box's outgoing interface > is assigned by a private IP which connects to a router. > But we want racoon to bind the public IP. man racoon.conf... listen { isakmp x.x.x.x; <-- your ip address goes here } -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 Thu May 16 22:48:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from cc.kmu.edu.tw (cc.kmu.edu.tw [163.15.154.1]) by hub.freebsd.org (Postfix) with ESMTP id BD71937B40E for ; Thu, 16 May 2002 22:48:18 -0700 (PDT) Received: from cc.kmu.edu.tw (c198.cc.kmu.edu.tw [163.15.154.198]) by cc.kmu.edu.tw (8.11.6/8.11.6) with ESMTP id g4H5mCQ03304; Fri, 17 May 2002 13:48:13 +0800 (CST) (envelope-from cch@cc.kmu.edu.tw) Message-ID: <3CE499A3.8030807@cc.kmu.edu.tw> Date: Fri, 17 May 2002 13:48:19 +0800 From: Chih-Chang Hsieh Reply-To: cch@cc.kmu.edu.tw Organization: KMU Computer Center User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc2) Gecko/20020514 X-Accept-Language: zh-tw, en-us MIME-Version: 1.0 To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: A question about racoon with multi-homed IPSec box References: <200205170515.g4H5Fqe36428@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 Archie Cobbs wrote: > Chih-Chang Hsieh writes: > >>Could someone tell us how to assign a local address for >>racoon to bind? Because the 3-IP box's outgoing interface >>is assigned by a private IP which connects to a router. >>But we want racoon to bind the public IP. > > man racoon.conf... > > listen > { > isakmp x.x.x.x; <-- your ip address goes here > } Sorry, I forgot to say that we had tried this. But it not works. :( We are using racoon-20020507a. Anyway, thank you very much. -- Chih-Chang Hsieh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 17 1: 6:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.dev.itouchnet.net (devco.net [196.15.188.2]) by hub.freebsd.org (Postfix) with ESMTP id 08DCD37B40A for ; Fri, 17 May 2002 01:06:16 -0700 (PDT) Received: from nobody by mx1.dev.itouchnet.net with scanned_ok (Exim 3.33 #2) id 178cp8-000EwV-00 for freebsd-net@freebsd.org; Fri, 17 May 2002 10:10:50 +0200 Received: from shell.devco.net ([196.15.188.7]) by mx1.dev.itouchnet.net with esmtp (Exim 3.33 #2) id 178cp4-000Ew8-00; Fri, 17 May 2002 10:10:46 +0200 Received: from bvi by shell.devco.net with local (Exim 3.33 #4) id 178cke-00074K-00; Fri, 17 May 2002 10:06:12 +0200 Date: Fri, 17 May 2002 10:06:12 +0200 From: Barry Irwin To: Chih-Chang Hsieh Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG Subject: Re: A question about racoon with multi-homed IPSec box Message-ID: <20020517100612.G17719@itouchlabs.com> References: <200205170515.g4H5Fqe36428@arch20m.dellroad.org> <3CE499A3.8030807@cc.kmu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CE499A3.8030807@cc.kmu.edu.tw>; from cch@cc.kmu.edu.tw on Fri, May 17, 2002 at 01:48:19PM +0800 X-Checked: This message has been scanned for any virusses and unauthorized attachments. X-iScan-ID: 57439-1021623049-04073@mx1.dev.itouchnet.net version $Name: REL_2_0_2 $ 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 2002-05-17 (13:48), Chih-Chang Hsieh wrote: > Archie Cobbs wrote: > > Chih-Chang Hsieh writes: > > > >>Could someone tell us how to assign a local address for > >>racoon to bind? Because the 3-IP box's outgoing interface > >>is assigned by a private IP which connects to a router. > >>But we want racoon to bind the public IP. > > > > man racoon.conf... > > > > listen > > { > > isakmp x.x.x.x; <-- your ip address goes here > > } > > Sorry, I forgot to say that we had tried this. > > But it not works. :( We are using racoon-20020507a. > > Anyway, thank you very much. I am running this on a number of my production firewalls and in cases where I ahev specifically bound and IP for Racoon to use it works. In most Cases I let it bind all interfaces - in which case the interface 'closest' to the other system is used. Where this doesnt work, and where I assume you are having the problem si swhere you have two IP's bound to an interface and you want racoon to use an IP that is not the primary bound address on the interface. racoon-20010322a KAME racoon IKE daemon racoon-20011215a KAME racoon IKE daemon Barry -- Barry Irwin bvi@itouchlabs.com +27214875177 Systems Administrator: Networks And Security Itouch Labs http://www.itouchlabs.com South Africa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 17 1:58:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id 88B9B37B40A for ; Fri, 17 May 2002 01:58:54 -0700 (PDT) Received: (qmail 2557 invoked by uid 1000); 17 May 2002 09:00:02 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 17 May 2002 09:00:02 -0000 Date: Fri, 17 May 2002 11:00:02 +0200 (CEST) From: Attila Nagy To: Adrian Penisoara Cc: freebsd-arch@freebsd.org, Subject: Re: HEADS UP: ALTQ integration developer preview In-Reply-To: Message-ID: References: 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, > We have started a "ALTQ integration in FreeBSD" project which is > headed towards integrating Mr. Kejiro's ALTQ framework into FreeBSD > 5.0-current (and perhaps 4-stable later). The FreeBSD Core Team has been > advised and we have received on principle approval. We are looking for > help with committing these bits to the CVS tree. Great. Do you have plans to merge OpenBSD's TCP_ECN stuff, committed yesterday to the tree? > Please have a look at the proposed ALTQ package for 5.0-current, which > is found here: > http://www.rofug.ro/projects/freebsd-altq/altq-freebsd-5.0-current-May14.tar.gz Although I'm not a coder myself, I would also look for the way to patch the "em" driver (if "gx" is already in the initial plan), because it reportedly works better (for example I couldn't do NFS serving with UDP packets bigger than the MTU with that, while the "em" driver works OK). Thanks! --------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 17 2:20:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from ady.warpnet.ro (ady.warpnet.ro [217.156.25.2]) by hub.freebsd.org (Postfix) with ESMTP id D5D0337B405 for ; Fri, 17 May 2002 02:20:16 -0700 (PDT) Received: from localhost (ady@localhost) by ady.warpnet.ro (8.9.3/8.9.3) with ESMTP id MAA65309; Fri, 17 May 2002 12:18:09 +0300 (EEST) (envelope-from ady@freebsd.ady.ro) X-RAV-AntiVirus: This e-mail has been scanned for viruses on host: ady.warpnet.ro Date: Fri, 17 May 2002 12:18:09 +0300 (EEST) From: Adrian Penisoara X-Sender: ady@ady.warpnet.ro To: Attila Nagy Cc: freebsd-net@freebsd.org, freebsd-altq list Subject: Re: HEADS UP: ALTQ integration developer preview 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 Hi, On Fri, 17 May 2002, Attila Nagy wrote: > > We have started a "ALTQ integration in FreeBSD" project which is > > headed towards integrating Mr. Kejiro's ALTQ framework into FreeBSD > > 5.0-current (and perhaps 4-stable later). The FreeBSD Core Team has been > > advised and we have received on principle approval. We are looking for > > help with committing these bits to the CVS tree. > Great. Do you have plans to merge OpenBSD's TCP_ECN stuff, committed > yesterday to the tree? Thanks for the pointer ! I don't know yet if we will merge it, but be sure we will review it. BTW, who does the integration/maintainance of ALTQ in OpenBSD ? > > > Please have a look at the proposed ALTQ package for 5.0-current, which > > is found here: > > http://www.rofug.ro/projects/freebsd-altq/altq-freebsd-5.0-current-May14.tar.gz > Although I'm not a coder myself, I would also look for the way to patch > the "em" driver (if "gx" is already in the initial plan), because it > reportedly works better (for example I couldn't do NFS serving with UDP > packets bigger than the MTU with that, while the "em" driver works OK). Our goal is to have _all_ the drivers modified and new drivers to use by default the new queueing handling scheme :). Ady (@freebsd.ady.ro) _______________________________________________________________________ | Programming in BASIC causes brain damage. | | (Edsger Wybe Dijkstra) | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 17 2:52: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from inetfw.csl.sony.co.jp (inetfw.SonyCSL.CO.JP [218.216.66.146]) by hub.freebsd.org (Postfix) with ESMTP id E778F37B403 for ; Fri, 17 May 2002 02:51:56 -0700 (PDT) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.11.6+3.4W/3.7Ws3/inetfw/2001101620/smtpfeed 1.12) with ESMTP id g4H9ps081369; Fri, 17 May 2002 18:51:54 +0900 (JST) Received: from localhost (hotaka.csl.sony.co.jp [43.27.101.57] (may be forged)) by hotaka.csl.sony.co.jp (8.11.6+3.4W/3.7Ws3/hotaka/2000061722) with ESMTP id g4H9psn26807; Fri, 17 May 2002 18:51:54 +0900 (JST) Date: Fri, 17 May 2002 18:51:54 +0900 (JST) Message-Id: <20020517.185154.68053992.kjc@csl.sony.co.jp> To: ady@freebsd.ady.ro Cc: bra@fsn.hu, freebsd-net@freebsd.org, freebsd-altq@rofug.ro Subject: Re: HEADS UP: ALTQ integration developer preview From: Kenjiro Cho In-Reply-To: References: X-Mailer: Mew version 2.2 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii 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 Adrian Penisoara wrote: > On Fri, 17 May 2002, Attila Nagy wrote: > > > We have started a "ALTQ integration in FreeBSD" project which is > > > headed towards integrating Mr. Kejiro's ALTQ framework into FreeBSD > > > 5.0-current (and perhaps 4-stable later). The FreeBSD Core Team has been > > > advised and we have received on principle approval. We are looking for > > > help with committing these bits to the CVS tree. > > Great. Do you have plans to merge OpenBSD's TCP_ECN stuff, committed > > yesterday to the tree? > > Thanks for the pointer ! > I don't know yet if we will merge it, but be sure we will review it. ECN support in TCP is independent from ALTQ, and it can be done separately. An ECN patch for 4.5 which doesn't require ALTQ is included in altq-3.1. It's been in KAME since December. If there are interests, I can make a patch for -current. > BTW, who does the integration/maintainance of ALTQ in OpenBSD ? I do. -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 17 3:22:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.dev.itouchnet.net (devco.net [196.15.188.2]) by hub.freebsd.org (Postfix) with ESMTP id 8B6EF37B404 for ; Fri, 17 May 2002 03:22:36 -0700 (PDT) Received: from nobody by mx1.dev.itouchnet.net with scanned_ok (Exim 3.33 #2) id 178ex3-000IZr-00 for freebsd-net@freebsd.org; Fri, 17 May 2002 12:27:09 +0200 Received: from shell.devco.net ([196.15.188.7]) by mx1.dev.itouchnet.net with esmtp (Exim 3.33 #2) id 178ex1-000IZb-00; Fri, 17 May 2002 12:27:07 +0200 Received: from bvi by shell.devco.net with local (Exim 3.33 #4) id 178esa-0007Sr-00; Fri, 17 May 2002 12:22:32 +0200 Date: Fri, 17 May 2002 12:22:32 +0200 From: Barry Irwin To: Matthew Zahorik Cc: freebsd-net@freebsd.org Subject: Re: IPsec and dynamically assigned IPs Message-ID: <20020517122232.A28402@itouchlabs.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from matt@hottub.org on Thu, May 16, 2002 at 09:30:58AM -0700 X-Checked: This message has been scanned for any virusses and unauthorized attachments. X-iScan-ID: 71411-1021631228-21120@mx1.dev.itouchnet.net version $Name: REL_2_0_2 $ 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 Thu 2002-05-16 (09:30), Matthew Zahorik wrote: > I am unclear regarding spdadd arguments and my VPN setup. > > I'm attempting to replace Nortel's Contivity Extranet Client on Windows > with a racoon/ipsec solution. > > I'm unsure if this is a "tunnel" or "transport" connection. > > I contact a fixed server at 205.173.93.x. This is a contivity switch. > My client is an IP address assigned by RoadRunner. > > During IKE (user w/ SecureID hard token, aggressive mode) another IP > address is assigned (3.179.89.x) by the contivity. > > How do I express this in spdadd so that I can fire off racoon? > > > [client] 66.67.157.x (RoadRunner IP, dynamic, known at spdadd time) > | > [tunnel? endpoint] 3.179.89.x (dynamic, assigned during/after IKE) > | > { Internet } > | > [tunnel? endpoint] ?.?.?.? (fixed, traceroute shows 3.179.68.x 1st hop) > | > [server] 205.173.93.x (fixed, known at spdadd time) If it is two endpoints talking directly then its transport mode Tunnel would be somethign along the lines of: A [client] -[vpn gw] - {internet} - [vpngw] - [server] or B [client] - {internet} - [vpngw] - [server] In case A, the client and server are completely unaware of the fact there is IPSEC involved, as all the work is performed by the gateways. in case B the client tunnels traffic destined for server to the vpngw where it is decapsulated adn passed onto the server. On the case of dynamic IP's have a look at the "generate policy on;" statement in racoon.conf. However you either need to authenticte using aggressive mode ( in which case you can provide a username or somethign else to look up against the password) or main mode using certificates. On another point, I spent a couple of days hacking around with the Nortel Client and didnt have much success :< would be great to hear if you do Barry -- Barry Irwin bvi@itouchlabs.com +27214875177 Systems Administrator: Networks And Security Itouch Labs http://www.itouchlabs.com South Africa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 17 3:40:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id BF91C37B403 for ; Fri, 17 May 2002 03:40:32 -0700 (PDT) Received: (qmail 3622 invoked by uid 1000); 17 May 2002 10:41:41 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 17 May 2002 10:41:41 -0000 Date: Fri, 17 May 2002 12:41:41 +0200 (CEST) From: Attila Nagy To: Kenjiro Cho Cc: ady@freebsd.ady.ro, , Subject: Re: HEADS UP: ALTQ integration developer preview In-Reply-To: <20020517.185154.68053992.kjc@csl.sony.co.jp> Message-ID: References: <20020517.185154.68053992.kjc@csl.sony.co.jp> 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, > ECN support in TCP is independent from ALTQ, and it can be done > separately. An ECN patch for 4.5 which doesn't require ALTQ is included > in altq-3.1. It's been in KAME since December. If there are interests, > I can make a patch for -current. I think it would be very good to catch up on that front. Thanks a lot. --------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 17 7:42:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from arjun.niksun.com (gwnew.niksun.com [63.148.27.34]) by hub.freebsd.org (Postfix) with ESMTP id CC7BA37B40A for ; Fri, 17 May 2002 07:42:05 -0700 (PDT) Received: from there (localhost.niksun.com [127.0.0.1]) by arjun.niksun.com (8.9.3/8.9.3) with SMTP id KAA15877; Fri, 17 May 2002 10:41:52 -0400 (EDT) (envelope-from arao@niksun.com) Message-Id: <200205171441.KAA15877@arjun.niksun.com> Content-Type: text/plain; charset="iso-8859-1" From: Amit Rao To: jimmy@CS.cofc.EDU Subject: for networking course exercises Re: [freebsd-net] Date: Fri, 17 May 2002 10:45:59 -0400 X-Mailer: KMail [version 1.3.2] References: <1021596067.311.91849.m12@yahoogroups.com> In-Reply-To: <1021596067.311.91849.m12@yahoogroups.com> Cc: freebsd-net@freebsd.org MIME-Version: 1.0 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 Jimmy, Take a look at http://www.netlab.ohio-state.edu/cise/ On Thursday 16 May 2002 08:41 pm, you wrote: >    Date: Thu, 16 May 2002 20:24:45 -0400 >    From: "James B. Wilkinson" > Subject: (unknown) > > I've got to teach a new graduate course in networking this fall. I'm > looking at using vol 1 and maybe vol 2 of "TCP/IP Illustrated" by > Richard Stevens. The basic premise of the book seems to be to do > experiments on a working network in order to learn about the > protocols. One thing that I thought about doing is to have them do > that sort of thing here as well as to read about what he did to do > the book. It seemed useful to me to have some of the machines set up > with a version of FreeBSD that let you fool around with what the IP > and TCP layers were doing. E.g. introduce delays in the transmission > of ack's so that packets get retransmitted or so that you can watch > the RTT estimate catch up. Maybe pick out particular TCP segments and > lose them. When I started looking at how one might do this, it seemed > like it might be hard. So I got to wondering if somebody had already > done it so that I don't have to. I have no idea how to do a Google > search for something like that. > > Do any of you guys know about any software like that. I spose it > would have to be a hacked version of a kernel. > > Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 17 8:19:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from hottub.hottub.org (hottub.org [66.60.164.74]) by hub.freebsd.org (Postfix) with ESMTP id 5198E37B40A for ; Fri, 17 May 2002 08:19:24 -0700 (PDT) Received: by hottub.hottub.org (Postfix, from userid 1100) id DCFC8213BC; Fri, 17 May 2002 08:17:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hottub.hottub.org (Postfix) with ESMTP id D07EC213BB; Fri, 17 May 2002 08:17:22 -0700 (PDT) Date: Fri, 17 May 2002 08:17:22 -0700 (PDT) From: Matthew Zahorik X-X-Sender: matt@hottub To: Barry Irwin Cc: freebsd-net@freebsd.org Subject: Re: IPsec and dynamically assigned IPs In-Reply-To: <20020517122232.A28402@itouchlabs.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 Fri, 17 May 2002, Barry Irwin wrote: > B [client] - {internet} - [vpngw] - [server] It would be a tunnel like B. The "[vpngw]" on the client side is software running on the client. The "[vpngw]" on the other side is a contivity switch. I'm trying to reach servers on the other side of the contivity. > On the case of dynamic IP's have a look at the "generate policy on;" > statement in racoon.conf. However you either need to authenticte using > aggressive mode ( in which case you can provide a username or somethign else > to look up against the password) or main mode using certificates. I'm pretty confident about racoon configuration. spdadd (seems to) require(s) fixed tunnel endpoints before I can start racoon, and that's the mystery. When I have a spare moment (not this week) I'll futz with spdadd and see if giving bogus values to spdadd to start and then using generate policy on; will work. Thanks for the replies! - Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 17 11: 1:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d68.as4.nwbl0.wi.voyager.net [169.207.137.68]) by hub.freebsd.org (Postfix) with ESMTP id A919437B400 for ; Fri, 17 May 2002 11:01:34 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.3/8.12.3) with ESMTP id g4HHxHUm024870; Fri, 17 May 2002 12:59:17 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.3/8.12.3/Submit) with ESMTP id g4HHwVHX024867; Fri, 17 May 2002 12:58:35 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Fri, 17 May 2002 12:58:31 -0500 (CDT) From: Mike Silbersack To: Kenjiro Cho Cc: ady@freebsd.ady.ro, , , Subject: Re: HEADS UP: ALTQ integration developer preview In-Reply-To: <20020517.185154.68053992.kjc@csl.sony.co.jp> Message-ID: <20020517125609.O24469-100000@patrocles.silby.com> 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 Fri, 17 May 2002, Kenjiro Cho wrote: > ECN support in TCP is independent from ALTQ, and it can be done > separately. > An ECN patch for 4.5 which doesn't require ALTQ is included in > altq-3.1. It's been in KAME since December. > If there are interests, I can make a patch for -current. Personally, I hope we keep ECN support out of the tree; it's unlikely to provide any benefit over the internet in general, and will just make integrating other TCP changes more difficult. I haven't looked over the ALTQ patches, but integration of those changes sounds like a good idea. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 17 12:32:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 11B2237B40D; Fri, 17 May 2002 12:32:20 -0700 (PDT) Received: from pool0392.cvx22-bradley.dialup.earthlink.net ([209.179.199.137] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 178nST-0003Jv-00; Fri, 17 May 2002 12:32:09 -0700 Message-ID: <3CE55A9B.73EA3DE4@mindspring.com> Date: Fri, 17 May 2002 12:31:39 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Attila Nagy Cc: Adrian Penisoara , freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: HEADS UP: ALTQ integration developer preview References: Content-Type: text/plain; charset=us-ascii 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 Attila Nagy wrote: > Although I'm not a coder myself, I would also look for the way to patch > the "em" driver (if "gx" is already in the initial plan), because it > reportedly works better (for example I couldn't do NFS serving with UDP > packets bigger than the MTU with that, while the "em" driver works OK). ??? It *does* frag packets bigger than the MTU, right? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 17 22:39:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id D8CC337B408; Fri, 17 May 2002 22:39:51 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g4I5dot36191; Fri, 17 May 2002 23:39:50 -0600 (MDT) (envelope-from ken) Date: Fri, 17 May 2002 23:39:50 -0600 From: "Kenneth D. Merry" To: current@FreeBSD.org Cc: net@FreeBSD.org Subject: new zero copy sockets patches available Message-ID: <20020517233950.A36169@panzer.kdm.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 I have released a new set of zero copy sockets patches, against -current from today (May 17th, 2002). The main change is to deal with the vfs_ioopt changes that Alan Cox made in kern_subr.c. (They conflicted a bit with the zero copy receive code.) The patches and the FAQ are available here: http://people.freebsd.org/~ken/zero_copy/ Comments, questions and reviews are all welcome! Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 17 22:45: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 4501937B406 for ; Fri, 17 May 2002 22:45:03 -0700 (PDT) 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 WAA43342; Fri, 17 May 2002 22:30:14 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g4I5TqI41036; Fri, 17 May 2002 22:29:52 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205180529.g4I5TqI41036@arch20m.dellroad.org> Subject: Re: IPsec and dynamically assigned IPs In-Reply-To: <20020517122232.A28402@itouchlabs.com> "from Barry Irwin at May 17, 2002 12:22:32 pm" To: Barry Irwin Date: Fri, 17 May 2002 22:29:52 -0700 (PDT) Cc: Matthew Zahorik , 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 Barry Irwin writes: > On another point, I spent a couple of days hacking around with the Nortel > Client and didnt have much success :< would be great to hear if you do It is not normally possible to get the Nortel client to work with non-Nortel IPSec servers because they purposefully mangle the shared secret in a proprietary way so that their clients only work with their servers. The Nortel clients come free; they make money by selling the server (not other companies' servers :-) -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 Fri May 17 23: 3: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id E877937B403; Fri, 17 May 2002 23:02:55 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id B9EA6AE1FB; Fri, 17 May 2002 23:02:55 -0700 (PDT) Date: Fri, 17 May 2002 23:02:55 -0700 From: Alfred Perlstein To: "Kenneth D. Merry" Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: new zero copy sockets patches available Message-ID: <20020518060255.GN20683@elvis.mu.org> References: <20020517233950.A36169@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020517233950.A36169@panzer.kdm.org> User-Agent: Mutt/1.3.27i 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 * Kenneth D. Merry [020517 22:40] wrote: > > I have released a new set of zero copy sockets patches, against -current > from today (May 17th, 2002). > > The main change is to deal with the vfs_ioopt changes that Alan Cox made in > kern_subr.c. (They conflicted a bit with the zero copy receive code.) > > The patches and the FAQ are available here: > > http://people.freebsd.org/~ken/zero_copy/ > > Comments, questions and reviews are all welcome! jumbo_vm_init() has a bunch of bugs first it doesn't work right if called concurrently. you need to protect the initialization of jumbo_vm_object otherwise bad things can happen. my suggestion is to store the results of vm_object_allocate into a temporary, grab the mutex and then check to see if jumbo_vm_object has been initialized again if it has then free the object, otherwise store the allocated object into the global and continue. you may not call malloc(9) with M_WAITOK while holding a mutex. --- entry = jumbo_kmap_inuse.slh_first; I'm sure that should use a list macro. --- That's all I see off the bat. :) Looks cool though. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 17 23:31:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 46D8F37B400; Fri, 17 May 2002 23:30:49 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g4I6UkX36632; Sat, 18 May 2002 00:30:46 -0600 (MDT) (envelope-from ken) Date: Sat, 18 May 2002 00:30:46 -0600 From: "Kenneth D. Merry" To: Alfred Perlstein Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: new zero copy sockets patches available Message-ID: <20020518003046.A36510@panzer.kdm.org> References: <20020517233950.A36169@panzer.kdm.org> <20020518060255.GN20683@elvis.mu.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: <20020518060255.GN20683@elvis.mu.org>; from bright@mu.org on Fri, May 17, 2002 at 11:02:55PM -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 Fri, May 17, 2002 at 23:02:55 -0700, Alfred Perlstein wrote: > * Kenneth D. Merry [020517 22:40] wrote: > > > > I have released a new set of zero copy sockets patches, against -current > > from today (May 17th, 2002). > > > > The main change is to deal with the vfs_ioopt changes that Alan Cox made in > > kern_subr.c. (They conflicted a bit with the zero copy receive code.) > > > > The patches and the FAQ are available here: > > > > http://people.freebsd.org/~ken/zero_copy/ > > > > Comments, questions and reviews are all welcome! > > jumbo_vm_init() has a bunch of bugs > > first it doesn't work right if called concurrently. > you need to protect the initialization of jumbo_vm_object otherwise > bad things can happen. my suggestion is to store the results of > vm_object_allocate into a temporary, grab the mutex and then check > to see if jumbo_vm_object has been initialized again if it has then > free the object, otherwise store the allocated object into the > global and continue. The problem here is that the mutex needs to be initialized before I can acquire it, and there's going to be a race between checking to see whether it has been initialized and actually initializing it. e.g.: if (!mtx_initialized(&jumbo_mutex)) mtx_init(&jumbo_mutex, "jumbo mutex", NULL, MTX_DEF); mtx_lock(&jumbo_mutex); if (jumbo_vm_object != NULL) { mtx_unlock(&jumbo_mutex); return (1); } /* allocate our object */ jumbo_vm_object = vm_object_allocate(OBJT_DEFAULT, JUMBO_MAX_PAGES); The above would work, I think, if it weren't for the race in the mutex initialization, and assuming I can allocate a vm object while holding the jumbo mutex. Suggestions? > you may not call malloc(9) with M_WAITOK while holding a mutex. Ahh, okay. > entry = jumbo_kmap_inuse.slh_first; > > I'm sure that should use a list macro. Yes, SLIST_FIRST(), thanks. > That's all I see off the bat. :) Looks cool though. Cool, thanks for the feedback! Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 1:20:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id AFAC237B408 for ; Sat, 18 May 2002 01:20:39 -0700 (PDT) Received: (qmail 10131 invoked by uid 1000); 18 May 2002 08:21:55 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 May 2002 08:21:55 -0000 Date: Sat, 18 May 2002 10:21:55 +0200 (CEST) From: Attila Nagy To: Terry Lambert Cc: freebsd-arch@freebsd.org, Subject: Re: HEADS UP: ALTQ integration developer preview In-Reply-To: <3CE55A9B.73EA3DE4@mindspring.com> Message-ID: References: <3CE55A9B.73EA3DE4@mindspring.com> 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, > > the "em" driver (if "gx" is already in the initial plan), because it > > reportedly works better (for example I couldn't do NFS serving with UDP > > packets bigger than the MTU with that, while the "em" driver works OK). > It *does* frag packets bigger than the MTU, right? netstat didn't show any errors regarding to that. If I used an NFS readsize, smaller than the 1500 bytes MTU it worked (was slow, but worked). netstat's frag counters were increased. I couldn't use tcpdump (I had no bpf support) to see what happens on the wire... --------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 1:54: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from goose.prod.itd.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by hub.freebsd.org (Postfix) with ESMTP id 3E8B837B40F; Sat, 18 May 2002 01:53:45 -0700 (PDT) Received: from pool0026.cvx40-bradley.dialup.earthlink.net ([216.244.42.26] helo=mindspring.com) by goose.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 178zyA-0004Pw-00; Sat, 18 May 2002 01:53:43 -0700 Message-ID: <3CE61675.BCE2A9E1@mindspring.com> Date: Sat, 18 May 2002 01:53:09 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Attila Nagy Cc: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: HEADS UP: ALTQ integration developer preview References: <3CE55A9B.73EA3DE4@mindspring.com> Content-Type: text/plain; charset=us-ascii 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 Attila Nagy wrote: > > > the "em" driver (if "gx" is already in the initial plan), because it > > > reportedly works better (for example I couldn't do NFS serving with UDP > > > packets bigger than the MTU with that, while the "em" driver works OK). > > > > It *does* frag packets bigger than the MTU, right? > > netstat didn't show any errors regarding to that. If I used an NFS > readsize, smaller than the 1500 bytes MTU it worked (was slow, but > worked). > netstat's frag counters were increased. > I couldn't use tcpdump (I had no bpf support) to see what happens on the > wire... Sending datagrams bigger than the MTU is a bad idea. I would be real tempted to drop the packets and send "don't fragment" ICMP responses to beat up anyone who abused UDP by sending larger than the MTU. I guess this is about Linux UDP NFS clients, in particular. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 2: 0:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 0264037B405; Sat, 18 May 2002 02:00:33 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id D5EDEAE1D1; Sat, 18 May 2002 02:00:32 -0700 (PDT) Date: Sat, 18 May 2002 02:00:32 -0700 From: Alfred Perlstein To: "Kenneth D. Merry" Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: new zero copy sockets patches available Message-ID: <20020518090032.GO20683@elvis.mu.org> References: <20020517233950.A36169@panzer.kdm.org> <20020518060255.GN20683@elvis.mu.org> <20020518003046.A36510@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020518003046.A36510@panzer.kdm.org> User-Agent: Mutt/1.3.27i 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 * Kenneth D. Merry [020517 23:31] wrote: > > The problem here is that the mutex needs to be initialized before I can > acquire it, and there's going to be a race between checking to see > whether it has been initialized and actually initializing it. > ... > Suggestions? *slaps forhead* Probably a SYSINIT? > Cool, thanks for the feedback! np, this is promising work! -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 2: 9:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from goose.prod.itd.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by hub.freebsd.org (Postfix) with ESMTP id 4F1C637B405; Sat, 18 May 2002 02:09:33 -0700 (PDT) Received: from pool0026.cvx40-bradley.dialup.earthlink.net ([216.244.42.26] helo=mindspring.com) by goose.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 1790DP-0002Gf-00; Sat, 18 May 2002 02:09:27 -0700 Message-ID: <3CE61A25.61C789FA@mindspring.com> Date: Sat, 18 May 2002 02:08:53 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: "Kenneth D. Merry" , current@FreeBSD.org, net@FreeBSD.org Subject: Re: new zero copy sockets patches available References: <20020517233950.A36169@panzer.kdm.org> <20020518060255.GN20683@elvis.mu.org> <20020518003046.A36510@panzer.kdm.org> <20020518090032.GO20683@elvis.mu.org> Content-Type: text/plain; charset=us-ascii 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 Alfred Perlstein wrote: > * Kenneth D. Merry [020517 23:31] wrote: > > The problem here is that the mutex needs to be initialized before I can > > acquire it, and there's going to be a race between checking to see > > whether it has been initialized and actually initializing it. > > > ... > > Suggestions? > > *slaps forhead* > > Probably a SYSINIT? God, it's annoying that a statically declared mutex is not defacto initialized. Yeah, I understand the "witness" crap (if it's there); that doesn't make it any less annoying. Actually, a linker set (not a SYSINIT) could fix that... you would still need one sysinit to do the linkage of the statically declared structures, but it's at least doable. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 3:13:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 7D9F037B40C; Sat, 18 May 2002 03:13:14 -0700 (PDT) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.6/8.11.6) id g4IACfe52918; Sat, 18 May 2002 12:12:41 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200205181012.g4IACfe52918@zibbi.icomtek.csir.co.za> Subject: Re: HEADS UP: ALTQ integration developer preview In-Reply-To: <3CE61675.BCE2A9E1@mindspring.com> from Terry Lambert at "May 18, 2002 01:53:09 am" To: tlambert2@mindspring.com (Terry Lambert) Date: Sat, 18 May 2002 12:12:41 +0200 (SAT) Cc: bra@fsn.hu (Attila Nagy), freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 > Attila Nagy wrote: > > > > the "em" driver (if "gx" is already in the initial plan), because it > > > > reportedly works better (for example I couldn't do NFS serving with UDP > > > > packets bigger than the MTU with that, while the "em" driver works OK). > > > > > > It *does* frag packets bigger than the MTU, right? > > > > netstat didn't show any errors regarding to that. If I used an NFS > > readsize, smaller than the 1500 bytes MTU it worked (was slow, but > > worked). > > netstat's frag counters were increased. > > I couldn't use tcpdump (I had no bpf support) to see what happens on the > > wire... > > Sending datagrams bigger than the MTU is a bad idea. > > I would be real tempted to drop the packets and send "don't fragment" > ICMP responses to beat up anyone who abused UDP by sending larger > than the MTU. > > I guess this is about Linux UDP NFS clients, in particular. If this is the same "problem" nfs had all the years, then nobody is violating the MTU. What was happening is this: NFS sends a big packet (for efficiency) and that gets fragmented by the ip layer and then sent as so many back to back packets. If the card on the receiving could not receive so many back to back packets and looses one or more, nfs will get stuck retrying the same big packet and the same thing happening over and over. John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 3:20: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mta06ps.bigpond.com (mta06ps.bigpond.com [144.135.25.138]) by hub.freebsd.org (Postfix) with ESMTP id C8C0A37B405 for ; Sat, 18 May 2002 03:19:56 -0700 (PDT) Received: from areilly.bpc-users.org ([144.135.25.78]) by mta06ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GWAY1600.D3G for ; Sat, 18 May 2002 20:19:54 +1000 Received: from CPE-144-132-243-222.nsw.bigpond.net.au ([144.132.243.222]) by PSMAM04.mailsvc.email.bigpond.com(MailRouter V3.0m 92/2528095); 18 May 2002 20:19:54 Received: (qmail 2268 invoked from network); 18 May 2002 10:19:54 -0000 Received: from localhost (andrew@127.0.0.1) by localhost with SMTP; 18 May 2002 10:19:54 -0000 Subject: Re: HEADS UP: ALTQ integration developer preview From: Andrew Reilly To: Terry Lambert Cc: Attila Nagy , freebsd-arch@freebsd.org, freebsd-net@freebsd.org In-Reply-To: <3CE61675.BCE2A9E1@mindspring.com> References: <3CE55A9B.73EA3DE4@mindspring.com> <3CE61675.BCE2A9E1@mindspring.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 18 May 2002 20:19:54 +1000 Message-Id: <1021717195.1466.4.camel@gurney.reilly.home> Mime-Version: 1.0 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, 2002-05-18 at 18:53, Terry Lambert wrote: > > Sending datagrams bigger than the MTU is a bad idea. > > I would be real tempted to drop the packets and send "don't fragment" > ICMP responses to beat up anyone who abused UDP by sending larger > than the MTU. > > I guess this is about Linux UDP NFS clients, in particular. Eh? Isn't the original, traditional and best NFS configuration 8k UDP packets? Sure worked fine that way on SunOS-4 those many years ago. (On LANs, of course. No one does NFS over the internet. I hope.) -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 4:41:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id 0201937B411 for ; Sat, 18 May 2002 04:41:47 -0700 (PDT) Received: (qmail 11036 invoked by uid 1000); 18 May 2002 11:43:04 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 May 2002 11:43:04 -0000 Date: Sat, 18 May 2002 13:43:04 +0200 (CEST) From: Attila Nagy To: Terry Lambert Cc: freebsd-arch@freebsd.org, Subject: Re: HEADS UP: ALTQ integration developer preview In-Reply-To: <3CE61675.BCE2A9E1@mindspring.com> Message-ID: References: <3CE55A9B.73EA3DE4@mindspring.com> <3CE61675.BCE2A9E1@mindspring.com> 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, > Sending datagrams bigger than the MTU is a bad idea. It depends on what do you want to do with that NFS server :) I want to get out from that several hundred megabits per second, so I can't use <1500 bytes MTU. Just for comparison: when using <1500 bytes MTU (as close as possible to the limit) I can achieve about 1-1.5 MBps throughput. When using 32768 bytes MTU I can get around 190 Mbps out from a PIII 450. (and only 190 Mbps because the two frontends have fast ethernet cards) So why this is so bad? If the other end can keep up, it will increase throughput. BTW, the default UDP readsize is above 1500 bytes, so I couldn't use the server with a simple NFS mount. When I replaced the gx driver to em it just started to work. Now I am using TCP and 32k readsize with 64k tcp.sendspace and recvspace (I could nearly double the performance with setting these from the default values). So I am happy with it, I just took a note that the gx driver has some problems in these cases. > I would be real tempted to drop the packets and send "don't fragment" > ICMP responses to beat up anyone who abused UDP by sending larger than > the MTU. That's another point. I want performance :) > I guess this is about Linux UDP NFS clients, in particular. Nope, both the server and the client side is FreeBSD stable. --------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 4:43:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id A5EBE37B40F for ; Sat, 18 May 2002 04:43:30 -0700 (PDT) Received: (qmail 11048 invoked by uid 1000); 18 May 2002 11:44:48 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 May 2002 11:44:48 -0000 Date: Sat, 18 May 2002 13:44:48 +0200 (CEST) From: Attila Nagy To: John Hay Cc: freebsd-arch@FreeBSD.ORG, Subject: Re: HEADS UP: ALTQ integration developer preview In-Reply-To: <200205181012.g4IACfe52918@zibbi.icomtek.csir.co.za> Message-ID: References: <200205181012.g4IACfe52918@zibbi.icomtek.csir.co.za> 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, > If the card on the receiving could not receive so many back to back > packets and looses one or more, nfs will get stuck retrying the same big > packet and the same thing happening over and over. Yep, but that's not my case. If this would be the problem, I guess changing from gx to em wouldn't help me... --------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 5:39:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from charon.0x54434D.net (pD95353C7.dip.t-dialin.net [217.83.83.199]) by hub.freebsd.org (Postfix) with ESMTP id 6BB4537B40C for ; Sat, 18 May 2002 05:39:56 -0700 (PDT) Received: from 0x54434D.net (powerbox.tcm.lan [192.168.1.11]) by charon.0x54434D.net (Postfix) with ESMTP id F36463E29 for ; Sat, 18 May 2002 14:39:53 +0200 (CEST) Message-ID: <3CE64B9B.1040407@0x54434D.net> Date: Sat, 18 May 2002 14:39:55 +0200 From: Nino Dehne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Intel Etherexpress Pro/100S settings 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 hi -net, recently i acquired a pair of above cards, one of which i use with w2k and the other with freebsd's fxp(4). with w2k i am able to set various options using intel's proset utility (cpu usage vs. throughput, pci bus efficiency etc.). my question is: are these settings stored into the system config or into the card itself? i.e. does it make sense to config a card with w2k first and then put it into the freebsd box? or is ifconfig(8)'s link0 option for the fxp driver the only knob to twiddle? tia nino To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 6: 4:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216]) by hub.freebsd.org (Postfix) with ESMTP id 3CE0837B407 for ; Sat, 18 May 2002 06:03:54 -0700 (PDT) Received: (qmail 23564 invoked from network); 18 May 2002 13:03:52 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail16.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 May 2002 13:03:52 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g4ID3oF82147; Sat, 18 May 2002 09:03:50 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020518003046.A36510@panzer.kdm.org> Date: Sat, 18 May 2002 09:03:38 -0400 (EDT) From: John Baldwin To: "Kenneth D. Merry" Subject: Re: new zero copy sockets patches available Cc: net@FreeBSD.org, current@FreeBSD.org, Alfred Perlstein 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 18-May-2002 Kenneth D. Merry wrote: > On Fri, May 17, 2002 at 23:02:55 -0700, Alfred Perlstein wrote: >> * Kenneth D. Merry [020517 22:40] wrote: >> > >> > I have released a new set of zero copy sockets patches, against -current >> > from today (May 17th, 2002). >> > >> > The main change is to deal with the vfs_ioopt changes that Alan Cox made >> > in >> > kern_subr.c. (They conflicted a bit with the zero copy receive code.) >> > >> > The patches and the FAQ are available here: >> > >> > http://people.freebsd.org/~ken/zero_copy/ >> > >> > Comments, questions and reviews are all welcome! >> >> jumbo_vm_init() has a bunch of bugs >> >> first it doesn't work right if called concurrently. >> you need to protect the initialization of jumbo_vm_object otherwise >> bad things can happen. my suggestion is to store the results of >> vm_object_allocate into a temporary, grab the mutex and then check >> to see if jumbo_vm_object has been initialized again if it has then >> free the object, otherwise store the allocated object into the >> global and continue. > > The problem here is that the mutex needs to be initialized before I can > acquire it, and there's going to be a race between checking to see > whether it has been initialized and actually initializing it. > > e.g.: > > if (!mtx_initialized(&jumbo_mutex)) > mtx_init(&jumbo_mutex, "jumbo mutex", NULL, MTX_DEF); > > mtx_lock(&jumbo_mutex); > > if (jumbo_vm_object != NULL) { > mtx_unlock(&jumbo_mutex); > return (1); > } > > /* allocate our object */ > jumbo_vm_object = vm_object_allocate(OBJT_DEFAULT, JUMBO_MAX_PAGES); > > The above would work, I think, if it weren't for the race in the mutex > initialization, and assuming I can allocate a vm object while holding > the jumbo mutex. > > Suggestions? Either use a sysinit or something gross like this: static int jumbo_init = 0; ... while (jumbo_init != 2) { if (atomic_cmpset_acq_int(&jumbo_init, 0, 1) { mtx_init(&jumbo_mutex, "jumbo_mutex", NULL, MTX_DEF); atomic_store_rel_int(&jumbo_init, 2); } } mtx_lock(&jumbo_mutex); ... a sysinit is probably best though. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 6: 4:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217]) by hub.freebsd.org (Postfix) with ESMTP id E6FD637B409 for ; Sat, 18 May 2002 06:03:54 -0700 (PDT) Received: (qmail 23408 invoked from network); 18 May 2002 13:03:54 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail17.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 May 2002 13:03:54 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g4ID3qF82151; Sat, 18 May 2002 09:03:52 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3CE61A25.61C789FA@mindspring.com> Date: Sat, 18 May 2002 09:03:40 -0400 (EDT) From: John Baldwin To: Terry Lambert Subject: Re: new zero copy sockets patches available Cc: net@FreeBSD.org, current@FreeBSD.org, "Kenneth D. Merry" , Alfred Perlstein 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 18-May-2002 Terry Lambert wrote: > Alfred Perlstein wrote: >> * Kenneth D. Merry [020517 23:31] wrote: >> > The problem here is that the mutex needs to be initialized before I can >> > acquire it, and there's going to be a race between checking to see >> > whether it has been initialized and actually initializing it. >> > >> ... >> > Suggestions? >> >> *slaps forhead* >> >> Probably a SYSINIT? > > God, it's annoying that a statically declared mutex is not > defacto initialized. Is it in solaris? > Yeah, I understand the "witness" crap (if it's there); that > doesn't make it any less annoying. > > Actually, a linker set (not a SYSINIT) could fix that... you > would still need one sysinit to do the linkage of the statically > declared structures, but it's at least doable. a SYSINIT just is a linker set, and there is a convenience SYSINIT MTX_SYSINIT() or what not that just registers a sysinit to initialize a mutex. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 7:42:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 89D4037B401; Sat, 18 May 2002 07:42:31 -0700 (PDT) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.3/8.12.3) with ESMTP id g4IEZGb4072709; Sat, 18 May 2002 10:35:16 -0400 (EDT) (envelope-from arr@FreeBSD.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.12.3/8.12.3/Submit) with SMTP id g4IEZFuK072706; Sat, 18 May 2002 10:35:16 -0400 (EDT) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Sat, 18 May 2002 10:35:15 -0400 (EDT) From: "Andrew R. Reiter" X-Sender: arr@fledge.watson.org To: Alfred Perlstein Cc: "Kenneth D. Merry" , current@FreeBSD.org, net@FreeBSD.org Subject: Re: new zero copy sockets patches available In-Reply-To: <3CE61A25.61C789FA@mindspring.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 :Alfred Perlstein wrote: :> * Kenneth D. Merry [020517 23:31] wrote: :> > The problem here is that the mutex needs to be initialized before I can :> > acquire it, and there's going to be a race between checking to see :> > whether it has been initialized and actually initializing it. :> > :> ... :> > Suggestions? :> :> *slaps forhead* :> :> Probably a SYSINIT? mutex(9) and sx(9) describe two macros for this purpose. -- Andrew R. Reiter arr@watson.org arr@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 9:28:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id 5207837B40F for ; Sat, 18 May 2002 09:28:29 -0700 (PDT) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.11.6/8.10.2) with ESMTP id g4IGSSf15678 for ; Sat, 18 May 2002 16:28:28 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Sat, 18 May 2002 16:28:28 +0000 (GMT) From: "E.B. Dreger" To: freebsd-net@freebsd.org Subject: VRRP and SIOCSIFLLADDR 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 Greetings all, I'm currently STFWing for info on proper VRRP implementation on FreeBSD. My motivations are those mentioned by Terry in a -net thread last July... Win2000 Advanced Server clustering is rather cool. I'd like FreeBSD to similarly support multiple MAC addresses (and emulate via multicast when the NIC only allows a single MAC). This IMHO obviously would be a big plus. As an aside... it seems that anything for which I seek info { has been | is being } done by Terry. ;-) Bottom line: Any developments, hints, tips, et cetera of which one should know? Or do I continue STFWing? ;-) -- Eddy Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to , or you are likely to be blocked. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 10:12:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 0381037B40C; Sat, 18 May 2002 10:12:40 -0700 (PDT) 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 NAA14847; Sat, 18 May 2002 13:12:39 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g4IHC9S82047; Sat, 18 May 2002 13:12:09 -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: <15590.35689.201153.550505@grasshopper.cs.duke.edu> Date: Sat, 18 May 2002 13:12:09 -0400 (EDT) To: "Kenneth D. Merry" Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: new zero copy sockets patches available In-Reply-To: <20020517233950.A36169@panzer.kdm.org> References: <20020517233950.A36169@panzer.kdm.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 Kenneth D. Merry writes: > > I have released a new set of zero copy sockets patches, against -current > from today (May 17th, 2002). > > The main change is to deal with the vfs_ioopt changes that Alan Cox made in > kern_subr.c. (They conflicted a bit with the zero copy receive code.) > > The patches and the FAQ are available here: > > http://people.freebsd.org/~ken/zero_copy/ > > Comments, questions and reviews are all welcome! > Hi Ken, I'm glad to see that you're still maintining this! Assuming the mutex issues get sorted out, what do you think the odds are of getting this into the tree? The only possible issue I see is with the tigon firmware. Is the firmware you're using of the same vintage as what's in the tree now? Does it contain all the same fixes? Thanks again for keeping this alive, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 10:15:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.sandvine.com (sandvine.com [209.167.74.226]) by hub.freebsd.org (Postfix) with ESMTP id 3759737B408; Sat, 18 May 2002 10:15:45 -0700 (PDT) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Sat, 18 May 2002 13:15:44 -0400 Message-ID: From: Don Bowman To: 'Andrew Gallatin' , "Kenneth D. Merry" Cc: current@FreeBSD.org, net@FreeBSD.org Subject: RE: new zero copy sockets patches available Date: Sat, 18 May 2002 13:15:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 > Andrew Gallatin writes: >> Kenneth D. Merry writes: >> > >> > I have released a new set of zero copy sockets patches, against -current >> > from today (May 17th, 2002). > > Hi Ken, > > I'm glad to see that you're still maintining this! > > Assuming the mutex issues get sorted out, what do you think the odds > are of getting this into the tree? The only possible issue I see is > with the tigon firmware. Is the firmware you're using of the same > vintage as what's in the tree now? Does it contain all the same > fixes? As a related question, will this work with the broadcom gigabit (bge) driver, which is the Tigon III? If not, what would it take to get it working? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 15:29:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 6432837B40E; Sat, 18 May 2002 15:29:14 -0700 (PDT) Received: from pool0271.cvx22-bradley.dialup.earthlink.net ([209.179.199.16] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 179ChE-0004Gt-00; Sat, 18 May 2002 15:29:04 -0700 Message-ID: <3CE6D592.DCF73743@mindspring.com> Date: Sat, 18 May 2002 15:28:34 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Reilly Cc: Attila Nagy , freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: HEADS UP: ALTQ integration developer preview References: <3CE55A9B.73EA3DE4@mindspring.com> <3CE61675.BCE2A9E1@mindspring.com> <1021717195.1466.4.camel@gurney.reilly.home> Content-Type: text/plain; charset=us-ascii 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 Andrew Reilly wrote: > On Sat, 2002-05-18 at 18:53, Terry Lambert wrote: > > Sending datagrams bigger than the MTU is a bad idea. > > > > I would be real tempted to drop the packets and send "don't fragment" > > ICMP responses to beat up anyone who abused UDP by sending larger > > than the MTU. > > > > I guess this is about Linux UDP NFS clients, in particular. > > Eh? Isn't the original, traditional and best NFS configuration 8k UDP > packets? > > Sure worked fine that way on SunOS-4 those many years ago. (On LANs, of > course. No one does NFS over the internet. I hope.) No. TCP. RPC over UDP is really a silly idea. If you need reliable delivery, then don't use a protocol with "unreliable" as the first word of it's name. 8-). In any case, the best UDP packet size is always "The largest possible amount of data which fits in the MTU". There's no retransmit timeout to deal with incomplete fragment sets pending reassembly. If you want to get technical, TCP also has a bug; in the move from FIN-WAIT-1 to FIN-WAIT-2, there's an assumption of two responses for a single request. That's just intrinsically bad protocol design. The workaround is to pretend you didn't get the first FIN, resend, and then either get re-ACK'ed, or get an RST. NT does this. So did Paul Vixie's "Interceptor" product (transparent proxy cache appliance using NetBSD). Putting yourself in a situation where protocol bugs result in effective attacks is, well, "a bad idea". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 15:45:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 80C9237B408; Sat, 18 May 2002 15:45:46 -0700 (PDT) Received: from pool0271.cvx22-bradley.dialup.earthlink.net ([209.179.199.16] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 179CxH-0002JV-00; Sat, 18 May 2002 15:45:40 -0700 Message-ID: <3CE6D976.3264DE53@mindspring.com> Date: Sat, 18 May 2002 15:45:10 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Attila Nagy Cc: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: HEADS UP: ALTQ integration developer preview References: <3CE55A9B.73EA3DE4@mindspring.com> <3CE61675.BCE2A9E1@mindspring.com> Content-Type: text/plain; charset=us-ascii 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 Attila Nagy wrote: > > Sending datagrams bigger than the MTU is a bad idea. > > It depends on what do you want to do with that NFS server :) Sure. Maybe you want to use up it's mbufs by jamming the frag reassembly queue for IP full of N-1 frags using 64K USP packets. > I want to get out from that several hundred megabits per second, so I > can't use <1500 bytes MTU. NFS works over TCP for a reason. TCP has sliding windows for a reason. > Just for comparison: > when using <1500 bytes MTU (as close as possible to the limit) I can > achieve about 1-1.5 MBps throughput. > When using 32768 bytes MTU I can get around 190 Mbps out from a PIII 450. > (and only 190 Mbps because the two frontends have fast ethernet cards) > So why this is so bad? If the other end can keep up, it will increase > throughput. And you could get even better by getting rid of the request/response turnaround stall by using TCP instead of UDP. Rather than having a packet overhead of latency per packet, you get two packet latencies over an arbitrary number of packets (unless you hit the window size, in which case, you probably needed to have a larger window. > BTW, the default UDP readsize is above 1500 bytes, so I couldn't use the > server with a simple NFS mount. > When I replaced the gx driver to em it just started to work. Now I am > using TCP and 32k readsize with 64k tcp.sendspace and recvspace (I could > nearly double the performance with setting these from the default values). > > So I am happy with it, I just took a note that the gx driver has some > problems in these cases. Most traffic is supposed to be at the MTU. You want to avoid fragging. The only reason you want fragging in the UDP case is so you can pretend you have a window, without having to use a windowing protocol: you use the fragment reassembly queue as a window buffer. This really only gives you an amortization of 32K/MTU (maximum), and you still have stalls every N packets, which you would not get with a windowed protocol. > > I would be real tempted to drop the packets and send "don't fragment" > > ICMP responses to beat up anyone who abused UDP by sending larger than > > the MTU. > > That's another point. I want performance :) Then don't add the fragment reassmbly code to the code path for packets you send to the server. That way you'll have less overhead. 8-). > > I guess this is about Linux UDP NFS clients, in particular. > > Nope, both the server and the client side is FreeBSD stable. I run all my NFS over TCP. If I avoid intentionally triggering fragmentation, it works out to a little over 100 machine instructions in the fast path. Done any cycle counting on your use of UDP yet? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 15:48:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 0A97B37B40C; Sat, 18 May 2002 15:48:28 -0700 (PDT) Received: from pool0271.cvx22-bradley.dialup.earthlink.net ([209.179.199.16] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 179Czl-0004W1-00; Sat, 18 May 2002 15:48:13 -0700 Message-ID: <3CE6DA0F.C4D8C289@mindspring.com> Date: Sat, 18 May 2002 15:47:43 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Attila Nagy Cc: John Hay , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: HEADS UP: ALTQ integration developer preview References: <200205181012.g4IACfe52918@zibbi.icomtek.csir.co.za> Content-Type: text/plain; charset=us-ascii 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 Attila Nagy wrote: > > If the card on the receiving could not receive so many back to back > > packets and looses one or more, nfs will get stuck retrying the same big > > packet and the same thing happening over and over. > > Yep, but that's not my case. If this would be the problem, I guess > changing from gx to em wouldn't help me... The really cool thing is that this means I can shout on the wire at the right time, cause a collision, and effectively stace an undetectable denial of service attack against your servers, by making it drop large UDP datagrams IP frags. Way to open yourself up to attack! -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 15:58:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by hub.freebsd.org (Postfix) with ESMTP id 73D5D37B404; Sat, 18 May 2002 15:58:49 -0700 (PDT) Received: from pc01 ([12.77.153.90]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020518225845.OLMF11146.mtiwmhc22.worldnet.att.net@pc01>; Sat, 18 May 2002 22:58:45 +0000 Reply-To: From: "Andrew Tate" To: , Subject: kernel profiling in FreeBSD 5.0DP - is it working? Date: Sat, 18 May 2002 18:55:36 -0400 Message-ID: <000101c1febf$213ab9f0$5a994d0c@pc01> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 know if kernel profiling is working in FreeBSD 5.0DP? Andrew Tate mailto:tate@att.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 16: 3:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id CF79A37B40B; Sat, 18 May 2002 16:03:07 -0700 (PDT) Received: from pool0271.cvx22-bradley.dialup.earthlink.net ([209.179.199.16] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 179DEA-0001yS-00; Sat, 18 May 2002 16:03:07 -0700 Message-ID: <3CE6DD8C.FC95386F@mindspring.com> Date: Sat, 18 May 2002 16:02:36 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: net@FreeBSD.org, current@FreeBSD.org, "Kenneth D. Merry" , Alfred Perlstein Subject: Re: new zero copy sockets patches available References: Content-Type: text/plain; charset=us-ascii 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 John Baldwin wrote: > > God, it's annoying that a statically declared mutex is not > > defacto initialized. > > Is it in solaris? It isn't in FreeBSD because of the need to link mutex'es into the "witness protection program". 8-). > > Yeah, I understand the "witness" crap (if it's there); that > > doesn't make it any less annoying. > > > > Actually, a linker set (not a SYSINIT) could fix that... you > > would still need one sysinit to do the linkage of the statically > > declared structures, but it's at least doable. > > a SYSINIT just is a linker set, and there is a convenience SYSINIT > MTX_SYSINIT() or what not that just registers a sysinit to initialize > a mutex. What you want to do is implement a: MUTEX_DECLARE(mutex_name). This would implicitly add the mutex into the limker set containing the addresses of statically declared mutex'es. The SYSINIT()'s purpose would be to traverse this linker set, calling the moral equivalent of "mutex_init" on each one of them. You could do this with a SYSINIT(), as has been suggested, but that would add a relatively large per mutex overhead for each one you want to declare, since you'd basically be repeating the common components for doing the job for each and every mutex, instead of sharing them. Technically, some later programmer could come along and recover the linker set memory, actually, since it's only used once, for the traversal, at kernel startup. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 16:22:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by hub.freebsd.org (Postfix) with ESMTP id 9661D37B409 for ; Sat, 18 May 2002 16:22:47 -0700 (PDT) Received: (qmail 11331 invoked from network); 18 May 2002 23:22:43 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 May 2002 23:22:43 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g4INLxF83616; Sat, 18 May 2002 19:21:59 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3CE6DD8C.FC95386F@mindspring.com> Date: Sat, 18 May 2002 19:21:48 -0400 (EDT) From: John Baldwin To: Terry Lambert Subject: Re: new zero copy sockets patches available Cc: Alfred Perlstein , "Kenneth D. Merry" , current@FreeBSD.org, net@FreeBSD.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 On 18-May-2002 Terry Lambert wrote: > John Baldwin wrote: >> > God, it's annoying that a statically declared mutex is not >> > defacto initialized. >> >> Is it in solaris? > > It isn't in FreeBSD because of the need to link mutex'es into > the "witness protection program". 8-). Actually, there is more to it than that. Or at least, there will be when turnstiles are added (turnstiles require some function callouts to work properly). > MUTEX_DECLARE(mutex_name). Umm, yes, like MTX_SYSINIT(). :) > You could do this with a SYSINIT(), as has been suggested, but > that would add a relatively large per mutex overhead for each > one you want to declare, since you'd basically be repeating the > common components for doing the job for each and every mutex, > instead of sharing them. Umm, this is a boot-up thing so it's not that big of a deal, plus the actual code isn't duplicated, we call a common function for the actual mutex initialization. > Technically, some later programmer could come along and recover > the linker set memory, actually, since it's only used once, for > the traversal, at kernel startup. Erm, they could do the same with the little mtx_args structs if they want to as well, but I think it's more effor than its worth. > -- Terry -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 16:23:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id BB5CB37B403; Sat, 18 May 2002 16:23:51 -0700 (PDT) Received: from pool0271.cvx22-bradley.dialup.earthlink.net ([209.179.199.16] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 179DY9-0001UX-00; Sat, 18 May 2002 16:23:46 -0700 Message-ID: <3CE6E263.77E337E0@mindspring.com> Date: Sat, 18 May 2002 16:23:15 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Bowman Cc: 'Andrew Gallatin' , "Kenneth D. Merry" , current@FreeBSD.org, net@FreeBSD.org Subject: Re: new zero copy sockets patches available References: Content-Type: text/plain; charset=us-ascii 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 Don Bowman wrote: > > Andrew Gallatin writes: > >> Kenneth D. Merry writes: > >> > > >> > I have released a new set of zero copy sockets patches, against > -current > >> > from today (May 17th, 2002). > > > > Hi Ken, > > > > I'm glad to see that you're still maintining this! > > > > Assuming the mutex issues get sorted out, what do you think the odds > > are of getting this into the tree? The only possible issue I see is > > with the tigon firmware. Is the firmware you're using of the same > > vintage as what's in the tree now? Does it contain all the same > > fixes? > > As a related question, will this work with the broadcom gigabit (bge) > driver, which is the Tigon III? If not, what would it take to get > it working? Broadcom is a bit more anal about people having access to their firmware to make their products meet their design capabilities. Really annoying about the whole Broadcom/Alteon thing... To do the work, you'd have to do it on your own, after licensing the firmware, after signing an NDA. Unlike the rather public Tigon II firmware, the Tigon III doesn't have a lot of synergy or interesting work going for it. Most people doing interesting work tend to use Tigon II cards, because of this. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 16:42:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id E354137B41C; Sat, 18 May 2002 16:41:54 -0700 (PDT) Received: from pool0271.cvx22-bradley.dialup.earthlink.net ([209.179.199.16] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 179Dph-0002IH-00; Sat, 18 May 2002 16:41:53 -0700 Message-ID: <3CE6E6A2.4A42228B@mindspring.com> Date: Sat, 18 May 2002 16:41:22 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: Alfred Perlstein , "Kenneth D. Merry" , current@FreeBSD.org, net@FreeBSD.org Subject: Re: new zero copy sockets patches available References: Content-Type: text/plain; charset=us-ascii 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 John Baldwin wrote: > On 18-May-2002 Terry Lambert wrote: > > John Baldwin wrote: > >> > God, it's annoying that a statically declared mutex is not > >> > defacto initialized. > >> > >> Is it in solaris? > > > > It isn't in FreeBSD because of the need to link mutex'es into > > the "witness protection program". 8-). > > Actually, there is more to it than that. Or at least, there will be > when turnstiles are added (turnstiles require some function callouts > to work properly). It's the function callouts that are the problem. 8-(. > > MUTEX_DECLARE(mutex_name). > > Umm, yes, like MTX_SYSINIT(). :) No. An MTX_SYSINIT() that wrapped a declaration and a SYSINIT() would als imply the definition of an static function to do the initialization, that then got called by the SYSINIT() itself. This is actually what I was saying was bad: a static function per mutex declaration. You really want to avoid the pthreads "mutex initializer" thing; the compiler doesn't have code that can attach to data declarations to fix the problem. So, among other things, you want to use the same initializer function instance for all statically declared mutexes. So you have to use something other than a SYSINIT() for the declarations, but you could use *one SYSINIT()* to do the pre-use initialization of *all* declarations. > > You could do this with a SYSINIT(), as has been suggested, but > > that would add a relatively large per mutex overhead for each > > one you want to declare, since you'd basically be repeating the > > common components for doing the job for each and every mutex, > > instead of sharing them. > > Umm, this is a boot-up thing so it's not that big of a deal, plus > the actual code isn't duplicated, we call a common function for > the actual mutex initialization. Maybe. I don't think a large sysinit structure is as useful as an array of addresses of mutexes needing initialization. There would be a serious tempation in the former case to provide for some type of non-uniform initialization of statically declared sysinit objects. It would be nice if the non-uniformity could be limited to the fact that if the WITNESS code was there, it needed to be linked onto the list. With the WITNESS code not compiled into the kernel, I'd prefer not to include the initialization code at all. It would encorage bad practice, if it weren't conditional on WITNESS. > > Technically, some later programmer could come along and recover > > the linker set memory, actually, since it's only used once, for > > the traversal, at kernel startup. > > Erm, they could do the same with the little mtx_args structs if > they want to as well, but I think it's more effor than its worth. Actually, I don't think they could. The intermediate stage for that would really suck. The only way to handle it is to use different ELF sections for that datam so that you could discard the section later. This is worthwhile for device probe code, maybe attach code, any linker set contents, but not really for individial small structures each getting jammed into their own page size object. 8-). You'd need to do a lot more work, including KVA defragmentation by being able to sectionally attribute anything in the paging path, to keep it from being moved around, or the move-it-around code itself. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 16:53:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by hub.freebsd.org (Postfix) with ESMTP id A065E37B416 for ; Sat, 18 May 2002 16:53:28 -0700 (PDT) Received: (qmail 27112 invoked from network); 18 May 2002 23:53:25 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 May 2002 23:53:25 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g4INqkF83718; Sat, 18 May 2002 19:52:46 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3CE6E6A2.4A42228B@mindspring.com> Date: Sat, 18 May 2002 19:52:36 -0400 (EDT) From: John Baldwin To: Terry Lambert Subject: Re: new zero copy sockets patches available Cc: net@FreeBSD.org, current@FreeBSD.org, "Kenneth D. Merry" , Alfred Perlstein 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 18-May-2002 Terry Lambert wrote: > John Baldwin wrote: >> On 18-May-2002 Terry Lambert wrote: >> > John Baldwin wrote: >> >> > God, it's annoying that a statically declared mutex is not >> >> > defacto initialized. >> >> >> >> Is it in solaris? >> > >> > It isn't in FreeBSD because of the need to link mutex'es into >> > the "witness protection program". 8-). >> >> Actually, there is more to it than that. Or at least, there will be >> when turnstiles are added (turnstiles require some function callouts >> to work properly). > > It's the function callouts that are the problem. 8-(. Unfortunately there aren't easy solutions to this. Even solaris 7 uses callouts. We would use fewer of them at least. >> > MUTEX_DECLARE(mutex_name). >> >> Umm, yes, like MTX_SYSINIT(). :) > > No. An MTX_SYSINIT() that wrapped a declaration and a SYSINIT() > would als imply the definition of an static function to do the > initialization, that then got called by the SYSINIT() itself. This is a false implication. > This is actually what I was saying was bad: a static function > per mutex declaration. Umm, no, there is _one_ global function that we call. Why not check the actual code? > So, among other things, you want to use the same initializer function > instance for all statically declared mutexes. Um, we already do this. > So you have to use something other than a SYSINIT() for the declarations, > but you could use *one SYSINIT()* to do the pre-use initialization of > *all* declarations. Why don't you read the code? Here, I'll quote it for you: struct mtx_args { struct mtx *ma_mtx; const char *ma_desc; int ma_opts; }; #define MTX_SYSINIT(name, mtx, desc, opts) \ static struct mtx_args name##_args = { \ mtx, \ desc, \ opts \ }; \ SYSINIT(name##_mtx_sysinit, SI_SUB_LOCK, SI_ORDER_MIDDLE, \ mtx_sysinit, &name##_args) Note no static function, instead we use the global function mtx_sysinit() in kern_mutex.c: /* * General init routine used by the MTX_SYSINIT() macro. */ void mtx_sysinit(void *arg) { struct mtx_args *margs = arg; mtx_init(margs->ma_mtx, margs->ma_desc, NULL, margs->ma_opts); } -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 17: 1:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id A641C37B400; Sat, 18 May 2002 17:01:42 -0700 (PDT) Received: from isi.edu (u3xit41xo3mv53gd@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4J01TF08127; Sat, 18 May 2002 17:01:29 -0700 (PDT) Message-ID: <3CE6EB56.5080506@isi.edu> Date: Sat, 18 May 2002 17:01:26 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Terry Lambert Cc: Andrew Reilly , Attila Nagy , freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: HEADS UP: ALTQ integration developer preview References: <3CE55A9B.73EA3DE4@mindspring.com> <3CE61675.BCE2A9E1@mindspring.com> <1021717195.1466.4.camel@gurney.reilly.home> <3CE6D592.DCF73743@mindspring.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060500030403020908090605" 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. --------------ms060500030403020908090605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Terry Lambert wrote: > No. TCP. RPC over UDP is really a silly idea. If you need > reliable delivery, then don't use a protocol with "unreliable" > as the first word of it's name. 8-). The U in UDP is for "User". See RFC768. NFS over UDP works just fine in the majority of cases, and for slow receivers (the problem John Hay described), there's TCP mounts. Lars -- Lars Eggert USC Information Sciences Institute --------------ms060500030403020908090605 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 HAYJKoZIhvcNAQkFMQ8XDTAyMDUxOTAwMDEyOFowIwYJKoZIhvcNAQkEMRYEFAWiQcCpxpLF oQuF3XIVXtdd8iLSMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYCScN2EqE27P0v1UFcY8u8sVFO9ezzSc0xyo4r2ZkcZ2wvy guZ7X3D4rU/FHfVWiEdRFtZ+ZvYUFtJAB/J3c0g4ZJkVtAj97ppl9xiHU2DpMrmwfAZpfHRW fINmvWAgYbwCWkiZiWoz5aAETPMl2amwJlOoQg6pEhEOjbVpZIWAKQAAAAAAAA== --------------ms060500030403020908090605-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 17: 6:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 200C237B400; Sat, 18 May 2002 17:06:26 -0700 (PDT) Received: from isi.edu (5oso8ry8i01hla2b@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4J05wF10558; Sat, 18 May 2002 17:05:58 -0700 (PDT) Message-ID: <3CE6EC64.3060704@isi.edu> Date: Sat, 18 May 2002 17:05:56 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Terry Lambert Cc: Attila Nagy , John Hay , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: HEADS UP: ALTQ integration developer preview References: <200205181012.g4IACfe52918@zibbi.icomtek.csir.co.za> <3CE6DA0F.C4D8C289@mindspring.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080506050809060506010809" 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. --------------ms080506050809060506010809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Terry Lambert wrote: > The really cool thing is that this means I can shout on the wire at > the right time, cause a collision, and effectively stace an undetectable > denial of service attack against your servers, by making it drop large > UDP datagrams IP frags. This "attack" works against any other protocol as well, including TCP. If you can create collisions "at the right time", you can disable all retransmission schemes. The kicker is - how? Lars -- Lars Eggert USC Information Sciences Institute --------------ms080506050809060506010809 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 HAYJKoZIhvcNAQkFMQ8XDTAyMDUxOTAwMDU1OFowIwYJKoZIhvcNAQkEMRYEFPMfjzE/co70 jJv9FbMBvMh01eUYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYBP7HmKO1R/2/qLwYcCY4adLXyusOPBzeiFABj5u5unljNi Tg1jCac2y1p92xSEbGrEXdQakKrCRJrk3hhWmh8jZ0UyKAYnhDTwh4dep6uexuCsLYafwugP uvU2zLoabeU30DL148hRCIbWJc3iZNtaKCYGGa6TxeGzqjHeUKcs8QAAAAAAAA== --------------ms080506050809060506010809-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 17: 7: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 9CF1337B40A; Sat, 18 May 2002 17:06:55 -0700 (PDT) Received: from pool0271.cvx22-bradley.dialup.earthlink.net ([209.179.199.16] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 179EDu-0000VZ-00; Sat, 18 May 2002 17:06:54 -0700 Message-ID: <3CE6EC7F.F75B00F9@mindspring.com> Date: Sat, 18 May 2002 17:06:23 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: net@FreeBSD.org, current@FreeBSD.org, "Kenneth D. Merry" , Alfred Perlstein Subject: Re: new zero copy sockets patches available References: Content-Type: text/plain; charset=us-ascii 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 John Baldwin wrote: > > This is actually what I was saying was bad: a static function > > per mutex declaration. > > Umm, no, there is _one_ global function that we call. Why not check > the actual code? Are you talking about a P4 branch, and not the main repository? > Why don't you read the code? > > Here, I'll quote it for you: > > struct mtx_args { > struct mtx *ma_mtx; > const char *ma_desc; > int ma_opts; > }; > > #define MTX_SYSINIT(name, mtx, desc, opts) \ > static struct mtx_args name##_args = { \ > mtx, \ > desc, \ > opts \ > }; \ > SYSINIT(name##_mtx_sysinit, SI_SUB_LOCK, SI_ORDER_MIDDLE, \ > mtx_sysinit, &name##_args) This is *EXACTLY* what I thought should be avoided. The linker set should not contain the address of a bunch of static mtx_args structs, because there shouldn't *be* a bunch of static mtx_args structs. And the ability to pass different initialization values to different mutex instances is broken, in that it makes it impossible to look at a mutex, and know what you need to know about it, merely because it's a mutex. Minimally, you are going to add 12 bytes per mutex (24 on 64 bit machines), plus however much memory is taken up by the "ma_desc", plus it makes the memory unrecoverable, because the address of the string that's in the supposedly "recoverable" data segment can't be recovered any more, because making the data segment "go away" would invalidate dereferences of the pointer. This is about as ugly the mutex code taking parameters (we've had that discussion before). > Note no static function, instead we use the global function mtx_sysinit() > in kern_mutex.c: > > /* > * General init routine used by the MTX_SYSINIT() macro. > */ > void > mtx_sysinit(void *arg) > { > struct mtx_args *margs = arg; > > mtx_init(margs->ma_mtx, margs->ma_desc, NULL, margs->ma_opts); > } On a per instance basis. For which you create not only an mtx_args structure, but also a sysinit structure, to act as a container for the reference to the mtx_args struct address, and the mtx_sysinit function, etc.. Bleh. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 17:13: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from yello.shallow.net (yello.shallow.net [203.18.243.120]) by hub.freebsd.org (Postfix) with ESMTP id 18D3037B403 for ; Sat, 18 May 2002 17:12:57 -0700 (PDT) Received: by yello.shallow.net (Postfix, from userid 1001) id 23A5B2A6D; Sun, 19 May 2002 10:12:50 +1000 (EST) Date: Sun, 19 May 2002 10:12:50 +1000 From: Joshua Goodall To: Terry Lambert Cc: Andrew Reilly , Attila Nagy , freebsd-net@freebsd.org Subject: Re: HEADS UP: ALTQ integration developer preview Message-ID: <20020519001249.GA24012@roughtrade.net> References: <3CE55A9B.73EA3DE4@mindspring.com> <3CE61675.BCE2A9E1@mindspring.com> <1021717195.1466.4.camel@gurney.reilly.home> <3CE6D592.DCF73743@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CE6D592.DCF73743@mindspring.com> User-Agent: Mutt/1.3.28i 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, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote: > No. TCP. RPC over UDP is really a silly idea. If you need > reliable delivery, then don't use a protocol with "unreliable" > as the first word of it's name. 8-). UDP may well be perfectly viable as a RPC transport, but Terry's misinforming statement is not a good justification. UDP is the User Datagram Protocol. Joshua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 17:49:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by hub.freebsd.org (Postfix) with ESMTP id 9319F37B403 for ; Sat, 18 May 2002 17:49:10 -0700 (PDT) Received: from dialup-209.247.138.189.dial1.sanjose1.level3.net ([209.247.138.189] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 179Esi-000496-00; Sat, 18 May 2002 17:49:04 -0700 Message-ID: <3CE6F653.CDE9D2B4@mindspring.com> Date: Sat, 18 May 2002 17:48:19 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joshua Goodall Cc: Andrew Reilly , Attila Nagy , freebsd-net@freebsd.org Subject: Re: HEADS UP: ALTQ integration developer preview References: <3CE55A9B.73EA3DE4@mindspring.com> <3CE61675.BCE2A9E1@mindspring.com> <1021717195.1466.4.camel@gurney.reilly.home> <3CE6D592.DCF73743@mindspring.com> <20020519001249.GA24012@roughtrade.net> Content-Type: text/plain; charset=us-ascii 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 Joshua Goodall wrote: > On Sat, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote: > > No. TCP. RPC over UDP is really a silly idea. If you need > > reliable delivery, then don't use a protocol with "unreliable" > > as the first word of it's name. 8-). > > UDP may well be perfectly viable as a RPC transport, but Terry's > misinforming statement is not a good justification. > > UDP is the User Datagram Protocol. Was that a "miss" or an "ignore" on the "8-)"? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 18: 7: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from yello.shallow.net (yello.shallow.net [203.18.243.120]) by hub.freebsd.org (Postfix) with ESMTP id 4E4EB37B403 for ; Sat, 18 May 2002 18:07:04 -0700 (PDT) Received: by yello.shallow.net (Postfix, from userid 1001) id 4B70C2A6D; Sun, 19 May 2002 11:07:03 +1000 (EST) Date: Sun, 19 May 2002 11:07:03 +1000 From: Joshua Goodall To: Terry Lambert Cc: Andrew Reilly , Attila Nagy , freebsd-net@freebsd.org Subject: Re: HEADS UP: ALTQ integration developer preview Message-ID: <20020519010703.GE24468@roughtrade.net> References: <3CE55A9B.73EA3DE4@mindspring.com> <3CE61675.BCE2A9E1@mindspring.com> <1021717195.1466.4.camel@gurney.reilly.home> <3CE6D592.DCF73743@mindspring.com> <20020519001249.GA24012@roughtrade.net> <3CE6F653.CDE9D2B4@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CE6F653.CDE9D2B4@mindspring.com> User-Agent: Mutt/1.3.28i 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, May 18, 2002 at 05:48:19PM -0700, Terry Lambert wrote: > Joshua Goodall wrote: > > On Sat, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote: > > > No. TCP. RPC over UDP is really a silly idea. If you need > > > reliable delivery, then don't use a protocol with "unreliable" > > > as the first word of it's name. 8-). > > > > UDP may well be perfectly viable as a RPC transport, but Terry's > > misinforming statement is not a good justification. > > > > UDP is the User Datagram Protocol. > > Was that a "miss" or an "ignore" on the "8-)"? Definitely an ignore. An incorrect statement remains incorrect no matter how many irrelevant smilies are appended in a feeble attempt at irony. Particularly when it reverses the sense of the preceeding statement. Joshua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 20:36: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 6CC7C37B40F; Sat, 18 May 2002 20:35:56 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g4J3ZtU46246; Sat, 18 May 2002 21:35:55 -0600 (MDT) (envelope-from ken) Date: Sat, 18 May 2002 21:35:55 -0600 From: "Kenneth D. Merry" To: John Baldwin Cc: net@FreeBSD.org, current@FreeBSD.org, Alfred Perlstein Subject: Re: new zero copy sockets patches available Message-ID: <20020518213555.A46216@panzer.kdm.org> References: <20020518003046.A36510@panzer.kdm.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 jhb@FreeBSD.org on Sat, May 18, 2002 at 09:03:38AM -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 Sat, May 18, 2002 at 09:03:38 -0400, John Baldwin wrote: > > On 18-May-2002 Kenneth D. Merry wrote: > > On Fri, May 17, 2002 at 23:02:55 -0700, Alfred Perlstein wrote: > >> * Kenneth D. Merry [020517 22:40] wrote: > >> > > >> > I have released a new set of zero copy sockets patches, against -current > >> > from today (May 17th, 2002). > >> > > >> > The main change is to deal with the vfs_ioopt changes that Alan Cox made > >> > in > >> > kern_subr.c. (They conflicted a bit with the zero copy receive code.) > >> > > >> > The patches and the FAQ are available here: > >> > > >> > http://people.freebsd.org/~ken/zero_copy/ > >> > > >> > Comments, questions and reviews are all welcome! > >> > >> jumbo_vm_init() has a bunch of bugs > >> > >> first it doesn't work right if called concurrently. > >> you need to protect the initialization of jumbo_vm_object otherwise > >> bad things can happen. my suggestion is to store the results of > >> vm_object_allocate into a temporary, grab the mutex and then check > >> to see if jumbo_vm_object has been initialized again if it has then > >> free the object, otherwise store the allocated object into the > >> global and continue. > > > > The problem here is that the mutex needs to be initialized before I can > > acquire it, and there's going to be a race between checking to see > > whether it has been initialized and actually initializing it. > > > > e.g.: > > > > if (!mtx_initialized(&jumbo_mutex)) > > mtx_init(&jumbo_mutex, "jumbo mutex", NULL, MTX_DEF); > > > > mtx_lock(&jumbo_mutex); > > > > if (jumbo_vm_object != NULL) { > > mtx_unlock(&jumbo_mutex); > > return (1); > > } > > > > /* allocate our object */ > > jumbo_vm_object = vm_object_allocate(OBJT_DEFAULT, JUMBO_MAX_PAGES); > > > > The above would work, I think, if it weren't for the race in the mutex > > initialization, and assuming I can allocate a vm object while holding > > the jumbo mutex. > > > > Suggestions? > > Either use a sysinit or something gross like this: > > static int jumbo_init = 0; > > ... > while (jumbo_init != 2) { > if (atomic_cmpset_acq_int(&jumbo_init, 0, 1) { > mtx_init(&jumbo_mutex, "jumbo_mutex", NULL, MTX_DEF); > atomic_store_rel_int(&jumbo_init, 2); > } > } > > mtx_lock(&jumbo_mutex); > > ... > > a sysinit is probably best though. Sounds like a sysinit is probably the way to go. I'll give it a try, thanks! Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 20:39:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 30E8137B400; Sat, 18 May 2002 20:39:30 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g4J3dKe46299; Sat, 18 May 2002 21:39:20 -0600 (MDT) (envelope-from ken) Date: Sat, 18 May 2002 21:39:20 -0600 From: "Kenneth D. Merry" To: Andrew Gallatin Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: new zero copy sockets patches available Message-ID: <20020518213920.B46216@panzer.kdm.org> References: <20020517233950.A36169@panzer.kdm.org> <15590.35689.201153.550505@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: <15590.35689.201153.550505@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Sat, May 18, 2002 at 01:12:09PM -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 Sat, May 18, 2002 at 13:12:09 -0400, Andrew Gallatin wrote: > > Kenneth D. Merry writes: > > > > I have released a new set of zero copy sockets patches, against -current > > from today (May 17th, 2002). > > > > The main change is to deal with the vfs_ioopt changes that Alan Cox made in > > kern_subr.c. (They conflicted a bit with the zero copy receive code.) > > > > The patches and the FAQ are available here: > > > > http://people.freebsd.org/~ken/zero_copy/ > > > > Comments, questions and reviews are all welcome! > > > > Hi Ken, > > I'm glad to see that you're still maintining this! > > Assuming the mutex issues get sorted out, what do you think the odds > are of getting this into the tree? The only possible issue I see is > with the tigon firmware. Is the firmware you're using of the same > vintage as what's in the tree now? Does it contain all the same > fixes? I think the odds of getting into the tree are pretty good. I certainly plan to give it a shot. The firmware is basically identical to what we currently have in the tree (12.4.11 plus some fixes Bill Paul picked out from 12.4.13), plus the header splitting patches. There have been some newer firmware releases, up to 12.4.18 I think, but I haven't yet been able to get anything from 3Com. I know 12.4.18 at least fixes some checksum offloading issues in a few strange cases. > Thanks again for keeping this alive, > > Drew Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 18 20:45:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id C82B137B40B; Sat, 18 May 2002 20:45:20 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g4J3j9m46348; Sat, 18 May 2002 21:45:09 -0600 (MDT) (envelope-from ken) Date: Sat, 18 May 2002 21:45:09 -0600 From: "Kenneth D. Merry" To: Don Bowman Cc: "'Andrew Gallatin'" , current@FreeBSD.org, net@FreeBSD.org Subject: Re: new zero copy sockets patches available Message-ID: <20020518214509.C46216@panzer.kdm.org> References: 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 don@sandvine.com on Sat, May 18, 2002 at 01:15:43PM -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 Sat, May 18, 2002 at 13:15:43 -0400, Don Bowman wrote: > > Andrew Gallatin writes: > >> Kenneth D. Merry writes: > >> > > >> > I have released a new set of zero copy sockets patches, against > -current > >> > from today (May 17th, 2002). > > > > Hi Ken, > > > > I'm glad to see that you're still maintining this! > > > > Assuming the mutex issues get sorted out, what do you think the odds > > are of getting this into the tree? The only possible issue I see is > > with the tigon firmware. Is the firmware you're using of the same > > vintage as what's in the tree now? Does it contain all the same > > fixes? > > As a related question, will this work with the broadcom gigabit (bge) > driver, which is the Tigon III? If not, what would it take to get > it working? Unfortunately, it won't work with the Tigon III. If you can get firmware source for the Tigon III, I can probably get header splitting working. (The only way it wouldn't work is if they've offloaded most of the packet processing into the hardware.) The send side code will work on any NIC, and you can kludge up special case header splitting on the receive side if the NIC allows you to break jumbo frames into multiple chunks of data. (This is what Drew originally did for the Tigon II -- you just size the initial chunk of data so that it'll just hold the ethernet header, IP header, TCP header and TCP options, and the payload will "magically" end up page aligned. This doesn't work for protocols other than TCP, and it won't work if your TCP header changes in length.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message