From owner-freebsd-net Sun Jul 14 11:58:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF01B37B400; Sun, 14 Jul 2002 11:58:46 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D02D43E5E; Sun, 14 Jul 2002 11:58:46 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g6EIwka78526; Sun, 14 Jul 2002 11:58:46 -0700 (PDT) (envelope-from rizzo) Date: Sun, 14 Jul 2002 11:58:46 -0700 From: Luigi Rizzo To: arch@freebsd.org Subject: reintroduce handling of NULL route in ip_output() Message-ID: <20020714115846.C78146@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [discussion on -arch, Bcc to -net in case someone is interested there] Hi, I would like to reintroduce the ability to pass a NULL route to p_output(), which has been possible up to rev.1.34 of ip_output(). Making ip_output() unable to handle NULL routes only saved a single "if (ro == NULL)" check, but caused the work of allocating/deallocating the route to be replicated in multiple places in the clients of ip_output(), and the way this is done is very inconsistent, sometimes involving the use of static variables which (apart from potential errors due to misuse) are a no-no if we ever want to go to fine-grained locking in the network stack. See for example how the route to ip_output is passed in netinet/igmp.c netinet/ip_mroute.c netinet/ip_input.c netinet/tcp_subr.c at least in one place there is a "bug" (like resetting some fields of an automatic variable right before exiting from the block). Other usages look suspicious too. My reason to re-allow NULL routes in ip_output() are: * simplify the code in the callers by centralizing a common function; * make another step towards the removal of global variables in the protocol stack; Does any of you have strong and _motivated_ objections ? thanks luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 14 18:28: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 299AF37B400 for ; Sun, 14 Jul 2002 18:28:01 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AB6E43E5E for ; Sun, 14 Jul 2002 18:28:00 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (ras01.isi.edu [128.9.176.101]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g6F1Rwr12034; Sun, 14 Jul 2002 18:27:58 -0700 (PDT) Message-ID: <3D3305D1.5050103@isi.edu> Date: Mon, 15 Jul 2002 10:26:41 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: net@freebsd.org, Joe Touch , Yu-Shun Wang Subject: Denial-of-service through ARP snooping Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010907040904060507060705" 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. --------------ms010907040904060507060705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, we've just stumbled over an interesting denial-of-service case at IETF. I was playing with a custom startup script to auto-configure local interfaces, part of which sent out an ARP request "borrowing" the IP address of the gateway as source address (e.g. "who-has X tell X"). It seems that most/all BSDs do ARP snooping, and will happily add the apparent "new" MAC address of the gateway to their ARP table, possibly flushing the existing one of the default gateway. This of course causes everybody's packets to fall on the floor until the fake ARP entry times out. (RFC826 seems to imply that snooping is allowed, the "packet reception" section doesn't seem to limit *how* packets are received.) Maybe ARP entries should only be updated when replies are received in response to locally originated requests? Initial latency might be a bit higher, since the ARP table won't be pre-loaded, but it will add some protection against this particular DOS attack. Lars -- Lars Eggert USC Information Sciences Institute --------------ms010907040904060507060705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDcxNTE3MjY0MlowIwYJKoZIhvcNAQkEMRYEFOl+SHloSKx1 lzShQJiyKeRQlesYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYB/KM70J7rJaGNXpUpLlo115D6EzZ3usMJ39zjbX239pug3 PanJYSbRnlvJjRuUpjLP1fl5S6O83vP1t5TXYLYVRtIt4RAEnpXEoDSbFa8HZ65s3VmXk6PK 725Mi6EkcBEXLa67TjHH6dkiGJwL2qVqT8OacTWeJ1ch6jJjE882pQAAAAAAAA== --------------ms010907040904060507060705-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 14 20: 0:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0422437B401 for ; Sun, 14 Jul 2002 20:00:45 -0700 (PDT) Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AA8943E58 for ; Sun, 14 Jul 2002 20:00:44 -0700 (PDT) (envelope-from barney@databus.com) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.5/8.12.5) with ESMTP id g6F30hBM057768; Sun, 14 Jul 2002 23:00:43 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.5/8.12.5/Submit) id g6F30hoF057767; Sun, 14 Jul 2002 23:00:43 -0400 (EDT) Date: Sun, 14 Jul 2002 23:00:43 -0400 From: Barney Wolff To: Lars Eggert Cc: net@FreeBSD.ORG, Joe Touch , Yu-Shun Wang Subject: Re: Denial-of-service through ARP snooping Message-ID: <20020715030043.GA57525@tp.databus.com> References: <3D3305D1.5050103@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D3305D1.5050103@isi.edu> User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I don't see that the risk is diminished by much. A hostile host will see any ARP requests, since they're sent to the broadcast addr, and can try to beat the real node's response - it probably has a faster cpu than the router. Besides, there are loads of ways to wreak havoc on your local subnet, including sending 64-byte frames at wirespeed to the broadcast address. It doesn't seem worthwhile to start closing holes unless there's a real chance to close all or nearly all, which I doubt. I recall seeing a syslog when the MAC address for an ARP table entry changes, so at least there's some evidence. A clever attacker who can fudge your ARP table can do better than DoS; he can forward the packets onward while snooping or playing MitM. So a hostile node on your subnet is a real disaster. On Mon, Jul 15, 2002 at 10:26:41AM -0700, Lars Eggert wrote: > Hi, > > we've just stumbled over an interesting denial-of-service case at IETF. > I was playing with a custom startup script to auto-configure local > interfaces, part of which sent out an ARP request "borrowing" the IP > address of the gateway as source address (e.g. "who-has X tell X"). > > It seems that most/all BSDs do ARP snooping, and will happily add the > apparent "new" MAC address of the gateway to their ARP table, possibly > flushing the existing one of the default gateway. This of course causes > everybody's packets to fall on the floor until the fake ARP entry times > out. (RFC826 seems to imply that snooping is allowed, the "packet > reception" section doesn't seem to limit *how* packets are received.) > > Maybe ARP entries should only be updated when replies are received in > response to locally originated requests? Initial latency might be a bit > higher, since the ARP table won't be pre-loaded, but it will add some > protection against this particular DOS attack. > > Lars > -- > Lars Eggert USC Information Sciences Institute -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 14 21:56:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CEE837B400 for ; Sun, 14 Jul 2002 21:56:28 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A76A43E70 for ; Sun, 14 Jul 2002 21:56:27 -0700 (PDT) (envelope-from touch@ISI.EDU) Received: from isi.edu (ras31.isi.edu [128.9.176.131]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g6F4uJr07275; Sun, 14 Jul 2002 21:56:20 -0700 (PDT) Message-ID: <3D3255CE.6000707@isi.edu> Date: Sun, 14 Jul 2002 21:55:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lars Eggert Cc: net@freebsd.org, Yu-Shun Wang Subject: Re: Denial-of-service through ARP snooping References: <3D3305D1.5050103@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org PS - this is more than a DOS attack. It's also a misconfiguration DOS attack. Users who type the wrong address in will cause this. I.e., even on a friendly LAN, a single accident can pull the net down. Joe Lars Eggert wrote: > Hi, > > we've just stumbled over an interesting denial-of-service case at IETF. > I was playing with a custom startup script to auto-configure local > interfaces, part of which sent out an ARP request "borrowing" the IP > address of the gateway as source address (e.g. "who-has X tell X"). > > It seems that most/all BSDs do ARP snooping, and will happily add the > apparent "new" MAC address of the gateway to their ARP table, possibly > flushing the existing one of the default gateway. This of course causes > everybody's packets to fall on the floor until the fake ARP entry times > out. (RFC826 seems to imply that snooping is allowed, the "packet > reception" section doesn't seem to limit *how* packets are received.) > > Maybe ARP entries should only be updated when replies are received in > response to locally originated requests? Initial latency might be a bit > higher, since the ARP table won't be pre-loaded, but it will add some > protection against this particular DOS attack. > > Lars To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 15 0:54:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8064F37B84F for ; Mon, 15 Jul 2002 00:54:29 -0700 (PDT) Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C90443E3B for ; Mon, 15 Jul 2002 00:53:05 -0700 (PDT) (envelope-from sakane@kame.net) Received: from localhost ([2001:218:1e1f:40:260:1dff:fe21:f766]) by papa.tanu.org (8.11.6/8.11.6) with ESMTP id g6F7upn80384; Mon, 15 Jul 2002 16:56:53 +0900 (JST) (envelope-from sakane@kame.net) To: vulture@consult-scs.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPSEC Tunnel In-Reply-To: Your message of "Tue, 09 Jul 2002 22:07:40 -0700" <3D2BC11C.2000508@consult-scs.com> References: <3D2BC11C.2000508@consult-scs.com> X-Mailer: Cue version 0.6 (020620-1817/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20020715165303Y.sakane@kame.net> Date: Mon, 15 Jul 2002 16:53:03 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 16 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 it not possible to have the internal ip addresses of the tunnel > machines talk with other internal addresses on the other side of the tunnel? > Example Set Up: > Packets from say 192.168.0.2 to 192.168.1.1 and back > (192.168.0.0/24 Lan)-(192.168.0.1 Internal)->(200.0.0.1 > Interface)===IPSEC TUNNEL===(200.0.0.2 Inteface)<-(192.168.1.1 > Internal)-(192.168.0.1/24 Lan) > > I can see the packets from 192.168.0.2->192.168.1.1 under tcpdump of > 200.0.0.2 as a (ipip) Packet from 200.0.0.1->200.0.0.2 having > 192.168.0.2->192.168.1.1 listed but the packet just seems to disappear > after that. It does not show up under lo0 or the internal interface. because the network behind the gateway 200.0.0.2 is 192.168.0.1/24 as you descirbed. any packet to 192.168.1.1 can not be routed by 200.0.0.2. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 15 10:36:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E732137B6F9 for ; Mon, 15 Jul 2002 10:35:56 -0700 (PDT) Received: from kali.avantgo.com (shadow.avantgo.com [64.157.226.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF866442A2 for ; Mon, 15 Jul 2002 10:23:20 -0700 (PDT) (envelope-from scott@avantgo.com) Received: from river.avantgo.com ([10.11.30.114]) by kali.avantgo.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 15 Jul 2002 10:23:11 -0700 Date: Mon, 15 Jul 2002 10:20:06 -0700 (PDT) From: Scott Hess To: Bosko Milekic Cc: Jon Mini , Subject: Re: mbuf external buffer reference counters In-Reply-To: <20020712074507.B75547@unixdaemons.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 15 Jul 2002 17:23:11.0404 (UTC) FILETIME=[4B540EC0:01C22C24] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 12 Jul 2002, Bosko Milekic wrote: > On Fri, Jul 12, 2002 at 04:26:53AM -0700, Jon Mini wrote: > > I'm probably speaking out of turn here (I have no idea what structure > > you all are talking about), but a monodirectional ring can be safely > > modified with a compare-and-exchange atomic operation. > > The jist of the problem is that when you want to say, remove yourself > from the list, you have to: > > 1) your "next"'s back pointer to your "back" pointer > 2) your "Prev"'s next pointer to your "next" pointer > > So that's two operations but for all you know your "next" or your > "back" may be doing the same thing to you at the same time. As far as > I know, you can't (intuitively) figure out a way to do both of these > atomically. i.e., maybe you'll set your next's back pointer to whatever > you have in `back' but then your `back' guy will set your back pointer > to whatever he has in `back' and then your next guy's back pointer will > be invalid, for example. You threw out a logic problem The following came to mind, though I've not quite been able to fully think through all possibilities, yet (C psuedo-code, because I am not up-to-date on my assembly. Comments assume a list A<->B<->C<-^, B being deleted): r1=prev; // If prev!=r1, A was deleted during the race. prev=0 iff prev==r1; // atomic test-and-set. r2=next; // If next!=r2, C was deleted during the race. next=0 iff next==r2; // If r2->prev!=self, then the C is in delete. r2->prev=r1 iff r2->prev==self; // At this point, if C attempted a delete, the delete code would // notice that C->prev->next != C (it is still B). // If r1->next!=self, then the A is in delete. r1->next=r2 iff r1->next==self; Storing the 0's locks against deletes from the neighbors. The failure cases for the first three exchanges (X=Y iff X==Z) are pretty straightforward, and I think can be safely unwound. The fourth failure case is interesting, though, because I _think_ that if you correctly code the failure cases, you can try to run 'r1->next=r2 iff r1->next==0;' to salvage it. It's possible that there's a way of coding things which would always allow one of two conflicting threads to proceed, so that spinning on failure is sensible. I can't quite see it, though. I have no idea what the performance implications of this are. AFAICT, you would require 3 locks to accomplish this correctly (self, next, prev *), which implies 6 total exchanges. Also, I haven't considered the insert case, though I'm not sure why it wouldn't simply invert the ordering of the delete. (*) Hmm. I thought you could do two (Lock self, lock next, prev->next=next, next->prev=prev, unlock next, delete self), but then realized that there was a race between finding next and applying the lock. So you need all three. Later, scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 15 15: 4:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3468237B400 for ; Mon, 15 Jul 2002 15:04:29 -0700 (PDT) Received: from kali.avantgo.com (shadow.avantgo.com [64.157.226.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5C4E43E4A for ; Mon, 15 Jul 2002 15:04:28 -0700 (PDT) (envelope-from scott@avantgo.com) Received: from river.avantgo.com ([10.11.30.114]) by kali.avantgo.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 15 Jul 2002 15:04:27 -0700 Date: Mon, 15 Jul 2002 15:01:22 -0700 (PDT) From: Scott Hess To: freebsd-net@freebsd.org Subject: Re: increasing throughput In-Reply-To: <001b01c22212$6355fa90$0b01a8c0@fear.wrath.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 15 Jul 2002 22:04:27.0169 (UTC) FILETIME=[96117110:01C22C4B] 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, 2 Jul 2002, Brian wrote: > On Tue, July 2, 2002, "Scott Hess" wrote: > > I'm very interested in this type of product (meaning "Really small box > > that's essentially a complete PC, without having to build an > > enclosure"). Here's a unit which I'm looking at (but, unfortunately, > > have yet to receive info on): > > > > http://www.advantech.com/products/Model_Detail.asp?model_id=1-8089T&bu= > > > > In case that doesn't work, select Network Computing/Network Appliances > > from the products popup, then Firewall Platforms. > > Now that is pretty slick. If you find out how much it costs let us all > know. Finally got info back: $500 FWA-200 (barebones box) $ 64 Celeron 566 $ 36 128MB SODIMM $ 54 64MB Compact Flash Card $ 35 Wiring kit (not certain what this means, since there isn't anything to wire) $ 80 Installation, test, burn-in ---- $769 Ouch! That's about $300 above where I'm willing to consider it. Maybe you could save $60 buying the commodity components yourself, and another $80 by doing your own burn-in, but since most of the money is in the box, that doesn't get you far... they did say that orders of 10 or more can get a 5% discount. [I can throw out a recommendation for the company, though. A number of years back I bought a POS system from them for use as a router. it was pretty small for the time, while still allowing me to stuff in a standard hard drive and two or three standard PCI or ISA cards. It's long since bit the dust, though, I'm sure some would say _because_ I used a standard hard drive and the like :-).] Later, scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 15 17:38:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DA6437B400 for ; Mon, 15 Jul 2002 17:38:06 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 869B443E64 for ; Mon, 15 Jul 2002 17:38:05 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (ras01.isi.edu [128.9.176.101]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g6FNmFr20697; Mon, 15 Jul 2002 16:48:15 -0700 (PDT) Message-ID: <3D343FF2.3070405@isi.edu> Date: Tue, 16 Jul 2002 08:46:58 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Scott Hess Cc: freebsd-net@freebsd.org Subject: Re: increasing throughput References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080702020409080205050302" 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. --------------ms080702020409080205050302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Scott Hess wrote: > Finally got info back: > > $500 FWA-200 (barebones box) > $ 64 Celeron 566 > $ 36 128MB SODIMM > $ 54 64MB Compact Flash Card > $ 35 Wiring kit (not certain what this means, since there isn't anything > to wire) > $ 80 Installation, test, burn-in > ---- > $769 Ouch! > > That's about $300 above where I'm willing to consider it. Soren's boxes (http://www.soekris.com/) are half that price and work great for our purposes. (Although the current models are also a bit less powerful than the one above.) Lars -- Lars Eggert USC Information Sciences Institute --------------ms080702020409080205050302 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDcxNjE1NDY1OFowIwYJKoZIhvcNAQkEMRYEFITCP54juvue K6FR5GDXAZgJfQ2eMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYCXPeaBb9G/89JCIvq3s0vpUQNNhg5gBr17GqjrYFkq/xX4 Xq9Ki+Y3kVsOvUwCr56UV1xfwnw2YiALlzSH5+A6ccsdkSsAcpykJ32EbYsWLPiUZk34lGqS DrJgN6pxsnUDKkCMxzLPAowd7dHnbSD9a5YQwdbAcaoFwIG3fh/n2gAAAAAAAA== --------------ms080702020409080205050302-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 16 4: 6: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5733437B400 for ; Tue, 16 Jul 2002 04:05:58 -0700 (PDT) Received: from publica.ub.mng.net (publica.ub.mng.net [202.179.0.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id E80E543E4A for ; Tue, 16 Jul 2002 04:05:55 -0700 (PDT) (envelope-from balgaa@publica.ub.mng.net) Received: (from root@localhost) by publica.ub.mng.net (8.12.3/8.12.2) id g6GC2jWJ037000 for freebsd-net@freebsd.org; Tue, 16 Jul 2002 20:02:45 +0800 (ULAT) (envelope-from balgaa@publica.ub.mng.net) Received: from publica.ub.mng.net (localhost [127.0.0.1]) by publica.ub.mng.net (8.12.3/8.12.3) with ESMTP id g6GC2hg6036990 for ; Tue, 16 Jul 2002 20:02:44 +0800 (ULAT) (envelope-from balgaa@publica.ub.mng.net) Received: from localhost (balgaa@localhost) by publica.ub.mng.net (8.12.3/8.12.3/Submit) with ESMTP id g6GC2hDt036987 for ; Tue, 16 Jul 2002 20:02:43 +0800 (ULAT) Date: Tue, 16 Jul 2002 20:02:43 +0800 (ULAT) From: User BALGAA System Engineer To: freebsd-net@freebsd.org Subject: FreeBSD+IPFILTER+PPPoE+DHCP problem Message-ID: <20020716200229.V30816-100000@publica.ub.mng.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I installed FreeBSD-4.6 on HP Vectra PC. I configured this machine as NAT gateway. Connection diagram: LAN-------FreeBSD IPFILTER/NAT/DHCP----ADSL modem-----ISP PPPoE and IPFilter/NAT/DHCP working normal. Problem is Windows 95/98/98SE users can to go through FreeBSD gateway machine, but Windows 2000/XP sometimes working, sometimes can't. Sametime if can't work Windows 2000/XP stop to access LAN servers, shared resources. Strange thing, I can to ping from Windows 2000/XP PC to outside network hosts. If sometime I refresh IP address from DHCP, then I can to access some website after few minutes it stop. If I try to ping using domainname of outside host then impossible. But from FreeBSD gateway machine I can to ping IP/domain name of hosts. I check DNS servers of our ISP and it is working normal. I don't know this mailing list correct or not. Any suggestion? Thanks, Balgaa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 16 5:38:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0323E37B400; Tue, 16 Jul 2002 05:38:15 -0700 (PDT) Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5835B43E31; Tue, 16 Jul 2002 05:38:13 -0700 (PDT) (envelope-from c.prevotaux@hexanet.fr) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.3/8.12.3) with SMTP id g6GCcBCE029429; Tue, 16 Jul 2002 14:38:11 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Tue, 16 Jul 2002 14:38:10 +0200 From: Christophe Prevotaux To: net@freebsd.org Subject: vr driver Message-Id: <20020716143810.786ac522.c.prevotaux@hexanet.fr> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Has anyone fixed yet the vr 'driver' "watchdog timeout" bug in STABLE ? -- -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 16 7:36:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5ECD37B40B for ; Tue, 16 Jul 2002 07:36:05 -0700 (PDT) Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 471F043E5E for ; Tue, 16 Jul 2002 07:36:05 -0700 (PDT) (envelope-from ghelmer@palisadesys.com) Received: from mira (mira.palisadesys.com [192.188.162.116]) (authenticated (0 bits)) by magellan.palisadesys.com (8.11.6/8.11.6) with ESMTP id g6GDq2I00728 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 16 Jul 2002 08:52:03 -0500 From: "Guy Helmer" To: "Song Bo Run" , Subject: RE: Crashes in fxp driver with polling enabled Date: Tue, 16 Jul 2002 08:52:02 -0500 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <3D33B8C6.2FF275F1@rdsk.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tuesday, July 16, 2002 1:10 AM, Song Bo Run [mailto:song@rdsk.net] wrote: > Hello, Guy > > Here we are encountering almost exactly the same problem as you are, > except that we are using OpenBSD. We have ported Luigi's polling code > to OpenBSD 2.9 and are using fxp driver. Our testing attack is just ping > -f with 65500 bytes data. > > We notice that mclfree is bad when the system crashes. It seems that the > card write to a freed cluster, because the mclfree is always 0xa020xxxx > when crash. 0xa0 is exactly (FXP_RFA_STATUS_OK|FXP_RFA_STATUS_C). > > We can 100% crash the system if we boot the system while doing the > attack. > So we guess that under heavy system bus usage (we guess that during > system startup, VM system must be very busy faulting) the Intel NIC will > do something wrong. > > Has your problem solved under FreeBSD 4.6-Release? I just test 4.6, it > does not crash. Maybe the attack is not strong enough. I'll do more test > later. Over the past few days I have been testing polling with fxp on FreeBSD 4.6-stable (as of a week ago) and it has not crashed at all under the various heavy loads under which 4.5 would crash. Before 4.6-RELEASE, Luigi mentioned to me in an email that he had received a patch from someone that fixed the problem and that he hoped to check it in before 4.6 was released. I didn't notice anything in the CVS logs but Luigi might have committed that fix. > Guy Helmer wrote: > > > > I am encountering a problem in the fxp driver that seems to be exposed by > > enabling polling under high packet load (~12000pps). I have been > > corresponding with Luigi regarding this problem but would like to see if > > anyone else might have any ideas that could help. > > > > I'm using FreeBSD 4.5-stable kernels on two completely different hardware > > platforms, a P-III 800 Intel ISP1100 and a homebrew Celeron with an Intel > > EtherExpress Pro-100B. Both machines panic with the same results. The > > machines panic with a kernel page fault, usually right after I enable > > polling but sometimes the machines will keep running until I do some other > > I/O-intensive tasks or run "top". > > > > There usually isn't an IP address on the fxp interface, but the interface is > > UP and listening to packets in promiscuous mode. I have verified that the > > crashes do occur when there is an IP address on the interface and when the > > interface is not in promiscuous mode. > > > > I noticed that after the kernel page fault trap occurs, fxp0 is sending the > > same bogus frame (containing junk) every millisecond or so. I don't > > understand why fxp0 is sending anything because the machine shouldn't be > > transmitting anything on that interface. I have the exact same code running > > on a system that has a SIS interface, and that system runs fine. > > > > The crash occurs in line 1847 of if_fxp.c: MCLGET(m, M_DONTWAIT) (in the > > expansion of MCLALLOC()). It looks like there is a bad index generated by > > mtocl(_mp) when "mclrefcnt[mtocl(_mp)]++;" is performed. mclfree is > > 0xc0306524 and mbutl is 0xc0306578 after the crash. I think there is some > > free mbuf list corruption triggered somewhere else in the driver, but I > > can't find anything in if_fxp.c that looks suspicious. > > > > Backtrace: > > fxp_add_rfabuf(c04e1400, c04e2900) at fxp_add_rfabuf+0x9f > > fxp_intr_body(c04e1400, e0, 3, 0, 5) at fxp_intr_body+0xd8 > > fxp_poll(c04e1400, 0, 5) at fxp_poll+0x9a > > netisr_poll(c026b4cf, bfbf002f, bfbf002f, bfbf002f) at netisr_poll+0x16b > > swi_net_next() at swi_net_next > > > > Registers: > > eax: 0x01bfb12 > > ecx: 0xa026b000 > > edx: 0xc04d7000 > > ebx: 0xc052ae00 > > esp: 0xc3cdbf1c > > ebp: 0xc3cdbf2c > > esi: 0x660c00 > > edi: 0xc052ae00 > > eip: 0xc0137d87 > > cs: 0x8 > > ds: 0xc0190010 > > es: 0xc3cd0010 > > fs: c04e0010 > > ss: 0x10 > > > > ... > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 16 8:17:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E280337B400; Tue, 16 Jul 2002 08:17:46 -0700 (PDT) Received: from obsidian.sentex.ca (obsidian.sentex.ca [64.7.128.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46CEF43E5E; Tue, 16 Jul 2002 08:17:46 -0700 (PDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (pyroxene.sentex.ca [199.212.134.18]) by obsidian.sentex.ca (8.12.5/8.12.4) with ESMTP id g6GFHjmW018696; Tue, 16 Jul 2002 11:17:45 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020716111422.07bc1498@marble.sentex.ca> X-Sender: mdtpop@marble.sentex.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 16 Jul 2002 11:21:21 -0400 To: freebsd-net@freebsd.org From: Mike Tancsa Subject: mpd and bringing up routes at connect time Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: By Sentex Communications (obsidian/20020220) 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 any way with mpd to automatically bring up a route when a customer connects using pptp where multiple users are connecting ? The problem I am running into is that user X will PPTP into the server. As they will come in on different netgraph interfaces, the route needs to be pointed to a different netgraph interface each time. Specifically, how do I add n routes to user X's connection on demand. Is it possible with mpd ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 16 9:25: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB1E337B400 for ; Tue, 16 Jul 2002 09:24:57 -0700 (PDT) Received: from hotmail.com (f175.law14.hotmail.com [64.4.21.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15CC343E4A for ; Tue, 16 Jul 2002 09:24:57 -0700 (PDT) (envelope-from alexdyas@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 16 Jul 2002 09:24:56 -0700 Received: from 194.6.2.163 by lw14fd.law14.hotmail.msn.com with HTTP; Tue, 16 Jul 2002 16:24:56 GMT X-Originating-IP: [194.6.2.163] From: "Alex Dyas" To: net@freebsd.org Cc: silby@silby.com Subject: Re: BSD / Firewall / 0 window size problem Date: Tue, 16 Jul 2002 16:24:56 +0000 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_4f35_66b_36e0" Message-ID: X-OriginalArrivalTime: 16 Jul 2002 16:24:56.0996 (UTC) FILETIME=[52E97640:01C22CE5] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_4f35_66b_36e0 Content-Type: text/plain; format=flowed Mike Silbersack wrote: >On Thu, 11 Jul 2002, Alex Dyas wrote: > > >>The only clue I've managed to find as to what is going on is in a tcpdump >>of >>the session (attached). The trigger for the lock up seems to be a >>messages >>from the Otherbox machine setting the window size to 0 : >> >>10:41:38.614141 otherbox.foo.com.telnet > bsdbox.foo.com.2230: . ack 154 >>win >>0 >>10:41:38.614200 bsdbox.foo.com.2230 > otherbox.foo.com.telnet: . ack 337 >>win >>33304 (DF) [tos 0x10] >> >>I've tried all the following scenarios, none of which exhibit the same >>problem, which is why I think the problem is with FreeBSD : >> >>bsdbox.foo.com -> otherbox.foo.com >>solarisbox.foo.com -> internal GNAT firewall -> otherbox.foo.com >>windowsbox.foo.com -> internal GNAT firewall -> otherbox.foo.com >>linuxbox.foo.com -> internal GNAT firewall -> otherbox.foo.com > > >Could you post a tcpdump of one of the successful connections so that we >can see how 0 windows are handled there? > >Also, have you tcpdump'd at both ends to ensure that we're not actually >seeing odd sideeffects of packet loss or something? (Some reported >problems in the past have been due to misbehaving duplex autodetect and >bad cables.) > >Offhand, I can't see what the FreeBSD box is doing wrong, but I'd like >something else to compare to. > >Thanks, > >Mike "Silby" Silbersack > I've attached a tcpdump of a Linux machine doing the same thing (working.txt). the same 0 sized window can be seen: 17:15:56.094161 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack 456 win 5840 (DF) [tos 0x10] 17:16:12.634540 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: . ack 74 win 0 17:16:12.634540 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack 456 win 5840 (DF) [tos 0x10] but the Linux telnet session does not freeze up as the BSD one does. Again, any help would be most appreciated. Thanks again, Alex... _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com ------=_NextPart_000_4f35_66b_36e0 Content-Type: text/plain; name="working.txt"; format=flowed Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="working.txt" 17:15:52.134070 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: P 68:70(2) ack 417 win 5840 (DF) [tos 0x10] 17:15:52.144070 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P 417:419(2) ack 70 win 24616 (DF) 17:15:52.144070 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack 419 win 5840 (DF) [tos 0x10] 17:15:52.144070 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P 419:430(11) ack 70 win 24616 (DF) 17:15:52.144070 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack 430 win 5840 (DF) [tos 0x10] 17:15:53.744107 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: P 70:72(2) ack 430 win 5840 (DF) [tos 0x10] 17:15:53.744107 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P 430:432(2) ack 72 win 24616 (DF) 17:15:53.744107 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack 432 win 5840 (DF) [tos 0x10] 17:15:53.744107 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P 432:443(11) ack 72 win 24616 (DF) 17:15:53.744107 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack 443 win 5840 (DF) [tos 0x10] 17:15:56.094161 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: P 72:74(2) ack 443 win 5840 (DF) [tos 0x10] 17:15:56.094161 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P 443:445(2) ack 74 win 24616 (DF) 17:15:56.094161 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack 445 win 5840 (DF) [tos 0x10] 17:15:56.094161 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P 445:456(11) ack 74 win 24616 (DF) 17:15:56.094161 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack 456 win 5840 (DF) [tos 0x10] 17:16:12.634540 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: . ack 74 win 0 17:16:12.634540 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack 456 win 5840 (DF) [tos 0x10] 17:16:20.034709 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: P 74:76(2) ack 456 win 5840 (DF) [tos 0x10] 17:16:20.034709 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P 456:458(2) ack 76 win 24616 (DF) 17:16:20.034709 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack 458 win 5840 (DF) [tos 0x10] 17:16:20.034709 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P 458:469(11) ack 76 win 24616 (DF) 17:16:20.034709 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack 469 win 5840 (DF) [tos 0x10] 17:16:20.234714 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: P 76:78(2) ack 469 win 5840 (DF) [tos 0x10] 17:16:20.234714 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P 469:471(2) ack 78 win 24616 (DF) 17:16:20.234714 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack 471 win 5840 (DF) [tos 0x10] 17:16:20.234714 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P 471:482(11) ack 78 win 24616 (DF) 17:16:20.234714 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack 482 win 5840 (DF) [tos 0x10] ------=_NextPart_000_4f35_66b_36e0 Content-Type: text/plain; name="notworking.txt"; format=flowed Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="notworking.txt" 10:41:22.149761 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: P 146:148(2) ack 285 win 33304 (DF) [tos 0x10] 10:41:22.150396 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 285:287(2) ack 148 win 24616 (DF) 10:41:22.249151 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 287 win 33304 (DF) [tos 0x10] 10:41:22.249515 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 287:298(11) ack 148 win 24616 (DF) 10:41:22.349154 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 298 win 33304 (DF) [tos 0x10] 10:41:22.380132 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: P 148:150(2) ack 298 win 33304 (DF) [tos 0x10] 10:41:22.380644 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 298:300(2) ack 150 win 24616 (DF) 10:41:22.484269 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 300 win 33304 (DF) [tos 0x10] 10:41:22.484920 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 300:311(11) ack 150 win 24616 (DF) 10:41:22.579160 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 311 win 33304 (DF) [tos 0x10] 10:41:22.599564 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: P 150:152(2) ack 311 win 33304 (DF) [tos 0x10] 10:41:22.600250 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 311:313(2) ack 152 win 24616 (DF) 10:41:22.699161 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 313 win 33304 (DF) [tos 0x10] 10:41:22.699564 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 313:324(11) ack 152 win 24616 (DF) 10:41:22.799162 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 324 win 33304 (DF) [tos 0x10] 10:41:22.818906 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: P 152:154(2) ack 324 win 33304 (DF) [tos 0x10] 10:41:22.819479 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 324:326(2) ack 154 win 24616 (DF) 10:41:22.919168 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 326 win 33304 (DF) [tos 0x10] 10:41:22.919576 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 326:337(11) ack 154 win 24616 (DF) 10:41:23.019171 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 337 win 33304 (DF) [tos 0x10] 10:41:38.614141 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: . ack 154 win 0 10:41:38.614200 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 337 win 33304 (DF) [tos 0x10] 10:41:47.199533 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . 154:155(1) ack 337 win 33304 (DF) [tos 0x10] 10:41:47.297912 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: . ack 155 win 24616 (DF) 10:41:47.297970 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: P 155:162(7) ack 337 win 33304 (DF) [tos 0x10] 10:41:47.298154 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 337:339(2) ack 155 win 24616 (DF) 10:41:47.389540 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 339 win 33304 (DF) [tos 0x10] 10:41:47.390038 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 339:395(56) ack 162 win 24616 (DF) 10:41:47.489541 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 395 win 33304 (DF) [tos 0x10] ------=_NextPart_000_4f35_66b_36e0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 16 10:36:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA68237B400 for ; Tue, 16 Jul 2002 10:36:28 -0700 (PDT) Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1659043E31 for ; Tue, 16 Jul 2002 10:36:28 -0700 (PDT) (envelope-from barney@databus.com) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.5/8.12.5) with ESMTP id g6GHaRBM079873; Tue, 16 Jul 2002 13:36:27 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.5/8.12.5/Submit) id g6GHaQcK079872; Tue, 16 Jul 2002 13:36:26 -0400 (EDT) Date: Tue, 16 Jul 2002 13:36:26 -0400 From: Barney Wolff To: Alex Dyas Cc: net@FreeBSD.ORG, silby@silby.com Subject: Re: BSD / Firewall / 0 window size problem Message-ID: <20020716173626.GA79838@tp.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Wrong - the packet you're interpreting as "not freeze up" is an ack. The next data packet, which is a window probe in both cases, shows about the same delay with both OS's. On Tue, Jul 16, 2002 at 04:24:56PM +0000, Alex Dyas wrote: > Mike Silbersack wrote: > >On Thu, 11 Jul 2002, Alex Dyas wrote: > > > > > >>The only clue I've managed to find as to what is going on is in a tcpdump > >>of > >>the session (attached). The trigger for the lock up seems to be a > >>messages > >>from the Otherbox machine setting the window size to 0 : > >> > >>10:41:38.614141 otherbox.foo.com.telnet > bsdbox.foo.com.2230: . ack 154 > >>win > >>0 > >>10:41:38.614200 bsdbox.foo.com.2230 > otherbox.foo.com.telnet: . ack 337 > >>win > >>33304 (DF) [tos 0x10] > >> > >>I've tried all the following scenarios, none of which exhibit the same > >>problem, which is why I think the problem is with FreeBSD : > >> > >>bsdbox.foo.com -> otherbox.foo.com > >>solarisbox.foo.com -> internal GNAT firewall -> otherbox.foo.com > >>windowsbox.foo.com -> internal GNAT firewall -> otherbox.foo.com > >>linuxbox.foo.com -> internal GNAT firewall -> otherbox.foo.com > > > > > >Could you post a tcpdump of one of the successful connections so that we > >can see how 0 windows are handled there? > > > >Also, have you tcpdump'd at both ends to ensure that we're not actually > >seeing odd sideeffects of packet loss or something? (Some reported > >problems in the past have been due to misbehaving duplex autodetect and > >bad cables.) > > > >Offhand, I can't see what the FreeBSD box is doing wrong, but I'd like > >something else to compare to. > > > >Thanks, > > > >Mike "Silby" Silbersack > > > > I've attached a tcpdump of a Linux machine doing the same thing > (working.txt). > > the same 0 sized window can be seen: > > 17:15:56.094161 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack > 456 win 5840 (DF) [tos 0x10] > 17:16:12.634540 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: . ack 74 > win 0 > 17:16:12.634540 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack > 456 win 5840 (DF) [tos 0x10] > > but the Linux telnet session does not freeze up as the BSD one does. > > Again, any help would be most appreciated. > > Thanks again, > > Alex... > > > _________________________________________________________________ > Join the world?s largest e-mail service with MSN Hotmail. > http://www.hotmail.com > 17:15:52.134070 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: P > 68:70(2) ack 417 win 5840 (DF) [tos > 0x10] > 17:15:52.144070 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P > 417:419(2) ack 70 win 24616 (DF) > 17:15:52.144070 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack > 419 win 5840 (DF) [tos 0x10] > 17:15:52.144070 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P > 419:430(11) ack 70 win 24616 (DF) > 17:15:52.144070 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack > 430 win 5840 (DF) [tos 0x10] > 17:15:53.744107 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: P > 70:72(2) ack 430 win 5840 (DF) [tos > 0x10] > 17:15:53.744107 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P > 430:432(2) ack 72 win 24616 (DF) > 17:15:53.744107 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack > 432 win 5840 (DF) [tos 0x10] > 17:15:53.744107 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P > 432:443(11) ack 72 win 24616 (DF) > 17:15:53.744107 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack > 443 win 5840 (DF) [tos 0x10] > 17:15:56.094161 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: P > 72:74(2) ack 443 win 5840 (DF) [tos > 0x10] > 17:15:56.094161 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P > 443:445(2) ack 74 win 24616 (DF) > 17:15:56.094161 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack > 445 win 5840 (DF) [tos 0x10] > 17:15:56.094161 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P > 445:456(11) ack 74 win 24616 (DF) > 17:15:56.094161 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack > 456 win 5840 (DF) [tos 0x10] > 17:16:12.634540 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: . ack 74 > win 0 > 17:16:12.634540 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack > 456 win 5840 (DF) [tos 0x10] > 17:16:20.034709 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: P > 74:76(2) ack 456 win 5840 (DF) [tos > 0x10] > 17:16:20.034709 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P > 456:458(2) ack 76 win 24616 (DF) > 17:16:20.034709 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack > 458 win 5840 (DF) [tos 0x10] > 17:16:20.034709 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P > 458:469(11) ack 76 win 24616 (DF) > 17:16:20.034709 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack > 469 win 5840 (DF) [tos 0x10] > 17:16:20.234714 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: P > 76:78(2) ack 469 win 5840 (DF) [tos > 0x10] > 17:16:20.234714 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P > 469:471(2) ack 78 win 24616 (DF) > 17:16:20.234714 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack > 471 win 5840 (DF) [tos 0x10] > 17:16:20.234714 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: P > 471:482(11) ack 78 win 24616 (DF) > 17:16:20.234714 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack > 482 win 5840 (DF) [tos 0x10] > > 10:41:22.149761 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: P > 146:148(2) ack 285 win 33304 (DF) > [tos 0x10] > 10:41:22.150396 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P > 285:287(2) ack 148 win 24616 (DF) > 10:41:22.249151 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 287 > win 33304 (DF) [tos 0x10] > 10:41:22.249515 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P > 287:298(11) ack 148 win 24616 (DF) > 10:41:22.349154 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 298 > win 33304 (DF) [tos 0x10] > 10:41:22.380132 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: P > 148:150(2) ack 298 win 33304 (DF) > [tos 0x10] > 10:41:22.380644 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P > 298:300(2) ack 150 win 24616 (DF) > 10:41:22.484269 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 300 > win 33304 (DF) [tos 0x10] > 10:41:22.484920 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P > 300:311(11) ack 150 win 24616 (DF) > 10:41:22.579160 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 311 > win 33304 (DF) [tos 0x10] > 10:41:22.599564 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: P > 150:152(2) ack 311 win 33304 (DF) > [tos 0x10] > 10:41:22.600250 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P > 311:313(2) ack 152 win 24616 (DF) > 10:41:22.699161 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 313 > win 33304 (DF) [tos 0x10] > 10:41:22.699564 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P > 313:324(11) ack 152 win 24616 (DF) > 10:41:22.799162 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 324 > win 33304 (DF) [tos 0x10] > 10:41:22.818906 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: P > 152:154(2) ack 324 win 33304 (DF) > [tos 0x10] > 10:41:22.819479 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P > 324:326(2) ack 154 win 24616 (DF) > 10:41:22.919168 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 326 > win 33304 (DF) [tos 0x10] > 10:41:22.919576 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P > 326:337(11) ack 154 win 24616 (DF) > 10:41:23.019171 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 337 > win 33304 (DF) [tos 0x10] > 10:41:38.614141 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: . ack 154 > win 0 > 10:41:38.614200 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 337 > win 33304 (DF) [tos 0x10] > 10:41:47.199533 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . > 154:155(1) ack 337 win 33304 (DF) > [tos 0x10] > 10:41:47.297912 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: . ack 155 > win 24616 (DF) > 10:41:47.297970 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: P > 155:162(7) ack 337 win 33304 (DF) > [tos 0x10] > 10:41:47.298154 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P > 337:339(2) ack 155 win 24616 (DF) > 10:41:47.389540 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 339 > win 33304 (DF) [tos 0x10] > 10:41:47.390038 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P > 339:395(56) ack 162 win 24616 (DF) > 10:41:47.489541 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 395 > win 33304 (DF) [tos 0x10] > -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 16 12:12: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EA3537B400 for ; Tue, 16 Jul 2002 12:12:04 -0700 (PDT) Received: from isilon.com (isilon.com [65.101.129.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C97143E65 for ; Tue, 16 Jul 2002 12:12:04 -0700 (PDT) (envelope-from bbaumann@isilon.com) Received: from localhost (localhost [127.0.0.1]) by isilon.com (8.12.2/8.11.1) with ESMTP id g6GJC3l3015522 for ; Tue, 16 Jul 2002 12:12:03 -0700 (PDT) (envelope-from bbaumann@isilon.com) Date: Tue, 16 Jul 2002 12:12:03 -0700 (PDT) From: Bill Baumann To: freebsd-net@FreeBSD.ORG Subject: Inconsistency between net/if.c and several ethernet drivers 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 In net/if.c in a couple of places, the ethernet address is needed. This is stored in the arpcom structure. A couple lines of code in if.c require struct arpcom be at the very begining of device softc structures. Nearly all drivers observe this. However, several do not. Sadly, this includes the one I'm working on. net/if.c routines if_findindex() and if_setlladdr() gain access to the ethernet address via the following expression: ((struct arpcom *)ifp->if_softc)->ac_enaddr The above code assumes that the if_softc pointer is equivalent to an struct arpcom pointer. The awi, ray, lnc and pdq drivers have other fields at the beginning of their softc structures. Attempts to set the ethernet address of these devices may cause corruption. Shouldn't access of arpcom be via ifp instead? ((struct arpcom *)ifp)->ac_enaddr For example, if_ethersubr.c uses the following macro: #define IFP2AC(IFP) ((struct arpcom *)IFP) It looked to me like the other code in net, like if_ethersubr.c use ifp rather than if_softc to find struct arpcom. Bug? - Bill Baumann (bbaumann@isilon.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 16 15:52: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6367737B400 for ; Tue, 16 Jul 2002 15:51:59 -0700 (PDT) Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 808F943E3B for ; Tue, 16 Jul 2002 15:51:58 -0700 (PDT) (envelope-from barney@databus.com) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.5/8.12.5) with ESMTP id g6GMpvBM082374 for ; Tue, 16 Jul 2002 18:51:57 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.5/8.12.5/Submit) id g6GMpvqD082373 for net@freebsd.org; Tue, 16 Jul 2002 18:51:57 -0400 (EDT) Date: Tue, 16 Jul 2002 18:51:57 -0400 From: Barney Wolff To: net@freebsd.org Subject: Re: ARP risks Message-ID: <20020716225157.GA82341@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Since it came up on this list... Barney ----- Forwarded message from Fr?d?ric Raynal ----- Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Date: Tue, 16 Jul 2002 21:50:35 +0200 From: Fr?d?ric Raynal To: alaric@alaricsecurity.com Cc: bugtraq@securityfocus.com, Fr?d?ric Raynal , Eric Detoisien , Cedric Blancher Subject: Re: Sniffable Switch Project User-Agent: Mutt/1.2.5.1i In-Reply-To: <200207161037.g6GAbGJ19089@helium.can-host.com>; from alaric@alaricsecurity.com on Tue, Jul 16, 2002 at 06:37:16AM -0400 X-Operating-System: Windoz 3.11 (almost) X-URL: http://minimum.inria.fr/~raynal Hello, On Tue, Jul 16, 2002 at 06:37:16AM -0400, alaric@alaricsecurity.com wrote: > > If you decided to participate, please include all information about the > switch(es) you tested (e.g. manufacture, model, managed or unmanaged, how many > ports, firmware/OS version, etc.). Please also include what you tested for > - ARP spoofing, MAC flooding, MAC duplicating, or the like - and what the > results were. For an article recently published in a French magazine on security, I also work on something very similar. Our (our = the 3 authors) goal was to detail all what you can do with the protocol ARP. Of course, sniffing is one thing, but there are many more. Another not so well known issue about ARP is the handling of messages according to the OS. Some of them (some Windows, IOS 12, OpenBSD 3.0) create new entries in their cache when they receive an reply (even unsolicited) , while others do not (Linux for instance). Note that the creation is the correct behavior according to the RFC. So, there are in fact many thing to mention with ARP : - switches that fail open like hubs when they are flooded - OS that are RFC compliant - and so on for various attacks... A short summary of the article is available on http://www.arp-sk.org. We show that ARP is not only efficient for sniffing, and that you can have really fun with that protocol. arp-sk is a Swiss army knife for the handling of ARP messages based on the latest libnet-1.1.0beta. Among cool features, you can notice : - complete control of all addresses either on Ethernet layer or ARP itself - target assignment is made at Ethernet layer, but either with target's MAC or IP - complete control of the randomization of the 6 addresses (2 with Ethernet, 4 with ARP), i.e. you can set some addresses and randomize those you want - control the period of time for sending packets (from very slow to fury mode), and randomize the interval Even if it is still under development, it is already functional. Lastly, note that ARP messages can be used to detect promiscuous cards on a network. To check a target, the trick is to send an ARP query with all valid information in the ARP message, but with a fake Ethernet destination address. Ethernet dst FF:FF:FF:FF:FF:FE Ethernet src ARP mode Who-has ? ARP dst eth 00:00:00:00:00:00 ARP dst IP ARP src eth ARP src IP If the target answers, it is very likely that it is in promiscuous mode. I've also tested that solution with icmp echo-request (target was a Linux-2.4), but that did not success. I had no time to investigate any further but it used to work with kernel 2.2. I had no time to check if this behavior came from the change of the kernel or from something else. Regards -- Frederic RAYNAL, Ph.D. http://minimum.inria.fr/~raynal Chief Editor of M.I.S.C. Multi-Systems & Internet Security Cookbook ----- End forwarded message ----- -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 16 17:11:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB03F37B400 for ; Tue, 16 Jul 2002 17:11:21 -0700 (PDT) Received: from artemis.drwilco.net (artemis.drwilco.net [209.162.234.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1D8243E3B for ; Tue, 16 Jul 2002 17:11:20 -0700 (PDT) (envelope-from drwilco@quakecon.org) Received: from ceres.quakecon.org (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.12.3/8.12.3) with ESMTP id g6H09nOG054384 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 16 Jul 2002 20:09:52 -0400 (EDT) (envelope-from drwilco@quakecon.org) Message-Id: <5.1.0.14.0.20020717020039.01f1d8d8@mail.drwilco.net> X-Sender: drwilco@quakecon.org@mail.quakecon.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 17 Jul 2002 02:13:46 +0200 To: freebsd-net@freebsd.org From: "Rogier R. Mulhuijzen" Subject: UDP broadcasts and delivery to sockets Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, I'm working with a few others to get everything in gear for the network at QuakeCon (www.quakecon.org). One part of that event is a huge Bring Your Own Computer LAN with a 1250 PC capacity, for which we will provide a number of servers running a ton of gameservers. One problem we've had with gameservers in the past is that when we bind them to a specific IP on the box they stop responding to broadcasts that the clients use for finding servers on the local LAN. The crux of the problem is that the dedicated server only binds one UDP socket and when binding to a specific IP it doesn't open a INADDR_ANY socket as well to catch the broadcasts (something I'll be talking about with the idsoftware people). The solution to that could be to use different ports for each daemon, since the clients scan a number of ports, but that had strange effects when using multiple NICs and it limits the amount of daemons per box to either 8 or 4. Furthermore if the ports aren't consecutive there's more strange sideeffects. What we did however is dive into the FreeBSD kernel and hack up the UDP handling. I added a sysctl that controls whether or not broadcast packets are delivered to all sockets on the port the datagram was sent to regardless of what address the socket is bound to. I have a patch that applies cleanly to -STABLE, but it's still a little rough in the sense that the behaviour is now default, and multicast packets get delivered too. But that's not really important for us right now. The reason I am sending this email to the list is that I was wondering if there's any interest in merging this sysctl into the main source tree. Because this behaviour is mentioned in comments, but not coded for since some applications might have problems with it. If there's interest in this I'll clean the patch up some more, if not I'll just drop it and get on with the rest of my tasks. For those interested regardless, the patch can be found here: http://www.bsdchicks.com/patches/udp_wide_broadcast.patch Greetings, DocWilco - QuakeCon Network Director To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 16 18:28:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD10F37B400 for ; Tue, 16 Jul 2002 18:28:49 -0700 (PDT) Received: from gateway.posi.net (adsl-63-201-92-2.dsl.snfc21.pacbell.net [63.201.92.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 371E143E3B for ; Tue, 16 Jul 2002 18:28:49 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.3/8.12.3) with ESMTP id g6H1SkcT004773; Tue, 16 Jul 2002 18:28:47 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Tue, 16 Jul 2002 18:28:46 -0700 (PDT) From: Kelly Yancey To: Bill Baumann Cc: freebsd-net@FreeBSD.ORG Subject: Re: Inconsistency between net/if.c and several ethernet drivers In-Reply-To: Message-ID: <20020716180110.E4709-100000@gateway.posi.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 16 Jul 2002, Bill Baumann wrote: > > In net/if.c in a couple of places, the ethernet address is needed. This > is stored in the arpcom structure. A couple lines of code in if.c require > struct arpcom be at the very begining of device softc structures. Nearly > all drivers observe this. However, several do not. Sadly, this includes > the one I'm working on. > > net/if.c routines if_findindex() and if_setlladdr() gain access to the > ethernet address via the following expression: > > ((struct arpcom *)ifp->if_softc)->ac_enaddr > > The above code assumes that the if_softc pointer is equivalent to an > struct arpcom pointer. The awi, ray, lnc and pdq drivers have other > fields at the beginning of their softc structures. Attempts to set the > ethernet address of these devices may cause corruption. > > > Shouldn't access of arpcom be via ifp instead? > > ((struct arpcom *)ifp)->ac_enaddr > > > For example, if_ethersubr.c uses the following macro: > #define IFP2AC(IFP) ((struct arpcom *)IFP) > > It looked to me like the other code in net, like if_ethersubr.c use ifp > rather than if_softc to find struct arpcom. > > Bug? > Design. :) See page 77 of Stevens' TCP/IP Illustrated Volume 2. By putting the structures at the beginning of the softc, the networking code can access them without any explicit knowledge of the driver's softc itself (i.e. it can use the softc as an opaque encapsulated version of either the arpcom or ifnet structures). The bug, then, would seem to be in the network drivers that don't follow this convention. But I'm not familiar with those particular drivers, so I cannot comment on them; perhaps they employ some cleverness to circumvent the requirement (by why?). Anyway, it should be obvious that accessing the arpcom structure via casting from the ifnet structure or the softc structure are supposed to have the same results, so the code your quoted above is fine. Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} "The worst sin towards our fellow creatures is not to hate them, but to be indifferent to them; that's the essence of inhumanity." -- George Bernard Shaw To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 16 21:56: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3347337B400 for ; Tue, 16 Jul 2002 21:56:06 -0700 (PDT) Received: from patrocles.silby.com (d151.as12.nwbl0.wi.voyager.net [169.207.136.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51D5543E4A for ; Tue, 16 Jul 2002 21:56:04 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g6H50Kcv079820; Wed, 17 Jul 2002 00:00:20 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.5/8.12.5/Submit) with ESMTP id g6H50IgY079816; Wed, 17 Jul 2002 00:00:19 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Wed, 17 Jul 2002 00:00:18 -0500 (CDT) From: Mike Silbersack To: Alex Dyas Cc: net@freebsd.org Subject: Re: BSD / Firewall / 0 window size problem In-Reply-To: Message-ID: <20020716235818.K79793-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 16 Jul 2002, Alex Dyas wrote: > I've attached a tcpdump of a Linux machine doing the same thing > (working.txt). > > the same 0 sized window can be seen: > > 17:15:56.094161 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack 456 > win 5840 (DF) [tos 0x10] > 17:16:12.634540 solarisbox.foo.com.telnet > linuxbox.foo.com.3479: . ack 74 > win 0 > 17:16:12.634540 linuxbox.foo.com.3479 > solarisbox.foo.com.telnet: . ack 456 > win 5840 (DF) [tos 0x10] > > but the Linux telnet session does not freeze up as the BSD one does. > > Again, any help would be most appreciated. > > Thanks again, > > Alex... As Barney noted, the behavior of both OSes looks very similar. Have you run tcpdump on the solaris box at the same time? That win 0 packet looks _really_ suspicious to me; it doesn't share the DF bit or timestamps of the other packets in the stream. On top of that, I see no reason why a win 0 should be sent when the previous window was ~24K in size. Is it possible that the NAT box is adding it in? Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 17 3:49:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E56937B400 for ; Wed, 17 Jul 2002 03:49:43 -0700 (PDT) Received: from web14605.mail.yahoo.com (web14605.mail.yahoo.com [216.136.224.85]) by mx1.FreeBSD.org (Postfix) with SMTP id 1B2DC43E3B for ; Wed, 17 Jul 2002 03:49:43 -0700 (PDT) (envelope-from shubha_mr@yahoo.com) Message-ID: <20020717104943.57136.qmail@web14605.mail.yahoo.com> Received: from [12.151.32.25] by web14605.mail.yahoo.com via HTTP; Wed, 17 Jul 2002 11:49:43 BST Date: Wed, 17 Jul 2002 11:49:43 +0100 (BST) From: =?iso-8859-1?q?shubha=20mr?= Subject: IP Fragmentation To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I am writing a gigabit ethernet driver for one of the NICs.My hardware is capable of computing the checksum and hence I am enabling per-packet handling of TCP/IP/UDP checksum offload in transmit side.I would like to know if there is a way by which I can tell the upperguy that I will not be able to compute the tcp checksum for the fragmented packets.That is I want to indicate that checksum offload can be offloaded only for the non fragmented and hence complete packets only. A quick reply will be greatly and thankfully appreciated. Thanks and Regards shubha __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 17 6:26:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73E4837B400 for ; Wed, 17 Jul 2002 06:26:10 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A6AF43E4A for ; Wed, 17 Jul 2002 06:26:09 -0700 (PDT) (envelope-from marks@ripe.net) Received: from laptop.6bone.nl (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g6HDPst23822; Wed, 17 Jul 2002 15:25:54 +0200 Received: (nullmailer pid 71802 invoked by uid 1000); Wed, 17 Jul 2002 13:25:51 -0000 Date: Wed, 17 Jul 2002 15:25:51 +0200 From: Mark Santcroos To: net@freebsd.org Cc: Joe Pellegrino Subject: ip options on udp sockets Message-ID: <20020717132551.GF485@laptop.6bone.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.99i X-Handles: MS6-6BONE, MS18417-RIPE X-RIPE-NCC-SpamStatus: Found to be clean X-RIPE-NCC-SpamCheck: SpamAssassin (score=-100, required 10, USER_IN_WHITELIST) 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 Why are IP options not passed to userland on a udp socket? (and on all other transport protocols for that matter) We created such an implementation by just returning it in the ancillary data control message. (Only for IP timestamps which we needed but this could be easily done for all IP options) If there is any good (maybe historic) reason why this is not done and why it should not be done I would like to hear that. We also created a kernel option to threat the IP timestamp as microseconds instead of milliseconds to make the measurements more useful. If there is interest we are more than happy to submit the code to the project. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 17 7:24:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 684EB37B400; Wed, 17 Jul 2002 07:24:43 -0700 (PDT) Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE26B43E58; Wed, 17 Jul 2002 07:24:41 -0700 (PDT) (envelope-from c.prevotaux@hexanet.fr) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.3/8.12.3) with SMTP id g6HEOcCE033060; Wed, 17 Jul 2002 16:24:38 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Wed, 17 Jul 2002 16:24:38 +0200 From: Christophe Prevotaux To: net@freebsd.org, atm@freebsd.org Subject: lge0: gigabit link up[lge locks up] Message-Id: <20020717162438.0a9d3acc.c.prevotaux@hexanet.fr> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi ============= Hardware configuration ============ I am running : - FreeBSD 4.6 Release SMP The machine contains the following hardware - ASUS CU4VX Motherboard Dual Processor (with 1 onboard fxp ethernet interface) - FORERUNNER PCA200E ATM Adapter (hfa) - DLINK 500SX Gigabit Fiber SX Ethernet board (lge) note: Each network card has its own IRQ (if that matters) ============ The problem ========================== I have posted already about this but I keep getting this error message in my /var/log/messages 'lge0: gigabit link up' After getting many such messages my card will hang and the machine will not be accessible thru that interface (lge0) most of the time the machine is still accessible thru the 'fxp0' ethernet interface. At some other time the pca200e ATM interface will hang as well ================================================= Would anyone know how to fix this ? -- -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 17 7:59: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D041837B401 for ; Wed, 17 Jul 2002 07:59:07 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AF6943E31 for ; Wed, 17 Jul 2002 07:59:07 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 67374AE1CA; Wed, 17 Jul 2002 07:59:07 -0700 (PDT) Date: Wed, 17 Jul 2002 07:59:07 -0700 From: Alfred Perlstein To: shubha mr Cc: net@freebsd.org Subject: Re: IP Fragmentation Message-ID: <20020717145907.GY77219@elvis.mu.org> References: <20020717104943.57136.qmail@web14605.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020717104943.57136.qmail@web14605.mail.yahoo.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * shubha mr [020717 03:50] wrote: > Hi, > I am writing a gigabit ethernet driver for one of the > NICs.My hardware is capable of computing the checksum > and hence I am enabling per-packet handling of > TCP/IP/UDP checksum offload in transmit side.I would > like to know if there is a way by which I can tell the > upperguy that I will not be able to compute the tcp > checksum for the fragmented packets.That is I want to > indicate that checksum offload can be offloaded only > for the non fragmented and hence complete packets > only. From mbuf.h: #define CSUM_IP 0x0001 /* will csum IP */ #define CSUM_TCP 0x0002 /* will csum TCP */ #define CSUM_UDP 0x0004 /* will csum UDP */ #define CSUM_IP_FRAGS 0x0008 /* will csum IP fragments */ #define CSUM_FRAGMENT 0x0010 /* will do IP fragmentation */ Just use the first 3, have a look at the if_bge.c driver for an example. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 17 10:58:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E13D837B400 for ; Wed, 17 Jul 2002 10:58:17 -0700 (PDT) Received: from isilon.com (isilon.com [65.101.129.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46BF043E4A for ; Wed, 17 Jul 2002 10:58:17 -0700 (PDT) (envelope-from bbaumann@isilon.com) Received: from localhost (localhost [127.0.0.1]) by isilon.com (8.12.2/8.11.1) with ESMTP id g6HHwCl3064363; Wed, 17 Jul 2002 10:58:12 -0700 (PDT) (envelope-from bbaumann@isilon.com) Date: Wed, 17 Jul 2002 10:58:12 -0700 (PDT) From: Bill Baumann To: Kelly Yancey Cc: freebsd-net@FreeBSD.ORG Subject: Re: Inconsistency between net/if.c and several ethernet drivers In-Reply-To: <20020716180110.E4709-100000@gateway.posi.net> 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 Pointers to interface and arpcom are clearly equivalent as arpcom contains the interface structure. The one definition for the combined structure makes it very safe. However, there are many definitions of the softc structure. Requiring arpcom to be at the beginning of all softc structs requires every device driver writer to either track this obscure detail, or risk obscure bugs. Why bother with a if_softc field when the interface and softc pointer are supposed to be the same? Also, the very old Lance driver (lnc) has this problem. It makes me wonder how true we are to TCP/IP Illustrated... So while this wouldn't really be a bug fix, perhaps we should do my suggested change anyway to avoid modifying the drivers. Regards, Bill Baumann On Tue, 16 Jul 2002, Kelly Yancey wrote: > On Tue, 16 Jul 2002, Bill Baumann wrote: > > > > > In net/if.c in a couple of places, the ethernet address is needed. This > > is stored in the arpcom structure. A couple lines of code in if.c require > > struct arpcom be at the very begining of device softc structures. Nearly > > all drivers observe this. However, several do not. Sadly, this includes > > the one I'm working on. > > > > net/if.c routines if_findindex() and if_setlladdr() gain access to the > > ethernet address via the following expression: > > > > ((struct arpcom *)ifp->if_softc)->ac_enaddr > > > > The above code assumes that the if_softc pointer is equivalent to an > > struct arpcom pointer. The awi, ray, lnc and pdq drivers have other > > fields at the beginning of their softc structures. Attempts to set the > > ethernet address of these devices may cause corruption. > > > > > > Shouldn't access of arpcom be via ifp instead? > > > > ((struct arpcom *)ifp)->ac_enaddr > > > > > > For example, if_ethersubr.c uses the following macro: > > #define IFP2AC(IFP) ((struct arpcom *)IFP) > > > > It looked to me like the other code in net, like if_ethersubr.c use ifp > > rather than if_softc to find struct arpcom. > > > > Bug? > > > > Design. :) See page 77 of Stevens' TCP/IP Illustrated Volume 2. By putting > the structures at the beginning of the softc, the networking code can access > them without any explicit knowledge of the driver's softc itself (i.e. it can > use the softc as an opaque encapsulated version of either the arpcom or ifnet > structures). The bug, then, would seem to be in the network drivers that > don't follow this convention. But I'm not familiar with those particular > drivers, so I cannot comment on them; perhaps they employ some cleverness to > circumvent the requirement (by why?). Anyway, it should be obvious that > accessing the arpcom structure via casting from the ifnet structure or the > softc structure are supposed to have the same results, so the code your quoted > above is fine. > > Kelly > > -- > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} > "The worst sin towards our fellow creatures is not to hate them, but to be > indifferent to them; that's the essence of inhumanity." > -- George Bernard Shaw > > > > 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 Jul 17 11:25:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6CDA37B400 for ; Wed, 17 Jul 2002 11:25:33 -0700 (PDT) Received: from out005.verizon.net (out005pub.verizon.net [206.46.170.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D83D43E75 for ; Wed, 17 Jul 2002 11:25:32 -0700 (PDT) (envelope-from jimmcgra@bellatlantic.net) Received: from Default ([141.154.238.54]) by out005.verizon.net (InterMail vM.5.01.05.05 201-253-122-126-105-20020426) with SMTP id <20020717182443.IIPC20552.out005.verizon.net@Default>; Wed, 17 Jul 2002 13:24:43 -0500 From: "Jim McGrath" To: "Kelly Yancey" , "Bill Baumann" Cc: "Jim McGrath" , Subject: RE: Inconsistency between net/if.c and several ethernet drivers Date: Wed, 17 Jul 2002 14:25:29 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 Any driver that uses miibus_attach() is broken if struct arpcom is not at the beginning of the softc structure. There was some discussion of this more than a year ago when this bug showed up in the wx driver. Jim > -----Original Message----- > From: owner-freebsd-net@FreeBSD.ORG > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Bill Baumann > Sent: Wednesday, July 17, 2002 1:58 PM > To: Kelly Yancey > Cc: freebsd-net@FreeBSD.ORG > Subject: Re: Inconsistency between net/if.c and several ethernet drivers > > > > Pointers to interface and arpcom are clearly equivalent as arpcom contains > the interface structure. The one definition for the combined structure > makes it very safe. However, there are many definitions of the softc > structure. Requiring arpcom to be at the beginning of all softc structs > requires every device driver writer to either track this obscure detail, > or risk obscure bugs. > > > Why bother with a if_softc field when the interface and softc pointer are > supposed to be the same? Also, the very old Lance driver (lnc) has this > problem. It makes me wonder how true we are to TCP/IP Illustrated... > > So while this wouldn't really be a bug fix, perhaps we should do my > suggested change anyway to avoid modifying the drivers. > > Regards, > Bill Baumann > > > On Tue, 16 Jul 2002, Kelly Yancey wrote: > > > On Tue, 16 Jul 2002, Bill Baumann wrote: > > > > > > > > In net/if.c in a couple of places, the ethernet address is > needed. This > > > is stored in the arpcom structure. A couple lines of code in > if.c require > > > struct arpcom be at the very begining of device softc > structures. Nearly > > > all drivers observe this. However, several do not. Sadly, > this includes > > > the one I'm working on. > > > > > > net/if.c routines if_findindex() and if_setlladdr() gain access to the > > > ethernet address via the following expression: > > > > > > ((struct arpcom *)ifp->if_softc)->ac_enaddr > > > > > > The above code assumes that the if_softc pointer is equivalent to an > > > struct arpcom pointer. The awi, ray, lnc and pdq drivers have other > > > fields at the beginning of their softc structures. Attempts > to set the > > > ethernet address of these devices may cause corruption. > > > > > > > > > Shouldn't access of arpcom be via ifp instead? > > > > > > ((struct arpcom *)ifp)->ac_enaddr > > > > > > > > > For example, if_ethersubr.c uses the following macro: > > > #define IFP2AC(IFP) ((struct arpcom *)IFP) > > > > > > It looked to me like the other code in net, like > if_ethersubr.c use ifp > > > rather than if_softc to find struct arpcom. > > > > > > Bug? > > > > > > > Design. :) See page 77 of Stevens' TCP/IP Illustrated Volume > 2. By putting > > the structures at the beginning of the softc, the networking > code can access > > them without any explicit knowledge of the driver's softc > itself (i.e. it can > > use the softc as an opaque encapsulated version of either the > arpcom or ifnet > > structures). The bug, then, would seem to be in the network > drivers that > > don't follow this convention. But I'm not familiar with those > particular > > drivers, so I cannot comment on them; perhaps they employ some > cleverness to > > circumvent the requirement (by why?). Anyway, it should be obvious that > > accessing the arpcom structure via casting from the ifnet > structure or the > > softc structure are supposed to have the same results, so the > code your quoted > > above is fine. > > > > Kelly > > > > -- > > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} > > "The worst sin towards our fellow creatures is not to hate > them, but to be > > indifferent to them; that's the essence of inhumanity." > > -- George Bernard Shaw > > > > > > > > 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 Jul 17 11:51:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FCE137B400 for ; Wed, 17 Jul 2002 11:51:11 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id D41E443E9E for ; Wed, 17 Jul 2002 11:51:10 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.3) with ESMTP id g6HICnRC097765; Wed, 17 Jul 2002 14:12:49 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.3/Submit) id g6HICmm8097762; Wed, 17 Jul 2002 14:12:48 -0400 (EDT) (envelope-from wollman) Date: Wed, 17 Jul 2002 14:12:48 -0400 (EDT) From: Garrett Wollman Message-Id: <200207171812.g6HICmm8097762@khavrinen.lcs.mit.edu> To: Bill Baumann Cc: freebsd-net@FreeBSD.ORG Subject: Re: Inconsistency between net/if.c and several ethernet drivers In-Reply-To: References: <20020716180110.E4709-100000@gateway.posi.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Why bother with a if_softc field when the interface and softc pointer are > supposed to be the same? Also, the very old Lance driver (lnc) has this > problem. It makes me wonder how true we are to TCP/IP Illustrated... if_softc was added to pacify those who either didn't understand the C language, or thought they had a good reason why the softc structure had to begin with some other structure than ifnet. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 17 12:28:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 102B837B400 for ; Wed, 17 Jul 2002 12:28:47 -0700 (PDT) Received: from isilon.com (isilon.com [65.101.129.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F11043E31 for ; Wed, 17 Jul 2002 12:28:46 -0700 (PDT) (envelope-from bbaumann@isilon.com) Received: from localhost (localhost [127.0.0.1]) by isilon.com (8.12.2/8.11.1) with ESMTP id g6HJSjl3069785 for ; Wed, 17 Jul 2002 12:28:45 -0700 (PDT) (envelope-from bbaumann@isilon.com) Date: Wed, 17 Jul 2002 12:28:45 -0700 (PDT) From: Bill Baumann To: freebsd-net@FreeBSD.ORG Subject: RE: Inconsistency between net/if.c and several ethernet drivers 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 Fortunately, none of the offending drivers (awi,lnc,pdq,ray) use mii. On Wed, 17 Jul 2002, Jim McGrath wrote: > Any driver that uses miibus_attach() is broken if struct arpcom is not at > the beginning of the softc structure. There was some discussion of this > more than a year ago when this bug showed up in the wx driver. > > Jim > > > -----Original Message----- > > From: owner-freebsd-net@FreeBSD.ORG > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Bill Baumann > > Sent: Wednesday, July 17, 2002 1:58 PM > > To: Kelly Yancey > > Cc: freebsd-net@FreeBSD.ORG > > Subject: Re: Inconsistency between net/if.c and several ethernet drivers > > > > > > > > Pointers to interface and arpcom are clearly equivalent as arpcom contains > > the interface structure. The one definition for the combined structure > > makes it very safe. However, there are many definitions of the softc > > structure. Requiring arpcom to be at the beginning of all softc structs > > requires every device driver writer to either track this obscure detail, > > or risk obscure bugs. > > > > > > Why bother with a if_softc field when the interface and softc pointer are > > supposed to be the same? Also, the very old Lance driver (lnc) has this > > problem. It makes me wonder how true we are to TCP/IP Illustrated... > > > > So while this wouldn't really be a bug fix, perhaps we should do my > > suggested change anyway to avoid modifying the drivers. > > > > Regards, > > Bill Baumann > > > > > > On Tue, 16 Jul 2002, Kelly Yancey wrote: > > > > > On Tue, 16 Jul 2002, Bill Baumann wrote: > > > > > > > > > > > In net/if.c in a couple of places, the ethernet address is > > needed. This > > > > is stored in the arpcom structure. A couple lines of code in > > if.c require > > > > struct arpcom be at the very begining of device softc > > structures. Nearly > > > > all drivers observe this. However, several do not. Sadly, > > this includes > > > > the one I'm working on. > > > > > > > > net/if.c routines if_findindex() and if_setlladdr() gain access to the > > > > ethernet address via the following expression: > > > > > > > > ((struct arpcom *)ifp->if_softc)->ac_enaddr > > > > > > > > The above code assumes that the if_softc pointer is equivalent to an > > > > struct arpcom pointer. The awi, ray, lnc and pdq drivers have other > > > > fields at the beginning of their softc structures. Attempts > > to set the > > > > ethernet address of these devices may cause corruption. > > > > > > > > > > > > Shouldn't access of arpcom be via ifp instead? > > > > > > > > ((struct arpcom *)ifp)->ac_enaddr > > > > > > > > > > > > For example, if_ethersubr.c uses the following macro: > > > > #define IFP2AC(IFP) ((struct arpcom *)IFP) > > > > > > > > It looked to me like the other code in net, like > > if_ethersubr.c use ifp > > > > rather than if_softc to find struct arpcom. > > > > > > > > Bug? > > > > > > > > > > Design. :) See page 77 of Stevens' TCP/IP Illustrated Volume > > 2. By putting > > > the structures at the beginning of the softc, the networking > > code can access > > > them without any explicit knowledge of the driver's softc > > itself (i.e. it can > > > use the softc as an opaque encapsulated version of either the > > arpcom or ifnet > > > structures). The bug, then, would seem to be in the network > > drivers that > > > don't follow this convention. But I'm not familiar with those > > particular > > > drivers, so I cannot comment on them; perhaps they employ some > > cleverness to > > > circumvent the requirement (by why?). Anyway, it should be obvious that > > > accessing the arpcom structure via casting from the ifnet > > structure or the > > > softc structure are supposed to have the same results, so the > > code your quoted > > > above is fine. > > > > > > Kelly > > > > > > -- > > > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} > > > "The worst sin towards our fellow creatures is not to hate > > them, but to be > > > indifferent to them; that's the essence of inhumanity." > > > -- George Bernard Shaw > > > > > > > > > > > > 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 Thu Jul 18 3: 0:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09C2A37B400 for ; Thu, 18 Jul 2002 03:00:21 -0700 (PDT) Received: from mail4.home.nl (mail4.home.nl [213.51.129.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 274A843E58 for ; Thu, 18 Jul 2002 03:00:20 -0700 (PDT) (envelope-from nascar24@home.nl) Received: from winxp ([217.120.146.224]) by mail4.home.nl (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20020718100149.ERAG25389.mail4.home.nl@winxp> for ; Thu, 18 Jul 2002 12:01:49 +0200 Message-ID: <11c801c22e41$edc7c740$0200a8c0@winxp> From: "nascar24" To: Subject: FXP behind firewall Date: Thu, 18 Jul 2002 12:00:21 +0200 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 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 have enabled AllowForeighAddress is proftpd.conf but still, people can't fxp to my ftp site. I think it has something to do with my IPFW rules. Here are the rules. # allow loopback traffic add 100 allow ip from any to any via lo0 # protect loopback address add 200 deny ip from 127.0.0.1 to any add 249 deny ip from any to 127.0.0.1 # block spoofs add 400 deny log ip from me to any in via ed0 # enable NATD add 425 divert 8668 ip from any to any via ed0 # check dynamic rules add 450 check-state # make dynamic entries for all outgoing traffic add 500 allow tcp from me to any 1024-65535,21,22,25,80,110,123,443,666 keep-state out via ed0 add 550 allow udp from me to any 21,22,80,53,68,123 keep-state out via ed0 # services we offer to the world add 600 allow log tcp from any to me 1024-65535,22,5067,5617,8472,10000 keep-state in # pass ICMP add 700 allow icmp from me to any out add 750 allow icmp from any to me in # pass everything on private LAN add 800 allow all from 192.168.0.0/16 to any add 850 allow all from any to 192.168.0.0/16 # log rejects that have fallen through add 65000 deny log ip from any to any And this is the message that a user gets when he tries to FXP something from a ftp to mine: 227 Entering Passive Mode (IP_ADDRESS,4,190). PORT IP_ADDRESS,4,190 200 Port command successful. STOR TEST.mp3 150 Opening data connection for TEST.mp3. RETR TEST.mp3 425 Cannot open data connection (10060). ABOR I hope some one here can help. FTP is not a great protocol for firewalls! Gr. Marcel. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 3:31:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EEE237B400 for ; Thu, 18 Jul 2002 03:31:26 -0700 (PDT) Received: from mail.oprit7.nl (mail.oprit7.nl [212.136.135.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id D47CB43E5E for ; Thu, 18 Jul 2002 03:31:20 -0700 (PDT) (envelope-from eelco@2complex.nl) Received: from CPQ32702973114 (XPMachine.oprit7.nl [212.136.135.182]) by mail.oprit7.nl (8.11.6/8.11.6) with SMTP id g6IAaBK33459; Thu, 18 Jul 2002 12:36:11 +0200 (CEST) (envelope-from eelco@2complex.nl) Message-ID: <00c601c22e46$405fe510$b68788d4@CPQ32702973114> From: "Eelco Bode" To: "nascar24" Cc: References: <11c801c22e41$edc7c740$0200a8c0@winxp> Subject: Re: FXP behind firewall Date: Thu, 18 Jul 2002 12:27:39 +0200 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 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 ----- Original Message ----- From: "nascar24" To: Sent: Thursday, July 18, 2002 12:00 PM Subject: FXP behind firewall > Hello, > > I have enabled AllowForeighAddress is proftpd.conf but still, people can't > fxp to my ftp site. > > I think it has something to do with my IPFW rules. Here are the rules. > > # allow loopback traffic > add 100 allow ip from any to any via lo0 > > # protect loopback address > add 200 deny ip from 127.0.0.1 to any > add 249 deny ip from any to 127.0.0.1 > > # block spoofs > add 400 deny log ip from me to any in via ed0 > > # enable NATD > add 425 divert 8668 ip from any to any via ed0 > > # check dynamic rules > add 450 check-state > > # make dynamic entries for all outgoing traffic > add 500 allow tcp from me to any 1024-65535,21,22,25,80,110,123,443,666 > keep-state out via ed0 > add 550 allow udp from me to any 21,22,80,53,68,123 keep-state out via ed0 > > # services we offer to the world > add 600 allow log tcp from any to me 1024-65535,22,5067,5617,8472,10000 > keep-state in > > # pass ICMP > add 700 allow icmp from me to any out > add 750 allow icmp from any to me in > > # pass everything on private LAN > add 800 allow all from 192.168.0.0/16 to any > add 850 allow all from any to 192.168.0.0/16 > > # log rejects that have fallen through > add 65000 deny log ip from any to any > > And this is the message that a user gets when he tries to FXP something from > a ftp to mine: > > 227 Entering Passive Mode (IP_ADDRESS,4,190). > PORT IP_ADDRESS,4,190 > 200 Port command successful. > STOR TEST.mp3 > 150 Opening data connection for TEST.mp3. > RETR TEST.mp3 > 425 Cannot open data connection (10060). > ABOR > > I hope some one here can help. FTP is not a great protocol for firewalls! > > Gr. > > Marcel. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > Hi Marcel To have someone access your ftp server, you will also need to allow traffic to flow over port 20. Ftp uses port 21 tcp/udp for its control session and port 20 tcp/udp for its data session. If you'll add port 20 into rule 500 and 550 it's probably ok. Regards Eelco Bode To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 4: 3:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4152137B400; Thu, 18 Jul 2002 04:03:36 -0700 (PDT) Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 053D943E5E; Thu, 18 Jul 2002 04:03:35 -0700 (PDT) (envelope-from wosch@cs.tu-berlin.de) Received: from freno.cs.tu-berlin.de (wosch@freno.cs.tu-berlin.de [130.149.17.167]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id MAA23511; Thu, 18 Jul 2002 12:59:34 +0200 (MET DST) Received: (from wosch@localhost) by freno.cs.tu-berlin.de (8.9.3/8.9.3) id MAA00123; Thu, 18 Jul 2002 12:59:34 +0200 (MET DST) Date: Thu, 18 Jul 2002 12:59:34 +0200 From: Wolfram Schneider To: Sulaiman Khan Cc: wosch@freebsd.org, freebsd-net@freebsd.org Subject: Re: BSD Sockets API Message-ID: <20020718125933.B63@freno.cs.tu-berlin.de> References: <20020718103746.19792.qmail@web13106.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20020718103746.19792.qmail@web13106.mail.yahoo.com>; from msulaimankhan@yahoo.com on Thu, Jul 18, 2002 at 03:37:46AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2002-07-18 03:37:46 -0700, Sulaiman Khan wrote: > > Hello, > > where can I download the complete API for BSD Sockets. I am currently working to make an application compatiable with Berkeley sockets. So can you please guide me how I can obtain the complete API > > Thanks > > Sulaiman Khan Hi, please read: http://www.freebsd.org/cgi/man.cgi?socket http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/sockets.html -Wolfram -- Wolfram Schneider http://wolfram.schneider.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 7:27:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFAB137B400 for ; Thu, 18 Jul 2002 07:27:09 -0700 (PDT) Received: from hotmail.com (f44.law9.hotmail.com [64.4.9.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79EA843E5E for ; Thu, 18 Jul 2002 07:27:09 -0700 (PDT) (envelope-from freebsdfan@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Jul 2002 07:27:09 -0700 Received: from 68.4.57.222 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 18 Jul 2002 14:27:08 GMT X-Originating-IP: [68.4.57.222] From: "Chuck T." To: net@FreeBSD.ORG Subject: programatically list all local IP addresses ? Date: Thu, 18 Jul 2002 07:27:08 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jul 2002 14:27:09.0281 (UTC) FILETIME=[330D3D10:01C22E67] 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'm sure this is a FAQ, but I sure can't find the answer. I've tried the usually suggested gethostname()/gethostbyname() approach, but that only returns the *first* match in /etc/hosts. In one case that was 127.0.0.1. Clearly this was a case where /etc/host.conf gave priority to the host file. I don't want to call gethostent() because (if I understand the man page correctly) that would limit me entries /etc/hosts ignoring DNS. I guess I could do a gethostname()/gethostbyname() and then if I fail to find a usable (non-rfc1918) address gethosten(). Is there a better way? Also is listing 127.0.0.1 as the actual host name in addition to "localhost" in /etc/hosts considered to be proper ? _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 7:51:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A3C337B401 for ; Thu, 18 Jul 2002 07:51:36 -0700 (PDT) Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2191343E58 for ; Thu, 18 Jul 2002 07:51:35 -0700 (PDT) (envelope-from erikt@midgard.homeip.net) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by maild.telia.com (8.12.5/8.12.5) with ESMTP id g6IEpX2a001888 for ; Thu, 18 Jul 2002 16:51:33 +0200 (CEST) X-Original-Recipient: Received: from falcon.midgard.homeip.net (h187n3fls20o913.telia.com [213.67.148.187]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id QAA17060 for ; Thu, 18 Jul 2002 16:51:31 +0200 (CEST) Received: (qmail 39317 invoked by uid 1001); 18 Jul 2002 14:51:30 -0000 Date: Thu, 18 Jul 2002 16:51:29 +0200 From: Erik Trulsson To: "Chuck T." Cc: net@FreeBSD.ORG Subject: Re: programatically list all local IP addresses ? Message-ID: <20020718145129.GA39189@falcon.midgard.homeip.net> Mail-Followup-To: "Chuck T." , net@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jul 18, 2002 at 07:27:08AM -0700, Chuck T. wrote: > I'm sure this is a FAQ, but I sure can't find the answer. I've tried the > usually suggested gethostname()/gethostbyname() approach, but that only > returns the *first* match in /etc/hosts. In one case that was 127.0.0.1. > Clearly this was a case where /etc/host.conf gave priority to the host file. Use gethostname()/gethostbyname() (or gethostbyaddr()) and then look through the 'h_addr_list' array in the 'struct hostent' returned by gethostbyname(). That should contain all the network addresses that were found for the given host. Another possibility is of course to run 'ifconfig -a' and then parse the output to find out what IP-addresses are configured on the machine. > > I don't want to call gethostent() because (if I understand the man page > correctly) that would limit me entries /etc/hosts ignoring DNS. > > I guess I could do a gethostname()/gethostbyname() and then if I fail to > find > a usable (non-rfc1918) address gethosten(). Is there a better way? > > Also is listing 127.0.0.1 as the actual host name in addition to "localhost" > in /etc/hosts considered to be proper ? That might be the only IP-address the machine has, so why not? -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 7:55:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CF6737B400 for ; Thu, 18 Jul 2002 07:55:49 -0700 (PDT) Received: from exchange.epx.com (exchange.epx.com [128.121.22.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id C97ED43E5E for ; Thu, 18 Jul 2002 07:55:48 -0700 (PDT) (envelope-from tsevy@exchange.epx.com) Received: (from root@localhost) by exchange.epx.com (8.11.6/8.11.6) id g6IEteH00795 for net@freebsd.org; Thu, 18 Jul 2002 10:55:40 -0400 (EDT) (envelope-from tsevy) Message-Id: <200207181455.g6IEteH00795@exchange.epx.com> Content-Type: text/plain; charset="iso-8859-1" From: freebsd To: net@freebsd.org Subject: Re: Question about network layers in FreeBSD 4.x Date: Thu, 18 Jul 2002 10:55:40 -0400 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thierry/all, I do now notice that if I don't put a bpf filter inplace to cut out some of the traffic there are a lot of dropped packets. My question then is: Does FreeBSD multi-thread the NIC drivers? Right now, using the dc driver. From: Thierry Herbelot [thierry@herbelot.com] Sent: Friday, July 12, 2002 2:02 PM To: freebsd Cc: net@FreeBSD.ORG Subject: Re: Question about network layers in FreeBSD 4.x freebsd wrote: > > I have a system I run FreeBSD 4.5-release on. The purpose of this system is > to run Snort (IDS). > > The current system is a Compaq Proliant 1850R, have also tried on a Compaq > Proliant 1600R. > > Both systems are SMP with dual processors, > 256m ram, and Compaq Smart Array > controller to handle raid in hardware. > FreeBSD 4.x (did-you notice 4.6 has been released ?) is not very good at using SMP machines where there are lots of interrupts (the kernel can only be run by one CPU at any one time, and this is enforced by a "Big Giant Lock"). you should re-run your test without the SMP option, to see it the problem is still here (it should not) then, there are kernel options in recent versions of FreeBSD enabling an optimized use of the interrupts (DEVICE POLLING). this may help you, if the driver has been modified. I used a cheap 4-port NIC from DLINK (DFE-570-TX) with very good success (this is the dc driver) Hope this helps TfH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 8: 2:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E7A037B401 for ; Thu, 18 Jul 2002 08:02:48 -0700 (PDT) Received: from mail.emergecore.com (mail.emergecore.com [216.190.54.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 7D6B643E3B for ; Thu, 18 Jul 2002 08:02:47 -0700 (PDT) (envelope-from bjones@emergecore.com) Received: (qmail 61649 invoked by uid 1007); 18 Jul 2002 15:04:12 -0000 Received: from bjones@emergecore.com by mail.emergecore.com by uid 1004 with qmail-scanner-1.12 (uvscan: v4.1.60/v4171. . Clear:. Processed in 0.732576 secs); 18 Jul 2002 15:04:12 -0000 Received: from unknown (HELO emergecore.com) (192.168.1.93) by 0 with SMTP; 18 Jul 2002 15:04:11 -0000 Message-ID: <3D36D820.4070707@emergecore.com> Date: Thu, 18 Jul 2002 09:00:48 -0600 From: Bruce Jones User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Trulsson Cc: "Chuck T." , net@FreeBSD.ORG Subject: Re: programatically list all local IP addresses ? References: <20020718145129.GA39189@falcon.midgard.homeip.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Erik Trulsson wrote: > On Thu, Jul 18, 2002 at 07:27:08AM -0700, Chuck T. wrote: > >>I'm sure this is a FAQ, but I sure can't find the answer. I've tried the >>usually suggested gethostname()/gethostbyname() approach, but that only >>returns the *first* match in /etc/hosts. In one case that was 127.0.0.1. >>Clearly this was a case where /etc/host.conf gave priority to the host file. > > > Use gethostname()/gethostbyname() (or gethostbyaddr()) and then look > through the 'h_addr_list' array in the 'struct hostent' returned by > gethostbyname(). That should contain all the network addresses that > were found for the given host. > > Another possibility is of course to run 'ifconfig -a' and then parse > the output to find out what IP-addresses are configured on the machine. > > do a man getifaddrs(3) Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 9:50: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3478D37B400 for ; Thu, 18 Jul 2002 09:50:05 -0700 (PDT) Received: from hotmail.com (f94.law9.hotmail.com [64.4.9.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id F233243E5E for ; Thu, 18 Jul 2002 09:50:04 -0700 (PDT) (envelope-from freebsdfan@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Jul 2002 09:50:04 -0700 Received: from 68.4.57.222 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 18 Jul 2002 16:50:04 GMT X-Originating-IP: [68.4.57.222] From: "Chuck T." To: ertr1013@student.uu.se Cc: net@freebsd.org Subject: Re: programatically list all local IP addresses ? Date: Thu, 18 Jul 2002 09:50:04 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jul 2002 16:50:04.0815 (UTC) FILETIME=[2A77E1F0:01C22E7B] 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 >Use gethostname()/gethostbyname() (or gethostbyaddr()) and then look >through the 'h_addr_list' array in the 'struct hostent' returned by >gethostbyname(). That should contain all the network addresses that >were found for the given host. That doesn't work when the lookup matches an entry in /etc/hosts, only the *first* address is returned even if there are multiple entries. That was my first attempt. The machine that was returning 127.0.0.1 also had a valid (nonlocal) IP address listed later in the file. 127.0.0.1 isn't very useful in my application because it's sent to another host, not used locally. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 9:52:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5799037B400 for ; Thu, 18 Jul 2002 09:52:18 -0700 (PDT) Received: from hotmail.com (f171.law9.hotmail.com [64.4.9.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2459C43E65 for ; Thu, 18 Jul 2002 09:52:18 -0700 (PDT) (envelope-from freebsdfan@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Jul 2002 09:52:14 -0700 Received: from 68.4.57.222 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 18 Jul 2002 16:52:14 GMT X-Originating-IP: [68.4.57.222] From: "Chuck T." To: bjones@emergecore.com Cc: net@FreeBSD.ORG Subject: Re: programatically list all local IP addresses ? Date: Thu, 18 Jul 2002 09:52:14 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jul 2002 16:52:14.0899 (UTC) FILETIME=[78012030:01C22E7B] 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 Excellent, that's just what I was looking for! Thanks. >do a man getifaddrs(3) > >Bruce _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 10:18:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BEFA37B400 for ; Thu, 18 Jul 2002 10:18:44 -0700 (PDT) Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E05043E64 for ; Thu, 18 Jul 2002 10:18:42 -0700 (PDT) (envelope-from erikt@midgard.homeip.net) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailc.telia.com (8.12.5/8.12.5) with ESMTP id g6IHIdt3015852 for ; Thu, 18 Jul 2002 19:18:40 +0200 (CEST) X-Original-Recipient: Received: from falcon.midgard.homeip.net (h187n3fls20o913.telia.com [213.67.148.187]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id TAA13803 for ; Thu, 18 Jul 2002 19:18:39 +0200 (CEST) Received: (qmail 40299 invoked by uid 1001); 18 Jul 2002 17:18:34 -0000 Date: Thu, 18 Jul 2002 19:18:33 +0200 From: Erik Trulsson To: "Chuck T." Cc: bjones@emergecore.com, net@FreeBSD.ORG Subject: Re: programatically list all local IP addresses ? Message-ID: <20020718171833.GA40200@falcon.midgard.homeip.net> Mail-Followup-To: "Chuck T." , bjones@emergecore.com, net@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jul 18, 2002 at 09:52:14AM -0700, Chuck T. wrote: > Excellent, that's just what I was looking for! Thanks. > >do a man getifaddrs(3) > > > >Bruce Just be aware that getifaddrs(3) (which does seem to be a quite useful function) is not very portable. It appears to be available on recent releases of all the *BSDs, but it does not seem to exist on Solaris or Linux. Now, if you don't need your program to be portable this is of course not a problem, but writing unportable code should be an informed decision rather than done out of ignorance. -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 10:22:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 264ED37B400 for ; Thu, 18 Jul 2002 10:22:12 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08A8943E4A for ; Thu, 18 Jul 2002 10:22:11 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.3/8.11.4) with ESMTP id g6IHM36l013805; Thu, 18 Jul 2002 20:22:04 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3D36F939.680BD76C@he.iki.fi> Date: Thu, 18 Jul 2002 20:22:01 +0300 From: Petri Helenius X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.6-PRERELEASE i386) X-Accept-Language: en,fi MIME-Version: 1.0 To: Erik Trulsson Cc: "Chuck T." , bjones@emergecore.com, net@FreeBSD.ORG Subject: Re: programatically list all local IP addresses ? References: <20020718171833.GA40200@falcon.midgard.homeip.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Erik Trulsson wrote: > > Just be aware that getifaddrs(3) (which does seem to be a quite useful > function) is not very portable. > It appears to be available on recent releases of all the *BSDs, but it > does not seem to exist on Solaris or Linux. > What would be the portable alternative to getifaddrs? I don't know one, but obviously it's good to know that you'll reimplement some of your code when going from platform to another. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 10:34:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8521137B400 for ; Thu, 18 Jul 2002 10:34:48 -0700 (PDT) Received: from isilon.com (isilon.com [65.101.129.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id E87E643E6A for ; Thu, 18 Jul 2002 10:34:47 -0700 (PDT) (envelope-from bbaumann@isilon.com) Received: from localhost (localhost [127.0.0.1]) by isilon.com (8.12.2/8.11.1) with ESMTP id g6IHYkl3010486; Thu, 18 Jul 2002 10:34:47 -0700 (PDT) (envelope-from bbaumann@isilon.com) Date: Thu, 18 Jul 2002 10:34:46 -0700 (PDT) From: Bill Baumann To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: Inconsistency between net/if.c and several ethernet drivers In-Reply-To: <200207171812.g6HICmm8097762@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm working on just such a driver. It has layers that communicate with assumptions about structure alignment. Moving struct arpcom to the beginning breaks this, and requires scattered changes throughout. :-( Even so I'd rather do it the right way. Unless, I hear someone else disagreeing, I'll assume that arpcom must be at the top of softc and write a problem report against the offending drivers (awi,lnc,pdq,ray). - Bill Baumann On Wed, 17 Jul 2002, Garrett Wollman wrote: > < said: > > > Why bother with a if_softc field when the interface and softc pointer are > > supposed to be the same? Also, the very old Lance driver (lnc) has this > > problem. It makes me wonder how true we are to TCP/IP Illustrated... > > if_softc was added to pacify those who either didn't understand the C > language, or thought they had a good reason why the softc structure > had to begin with some other structure than ifnet. > > -GAWollman > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 11: 2:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79CB237B400 for ; Thu, 18 Jul 2002 11:02:41 -0700 (PDT) Received: from hotmail.com (f273.law9.hotmail.com [64.4.8.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C36543E5E for ; Thu, 18 Jul 2002 11:02:41 -0700 (PDT) (envelope-from freebsdfan@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Jul 2002 11:02:41 -0700 Received: from 68.4.57.222 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 18 Jul 2002 18:02:40 GMT X-Originating-IP: [68.4.57.222] From: "Chuck T." To: ertr1013@student.uu.se Cc: bjones@emergecore.com, net@FreeBSD.ORG Subject: Re: programatically list all local IP addresses ? Date: Thu, 18 Jul 2002 11:02:40 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jul 2002 18:02:41.0185 (UTC) FILETIME=[4F113110:01C22E85] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Yes portablity is a concern, unfortunately my program will probably be used on Linux more than FreeBSD, sigh. I starting to read about ioctl() and SIOCGIFADDR which appears to be portable (and a pain). It looks like the Linux crowd is adding getifaddrs(3) as part of their ipv6 effort, but I'd rather not depend on that. >On Thu, Jul 18, 2002 at 09:52:14AM -0700, Chuck T. wrote: > > Excellent, that's just what I was looking for! Thanks. > > >do a man getifaddrs(3) > > > > > >Bruce > >Just be aware that getifaddrs(3) (which does seem to be a quite useful >function) is not very portable. >It appears to be available on recent releases of all the *BSDs, but it >does not seem to exist on Solaris or Linux. > >Now, if you don't need your program to be portable this is of course >not a problem, but writing unportable code should be an informed >decision rather than done out of ignorance. > > >-- > >Erik Trulsson >ertr1013@student.uu.se _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 12: 0: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDAC337B400 for ; Thu, 18 Jul 2002 11:59:59 -0700 (PDT) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6383643E42 for ; Thu, 18 Jul 2002 11:59:59 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.5/8.12.5) with ESMTP id g6IIxw4S045971; Thu, 18 Jul 2002 12:59:58 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.5/8.12.5/Submit) id g6IIxwxv045970; Thu, 18 Jul 2002 12:59:58 -0600 (MDT) (envelope-from rousskov) Date: Thu, 18 Jul 2002 12:59:58 -0600 (MDT) From: Alex Rousskov To: "Chuck T." Cc: net@FreeBSD.ORG Subject: Re: programatically list all local IP addresses ? 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 Thu, 18 Jul 2002, Chuck T. wrote: > Yes portablity is a concern, unfortunately my program will > probably be used on Linux more than FreeBSD, sigh. I starting to > read about ioctl() and SIOCGIFADDR which appears to be portable > (and a pain). We had to write portable local address detection for Web Polygraph. In my experience, ioctl/SIOCGIFADDR is not portable at all and is a lot of pain. Linux uses them differently from FreeBSD, and the exact interface/behavior is often OS-version specific (e.g., for Solaris IIRC). Looking at existing code helps. I would suggest using getifaddrs(3) where available (./configure can detect that, of course) and delve into ioctl() and other OS-specific methods where getifaddrs(3) is not supported. Stockpile some pain relieve medication first. $0.02, Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 12:15:17 2002 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 30F6E37B400; Thu, 18 Jul 2002 12:15:15 -0700 (PDT) Date: Thu, 18 Jul 2002 12:15:15 -0700 From: Juli Mallett To: Alex Rousskov Cc: "Chuck T." , net@FreeBSD.ORG Subject: Re: programatically list all local IP addresses ? Message-ID: <20020718121515.A95081@FreeBSD.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rousskov@measurement-factory.com on Thu, Jul 18, 2002 at 12:59:58PM -0600 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * De: Alex Rousskov [ Data: 2002-07-18 ] [ Subjecte: Re: programatically list all local IP addresses ? ] > On Thu, 18 Jul 2002, Chuck T. wrote: > > > Yes portablity is a concern, unfortunately my program will > > probably be used on Linux more than FreeBSD, sigh. I starting to > > read about ioctl() and SIOCGIFADDR which appears to be portable > > (and a pain). > > We had to write portable local address detection for Web Polygraph. In > my experience, ioctl/SIOCGIFADDR is not portable at all and is a lot > of pain. Linux uses them differently from FreeBSD, and the exact > interface/behavior is often OS-version specific (e.g., for Solaris > IIRC). > > Looking at existing code helps. I would suggest using getifaddrs(3) > where available (./configure can detect that, of course) and delve > into ioctl() and other OS-specific methods where getifaddrs(3) is not > supported. Stockpile some pain relieve medication first. Using a library which has these sorts of things abstracted helps. I believe this particular case is one covered by libnet or libdnet or whatever it's called. -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 14:33:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7613137B400 for ; Thu, 18 Jul 2002 14:33:20 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id A272343E65 for ; Thu, 18 Jul 2002 14:33:19 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.5) with ESMTP id g6ILXHqw007761 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 18 Jul 2002 17:33:17 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.3/Submit) id g6ILXHNl007758; Thu, 18 Jul 2002 17:33:17 -0400 (EDT) (envelope-from wollman) Date: Thu, 18 Jul 2002 17:33:17 -0400 (EDT) From: Garrett Wollman Message-Id: <200207182133.g6ILXHNl007758@khavrinen.lcs.mit.edu> To: Jonathan Lemon Cc: net@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_timer.h In-Reply-To: <20020718154341.D78047@prism.flugsvamp.com> References: <200207181608.g6IG8dN82437@prism.flugsvamp.com> <200207181732.g6IHW9rY018853@apollo.backplane.com> <20020718133111.B78047@prism.flugsvamp.com> <200207181857.g6IIv9ei019345@apollo.backplane.com> <20020718125410.K91443@nexus.root.com> <20020718154341.D78047@prism.flugsvamp.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [Trying desparately to move this discussion to the correct list....] I spent a few minutes talking to Dave Clark about this question this afternoon. Here's my paraphrase of his opinion: - He disclaims completely up-to-date knowledge of the current research results. - He feels that 1000 ms is commonly used only because the historical BSD implementation couldn't do any better (it actually did 750 ms +/- 250 ms), and supports the idea that retransmits could occur more frequently. He has traces which show where a longer RTO would be both beneficial and harmful. - He questioned whether the traditional VJ `srtt + 4*rttvar' computation captures enough of the variance in the real Internet to avoid unnecessary slow retransmits. - He notes that Microsoft's TCP had a serious problem wherein it would slow-retransmit too aggressively, which resulted in almost any network transient triggering sufficient dupacks to cause fast retransmit to engage. (The result was that every data packet would be sent twice.) He suggests that, to avoid this, it may be necessary to lengthen the slow-retransmit timeout after a fast retransmit is triggered. - He also notes that there have not been screams of protest since Linux adopted the 200-ms minimum, which suggests that it's not a completely hare-brained value. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 14:40:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1ACB37B41C for ; Thu, 18 Jul 2002 14:40:28 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C86C43E5E for ; Thu, 18 Jul 2002 14:40:28 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020718214027.QXRH29588.sccrmhc01.attbi.com@InterJet.elischer.org>; Thu, 18 Jul 2002 21:40:27 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA85459; Thu, 18 Jul 2002 14:39:27 -0700 (PDT) Date: Thu, 18 Jul 2002 14:39:26 -0700 (PDT) From: Julian Elischer To: Garrett Wollman Cc: Jonathan Lemon , net@FreeBSD.org Subject: Re: Retransmit times (was something else) In-Reply-To: <200207182133.g6ILXHNl007758@khavrinen.lcs.mit.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 and now that we are on -net....... TADA!!! SACK is now supported by default on 90% of internet hosts except for "guess who?" SACK is the way that most internet traffic is now handling packet loss. Isn't it about time that one of the (3?) SACK implementations got integrated? On Thu, 18 Jul 2002, Garrett Wollman wrote: > [Trying desparately to move this discussion to the correct list....] > > > - He notes that Microsoft's TCP had a serious problem wherein it would > slow-retransmit too aggressively, which resulted in almost any network > transient triggering sufficient dupacks to cause fast retransmit to > engage. (The result was that every data packet would be sent twice.) > He suggests that, to avoid this, it may be necessary to lengthen the > slow-retransmit timeout after a fast retransmit is triggered. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 14:53: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79BBC37B400 for ; Thu, 18 Jul 2002 14:53:01 -0700 (PDT) Received: from crimea.dzhan.com (w060.z064001192.sea-wa.dsl.cnc.net [64.1.192.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C05443E42 for ; Thu, 18 Jul 2002 14:53:01 -0700 (PDT) (envelope-from benjamin@dzhan.com) Received: by crimea.dzhan.com (Postfix, from userid 1001) id 2AB2222E0E; Thu, 18 Jul 2002 15:01:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by crimea.dzhan.com (Postfix) with ESMTP id 290B31D10D for ; Thu, 18 Jul 2002 15:01:51 -0700 (PDT) Date: Thu, 18 Jul 2002 15:01:51 -0700 (PDT) From: Benjamin Franks To: Subject: tcp SYN retries? Message-ID: <20020718150136.M46100-100000@crimea.dzhan.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org When I attempt to make a sock_stream connection to an IP, and DON'T receive an ACK or RST response, it seems that the system retries a finite number of times by sending additional SYN packets. There also looks to be a 3 or 6 second delay between SYN retries. After four or five, the connection fails. Is there a way I can change the interval time for SYN retries, or decrease the number of times it retries? I would imagine this would be dependent on the particular tcp/ip stack implementation of my OS. I'm using FreeBSD and would imaging some kernel sysctl variable would control this... Any ideas? Or perhaps it's a socket option? Thanks! --Ben To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 15: 6:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D111A37B400 for ; Thu, 18 Jul 2002 15:06:50 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D09A43E4A for ; Thu, 18 Jul 2002 15:06:50 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g6IM6h526828; Thu, 18 Jul 2002 15:06:43 -0700 (PDT) (envelope-from rizzo) Date: Thu, 18 Jul 2002 15:06:43 -0700 From: Luigi Rizzo To: Julian Elischer Cc: Garrett Wollman , Jonathan Lemon , net@FreeBSD.ORG Subject: Re: Retransmit times (was something else) Message-ID: <20020718150643.A26307@iguana.icir.org> References: <200207182133.g6ILXHNl007758@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Thu, Jul 18, 2002 at 02:39:26PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jul 18, 2002 at 02:39:26PM -0700, Julian Elischer wrote: > and now that we are on -net....... > TADA!!! > SACK is now supported by default on 90% of internet hosts except for > "guess who?" supported does not mean used though, and I am not even sure how much traffic is successfully delivered using SACK. I am Bcc-ing someone who might know some data... > SACK is the way that most internet traffic is now handling packet loss. > Isn't it about time that one of the (3?) SACK implementations got > integrated? well, mine (dating back to 1996) is totally outdated and not terribly well tested (in other words, "sacks"...), and the other one which was announced last summer broke the regular behaviour in the non-sack case, so... I'd rather stay away from them unless someone wants to put substantial amount of time in looking at them (which is not fun at all). cheers luigi > On Thu, 18 Jul 2002, Garrett Wollman wrote: > > > [Trying desparately to move this discussion to the correct list....] > > > > > > - He notes that Microsoft's TCP had a serious problem wherein it would > > slow-retransmit too aggressively, which resulted in almost any network > > transient triggering sufficient dupacks to cause fast retransmit to > > engage. (The result was that every data packet would be sent twice.) > > He suggests that, to avoid this, it may be necessary to lengthen the > > slow-retransmit timeout after a fast retransmit is triggered. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 16:37:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC4B037B400 for ; Thu, 18 Jul 2002 16:37:25 -0700 (PDT) Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F45C43E31 for ; Thu, 18 Jul 2002 16:37:25 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g6INb8n97317; Thu, 18 Jul 2002 18:37:08 -0500 (CDT) (envelope-from jlemon) Date: Thu, 18 Jul 2002 18:37:08 -0500 (CDT) From: Jonathan Lemon Message-Id: <200207182337.g6INb8n97317@prism.flugsvamp.com> To: benjamin@dzhan.com, net@freebsd.org Subject: Re: tcp SYN retries? X-Newsgroups: local.mail.freebsd-net In-Reply-To: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article you write: > >When I attempt to make a sock_stream connection to an IP, and DON'T >receive an ACK or RST response, it seems that the system retries a finite >number of times by sending additional SYN packets. There also looks to be >a 3 or 6 second delay between SYN retries. After four or five, the >connection fails. > >Is there a way I can change the interval time for SYN retries, or decrease >the number of times it retries? I would imagine this would be dependent >on the particular tcp/ip stack implementation of my OS. I'm using FreeBSD >and would imaging some kernel sysctl variable would control this... Any >ideas? Or perhaps it's a socket option? You don't mention what version of FreeBSD you're using. The latest versions have a only a 1 sec interval between retries for the first couple of attempts. An overall timeout would be best implemented at the application layer. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 21:13: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B2E037B400 for ; Thu, 18 Jul 2002 21:13:05 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 492BB43E65 for ; Thu, 18 Jul 2002 21:13:04 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:4819:2000:944b:74ea:3301:7fbb]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6J4CgA00835; Fri, 19 Jul 2002 13:12:42 +0900 (JST) Date: Fri, 19 Jul 2002 13:12:45 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Trulsson Cc: "Chuck T." , bjones@emergecore.com, net@FreeBSD.ORG Subject: Re: programatically list all local IP addresses ? In-Reply-To: <20020718171833.GA40200@falcon.midgard.homeip.net> References: <20020718171833.GA40200@falcon.midgard.homeip.net> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 23 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, 18 Jul 2002 19:18:33 +0200, >>>>> Erik Trulsson said: >> Excellent, that's just what I was looking for! Thanks. >> >do a man getifaddrs(3) > Just be aware that getifaddrs(3) (which does seem to be a quite useful > function) is not very portable. > It appears to be available on recent releases of all the *BSDs, but it > does not seem to exist on Solaris or Linux. If I remember correctly, the USAGI project (http://www.linux-ipv6.org/) provided getifaddrs(3) on linux. They should also be trying to merge their products to the linux main kernel and major distributions. (still, it's true that we cannot always expect portability of getifaddrs(3)) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 22: 4: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4FEC37B400; Thu, 18 Jul 2002 22:03:59 -0700 (PDT) Received: from crimea.dzhan.com (w060.z064001192.sea-wa.dsl.cnc.net [64.1.192.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ED9D43E65; Thu, 18 Jul 2002 22:03:59 -0700 (PDT) (envelope-from benjamin@dzhan.com) Received: by crimea.dzhan.com (Postfix, from userid 1001) id 4D3AE22E0E; Thu, 18 Jul 2002 22:12:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by crimea.dzhan.com (Postfix) with ESMTP id 494AE1D10D; Thu, 18 Jul 2002 22:12:53 -0700 (PDT) Date: Thu, 18 Jul 2002 22:12:53 -0700 (PDT) From: Benjamin Franks To: Cc: Subject: giving priority to udp over tcp? Message-ID: <20020718220521.F46506-100000@crimea.dzhan.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm using FreeBSD 4.5 and have custom applications that send receive network packets over both tcp and udp sockets. For the sake of an example, assume that the udp traffic is always constant, but the tcp traffic density changes. During times of heavy tcp traffic density, will udp messages which have been sent to the out queue typically wait in the queue longer before being sent out? Does tcp traffic get some sort of priority? If so, is there a way I can de-prioritize tcp traffic and up the priority of the udp traffic to make certain all the queued udp messages get out as soon as possible...? sysctl variables? does it depend on the network card driver, or perhaps i'm imagining something that isn't there and the two traffic types are totally isolated! ;) Thanks! --Ben To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 22:21: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B0B837B400; Thu, 18 Jul 2002 22:20:59 -0700 (PDT) Received: from melete.ch.intel.com (chfdns02.ch.intel.com [143.182.246.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8005443E42; Thu, 18 Jul 2002 22:20:58 -0700 (PDT) (envelope-from pavan.balaji@intel.com) Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by melete.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g6J5KwF00491; Fri, 19 Jul 2002 05:20:58 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002071822214609901 ; Thu, 18 Jul 2002 22:21:46 -0700 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3WZGTSZ4>; Thu, 18 Jul 2002 22:20:57 -0700 Message-ID: <3D386AED1B47D411A94300508B11F18703BC5BD4@fmsmsx116.fm.intel.com> From: "Balaji, Pavan" To: "'Benjamin Franks'" , freebsd-questions@FreeBSD.ORG Cc: freebsd-net@FreeBSD.ORG Subject: RE: giving priority to udp over tcp? Date: Thu, 18 Jul 2002 22:20:55 -0700 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 TCP traffic as such does not get any priority over UDP traffic, but the way in which the TCP messages are sent (Data Streaming) is different from the way UDP messages are sent (Datagram). In essense, UDP messages wait till there's enough space for the entire message before the message is added to the output queue. Whereas, if there isn't enough space for the entire message, a part of the message is sent and the rest buffered. So, it might appear to be getting higher priority for some applications. Pavan Balaji, Intel Corporation "Only the Paranoid Survive" -- Andy Grove > -----Original Message----- > From: Benjamin Franks [mailto:benjamin@dzhan.com] > Sent: Friday, July 19, 2002 12:13 AM > To: freebsd-questions@FreeBSD.ORG > Cc: freebsd-net@FreeBSD.ORG > Subject: giving priority to udp over tcp? > > > > I'm using FreeBSD 4.5 and have custom applications that send receive > network packets over both tcp and udp sockets. For the sake of an > example, assume that the udp traffic is always constant, but the tcp > traffic density changes. During times of heavy tcp traffic > density, will > udp messages which have been sent to the out queue typically > wait in the > queue longer before being sent out? Does tcp traffic get some sort of > priority? If so, is there a way I can de-prioritize tcp > traffic and up > the priority of the udp traffic to make certain all the queued udp > messages get out as soon as possible...? sysctl variables? does it > depend on the network card driver, or perhaps i'm imagining > something that > isn't there and the two traffic types are totally isolated! ;) > > Thanks! > --Ben > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 18 22:48: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E26BD37B405 for ; Thu, 18 Jul 2002 22:48:04 -0700 (PDT) Received: from web14609.mail.yahoo.com (web14609.mail.yahoo.com [216.136.224.241]) by mx1.FreeBSD.org (Postfix) with SMTP id B952043E4A for ; Thu, 18 Jul 2002 22:48:04 -0700 (PDT) (envelope-from shubha_mr@yahoo.com) Message-ID: <20020719054804.78353.qmail@web14609.mail.yahoo.com> Received: from [12.151.32.25] by web14609.mail.yahoo.com via HTTP; Fri, 19 Jul 2002 06:48:04 BST Date: Fri, 19 Jul 2002 06:48:04 +0100 (BST) From: =?iso-8859-1?q?shubha=20mr?= Subject: VLAN - testing-urgent! To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Would like to know how to test VLAN for ethernet network driver for a NIC. Thanks a lot shubha __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 19 5:55:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22DF837B400; Fri, 19 Jul 2002 05:55:17 -0700 (PDT) Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 246EA43E58; Fri, 19 Jul 2002 05:55:16 -0700 (PDT) (envelope-from c.prevotaux@hexanet.fr) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.3/8.12.3) with SMTP id g6JCtDCE041136; Fri, 19 Jul 2002 14:55:13 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Fri, 19 Jul 2002 14:55:13 +0200 From: Christophe Prevotaux To: atm@freebsd.org, net@freebsd.org Subject: HELP: 4.6Release-p2 Message-Id: <20020719145513.76f4876b.c.prevotaux@hexanet.fr> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi I was wondering if this was a coincidence or if something BROKE the hfa driver in 4.6Release-p2 After recompiling the system my PCA200E Forerunner ATM adapter does not work anymore, I get a message: atm: ATM network is inoperable and and an : atm show config will tell me no Mac Address has assigned to the card and the card has no serial number (which can't be true) and there is no hardware version. Intf Vendor Model Media Bus Serial No hfa0 Fore PCA-200E OC-3c PCI 0 MAC address = 00:00:00:00:00:00 Hardware version = Firmware version = 3.0.1 The card was working before the only thing that has changed on this machine is that the kernel has been recompiled in MONO CPU mode, it was running SMP before and the source has been recompiled to match the lastest patches from 4.6Release the strange thing is that I have an atm0 interface shown when running ifconfig atm0: flags=42 mtu 9180 ether 00:00:00:00:00:00 If I try to manually start the card with first downloading the firmware I get a : hfa0 is up and running - no download allowed. My question is : what has changed and how can i fix this ? or is the card DEAD ? The exact same card model on the exact same machine ( a spare) not upgraded to 4.6p2 works. -- -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 19 11:40:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51F2C37B401 for ; Fri, 19 Jul 2002 11:40:18 -0700 (PDT) Received: from mail.webjockey.net (mail.webjockey.net [208.141.46.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 872C643E3B for ; Fri, 19 Jul 2002 11:40:17 -0700 (PDT) (envelope-from gary@outloud.org) Received: from lunar-fx2shz8f6.outloud.org (wv-mrtnbrg-cmts1a-a-233.shphwv.adelphia.net [68.67.224.233]) by mail.webjockey.net (8.12.3/8.12.3) with ESMTP id g6JIlCaM014540 for ; Fri, 19 Jul 2002 14:47:13 -0400 (EDT) (envelope-from gary@outloud.org) Message-Id: <5.1.0.14.2.20020719142640.00c87410@208.141.46.254> X-Sender: ancient@208.141.46.3 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 19 Jul 2002 14:39:04 -0400 To: freebsd-net@freebsd.org From: Gary Stanley Subject: Trouble with SMP, and 2 ethernet cards Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi. This is a strange problem. FreeBSD 4.5-REL, with 2 ethernet cards (one of them is a fxp, and other is a copper intel gig-e) , SMP machine with 4 intel P4 2ghz CPU's, 2 gigs of memory, etc. (your normal I-want-a-big-webserver deal ;-) Problems start with data/bandwidth. I tried zeus as a webserver for static content delivery, and downloads to customers on fast connections is, slow. I'm talking 60kbytes when most of the customers pull 3-5mbit down from a different server on the same switch this machine is connected to. The traffic stays at that level until we restart the server, at that point, when I do, traffic is normal (around 4mbit for me, downstream) After a couple of minutes the machine starts to grind to a halt as far as data xfer goes. Windows Sizes are Default. Kernel is built fine. Any idea? PS. Please CC me as I don't have a subscription to this list. :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 19 11:58:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C714337B400 for ; Fri, 19 Jul 2002 11:58:14 -0700 (PDT) Received: from patrocles.silby.com (d100.as5.nwbl0.wi.voyager.net [169.207.137.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A29D43E3B for ; Fri, 19 Jul 2002 11:58:13 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g6JJ2gcv095413; Fri, 19 Jul 2002 14:02:42 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.5/8.12.5/Submit) with ESMTP id g6JJ2dPI095410; Fri, 19 Jul 2002 14:02:40 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Fri, 19 Jul 2002 14:02:38 -0500 (CDT) From: Mike Silbersack To: Garrett Wollman Cc: Jonathan Lemon , Subject: Re: cvs commit: src/sys/netinet tcp_timer.h In-Reply-To: <200207182133.g6ILXHNl007758@khavrinen.lcs.mit.edu> Message-ID: <20020719134639.S95326-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 18 Jul 2002, Garrett Wollman wrote: > - He questioned whether the traditional VJ `srtt + 4*rttvar' > computation captures enough of the variance in the real Internet to > avoid unnecessary slow retransmits. > > - He also notes that there have not been screams of protest since > Linux adopted the 200-ms minimum, which suggests that it's not a > completely hare-brained value. > > -GAWollman Now that I've had a bit more time to think it over, I believe that Matt's 200ms slop + no floor on rtomin provides us with a very good system. In effect, Matt has seperated the delay necessary to avoid retrans because of delayed acks (200ms or less on modern systems) from rtt (quite variable.) This is an approach that seems quite obvious in hindsight, and should allow the tcp stack to adapt to varying link types quite dynamically. The main improvement upon this I could see is dynamically detecting the delayed ack period of the receiver, as suggesed by DG. Unfortunately, I suspect that such detection would be nearly impossible to get correct. In place of this, I'd suggest that the slop be bumped from 200ms up to 220ms; both linux and windows use a 200ms delayed ACK period, and we don't want to be exactly synchronized to that time period. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 19 17:36:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B499937B400; Fri, 19 Jul 2002 17:36:40 -0700 (PDT) Received: from mirapoint2.brutele.be (mirapoint2.brutele.be [212.68.193.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id C578E43E58; Fri, 19 Jul 2002 17:36:39 -0700 (PDT) (envelope-from jylefort@brutele.be) Received: from gateway.lefort.net ([213.189.162.78]) by mirapoint2.brutele.be (Mirapoint) with ESMTP id BBQ51096; Sat, 20 Jul 2002 01:59:18 +0200 (CEST) Received: from jsite.lefort.net (jsite.lefort.net [192.168.1.2]) by gateway.lefort.net (Postfix) with ESMTP id 9B7231539A; Sat, 20 Jul 2002 01:59:17 +0200 (CEST) Received: from jsite.lefort.net (localhost [127.0.0.1]) by jsite.lefort.net (Postfix) with SMTP id CD4E82304B; Sat, 20 Jul 2002 01:59:16 +0200 (CEST) Date: Sat, 20 Jul 2002 01:59:16 +0200 From: Jean-Yves Lefort To: Benjamin Franks Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: giving priority to udp over tcp? Message-Id: <20020720015916.682d49fd.jylefort@brutele.be> In-Reply-To: <20020718220521.F46506-100000@crimea.dzhan.com> References: <20020718220521.F46506-100000@crimea.dzhan.com> X-Mailer: Sylpheed version 0.8.0 (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 18 Jul 2002 22:12:53 -0700 (PDT) Benjamin Franks wrote: > I'm using FreeBSD 4.5 and have custom applications that send receive > network packets over both tcp and udp sockets. For the sake of an > example, assume that the udp traffic is always constant, but the tcp > traffic density changes. During times of heavy tcp traffic density, > will udp messages which have been sent to the out queue typically wait > in the queue longer before being sent out? Does tcp traffic get some > sort of priority? If so, is there a way I can de-prioritize tcp > traffic and up the priority of the udp traffic to make certain all the > queued udp messages get out as soon as possible...? sysctl variables? > does it > depend on the network card driver, or perhaps i'm imagining something > that isn't there and the two traffic types are totally isolated! ;) man dummynet Regards, Jean-Yves Lefort -- Jean-Yves Lefort jylefort@brutele.be http://void.adminz.be/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 19 18: 3:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F7AC37B400; Fri, 19 Jul 2002 18:03:07 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB6F543E67; Fri, 19 Jul 2002 18:03:06 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g6K135CV081156; Fri, 19 Jul 2002 18:03:05 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g6K135Ap081155; Fri, 19 Jul 2002 18:03:05 -0700 (PDT) (envelope-from dillon) Date: Fri, 19 Jul 2002 18:03:05 -0700 (PDT) From: Matthew Dillon Message-Id: <200207200103.g6K135Ap081155@apollo.backplane.com> To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Another go at bandwidth delay product pipeline limiting for TCP 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 Ok, I am having another go at trying to implement a bandwidth delay product calculation to limit the number of inflight packets. The idea behind this feature is two fold: (1) If you have huge TCP buffers and there is no packet loss our TCP stack will happily build up potentially hundreds of outgoing packets even though most of them just sit in the interface queue (or, worse, in your router's interface queue!). (2) If you have a bandwidth constriction, such as a modem, this feature attempts to place only as many packets in the pipeline as is necessary to fill the pipeline, which means that you can type in one window and send large amounts of data (scp, ftp) in another. Note that this is a transmitter-side solution, not a receiver-side solution. This will not help your typing if you are downloading a lot of stuff and the remote end builds up a lot of packets on your ISP's router. Theoretically we should be able to also restrict the window we advertise but that is a much more difficult problem. This code is highly experimental and so the SYSCTL's are setup for debugging (and it is disabled by default). I'm sure a lot of tuning can be done. The sysctl's are as follows: net.inet.tcp.inflight_enable default off (0) net.inet.tcp.inflight_debug default on (1) net.inet.tcp.inflight_min default 1024 net.inet.tcp.inflight_max default seriously large number Under normal operating conditions the min default would usually be at least 4096. For debugging it is useful to allow it to be 1024. Note that the code will not internally allow the inflight size to drop under 2 * maxseg (two segments). This code calculates the bandwidth delay product and artifically closes the transmit window to that value. The bandwidth delay product for the purposes of transmit window calculation is: bytes_in_flight = end_to_end_bandwidth * srtt Examples: Transport Bandwidth Ping Bandwidth Delay product (-s 1440) GigE 100 MBytes/sec 1.00 ms 100000 bytes 100BaseTX 10 MBytes/sec 0.65 ms 6500 bytes 10BaseT 1 MByte/sec 1.00 ms 1000 bytes T1 170 KBytes/sec 5.00 ms 850 bytes DSL 120 KBytes/sec 20.00 ms 2400 bytes ISDN 14 KBytes/sec 40.00 ms 560 bytes 56K modem 5.6 KBytes/sec 120 ms 672 bytes Slow client 50 KBytes/sec 200 ms 10000 bytes Now lets say you have a TCP send buffer of 128K and the remote end has a receive buffer of 128K, and window scaling works. On a 100BaseTX connection with no packet loss your TCP sender will queue up to 91 packets to the interface even though it only really needs to queue up 5 packets. With net.inet.tcp.inflight_enable turned on, the TCP sender will only queue up 4 packets. On the GigE link which actually needs 69 packets in flight, 69 packets will be queued up. That's what this code is supposed to do. This is my second attempt. I tried this last year too but it was too messy. But this time I think I've got it down to where it isn't as messy. -Matt Matthew Dillon Index: tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.165 diff -u -r1.165 tcp_input.c --- tcp_input.c 19 Jul 2002 18:27:39 -0000 1.165 +++ tcp_input.c 20 Jul 2002 00:38:15 -0000 @@ -1008,6 +1008,8 @@ else if (tp->t_rtttime && SEQ_GT(th->th_ack, tp->t_rtseq)) tcp_xmit_timer(tp, ticks - tp->t_rtttime); + tcp_xmit_bandwidth_limit(tp, th->th_ack); + acked = th->th_ack - tp->snd_una; tcpstat.tcps_rcvackpack++; tcpstat.tcps_rcvackbyte += acked; @@ -1805,6 +1807,8 @@ tcp_xmit_timer(tp, ticks - to.to_tsecr + 1); else if (tp->t_rtttime && SEQ_GT(th->th_ack, tp->t_rtseq)) tcp_xmit_timer(tp, ticks - tp->t_rtttime); + + tcp_xmit_bandwidth_limit(tp, th->th_ack); /* * If all outstanding data is acked, stop retransmit Index: tcp_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v retrieving revision 1.65 diff -u -r1.65 tcp_output.c --- tcp_output.c 23 Jun 2002 21:25:36 -0000 1.65 +++ tcp_output.c 20 Jul 2002 00:38:15 -0000 @@ -164,6 +164,7 @@ sendalot = 0; off = tp->snd_nxt - tp->snd_una; win = min(tp->snd_wnd, tp->snd_cwnd); + win = min(win, tp->snd_bwnd); flags = tcp_outflags[tp->t_state]; /* @@ -773,7 +774,8 @@ tp->snd_max = tp->snd_nxt; /* * Time this transmission if not a retransmission and - * not currently timing anything. + * not currently timing anything. Also calculate + * the bandwidth (8 segment average) */ if (tp->t_rtttime == 0) { tp->t_rtttime = ticks; Index: tcp_subr.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.137 diff -u -r1.137 tcp_subr.c --- tcp_subr.c 18 Jul 2002 19:06:12 -0000 1.137 +++ tcp_subr.c 20 Jul 2002 00:38:16 -0000 @@ -144,6 +144,22 @@ SYSCTL_INT(_net_inet_tcp, OID_AUTO, isn_reseed_interval, CTLFLAG_RW, &tcp_isn_reseed_interval, 0, "Seconds between reseeding of ISN secret"); +static int tcp_inflight_enable = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_enable, CTLFLAG_RW, + &tcp_inflight_enable, 0, "Enable automatic TCP inflight data limiting"); + +static int tcp_inflight_debug = 1; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_debug, CTLFLAG_RW, + &tcp_inflight_debug, 0, "Debug TCP inflight calculations"); + +static int tcp_inflight_min = 1024; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_min, CTLFLAG_RW, + &tcp_inflight_min, 0, "Lower-bound for TCP inflight window"); + +static int tcp_inflight_max = TCP_MAXWIN << TCP_MAX_WINSHIFT; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_max, CTLFLAG_RW, + &tcp_inflight_max, 0, "Upper-bound for TCP inflight window"); + static void tcp_cleartaocache(void); static struct inpcb *tcp_notify(struct inpcb *, int); @@ -547,6 +563,7 @@ tp->t_rttmin = tcp_rexmit_min; tp->t_rxtcur = TCPTV_RTOBASE; tp->snd_cwnd = TCP_MAXWIN << TCP_MAX_WINSHIFT; + tp->snd_bwnd = TCP_MAXWIN << TCP_MAX_WINSHIFT; tp->snd_ssthresh = TCP_MAXWIN << TCP_MAX_WINSHIFT; tp->t_rcvtime = ticks; /* @@ -1509,3 +1526,129 @@ tcp_cleartaocache() { } + +/* + * Calculate the bandwidth based on received acks every 8 + * maximal segments and smooth the result. + * + * The nominal snd_bwnd calculation is (bandwidth * rtt), + * the amount of data required to keep the network pipe + * full. However, we cannot simply make this calculation + * because our adjustment of snd_bwnd based on it will + * be highly unstable, producing positive feedback if we are + * too low and also producing positive feedback if we are + * too high. + * + * In order to stabilize the calculation we have to increase + * bwnd a little, measure the bandwidth, then decrease bwnd + * a little and measure the rtt. The resulting calculation + * will should then be stable. + */ +void +tcp_xmit_bandwidth_limit(struct tcpcb *tp, tcp_seq ack_seq) +{ + u_long bw; + + /* + * If inflight_enable is disabled in the middle of a tcp connection, + * make sure snd_bwnd is effectively disabled. + */ + if (tcp_inflight_enable == 0) { + tp->snd_bwnd = TCP_MAXWIN << TCP_MAX_WINSHIFT; + tp->snd_bandwidth = 0; + } + + /* + * Base periodic is once every 8 maximal segments. + */ + if (tcp_inflight_enable == 0 || + (int)(ack_seq - tp->t_bw_rtseq) < tp->t_maxseg * 8 || + tp->t_bw_rtttime == ticks) { + return; + } + + /* + * Calculate the bandwidth + */ + if (tp->t_bw_rtttime) { + bw = (ack_seq - tp->t_bw_rtseq) * hz / + (ticks - tp->t_bw_rtttime); + } else { + bw = tp->snd_bandwidth; + } + tp->t_bw_rtseq = ack_seq; + tp->t_bw_rtttime = ticks; + if (tp->snd_bandwidth == 0) + tp->snd_bandwidth = bw; + else + tp->snd_bandwidth = (tp->snd_bandwidth * 3 + bw) >> 2; + + /* + * Initial Conditions + */ + if (bw && tp->snd_bwnd == TCP_MAXWIN << TCP_MAX_WINSHIFT) { + tp->snd_bwnd = (u_int64_t)tp->snd_bandwidth * tp->t_srtt / + (hz << TCP_RTT_SHIFT); + } + + /* + * calculate the bandwidth delay product and cycle through + * our state machine. + */ + ++tp->t_bw_state; + + switch(tp->t_bw_state & 0x0F) { + case 0x00: + /* + * Save the bandwidth and increase bwnd. + */ + tp->t_bw_bandwidth = tp->snd_bandwidth; + tp->snd_bwnd += tp->t_maxseg; + break; + case 0x04: + /* + * If the bandwidth does not go up by at least maxseg / 4, + * cycle back to neutral. + */ + if (tp->snd_bandwidth <= tp->t_bw_bandwidth + tp->t_maxseg / 4) + tp->snd_bwnd -= tp->t_maxseg; + break; + case 0x08: + /* + * Save the bandwidth and decrease bwnd. + */ + tp->t_bw_bandwidth = tp->snd_bandwidth; + tp->snd_bwnd -= tp->t_maxseg; + break; + case 0x0C: + /* + * If the bandwidth goes down by more then maxseg / 4, + * cycle back to neutral. Otherwise keep the change. + * + * Note: in the bwnd-too-high case the bandwidth does not + * usually change much so we tend to keep the change, + * which means we tend to decrease bwnd. This stabilizes + * the algorithm. + */ + if (tp->snd_bandwidth <= tp->t_bw_bandwidth - tp->t_maxseg / 4) + tp->snd_bwnd += tp->t_maxseg; + break; + default: + break; /* no action */ + } + if (tcp_inflight_debug) { + static int ltick; + if ((unsigned int)(ticks - ltick) > hz) { + printf("BW %ld (%ld) BWND %d srtt %d\n", + tp->snd_bandwidth, bw, tp->snd_bwnd, tp->t_srtt); + ltick = ticks; + } + } + if (tp->snd_bwnd < tcp_inflight_min) + tp->snd_bwnd = tcp_inflight_min; + if (tp->snd_bwnd < tp->t_maxseg * 2) + tp->snd_bwnd = tp->t_maxseg * 2; + if (tp->snd_bwnd > tcp_inflight_max) + tp->snd_bwnd = tcp_inflight_max; +} + Index: tcp_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_usrreq.c,v retrieving revision 1.76 diff -u -r1.76 tcp_usrreq.c --- tcp_usrreq.c 13 Jun 2002 23:14:58 -0000 1.76 +++ tcp_usrreq.c 20 Jul 2002 00:38:16 -0000 @@ -875,6 +875,7 @@ tp->t_state = TCPS_SYN_SENT; callout_reset(tp->tt_keep, tcp_keepinit, tcp_timer_keep, tp); tp->iss = tcp_new_isn(tp); + tp->t_bw_rtseq = tp->iss; tcp_sendseqinit(tp); /* @@ -961,6 +962,7 @@ tp->t_state = TCPS_SYN_SENT; callout_reset(tp->tt_keep, tcp_keepinit, tcp_timer_keep, tp); tp->iss = tcp_new_isn(tp); + tp->t_bw_rtseq = tp->iss; tcp_sendseqinit(tp); /* Index: tcp_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v retrieving revision 1.82 diff -u -r1.82 tcp_var.h --- tcp_var.h 19 Jul 2002 18:27:39 -0000 1.82 +++ tcp_var.h 20 Jul 2002 00:38:17 -0000 @@ -124,10 +124,12 @@ u_long snd_wnd; /* send window */ u_long snd_cwnd; /* congestion-controlled window */ + u_long snd_bwnd; /* bandwidth-controlled window */ u_long snd_ssthresh; /* snd_cwnd size threshold for * for slow start exponential to * linear switch */ + u_long snd_bandwidth; /* calculated bandwidth or 0 */ tcp_seq snd_recover; /* for use in fast recovery */ u_int t_maxopd; /* mss plus options */ @@ -137,6 +139,11 @@ int t_rtttime; /* round trip time */ tcp_seq t_rtseq; /* sequence number being timed */ + int t_bw_rtttime; /* used for bandwidth calculation */ + tcp_seq t_bw_rtseq; /* used for bandwidth calculation */ + int t_bw_state; /* used for snd_bwnd calculation */ + u_long t_bw_bandwidth; /* used for snd_bwnd calculation */ + int t_rxtcur; /* current retransmit value (ticks) */ u_int t_maxseg; /* maximum segment size */ int t_srtt; /* smoothed round-trip time */ @@ -473,6 +480,7 @@ struct tcpcb * tcp_timers(struct tcpcb *, int); void tcp_trace(int, int, struct tcpcb *, void *, struct tcphdr *, int); +void tcp_xmit_bandwidth_limit(struct tcpcb *tp, tcp_seq ack_seq); void syncache_init(void); void syncache_unreach(struct in_conninfo *, struct tcphdr *); int syncache_expand(struct in_conninfo *, struct tcphdr *, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 19 19: 4:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25CB437B400 for ; Fri, 19 Jul 2002 19:04:48 -0700 (PDT) Received: from garrincha.netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by mx1.FreeBSD.org (Postfix) with SMTP id F2C7943E5E for ; Fri, 19 Jul 2002 19:04:45 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: (qmail 9350 invoked by uid 84); 20 Jul 2002 02:08:37 -0000 Received: from riel@conectiva.com.br by garrincha.netbank.com.br with qmail-scanner-1.01 (. Clean. Processed in 0.367329 secs); 20 Jul 2002 02:08:37 -0000 Received: from 2-110.ctame701-1.telepar.net.br (abcghl@200.193.160.110) by garrincha.netbank.com.br with SMTP; 20 Jul 2002 02:08:37 -0000 Received: from localhost ([IPv6:::ffff:127.0.0.1]:24525 "EHLO localhost") by imladris.surriel.com with ESMTP id ; Fri, 19 Jul 2002 23:04:17 -0300 Date: Fri, 19 Jul 2002 23:04:12 -0300 (BRT) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: Matthew Dillon Cc: freebsd-hackers@freebsd.org, Subject: Re: Another go at bandwidth delay product pipeline limiting for TCP In-Reply-To: <200207200103.g6K135Ap081155@apollo.backplane.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.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 On Fri, 19 Jul 2002, Matthew Dillon wrote: > Note that this is a transmitter-side solution, not a receiver-side > solution. This will not help your typing if you are downloading a > lot of stuff and the remote end builds up a lot of packets on your > ISP's router. Theoretically we should be able to also restrict the > window we advertise but that is a much more difficult problem. It's not too hard actually. Random early drop should be enough for incoming packets, just artificially restrict the bandwidth to something like 90% of your maximum download bandwidth and drop packets that come in too fast. This will cause tcp to slow down to the speed limit you've chosen and the ISP queue will never fill up. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 19 19:45:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BB7637B400; Fri, 19 Jul 2002 19:45:25 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72CF443E31; Fri, 19 Jul 2002 19:45:25 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g6K2jHCV081550; Fri, 19 Jul 2002 19:45:17 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g6K2jHOh081549; Fri, 19 Jul 2002 19:45:17 -0700 (PDT) (envelope-from dillon) Date: Fri, 19 Jul 2002 19:45:17 -0700 (PDT) From: Matthew Dillon Message-Id: <200207200245.g6K2jHOh081549@apollo.backplane.com> To: Rik van Riel Cc: freebsd-hackers@FreeBSD.ORG, Subject: Re: Another go at bandwidth delay product pipeline limiting for TCP References: 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 :It's not too hard actually. Random early drop should be :enough for incoming packets, just artificially restrict :the bandwidth to something like 90% of your maximum :download bandwidth and drop packets that come in too :fast. : :This will cause tcp to slow down to the speed limit you've :chosen and the ISP queue will never fill up. : :regards, : :Rik As a receive side mechanism the idea has merit, but I really dislike artificallly dropping packets as a means of controlling TCP. It's impossible to know what the effect of the drop would have on the remote host's protocol stack. Controlling the remote transmitter by having the receiver change it's window advertisement seems to be a safer route. I may take up the receive-side problem after I get the transmit side down. I still have a lot of work to do on the transmit side. It still takes a little too long to lock onto the correct bandwidth, and interactive traffic will confuse it (though that is one of the reasons why one should set a fairly high minimum, like 4K-8K or so). Your comment on limiting the bandwidth to 90% of maximum is really humerous to me! I spent good two hours trying to get the sender-side algorithm to maintain >90% maximum available bandwidth. The algorithm I am using winds up being the most stable at around 88% and it took a bit of messing around to get it to stabilize at > 90%. I expect a receiver side algorithm would have the same problem. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 19 20:14: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC3B337B400 for ; Fri, 19 Jul 2002 20:13:57 -0700 (PDT) Received: from garrincha.netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by mx1.FreeBSD.org (Postfix) with SMTP id 2609F43E64 for ; Fri, 19 Jul 2002 20:13:56 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: (qmail 26877 invoked by uid 84); 20 Jul 2002 03:17:48 -0000 Received: from riel@conectiva.com.br by garrincha.netbank.com.br with qmail-scanner-1.01 (. Clean. Processed in 0.717816 secs); 20 Jul 2002 03:17:48 -0000 Received: from 2-110.ctame701-1.telepar.net.br (itdijx@200.193.160.110) by garrincha.netbank.com.br with SMTP; 20 Jul 2002 03:17:47 -0000 Received: from localhost ([IPv6:::ffff:127.0.0.1]:17116 "EHLO localhost") by imladris.surriel.com with ESMTP id ; Sat, 20 Jul 2002 00:12:51 -0300 Date: Sat, 20 Jul 2002 00:12:46 -0300 (BRT) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, Subject: Re: Another go at bandwidth delay product pipeline limiting for TCP In-Reply-To: <200207200245.g6K2jHOh081549@apollo.backplane.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.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 On Fri, 19 Jul 2002, Matthew Dillon wrote: > :It's not too hard actually. Random early drop should be > :enough for incoming packets, just artificially restrict > :the bandwidth to something like 90% of your maximum > :download bandwidth and drop packets that come in too > :fast. > : > :This will cause tcp to slow down to the speed limit you've > :chosen and the ISP queue will never fill up. > > As a receive side mechanism the idea has merit, but I really > dislike artificallly dropping packets as a means of controlling > TCP. It's impossible to know what the effect of the drop would > have on the remote host's protocol stack. I agree it's pretty crude, but it seems to work wonders on my DSL line. I'm using a slightly changed version of the wondershaper script (for Linux)... > Your comment on limiting the bandwidth to 90% of maximum is > really humerous to me! I spent good two hours trying to get > the sender-side algorithm to maintain >90% maximum available > bandwidth. The algorithm I am using winds up being the most stable > at around 88% and it took a bit of messing around to get it > to stabilize at > 90%. I expect a receiver side algorithm would > have the same problem. Absolutely. On my DSL things work best when I limit myself to 220 kbit/s down (from the maximum 256 kbit/s), or about 85% of the bandwidth. For sending I'm using cbq as the top scheduler, dividing traffic in the categories 'interactive', 'bulk' and 'traffic we hate', each of these has a token bucket filter (tbf) leaf scheduler to keep latencies down. Sending is also limited to about 85% of the bandwidth. OTOH, the DSL hardware here seems to be a bit broken, fast uploads seem to interfere with the download and break the download speed. I can run one-way traffic with low latency all the way up to about 95% of the bandwidth... regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 19 20:46: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33B1937B400 for ; Fri, 19 Jul 2002 20:45:59 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E90F43E5E for ; Fri, 19 Jul 2002 20:45:58 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.5) with ESMTP id g6K3jiqw017054 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 19 Jul 2002 23:45:45 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.3/Submit) id g6K3jise017051; Fri, 19 Jul 2002 23:45:44 -0400 (EDT) (envelope-from wollman) Date: Fri, 19 Jul 2002 23:45:44 -0400 (EDT) From: Garrett Wollman Message-Id: <200207200345.g6K3jise017051@khavrinen.lcs.mit.edu> To: Rik van Riel Cc: freebsd-net@FreeBSD.ORG Subject: Re: Another go at bandwidth delay product pipeline limiting for TCP In-Reply-To: References: <200207200245.g6K2jHOh081549@apollo.backplane.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Absolutely. On my DSL things work best when I limit myself > to 220 kbit/s down (from the maximum 256 kbit/s), or about > 85% of the bandwidth. That is hardly surprising. In fact, that is a well-known result of Queueing Theory. It is impossible to achive better than 85-90% utilization in the presence of appreciable non-scheduled traffic competing for the same channel. (That's a big part of why protocols like ATM were designed to require everything to go through admission control and shaping: otherwise you can't make tight guarantees of latency and drop rates while still maximizing channel utilization.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 20 0:20:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19D2C37B400; Sat, 20 Jul 2002 00:20:12 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 705F843E3B; Sat, 20 Jul 2002 00:20:11 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020720072010.HCZT6023.sccrmhc02.attbi.com@InterJet.elischer.org>; Sat, 20 Jul 2002 07:20:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA93310; Sat, 20 Jul 2002 00:05:18 -0700 (PDT) Date: Sat, 20 Jul 2002 00:05:16 -0700 (PDT) From: Julian Elischer To: Rik van Riel Cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Another go at bandwidth delay product pipeline limiting for TCP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 20 Jul 2002, Rik van Riel wrote: > On Fri, 19 Jul 2002, Matthew Dillon wrote: I once wrote a traffic shaper to allow people sharing a link to be able to keep interractive responses good while someone else is FTPing a big file in.. the theory was that teh line becomes unresponsive because the majority of teh window is sitting in the send queue on the internet side of the slow link to the custommer. The answer was to artificially meter out the acks going back to the ftp bulk data source. basically instead of queueing incoming data (well you could do that too,) I queued the outgoing acks and clocked them out by only allowing an ack to be released and forwarded, when my own 'metered simulation' of the ack rate had passed the ack in the packet.. It had the desired affect... With propper tuning you can keep the send queue at the far end of your slow link to 1 or two packets and interactive sessions (which were accounted for, but not controlled) became 'interactive' again despite the existance of the parallel ftp session using most of the bandwidth. Whistle/IBM was going to try for a patent (silly idea I think). I wonder if they ever did..? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 20 0:25:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D7FA37B400; Sat, 20 Jul 2002 00:25:50 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89DB243E4A; Sat, 20 Jul 2002 00:25:49 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g6K7PFp40879; Sat, 20 Jul 2002 00:25:15 -0700 (PDT) (envelope-from rizzo) Date: Sat, 20 Jul 2002 00:25:15 -0700 From: Luigi Rizzo To: Julian Elischer Cc: Rik van Riel , Matthew Dillon , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Another go at bandwidth delay product pipeline limiting for TCP Message-ID: <20020720002515.A40795@iguana.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Sat, Jul 20, 2002 at 12:05:16AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Jul 20, 2002 at 12:05:16AM -0700, Julian Elischer wrote: ... > I queued the outgoing acks and clocked them out by only allowing an ack to > be released and forwarded, when my own 'metered simulation' of the ack > rate had passed the ack in the packet.. It had the desired affect... ... this seems to be the same approach used by "Packeteer". Maybe they ended up patenting it :) On the other hand, you can achieve pretty much the same effect with dummynet, as you release incoming (bulky) packets at the desired rate. Both dummynet and your/packeteer approach cannot avoid the initial queue buildup at the far end, but they are 100% equivalent and usavble in the steady state (with responsive flows). cheers luigi > Whistle/IBM was going to try for a patent (silly idea I think). > I wonder if they ever did..? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 20 1:47:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6FBF37B400; Sat, 20 Jul 2002 01:47:43 -0700 (PDT) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BF5A43E4A; Sat, 20 Jul 2002 01:47:43 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0189.cvx40-bradley.dialup.earthlink.net ([216.244.42.189] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17Vptg-00041y-00; Sat, 20 Jul 2002 01:47:28 -0700 Message-ID: <3D392372.B744476C@mindspring.com> Date: Sat, 20 Jul 2002 01:46:42 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Rik van Riel , Matthew Dillon , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Another go at bandwidth delay product pipeline limiting for TCP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian Elischer wrote: > I once wrote a traffic shaper to allow people sharing a link to be able > to keep interractive responses good while someone else is FTPing > a big file in.. > the theory was that teh line becomes unresponsive because the > majority of teh window is sitting in the send queue on the internet side > of the slow link to the custommer. The answer was to artificially meter > out the acks going back to the ftp bulk data source. > basically instead of queueing incoming data (well you could do that too,) > I queued the outgoing acks and clocked them out by only allowing an ack to > be released and forwarded, when my own 'metered simulation' of the ack > rate had passed the ack in the packet.. It had the desired affect... > With propper tuning you can keep the send queue at the far end of your > slow link to 1 or two packets and interactive sessions (which were > accounted for, but not controlled) became 'interactive' again > despite the existance of the parallel ftp session using most of the > bandwidth. > > Whistle/IBM was going to try for a patent (silly idea I think). > I wonder if they ever did..? As primary author, you would have to sign the filing forms, and then assign it to IBM with another set of forms, since a company is not legally permitted to be named as "inventor". Ask Archie and Paul and Jim what they had to do for the ACL patent (which was granted to them, and assigned to IBM). So if you don't have a patent on it, they don't have a patent on it. 8-). I think the reason this is coming up now is that there was a recent thread on Slashdot where someone was asking for a Windows "traffic shaper" for a DSL line. Let's ignore for the moment that no one has the source code to the Windows TCP stack except Microsoft and there're very few people it has licensed the code to (last time I checked, a Windows source licence was a significant fraction of a billion dollars; there's only one company that has a piecemeal license agreement that lets them get NT source code for a per chunk fee significantly less than licensing the whole thing; last I heard, Microsoft was in negotiations to buy them). In that case, the upstream bandwidth was being limited by a device that lives one or two hops past the customer premesis equipment, and there's really no way you could control it, unless there was a stream protocol involved, and your control mechanism was stateful base on that. The problem was that the outbound ACKs were delayed or dropped, and the incoming asymmertric bandwidth (1.5Mbit diwn, 96Kbit up) was under utilised. In a perfect world, with no dropping, and a fully asymetric transfer (e.g. data in the downchannel, no data in the upchannel, so MTU is 1500 bytes and ACK pakets up were 60 bytes, you are talking fully 2/3rds if the upchannel being needed for *nothing but ACK traffic for downchannel data*. But since you can't distinguish packets, except by length, and the protocols involved were likely not over TCP (RTSP or UDP based streaming), there was no way to favor payload less outbound ACK packets over other traffic. before the outbound queue at the bandwidth delay device saturated and killed your downchannel. Knowing the BWDP, as Matt suggests, lets you calculate the percentage you need to reserve fairly accurately, but really doesn't let you do anything about it, since the buffers you need to control are several hops away. Unfortunately, your approach would not work in this case, or I would have mentioned you as someone to contact about solving the problem. The real problem is that you have to know too much about the data channels involved to be able to do this... unless you *are* the bandwidth limiting device, itself. And that's where the fix needs to go. Basically, the DSL provider in the example case needed to pay more money for their equipment than they did. Even limiting locally to the rate you know you are limited to remotely doesn't really work -- because the throughput, and therefore the ability of the remote end to drain the buffers on the limiter device is dictated by the full path, not just the limiter, so if the limiter was not the "limiting factor" (har! 8-)) for a given link, then you are still going to fill the buffers with packets which are not ACKs for data coming down your faster downchannel. It's a really ugly artificial problem. You have to think that the fact that the upstream is 150% of what it would need to be to keep the downstream fully saturated, IFF the upstream's *only* payload was ACK packets for the downstream, has to be more than simple coincidence. The best "gross hack fix" I could think of for it would be to set the outbound window size to 1 packet. Not very satisfying, for a lot of reasons. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 20 4:47:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41C0B37B405 for ; Sat, 20 Jul 2002 04:47:33 -0700 (PDT) Received: from mail.dada.it (mail2.dada.it [195.110.96.69]) by mx1.FreeBSD.org (Postfix) with SMTP id B7D3043E72 for ; Sat, 20 Jul 2002 04:47:30 -0700 (PDT) (envelope-from ale@unixmania.net) Received: (qmail 18744 invoked from network); 20 Jul 2002 11:46:07 -0000 Received: from unknown (HELO libero.sunshine.ale) (195.110.114.252) by mail.dada.it with SMTP; 20 Jul 2002 11:46:07 -0000 Received: by libero.sunshine.ale (Postfix, from userid 1001) id 1E5805FA4; Sat, 20 Jul 2002 13:46:09 +0200 (CEST) Date: Sat, 20 Jul 2002 13:46:09 +0200 From: Alessandro de Manzano To: net@freebsd.org Subject: IPSec NAT Traversal ? Message-ID: <20020720134609.A41761@libero.sunshine.ale> Reply-To: Alessandro de Manzano Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Operating-System: FreeBSD 4.6-STABLE 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 would setup an IPSec VPN between my home network and company's one. On both ends I've FreeBSD 4.x servers. On server side I've a bunch of public static IP addresses and on client (home) side I've an ADSL connection with one static IP address. Such IP is assigned to the router which also is NATting the traffic, as usual. This situation is not IPSec compatible, but I've been told that SSH Inc. sell a "NAT Traversal Toolkit" compatbile with IPSec VPNs. Its whitepaper tells this NAT-T solution is an IETF draft (draft-stenberg-ipsec-nat-traversal-02 , Feb 2001) so I wonder if there already are some free, public alternatives to the SSH Inc. ones... Thanks in advance for your hints ! -- bye! Ale To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 20 7:30: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC87C37B400 for ; Sat, 20 Jul 2002 07:29:56 -0700 (PDT) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27F5543E31 for ; Sat, 20 Jul 2002 07:29:56 -0700 (PDT) (envelope-from barney@databus.com) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.5/8.12.5) with ESMTP id g6KETtvG006672; Sat, 20 Jul 2002 10:29:55 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.5/8.12.5/Submit) id g6KETtIk006671; Sat, 20 Jul 2002 10:29:55 -0400 (EDT) Date: Sat, 20 Jul 2002 10:29:55 -0400 From: Barney Wolff To: Alessandro de Manzano Cc: net@FreeBSD.ORG Subject: Re: IPSec NAT Traversal ? Message-ID: <20020720142955.GA6536@tp.databus.com> References: <20020720134609.A41761@libero.sunshine.ale> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020720134609.A41761@libero.sunshine.ale> User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The general case, where there are multiple IPsec speakers behind multiple NATs, is what's not possible without special not-yet-standard effort. But a single IPsec speaker behind a client NAT on one side works fine. I routinely talk IPsec using the Nortel Contivity client on W2K to "a major financial institution" through my FBSD router/firewall/NAT, and it works fine. The only snag was that natd's keepalive timeouts are not adjustable, and rather than fiddle with the code I just run a slow ping from my W2K to the other side to keep the NAT state from being flushed. Tcpdump verifies that it really is ESP that's being sent and received. AH would be another story, but is not used by the Nortel stuff, and probably not by others either. On Sat, Jul 20, 2002 at 01:46:09PM +0200, Alessandro de Manzano wrote: > > I would setup an IPSec VPN between my home network and company's one. > On both ends I've FreeBSD 4.x servers. > > On server side I've a bunch of public static IP addresses and on client > (home) side I've an ADSL connection with one static IP address. > > Such IP is assigned to the router which also is NATting the traffic, as > usual. > > This situation is not IPSec compatible, but I've been told that SSH > Inc. sell a "NAT Traversal Toolkit" compatbile with IPSec VPNs. > > Its whitepaper tells this NAT-T solution is an IETF draft > (draft-stenberg-ipsec-nat-traversal-02 , Feb 2001) so I wonder if there > already are some free, public alternatives to the SSH Inc. ones... -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 20 9:12:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6F8237B400; Sat, 20 Jul 2002 09:12:29 -0700 (PDT) Received: from patrocles.silby.com (d165.as12.nwbl0.wi.voyager.net [169.207.136.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FB0E43E42; Sat, 20 Jul 2002 09:12:28 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g6KGGacv099548; Sat, 20 Jul 2002 11:16:36 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.5/8.12.5/Submit) with ESMTP id g6KGGTeD099545; Sat, 20 Jul 2002 11:16:31 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Sat, 20 Jul 2002 11:16:29 -0500 (CDT) From: Mike Silbersack To: Luigi Rizzo Cc: Julian Elischer , Rik van Riel , Matthew Dillon , , Subject: Re: Another go at bandwidth delay product pipeline limiting for TCP In-Reply-To: <20020720002515.A40795@iguana.icir.org> Message-ID: <20020720111335.V99536-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 20 Jul 2002, Luigi Rizzo wrote: > this seems to be the same approach used by "Packeteer". Maybe they > ended up patenting it :) Packeteer? Here's my commentary on Packeteer: DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE (That was censored, I have much better words for them.) (Part of this anger may be due to having been behind a Packeteer box which made the campus resnet slower than a 56K modem during peak hours.) As a result of that experience, I have serious doubts about rolling out such an algorithm on the internet at large. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 20 18:45: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA18137B400 for ; Sat, 20 Jul 2002 18:45:03 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A2CD43E58 for ; Sat, 20 Jul 2002 18:45:03 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id SAA49149; Sat, 20 Jul 2002 18:44:10 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g6L1hIF74872; Sat, 20 Jul 2002 18:43:18 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200207210143.g6L1hIF74872@arch20m.dellroad.org> Subject: Re: mpd and bringing up routes at connect time In-Reply-To: <5.1.0.14.0.20020716111422.07bc1498@marble.sentex.ca> "from Mike Tancsa at Jul 16, 2002 11:21:21 am" To: Mike Tancsa Date: Sat, 20 Jul 2002 18:43:18 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Tancsa writes: > Is there any way with mpd to automatically bring up a route when a customer > connects using pptp where multiple users are connecting ? The problem I > am running into is that user X will PPTP into the server. As they will come > in on different netgraph interfaces, the route needs to be pointed to a > different netgraph interface each time. If each user always connects from the same, distinct IP address then the answer is yes - just allocate a separate bundle for each user. Otherwise, mpd doesn't support doing that. It wouldn't be too difficult of a hack though, to add a route to the mpd.secrets file in the same way that you can add an IP address. > Specifically, how do I add n routes to user X's connection on demand. Is > it possible with mpd ? If you know the bundle that will be chosen ahead of time (same thing as knowing the client's IP address ahead of time, as mentioned above) then just use the 'set iface route ...' command. Otherwise, you can't currently do it. -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 Sat Jul 20 18:47:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3ADAB37B400 for ; Sat, 20 Jul 2002 18:47:49 -0700 (PDT) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id A683443E42 for ; Sat, 20 Jul 2002 18:47:48 -0700 (PDT) (envelope-from mike@sentex.net) Received: from house (cage.simianscience.com [64.7.134.1]) by smtp2.sentex.ca (8.12.5/8.12.4) with SMTP id g6L1llCE019202; Sat, 20 Jul 2002 21:47:47 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: shubha mr Cc: freebsd-net@freebsd.org Subject: Re: VLAN - testing-urgent! Date: Sat, 20 Jul 2002 21:48:05 -0400 Message-ID: References: <20020719054804.78353.qmail@web14609.mail.yahoo.com> In-Reply-To: <20020719054804.78353.qmail@web14609.mail.yahoo.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 quick example... Use a NIC that is vlan capable. e.g. fxp is very good. Get a 802.1q VLAN capable switch (e.g. a cisco 29xx) in port 1 plug in your fxp card On the Cisco (IP address 10.1.1.2 netmask 255.255.255.252), do something like interface FastEthernet0/1 description vlan trunking port duplex full speed 100 switchport trunk encapsulation dot1q switchport trunk allowed vlan 1,100,101 switchport mode trunk interface FastEthernet0/2 description the-192-network switchport access vlan 100 interface FastEthernet0/3 description the-17-network switchport access vlan 101 On the FreeBSD box (with a kernel entry of pseudo-device vlan 1) =20 ifconfig fxp0 10.1.1.1 netmask 255.255.255.252 media 100baseTX mediaopt full-duplex ifconfig vlan0 192.168.1.1 netmask 255.255.255.0 vlan 100 vlandev fxp0 = mtu 1500 up ifconfig vlan1 create ifconfig vlan1 172.16.1.1 netmask 255.255.255.0 vlan 101 vlandev fxp0 mtu 1500 up ---Mike On Fri, 19 Jul 2002 06:48:04 +0100 (BST), in sentex.lists.freebsd.net you wrote: >Hi, >Would like to know how to test VLAN for ethernet >network driver for a NIC. > >Thanks a lot >shubha > >__________________________________________________ >Do You Yahoo!? >Yahoo! Autos - Get free new car price quotes >http://autos.yahoo.com > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 20 19: 0: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED58937B400 for ; Sat, 20 Jul 2002 18:59:55 -0700 (PDT) Received: from cage.simianscience.com (cage.simianscience.com [64.7.134.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1602043E42 for ; Sat, 20 Jul 2002 18:59:55 -0700 (PDT) (envelope-from mike@sentex.net) Received: from house.sentex.net (fcage [192.168.0.2]) by cage.simianscience.com (8.12.5/8.12.3) with ESMTP id g6L1xnrw039065; Sat, 20 Jul 2002 21:59:50 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020720215920.07694b88@192.168.0.12> X-Sender: mdtancsa@192.168.0.12 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 20 Jul 2002 22:00:06 -0400 To: Archie Cobbs From: Mike Tancsa Subject: Re: mpd and bringing up routes at connect time Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <200207210143.g6L1hIF74872@arch20m.dellroad.org> References: <5.1.0.14.0.20020716111422.07bc1498@marble.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: amavis-20020220 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 for the clarification. I think I will try and take your suggestion and see about adding a route at connect time via the secrets file. ---Mike At 06:43 PM 7/20/2002 -0700, Archie Cobbs wrote: >Mike Tancsa writes: > > Is there any way with mpd to automatically bring up a route when a > customer > > connects using pptp where multiple users are connecting ? The problem I > > am running into is that user X will PPTP into the server. As they will > come > > in on different netgraph interfaces, the route needs to be pointed to a > > different netgraph interface each time. > >If each user always connects from the same, distinct IP address then >the answer is yes - just allocate a separate bundle for each user. > >Otherwise, mpd doesn't support doing that. It wouldn't be too difficult >of a hack though, to add a route to the mpd.secrets file in the same way >that you can add an IP address. > > > Specifically, how do I add n routes to user X's connection on demand. Is > > it possible with mpd ? > >If you know the bundle that will be chosen ahead of time (same thing >as knowing the client's IP address ahead of time, as mentioned above) >then just use the 'set iface route ...' command. Otherwise, you can't >currently do it. > >-Archie > >__________________________________________________________________________ >Archie Cobbs * Packet Design * http://www.packetdesign.com -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 20 19:36:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C6D037B400; Sat, 20 Jul 2002 19:36:02 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09BA543E31; Sat, 20 Jul 2002 19:36:02 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g6L2a1CV000271; Sat, 20 Jul 2002 19:36:01 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g6L2a11a000270; Sat, 20 Jul 2002 19:36:01 -0700 (PDT) (envelope-from dillon) Date: Sat, 20 Jul 2002 19:36:01 -0700 (PDT) From: Matthew Dillon Message-Id: <200207210236.g6L2a11a000270@apollo.backplane.com> To: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Bandwidth delay product limiting for TCP - update. 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 Ok, I've done a bunch more work. I've simplified the code enormously. Basically what it does now is calculate the window size based on the current bandwidth and the best RTT it's ever seen. This will handle: (1) Limiting packet queueing to just the amount required to fill the pipe. (2) Reducing the window if the network load increases. (3) Partial ability to handle changes in latency which do not effect the bandwidth carrying capacity of the network. #4 is the most difficult problem to deal with because calculating the window based on SRTT is a positive-feedback loop. i.e. a larger window results in a larger SRTT which results in a larger window. So I can't just use SRTT. Instead I use ((SRTT + RTTBEST) / 2) for the RTT portion of the calculation. This has the effect of allowing the algorithm to compensate for the increased latencies but providing negative bias that increases as the window increases, stabilizing the calculation of the window. I think this may be good enough to commit but I would really like as many people as possible to test it in real life situations (keeping in mind that it only effects the transmit side). I believe I have solved just about all the problems that I had with previous versions. An the damn thing is actually clean(!). -Matt Index: tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.165 diff -u -r1.165 tcp_input.c --- tcp_input.c 19 Jul 2002 18:27:39 -0000 1.165 +++ tcp_input.c 21 Jul 2002 02:32:57 -0000 @@ -1008,6 +1008,7 @@ else if (tp->t_rtttime && SEQ_GT(th->th_ack, tp->t_rtseq)) tcp_xmit_timer(tp, ticks - tp->t_rtttime); + tcp_xmit_bandwidth_limit(tp, th->th_ack); acked = th->th_ack - tp->snd_una; tcpstat.tcps_rcvackpack++; tcpstat.tcps_rcvackbyte += acked; @@ -1805,6 +1806,7 @@ tcp_xmit_timer(tp, ticks - to.to_tsecr + 1); else if (tp->t_rtttime && SEQ_GT(th->th_ack, tp->t_rtseq)) tcp_xmit_timer(tp, ticks - tp->t_rtttime); + tcp_xmit_bandwidth_limit(tp, th->th_ack); /* * If all outstanding data is acked, stop retransmit @@ -2431,6 +2433,8 @@ delta -= tp->t_rttvar >> (TCP_RTTVAR_SHIFT - TCP_DELTA_SHIFT); if ((tp->t_rttvar += delta) <= 0) tp->t_rttvar = 1; + if (tp->t_rttbest > tp->t_srtt + tp->t_rttvar) + tp->t_rttbest = tp->t_srtt + tp->t_rttvar; } else { /* * No rtt measurement yet - use the unsmoothed rtt. @@ -2439,6 +2443,7 @@ */ tp->t_srtt = rtt << TCP_RTT_SHIFT; tp->t_rttvar = rtt << (TCP_RTTVAR_SHIFT - 1); + tp->t_rttbest = tp->t_srtt + tp->t_rttvar; } tp->t_rtttime = 0; tp->t_rxtshift = 0; @@ -2578,6 +2583,7 @@ if (rt->rt_rmx.rmx_locks & RTV_RTT) tp->t_rttmin = rtt / (RTM_RTTUNIT / hz); tp->t_srtt = rtt / (RTM_RTTUNIT / (hz * TCP_RTT_SCALE)); + tp->t_rttbest = tp->t_srtt + TCP_RTT_SCALE; tcpstat.tcps_usedrtt++; if (rt->rt_rmx.rmx_rttvar) { tp->t_rttvar = rt->rt_rmx.rmx_rttvar / Index: tcp_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v retrieving revision 1.65 diff -u -r1.65 tcp_output.c --- tcp_output.c 23 Jun 2002 21:25:36 -0000 1.65 +++ tcp_output.c 21 Jul 2002 02:32:57 -0000 @@ -164,6 +164,7 @@ sendalot = 0; off = tp->snd_nxt - tp->snd_una; win = min(tp->snd_wnd, tp->snd_cwnd); + win = min(win, tp->snd_bwnd); flags = tcp_outflags[tp->t_state]; /* @@ -773,7 +774,7 @@ tp->snd_max = tp->snd_nxt; /* * Time this transmission if not a retransmission and - * not currently timing anything. + * not currently timing anything. */ if (tp->t_rtttime == 0) { tp->t_rtttime = ticks; Index: tcp_subr.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.137 diff -u -r1.137 tcp_subr.c --- tcp_subr.c 18 Jul 2002 19:06:12 -0000 1.137 +++ tcp_subr.c 21 Jul 2002 02:32:57 -0000 @@ -144,6 +144,32 @@ SYSCTL_INT(_net_inet_tcp, OID_AUTO, isn_reseed_interval, CTLFLAG_RW, &tcp_isn_reseed_interval, 0, "Seconds between reseeding of ISN secret"); +static int tcp_inflight_enable = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_enable, CTLFLAG_RW, + &tcp_inflight_enable, 0, "Enable automatic TCP inflight data limiting"); + +static int tcp_inflight_debug = 1; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_debug, CTLFLAG_RW, + &tcp_inflight_debug, 0, "Debug TCP inflight calculations"); + +static int tcp_inflight_min = 1024; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_min, CTLFLAG_RW, + &tcp_inflight_min, 0, "Lower-bound for TCP inflight window"); + +static int tcp_inflight_max = TCP_MAXWIN << TCP_MAX_WINSHIFT; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_max, CTLFLAG_RW, + &tcp_inflight_max, 0, "Upper-bound for TCP inflight window"); + +#if 0 +static int tcp_inflight_attack = 20; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_attack, CTLFLAG_RW, + &tcp_inflight_attack, 0, "TCP inflight compensation attack rate (%)"); + +static int tcp_inflight_shift = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_shift, CTLFLAG_RW, + &tcp_inflight_shift, 0, "TCP inflight compensation shift (+/-100) "); +#endif + static void tcp_cleartaocache(void); static struct inpcb *tcp_notify(struct inpcb *, int); @@ -547,8 +573,10 @@ tp->t_rttmin = tcp_rexmit_min; tp->t_rxtcur = TCPTV_RTOBASE; tp->snd_cwnd = TCP_MAXWIN << TCP_MAX_WINSHIFT; + tp->snd_bwnd = TCP_MAXWIN << TCP_MAX_WINSHIFT; tp->snd_ssthresh = TCP_MAXWIN << TCP_MAX_WINSHIFT; tp->t_rcvtime = ticks; + tp->t_bw_rtttime = ticks; /* * IPv4 TTL initialization is necessary for an IPv6 socket as well, * because the socket may be bound to an IPv6 wildcard address, @@ -1509,3 +1537,102 @@ tcp_cleartaocache() { } + +/* + * This code attempts to calculate the bandwidth-delay product. + * The problem with calculating this product is that our manipulation + * of the congestion window modifies both the perceived bandwidth + * and the srtt. It is possible to get a fairly stable maximal + * bandwidth by increasing the congestion window. The bandwidth + * calculation will be fairly good even if bwnd is set very high. + * However, figuring out the minimal srtt is far more difficult + * because we do not want the TCP stream to suffer greatly and therefore + * cannot reduce the congestion window to something very small. + * + * What we do is first increase the congestion window to try to + * obtain a maximal (or at least a 'larger') bandwidth, then decrease + * the congestion window to try to obtain a minimal (or at least a 'smaller') + * rtt. We also have to detect the case where BWND is too high and + * neither increasing nor decreasing it has the desired effect on the + * calculation. By detecting this special case we can stabilize the + * algorithm and recalculate bwnd within a reasonable period of time. + */ +void +tcp_xmit_bandwidth_limit(struct tcpcb *tp, tcp_seq ack_seq) +{ + u_long bw; + u_long bwnd; + int save_ticks; + + /* + * If inflight_enable is disabled in the middle of a tcp connection, + * make sure snd_bwnd is effectively disabled. + */ + if (tcp_inflight_enable == 0) { + tp->snd_bwnd = TCP_MAXWIN << TCP_MAX_WINSHIFT; + tp->snd_bandwidth = 0; + return; + } + + /* + * Figure out the bandwidth. Due to the tick granularity this + * is a very rough number and it MUST be averaged over a fairly + * long period of time. + */ + save_ticks = ticks; + n = save_ticks - tp->t_bw_rtttime; + if ((u_int)n < 1) + return; + + bw = (int64_t)(ack_seq - tp->t_bw_rtseq) * hz / + (save_ticks - tp->t_bw_rtttime); + tp->t_bw_rtttime = save_ticks; + tp->t_bw_rtseq = ack_seq; + if (tp->t_bw_rtttime == 0) + return; + bw = ((int64_t)tp->snd_bandwidth * 15 + bw) >> 4; + + tp->snd_bandwidth = bw; + + /* + * Calculate the semi-static bandwidth delay product, plus two maximal + * segments. The additional slop puts us squarely in the sweet + * spot and also handles the bandwidth run-up case. Without the + * slop we could be locking ourselves into a lower bandwidth. + * + * Situations Handled: + * (1) prevents over-queueing of packets on LANs, especially + * high speed LANs, allowing larger TCP buffers to be + * specified. + * + * (2) able to handle increased network loads (bandwidth drops + * so bwnd drops). + * + * (3) Randomly changes the window size in order to force + * bandwidth balancing between connections. + */ +#define USERTT ((tp->t_srtt + tp->t_rttbest) / 2) + bwnd = (int64_t)bw * USERTT / (hz << TCP_RTT_SHIFT) + 2 * tp->t_maxseg; + + if (tcp_inflight_debug > 0) { + static int ltime; + if ((u_int)(ticks - ltime) >= hz / tcp_inflight_debug) { + ltime = ticks; + printf("%p bw %ld rttbest %d srtt %d bwnd %ld\n", + tp, + bw, + tp->t_rttbest, + tp->t_srtt, + bwnd + ); + } + } + if ((long)bwnd < tcp_inflight_min) + bwnd = tcp_inflight_min; + if (bwnd > tcp_inflight_max) + bwnd = tcp_inflight_max; + if ((long)bwnd < tp->t_maxseg * 2) + bwnd = tp->t_maxseg * 2; + tp->snd_bwnd = bwnd; +} + Index: tcp_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_usrreq.c,v retrieving revision 1.76 diff -u -r1.76 tcp_usrreq.c --- tcp_usrreq.c 13 Jun 2002 23:14:58 -0000 1.76 +++ tcp_usrreq.c 21 Jul 2002 02:32:58 -0000 @@ -875,6 +875,7 @@ tp->t_state = TCPS_SYN_SENT; callout_reset(tp->tt_keep, tcp_keepinit, tcp_timer_keep, tp); tp->iss = tcp_new_isn(tp); + tp->t_bw_rtseq = tp->iss; tcp_sendseqinit(tp); /* @@ -961,6 +962,7 @@ tp->t_state = TCPS_SYN_SENT; callout_reset(tp->tt_keep, tcp_keepinit, tcp_timer_keep, tp); tp->iss = tcp_new_isn(tp); + tp->t_bw_rtseq = tp->iss; tcp_sendseqinit(tp); /* Index: tcp_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v retrieving revision 1.82 diff -u -r1.82 tcp_var.h --- tcp_var.h 19 Jul 2002 18:27:39 -0000 1.82 +++ tcp_var.h 21 Jul 2002 02:32:58 -0000 @@ -124,10 +124,12 @@ u_long snd_wnd; /* send window */ u_long snd_cwnd; /* congestion-controlled window */ + u_long snd_bwnd; /* bandwidth-controlled window */ u_long snd_ssthresh; /* snd_cwnd size threshold for * for slow start exponential to * linear switch */ + u_long snd_bandwidth; /* calculated bandwidth or 0 */ tcp_seq snd_recover; /* for use in fast recovery */ u_int t_maxopd; /* mss plus options */ @@ -137,6 +139,9 @@ int t_rtttime; /* round trip time */ tcp_seq t_rtseq; /* sequence number being timed */ + int t_bw_rtttime; /* used for bandwidth calculation */ + tcp_seq t_bw_rtseq; /* used for bandwidth calculation */ + int t_rxtcur; /* current retransmit value (ticks) */ u_int t_maxseg; /* maximum segment size */ int t_srtt; /* smoothed round-trip time */ @@ -144,6 +149,7 @@ int t_rxtshift; /* log(2) of rexmt exp. backoff */ u_int t_rttmin; /* minimum rtt allowed */ + u_int t_rttbest; /* best rtt we've seen */ u_long t_rttupdated; /* number of times rtt sampled */ u_long max_sndwnd; /* largest window peer has offered */ @@ -473,6 +479,7 @@ struct tcpcb * tcp_timers(struct tcpcb *, int); void tcp_trace(int, int, struct tcpcb *, void *, struct tcphdr *, int); +void tcp_xmit_bandwidth_limit(struct tcpcb *tp, tcp_seq ack_seq); void syncache_init(void); void syncache_unreach(struct in_conninfo *, struct tcphdr *); int syncache_expand(struct in_conninfo *, struct tcphdr *, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 20 20:33:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E044D37B400 for ; Sat, 20 Jul 2002 20:33:23 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09B9943E31 for ; Sat, 20 Jul 2002 20:33:23 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g6L3XAwr041931 for ; Sat, 20 Jul 2002 20:33:14 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200207210333.g6L3XAwr041931@gw.catspoiler.org> Date: Sat, 20 Jul 2002 20:33:10 -0700 (PDT) From: Don Lewis Subject: disabling IPv6 *without* recompiling the kernel To: 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 I've run into the same problems with Mozilla that many other people have reported. Even though I'm on an IPv4 only network, I'm seeing DNS lookups for AAAA records, many of which are timing out due to problems with the authoritative DNS servers. I'm also seeing long pauses when Mozilla attempts to connect to various web sites which I suspect are caused by Mozilla's attempts to connect to unreachable IPv6 addresses. The only reported solution is to recompile the kernel without the INET6 option, but this seems to be a pretty inconvenient workaround. It doesn't seem reasonable to require the large number of users who are connected to IPv4 only networks to compile custom kernels. This workaround is expecially inconvenient for mobile users who may migrate between network types and for users who might want to test IPv6 on their private networks but only have IPv4 connectivity to the outside world. While the Mozilla port doesn't currently use getipnodebyname(), it uses an equivalent algorithm to decide whether query for IPv4 or IPv6 addresses. Our implementation of getipnodebyname() contains the comment: /* * TODO: * Note that implementation dependent test for address * configuration should be done everytime called * (or apropriate interval), * because addresses will be dynamically assigned or deleted. */ but the test implemented in the code is just seeing whether socket(AF_INET6, SOCK_DGRAM, 0) succeeds. The problem is that this test always succeeds if the kernel is compiled with the INET6 socket even though ipv6_enable is set to "NO" in rc.conf and none of the interfaces have been configured with IPv6 addresses. This test is broken even in the static case. Should it be possible to create AF_INET6 sockets if none of the interfaces have been configured with IPv6 addresses? Is the ability to create AF_INET6 sockets the proper way to determine whether to query for IPv6 DNS records, or should there be some other method of determining this information? By default, all the interfaces get IPv6 addresses assigned even when ipv6_enable is set to "NO". Ethernet interfaces get link local addresses if net.inet6.ip6.auto_linklocal is left at it's default value of "1". Shouldn't this sysctl be set according to the value of ipv6_enable or some other configuration knob? The loopback interface unconditionally gets the IPv6 address assigned by in6_ifattach(). This is different than the IPv4 case, which requires the address to be assigned with ifconfig, and it also has problems if there are multiple loopback interfaces as noted by the XXX comment in the code. Ideally, getipnodebyname() should have some sort of fine grained control to tell it when it should query for and return IPv6 addresses so that the client doesn't waste a lot of time doing useless DNS lookups and attempting to connect to obviously unreachable addresses. In the mean time it would be nice to have an implemenation that wasn't so badly broken for the most common environment. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message