From owner-freebsd-net Sun Jan 5 3:18:38 2003 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 56A1F37B401 for ; Sun, 5 Jan 2003 03:18:31 -0800 (PST) Received: from basit.cc (wireless.cs.twsu.edu [156.26.10.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3B5543ED4 for ; Sun, 5 Jan 2003 03:18:30 -0800 (PST) (envelope-from basit@basit.cc) Received: from basit (helo=localhost) by basit.cc with local-esmtp (Exim 4.10) id 18V8oC-000CyZ-00 for net@freebsd.org; Sun, 05 Jan 2003 05:19:12 -0600 Date: Sun, 5 Jan 2003 05:19:12 -0600 (CST) From: Abdul Basit X-X-Sender: basit@wireless.cs.twsu.edu To: net@freebsd.org Subject: test Message-ID: <20030105051909.Y49882-100000@wireless.cs.twsu.edu> 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 3:30:51 2003 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 267C437B407 for ; Sun, 5 Jan 2003 03:30:43 -0800 (PST) Received: from basit.cc (wireless.cs.twsu.edu [156.26.10.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD50E43EC2 for ; Sun, 5 Jan 2003 03:30:42 -0800 (PST) (envelope-from basit@basit.cc) Received: from basit (helo=localhost) by basit.cc with local-esmtp (Exim 4.10) id 18V90B-000D0A-00 for net@freebsd.org; Sun, 05 Jan 2003 05:31:35 -0600 Date: Sun, 5 Jan 2003 05:31:35 -0600 (CST) From: Abdul Basit X-X-Sender: basit@wireless.cs.twsu.edu To: net@freebsd.org Subject: raw socket/icmp-echo Message-ID: <20030105052449.K49935-100000@wireless.cs.twsu.edu> 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 was trying to learn raw sockets, I wrote a simple program to get all icmp packets and display .. -- program int main(void) { int sockfd; int ip_len; char *buf; int n; struct icmp *icmp; struct ip *ip; buf = (char*) malloc(sizeof(struct ip)+sizeof(struct icmp)); sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); for (;;) { n = recv(sockfd, buf, sizeof(buf),0); ip = (struct ip *) buf; ip_len = ip->ip_hl << 2; // ip header length icmp = (struct icmp *) (buf + ip_len); if (icmp->icmp_type == ICMP_ECHO) { printf("ping request arrived\n"); } } } -- end The program compiles fine, but it can't recieve echo request , seems like the BSD kernel is not passing icmp echo type requests to raw socket? I beleive this is NOT the case in Linux, why this behaviour exists in BSD? is there any way to circumvent this ? Also, if anyone know any good tutorial on bpf , let me know the url (some simple example for capturing will be good .. i read bpf manpage, it seems little obscure to me). -- basit Graduate Stdudent Dept. Of Computer science. Wichita state university To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 8:33:24 2003 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 2F42A37B405 for ; Sun, 5 Jan 2003 08:33:23 -0800 (PST) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by mx1.FreeBSD.org (Postfix) with SMTP id 7AD5543ED1 for ; Sun, 5 Jan 2003 08:33:22 -0800 (PST) (envelope-from will@willardjwilliams.com) Received: from pd9e2cc38.dip.t-dialin.net (HELO willwilliams.homeunix.net) (willardjwilliams@217.226.204.56 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 5 Jan 2003 16:33:17 -0000 Content-Type: text/plain; charset="us-ascii" From: Will Williams Reply-To: will@willardjwilliams.com To: "freebsd-java" , "freebsd-net" Subject: OpenNMS requiring JDK 1.4 Date: Sun, 5 Jan 2003 17:32:42 +0100 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200301051732.42744.will@willardjwilliams.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 Hi, I am sending this to Java and Net lists in hopes of someone having some i= nfo=20 on OpenNMS. I would like to install but, OpenNMS requires JDK 1.4, which= =20 doesn't appear to be fully supported by FreeBSD yet. Is this correct? D= oes=20 anyone else have any success stories or horror stories on FreeBSD and=20 OpenNMS? Thanks, Will To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 13: 5:11 2003 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 3C3F337B401 for ; Sun, 5 Jan 2003 13:05:09 -0800 (PST) Received: from mail.econolodgetulsa.com (mail.econolodgetulsa.com [198.78.66.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9488D43EA9 for ; Sun, 5 Jan 2003 13:05:08 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Received: from mail (user@mail [198.78.66.163]) by mail.econolodgetulsa.com (8.12.3/8.12.3) with ESMTP id h05L59Zb013309 for ; Sun, 5 Jan 2003 13:05:09 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Date: Sun, 5 Jan 2003 13:05:09 -0800 (PST) From: Josh Brooks To: freebsd-net@freebsd.org Subject: Need help dealing with (D)DoS attacks (desperately) Message-ID: <20030105124644.Q80512-100000@mail.econolodgetulsa.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 Hi. I am running this as my firewall/router: 4.4-RELEASE FreeBSD 4.4-RELEASE #0 And I have no ability to change that anytime soon. Recently I have been having a lot of trouble with floods/ddos/etc. When these attacks occur, my firewall is totally unresponsive, I cannot ssh in to type a single command (and thus cannot tcpdump anything) and clients of systems on the inside either get no response, or get: ssh_exchange_identification: read: Connection reset by peer (and things like that) -------- So far, I have only done two things to my firewall. First, I upped NMBCLUSTERS to the point that I am now running at: # netstat -m 650/4768/32768 mbufs in use (current/peak/max): 650 mbufs allocated to data 559/4524/8192 mbuf clusters in use (current/peak/max) 10240 Kbytes allocated to network (41% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines So therefore I can conclude that the unresponsiveness, etc., is not due to running out of mbuf clusters. The only other thing I did was: sysctl -w net.inet.icmp.drop_redirect=1 I have no reason to suspect I am getting redirects, but it seemed like a good idea to do anyway. So that is all I have done to the firewall in terms of protection/hardening. ----------- So now I need to know what else I can do. All I know is that I am getting attacks that are _not_ saturating the physical pipe, but are cutting my network off from the rest of the world because the firewall simply refuses to do anything - its just hung. Generally, of the 15meg pipe we have, we have about 6-9 megs of traffic during an attack, so the pipe is _not_ saturated, but again, the firewall just hangs during it. I am open to any suggestions. The only thing I can fine that I might do is: ipfw add drop tcp from any to any tcpflags syn,fin which I am led to believe is functionally equivalent to the TCP_DROP_SYNFIN option and sysctl. Is this ipfw rule a general protection against syn floods ? Also what is the downside to doing this ? I read not to do it on webservers - this firewall runs _nothing_ but ssh, so presumably it is sfae, but there are a LOT of servers behind this firewall that _do_ run web servers, ircds, mail servers, etc. - will it have any effect on them ? Will it even be useful at all since the firewall is presumably not even the target, but rather the target is on the other side of the firewall ? ----------- Again, and and all suggestions appreciated - even theoretical guesses as to what kind of attack/traffic would make the firewall just hang like that and not process any traffic, even though mbuf clusters were not maxed out... I am not concnetragin on the syn-fin stuff above because I think it is the right thing, only because it is all I can come up with - so anything is appreciate. thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 13:21:10 2003 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 0759F37B401 for ; Sun, 5 Jan 2003 13:21:08 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DF2F43EE5 for ; Sun, 5 Jan 2003 13:21:06 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (c1-vpn4.isi.edu [128.9.176.34]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h05LL1C26443; Sun, 5 Jan 2003 13:21:01 -0800 (PST) Message-ID: <3E18A1BA.8000607@isi.edu> Date: Sun, 05 Jan 2003 13:20:58 -0800 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Josh Brooks Cc: freebsd-net@freebsd.org Subject: Re: Need help dealing with (D)DoS attacks (desperately) References: <20030105124644.Q80512-100000@mail.econolodgetulsa.com> In-Reply-To: <20030105124644.Q80512-100000@mail.econolodgetulsa.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030102030708000703050508" Sender: owner-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. --------------ms030102030708000703050508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On 1/5/2003 1:05 PM, Josh Brooks wrote: > > I am running this as my firewall/router: > > 4.4-RELEASE FreeBSD 4.4-RELEASE #0 > > And I have no ability to change that anytime soon. Recently I have been > having a lot of trouble with floods/ddos/etc. When these attacks occur, > my firewall is totally unresponsive, I cannot ssh in to type a single > command (and thus cannot tcpdump anything) and clients of systems on the > inside either get no response, or get: What processor and NICs do you use? This sounds like your machine is being pushed into livelock, which shouldn't happen at the traffic load you described (when you say "megs", do you mean Mb/s or MB/s?) Complicated firewall rule sets also eat CPU time. Lars -- Lars Eggert USC Information Sciences Institute --------------ms030102030708000703050508 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDEwNTIxMjA1OFowIwYJKoZIhvcNAQkEMRYEFONLFGBQQvT4I69mQ+8U rxylicrtMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAiV6V6nVuMSoW++dI4YzzRbw6iqWZUBObYrsX RbsIozgnSHyhz7o1QYEfg81j0yFyOwQLszzTyzmVrLF7epeGwp31r7QbqYfpv15cqYcnCVqB TyEbzPQweZyga0aSEMdYHZf+LlrCL02wZyUrdZbOLYZ92na+TP14khGt+pISuAu9rYOskeHa sn9UB7nG5BWJsFMdWTXrjKQUIcSOWa6yPoyy73n7DQMg9+50eaa5C3NdHc+u8Js+fmWrUfPj J7wc9iabynjUVf2AkFGZb9FxsEe/RFxuYqDy/PXkG9fGvX9D8rreb71p5KFOfuiUV6SFCWs9 /HwEMfu0DLAItLBPWQAAAAAAAA== --------------ms030102030708000703050508-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 13:26:44 2003 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 7567237B401 for ; Sun, 5 Jan 2003 13:26:43 -0800 (PST) Received: from isber.ucsb.edu (research.isber.ucsb.edu [128.111.147.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FA7043EC2 for ; Sun, 5 Jan 2003 13:26:43 -0800 (PST) (envelope-from randall@isber.ucsb.edu) Received: from localhost ([127.0.0.1] helo=research.isber.ucsb.edu) by isber.ucsb.edu with esmtp (Exim 3.36 #2) id 18VIHw-000BGe-00 for freebsd-net@freebsd.org; Sun, 05 Jan 2003 13:26:32 -0800 Date: Sun, 5 Jan 2003 13:26:32 -0800 (PST) From: randall ehren To: Subject: default route Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *18VIHw-000BGe-00*JrhIjCDXm8M* (ISBER - Institute for Social, Behavioral, and Economic Research) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi, i have a freebsd box acting as a firewall using ipfilter over a bridge. the machine has two interfaces: fxp0 = connected to outside world interface rl0 = connected to internal subnet when i add the default gateway, it defaults to assigning it to rl0. from netstat -rn: Destination Gateway Flags Refs Use Netif Expire 128.111.147.254 00:e0:52:d8:43:00 UHLW 1 0 rl0 1182 how can i assign the default gateway to use fxp0 instead? notes: root@fw-1[~]% ifconfig -u fxp0: flags=8943 mtu 1500 inet 128.111.147.250 netmask 0xffffffff broadcast 128.111.147.250 ether 00:00:5e:00:01:01 media: Ethernet 100baseTX status: active rl0: flags=8943 mtu 1500 inet 128.111.147.251 netmask 0xffffff00 broadcast 128.111.147.255 ether 00:30:1b:10:5b:e3 media: Ethernet 100baseTX status: active thanks, -randall -- :// randall s. ehren :// voice 805.893.5632 :// systems administrator :// isber|survey|avss.ucsb.edu :// institute for social, behavioral, and economic research To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 13:30: 8 2003 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 AF76037B405 for ; Sun, 5 Jan 2003 13:30:05 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B96943ED8 for ; Sun, 5 Jan 2003 13:30:05 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (c1-vpn4.isi.edu [128.9.176.34]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h05LU4C29923; Sun, 5 Jan 2003 13:30:04 -0800 (PST) Message-ID: <3E18A3D9.3010909@isi.edu> Date: Sun, 05 Jan 2003 13:30:01 -0800 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: randall ehren Cc: freebsd-net@freebsd.org Subject: Re: default route References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030109030601050004000001" Sender: owner-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. --------------ms030109030601050004000001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On 1/5/2003 1:26 PM, randall ehren wrote: > > how can i assign the default gateway to use fxp0 instead? route delete default route add default A.B.C.D As described in the man page. Lars -- Lars Eggert USC Information Sciences Institute --------------ms030109030601050004000001 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDEwNTIxMzAwMVowIwYJKoZIhvcNAQkEMRYEFBhqX4rVqukOFednYL+R Hz5YhWVmMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAzwzxT5NVSV96mmkApEq2p3fGdgi/moPS0Mad i3qKF3IXvKhCPL4+r8p6KWxBPQ2KmzBKywJm77cjAMPJlBNBIPQVEox8rGrV+lJ3rXJIuoR8 4YHrjfdyy8OhV3xRj+woZYnUaTxIN083uB0Za14fVf05fkjnZvqcM0adqZkkgBW7GlxIvw08 ROyDpKMRJ+4uDMrmX4hJVwDQBt01gYqutF+fARwPjs32oaoNb0jEQ72kKrzf8D2s9Gtj3CKD mD/5+L3+lZpddOffugG1OL0N6abc3Rp7JNIf3imPKMUOYK0BWZ7XCx7puL48E5h5ao5DlmNV KyqOGUsvA71kz/YN3AAAAAAAAA== --------------ms030109030601050004000001-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 13:31:27 2003 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 58B4637B401 for ; Sun, 5 Jan 2003 13:31:25 -0800 (PST) Received: from mail.econolodgetulsa.com (mail.econolodgetulsa.com [198.78.66.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A9AD43EE5 for ; Sun, 5 Jan 2003 13:31:24 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Received: from mail (user@mail [198.78.66.163]) by mail.econolodgetulsa.com (8.12.3/8.12.3) with ESMTP id h05LVPZb022443; Sun, 5 Jan 2003 13:31:25 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Date: Sun, 5 Jan 2003 13:31:24 -0800 (PST) From: Josh Brooks To: Lars Eggert Cc: freebsd-net@freebsd.org Subject: Re: Need help dealing with (D)DoS attacks (desperately) In-Reply-To: <3E18A1BA.8000607@isi.edu> Message-ID: <20030105132545.I80512-100000@mail.econolodgetulsa.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, Ok, right now this second, everything is normal, I am not under attack AFAIK, and everything is working wonderfully - and when I run top I see: 21 processes: 1 running, 20 sleeping CPU states: 0.0% user, 0.0% nice, 0.0% system, 41.7% interrupt, 58.3% idle Mem: 6812K Active, 43M Inact, 28M Wired, 28K Cache, 35M Buf, 170M Free Swap: 128M Total, 128M Free and it fluctuates between 20-60% idle So it does look like the cpu is ... being used :) uptime tells me: # uptime 1:22PM up 20 days, 11:52, 2 users, load averages: 0.02, 0.01, 0.00 ----- ipfw rules: # ipfw show | wc -l 927 So, I have 927 ipfw tules in place - but I am guessing that about 800 of those rules are just "count" rules for me to count bandwidth: 001 164994 120444282 count ip from any to 10.10.10.10 002 158400 16937232 count ip from 10.10.10.10 to any ------ CPU is a ... celeron 500 ? 600 ? Something like that, and I have 256 megs ram. More infomration: although it looks like I am using a lot of cpu, and do indeed have a lot of ipfw rules, I _do know_ that it was an attack, as it was aimed at IPs running very high profile services (ircd, etc.) that have been targets in the past. We filtered those IPs and the problem went away instantly. So again, what should I be looking to add ? Before my list included only the syn/fin protection, and now I am being told to block all icmp types besides 0,3,8,11. Any other thoughts ? thanks! On Sun, 5 Jan 2003, Lars Eggert wrote: > On 1/5/2003 1:05 PM, Josh Brooks wrote: > > > > I am running this as my firewall/router: > > > > 4.4-RELEASE FreeBSD 4.4-RELEASE #0 > > > > And I have no ability to change that anytime soon. Recently I have been > > having a lot of trouble with floods/ddos/etc. When these attacks occur, > > my firewall is totally unresponsive, I cannot ssh in to type a single > > command (and thus cannot tcpdump anything) and clients of systems on the > > inside either get no response, or get: > > What processor and NICs do you use? This sounds like your machine is > being pushed into livelock, which shouldn't happen at the traffic load > you described (when you say "megs", do you mean Mb/s or MB/s?) > Complicated firewall rule sets also eat CPU time. > > Lars > -- > Lars Eggert USC Information Sciences Institute > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 13:37:28 2003 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 5392B37B401 for ; Sun, 5 Jan 2003 13:37:27 -0800 (PST) Received: from isber.ucsb.edu (research.isber.ucsb.edu [128.111.147.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72B7543EB2 for ; Sun, 5 Jan 2003 13:37:23 -0800 (PST) (envelope-from randall@isber.ucsb.edu) Received: from localhost ([127.0.0.1] helo=research.isber.ucsb.edu) by isber.ucsb.edu with esmtp (Exim 3.36 #2) id 18VISL-000BLX-00; Sun, 05 Jan 2003 13:37:17 -0800 Date: Sun, 5 Jan 2003 13:37:16 -0800 (PST) From: randall ehren To: Lars Eggert Cc: Subject: Re: default route In-Reply-To: <3E18A3D9.3010909@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *18VISL-000BLX-00*J1mBRlnMLAM* (ISBER - Institute for Social, Behavioral, and Economic Research) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > how can i assign the default gateway to use fxp0 instead? > > route delete default > route add default A.B.C.D i read the man page, it indicated the use of the -inteface flag but i could not get it to work. doing what you say did not fix the problem either: as you described: root@fw-1[~]% route delete default route: writing to routing socket: No such process delete net default: not in table so i manually deleted it: root@fw-1[~]% route delete 128.111.147.254 delete host 128.111.147.254 netstat -rn then indicated it was deleted. then i ran: root@fw-1[~]% route add default 128.111.147.254 add net default: gateway 128.111.147.254 and netstat -rn again shows: Destination Gateway Flags Refs Use Netif Expire 128.111.147.254 00:e0:52:d8:43:00 UHLW 1 0 rl0 1173 my problem is not adding a default gateway, but rather assigning the default gateway to the outside interface fxp0, not my internal interface rl0. any more ideas? -randall -- :// randall s. ehren :// voice 805.893.5632 :// systems administrator :// isber|survey|avss.ucsb.edu :// institute for social, behavioral, and economic research To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 14: 3:10 2003 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 9F82137B401 for ; Sun, 5 Jan 2003 14:03:07 -0800 (PST) Received: from mail.econolodgetulsa.com (mail.econolodgetulsa.com [198.78.66.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 272EA43EC5 for ; Sun, 5 Jan 2003 14:03:07 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Received: from mail (user@mail [198.78.66.163]) by mail.econolodgetulsa.com (8.12.3/8.12.3) with ESMTP id h05M38Zb034356; Sun, 5 Jan 2003 14:03:08 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Date: Sun, 5 Jan 2003 14:03:08 -0800 (PST) From: Josh Brooks To: Lars Eggert Cc: freebsd-net@freebsd.org Subject: Re: Need help dealing with (D)DoS attacks (desperately) - MORE INFO In-Reply-To: <3E18A1BA.8000607@isi.edu> Message-ID: <20030105135310.U80512-100000@mail.econolodgetulsa.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 Ok, I am now armed with quite a bit more info regarding these attacks. First off, the target looks like this: Port State Service 21/tcp open ftp 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 110/tcp open pop-3 3333/tcp open dec-notes 10000/tcp open snet-sensor-mgmt 31337/tcp open Elite (and yes, port 31337 is legit - this is a linux server and that is not a trojan running) OK, so during the attack, an upstream router captured the packets. I see two interesting things: 1. a ton of TCP SYN, [1658] -> [106] 3COM-TSMUX to ports that do not exist on the target. See how this one goes to destination 106, but the target is not running anything on 106 ? Once in a while the SYN packets go to an existing port, but most of them go to nonexistent (seemingly random) ports on the target. 2. a noticable amount of christmas tree packets aimed at the target: TCP FIN SYN RST PSH ACK, [1400] -> [98] TAC-news again, to ports not actually open on the target. I guess a xmas tree packet technically has a URG flag as well, which these do not - but even still I suspect these are bad news to be seeing. Also some of them are not quite as xmas as other: TCP SYN RST PSH ACK, [1230] -> [118] SQL-service again, directed at a service that does not exist. 3. These seem less frequent, but I am seeing: UDP, [21397] -> [2284] ^M Source port: [21397] ^M Destination port: [2284] ^M UDP length: 908^M Checksum: 0x0000 (data fragment - not able to check)^M So .. a UDP fragment sent to a port not open on the target. This also seems like bad news. ----- So that's that - I see this for all three IPs that were being targeted. So now there are two things I need to know (and ask cordially for your help with) 1. what can I put into place on a 4.4-RELEASE ipfw firewall to combat these items 2. What are 1 2 and 3 called ? For instance, is #1 a "syn flood" ? 3. will the solutions given to me actually help ? I mean, the packets will still hit my firewall, and given the cpu utilization and config I showed you earlier, will the fixes nullify the effect of these attacks, or am I so underpowered that getting hit with these in any way, no matter what precautions I have in place will disable me ? thanks a LOT. On Sun, 5 Jan 2003, Lars Eggert wrote: > On 1/5/2003 1:05 PM, Josh Brooks wrote: > > > > I am running this as my firewall/router: > > > > 4.4-RELEASE FreeBSD 4.4-RELEASE #0 > > > > And I have no ability to change that anytime soon. Recently I have been > > having a lot of trouble with floods/ddos/etc. When these attacks occur, > > my firewall is totally unresponsive, I cannot ssh in to type a single > > command (and thus cannot tcpdump anything) and clients of systems on the > > inside either get no response, or get: > > What processor and NICs do you use? This sounds like your machine is > being pushed into livelock, which shouldn't happen at the traffic load > you described (when you say "megs", do you mean Mb/s or MB/s?) > Complicated firewall rule sets also eat CPU time. > > Lars > -- > Lars Eggert USC Information Sciences Institute > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 14:15:57 2003 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 6865437B401 for ; Sun, 5 Jan 2003 14:15:56 -0800 (PST) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CB9843E4A for ; Sun, 5 Jan 2003 14:15:55 -0800 (PST) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.6/8.12.6) with ESMTP id h05MFn1N081922; Sun, 5 Jan 2003 17:15:49 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.6/8.12.6/Submit) id h05MFnOf081921; Sun, 5 Jan 2003 17:15:49 -0500 (EST) (envelope-from barney) Date: Sun, 5 Jan 2003 17:15:49 -0500 From: Barney Wolff To: Josh Brooks Cc: Lars Eggert , freebsd-net@FreeBSD.ORG Subject: Re: Need help dealing with (D)DoS attacks (desperately) Message-ID: <20030105221549.GA81793@pit.databus.com> References: <3E18A1BA.8000607@isi.edu> <20030105132545.I80512-100000@mail.econolodgetulsa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030105132545.I80512-100000@mail.econolodgetulsa.com> User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Jan 05, 2003 at 01:31:24PM -0800, Josh Brooks wrote: > So, I have 927 ipfw tules in place - but I am guessing that about 800 of > those rules are just "count" rules for me to count bandwidth: > > 001 164994 120444282 count ip from any to 10.10.10.10 > 002 158400 16937232 count ip from 10.10.10.10 to any Much of your problem is that you're running through all the rules on every packet. ipfw keeps going until it hits an allow or deny rule. Since all rules get counted, I'd suggest putting all your denies up front, and then have allow rules, not count rules, with the most heavily used addresses first. That way, many fewer rules should get interpreted for each packet. An even fancier scheme would use skipto and divide up your IP ranges in a binary search. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 14:18: 8 2003 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 B9A2F37B401 for ; Sun, 5 Jan 2003 14:18:07 -0800 (PST) Received: from mail.econolodgetulsa.com (mail.econolodgetulsa.com [198.78.66.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D90743EA9 for ; Sun, 5 Jan 2003 14:18:07 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Received: from mail (user@mail [198.78.66.163]) by mail.econolodgetulsa.com (8.12.3/8.12.3) with ESMTP id h05MI7Zb057420; Sun, 5 Jan 2003 14:18:07 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Date: Sun, 5 Jan 2003 14:18:07 -0800 (PST) From: Josh Brooks To: Barney Wolff Cc: Lars Eggert , Subject: Re: Need help dealing with (D)DoS attacks (desperately) In-Reply-To: <20030105221549.GA81793@pit.databus.com> Message-ID: <20030105141736.C80512-100000@mail.econolodgetulsa.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 Alternatively, is getting a much faster CPU (p3 1.6g ?) a "big hammer" that solves problems related to the number of rules being parsed for each packet ? Just curious. On Sun, 5 Jan 2003, Barney Wolff wrote: > On Sun, Jan 05, 2003 at 01:31:24PM -0800, Josh Brooks wrote: > > So, I have 927 ipfw tules in place - but I am guessing that about 800 of > > those rules are just "count" rules for me to count bandwidth: > > > > 001 164994 120444282 count ip from any to 10.10.10.10 > > 002 158400 16937232 count ip from 10.10.10.10 to any > > Much of your problem is that you're running through all the rules on > every packet. ipfw keeps going until it hits an allow or deny rule. > Since all rules get counted, I'd suggest putting all your denies up > front, and then have allow rules, not count rules, with the most > heavily used addresses first. That way, many fewer rules should get > interpreted for each packet. An even fancier scheme would use skipto > and divide up your IP ranges in a binary search. > > -- > Barney Wolff http://www.databus.com/bwresume.pdf > I'm available by contract or FT, in the NYC metro area or via the 'Net. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 15:25:45 2003 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 2098737B401 for ; Sun, 5 Jan 2003 15:25:43 -0800 (PST) Received: from vineyard.net (K1.vineyard.net [204.17.195.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 171E543EC5 for ; Sun, 5 Jan 2003 15:25:42 -0800 (PST) (envelope-from ericx@vineyard.net) Received: from alice (loopback [127.0.0.1]) by vineyard.net (Postfix) with ESMTP id 48085916CD; Sun, 5 Jan 2003 18:25:36 -0500 (EST) Message-ID: <00b701c2b512$1043c1f0$3ee380cc@alice> From: "Eric W. Bates" To: "randall ehren" , References: Subject: Re: default route Date: Sun, 5 Jan 2003 18:27:50 -0500 Organization: Vineyard.NET, Inc. 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 According to your ifconfig, I believe you have essentially assigned the same networks to both interfaces (128.111.147.250 netmask 0xffffffff falls within the larger 128.111.147.251/24). In which case, there is no way to distinguish between the two interfaces because your default IP, 128.111.147.251 actually falls within both subnets. ----- Original Message ----- From: "randall ehren" To: Sent: Sunday, January 05, 2003 4:26 PM Subject: default route > hi, > i have a freebsd box acting as a firewall using ipfilter over a bridge. > > the machine has two interfaces: > fxp0 = connected to outside world interface > rl0 = connected to internal subnet > > when i add the default gateway, it defaults to assigning it to rl0. > > from netstat -rn: > Destination Gateway Flags Refs Use Netif Expire > 128.111.147.254 00:e0:52:d8:43:00 UHLW 1 0 rl0 1182 > > how can i assign the default gateway to use fxp0 instead? > > notes: > > root@fw-1[~]% ifconfig -u > fxp0: flags=8943 mtu 1500 > inet 128.111.147.250 netmask 0xffffffff broadcast 128.111.147.250 > ether 00:00:5e:00:01:01 > media: Ethernet 100baseTX > status: active > rl0: flags=8943 mtu 1500 > inet 128.111.147.251 netmask 0xffffff00 broadcast 128.111.147.255 > ether 00:30:1b:10:5b:e3 > media: Ethernet 100baseTX > status: active > > > thanks, > -randall > > -- > :// randall s. ehren :// voice 805.893.5632 > :// systems administrator :// isber|survey|avss.ucsb.edu > :// institute for social, behavioral, and economic research > > > 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 Sun Jan 5 16:55:37 2003 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 0544137B401 for ; Sun, 5 Jan 2003 16:55:35 -0800 (PST) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE61E43EC5 for ; Sun, 5 Jan 2003 16:55:33 -0800 (PST) (envelope-from babolo@aaz.links.ru) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by aaz.links.ru (8.12.6/8.12.6) with ESMTP id h060ursQ046967; Mon, 6 Jan 2003 03:56:53 +0300 (MSK) (envelope-from babolo@aaz.links.ru) Received: (from babolo@localhost) by aaz.links.ru (8.12.6/8.12.6/Submit) id h060uq2J046966; Mon, 6 Jan 2003 03:56:52 +0300 (MSK) Message-Id: <200301060056.h060uq2J046966@aaz.links.ru> Subject: Re: Need help dealing with (D)DoS attacks (desperately) X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20030105132545.I80512-100000@mail.econolodgetulsa.com> To: Josh Brooks Date: Mon, 6 Jan 2003 03:56:51 +0300 (MSK) From: "."@babolo.ru Cc: Lars Eggert , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Hello, > > Ok, right now this second, everything is normal, I am not under attack > AFAIK, and everything is working wonderfully - and when I run top I see: > > 21 processes: 1 running, 20 sleeping > CPU states: 0.0% user, 0.0% nice, 0.0% system, 41.7% interrupt, 58.3% > idle > Mem: 6812K Active, 43M Inact, 28M Wired, 28K Cache, 35M Buf, 170M Free > Swap: 128M Total, 128M Free > > and it fluctuates between 20-60% idle > > So it does look like the cpu is ... being used :) uptime tells me: > > # uptime > 1:22PM up 20 days, 11:52, 2 users, load averages: 0.02, 0.01, 0.00 > > ----- > > ipfw rules: > > # ipfw show | wc -l > 927 > > So, I have 927 ipfw tules in place - but I am guessing that about 800 of > those rules are just "count" rules for me to count bandwidth: > > 001 164994 120444282 count ip from any to 10.10.10.10 > 002 158400 16937232 count ip from 10.10.10.10 to any > > ------ > > CPU is a ... celeron 500 ? 600 ? Something like that, and I have 256 > megs ram. > > More infomration: although it looks like I am using a lot of cpu, and do > indeed have a lot of ipfw rules, I _do know_ that it was an attack, as it > was aimed at IPs running very high profile services (ircd, etc.) that have > been targets in the past. We filtered those IPs and the problem went away > instantly. I administrate big (~1000 users each) nets. Without such a rules at the begin ipwf ruleset: 02300 96121 77175703 pipe 2300 ip from X.X.X.X/24 to any in recv xl1 02300 26528 17986211 pipe 2300 ip from Y.Y.Y.Y/24 to any in recv xl3 02300 27044 21370476 pipe 2300 ip from Z.Z.Z.Z/24 to any in recv xl4 router was unstable because of great number of rules: <*1> Pipes restricts per IP address, in my case: <*2> !Place pipe rules at the ruleset begin to protect your router from flood! Another tips: Remember, that routed packets goes through the ruleset twice, write rules to optimize CPU usage. Use special tools to collect traffic. I use argus - it is beautiful trafic auditing tool and costs less cpu. It behavies better under overload because of much work done in userland. Sorry my bad English. Ask when need help. -- <*1> 0sw~(1)#ipfw show | wc 435 4868 41602 0rw~(1)#ipfw show | wc 1917 19228 153479 0gw~(1)#ipfw show | wc 317 3480 34721 So on. Some rules are very wide (ipfw2 specific) <*2> 0kw~(1)#ipfw pipe show 02300: 3.200 Mbit/s 0 ms 30 KB 44 queues (1024 buckets) droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 .... different pipes for different user classes In your case you probably need in another direction tube: 0x00000000/0x0000 -> 0xffffffff/0x0000 -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 17: 1: 6 2003 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 6635C37B401 for ; Sun, 5 Jan 2003 17:01:03 -0800 (PST) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68FF143EA9 for ; Sun, 5 Jan 2003 17:01:02 -0800 (PST) (envelope-from babolo@aaz.links.ru) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by aaz.links.ru (8.12.6/8.12.6) with ESMTP id h0612QsQ047382; Mon, 6 Jan 2003 04:02:26 +0300 (MSK) (envelope-from babolo@aaz.links.ru) Received: (from babolo@localhost) by aaz.links.ru (8.12.6/8.12.6/Submit) id h0612PSM047380; Mon, 6 Jan 2003 04:02:25 +0300 (MSK) Message-Id: <200301060102.h0612PSM047380@aaz.links.ru> Subject: Re: default route X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <00b701c2b512$1043c1f0$3ee380cc@alice> To: "Eric W. Bates" Date: Mon, 6 Jan 2003 04:02:25 +0300 (MSK) From: "."@babolo.ru Cc: randall ehren , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [ Charset ISO-8859-1 unsupported, converting... ] > According to your ifconfig, I believe you have essentially assigned the same > networks to both interfaces (128.111.147.250 netmask 0xffffffff falls within > the larger 128.111.147.251/24). In which case, there is no way to > distinguish between the two interfaces because your default IP, > 128.111.147.251 actually falls within both subnets. fxp0: 128.111.147.250/32 rl0: 128.111.147.251/24 obviously 128.111.147.254 is in 128.111.147.251/24 and not in 128.111.147.250/32 assign 128.111.147.253/30 to fxp0 > ----- Original Message ----- > From: "randall ehren" > To: > Sent: Sunday, January 05, 2003 4:26 PM > Subject: default route > > > > hi, > > i have a freebsd box acting as a firewall using ipfilter over a bridge. > > > > the machine has two interfaces: > > fxp0 = connected to outside world interface > > rl0 = connected to internal subnet > > > > when i add the default gateway, it defaults to assigning it to rl0. > > > > from netstat -rn: > > Destination Gateway Flags Refs Use Netif > Expire > > 128.111.147.254 00:e0:52:d8:43:00 UHLW 1 0 rl0 > 1182 > > > > how can i assign the default gateway to use fxp0 instead? > > > > notes: > > > > root@fw-1[~]% ifconfig -u > > fxp0: flags=8943 mtu 1500 > > inet 128.111.147.250 netmask 0xffffffff broadcast 128.111.147.250 > > ether 00:00:5e:00:01:01 > > media: Ethernet 100baseTX > > status: active > > rl0: flags=8943 mtu 1500 > > inet 128.111.147.251 netmask 0xffffff00 broadcast 128.111.147.255 > > ether 00:30:1b:10:5b:e3 > > media: Ethernet 100baseTX > > status: active > > > > > > thanks, > > -randall > > > > -- > > :// randall s. ehren :// voice 805.893.5632 > > :// systems administrator :// isber|survey|avss.ucsb.edu > > :// institute for social, behavioral, and economic research > > > > > > 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 > -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 17:31: 8 2003 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 ADE0437B401 for ; Sun, 5 Jan 2003 17:31:04 -0800 (PST) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7571343EC2 for ; Sun, 5 Jan 2003 17:31:03 -0800 (PST) (envelope-from babolo@aaz.links.ru) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by aaz.links.ru (8.12.6/8.12.6) with ESMTP id h061WRsQ048597; Mon, 6 Jan 2003 04:32:27 +0300 (MSK) (envelope-from babolo@aaz.links.ru) Received: (from babolo@localhost) by aaz.links.ru (8.12.6/8.12.6/Submit) id h061WQ2i048596; Mon, 6 Jan 2003 04:32:26 +0300 (MSK) Message-Id: <200301060132.h061WQ2i048596@aaz.links.ru> Subject: Re: Need help dealing with (D)DoS attacks (desperately) - MORE INFO X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20030105135310.U80512-100000@mail.econolodgetulsa.com> To: Josh Brooks Date: Mon, 6 Jan 2003 04:32:26 +0300 (MSK) From: "."@babolo.ru Cc: Lars Eggert , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Ok, I am now armed with quite a bit more info regarding these attacks. > > First off, the target looks like this: > > Port State Service > 21/tcp open ftp > 22/tcp open ssh > 25/tcp open smtp > 53/tcp open domain > 80/tcp open http > 110/tcp open pop-3 > 3333/tcp open dec-notes > 10000/tcp open snet-sensor-mgmt > 31337/tcp open Elite > > (and yes, port 31337 is legit - this is a linux server and that is not a > trojan running) > > OK, so during the attack, an upstream router captured the packets. I see > two interesting things: > > 1. a ton of TCP SYN, [1658] -> [106] 3COM-TSMUX to ports that do > not exist on the target. See how this one goes to destination 106, but > the target is not running anything on 106 ? Once in a while the SYN > packets go to an existing port, but most of them go to nonexistent > (seemingly random) ports on the target. > > 2. a noticable amount of christmas tree packets aimed at the target: > > TCP FIN SYN RST PSH ACK, [1400] -> [98] TAC-news > > again, to ports not actually open on the target. I guess a xmas tree > packet technically has a URG flag as well, which these do not - but even > still I suspect these are bad news to be seeing. > > Also some of them are not quite as xmas as other: > > TCP SYN RST PSH ACK, [1230] -> [118] SQL-service > > again, directed at a service that does not exist. > > > 3. These seem less frequent, but I am seeing: > > UDP, [21397] -> [2284] ^M > Source port: [21397] ^M > Destination port: [2284] ^M > UDP length: 908^M > Checksum: 0x0000 (data fragment - not able to check)^M > > So .. a UDP fragment sent to a port not open on the target. This also > seems like bad news. > > ----- > > So that's that - I see this for all three IPs that were being targeted. > > So now there are two things I need to know (and ask cordially for your > help with) > > 1. what can I put into place on a 4.4-RELEASE ipfw firewall to combat > these items ipfw add 1 allow tcp from any to server_IP 21,22,25,53,80,110,3333,10000,31337 ipfw add 1 allow udp from any to server_IP 53 ipfw add 2 deny ip from any to server_IP ipfw add 2 allow ip from any to any out If you do not separate in and out in rules and have a lot of count rules. This is very aggresive for your server, but save your router. may be you have to tweak this rules (it depends) More detailed description of router/net and original ruleset can help. Also sysctl: net.inet.ip.fastforwarding net.inet.ip.fw.one_pass net.link.ether.inet.proxyall net.inet.ip.redirect net.link.ether.ipfw net.inet.ip.fw.enable net.inet.ip.check_interface Substitute userland traffic counter for count rules helps to low CPU usage > 2. What are 1 2 and 3 called ? For instance, is #1 a "syn flood" ? > > 3. will the solutions given to me actually help ? I mean, the packets > will still hit my firewall, and given the cpu utilization and config I > showed you earlier, will the fixes nullify the effect of these attacks, or > am I so underpowered that getting hit with these in any way, no matter > what precautions I have in place will disable me ? > > thanks a LOT. > > On Sun, 5 Jan 2003, Lars Eggert wrote: > > > On 1/5/2003 1:05 PM, Josh Brooks wrote: > > > > > > I am running this as my firewall/router: > > > > > > 4.4-RELEASE FreeBSD 4.4-RELEASE #0 > > > > > > And I have no ability to change that anytime soon. Recently I have been > > > having a lot of trouble with floods/ddos/etc. When these attacks occur, > > > my firewall is totally unresponsive, I cannot ssh in to type a single > > > command (and thus cannot tcpdump anything) and clients of systems on the > > > inside either get no response, or get: > > > > What processor and NICs do you use? This sounds like your machine is > > being pushed into livelock, which shouldn't happen at the traffic load > > you described (when you say "megs", do you mean Mb/s or MB/s?) > > Complicated firewall rule sets also eat CPU time. > > > > Lars > > -- > > Lars Eggert USC Information Sciences Institute > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 22:25:15 2003 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 1910C37B405 for ; Sun, 5 Jan 2003 22:25:14 -0800 (PST) Received: from web41203.mail.yahoo.com (web41203.mail.yahoo.com [66.218.93.36]) by mx1.FreeBSD.org (Postfix) with SMTP id A2EDE43EC5 for ; Sun, 5 Jan 2003 22:25:13 -0800 (PST) (envelope-from shubha_mr@yahoo.com) Message-ID: <20030106062513.51746.qmail@web41203.mail.yahoo.com> Received: from [12.151.32.25] by web41203.mail.yahoo.com via HTTP; Mon, 06 Jan 2003 06:25:13 GMT Date: Mon, 6 Jan 2003 06:25:13 +0000 (GMT) From: =?iso-8859-1?q?shubha=20mr?= Subject: help-urgent To: freebsd-questions@FreeBSD.ORG Cc: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, If I have to write to a register at offset say x,in the pci configuration space,how do I do it? If it is using pci_read_config and pci_write_config,how does the system know where the pci reg base address of my device is? plese help urgent shubha __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 5 23:16:39 2003 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 28A8337B401; Sun, 5 Jan 2003 23:16:38 -0800 (PST) Received: from yama.openaccess.org (ns1.openaccess.org [216.57.214.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id A215443EB2; Sun, 5 Jan 2003 23:16:37 -0800 (PST) (envelope-from michael@staff.openaccess.org) Received: from [192.168.0.254] (sk4521-bcsap.bcs.openaccess.org [216.57.214.35]) by yama.geminisolutions.com (8.12.3/8.11.6) with ESMTP id h05KejFY023691; Sun, 5 Jan 2003 12:40:45 -0800 (PST) (envelope-from michael@staff.openaccess.org) User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Sun, 05 Jan 2003 12:49:04 -0800 Subject: Re: OpenNMS requiring JDK 1.4 From: Michael DeMan To: , freebsd-java , freebsd-net Message-ID: In-Reply-To: <200301051732.42744.will@willardjwilliams.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Yes, you need JDK 1.4, a friend of mine was porting it to MacOSX and the whole thing broke when OpenNMS release a 1.4 dependent version. In theory, you should be able to run it in linux-compatibility mode on FreeBSD with a recent JDK. We have played with it on a RedHat 7.3 box, and looked into putting into production on BSD via linux emulation but gave up after a day or so of fooling around with it. - mike On 1/5/03 8:32 AM, "Will Williams" wrote: > Hi, > > I am sending this to Java and Net lists in hopes of someone having some info > on OpenNMS. I would like to install but, OpenNMS requires JDK 1.4, which > doesn't appear to be fully supported by FreeBSD yet. Is this correct? Does > anyone else have any success stories or horror stories on FreeBSD and > OpenNMS? > > Thanks, > > Will > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > Michael F. DeMan Director of Technology OpenAccess Internet Services 1305 11th St., 3rd Floor Bellingham, WA 98225 Tel 360-647-0785 x204 Fax 360-738-9785 michael@staff.openaccess.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 6 1:22: 8 2003 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 BA2C437B401; Mon, 6 Jan 2003 01:22:06 -0800 (PST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCE0643E4A; Mon, 6 Jan 2003 01:22:05 -0800 (PST) (envelope-from marks@ripe.net) Received: from laptop.6bone.nl (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id h069M1vP008186; Mon, 6 Jan 2003 10:22:02 +0100 Received: (nullmailer pid 2167 invoked by uid 1000); Mon, 06 Jan 2003 09:22:04 -0000 Date: Mon, 6 Jan 2003 10:22:03 +0100 From: Mark Santcroos To: shubha mr Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: help-urgent Message-ID: <20030106092203.GA620@laptop.6bone.nl> References: <20030106062513.51746.qmail@web41203.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030106062513.51746.qmail@web41203.mail.yahoo.com> User-Agent: Mutt/1.4i X-Handles: MS6-6BONE, MS18417-RIPE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Don't think these lists are the best place for this question but alas... On Mon, Jan 06, 2003 at 06:25:13AM +0000, shubha mr wrote: > If I have to write to a register at offset say x,in > the pci configuration space,how do I do it? If it is > using pci_read_config and pci_write_config,how does > the system know where the pci reg base address of my > device is? val = pci_read_config(dev, OFFSET, len); dev: the PCI device your driver is working on OFFSET: the position you want to read from len: the number of bytes you want to read Because you specify the pci dev the system knows where to read from. Look at any random pci driver in sys/ and it will all become clear. 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 Mon Jan 6 1:58:31 2003 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 9D07737B401; Mon, 6 Jan 2003 01:58:30 -0800 (PST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A9C543EB2; Mon, 6 Jan 2003 01:58:29 -0800 (PST) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id h069wPJ15725; Mon, 6 Jan 2003 10:58:25 +0100 (MET) Date: Mon, 6 Jan 2003 10:58:25 +0100 (CET) From: Harti Brandt To: Nate Lawson Cc: current@FreeBSD.ORG, Subject: Re: Proper -current if_attach locking? In-Reply-To: Message-ID: <20030106105529.C12568-100000@beagle.fokus.gmd.de> 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, 3 Jan 2003, Nate Lawson wrote: NL>I was looking into some "could sleep messages" and found some bogus NL>locking in the attach routine of many drivers. Several init a mtx in NL>their softc and then lock/unlock it in their attach routine. This, of NL>course, does nothing to provide exclusive access to a device. I assume NL>there is going to be a global IF_LOCK or something to be used in attach NL>routines. Can someone fill me in on the intended design? Probably not. I asked the same question a couple of month ago and got 0 answers. I think, there is no way, the driver itself can assure exclusive access to the device it is attaching. It *must* assume, that there is some kind of locking around the call to the attach routine. Getting the lock in the softc inside the attach routine may be neccessary, because the routine may call other functions that assume they have the lock. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 6 6:34: 4 2003 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 82F6037B401; Mon, 6 Jan 2003 06:34:02 -0800 (PST) Received: from ada.snu.ac.kr (ada.snu.ac.kr [147.46.106.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEDB643EC5; Mon, 6 Jan 2003 06:34:01 -0800 (PST) (envelope-from redjade@ada.snu.ac.kr) Received: from ada.snu.ac.kr (ada.snu.ac.kr [147.46.106.49]) by ada.snu.ac.kr (8.12.6/8.12.6) with ESMTP id h06EVQjC011766; Mon, 6 Jan 2003 23:31:26 +0900 (KST) (envelope-from redjade@ada.snu.ac.kr) Received: (from redjade@localhost) by ada.snu.ac.kr (8.12.6/8.12.6/Submit) id h06EUASM011755; Mon, 6 Jan 2003 23:30:10 +0900 (KST) Date: Mon, 6 Jan 2003 23:30:10 +0900 From: Kyunghwan Kim To: Harti Brandt Cc: Nate Lawson , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Proper -current if_attach locking? Message-ID: <20030106143010.GA11655@ada.snu.ac.kr> References: <20030106105529.C12568-100000@beagle.fokus.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline In-Reply-To: <20030106105529.C12568-100000@beagle.fokus.gmd.de> User-Agent: Mutt/1.4i X-My-Present-Organization: Innuworks, Inc. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jan 06, 2003 at 10:58:25AM +0100, Harti Brandt wrote: > On Fri, 3 Jan 2003, Nate Lawson wrote: > NL>I was looking into some "could sleep messages" and found some bogus > NL>locking in the attach routine of many drivers. Several init a mtx in > NL>their softc and then lock/unlock it in their attach routine. This, of > NL>course, does nothing to provide exclusive access to a device. I assume > NL>there is going to be a global IF_LOCK or something to be used in attach > NL>routines. Can someone fill me in on the intended design? > > Probably not. I asked the same question a couple of month ago and got 0 > answers. I think, there is no way, the driver itself can assure exclusive > access to the device it is attaching. It *must* assume, that there is some > kind of locking around the call to the attach routine. Getting the lock in > the softc inside the attach routine may be neccessary, because the routine > may call other functions that assume they have the lock. Only using lock in softc can't assure its exclusive access because there are some cases of changing some values in ifnet struct outside of device driver routines. Most of the NIC drivers don't have its own locks for now, and using both IFNET_*LOCK() and its own softc lock can't make everything in sync. There should be two use of locks IMO: one or more per-device locks in driver softc for manipulating per-device private data protection, and ifnet lock for each ifnet struct protection (such as ifnet.if_mtx). Maybe these locks should be adaptive or spin.... And IFNET_*LOCK() should remain for adding/removing ifnet struct to the global ifnet whose type is ifnethead. In case of ifqueue, it should not need to acquire its ifnet lock because ifqueue has its own mutex. -- Kyunghwan Kim redjade@ada.snu.ac.kr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 6 16:26:17 2003 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 CCA5537B401 for ; Mon, 6 Jan 2003 16:26:15 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 0728543EC5 for ; Mon, 6 Jan 2003 16:26:11 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 12467 invoked by uid 1000); 7 Jan 2003 00:26:11 -0000 Date: Mon, 6 Jan 2003 16:26:11 -0800 (PST) From: Nate Lawson To: Kyunghwan Kim Cc: current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Proper -current if_attach locking? In-Reply-To: <20030106143010.GA11655@ada.snu.ac.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 6 Jan 2003, Kyunghwan Kim wrote: > On Mon, Jan 06, 2003 at 10:58:25AM +0100, Harti Brandt wrote: > > On Fri, 3 Jan 2003, Nate Lawson wrote: > > NL>I was looking into some "could sleep messages" and found some bogus > > NL>locking in the attach routine of many drivers. Several init a mtx in > > NL>their softc and then lock/unlock it in their attach routine. This, of > > NL>course, does nothing to provide exclusive access to a device. I assume > > NL>there is going to be a global IF_LOCK or something to be used in attach > > NL>routines. Can someone fill me in on the intended design? > > > > Probably not. I asked the same question a couple of month ago and got 0 > > answers. I think, there is no way, the driver itself can assure exclusive > > access to the device it is attaching. It *must* assume, that there is some > > kind of locking around the call to the attach routine. Getting the lock in > > the softc inside the attach routine may be neccessary, because the routine > > may call other functions that assume they have the lock. > > Only using lock in softc can't assure its exclusive access > because there are some cases of changing some values in ifnet struct > outside of device driver routines. > > Most of the NIC drivers don't have its own locks for now, and using > both IFNET_*LOCK() and its own softc lock can't make everything in sync. My point. > There should be two use of locks IMO: one or more per-device locks > in driver softc for manipulating per-device private data protection, > and ifnet lock for each ifnet struct protection (such as ifnet.if_mtx). Looking further into sys/net/if.c, it appears that the list of interfaces is protected by IFNET_WLOCK in if_attach(). I think it's safe to work under the following assumptions: 1. newbus will not call an attach routine twice for the same hw 2. ifnet routines take care of themselves 3. per-device locking is only necessary to provide exclusive access within a given driver instance. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 6 18:12:16 2003 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 120F637B401 for ; Mon, 6 Jan 2003 18:12:15 -0800 (PST) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADA9B43ED4 for ; Mon, 6 Jan 2003 18:12:14 -0800 (PST) (envelope-from kelly@alicia.nttmcl.com) Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h072C9vm087314 for ; Mon, 6 Jan 2003 18:12:09 -0800 (PST) (envelope-from kelly@alicia.nttmcl.com) Received: from localhost (kelly@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) with ESMTP id h072C9be087311 for ; Mon, 6 Jan 2003 18:12:09 -0800 (PST) Date: Mon, 6 Jan 2003 18:12:09 -0800 (PST) From: Kelly Yancey To: freebsd-net@FreeBSD.org Subject: Radix nodes, netmasks, and bogus sockaddrs, oh my! Message-ID: <20030106174323.H86820-100000@alicia.nttmcl.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 Is there any reason to fix the code in the kernel which assumes rt_mask(rt) is a properly-formed sockaddr? For example, sys/net/rtsock.c:sysctl_dumpentry() just passes rt_mask(rt)'s contents to userland to be interpretted as a sockaddr but it seldomly is a properly-formed sockaddr (i.e. sa_family is almost always garbage and sa_len is 0 for the default route). Nothing in the base system appears to care that the netmask isn't a full-fledged sockaddr so it isn't hurting anything. The main reason I ask is that interfaces such as sysctl_rtable and routing sockets are currently making stronger claims then they are living up to and I would be inclined to fix it. But if it were to be fixed, is there a preference for whether it should be corrected in the routing table itself or just when the information is exported? Thanks, Kelly To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 6 18:41:35 2003 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 A2DEE37B401 for ; Mon, 6 Jan 2003 18:41:33 -0800 (PST) Received: from smtp.netli.com (ip2-pal-focal.netli.com [66.243.52.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B91743EB2 for ; Mon, 6 Jan 2003 18:41:33 -0800 (PST) (envelope-from vlm@netli.com) Received: (qmail 5439 invoked by uid 84); 7 Jan 2003 02:41:18 -0000 Received: from vlm@netli.com by l3-1 with qmail-scanner-0.96 (uvscan: v4.1.40/v4121. . Clean. Processed in 0.119913 secs); 07 Jan 2003 02:41:18 -0000 Received: from unknown (HELO netli.com) (172.17.1.38) by mx01-pal-lan.netli.lan with SMTP; 7 Jan 2003 02:41:18 -0000 Message-ID: <3E1A3E92.6030607@netli.com> Date: Mon, 06 Jan 2003 18:42:26 -0800 From: Lev Walkin Organization: Netli, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021117 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Abdul Basit Cc: net@freebsd.org Subject: Re: raw socket/icmp-echo References: <20030105052449.K49935-100000@wireless.cs.twsu.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 Abdul Basit wrote: > Hello, > > I was trying to learn raw sockets, I wrote a simple program > to get all icmp packets and display .. > > -- program > > int > main(void) > { > int sockfd; > int ip_len; > char *buf; > int n; > struct icmp *icmp; > struct ip *ip; > > buf = (char*) malloc(sizeof(struct ip)+sizeof(struct icmp)); > > sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); > Please make a habit to check the return values. To answer your question: (W. Richard Stevens) The semantics of BSD raw sockets are: - TCP and UDP: no one other than the kernel gets these. - ICMP: a copy of each ICMP gets passed to each matching raw socket, except for a few that the kernel generates the reply for: ICMP echo request, timestamp request, and mask request. - IGMP: all of these get passed to all matching raw sockets. - all other protocols that the kernel doesn't deal with (OSPF, etc.): these all get passed to all matching raw sockets. Also read http://www.whitefang.com/rin/rawfaq.html > > Also, if anyone know any good tutorial on bpf , let me know the url (some > simple example for capturing will be good .. i read bpf manpage, it seems > little obscure to me). Consider using libpcap - this is the portable library that uses bpf, raw socket, packet socket or whatever packets source is available for the particular platform. Pcap tutorial available here: http://reactor-core.org/security/libpcap-tutorial.html After you become familiar with libpcap, the bpf manual page will not seem obscure at all. Also, look at the trafd or ipcad daemons in the ports collection (/usr/ports/net). -- Lev Walkin vlm@netli.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 6 18:56:57 2003 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 8995037B401 for ; Mon, 6 Jan 2003 18:56:56 -0800 (PST) Received: from h00609772adf0.ne.client2.attbi.com (h00609772adf0.ne.client2.attbi.com [24.61.43.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id B204C43EB2 for ; Mon, 6 Jan 2003 18:56:55 -0800 (PST) (envelope-from rodrigc@attbi.com) Received: from h00609772adf0.ne.client2.attbi.com (localhost [127.0.0.1]) by h00609772adf0.ne.client2.attbi.com (8.12.6/8.12.6) with ESMTP id h072uCTc005054; Mon, 6 Jan 2003 21:56:12 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost) by h00609772adf0.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id h072uB7O005053; Mon, 6 Jan 2003 21:56:11 -0500 (EST) Date: Mon, 6 Jan 2003 21:56:11 -0500 From: Craig Rodrigues To: Lev Walkin Cc: Abdul Basit , net@freebsd.org Subject: Re: raw socket/icmp-echo Message-ID: <20030107025611.GA5014@attbi.com> References: <20030105052449.K49935-100000@wireless.cs.twsu.edu> <3E1A3E92.6030607@netli.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1A3E92.6030607@netli.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jan 06, 2003 at 06:42:26PM -0800, Lev Walkin wrote: > Consider using libpcap - this is the portable library that uses > bpf, raw socket, packet socket or whatever packets source is available > for the particular platform. > > Pcap tutorial available here: > http://reactor-core.org/security/libpcap-tutorial.html In addition to libpcap, I think if one is interested in using raw sockets, libnet is a library that is definitely one not to miss: http://www.packetfactory.net/libnet It is a well maintained library, and has examples for ICMP and other protocols. -- Craig Rodrigues http://home.attbi.com/~rodrigc rodrigc@attbi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 6 20:26:13 2003 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 D9CEE37B401 for ; Mon, 6 Jan 2003 20:26:12 -0800 (PST) Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40]) by mx1.FreeBSD.org (Postfix) with SMTP id 87C4443ED8 for ; Mon, 6 Jan 2003 20:26:12 -0800 (PST) (envelope-from shubha_mr@yahoo.com) Message-ID: <20030107042612.18203.qmail@web41207.mail.yahoo.com> Received: from [12.151.32.25] by web41207.mail.yahoo.com via HTTP; Tue, 07 Jan 2003 04:26:12 GMT Date: Tue, 7 Jan 2003 04:26:12 +0000 (GMT) From: =?iso-8859-1?q?shubha=20mr?= Subject: NIC throughput on multiprocessor low. To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, very surprisingly my ethernet gigabit NIC's performance (in MBPS) is more in single processor machine than in a dual processor machine.The tool used to measure the thruput was chariot.Is this due to cache issues? Any ideas to resolve this strange problem? Thanks in advance, shubha __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 6 21:13:20 2003 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 885C537B401 for ; Mon, 6 Jan 2003 21:13:17 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D05E43ED4 for ; Mon, 6 Jan 2003 21:13:16 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (c-24-130-112-121.we.client2.attbi.com [24.130.112.121]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h075DDC15132; Mon, 6 Jan 2003 21:13:13 -0800 (PST) Message-ID: <3E1A61E4.40308@isi.edu> Date: Mon, 06 Jan 2003 21:13:08 -0800 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: shubha mr Cc: freebsd-net@FreeBSD.org Subject: Re: NIC throughput on multiprocessor low. References: <20030107042612.18203.qmail@web41207.mail.yahoo.com> In-Reply-To: <20030107042612.18203.qmail@web41207.mail.yahoo.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040801050604000407060306" Sender: owner-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. --------------ms040801050604000407060306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On 1/6/2003 8:26 PM, shubha mr wrote: > > very surprisingly my ethernet gigabit NIC's > performance (in MBPS) is more in single processor > machine than in a dual processor machine.The tool used > to measure the thruput was chariot.Is this due to > cache issues? Any ideas to resolve this strange > problem? You'll have to provide sustantially more information before a diagnosis can be started. Which version of FreeBSD? Network topology? Which hardware (CPU, NICs, memory), and you did measure the same setup once with one and one with two CPUs (and not different setups/machines), right? Finally, what were the numbers you got when you measured (and what is chariot)? Lars -- Lars Eggert USC Information Sciences Institute --------------ms040801050604000407060306 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDEwNzA1MTMwOFowIwYJKoZIhvcNAQkEMRYEFAY/eZ7LijhqC3jz0d7E 2msD/NL0MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAWVSOXlp9FZ5IbXgRUFXsOU3RWm1Fol0++iqY Wm2kw0bJ/qRexVLHJOznL/HW8pZ9CSR1YtCYgSzpDQeG75/k3TobrOX0rLPOWD/F9FF+I7Hf 6d4hQ5QH95TBS+y3W7xOCT/8OCFKRT7o94mpT2BtT9IobpChNhEbKbvSi8Y8ukMX/Ohb4zAY IMk//0hYh3lu0PRRC58BaN0Cpo40ABBAqlc0OXyJzsAOLCWNVi7krhxLWVc8xrlpUuMrRUIh LchY04lH4gIuPPtCwwHROFnoPlqbnQSATAPc3gxFPyXlK3GO7ecJpJo1hJLwp6ZctpmNxcYS ReARjHLrj9UqwyKMQgAAAAAAAA== --------------ms040801050604000407060306-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 6 23:20:10 2003 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 AD6A637B401; Mon, 6 Jan 2003 23:20:09 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB87243EE1; Mon, 6 Jan 2003 23:20:08 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h077K71e066419; Tue, 7 Jan 2003 00:20:08 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 07 Jan 2003 00:19:24 -0700 (MST) Message-Id: <20030107.001924.02080410.imp@bsdimp.com> To: nate@root.org Cc: current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Proper -current if_attach locking? From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) 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 In message: Nate Lawson writes: : I was looking into some "could sleep messages" and found some bogus : locking in the attach routine of many drivers. Several init a mtx in : their softc and then lock/unlock it in their attach routine. This, of : course, does nothing to provide exclusive access to a device. I assume : there is going to be a global IF_LOCK or something to be used in attach : routines. Can someone fill me in on the intended design? The locking in the attach routines is generally bogus. Locking is only needed when you have more than one thread of execution. You don't have more than one thread of execution until after you establish the ISR and turn on interrupts. We should likely not be enabling interrupts until very late in the attach routine so that we don't need any locking in them. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 0:30:23 2003 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 790AE37B401; Tue, 7 Jan 2003 00:30:20 -0800 (PST) Received: from badboy.mail.pas.earthlink.net (badboy.mail.pas.earthlink.net [207.217.120.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id A932C43EE1; Tue, 7 Jan 2003 00:30:19 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from heron (heron.mail.pas.earthlink.net [207.217.120.189]) by badboy.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h077u5l15867; Mon, 6 Jan 2003 23:56:05 -0800 (PST) Received: from pool0087.cvx21-bradley.dialup.earthlink.net ([209.179.192.87] helo=mindspring.com) by heron with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18VoaK-0002nU-00; Mon, 06 Jan 2003 23:55:41 -0800 Message-ID: <3E1A87A8.F9C079F@mindspring.com> Date: Mon, 06 Jan 2003 23:54:16 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: nate@root.org, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Proper -current if_attach locking? References: <20030107.001924.02080410.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a40657a9cd98dbd816162151bf48de008d3ca473d225a0f487350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "M. Warner Losh" wrote: > In message: > Nate Lawson writes: > : I was looking into some "could sleep messages" and found some bogus > : locking in the attach routine of many drivers. Several init a mtx in > : their softc and then lock/unlock it in their attach routine. This, of > : course, does nothing to provide exclusive access to a device. I assume > : there is going to be a global IF_LOCK or something to be used in attach > : routines. Can someone fill me in on the intended design? > > The locking in the attach routines is generally bogus. Locking is > only needed when you have more than one thread of execution. You > don't have more than one thread of execution until after you establish > the ISR and turn on interrupts. We should likely not be enabling > interrupts until very late in the attach routine so that we don't need > any locking in them. I looked at this. It seems to me that it's not quite that simple (sorry). I think that there are issues with locking because you don't know if this is a driver that's getting loaded well after the system has booted, or if this is a PCCARD or other "hot plug" device that has just arrived in the system. It also seems to me that the "reversal" problems that would result by simply inserting locking have to do with the fact that the code is relatively schitzophrenic on deciding whether it's locking data, or it's locking a critical path. The entire idea of lock order reversals (please, don't use the abbreviation "LOR": my mind keeps telling me that Legolas just got his commit bit) is predicated, I think, on the idea that there is an order of operation that has to be adhered to because we are talking not about data object locking, we are in fact talking about (theoretically independent) code path locking, and what happens on a reentry during a sleep. Basically, this means that for code that can't result in a sleep, there's no such thing as a lock order reversal -- there's only locking at the wrong functional layer. In this particular case, we're talking about a interface list, and we're talking about a device instance, and the events that get a device on or off the list are *not* independent and they *are* mutually exclusive, based on state. Given all that, it seems to me that this would be an ideal place for a "critical section" lock -- or, at least, a lock that's asserted on the list of interfaces, and which doesn't have any witness registration (per Bruce's earlier suggestion). My preference (if it's not obvious) would be a critical section lock, but a data lock on a list held over the same operations is functionally the same thing, anyway. Perhaps it's time to step back, and look over the overall locking philosophy that everyone is supposed to be implementing to, and the implementation assumptions that that philosophy makes necessary for things to work? I think that some of the assumptions are themselves mutually exclusive with current implementation, and it would be nice to know, up front, what needs to be rewritten, and what *should* be rewritten, to conform to the new philosophy. I can't be the only one who finds FreeBSD 5.x to be in such a state of flux that it's almost impossible to know what a correct implementation is supposed to look like, for a given subsystem and/or device driver, list, etc.. If someone were to "lay down the law", we could at least discuss it, and come to some conclusions that would let people know what to do -- even if there's no change in "the law" as a result, it's a useful exercise, since people can then just "code to the spec.", and not have to have in depth knowledge of the overall design (if there is one) to deal with all the related issues... they can just copy the changes into every other driver/whatever that's in the same niche, ecologically. Parallel progress is a Good Thing(tm). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 1:15:23 2003 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 A540137B401; Tue, 7 Jan 2003 01:15:21 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6B1943ED8; Tue, 7 Jan 2003 01:15:20 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h079FD1e066855; Tue, 7 Jan 2003 02:15:13 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 07 Jan 2003 02:14:28 -0700 (MST) Message-Id: <20030107.021428.126452776.imp@bsdimp.com> To: tlambert2@mindspring.com Cc: nate@root.org, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Proper -current if_attach locking? From: "M. Warner Losh" In-Reply-To: <3E1A87A8.F9C079F@mindspring.com> References: <20030107.001924.02080410.imp@bsdimp.com> <3E1A87A8.F9C079F@mindspring.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) 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 In message: <3E1A87A8.F9C079F@mindspring.com> Terry Lambert writes: : "M. Warner Losh" wrote: : > In message: : > Nate Lawson writes: : > : I was looking into some "could sleep messages" and found some bogus : > : locking in the attach routine of many drivers. Several init a mtx in : > : their softc and then lock/unlock it in their attach routine. This, of : > : course, does nothing to provide exclusive access to a device. I assume : > : there is going to be a global IF_LOCK or something to be used in attach : > : routines. Can someone fill me in on the intended design? : > : > The locking in the attach routines is generally bogus. Locking is : > only needed when you have more than one thread of execution. You : > don't have more than one thread of execution until after you establish : > the ISR and turn on interrupts. We should likely not be enabling : > interrupts until very late in the attach routine so that we don't need : > any locking in them. : : I looked at this. It seems to me that it's not quite that : simple (sorry). I think that there are issues with locking : because you don't know if this is a driver that's getting : loaded well after the system has booted, or if this is a : PCCARD or other "hot plug" device that has just arrived in : the system. That doesn't mattar at all. If it is a new device that's just arrived, the attach still won't be interrupted *by other code in the driver* until after it has setup its ISR and told the hardware to start generating interrupts. No device locking is needed in the attach routine until after interrupts are enabled in the hardware. : It also seems to me that the "reversal" problems that would : result by simply inserting locking have to do with the fact : that the code is relatively schitzophrenic on deciding whether : it's locking data, or it's locking a critical path. The reversal is because of the bogus locking. The first time through it locks the device then the interface. However, after that it locks the interface and then the device, which can be bad. It does point to a problem, however, in that sometimes we'll take out the locks in one order and other times other orders depending on the code path if we aren't careful. I should go look at the new code more closely. I worry that in the non interrupt case we get things in the IF, DEV order (because the IF locks, then calls the callback routines, which then call the DEV lock). But in the interrupt case we get the DEV lock first, then try to queue data and that somehow causes the IF locks to be grabbed. But you are right, I do need to go look at the code to see what, exactly, is happening and how the new interface locking code is interacting with the semi-bogus locking than many of the wpaul drivers have in them now. : I can't be the only one who finds FreeBSD 5.x to be in such a state : of flux that it's almost impossible to know what a correct : implementation is supposed to look like, for a given subsystem : and/or device driver, list, etc.. There we agree. It takes a lot to keep up, and even then I fall behind when something new happens behind my back. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 1:27: 8 2003 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 0686F37B401; Tue, 7 Jan 2003 01:27:07 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5055C43EB2; Tue, 7 Jan 2003 01:27:06 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h079R11e066930; Tue, 7 Jan 2003 02:27:01 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 07 Jan 2003 02:26:17 -0700 (MST) Message-Id: <20030107.022617.23700606.imp@bsdimp.com> To: tlambert2@mindspring.com Cc: nate@root.org, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Proper -current if_attach locking? From: "M. Warner Losh" In-Reply-To: <20030107.021428.126452776.imp@bsdimp.com> References: <20030107.001924.02080410.imp@bsdimp.com> <3E1A87A8.F9C079F@mindspring.com> <20030107.021428.126452776.imp@bsdimp.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) 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 I was right (and I think you are too). We do have lock issues. dc_attach does approximately: DC_LOCK ether_attach() (which does a IFNET_WLOCK/UNLOCK pair) DC_UNLOCK (this sets the lock order to be DC_LOCK, IFNET_WLOCK). However in if_slowtimo we have: if_slowtimo(arg) { ... IFNET_RLOCK(); ... if (ifp->if_watchdog) (*ifp->if_watchdog)(ifp); ... IFNET_RUNLOCK(); } and dc_watchdog does a DC_LOCK/UNLOCK pair). This is a Lock Order Reversal, and not a LotR :-) What's worse is that dc_intr does: DC_LOCK ...dc_start (which calls IF_PREPEND which does the IFNET_LOCK/UNLOCK thing) DC_UNLOCK So even if we remove the one from attach, it looks like we have others lurking in the code. Either that, or it is too late for me to be looking at code like this :-( Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 7: 3:26 2003 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 62D0437B401; Tue, 7 Jan 2003 07:03:24 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB2DD43ED8; Tue, 7 Jan 2003 07:03:23 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.6/8.12.6) with ESMTP id h07F3Kro007789 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Jan 2003 10:03:20 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h07F3Ff59535; Tue, 7 Jan 2003 10:03:15 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15898.60467.681434.927797@grasshopper.cs.duke.edu> Date: Tue, 7 Jan 2003 10:03:15 -0500 (EST) To: "M. Warner Losh" Cc: tlambert2@mindspring.com, nate@root.org, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Proper -current if_attach locking? In-Reply-To: <20030107.022617.23700606.imp@bsdimp.com> References: <20030107.001924.02080410.imp@bsdimp.com> <3E1A87A8.F9C079F@mindspring.com> <20030107.021428.126452776.imp@bsdimp.com> <20030107.022617.23700606.imp@bsdimp.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org M. Warner Losh writes: <..> > However in if_slowtimo we have: > > if_slowtimo(arg) > { > ... IFNET_RLOCK(); > ... if (ifp->if_watchdog) > (*ifp->if_watchdog)(ifp); > ... IFNET_RUNLOCK(); > } > > and dc_watchdog does a DC_LOCK/UNLOCK pair). This is a Lock Order > Reversal, and not a LotR :-) > > What's worse is that dc_intr does: > > DC_LOCK > ...dc_start (which calls IF_PREPEND which does the IFNET_LOCK/UNLOCK thing) > DC_UNLOCK > > So even if we remove the one from attach, it looks like we have others > lurking in the code. > > Either that, or it is too late for me to be looking at code like this > :-( > I think its too late at night ;) The IFNET_RLOCK() called in if_slowtimo() is a global lock for the list of ifnet structs to ensure that no devices are removed or added while something may be using it. There is one ifnet list in the system. The lock in IF_PREPEND() (and more commonly used in drivers, IF_DEQUE()) is per-ifq, to protect against multiple accesses to a single ifq. There are many ifqs in the system. FWIW, I've been running my 3rd party Myrinet driver Giant-free and have had no problems, and no lock order reversals. I don't do bogus locking in my attach routine, though :) FWIW2: Running Giant-free brings -current TCP performance up to nearly 63% of -stable performance (from 39%), and udp xmit perf up to 87% of -stable. (testing w/o WITNESS). Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 8:20:52 2003 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 1D04337B401 for ; Tue, 7 Jan 2003 08:20:51 -0800 (PST) Received: from relay.comm2000.it (doppelganger.kpnqwest.it [212.97.34.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C0B343ED4 for ; Tue, 7 Jan 2003 08:20:50 -0800 (PST) (envelope-from massimo@datacode.it) Received: from insomma.local.lan (irimi.datacode.it [212.97.41.22]) by relay.comm2000.it (8.12.6/MFAGMM-19990726) with ESMTP id h07GL0Sg023765 for ; Tue, 7 Jan 2003 17:21:00 +0100 X-SMTP-Peer: irimi.datacode.it [212.97.41.22] Received: from massimo.datacode.it (massimo.datacode.it [192.168.1.13]) by insomma.local.lan (8.12.6/8.11.3) with ESMTP id h07GKEju064023 for ; Tue, 7 Jan 2003 17:20:14 +0100 (CET) (envelope-from massimo@datacode.it) Subject: mpd to work with ipfilter From: Massimo Lusetti To: freebsd-net@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 07 Jan 2003 17:20:18 +0100 Message-Id: <1041956418.1658.65.camel@massimo.datacode.it> Mime-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm trying to get mpd running beside ipfilter within the same box but i'm getting strange behavior. I've got ipfilter to: pass (in|out) tcp/1723 and gre protocol on the outside interface pass (in|out) all on ng* and other rules that let pass something and block with log the rest. When i try to istantiate a connection i got a succesfull login with Win client but no network services run correctly, if i totally open the fw i got the vpn runn correctly. The strange thing is that in the log of ipfilter i get no message about packet beeing blocked !? Where's my fault ? Regards, -- Massimo.run(); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 10: 6:56 2003 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 7C83A37B406; Tue, 7 Jan 2003 10:06:52 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E62D644322; Tue, 7 Jan 2003 10:01:22 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h07I0N1e069426; Tue, 7 Jan 2003 11:00:23 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 07 Jan 2003 10:59:33 -0700 (MST) Message-Id: <20030107.105933.19259527.imp@bsdimp.com> To: gallatin@cs.duke.edu Cc: tlambert2@mindspring.com, nate@root.org, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Proper -current if_attach locking? From: "M. Warner Losh" In-Reply-To: <15898.60467.681434.927797@grasshopper.cs.duke.edu> References: <20030107.021428.126452776.imp@bsdimp.com> <20030107.022617.23700606.imp@bsdimp.com> <15898.60467.681434.927797@grasshopper.cs.duke.edu> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) 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 In message: <15898.60467.681434.927797@grasshopper.cs.duke.edu> Andrew Gallatin writes: : The IFNET_RLOCK() called in if_slowtimo() is a global lock for the : list of ifnet structs to ensure that no devices are removed or added : while something may be using it. There is one ifnet list in the system. So this means that only the locking in attach is bogus, and similar locking in detach is also bogus because they produce lock order reversals as the global lock is held to insert/remove if interfaces. : The lock in IF_PREPEND() (and more commonly used in drivers, : IF_DEQUE()) is per-ifq, to protect against multiple accesses : to a single ifq. There are many ifqs in the system. I knew I must have been missing something really fundamental last night. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 10: 7:37 2003 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 A27B737B499 for ; Tue, 7 Jan 2003 10:07:33 -0800 (PST) Received: from ShadoW.OTEL.net (JuDiCaToR.OTEL.net [212.36.9.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3395F43FEE for ; Tue, 7 Jan 2003 10:06:29 -0800 (PST) (envelope-from tbyte@otel.net) Received: from shadowhand.otel.net ([212.36.9.116]) by ShadoW.OTEL.net with esmtp (Exim 3.36 #1) id 18Vy79-0008h1-00; Tue, 07 Jan 2003 20:06:11 +0200 Date: Tue, 7 Jan 2003 20:06:11 +0200 (EET) From: Iasen Kostoff To: Lars Eggert Cc: randall ehren , Subject: Re: default route In-Reply-To: <3E18A3D9.3010909@isi.edu> Message-ID: <20030107200550.U1633-100000@shadowhand.OTEL.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 User route add default x.x.x.x -ifp iface On Sun, 5 Jan 2003, Lars Eggert wrote: > On 1/5/2003 1:26 PM, randall ehren wrote: > > > > how can i assign the default gateway to use fxp0 instead? > > route delete default > route add default A.B.C.D > > As described in the man page. > > Lars > -- > Lars Eggert USC Information Sciences Institute > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 10: 9:14 2003 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 A400D37B401; Tue, 7 Jan 2003 10:09:13 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3BF543E4A; Tue, 7 Jan 2003 10:09:08 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.6/8.12.6) with ESMTP id h07I96ro018987 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Jan 2003 13:09:06 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h07I91S59743; Tue, 7 Jan 2003 13:09:01 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15899.6077.710661.497492@grasshopper.cs.duke.edu> Date: Tue, 7 Jan 2003 13:09:01 -0500 (EST) To: "M. Warner Losh" Cc: tlambert2@mindspring.com, nate@root.org, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Proper -current if_attach locking? In-Reply-To: <20030107.105933.19259527.imp@bsdimp.com> References: <20030107.021428.126452776.imp@bsdimp.com> <20030107.022617.23700606.imp@bsdimp.com> <15898.60467.681434.927797@grasshopper.cs.duke.edu> <20030107.105933.19259527.imp@bsdimp.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org M. Warner Losh writes: > In message: <15898.60467.681434.927797@grasshopper.cs.duke.edu> > Andrew Gallatin writes: > : The IFNET_RLOCK() called in if_slowtimo() is a global lock for the > : list of ifnet structs to ensure that no devices are removed or added > : while something may be using it. There is one ifnet list in the system. > > So this means that only the locking in attach is bogus, and similar > locking in detach is also bogus because they produce lock order > reversals as the global lock is held to insert/remove if interfaces. Yes. Though I haven't looked at if_dc myself, there may be other locking problems. I've only been commenting on the ones that you brought up. But back to an earlier point. Somebody (you?) validly pointed out that the driver should not be callable and should not generate interrupts until its finished attaching. The lock in its attach was probably a somewhat misguided attempt at that. The first point can be accomplished by doing the ether_ifattach() last, but the second may be harder. I do that by poking a bit on my card which prevents it from generating interrupts while the device is being setup. Not sure if a similar bit exists on tulip cards. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 12:18: 0 2003 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 43E5037B401 for ; Tue, 7 Jan 2003 12:17:59 -0800 (PST) Received: from ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B168243EB2 for ; Tue, 7 Jan 2003 12:17:58 -0800 (PST) (envelope-from ambrisko@www.ambrisko.com) Received: from www.ambrisko.com (localhost [127.0.0.1]) by ambrisko.com (8.12.6/8.12.6) with ESMTP id h07KHwF0037994 for ; Tue, 7 Jan 2003 12:17:58 -0800 (PST) (envelope-from ambrisko@www.ambrisko.com) Received: (from ambrisko@localhost) by www.ambrisko.com (8.12.6/8.12.6/Submit) id h07KHwCJ037993 for freebsd-net@freebsd.org; Tue, 7 Jan 2003 12:17:58 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200301072017.h07KHwCJ037993@www.ambrisko.com> Subject: if_tap.c interaction bug with netgraph?? To: freebsd-net@freebsd.org Date: Tue, 7 Jan 2003 12:17:58 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (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 I've run into this bug since about 4.6-stable of some time. I use netgraph to connect to a tap device in vmnet mode since in vmnet mode it is persistan. In tap mode if comes and goes depending on whether or not I have the device open. Anyways I couldn't get data to come in the vmnet node through netgraph with only the interface up, auto source off and promicious on (ie. bridge mode). This patches fixes it by doing and init to get the interface going. Any objections to this change? If you give the interface an IP then it works okay except you shouldn't have to do that. Thanks, Doug A. Index: net/if_tap.c =================================================================== RCS file: /home/cvs/freebsd/src/sys/net/if_tap.c,v retrieving revision 1.3.2.3 diff -c -r1.3.2.3 if_tap.c *** net/if_tap.c 14 Apr 2002 21:41:48 -0000 1.3.2.3 --- net/if_tap.c 7 Jan 2003 20:02:18 -0000 *************** *** 426,431 **** --- 426,432 ---- return (dummy); case SIOCSIFFLAGS: /* XXX -- just like vmnet does */ + tapifinit(tp); case SIOCADDMULTI: case SIOCDELMULTI: break; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 12:59:21 2003 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 8B42137B401; Tue, 7 Jan 2003 12:59:19 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9452943ED8; Tue, 7 Jan 2003 12:59:18 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h07Kx51e070574; Tue, 7 Jan 2003 13:59:06 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 07 Jan 2003 13:58:10 -0700 (MST) Message-Id: <20030107.135810.92265343.imp@bsdimp.com> To: gallatin@cs.duke.edu Cc: tlambert2@mindspring.com, nate@root.org, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Proper -current if_attach locking? From: "M. Warner Losh" In-Reply-To: <15899.6077.710661.497492@grasshopper.cs.duke.edu> References: <15898.60467.681434.927797@grasshopper.cs.duke.edu> <20030107.105933.19259527.imp@bsdimp.com> <15899.6077.710661.497492@grasshopper.cs.duke.edu> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) 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 In message: <15899.6077.710661.497492@grasshopper.cs.duke.edu> Andrew Gallatin writes: : : M. Warner Losh writes: : > In message: <15898.60467.681434.927797@grasshopper.cs.duke.edu> : > Andrew Gallatin writes: : > : The IFNET_RLOCK() called in if_slowtimo() is a global lock for the : > : list of ifnet structs to ensure that no devices are removed or added : > : while something may be using it. There is one ifnet list in the system. : > : > So this means that only the locking in attach is bogus, and similar : > locking in detach is also bogus because they produce lock order : > reversals as the global lock is held to insert/remove if interfaces. : : Yes. Though I haven't looked at if_dc myself, there may be other : locking problems. I've only been commenting on the ones that you : brought up. : : But back to an earlier point. Somebody (you?) validly pointed out : that the driver should not be callable and should not generate : interrupts until its finished attaching. The lock in its attach was : probably a somewhat misguided attempt at that. Yes. That was me. There are some drivers that have separated front/back ends that makes this harder, but most of them don't. : The first point can be accomplished by doing the ether_ifattach() : last, but the second may be harder. I do that by poking a bit on my : card which prevents it from generating interrupts while the device is : being setup. Not sure if a similar bit exists on tulip cards. All PCI cards have to be able to turn off their interrupt sources, otherwise interrupt storms result. At least that's my understanding. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 14:15: 3 2003 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 34BAA37B405 for ; Tue, 7 Jan 2003 14:15:02 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 557C243EE1 for ; Tue, 7 Jan 2003 14:15:01 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 15716 invoked by uid 1000); 7 Jan 2003 22:15:02 -0000 Date: Tue, 7 Jan 2003 14:15:02 -0800 (PST) From: Nate Lawson To: security@freebsd.org, net@freebsd.org Subject: @stake advisory: etherleak 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 The short of it is that if a tx packet is < 64 bytes (min ethernet frame len), data can be leaked if the driver transmits 64 bytes. It seems our use of mbufs would prevent leakage but I haven't examined any drivers to verify this. http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 14:55:38 2003 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 4E2B337B401 for ; Tue, 7 Jan 2003 14:55:37 -0800 (PST) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id EACE643EE1 for ; Tue, 7 Jan 2003 14:55:36 -0800 (PST) (envelope-from nectar@nectar.cc) Received: by gw.nectar.cc (Postfix, from userid 1001) id 7AE4E47; Tue, 7 Jan 2003 16:55:36 -0600 (CST) Date: Tue, 7 Jan 2003 16:55:36 -0600 From: "Jacques A. Vidrine" To: freebsd-net@FreeBSD.org Subject: network device drivers and information leak? Message-ID: <20030107225536.GA54470@hellblazer.nectar.cc> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-net@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i X-Url: http://www.celabo.org/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Might FreeBSD suffer from this issue? Do all our drivers pad packets with zero octets properly? http://www.kb.cert.org/vuls/id/412115 http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf Cheers, -- Jacques A. Vidrine http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 15: 6:40 2003 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 554AE37B401 for ; Tue, 7 Jan 2003 15:06:39 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id C42FD43E4A for ; Tue, 7 Jan 2003 15:06:38 -0800 (PST) (envelope-from Maksim.Yevmenkin@cw.com) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Jan 2003 15:06:38 -0800 Received: from exodus.net ([165.193.27.35]) by scl8owa01.int.exodus.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Jan 2003 15:06:38 -0800 Message-ID: <3E1B5CDA.3010309@exodus.net> Date: Tue, 07 Jan 2003 15:03:54 -0800 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Ambrisko Cc: freebsd-net@FreeBSD.ORG Subject: Re: if_tap.c interaction bug with netgraph?? References: <200301072017.h07KHwCJ037993@www.ambrisko.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jan 2003 23:06:38.0593 (UTC) FILETIME=[6EDF8F10:01C2B6A1] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Doug, >I've run into this bug since about 4.6-stable of some time. I use netgraph >to connect to a tap device in vmnet mode since in vmnet mode it is >persistan. In tap mode if comes and goes depending on whether or not I >have the device open. Anyways I couldn't get data to come in the vmnet >node through netgraph with only the interface up, auto source off and >promicious on (ie. bridge mode). This patches fixes it by doing >and init to get the interface going. Any objections to this change? >If you give the interface an IP then it works okay except you shouldn't >have to do that. > "vmnet" mode is special. It has been introduced when if_tap and vmnet were merged into one driver. I tried to be compatible with old vmnet driver (note XXX comment). Just need to make sure this does not break VMWare (will try later today). Another possible solution is to introduce "persistent" mode for tap, i.e. a couple of new ioctl()'s for tap device to set/get persistent mode and to init tap interface. thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 15:58:52 2003 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 2FEEB37B401; Tue, 7 Jan 2003 15:58:51 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73C9C43EA9; Tue, 7 Jan 2003 15:58:50 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h08014N40358; Tue, 7 Jan 2003 19:01:04 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Tue, 7 Jan 2003 19:01:04 -0500 From: Bosko Milekic To: Nate Lawson Cc: security@freebsd.org, net@freebsd.org Subject: Re: @stake advisory: etherleak Message-ID: <20030107190104.A40254@unixdaemons.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from nate@root.org on Tue, Jan 07, 2003 at 02:15:02PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jan 07, 2003 at 02:15:02PM -0800, Nate Lawson wrote: > The short of it is that if a tx packet is < 64 bytes (min ethernet frame > len), data can be leaked if the driver transmits 64 bytes. It seems our > use of mbufs would prevent leakage but I haven't examined any drivers to > verify this. > > http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf > > -Nate Heh! This seems like a pretty long paper for what it's worth. I can see how we could have the same "problem" but keep in mind the scope of the issue (the paper blows it out of proportion, I think, for someone who may not necessarily understand the issue too well): we're talking about very small packets here, under 64 bytes. So the "leaked information" will be AT MOST 63 bytes, but practically somewhere around 10 bytes and would be very occasional. Not to mention that it's totally undefined and random. An "attacker" might as well just rely on temperature to guess at how to interpret what he/she's seeing in those few bytes. The data in our case is probably DMA'd straight out of the mbuf's data region so what you'll probably find in there is just randomness from something before, not necessarily network data. Moreover, as the paper does mention, although the RFCs do appear to specify that for packets that are padded to the minimum ethernet packet size the padded bytes should be zeroed, it's pretty ambiguous as to where the zero-ing should happen. As noted, some cards will do the zeroing onboard. If you really see this as a 'security problem' then feel free to zero the padded bytes manually in the problematic drivers. Doing it universally would be too much in my opinion, especially given that some hardware takes care of it itself. -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 17:23:35 2003 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 EE3D737B405 for ; Tue, 7 Jan 2003 17:23:30 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 428E343EA9 for ; Tue, 7 Jan 2003 17:23:30 -0800 (PST) (envelope-from Maksim.Yevmenkin@cw.com) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Jan 2003 17:23:30 -0800 Received: from exodus.net ([165.193.27.35]) by scl8owa01.int.exodus.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Jan 2003 17:23:29 -0800 Message-ID: <3E1B7CED.8020907@exodus.net> Date: Tue, 07 Jan 2003 17:20:45 -0800 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Ambrisko Cc: net@freebsd.org Subject: Re: if_tap.c interaction bug with netgraph?? References: <200301072316.h07NGuEJ047694@www.ambrisko.com> Content-Type: multipart/mixed; boundary="------------040204080006040801000807" X-OriginalArrivalTime: 08 Jan 2003 01:23:30.0031 (UTC) FILETIME=[8D458FF0:01C2B6B4] Sender: owner-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. --------------040204080006040801000807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Doug, >| >I've run into this bug since about 4.6-stable of some time. I use netgraph >| >to connect to a tap device in vmnet mode since in vmnet mode it is >| >persistan. In tap mode if comes and goes depending on whether or not I >| >have the device open. Anyways I couldn't get data to come in the vmnet >| >node through netgraph with only the interface up, auto source off and >| >promicious on (ie. bridge mode). This patches fixes it by doing >| >and init to get the interface going. Any objections to this change? >| >If you give the interface an IP then it works okay except you shouldn't >| >have to do that. >| >| "vmnet" mode is special. It has been introduced when if_tap and >| vmnet were merged into one driver. I tried to be compatible with old >| vmnet driver (note XXX comment). Just need to make sure this does >| not break VMWare (will try later today). > >Doesn't break vmware for me. I've been running this patch for a long time. >Also I've been doing it under -stable and not -current. I will need to >test this under -current to see what happens before checking it in. > Thank you. >Currently vmware would be broken if you didn't ifconfig tap1 and then >connected it to a physical NIC on the host so you could plumb the >vmware session to a real ethernet port. Something I have done in the >past. Vmware as normaly used wouldn't see this problem since it would >have an IP assigned to it. > >| Another possible solution is to introduce "persistent" mode for tap, i.e. >| a couple of new ioctl()'s for tap device to set/get persistent mode and >| to init tap interface. > >I guess that would work. Since I do most of this from shell scripts >using netgraph to connect things together in strange ways for testing >it's nice not having to use any ioctl's. > I have attached the patch (untested) that implements three new ioctl() for tap device. You might want to try it. I agree ioctl() is not very shell friendly, but you always can write a five lines of C code and call it tapcontrol :) thanks, max --------------040204080006040801000807 Content-Type: text/plain; name="if_tap.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if_tap.diff" diff -u /sys/net/if_tap.c ./if_tap.c --- /sys/net/if_tap.c Mon Nov 25 15:23:38 2002 +++ ./if_tap.c Tue Jan 7 16:25:06 2003 @@ -464,7 +464,8 @@ * interface, if we are in VMnet mode. just close the device. */ - if (((tp->tap_flags & TAP_VMNET) == 0) && (ifp->if_flags & IFF_UP)) { + if (((tp->tap_flags & TAP_VMNET) == 0) && + ((tp->tap_flags & TAP_PERSIST) == 0) && (ifp->if_flags & IFF_UP)) { s = splimp(); if_down(ifp); if (ifp->if_flags & IFF_RUNNING) { @@ -739,6 +740,21 @@ case SIOCSIFADDR: /* set MAC address of the remote side */ bcopy(data, tp->ether_addr, sizeof(tp->ether_addr)); + break; + + case TAPINIT: + tapifinit(tp); + break; + + case TAPSPERSIST: + if (*(int *)data) + tp->tap_flags |= TAP_PERSIST; + else + tp->tap_flags &= ~TAP_PERSIST; + break; + + case TAPGPERSIST: + *(int *)data = (tp->tap_flags & TAP_PERSIST)? 1 : 0; break; default: diff -u /sys/net/if_tap.h ./if_tap.h --- /sys/net/if_tap.h Fri Apr 5 21:15:29 2002 +++ ./if_tap.h Tue Jan 7 16:22:29 2003 @@ -55,6 +55,9 @@ #define TAPGDEBUG _IOR('t', 89, int) #define TAPSIFINFO _IOW('t', 91, struct tapinfo) #define TAPGIFINFO _IOR('t', 92, struct tapinfo) +#define TAPINIT _IO ('t', 93) +#define TAPSPERSIST _IOW('t', 94, int) +#define TAPGPERSIST _IOW('t', 95, int) /* VMware ioctl's */ #define VMIO_SIOCSIFFLAGS _IO('V', 0) diff -u /sys/net/if_tapvar.h ./if_tapvar.h --- /sys/net/if_tapvar.h Fri Apr 5 21:15:29 2002 +++ ./if_tapvar.h Tue Jan 7 16:20:09 2003 @@ -53,6 +53,7 @@ #define TAP_ASYNC (1 << 3) #define TAP_READY (TAP_OPEN|TAP_INITED) #define TAP_VMNET (1 << 4) +#define TAP_PERSIST (1 << 5) u_int8_t ether_addr[ETHER_ADDR_LEN]; /* ether addr of the remote side */ --------------040204080006040801000807-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 18: 9:33 2003 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 DCCF637B405 for ; Tue, 7 Jan 2003 18:09:31 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 6EB2643E4A for ; Tue, 7 Jan 2003 18:09:27 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 16211 invoked by uid 1000); 8 Jan 2003 02:09:23 -0000 Date: Tue, 7 Jan 2003 18:09:23 -0800 (PST) From: Nate Lawson To: Bosko Milekic Cc: security@freebsd.org, net@freebsd.org Subject: Re: @stake advisory: etherleak In-Reply-To: <20030107190104.A40254@unixdaemons.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 7 Jan 2003, Bosko Milekic wrote: > On Tue, Jan 07, 2003 at 02:15:02PM -0800, Nate Lawson wrote: > > The short of it is that if a tx packet is < 64 bytes (min ethernet frame > > len), data can be leaked if the driver transmits 64 bytes. It seems our > > use of mbufs would prevent leakage but I haven't examined any drivers to > > verify this. > > > > http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf > > So the "leaked > information" will be AT MOST 63 bytes, but practically somewhere > around 10 bytes and would be very occasional. It depends on what's the shortest reply you can induce from a host. Perhaps there's something shorter than icmp but if you're not on the same network, it has to be at least 20 bytes (ip hdr) so you can see the response. In that case, you're getting at most 26 bytes of data. > Not to mention that > it's totally undefined and random. Well, you have the guarantee that it's network data since the min mbuf size is 128 bytes and a packet must be less than 64 bytes to trigger this. > An "attacker" might as well just > rely on temperature to guess at how to interpret what he/she's seeing > in those few bytes. The data in our case is probably DMA'd straight > out of the mbuf's data region so what you'll probably find in there is > just randomness from something before, not necessarily network data. Since the mbuf pool is statically allocated at boot, it's likely only mbuf hdrs or contents would leak this way. Still, this is data leakage even though it's a small channel. > Moreover, as the paper does mention, although the RFCs do appear to > specify that for packets that are padded to the minimum ethernet > packet size the padded bytes should be zeroed, it's pretty ambiguous > as to where the zero-ing should happen. As noted, some cards will do > the zeroing onboard. For cards that don't, it's the driver's responsibility to do this. Some do (xe) and some don't (ie). > If you really see this as a 'security problem' then feel free to zero > the padded bytes manually in the problematic drivers. Doing it > universally would be too much in my opinion, especially given that > some hardware takes care of it itself. I believe this should be done for the same reason that pages allocated to the user are pre-zeroed. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 7 19:44:54 2003 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 54FCC37B401; Tue, 7 Jan 2003 19:44:53 -0800 (PST) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0902343ED4; Tue, 7 Jan 2003 19:44:53 -0800 (PST) (envelope-from mbsd@pacbell.net) Received: from atlas ([64.168.24.241]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0H8D00G7EMESDG@mta7.pltn13.pbi.net>; Tue, 07 Jan 2003 19:44:52 -0800 (PST) Date: Tue, 07 Jan 2003 19:44:52 -0800 (PST) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= Subject: Re: @stake advisory: etherleak In-reply-to: X-X-Sender: mikko@atlas.home To: Nate Lawson Cc: Bosko Milekic , security@freebsd.org, net@freebsd.org Message-id: <20030107192435.B70415-100000@atlas.home> 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 On Tue, 7 Jan 2003, Nate Lawson wrote: > On Tue, 7 Jan 2003, Bosko Milekic wrote: [...] > > An "attacker" might as well just > > rely on temperature to guess at how to interpret what he/she's seeing > > in those few bytes. The data in our case is probably DMA'd straight > > out of the mbuf's data region so what you'll probably find in there is > > just randomness from something before, not necessarily network data. > > Since the mbuf pool is statically allocated at boot, it's likely only mbuf > hdrs or contents would leak this way. Still, this is data leakage even > though it's a small channel. This is definitely a security problem. It is also not new. First time I saw it was over five years ago; we could "poll" data from machines running various unix flavours. Just by pinging them we got snippets of data from inside the kernel of the target machine, including data from local connections and pipes. It was actually pretty easy to demonstrate significant leakage of recognizable information. $.02, /Mikko P.S. "rl" bzeros padding. Mikko Työläjärvi_______________________________________mikko@rsasecurity.com RSA Security To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 8 9:48:11 2003 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 4D01737B401; Wed, 8 Jan 2003 09:48:09 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E46943EB2; Wed, 8 Jan 2003 09:48:08 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h08HoLH42001; Wed, 8 Jan 2003 12:50:21 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Wed, 8 Jan 2003 12:50:21 -0500 From: Bosko Milekic To: Nate Lawson Cc: security@freebsd.org, net@freebsd.org Subject: Re: @stake advisory: etherleak Message-ID: <20030108125021.A41969@unixdaemons.com> References: <20030107190104.A40254@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from nate@root.org on Tue, Jan 07, 2003 at 06:09:23PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jan 07, 2003 at 06:09:23PM -0800, Nate Lawson wrote: > On Tue, 7 Jan 2003, Bosko Milekic wrote: > > On Tue, Jan 07, 2003 at 02:15:02PM -0800, Nate Lawson wrote: > > Not to mention that > > it's totally undefined and random. > > Well, you have the guarantee that it's network data since the min mbuf > size is 128 bytes and a packet must be less than 64 bytes to trigger this. No, not really. Yes, the mbufs come from a vmmap that is reserved for mbufs and clusters but it doesn't mean that the underlying physical memory contains network data, necessarily. It is the case if you're getting an mbuf from the allocator cache, but as soon as you make that call to vm you no longer have that guarantee. > > An "attacker" might as well just > > rely on temperature to guess at how to interpret what he/she's seeing > > in those few bytes. The data in our case is probably DMA'd straight > > out of the mbuf's data region so what you'll probably find in there is > > just randomness from something before, not necessarily network data. > > Since the mbuf pool is statically allocated at boot, it's likely only mbuf > hdrs or contents would leak this way. Still, this is data leakage even > though it's a small channel. No. You are leaking contents but it is not necessarily network data. It may be more often than not, but there is no way to determine what the nature/source of the data is remotely. > > Moreover, as the paper does mention, although the RFCs do appear to > > specify that for packets that are padded to the minimum ethernet > > packet size the padded bytes should be zeroed, it's pretty ambiguous > > as to where the zero-ing should happen. As noted, some cards will do > > the zeroing onboard. > > For cards that don't, it's the driver's responsibility to do this. Some > do (xe) and some don't (ie). > > > If you really see this as a 'security problem' then feel free to zero > > the padded bytes manually in the problematic drivers. Doing it > > universally would be too much in my opinion, especially given that > > some hardware takes care of it itself. > > I believe this should be done for the same reason that pages allocated to > the user are pre-zeroed. OK, but not in a universal fashion. I think drivers with this problem should implement it locally. Not all drivers have the problem because not all network cards "forget" to pad the data with zeros. > -Nate -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 8 12:28:30 2003 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 847BA37B401 for ; Wed, 8 Jan 2003 12:28:28 -0800 (PST) Received: from mel-rto4.wanadoo.fr (smtp-out-4.wanadoo.fr [193.252.19.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8259D43EE6 for ; Wed, 8 Jan 2003 12:28:27 -0800 (PST) (envelope-from vjardin@wanadoo.fr) Received: from mel-rta7.wanadoo.fr (193.252.19.61) by mel-rto4.wanadoo.fr (6.7.015) id 3E0C33FD0067FD80 for net@freebsd.org; Wed, 8 Jan 2003 21:28:26 +0100 Received: from there (217.128.206.18) by mel-rta7.wanadoo.fr (6.7.015) id 3E075B1B006C7811 for net@freebsd.org; Wed, 8 Jan 2003 21:28:26 +0100 Message-ID: <3E075B1B006C7811@mel-rta7.wanadoo.fr> (added by postmaster@wanadoo.fr) Content-Type: text/plain; charset="iso-8859-15" From: Vincent Jardin To: net@freebsd.org Subject: rt_refcnt and rtentry protection ?? Date: Wed, 8 Jan 2003 21:47:40 +0100 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 /* * Lookup or enter a new address in arptab. */ static struct llinfo_arp * arplookup(addr, create, proxy) u_long addr; int create, proxy; { register struct rtentry *rt; static struct sockaddr_inarp sin = {sizeof(sin), AF_INET }; const char *why = 0; sin.sin_addr.s_addr = addr; sin.sin_other = proxy ? SIN_PROXY : 0; rt = rtalloc1((struct sockaddr *)&sin, create, 0UL); if (rt == 0) return (0); rt->rt_refcnt--; if (rt->rt_flags & RTF_GATEWAY) /* XXX How can we be sure that rt won't be freeed by any other kernel thread now ?? XXX */ why = "host is not on local network"; else if ((rt->rt_flags & RTF_LLINFO) == 0) why = "could not allocate llinfo"; else if (rt->rt_gateway->sa_family != AF_LINK) why = "gateway route is not ours"; if (why && create) { log(LOG_DEBUG, "arplookup %s failed: %s\n", inet_ntoa(sin.sin_addr), why); return 0; } else if (why) { return 0; } return ((struct llinfo_arp *)rt->rt_llinfo); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 8 12:37:51 2003 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 5DFA637B401 for ; Wed, 8 Jan 2003 12:37:50 -0800 (PST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1692B43ED8 for ; Wed, 8 Jan 2003 12:37:50 -0800 (PST) (envelope-from hsu@FreeBSD.org) Received: from FreeBSD.org ([63.193.112.125]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0H8E00ASSXB1HW@mta5.snfc21.pbi.net> for net@freebsd.org; Wed, 08 Jan 2003 12:37:49 -0800 (PST) Date: Wed, 08 Jan 2003 12:38:06 -0800 From: Jeffrey Hsu Subject: Re: rt_refcnt and rtentry protection ?? In-reply-to: Message from Vincent Jardin "of Wed, 08 Jan 2003 21:47:40 +0100." <3E075B1B006C7811@mel-rta7.wanadoo.fr> To: Vincent Jardin Cc: net@freebsd.org Message-id: <0H8E00ASUXB1HW@mta5.snfc21.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 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 rtentry will get its own lock. The roadmap for locking up the IP stack looks like roughly like ifaddr ref counts, ifnet list, routing radix tree, ARP, ifaddr uses, and rtentry. I'm a little over 3/5 of the way done along this path. Jeffrey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 8 14: 3:12 2003 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 C561A37B401; Wed, 8 Jan 2003 14:03:10 -0800 (PST) Received: from mel-rto6.wanadoo.fr (smtp-out-6.wanadoo.fr [193.252.19.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id F30A843ED8; Wed, 8 Jan 2003 14:03:09 -0800 (PST) (envelope-from vjardin@wanadoo.fr) Received: from mel-rta7.wanadoo.fr (193.252.19.61) by mel-rto6.wanadoo.fr (6.7.015) id 3E0C343F006924B8; Wed, 8 Jan 2003 23:03:09 +0100 Received: from there (217.128.206.18) by mel-rta7.wanadoo.fr (6.7.015) id 3E075B1B006D4334; Wed, 8 Jan 2003 23:03:09 +0100 Message-ID: <3E075B1B006D4334@mel-rta7.wanadoo.fr> (added by postmaster@wanadoo.fr) Content-Type: text/plain; charset="iso-8859-1" From: Vincent Jardin To: Jeffrey Hsu Subject: Re: rt_refcnt and rtentry protection ?? Date: Wed, 8 Jan 2003 23:22:22 +0100 X-Mailer: KMail [version 1.3.2] Cc: net@freebsd.org References: <0H8E00ASUXB1HW@mta5.snfc21.pbi.net> In-Reply-To: <0H8E00ASUXB1HW@mta5.snfc21.pbi.net> 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 > > The roadmap for locking up the IP stack looks like roughly like ifaddr > ref counts, ifnet list, routing radix tree, ARP, ifaddr uses, and rtentry. However, it seems that the rtentries' rt_refcnt are not used like ifaddr, ifnet, ... It looks like something dirty has been done a long time ago. For example, the following lines: rt = rtalloc1((struct sockaddr *)&sin, create, 0UL); if (rt == 0) return (0); rt->rt_refcnt--; if (rt->rt_flags & RTF_GATEWAY) why = "host is not on local network"; else if ((rt->rt_flags & RTF_LLINFO) == 0) why = "could not allocate llinfo"; else if (rt->rt_gateway->sa_family != AF_LINK) why = "gateway route is not ours"; [...] return ((struct llinfo_arp *)rt->rt_llinfo); Why is rt_refnt decreased so early and not later ? I would think that it would be more correct to have: rt = rtalloc1((struct sockaddr *)&sin, create, 0UL); if (rt == 0) return (0); if (rt->rt_flags & RTF_GATEWAY) why = "host is not on local network"; else if ((rt->rt_flags & RTF_LLINFO) == 0) why = "could not allocate llinfo"; else if (rt->rt_gateway->sa_family != AF_LINK) why = "gateway route is not ours"; [...] rt->rt_refcnt--; return ((struct llinfo_arp *)rt->rt_llinfo); It looks like rt_refcnt is decreased just after many rtalloc() in order just to be sure that it won't be forgotten later, doesn'it ? > I'm a little over 3/5 of the way done along this path. Good luck, Vincent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 8 14: 6:43 2003 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 BC44837B401 for ; Wed, 8 Jan 2003 14:06:42 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11BF443ED1 for ; Wed, 8 Jan 2003 14:06:42 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h08M6eCJ008987 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 8 Jan 2003 17:06:41 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h08M6eHm008984; Wed, 8 Jan 2003 17:06:40 -0500 (EST) (envelope-from wollman) Date: Wed, 8 Jan 2003 17:06:40 -0500 (EST) From: Garrett Wollman Message-Id: <200301082206.h08M6eHm008984@khavrinen.lcs.mit.edu> To: Vincent Jardin Cc: net@FreeBSD.ORG Subject: Re: rt_refcnt and rtentry protection ?? In-Reply-To: <3E075B1B006D4334@mel-rta7.wanadoo.fr> (added by postmaster@wanadoo.fr) References: <0H8E00ASUXB1HW@mta5.snfc21.pbi.net> <3E075B1B006D4334@mel-rta7.wanadoo.fr> Sender: owner-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 is rt_refnt decreased so early and not later ? So long as the route is marked RTF_UP, it cannot be deleted. In a single-threaded kernel, it is not possible for this code to be preempted, so there is no means by which the route flags could be changed. (RTF_UP is unset when and only when the route is deleted from the radix tree.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 8 14:12:27 2003 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 BCE3637B401 for ; Wed, 8 Jan 2003 14:12:26 -0800 (PST) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 754ED43E4A for ; Wed, 8 Jan 2003 14:12:26 -0800 (PST) (envelope-from hsu@FreeBSD.org) Received: from FreeBSD.org ([63.193.112.125]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0H8F008W01OPKT@mta7.pltn13.pbi.net> for net@freebsd.org; Wed, 08 Jan 2003 14:12:26 -0800 (PST) Date: Wed, 08 Jan 2003 14:12:44 -0800 From: Jeffrey Hsu Subject: Re: rt_refcnt and rtentry protection ?? In-reply-to: Message from Vincent Jardin "of Wed, 08 Jan 2003 23:22:22 +0100." <3E075B1B006D4334@mel-rta7.wanadoo.fr> To: Vincent Jardin Cc: net@freebsd.org Message-id: <0H8F008W11OPKT@mta7.pltn13.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 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 if (rt->rt_flags & RTF_GATEWAY) /* XXX How can we be sure that rt won't be freeed by any other kernel thread now ?? XXX */ > Why is rt_refnt decreased so early and not later ? In the non-SMP kernel, the kernel can't be preempted so another thread can't run. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 8 14:26:26 2003 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 949F637B401 for ; Wed, 8 Jan 2003 14:26:25 -0800 (PST) Received: from mel-rto4.wanadoo.fr (smtp-out-4.wanadoo.fr [193.252.19.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8F8943EA9 for ; Wed, 8 Jan 2003 14:26:24 -0800 (PST) (envelope-from vjardin@wanadoo.fr) Received: from mel-rta8.wanadoo.fr (193.252.19.79) by mel-rto4.wanadoo.fr (6.7.015) id 3E0C33FD006905BB; Wed, 8 Jan 2003 23:26:18 +0100 Received: from there (217.128.206.18) by mel-rta8.wanadoo.fr (6.7.015) id 3E075B32006E7C25; Wed, 8 Jan 2003 23:26:18 +0100 Message-ID: <3E075B32006E7C25@mel-rta8.wanadoo.fr> (added by postmaster@wanadoo.fr) Content-Type: text/plain; charset="iso-8859-1" From: Vincent Jardin To: Garrett Wollman Subject: Re: rt_refcnt and rtentry protection ?? Date: Wed, 8 Jan 2003 23:45:32 +0100 X-Mailer: KMail [version 1.3.2] Cc: net@FreeBSD.ORG References: <0H8E00ASUXB1HW@mta5.snfc21.pbi.net> <3E075B1B006D4334@mel-rta7.wanadoo.fr> <200301082206.h08M6eHm008984@khavrinen.lcs.mit.edu> In-Reply-To: <200301082206.h08M6eHm008984@khavrinen.lcs.mit.edu> 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 > > So long as the route is marked RTF_UP, it cannot be deleted. In a > single-threaded kernel, it is not possible for this code to be > preempted, so there is no means by which the route flags could be > changed. (RTF_UP is unset when and only when the route is deleted > from the radix tree.) I agree. However, how would it work on a multi-threaded FreeBSD 5 kernel ? Regards, Vincent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 9 6: 7:10 2003 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 4107837B401 for ; Thu, 9 Jan 2003 06:07:09 -0800 (PST) Received: from ares.cs.Virginia.EDU (ares.cs.Virginia.EDU [128.143.137.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D9EA43F18 for ; Thu, 9 Jan 2003 06:07:08 -0800 (PST) (envelope-from nicolas@cs.Virginia.EDU) Received: from arachnion.cs.Virginia.EDU (arachnion.cs.Virginia.EDU [128.143.136.20]) by ares.cs.Virginia.EDU (8.9.3+Sun/8.9.2/UVACS-2000040300) with ESMTP id JAA21580 for ; Thu, 9 Jan 2003 09:07:07 -0500 (EST) Received: from localhost (nc2y@localhost) by arachnion.cs.Virginia.EDU (8.9.2/8.9.2) with ESMTP id JAA09150 for ; Thu, 9 Jan 2003 09:07:06 -0500 (EST) X-Authentication-Warning: arachnion.cs.Virginia.EDU: nc2y owned process doing -bs Date: Thu, 9 Jan 2003 09:07:06 -0500 (EST) From: Nicolas Christin X-X-Sender: nc2y@arachnion.cs.Virginia.EDU To: net@FreeBSD.ORG Subject: pf(4) port? Message-ID: Organization: University of Virginia - CS Dept. 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 would like to know if anyone knows of a port (or a porting project in progress) of OpenBSD's pf(4) to FreeBSD. I couldn't find anything... (I know some guy started porting it to NetBSD, but haven't seen anything FreeBSD-related.) Best regards, -- Nicolas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 9 10:21:54 2003 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 ECD9237B401 for ; Thu, 9 Jan 2003 10:21:52 -0800 (PST) Received: from mail.econolodgetulsa.com (mail.econolodgetulsa.com [198.78.66.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C03E43ED8 for ; Thu, 9 Jan 2003 10:21:52 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Received: from mail (user@mail [198.78.66.163]) by mail.econolodgetulsa.com (8.12.3/8.12.3) with ESMTP id h09ILqZb082075 for ; Thu, 9 Jan 2003 10:21:52 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Date: Thu, 9 Jan 2003 10:21:52 -0800 (PST) From: Josh Brooks To: freebsd-net@freebsd.org Subject: What is my next step as a script kiddie ? (DDoS) Message-ID: <20030109101652.E78856-100000@mail.econolodgetulsa.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, With the help of people in this group I have largely solved my problems - by simply placing in rules to drop all packets except the ones going to ports/services that are actually in use on the destination, I have found that even during a large attack (the kinds that used to cripple me) I have no problems at all - a lot of packets simply get dropped and that's that. But, I am concerned ... I am concerned that the attacks will simply change/escalate to something else. If I were a script kiddie, and I suddenly saw that all of my garbage packets to nonexistent ports were suddenly being dropped, and say I nmap'd the thing and saw that those ports were closed - what would my next step be ? Prior to this the attacks were very simply a big SYN flood to random ports on the victim, and because of the RSTs etc., all this traffic to nonexistent ports flooded the firewall off. So what do they do next ? What is the next step ? The next level of sophistication to get around the measures I have put into place (that have been very successful - I have an attack ongoing as I write this, and it isn't hurting me at all) ------- I am hoping that the answer is "same attack, but bigger - more bandwidth, in an attempt to saturate your pipe" because the victims ae low profile enough that it is unlikely enough people could pool enough resources to make this happen. But then again, maybe there is something sophisticated that a small attacker could do - and that is what I am trying to figure out and prevent before it happens. thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 9 13:51:17 2003 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 2D83037B401; Thu, 9 Jan 2003 13:51:16 -0800 (PST) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id DAF7D43ED8; Thu, 9 Jan 2003 13:51:14 -0800 (PST) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 9 Jan 2003 21:51:13 +0000 (GMT) To: freebsd-net@freebsd.org Cc: ume@freebsd.org Subject: ip6fw suggestion X-Request-Do: Date: Thu, 09 Jan 2003 21:51:13 +0000 From: David Malone Message-ID: <200301092151.aa25831@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I just got caught by a subtle problem with ip6fw. You can legally say: allow icmp from any to any and ip6fw doesn't complain, but this allows IPv4 ICMP in IPv6 packets, which is pretty meaningless. This seems to be because ip6fw uses getprotobyname to convert names into numbers. Of course, what I intended to say was: allow ipv6-icmp from any to any I think it might be worth adding a warning to ip6fw if someone gives the protocol as "icmp". If someone really wants to let ICMPv4 through ip6fw, they could always give the numerical version of the protocol instead. The patch below would make giving icmp an error, but it might just be better to syslog something? David. Index: ip6fw.c =================================================================== RCS file: /FreeBSD/FreeBSD-CVS/src/sbin/ip6fw/ip6fw.c,v retrieving revision 1.1.2.8 diff -u -r1.1.2.8 ip6fw.c --- ip6fw.c 28 Aug 2002 05:32:03 -0000 1.1.2.8 +++ ip6fw.c 9 Jan 2003 21:49:54 -0000 @@ -959,6 +959,8 @@ rule.fw_prot = proto; av++; ac--; } else if (!strncmp(*av,"all",strlen(*av))) { rule.fw_prot = IPPROTO_IPV6; av++; ac--; + } else if (!strncmp(*av,"icmp",strlen(*av))) { + show_usage("allowing ipv4 icmp does not make sense."); } else if ((pe = getprotobyname(*av)) != NULL) { rule.fw_prot = pe->p_proto; av++; ac--; } else { To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 9 15:31:35 2003 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 4145437B401 for ; Thu, 9 Jan 2003 15:31:34 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0F3043F18 for ; Thu, 9 Jan 2003 15:31:32 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 7882 invoked from network); 9 Jan 2003 23:38:09 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 9 Jan 2003 23:38:09 -0000 Received: (nullmailer pid 853 invoked by uid 136); Thu, 09 Jan 2003 23:25:53 -0000 Subject: Re: What is my next step as a script kiddie ? (DDoS) X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20030109101652.E78856-100000@mail.econolodgetulsa.com> To: Josh Brooks Date: Fri, 10 Jan 2003 02:25:53 +0300 (MSK) From: "."@babolo.ru Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1042154753.510477.852.nullmailer@cicuta.babolo.ru> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > With the help of people in this group I have largely solved my problems - > by simply placing in rules to drop all packets except the ones going to > ports/services that are actually in use on the destination, I have found > that even during a large attack (the kinds that used to cripple me) I have > no problems at all - a lot of packets simply get dropped and that's that. > > But, I am concerned ... I am concerned that the attacks will simply > change/escalate to something else. > > If I were a script kiddie, and I suddenly saw that all of my garbage > packets to nonexistent ports were suddenly being dropped, and say I nmap'd > the thing and saw that those ports were closed - what would my next step > be ? Prior to this the attacks were very simply a big SYN flood to random > ports on the victim, and because of the RSTs etc., all this traffic to > nonexistent ports flooded the firewall off. > > So what do they do next ? What is the next step ? The next level of > sophistication to get around the measures I have put into place (that have > been very successful - I have an attack ongoing as I write this, and it > isn't hurting me at all) > > ------- > > I am hoping that the answer is "same attack, but bigger - more bandwidth, > in an attempt to saturate your pipe" because the victims ae low profile > enough that it is unlikely enough people could pool enough resources to > make this happen. But then again, maybe there is something sophisticated > that a small attacker could do - and that is what I am trying to figure > out and prevent before it happens. What is your goal? To protect your router or to protect your client? This is a big difference. And may be police is best way for both in long term. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 9 18: 4:37 2003 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 F062937B405 for ; Thu, 9 Jan 2003 18:04:33 -0800 (PST) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9B0843EB2 for ; Thu, 9 Jan 2003 18:04:32 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id TAA19385 for ; Thu, 9 Jan 2003 19:04:20 -0700 (MST) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030109182517.02963410@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Jan 2003 19:04:18 -0700 To: freebsd-net@freebsd.org From: Brett Glass Subject: PPTP tunneling over PPPoE link 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 having trouble doing something which I'd THOUGHT would just work... but it's not. Any help would be much appreciated. Here's the story. A client's LAN is connected to the Internet via a FreeBSD firewall/router. The FreeBSD box is using PPPoE (userland PPP plus NetGraph PPPOE) to connect to the upstream router. The LAN inside the firewall is NATted to 192.168/16. It works perfectly; it even correctly passes SMTP connections on to an internal machine with the address 192.168.0.2 (see the configuration file below). The client calls and says that expects to be away for awhile, and wants to tunnel back into the LAN with his Windows laptop. Since userland PPP is already running on the machine and works fine, I set up PPTP on his server, using PopTop (yes, it's GPLed, but there's no actively maintained alternative) and userland PPP. The result, in theory, will be a tunnel that uses PPTP (which is encrypted PPP over GRE) over PPP over Ethernet. A bit awkward, but necessary given the need for an encrypted tunnel. Alas, try as I might, I can't tunnel in from the outside world. I can verify that TCP port 1723 (which is used by PPTP for a control channel) is open on the firewall and accepting connections. But attempts to establish a tunnel fail; the client reports that the server isn't responding to it. The log looks like this: Jan 9 09:55:00 www ppp[3119]: Phase: Using interface: tun1 Jan 9 09:55:00 www ppp[3119]: Phase: deflink: Created in closed state Jan 9 09:55:00 www ppp[3119]: tun1: Command: default: ident user-ppp VERSION (built COMPILATIONDATE) Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set timeout 0 Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set dial Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set login Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set ifaddr 192.168.0.1/32 Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set server /var/run/pptp_ppp_%d ******** 0700 Jan 9 09:55:00 www ppp[3119]: tun1: Phase: Listening at local socket /var/run/pptp_ppp_1. Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable chap Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: deny chap Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable pap Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable passwdauth Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable deflate pred1 Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: deny deflate pred1 Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable utmp Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: enable mschapv2 mppe Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set mppe * stateless Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable proxy Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: accept dns Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set dns 192.168.0.1 Jan 9 09:55:00 www ppp[3119]: tun1: Phase: PPP Started (direct mode). Jan 9 09:55:00 www ppp[3119]: tun1: Phase: bundle: Establish Jan 9 09:55:00 www ppp[3119]: tun1: Phase: deflink: closed -> opening Jan 9 09:55:00 www ppp[3119]: tun1: Phase: deflink: Connected! Jan 9 09:55:00 www ppp[3119]: tun1: Phase: deflink: opening -> carrier Jan 9 09:55:00 www ppp[3119]: tun1: Phase: deflink: carrier -> lcp Jan 9 09:55:00 www ppp[3119]: tun1: LCP: FSM: Using "deflink" as a transport Jan 9 09:55:00 www ppp[3119]: tun1: LCP: deflink: State change Initial --> Closed Jan 9 09:55:00 www ppp[3119]: tun1: LCP: deflink: State change Closed --> Stopped Jan 9 09:55:01 www ppp[3119]: tun1: LCP: deflink: LayerStart Jan 9 09:55:01 www ppp[3119]: tun1: LCP: deflink: SendConfigReq(1) state = Stopped Jan 9 09:55:01 www ppp[3119]: tun1: LCP: ACFCOMP[2] Jan 9 09:55:01 www ppp[3119]: tun1: LCP: PROTOCOMP[2] Jan 9 09:55:01 www ppp[3119]: tun1: LCP: ACCMAP[6] 0x00000000 Jan 9 09:55:01 www ppp[3119]: tun1: LCP: MRU[4] 1500 Jan 9 09:55:01 www ppp[3119]: tun1: LCP: MAGICNUM[6] 0x02b7e69a Jan 9 09:55:01 www ppp[3119]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x81) Jan 9 09:55:01 www ppp[3119]: tun1: LCP: deflink: State change Stopped --> Req-Sent Jan 9 09:55:04 www ppp[3119]: tun1: LCP: deflink: SendConfigReq(1) state = Req-Sent Jan 9 09:55:04 www ppp[3119]: tun1: LCP: ACFCOMP[2] Jan 9 09:55:04 www ppp[3119]: tun1: LCP: PROTOCOMP[2] Jan 9 09:55:04 www ppp[3119]: tun1: LCP: ACCMAP[6] 0x00000000 Jan 9 09:55:04 www ppp[3119]: tun1: LCP: MRU[4] 1500 Jan 9 09:55:04 www ppp[3119]: tun1: LCP: MAGICNUM[6] 0x02b7e69a Jan 9 09:55:04 www ppp[3119]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x81) Jan 9 09:55:07 www ppp[3119]: tun1: LCP: deflink: SendConfigReq(1) state = Req-Sent Jan 9 09:55:07 www ppp[3119]: tun1: LCP: ACFCOMP[2] Jan 9 09:55:07 www ppp[3119]: tun1: LCP: PROTOCOMP[2] Jan 9 09:55:07 www ppp[3119]: tun1: LCP: ACCMAP[6] 0x00000000 Jan 9 09:55:07 www ppp[3119]: tun1: LCP: MRU[4] 1500 Jan 9 09:55:07 www ppp[3119]: tun1: LCP: MAGICNUM[6] 0x02b7e69a Jan 9 09:55:07 www ppp[3119]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x81) Jan 9 09:55:10 www ppp[3119]: tun1: LCP: deflink: SendConfigReq(1) state = Req-Sent Jan 9 09:55:10 www ppp[3119]: tun1: LCP: ACFCOMP[2] Jan 9 09:55:10 www ppp[3119]: tun1: LCP: PROTOCOMP[2] Jan 9 09:55:10 www ppp[3119]: tun1: LCP: ACCMAP[6] 0x00000000 Jan 9 09:55:10 www ppp[3119]: tun1: LCP: MRU[4] 1500 Jan 9 09:55:10 www ppp[3119]: tun1: LCP: MAGICNUM[6] 0x02b7e69a Jan 9 09:55:10 www ppp[3119]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x81) Jan 9 09:55:13 www ppp[3119]: tun1: LCP: deflink: SendConfigReq(1) state = Req-Sent Jan 9 09:55:13 www ppp[3119]: tun1: LCP: ACFCOMP[2] Jan 9 09:55:13 www ppp[3119]: tun1: LCP: PROTOCOMP[2] Jan 9 09:55:13 www ppp[3119]: tun1: LCP: ACCMAP[6] 0x00000000 Jan 9 09:55:13 www ppp[3119]: tun1: LCP: MRU[4] 1500 Jan 9 09:55:13 www ppp[3119]: tun1: LCP: MAGICNUM[6] 0x02b7e69a Jan 9 09:55:13 www ppp[3119]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x81) Jan 9 09:55:16 www ppp[3119]: tun1: LCP: deflink: LayerFinish Jan 9 09:55:16 www ppp[3119]: tun1: LCP: deflink: State change Req-Sent --> Stopped Jan 9 09:55:16 www ppp[3119]: tun1: LCP: deflink: State change Stopped --> Closed Jan 9 09:55:16 www ppp[3119]: tun1: LCP: deflink: State change Closed --> Initial Jan 9 09:55:16 www ppp[3119]: tun1: Phase: deflink: Disconnected! Jan 9 09:55:16 www ppp[3119]: tun1: Phase: deflink: Connect time: 16 secs: 0 octets in, 300 octets out Jan 9 09:55:16 www ppp[3119]: tun1: Phase: deflink: : 0 packets in, 5 packets out Jan 9 09:55:16 www ppp[3119]: tun1: Phase: total 18 bytes/sec, peak 24 bytes/sec on Thu Jan 9 09:55:16 2003 Jan 9 09:55:16 www ppp[3119]: tun1: Phase: deflink: lcp -> closed Jan 9 09:55:16 www ppp[3119]: tun1: Phase: bundle: Dead Jan 9 09:55:16 www ppp[3119]: tun1: Phase: PPP Terminated (normal). What's wrong? It looks (though I'm not positive) as if the GRE packets, which carry the underlying PPP session, can't get through the PPPoE link. I've checked the documentation for userland PPP, and there's nothing to indicate that they wouldn't (or how to allow them to pass if they're blocked by default). The /etc/ppp.conf file looks like this, with passwords erased to protect the guilty. Note that the top portion is for the PPPoE connection and the bottom portion is for PPTP: default: set log Phase Chat LCP IPCP CCP tun command ident user-ppp VERSION (built COMPILATIONDATE) lariat: set device PPPoE:fxp1:provider set mru 1492 set mtu 1492 set speed sync set authname USERID set authkey PASSWORD set timeout 0 set cd 5 enable lqr set lqrperiod 15 disable chap disable pap disable mppe deny mppe nat enable yes nat unregistered_only yes nat same_ports yes nat port tcp 192.168.0.2:smtp smtp set dial set login set redial 0 0 pptp: set timeout 0 set dial set login set ifaddr 192.168.0.1/32 set server /var/run/pptp_ppp_%d "" 0700 disable chap deny chap disable pap disable passwdauth disable deflate pred1 deny deflate pred1 disable utmp enable mschapv2 mppe set mppe * stateless disable proxy accept dns set dns 192.168.0.1 --Brett Glass To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 9 18:10:19 2003 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 808DB37B401 for ; Thu, 9 Jan 2003 18:10:15 -0800 (PST) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0445343EB2 for ; Thu, 9 Jan 2003 18:10:15 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc51.attbi.com (rwcrmhc51) with ESMTP id <20030110021014051001se2oe>; Fri, 10 Jan 2003 02:10:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA37284; Thu, 9 Jan 2003 18:10:13 -0800 (PST) Date: Thu, 9 Jan 2003 18:10:09 -0800 (PST) From: Julian Elischer To: Brett Glass Cc: freebsd-net@freebsd.org Subject: Re: PPTP tunneling over PPPoE link In-Reply-To: <4.3.2.7.2.20030109182517.02963410@localhost> 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 mpd can do both pppoe and pptp. On Thu, 9 Jan 2003, Brett Glass wrote: > I'm having trouble doing something which I'd THOUGHT would just work... but it's not. Any help would be much appreciated. > > Here's the story. A client's LAN is connected to the Internet via a FreeBSD firewall/router. The FreeBSD box is using PPPoE (userland PPP plus NetGraph PPPOE) to connect to the upstream router. The LAN inside the firewall is NATted to 192.168/16. It works perfectly; it even correctly passes SMTP connections on to an internal machine with the address 192.168.0.2 (see the configuration file below). > > The client calls and says that expects to be away for awhile, and wants to tunnel back into the LAN with his Windows laptop. Since userland PPP is already running on the machine and works fine, I set up PPTP on his server, using PopTop (yes, it's GPLed, but there's no actively maintained alternative) and userland PPP. The result, in theory, will be a tunnel that uses PPTP (which is encrypted PPP over GRE) over PPP over Ethernet. A bit awkward, but necessary given the need for an encrypted tunnel. > > Alas, try as I might, I can't tunnel in from the outside world. I can verify that TCP port 1723 (which is used by PPTP for a control channel) is open on the firewall and accepting connections. But attempts to establish a tunnel fail; the client reports that the server isn't responding to it. The log looks like this: > > Jan 9 09:55:00 www ppp[3119]: Phase: Using interface: tun1 > Jan 9 09:55:00 www ppp[3119]: Phase: deflink: Created in closed state > Jan 9 09:55:00 www ppp[3119]: tun1: Command: default: ident user-ppp VERSION (built COMPILATIONDATE) > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set timeout 0 > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set dial > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set login > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set ifaddr 192.168.0.1/32 > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set server /var/run/pptp_ppp_%d ******** 0700 > Jan 9 09:55:00 www ppp[3119]: tun1: Phase: Listening at local socket /var/run/pptp_ppp_1. > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable chap > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: deny chap > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable pap > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable passwdauth > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable deflate pred1 > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: deny deflate pred1 > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable utmp > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: enable mschapv2 mppe > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set mppe * stateless > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable proxy > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: accept dns > Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set dns 192.168.0.1 > Jan 9 09:55:00 www ppp[3119]: tun1: Phase: PPP Started (direct mode). > Jan 9 09:55:00 www ppp[3119]: tun1: Phase: bundle: Establish > Jan 9 09:55:00 www ppp[3119]: tun1: Phase: deflink: closed -> opening > Jan 9 09:55:00 www ppp[3119]: tun1: Phase: deflink: Connected! > Jan 9 09:55:00 www ppp[3119]: tun1: Phase: deflink: opening -> carrier > Jan 9 09:55:00 www ppp[3119]: tun1: Phase: deflink: carrier -> lcp > Jan 9 09:55:00 www ppp[3119]: tun1: LCP: FSM: Using "deflink" as a transport > Jan 9 09:55:00 www ppp[3119]: tun1: LCP: deflink: State change Initial --> Closed > Jan 9 09:55:00 www ppp[3119]: tun1: LCP: deflink: State change Closed --> Stopped > Jan 9 09:55:01 www ppp[3119]: tun1: LCP: deflink: LayerStart > Jan 9 09:55:01 www ppp[3119]: tun1: LCP: deflink: SendConfigReq(1) state = Stopped > Jan 9 09:55:01 www ppp[3119]: tun1: LCP: ACFCOMP[2] > Jan 9 09:55:01 www ppp[3119]: tun1: LCP: PROTOCOMP[2] > Jan 9 09:55:01 www ppp[3119]: tun1: LCP: ACCMAP[6] 0x00000000 > Jan 9 09:55:01 www ppp[3119]: tun1: LCP: MRU[4] 1500 > Jan 9 09:55:01 www ppp[3119]: tun1: LCP: MAGICNUM[6] 0x02b7e69a > Jan 9 09:55:01 www ppp[3119]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x81) > Jan 9 09:55:01 www ppp[3119]: tun1: LCP: deflink: State change Stopped --> Req-Sent > Jan 9 09:55:04 www ppp[3119]: tun1: LCP: deflink: SendConfigReq(1) state = Req-Sent > Jan 9 09:55:04 www ppp[3119]: tun1: LCP: ACFCOMP[2] > Jan 9 09:55:04 www ppp[3119]: tun1: LCP: PROTOCOMP[2] > Jan 9 09:55:04 www ppp[3119]: tun1: LCP: ACCMAP[6] 0x00000000 > Jan 9 09:55:04 www ppp[3119]: tun1: LCP: MRU[4] 1500 > Jan 9 09:55:04 www ppp[3119]: tun1: LCP: MAGICNUM[6] 0x02b7e69a > Jan 9 09:55:04 www ppp[3119]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x81) > Jan 9 09:55:07 www ppp[3119]: tun1: LCP: deflink: SendConfigReq(1) state = Req-Sent > Jan 9 09:55:07 www ppp[3119]: tun1: LCP: ACFCOMP[2] > Jan 9 09:55:07 www ppp[3119]: tun1: LCP: PROTOCOMP[2] > Jan 9 09:55:07 www ppp[3119]: tun1: LCP: ACCMAP[6] 0x00000000 > Jan 9 09:55:07 www ppp[3119]: tun1: LCP: MRU[4] 1500 > Jan 9 09:55:07 www ppp[3119]: tun1: LCP: MAGICNUM[6] 0x02b7e69a > Jan 9 09:55:07 www ppp[3119]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x81) > Jan 9 09:55:10 www ppp[3119]: tun1: LCP: deflink: SendConfigReq(1) state = Req-Sent > Jan 9 09:55:10 www ppp[3119]: tun1: LCP: ACFCOMP[2] > Jan 9 09:55:10 www ppp[3119]: tun1: LCP: PROTOCOMP[2] > Jan 9 09:55:10 www ppp[3119]: tun1: LCP: ACCMAP[6] 0x00000000 > Jan 9 09:55:10 www ppp[3119]: tun1: LCP: MRU[4] 1500 > Jan 9 09:55:10 www ppp[3119]: tun1: LCP: MAGICNUM[6] 0x02b7e69a > Jan 9 09:55:10 www ppp[3119]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x81) > Jan 9 09:55:13 www ppp[3119]: tun1: LCP: deflink: SendConfigReq(1) state = Req-Sent > Jan 9 09:55:13 www ppp[3119]: tun1: LCP: ACFCOMP[2] > Jan 9 09:55:13 www ppp[3119]: tun1: LCP: PROTOCOMP[2] > Jan 9 09:55:13 www ppp[3119]: tun1: LCP: ACCMAP[6] 0x00000000 > Jan 9 09:55:13 www ppp[3119]: tun1: LCP: MRU[4] 1500 > Jan 9 09:55:13 www ppp[3119]: tun1: LCP: MAGICNUM[6] 0x02b7e69a > Jan 9 09:55:13 www ppp[3119]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x81) > Jan 9 09:55:16 www ppp[3119]: tun1: LCP: deflink: LayerFinish > Jan 9 09:55:16 www ppp[3119]: tun1: LCP: deflink: State change Req-Sent --> Stopped > Jan 9 09:55:16 www ppp[3119]: tun1: LCP: deflink: State change Stopped --> Closed > Jan 9 09:55:16 www ppp[3119]: tun1: LCP: deflink: State change Closed --> Initial > Jan 9 09:55:16 www ppp[3119]: tun1: Phase: deflink: Disconnected! > Jan 9 09:55:16 www ppp[3119]: tun1: Phase: deflink: Connect time: 16 secs: 0 octets in, 300 octets out > Jan 9 09:55:16 www ppp[3119]: tun1: Phase: deflink: : 0 packets in, 5 packets out > Jan 9 09:55:16 www ppp[3119]: tun1: Phase: total 18 bytes/sec, peak 24 bytes/sec on Thu Jan 9 09:55:16 2003 > Jan 9 09:55:16 www ppp[3119]: tun1: Phase: deflink: lcp -> closed > Jan 9 09:55:16 www ppp[3119]: tun1: Phase: bundle: Dead > Jan 9 09:55:16 www ppp[3119]: tun1: Phase: PPP Terminated (normal). > > What's wrong? It looks (though I'm not positive) as if the GRE packets, which carry the underlying PPP session, can't get through the PPPoE link. I've checked the documentation for userland PPP, and there's nothing to indicate that they wouldn't (or how to allow them to pass if they're blocked by default). > > The /etc/ppp.conf file looks like this, with passwords erased to protect the guilty. Note that the top portion is for the PPPoE connection and the bottom portion is for PPTP: > > default: > set log Phase Chat LCP IPCP CCP tun command > ident user-ppp VERSION (built COMPILATIONDATE) > > lariat: > set device PPPoE:fxp1:provider > set mru 1492 > set mtu 1492 > set speed sync > set authname USERID > set authkey PASSWORD > set timeout 0 > set cd 5 > enable lqr > set lqrperiod 15 > disable chap > disable pap > disable mppe > deny mppe > nat enable yes > nat unregistered_only yes > nat same_ports yes > nat port tcp 192.168.0.2:smtp smtp > set dial > set login > set redial 0 0 > > pptp: > set timeout 0 > set dial > set login > set ifaddr 192.168.0.1/32 > set server /var/run/pptp_ppp_%d "" 0700 > disable chap > deny chap > disable pap > disable passwdauth > disable deflate pred1 > deny deflate pred1 > disable utmp > enable mschapv2 mppe > set mppe * stateless > disable proxy > accept dns > set dns 192.168.0.1 > > --Brett Glass > > > 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 Jan 9 18:18:22 2003 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 A831937B401 for ; Thu, 9 Jan 2003 18:18:21 -0800 (PST) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E02F743F1E for ; Thu, 9 Jan 2003 18:18:20 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id TAA19544; Thu, 9 Jan 2003 19:18:13 -0700 (MST) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030109191546.02975920@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Jan 2003 19:18:11 -0700 To: Julian Elischer From: Brett Glass Subject: Re: PPTP tunneling over PPPoE link Cc: freebsd-net@freebsd.org In-Reply-To: References: <4.3.2.7.2.20030109182517.02963410@localhost> 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 At 07:10 PM 1/9/2003, Julian Elischer wrote: >mpd can do both pppoe and pptp. I've tried mpd, and its PPTP seems to be incompatible with XP and with some Macs. (It doesn't die completely, but runs at a crawl.) If it worked (and if the scripting language were more robust) I'd switch to it in a second! --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 1:18:17 2003 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 98E7D37B401 for ; Fri, 10 Jan 2003 01:18:15 -0800 (PST) Received: from mail.econolodgetulsa.com (mail.econolodgetulsa.com [198.78.66.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F3AA43F18 for ; Fri, 10 Jan 2003 01:18:15 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Received: from mail (user@mail [198.78.66.163]) by mail.econolodgetulsa.com (8.12.3/8.12.3) with ESMTP id h0A9I7Zb068590; Fri, 10 Jan 2003 01:18:08 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Date: Fri, 10 Jan 2003 01:18:07 -0800 (PST) From: Josh Brooks To: "."@babolo.ru Cc: freebsd-net@freebsd.org Subject: Re: What is my next step as a script kiddie ? (DDoS) In-Reply-To: <1042154753.510477.852.nullmailer@cicuta.babolo.ru> Message-ID: <20030110011642.O78856-100000@mail.econolodgetulsa.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 My goal is to protect my FreeBSD firewall. As I mentioned, now that I have closed off everything to the victim except the ports he is actually running services on, everything is great! The firewall is just fine - even during a big syn flood, because it just drops all the packets that aren't going to legitimate ports. So my question is, what will they do next ? When they nmap the victim and they see all the ports are closed, what will they move to then ? On Fri, 10 Jan 2003 .@babolo.ru wrote: > > With the help of people in this group I have largely solved my problems - > > by simply placing in rules to drop all packets except the ones going to > > ports/services that are actually in use on the destination, I have found > > that even during a large attack (the kinds that used to cripple me) I have > > no problems at all - a lot of packets simply get dropped and that's that. > > > > But, I am concerned ... I am concerned that the attacks will simply > > change/escalate to something else. > > > > If I were a script kiddie, and I suddenly saw that all of my garbage > > packets to nonexistent ports were suddenly being dropped, and say I nmap'd > > the thing and saw that those ports were closed - what would my next step > > be ? Prior to this the attacks were very simply a big SYN flood to random > > ports on the victim, and because of the RSTs etc., all this traffic to > > nonexistent ports flooded the firewall off. > > > > So what do they do next ? What is the next step ? The next level of > > sophistication to get around the measures I have put into place (that have > > been very successful - I have an attack ongoing as I write this, and it > > isn't hurting me at all) > > > > ------- > > > > I am hoping that the answer is "same attack, but bigger - more bandwidth, > > in an attempt to saturate your pipe" because the victims ae low profile > > enough that it is unlikely enough people could pool enough resources to > > make this happen. But then again, maybe there is something sophisticated > > that a small attacker could do - and that is what I am trying to figure > > out and prevent before it happens. > What is your goal? > To protect your router or to protect your client? > This is a big difference. > And may be police is best way for both > in long term. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 3:29:37 2003 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 E8F5237B401 for ; Fri, 10 Jan 2003 03:29:33 -0800 (PST) Received: from epita.fr (hermes.epita.fr [163.5.255.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80BD543F13 for ; Fri, 10 Jan 2003 03:29:32 -0800 (PST) (envelope-from le-hen_j@epita.fr) Received: from carpediem (carpediem [10.42.42.5]) by epita.fr id h0ABTTM14788 for freebsd-net@freebsd.org EPITA Paris France Fri, 10 Jan 2003 12:29:29 +0100 (MET) Date: Fri, 10 Jan 2003 12:29:29 +0100 From: jeremie le-hen To: freebsd-net@freebsd.org Subject: ipnat and ipf interaction precisions Message-ID: <20030110112929.GB1130@carpediem.epita.fr> 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 Hi, I'm trying to block a single IP address which belongs to my private nated network. Here is my ipnat.rules: --- map tun0 192.168.0.0/24 -> 0/32 proxy port ftp ftp/tcp map tun0 192.168.0.0/24 -> 0/32 --- and a summary of my ipf.rules: --- # Allow loopback traffic pass in quick on lo0 all pass out quick on lo0 all # Allow LAN traffic pass in quick on ep0 all pass out quick on ep0 all pass in quick on ep2 all pass out quick on ep2 all # Default to allow outcoming packets keeping state pass out quick proto tcp/udp all keep state pass out quick proto icmp all keep state # Allow ping requests pass in log first quick on proto icmp all icmp-type echo # Block everything else block in log first quick proto tcp all block in log first quick proto udp all block in log first quick proto icmp all --- As you can see, my private network is 192.168.0.0/24, and I would like to block all traffic to Internet from host 192.168.0.3. As far as I know, ipf and ipnat interact this way: interface -> ipnat -> ipf -> os -> ipf -> ipnat -> interface Any outgoing packets from the internal network to the Internet will see their source address modified by ipnat just before passing through the public interface. Conversely, incoming packets from Internet will see their destination address changed when they just passed through the public interface. So I tried to add this kind of rule in the beginning of the ruleset, but it does not seems to work (note that ep0 is the interface connected to my internal network): --- # Block all Internet traffic from host 192.168.0.3 block in quick on ep0 from 192.168.0.3/32 to ! 192.168.0.0/24 --- Theoretically, since ipnat will modify the source address of the IP packet once it reached the public interface, the packets should be blocked. And they are. Then I tried to block all traffic from host 192.168.0.3 to Internet by replacing the previous rule with this one: --- # Block all Internet traffic from host 192.168.0.3 block out quick on tun0 from 192.168.0.3/32 to any --- With this rule, the traffic is also blocked, but there is one major difference. Indeed my FreeBSD box running ipnat/ipf sends an ICMP host unreachable for each packet. I think that the OS IPv4 stack cannot route the packet to my public interface since ipfilter forbids the stack it to send the packet, and so the stacks notifies host 192.168.0.3 that it cannot contact the remote host, using an ICMP host unreachable. Am I right ? My second question concerns RDR mecanism. I have added the following line in my ipnat.rules: --- rdr tun0 0.0.0.0/0 port 2202 -> 192.168.0.2 port ssh --- And then I wished to block these packets with ipf (that's quite useless, but it's for my curiosity). Since this kind of redirection involve modifying destination address of the incoming packets when they just have been received by the public interface, ipf rules should take care of this. First, I tried the following rules, which seems to work perfectly (tun0 is my public interface): --- block in quick on tun0 from any to 192.168.0.2/32 --- TCP SYN packets to port 2202 are never sent to host 192.168.0.2. Then I tried to set up an equivalent rule on my internal interface ep0: --- block out quick on ep0 from ! 192.168.0.0/24 to 192.168.0.2/32 --- With this rule, the TCP SYN packets are not forwarded to host 192.168.0.2, but this time, my FreeBSD box sends back an RST packet to the remote host. I think this behaviour can be explained with the same reason as above, ipfilter simply prevents the OS IPv4 stack to forward the packet through ep0. Therefore, the OS notifies the remote host that the connection is impossible, following TCP RFC recommandations. Am I right there ? I'm pretty sure that these ICMP host unreachable and TCP RST packets are generated by the operating system itself, not by ipfilter. Thanks in advance for all replies that my confirm or refute my explanation. Finally, excuse me for my poor english, I'm working hard to improve it. Regards, -- Jeremie aka T{ata,t}Z le-hen_j@epita.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 4:25:26 2003 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 5C78E37B401 for ; Fri, 10 Jan 2003 04:25:25 -0800 (PST) Received: from beluga.cc.metu.edu.tr (beluga.cc.metu.edu.tr [144.122.156.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59A7443ED8 for ; Fri, 10 Jan 2003 04:25:21 -0800 (PST) (envelope-from eryol@metu.edu.tr) Received: (from eryol@localhost) by beluga.cc.metu.edu.tr (8.11.6/8.11.6) id h0ACOmL283760; Fri, 10 Jan 2003 14:24:48 +0200 Date: Fri, 10 Jan 2003 14:24:47 +0200 (WET) From: gokhan eryol To: Helge Oldach Cc: Subject: Re: freebsd 4.7-stable kernel gre tunnel support for squid's wccp cisco interaction In-Reply-To: <200212111747.gBBHlxYY051592@sep.oldach.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 On Wed, 11 Dec 2002, Helge Oldach wrote: > Gokhan Eryol: > > I upgraded /usr/src from 4.7-RELEASE to 4.7-STABLE by cvs and trying > > to compile it for transparent web-caching with squid (wccp support). I > > tried the steps described in > > http://www.squid-cache.org/Doc/FAQ/FAQ-17.html as i did before. > > I believe this should be mostly obsolete. GRE has been incorporated into > STABLE on 1st December, so you shouldn't need to patch anything any > more. Probably you will just have to configure a gre interface and make > squid talk to that. I tried some combinations, but unable to success the WCCP communication on GRE tunnel. However, Henrik, from squid-cache.org, warn me about there may not be WCCP support to an existing GRE module. Any suggestion will be appreciated. Regards, Gokhan ERYOL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 8: 7:25 2003 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 B059137B401 for ; Fri, 10 Jan 2003 08:07:23 -0800 (PST) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81CAA43EB2 for ; Fri, 10 Jan 2003 08:07:22 -0800 (PST) (envelope-from fanf@chiark.greenend.org.uk) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 18X1gg-000360-00 (Debian); Fri, 10 Jan 2003 16:07:14 +0000 Date: Fri, 10 Jan 2003 16:07:14 +0000 From: Tony Finch To: freebsd-net@freebsd.org Subject: Docco patch for review Message-ID: <20030110160714.D32571@chiark.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org There seems to be a slight lacuna in the signal documentation: --- src/lib/libc/gen/signal.3 19 Dec 2002 09:40:21 -0000 1.32 +++ src/lib/libc/gen/signal.3 10 Jan 2003 16:03:16 -0000 @@ -187,7 +187,9 @@ and during a .Xr ioctl 2 or -.Xr wait 2 . +.Xr wait 2 +or any other system call whose documentation says it may return +.Er EINTR . However, calls that have already committed are not restarted, but instead return a partial success (for example, a short read count). These semantics could be changed with --- src/lib/libc/sys/sigaction.2 27 Dec 2002 12:15:29 -0000 1.47 +++ src/lib/libc/sys/sigaction.2 10 Jan 2003 16:02:19 -0000 @@ -253,7 +253,9 @@ and during a .Xr wait 2 or -.Xr ioctl 2 . +.Xr ioctl 2 +or any other system call whose manual page says it may return +.Er EINTR . However, calls that have already committed are not restarted, but instead return a partial success (for example, a short read count). .Pp Tony. -- f.a.n.finch http://dotat.at/ DOVER WIGHT PORTLAND PLYMOUTH BISCAY: NORTH OR NORTHEAST VEERING EAST 5 OR 6, OCCASIONALLY 7. SHOWERS. MAINLY GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 11: 2: 6 2003 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 DAC5037B401 for ; Fri, 10 Jan 2003 11:02:04 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71ECF43F5F for ; Fri, 10 Jan 2003 11:02:03 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id GAA24588; Sat, 11 Jan 2003 06:01:49 +1100 Date: Sat, 11 Jan 2003 06:02:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Tony Finch Cc: freebsd-net@FreeBSD.ORG Subject: Re: Docco patch for review In-Reply-To: <20030110160714.D32571@chiark.greenend.org.uk> Message-ID: <20030111053338.K12262-100000@gamplex.bde.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, 10 Jan 2003, Tony Finch wrote: > There seems to be a slight lacuna in the signal documentation: > > --- src/lib/libc/gen/signal.3 19 Dec 2002 09:40:21 -0000 1.32 > +++ src/lib/libc/gen/signal.3 10 Jan 2003 16:03:16 -0000 > @@ -187,7 +187,9 @@ > and during a > .Xr ioctl 2 > or > -.Xr wait 2 . > +.Xr wait 2 > +or any other system call whose documentation says it may return > +.Er EINTR . This is not correct, since the relevant system calls are those that are affected by SA_RESTART, not the ones that may return EINTR. select(2) is the canonical example of a syscall that returns EINTR but is not affected by SA_RESTART. Similarly for sigaction.2. The bug is more that the effect of SA_RESTART isn't documented in the individual man pages for important syscalls like read(2). It is only documented in: fcntl.2.gz:.Dv SA_RESTART nanosleep.2.gz:.Dv SA_RESTART sigaction.2.gz:.It Dv SA_RESTART sigaction.2.gz:.Dv SA_RESTART sigaction.2.gz:.Dv SA_RESTART wait.2.gz:.Dv SA_RESTART wait3.2.gz:.Dv SA_RESTART wait4.2.gz:.Dv SA_RESTART waitpid.2.gz:.Dv SA_RESTART SA_RESTART actually applies to almost all syscalls (although it can only affect ones that return EINTR), so it would be much easier to document the ones that it doesn't affect. I could only find select(), poll(), aio_waitcoomplete(), nanosleep(), sigsuspend(), connect(), kevent() and open(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 13:36:49 2003 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 7FDB237B401 for ; Fri, 10 Jan 2003 13:36:47 -0800 (PST) Received: from mail.econolodgetulsa.com (mail.econolodgetulsa.com [198.78.66.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C57B43F13 for ; Fri, 10 Jan 2003 13:36:47 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Received: from mail (user@mail [198.78.66.163]) by mail.econolodgetulsa.com (8.12.3/8.12.3) with ESMTP id h0ALadZb049762; Fri, 10 Jan 2003 13:36:39 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Date: Fri, 10 Jan 2003 13:36:39 -0800 (PST) From: Josh Brooks To: Jess Kitchen Cc: freebsd-net@freebsd.org Subject: Re: What is my next step as a script kiddie ? (DDoS) In-Reply-To: <20030110175022.B42178-100000@platinum.burstfire.net> Message-ID: <20030110133515.Q78856-100000@mail.econolodgetulsa.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 Ok, understood - but the point is, at some point the attackers are going to realize that their syn floods are no longer hurting me ... and regardless of what they conclude from this, what is the standard "next step" ? If they are just flooders/packeteers, what do they graduate to when syn floods no longer do the job ? thanks! On Fri, 10 Jan 2003, Jess Kitchen wrote: > On Fri, 10 Jan 2003, Josh Brooks wrote: > > > My goal is to protect my FreeBSD firewall. As I mentioned, now that I > > have closed off everything to the victim except the ports he is actually > > running services on, everything is great! The firewall is just fine - > > even during a big syn flood, because it just drops all the packets that > > aren't going to legitimate ports. > > > > So my question is, what will they do next ? When they nmap the victim and > > they see all the ports are closed, what will they move to then ? > > Josh, > > If your firewall is correctly dropping packets they won't see closed ports > at all, unless you are sending tcp resets for everything (which would be > silly heh) > > Have you had a look at man blackhole yet? That usually proves to be quite > a pain when running generic-ish stuff along the lines of -sS -F or > whatever. > > Cheers, > J. > > -- > Jess Kitchen > http://www.burstfire.net/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 15: 7:25 2003 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 2A95A37B401 for ; Fri, 10 Jan 2003 15:07:24 -0800 (PST) Received: from out6.mx.nwbl.wi.voyager.net (out6.mx.nwbl.wi.voyager.net [169.207.3.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEBA243F5B for ; Fri, 10 Jan 2003 15:07:22 -0800 (PST) (envelope-from silby@silby.com) Received: from [10.1.1.6] (d9.as12.nwbl0.wi.voyager.net [169.207.135.9]) by out6.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id 312DADA74F; Fri, 10 Jan 2003 17:07:20 -0600 (CST) Date: Fri, 10 Jan 2003 17:14:46 -0600 (CST) From: Mike Silbersack To: Jeff Behl Cc: freebsd-net Subject: Re: when are mbuf clusters released? In-Reply-To: <3E14A22B.5070203@expertcity.com> Message-ID: <20030105204407.P20123-100000@patrocles.silby.com> References: <3E108C31.9060403@expertcity.com> <20021230132145.N22880-100000@patrocles.silby.com> <3E14A22B.5070203@expertcity.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 Urk, this message got stuck in my drafts folder, sorry for the delay. On Thu, 2 Jan 2003, Jeff Behl wrote: > Thanks for the info. Could you explain how mbuf clusters and mbufs are > related? i'd like to better understand how we can run out of one and > not the other. also, is there an upper value for mbuf clusters that we > should be wary of? again, the tuning page is quite vague on this. > 64000 seems to not do the trick so i was thinking of 2X this. we have > plenty of memory (1GB and the machine only runs apache). I think someone else answered this, so I'll skip doing so. As to what a good upper value is... well, 2K per cluster, how much memory you wish to dedicate to clusters is up to you. There *shouldn't* be any limit on the number besides memory usage, but remember that kernel address space is used for many other things, so don't waste it. :) > for those interested, we think we've found why we're getting lots of > connections in FIN_WAIT_1 state...it appears to be some sort of odd/bad > interaction between IE and flash (we think). these machines serve popup > adds (sorry!), and we're guessing that when a user with a slower > connection gets one of these pop-ups and kills the window before the > flash file is done downloading, IE leaves the socket open...sorta, and > here's where it gets interesting. it leaves it open, but closes the > window (sets it to 0)...or is the plugin doing this? apache is done > sending data and considers the conenction closed, so its client timeout > feature never comes into play. but there is still data in the sendq, > including the FIN, we believe. BSD obeys the spec (unfortunately) and > keeps probing to see if the window has opened so it can transmit the > last of the data. this goes on indefinitely! so we get gobs > connections stuck in fin_wait_1. interestingly, we have a solaris > machine serving the same purpose and it does not have the problem. it > seems to not folluw the rfc and silently closes the conenction after a > number of tries when a socket is in fin_wait_1. these seems more > reasonable to me. this seems (as i've read from other posts as well) > quite an opportunity for a DoS attack....just keep advertising a window > of 0. a single client could easily tie everything up in fin_wait_1... Can you recreate the problem with windows machines sitting around your office? If so, try capturing tcpdumps of the situation occuring on FreeBSD, and also it not occuring on Solaris so that we have something to look at. > > anyone think of a workaround (besides not serving pop-ups :) Well, not serving popups might be the simplest option, but I suppose that any fix to the problem would benefit non-popup servers too, so it's worth looking into. > jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 16:45:40 2003 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 561AF37B401 for ; Fri, 10 Jan 2003 16:45:17 -0800 (PST) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44EBB43F18 for ; Fri, 10 Jan 2003 16:45:16 -0800 (PST) (envelope-from julian@vicor.com) Received: from vicor.com (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 52BEE59228 for ; Fri, 10 Jan 2003 16:45:15 -0800 (PST) Message-ID: <3E1F691A.5060508@vicor.com> Date: Fri, 10 Jan 2003 16:45:14 -0800 From: Julian Elischer Reply-To: julian@freebsd.org Organization: VICOR User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021217 X-Accept-Language: en, hu MIME-Version: 1.0 To: net@freebsd.org Subject: Why we need SACK Content-Type: multipart/mixed; boundary="------------080708070209020700030803" Sender: owner-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. --------------080708070209020700030803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The internet is becoming a rather horrid place for packets sometimes.. Here's a trace. In this case SACK would have been a true blessing... Is there anyone considering looking at the varous SACK implementations to see if one might be fixed enough to be imported? (these were two 4.5 (+-) machines) talking through a vpn that apparently doesn't conserve packet order. (ipsec)), Link latency is about 73 mSecs, link bandwidth is about 300kBytes/sec. --------------080708070209020700030803 Content-Type: application/x-java-vm; name="trace" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="trace" MDAwMjk2IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogUyAzNDQ4MDU2 MTY5OjM0NDgwNTYxNjkoMCkgd2luIDY1NTM1IDxtc3MgMTQ2MCxub3Asd3NjYWxlIDEsbm9w LG5vcCx0aW1lc3RhbXAgMTI2ODk4NjE4MyAwPiAoREYpCjA3NTI2NSAxMC40Mi4yLjI1MC40 OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IFMgMjEzNzk4OTIxNzoyMTM3OTg5MjE3KDApIGFj ayAzNDQ4MDU2MTcwIHdpbiA2NTUzNSA8bXNzIDExNjAsbm9wLHdzY2FsZSAxLG5vcCxub3As dGltZXN0YW1wIDE4NDUzNzY1IDEyNjg5ODYxODM+IChERikKMDAwMTA2IDEwLjQyLjIuMjMu NDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3As dGltZXN0YW1wIDEyNjg5ODYxOTEgMTg0NTM3NjU+IChERikKMDEzNTg2IDEwLjQyLjIuMjUw LjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiAxMTQ5OjIyOTcoMTE0OCkgYWNrIDEgd2lu IDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc3MyAxMjY4OTg2MTkxPiAoREYpIFt0 b3MgMHg4XQowMDAxMTAgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAu IGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIwMCAxODQ1Mzc2 NT4gKERGKSBbdG9zIDB4OF0KMDAxNzg2IDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4y My40OTYwMDogLiAxOjExNDkoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVz dGFtcCAxODQ1Mzc3MyAxMjY4OTg2MTkxPiAoREYpIFt0b3MgMHg4XQowMDAxMDMgMTAuNDIu Mi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAyMjk3IHdpbiAzMjE0NCA8 bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIwMCAxODQ1Mzc3Mz4gKERGKSBbdG9zIDB4OF0K MDAwMzAzIDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgMjI5 NyB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMDAgMTg0NTM3NzM+IChE RikgW3RvcyAweDhdCjAwNjQ1MSAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2 MDA6IC4gMjI5NzozNDQ1KDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgMTg0NTM3NzMgMTI2ODk4NjE5MT4gKERGKSBbdG9zIDB4OF0KMDAyNzcxIDEwLjQyLjIu MjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogUCAzNDQ1OjQwOTcoNjUyKSBhY2sgMSB3 aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDUzNzczIDEyNjg5ODYxOTE+IChERikg W3RvcyAweDhdCjAwMDA4OSAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6 IC4gYWNrIDQwOTcgd2luIDMyOTY2IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjAxIDE4 NDUzNzczPiAoREYpIFt0b3MgMHg4XQowMDM4MjggMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40 Mi4yLjIzLjQ5NjAwOiAuIDQwOTc6NTI0NSgxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxu b3AsdGltZXN0YW1wIDE4NDUzNzczIDEyNjg5ODYxOTE+IChERikgW3RvcyAweDhdCjAwNjQ5 MiAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNTI0NTo2MzkzKDEx NDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3NzMgMTI2ODk4 NjE5MT4gKERGKSBbdG9zIDB4OF0KMDAwMDkxIDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4y LjI1MC40OTE2ODogLiBhY2sgNjM5MyB3aW4gMzI3MTggPG5vcCxub3AsdGltZXN0YW1wIDEy Njg5ODYyMDIgMTg0NTM3NzM+IChERikgW3RvcyAweDhdCjAwMTA2NSAxMC40Mi4yLjI1MC40 OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNjM5Mzo3NTQxKDExNDgpIGFjayAxIHdpbiAz MzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3NzMgMTI2ODk4NjE5MT4gKERGKSBbdG9z IDB4OF0KMDAwMTIyIDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBh Y2sgNzU0MSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMDIgMTg0NTM3 NzM+IChERikgW3RvcyAweDhdCjAwNjU5OCAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIu MjMuNDk2MDA6IC4gODY4OTo5ODM3KDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0 aW1lc3RhbXAgMTg0NTM3NzMgMTI2ODk4NjE5MT4gKERGKSBbdG9zIDB4OF0KMDAwMDk2IDEw LjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNzU0MSB3aW4gMzMy OTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMDIgMTg0NTM3NzM+IChERikgW3RvcyAw eDhdCjAxMzAxOCAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNzU0 MTo4Njg5KDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3 NzMgMTI2ODk4NjE5MT4gKERGKSBbdG9zIDB4OF0KMDAwMTAzIDEwLjQyLjIuMjMuNDk2MDAg PiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgOTgzNyB3aW4gMzIxNDQgPG5vcCxub3AsdGlt ZXN0YW1wIDEyNjg5ODYyMDQgMTg0NTM3NzM+IChERikgW3RvcyAweDhdCjAwMDI2OSAxMC40 Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDk4Mzcgd2luIDMzMjky IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjA0IDE4NDUzNzczPiAoREYpIFt0b3MgMHg4 XQowMTAxNzAgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDk4Mzc6 MTA5ODUoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc3 MyAxMjY4OTg2MTkxPiAoREYpIFt0b3MgMHg4XQowMDY3NDAgMTAuNDIuMi4yNTAuNDkxNjgg PiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDEyMTMzOjEzMjgxKDExNDgpIGFjayAxIHdpbiAzMzI5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3NzMgMTI2ODk4NjE5MT4gKERGKSBbdG9zIDB4 OF0KMDAwMDk0IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sg MTA5ODUgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjA2IDE4NDUzNzcz PiAoREYpIFt0b3MgMHg4XQowMDEwODMgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIz LjQ5NjAwOiAuIDEwOTg1OjEyMTMzKDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0 aW1lc3RhbXAgMTg0NTM3NzMgMTI2ODk4NjE5MT4gKERGKSBbdG9zIDB4OF0KMDAwMTAxIDEw LjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgMTMyODEgd2luIDMy MTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjA2IDE4NDUzNzczPiAoREYpIFt0b3Mg MHg4XQowMDAyNzUgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFj ayAxMzI4MSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMDYgMTg0NTM3 NzM+IChERikgW3RvcyAweDhdCjAwNTE4OSAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIu MjMuNDk2MDA6IC4gMTQ0Mjk6MTU1NzcoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9w LHRpbWVzdGFtcCAxODQ1Mzc3MyAxMjY4OTg2MTkxPiAoREYpIFt0b3MgMHg4XQowMDAwOTYg MTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxMzI4MSB3aW4g MzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMDYgMTg0NTM3NzM+IChERikgW3Rv cyAweDhdCjAwMTA4MiAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4g MTMyODE6MTQ0MjkoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAx ODQ1Mzc3MyAxMjY4OTg2MTkxPiAoREYpIFt0b3MgMHg4XQowMDAxMDAgMTAuNDIuMi4yMy40 OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxNTU3NyB3aW4gMzIxNDQgPG5vcCxu b3AsdGltZXN0YW1wIDEyNjg5ODYyMDYgMTg0NTM3NzM+IChERikgW3RvcyAweDhdCjAwMDI2 OSAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDE1NTc3IHdp biAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIwNiAxODQ1Mzc3Mz4gKERGKSBb dG9zIDB4OF0KMDA1MTc3IDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDog LiAxNjcyNToxNzg3MygxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1w IDE4NDUzNzczIDEyNjg5ODYxOTE+IChERikgW3RvcyAweDhdCjAwMDA5NCAxMC40Mi4yLjIz LjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDE1NTc3IHdpbiAzMzI5MiA8bm9w LG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIwNyAxODQ1Mzc3Mz4gKERGKSBbdG9zIDB4OF0KMDA1 MzcwIDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiAxNTU3NzoxNjcy NSgxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDUzNzczIDEy Njg5ODYxOTE+IChERikgW3RvcyAweDhdCjAwMDEwMSAxMC40Mi4yLjIzLjQ5NjAwID4gMTAu NDIuMi4yNTAuNDkxNjg6IC4gYWNrIDE3ODczIHdpbiAzMjE0NCA8bm9wLG5vcCx0aW1lc3Rh bXAgMTI2ODk4NjIwNyAxODQ1Mzc3Mz4gKERGKSBbdG9zIDB4OF0KMDAwMzA4IDEwLjQyLjIu MjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgMTc4NzMgd2luIDMzMjkyIDxu b3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjA3IDE4NDUzNzczPiAoREYpIFt0b3MgMHg4XQow MDEwNTggMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDE5MDIxOjIw MTY5KDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3NzMg MTI2ODk4NjE5MT4gKERGKSBbdG9zIDB4OF0KMDAwMDk1IDEwLjQyLjIuMjMuNDk2MDAgPiAx MC40Mi4yLjI1MC40OTE2ODogLiBhY2sgMTc4NzMgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVz dGFtcCAxMjY4OTg2MjA4IDE4NDUzNzczPiAoREYpIFt0b3MgMHg4XQowMDQ5NzAgMTAuNDIu Mi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDE3ODczOjE5MDIxKDExNDgpIGFj ayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3NzMgMTI2ODk4NjE5MT4g KERGKSBbdG9zIDB4OF0KMDAwMTA1IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40 OTE2ODogLiBhY2sgMjAxNjkgd2luIDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2 MjA4IDE4NDUzNzczPiAoREYpIFt0b3MgMHg4XQowMDEwODQgMTAuNDIuMi4yNTAuNDkxNjgg PiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDIxMzE3OjIyNDY1KDExNDgpIGFjayAxIHdpbiAzMzI5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3NzMgMTI2ODk4NjE5MT4gKERGKSBbdG9zIDB4 OF0KMDAwMDkyIDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sg MjAxNjkgd2luIDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjA4IDE4NDUzNzcz PiAoREYpIFt0b3MgMHg4XQowMDAyNzAgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUw LjQ5MTY4OiAuIGFjayAyMDE2OSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5 ODYyMDggMTg0NTM3NzM+IChERikgW3RvcyAweDhdCjAwNTE2NSAxMC40Mi4yLjI1MC40OTE2 OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gMjAxNjk6MjEzMTcoMTE0OCkgYWNrIDEgd2luIDMz MjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc3MyAxMjY4OTg2MTkxPiAoREYpIFt0b3Mg MHg4XQowMDAxMzUgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFj ayAyMjQ2NSB3aW4gMzIxNDQgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMDkgMTg0NTM3 NzM+IChERikgW3RvcyAweDhdCjAwMTA4OCAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIu MjMuNDk2MDA6IC4gMjM2MTM6MjQ3NjEoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9w LHRpbWVzdGFtcCAxODQ1Mzc3MyAxMjY4OTg2MTkxPiAoREYpIFt0b3MgMHg4XQowMDAwOTMg MTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAyMjQ2NSB3aW4g MzI3NDcgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMDkgMTg0NTM3NzM+IChERikgW3Rv cyAweDhdCjAwNjY3NiAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4g MjU5MDk6MjcwNTcoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAx ODQ1Mzc3MyAxMjY4OTg2MTkxPiAoREYpIFt0b3MgMHg4XQowMDAwOTYgMTAuNDIuMi4yMy40 OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAyMjQ2NSB3aW4gMzMyOTIgPG5vcCxu b3AsdGltZXN0YW1wIDEyNjg5ODYyMTAgMTg0NTM3NzM+IChERikgW3RvcyAweDhdCjAwNjU2 MCAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gMjgyMDU6MjkzNTMo MTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc3MyAxMjY4 OTg2MTkxPiAoREYpIFt0b3MgMHg4XQowMDAwOTIgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQy LjIuMjUwLjQ5MTY4OiAuIGFjayAyMjQ2NSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1w IDEyNjg5ODYyMTAgMTg0NTM3NzM+IChERikgW3RvcyAweDhdCjAwNjY0OCAxMC40Mi4yLjI1 MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gMzA1MDE6MzE2NDkoMTE0OCkgYWNrIDEg d2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc3MyAxMjY4OTg2MTkxPiAoREYp IFt0b3MgMHg4XQowMDAwOTMgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4 OiAuIGFjayAyMjQ2NSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMTEg MTg0NTM3NzM+IChERikgW3RvcyAweDhdCjAwNjY2OCAxMC40Mi4yLjI1MC40OTE2OCA+IDEw LjQyLjIuMjMuNDk2MDA6IC4gMzI3OTc6MzM5NDUoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxu b3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc4MSAxMjY4OTg2MjAwPiAoREYpIFt0b3MgMHg4XQow MDAwOTMgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAyMjQ2 NSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMTIgMTg0NTM3NzM+IChE RikgW3RvcyAweDhdCjAwMjI3NiAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2 MDA6IC4gMjI0NjU6MjM2MTMoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVz dGFtcCAxODQ1Mzc3MyAxMjY4OTg2MTkxPiAoREYpIFt0b3MgMHg4XQowMDAxMDIgMTAuNDIu Mi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAyNDc2MSB3aW4gMzIxNDQg PG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMTIgMTg0NTM3NzM+IChERikgW3RvcyAweDhd CjAwMDI3MCAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDI0 NzYxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIxMiAxODQ1Mzc3Mz4g KERGKSBbdG9zIDB4OF0KMDAzOTQ3IDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40 OTYwMDogLiAzNTA5MzozNjI0MSgxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGlt ZXN0YW1wIDE4NDUzNzgxIDEyNjg5ODYyMDA+IChERikgW3RvcyAweDhdCjAwMDA5NiAxMC40 Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDI0NzYxIHdpbiAzMzI5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIxMiAxODQ1Mzc3Mz4gKERGKSBbdG9zIDB4 OF0KMDA2NjI0IDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiAzNzM4 OTozODUzNygxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDUz NzgxIDEyNjg5ODYyMDA+IChERikgW3RvcyAweDhdCjAwMDA5NCAxMC40Mi4yLjIzLjQ5NjAw ID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDI0NzYxIHdpbiAzMzI5MiA8bm9wLG5vcCx0 aW1lc3RhbXAgMTI2ODk4NjIxMyAxODQ1Mzc3Mz4gKERGKSBbdG9zIDB4OF0KMDAxMDgyIDEw LjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiAyNDc2MToyNTkwOSgxMTQ4 KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDUzNzczIDEyNjg5ODYx OTE+IChERikgW3RvcyAweDhdCjAwMDEwNiAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4y NTAuNDkxNjg6IC4gYWNrIDI3MDU3IHdpbiAzMjE0NCA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2 ODk4NjIxMyAxODQ1Mzc3Mz4gKERGKSBbdG9zIDB4OF0KMDAwMjczIDEwLjQyLjIuMjMuNDk2 MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgMjcwNTcgd2luIDMzMjkyIDxub3Asbm9w LHRpbWVzdGFtcCAxMjY4OTg2MjEzIDE4NDUzNzczPiAoREYpIFt0b3MgMHg4XQowMDYxNjkg MTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDI3MDU3OjI4MjA1KDEx NDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3NzMgMTI2ODk4 NjE5MT4gKERGKSBbdG9zIDB4OF0KMDAwMTA3IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4y LjI1MC40OTE2ODogLiBhY2sgMjkzNTMgd2luIDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAx MjY4OTg2MjE0IDE4NDUzNzczPiAoREYpIFt0b3MgMHg4XQowMDAyNzggMTAuNDIuMi4yMy40 OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAyOTM1MyB3aW4gMzMyOTIgPG5vcCxu b3AsdGltZXN0YW1wIDEyNjg5ODYyMTQgMTg0NTM3NzM+IChERikgW3RvcyAweDhdCjAwNjM4 NSAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gMjkzNTM6MzA1MDEo MTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc3MyAxMjY4 OTg2MTkxPiAoREYpIFt0b3MgMHg4XQowMDAxMDMgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQy LjIuMjUwLjQ5MTY4OiAuIGFjayAzMTY0OSB3aW4gMzIxNDQgPG5vcCxub3AsdGltZXN0YW1w IDEyNjg5ODYyMTQgMTg0NTM3NzM+IChERikgW3RvcyAweDhdCjAwMDI3NSAxMC40Mi4yLjIz LjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDMxNjQ5IHdpbiAzMzI5MiA8bm9w LG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIxNCAxODQ1Mzc3Mz4gKERGKSBbdG9zIDB4OF0KMDAx MTIyIDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiAzOTY4NTo0MDgz MygxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDUzNzgxIDEy Njg5ODYyMDA+IChERikgW3RvcyAweDhdCjAwMDA5NSAxMC40Mi4yLjIzLjQ5NjAwID4gMTAu NDIuMi4yNTAuNDkxNjg6IC4gYWNrIDMxNjQ5IHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgMTI2ODk4NjIxNSAxODQ1Mzc3Mz4gKERGKSBbdG9zIDB4OF0KMDA1MTAwIDEwLjQyLjIu MjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiAzMTY0OTozMjc5NygxMTQ4KSBhY2sg MSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDUzNzczIDEyNjg5ODYxOTE+IChE RikgW3RvcyAweDhdCjAwMDEwMyAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkx Njg6IC4gYWNrIDMzOTQ1IHdpbiAzMjE0NCA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIx NSAxODQ1Mzc3Mz4gKERGKSBbdG9zIDB4OF0KMDAwMjkzIDEwLjQyLjIuMjMuNDk2MDAgPiAx MC40Mi4yLjI1MC40OTE2ODogLiBhY2sgMzM5NDUgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVz dGFtcCAxMjY4OTg2MjE1IDE4NDUzNzczPiAoREYpIFt0b3MgMHg4XQowMDExMzIgMTAuNDIu Mi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDQxOTgxOjQzMTI5KDExNDgpIGFj ayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3ODIgMTI2ODk4NjIwMD4g KERGKSBbdG9zIDB4OF0KMDAwMDk2IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40 OTE2ODogLiBhY2sgMzM5NDUgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2 MjE1IDE4NDUzNzczPiAoREYpIFt0b3MgMHg4XQowMDY2MjkgMTAuNDIuMi4yNTAuNDkxNjgg PiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDQ0Mjc3OjQ1NDI1KDExNDgpIGFjayAxIHdpbiAzMzI5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3ODIgMTI2ODk4NjIwMD4gKERGKSBbdG9zIDB4 OF0KMDAwMDk2IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sg MzM5NDUgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjE2IDE4NDUzNzcz PiAoREYpIFt0b3MgMHg4XQowMDY2NDYgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIz LjQ5NjAwOiAuIDQ2NTczOjQ3NzIxKDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0 aW1lc3RhbXAgMTg0NTM3ODIgMTI2ODk4NjIwMD4gKERGKSBbdG9zIDB4OF0KMDAwMDk0IDEw LjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgMzM5NDUgd2luIDMz MjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjE3IDE4NDUzNzczPiAoREYpIFt0b3Mg MHg4XQowMTI2MTUgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDQ4 ODY5OjUwMDE3KDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0 NTM3ODIgMTI2ODk4NjIwMD4gKERGKSBbdG9zIDB4OF0KMDAwMDk1IDEwLjQyLjIuMjMuNDk2 MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgMzM5NDUgd2luIDMzMjkyIDxub3Asbm9w LHRpbWVzdGFtcCAxMjY4OTg2MjE4IDE4NDUzNzczPiAoREYpIFt0b3MgMHg4XQowMDI3NjQg MTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDMzOTQ1OjM1MDkzKDEx NDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3ODEgMTI2ODk4 NjIwMD4gKERGKSBbdG9zIDB4OF0KMDAwMTAyIDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4y LjI1MC40OTE2ODogLiBhY2sgMzYyNDEgd2luIDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAx MjY4OTg2MjE4IDE4NDUzNzgxPiAoREYpIFt0b3MgMHg4XQowMDAyNjggMTAuNDIuMi4yMy40 OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAzNjI0MSB3aW4gMzMyOTIgPG5vcCxu b3AsdGltZXN0YW1wIDEyNjg5ODYyMTggMTg0NTM3ODE+IChERikgW3RvcyAweDhdCjAwMzU0 MiAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNTExNjU6NTIzMTMo MTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc4MiAxMjY4 OTg2MjAwPiAoREYpIFt0b3MgMHg4XQowMDAxMTIgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQy LjIuMjUwLjQ5MTY4OiAuIGFjayAzNjI0MSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1w IDEyNjg5ODYyMTggMTg0NTM3ODE+IChERikgW3RvcyAweDhdCjAwNjU1NCAxMC40Mi4yLjI1 MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNTM0NjE6NTQ2MDkoMTE0OCkgYWNrIDEg d2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc4MiAxMjY4OTg2MjAwPiAoREYp IFt0b3MgMHg4XQowMDAwOTQgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4 OiAuIGFjayAzNjI0MSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMTkg MTg0NTM3ODE+IChERikgW3RvcyAweDhdCjAwNjY0MCAxMC40Mi4yLjI1MC40OTE2OCA+IDEw LjQyLjIuMjMuNDk2MDA6IC4gNTU3NTc6NTY5MDUoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxu b3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc4MiAxMjY4OTg2MjAwPiAoREYpIFt0b3MgMHg4XQow MDAwOTQgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAzNjI0 MSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMjAgMTg0NTM3ODE+IChE RikgW3RvcyAweDhdCjAwNjU5NiAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2 MDA6IC4gNTgwNTM6NTkyMDEoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVz dGFtcCAxODQ1Mzc4MiAxMjY4OTg2MjAwPiAoREYpIFt0b3MgMHg4XQowMDAwOTYgMTAuNDIu Mi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAzNjI0MSB3aW4gMzMyOTIg PG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMjEgMTg0NTM3ODE+IChERikgW3RvcyAweDhd CjAwNjUxNiAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gMzYyNDE6 MzczODkoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc4 MSAxMjY4OTg2MjAwPiAoREYpIFt0b3MgMHg4XQowMDAxMDIgMTAuNDIuMi4yMy40OTYwMCA+ IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAzODUzNyB3aW4gMzIxNDQgPG5vcCxub3AsdGlt ZXN0YW1wIDEyNjg5ODYyMjEgMTg0NTM3ODE+IChERikgW3RvcyAweDhdCjAwMTA4MCAxMC40 Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNjAzNDk6NjE0OTcoMTE0OCkg YWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc4MiAxMjY4OTg2MjAw PiAoREYpIFt0b3MgMHg4XQowMDAwOTQgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUw LjQ5MTY4OiAuIGFjayAzODUzNyB3aW4gMzIxNDQgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5 ODYyMjEgMTg0NTM3ODE+IChERikgW3RvcyAweDhdCjAwMDI2OCAxMC40Mi4yLjIzLjQ5NjAw ID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDM4NTM3IHdpbiAzMzI5MiA8bm9wLG5vcCx0 aW1lc3RhbXAgMTI2ODk4NjIyMSAxODQ1Mzc4MT4gKERGKSBbdG9zIDB4OF0KMDA1MjIyIDEw LjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiAzODUzNzozOTY4NSgxMTQ4 KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDUzNzgxIDEyNjg5ODYy MDA+IChERikgW3RvcyAweDhdCjAwMDEwMyAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4y NTAuNDkxNjg6IC4gYWNrIDQwODMzIHdpbiAzMjE0NCA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2 ODk4NjIyMiAxODQ1Mzc4MT4gKERGKSBbdG9zIDB4OF0KMDAxMDYyIDEwLjQyLjIuMjUwLjQ5 MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiA2MjY0NTo2Mzc5MygxMTQ4KSBhY2sgMSB3aW4g MzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDUzNzgyIDEyNjg5ODYyMDA+IChERikgW3Rv cyAweDhdCjAwMDA5MyAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4g YWNrIDQwODMzIHdpbiAzMjE0NCA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIyMiAxODQ1 Mzc4MT4gKERGKSBbdG9zIDB4OF0KMDAwMjk2IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4y LjI1MC40OTE2ODogLiBhY2sgNDA4MzMgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAx MjY4OTg2MjIyIDE4NDUzNzgxPiAoREYpIFt0b3MgMHg4XQowMDUxNjQgMTAuNDIuMi4yNTAu NDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDQwODMzOjQxOTgxKDExNDgpIGFjayAxIHdp biAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3ODIgMTI2ODk4NjIwMD4gKERGKSBb dG9zIDB4OF0KMDAwMTA0IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODog LiBhY2sgNDMxMjkgd2luIDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjIzIDE4 NDUzNzgyPiAoREYpIFt0b3MgMHg4XQowMDEwNjEgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40 Mi4yLjIzLjQ5NjAwOiAuIDY0OTQxOjY2MDg5KDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9w LG5vcCx0aW1lc3RhbXAgMTg0NTM3ODIgMTI2ODk4NjIwMD4gKERGKSBbdG9zIDB4OF0KMDAw MDk0IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNDMxMjkg d2luIDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjIzIDE4NDUzNzgyPiAoREYp IFt0b3MgMHg4XQowMDAyNzQgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4 OiAuIGFjayA0MzEyOSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMjMg MTg0NTM3ODI+IChERikgW3RvcyAweDhdCjAwNTIwNiAxMC40Mi4yLjI1MC40OTE2OCA+IDEw LjQyLjIuMjMuNDk2MDA6IC4gNDMxMjk6NDQyNzcoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxu b3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc4MiAxMjY4OTg2MjAwPiAoREYpIFt0b3MgMHg4XQow MDAxMDUgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA0NTQy NSB3aW4gMzIxNDQgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMjMgMTg0NTM3ODI+IChE RikgW3RvcyAweDhdCjAwMTA3MiAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2 MDA6IC4gNjcyMzc6NjgzODUoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVz dGFtcCAxODQ1Mzc4MiAxMjY4OTg2MjAwPiAoREYpIFt0b3MgMHg4XQowMDAwOTQgMTAuNDIu Mi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA0NTQyNSB3aW4gMzIxNDQg PG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMjMgMTg0NTM3ODI+IChERikgW3RvcyAweDhd CjAwMDI3MSAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDQ1 NDI1IHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIyMyAxODQ1Mzc4Mj4g KERGKSBbdG9zIDB4OF0KMDA1MTc5IDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40 OTYwMDogLiA0NTQyNTo0NjU3MygxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGlt ZXN0YW1wIDE4NDUzNzgyIDEyNjg5ODYyMDA+IChERikgW3RvcyAweDhdCjAwMDEwNCAxMC40 Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDQ3NzIxIHdpbiAzMjE0 NCA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIyNCAxODQ1Mzc4Mj4gKERGKSBbdG9zIDB4 OF0KMDAwMjk1IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sg NDc3MjEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjI0IDE4NDUzNzgy PiAoREYpIFt0b3MgMHg4XQowMDIwMTAgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIz LjQ5NjAwOiAuIDY5NTMzOjcwNjgxKDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0 aW1lc3RhbXAgMTg0NTM3ODMgMTI2ODk4NjIwMj4gKERGKSBbdG9zIDB4OF0KMDAwMDk3IDEw LjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNDc3MjEgd2luIDMz MjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjI0IDE4NDUzNzgyPiAoREYpIFt0b3Mg MHg4XQowMDQxOTEgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDQ3 NzIxOjQ4ODY5KDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0 NTM3ODIgMTI2ODk4NjIwMD4gKERGKSBbdG9zIDB4OF0KMDAwMTAzIDEwLjQyLjIuMjMuNDk2 MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNTAwMTcgd2luIDMyMTQ0IDxub3Asbm9w LHRpbWVzdGFtcCAxMjY4OTg2MjI1IDE4NDUzNzgyPiAoREYpIFt0b3MgMHg4XQowMDAyNzEg MTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA1MDAxNyB3aW4g MzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMjUgMTg0NTM3ODI+IChERikgW3Rv cyAweDhdCjAwMjAyNiAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4g NzE4Mjk6NzI5NzcoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAx ODQ1Mzc4NCAxMjY4OTg2MjAyPiAoREYpIFt0b3MgMHg4XQowMDAwOTcgMTAuNDIuMi4yMy40 OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA1MDAxNyB3aW4gMzMyOTIgPG5vcCxu b3AsdGltZXN0YW1wIDEyNjg5ODYyMjUgMTg0NTM3ODI+IChERikgW3RvcyAweDhdCjAwNDI0 NyAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNTAwMTc6NTExNjUo MTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc4MiAxMjY4 OTg2MjAwPiAoREYpIFt0b3MgMHg4XQowMDAxMDIgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQy LjIuMjUwLjQ5MTY4OiAuIGFjayA1MjMxMyB3aW4gMzIxNDQgPG5vcCxub3AsdGltZXN0YW1w IDEyNjg5ODYyMjUgMTg0NTM3ODI+IChERikgW3RvcyAweDhdCjAwMDI3MCAxMC40Mi4yLjIz LjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDUyMzEzIHdpbiAzMzI5MiA8bm9w LG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIyNSAxODQ1Mzc4Mj4gKERGKSBbdG9zIDB4OF0KMDAx OTgzIDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiA3NDEyNTo3NTI3 MygxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDUzNzg2IDEy Njg5ODYyMDQ+IChERikgW3RvcyAweDhdCjAwMDA5NyAxMC40Mi4yLjIzLjQ5NjAwID4gMTAu NDIuMi4yNTAuNDkxNjg6IC4gYWNrIDUyMzEzIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgMTI2ODk4NjIyNSAxODQ1Mzc4Mj4gKERGKSBbdG9zIDB4OF0KMDA0MzA5IDEwLjQyLjIu MjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiA1MjMxMzo1MzQ2MSgxMTQ4KSBhY2sg MSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDUzNzgyIDEyNjg5ODYyMDA+IChE RikgW3RvcyAweDhdCjAwMDEwMyAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkx Njg6IC4gYWNrIDU0NjA5IHdpbiAzMjE0NCA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIy NiAxODQ1Mzc4Mj4gKERGKSBbdG9zIDB4OF0KMDAwMjcxIDEwLjQyLjIuMjMuNDk2MDAgPiAx MC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNTQ2MDkgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVz dGFtcCAxMjY4OTg2MjI2IDE4NDUzNzgyPiAoREYpIFt0b3MgMHg4XQowMDE5NzMgMTAuNDIu Mi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDc2NDIxOjc3NTY5KDExNDgpIGFj ayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3ODcgMTI2ODk4NjIwNj4g KERGKSBbdG9zIDB4OF0KMDAwMDk2IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40 OTE2ODogLiBhY2sgNTQ2MDkgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2 MjI2IDE4NDUzNzgyPiAoREYpIFt0b3MgMHg4XQowMDQyODMgMTAuNDIuMi4yNTAuNDkxNjgg PiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDU0NjA5OjU1NzU3KDExNDgpIGFjayAxIHdpbiAzMzI5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3ODIgMTI2ODk4NjIwMD4gKERGKSBbdG9zIDB4 OF0KMDAwMTAyIDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sg NTY5MDUgd2luIDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjI3IDE4NDUzNzgy PiAoREYpIFt0b3MgMHg4XQowMDAzMDAgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUw LjQ5MTY4OiAuIGFjayA1NjkwNSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5 ODYyMjcgMTg0NTM3ODI+IChERikgW3RvcyAweDhdCjAwMjIzMCAxMC40Mi4yLjI1MC40OTE2 OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNzg3MTc6Nzk4NjUoMTE0OCkgYWNrIDEgd2luIDMz MjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc4OCAxMjY4OTg2MjA2PiAoREYpIFt0b3Mg MHg4XQowMDAwOTggMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFj ayA1NjkwNSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMjcgMTg0NTM3 ODI+IChERikgW3RvcyAweDhdCjAwNDAyMiAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIu MjMuNDk2MDA6IC4gNTY5MDU6NTgwNTMoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9w LHRpbWVzdGFtcCAxODQ1Mzc4MiAxMjY4OTg2MjAwPiAoREYpIFt0b3MgMHg4XQowMDAxMDIg MTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA1OTIwMSB3aW4g MzIxNDQgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMjcgMTg0NTM3ODI+IChERikgW3Rv cyAweDhdCjAwMDI2OSAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4g YWNrIDU5MjAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIyNyAxODQ1 Mzc4Mj4gKERGKSBbdG9zIDB4OF0KMDAyMjA2IDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIu Mi4yMy40OTYwMDogLiA4MTAxMzo4MjE2MSgxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxu b3AsdGltZXN0YW1wIDE4NDUzNzg5IDEyNjg5ODYyMDc+IChERikgW3RvcyAweDhdCjAwMDA5 OCAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDU5MjAxIHdp biAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIyNyAxODQ1Mzc4Mj4gKERGKSBb dG9zIDB4OF0KMDA0MDcxIDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDog LiA1OTIwMTo2MDM0OSgxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1w IDE4NDUzNzgyIDEyNjg5ODYyMDA+IChERikgW3RvcyAweDhdCjAwMDEwMiAxMC40Mi4yLjIz LjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDYxNDk3IHdpbiAzMjE0NCA8bm9w LG5vcCx0aW1lc3RhbXAgMTI2ODk4NjIyOCAxODQ1Mzc4Mj4gKERGKSBbdG9zIDB4OF0KMDAw MjczIDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNjE0OTcg d2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjI4IDE4NDUzNzgyPiAoREYp IFt0b3MgMHg4XQowMDIxNTMgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAw OiAuIDgzMzA5Ojg0NDU3KDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgMTg0NTM3ODkgMTI2ODk4NjIwNz4gKERGKSBbdG9zIDB4OF0KMDAwMDk1IDEwLjQyLjIu MjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNjE0OTcgd2luIDMzMjkyIDxu b3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjI4IDE4NDUzNzgyPiAoREYpIFt0b3MgMHg4XQow MDQwODUgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDYxNDk3OjYy NjQ1KDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3ODIg MTI2ODk4NjIwMD4gKERGKSBbdG9zIDB4OF0KMDAwMTAxIDEwLjQyLjIuMjMuNDk2MDAgPiAx MC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNjM3OTMgd2luIDMyMTQ0IDxub3Asbm9wLHRpbWVz dGFtcCAxMjY4OTg2MjI5IDE4NDUzNzgyPiAoREYpIFt0b3MgMHg4XQowMDAyODkgMTAuNDIu Mi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMyOTIg PG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMjkgMTg0NTM3ODI+IChERikgW3RvcyAweDhd CjAwMjE4NyAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gODU2MDU6 ODY3NTMoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc5 MSAxMjY4OTg2MjA5PiAoREYpIFt0b3MgMHg4XQowMDAwOTcgMTAuNDIuMi4yMy40OTYwMCA+ IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMyOTIgPG5vcCxub3AsdGlt ZXN0YW1wIDEyNjg5ODYyMjkgMTg0NTM3ODI+IChERikgW3RvcyAweDhdCjAwNjY0MCAxMC40 Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gODc5MDE6ODkwNDkoMTE0OCkg YWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc5MSAxMjY4OTg2MjEw PiAoREYpIFt0b3MgMHg4XQowMDAxMDggMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUw LjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5 ODYyMzAgMTg0NTM3ODI+IChERikgW3RvcyAweDhdCjAwNjYyMSAxMC40Mi4yLjI1MC40OTE2 OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gMjQ3NjE6MjU5MDkoMTE0OCkgYWNrIDEgd2luIDMz MjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc5NCAxMjY4OTg2MjEyPiAoREYpIFt0b3Mg MHg4XQowMDAwODkgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFj ayA2Mzc5MyB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMzAgMTg0NTM3 OTQ+IChERikgW3RvcyAweDhdCjAxNDQ1NiAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIu MjMuNDk2MDA6IC4gNjM3OTM6NjQ5NDEoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9w LHRpbWVzdGFtcCAxODQ1Mzc4MiAxMjY4OTg2MjAwPiAoREYpIFt0b3MgMHg4XQowMDAwODgg MTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4g MzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMzIgMTg0NTM3OTQ+IChERikgW3Rv cyAweDhdCjAwNjY0NSAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4g NjYwODk6NjcyMzcoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAx ODQ1Mzc4MiAxMjY4OTg2MjAwPiAoREYpIFt0b3MgMHg4XQowMDAwODcgMTAuNDIuMi4yMy40 OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMyOTIgPG5vcCxu b3AsdGltZXN0YW1wIDEyNjg5ODYyMzIgMTg0NTM3OTQ+IChERikgW3RvcyAweDhdCjAwNjY1 MCAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNjgzODU6Njk1MzMo MTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc4MiAxMjY4 OTg2MjAxPiAoREYpIFt0b3MgMHg4XQowMDAwODcgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQy LjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1w IDEyNjg5ODYyMzMgMTg0NTM3OTQ+IChERikgW3RvcyAweDhdCjAxMjE4MiAxMC40Mi4yLjI1 MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNzA2ODE6NzE4MjkoMTE0OCkgYWNrIDEg d2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc4NCAxMjY4OTg2MjAyPiAoREYp IFt0b3MgMHg4XQowMDAwODcgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4 OiAuIGFjayA2Mzc5MyB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMzQg MTg0NTM3OTQ+IChERikgW3RvcyAweDhdCjAwMjY0MiAxMC40Mi4yLjI1MC40OTE2OCA+IDEw LjQyLjIuMjMuNDk2MDA6IC4gOTAxOTc6OTEzNDUoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxu b3Asbm9wLHRpbWVzdGFtcCAxODQ1MzgwOCAxMjY4OTg2MjI2PiAoREYpIFt0b3MgMHg4XQow MDAwOTUgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5 MyB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMzQgMTg0NTM3OTQ+IChE RikgW3RvcyAweDhdCjAwMzkyMSAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2 MDA6IC4gNzI5Nzc6NzQxMjUoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVz dGFtcCAxODQ1Mzc4NiAxMjY4OTg2MjA0PiAoREYpIFt0b3MgMHg4XQowMDAwODYgMTAuNDIu Mi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMyOTIg PG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMzUgMTg0NTM3OTQ+IChERikgW3RvcyAweDhd CjAwMjg2NSAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gOTI0OTM6 OTM2NDEoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzgw OCAxMjY4OTg2MjI3PiAoREYpIFt0b3MgMHg4XQowMDAwOTQgMTAuNDIuMi4yMy40OTYwMCA+ IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMyOTIgPG5vcCxub3AsdGlt ZXN0YW1wIDEyNjg5ODYyMzUgMTg0NTM3OTQ+IChERikgW3RvcyAweDhdCjAwNzIzMiAxMC40 Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gOTQ3ODk6OTU5MzcoMTE0OCkg YWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1MzgwOSAxMjY4OTg2MjI3 PiAoREYpIFt0b3MgMHg4XQowMDAwOTYgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUw LjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5 ODYyMzYgMTg0NTM3OTQ+IChERikgW3RvcyAweDhdCjAwNDk3NSAxMC40Mi4yLjI1MC40OTE2 OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNzUyNzM6NzY0MjEoMTE0OCkgYWNrIDEgd2luIDMz MjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc4NiAxMjY4OTg2MjA0PiAoREYpIFt0b3Mg MHg4XQowMDAwODYgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFj ayA2Mzc5MyB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMzYgMTg0NTM3 OTQ+IChERikgW3RvcyAweDhdCjAwMTU2MyAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIu MjMuNDk2MDA6IC4gOTcwODU6OTgyMzMoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9w LHRpbWVzdGFtcCAxODQ1MzgxMCAxMjY4OTg2MjI4PiAoREYpIFt0b3MgMHg4XQowMDAwOTYg MTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4g MzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMzcgMTg0NTM3OTQ+IChERikgW3Rv cyAweDhdCjAwNTAwMyAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4g Nzc1Njk6Nzg3MTcoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAx ODQ1Mzc4OCAxMjY4OTg2MjA2PiAoREYpIFt0b3MgMHg4XQowMDAwODYgMTAuNDIuMi4yMy40 OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMyOTIgPG5vcCxu b3AsdGltZXN0YW1wIDEyNjg5ODYyMzcgMTg0NTM3OTQ+IChERikgW3RvcyAweDhdCjAwMTU1 MyAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gOTkzODE6MTAwNTI5 KDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM4MTAgMTI2 ODk4NjIyOT4gKERGKSBbdG9zIDB4OF0KMDAwMDk2IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40 Mi4yLjI1MC40OTE2ODogLiBhY2sgNjM3OTMgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFt cCAxMjY4OTg2MjM3IDE4NDUzNzk0PiAoREYpIFt0b3MgMHg4XQowMDYzNTkgMTAuNDIuMi4y NTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDc5ODY1OjgxMDEzKDExNDgpIGFjayAx IHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3ODggMTI2ODk4NjIwNj4gKERG KSBbdG9zIDB4OF0KMDAwMDg4IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2 ODogLiBhY2sgNjM3OTMgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjM4 IDE4NDUzNzk0PiAoREYpIFt0b3MgMHg4XQowMDY2NTMgMTAuNDIuMi4yNTAuNDkxNjggPiAx MC40Mi4yLjIzLjQ5NjAwOiAuIDgyMTYxOjgzMzA5KDExNDgpIGFjayAxIHdpbiAzMzI5MiA8 bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM3ODkgMTI2ODk4NjIwNz4gKERGKSBbdG9zIDB4OF0K MDAwMDg2IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNjM3 OTMgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjM5IDE4NDUzNzk0PiAo REYpIFt0b3MgMHg4XQowMDE5MzUgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5 NjAwOiAuIDEwMTY3NzoxMDI4MjUoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRp bWVzdGFtcCAxODQ1MzgxMiAxMjY4OTg2MjMwPiAoREYpIFt0b3MgMHg4XQowMDAwOTcgMTAu NDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMy OTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyMzkgMTg0NTM3OTQ+IChERikgW3RvcyAw eDhdCjAyODQ5MSAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gODQ0 NTc6ODU2MDUoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1 Mzc5MCAxMjY4OTg2MjA4PiAoREYpIFt0b3MgMHg4XQowMDAwODkgMTAuNDIuMi4yMy40OTYw MCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMyOTIgPG5vcCxub3As dGltZXN0YW1wIDEyNjg5ODYyNDIgMTg0NTM3OTQ+IChERikgW3RvcyAweDhdCjAwNjY0OSAx MC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gODY3NTM6ODc5MDEoMTE0 OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc5MSAxMjY4OTg2 MjA5PiAoREYpIFt0b3MgMHg4XQowMDAwODYgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIu MjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEy Njg5ODYyNDIgMTg0NTM3OTQ+IChERikgW3RvcyAweDhdCjAwNjY1MCAxMC40Mi4yLjI1MC40 OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gMjI0NjU6MjM2MTMoMTE0OCkgYWNrIDEgd2lu IDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1Mzc5MyAxMjY4OTg2MjEyPiAoREYpIFt0 b3MgMHg4XQowMDAwODYgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAu IGFjayA2Mzc5MyB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyNDMgMTg0 NTM3OTQ+IChERikgW3RvcyAweDhdCjAwNDgxMyAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQy LjIuMjMuNDk2MDA6IC4gMTAzOTczOjEwNTEyMSgxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5v cCxub3AsdGltZXN0YW1wIDE4NDUzODE3IDEyNjg5ODYyMzU+IChERikgW3RvcyAweDhdCjAw MDA5NiAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDYzNzkz IHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjI0MyAxODQ1Mzc5ND4gKERG KSBbdG9zIDB4OF0KMDAyODg4IDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYw MDogLiA4OTA0OTo5MDE5NygxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0 YW1wIDE4NDUzODA3IDEyNjg5ODYyMjU+IChERikgW3RvcyAweDhdCjAwMDA5NyAxMC40Mi4y LjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDYzNzkzIHdpbiAzMzI5MiA8 bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjI0NCAxODQ1Mzc5ND4gKERGKSBbdG9zIDB4OF0K MDA2NjY2IDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiA5MTM0NTo5 MjQ5MygxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDUzODA4 IDEyNjg5ODYyMjY+IChERikgW3RvcyAweDhdCjAwMDA5NCAxMC40Mi4yLjIzLjQ5NjAwID4g MTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDYzNzkzIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1l c3RhbXAgMTI2ODk4NjI0NCAxODQ1Mzc5ND4gKERGKSBbdG9zIDB4OF0KMDE0ODAwIDEwLjQy LjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiA5MzY0MTo5NDc4OSgxMTQ4KSBh Y2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDUzODA4IDEyNjg5ODYyMjc+ IChERikgW3RvcyAweDhdCjAwMDA5NSAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAu NDkxNjg6IC4gYWNrIDYzNzkzIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4 NjI0NiAxODQ1Mzc5ND4gKERGKSBbdG9zIDB4OF0KMDA1NDc5IDEwLjQyLjIuMjUwLjQ5MTY4 ID4gMTAuNDIuMi4yMy40OTYwMDogLiAxMDYyNjk6MTA3NDE3KDExNDgpIGFjayAxIHdpbiAz MzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM4MTkgMTI2ODk4NjIzNz4gKERGKSBbdG9z IDB4OF0KMDAwMDk1IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBh Y2sgNjM3OTMgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjQ2IDE4NDUz Nzk0PiAoREYpIFt0b3MgMHg4XQowMjUxNDYgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4y LjIzLjQ5NjAwOiAuIDk1OTM3Ojk3MDg1KDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5v cCx0aW1lc3RhbXAgMTg0NTM4MDkgMTI2ODk4NjIyNz4gKERGKSBbdG9zIDB4OF0KMDAwMDk3 IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNjM3OTMgd2lu IDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjQ5IDE4NDUzNzk0PiAoREYpIFt0 b3MgMHg4XQowMjU1MTcgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAu IDEwODU2NToxMDk3MTMoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFt cCAxODQ1MzgyNSAxMjY4OTg2MjQzPiAoREYpIFt0b3MgMHg4XQowMDAwOTkgMTAuNDIuMi4y My40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMyOTIgPG5v cCxub3AsdGltZXN0YW1wIDEyNjg5ODYyNTIgMTg0NTM3OTQ+IChERikgW3RvcyAweDhdCjAw NDg0NCAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gOTgyMzM6OTkz ODEoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1MzgxMCAx MjY4OTg2MjI4PiAoREYpIFt0b3MgMHg4XQowMDAwOTYgMTAuNDIuMi4yMy40OTYwMCA+IDEw LjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0 YW1wIDEyNjg5ODYyNTIgMTg0NTM3OTQ+IChERikgW3RvcyAweDhdCjAwNjY1OCAxMC40Mi4y LjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gMTAwNTI5OjEwMTY3NygxMTQ4KSBh Y2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDUzODEwIDEyNjg5ODYyMjk+ IChERikgW3RvcyAweDhdCjAwMDA5NyAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAu NDkxNjg6IC4gYWNrIDYzNzkzIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4 NjI1MyAxODQ1Mzc5ND4gKERGKSBbdG9zIDB4OF0KMDA2NjM2IDEwLjQyLjIuMjUwLjQ5MTY4 ID4gMTAuNDIuMi4yMy40OTYwMDogLiAxMDI4MjU6MTAzOTczKDExNDgpIGFjayAxIHdpbiAz MzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM4MTUgMTI2ODk4NjIzMz4gKERGKSBbdG9z IDB4OF0KMDAwMDk4IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBh Y2sgNjM3OTMgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjUzIDE4NDUz Nzk0PiAoREYpIFt0b3MgMHg4XQowMzc2MDYgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4y LjIzLjQ5NjAwOiAuIDEwNTEyMToxMDYyNjkoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3As bm9wLHRpbWVzdGFtcCAxODQ1MzgxOCAxMjY4OTg2MjM2PiAoREYpIFt0b3MgMHg4XQowMDAw OTggMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3 aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyNTcgMTg0NTM3OTQ+IChERikg W3RvcyAweDhdCjAwNDIwNSAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6 IC4gMTEwODYxOjExMjAwOSgxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0 YW1wIDE4NDUzODMxIDEyNjg5ODYyNDk+IChERikgW3RvcyAweDhdCjAwMDA5OSAxMC40Mi4y LjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDYzNzkzIHdpbiAzMzI5MiA8 bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjI1OCAxODQ1Mzc5ND4gKERGKSBbdG9zIDB4OF0K MDA2NjIxIDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiAxMDc0MTc6 MTA4NTY1KDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM4 MjEgMTI2ODk4NjIzOT4gKERGKSBbdG9zIDB4OF0KMDAwMDk4IDEwLjQyLjIuMjMuNDk2MDAg PiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNjM3OTMgd2luIDMzMjkyIDxub3Asbm9wLHRp bWVzdGFtcCAxMjY4OTg2MjU4IDE4NDUzNzk0PiAoREYpIFt0b3MgMHg4XQowMDgxMDIgMTAu NDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDEwOTcxMzoxMTA4NjEoMTE0 OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1MzgyNiAxMjY4OTg2 MjQ0PiAoREYpIFt0b3MgMHg4XQowMDAwOTggMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIu MjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEy Njg5ODYyNTkgMTg0NTM3OTQ+IChERikgW3RvcyAweDhdCjAzMzEyNiAxMC40Mi4yLjI1MC40 OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gMTEyMDA5OjExMzE1NygxMTQ4KSBhY2sgMSB3 aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDUzODM1IDEyNjg5ODYyNTM+IChERikg W3RvcyAweDhdCjAwMDA5OSAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6 IC4gYWNrIDYzNzkzIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjI2MiAx ODQ1Mzc5ND4gKERGKSBbdG9zIDB4OF0KMDM3ODYyIDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAu NDIuMi4yMy40OTYwMDogLiAxMTMxNTc6MTE0MzA1KDExNDgpIGFjayAxIHdpbiAzMzI5MiA8 bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTM4MzkgMTI2ODk4NjI1OD4gKERGKSBbdG9zIDB4OF0K MDAwMDk5IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNjM3 OTMgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2MjY2IDE4NDUzNzk0PiAo REYpIFt0b3MgMHg4XQowOTg0ODkgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5 NjAwOiAuIDExNDMwNToxMTU0NTMoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRp bWVzdGFtcCAxODQ1Mzg0OCAxMjY4OTg2MjY2PiAoREYpIFt0b3MgMHg4XQowMDAxMDMgMTAu NDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2Mzc5MyB3aW4gMzMy OTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODYyNzYgMTg0NTM3OTQ+IChERikgW3RvcyAw eDhdCjYwMjExMyAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNjM3 OTM6NjQ5NDEoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1 MzkxMCAxMjY4OTg2Mjc2PiAoREYpIFt0b3MgMHg4XQowMDAxMDkgMTAuNDIuMi4yMy40OTYw MCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2NjA4OSB3aW4gMzIxNDQgPG5vcCxub3As dGltZXN0YW1wIDEyNjg5ODYzMzYgMTg0NTM5MTA+IChERikgW3RvcyAweDhdCjAwMDMxNSAx MC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDY2MDg5IHdpbiAz MzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjMzNiAxODQ1MzkxMD4gKERGKSBbdG9z IDB4OF0KMDg4MjE5IDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiAx MTU0NTM6MTE2NjAxKDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAg MTg0NTM5MTggMTI2ODk4NjMzNj4gKERGKSBbdG9zIDB4OF0KMDAwMTEwIDEwLjQyLjIuMjMu NDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNjYwODkgd2luIDMzMjkyIDxub3As bm9wLHRpbWVzdGFtcCAxMjY4OTg2MzQ1IDE4NDUzOTEwPiAoREYpIFt0b3MgMHg4XQowMDE2 MDMgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDExNjYwMToxMTc3 NDkoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1MzkxOCAx MjY4OTg2MzM2PiAoREYpIFt0b3MgMHg4XQowMDAwOTggMTAuNDIuMi4yMy40OTYwMCA+IDEw LjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA2NjA4OSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0 YW1wIDEyNjg5ODYzNDUgMTg0NTM5MTA+IChERikgW3RvcyAweDhdCjk5MjE4OSAxMC40Mi4y LjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNjYwODk6NjcyMzcoMTE0OCkgYWNr IDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDAxOCAxMjY4OTg2MzQ1PiAo REYpIFt0b3MgMHg4XQowMDAxMzIgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5 MTY4OiAuIGFjayA2ODM4NSB3aW4gMzIxNDQgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODY0 NDUgMTg0NTQwMTg+IChERikgW3RvcyAweDhdCjAwMDMxMyAxMC40Mi4yLjIzLjQ5NjAwID4g MTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDY4Mzg1IHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1l c3RhbXAgMTI2ODk4NjQ0NSAxODQ1NDAxOD4gKERGKSBbdG9zIDB4OF0KMDg1NzExIDEwLjQy LjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiAxMTc3NDk6MTE4ODk3KDExNDgp IGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTQwMjYgMTI2ODk4NjQ0 NT4gKERGKSBbdG9zIDB4OF0KMDAwMTA4IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1 MC40OTE2ODogLiBhY2sgNjgzODUgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4 OTg2NDUzIDE4NDU0MDE4PiAoREYpIFt0b3MgMHg4XQowMzQ0NDYgMTAuNDIuMi4yNTAuNDkx NjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDExODg5NzoxMjAwNDUoMTE0OCkgYWNrIDEgd2lu IDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDAyNiAxMjY4OTg2NDQ1PiAoREYpIFt0 b3MgMHg4XQowMDAxMDEgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAu IGFjayA2ODM4NSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODY0NTcgMTg0 NTQwMTg+IChERikgW3RvcyAweDhdCjk1NjM0MSAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQy LjIuMjMuNDk2MDA6IC4gNjgzODU6Njk1MzMoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3As bm9wLHRpbWVzdGFtcCAxODQ1NDEyNiAxMjY4OTg2NDU3PiAoREYpIFt0b3MgMHg4XQowMDAx MzYgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA3MDY4MSB3 aW4gMzIxNDQgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODY1NTIgMTg0NTQxMjY+IChERikg W3RvcyAweDhdCjAwMDc4MiAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6 IC4gYWNrIDcwNjgxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjU1MiAx ODQ1NDEyNj4gKERGKSBbdG9zIDB4OF0KMDg1NDgzIDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAu NDIuMi4yMy40OTYwMDogLiAxMjExOTM6MTIyMzQxKDExNDgpIGFjayAxIHdpbiAzMzI5MiA8 bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTQxMzQgMTI2ODk4NjU1Mj4gKERGKSBbdG9zIDB4OF0K MDAwMTE0IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNzA2 ODEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NTYxIDE4NDU0MTI2PiAo REYpIFt0b3MgMHg4XQowMDIxNDYgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5 NjAwOiAuIDEyMDA0NToxMjExOTMoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRp bWVzdGFtcCAxODQ1NDEzNCAxMjY4OTg2NTUyPiAoREYpIFt0b3MgMHg4XQowMDAxMDAgMTAu NDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA3MDY4MSB3aW4gMzMy OTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODY1NjEgMTg0NTQxMjY+IChERikgW3RvcyAw eDhdCjEuIDAxNzA1NCAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4g NzA2ODE6NzE4MjkoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAx ODQ1NDIzNCAxMjY4OTg2NTYxPiAoREYpIFt0b3MgMHg4XQowMDAxMTQgMTAuNDIuMi4yMy40 OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA3Mjk3NyB3aW4gMzIxNDQgPG5vcCxu b3AsdGltZXN0YW1wIDEyNjg5ODY2NjMgMTg0NTQyMzQ+IChERikgW3RvcyAweDhdCjAwMDMw NSAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDcyOTc3IHdp biAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjY2MyAxODQ1NDIzND4gKERGKSBb dG9zIDB4OF0KMDg1NjYzIDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDog LiA3Mjk3Nzo3NDEyNSgxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1w IDE4NDU0MjQ1IDEyNjg5ODY2NjM+IChERikgW3RvcyAweDhdCjAwMDEwNiAxMC40Mi4yLjIz LjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDc1MjczIHdpbiAzMjE0NCA8bm9w LG5vcCx0aW1lc3RhbXAgMTI2ODk4NjY3MSAxODQ1NDI0NT4gKERGKSBbdG9zIDB4OF0KMDAw MzE3IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNzUyNzMg d2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NjcyIDE4NDU0MjQ1PiAoREYp IFt0b3MgMHg4XQowMDkxNzIgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAw OiAuIDc0MTI1Ojc1MjczKDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgMTg0NTQyNDUgMTI2ODk4NjY2Mz4gKERGKSBbdG9zIDB4OF0KMDAwMDkzIDEwLjQyLjIu MjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNzUyNzMgd2luIDMzMjkyIDxu b3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NjcyIDE4NDU0MjQ1PiAoREYpIFt0b3MgMHg4XQow NzY0MzEgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDc1MjczOjc2 NDIxKDExNDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTQyNTMg MTI2ODk4NjY3MT4gKERGKSBbdG9zIDB4OF0KMDAwMTA0IDEwLjQyLjIuMjMuNDk2MDAgPiAx MC40Mi4yLjI1MC40OTE2ODogLiBhY2sgNzc1Njkgd2luIDMyMTQ0IDxub3Asbm9wLHRpbWVz dGFtcCAxMjY4OTg2NjgwIDE4NDU0MjUzPiAoREYpIFt0b3MgMHg4XQowMDAzMDIgMTAuNDIu Mi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA3NzU2OSB3aW4gMzMyOTIg PG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODY2ODAgMTg0NTQyNTM+IChERikgW3RvcyAweDhd CjAwMzI1MiAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNzY0MjE6 Nzc1NjkoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDI1 MyAxMjY4OTg2NjcxPiAoREYpIFt0b3MgMHg4XQowMDAwOTIgMTAuNDIuMi4yMy40OTYwMCA+ IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA3NzU2OSB3aW4gMzMyOTIgPG5vcCxub3AsdGlt ZXN0YW1wIDEyNjg5ODY2ODAgMTg0NTQyNTM+IChERikgW3RvcyAweDhdCjAwMjk0MSAxMC40 Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNzc1Njk6Nzg3MTcoMTE0OCkg YWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDI1MyAxMjY4OTg2Njcx PiAoREYpIFt0b3MgMHg4XQowMDAxMDYgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUw LjQ5MTY4OiAuIGFjayA3OTg2NSB3aW4gMzIxNDQgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5 ODY2ODEgMTg0NTQyNTM+IChERikgW3RvcyAweDhdCjAwMDI3NCAxMC40Mi4yLjIzLjQ5NjAw ID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDc5ODY1IHdpbiAzMzI5MiA8bm9wLG5vcCx0 aW1lc3RhbXAgMTI2ODk4NjY4MSAxODQ1NDI1Mz4gKERGKSBbdG9zIDB4OF0KMDc5MzkwIDEw LjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiA3OTg2NTo4MTAxMygxMTQ4 KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDU0MjYyIDEyNjg5ODY2 ODA+IChERikgW3RvcyAweDhdCjAwMDEwNiAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4y NTAuNDkxNjg6IC4gYWNrIDgyMTYxIHdpbiAzMjE0NCA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2 ODk4NjY4OSAxODQ1NDI2Mj4gKERGKSBbdG9zIDB4OF0KMDAwMjc4IDEwLjQyLjIuMjMuNDk2 MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgODIxNjEgd2luIDMzMjkyIDxub3Asbm9w LHRpbWVzdGFtcCAxMjY4OTg2Njg5IDE4NDU0MjYyPiAoREYpIFt0b3MgMHg4XQowMTM2OTQg MTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDgyMTYxOjgzMzA5KDEx NDgpIGFjayAxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTQyNjMgMTI2ODk4 NjY4MT4gKERGKSBbdG9zIDB4OF0KMDAwMTA2IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4y LjI1MC40OTE2ODogLiBhY2sgODQ0NTcgd2luIDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAx MjY4OTg2NjkwIDE4NDU0MjYzPiAoREYpIFt0b3MgMHg4XQowMDAyNzcgMTAuNDIuMi4yMy40 OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA4NDQ1NyB3aW4gMzMyOTIgPG5vcCxu b3AsdGltZXN0YW1wIDEyNjg5ODY2OTAgMTg0NTQyNjM+IChERikgW3RvcyAweDhdCjAyNjUw OSAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gNzg3MTc6Nzk4NjUo MTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDI2MiAxMjY4 OTg2NjgwPiAoREYpIFt0b3MgMHg4XQowMDAwOTAgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQy LjIuMjUwLjQ5MTY4OiAuIGFjayA4NDQ1NyB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1w IDEyNjg5ODY2OTMgMTg0NTQyNjM+IChERikgW3RvcyAweDhdCjAwOTg0NSAxMC40Mi4yLjI1 MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gODEwMTM6ODIxNjEoMTE0OCkgYWNrIDEg d2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDI2MyAxMjY4OTg2NjgxPiAoREYp IFt0b3MgMHg4XQowMDAwOTEgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4 OiAuIGFjayA4NDQ1NyB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODY2OTQg MTg0NTQyNjM+IChERikgW3RvcyAweDhdCjAzNTM1NSAxMC40Mi4yLjI1MC40OTE2OCA+IDEw LjQyLjIuMjMuNDk2MDA6IC4gODQ0NTc6ODU2MDUoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxu b3Asbm9wLHRpbWVzdGFtcCAxODQ1NDI3MSAxMjY4OTg2Njg5PiAoREYpIFt0b3MgMHg4XQow MDAxMDYgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayA4Njc1 MyB3aW4gMzIxNDQgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODY2OTcgMTg0NTQyNzE+IChE RikgW3RvcyAweDhdCjAwMDI3NiAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkx Njg6IC4gYWNrIDg2NzUzIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjY5 NyAxODQ1NDI3MT4gKERGKSBbdG9zIDB4OF0KMDAyNzkzIDEwLjQyLjIuMjUwLjQ5MTY4ID4g MTAuNDIuMi4yMy40OTYwMDogLiA4MzMwOTo4NDQ1NygxMTQ4KSBhY2sgMSB3aW4gMzMyOTIg PG5vcCxub3AsdGltZXN0YW1wIDE4NDU0MjcxIDEyNjg5ODY2ODk+IChERikgW3RvcyAweDhd CjAwMDA5MyAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDg2 NzUzIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjY5OCAxODQ1NDI3MT4g KERGKSBbdG9zIDB4OF0KMDA3NjEyIDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40 OTYwMDogLiA4NTYwNTo4Njc1MygxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGlt ZXN0YW1wIDE4NDU0MjcxIDEyNjg5ODY2ODk+IChERikgW3RvcyAweDhdCjAwMDA5MCAxMC40 Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDg2NzUzIHdpbiAzMzI5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjY5OCAxODQ1NDI3MT4gKERGKSBbdG9zIDB4 OF0KMDAyNzk2IDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40OTYwMDogLiA4Njc1 Mzo4NzkwMSgxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1wIDE4NDU0 MjcyIDEyNjg5ODY2OTA+IChERikgW3RvcyAweDhdCjAwMDIxMCAxMC40Mi4yLjIzLjQ5NjAw ID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDEyMjM0MSB3aW4gMTU0OTggPG5vcCxub3As dGltZXN0YW1wIDEyNjg5ODY2OTkgMTg0NTQyNzI+IChERikgW3RvcyAweDhdCjAwMDQ0MCAx MC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDEyMjM0MSB3aW4g MjM2OTAgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODY2OTkgMTg0NTQyNzI+IChERikgW3Rv cyAweDhdCjAwMTA5MSAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4g YWNrIDEyMjM0MSB3aW4gMzE4ODIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODY2OTkgMTg0 NTQyNzI+IChERikgW3RvcyAweDhdCjAwMDkyNSAxMC40Mi4yLjIzLjQ5NjAwID4gMTAuNDIu Mi4yNTAuNDkxNjg6IC4gYWNrIDEyMjM0MSB3aW4gMzMyOTIgPG5vcCxub3AsdGltZXN0YW1w IDEyNjg5ODY2OTkgMTg0NTQyNzI+IChERikgW3RvcyAweDhdCjAwMTg2MCAxMC40Mi4yLjI1 MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gODc5MDE6ODkwNDkoMTE0OCkgYWNrIDEg d2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDI3MiAxMjY4OTg2NjkwPiAoREYp IFt0b3MgMHg4XQowMDAwOTUgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4 OiAuIGFjayAxMjIzNDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2Njk5 IDE4NDU0MjcyPiAoREYpIFt0b3MgMHg4XQowMDIzOTcgMTAuNDIuMi4yNTAuNDkxNjggPiAx MC40Mi4yLjIzLjQ5NjAwOiAuIDg5MDQ5OjkwMTk3KDExNDgpIGFjayAxIHdpbiAzMzI5MiA8 bm9wLG5vcCx0aW1lc3RhbXAgMTg0NTQyNzIgMTI2ODk4NjY5MD4gKERGKSBbdG9zIDB4OF0K MDAwMDg5IDEwLjQyLjIuMjMuNDk2MDAgPiAxMC40Mi4yLjI1MC40OTE2ODogLiBhY2sgMTIy MzQxIHdpbiAzMzI5MiA8bm9wLG5vcCx0aW1lc3RhbXAgMTI2ODk4NjY5OSAxODQ1NDI3Mj4g KERGKSBbdG9zIDB4OF0KMDY1NTU5IDEwLjQyLjIuMjUwLjQ5MTY4ID4gMTAuNDIuMi4yMy40 OTYwMDogLiA5MTM0NTo5MjQ5MygxMTQ4KSBhY2sgMSB3aW4gMzMyOTIgPG5vcCxub3AsdGlt ZXN0YW1wIDE4NDU0Mjc5IDEyNjg5ODY2OTc+IChERikgW3RvcyAweDhdCjAwMDEwMiAxMC40 Mi4yLjIzLjQ5NjAwID4gMTAuNDIuMi4yNTAuNDkxNjg6IC4gYWNrIDEyMjM0MSB3aW4gMzMy OTIgPG5vcCxub3AsdGltZXN0YW1wIDEyNjg5ODY3MDYgMTg0NTQyNzk+IChERikgW3RvcyAw eDhdCjAwMjA1MyAxMC40Mi4yLjI1MC40OTE2OCA+IDEwLjQyLjIuMjMuNDk2MDA6IC4gOTAx OTc6OTEzNDUoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1 NDI3OSAxMjY4OTg2Njk3PiAoREYpIFt0b3MgMHg4XQowMDAwOTAgMTAuNDIuMi4yMy40OTYw MCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxMjIzNDEgd2luIDMzMjkyIDxub3Asbm9w LHRpbWVzdGFtcCAxMjY4OTg2NzA2IDE4NDU0Mjc5PiAoREYpIFt0b3MgMHg4XQowMTE4MzQg MTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDEyMzQ4OToxMjQ2Mzco MTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDI4MSAxMjY4 OTg2Njk5PiAoREYpIFt0b3MgMHg4XQowMDAwOTQgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQy LjIuMjUwLjQ5MTY4OiAuIGFjayAxMjIzNDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFt cCAxMjY4OTg2NzA3IDE4NDU0Mjc5PiAoREYpIFt0b3MgMHg4XQowMDM4OTkgMTAuNDIuMi4y NTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDEyMjM0MToxMjM0ODkoMTE0OCkgYWNr IDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDI4MSAxMjY4OTg2Njk5PiAo REYpIFt0b3MgMHg4XQowMDAxMDEgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5 MTY4OiAuIGFjayAxMjQ2Mzcgd2luIDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2 NzA4IDE4NDU0MjgxPiAoREYpIFt0b3MgMHg4XQowMDAyNzEgMTAuNDIuMi4yMy40OTYwMCA+ IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxMjQ2Mzcgd2luIDMzMjkyIDxub3Asbm9wLHRp bWVzdGFtcCAxMjY4OTg2NzA4IDE4NDU0MjgxPiAoREYpIFt0b3MgMHg4XQowMDI5OTMgMTAu NDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDEyNTc4NToxMjY5MzMoMTE0 OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDI4MSAxMjY4OTg2 Njk5PiAoREYpIFt0b3MgMHg4XQowMDAwOTggMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIu MjUwLjQ5MTY4OiAuIGFjayAxMjQ2Mzcgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAx MjY4OTg2NzA4IDE4NDU0MjgxPiAoREYpIFt0b3MgMHg4XQowMjcxMTEgMTAuNDIuMi4yNTAu NDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDEyNDYzNzoxMjU3ODUoMTE0OCkgYWNrIDEg d2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDI4MSAxMjY4OTg2Njk5PiAoREYp IFt0b3MgMHg4XQowMDAxMDAgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4 OiAuIGFjayAxMjY5MzMgd2luIDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzEx IDE4NDU0MjgxPiAoREYpIFt0b3MgMHg4XQowMDAyOTAgMTAuNDIuMi4yMy40OTYwMCA+IDEw LjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxMjY5MzMgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVz dGFtcCAxMjY4OTg2NzExIDE4NDU0MjgxPiAoREYpIFt0b3MgMHg4XQowMDYzOTUgMTAuNDIu Mi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDEyNjkzMzoxMjgwODEoMTE0OCkg YWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDI4MSAxMjY4OTg2Njk5 PiAoREYpIFt0b3MgMHg4XQowMzA2MzQgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIz LjQ5NjAwOiAuIDEyMjM0MToxMjM0ODkoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9w LHRpbWVzdGFtcCAxODQ1NDI4OCAxMjY4OTg2NzA2PiAoREYpIFt0b3MgMHg4XQowMDAwOTMg MTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxMjgwODEgd2lu IDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzE1IDE4NDU0Mjg4PiAoREYpIFt0 b3MgMHg4XQowMDU3MjggMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAu IDEyODA4MToxMjkyMjkoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFt cCAxODQ1NDI4OCAxMjY4OTg2NzA2PiAoREYpIFt0b3MgMHg4XQowMDg5MTAgMTAuNDIuMi4y NTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDEyOTIyOToxMzAzNzcoMTE0OCkgYWNr IDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDI4OSAxMjY4OTg2NzA3PiAo REYpIFt0b3MgMHg4XQowMDAwOTIgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5 MTY4OiAuIGFjayAxMzAzNzcgd2luIDMyNzE4IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2 NzE2IDE4NDU0Mjg4PiAoREYpIFt0b3MgMHg4XQowMDY2NDIgMTAuNDIuMi4yNTAuNDkxNjgg PiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDEzMDM3NzoxMzE1MjUoMTE0OCkgYWNrIDEgd2luIDMz MjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDI5MCAxMjY4OTg2NzA4PiAoREYpIFt0b3Mg MHg4XQowMDAxMTkgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFj ayAxMzE1MjUgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzE3IDE4NDU0 MjkwPiAoREYpIFt0b3MgMHg4XQowMzY4MTcgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4y LjIzLjQ5NjAwOiAuIDEzMjY3MzoxMzM4MjEoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3As bm9wLHRpbWVzdGFtcCAxODQ1NDI5MyAxMjY4OTg2NzExPiAoREYpIFt0b3MgMHg4XQowMDAw OTggMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxMzE1MjUg d2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzIwIDE4NDU0MjkwPiAoREYp IFt0b3MgMHg4XQowMDE4MDUgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAw OiAuIDEyNDYzNzoxMjU3ODUoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVz dGFtcCAxODQ1NDI5MCAxMjY4OTg2NzA4PiAoREYpIFt0b3MgMHg4XQowMDAwODkgMTAuNDIu Mi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxMzE1MjUgd2luIDMzMjky IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzIxIDE4NDU0MjkwPiAoREYpIFt0b3MgMHg4 XQowMzE5NTYgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDEzMTUy NToxMzI2NzMoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1 NDI5MyAxMjY4OTg2NzExPiAoREYpIFt0b3MgMHg4XQowMDAxMDIgMTAuNDIuMi4yMy40OTYw MCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxMzM4MjEgd2luIDMyMTQ0IDxub3Asbm9w LHRpbWVzdGFtcCAxMjY4OTg2NzI0IDE4NDU0MjkzPiAoREYpIFt0b3MgMHg4XQowMDAyNjkg MTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxMzM4MjEgd2lu IDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzI0IDE4NDU0MjkzPiAoREYpIFt0 b3MgMHg4XQowMDYzNTggMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAu IDEzMzgyMToxMzQ5NjkoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFt cCAxODQ1NDI5NiAxMjY4OTg2NzE1PiAoREYpIFt0b3MgMHg4XQowMDE3MDUgMTAuNDIuMi4y NTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDEzNDk2OToxMzYxMTcoMTE0OCkgYWNr IDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDI5OCAxMjY4OTg2NzE2PiAo REYpIFt0b3MgMHg4XQowMDAwOTIgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5 MTY4OiAuIGFjayAxMzYxMTcgd2luIDMyNzE4IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2 NzI1IDE4NDU0Mjk2PiAoREYpIFt0b3MgMHg4XQowMDY2NDQgMTAuNDIuMi4yNTAuNDkxNjgg PiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDEzNzI2NToxMzg0MTMoMTE0OCkgYWNrIDEgd2luIDMz MjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDI5OSAxMjY4OTg2NzE3PiAoREYpIFt0b3Mg MHg4XQowMDAwOTUgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFj ayAxMzYxMTcgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzI1IDE4NDU0 Mjk2PiAoREYpIFt0b3MgMHg4XQowMTQwNzggMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4y LjIzLjQ5NjAwOiAuIDEzNjExNzoxMzcyNjUoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3As bm9wLHRpbWVzdGFtcCAxODQ1NDI5OCAxMjY4OTg2NzE2PiAoREYpIFt0b3MgMHg4XQowMDAx MDAgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxMzg0MTMg d2luIDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzI3IDE4NDU0Mjk4PiAoREYp IFt0b3MgMHg4XQowMDAyNzAgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4 OiAuIGFjayAxMzg0MTMgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzI3 IDE4NDU0Mjk4PiAoREYpIFt0b3MgMHg4XQowNTY2NTEgMTAuNDIuMi4yNTAuNDkxNjggPiAx MC40Mi4yLjIzLjQ5NjAwOiAuIDEzOTU2MToxNDA3MDkoMTE0OCkgYWNrIDEgd2luIDMzMjky IDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDMwNiAxMjY4OTg2NzI0PiAoREYpIFt0b3MgMHg4 XQowMDAwOTUgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAx Mzg0MTMgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzMyIDE4NDU0Mjk4 PiAoREYpIFt0b3MgMHg4XQowMDIwNDkgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIz LjQ5NjAwOiAuIDEzODQxMzoxMzk1NjEoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9w LHRpbWVzdGFtcCAxODQ1NDMwNiAxMjY4OTg2NzI0PiAoREYpIFt0b3MgMHg4XQowMDAxMDIg MTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxNDA3MDkgd2lu IDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzMzIDE4NDU0MzA2PiAoREYpIFt0 b3MgMHg4XQowMDAyNzEgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAu IGFjayAxNDA3MDkgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzMzIDE4 NDU0MzA2PiAoREYpIFt0b3MgMHg4XQowMDU3OTYgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40 Mi4yLjIzLjQ5NjAwOiAuIDE0MTg1NzoxNDMwMDUoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxu b3Asbm9wLHRpbWVzdGFtcCAxODQ1NDMwNyAxMjY4OTg2NzI1PiAoREYpIFt0b3MgMHg4XQow MDAwOTYgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxNDA3 MDkgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzMzIDE4NDU0MzA2PiAo REYpIFt0b3MgMHg4XQowMDYwMzggMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5 NjAwOiAuIDE0MDcwOToxNDE4NTcoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRp bWVzdGFtcCAxODQ1NDMwNyAxMjY4OTg2NzI1PiAoREYpIFt0b3MgMHg4XQowMDAxMDQgMTAu NDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxNDMwMDUgd2luIDMy MTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzM0IDE4NDU0MzA3PiAoREYpIFt0b3Mg MHg4XQowMDAyNzYgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFj ayAxNDMwMDUgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzM0IDE4NDU0 MzA3PiAoREYpIFt0b3MgMHg4XQowMTQ0MTkgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4y LjIzLjQ5NjAwOiAuIDE0NDE1MzoxNDUzMDEoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3As bm9wLHRpbWVzdGFtcCAxODQ1NDMwOSAxMjY4OTg2NzI3PiAoREYpIFt0b3MgMHg4XQowMDAw OTUgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxNDMwMDUg d2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzM1IDE4NDU0MzA3PiAoREYp IFt0b3MgMHg4XQowMDk0NTggMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAw OiAuIDE0MzAwNToxNDQxNTMoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVz dGFtcCAxODQ1NDMwOSAxMjY4OTg2NzI3PiAoREYpIFt0b3MgMHg4XQowMDAxMDIgMTAuNDIu Mi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxNDUzMDEgd2luIDMyMTQ0 IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzM2IDE4NDU0MzA5PiAoREYpIFt0b3MgMHg4 XQowMDAyOTUgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAx NDUzMDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzM2IDE4NDU0MzA5 PiAoREYpIFt0b3MgMHg4XQowNTE1NjQgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIz LjQ5NjAwOiAuIDE0NTMwMToxNDY0NDkoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9w LHRpbWVzdGFtcCAxODQ1NDMxNSAxMjY4OTg2NzMzPiAoREYpIFt0b3MgMHg4XQowMDM2OTAg MTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDE0NjQ0OToxNDc1OTco MTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDMxNSAxMjY4 OTg2NzMzPiAoREYpIFt0b3MgMHg4XQowMDAwOTEgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQy LjIuMjUwLjQ5MTY4OiAuIGFjayAxNDc1OTcgd2luIDMyNzE4IDxub3Asbm9wLHRpbWVzdGFt cCAxMjY4OTg2NzQyIDE4NDU0MzE1PiAoREYpIFt0b3MgMHg4XQowMDY4OTcgMTAuNDIuMi4y NTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDE0ODc0NToxNDk4OTMoMTE0OCkgYWNr IDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDMxNiAxMjY4OTg2NzM0PiAo REYpIFt0b3MgMHg4XQowMDAwOTcgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5 MTY4OiAuIGFjayAxNDc1OTcgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2 NzQzIDE4NDU0MzE1PiAoREYpIFt0b3MgMHg4XQowMTcxMTEgMTAuNDIuMi4yNTAuNDkxNjgg PiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDE0NzU5NzoxNDg3NDUoMTE0OCkgYWNrIDEgd2luIDMz MjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDMxNiAxMjY4OTg2NzM0PiAoREYpIFt0b3Mg MHg4XQowMDAxMDQgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFj ayAxNDk4OTMgd2luIDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzQ0IDE4NDU0 MzE2PiAoREYpIFt0b3MgMHg4XQowMDAyNzQgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIu MjUwLjQ5MTY4OiAuIGFjayAxNDk4OTMgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAx MjY4OTg2NzQ0IDE4NDU0MzE2PiAoREYpIFt0b3MgMHg4XQowMDYwNjkgMTAuNDIuMi4yNTAu NDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDE1MTA0MToxNTIxODkoMTE0OCkgYWNrIDEg d2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDMxOCAxMjY4OTg2NzM2PiAoREYp IFt0b3MgMHg4XQowMDAwOTYgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4 OiAuIGFjayAxNDk4OTMgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzQ1 IDE4NDU0MzE2PiAoREYpIFt0b3MgMHg4XQowNDMyNjMgMTAuNDIuMi4yNTAuNDkxNjggPiAx MC40Mi4yLjIzLjQ5NjAwOiAuIDE0OTg5MzoxNTEwNDEoMTE0OCkgYWNrIDEgd2luIDMzMjky IDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDMxOCAxMjY4OTg2NzM2PiAoREYpIFt0b3MgMHg4 XQowMDAxMDEgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAx NTIxODkgd2luIDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzQ5IDE4NDU0MzE4 PiAoREYpIFt0b3MgMHg4XQowMDAyOTQgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUw LjQ5MTY4OiAuIGFjayAxNTIxODkgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4 OTg2NzQ5IDE4NDU0MzE4PiAoREYpIFt0b3MgMHg4XQowMTE5MjEgMTAuNDIuMi4yNTAuNDkx NjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDE1MzMzNzoxNTQ0ODUoMTE0OCkgYWNrIDEgd2lu IDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDMyNCAxMjY4OTg2NzQyPiAoREYpIFt0 b3MgMHg4XQowMDAwOTQgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAu IGFjayAxNTIxODkgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzUxIDE4 NDU0MzE4PiAoREYpIFt0b3MgMHg4XQowMjQ0NDYgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40 Mi4yLjIzLjQ5NjAwOiAuIDE1NTYzMzoxNTY3ODEoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxu b3Asbm9wLHRpbWVzdGFtcCAxODQ1NDMyNiAxMjY4OTg2NzQ0PiAoREYpIFt0b3MgMHg4XQow MDAwOTkgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxNTIx ODkgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzUzIDE4NDU0MzE4PiAo REYpIFt0b3MgMHg4XQowMDY0MjMgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5 NjAwOiAuIDE1MjE4OToxNTMzMzcoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRp bWVzdGFtcCAxODQ1NDMyNCAxMjY4OTg2NzQyPiAoREYpIFt0b3MgMHg4XQowMDAxMDUgMTAu NDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxNTQ0ODUgd2luIDMy MTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzU0IDE4NDU0MzI0PiAoREYpIFt0b3Mg MHg4XQowMDAyNzEgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFj ayAxNTQ0ODUgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzU0IDE4NDU0 MzI0PiAoREYpIFt0b3MgMHg4XQowMzg0ODQgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4y LjIzLjQ5NjAwOiAuIDE1NDQ4NToxNTU2MzMoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3As bm9wLHRpbWVzdGFtcCAxODQ1NDMyNiAxMjY4OTg2NzQ0PiAoREYpIFt0b3MgMHg4XQowMDAx MDcgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxNTY3ODEg d2luIDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzU4IDE4NDU0MzI2PiAoREYp IFt0b3MgMHg4XQowMDA0NzEgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4 OiAuIGFjayAxNTY3ODEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzU4 IDE4NDU0MzI2PiAoREYpIFt0b3MgMHg4XQowMDM1MDQgMTAuNDIuMi4yNTAuNDkxNjggPiAx MC40Mi4yLjIzLjQ5NjAwOiAuIDE1NzkyOToxNTkwNzcoMTE0OCkgYWNrIDEgd2luIDMzMjky IDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDMzMSAxMjY4OTg2NzQ5PiAoREYpIFt0b3MgMHg4 XQowMDAwOTcgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAx NTY3ODEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzU4IDE4NDU0MzI2 PiAoREYpIFt0b3MgMHg4XQowMDI5MzcgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIz LjQ5NjAwOiAuIDE1Njc4MToxNTc5MjkoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9w LHRpbWVzdGFtcCAxODQ1NDMyNiAxMjY4OTg2NzQ0PiAoREYpIFt0b3MgMHg4XQowMDAxMDIg MTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxNTkwNzcgd2lu IDMyMTQ0IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzU4IDE4NDU0MzI2PiAoREYpIFt0 b3MgMHg4XQowMDA1ODYgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAu IGFjayAxNTkwNzcgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzU4IDE4 NDU0MzI2PiAoREYpIFt0b3MgMHg4XQowMjM4NjkgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40 Mi4yLjIzLjQ5NjAwOiAuIDE1OTA3NzoxNjAyMjUoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxu b3Asbm9wLHRpbWVzdGFtcCAxODQ1NDMzMSAxMjY4OTg2NzQ5PiAoREYpIFt0b3MgMHg4XQow MTU1MzAgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDE2MDIyNTox NjEzNzMoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDMz NSAxMjY4OTg2NzU0PiAoREYpIFt0b3MgMHg4XQowMDAwOTQgMTAuNDIuMi4yMy40OTYwMCA+ IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxNjEzNzMgd2luIDMyNzE4IDxub3Asbm9wLHRp bWVzdGFtcCAxMjY4OTg2NzYyIDE4NDU0MzMxPiAoREYpIFt0b3MgMHg4XQowMTc3MTEgMTAu NDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDE2MTM3MzoxNjI1MjEoMTE0 OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDMzNiAxMjY4OTg2 NzU0PiAoREYpIFt0b3MgMHg4XQowMDAxMTcgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIu MjUwLjQ5MTY4OiAuIGFjayAxNjI1MjEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAx MjY4OTg2NzY0IDE4NDU0MzM2PiAoREYpIFt0b3MgMHg4XQowMjEwMjQgMTAuNDIuMi4yNTAu NDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDE2MjUyMToxNjM2NjkoMTE0OCkgYWNrIDEg d2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDMzOSAxMjY4OTg2NzU4PiAoREYp IFt0b3MgMHg4XQowMDQyMjEgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAw OiAuIDE2MzY2OToxNjQ4MTcoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVz dGFtcCAxODQ1NDMzOSAxMjY4OTg2NzU4PiAoREYpIFt0b3MgMHg4XQowMDAwOTEgMTAuNDIu Mi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxNjQ4MTcgd2luIDMyNzE4 IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzY3IDE4NDU0MzM5PiAoREYpIFt0b3MgMHg4 XQowMDI3MTkgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDE2NDgx NzoxNjU5NjUoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1 NDM0MCAxMjY4OTg2NzU4PiAoREYpIFt0b3MgMHg4XQowMDAxMTcgMTAuNDIuMi4yMy40OTYw MCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxNjU5NjUgd2luIDMzMjkyIDxub3Asbm9w LHRpbWVzdGFtcCAxMjY4OTg2NzY3IDE4NDU0MzQwPiAoREYpIFt0b3MgMHg4XQowMDM3Nzcg MTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDE2NTk2NToxNjcxMTMo MTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxODQ1NDM0MCAxMjY4 OTg2NzU4PiAoREYpIFt0b3MgMHg4XQowMzYxMzkgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40 Mi4yLjIzLjQ5NjAwOiAuIDE2NzExMzoxNjgyNjEoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxu b3Asbm9wLHRpbWVzdGFtcCAxODQ1NDM0NCAxMjY4OTg2NzYyPiAoREYpIFt0b3MgMHg4XQow MDAwOTIgMTAuNDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxNjgy NjEgd2luIDMyNzE4IDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzcxIDE4NDU0MzQwPiAo REYpIFt0b3MgMHg4XQowMDI3ODYgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5 NjAwOiAuIDE2ODI2MToxNjk0MDkoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRp bWVzdGFtcCAxODQ1NDM0NCAxMjY4OTg2NzYyPiAoREYpIFt0b3MgMHg4XQowMDAxMTggMTAu NDIuMi4yMy40OTYwMCA+IDEwLjQyLjIuMjUwLjQ5MTY4OiAuIGFjayAxNjk0MDkgd2luIDMz MjkyIDxub3Asbm9wLHRpbWVzdGFtcCAxMjY4OTg2NzcxIDE4NDU0MzQ0PiAoREYpIFt0b3Mg MHg4XQowMTQ3MTMgMTAuNDIuMi4yNTAuNDkxNjggPiAxMC40Mi4yLjIzLjQ5NjAwOiAuIDE2 OTQwOToxNzA1NTcoMTE0OCkgYWNrIDEgd2luIDMzMjkyIDxub3Asbm9wLHRpbWVzdGFtcCAx ODQ1NDM0NiAxMjY4OTg2NzY0PiAoREYpIFt0b3MgMHg4XQoK --------------080708070209020700030803-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 16:49:35 2003 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 1A9D137B401; Fri, 10 Jan 2003 16:49:34 -0800 (PST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD11943E4A; Fri, 10 Jan 2003 16:49:33 -0800 (PST) (envelope-from hsu@FreeBSD.org) Received: from FreeBSD.org ([63.193.112.125]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0H8I00M51YALFG@mta6.snfc21.pbi.net>; Fri, 10 Jan 2003 16:49:33 -0800 (PST) Date: Fri, 10 Jan 2003 16:49:45 -0800 From: Jeffrey Hsu Subject: Re: Why we need SACK In-reply-to: Message from Julian Elischer "of Fri, 10 Jan 2003 16:45:14 PST." <3E1F691A.5060508@vicor.com> To: julian@freebsd.org Cc: net@freebsd.org Message-id: <0H8I00M52YALFG@mta6.snfc21.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 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 It's high up on my list of things to do, after locking up the networking stack, fixing NewReno, and adding hardware TCP segmentation off-loading. Jeffrey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 16:59:42 2003 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 3E98537B401; Fri, 10 Jan 2003 16:59:41 -0800 (PST) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9C9643F18; Fri, 10 Jan 2003 16:59:40 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc51.attbi.com (rwcrmhc51) with ESMTP id <20030111005940051007rhd1e>; Sat, 11 Jan 2003 00:59:40 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA46121; Fri, 10 Jan 2003 16:59:39 -0800 (PST) Date: Fri, 10 Jan 2003 16:59:37 -0800 (PST) From: Julian Elischer To: julian@freebsd.org Cc: net@freebsd.org Subject: Re: Why we need SACK In-Reply-To: <3E1F691A.5060508@vicor.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org SOrry guys I don;t know why this ^$%#^# mail program encodes plain text files as Java.. will resend.. On Fri, 10 Jan 2003, Julian Elischer wrote: > The internet is becoming a rather horrid place for packets sometimes.. > Here's a trace. In this case SACK would have been a true blessing... > > Is there anyone considering looking at the varous SACK implementations > to see if one might be fixed enough to be imported? > > (these were two 4.5 (+-) machines) talking through a vpn that apparently > doesn't conserve packet order. (ipsec)), > Link latency is about 73 mSecs, link bandwidth is about 300kBytes/sec. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 17: 1:31 2003 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 242B637B401 for ; Fri, 10 Jan 2003 17:01:21 -0800 (PST) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A97D743F5F for ; Fri, 10 Jan 2003 17:01:19 -0800 (PST) (envelope-from julian@vicor.com) Received: from vicor.com (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 2A1C059228 for ; Fri, 10 Jan 2003 17:01:19 -0800 (PST) Message-ID: <3E1F6CDF.9080100@vicor.com> Date: Fri, 10 Jan 2003 17:01:19 -0800 From: Julian Elischer Reply-To: julian@freebsd.org Organization: VICOR User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021217 X-Accept-Language: en, hu MIME-Version: 1.0 To: net@freebsd.org Subject: Why we need SACK (resend) Content-Type: multipart/mixed; boundary="------------060902050201000106090205" Sender: owner-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. --------------060902050201000106090205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The internet is becoming a rather horrid place for packets sometimes.. Here's a trace. In this case SACK would have been a true blessing... Is there anyone considering looking at the varous SACK implementations to see if one might be fixed enough to be imported? (these were two 4.5 (+-) machines) talking through a vpn that apparently doesn't conserve packet order. (ipsec)), Link latency is about 73 mSecs, link bandwidth is about 300kBytes/sec. --------------060902050201000106090205 Content-Type: text/plain; name="trace.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="trace.txt" 000296 10.42.2.23.49600 > 10.42.2.250.49168: S 3448056169:3448056169(0) win 65535 (DF) 075265 10.42.2.250.49168 > 10.42.2.23.49600: S 2137989217:2137989217(0) ack 3448056170 win 65535 (DF) 000106 10.42.2.23.49600 > 10.42.2.250.49168: . ack 1 win 33292 (DF) 013586 10.42.2.250.49168 > 10.42.2.23.49600: . 1149:2297(1148) ack 1 win 33292 (DF) [tos 0x8] 000110 10.42.2.23.49600 > 10.42.2.250.49168: . ack 1 win 33292 (DF) [tos 0x8] 001786 10.42.2.250.49168 > 10.42.2.23.49600: . 1:1149(1148) ack 1 win 33292 (DF) [tos 0x8] 000103 10.42.2.23.49600 > 10.42.2.250.49168: . ack 2297 win 32144 (DF) [tos 0x8] 000303 10.42.2.23.49600 > 10.42.2.250.49168: . ack 2297 win 33292 (DF) [tos 0x8] 006451 10.42.2.250.49168 > 10.42.2.23.49600: . 2297:3445(1148) ack 1 win 33292 (DF) [tos 0x8] 002771 10.42.2.250.49168 > 10.42.2.23.49600: P 3445:4097(652) ack 1 win 33292 (DF) [tos 0x8] 000089 10.42.2.23.49600 > 10.42.2.250.49168: . ack 4097 win 32966 (DF) [tos 0x8] 003828 10.42.2.250.49168 > 10.42.2.23.49600: . 4097:5245(1148) ack 1 win 33292 (DF) [tos 0x8] 006492 10.42.2.250.49168 > 10.42.2.23.49600: . 5245:6393(1148) ack 1 win 33292 (DF) [tos 0x8] 000091 10.42.2.23.49600 > 10.42.2.250.49168: . ack 6393 win 32718 (DF) [tos 0x8] 001065 10.42.2.250.49168 > 10.42.2.23.49600: . 6393:7541(1148) ack 1 win 33292 (DF) [tos 0x8] 000122 10.42.2.23.49600 > 10.42.2.250.49168: . ack 7541 win 33292 (DF) [tos 0x8] 006598 10.42.2.250.49168 > 10.42.2.23.49600: . 8689:9837(1148) ack 1 win 33292 (DF) [tos 0x8] 000096 10.42.2.23.49600 > 10.42.2.250.49168: . ack 7541 win 33292 (DF) [tos 0x8] 013018 10.42.2.250.49168 > 10.42.2.23.49600: . 7541:8689(1148) ack 1 win 33292 (DF) [tos 0x8] 000103 10.42.2.23.49600 > 10.42.2.250.49168: . ack 9837 win 32144 (DF) [tos 0x8] 000269 10.42.2.23.49600 > 10.42.2.250.49168: . ack 9837 win 33292 (DF) [tos 0x8] 010170 10.42.2.250.49168 > 10.42.2.23.49600: . 9837:10985(1148) ack 1 win 33292 (DF) [tos 0x8] 006740 10.42.2.250.49168 > 10.42.2.23.49600: . 12133:13281(1148) ack 1 win 33292 (DF) [tos 0x8] 000094 10.42.2.23.49600 > 10.42.2.250.49168: . ack 10985 win 33292 (DF) [tos 0x8] 001083 10.42.2.250.49168 > 10.42.2.23.49600: . 10985:12133(1148) ack 1 win 33292 (DF) [tos 0x8] 000101 10.42.2.23.49600 > 10.42.2.250.49168: . ack 13281 win 32144 (DF) [tos 0x8] 000275 10.42.2.23.49600 > 10.42.2.250.49168: . ack 13281 win 33292 (DF) [tos 0x8] 005189 10.42.2.250.49168 > 10.42.2.23.49600: . 14429:15577(1148) ack 1 win 33292 (DF) [tos 0x8] 000096 10.42.2.23.49600 > 10.42.2.250.49168: . ack 13281 win 33292 (DF) [tos 0x8] 001082 10.42.2.250.49168 > 10.42.2.23.49600: . 13281:14429(1148) ack 1 win 33292 (DF) [tos 0x8] 000100 10.42.2.23.49600 > 10.42.2.250.49168: . ack 15577 win 32144 (DF) [tos 0x8] 000269 10.42.2.23.49600 > 10.42.2.250.49168: . ack 15577 win 33292 (DF) [tos 0x8] 005177 10.42.2.250.49168 > 10.42.2.23.49600: . 16725:17873(1148) ack 1 win 33292 (DF) [tos 0x8] 000094 10.42.2.23.49600 > 10.42.2.250.49168: . ack 15577 win 33292 (DF) [tos 0x8] 005370 10.42.2.250.49168 > 10.42.2.23.49600: . 15577:16725(1148) ack 1 win 33292 (DF) [tos 0x8] 000101 10.42.2.23.49600 > 10.42.2.250.49168: . ack 17873 win 32144 (DF) [tos 0x8] 000308 10.42.2.23.49600 > 10.42.2.250.49168: . ack 17873 win 33292 (DF) [tos 0x8] 001058 10.42.2.250.49168 > 10.42.2.23.49600: . 19021:20169(1148) ack 1 win 33292 (DF) [tos 0x8] 000095 10.42.2.23.49600 > 10.42.2.250.49168: . ack 17873 win 33292 (DF) [tos 0x8] 004970 10.42.2.250.49168 > 10.42.2.23.49600: . 17873:19021(1148) ack 1 win 33292 (DF) [tos 0x8] 000105 10.42.2.23.49600 > 10.42.2.250.49168: . ack 20169 win 32144 (DF) [tos 0x8] 001084 10.42.2.250.49168 > 10.42.2.23.49600: . 21317:22465(1148) ack 1 win 33292 (DF) [tos 0x8] 000092 10.42.2.23.49600 > 10.42.2.250.49168: . ack 20169 win 32144 (DF) [tos 0x8] 000270 10.42.2.23.49600 > 10.42.2.250.49168: . ack 20169 win 33292 (DF) [tos 0x8] 005165 10.42.2.250.49168 > 10.42.2.23.49600: . 20169:21317(1148) ack 1 win 33292 (DF) [tos 0x8] 000135 10.42.2.23.49600 > 10.42.2.250.49168: . ack 22465 win 32144 (DF) [tos 0x8] 001088 10.42.2.250.49168 > 10.42.2.23.49600: . 23613:24761(1148) ack 1 win 33292 (DF) [tos 0x8] 000093 10.42.2.23.49600 > 10.42.2.250.49168: . ack 22465 win 32747 (DF) [tos 0x8] 006676 10.42.2.250.49168 > 10.42.2.23.49600: . 25909:27057(1148) ack 1 win 33292 (DF) [tos 0x8] 000096 10.42.2.23.49600 > 10.42.2.250.49168: . ack 22465 win 33292 (DF) [tos 0x8] 006560 10.42.2.250.49168 > 10.42.2.23.49600: . 28205:29353(1148) ack 1 win 33292 (DF) [tos 0x8] 000092 10.42.2.23.49600 > 10.42.2.250.49168: . ack 22465 win 33292 (DF) [tos 0x8] 006648 10.42.2.250.49168 > 10.42.2.23.49600: . 30501:31649(1148) ack 1 win 33292 (DF) [tos 0x8] 000093 10.42.2.23.49600 > 10.42.2.250.49168: . ack 22465 win 33292 (DF) [tos 0x8] 006668 10.42.2.250.49168 > 10.42.2.23.49600: . 32797:33945(1148) ack 1 win 33292 (DF) [tos 0x8] 000093 10.42.2.23.49600 > 10.42.2.250.49168: . ack 22465 win 33292 (DF) [tos 0x8] 002276 10.42.2.250.49168 > 10.42.2.23.49600: . 22465:23613(1148) ack 1 win 33292 (DF) [tos 0x8] 000102 10.42.2.23.49600 > 10.42.2.250.49168: . ack 24761 win 32144 (DF) [tos 0x8] 000270 10.42.2.23.49600 > 10.42.2.250.49168: . ack 24761 win 33292 (DF) [tos 0x8] 003947 10.42.2.250.49168 > 10.42.2.23.49600: . 35093:36241(1148) ack 1 win 33292 (DF) [tos 0x8] 000096 10.42.2.23.49600 > 10.42.2.250.49168: . ack 24761 win 33292 (DF) [tos 0x8] 006624 10.42.2.250.49168 > 10.42.2.23.49600: . 37389:38537(1148) ack 1 win 33292 (DF) [tos 0x8] 000094 10.42.2.23.49600 > 10.42.2.250.49168: . ack 24761 win 33292 (DF) [tos 0x8] 001082 10.42.2.250.49168 > 10.42.2.23.49600: . 24761:25909(1148) ack 1 win 33292 (DF) [tos 0x8] 000106 10.42.2.23.49600 > 10.42.2.250.49168: . ack 27057 win 32144 (DF) [tos 0x8] 000273 10.42.2.23.49600 > 10.42.2.250.49168: . ack 27057 win 33292 (DF) [tos 0x8] 006169 10.42.2.250.49168 > 10.42.2.23.49600: . 27057:28205(1148) ack 1 win 33292 (DF) [tos 0x8] 000107 10.42.2.23.49600 > 10.42.2.250.49168: . ack 29353 win 32144 (DF) [tos 0x8] 000278 10.42.2.23.49600 > 10.42.2.250.49168: . ack 29353 win 33292 (DF) [tos 0x8] 006385 10.42.2.250.49168 > 10.42.2.23.49600: . 29353:30501(1148) ack 1 win 33292 (DF) [tos 0x8] 000103 10.42.2.23.49600 > 10.42.2.250.49168: . ack 31649 win 32144 (DF) [tos 0x8] 000275 10.42.2.23.49600 > 10.42.2.250.49168: . ack 31649 win 33292 (DF) [tos 0x8] 001122 10.42.2.250.49168 > 10.42.2.23.49600: . 39685:40833(1148) ack 1 win 33292 (DF) [tos 0x8] 000095 10.42.2.23.49600 > 10.42.2.250.49168: . ack 31649 win 33292 (DF) [tos 0x8] 005100 10.42.2.250.49168 > 10.42.2.23.49600: . 31649:32797(1148) ack 1 win 33292 (DF) [tos 0x8] 000103 10.42.2.23.49600 > 10.42.2.250.49168: . ack 33945 win 32144 (DF) [tos 0x8] 000293 10.42.2.23.49600 > 10.42.2.250.49168: . ack 33945 win 33292 (DF) [tos 0x8] 001132 10.42.2.250.49168 > 10.42.2.23.49600: . 41981:43129(1148) ack 1 win 33292 (DF) [tos 0x8] 000096 10.42.2.23.49600 > 10.42.2.250.49168: . ack 33945 win 33292 (DF) [tos 0x8] 006629 10.42.2.250.49168 > 10.42.2.23.49600: . 44277:45425(1148) ack 1 win 33292 (DF) [tos 0x8] 000096 10.42.2.23.49600 > 10.42.2.250.49168: . ack 33945 win 33292 (DF) [tos 0x8] 006646 10.42.2.250.49168 > 10.42.2.23.49600: . 46573:47721(1148) ack 1 win 33292 (DF) [tos 0x8] 000094 10.42.2.23.49600 > 10.42.2.250.49168: . ack 33945 win 33292 (DF) [tos 0x8] 012615 10.42.2.250.49168 > 10.42.2.23.49600: . 48869:50017(1148) ack 1 win 33292 (DF) [tos 0x8] 000095 10.42.2.23.49600 > 10.42.2.250.49168: . ack 33945 win 33292 (DF) [tos 0x8] 002764 10.42.2.250.49168 > 10.42.2.23.49600: . 33945:35093(1148) ack 1 win 33292 (DF) [tos 0x8] 000102 10.42.2.23.49600 > 10.42.2.250.49168: . ack 36241 win 32144 (DF) [tos 0x8] 000268 10.42.2.23.49600 > 10.42.2.250.49168: . ack 36241 win 33292 (DF) [tos 0x8] 003542 10.42.2.250.49168 > 10.42.2.23.49600: . 51165:52313(1148) ack 1 win 33292 (DF) [tos 0x8] 000112 10.42.2.23.49600 > 10.42.2.250.49168: . ack 36241 win 33292 (DF) [tos 0x8] 006554 10.42.2.250.49168 > 10.42.2.23.49600: . 53461:54609(1148) ack 1 win 33292 (DF) [tos 0x8] 000094 10.42.2.23.49600 > 10.42.2.250.49168: . ack 36241 win 33292 (DF) [tos 0x8] 006640 10.42.2.250.49168 > 10.42.2.23.49600: . 55757:56905(1148) ack 1 win 33292 (DF) [tos 0x8] 000094 10.42.2.23.49600 > 10.42.2.250.49168: . ack 36241 win 33292 (DF) [tos 0x8] 006596 10.42.2.250.49168 > 10.42.2.23.49600: . 58053:59201(1148) ack 1 win 33292 (DF) [tos 0x8] 000096 10.42.2.23.49600 > 10.42.2.250.49168: . ack 36241 win 33292 (DF) [tos 0x8] 006516 10.42.2.250.49168 > 10.42.2.23.49600: . 36241:37389(1148) ack 1 win 33292 (DF) [tos 0x8] 000102 10.42.2.23.49600 > 10.42.2.250.49168: . ack 38537 win 32144 (DF) [tos 0x8] 001080 10.42.2.250.49168 > 10.42.2.23.49600: . 60349:61497(1148) ack 1 win 33292 (DF) [tos 0x8] 000094 10.42.2.23.49600 > 10.42.2.250.49168: . ack 38537 win 32144 (DF) [tos 0x8] 000268 10.42.2.23.49600 > 10.42.2.250.49168: . ack 38537 win 33292 (DF) [tos 0x8] 005222 10.42.2.250.49168 > 10.42.2.23.49600: . 38537:39685(1148) ack 1 win 33292 (DF) [tos 0x8] 000103 10.42.2.23.49600 > 10.42.2.250.49168: . ack 40833 win 32144 (DF) [tos 0x8] 001062 10.42.2.250.49168 > 10.42.2.23.49600: . 62645:63793(1148) ack 1 win 33292 (DF) [tos 0x8] 000093 10.42.2.23.49600 > 10.42.2.250.49168: . ack 40833 win 32144 (DF) [tos 0x8] 000296 10.42.2.23.49600 > 10.42.2.250.49168: . ack 40833 win 33292 (DF) [tos 0x8] 005164 10.42.2.250.49168 > 10.42.2.23.49600: . 40833:41981(1148) ack 1 win 33292 (DF) [tos 0x8] 000104 10.42.2.23.49600 > 10.42.2.250.49168: . ack 43129 win 32144 (DF) [tos 0x8] 001061 10.42.2.250.49168 > 10.42.2.23.49600: . 64941:66089(1148) ack 1 win 33292 (DF) [tos 0x8] 000094 10.42.2.23.49600 > 10.42.2.250.49168: . ack 43129 win 32144 (DF) [tos 0x8] 000274 10.42.2.23.49600 > 10.42.2.250.49168: . ack 43129 win 33292 (DF) [tos 0x8] 005206 10.42.2.250.49168 > 10.42.2.23.49600: . 43129:44277(1148) ack 1 win 33292 (DF) [tos 0x8] 000105 10.42.2.23.49600 > 10.42.2.250.49168: . ack 45425 win 32144 (DF) [tos 0x8] 001072 10.42.2.250.49168 > 10.42.2.23.49600: . 67237:68385(1148) ack 1 win 33292 (DF) [tos 0x8] 000094 10.42.2.23.49600 > 10.42.2.250.49168: . ack 45425 win 32144 (DF) [tos 0x8] 000271 10.42.2.23.49600 > 10.42.2.250.49168: . ack 45425 win 33292 (DF) [tos 0x8] 005179 10.42.2.250.49168 > 10.42.2.23.49600: . 45425:46573(1148) ack 1 win 33292 (DF) [tos 0x8] 000104 10.42.2.23.49600 > 10.42.2.250.49168: . ack 47721 win 32144 (DF) [tos 0x8] 000295 10.42.2.23.49600 > 10.42.2.250.49168: . ack 47721 win 33292 (DF) [tos 0x8] 002010 10.42.2.250.49168 > 10.42.2.23.49600: . 69533:70681(1148) ack 1 win 33292 (DF) [tos 0x8] 000097 10.42.2.23.49600 > 10.42.2.250.49168: . ack 47721 win 33292 (DF) [tos 0x8] 004191 10.42.2.250.49168 > 10.42.2.23.49600: . 47721:48869(1148) ack 1 win 33292 (DF) [tos 0x8] 000103 10.42.2.23.49600 > 10.42.2.250.49168: . ack 50017 win 32144 (DF) [tos 0x8] 000271 10.42.2.23.49600 > 10.42.2.250.49168: . ack 50017 win 33292 (DF) [tos 0x8] 002026 10.42.2.250.49168 > 10.42.2.23.49600: . 71829:72977(1148) ack 1 win 33292 (DF) [tos 0x8] 000097 10.42.2.23.49600 > 10.42.2.250.49168: . ack 50017 win 33292 (DF) [tos 0x8] 004247 10.42.2.250.49168 > 10.42.2.23.49600: . 50017:51165(1148) ack 1 win 33292 (DF) [tos 0x8] 000102 10.42.2.23.49600 > 10.42.2.250.49168: . ack 52313 win 32144 (DF) [tos 0x8] 000270 10.42.2.23.49600 > 10.42.2.250.49168: . ack 52313 win 33292 (DF) [tos 0x8] 001983 10.42.2.250.49168 > 10.42.2.23.49600: . 74125:75273(1148) ack 1 win 33292 (DF) [tos 0x8] 000097 10.42.2.23.49600 > 10.42.2.250.49168: . ack 52313 win 33292 (DF) [tos 0x8] 004309 10.42.2.250.49168 > 10.42.2.23.49600: . 52313:53461(1148) ack 1 win 33292 (DF) [tos 0x8] 000103 10.42.2.23.49600 > 10.42.2.250.49168: . ack 54609 win 32144 (DF) [tos 0x8] 000271 10.42.2.23.49600 > 10.42.2.250.49168: . ack 54609 win 33292 (DF) [tos 0x8] 001973 10.42.2.250.49168 > 10.42.2.23.49600: . 76421:77569(1148) ack 1 win 33292 (DF) [tos 0x8] 000096 10.42.2.23.49600 > 10.42.2.250.49168: . ack 54609 win 33292 (DF) [tos 0x8] 004283 10.42.2.250.49168 > 10.42.2.23.49600: . 54609:55757(1148) ack 1 win 33292 (DF) [tos 0x8] 000102 10.42.2.23.49600 > 10.42.2.250.49168: . ack 56905 win 32144 (DF) [tos 0x8] 000300 10.42.2.23.49600 > 10.42.2.250.49168: . ack 56905 win 33292 (DF) [tos 0x8] 002230 10.42.2.250.49168 > 10.42.2.23.49600: . 78717:79865(1148) ack 1 win 33292 (DF) [tos 0x8] 000098 10.42.2.23.49600 > 10.42.2.250.49168: . ack 56905 win 33292 (DF) [tos 0x8] 004022 10.42.2.250.49168 > 10.42.2.23.49600: . 56905:58053(1148) ack 1 win 33292 (DF) [tos 0x8] 000102 10.42.2.23.49600 > 10.42.2.250.49168: . ack 59201 win 32144 (DF) [tos 0x8] 000269 10.42.2.23.49600 > 10.42.2.250.49168: . ack 59201 win 33292 (DF) [tos 0x8] 002206 10.42.2.250.49168 > 10.42.2.23.49600: . 81013:82161(1148) ack 1 win 33292 (DF) [tos 0x8] 000098 10.42.2.23.49600 > 10.42.2.250.49168: . ack 59201 win 33292 (DF) [tos 0x8] 004071 10.42.2.250.49168 > 10.42.2.23.49600: . 59201:60349(1148) ack 1 win 33292 (DF) [tos 0x8] 000102 10.42.2.23.49600 > 10.42.2.250.49168: . ack 61497 win 32144 (DF) [tos 0x8] 000273 10.42.2.23.49600 > 10.42.2.250.49168: . ack 61497 win 33292 (DF) [tos 0x8] 002153 10.42.2.250.49168 > 10.42.2.23.49600: . 83309:84457(1148) ack 1 win 33292 (DF) [tos 0x8] 000095 10.42.2.23.49600 > 10.42.2.250.49168: . ack 61497 win 33292 (DF) [tos 0x8] 004085 10.42.2.250.49168 > 10.42.2.23.49600: . 61497:62645(1148) ack 1 win 33292 (DF) [tos 0x8] 000101 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 32144 (DF) [tos 0x8] 000289 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 002187 10.42.2.250.49168 > 10.42.2.23.49600: . 85605:86753(1148) ack 1 win 33292 (DF) [tos 0x8] 000097 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 006640 10.42.2.250.49168 > 10.42.2.23.49600: . 87901:89049(1148) ack 1 win 33292 (DF) [tos 0x8] 000108 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 006621 10.42.2.250.49168 > 10.42.2.23.49600: . 24761:25909(1148) ack 1 win 33292 (DF) [tos 0x8] 000089 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 014456 10.42.2.250.49168 > 10.42.2.23.49600: . 63793:64941(1148) ack 1 win 33292 (DF) [tos 0x8] 000088 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 006645 10.42.2.250.49168 > 10.42.2.23.49600: . 66089:67237(1148) ack 1 win 33292 (DF) [tos 0x8] 000087 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 006650 10.42.2.250.49168 > 10.42.2.23.49600: . 68385:69533(1148) ack 1 win 33292 (DF) [tos 0x8] 000087 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 012182 10.42.2.250.49168 > 10.42.2.23.49600: . 70681:71829(1148) ack 1 win 33292 (DF) [tos 0x8] 000087 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 002642 10.42.2.250.49168 > 10.42.2.23.49600: . 90197:91345(1148) ack 1 win 33292 (DF) [tos 0x8] 000095 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 003921 10.42.2.250.49168 > 10.42.2.23.49600: . 72977:74125(1148) ack 1 win 33292 (DF) [tos 0x8] 000086 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 002865 10.42.2.250.49168 > 10.42.2.23.49600: . 92493:93641(1148) ack 1 win 33292 (DF) [tos 0x8] 000094 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 007232 10.42.2.250.49168 > 10.42.2.23.49600: . 94789:95937(1148) ack 1 win 33292 (DF) [tos 0x8] 000096 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 004975 10.42.2.250.49168 > 10.42.2.23.49600: . 75273:76421(1148) ack 1 win 33292 (DF) [tos 0x8] 000086 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 001563 10.42.2.250.49168 > 10.42.2.23.49600: . 97085:98233(1148) ack 1 win 33292 (DF) [tos 0x8] 000096 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 005003 10.42.2.250.49168 > 10.42.2.23.49600: . 77569:78717(1148) ack 1 win 33292 (DF) [tos 0x8] 000086 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 001553 10.42.2.250.49168 > 10.42.2.23.49600: . 99381:100529(1148) ack 1 win 33292 (DF) [tos 0x8] 000096 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 006359 10.42.2.250.49168 > 10.42.2.23.49600: . 79865:81013(1148) ack 1 win 33292 (DF) [tos 0x8] 000088 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 006653 10.42.2.250.49168 > 10.42.2.23.49600: . 82161:83309(1148) ack 1 win 33292 (DF) [tos 0x8] 000086 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 001935 10.42.2.250.49168 > 10.42.2.23.49600: . 101677:102825(1148) ack 1 win 33292 (DF) [tos 0x8] 000097 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 028491 10.42.2.250.49168 > 10.42.2.23.49600: . 84457:85605(1148) ack 1 win 33292 (DF) [tos 0x8] 000089 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 006649 10.42.2.250.49168 > 10.42.2.23.49600: . 86753:87901(1148) ack 1 win 33292 (DF) [tos 0x8] 000086 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 006650 10.42.2.250.49168 > 10.42.2.23.49600: . 22465:23613(1148) ack 1 win 33292 (DF) [tos 0x8] 000086 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 004813 10.42.2.250.49168 > 10.42.2.23.49600: . 103973:105121(1148) ack 1 win 33292 (DF) [tos 0x8] 000096 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 002888 10.42.2.250.49168 > 10.42.2.23.49600: . 89049:90197(1148) ack 1 win 33292 (DF) [tos 0x8] 000097 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 006666 10.42.2.250.49168 > 10.42.2.23.49600: . 91345:92493(1148) ack 1 win 33292 (DF) [tos 0x8] 000094 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 014800 10.42.2.250.49168 > 10.42.2.23.49600: . 93641:94789(1148) ack 1 win 33292 (DF) [tos 0x8] 000095 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 005479 10.42.2.250.49168 > 10.42.2.23.49600: . 106269:107417(1148) ack 1 win 33292 (DF) [tos 0x8] 000095 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 025146 10.42.2.250.49168 > 10.42.2.23.49600: . 95937:97085(1148) ack 1 win 33292 (DF) [tos 0x8] 000097 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 025517 10.42.2.250.49168 > 10.42.2.23.49600: . 108565:109713(1148) ack 1 win 33292 (DF) [tos 0x8] 000099 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 004844 10.42.2.250.49168 > 10.42.2.23.49600: . 98233:99381(1148) ack 1 win 33292 (DF) [tos 0x8] 000096 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 006658 10.42.2.250.49168 > 10.42.2.23.49600: . 100529:101677(1148) ack 1 win 33292 (DF) [tos 0x8] 000097 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 006636 10.42.2.250.49168 > 10.42.2.23.49600: . 102825:103973(1148) ack 1 win 33292 (DF) [tos 0x8] 000098 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 037606 10.42.2.250.49168 > 10.42.2.23.49600: . 105121:106269(1148) ack 1 win 33292 (DF) [tos 0x8] 000098 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 004205 10.42.2.250.49168 > 10.42.2.23.49600: . 110861:112009(1148) ack 1 win 33292 (DF) [tos 0x8] 000099 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 006621 10.42.2.250.49168 > 10.42.2.23.49600: . 107417:108565(1148) ack 1 win 33292 (DF) [tos 0x8] 000098 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 008102 10.42.2.250.49168 > 10.42.2.23.49600: . 109713:110861(1148) ack 1 win 33292 (DF) [tos 0x8] 000098 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 033126 10.42.2.250.49168 > 10.42.2.23.49600: . 112009:113157(1148) ack 1 win 33292 (DF) [tos 0x8] 000099 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 037862 10.42.2.250.49168 > 10.42.2.23.49600: . 113157:114305(1148) ack 1 win 33292 (DF) [tos 0x8] 000099 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 098489 10.42.2.250.49168 > 10.42.2.23.49600: . 114305:115453(1148) ack 1 win 33292 (DF) [tos 0x8] 000103 10.42.2.23.49600 > 10.42.2.250.49168: . ack 63793 win 33292 (DF) [tos 0x8] 602113 10.42.2.250.49168 > 10.42.2.23.49600: . 63793:64941(1148) ack 1 win 33292 (DF) [tos 0x8] 000109 10.42.2.23.49600 > 10.42.2.250.49168: . ack 66089 win 32144 (DF) [tos 0x8] 000315 10.42.2.23.49600 > 10.42.2.250.49168: . ack 66089 win 33292 (DF) [tos 0x8] 088219 10.42.2.250.49168 > 10.42.2.23.49600: . 115453:116601(1148) ack 1 win 33292 (DF) [tos 0x8] 000110 10.42.2.23.49600 > 10.42.2.250.49168: . ack 66089 win 33292 (DF) [tos 0x8] 001603 10.42.2.250.49168 > 10.42.2.23.49600: . 116601:117749(1148) ack 1 win 33292 (DF) [tos 0x8] 000098 10.42.2.23.49600 > 10.42.2.250.49168: . ack 66089 win 33292 (DF) [tos 0x8] 992189 10.42.2.250.49168 > 10.42.2.23.49600: . 66089:67237(1148) ack 1 win 33292 (DF) [tos 0x8] 000132 10.42.2.23.49600 > 10.42.2.250.49168: . ack 68385 win 32144 (DF) [tos 0x8] 000313 10.42.2.23.49600 > 10.42.2.250.49168: . ack 68385 win 33292 (DF) [tos 0x8] 085711 10.42.2.250.49168 > 10.42.2.23.49600: . 117749:118897(1148) ack 1 win 33292 (DF) [tos 0x8] 000108 10.42.2.23.49600 > 10.42.2.250.49168: . ack 68385 win 33292 (DF) [tos 0x8] 034446 10.42.2.250.49168 > 10.42.2.23.49600: . 118897:120045(1148) ack 1 win 33292 (DF) [tos 0x8] 000101 10.42.2.23.49600 > 10.42.2.250.49168: . ack 68385 win 33292 (DF) [tos 0x8] 956341 10.42.2.250.49168 > 10.42.2.23.49600: . 68385:69533(1148) ack 1 win 33292 (DF) [tos 0x8] 000136 10.42.2.23.49600 > 10.42.2.250.49168: . ack 70681 win 32144 (DF) [tos 0x8] 000782 10.42.2.23.49600 > 10.42.2.250.49168: . ack 70681 win 33292 (DF) [tos 0x8] 085483 10.42.2.250.49168 > 10.42.2.23.49600: . 121193:122341(1148) ack 1 win 33292 (DF) [tos 0x8] 000114 10.42.2.23.49600 > 10.42.2.250.49168: . ack 70681 win 33292 (DF) [tos 0x8] 002146 10.42.2.250.49168 > 10.42.2.23.49600: . 120045:121193(1148) ack 1 win 33292 (DF) [tos 0x8] 000100 10.42.2.23.49600 > 10.42.2.250.49168: . ack 70681 win 33292 (DF) [tos 0x8] 1. 017054 10.42.2.250.49168 > 10.42.2.23.49600: . 70681:71829(1148) ack 1 win 33292 (DF) [tos 0x8] 000114 10.42.2.23.49600 > 10.42.2.250.49168: . ack 72977 win 32144 (DF) [tos 0x8] 000305 10.42.2.23.49600 > 10.42.2.250.49168: . ack 72977 win 33292 (DF) [tos 0x8] 085663 10.42.2.250.49168 > 10.42.2.23.49600: . 72977:74125(1148) ack 1 win 33292 (DF) [tos 0x8] 000106 10.42.2.23.49600 > 10.42.2.250.49168: . ack 75273 win 32144 (DF) [tos 0x8] 000317 10.42.2.23.49600 > 10.42.2.250.49168: . ack 75273 win 33292 (DF) [tos 0x8] 009172 10.42.2.250.49168 > 10.42.2.23.49600: . 74125:75273(1148) ack 1 win 33292 (DF) [tos 0x8] 000093 10.42.2.23.49600 > 10.42.2.250.49168: . ack 75273 win 33292 (DF) [tos 0x8] 076431 10.42.2.250.49168 > 10.42.2.23.49600: . 75273:76421(1148) ack 1 win 33292 (DF) [tos 0x8] 000104 10.42.2.23.49600 > 10.42.2.250.49168: . ack 77569 win 32144 (DF) [tos 0x8] 000302 10.42.2.23.49600 > 10.42.2.250.49168: . ack 77569 win 33292 (DF) [tos 0x8] 003252 10.42.2.250.49168 > 10.42.2.23.49600: . 76421:77569(1148) ack 1 win 33292 (DF) [tos 0x8] 000092 10.42.2.23.49600 > 10.42.2.250.49168: . ack 77569 win 33292 (DF) [tos 0x8] 002941 10.42.2.250.49168 > 10.42.2.23.49600: . 77569:78717(1148) ack 1 win 33292 (DF) [tos 0x8] 000106 10.42.2.23.49600 > 10.42.2.250.49168: . ack 79865 win 32144 (DF) [tos 0x8] 000274 10.42.2.23.49600 > 10.42.2.250.49168: . ack 79865 win 33292 (DF) [tos 0x8] 079390 10.42.2.250.49168 > 10.42.2.23.49600: . 79865:81013(1148) ack 1 win 33292 (DF) [tos 0x8] 000106 10.42.2.23.49600 > 10.42.2.250.49168: . ack 82161 win 32144 (DF) [tos 0x8] 000278 10.42.2.23.49600 > 10.42.2.250.49168: . ack 82161 win 33292 (DF) [tos 0x8] 013694 10.42.2.250.49168 > 10.42.2.23.49600: . 82161:83309(1148) ack 1 win 33292 (DF) [tos 0x8] 000106 10.42.2.23.49600 > 10.42.2.250.49168: . ack 84457 win 32144 (DF) [tos 0x8] 000277 10.42.2.23.49600 > 10.42.2.250.49168: . ack 84457 win 33292 (DF) [tos 0x8] 026509 10.42.2.250.49168 > 10.42.2.23.49600: . 78717:79865(1148) ack 1 win 33292 (DF) [tos 0x8] 000090 10.42.2.23.49600 > 10.42.2.250.49168: . ack 84457 win 33292 (DF) [tos 0x8] 009845 10.42.2.250.49168 > 10.42.2.23.49600: . 81013:82161(1148) ack 1 win 33292 (DF) [tos 0x8] 000091 10.42.2.23.49600 > 10.42.2.250.49168: . ack 84457 win 33292 (DF) [tos 0x8] 035355 10.42.2.250.49168 > 10.42.2.23.49600: . 84457:85605(1148) ack 1 win 33292 (DF) [tos 0x8] 000106 10.42.2.23.49600 > 10.42.2.250.49168: . ack 86753 win 32144 (DF) [tos 0x8] 000276 10.42.2.23.49600 > 10.42.2.250.49168: . ack 86753 win 33292 (DF) [tos 0x8] 002793 10.42.2.250.49168 > 10.42.2.23.49600: . 83309:84457(1148) ack 1 win 33292 (DF) [tos 0x8] 000093 10.42.2.23.49600 > 10.42.2.250.49168: . ack 86753 win 33292 (DF) [tos 0x8] 007612 10.42.2.250.49168 > 10.42.2.23.49600: . 85605:86753(1148) ack 1 win 33292 (DF) [tos 0x8] 000090 10.42.2.23.49600 > 10.42.2.250.49168: . ack 86753 win 33292 (DF) [tos 0x8] 002796 10.42.2.250.49168 > 10.42.2.23.49600: . 86753:87901(1148) ack 1 win 33292 (DF) [tos 0x8] 000210 10.42.2.23.49600 > 10.42.2.250.49168: . ack 122341 win 15498 (DF) [tos 0x8] 000440 10.42.2.23.49600 > 10.42.2.250.49168: . ack 122341 win 23690 (DF) [tos 0x8] 001091 10.42.2.23.49600 > 10.42.2.250.49168: . ack 122341 win 31882 (DF) [tos 0x8] 000925 10.42.2.23.49600 > 10.42.2.250.49168: . ack 122341 win 33292 (DF) [tos 0x8] 001860 10.42.2.250.49168 > 10.42.2.23.49600: . 87901:89049(1148) ack 1 win 33292 (DF) [tos 0x8] 000095 10.42.2.23.49600 > 10.42.2.250.49168: . ack 122341 win 33292 (DF) [tos 0x8] 002397 10.42.2.250.49168 > 10.42.2.23.49600: . 89049:90197(1148) ack 1 win 33292 (DF) [tos 0x8] 000089 10.42.2.23.49600 > 10.42.2.250.49168: . ack 122341 win 33292 (DF) [tos 0x8] 065559 10.42.2.250.49168 > 10.42.2.23.49600: . 91345:92493(1148) ack 1 win 33292 (DF) [tos 0x8] 000102 10.42.2.23.49600 > 10.42.2.250.49168: . ack 122341 win 33292 (DF) [tos 0x8] 002053 10.42.2.250.49168 > 10.42.2.23.49600: . 90197:91345(1148) ack 1 win 33292 (DF) [tos 0x8] 000090 10.42.2.23.49600 > 10.42.2.250.49168: . ack 122341 win 33292 (DF) [tos 0x8] 011834 10.42.2.250.49168 > 10.42.2.23.49600: . 123489:124637(1148) ack 1 win 33292 (DF) [tos 0x8] 000094 10.42.2.23.49600 > 10.42.2.250.49168: . ack 122341 win 33292 (DF) [tos 0x8] 003899 10.42.2.250.49168 > 10.42.2.23.49600: . 122341:123489(1148) ack 1 win 33292 (DF) [tos 0x8] 000101 10.42.2.23.49600 > 10.42.2.250.49168: . ack 124637 win 32144 (DF) [tos 0x8] 000271 10.42.2.23.49600 > 10.42.2.250.49168: . ack 124637 win 33292 (DF) [tos 0x8] 002993 10.42.2.250.49168 > 10.42.2.23.49600: . 125785:126933(1148) ack 1 win 33292 (DF) [tos 0x8] 000098 10.42.2.23.49600 > 10.42.2.250.49168: . ack 124637 win 33292 (DF) [tos 0x8] 027111 10.42.2.250.49168 > 10.42.2.23.49600: . 124637:125785(1148) ack 1 win 33292 (DF) [tos 0x8] 000100 10.42.2.23.49600 > 10.42.2.250.49168: . ack 126933 win 32144 (DF) [tos 0x8] 000290 10.42.2.23.49600 > 10.42.2.250.49168: . ack 126933 win 33292 (DF) [tos 0x8] 006395 10.42.2.250.49168 > 10.42.2.23.49600: . 126933:128081(1148) ack 1 win 33292 (DF) [tos 0x8] 030634 10.42.2.250.49168 > 10.42.2.23.49600: . 122341:123489(1148) ack 1 win 33292 (DF) [tos 0x8] 000093 10.42.2.23.49600 > 10.42.2.250.49168: . ack 128081 win 33292 (DF) [tos 0x8] 005728 10.42.2.250.49168 > 10.42.2.23.49600: . 128081:129229(1148) ack 1 win 33292 (DF) [tos 0x8] 008910 10.42.2.250.49168 > 10.42.2.23.49600: . 129229:130377(1148) ack 1 win 33292 (DF) [tos 0x8] 000092 10.42.2.23.49600 > 10.42.2.250.49168: . ack 130377 win 32718 (DF) [tos 0x8] 006642 10.42.2.250.49168 > 10.42.2.23.49600: . 130377:131525(1148) ack 1 win 33292 (DF) [tos 0x8] 000119 10.42.2.23.49600 > 10.42.2.250.49168: . ack 131525 win 33292 (DF) [tos 0x8] 036817 10.42.2.250.49168 > 10.42.2.23.49600: . 132673:133821(1148) ack 1 win 33292 (DF) [tos 0x8] 000098 10.42.2.23.49600 > 10.42.2.250.49168: . ack 131525 win 33292 (DF) [tos 0x8] 001805 10.42.2.250.49168 > 10.42.2.23.49600: . 124637:125785(1148) ack 1 win 33292 (DF) [tos 0x8] 000089 10.42.2.23.49600 > 10.42.2.250.49168: . ack 131525 win 33292 (DF) [tos 0x8] 031956 10.42.2.250.49168 > 10.42.2.23.49600: . 131525:132673(1148) ack 1 win 33292 (DF) [tos 0x8] 000102 10.42.2.23.49600 > 10.42.2.250.49168: . ack 133821 win 32144 (DF) [tos 0x8] 000269 10.42.2.23.49600 > 10.42.2.250.49168: . ack 133821 win 33292 (DF) [tos 0x8] 006358 10.42.2.250.49168 > 10.42.2.23.49600: . 133821:134969(1148) ack 1 win 33292 (DF) [tos 0x8] 001705 10.42.2.250.49168 > 10.42.2.23.49600: . 134969:136117(1148) ack 1 win 33292 (DF) [tos 0x8] 000092 10.42.2.23.49600 > 10.42.2.250.49168: . ack 136117 win 32718 (DF) [tos 0x8] 006644 10.42.2.250.49168 > 10.42.2.23.49600: . 137265:138413(1148) ack 1 win 33292 (DF) [tos 0x8] 000095 10.42.2.23.49600 > 10.42.2.250.49168: . ack 136117 win 33292 (DF) [tos 0x8] 014078 10.42.2.250.49168 > 10.42.2.23.49600: . 136117:137265(1148) ack 1 win 33292 (DF) [tos 0x8] 000100 10.42.2.23.49600 > 10.42.2.250.49168: . ack 138413 win 32144 (DF) [tos 0x8] 000270 10.42.2.23.49600 > 10.42.2.250.49168: . ack 138413 win 33292 (DF) [tos 0x8] 056651 10.42.2.250.49168 > 10.42.2.23.49600: . 139561:140709(1148) ack 1 win 33292 (DF) [tos 0x8] 000095 10.42.2.23.49600 > 10.42.2.250.49168: . ack 138413 win 33292 (DF) [tos 0x8] 002049 10.42.2.250.49168 > 10.42.2.23.49600: . 138413:139561(1148) ack 1 win 33292 (DF) [tos 0x8] 000102 10.42.2.23.49600 > 10.42.2.250.49168: . ack 140709 win 32144 (DF) [tos 0x8] 000271 10.42.2.23.49600 > 10.42.2.250.49168: . ack 140709 win 33292 (DF) [tos 0x8] 005796 10.42.2.250.49168 > 10.42.2.23.49600: . 141857:143005(1148) ack 1 win 33292 (DF) [tos 0x8] 000096 10.42.2.23.49600 > 10.42.2.250.49168: . ack 140709 win 33292 (DF) [tos 0x8] 006038 10.42.2.250.49168 > 10.42.2.23.49600: . 140709:141857(1148) ack 1 win 33292 (DF) [tos 0x8] 000104 10.42.2.23.49600 > 10.42.2.250.49168: . ack 143005 win 32144 (DF) [tos 0x8] 000276 10.42.2.23.49600 > 10.42.2.250.49168: . ack 143005 win 33292 (DF) [tos 0x8] 014419 10.42.2.250.49168 > 10.42.2.23.49600: . 144153:145301(1148) ack 1 win 33292 (DF) [tos 0x8] 000095 10.42.2.23.49600 > 10.42.2.250.49168: . ack 143005 win 33292 (DF) [tos 0x8] 009458 10.42.2.250.49168 > 10.42.2.23.49600: . 143005:144153(1148) ack 1 win 33292 (DF) [tos 0x8] 000102 10.42.2.23.49600 > 10.42.2.250.49168: . ack 145301 win 32144 (DF) [tos 0x8] 000295 10.42.2.23.49600 > 10.42.2.250.49168: . ack 145301 win 33292 (DF) [tos 0x8] 051564 10.42.2.250.49168 > 10.42.2.23.49600: . 145301:146449(1148) ack 1 win 33292 (DF) [tos 0x8] 003690 10.42.2.250.49168 > 10.42.2.23.49600: . 146449:147597(1148) ack 1 win 33292 (DF) [tos 0x8] 000091 10.42.2.23.49600 > 10.42.2.250.49168: . ack 147597 win 32718 (DF) [tos 0x8] 006897 10.42.2.250.49168 > 10.42.2.23.49600: . 148745:149893(1148) ack 1 win 33292 (DF) [tos 0x8] 000097 10.42.2.23.49600 > 10.42.2.250.49168: . ack 147597 win 33292 (DF) [tos 0x8] 017111 10.42.2.250.49168 > 10.42.2.23.49600: . 147597:148745(1148) ack 1 win 33292 (DF) [tos 0x8] 000104 10.42.2.23.49600 > 10.42.2.250.49168: . ack 149893 win 32144 (DF) [tos 0x8] 000274 10.42.2.23.49600 > 10.42.2.250.49168: . ack 149893 win 33292 (DF) [tos 0x8] 006069 10.42.2.250.49168 > 10.42.2.23.49600: . 151041:152189(1148) ack 1 win 33292 (DF) [tos 0x8] 000096 10.42.2.23.49600 > 10.42.2.250.49168: . ack 149893 win 33292 (DF) [tos 0x8] 043263 10.42.2.250.49168 > 10.42.2.23.49600: . 149893:151041(1148) ack 1 win 33292 (DF) [tos 0x8] 000101 10.42.2.23.49600 > 10.42.2.250.49168: . ack 152189 win 32144 (DF) [tos 0x8] 000294 10.42.2.23.49600 > 10.42.2.250.49168: . ack 152189 win 33292 (DF) [tos 0x8] 011921 10.42.2.250.49168 > 10.42.2.23.49600: . 153337:154485(1148) ack 1 win 33292 (DF) [tos 0x8] 000094 10.42.2.23.49600 > 10.42.2.250.49168: . ack 152189 win 33292 (DF) [tos 0x8] 024446 10.42.2.250.49168 > 10.42.2.23.49600: . 155633:156781(1148) ack 1 win 33292 (DF) [tos 0x8] 000099 10.42.2.23.49600 > 10.42.2.250.49168: . ack 152189 win 33292 (DF) [tos 0x8] 006423 10.42.2.250.49168 > 10.42.2.23.49600: . 152189:153337(1148) ack 1 win 33292 (DF) [tos 0x8] 000105 10.42.2.23.49600 > 10.42.2.250.49168: . ack 154485 win 32144 (DF) [tos 0x8] 000271 10.42.2.23.49600 > 10.42.2.250.49168: . ack 154485 win 33292 (DF) [tos 0x8] 038484 10.42.2.250.49168 > 10.42.2.23.49600: . 154485:155633(1148) ack 1 win 33292 (DF) [tos 0x8] 000107 10.42.2.23.49600 > 10.42.2.250.49168: . ack 156781 win 32144 (DF) [tos 0x8] 000471 10.42.2.23.49600 > 10.42.2.250.49168: . ack 156781 win 33292 (DF) [tos 0x8] 003504 10.42.2.250.49168 > 10.42.2.23.49600: . 157929:159077(1148) ack 1 win 33292 (DF) [tos 0x8] 000097 10.42.2.23.49600 > 10.42.2.250.49168: . ack 156781 win 33292 (DF) [tos 0x8] 002937 10.42.2.250.49168 > 10.42.2.23.49600: . 156781:157929(1148) ack 1 win 33292 (DF) [tos 0x8] 000102 10.42.2.23.49600 > 10.42.2.250.49168: . ack 159077 win 32144 (DF) [tos 0x8] 000586 10.42.2.23.49600 > 10.42.2.250.49168: . ack 159077 win 33292 (DF) [tos 0x8] 023869 10.42.2.250.49168 > 10.42.2.23.49600: . 159077:160225(1148) ack 1 win 33292 (DF) [tos 0x8] 015530 10.42.2.250.49168 > 10.42.2.23.49600: . 160225:161373(1148) ack 1 win 33292 (DF) [tos 0x8] 000094 10.42.2.23.49600 > 10.42.2.250.49168: . ack 161373 win 32718 (DF) [tos 0x8] 017711 10.42.2.250.49168 > 10.42.2.23.49600: . 161373:162521(1148) ack 1 win 33292 (DF) [tos 0x8] 000117 10.42.2.23.49600 > 10.42.2.250.49168: . ack 162521 win 33292 (DF) [tos 0x8] 021024 10.42.2.250.49168 > 10.42.2.23.49600: . 162521:163669(1148) ack 1 win 33292 (DF) [tos 0x8] 004221 10.42.2.250.49168 > 10.42.2.23.49600: . 163669:164817(1148) ack 1 win 33292 (DF) [tos 0x8] 000091 10.42.2.23.49600 > 10.42.2.250.49168: . ack 164817 win 32718 (DF) [tos 0x8] 002719 10.42.2.250.49168 > 10.42.2.23.49600: . 164817:165965(1148) ack 1 win 33292 (DF) [tos 0x8] 000117 10.42.2.23.49600 > 10.42.2.250.49168: . ack 165965 win 33292 (DF) [tos 0x8] 003777 10.42.2.250.49168 > 10.42.2.23.49600: . 165965:167113(1148) ack 1 win 33292 (DF) [tos 0x8] 036139 10.42.2.250.49168 > 10.42.2.23.49600: . 167113:168261(1148) ack 1 win 33292 (DF) [tos 0x8] 000092 10.42.2.23.49600 > 10.42.2.250.49168: . ack 168261 win 32718 (DF) [tos 0x8] 002786 10.42.2.250.49168 > 10.42.2.23.49600: . 168261:169409(1148) ack 1 win 33292 (DF) [tos 0x8] 000118 10.42.2.23.49600 > 10.42.2.250.49168: . ack 169409 win 33292 (DF) [tos 0x8] 014713 10.42.2.250.49168 > 10.42.2.23.49600: . 169409:170557(1148) ack 1 win 33292 (DF) [tos 0x8] --------------060902050201000106090205-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 20:14:10 2003 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 E28D637B401 for ; Fri, 10 Jan 2003 20:14:08 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D7DE43F3F for ; Fri, 10 Jan 2003 20:14:07 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 65714 invoked from network); 11 Jan 2003 04:27:38 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 11 Jan 2003 04:27:38 -0000 Received: (nullmailer pid 9609 invoked by uid 136); Sat, 11 Jan 2003 04:15:19 -0000 Subject: Re: What is my next step as a script kiddie ? (DDoS) X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20030110133515.Q78856-100000@mail.econolodgetulsa.com> To: Josh Brooks Date: Sat, 11 Jan 2003 07:15:19 +0300 (MSK) From: "."@babolo.ru Cc: Jess Kitchen , freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1042258519.765651.9608.nullmailer@cicuta.babolo.ru> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org IMHO it is almoust impossible to touch properly configured router without open services on it. I have a great experience of wars with above 3000 users of my nets over ethernet. Every my lose was for hardware error of switch or ethernet port or configuration error. Optimize ipfw for speed, do not use it for count - and only mistakes lead to crash. It seems your router is powerful enough for your circumstances Servers are another thing however... :-(( > Ok, understood - but the point is, at some point the attackers are going > to realize that their syn floods are no longer hurting me ... and > regardless of what they conclude from this, what is the standard "next > step" ? If they are just flooders/packeteers, what do they graduate to > when syn floods no longer do the job ? > > thanks! > > On Fri, 10 Jan 2003, Jess Kitchen wrote: > > > On Fri, 10 Jan 2003, Josh Brooks wrote: > > > > > My goal is to protect my FreeBSD firewall. As I mentioned, now that I > > > have closed off everything to the victim except the ports he is actually > > > running services on, everything is great! The firewall is just fine - > > > even during a big syn flood, because it just drops all the packets that > > > aren't going to legitimate ports. > > > > > > So my question is, what will they do next ? When they nmap the victim and > > > they see all the ports are closed, what will they move to then ? > > > > Josh, > > > > If your firewall is correctly dropping packets they won't see closed ports > > at all, unless you are sending tcp resets for everything (which would be > > silly heh) > > > > Have you had a look at man blackhole yet? That usually proves to be quite > > a pain when running generic-ish stuff along the lines of -sS -F or > > whatever. > > > > Cheers, > > J. > > > > -- > > Jess Kitchen > > http://www.burstfire.net/ > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 20:23:16 2003 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 8BCEE37B401 for ; Fri, 10 Jan 2003 20:23:14 -0800 (PST) Received: from mail.econolodgetulsa.com (mail.econolodgetulsa.com [198.78.66.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 183BB43F5F for ; Fri, 10 Jan 2003 20:23:14 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Received: from mail (user@mail [198.78.66.163]) by mail.econolodgetulsa.com (8.12.3/8.12.3) with ESMTP id h0B4HwZb098262; Fri, 10 Jan 2003 20:17:58 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Date: Fri, 10 Jan 2003 20:17:58 -0800 (PST) From: Josh Brooks To: "."@babolo.ru Cc: Jess Kitchen , Subject: Re: What is my next step as a script kiddie ? (DDoS) In-Reply-To: <1042258519.765651.9608.nullmailer@cicuta.babolo.ru> Message-ID: <20030110201640.A78856-100000@mail.econolodgetulsa.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 Well, my "router" is the freebsd machine - celeron 500 and 256 megs. Where would you suggest doing bandwidth counts for all of my IPs if I don't use ipfw count rules at the firewall/router ? And also thank you very much - I am very happy to hear that you think a freebsd firewall/router will not be easy to break if it is not allowing things to ports on the servers behind it that are not valid... On Sat, 11 Jan 2003 .@babolo.ru wrote: > IMHO it is almoust impossible to touch > properly configured router without > open services on it. > > I have a great experience of wars with above > 3000 users of my nets over ethernet. > > Every my lose was for hardware error > of switch or ethernet port > or configuration error. > > Optimize ipfw for speed, do not > use it for count - and only > mistakes lead to crash. > > It seems your router is powerful enough for > your circumstances > > Servers are another thing however... :-(( > > > Ok, understood - but the point is, at some point the attackers are going > > to realize that their syn floods are no longer hurting me ... and > > regardless of what they conclude from this, what is the standard "next > > step" ? If they are just flooders/packeteers, what do they graduate to > > when syn floods no longer do the job ? > > > > thanks! > > > > On Fri, 10 Jan 2003, Jess Kitchen wrote: > > > > > On Fri, 10 Jan 2003, Josh Brooks wrote: > > > > > > > My goal is to protect my FreeBSD firewall. As I mentioned, now that I > > > > have closed off everything to the victim except the ports he is actually > > > > running services on, everything is great! The firewall is just fine - > > > > even during a big syn flood, because it just drops all the packets that > > > > aren't going to legitimate ports. > > > > > > > > So my question is, what will they do next ? When they nmap the victim and > > > > they see all the ports are closed, what will they move to then ? > > > > > > Josh, > > > > > > If your firewall is correctly dropping packets they won't see closed ports > > > at all, unless you are sending tcp resets for everything (which would be > > > silly heh) > > > > > > Have you had a look at man blackhole yet? That usually proves to be quite > > > a pain when running generic-ish stuff along the lines of -sS -F or > > > whatever. > > > > > > Cheers, > > > J. > > > > > > -- > > > Jess Kitchen > > > http://www.burstfire.net/ > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 20:46:15 2003 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 4755937B401 for ; Fri, 10 Jan 2003 20:46:14 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14BF443F3F for ; Fri, 10 Jan 2003 20:46:13 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 4710 invoked from network); 11 Jan 2003 04:59:33 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 11 Jan 2003 04:59:33 -0000 Received: (nullmailer pid 9735 invoked by uid 136); Sat, 11 Jan 2003 04:47:26 -0000 Subject: Re: What is my next step as a script kiddie ? (DDoS) X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20030110201640.A78856-100000@mail.econolodgetulsa.com> To: Josh Brooks Date: Sat, 11 Jan 2003 07:47:26 +0300 (MSK) From: "."@babolo.ru Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1042260446.806267.9734.nullmailer@cicuta.babolo.ru> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Well, my "router" is the freebsd machine - celeron 500 and 256 megs. > > Where would you suggest doing bandwidth counts for all of my IPs if I > don't use ipfw count rules at the firewall/router ? I use argus. It is not so comfortable for traffic accounting. It is used for the second role - traffic auditing too. And see - trafic estimation is not router's job. Use separate server, and remember, that traffic calculation can be huge under attack. > And also thank you very much - I am very happy to hear that you think a > freebsd firewall/router will not be easy to break if it is not allowing > things to ports on the servers behind it that are not valid... Sorry, I know English bad and do not understant your last line above. > On Sat, 11 Jan 2003 .@babolo.ru wrote: > > > IMHO it is almoust impossible to touch > > properly configured router without > > open services on it. .. > > Optimize ipfw for speed, do not > > use it for count - and only > > mistakes lead to crash. > > > > It seems your router is powerful enough for > > your circumstances > > > > Servers are another thing however... :-(( > > > > > Ok, understood - but the point is, at some point the attackers are going > > > to realize that their syn floods are no longer hurting me ... and > > > regardless of what they conclude from this, what is the standard "next > > > step" ? If they are just flooders/packeteers, what do they graduate to > > > when syn floods no longer do the job ? > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 21:31:50 2003 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 61C5637B401 for ; Fri, 10 Jan 2003 21:31:48 -0800 (PST) Received: from mail.econolodgetulsa.com (mail.econolodgetulsa.com [198.78.66.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D02043ED8 for ; Fri, 10 Jan 2003 21:31:48 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Received: from mail (user@mail [198.78.66.163]) by mail.econolodgetulsa.com (8.12.3/8.12.3) with ESMTP id h0B5VfZb024375; Fri, 10 Jan 2003 21:31:41 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Date: Fri, 10 Jan 2003 21:31:41 -0800 (PST) From: Josh Brooks To: "."@babolo.ru Cc: freebsd-net@freebsd.org Subject: Re: What is my next step as a script kiddie ? (DDoS) In-Reply-To: <1042260446.806267.9734.nullmailer@cicuta.babolo.ru> Message-ID: <20030110213122.C78856-100000@mail.econolodgetulsa.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 What would you run on a different server to do traffic estimation ? How would you do such a thing ? thanks. On Sat, 11 Jan 2003 .@babolo.ru wrote: > > Well, my "router" is the freebsd machine - celeron 500 and 256 megs. > > > > Where would you suggest doing bandwidth counts for all of my IPs if I > > don't use ipfw count rules at the firewall/router ? > I use argus. > It is not so comfortable for traffic accounting. > It is used for the second role - traffic auditing too. > > And see - trafic estimation is not router's job. > Use separate server, and remember, that traffic calculation > can be huge under attack. > > > And also thank you very much - I am very happy to hear that you think a > > freebsd firewall/router will not be easy to break if it is not allowing > > things to ports on the servers behind it that are not valid... > Sorry, I know English bad and do not understant > your last line above. > > > On Sat, 11 Jan 2003 .@babolo.ru wrote: > > > > > IMHO it is almoust impossible to touch > > > properly configured router without > > > open services on it. > .. > > > Optimize ipfw for speed, do not > > > use it for count - and only > > > mistakes lead to crash. > > > > > > It seems your router is powerful enough for > > > your circumstances > > > > > > Servers are another thing however... :-(( > > > > > > > Ok, understood - but the point is, at some point the attackers are going > > > > to realize that their syn floods are no longer hurting me ... and > > > > regardless of what they conclude from this, what is the standard "next > > > > step" ? If they are just flooders/packeteers, what do they graduate to > > > > when syn floods no longer do the job ? > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 23:30:52 2003 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 7254237B401 for ; Fri, 10 Jan 2003 23:30:50 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55E3B43E4A for ; Fri, 10 Jan 2003 23:30:49 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 31810 invoked from network); 11 Jan 2003 07:44:10 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 11 Jan 2003 07:44:10 -0000 Received: (nullmailer pid 9989 invoked by uid 136); Sat, 11 Jan 2003 07:32:03 -0000 Subject: Re: What is my next step as a script kiddie ? (DDoS) X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20030110213122.C78856-100000@mail.econolodgetulsa.com> To: Josh Brooks Date: Sat, 11 Jan 2003 10:32:03 +0300 (MSK) From: "."@babolo.ru Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1042270323.565094.9988.nullmailer@cicuta.babolo.ru> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > What would you run on a different server to do traffic estimation ? How > would you do such a thing ? I use argus 1.8 and my package http://free.babolo.ru/src/traf-tools-0.14.tar.gz as part of ISPMS/ISPDB http://free.babolo.ru/ports/ispms/ traf-tools has free license ISPMS/ISPDB - for non-profit or estimation > thanks. > > On Sat, 11 Jan 2003 .@babolo.ru wrote: > > > > Well, my "router" is the freebsd machine - celeron 500 and 256 megs. > > > > > > Where would you suggest doing bandwidth counts for all of my IPs if I > > > don't use ipfw count rules at the firewall/router ? > > I use argus. > > It is not so comfortable for traffic accounting. > > It is used for the second role - traffic auditing too. > > > > And see - trafic estimation is not router's job. > > Use separate server, and remember, that traffic calculation > > can be huge under attack. > > > > > And also thank you very much - I am very happy to hear that you think a > > > freebsd firewall/router will not be easy to break if it is not allowing > > > things to ports on the servers behind it that are not valid... > > Sorry, I know English bad and do not understant > > your last line above. > > > > > On Sat, 11 Jan 2003 .@babolo.ru wrote: > > > > > > > IMHO it is almoust impossible to touch > > > > properly configured router without > > > > open services on it. > > .. > > > > Optimize ipfw for speed, do not > > > > use it for count - and only > > > > mistakes lead to crash. > > > > > > > > It seems your router is powerful enough for > > > > your circumstances > > > > > > > > Servers are another thing however... :-(( > > > > > > > > > Ok, understood - but the point is, at some point the attackers are going > > > > > to realize that their syn floods are no longer hurting me ... and > > > > > regardless of what they conclude from this, what is the standard "next > > > > > step" ? If they are just flooders/packeteers, what do they graduate to > > > > > when syn floods no longer do the job ? > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 10 23:42:59 2003 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 521A437B401 for ; Fri, 10 Jan 2003 23:42:58 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28BEC43F3F for ; Fri, 10 Jan 2003 23:42:57 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 34976 invoked from network); 11 Jan 2003 07:56:18 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 11 Jan 2003 07:56:18 -0000 Received: (nullmailer pid 10037 invoked by uid 136); Sat, 11 Jan 2003 07:44:11 -0000 Subject: Re: What is my next step as a script kiddie ? (DDoS) X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: To: "."@babolo.ru Date: Sat, 11 Jan 2003 10:44:11 +0300 (MSK) From: "."@babolo.ru Cc: Josh Brooks , freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1042271051.934579.10036.nullmailer@cicuta.babolo.ru> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > > What would you run on a different server to do traffic estimation ? How > > would you do such a thing ? > I use argus 1.8 and my package > > http://free.babolo.ru/src/traf-tools-0.14.tar.gz You can use http://free.babolo.ru/src/binfout-0.02.tar.gz for easy and flexible parsing binary output to any text format. For free. Or for man page if you know English well. > as part of ISPMS/ISPDB > > http://free.babolo.ru/ports/ispms/ > > traf-tools has free license > ISPMS/ISPDB - for non-profit or estimation > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 11 14:12:33 2003 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 8926637B401 for ; Sat, 11 Jan 2003 14:12:32 -0800 (PST) Received: from overlord.e-gerbil.net (e-gerbil.net [64.186.142.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC66043ED8 for ; Sat, 11 Jan 2003 14:12:31 -0800 (PST) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (ras@localhost.globali.net [127.0.0.1]) by overlord.e-gerbil.net (8.12.6/8.12.6) with ESMTP id h0BMC7Tg037715; Sat, 11 Jan 2003 17:12:07 -0500 (EST) (envelope-from ras@overlord.e-gerbil.net) Received: (from ras@localhost) by overlord.e-gerbil.net (8.12.6/8.12.6/Submit) id h0BMC6tO037714; Sat, 11 Jan 2003 17:12:06 -0500 (EST) (envelope-from ras) Date: Sat, 11 Jan 2003 17:12:06 -0500 From: Richard A Steenbergen To: "."@babolo.ru Cc: Josh Brooks , Jess Kitchen , freebsd-net@FreeBSD.ORG Subject: Re: What is my next step as a script kiddie ? (DDoS) Message-ID: <20030111221206.GF78231@overlord.e-gerbil.net> References: <20030110133515.Q78856-100000@mail.econolodgetulsa.com> <1042258519.765651.9608.nullmailer@cicuta.babolo.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1042258519.765651.9608.nullmailer@cicuta.babolo.ru> 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 Sat, Jan 11, 2003 at 07:15:19AM +0300, "."@babolo.ru wrote: > IMHO it is almoust impossible to touch > properly configured router without > open services on it. Don't be silly. Routers are fragile little things compared to hosts, with much less CPU and plenty of places to strike. Protecting your network infrastructure is certainly the next place to go after you protect your high-target hosts. For some examples, see http://www.e-gerbil.net/ras/projects/dos/dos.txt -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 11 14:18:50 2003 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 7753537B401 for ; Sat, 11 Jan 2003 14:18:49 -0800 (PST) Received: from overlord.e-gerbil.net (e-gerbil.net [64.186.142.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCE5443F6B for ; Sat, 11 Jan 2003 14:18:48 -0800 (PST) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (ras@localhost.globali.net [127.0.0.1]) by overlord.e-gerbil.net (8.12.6/8.12.6) with ESMTP id h0BMImTg037797; Sat, 11 Jan 2003 17:18:48 -0500 (EST) (envelope-from ras@overlord.e-gerbil.net) Received: (from ras@localhost) by overlord.e-gerbil.net (8.12.6/8.12.6/Submit) id h0BMImHN037796; Sat, 11 Jan 2003 17:18:48 -0500 (EST) (envelope-from ras) Date: Sat, 11 Jan 2003 17:18:48 -0500 From: Richard A Steenbergen To: Josh Brooks Cc: freebsd-net@FreeBSD.ORG Subject: Re: What is my next step as a script kiddie ? (DDoS) Message-ID: <20030111221848.GG78231@overlord.e-gerbil.net> References: <20030109101652.E78856-100000@mail.econolodgetulsa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030109101652.E78856-100000@mail.econolodgetulsa.com> 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, Jan 09, 2003 at 10:21:52AM -0800, Josh Brooks wrote: > > But, I am concerned ... I am concerned that the attacks will simply > change/escalate to something else. > > If I were a script kiddie, and I suddenly saw that all of my garbage > packets to nonexistent ports were suddenly being dropped, and say I nmap'd > the thing and saw that those ports were closed - what would my next step > be ? Prior to this the attacks were very simply a big SYN flood to random > ports on the victim, and because of the RSTs etc., all this traffic to > nonexistent ports flooded the firewall off. > > So what do they do next ? What is the next step ? The next level of > sophistication to get around the measures I have put into place (that have > been very successful - I have an attack ongoing as I write this, and it > isn't hurting me at all) You're very right, thats exactly what they will do. Many frequent DoS victims find it easier to leave open a hole so they can die easily, rather than risk the attacks escalating and taking out other parts of the network or services, other customers, etc. Obviously the next step would be for them to move to SYN flooding only the ports of the service they are trying to kill, rather than random ports (if they were smart or motivated by anything other than "I'll keep changing numbers until they go down again" they would be doing that already). The next step would be ACK floods so you can't even keep already established flows up during the attack (though if its a quick connect/disconnect service like http it wouldn't matter). The next step would be attacking the routers near the victim... Etc etc etc. But I think you're now going outside the scope and expertise of this mailing list. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 11 14:40:44 2003 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 CBCC837B401 for ; Sat, 11 Jan 2003 14:40:43 -0800 (PST) Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99E6B43F6B for ; Sat, 11 Jan 2003 14:40:40 -0800 (PST) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-b038.otenet.gr [195.167.121.166]) by mailsrv.otenet.gr (8.12.6/8.12.6) with ESMTP id h0BMeQMZ016757; Sun, 12 Jan 2003 00:40:28 +0200 (EET) Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.12.6/8.12.6) with ESMTP id h0BMePnB000959; Sun, 12 Jan 2003 00:40:25 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.12.6/8.12.6/Submit) id h0BMePvU000958; Sun, 12 Jan 2003 00:40:25 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 12 Jan 2003 00:40:25 +0200 From: Giorgos Keramidas To: Josh Brooks Cc: Jess Kitchen , freebsd-net@FreeBSD.ORG Subject: Re: What is my next step as a script kiddie ? (DDoS) Message-ID: <20030111224025.GA915@gothmog.gr> References: <20030110175022.B42178-100000@platinum.burstfire.net> <20030110133515.Q78856-100000@mail.econolodgetulsa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030110133515.Q78856-100000@mail.econolodgetulsa.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 On 2003-01-10 13:36, user@mail.econolodgetulsa.com (Josh Brooks) wrote: > Ok, understood - but the point is, at some point the attackers are > going to realize that their syn floods are no longer hurting me ... > and regardless of what they conclude from this, what is the standard > "next step" ? If they are just flooders/packeteers, what do they > graduate to when syn floods no longer do the job ? They'll probably try icmp floods, or floods that will forcee your server to generate a lot of RST responses. You can safely handle a lot of icmp traffic by ignoring those icmp packets that are not useful to you or mandatory according to one of the router requirements RFCs. The rate limiting features of RESTRICT_RST will handle the rest nicely, imho. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 11 15:12:37 2003 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 C88B037B401 for ; Sat, 11 Jan 2003 15:12:35 -0800 (PST) Received: from mail.econolodgetulsa.com (mail.econolodgetulsa.com [198.78.66.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33CF443F18 for ; Sat, 11 Jan 2003 15:12:35 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Received: from mail (user@mail [198.78.66.163]) by mail.econolodgetulsa.com (8.12.3/8.12.3) with ESMTP id h0BNBWZb069770; Sat, 11 Jan 2003 15:11:32 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Date: Sat, 11 Jan 2003 15:11:32 -0800 (PST) From: Josh Brooks To: Richard A Steenbergen Cc: freebsd-net@FreeBSD.ORG Subject: Re: What is my next step as a script kiddie ? (DDoS) In-Reply-To: <20030111221848.GG78231@overlord.e-gerbil.net> Message-ID: <20030111150725.E78856-100000@mail.econolodgetulsa.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 Thanks for your help - two last questions regarding this: 1. On a FreeBSD router/firewall, does it take more processing power to respond to (and reset) a SYN to a target IP:port that is nonexistent than it does to respond to a target IP:port that is in heavy use ? that is, is there some caching mechanism in use that makes incoming DoS packets to _already busy_ IP:ports "cost less" in terms of processor than SYN packets to IP:ports that don't exist ? Just curious. 2. If this is getting beyond the scope of this list, what list should I move to ? I have been reading through NANOG archives, and any DoS discussion there just seems to degenerate into "it is/is not your fault since you run IRC, which is/is not a legitimate service" thanks - and thanks for the pointer to your document which I am reading and re-reading. On Sat, 11 Jan 2003, Richard A Steenbergen wrote: > On Thu, Jan 09, 2003 at 10:21:52AM -0800, Josh Brooks wrote: > > > > But, I am concerned ... I am concerned that the attacks will simply > > change/escalate to something else. > > > > If I were a script kiddie, and I suddenly saw that all of my garbage > > packets to nonexistent ports were suddenly being dropped, and say I nmap'd > > the thing and saw that those ports were closed - what would my next step > > be ? Prior to this the attacks were very simply a big SYN flood to random > > ports on the victim, and because of the RSTs etc., all this traffic to > > nonexistent ports flooded the firewall off. > > > > So what do they do next ? What is the next step ? The next level of > > sophistication to get around the measures I have put into place (that have > > been very successful - I have an attack ongoing as I write this, and it > > isn't hurting me at all) > > You're very right, thats exactly what they will do. Many frequent DoS > victims find it easier to leave open a hole so they can die easily, rather > than risk the attacks escalating and taking out other parts of the network > or services, other customers, etc. > > Obviously the next step would be for them to move to SYN flooding only the > ports of the service they are trying to kill, rather than random ports (if > they were smart or motivated by anything other than "I'll keep changing > numbers until they go down again" they would be doing that already). The > next step would be ACK floods so you can't even keep already established > flows up during the attack (though if its a quick connect/disconnect > service like http it wouldn't matter). The next step would be attacking > the routers near the victim... Etc etc etc. > > But I think you're now going outside the scope and expertise of this > mailing list. :) > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 11 16:32: 6 2003 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 0DCAD37B4D5 for ; Sat, 11 Jan 2003 16:32:04 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88EDF43F1E for ; Sat, 11 Jan 2003 16:32:02 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 51976 invoked from network); 12 Jan 2003 00:45:25 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 12 Jan 2003 00:45:25 -0000 Received: (nullmailer pid 69021 invoked by uid 136); Sun, 12 Jan 2003 00:33:16 -0000 Subject: Re: What is my next step as a script kiddie ? (DDoS) X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20030111221206.GF78231@overlord.e-gerbil.net> To: Richard A Steenbergen Date: Sun, 12 Jan 2003 03:33:16 +0300 (MSK) From: "."@babolo.ru Cc: "."@babolo.ru, Josh Brooks , Jess Kitchen , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1042331596.782866.69020.nullmailer@cicuta.babolo.ru> Sender: owner-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, Jan 11, 2003 at 07:15:19AM +0300, "."@babolo.ru wrote: > > IMHO it is almoust impossible to touch > > properly configured router without > > open services on it. > > Don't be silly. Routers are fragile little things compared to hosts, with be correct... please > much less CPU and plenty of places to strike. Protecting your network > infrastructure is certainly the next place to go after you protect your > high-target hosts. > > For some examples, see http://www.e-gerbil.net/ras/projects/dos/dos.txt remember disposition: small net(s) connected via low band (less then 10M) link to one upstream. _If_ such a router configured correctly (no services, static only routes, closed enough efficiency optimized ipfw) then it is brobably unkillable, if source of attack in not directly connected. Unfortunately I know method to disable some directly connected ethernet ports on FreeBSD based router. Thank you for the link, it brings up some interesting idea for my student's work. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 11 16:37:56 2003 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 3DBE037B401 for ; Sat, 11 Jan 2003 16:37:55 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EECD43F1E for ; Sat, 11 Jan 2003 16:37:54 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 59377 invoked from network); 12 Jan 2003 00:51:18 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 12 Jan 2003 00:51:18 -0000 Received: (nullmailer pid 69035 invoked by uid 136); Sun, 12 Jan 2003 00:39:09 -0000 Subject: Re: What is my next step as a script kiddie ? (DDoS) X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20030111221848.GG78231@overlord.e-gerbil.net> To: Richard A Steenbergen Date: Sun, 12 Jan 2003 03:39:09 +0300 (MSK) From: "."@babolo.ru Cc: Josh Brooks , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1042331949.784310.69034.nullmailer@cicuta.babolo.ru> Sender: owner-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, Jan 09, 2003 at 10:21:52AM -0800, Josh Brooks wrote: > > > > But, I am concerned ... I am concerned that the attacks will simply > > change/escalate to something else. > > > > If I were a script kiddie, and I suddenly saw that all of my garbage > > packets to nonexistent ports were suddenly being dropped, and say I nmap'd > > the thing and saw that those ports were closed - what would my next step > > be ? Prior to this the attacks were very simply a big SYN flood to random > > ports on the victim, and because of the RSTs etc., all this traffic to > > nonexistent ports flooded the firewall off. > > > > So what do they do next ? What is the next step ? The next level of > > sophistication to get around the measures I have put into place (that have > > been very successful - I have an attack ongoing as I write this, and it > > isn't hurting me at all) > > You're very right, thats exactly what they will do. Many frequent DoS > victims find it easier to leave open a hole so they can die easily, rather > than risk the attacks escalating and taking out other parts of the network > or services, other customers, etc. > > Obviously the next step would be for them to move to SYN flooding only the > ports of the service they are trying to kill, rather than random ports (if > they were smart or motivated by anything other than "I'll keep changing > numbers until they go down again" they would be doing that already). The > next step would be ACK floods so you can't even keep already established > flows up during the attack (though if its a quick connect/disconnect > service like http it wouldn't matter). The next step would be attacking > the routers near the victim... Etc etc etc. Don't panic. This is headache of his upstrim provider or his client under attack. His goal - as stated in question - to protect router - is solveable But you are right - global problem is not solveable that easy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 11 16:40:59 2003 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 4F62037B401 for ; Sat, 11 Jan 2003 16:40:58 -0800 (PST) Received: from mail.econolodgetulsa.com (mail.econolodgetulsa.com [198.78.66.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0127043ED8 for ; Sat, 11 Jan 2003 16:40:58 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Received: from mail (user@mail [198.78.66.163]) by mail.econolodgetulsa.com (8.12.3/8.12.3) with ESMTP id h0C0erZb002662 for ; Sat, 11 Jan 2003 16:40:53 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Date: Sat, 11 Jan 2003 16:40:53 -0800 (PST) From: Josh Brooks To: freebsd-net@freebsd.org Subject: ipfw rules - SYN w/o MSS, and ACK with 0 sequence number Message-ID: <20030111163433.S78856-100000@mail.econolodgetulsa.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 Hi, After reading some more documents on DoS attacks (namely http://www.e-gerbil.net/ras/projects/dos/dos.txt ) I have found that there are two nice mechanisms to thwart a large number of ack and syn floods. First, it turns out (from the paper I mention above) that most of the SYN flood tools out there send the SYNs with no MSS. Second, it turns out that the default stream.c has ACK numbers of zero on every packet. So although I realize that since ipfw is stateless I cannot put in the _real_ fix (with ipfilter): -- start rule set -- block in quick proto tcp from any to any head 100 pass in quick proto tcp from any to any flags S keep state group 100 pass in all -- end rule set -- BUT, if I am willing to give up all of my packets with an ACK of zero (even legitimate ones) I could then block the default behavior of stream.c, right ? --------- So ... does anyone have ipfw syntax for the above two scenarios ? AND, am I correct, or will I introduce unexpected trouble by placing them in my ipfw ruleset ? As far as I understand it to this point, if I were to place these two rules in place _not only_ would I receive a great degree of protection from ack and syn floods, but further the only possible downside is that I might drop a legitimate ack=0 packet once in a while. COmments ? thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 11 16:53:47 2003 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 AD63937B401 for ; Sat, 11 Jan 2003 16:53:46 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EAAB43EB2 for ; Sat, 11 Jan 2003 16:53:45 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 66702 invoked from network); 12 Jan 2003 01:07:09 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 12 Jan 2003 01:07:09 -0000 Received: (nullmailer pid 69074 invoked by uid 136); Sun, 12 Jan 2003 00:55:01 -0000 Subject: Re: What is my next step as a script kiddie ? (DDoS) X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20030111150725.E78856-100000@mail.econolodgetulsa.com> To: Josh Brooks Date: Sun, 12 Jan 2003 03:55:01 +0300 (MSK) From: "."@babolo.ru Cc: Richard A Steenbergen , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1042332901.347040.69073.nullmailer@cicuta.babolo.ru> Sender: owner-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 your help - two last questions regarding this: > > 1. On a FreeBSD router/firewall, does it take more processing power to > respond to (and reset) a SYN to a target IP:port that is nonexistent than > it does to respond to a target IP:port that is in heavy use ? > > that is, is there some caching mechanism in use that makes incoming DoS > packets to _already busy_ IP:ports "cost less" in terms of processor than > SYN packets to IP:ports that don't exist ? Just curious. I think (when looking for my routers) that exact ipfw rules have much more influence on CPU usage. But _why_ ever your router responds? Just drop everything come to router with dst == any of router IP exept some ICMP. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 11 17: 7: 2 2003 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 29E2937B401 for ; Sat, 11 Jan 2003 17:07:01 -0800 (PST) Received: from out6.mx.nwbl.wi.voyager.net (out6.mx.nwbl.wi.voyager.net [169.207.3.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id A240D43F5B for ; Sat, 11 Jan 2003 17:07:00 -0800 (PST) (envelope-from silby@silby.com) Received: from [10.1.1.6] (d20.as21.nwbl0.wi.voyager.net [169.207.138.148]) by out6.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id B0C89DA8E4; Sat, 11 Jan 2003 19:06:58 -0600 (CST) Date: Sat, 11 Jan 2003 19:14:30 -0600 (CST) From: Mike Silbersack To: Josh Brooks Cc: Richard A Steenbergen , "" Subject: Re: What is my next step as a script kiddie ? (DDoS) In-Reply-To: <20030111150725.E78856-100000@mail.econolodgetulsa.com> Message-ID: <20030111191108.L19841-100000@patrocles.silby.com> References: <20030111150725.E78856-100000@mail.econolodgetulsa.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, 11 Jan 2003, Josh Brooks wrote: > Thanks for your help - two last questions regarding this: > > 1. On a FreeBSD router/firewall, does it take more processing power to > respond to (and reset) a SYN to a target IP:port that is nonexistent than > it does to respond to a target IP:port that is in heavy use ? > > that is, is there some caching mechanism in use that makes incoming DoS > packets to _already busy_ IP:ports "cost less" in terms of processor than > SYN packets to IP:ports that don't exist ? Just curious. Handling random packets to unused ports is far easier for the computer to handle. By default the first 200 or so are responded to, and the rest are just ignored. On the other hand, a SYN flood targetting an active port is another story. The host must assume that all incoming packets are legitimate, and can't just throw some away. You're going to need to do more reading. Serious attackers are already 5 miles ahead of you. No, I'm not going to say how, I don't want to give the script kiddies ideas about FreeBSD's weaknesses. :) 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 Jan 11 17:45:10 2003 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 D14CD37B401 for ; Sat, 11 Jan 2003 17:45:09 -0800 (PST) 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 0923E43F5B for ; Sat, 11 Jan 2003 17:45:09 -0800 (PST) (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 RAA99221; Sat, 11 Jan 2003 17:39:01 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id h0C1cfHg030936; Sat, 11 Jan 2003 17:38:42 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id h0C1cfSw030935; Sat, 11 Jan 2003 17:38:41 -0800 (PST) From: Archie Cobbs Message-Id: <200301120138.h0C1cfSw030935@arch20m.dellroad.org> Subject: Re: PPTP tunneling over PPPoE link In-Reply-To: <4.3.2.7.2.20030109191546.02975920@localhost> To: Brett Glass Date: Sat, 11 Jan 2003 17:38:41 -0800 (PST) Cc: Julian Elischer , freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL99b (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 Brett Glass wrote: > >mpd can do both pppoe and pptp. > > I've tried mpd, and its PPTP seems to be incompatible with > XP and with some Macs. (It doesn't die completely, but runs > at a crawl.) If it worked (and if the scripting language > were more robust) I'd switch to it in a second! That bug has been fixed, in sys/netgraph/ng_pptpgre.c revisions 1.26 and 1.2.2.13. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_pptpgre.c -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 Jan 11 19:35:16 2003 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 209C937B401 for ; Sat, 11 Jan 2003 19:35:15 -0800 (PST) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D28D43F3F for ; Sat, 11 Jan 2003 19:35:14 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id UAA12105; Sat, 11 Jan 2003 20:34:57 -0700 (MST) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030111202854.0278c4a0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 11 Jan 2003 20:34:42 -0700 To: Archie Cobbs From: Brett Glass Subject: Re: PPTP tunneling over PPPoE link Cc: Julian Elischer , freebsd-net@FreeBSD.org In-Reply-To: <200301120138.h0C1cfSw030935@arch20m.dellroad.org> References: <4.3.2.7.2.20030109191546.02975920@localhost> 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 At 06:38 PM 1/11/2003, Archie Cobbs wrote: >That bug has been fixed, in sys/netgraph/ng_pptpgre.c revisions >1.26 and 1.2.2.13. Excellent! In that case, the only other thing I need to be able to use it just about everywhere is to be able to trigger shell commands at various points in the scripts, and get output back into variables. (Right now, the scripting language really doesn't have variables and doesn't seem to be able to access environment variables.) The reason I need this is that some of my systems do account timing and expiration. I need to be able to determine when an account expires and to let the system know that a user has logged on and logged off. (I can hack this with the !fg and !bg commands in userland PPP, but can't do it with mpd.) --Brett P.S. -- I'm still wondering why userland PPP doesn't seem to pass GRE. Surely I'm not the first person to run into this? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message