From owner-freebsd-net Mon Mar 25 11:36:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (oe59.pav1.hotmail.com [64.4.30.194]) by hub.freebsd.org (Postfix) with ESMTP id B952C37B404 for ; Mon, 25 Mar 2002 11:36:52 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 11:36:51 -0800 X-Originating-IP: [207.112.2.1] From: "jack xiao" To: Subject: VLAN questions Date: Mon, 25 Mar 2002 14:32:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 25 Mar 2002 19:36:51.0503 (UTC) FILETIME=[696A0BF0:01C1D434] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I set up VLAN attached to some physical interface. It works fine on my own LAN. But it doesn't work on Internet. Does anybody have met this problem? Thanks! Jack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 25 11:42: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 2C0ED37B41A for ; Mon, 25 Mar 2002 11:41:58 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g2PJfsb16467; Mon, 25 Mar 2002 11:41:54 -0800 Date: Mon, 25 Mar 2002 11:41:54 -0800 From: Brooks Davis To: jack xiao Cc: freebsd-net@FreeBSD.ORG Subject: Re: VLAN questions Message-ID: <20020325114154.A15616@Odin.AC.HMC.Edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jack_xiao99@hotmail.com on Mon, Mar 25, 2002 at 02:32:48PM -0500 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 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 25, 2002 at 02:32:48PM -0500, jack xiao wrote: > I set up VLAN attached to some physical interface. It works fine on my own > LAN. But it doesn't work on Internet. Does anybody have met this problem? You need to give a lot more detail if you want an answer. What type of phyisical interface are you using? What is the MTU of the phyisical and vlan interfaces? What do you mean by "is doesn't work"? -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8n32BXY6L6fI4GtQRArXaAKClmgnaskA/2TWACpcZiAAnRk+EagCfabpd XQyhJaH3T8k/vRJS3P1yv6c= =Tvw5 -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 25 13:17:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mave.nlanr.net (mave.nlanr.net [198.202.74.38]) by hub.freebsd.org (Postfix) with ESMTP id AC97637B417 for ; Mon, 25 Mar 2002 13:17:50 -0800 (PST) Received: from localhost (mjl@localhost) by mave.nlanr.net (8.11.1/8.11.1) with ESMTP id g2PLHoE88874 for ; Mon, 25 Mar 2002 13:17:50 -0800 (PST) (envelope-from mjl@nlanr.net) X-Authentication-Warning: mave.nlanr.net: mjl owned process doing -bs Date: Mon, 25 Mar 2002 13:17:50 -0800 (PST) From: Matthew Luckie To: freebsd-net@freebsd.org Subject: ip_output and ENOBUFS 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 I have written a syscall that creates a packet in kernel-space, timestamps it, and then sends it via ip_output If the user-space application uses this system call faster than the packets can be sent, ip_output will return ENOBUFS. Is there a mechanism to tell when ip_output should be called again? Ideally, I would block until such time as i could send it via ip_output (please CC: me on any responses) Matthew Luckie mjl@nlanr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 25 13:42: 9 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 8575237B434 for ; Mon, 25 Mar 2002 13:41:31 -0800 (PST) Received: from isi.edu (ahzw44c97y6rbte6@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g2PLfU010736; Mon, 25 Mar 2002 13:41:30 -0800 (PST) Message-ID: <3C9F9989.4070201@isi.edu> Date: Mon, 25 Mar 2002 13:41:29 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020320 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Matthew Luckie Cc: freebsd-net@freebsd.org Subject: Re: ip_output and ENOBUFS References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070409060100090209060308" 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. --------------ms070409060100090209060308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Matthew Luckie wrote: > I have written a syscall that creates a packet in kernel-space, > timestamps it, and then sends it via ip_output > > If the user-space application uses this system call faster than the > packets can be sent, ip_output will return ENOBUFS. > > Is there a mechanism to tell when ip_output should be called again? > Ideally, I would block until such time as i could send it via ip_output You probably get that because the outbound interface queue gets full, so you want to block your caller until space becomes available there. There currently is no such mechanism (AFAIK, and talking about -STABLE here), but it's not too much work to add. Not sure if this is really useful though. Ususally the NIC doesn't limit your transmission speed, it's losses inside the network that do. Also, why a new system call? Is it that much more efficient than RawIP? Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms070409060100090209060308 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 DTAyMDMyNTIxNDEzMFowIwYJKoZIhvcNAQkEMRYEFKOc88v9loy4+rGnabXHLq3hurmdMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYCIAy/JEFT+ub2gGeA2WTZXLHhkHkdZcJ5fwoBdPfw81BUFPSUDqb6uRmx/OPasX6ob XhcvnNzewsQzDMVgvcEILehkpPrn1IvuwNpXEKuJ/8YSMoIFnHw90Sppb71hldyUvqClhYd9 WUBhBqd+KZcDmDj1UHk8MwTJrI7gvRr78wAAAAAAAA== --------------ms070409060100090209060308-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 25 14: 3:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from mave.nlanr.net (mave.nlanr.net [198.202.74.38]) by hub.freebsd.org (Postfix) with ESMTP id C926137B416 for ; Mon, 25 Mar 2002 14:03:36 -0800 (PST) Received: from localhost (mjl@localhost) by mave.nlanr.net (8.11.1/8.11.1) with ESMTP id g2PM3ZG89096; Mon, 25 Mar 2002 14:03:35 -0800 (PST) (envelope-from mjl@nlanr.net) X-Authentication-Warning: mave.nlanr.net: mjl owned process doing -bs Date: Mon, 25 Mar 2002 14:03:35 -0800 (PST) From: Matthew Luckie To: Lars Eggert Cc: freebsd-net@freebsd.org Subject: Re: ip_output and ENOBUFS In-Reply-To: <3C9F9989.4070201@isi.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 > > Is there a mechanism to tell when ip_output should be called again? > > Ideally, I would block until such time as i could send it via ip_output > > You probably get that because the outbound interface queue gets full, so > you want to block your caller until space becomes available there. There > currently is no such mechanism (AFAIK, and talking about -STABLE here), > but it's not too much work to add. i've worked at a layer above ip_output, but i havent looked to deeply at this issue and the code in the kernel. if you could suggest a few modifications that would be required, i'd like to pursue this further. Thanks for your response. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 25 14: 6:25 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 E1B8B37B400 for ; Mon, 25 Mar 2002 14:06:19 -0800 (PST) Received: from isi.edu (gfvwyr2uu6lb6sll@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g2PM6J025570; Mon, 25 Mar 2002 14:06:19 -0800 (PST) Message-ID: <3C9F9F5B.4090409@isi.edu> Date: Mon, 25 Mar 2002 14:06:19 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020320 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Matthew Luckie Cc: freebsd-net@freebsd.org Subject: Re: ip_output and ENOBUFS References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070005080302030001000102" 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. --------------ms070005080302030001000102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Matthew Luckie wrote: >>>Is there a mechanism to tell when ip_output should be called again? >>>Ideally, I would block until such time as i could send it via ip_output >> >>You probably get that because the outbound interface queue gets full, so >>you want to block your caller until space becomes available there. There >>currently is no such mechanism (AFAIK, and talking about -STABLE here), >>but it's not too much work to add. > > if you could suggest a few modifications that would be required, i'd like > to pursue this further. Look at tsleep/wakeup on ifnet of if_snd. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms070005080302030001000102 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 DTAyMDMyNTIyMDYxOVowIwYJKoZIhvcNAQkEMRYEFORJCs7pichugQ16pJYz2+rfNcpwMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYCvbc2BaSR6a05bPjKDy3RfKu6d5CfTqyyXh1e7jbhB+81VaQbaQMRNSnGVznvgwsVn c4iUNbDxrdRXED1e4R4ZC0bjaPXSAyXBWJWrTmGZIT6SQt88g6yX4qJSocU9Vw2ehfnEzwx0 R/woA6UwRv4HsDZ+SK0bb9S4+iqkIJqoZQAAAAAAAA== --------------ms070005080302030001000102-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 25 14: 8:44 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 1D67137B416 for ; Mon, 25 Mar 2002 14:08:23 -0800 (PST) Received: from isi.edu (s0hrrg7h2lk7u8j7@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g2PM87027115; Mon, 25 Mar 2002 14:08:07 -0800 (PST) Message-ID: <3C9F9FC6.2070609@isi.edu> Date: Mon, 25 Mar 2002 14:08:06 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020320 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Lars Eggert Cc: Matthew Luckie , freebsd-net@freebsd.org Subject: Re: ip_output and ENOBUFS References: <3C9F9F5B.4090409@isi.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090809040308030603020106" 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. --------------ms090809040308030603020106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lars Eggert wrote: > Matthew Luckie wrote: > >>>> Is there a mechanism to tell when ip_output should be called again? >>>> Ideally, I would block until such time as i could send it via ip_output >>> >>> >>> You probably get that because the outbound interface queue gets full, >>> so you want to block your caller until space becomes available there. >>> There currently is no such mechanism (AFAIK, and talking about >>> -STABLE here), but it's not too much work to add. >> >> >> if you could suggest a few modifications that would be required, i'd like >> to pursue this further. > > > Look at tsleep/wakeup on ifnet of if_snd. ^^ or Sorry, big fingers. -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms090809040308030603020106 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 DTAyMDMyNTIyMDgwNlowIwYJKoZIhvcNAQkEMRYEFHfGrZ/BqOntHV6qP66KVD3hfPrPMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYCEi6aSoLMigpON8iTpyxpyCCRGQVedXvxeg1Mh0tsvVwhl+suzNVoy9BQP/fJY9/fn o7CTOpzYjUBJjYrAHKJADUvv0QJQH8nGhDwH+Duij7CVWjjG7GTESTpouOWuehnbxq5qN7fL Mzu6N/szRG7j3IU7Zsp9tcqePZ5NMGKR2AAAAAAAAA== --------------ms090809040308030603020106-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 25 14:42:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id DAF7737B9FC for ; Mon, 25 Mar 2002 14:40:32 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020325224012.SZWN2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Mon, 25 Mar 2002 22:40:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA38320; Mon, 25 Mar 2002 14:34:20 -0800 (PST) Date: Mon, 25 Mar 2002 14:34:19 -0800 (PST) From: Julian Elischer To: Matthew Luckie Cc: freebsd-net@freebsd.org Subject: Re: ip_output and ENOBUFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 25 Mar 2002, Matthew Luckie wrote: > Hi > > > Is there a mechanism to tell when ip_output should be called again? > Ideally, I would block until such time as i could send it via ip_output no, there is no such mechanism that I know of.. > > (please CC: me on any responses) > > Matthew Luckie > mjl@nlanr.net > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 25 14:55: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 4695C37B41F for ; Mon, 25 Mar 2002 14:54:50 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g2PMslm03074; Mon, 25 Mar 2002 14:54:47 -0800 (PST) (envelope-from rizzo) Date: Mon, 25 Mar 2002 14:54:47 -0800 From: Luigi Rizzo To: Lars Eggert Cc: Matthew Luckie , freebsd-net@FreeBSD.ORG Subject: Re: ip_output and ENOBUFS Message-ID: <20020325145447.A2986@iguana.icir.org> References: <3C9F9F5B.4090409@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C9F9F5B.4090409@isi.edu> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Mar 25, 2002 at 02:06:19PM -0800, Lars Eggert wrote: > Matthew Luckie wrote: > >>>Is there a mechanism to tell when ip_output should be called again? ... > >if you could suggest a few modifications that would be required, i'd like > >to pursue this further. > > Look at tsleep/wakeup on ifnet of if_snd. I am under the impression that implementing this mechanism would not be so trivial. It is not immediate to tell back to the caller on which interface ip_output() failed. Nor there is a common place that i know of where you can be notified that a packet was successfully transmitted -- i suspect you should patch all individual drivers. Finally, there is the question on whether you do a wakeup as soon as you get a free slot in the queue (in which case you most likely end up paying the cost of a tsleep/wakeup pair on each transmission), or you put some histeresys. cheers luigi > Lars > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 25 18:11:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by hub.freebsd.org (Postfix) with ESMTP id 1AF6F37B400 for ; Mon, 25 Mar 2002 18:11:48 -0800 (PST) Received: from hsu (dhcp252.nttmcl.com [216.69.69.252]) by alicia.nttmcl.com (8.10.1/8.10.1) with SMTP id g2Q2Bhv16776; Mon, 25 Mar 2002 18:11:43 -0800 (PST) Reply-To: From: "Henry Su" To: "jack xiao" , Subject: RE: VLAN questions Date: Mon, 25 Mar 2002 18:13:54 -0800 Message-ID: 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 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 No, we do not have this problem. If it works on your LAN, it should work on Internet too. -----Original Message----- From: owner-freebsd-net@FreeBSD.ORG [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of jack xiao Sent: Monday, March 25, 2002 11:33 AM To: freebsd-net@FreeBSD.ORG Subject: VLAN questions Hi, I set up VLAN attached to some physical interface. It works fine on my own LAN. But it doesn't work on Internet. Does anybody have met this problem? Thanks! Jack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 25 18:24:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from rerun.avayactc.com (rerun.avayactc.com [199.93.237.2]) by hub.freebsd.org (Postfix) with ESMTP id 2920E37B41C for ; Mon, 25 Mar 2002 18:24:41 -0800 (PST) Received: by rerun.avayactc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 21:23:34 -0500 Message-ID: <3A6D367EA1EFD4118C9B00A0C9DD99D70655CA@rerun.avayactc.com> From: "Cambria, Mike" To: 'Archie Cobbs' , Julian Elischer , "'freebsd-net@freebsd.org'" Cc: "Cambria, Mike" Subject: RE: Unnumbered IP Interface Date: Mon, 25 Mar 2002 21:23:25 -0500 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 Thanks. I have a few follow-up questions to your answer. I'm not using netgraph (at least at the moment). Will this matter? I assume 'ifconfig lmc0 up' is all I need to do to bring the interface up prior to "route add -iface lmc0..." On FreeBSD, do I need to do anything special to run OSPF or BGP4 over an unnumbered interface? (If I remember correctly RIP doesn't support an unnumbered interface.) I have four of these lmc cards. Besides the leased line monthly charges ... am I crazy doing this on FreeBSD? They all work in one machine at the moment (4.5-Stable). I'm just starting to get the p2p routing setup (it has been a long time.) Are 4 unnumbered interfaces supported in one machine? Can they all point to the same next hop? 4 different next hops? A combination? Thanks, MikeC -----Original Message----- From: Archie Cobbs [mailto:archie@dellroad.org] Sent: Friday, March 22, 2002 1:19 AM To: Julian Elischer Cc: Cambria, Mike; 'freebsd-net@freebsd.org' Subject: Re: Unnumbered IP Interface Julian Elischer writes: > A while ago it was possible to use 'route' to add a rout eto a p2p > interface by name and not assign it any addresses. Yes, this still works.. e.g., "route add 1.2.3.4 -iface ng0". The interface has to be marked 'UP' of course. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 25 19: 0:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 8C3C637B419 for ; Mon, 25 Mar 2002 19:00:19 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020326030019.JTLJ1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Tue, 26 Mar 2002 03:00:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA39249; Mon, 25 Mar 2002 18:49:20 -0800 (PST) Date: Mon, 25 Mar 2002 18:49:20 -0800 (PST) From: Julian Elischer To: "Cambria, Mike" Cc: "'Archie Cobbs'" , "'freebsd-net@freebsd.org'" Subject: RE: Unnumbered IP Interface In-Reply-To: <3A6D367EA1EFD4118C9B00A0C9DD99D70655CA@rerun.avayactc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 25 Mar 2002, Cambria, Mike wrote: > > Thanks. I have a few follow-up questions to your answer. > > I'm not using netgraph (at least at the moment). Will this matter? No it's a totally sepaate matter. > > I assume 'ifconfig lmc0 up' is all I need to do to bring the interface up > prior to "route add -iface lmc0..." yes, assuming it's a point-to-point interface. > > On FreeBSD, do I need to do anything special to run OSPF or BGP4 over an > unnumbered interface? (If I remember correctly RIP doesn't support an > unnumbered interface.) I have NO idea.. I've only used it with static routes. > > I have four of these lmc cards. Besides the leased line monthly charges ... > am I crazy doing this on FreeBSD? They all work in one machine at the > moment (4.5-Stable). I'm just starting to get the p2p routing setup (it has > been a long time.) Are 4 unnumbered interfaces supported in one machine? > Can they all point to the same next hop? 4 different next hops? A > combination? It all depends on what you want to do. what is the driver called? does it have a netgraph interface? (if so you can GANG the cards by using the one2many netgraph node. otherwise I need more info on what you are trying to do.... > > Thanks, > MikeC > > -----Original Message----- > From: Archie Cobbs [mailto:archie@dellroad.org] > Sent: Friday, March 22, 2002 1:19 AM > To: Julian Elischer > Cc: Cambria, Mike; 'freebsd-net@freebsd.org' > Subject: Re: Unnumbered IP Interface > > Julian Elischer writes: > > A while ago it was possible to use 'route' to add a rout eto a p2p > > interface by name and not assign it any addresses. > > Yes, this still works.. e.g., "route add 1.2.3.4 -iface ng0". > > The interface has to be marked 'UP' of course. > > -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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 7: 1: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from rerun.avayactc.com (rerun.avayactc.com [199.93.237.2]) by hub.freebsd.org (Postfix) with ESMTP id DE2C737B417 for ; Tue, 26 Mar 2002 07:00:52 -0800 (PST) Received: by rerun.avayactc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 09:59:43 -0500 Message-ID: <3A6D367EA1EFD4118C9B00A0C9DD99D70655CE@rerun.avayactc.com> From: "Cambria, Mike" To: 'Julian Elischer' , 'Archie Cobbs' , "'freebsd-net@freebsd.org'" Subject: RE: Unnumbered IP Interface Date: Tue, 26 Mar 2002 09:59:40 -0500 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 The driver is lmc. The version from the SBEI (formally LanMedia) web site does not support netgraph. Their support claims to have one (or will have one I forget). I want to hold off on NG at the moment. As for what I'm doing. In this case, I have 4 of these PCI cards. I eventually, I want to be dual homed to 2 different ISP's and run BGP4. The other two p2p lines will go to different remote sites (e.g. "leased line"). I'll need to run OSPF (or possibly RIP) on the leased lines and BGP4 to the ISP's. In one case, the box at the other end forces me to use unnumbered interfaces (hence my initial message). In the other cases I'm staging the BSD box here first. There are subnets at the other end of all these p2p connections. Route advertisements will need to be exchanged over the p2p links. I'm just getting to this part in the lab now and wanted to get some hints. For example, Archie's answer for unnumbered interfaces isn't in the route manpage. I'm glad I asked. MikeC -----Original Message----- From: Julian Elischer [mailto:julian@elischer.org] Sent: Monday, March 25, 2002 9:49 PM To: Cambria, Mike Cc: 'Archie Cobbs'; 'freebsd-net@freebsd.org' Subject: RE: Unnumbered IP Interface On Mon, 25 Mar 2002, Cambria, Mike wrote: > > Thanks. I have a few follow-up questions to your answer. > > I'm not using netgraph (at least at the moment). Will this matter? No it's a totally sepaate matter. > > I assume 'ifconfig lmc0 up' is all I need to do to bring the interface up > prior to "route add -iface lmc0..." yes, assuming it's a point-to-point interface. > > On FreeBSD, do I need to do anything special to run OSPF or BGP4 over an > unnumbered interface? (If I remember correctly RIP doesn't support an > unnumbered interface.) I have NO idea.. I've only used it with static routes. > > I have four of these lmc cards. Besides the leased line monthly charges ... > am I crazy doing this on FreeBSD? They all work in one machine at the > moment (4.5-Stable). I'm just starting to get the p2p routing setup (it has > been a long time.) Are 4 unnumbered interfaces supported in one machine? > Can they all point to the same next hop? 4 different next hops? A > combination? It all depends on what you want to do. what is the driver called? does it have a netgraph interface? (if so you can GANG the cards by using the one2many netgraph node. otherwise I need more info on what you are trying to do.... > > Thanks, > MikeC > > -----Original Message----- > From: Archie Cobbs [mailto:archie@dellroad.org] > Sent: Friday, March 22, 2002 1:19 AM > To: Julian Elischer > Cc: Cambria, Mike; 'freebsd-net@freebsd.org' > Subject: Re: Unnumbered IP Interface > > Julian Elischer writes: > > A while ago it was possible to use 'route' to add a rout eto a p2p > > interface by name and not assign it any addresses. > > Yes, this still works.. e.g., "route add 1.2.3.4 -iface ng0". > > The interface has to be marked 'UP' of course. > > -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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 8:49: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mave.nlanr.net (mave.nlanr.net [198.202.74.38]) by hub.freebsd.org (Postfix) with ESMTP id 90DC137B419 for ; Tue, 26 Mar 2002 08:49:05 -0800 (PST) Received: from localhost (mjl@localhost) by mave.nlanr.net (8.11.1/8.11.1) with ESMTP id g2QGmx092341; Tue, 26 Mar 2002 08:48:59 -0800 (PST) (envelope-from mjl@nlanr.net) X-Authentication-Warning: mave.nlanr.net: mjl owned process doing -bs Date: Tue, 26 Mar 2002 08:48:59 -0800 (PST) From: Matthew Luckie To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: ip_output and ENOBUFS In-Reply-To: <20020325145447.A2986@iguana.icir.org> 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 am under the impression that implementing this mechanism would > not be so trivial. hmm, we looked at how other protocols handled the ENOBUFS case from ip_output. tcp_output calls tcp_quench on this error. while the interface may not be able to send any more packets than it does currently, closing the congestion window back to 1 segment seems a severe way to handle this error, knowing that the network did not drop the packet due to congestion. Ideally, there might be some form of blocking until such time as a mbuf comes available. This sounds as if it will be much easier come FreeBSD 5.0 I'm aware that if people are hitting this condition, they need to increase the number of mbufs to get maximum performance. This section of code has previously been discussed here: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=119188+0+archive/2000/freebsd-net/20000730.freebsd-net and has been in use for many years (a glance at TCP/IP Illustrated Vol 2 shows similar code), so there is probably a good reason that I am not aware of for this code to be in place. Comments? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 9: 9:25 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 9093F37B41E for ; Tue, 26 Mar 2002 09:09:19 -0800 (PST) Received: from isi.edu (nylpwi31cjs89nty@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g2QH9I015244; Tue, 26 Mar 2002 09:09:18 -0800 (PST) Message-ID: <3CA0AB3D.5000300@isi.edu> Date: Tue, 26 Mar 2002 09:09:17 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020322 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Matthew Luckie Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: ip_output and ENOBUFS References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020106030009060502050803" 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. --------------ms020106030009060502050803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Matthew Luckie wrote: > hmm, we looked at how other protocols handled the ENOBUFS case from > ip_output. > > tcp_output calls tcp_quench on this error. > > while the interface may not be able to send any more packets than it > does currently, closing the congestion window back to 1 segment > seems a severe way to handle this error, knowing that the network > did not drop the packet due to congestion. Ideally, there might be > some form of blocking until such time as a mbuf comes available. > This sounds as if it will be much easier come FreeBSD 5.0 TCP will almost never encouter this scenario, since it's self-clocking. The NIC is very rarely the bottleneck resource for a given network connection. Have you looked at mean queue lengths for NICs? They are typically zero or one. The NIC will only be the bottleneck if you are sending at a higher rate than line speed and your burt time is too long to be absorbed by the queue. > I'm aware that if people are hitting this condition, they need to > increase the number of mbufs to get maximum performance. No. ENOBUFS in ip_output almost always means that your NIC queue is full, which isn't controlled through mbufs. You can make the queue longer, but that won't help if you're sending too fast. > This section of code has previously been discussed here: > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=119188+0+archive/2000/fr- > eebsd-net/20000730.freebsd-net and has been in use for many years (a This is a slightly different problem than you describe. What Archie saw was an ENOBUFS being handled like a loss inside the network, even though the sender has information locally that can allow it to make smarter retransmission decisions. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms020106030009060502050803 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 DTAyMDMyNjE3MDkxN1owIwYJKoZIhvcNAQkEMRYEFL8F/RoKgewxrN9mTpQasOH4HIZPMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYBos3m9Uz1SsX+IQI2NCn6ZmAIFiIUoG9Dz+NJHpJohQf7oS2H0Ffy3AWhk0LdmqJmB iN771vOJ3z/86Vs1y8KAYJhhT2gWNXA+KB064yvUwNR/rMzKwCWVKFEAmlIGzUq78pJ/gfhk mapYst7aCXuEUZ3DN9OCPLhmeLYYwXKCUAAAAAAAAA== --------------ms020106030009060502050803-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 12:38:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from hairball.treehouse.napa.ca.us (dsl-64-128-194-169.telocity.com [64.128.194.169]) by hub.freebsd.org (Postfix) with ESMTP id 76E1A37B405 for ; Tue, 26 Mar 2002 12:38:37 -0800 (PST) Received: (from mailnull@localhost) by hairball.treehouse.napa.ca.us (8.11.6/8.11.5) id g2QKcbl55210 for freebsd-net@freebsd.org; Tue, 26 Mar 2002 12:38:37 -0800 (PST) (envelope-from mailnull) Received: (from news@localhost) by hairball.treehouse.napa.ca.us (8.11.6/8.11.5) id g2QKcah55196 for treehouse-mail-freebsd-net@hairball.treehouse.napa.ca.us; Tue, 26 Mar 2002 12:38:36 -0800 (PST) (envelope-from news) From: "G. Paul Ziemba" To: treehouse-mail-freebsd-net@treehouse.napa.ca.us Subject: should tcp_reass() update tcps_rcvpartduppack, tcps_rcvpartdupbyte? Date: Tue, 26 Mar 2002 20:38:36 +0000 (UTC) Message-id: Reply-To: paul@w6yx.stanford.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is just a nit, but it seems to me that although the code in tcp_reass() counts completely overlapping packets via the statistics tcps_rcvduppack and tcps_rcvdupbyte, it does NOT count partially overlapping packets as it should with tcps_rcvpartduppack and tcps_rcvpartdupbyte. I'm thinking that the following change ought to do the right thing, but I'd like to know if anyone disagrees: --- tcp_input.c Sat Dec 15 03:23:56 2001 +++ tcp_input.c+ Tue Mar 26 11:04:35 2002 @@ -223,6 +223,9 @@ * completes. */ goto present; /* ??? */ + } else { + tcpstat.tcps_rcvpartduppack++; + tcpstat.tcps_rcvpartdupbyte += *tlenp; } m_adj(m, i); *tlenp -= i; -- G. Paul Ziemba paul@w6yx.stanford.edu FreeBSD unix: 12:36PM up 1 day, 2:44, 9 users, load averages: 0.04, 0.04, 0.01 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 13: 0:18 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 2CA1D37B400 for ; Tue, 26 Mar 2002 13:00:05 -0800 (PST) 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 MAA48616; Tue, 26 Mar 2002 12:45:00 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g2QKicE37079; Tue, 26 Mar 2002 12:44:38 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200203262044.g2QKicE37079@arch20m.dellroad.org> Subject: Re: Unnumbered IP Interface In-Reply-To: <3A6D367EA1EFD4118C9B00A0C9DD99D70655CE@rerun.avayactc.com> "from Cambria, Mike at Mar 26, 2002 09:59:40 am" To: "Cambria, Mike" Date: Tue, 26 Mar 2002 12:44:38 -0800 (PST) Cc: "'Julian Elischer'" , "'Archie Cobbs'" , "'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 Cambria, Mike writes: > example, Archie's answer for unnumbered interfaces isn't in the route > manpage. I'm glad I asked. Quoting route(8): "If the destination is directly reachable via an interface requiring no intermediary system to act as a gateway, the -interface modifier should be specified; the gateway given is the address of this host on the common network, indicating the interface to be used for transmission. Alter- nately, if the interface is point to point the name of the interface itself may be given, in which case the route remains valid even if the local or remote addresses change. By the way, you can have an "unnumbered" P2P interface that still has an IP address configured on it -- just configure the same IP address that's on another interface, e.g.: $ ifconfig dc0: flags=8843 mtu 1500 inet 192.168.0.223 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:a0:cc:d6:cc:b1 media: Ethernet autoselect (100baseTX ) status: active ng0: flags=88d1 mtu 1500 inet 192.168.0.223 --> 1.2.3.4 netmask 0xffffff00 This is sometimes known as "half-routing".. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 13:40:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id C22EC37B419 for ; Tue, 26 Mar 2002 13:40:12 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020326214012.PXA2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Tue, 26 Mar 2002 21:40:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA43269; Tue, 26 Mar 2002 13:28:25 -0800 (PST) Date: Tue, 26 Mar 2002 13:28:24 -0800 (PST) From: Julian Elischer To: "Cambria, Mike" Cc: "'Archie Cobbs'" , "'freebsd-net@freebsd.org'" Subject: RE: Unnumbered IP Interface In-Reply-To: <3A6D367EA1EFD4118C9B00A0C9DD99D70655CE@rerun.avayactc.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 You only need to use unnumbered interfaces on one local link, so you are ok.. you can use static routes to get to and from that site.. and leave BGP to handle the double homed links to the Internet. On Tue, 26 Mar 2002, Cambria, Mike wrote: > > The driver is lmc. The version from the SBEI (formally LanMedia) web site > does not support netgraph. Their support claims to have one (or will have > one I forget). I want to hold off on NG at the moment. > > As for what I'm doing. In this case, I have 4 of these PCI cards. I > eventually, I want to be dual homed to 2 different ISP's and run BGP4. The > other two p2p lines will go to different remote sites (e.g. "leased line"). > I'll need to run OSPF (or possibly RIP) on the leased lines and BGP4 to the > ISP's. > > In one case, the box at the other end forces me to use unnumbered interfaces > (hence my initial message). In the other cases I'm staging the BSD box here > first. > > There are subnets at the other end of all these p2p connections. Route > advertisements will need to be exchanged over the p2p links. I'm just > getting to this part in the lab now and wanted to get some hints. For > example, Archie's answer for unnumbered interfaces isn't in the route > manpage. I'm glad I asked. > > MikeC > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 13:46:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from cobalt.hytekblue.com (adsl-208-191-100-47.dsl.stlsmo.swbell.net [208.191.100.47]) by hub.freebsd.org (Postfix) with ESMTP id 781EC37B417 for ; Tue, 26 Mar 2002 13:46:39 -0800 (PST) Received: from duron-1150 ([10.0.0.177]) by cobalt.hytekblue.com (8.9.3/8.9.3) with ESMTP id PAA12873 for ; Tue, 26 Mar 2002 15:46:52 -0600 (CST) (envelope-from mgt@hytekblue.com) Message-ID: <200203261546400907.06F1A46F@cobalt.hytekblue.com> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Tue, 26 Mar 2002 15:46:40 -0600 Reply-To: mgt@hytekblue.com From: "Matthew" To: freebsd-net@FreeBSD.ORG Subject: routeing problems with 4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a machine that was in service for a month when it ceased to have a= default gateway. I have one listed in the rc.conf file. but when you do a= netstat -r it does not show up. the machine can see anything on the local= network includeing the gateway ip which does snow up when you do a netstat= -r but no static route will show up at all. does anyone have any idea's. i= would like to figure this one out as oposed to simply re-installing the= os. thanks for any light anyone can shed on this. Matthew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 14:17:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by hub.freebsd.org (Postfix) with SMTP id 3FCFF37B416 for ; Tue, 26 Mar 2002 14:17:36 -0800 (PST) Received: (qmail 79391 invoked by uid 1013); 26 Mar 2002 22:17:34 -0000 Date: Tue, 26 Mar 2002 23:17:34 +0100 From: Markus Stumpf To: freebsd-net@FreeBSD.ORG Subject: problems with udp46 sockets Message-ID: <20020326231734.H58573@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF 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 am trying to get dnscache running with IPv6 patches. dnscache binds to the IPv6 unqualified address "::". This works fine and I get (from netstat) udp46 0 0 *.53 *.* As the sending address the IPv6 unqualified address "::" is used, also. As long as I only send queries via either IPv6 or IPv4 all works well, but all subsequent queries via IPv6 after one or more queries via IPv4 fail. The queries arrive properly, but sending the answer fails. From truss I can see for that IPv6 answers: sendto(0x3,0x80f34e0,0x55,0x0,0xbfbffbd0,0x1c) ERR#65 'No route to host' for all queries via IPv6, queries via IPv4 still work without problems. It doesn't matter if I use different source hosts for the queries via IPv6, it fails for all of them. The code sending the answers is: int socket_send6(int s,const char *buf,unsigned int len,const char ip[16],uint16 port,uint32 scope_id) { struct sockaddr_in6 sa; byte_zero(&sa,sizeof sa); sa.sin6_family = AF_INET6; if (scope_id) uint32_pack_big((char *)&sa.sin6_scope_id, scope_id); uint16_pack_big((char *) &sa.sin6_port,port); byte_copy((char *) &sa.sin6_addr,16,ip); return sendto(s,buf,len,0,(struct sockaddr *) &sa,sizeof sa); } I have checked with debug output and the port and dest ip address are correctly filled in. What really puzzles me is that answers via IPv4 seem to cause some kind of confusion so that subsequent IPv6 packets have the "no route to host" error, but answers via IPv4 still work. Also there is no problem to ping6 the hosts from each other. I am running FreeBSD 4.5-RELEASE GENERIC kernel. I have also applied the patch from this list http://docs.freebsd.org/cgi/getmsg.cgi?fetch=345287+0+archive/2002/freebsd-net/20020224.freebsd-net From: JINMEI Tatuya / ?$B?@L@C#:H?(B Subject: Re: nd6_rtrequest: bad gateway value: stf0 Date: Sat, 23 Feb 2002 01:32:22 +0900 Message-ID: and built a new kernel, but that didn't fix the problem (thought it could be related). Could it be that the problem JINMEI Tatuya fixed in http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=100979+0+/usr/local/www/db/text/2002/freebsd-hackers/20020303.freebsd-hackers for TCP also applies to UDP (and has to be fixed there?) Any ideas? If you need more information, I'll be happy to provide it. Thanks, \Maex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 14:40:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 8141C37B404 for ; Tue, 26 Mar 2002 14:40:15 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020326224015.MOHB1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Tue, 26 Mar 2002 22:40:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA43568; Tue, 26 Mar 2002 14:23:19 -0800 (PST) Date: Tue, 26 Mar 2002 14:23:19 -0800 (PST) From: Julian Elischer To: Matthew Cc: freebsd-net@FreeBSD.ORG Subject: Re: routeing problems with 4.4 In-Reply-To: <200203261546400907.06F1A46F@cobalt.hytekblue.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 are you running dhclient or routed? On Tue, 26 Mar 2002, Matthew wrote: > I have a machine that was in service for a month when it ceased to have a default gateway. I have one listed in the rc.conf file. but when you do a netstat -r it does not show up. the machine can see anything on the local network includeing the gateway ip which does snow up when you do a netstat -r but no static route will show up at all. does anyone have any idea's. i would like to figure this one out as oposed to simply re-installing the os. > > thanks for any light anyone can shed on this. > > Matthew > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 16:32:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from web21109.mail.yahoo.com (web21109.mail.yahoo.com [216.136.227.111]) by hub.freebsd.org (Postfix) with SMTP id 181C037B404 for ; Tue, 26 Mar 2002 16:32:17 -0800 (PST) Message-ID: <20020327003216.55237.qmail@web21109.mail.yahoo.com> Received: from [152.15.26.29] by web21109.mail.yahoo.com via HTTP; Tue, 26 Mar 2002 16:32:16 PST Date: Tue, 26 Mar 2002 16:32:16 -0800 (PST) From: Vinod Subject: network monitoring tools for streaming video To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Can anyone tell me what network monitoring tools are available on freebsd suitable for monitoring things like frame size,frames per second,frame no. e.t.c when streaming videos are received though the network. Thanks, Vinod __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 17:16:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id A46E437B400 for ; Tue, 26 Mar 2002 17:16:52 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020327011652.IYGN2951.rwcrmhc53.attbi.com@blossom.cjclark.org>; Wed, 27 Mar 2002 01:16:52 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g2R1Gjh91257; Tue, 26 Mar 2002 17:16:45 -0800 (PST) (envelope-from cjc) Date: Tue, 26 Mar 2002 17:16:45 -0800 From: "Crist J. Clark" To: Matthew Cc: freebsd-net@FreeBSD.ORG Subject: Re: routeing problems with 4.4 Message-ID: <20020326171645.G89885@blossom.cjclark.org> References: <200203261546400907.06F1A46F@cobalt.hytekblue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200203261546400907.06F1A46F@cobalt.hytekblue.com>; from mgt@hytekblue.com on Tue, Mar 26, 2002 at 03:46:40PM -0600 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Mar 26, 2002 at 03:46:40PM -0600, Matthew wrote: > I have a machine that was in service for a month when it ceased to have a default gateway. I have one listed in the rc.conf file. but when you do a netstat -r it does not show up. the machine can see anything on the local network includeing the gateway ip which does snow up when you do a netstat -r but no static route will show up at all. does anyone have any idea's. i would like to figure this one out as oposed to simply re-installing the os. *blink, blink* Why on Earth would you reinstall the operating system? Are you saying when you try to add the route again, # route add default It doesn't actually show up in the routing table? -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 18:20:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 2DE0937B41C for ; Tue, 26 Mar 2002 18:20:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020327022007.VCXT1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Wed, 27 Mar 2002 02:20:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA44419; Tue, 26 Mar 2002 18:11:43 -0800 (PST) Date: Tue, 26 Mar 2002 18:11:42 -0800 (PST) From: Julian Elischer To: "Cambria, Mike" Cc: net@freebsd.org Subject: RE: Unnumbered IP Interface In-Reply-To: <3A6D367EA1EFD4118C9B00A0C9DD99D70655CE@rerun.avayactc.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 [looks at website] will read.. hmmmm. hmmmmm I'm sure I've seen this somewhere before.. ah it's in -current... in /usr/src/sys/dev/lmc the version there DOES support netgraph but I don;t know if it's well maintained.. I'll have to look at it sometime. On Tue, 26 Mar 2002, Cambria, Mike wrote: > > The driver is lmc. The version from the SBEI (formally LanMedia) web site > does not support netgraph. Their support claims to have one (or will have > one I forget). I want to hold off on NG at the moment. > > As for what I'm doing. In this case, I have 4 of these PCI cards. I > eventually, I want to be dual homed to 2 different ISP's and run BGP4. The > other two p2p lines will go to different remote sites (e.g. "leased line"). > I'll need to run OSPF (or possibly RIP) on the leased lines and BGP4 to the > ISP's. > > In one case, the box at the other end forces me to use unnumbered interfaces > (hence my initial message). In the other cases I'm staging the BSD box here > first. > > There are subnets at the other end of all these p2p connections. Route > advertisements will need to be exchanged over the p2p links. I'm just > getting to this part in the lab now and wanted to get some hints. For > example, Archie's answer for unnumbered interfaces isn't in the route > manpage. I'm glad I asked. > > MikeC > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 22:15:40 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 515A837B417 for ; Tue, 26 Mar 2002 22:15:34 -0800 (PST) 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 WAA51833; Tue, 26 Mar 2002 22:10:27 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g2R6A5x39204; Tue, 26 Mar 2002 22:10:05 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200203270610.g2R6A5x39204@arch20m.dellroad.org> Subject: Re: ip_output and ENOBUFS In-Reply-To: <20020325145447.A2986@iguana.icir.org> "from Luigi Rizzo at Mar 25, 2002 02:54:47 pm" To: Luigi Rizzo Date: Tue, 26 Mar 2002 22:10:05 -0800 (PST) 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 Luigi Rizzo writes: > > >if you could suggest a few modifications that would be required, i'd like > > >to pursue this further. > > > > Look at tsleep/wakeup on ifnet of if_snd. > > I am under the impression that implementing this mechanism would > not be so trivial. It is not immediate to tell back to the caller > on which interface ip_output() failed. Nor there is a common place > that i know of where you can be notified that a packet was successfully > transmitted -- i suspect you should patch all individual drivers. > Finally, there is the question on whether you do a wakeup as soon > as you get a free slot in the queue (in which case you most likely > end up paying the cost of a tsleep/wakeup pair on each transmission), > or you put some histeresys. Along those lines, this might be a handy thing to add... int if_get_next(struct ifnet *ifp); /* runs at splimp() */ This function tries to "get" the next packet scheduled to go out interface 'ifp' and, if successful, puts it on &ifp->if_snd (the interface output queue for 'ifp') and returns 1; otherwise, it returns zero. Then, each device driver can be modified (over time) to invoke this function when it gets a transmit interrupt and it's output queue is empty. If the function returns 1, grab the new packet off the queue and schedule it for transmission. Once this is done it becomes much easier to hack together ideas for queueing and scheduling e.g., a netgraph node that does packet scheduling. I think ALTQ does something like this. It would be nice if it was generic enough that other mechanisms besides ALTQ (like netgraph) could also use it. I'm not that familiar with how ALTQ is implemented. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 22:21:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 86DD637B419 for ; Tue, 26 Mar 2002 22:21:29 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g2R6LSB16494; Tue, 26 Mar 2002 22:21:28 -0800 (PST) (envelope-from rizzo) Date: Tue, 26 Mar 2002 22:21:28 -0800 From: Luigi Rizzo To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: ip_output and ENOBUFS Message-ID: <20020326222128.A16450@iguana.icir.org> References: <20020325145447.A2986@iguana.icir.org> <200203270610.g2R6A5x39204@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203270610.g2R6A5x39204@arch20m.dellroad.org> User-Agent: Mutt/1.3.23i 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, Mar 26, 2002 at 10:10:05PM -0800, Archie Cobbs wrote: > Luigi Rizzo writes: ... > Along those lines, this might be a handy thing to add... > > int if_get_next(struct ifnet *ifp); /* runs at splimp() */ > > This function tries to "get" the next packet scheduled to go > out interface 'ifp' and, if successful, puts it on &ifp->if_snd > (the interface output queue for 'ifp') and returns 1; otherwise, > it returns zero. how is this different from having a longer device queue ? cheers luigi > Then, each device driver can be modified (over time) to invoke > this function when it gets a transmit interrupt and it's output > queue is empty. If the function returns 1, grab the new packet > off the queue and schedule it for transmission. > > Once this is done it becomes much easier to hack together ideas > for queueing and scheduling e.g., a netgraph node that does packet > scheduling. > > I think ALTQ does something like this. It would be nice if it > was generic enough that other mechanisms besides ALTQ (like > netgraph) could also use it. I'm not that familiar with how > ALTQ is implemented. > > -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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 22:39:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 586C537B417 for ; Tue, 26 Mar 2002 22:39:50 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g2R6dmD16594; Tue, 26 Mar 2002 22:39:48 -0800 (PST) (envelope-from rizzo) Date: Tue, 26 Mar 2002 22:39:48 -0800 From: Luigi Rizzo To: Lars Eggert Cc: Matthew Luckie , freebsd-net@FreeBSD.ORG Subject: Re: ip_output and ENOBUFS Message-ID: <20020326223947.B16450@iguana.icir.org> References: <3CA0AB3D.5000300@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CA0AB3D.5000300@isi.edu> User-Agent: Mutt/1.3.23i 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 ENOBUFS is very typical with UDP applications that try to send as fast as possible (e.g. the various network test utilities in ports), and as i said in a previous message, putting up a mechanism to pass around queue full/queue not full events is expensive because it might trigger on every single packet, and possibly have to wakeup multiple processes each time (with only one being able to succeed). The tcp handling of ENOBUFS is much cheaper. TCP is not waken up by the device, but from acks coming from the other side, or from timeouts. So there is not per-packet overhead just to implement this mechanism. As a matter of fact, i even implemented a similar thing in dummynet, and if device drivers call if_tx_rdy() when they complete a transmission, then the tx interrupt can be used to clock packets out of the dummynet pipes. A patch for if_tun.c is below, and if_tx_rdy() is in netinet/ip_dummynet.c. You could replace the call to if_tx_rdy with a wakeup() using some appropriate argument to wake up threads waiting for devices to become ready. cheers luigi > lcvs diff -u if_tun.c Index: if_tun.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_tun.c,v retrieving revision 1.51.2.2 diff -u -r1.51.2.2 if_tun.c --- if_tun.c 28 Jul 1999 15:08:06 -0000 1.51.2.2 +++ if_tun.c 19 Jun 2000 12:07:17 -0000 @@ -19,6 +19,7 @@ #include "opt_devfs.h" #include "opt_inet.h" +#include "opt_ipdn.h" #include #include @@ -162,6 +163,10 @@ ifp = &tp->tun_if; tp->tun_flags |= TUN_OPEN; TUNDEBUG("%s%d: open\n", ifp->if_name, ifp->if_unit); +#ifdef DUMMYNET + if (ifp->if_snd.ifq_len == 0) /* better be! */ + if_tx_rdy(ifp); +#endif return (0); } @@ -487,6 +492,10 @@ } } } while (m0 == 0); +#ifdef DUMMYNET + if (ifp->if_snd.ifq_len == 0) + if_tx_rdy(ifp); +#endif splx(s); while (m0 && uio->uio_resid > 0 && error == 0) { On Tue, Mar 26, 2002 at 09:09:17AM -0800, Lars Eggert wrote: > Matthew Luckie wrote: > > hmm, we looked at how other protocols handled the ENOBUFS case from > > ip_output. > > > > tcp_output calls tcp_quench on this error. > > > > while the interface may not be able to send any more packets than it > > does currently, closing the congestion window back to 1 segment > > seems a severe way to handle this error, knowing that the network > > did not drop the packet due to congestion. Ideally, there might be > > some form of blocking until such time as a mbuf comes available. > > This sounds as if it will be much easier come FreeBSD 5.0 > > TCP will almost never encouter this scenario, since it's self-clocking. > The NIC is very rarely the bottleneck resource for a given network > connection. Have you looked at mean queue lengths for NICs? They are > typically zero or one. The NIC will only be the bottleneck if you are > sending at a higher rate than line speed and your burt time is too long > to be absorbed by the queue. > > > I'm aware that if people are hitting this condition, they need to > > increase the number of mbufs to get maximum performance. > > No. ENOBUFS in ip_output almost always means that your NIC queue is > full, which isn't controlled through mbufs. You can make the queue > longer, but that won't help if you're sending too fast. > > > This section of code has previously been discussed here: > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=119188+0+archive/2000/fr- > > eebsd-net/20000730.freebsd-net and has been in use for many years (a > > This is a slightly different problem than you describe. What Archie saw > was an ENOBUFS being handled like a loss inside the network, even though > the sender has information locally that can allow it to make smarter > retransmission decisions. > > Lars > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 23: 0: 9 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 E3CA637B41A for ; Tue, 26 Mar 2002 23:00:02 -0800 (PST) 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 WAA52062; Tue, 26 Mar 2002 22:48:55 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g2R6mXl39332; Tue, 26 Mar 2002 22:48:33 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200203270648.g2R6mXl39332@arch20m.dellroad.org> Subject: Re: ip_output and ENOBUFS In-Reply-To: <20020326223947.B16450@iguana.icir.org> "from Luigi Rizzo at Mar 26, 2002 10:39:48 pm" To: Luigi Rizzo Date: Tue, 26 Mar 2002 22:48:33 -0800 (PST) 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 Luigi Rizzo writes: > As a matter of fact, i even implemented a similar thing in dummynet, > and if device drivers call if_tx_rdy() when they complete a > transmission, then the tx interrupt can be used to clock > packets out of the dummynet pipes. A patch for if_tun.c is below, So if_tx_rdy() sounds like my if_get_next().. guess you already did that :-) Is if_tx_rdy() something that can be used generally or does it only work with dummynet ? -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 23: 0:12 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 7ACFF37B417 for ; Tue, 26 Mar 2002 23:00:05 -0800 (PST) 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 WAA52058; Tue, 26 Mar 2002 22:46:37 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g2R6kFt39325; Tue, 26 Mar 2002 22:46:15 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200203270646.g2R6kFt39325@arch20m.dellroad.org> Subject: Re: ip_output and ENOBUFS In-Reply-To: <20020326222128.A16450@iguana.icir.org> "from Luigi Rizzo at Mar 26, 2002 10:21:28 pm" To: Luigi Rizzo Date: Tue, 26 Mar 2002 22:46:15 -0800 (PST) Cc: Archie Cobbs , 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 Luigi Rizzo writes: > > Along those lines, this might be a handy thing to add... > > > > int if_get_next(struct ifnet *ifp); /* runs at splimp() */ > > > > This function tries to "get" the next packet scheduled to go > > out interface 'ifp' and, if successful, puts it on &ifp->if_snd > > (the interface output queue for 'ifp') and returns 1; otherwise, > > it returns zero. > > how is this different from having a longer device queue ? The idea is that if_get_next() may in turn call some scheduling code that intelligently decides what packet gets to go next. So, when this kind of thing is enabled, the device queue basically always has either zero or one packets on it. In effect, this allows you to move the interface output queue out of the (dumb) device driver upwards in the networking stack, where e.g. a netgraph node can make the scheduling decision. The existing fixed length FIFO queues at each device mean you can't do intelligent scheduling of packets, because you can't manage that queue, because part of "managing" the queue is knowing when it goes empty. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 23:17: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 3C7A937B400 for ; Tue, 26 Mar 2002 23:16:58 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g2R7Gv816901; Tue, 26 Mar 2002 23:16:57 -0800 (PST) (envelope-from rizzo) Date: Tue, 26 Mar 2002 23:16:57 -0800 From: Luigi Rizzo To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: ip_output and ENOBUFS Message-ID: <20020326231657.A16810@iguana.icir.org> References: <20020326223947.B16450@iguana.icir.org> <200203270648.g2R6mXl39332@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203270648.g2R6mXl39332@arch20m.dellroad.org> User-Agent: Mutt/1.3.23i 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, Mar 26, 2002 at 10:48:33PM -0800, Archie Cobbs wrote: > Luigi Rizzo writes: > > As a matter of fact, i even implemented a similar thing in dummynet, > > and if device drivers call if_tx_rdy() when they complete a > > transmission, then the tx interrupt can be used to clock > > packets out of the dummynet pipes. A patch for if_tun.c is below, > > So if_tx_rdy() sounds like my if_get_next().. guess you already did that :-) yes, but it does not solve the problem of the original poster who wanted to block/wakeup processes getting enobufs. Signal just do not propagate beyond the pipe they are sent to. > Is if_tx_rdy() something that can be used generally or does it only > work with dummynet ? well, the function is dummynet-specific, but I would certainly like a generic callback list to be implemented in ifnet which is invoked on tx_empty events. So Ckernel modules could hook their own callback to the list and get notified of events when they occur. The problem as usual is that you have to touch every single device driver... Fortunately we can leave the ifnet structure unmodified because i just discovered there is an ifindex2ifnet array which is managed and can be extended to point to additional ifnet state that does not fit in the immutable one... cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 26 23:23:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by hub.freebsd.org (Postfix) with ESMTP id EFB2237B405 for ; Tue, 26 Mar 2002 23:23:22 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id QAA00217 for ; Wed, 27 Mar 2002 16:23:21 +0900 (JST) Received: from localhost (h123n005.iij.ad.jp [192.168.5.123]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id QAA10756 for ; Wed, 27 Mar 2002 16:23:21 +0900 (JST) Date: Wed, 27 Mar 2002 16:23:20 +0900 (JST) Message-Id: <20020327.162320.922733592.keiichi@iij.ad.jp> To: freebsd-net@FreeBSD.ORG Subject: Re: problems with udp46 sockets From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <20020326231734.H58573@Space.Net> References: <20020326231734.H58573@Space.Net> X-Mailer: Mew version 3.0.55 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Mar_27_16:23:20_2002_428)--" 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 ----Next_Part(Wed_Mar_27_16:23:20_2002_428)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, From: Markus Stumpf > I am trying to get dnscache running with IPv6 patches. > dnscache binds to the IPv6 unqualified address "::". This works fine > and I get (from netstat) > udp46 0 0 *.53 *.* > As the sending address the IPv6 unqualified address "::" is used, also. > > As long as I only send queries via either IPv6 or IPv4 all works well, but > all subsequent queries via IPv6 after one or more queries via > IPv4 fail. The queries arrive properly, but sending the answer fails. > > >From truss I can see for that IPv6 answers: > sendto(0x3,0x80f34e0,0x55,0x0,0xbfbffbd0,0x1c) ERR#65 'No route to host' > for all queries via IPv6, queries via IPv4 still work without problems. > It doesn't matter if I use different source hosts for the queries via IPv6, > it fails for all of them. This is a cached route problem. struct inpcb has a route entry for cached route. Since inpcb is shared by both IPv4 and IPv6, the cached route entry is also shared by them. 4.5-STABLE doesn't check the protocol family of the cached route when using it. Therefore, once a IPv4 route is cached, ip6_output mistakingly use it as a cached route for IPv6 destination. Please try attached patches. --- Keiichi SHIMA IIJ Research Laboratory KAME Project ----Next_Part(Wed_Mar_27_16:23:20_2002_428)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ip_output.c.diff" --- ip_output.c.orig Wed Mar 27 14:29:43 2002 +++ ip_output.c Wed Mar 27 13:54:40 2002 @@ -219,6 +219,7 @@ * and is still up. If not, free it and try again. */ if (ro->ro_rt && ((ro->ro_rt->rt_flags & RTF_UP) == 0 || + dst->sin_family != AF_INET || dst->sin_addr.s_addr != ip->ip_dst.s_addr)) { RTFREE(ro->ro_rt); ro->ro_rt = (struct rtentry *)0; ----Next_Part(Wed_Mar_27_16:23:20_2002_428)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ip6_output.c.diff" --- ip6_output.c.orig Wed Mar 27 14:23:54 2002 +++ ip6_output.c Wed Mar 27 14:08:22 2002 @@ -461,6 +461,7 @@ * and is still up. If not, free it and try again. */ if (ro->ro_rt && ((ro->ro_rt->rt_flags & RTF_UP) == 0 || + dst->sin6_family != AF_INET6 || !IN6_ARE_ADDR_EQUAL(&dst->sin6_addr, &ip6->ip6_dst))) { RTFREE(ro->ro_rt); ro->ro_rt = (struct rtentry *)0; ----Next_Part(Wed_Mar_27_16:23:20_2002_428)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="in6_src.c.diff" --- in6_src.c.orig Wed Mar 27 14:24:28 2002 +++ in6_src.c Wed Mar 27 14:47:31 2002 @@ -239,7 +239,9 @@ */ if (ro) { if (ro->ro_rt && - !IN6_ARE_ADDR_EQUAL(&satosin6(&ro->ro_dst)->sin6_addr, dst)) { + (!(ro->ro_rt->rt_flags & RTF_UP) || + ro->ro_dst.sin6_family != AF_INET6 || + !IN6_ARE_ADDR_EQUAL(&satosin6(&ro->ro_dst)->sin6_addr, dst))) { RTFREE(ro->ro_rt); ro->ro_rt = (struct rtentry *)0; } ----Next_Part(Wed_Mar_27_16:23:20_2002_428)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 27 8: 1:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from D00015.dialonly.kemerovo.su (www2.svzserv.kemerovo.su [213.184.65.86]) by hub.freebsd.org (Postfix) with ESMTP id DC09D37B419; Wed, 27 Mar 2002 08:01:36 -0800 (PST) Received: (from eugen@localhost) by D00015.dialonly.kemerovo.su (8.11.6/8.11.6) id g2RG0ZV01130; Wed, 27 Mar 2002 23:00:35 +0700 (KRAT) (envelope-from eugen) Date: Wed, 27 Mar 2002 23:00:35 +0700 (KRAT) Message-Id: <200203271600.g2RG0ZV01130@D00015.dialonly.kemerovo.su> To: FreeBSD-gnats-submit@freebsd.org Subject: [PATCH] Introduction of non-strict IFF_NOARP semantics From: Eugene Grosbein Reply-To: Eugene Grosbein Cc: net@freebsd.org X-send-pr-version: 3.113 X-GNATS-Notify: 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 >Submitter-Id: current-users >Originator: Eugene Grosbein >Organization: Svyaz Service >Confidential: no >Synopsis: [PATCH] Introduction of non-strict IFF_NOARP semantics >Severity: non-critical >Priority: low >Category: kern >Class: change-request >Release: FreeBSD 4.5-STABLE i386 >Environment: System: FreeBSD D00015.dialonly.kemerovo.su 4.5-STABLE FreeBSD 4.5-STABLE #1: Tue Mar 26 19:19:56 KRAT 2002 eu@D00015.dialonly.kemerovo.su:/usr/local/obj/usr/local/src/sys/DADV i386 >Description: FreeBSD currently handles flag NOARP for network interface in the way that completely disables ARP for that interface. It's often too strict for real world operations. Sometimes we just want ARP table to be protected from modification via public interface but host must respond to ARP queries for its own MAC address. So, this host will cooperate with known hosts only (using preloaded ARP table), can act as gateway for them and those hosts are not forced to have static ARP records themselves. The patches implementing such behavour float around for long time. Here is an adaptaion of one such patch for 4.5-STABLE. It introcudes new sysctl named net.link.ether.inet.strict_noarp with default value of 1. This value correspondes to current meaning of IFF_NOARP. One can change it to 0 to enable host replies to ARP queries; the ARP table is still protected from modifications via interfces marked as NOARP. >How-To-Repeat: There is no problem, see above. >Fix: Apply this patch. --- sys/netinet/if_ether.c.orig Fri Mar 22 17:50:23 2002 +++ sys/netinet/if_ether.c Sat Mar 23 15:52:10 2002 @@ -107,6 +107,7 @@ static int arp_maxtries = 5; static int useloopback = 1; /* use loopback interface for local traffic */ static int arp_proxyall = 0; +int strict_noarp = 1; /* used in src/net/if_ethersubr.c */ SYSCTL_INT(_net_link_ether_inet, OID_AUTO, maxtries, CTLFLAG_RW, &arp_maxtries, 0, ""); @@ -114,6 +115,8 @@ &useloopback, 0, ""); SYSCTL_INT(_net_link_ether_inet, OID_AUTO, proxyall, CTLFLAG_RW, &arp_proxyall, 0, ""); +SYSCTL_INT(_net_link_ether_inet, OID_AUTO, strict_noarp, CTLFLAG_RW, + &strict_noarp, 0, ""); static void arp_rtrequest __P((int, struct rtentry *, struct rt_addrinfo *)); static void arprequest __P((struct ifnet *, @@ -441,7 +444,7 @@ * Probably should not allocate empty llinfo struct if we are * not going to be sending out an arp request. */ - if (ifp->if_flags & IFF_NOARP) { + if (strict_noarp && (ifp->if_flags & IFF_NOARP)) { m_freem(m); return (0); } @@ -635,6 +638,7 @@ itaddr = myaddr; goto reply; } + if (strict_noarp || !(ifp->if_flags & IFF_NOARP)) { la = arplookup(isaddr.s_addr, itaddr.s_addr == myaddr.s_addr, 0); if (la && (rt = la->la_rt) && (sdl = SDL(rt->rt_gateway))) { /* the following is not an error when doing bridging */ @@ -725,6 +729,7 @@ rt_key(rt), rt); la->la_hold = 0; } + } } reply: if (op != ARPOP_REQUEST) { --- sys/net/if_ethersubr.c.orig Fri Mar 22 17:50:04 2002 +++ sys/net/if_ethersubr.c Sat Mar 23 15:26:06 2002 @@ -97,6 +97,10 @@ extern u_char aarp_org_code[3]; #endif /* NETATALK */ +#ifdef INET +extern int strict_noarp; /* defined in src/netinet/if_ether.c */ +#endif + /* netgraph node hooks for ng_ether(4) */ void (*ng_ether_input_p)(struct ifnet *ifp, struct mbuf **mp, struct ether_header *eh); @@ -559,11 +563,12 @@ break; case ETHERTYPE_ARP: - if (ifp->if_flags & IFF_NOARP) { + if (strict_noarp && (ifp->if_flags & IFF_NOARP)) { /* Discard packet if ARP is disabled on interface */ m_freem(m); return; } + schednetisr(NETISR_ARP); inq = &arpintrq; break; Eugene Grosbein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 27 9:26: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.cyberedge.net (mail.cyberedge.net [209.74.137.196]) by hub.freebsd.org (Postfix) with ESMTP id 645CE37B482; Wed, 27 Mar 2002 09:24:46 -0800 (PST) Received: from greenleaf (dsl-64-129-43-249.telocity.com [64.129.43.249]) by mail.cyberedge.net (8.9.3/8.9.3) with ESMTP id LAA03264; Wed, 27 Mar 2002 11:13:22 -0600 From: "Dave Brancato" To: Cc: , , , Subject: Adaptec NIC and Netfinity Date: Wed, 27 Mar 2002 11:23:55 -0600 Message-ID: <000001c1d5b4$2c5bd550$d120a8c0@corp.cyberedge.net> 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, Build 10.0.2616 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 Hello I am having some problems with an Adaptec 62044 network card (quad NIC), the first three interfaces initialize but then the last fails. I have compiled in the starfire driver with my kernel using the line: device sf # Adaptec AIC-6915 (``Starfire'') The hardware platform is on a IBM Netfinity 4000R. I have disabled any PnP options in the bios and have also disabled floppy and com ports. I am posting the output from the command "dmesg" and also the output of "vmstat -I". Please CC:g00ru@cyberedge.net with any info. Thanks, Dave Brancato interrupt total rate ata1 irq15 4 0 mux irq10 2589 1 mux irq3 1216 0 atkbd0 irq1 2325 1 clk irq0 145260 99 rtc irq8 185939 127 Total 337333 232 Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-RELEASE #0: Mon Mar 25 06:40:31 CST 2002 root@:/usr/src/sys/compile/TAZ Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (645.66-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x387fbff real memory = 2147483648 (2097152K bytes) avail memory = 2088800256 (2039844K bytes) APIC_IO: MP table broken: 8259->APIC entry missing! Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 IOAPIC #0 intpin 16 -> irq 11 IOAPIC #0 intpin 17 -> irq 10 IOAPIC #0 intpin 18 -> irq 3 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 14, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc02e5000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc02e509c. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib2: at device 1.0 on pci0 pci1: on pcib2 pci1: at 0.0 isab0: at device 7.0 on pci0 isa0: on isab0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.2 Timecounter "PIIX" frequency 3579545 Hz 3 on pci0 ffff,0xfebff000-0xfebfffff irq 3 at device 17.0 on pci0 fxp0: Ethernet address 00:06:29:de:c2:fb inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ffff,0xfebfe000-0xfebfefff irq 10 at device 18.0 on pci0 fxp1: Ethernet address 00:06:29:de:c2:fa inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcib3: at device 20.0 on pci0 pci2: on pcib3 0fff irq 10 at device 14.0 on pci2 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/255 SCBs pcib4: at device 15.0 on pci2 pci3: on pcib4 ff irq 11 at device 4.0 on pci3 sf0: Ethernet address: 00:00:d1:ee:08:a1 miibus2: on sf0 ukphy0: on miibus2 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ff irq 10 at device 5.0 on pci3 sf1: Ethernet address: 00:00:d1:ee:08:a2 miibus3: on sf1 ukphy1: on miibus3 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ff irq 3 at device 6.0 on pci3 sf2: Ethernet address: 00:00:d1:ee:08:a3 miibus4: on sf2 ukphy2: on miibus4 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ff at device 7.0 on pci3 pci_cfgintr: can't route an interrupt to 3:7 INTA sf3: couldn't map interrupt device_probe_and_attach: sf3 attach returned 6 pcib1: on motherboard pci4: on pcib1 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 IP Filter: v3.4.20 initialized. Default = pass all, Logging = enabled SMP: AP CPU #1 Launched! acd0: CDROM at ata1-master using PIO4 Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 17357MB (35548320 512 byte sectors: 255H 63S/T 2212C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 17357MB (35548320 512 byte sectors: 255H 63S/T 2212C) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 27 10: 0:11 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 947BB37B405 for ; Wed, 27 Mar 2002 10:00:02 -0800 (PST) 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 JAA55601; Wed, 27 Mar 2002 09:53:23 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g2RHr0L41197; Wed, 27 Mar 2002 09:53:00 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200203271753.g2RHr0L41197@arch20m.dellroad.org> Subject: Re: ip_output and ENOBUFS In-Reply-To: <20020326231657.A16810@iguana.icir.org> "from Luigi Rizzo at Mar 26, 2002 11:16:57 pm" To: Luigi Rizzo Date: Wed, 27 Mar 2002 09:53:00 -0800 (PST) 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 Luigi Rizzo writes: > > Is if_tx_rdy() something that can be used generally or does it only > > work with dummynet ? > > well, the function is dummynet-specific, but I would certainly like > a generic callback list to be implemented in ifnet which is > invoked on tx_empty events. Me too :-) > The problem as usual is that you have to touch every single device > driver... Fortunately we can leave the ifnet structure unmodified > because i just discovered there is an ifindex2ifnet array which is > managed and can be extended to point to additional ifnet state that > does not fit in the immutable one... Why is it important to avoid changing 'struct ifnet' ? -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 Wed Mar 27 10:11:51 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 5D17A37B41A for ; Wed, 27 Mar 2002 10:11:46 -0800 (PST) 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 NAA28306; Wed, 27 Mar 2002 13:11:44 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g2RIBEL73857; Wed, 27 Mar 2002 13:11:14 -0500 (EST) (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: <15522.2882.479989.695082@grasshopper.cs.duke.edu> Date: Wed, 27 Mar 2002 13:11:14 -0500 (EST) To: Archie Cobbs Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: ip_output and ENOBUFS In-Reply-To: <200203271753.g2RHr0L41197@arch20m.dellroad.org> References: <20020326231657.A16810@iguana.icir.org> <200203271753.g2RHr0L41197@arch20m.dellroad.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 Archie Cobbs writes: > Luigi Rizzo writes: > > > Is if_tx_rdy() something that can be used generally or does it only > > > work with dummynet ? > > > > well, the function is dummynet-specific, but I would certainly like > > a generic callback list to be implemented in ifnet which is > > invoked on tx_empty events. > > Me too :-) > > > The problem as usual is that you have to touch every single device > > driver... Fortunately we can leave the ifnet structure unmodified > > because i just discovered there is an ifindex2ifnet array which is > > managed and can be extended to point to additional ifnet state that > > does not fit in the immutable one... > > Why is it important to avoid changing 'struct ifnet' ? To maintain binary compatability for commercial network drivers. Currently, network driver modules built on 4.1.1 work on all versions of FreeBSD through 4.5-STABLE. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 27 10:14: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 5A34D37B405 for ; Wed, 27 Mar 2002 10:13:59 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g2RIDwV22440; Wed, 27 Mar 2002 10:13:58 -0800 (PST) (envelope-from rizzo) Date: Wed, 27 Mar 2002 10:13:58 -0800 From: Luigi Rizzo To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: ip_output and ENOBUFS Message-ID: <20020327101358.B22365@iguana.icir.org> References: <20020326231657.A16810@iguana.icir.org> <200203271753.g2RHr0L41197@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203271753.g2RHr0L41197@arch20m.dellroad.org> User-Agent: Mutt/1.3.23i 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, Mar 27, 2002 at 09:53:00AM -0800, Archie Cobbs wrote: ... > > managed and can be extended to point to additional ifnet state that > > does not fit in the immutable one... > > Why is it important to avoid changing 'struct ifnet' ? backward compatibility with binary-only drivers ... Not that i care too much (in the end it is for the benefit of a limited set of people which could as well not upgrade, vs. preventing useful functionality to be added in a safe way), but some people do and i can see their point. On the other hand, this also means we can never progress if not on major releases or unless changes slip in unnoticed... cheers luigi > -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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 27 10:40:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 8DC9E37B416 for ; Wed, 27 Mar 2002 10:40:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020327184010.FGOK2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Wed, 27 Mar 2002 18:40:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA47804; Wed, 27 Mar 2002 10:38:04 -0800 (PST) Date: Wed, 27 Mar 2002 10:38:04 -0800 (PST) From: Julian Elischer To: Luigi Rizzo Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG Subject: Re: ip_output and ENOBUFS In-Reply-To: <20020327101358.B22365@iguana.icir.org> 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 Wed, 27 Mar 2002, Luigi Rizzo wrote: > On Wed, Mar 27, 2002 at 09:53:00AM -0800, Archie Cobbs wrote: > ... > > > managed and can be extended to point to additional ifnet state that > > > does not fit in the immutable one... > > > > Why is it important to avoid changing 'struct ifnet' ? > > backward compatibility with binary-only drivers ... > Not that i care too much (in the end it is for the benefit of > a limited set of people which could as well not upgrade, vs. > preventing useful functionality to be added in a safe way), > but some people do and i can see their point. > On the other hand, this also means we can never progress if not > on major releases or unless changes slip in unnoticed... It is possible to hang extra info off the ifnet structure if one is careful. just not IN it.. > > cheers > luigi > > > -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 > > 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 Wed Mar 27 10:40:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id B761137B41F for ; Wed, 27 Mar 2002 10:40:16 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020327184016.FGQO2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Wed, 27 Mar 2002 18:40:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA47794; Wed, 27 Mar 2002 10:33:51 -0800 (PST) Date: Wed, 27 Mar 2002 10:33:50 -0800 (PST) From: Julian Elischer To: Archie Cobbs Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: ip_output and ENOBUFS In-Reply-To: <200203271753.g2RHr0L41197@arch20m.dellroad.org> 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 Wed, 27 Mar 2002, Archie Cobbs wrote: > Luigi Rizzo writes: > > > Is if_tx_rdy() something that can be used generally or does it only > > > work with dummynet ? > > > > well, the function is dummynet-specific, but I would certainly like > > a generic callback list to be implemented in ifnet which is > > invoked on tx_empty events. > > Me too :-) > > > The problem as usual is that you have to touch every single device > > driver... Fortunately we can leave the ifnet structure unmodified > > because i just discovered there is an ifindex2ifnet array which is > > managed and can be extended to point to additional ifnet state that > > does not fit in the immutable one... > > Why is it important to avoid changing 'struct ifnet' ? You can't touch struct ifnet in a released line of systems e.g. 4.x must not touch struct ifnet of break binary compatibility with drivers written for earlier 4.x systems. (and not available in source).. it turns out that sync interface cards are the single largest set of binary drivers... > > -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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 27 10:40:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 753C337B419 for ; Wed, 27 Mar 2002 10:40:18 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020327184018.FGRG2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Wed, 27 Mar 2002 18:40:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA47802; Wed, 27 Mar 2002 10:36:21 -0800 (PST) Date: Wed, 27 Mar 2002 10:36:21 -0800 (PST) From: Julian Elischer To: Andrew Gallatin Cc: Archie Cobbs , Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: ip_output and ENOBUFS In-Reply-To: <15522.2882.479989.695082@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 27 Mar 2002, Andrew Gallatin wrote: > > Archie Cobbs writes: > > Luigi Rizzo writes: > > > > Is if_tx_rdy() something that can be used generally or does it only > > > > work with dummynet ? > > > > > > well, the function is dummynet-specific, but I would certainly like > > > a generic callback list to be implemented in ifnet which is > > > invoked on tx_empty events. > > > > Me too :-) > > > > > The problem as usual is that you have to touch every single device > > > driver... Fortunately we can leave the ifnet structure unmodified > > > because i just discovered there is an ifindex2ifnet array which is > > > managed and can be extended to point to additional ifnet state that > > > does not fit in the immutable one... > > > > Why is it important to avoid changing 'struct ifnet' ? > > To maintain binary compatability for commercial network drivers. > > Currently, network driver modules built on 4.1.1 work on all versions > of FreeBSD through 4.5-STABLE. > Not QUITE true.. they ar ebroken in some cases for 4.4 amd 4.5 due to a renumberring of SYSINIT orderings, but I fixed that and they should work in 4.6 again.. I know we hit it here with some cards we have.. I just made a small patch in teh local trees to allow us to use them. Some cards may not hit this problem. > > Drew > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 27 10:52:13 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 87DEA37B404 for ; Wed, 27 Mar 2002 10:52:07 -0800 (PST) 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 NAA29667; Wed, 27 Mar 2002 13:52:07 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g2RIpaL73915; Wed, 27 Mar 2002 13:51:36 -0500 (EST) (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: <15522.5304.931386.964581@grasshopper.cs.duke.edu> Date: Wed, 27 Mar 2002 13:51:36 -0500 (EST) To: Julian Elischer Cc: freebsd-net@FreeBSD.ORG Subject: Re: ip_output and ENOBUFS In-Reply-To: References: <15522.2882.479989.695082@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian Elischer writes: > > > On Wed, 27 Mar 2002, Andrew Gallatin wrote: > > > > > Archie Cobbs writes: > > > Luigi Rizzo writes: > > > > > Is if_tx_rdy() something that can be used generally or does it only > > > > > work with dummynet ? > > > > > > > > well, the function is dummynet-specific, but I would certainly like > > > > a generic callback list to be implemented in ifnet which is > > > > invoked on tx_empty events. > > > > > > Me too :-) > > > > > > > The problem as usual is that you have to touch every single device > > > > driver... Fortunately we can leave the ifnet structure unmodified > > > > because i just discovered there is an ifindex2ifnet array which is > > > > managed and can be extended to point to additional ifnet state that > > > > does not fit in the immutable one... > > > > > > Why is it important to avoid changing 'struct ifnet' ? > > > > To maintain binary compatability for commercial network drivers. > > > > Currently, network driver modules built on 4.1.1 work on all versions > > of FreeBSD through 4.5-STABLE. > > > Not QUITE true.. > > they ar ebroken in some cases for 4.4 amd 4.5 due to a renumberring > of SYSINIT orderings, but I fixed that and they should work in 4.6 > again.. I know we hit it here with some cards we have.. > I just made a small patch in teh local trees to allow us to use them. > > Some cards may not hit this problem. I've never tried loading our driver at boot (we have customers load it manually, or via a /usr/local/etc/rc.d script very late in boot). 4.5 works fine for us. There was a bit of breakage just after 4.5 when for ARP support for variable length link level addresses was MFCed, but I caught that early.. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 27 11:11:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by hub.freebsd.org (Postfix) with SMTP id B726437B416 for ; Wed, 27 Mar 2002 11:11:20 -0800 (PST) Received: (qmail 74814 invoked by uid 1013); 27 Mar 2002 19:11:19 -0000 Date: Wed, 27 Mar 2002 20:11:19 +0100 From: Markus Stumpf To: "Keiichi SHIMA / ?$BEg7D0l?(B" Cc: freebsd-net@FreeBSD.ORG Subject: Re: problems with udp46 sockets Message-ID: <20020327201119.E68348@Space.Net> References: <20020326231734.H58573@Space.Net> <20020327.162320.922733592.keiichi@iij.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020327.162320.922733592.keiichi@iij.ad.jp>; from keiichi@iij.ad.jp on Wed, Mar 27, 2002 at 04:23:20PM +0900 Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF 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, Mar 27, 2002 at 04:23:20PM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > This is a cached route problem. struct inpcb has a route entry for > cached route. Since inpcb is shared by both IPv4 and IPv6, the cached > route entry is also shared by them. 4.5-STABLE doesn't check the > protocol family of the cached route when using it. Therefore, once a > IPv4 route is cached, ip6_output mistakingly use it as a cached route > for IPv6 destination. > > Please try attached patches. Thanks a lot! I have applied the patches and it works only partially. I have the server at de0: flags=8943 mtu 1500 inet6 fe80::280:c8ff:fe45:b392%de0 prefixlen 64 scopeid 0x1 inet 195.30.1.139 netmask 0xffffff00 broadcast 195.30.1.255 inet6 2001:608:0:1:280:c8ff:fe45:b392 prefixlen 64 autoconf ether 00:80:c8:45:b3:92 the IPv4 only client is at de0: flags=8843 mtu 1500 inet 195.30.1.54 netmask 0xffffff00 broadcast 195.30.1.255 ether 00:80:c8:4c:33:36 the IPv6 client is at de0: flags=8843 mtu 1500 inet 195.30.0.29 netmask 0xffffff00 broadcast 195.30.0.255 inet6 fe80::280:c8ff:fe56:bf25%de0 prefixlen 64 scopeid 0x1 inet6 2001:608::1000:1 prefixlen 64 inet6 2001:608::280:c8ff:fe56:bf25 prefixlen 64 ether 00:80:c8:56:bf:25 queries from the IPv6 client both to 2001:608:0:1:280:c8ff:fe45:b392 or 195.30.1.139 work fine, always. As long as I only do queries via IPv4 it works for both clients. As the IPv4 client and the server are on the same subnet/ethernet they can talk directly. What happens is that the server has two ARP entries as soon as a query via IPv4 comes in: lagrange.Space.Net (195.30.1.54) at 0:80:c8:4c:33:36 on de0 [ethernet] lagrange.Space.Net (195.30.1.54) at (incomplete) on de0 [ethernet] As soon as I do the first query via IPv6 I can do further queries via IPv6 from that host but queries via IPv4 from any host on the same subnet/ethernet don't work any longer. truss shows the sendto() without any errors. recvfrom(0x3,0x80556c0,0x400,0x0,0xbfbffbc0,0xbfbffbbc) = 31 (0x1f) [ ... ] sendto(0x3,0x80f34c0,0x2f,0x0,0xbfbffba0,0x1c) = 47 (0x2f) tcpdump shows that at the moment the server does the sendto() the server host sends ARP requests and gets answers but doesn't send any packets: 19:56:26.381491 195.30.1.54.2494 > 195.30.1.139.53: 6+ A? www.space.net. (31) 19:56:26.382267 arp who-has 195.30.1.54 tell 195.30.1.139 19:56:26.382366 arp reply 195.30.1.54 is-at 0:80:c8:4c:33:36 arp -a still shows the above two entries (one incomplete). Same happens if I use other hosts e.g.: moebius2.Space.Net (195.30.1.100) at 0:d0:b7:a9:2e:5b on de0 [ethernet] moebius2.Space.Net (195.30.1.100) at (incomplete) on de0 [ethernet] and no packets get out: 20:02:56.283806 195.30.1.100.3227 > 195.30.1.139.53: 6+ A? www.space.net. (31) 20:02:56.284575 arp who-has 195.30.1.100 tell 195.30.1.139 20:02:56.284753 arp reply 195.30.1.100 is-at 0:d0:b7:a9:2e:5b I have also tried # arp -a -d but that doesn't change anything. ping and ssh still work for all clients to the server. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 27 12:59:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from pump3.york.ac.uk (pump3.york.ac.uk [144.32.128.131]) by hub.freebsd.org (Postfix) with ESMTP id EB4C337B405 for ; Wed, 27 Mar 2002 12:59:32 -0800 (PST) Received: from ury.york.ac.uk (ury.york.ac.uk [144.32.108.81]) by pump3.york.ac.uk (8.10.2/8.10.2) with ESMTP id g2RKxVL20375 for ; Wed, 27 Mar 2002 20:59:31 GMT Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.11.6/8.11.3) with ESMTP id g2RKxVK06222 for ; Wed, 27 Mar 2002 20:59:31 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Wed, 27 Mar 2002 20:59:31 +0000 (GMT) From: Gavin Atkinson To: Subject: How to detect link on unconfigered interface? Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2094456856-1017262771=:6118" 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-2094456856-1017262771=:6118 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I have a problem I have so far been unsuccessful in solving. I want to detect if a particular network interface has a link, before this interface has an IP address configured. From looking at the source to ifconfig, which successfully does this, the attached code should work, but doesn't. Can anyone help me please? Thanks, Gvain --0-2094456856-1017262771=:6118 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="naff.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="naff.c" I2luY2x1ZGUgPHN5cy9wYXJhbS5oPg0KI2luY2x1ZGUgPHN5cy9pb2N0bC5o Pg0KI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4NCg0KI2luY2x1ZGUgPG5ldC9p Zi5oPg0KI2luY2x1ZGUgPG5ldC9pZl9tZWRpYS5oPg0KDQpjaGFyIG5hbWVb MzJdID0gImVwMCI7DQoNCiNkZWZpbmUgRkFMU0UgMA0KI2RlZmluZSBUUlVF IDENCg0KaW50DQptZWRpYV9zdGF0dXMocykNCglpbnQgczsNCnsNCglzdHJ1 Y3QgaWZtZWRpYXJlcSBpZm1yOw0KCWludCBsaW5rID0gMDsNCg0KCSh2b2lk KSBtZW1zZXQoJmlmbXIsIDAsIHNpemVvZihpZm1yKSk7DQoJKHZvaWQpIHN0 cm5jcHkoaWZtci5pZm1fbmFtZSwgbmFtZSwgc2l6ZW9mKGlmbXIuaWZtX25h bWUpKTsNCg0KCWlmIChpb2N0bChzLCBTSU9DR0lGTUVESUEsIChjYWRkcl90 KSZpZm1yKSA8IDApDQoJCWVycigxLCAiU0lPQ0dJRk1FRElBIik7DQoJZWxz ZSB7DQoJCXByaW50ZiAoImlmbV9zdGF0dXM9JXhcbiIsIGlmbXIuaWZtX3N0 YXR1cyk7DQoJCWlmIChpZm1yLmlmbV9zdGF0dXMgJiBJRk1fQVZBTElEKSB7 DQoJCQlwcmludGYgKCIgIHN1Y2Nlc3MgLSBBVkFMSUQgaXMgc2V0XG4iKTsN CgkJCWlmIChpZm1yLmlmbV9zdGF0dXMgJiBJRk1fQUNUSVZFKSB7DQoJCQkJ bGluayA9IDE7DQoJCQl9DQoJCX0NCgl9DQoJcmV0dXJuIGxpbms7DQp9DQoN CmludCBtYWluICh2b2lkKQ0Kew0KCWludCBzID0gLTE7DQoNCglpZiAoKCBz ID0gc29ja2V0IChBRl9JTkVULCBTT0NLX0RHUkFNLCAwKSkgPT0gLTEpDQoJ CWVycigxLCAic29ja2V0Iik7DQoJcHJpbnRmICgiaW50ZXJmYWNlIGlzICVz XG4iLCAobWVkaWFfc3RhdHVzKHMpID8gInVwIiA6ICJkb3duIikpOw0KfQ0K --0-2094456856-1017262771=:6118-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 27 13:40:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id E28AB37B400 for ; Wed, 27 Mar 2002 13:40:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020327214010.LBFL2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Wed, 27 Mar 2002 21:40:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA48774; Wed, 27 Mar 2002 13:37:31 -0800 (PST) Date: Wed, 27 Mar 2002 13:37:30 -0800 (PST) From: Julian Elischer To: Gavin Atkinson Cc: freebsd-net@freebsd.org Subject: Re: How to detect link on unconfigered interface? 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 you can bring it 'up' without giving it an IP address e.g. ifconfig ed0 up On Wed, 27 Mar 2002, Gavin Atkinson wrote: > > Hi, > > I have a problem I have so far been unsuccessful in solving. I want to > detect if a particular network interface has a link, before this interface > has an IP address configured. > > From looking at the source to ifconfig, which successfully does this, the > attached code should work, but doesn't. Can anyone help me please? > > Thanks, > > Gvain > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 27 21:30:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by hub.freebsd.org (Postfix) with ESMTP id BEA2E37B405 for ; Wed, 27 Mar 2002 21:30:48 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id OAA22855 for ; Thu, 28 Mar 2002 14:30:47 +0900 (JST) Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA03261 for ; Thu, 28 Mar 2002 14:30:47 +0900 (JST) Date: Thu, 28 Mar 2002 14:30:43 +0900 (JST) Message-Id: <20020328.143043.67876714.keiichi@iij.ad.jp> To: freebsd-net@FreeBSD.ORG Subject: Re: problems with udp46 sockets From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <20020327201119.E68348@Space.Net> References: <20020326231734.H58573@Space.Net> <20020327.162320.922733592.keiichi@iij.ad.jp> <20020327201119.E68348@Space.Net> X-Mailer: Mew version 3.0.55 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Mar_28_14:30:43_2002_965)--" 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 ----Next_Part(Thu_Mar_28_14:30:43_2002_965)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Markus Stumpf > > Thanks a lot! I have applied the patches and it works only partially. Sorry, it needs more work... Please revert the previous patches, and try with these attached again. --- Keiichi SHIMA IIJ Research Laboratory KAME Project ----Next_Part(Thu_Mar_28_14:30:43_2002_965)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="in_pcb.c.diff" --- in_pcb.c.orig Thu Mar 28 14:13:23 2002 +++ in_pcb.c Thu Mar 28 14:15:10 2002 @@ -411,9 +411,10 @@ */ ro = &inp->inp_route; if (ro->ro_rt && - (satosin(&ro->ro_dst)->sin_addr.s_addr != - sin->sin_addr.s_addr || - inp->inp_socket->so_options & SO_DONTROUTE)) { + (ro->ro_dst.sa_family != AF_INET || + satosin(&ro->ro_dst)->sin_addr.s_addr != + sin->sin_addr.s_addr || + inp->inp_socket->so_options & SO_DONTROUTE)) { RTFREE(ro->ro_rt); ro->ro_rt = (struct rtentry *)0; } @@ -421,6 +422,7 @@ (ro->ro_rt == (struct rtentry *)0 || ro->ro_rt->rt_ifp == (struct ifnet *)0)) { /* No route yet, so try to acquire one */ + bzero(&ro->ro_dst, sizeof(struct sockaddr_in)); ro->ro_dst.sa_family = AF_INET; ro->ro_dst.sa_len = sizeof(struct sockaddr_in); ((struct sockaddr_in *) &ro->ro_dst)->sin_addr = ----Next_Part(Thu_Mar_28_14:30:43_2002_965)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ip_output.c.diff" --- ip_output.c.orig Wed Mar 27 14:29:43 2002 +++ ip_output.c Thu Mar 28 14:15:56 2002 @@ -219,11 +219,13 @@ * and is still up. If not, free it and try again. */ if (ro->ro_rt && ((ro->ro_rt->rt_flags & RTF_UP) == 0 || + dst->sin_family != AF_INET || dst->sin_addr.s_addr != ip->ip_dst.s_addr)) { RTFREE(ro->ro_rt); ro->ro_rt = (struct rtentry *)0; } if (ro->ro_rt == 0) { + bzero(dst, sizeof(*dst)); dst->sin_family = AF_INET; dst->sin_len = sizeof(*dst); dst->sin_addr = ip->ip_dst; ----Next_Part(Thu_Mar_28_14:30:43_2002_965)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ip6_output.c.diff" --- ip6_output.c.orig Wed Mar 27 14:23:54 2002 +++ ip6_output.c Wed Mar 27 14:08:22 2002 @@ -461,6 +461,7 @@ * and is still up. If not, free it and try again. */ if (ro->ro_rt && ((ro->ro_rt->rt_flags & RTF_UP) == 0 || + dst->sin6_family != AF_INET6 || !IN6_ARE_ADDR_EQUAL(&dst->sin6_addr, &ip6->ip6_dst))) { RTFREE(ro->ro_rt); ro->ro_rt = (struct rtentry *)0; ----Next_Part(Thu_Mar_28_14:30:43_2002_965)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="in6_src.c.diff" --- in6_src.c.orig Wed Mar 27 14:24:28 2002 +++ in6_src.c Wed Mar 27 14:47:31 2002 @@ -239,7 +239,9 @@ */ if (ro) { if (ro->ro_rt && - !IN6_ARE_ADDR_EQUAL(&satosin6(&ro->ro_dst)->sin6_addr, dst)) { + (!(ro->ro_rt->rt_flags & RTF_UP) || + ro->ro_dst.sin6_family != AF_INET6 || + !IN6_ARE_ADDR_EQUAL(&satosin6(&ro->ro_dst)->sin6_addr, dst))) { RTFREE(ro->ro_rt); ro->ro_rt = (struct rtentry *)0; } ----Next_Part(Thu_Mar_28_14:30:43_2002_965)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 28 4:13:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from tesla.foo.is (tesla.reverse-bias.org [217.151.166.96]) by hub.freebsd.org (Postfix) with ESMTP id CB87837B419 for ; Thu, 28 Mar 2002 04:13:25 -0800 (PST) Received: from germanium (germanium.reverse-bias.org [192.168.1.1]) by tesla.foo.is (Postfix) with SMTP id 69911276D for ; Thu, 28 Mar 2002 12:13:19 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" From: Baldur Gislason To: freebsd-net@freebsd.org Subject: ARP complaints Date: Thu, 28 Mar 2002 12:16:21 +0000 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <0203281216210G.03229@germanium> 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 My logs are filled with crap like: arplookup 172.30.101.194 failed: host is not on local network arplookup 172.30.101.200 failed: host is not on local network arplookup 172.30.101.194 failed: host is not on local network arplookup 172.30.101.200 failed: host is not on local network arplookup 172.30.101.200 failed: host is not on local network My machine is 172.30.101.100, the netmask on that net is 255.255.255.240 There are other machines on the same physical network but with a different subnet, 172.30.101.192/28 My machine is complaining when it sees packets from the other machines, how can I turn this off? Baldur To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 28 5:26:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 5EA8937B400 for ; Thu, 28 Mar 2002 05:26:46 -0800 (PST) Received: by freesbee.wheel.dk (Postfix, from userid 1002) id 10DE25F46; Thu, 28 Mar 2002 14:26:44 +0100 (CET) Date: Thu, 28 Mar 2002 14:26:44 +0100 From: "Niels Chr. Bank-Pedersen" To: freebsd-net@freebsd.org Subject: Re: ARP complaints Message-ID: <20020328142644.D40568@bank-pedersen.dk> Mail-Followup-To: "Niels Chr. Bank-Pedersen" , freebsd-net@freebsd.org References: <0203281216210G.03229@germanium> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0203281216210G.03229@germanium>; from baldur@foo.is on Thu, Mar 28, 2002 at 12:16:21PM +0000 X-PGP-Fingerprint: 18D0 73F3 767F 3A40 CEBA C595 4783 D7F5 5DD1 FB8C X-PGP-Public-Key: http://freesbee.wheel.dk/~ncbp/gpgkey.pub Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Mar 28, 2002 at 12:16:21PM +0000, Baldur Gislason wrote: > My logs are filled with crap like: > > arplookup 172.30.101.194 failed: host is not on local network > arplookup 172.30.101.200 failed: host is not on local network > arplookup 172.30.101.194 failed: host is not on local network > arplookup 172.30.101.200 failed: host is not on local network > arplookup 172.30.101.200 failed: host is not on local network > > My machine is 172.30.101.100, the netmask on that net is 255.255.255.240 > There are other machines on the same physical network but with a different > subnet, 172.30.101.192/28 > My machine is complaining when it sees packets from the other machines, how > can I turn this off? sysctl -w net.link.ether.inet.log_arp_wrong_iface=0 > Baldur /Niels Chr. -- Niels Christian Bank-Pedersen, NCB1-RIPE. "Hey, are any of you guys out there actually *using* RFC 2549?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 28 12:57:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by hub.freebsd.org (Postfix) with SMTP id EA6D237B41D for ; Thu, 28 Mar 2002 12:57:24 -0800 (PST) Received: (qmail 87253 invoked by uid 1013); 28 Mar 2002 20:57:22 -0000 Date: Thu, 28 Mar 2002 21:57:22 +0100 From: Markus Stumpf To: "Keiichi SHIMA / ?$BEg7D0l?(B" Cc: freebsd-net@FreeBSD.ORG Subject: Re: problems with udp46 sockets Message-ID: <20020328215722.Q68348@Space.Net> References: <20020326231734.H58573@Space.Net> <20020327.162320.922733592.keiichi@iij.ad.jp> <20020327201119.E68348@Space.Net> <20020328.143043.67876714.keiichi@iij.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020328.143043.67876714.keiichi@iij.ad.jp>; from keiichi@iij.ad.jp on Thu, Mar 28, 2002 at 02:30:43PM +0900 Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF 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, Mar 28, 2002 at 02:30:43PM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > Sorry, it needs more work... > > Please revert the previous patches, and try with these attached again. It works perfect with the new patches. Thanks a lot, and also for the quick actions and for doing a great job for freebsd-net! \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 28 19: 4:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from fep4.cogeco.net (smtp.cogeco.net [216.221.81.25]) by hub.freebsd.org (Postfix) with ESMTP id B524537B404 for ; Thu, 28 Mar 2002 19:04:30 -0800 (PST) Received: from spirit.jaded.net (d141-4-223.home.cgocable.net [24.141.4.223]) by fep4.cogeco.net (Postfix) with ESMTP id 968001CB1; Thu, 28 Mar 2002 22:04:29 -0500 (EST) Received: from spirit.jaded.net (localhost [127.0.0.1]) by spirit.jaded.net (8.12.2/8.12.2) with ESMTP id g2T35ocw047431; Thu, 28 Mar 2002 22:05:55 -0500 (EST) (envelope-from dan@spirit.jaded.net) Received: (from dan@localhost) by spirit.jaded.net (8.12.2/8.12.2/Submit) id g2T35npX047430; Thu, 28 Mar 2002 22:05:49 -0500 (EST) Date: Thu, 28 Mar 2002 22:05:49 -0500 From: Dan Moschuk To: Sheldon Hearn Cc: freebsd-net@FreeBSD.org Subject: Re: Plans to MFC icmplim_output sysctl? Message-ID: <20020329030549.GB47250@spirit.jaded.net> References: <59376.1016628698@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59376.1016628698@axl.seasidesoftware.co.za> 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 | Hi Dan, | | Do you plan to MFC the icmplim_output sysctl work you did in ip_icmp.c | mid-2000? Seems quite useful for firewall-class systems running | 4.5-STABLE. Depends, has anyone backported the patch and tested it? I think it should apply cleanly, but I don't have a -STABLE machine to test it myself. Cheers, -Dan -- Build a man a fire and he'll be warm for a day. Set a man on fire and he'll be warm for the rest of his life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 29 7:58:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from evo2.evosoft.hu (evo2.evosoft.hu [194.143.228.181]) by hub.freebsd.org (Postfix) with ESMTP id B0F4637B419; Fri, 29 Mar 2002 07:58:06 -0800 (PST) Received: from evosoft.hu (griff.evosoft.hu [172.16.110.26]) by evo2.evosoft.hu (8.11.6/8.11.6) with ESMTP id g2TG1pf15252; Fri, 29 Mar 2002 17:01:51 +0100 (CET) (envelope-from Pelhrimovszky.Zsolt@evosoft.hu) Received: from evosoft.hu (pzso.evosoft.hu [172.16.110.144]) by evosoft.hu (8.11.3/8.11.3) with ESMTP id g2TFv5d01709; Fri, 29 Mar 2002 16:57:06 +0100 (CET) (envelope-from Pelhrimovszky.Zsolt@evosoft.hu) Message-ID: <3CA48E9A.603B7040@evosoft.hu> Date: Fri, 29 Mar 2002 16:56:10 +0100 From: "Pelhrimovszky, Zsolt" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de,hu MIME-Version: 1.0 To: stable@FreeBSD.ORG, net@FreeBSD.ORG Subject: Mystic network behaviour 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, in the past months we had a lot of network problems with our new FreeBSD gateway. These were network slowdowns. Playing with sysctls (rfc1323, newreno, syncookies, delayed_ack ..) didn't help. We upraded the system from 4.4 stable, up to 4.5 stable 2 weekly, downgraded it to 4.5 Release p2, but the slowdown still remained. The gateway has two interfaces: tx0 and tx1. tx0 was connected to 10Mb hub (towards to our ISPs router with 512Kbit leased line), tx1 to an 100MB switch (internal lan). The throughput was usually so much, that it filled the 512k bandwith. There were enough mbufs and other nerwork resources, the system does only gatewaying. The slowdown was caused by input errors on the tx0 interface (1-2 new errors per second, output from netstat -ni). Reinitialising it with ifconfig down and up stopped these errors for some time (from 2 minutes up to 2-3 days). Setting manually the ifconfig parameters (media, and mediaopts) also didn't help. The final solution was, that we changed the 10Mb hub to an 100MB switch, and now it works fine. Has anybody some ideas what was worng? Is a defect somewere in the FreeBSD ip-stack, or network driver implementation? Regards, Zs. Pelhrimovszky To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 29 8:39:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from cheer.mahoroba.org (flets20-089.kamome.or.jp [218.45.20.89]) by hub.freebsd.org (Postfix) with ESMTP id CE6AF37B416 for ; Fri, 29 Mar 2002 08:39:02 -0800 (PST) Received: from mille.mahoroba.org (IDENT:4LIDXcLOAx4SrTgvtbg+yjPUbiIl8mKFkkX3D0muMjubrcxtJca17WULeVe0wRVB@mille.mahoroba.org [IPv6:2001:200:301:0:202:2dff:fe0a:6bee]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.12.2/8.12.2) with ESMTP/inet6 id g2TGd09B013460 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 30 Mar 2002 01:39:00 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 30 Mar 2002 01:38:59 +0900 Message-ID: From: Hajimu UMEMOTO To: freebsd-net@FreeBSD.org Subject: route add -inet6 default ::1 -ifp gif0 User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 4.5-STABLE MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, The commit log of http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if.c.diff?r1=3D1.123&r2= =3D1.124 says: Benefit: the following command now works. Previously we needed two route(8) invocations, "add" then "change". # route add -inet6 default ::1 -ifp gif0 But, actually `route add -inet6 default ::1 -ifp gif0' doesn't work. This is because following code is in sys/net/if.c: if ( #ifdef INET6 /* XXX: for maching gif tunnel dst as routing entry gateway */ addr->sa_family !=3D AF_INET6 && #endif ifp->if_flags & IFF_POINTOPOINT) { /* * This is a bit broken as it doesn't * take into account that the remote end may * be a single node in the network we are * looking for. * The trouble is that we don't know the * netmask for the remote end. */ if (ifa->ifa_dstaddr !=3D 0 && equal(addr, ifa->ifa_dstaddr)) return (ifa); } else { The commit log of http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if.c.diff?r1=3D1.13&r2=3D= 1.14 says: Added a fix for a bug which caused the wrong interface to be selected for broadcasts if point-to-point links shared the same IP address as the ethernet. The fix must be enabled with P2P_LOCALADDR_SHARE option in the kernel config file. This will someday likely be standard, but there isn't sufficient time before release to determine if there are any interoperability problems with routed and/or gated. =46rom the commit log, I think this is specific to AF_INET. So, I wish to commit following change: Index: sys/net/if.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/net/if.c,v retrieving revision 1.127 diff -u -r1.127 if.c --- sys/net/if.c 18 Jan 2002 14:33:03 -0000 1.127 +++ sys/net/if.c 29 Mar 2002 16:16:11 -0000 @@ -830,10 +830,7 @@ =20 if (ifa->ifa_addr->sa_family !=3D af) next: continue; - if ( -#ifdef INET6 /* XXX: for maching gif tunnel dst as routing entry gateway */ - addr->sa_family !=3D AF_INET6 && -#endif + if (addr->sa_family =3D=3D AF_INET && ifp->if_flags & IFF_POINTOPOINT) { /* * This is a bit broken as it doesn't Any objection? -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 29 10:17:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from owa1.digisle.com (ex-owa-sj.digisle.com [165.193.27.217]) by hub.freebsd.org (Postfix) with ESMTP id 05A7037B416; Fri, 29 Mar 2002 10:16:33 -0800 (PST) Received: from digisle.net ([206.220.227.145] RDNS failed) by owa1.digisle.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.2966); Fri, 29 Mar 2002 10:16:32 -0800 Message-ID: <3CA4AF7F.4B0A1C93@digisle.net> Date: Fri, 29 Mar 2002 10:16:31 -0800 From: Maksim Yevmenkin Organization: Digital Island X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Flow control in -current Netgraph (long) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2002 18:16:32.0509 (UTC) FILETIME=[DAB8EAD0:01C1D74D] 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 Hackers, i'm writing Bluetooth L2CAP sockets layer in Netgraph. the basic idea is very similar to Netgraph sockets except L2CAP is a reliable protocol. before L2CAP channel is open, each peer must negotiate incoming and outgoing MTU for the channel. so the idea is that each peer sends and receives datagram of fixed MTU. note that send and receive MTU might be different. L2CAP protocol also provides protocol/service multiplexing (PSM) so upper layer protocols can use L2CAP as a transport (for example SDP, RFCOMM etc.) new L2CAP node is created for every Bluetooth unit. L2CAP downstream hook is connected to the HCI layer. also L2CAP node presents four upstream hooks that represents protocols (i.e. sdp, rfcomm, tcp and orphan - for other protocols). for now every L2CAP upstream hook of every L2CAP node is connected to the same L2CAP sockets layer. so the sockets layer knows which PSM/unit downstream hook is connected to. the socket address contains PSM and BDADDR. (BDADDR is a Bluetooth unit address similar to MAC address in Ethernet). when socket requesting new connection (via connect() call) new Netgraph control message is sent to appropriate downstream hook (based on which address socket was bound via bind() and remote peer's address from connect()). the L2CAP node responds to control message and eventually socket goes into CONNECTED state. now the data transfer is a bit of a problem. currently i'm using Netgraph NG_SEND_DATA macros to send data from socket to the L2CAP node. when i do stress testing and sending data as fast as i can the system runs out of mbufs. packets gets dropped and everything goes into unpredictable state. bottom line: in order to guarantee reliable L2CAP channel i must acknowledge every data packet. the upper layer must not send any more until is gets an acknowledgment. note that single L2CAP packet must be fragmented before it can be send to the HCI layer. it is not allowed to reorder/mix fragments on the same physical link. so, as of now i have three options 1) put data in queue on every layer and try not to overflow them. i do not know the easy and fast way to implement this. note that upstream hooks may be connected to the different nodes and L2CAP node must somehow synchronize them and make sure than everyone gets bandwidth. 2) prepend every data mbuf with some soft of envelope and as soon as packet was sent acknowledge it by sending Netgraph control message back to sender (using information from envelope). i can live with that, but it might be confusing. the sender sends data, but gets a message back. 3) convert every send request into Netgraph message and as soon as packet was sent acknowledge it by sending response message back. i like this too, but there is another problem. i can not pass mbuf in Netgraph control message. here is an example: socket layer pru_send function accepts mbuf. it converts it into Netgraph message (m_copydata) and sends it to downstream hook. lower layer would have to convert it back to mbuf (m_copyback) because it wants to fragment it, add headers, etc. yuck! i would go with option 2 for now unless someone can suggest a better way. thanks max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 30 12: 2:27 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 2D0DD37B404; Sat, 30 Mar 2002 12:01:56 -0800 (PST) Received: from localhost (ady@localhost) by ady.warpnet.ro (8.9.3/8.9.3) with ESMTP id WAA29174; Sat, 30 Mar 2002 22:01:52 +0200 (EET) (envelope-from ady@freebsd.ady.ro) Date: Sat, 30 Mar 2002 22:01:51 +0200 (EET) From: Adrian Penisoara X-Sender: ady@ady.warpnet.ro To: freebsd-net@freebsd.org, freebsd-smp@freebsd.org Cc: altq@freebsd.ady.ro Subject: ATTN: ALTQ integration -- looking for people 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, The ALTQ integration project is about to emerge. We will need heelp with code reviewing, SMP procedures (making ALTQ SMP-safe), networking architecture and, last but not least, we are looking for one (or more) committer to help us with patch integrations. All interested people please reply to the address (an ALTQ developing mini-list). Please also specify wether you'd like your e-mail address to be added to this list. Thanks! Adrian Penisoara Ady (@freebsd.ady.ro) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message