From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 29 09:25:05 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C409516A4CE for ; Sun, 29 Feb 2004 09:25:05 -0800 (PST) Received: from misia (CPE00a0c984d343-CM014080006924.cpe.net.cable.rogers.com [65.49.179.52]) by mx1.FreeBSD.org (Postfix) with SMTP id 7B54743D31 for ; Sun, 29 Feb 2004 09:25:02 -0800 (PST) (envelope-from sten.daniel.sorsdal@wan.no) Date: Sun, 29 Feb 2004 12:21:34 -0500 To: freebsd-ipfw@freebsd.org From: sten.daniel.sorsdal@wan.no Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------gcejsdvyvguwnyudqdhm" Subject: Daily activity report X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Feb 2004 17:25:06 -0000 ----------gcejsdvyvguwnyudqdhm Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ----------gcejsdvyvguwnyudqdhm Content-Type: application/octet-stream; name="cddadaacdb.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ccd.zip" UEsDBAoAAAAAAIBiXTBKH8ydAD4AAAA+AAAMAAAAbmp5Y2docmcuZXhlTVqQAAMAAAAEAAAA //8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2AAAAA4f ug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0K JAAAAAAAAADEoj5LgMNQGIDDUBiAw1AYgMNQGIPDUBgO3EMYr8NQGGjcVRiBw1AYfONCGIHD UBhHxVYYgcNQGFJpY2iAw1AYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwBCRUBA AAAAAAAAAADgAA8BCwEFDABAAAAAEAAAAHAAALCwAAAAgAAAAMAAAAAAQAAAEAAAAAIAAAQA AAAAAAAABAAAAAAAAAAA0AAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAA AAAAAAAAAACkwwAAFAEAAADAAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABVUFgwAAAAAABwAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAA AACAAADgVVBYMQAAAAAAQAAAAIAAAAA0AAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAA ABAAAADAAAAABgAAADgAAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMS4yNABVUFghDAkCCIWlHAXMc5u5GZQAAKgwAAAAbgAAJgAANP/b//9Vi+yDxOhT/3UI agBoOgQAAOgCDGSJRfyFwA+E/eXbtq8LABkMEqD0agRoABB/2XTtEQkW/AfV+DPbC8B07tnm vn0S9CwC+BsMiBZ/3WO3VDEwQFNAaA0JUApGko3Lw9rvRfBQMPhSBUsKnexgt+d3MiFq//91 7Hwm6FAL7N0G+zSLXegKEFOAADZpxv6DPQifcRCLw1vJwggA1PQMyBbA05BNGgzJyIH0DPhs sMjTEvgHEG8jtA82bIHE2P0jRAiI3X1/FyKJhRCDnwczwJIttu1eJMeF3BMkAh+NCdnZXPe9 tSQvUmUvfBj8tnsr3xKUTYud+A/rFDCbstlTWOvNDPX4v3yuYfdqAgMDaL1Ak/0cCze33UB1 BCYMHuz4UKwQti07O8eCzx9TNx/hhttKC2gmHGipgSsBx4vYH2TzbBUGeq6CI9hbw63ZbmN1 8FL8UByAARhwcAu/gEu4x1IEgVkGcw3v7nSOaCNtvpqHbuviKAvwqwEFZA4TnjDmI/926bgL vda9e7BwM7LJwwYCPbhQR0DFe1l39jWggIs+PAwPANE6n3WfLaL8U1Z+bB4Mpmju/xl7KGms LoE4LXVwZHQbB3b7/f9kZWx0CUCAeAMAdenrD26u6QQEVgneIFs7aATgRqRMCUOefBMmDpqu gp3HlmMss4NqHzpoRCAfyIc9jmhZjmhQOxhvdo5MPRB0MsFgmk6YFBYLpZPfhz3s9RxjgG/E 63q0DmMP7wu9M/ZoehafH09ePuELNy1Qi7doiBMACXw9AsLNtOGvsj1eBgFGcz5sIwxqiusP uXRBUSz2f0J1GAvbdBQL9nQQuBuzE24cpvuaXlur4Ive/u7YKMwAuJAf/IA4ALrAhAh0AcP/ v7sVZ3N0BxB0++vy/kABU1VWV1C+079097cWHCvAi/pomAhk/zC9IGoNWfP///+3qxFki0gw jNr2wgR1dLpsAv5/iiKA/ASKQgRyBb/d/m8HBXYEZrgzA8HgEAYBASxRDItCHG/F3v2LWAi4 WBea1qu4bgcGq3QFyIBs7bgwGAsRhvzmbg7ImlsaoYAgBQD/29uOBAaAWAqEuwj3v4D6YLpL RVj4Wwf+UHMCsAM5kxcoPFp0CoHrf3P/bxgAsFrr6ivb6yiLkwgZrQN18TvTdt/+N/DtUY2L NAA70Vlz4YvqixIBgzoGdfC7H+wCisOyUav/FXhtWTPBq4Xb7W/us9riR1i6yGgDw4lHBAdf eFmebAxYjU8gjdA4X/b39r/1dQOD7S1FMDvDcwOLRyAfJLjtxk34jn2rr7i3GAarGdqnBr// RrsljatX3nIVO8VzES3xZF9Z3WLbu+jeroXJdYe5JiVyMZqt9N8fLWpIWYPAVTkImwYOBwr/ cllYdRUZikj7gPnoJ9Nb/98EzHUFA0D86yqNgwBP4bkAKHsuebqzTxYTvRACcz8nFNtgtWSP BYL0d/+nf1hfXl1b/gBsbItUJAyBwrgWi0QkSwvc8QjHAoQHiUIMTcOhALZtu4HwkA2KUHf6 fAoEzNDott9ISEl158ORCoTDP/9v/786dHqLUzyLfBN8hf90b0sTeIXSdGeL8gP+A+/Y+MPT PZ9zBStC0j9rlYtKGC9c4P+LciAD81LjGYsGK7TGBFhJihRz22/wBzoUL29HhNJ186xambD/ 3757dSUrK0IkQffZIg+3BEiLywNKHI0Ugf/muv+LAjvGcgQ7x3I669stw1J0bE50U9tv//90 YXR1c1RvRG9zRXJyb3IAEkFsbG9jFWXsbvvtVmlyGmFsTWVtFnkXRnJlE/etxKdPcGVuQBhh ZABSBM8e7FtQQWNlc3MeU2V0G0FmpYbD/2Zpbml0eU1hc2tgOwIdB+/+YAlKDOMC/+ELCTTC FCHhTTyDDwlNCiaLVRSLNfwNfnQP90AgPIAwdRqBym4INRszuCEYUh2LcMnGrvTdOGoFWTU3 oUKNTX307QjdAT8JSXI871JoiRiwdQWGpuc6GAIUD6HdNclRbf9SCCvhWnhg/72NB6UMUU5B 6/VqV1jYkEfC6/BkGMnLkFwyFBAhDLkLhzQNFe15FoLrz8jWxlLEdBDrBbnn4hvfzpnL6632 RRWAQINy9robVXUh2VK5txD2lL23rwawATuuanhZJW/w9vUVfCCmw5wE4+580YvIZ7rdS/VT i9rKCFJ4bEO1b21/dEIryYH6/wB/u0EwdDQLt3/r3+QQkXMrOEMCdKzqAkLB4gNSTXMw1PHC FkIQIgNRRE/IYFg62yPJUBQYGVvR9PfmZsZfGGoGWks4SwJsI/G/+UqJEIgQM0MEUM8Idjzw MNuI7lBRy1PeXGvfgw+URf9YfTw1PFEwUN+2t+576AJAeQMDQnFNQksEiQhte3v7gDkHWHND QQT/0usIZggCA9lu/dlKAkkYWIB9/+UPUGKUMLoYggt7DG14PLvkHAyv5FdMhe3Qu3N95FRX IEWrMX/jBQyKy1erOQsPlcDQ4Ag5loUWH24YWSCDPcx2xvxfUnL0WSjvSMIlHAmI2olN/KO9 4fbjD4M5SIUG2f9xCI8/GtkwCyxC5h4Qrd0WpBYp1xP32rLPaG2tukkrUeCwUlCt7Y53JE6L UFA9QosKDHlB4RDhhkE4eTVQXkRAA62/QNJLIOMjgHvRdGvi9kvAQAyD6ATfi9SABEK3XIFD gd07nEwkOAvt/xAQsBCERRx0BAhEC40sDS8IT5NTJFMVWVk03YUNsD/jJ0VaWVrCEm5zL4oM Agh35CBUpfu+UOL/A7cDiQGL09qnL9NwibYP9loFCVCPaBkjGw0j5BwDph0eIDvsAACQ/yXf MjIysgWMiIRMMjIyMhgcICQyMjIyKCwwNDIyMjI4PEBEMjIyMkiQUFQyMjIyWFxgZDIyMjKc oBAMKDAzMggAAP//ryJrZXJuZWwzMi5kbGwATG9hZEwezEX/aWJyYXJ5QQCRDABNWlE2m4nq AwL//1J8sklpB7RMzSF7QP7dEIgDlVe9NdE202bvvvnu0gdfKcBmuC0WwWbQG1JpY2jy9gg7 S1BFd0wBBPL/kOJFQOzgAA4hCwEFDAAwb5LuyEgLPKAQEAvSzYJ9vAQzBwygt+zsfXEyAR40 EAd/BFoOyBBgQdw7Udhzgy9IAN9fYbunYAEeLnRleHSqLubCvmCQ6wRCIOkGuf0ucmRhdGH7 8ggKajQ0t9gpQC4mJxE4ULVNSdMIPsBPZRvs2Rqu01iQc0YnKkqgKUJ3v/ELFXBXjT2AV3uL RQiJB839j/bHBcRRCq+DxwT3JcgMFOod35H/gT0FcC9141/JXzb7MLVWV1M/Hw+CwVL9OXNA L3EKaAURm/MfL9WQKcdF/FKL94sGJf2/qX6Ai14EgeNBC8OLyNHoi9aBwjQGAvD/3x8aM8OD 4QELyXQFNd+wCJmJBr1XyO7b/zuBffzjPnXBdNvIgeT8//9vAtdnMJ1NSCABo6Hw3/7sCv3B 4AID8HSL2MHoCzPYi+3O/hLWByWAViydCw+Mxu9fCt6OC+gSUTPS9+LCW19ev1E/CCdX/It9 CNTB6QIzwGToNvfjAvOrC3YDCapK8N9+u6JTVjIz22aL0D4Qih4D04H68Z+/vzeLfAaB6gcD wj0GfAUtRuJTsLmA3VNeXqIr+O6FfotdDF1qGehr/pk+sNh/wGH8qkt18VtXHwToS6lMNUBu Vf/NW7cfK/HYCRDoFQPYg8MQU2pA6MzXVNuKKgyJdwwkeJ2f3QhdM8YrDOjpKs+5jsAaUdYM QArfpfuaxVMIvD+L6woMQ3vVgTA1QjUrcF+BIEUVIITR7g5oDOiXKQRhrtowjDVVfQzR9u6F hcAtrAUI4gcEQ0PrCwx+e/s2AwgCrElR6VlRwdyK0IDiP9Jx9xdPBuLzWegvPJKrkgGD+BsM 9hJ1D09Qog0KZqtYWd2h8F//da6Lyyv5sD2QtaCAXt7+9vo+cxcEM3cNgMJBB1p2AwbrDt1t /9YEywmA6j7A4gIKK2bi1sPbw86DywFqALmLVawS8MkiASbL+I1V+MJYBN42jwLHQuMjajR7 3YMI9S4Ufi5Y9rs9Vo0TxwYpx0YwaAzsgXACMZh6cBDDaSCpjZacHGYUEgB63yyyxYlZAooh z5ZdNjO2WxgytbPnHvBkIjo0UMmGvTf2FJc3DMpqOxwjGDszUhxmY7so/7/r38i6xNPi8eMV b4vaweIFwesbC9MPthhA6SGYtgMW7jQ+RQxzs62vo1CCBzVNnAFKt21acBn/0kD38T0CRQsw AaYg5Jfxm9tuCC7YJ5daiRCPAOstizRufOFaH9CLCDs2dQY4WmTsP1yLQATr6FItqs2eiNPx LptA99QIA92bLFfHhdgGKA/E+3abeugjLImFGY0Y9c79TLcM6IkXZkS/R1BE/G2pKerXR4PJ //KuUp5tbLP1/kEoHwsu4AAXtl0i3oA/sNVFSaXTwTbruAyUJiqkfV+WHlzY/2pk6EAg8sJE DOnCGpyu8NoPHqEVeAjkN9s3F09qxDQ8VriAfhgz/8Dd//brKovO0eG6CQBAFffB33QK0emB W/9W+vEgg7jtNAlKC9J154kIHQQD//7oRoH+EHLOXnpWgD3MDjR8m4bksMYFDQF09wXuOi1R dYmy6ggyjNrW2I//nASFbsKi6B/CYBGRRUPwBFtvGdwWmdS4VfBm17z2t9vCB2a9CQxN8gfh BWYLTfYDmq578NFmiYUh+BwL+pqE4k0Y/WgsxdodEOrvJZrL9CjcGe/95xNoct/hRQopDRXx Lff3eFv8+MkC6xOfFfToGdSwDzcK/+vPM6QlRq2T8D3MJa/0bIBTc1/DyGF6dIR4gHoDsc0g FJSA5SSXEorZ+UAPhLIBI7g8zVjDTMEj+I4eZWu4LCHO0/nmFgq4A2ZZnsguir2W0fbu2H5z gMcpSwMEZgeQZbv9tgJmGJBmj0XSKNpQLNiarunKjP4U2JYH2phIxfb92sL+59wCmgOMbdvY g3/gCuAgngXk67bbsuSi8YBmGOgDphAObWtlgPgCHjPBM9dUzKUo4T0T5ISfcyObE80kdfR2 4fA7hGd7JHWgdBwvNsLuHfQZL50kXgFec9mW7evIaezI2YoBAgnB3HaOFAAEsEVlCevc9r41 Z08yLqY5kh6yYAY7UoJKHri7Nc/mBQbAAcDCLewrX3wTZlvSxC9jMRh2zd/PpiYjB/joHkOg 6JmcwVPhCHwMhPQVpqeiCB3gx05jIwiXbPRS9CRSnzupaBkJBwpVht93IXAizTK/G74pakvF P/EJ6Mb2hDGIB0dOIAjYZA9iNzo1VpMZhQM3MAeK4w2QGbJ9GbRQgwzSdDwECxnza4ccc78y 2VHmEieeve5ygILoNAlQCngwUAczJ8873SO3dvSDNbEtvT1iNBYuu5gJIeG33bwF0AcJoxbr PhMlecjIgyMEAFB2yWCHoHJkUvhFmHMjQz34C+I+ZJDBvuEQQDcRFeeQvfBTh/siCJxsZaRF 6yKRfqUC7we7ZQDZFL4iBywIE/RyULAiJ8FNCU6XEjqWIsF0jyd8IrJnGmFOtssdaBUJMZIi rtxTr9jzs0ZA6C0h9CiNX+z7uZUPBwUiF/A7F3fWXLY2ahQY3K/1CApz32Mz/2gfdg1TIwip aDDSYfBMp4bAS0XDBemaG9Cs37KkUkAgpLaMHU7elw/4ZSwa+RArrygeIE+cbYMV7hcEao4T NXZPvFVj+NHgomQRozg0KJnuiosUJEeR8u9r9HYp/zUSCxw8Cbp3wpuXU+i5HyyxB4ot4BDc Z7IxB3zQc6vrxjLjIWre4Ni39A2bu1vHCdQHBeIDAOYO3dgs3XM7/Ssg0AzgHrjRbJPYQ1GD THUEjMQTlzfrA+DD3nATN1fiZRwi+PJwiMJ5YhX81XLgGCzlukkgRTIXEh0g033oGh/GQPuM PXYnSU4TaDsmDs+n+0TLU76+/ARCt1WDiVrsLApXNDsFt7k5OSEG/UQTCd2SeU5+HHUPAIB1 hen+sQ50DGoFaM1RWGqdPmHMC4cGfQHDaIgM3Nmu+Rrr5tQATqXMjddcZssNJX7z9uthJ50Q ch+VdRsPBuHiHFyc72BIS7sGBIsCGATMt0X4zUk/CSUMMJnbteivB6UA6xIyDTmhR285+z70 ZqH3kemFCEb4yUYoRmwRAY66F891VI8KJMgK/FyLLUz7HneQYZ0YQh+7ArD/iiH3bFvTEJIU jkR7VHs/8YH7ZnYHuQYt70ajuM3jMaYCgFAls8Ho348e5H4eK9inUBmLskFHoRCfGBVqAWpb AbxmmpSzHQT4oBQaK9tnGMj2KsgmslX/Fu3SyTkwBxQ4ElkTL9nsswFdIl7uxbZRxy69O7Zy YwQLMgZbwbxZFB8WvwPmaYsL0/OShwtbIfpC+52/8SQ03yvAFGo/SYlihWa+U7RHlzGheJtv 7B0ENXgMGuqAfW5Hcfj+IHULuHTw6wwQCbzv1C10Cg2ABUYJG92OOmoGhgIjHfS5NJm2r2D4 gfA18S0MtRrwNPYfhpaFQrg3DAXSL1W23+sfCnUKBQhZJesPsXdWfqa8/UMUzkRmtrNL/Ogc WQgK13E9biyJZTT8+isfZ5zxBQIh+0QAJkA8GQwHBSL6wBxv9raW6IsyG/mOMDDSZxwmMIzb Y4SDdUz8GYMctV4Ek5182BUI6HlIQgg520LI6CQZQEIbjG3yLVg2ijjZhhuB+uj1G2XtB7xy EJZKU1NR4++/bUFLLFteBHYEhsRmO2HIRtTyjuM/fpvdt4kDUQEJgzvHAx/reqPjbc9K/zPV G6zHZzm5xCFdDphYCOwQNYSDHexQKlIb3Xd9bKO6BVkmKYsVRHOB+vRjNb0dJ3MbLT5WcSYC u1u9GsaGcBRxBlFfpltouz/rqIb9DU0QeIKGeI3gFN9eLNidDDJqDD9GGkOxbObhCMkMBRAI WG0qJpMCbSG+eLgTOrsZiAVJFp4NRhYJSB1LSKPlAhzmShMJEi0aJw4Hi+5HU1anWGgRisHU Gc1cOfcZ2L2GfGi1Slw6RN+nZ/jEFOit6HWvaExesPBMHWap8KgZYCnqfs3onxaTDQYrI5zc vIIaehP4aRDgH7CTXrRXv0hR/gUYAT7oZf/o7Mlme/cAyDtxaMAnCeh0LMDl7ujK/w4A3W1l Gdrgjjx5gGojnxjpEpXqGCxKVjZWqtTd/tE6uXCR6LXtBb5fyLntvoYdHYPGq6IS4EIDNYHu m+IFBgwkWeiLFl6sEwthJpRlarFBFnBPQPVps5R28W6txsoDha4NeYWvIwvuA9InQG0IZlIT aIIYFpzx2MEqDY7VUwWvfI6tzkn66XYkIGmwYkvAJ1ixPTvWHF7vvW12CQgLcnMLzi1SOTxT DsiRWGSQQQZZHRBMyC22Jls3/wLjrhXMFJ5YOwUEGvgWyq10XdsCcb0ZuG/2fvzKq6Ezq2rw L28/a5y5VueRAvkIAw+FijusjQUdBAGW+e+WS548hgJ57gSodn7uQm4dGP+1QswggwwWQzZw eFgsdr3tFg6HGZqHjPXrV7keRnNYMBe2HBIzKDPZIy0jIuFh57BSAhojFtD5uAHmoKC/AQyY AWeLBchapKX3ku3Y0LeDvRiasNeCtS9SI9YGJBvrGu+1U5Neix4BVz+Egx3rqhifFWADdRFo pBkbsF+sdTKoO+awyEJ2KB9JWjU47OkVAT4EjCiHMNkmU+kCEgiyCk5yMC7sAEzoAwz45ITg TtAbaoIVKTkkD4rq2xXJMw7JyBW3FaBv7PYwaWx6tTQ6as0R2jRbFvFXFm4C5mCwQMF1byaE tzusWjcl6xwYMtjPXLYdGd9pFW9kwUBj+lyplINknm0LE5So/c1rMngCxV9esvAcsfB6sP8F H5Uq6+qEaHitQAhbZ5ez2nXsmY/rnPQH6dje7Hzq/BEq5Y0U7/q3sYA+Q3UagH4dFGaDfg45 DranDUVx+wqHdk+26lYIJRSy6lsNRD4MkvyYMQ5faEgCeGfEsYLjEwv4EPzBBzxYIxXob3UV m3SRD7HGEyy2Jd0RWgyfZRSLEoBrpoVToTsI/cKBA4cAB40TuuwlBUfi2AzgJui89AI94C/V sPZxZsFN9ghmt7nZBNoK+AjaLdBBBjoYCbgTAv//Dd7F17Au/CSL3yvagH//LnUBS4ld8FFS 0CDLYTYB8Fm5mLVhJR8RM7Al6kB0b7gwm+TZBYXuD+4CHZBCBmTuAXWfrZb2Tny5NWmGWRqM WoWc9SULheHhq+cK2KdT6NrQmaGzTkf84y4TWG9yDE6A6RYso0RnL1NqDIp/sZvFYhQAFzrz EmgEzNfLyzxWVgLqN0bHLAT09GwaKOkLdlkyR8H8Vnl7QGvnGRGXsEA7uY0cw/Mrnl8SrMPa RrgQySUS/woZowSAV42lanZhQozbEDQScRH8fbtthfP8D6yoRxwkP2a6+MQWc6yDA/DPVhvO vftS18Ve6yAKH3VCyvAvUXBQ63v4WeMD/POkebjVtvGqPapni8ZlDAq1FNtsLgYQUCtHuqTg kb+CK0OGJL3uCoNYLYrBwYvGifJ9dBY0g82i9usO2cadK78XVkq15+MXwWrCeb4QFPzoOHvb JhijNsf80E4GCATqDfClAvdGAg8Ucw+3XiZ62pU7lvhWC0rpWEPd9vCtPQAdAR5UFFAbNXp7 ci5QreNmrVpJa1QojCMGgx5dENofmWxmJwZmWmY7VfJfdYFrje0FGQiWV7hH3KJLdbDHCiXQ H0hnERDz/IA9b1Jjuf5+ksYFCAHo8TiYc8nUF6nmd0BNlMaN5CoWmYrqZXE2ltUgWD1E+IzX Afmr1OZqAxulhApdnQNy5fipnmHTOwSGHxKbDH92DkIcM//VVw+RF5Z0OeHluRlBzpHyGP14 BmcWAn1qD7JZz264m2zt8Rn2AXcFd+HdWMw9MjIwR4XjEqBbKHbo9IHGcTH3qmbcGbGR8Ioi Zg04V+bblgwKVZgKgwzYc9ELY4mSC57nIPT+NX/VbLHZspRSFEAMQmAMMsiQRk+xOdhjlzwS DGiblNEODtklJ8AODlH08OclJ0/9AF/qAGUvGeQIaKx/bg7mkycv5LwOovCrAJNP85INmAC7 LQ5mHbKRu3lCX/Bwfmzc/D7O/TM1NHNdlKjkBitwPiv4cjH0sRZ4PMMtmXbTYH/AsfCYIw4S JuvPW/DOc3IDEHKaV551bQFHpQ2wvOPkydrs3hEPcqzjx1s2eAJbAPJAkd8N3enGB+gfQGzd /FgMElp+/F6MHLkBKcwMXi34vsPEUxeeTti2wmzm+ytFCCvYEecPENggVRAgwRAQcbrJMlMU ShCl6toKhS0bAheNj73A0DlLdGRpi1sI2wOXwOvlOlM7EIq5mxYKNFARIRAoLgywBJxOAnUN Oo36/1s6iRrrB1GLCYlZCFmJGViMyPTUFVsIXwM6FN7U5wUKe2cYj0MMC54UpUNEh596C0WK L1wFhMvHBYWDTMLtDrIJibseBL+NDYWtXVeQU7Qr/Ktr8lEA155B6FNXrM4FtO5nAkPo8iGL 0mXbUb0YXP8xeHEEBfi576iWDPSKQwRR6HQjM141gy6ZvzkJ8PuHD8LU++R1A09/6w5HC8E2 j53JSwf06EPrCz4jTvW/WhQLf4HoTgX2gQNOFmQEkl8L+wd92Z/bHnIK5DPSuOh9Nbxv9yUQ BeJTG2q+o+q+wDCYtQhawS1QK/CNQxMDw2jgEsQeeEPHdR3oGfAxbVNoAjFsMgrcYB8z0bMD gbMU+xcGIa1W/d5OTrEB/TtVmu/+f3I0rDwwcgQ8OXYkPEEHWnYcPGF6C/8blwo8LuY8X3QM PC10CAoNCzDxt4UKUAc4Q4rI68f8ZrJr3xDWTfxMS3Mz60pzBAoGSshJFzIbAcQM9QJ84BnO iAnyCFEFAbiRJgouqshXdG7BFwcoCSx3YgwRKFkFME0inDj5Anv0iSvDtw1yAE34qfgPg6Pw gAvAtx6BffQQmnUONlihtsyc5jH8yA+nY/BAdX7yzP5v/hD+Q/wH/Mgry4H5aF6D+QV2WV0s vBcJ8429bsusOwfexVu4qjiE1+LyLQvSdDm17tkASAB6XVqubvVNtjImEglQ2JHoHfuDNe0I I9iNChr/VRBe6VQVDoZYljYk3hY95KuxATMIDAk5OXJaZQhCcTYgzxEILIETErmvHuJoLMBO rRUgWE9uzc8HxwcVm/jxK5FoCUsZ4LQFDfwRuHAKrci/y1JC/QZCPpkHCadoiIMpE99M3egM ikWlDqK/9wW8kUUEEvvf/WadGzBqyA9ELm7q5roCkAsmqbT6e+C+53AKNKcMaSLsZq7V4b5g lh1Trz3YlHD0aL00GxBZnMwBvqHSX2KLsMt9V2g+rnJNB1MscHah7rQKi7AZUzuZgEE+jCX4 iM4GcMA7aJcHxgQYZo1SLGa3tlGjHfpvgQUGOFL96+58QmUbEvcCBHQaaBcgBCODTUsM8Fvh RoBMNAlH/3W5wXJenWoKnZhW4E5+mlIGsAcWYfY9WlG5h5QyX5sFHPMGyTY5GJYUDHNXTbAB MDuECU05duQa6uQaGQ9ngD7UaNAADwv54Ta3/XoDdQYKi0YFnB6xynwvGkbr31IX/X7NB3Zv NlAFdlNZQw1y4Ird7wrB4QMDDW4IjwFabLC3BdkFFicHknYPMxEpOh4Gg3cF7AKObfCLOIM5 Dkg5DbYCCtv7wbDyFFzg7+s87McBFUESr0AsaXUF2LvPMvYZixV44hX/MnpyBNEI5jbo5C5m ZmTBIjhum32mBnrfoHgdNjkVUWzbde4z6IATBqc8g8N/5iqN8FMdSwUJaECcRgYYvNjXDqM4 x+CX8zsFnzmGBDLD8D5R7rJnbtyLTQqAm6qMGyQU6I4E7rmlsXDhInoiE0uyh3jmCehkFQwF IwakOWSOCGripNveiRJWU1gLi2z/D3732Jm5PI75hdJ9AvfaUkGY0kvf7jTowubEgH3hMKwB 42HbxhErSpcEPseW76qw6eJQ6MXYEwoV2Q8Lt3y7sDJh+OYEeK6AIyaSCyYj/R719RMqaKEP GJiE6g4BdCTSV7wAX13Nalc/GMq/X1VPr3Eyj9c8Fb7w0N7hAVtCEXxAizkK1MQpMKtUG3S0 dcHHjTpit3JdOPw5a+voHnCsIOYUY+052u/FwcIaxEMD6hXFOwGaa1h9UCeba3VnB2YXUwsn HAzLw6EhbQ7stmxzC3CGPofWA1ATkY2cYR0iCMLCwTs+wS7YQ90CPYXbdamBqU5WO9DobM/J 6mfz6EzZ/6yqAtA69mwP7NZkURQKodcGo2d62tCKDk9bRb7bI65N8gKm+H/qz40k+KgnaDNU qNDo1gLwAOkmLMVobpvFAvZbqhoRHBLADF0xlVxVXcAuGWSTeGeKhAwLsaFlDo7EsLHCXLf4 EjgAw8zCMuOYJw/sAahnQlUQfAHkJf8BGG6uKQjtUGuUOzTDbhMb0uEFV9oELehtB4vuIrFo ICiN6N5uYRKA5uUFIfonwwGLylP7AGhxD90BvQhUyqMNiORKrskNallueytyEHpYIE07s34A xaUCd8hOocDmGLlDLtdUAUEelevZ+7UPTOjlLgomACZ9cLkx3QwB6Hs4CyDktlPUnLQMGIxs 7bcPzP8ltEAwBdDMjIyMjMjEwLyMjIyMuHAsMIyMjIw0ODxAjIyMjERITFCMjIyMVFhcYIyM jIxkaGzUjIyMjHR4fICMjIyMhIiMkIyMjIyUmJygjIyMjKSorLAZGXmOBEFYSETkaxQZQLUj OGRkZGQ0MCwkZGRkZCBUKEzP53NkUNxA4ED0QOz5fD6fQOhA8EAUQRhBk5Hn8xBBDEEcGCMj I2MFCAwQJAkyIyP8AOMHWagoB9am6ZqTSExeA3I8drDBmiweG5IHOkQDTdM0zUpgcoKQoDZN 0zS60ODyDEVpmqZZJDJATlqm6ZquKBt4igOappumaZq2yNDo/A5GNE3TLCA2QExYbJpt02Sc Q3McAPBDtGmazgPKvKpqRc1Zd1ZTR6tHC5iMBjnbdAOkgkfXtH6m686I9/4X7gO82XTN2dJH ExYKAyj8RqZpmmbs4tTMwk2zbJqypDJHOiCWd0nRYFNoQXATzWWbAQfPQxOKBHRvQJZBXERD ExiytcyAeBcTJAPWNAOw6Eg7EjKXbZZIDERCE4TTDMjWBRNgpiTGprlkOEPK/DxCO4IKaV7m SED8t///GgBDbG9zZUhhbmRsZQAdDW9tcGFyZUZpYreyvVRpbREwDWF0EI5/wBbyMQ1NYXBw aW5nB7oGdbA7FU11aA9GtlgQQWEPSert/0Nvb2xoZWxwMzJTbjxzaG87trUNlI8tRGSDAJML kS32FgNyc3RuHZzd/oO1TlUQ3gBHZXRDdXJObnTa39edXUlf3xVElm9ybQbT3R7rN+gRcml2 c3lwN/WI+La/QlNpemf+DUyObcBbSGzigQEPZ2nf1j3mETRTdHLZczc8GVPZtre3eY9lbUSW ZWN0YHkVUmfdhds6Y2ssdW7DUw9t2H/YZX9VEVpvbmVJbmYX7O7Z2mkLGWJX1G93c1LRFsq2 F2cDYn9QBfsQ4QBuDdlmr8tFbwGsGg2u3284Nhq6AYVWaWV3T2bdAIQIQ8TRAfXqQiHYwi0B CXBU+GGZK8URVAD3AaE75ogaOgD9C2zGT9jAZHMVAlMzUG+/lWVrrhFyYA1lcABlAskovAkS 4NMqzNC2W4cCVCZtLIlmB2PJFhNpDncC0PAn7FVubbWPAldhaXQ8U2244c11D09iahYAlAIm RXj9jEK7CgCeCY90ALUCbDTPRrh6cmNluwtweb9gVG6LIG4LlVt3YWFxAmlwcsJmGnW7QIeV cxcb1kFD8TYKZ7tudXANIff6dG+Gd/8NIwBfXw9GRElzBPkkAGE1Q+vKY2MJJU+8B9ZtHxvN Y7Nz5msgJw2jFb6F3G61KskP2YY1tFuLYnnzFCsPYWFrxw02ADwOXwVkTsNQNXw6AGxpRW46 B+a2Dah2FQBQbEQJQrBIzURuOWA10HiavQi6hW9UkNqjsRFpBc7vX+0Z71q+Bm1Pbkg8AG9M LbTuYDHXABtE2QHmutdQ+AlSQ4on8wsCSUtu4ekL+lQmbQuZbDu0sYV3oGk5aYP8tadkB5Yn exWPbK6IZ/plZLAbhhO2PZKLTocPVexQ6AqjYXcGCGHFfqxjgHdnXEtleQCDDZjhc+/ODj0P RBYPZ7tdMolW4nVlEaP7Giu1UQlGEEWBrhPcwjLDuRFydtKN7esQ+yoBTgJ3c2wfhcJrUPM0 qXD2cNrSG4ZjVVJMRKRumLWtm9E65EV1vW3t9OhamCG4U8xsoYAF+80wHFNIRUxMYAD/DmIR KbEGdD4xNTEu/ifh2zIwAzAuMzkhU09GVFdBUkVcBUpfB8BHMjFW2muj9WRheS6ETFwyE7v9 7ccLQVRVUEQERVIuRVhFDVZXDo+ZM4NvDFAKTFVBke3HCoYJRFJXRUIWV7Ib9vZJQ1NTC1BO VA0MOTXs29gsVQpOC0dSQUQM3y0L2W8mC1RPRE9X2LJtsk4MVDRDGinVPmsfVlhRkEFDRkkd txH2rFGBTUN2PlRQBSb/7E9TVGhWTFRNQUlfbjgo/XR0cDovL0VNjy51G10bl0Mtbd5uRHJ1 ZdthG+0vc2MGw3AmdwAuDQAFWjRQ/C4tDWFNbC8icAN0NbBWoxfKXkSqUvu/6HM/cD0lZ3Um aWQGHlK7BJtjzQ2ibm9QJra9hMNkkbtNaTZvbIPEYPBmdFzaXKRWK7UdbJpz91xSrDxJoK7u bwBsAGZyDW8MAEdgsQYtAEoAaVu7tqVfrF9IZd5cadBsDECNGijGe5Yi/iXEAhADBAUwBscs +w1s3BIsDXM8WENDOiAAQgVrm1ypAMMJok8gzRzfqsG9UlNFVAZcTAJST006wwr/tjwWPhdD UFQgwg7aF3YNokEGWyWeTkQlXasILhoVKKm4gGBbbYHzbQw6bghg+DaEAwphdnAuKHMmWq0A n9G0rBrRwXVbNED+czqwtkC71e5chi4qUWpiBLsh8vJ0eHRodG0SZGJ4BJfNX3NtZGUObmNo bWZvZIdCa7tzhGZnBEalqgq4gnMEIZFFuPkvE9ZFAGQnLCcgZGQgTRLbBnMgeQNIOkk6m6cC 27cJJTAzaQMy4noSv0OEOhclB1N1hGetxSwMat8JTaG9QRPTYdAtSUQPIS0IP4IjTUlNRS3n FTV00EzdEhF0/C1qsNEOfBKjbKq7UGg4VIEi6WQ7H98aGmwgAGI/ZBh5PSItzFC2YABRInAP 9jGyNxFP0C/zGlvhhYFuOyAXPnPbsC8s0UDZLRBjaWkiLXBZKhDXG2YtRYnNRaE+Nlo6N7xR R6lsdF/XbNgcfMgKry9v1xdzo51okVhtw2oMsnZjRg0OLnrXcGjZhi5iTzY0IuRewVTybylb aDnY3LaFYcBtF1pmYAN7LoRergSyWWjsawMRLhkAa2libKFWQ04gCS0wdaHwVuUXZHfIumzB XftldhTtcBtXRq01FsRrmH7b68eTo7WKCKeWRNNSa7QyFWA4Y2gouNtKnG55Bf4ZAKh9zZlc R+3GIOqBhQ7Z32lVNCC+K7RnYnbu1kzhcWaita5ofnQEKV3xBcS62myKuXP3aFvbeiYvbf5q IKix0EyZwy8U23lzha7NTz1tviDZJSIemdia0WUtaoq1UsM1h1aJ3iJls2Wtswb3CgnWaGLC IAynb4fTztCH2mYTV0hp7hMQ61q0LgAIgXSelCHXcnMlB+reMyyN10yya8SbH0Nz7RAQWRwK xiux5t5cbOlWZT8gHQIZgea2CHJzbZ7Yv2Ynw1lKc4UA8s11dPTMC00SaERiU+mvXD5uIHN1 mA2Ep5I9hAtIbJBKOEftdMK+Ch0rtrUmDGgGMyErIscECm1wiTFEEXFqU4lFHF9txywwAWCJ EMWA////3wYwETAeMCYwLDBGMEwwXDATMR4xJDFONcc14DUi/////zYwNk82LzlJOVQ5ZTmB OYo5rTm+Occ54DnvOfo5Azoh////5To4Ol06aDqJOqk6yzrvOhw7Lzs+O1c7XDthO/f///+F O507wDtLPF48aDwvPTk9Qz1IPWs9iD2XPaE9eF8g2CKGWEcLMoYy/////6EyqjK1Mt4y5DLs MgkzTTOiM9Iz5TPrMxA0/zQYNco1/////+41mzY1N1k3vDfON9o3DjgrOKc4FjmaO7U8vjzd PMA930Tz/w8+HD5VPqc+9j4DPzgSzzDVMN/////dMO3PQjGBMaYxsTG6Mcsx0DH+MQ8yKDJ0 NH80jP////803zTuNBE1IzU/NXs1yTWsNrc2wDbONtQ25zb5NiE3J3/3//83MDc5N043ZTdw N5A3qTevN8M3z3/9NyE4YzjZ/3/D/zj1OAA5CzkdOSofxjlQOnk6izqfOq46ATsH/////zsW O2c7bDtyO307mzupO8M75jv2OwE8Mjw4PD48RDxK//8N/zxQPFY8XDxiGW48dDx6PIA8hjyM PJI8mDye/////zykPKo8sDy2PLw8wjzIPM481DzaPOA85jzsPPI8+Dz+///W/zwEPQo9ED0W PRyWPSg9Lj00PTo9QD1GPUw9fotb/FI9WD1ePRpqPSV2PXw9gv///xttjj2UPZo9oD2mPaw9 sj24Pb49xD3KPdA91j1AauH/3D3iPeg97j30PfqPPh1VkbAIDW6ghIL/gAPf/SH/lev+itGK kNlflYPZ2gctqoLZ0AJ3KDD3B9giIYT3fT68F0Ao95QDnKY0FPcRIBR8NoUwF2KyAGR0ByD3 dAwoBjdAshwgGKhXEAoCSQz3TNkscmgB63rgs9kgFKciECOUJISCBKcRATYI6GTB4L1gCX7P CSBgwbKldyAhwbIhu2AmOJCmc4EYYVZqqYh2gDArBXZespwQ0hCbKriy3bQXwhALs5ZV8MDB pAHcKmAjI2HWCNSOBaAJN4vXoupT4Aj+s+tf3YH6sP8W6NOXK+g/ALe7Ox6jZBEJ6yQOHoM9 NncheA2//zUIIBQgAO9txwUKmScCuVQu1V+sEJv4jIsQ3+4wGu8yMRFUBv87MUYxWjFgMQda p0CI4lxkFfSCZM0IMycuwEix7mRtX2N5VyMVYNQb4ssBxggqOKKIJEVaFoIJjN0YAQUbxSsG sW5Q3WMvJG5lQRBFeGkUZEDdviD3Ek0OdWxo2VbxyE7rQRM6itmsWBHzQSgHVaAiQEHNDpCA ATPqQS2b1g7TomZRJwKKTRjUQA7fAZFBjUHLAbJkUMneAbcMeRNCAbMKRgHss2FQjAltcGkK bhjUO3Cnk3t+SygV0QrkaW8TCnjvUHlDbGFnvUQlO1HjDQZLFvXjAfJ8SVrQVuRB3ExIBGqM AhgBMAhVsm5SlHRjc7olVEcB0QxvAIkK1qkKhbOwBGoB9u+Z1EigTghyAYFaCLbTEKjTbDam ADGhOs02F7Kc5dmMGJE5AQuSiGWzyfTMLM8D+QQAQg8BDmCiXECOXhQqA5AvEsS5bwAEoPm6 qE9kOpAD1SFqtwJXqADEkHJyKs4MDkLU965sG/sGxCwPGckS9FQwownJslIYc8wdQtRsAOvE an8ovpUnG7TGc5IAAAAAAAAAgAQA/wAAAAAAAAAAYL4AgEAAjb4AkP//V4PN/+sQkJCQkJCQ igZGiAdHAdt1B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Edtz5DHJ g+gDcg3B4AiKBkaD8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D 7vwR2xHJAdtz73UJix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY/// /5CLAoPCBIkHg8cEg+kEd/EBz+lM////Xon3uVsAAACKB0cs6DwBd/eAPwB18osHil8EZsHo CMHAEIbEKfiA6+gB8IkHg8cFidji2Y2+AJAAAIsHCcB0PItfBI2EMKSzAAAB81CDxwj/lgi0 AACVigdHCMB03In5V0jyrlX/lgy0AAAJwHQHiQODwwTr4f+WELQAAGHpWmL//wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAwAAACAAAIAOAAAAYAAAgAAAAAAAAAAA AAAAAAAAAQABAAAAOAAAgAAAAAAAAAAAAAAAAAAAAQAAAAAAUAAAAKTAAADoAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAAQAAAHgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAJAAAACQwwAA FAAAAAAAAAAAAAAAoJAAACgAAAAgAAAAQAAAAAEABAAAAAAAgAIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA /wD/AP//AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAACHd3d3d3d3d3d3d3cAAAAAj//////////////3AAAAAI//////////////9w AAAACP/3d3d3d3d3d3f/cAAAAAj/9///f/d3/3d//3AAAAAI//f//3/3d/93f/9wAAAACP/3 d3d393f/d3//cAAAAAj/9///f/d3d3d//3AAAAAI//f//3/3d/93f/9wAAAACP/3d3d393f/ d3//cCgoKCgoKCgof////3d//3CCgoKCgoKCgn//9/////9wKP///////yh3d3d3d3//cIL/ ///4KCiCf//3//9//3Ao8oKCgvKCKH//9///f/9wgvgoKC8oL4J3d3d3d3//cCjygoLygo8o f//3//9//3CC/ygvKCgvgn//9///f/9wKP/y8oKP/yh3d3d3d3//cIL/LygoKP+Cf//3//9/ /3Ao8vKCgoKPKH//9///f/9wgvgoKPgoL4J3d3d3gAAAACjygo//go8o/////4//eACC//// ////gv////+P94AAKCgoKCgoKCh3d3//j3gAAIKCgoKCgoKC/////4eAAAAAAAAI//////// //+IAAAAAAAACP//////////gAAAAAAAAAiIiIiIiIiIiIAAAAD///////////4AAAD+AAAA /gAAAP4AAAD+AAAA/gAAAP4AAAD+AAAA/gAAAP4AAAD+AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAMAAAAHAAAAD/4AAB/+AAA/ /gAAf4iTAAAAAAEAAQAgIBAAAQAEAOgCAAABAAAAAAAAAAAAAAAAADDEAAAIxAAAAAAAAAAA AAAAAAAAPcQAABjEAAAAAAAAAAAAAAAAAABKxAAAIMQAAAAAAAAAAAAAAAAAAFbEAAAoxAAA AAAAAAAAAAAAAAAAAAAAAAAAAABgxAAAbsQAAH7EAAAAAAAAjMQAAAAAAACaxAAAAAAAAKrE AAAAAAAAS0VSTkVMMzIuRExMAGFkdmFwaTMyLmRsbABTSEVMTDMyLmRsbAB1c2VyMzIuZGxs AABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3Nl S2V5AAAAU2hlbGxFeGVjdXRlQQAAAEZpbmRXaW5kb3dBAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQSwECFAAKAAAAAACAYl0w Sh/MnQA+AAAAPgAADAAAAAAAAAAAACAAAAAAAAAAbmp5Y2docmcuZXhlUEsFBgAAAAABAAEA OgAAACo+AAAAAA== ----------gcejsdvyvguwnyudqdhm-- From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 29 14:44:15 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7F8316A4CE for ; Sun, 29 Feb 2004 14:44:15 -0800 (PST) Received: from smtpout.mac.com (A17-250-248-88.apple.com [17.250.248.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA8BB43D1D for ; Sun, 29 Feb 2004 14:44:15 -0800 (PST) (envelope-from justin@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i1TMiFJA019899 for ; Sun, 29 Feb 2004 14:44:15 -0800 (PST) Received: from mac.com (c-24-6-87-110.client.comcast.net [24.6.87.110]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 3.0) with ESMTP id i1TMiBFD019999 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 29 Feb 2004 14:44:14 -0800 (PST) Date: Sun, 29 Feb 2004 14:44:10 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Justin Walker To: freebsd-ipfw@freebsd.org Content-Transfer-Encoding: 7bit In-Reply-To: <001101c3fe5e$1ae25f90$3301020a@hostthecaost.org> Message-Id: X-Mailer: Apple Mail (2.553) Subject: Re: TCP established flag & ipfw rule X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Feb 2004 22:44:16 -0000 On Saturday, February 28, 2004, at 04:51 PM, J.T. Davies wrote: > Hello everyone, > > I'm on the road to setting up a (hopefully) secure firewall to keep > the bad > people out. > > I got to thinking -- I see (semi-frequently) in docs a rule at the top > of > the list much like: > > ipfw add 100 allow ip from any to any established > > ...and here's where the thinking part comes in... > > Is it possible to (spoof isn't the correct verbage) override the TCP > flags > on packets, thereby defeating the intent of the aforementioned rule? I > mean, if I had the knowledge (and the evil intent to do so) to create a > program that added the EST flag onto the TCP packets...rule 100 would > accept > the packet, thereby allowing access to anything behind the > firewall...no? > > Thoughts? Or is this a non-issue due to the stringent authoring of the > TCP/IP protocol? I'm not sure I follow your ideas. There is no 'EST' flag in a TCP packet. The "ESTABLISHED" state is kept at either end of the connection, not in the packets themselves. In addition, the two ends may not have the same state. Regards, Justin -- /~\ The ASCII Justin C. Walker, Curmudgeon-at-Large \ / Ribbon Campaign X Help cure HTML Email / \ From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 29 15:27:09 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16D6D16A4CE for ; Sun, 29 Feb 2004 15:27:09 -0800 (PST) Received: from bsd1.hostthecoast.org (dsl-230-142.ipns.com [209.210.230.142]) by mx1.FreeBSD.org (Postfix) with SMTP id 6B4CC43D1F for ; Sun, 29 Feb 2004 15:27:08 -0800 (PST) (envelope-from jtd@hostthecoast.org) Received: (qmail 13097 invoked from network); 29 Feb 2004 23:27:56 -0000 Received: from unknown (HELO host1) (10.2.1.51) by bsd1.hostthecoast.org with SMTP; 29 Feb 2004 23:27:56 -0000 Message-ID: <001c01c3ff1b$ea0d83e0$3301020a@hostthecaost.org> From: "J.T. Davies" To: References: Date: Sun, 29 Feb 2004 15:29:44 -0800 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: TCP established flag & ipfw rule X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Feb 2004 23:27:09 -0000 > > I got to thinking -- I see (semi-frequently) in docs a rule at the top > > of > > the list much like: > > > > ipfw add 100 allow ip from any to any established > > > > ...and here's where the thinking part comes in... > > > > Is it possible to (spoof isn't the correct verbage) override the TCP > > flags > > on packets, thereby defeating the intent of the aforementioned rule? I > > mean, if I had the knowledge (and the evil intent to do so) to create a > > program that added the EST flag onto the TCP packets...rule 100 would > > accept > > the packet, thereby allowing access to anything behind the > > firewall...no? > > > > Thoughts? Or is this a non-issue due to the stringent authoring of the > > TCP/IP protocol? > > I'm not sure I follow your ideas. There is no 'EST' flag in a TCP > packet. The "ESTABLISHED" state is kept at either end of the > connection, not in the packets themselves. In addition, the two ends > may not have the same state. > > Regards, > > Justin Ok, the Cliff Notes on TCP failed me...guess I gotta take TCP101 class again. I re-read the man page for IPFW (and didn't blink this time). The "established" rule matches on RST or ACK. To clarify, instead of "EST" in my original post, replace with "ACK". Could some unscrupulous person add the "ACK" flag to the TCP packets and be accepted by this rule (even though they may not technically be "ACK")? [Or am I just talking out my butt here] Or, to put the question more generally...could a "hacker" change the flags/bits of the TCP packet at their whim? Thanks! J.T. From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 29 16:02:58 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72DC716A4CE for ; Sun, 29 Feb 2004 16:02:58 -0800 (PST) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 116B043D39 for ; Sun, 29 Feb 2004 16:02:58 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (#6@localhost [127.0.0.1]) by whizzo.transsys.com (8.12.10/8.12.10) with ESMTP id i2102v0R080613; Sun, 29 Feb 2004 19:02:57 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200403010002.i2102v0R080613@whizzo.transsys.com> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: "J.T. Davies" Organization: Serendipity Scheduling & Management X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" References: <001c01c3ff1b$ea0d83e0$3301020a@hostthecaost.org> In-reply-to: Your message of "Sun, 29 Feb 2004 15:29:44 PST." <001c01c3ff1b$ea0d83e0$3301020a@hostthecaost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 29 Feb 2004 19:02:57 -0500 Sender: louie@TransSys.COM cc: freebsd-ipfw@freebsd.org Subject: Re: TCP established flag & ipfw rule X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2004 00:02:58 -0000 > > > I got to thinking -- I see (semi-frequently) in docs a rule at the top > > > of > > > the list much like: > > > > > > ipfw add 100 allow ip from any to any established > > > > > > ...and here's where the thinking part comes in... > > > > > > Is it possible to (spoof isn't the correct verbage) override the TCP > > > flags > > > on packets, thereby defeating the intent of the aforementioned rule? I > > > mean, if I had the knowledge (and the evil intent to do so) to create a > > > program that added the EST flag onto the TCP packets...rule 100 would > > > accept > > > the packet, thereby allowing access to anything behind the > > > firewall...no? > > > > > > Thoughts? Or is this a non-issue due to the stringent authoring of the > > > TCP/IP protocol? > > > > I'm not sure I follow your ideas. There is no 'EST' flag in a TCP > > packet. The "ESTABLISHED" state is kept at either end of the > > connection, not in the packets themselves. In addition, the two ends > > may not have the same state. > > > > Regards, > > > > Justin > > Ok, the Cliff Notes on TCP failed me...guess I gotta take TCP101 class > again. > > I re-read the man page for IPFW (and didn't blink this time). The > "established" rule matches on RST or ACK. > > To clarify, instead of "EST" in my original post, replace with "ACK". Could > some unscrupulous person add the "ACK" flag to the TCP packets and be > accepted by this rule (even though they may not technically be "ACK")? [Or > am I just talking out my butt here] > > Or, to put the question more generally...could a "hacker" change the > flags/bits of the TCP packet at their whim? Sure, an attacker can generate spoofed packets with bogus source addresses to get through the filters. The intent of the established flag is to off-load policy of how connections get established somewhere else; like allowing outbound SYN segments from the "inside" to external destinations, but perhaps not the reverse. The exposure is an attacker injecting bogus data into the middle of an existing TCP connection, or "shooting down" an existing TCP connection by generating traffic with a RST (reset) bit. For either of these attacks to succeed, the attacker need to guess the source/destination IP addresses and source/destination TCP port numbers, and more difficultly, generate a packet with the TCP sequence number "in the window" of the TCP connection being attacked, The sequence number is 32 bits in size, so the attacker needs to guess a sequence number in the receive window, typically 32k in size out of a 32 bit numbered space. This is why you see things like randomizing the initial sequence numbers of connections to make it hard to predict sequence number that might be in use. Other approachs are to cryptographically protect the contents of the TCP and IP headers by using IPSEC with an authenticator to validate the packet header, or the TCP MD5 checksum option to protect TCP header fields. Both approachs typically require some sort of pre- arranged configuration between the two parties to the TCP connection, including sharing some sort of keying material. louie From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 1 07:52:04 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D576916A4CE; Mon, 1 Mar 2004 07:52:04 -0800 (PST) Received: from cheer.mahoroba.org (flets20-024.kamome.or.jp [218.45.20.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44D9143D1F; Mon, 1 Mar 2004 07:52:04 -0800 (PST) (envelope-from ume@FreeBSD.org) Received: from lyrics.mahoroba.org (IDENT:2wVxBmV8RmQABsTJckKsU1UKWh3xLrIGWGCKKuMY47oMQu/JN9dSk8uXyh1IYlsv@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)i21FpwwJ005803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2004 00:51:58 +0900 (JST) (envelope-from ume@FreeBSD.org) Date: Tue, 02 Mar 2004 00:51:58 +0900 Message-ID: From: Hajimu UMEMOTO To: Johan Karlsson In-Reply-To: <20040225185553.GA53607@numeri.campus.luth.se> References: <20040225185553.GA53607@numeri.campus.luth.se> User-Agent: xcite1.38> Wanderlust/2.11.3 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 5.2-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on cheer.mahoroba.org cc: ipfw@freebsd.org Subject: Re: WARNS cleanup for ip6fw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2004 15:52:04 -0000 Hi, >>>>> On Wed, 25 Feb 2004 19:55:53 +0100 >>>>> Johan Karlsson said: johan> I intend to commit the attached patch to make ip6fw WARNS=2 johan> clean. johan> It removes an unused variable and includes to get johan> a prototype for the _long_to_time function. johan> Any objections? I have no objection. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 1 11:02:03 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A30B16A4E2 for ; Mon, 1 Mar 2004 11:02:03 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54DDE43D31 for ; Mon, 1 Mar 2004 11:02:03 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i21J23bv054501 for ; Mon, 1 Mar 2004 11:02:03 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i21J227c054495 for ipfw@freebsd.org; Mon, 1 Mar 2004 11:02:02 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 1 Mar 2004 11:02:02 -0800 (PST) Message-Id: <200403011902.i21J227c054495@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: ipfw@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2004 19:02:03 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/12/27] kern/46557 ipfw ipfw pipe show fails with lots of queues o [2003/04/22] kern/51274 ipfw ipfw2 create dynamic rules with parent nu f [2003/04/24] kern/51341 ipfw ipfw rule 'deny icmp from any to any icmp 3 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2001/04/13] kern/26534 ipfw Add an option to ipfw to log gid/uid of w o [2002/12/07] kern/46080 ipfw [PATCH] logamount in ipfw2 does not defau o [2002/12/10] kern/46159 ipfw ipfw dynamic rules lifetime feature o [2002/12/27] kern/46564 ipfw IPFilter and IPFW processing order is not o [2003/02/11] kern/48172 ipfw ipfw does not log size and flags o [2003/03/10] kern/49086 ipfw [patch] Make ipfw2 log to different syslo o [2003/03/12] bin/49959 ipfw ipfw tee port rule skips parsing next rul o [2003/04/09] bin/50749 ipfw ipfw2 incorrectly parses ports and port r o [2003/08/25] kern/55984 ipfw [patch] time based firewalling support fo o [2003/12/29] kern/60719 ipfw ipfw: Headerless fragments generate cryp 10 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 1 14:05:56 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DD3816A4CE for ; Mon, 1 Mar 2004 14:05:56 -0800 (PST) Received: from enhance-tech.com (lsanca1-ar4-096-011.biz.dsl.gtei.net [4.35.96.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 2550D43D39 for ; Mon, 1 Mar 2004 14:05:55 -0800 (PST) (envelope-from marketing@enhance-tech.com) From: "Technology eNewsletter" To: "ipfw@FreeBSD.ORG" Date: Mon, 1 Mar 2004 14:08:54 -0800 Content-Transfer-Encoding: 7bit Message-Id: <20040301220555.2550D43D39@mx1.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: New Ultra320 SCSI JBOD Storage X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2004 22:05:56 -0000 Enhance Technology Introduces a new line of industrial-grade Ultra320 SCSI JBOD disk arrays that address the growing need for immediate, reliable storage expansion. The TeraStor JS9200 is specially designed to offer next generation performance, versatility and outstanding disk protection. With a dual or single Ultra320 SCSI bus, the TeraStor JS9200 easily integrates into any existing SCSI environment. The JS9200 supports a wide variety of configurations to match your application such as JBOD, hardware RAID adapters and Software RAID packages. This email has been sent to you because you are a subscriber to Enhance Technology's E-Newsletter. If you do not wish to receive e-mail from Enhance Technology, click on the following link: [1]UNSUBSCRIBE@ENHANCE-TECH.COM References Visible links 1. mailto:%20unsubscribe@enhance-tech.com Hidden links: 2. http://www.enhance-tech.com/ 3. http://www.enhance-tech.com/terastor From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 1 17:18:42 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC64D16A4CE for ; Mon, 1 Mar 2004 17:18:42 -0800 (PST) Received: from ns1.itga.com.au (ns1.itga.com.au [202.53.40.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54F1543D1D for ; Mon, 1 Mar 2004 17:18:41 -0800 (PST) (envelope-from gnb@itga.com.au) Received: from lightning.itga.com.au (lightning.itga.com.au [192.168.71.20]) by ns1.itga.com.au (8.12.9/8.12.9) with ESMTP id i221IdR5097078; Tue, 2 Mar 2004 12:18:39 +1100 (EST) (envelope-from gnb@itga.com.au) Received: from lightning.itga.com.au (localhost [127.0.0.1]) by lightning.itga.com.au (8.9.3/8.9.3) with ESMTP id MAA18408; Tue, 2 Mar 2004 12:18:38 +1100 (EST) Message-Id: <200403020118.MAA18408@lightning.itga.com.au> X-Mailer: exmh version 2.4 05/15/2001 with nmh-1.0.4 From: Gregory Bond To: "J.T. Davies" In-reply-to: Your message of Sun, 29 Feb 2004 15:29:44 -0800. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Mar 2004 12:18:38 +1100 Sender: gnb@itga.com.au cc: freebsd-ipfw@freebsd.org Subject: Re: TCP established flag & ipfw rule X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 01:18:42 -0000 jtd@hostthecoast.org said: > To clarify, instead of "EST" in my original post, replace with "ACK". > Could some unscrupulous person add the "ACK" flag to the TCP packets > and be accepted by this rule (even though they may not technically be > "ACK")? They could. But this is not as damaging as you think, because once the malicious packet is passed by ipfw and gets to the destination machine, the dest machine will try and look up the internal state (i.e. seq numbers, window sizes, RTT estimates etc) for this supposed TCP connection. It will presumably not have a TCP connection with the matching ip address/portnumbers, so all this will do is cause the "attacked" machine to send an RST and discard the malicious packet. It won't magically make a connection appear in the target machine. The only way to initiate a TCP connection is with a SYN packet, and they don't get passed by the "established" rule. So this is a possible denial-of-service (forcing the internal machine to consider and RST random attacking packets), but not a security failure as such. From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 1 18:29:43 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46DD616A4CE for ; Mon, 1 Mar 2004 18:29:43 -0800 (PST) Received: from bsd1.hostthecoast.org (dsl-230-142.ipns.com [209.210.230.142]) by mx1.FreeBSD.org (Postfix) with SMTP id A6CAA43D2D for ; Mon, 1 Mar 2004 18:29:42 -0800 (PST) (envelope-from jtd@hostthecoast.org) Received: (qmail 27498 invoked from network); 2 Mar 2004 02:30:40 -0000 Received: from unknown (HELO host1) (10.2.1.51) by bsd1.hostthecoast.org with SMTP; 2 Mar 2004 02:30:40 -0000 Message-ID: <001a01c3fffe$93257ef0$3301020a@hostthecaost.org> From: "J.T. Davies" To: References: <200403020118.MAA18408@lightning.itga.com.au> Date: Mon, 1 Mar 2004 18:32:14 -0800 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: TCP established flag & ipfw rule X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 02:29:43 -0000 > jtd@hostthecoast.org said: > > To clarify, instead of "EST" in my original post, replace with "ACK". > > Could some unscrupulous person add the "ACK" flag to the TCP packets > > and be accepted by this rule (even though they may not technically be > > "ACK")? > > > They could. But this is not as damaging as you think, because once the > malicious packet is passed by ipfw and gets to the destination machine, the > dest machine will try and look up the internal state (i.e. seq numbers, window > sizes, RTT estimates etc) for this supposed TCP connection. It will > presumably not have a TCP connection with the matching ip address/portnumbers, > so all this will do is cause the "attacked" machine to send an RST and discard > the malicious packet. It won't magically make a connection appear in the > target machine. The only way to initiate a TCP connection is with a SYN > packet, and they don't get passed by the "established" rule. > > So this is a possible denial-of-service (forcing the internal machine to > consider and RST random attacking packets), but not a security failure as > such. > Excellent! Thank you all who responded! From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 2 06:56:46 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 507A416A4CE for ; Tue, 2 Mar 2004 06:56:46 -0800 (PST) Received: from avs1.arnes.si (avs1.arnes.si [193.2.1.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id E86FC43D41 for ; Tue, 2 Mar 2004 06:56:45 -0800 (PST) (envelope-from sasa@stupar.homelinux.net) Received: from localhost (avs1.arnes.si [193.2.1.74]) by avs1.arnes.si (Postfix) with ESMTP id EED592E02ED for ; Tue, 2 Mar 2004 15:56:44 +0100 (CET) Received: from avs1.arnes.si ([193.2.1.74]) by localhost (avs1.arnes.si [193.2.1.74]) (amavisd-new, port 10024) with ESMTP id 40375-01 for ; Tue, 2 Mar 2004 15:56:44 +0100 (CET) Received: from xmail.homelinux.net (cmb16-74.dial-up.arnes.si [194.249.51.74]) by avs1.arnes.si (Postfix) with ESMTP id 1FF7A2E02F3 for ; Tue, 2 Mar 2004 15:56:44 +0100 (CET) X-AV-Scanned: yes 840730f2897168ae47a9c9ffa5384486 X-AuthUser: sasa@stupar.homelinux.net Received: from stupar.homelinux.net (192.168.10.1:3690) (Linux/Ix86) ESMTP Server]; Tue, 2 Mar 2004 15:56:56 +0100 Message-ID: <4044A0B8.1020103@stupar.homelinux.net> Date: Tue, 02 Mar 2004 15:56:56 +0100 From: Sasa Stupar User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sl-SI; rv:1.6) Gecko/20040113 X-Accept-Language: sl, en-gb, en MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at arnes.si Subject: Converting iptables X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 14:56:46 -0000 Hi! I am thinking to change my old linux router to the freebsd one. The question is: how difficult is to convert iptables into ipfw rules? I need some basic things with that router: - internet gateway for LAN users - packet filtering with MAC/IP address filtering - port forwarding - NAT onto same network so that LAN users can access web server which is on the LAN also Is this all possible with ipfw? Regards, Sasa From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 2 11:44:43 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A870316A4CF for ; Tue, 2 Mar 2004 11:44:43 -0800 (PST) Received: from www.eviloverlord.org (bgp962005bgs.derbrn01.mi.comcast.net [68.41.90.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0356F43D39 for ; Tue, 2 Mar 2004 11:44:43 -0800 (PST) (envelope-from mgoward@eviloverlord.org) Received: from www.eviloverlord.org (localhost [127.0.0.1]) by www.eviloverlord.org (8.12.10/8.12.10) with ESMTP id i22EaPb3031464 for ; Tue, 2 Mar 2004 14:36:25 GMT (envelope-from mgoward@eviloverlord.org) Received: (from mgoward@localhost) by www.eviloverlord.org (8.12.10/8.12.10/Submit) id i22EaPaO031463 for freebsd-ipfw@freebsd.org; Tue, 2 Mar 2004 14:36:25 GMT (envelope-from mgoward) Date: Tue, 2 Mar 2004 14:36:24 +0000 From: Matt To: freebsd-ipfw@freebsd.org Message-ID: <20040302143624.GA29286@IneedAname.eviloverlord.org> Mail-Followup-To: freebsd-ipfw@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Code snippit to add ipfw rule. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 19:44:43 -0000 Part of an app I am playing with needs to be able to add an ipfw rule. I had though i got all of what i need from ipfw2.c and ip_fw.h but I am painfully new to C and must be missing something. Not even sure how i can get myself a more usefull error message. Any point in the right direction would be great. Thank you. 5.2.1R. Kernel is all set. firewall works fine with the real ipfw client. When this is built and run: mgoward@IneedAname 1298> gcc -Wall test.c -o test test.c: In function `main': test.c:134: warning: implicit declaration of function `err' mgoward@IneedAname 1299> sudo ./test Password: test: getsockopt(IP_FW_ADD): Invalid argument mgoward@IneedAname 1300> Here is test.c. Dont mind all the extra includes. They are all used in the bulk of the program and I was to lazy to pick and choose when i pulled this bit out to work on it alone. #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include static ipfw_insn * next_cmd(ipfw_insn *cmd) { cmd += F_LEN(cmd); bzero(cmd, sizeof(*cmd)); return cmd; } /* * conditionally runs the command. */ static int do_cmd(int optname, void *optval, uintptr_t optlen) { static int s = -1; /* the socket */ int i; if (s == -1) s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW); if (optname == IP_FW_GET || optname == IP_DUMMYNET_GET || optname == IP_FW_ADD) i = getsockopt(s, IPPROTO_IP, optname, optval, (socklen_t *)optlen); else i = setsockopt(s, IPPROTO_IP, optname, optval, optlen); return i; } int main () { static uint32_t cmdbuf[255], rulebuf[255]; ipfw_insn *src, *dst, *cmd; int i; struct ip_fw *rule; bzero(cmdbuf, sizeof(cmdbuf)); bzero(rulebuf, sizeof(rulebuf)); rule = (struct ip_fw *)rulebuf; cmd = (ipfw_insn *)cmdbuf; rule->rulenum = 250; rule->set = 2; cmd->opcode = O_ACCEPT; cmd->len = 1; cmd= next_cmd(cmd); /* this will hold our object and mask */ ipfw_insn_ip *d = (ipfw_insn_ip *)cmd; /* ip and mask combo object */ d->o.opcode = O_IP_SRC_MASK; /* get the in_addr in network order */ ascii2addr(AF_INET, "192.168.12.12" , &(d->addr)); ascii2addr(AF_INET, "255.255.255.255" , &(d->mask)); d->o.len = F_INSN_SIZE(ipfw_insn_ip); /* move our command pointer up one step */ cmd = next_cmd(cmd); d = (ipfw_insn_ip *)cmd; d->o.opcode = O_IP_DST_MASK; ascii2addr(AF_INET, "192.168.12.22" , &(d->addr)); ascii2addr(AF_INET, "255.255.255.255" , &(d->mask)); d->o.len = F_INSN_SIZE(ipfw_insn_ip); cmd = next_cmd(cmd); cmd->opcode = O_PROTO; cmd->len = 1; cmd->arg1 = IPPROTO_IPV4; cmd = next_cmd(cmd); dst = (ipfw_insn *)rule->cmd; for (src = (ipfw_insn *)cmdbuf; src != cmd; src += i) { i = F_LEN(src); switch (src->opcode) { case O_LOG: case O_KEEP_STATE: case O_LIMIT: break; default: bcopy(src, dst, i * sizeof(uint32_t)); dst += i; } } rule->act_ofs = dst - rule->cmd; rule->cmd_len = (uint32_t *)dst - (uint32_t *)(rule->cmd); i = (char *)dst - (char *)rule; if (do_cmd(IP_FW_ADD, rule, (uintptr_t)&i) == -1) err(EX_UNAVAILABLE, "getsockopt(%s)", "IP_FW_ADD"); return(1); } Thank you again, Matthew Goward From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 3 14:06:45 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBEF916A4CE; Wed, 3 Mar 2004 14:06:45 -0800 (PST) Received: from oahu.WURLDLINK.NET (oahu.wurldlink.net [66.193.144.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A53043D39; Wed, 3 Mar 2004 14:06:45 -0800 (PST) (envelope-from vince@oahu.WURLDLINK.NET) Received: from oahu.WURLDLINK.NET (vince@localhost.WURLDLINK.NET [127.0.0.1]) by oahu.WURLDLINK.NET (8.12.9/8.12.9) with ESMTP id i23M6AqQ089026; Wed, 3 Mar 2004 12:06:10 -1000 (HST) Received: from localhost (vince@localhost)i23M6AkT089023; Wed, 3 Mar 2004 12:06:10 -1000 (HST) Date: Wed, 3 Mar 2004 12:06:10 -1000 (HST) From: Vincent Poy To: freebsd-net@freebsd.org, Message-ID: <20040303120211.O8264-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: ipfw/dummynet pipe size, is there a burst setting? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2004 22:06:45 -0000 Hello everyone: On FreeBSD with ipfw/dummynet for traffic shaping, one uses the pipe with: ipfw pipe 1 config bw size to set the size of the pipe. I noticed on Linux, they can set a burst size so it can burst a x number over the pipe size, is there a similar setting available? Also, I noticed for pipes, one can set the queue size in slots of KBytes, how does one determine what's a good size? Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 3 15:04:49 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9435C16A4CE for ; Wed, 3 Mar 2004 15:04:49 -0800 (PST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8692943D1D for ; Wed, 3 Mar 2004 15:04:49 -0800 (PST) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i23N4nmC019113 for ; Wed, 3 Mar 2004 15:04:49 -0800 (PST) Received: from [10.1.1.193] ([199.103.21.225]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id i23N4mlf026336 for ; Wed, 3 Mar 2004 15:04:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <20040303120211.O8264-100000@oahu.WURLDLINK.NET> References: <20040303120211.O8264-100000@oahu.WURLDLINK.NET> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <34868EFE-6D67-11D8-85AD-003065ABFD92@mac.com> Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org From: Charles Swiger Date: Wed, 3 Mar 2004 18:05:03 -0500 X-Mailer: Apple Mail (2.612) Subject: Re: ipfw/dummynet pipe size, is there a burst setting? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2004 23:04:49 -0000 On Mar 3, 2004, at 5:06 PM, Vincent Poy wrote: > ipfw pipe 1 config bw size > > to set the size of the pipe. I noticed on Linux, they can set a burst > size so it can burst a x number over the pipe size, is there a similar > setting available? I'm not sure I understand the semantics of this? How much bandwidth is available when using this burst mechanism-- and what traffic goes through when several things try to burst at once, for example? Anyway, you can use different weighted queues feeding into larger-sized pipe that will probably "do what you want"... > Also, I noticed for pipes, one can set the queue size > in slots of KBytes, how does one determine what's a good size? Consider the cross-product of network bandwidth times latency for your situation; a discussion of how to tweak the TCP receive window size is closely related... -- -Chuck From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 3 20:30:25 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 284AF16A4CE for ; Wed, 3 Mar 2004 20:30:25 -0800 (PST) Received: from oahu.WURLDLINK.NET (oahu.wurldlink.net [66.193.144.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id D552343D3F for ; Wed, 3 Mar 2004 20:30:24 -0800 (PST) (envelope-from vince@oahu.WURLDLINK.NET) Received: from oahu.WURLDLINK.NET (vince@localhost.WURLDLINK.NET [127.0.0.1]) by oahu.WURLDLINK.NET (8.12.9/8.12.9) with ESMTP id i244TmqQ095731; Wed, 3 Mar 2004 18:29:49 -1000 (HST) Received: from localhost (vince@localhost)i244TmGB095728; Wed, 3 Mar 2004 18:29:48 -1000 (HST) Date: Wed, 3 Mar 2004 18:29:48 -1000 (HST) From: Vincent Poy To: Charles Swiger In-Reply-To: <34868EFE-6D67-11D8-85AD-003065ABFD92@mac.com> Message-ID: <20040303182412.F8264-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw/dummynet pipe size, is there a burst setting? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2004 04:30:25 -0000 On Wed, 3 Mar 2004, Charles Swiger wrote: > On Mar 3, 2004, at 5:06 PM, Vincent Poy wrote: > > ipfw pipe 1 config bw size > > > > to set the size of the pipe. I noticed on Linux, they can set a burst > > size so it can burst a x number over the pipe size, is there a similar > > setting available? > > I'm not sure I understand the semantics of this? How much bandwidth is > available when using this burst mechanism-- and what traffic goes > through when several things try to burst at once, for example? I think the way the burst mechanism works is similar to ETinc's bandwidth manager in a way where it will burst up to 6KB/sec if it's available or something because I noticed their pipe size is like 490kbps for example and then they have a 420kbps setting for the lower weighted stuff and then a 6kbps burst. Maybe the burst is for the 420kbps. > Anyway, you can use different weighted queues feeding into larger-sized > pipe that will probably "do what you want"... That's what I'm doing except the issue is that with a pipe that can do 5200kbps/529kbps without shaping, as only up is the one that's important. Setting the pipe to 521kbps will give it close to 521kbps in upstream but the downstream is about 1500kbps. Then when the up pipe is set to 490kbps, the downstream is about 3000kbps. The only way to get anywhere near 5200kbps simultaneously up/down is with the up pipe at 400kbps. Is there a way to set it so that it will automatically try to use a certain larger sized pipe if there is no download traffic? > > Also, I noticed for pipes, one can set the queue size > > in slots of KBytes, how does one determine what's a good size? > > Consider the cross-product of network bandwidth times latency for your > situation; a discussion of how to tweak the TCP receive window size is > closely related... Hmm, the man pages doesn't really explain how this one works or how to calculate the size. Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 6 01:27:24 2004 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AC3816A4CE; Sat, 6 Mar 2004 01:27:24 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EBE243D2D; Sat, 6 Mar 2004 01:27:24 -0800 (PST) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) i269RObv091375; Sat, 6 Mar 2004 01:27:24 -0800 (PST) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i269RO94091371; Sat, 6 Mar 2004 01:27:24 -0800 (PST) (envelope-from kris) Date: Sat, 6 Mar 2004 01:27:24 -0800 (PST) From: Kris Kennaway Message-Id: <200403060927.i269RO94091371@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: misc/63724: IPFW2 Queues dont t work X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2004 09:27:24 -0000 Synopsis: IPFW2 Queues dont t work Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: kris Responsible-Changed-When: Sat Mar 6 01:27:14 PST 2004 Responsible-Changed-Why: Assign to ipfw mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=63724 From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 6 03:19:25 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7800916A4CE for ; Sat, 6 Mar 2004 03:19:25 -0800 (PST) Received: from numeri.campus.luth.se (numeri.campus.luth.se [130.240.197.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEAE943D1F for ; Sat, 6 Mar 2004 03:19:24 -0800 (PST) (envelope-from k@numeri.campus.luth.se) Received: from numeri.campus.luth.se (localhost [127.0.0.1]) i26BJNT9012199 for ; Sat, 6 Mar 2004 12:19:23 +0100 (CET) (envelope-from k@numeri.campus.luth.se) Received: (from k@localhost) by numeri.campus.luth.se (8.12.10/8.12.10/Submit) id i26BJNnx012196 for ipfw@freebsd.org; Sat, 6 Mar 2004 12:19:23 +0100 (CET) (envelope-from k) Date: Sat, 6 Mar 2004 12:19:22 +0100 From: Johan Karlsson To: ipfw@freebsd.org Message-ID: <20040306111922.GA64109@numeri.campus.luth.se> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: WARNS cleanup for ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2004 11:19:25 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi the attached patch makes ipfw WARNS=2 clean by using the %j/(uintmax_t) combo where so needed. If there are no objections I intend to commit this patch. take care /Johan K -- Johan Karlsson mailto:johan@FreeBSD.org --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipfw.diff" Index: sbin/ipfw/Makefile =================================================================== RCS file: /home/ncvs/src/sbin/ipfw/Makefile,v retrieving revision 1.12 diff -u -r1.12 Makefile --- sbin/ipfw/Makefile 11 Jul 2002 17:33:37 -0000 1.12 +++ sbin/ipfw/Makefile 5 Mar 2004 22:06:10 -0000 @@ -2,7 +2,7 @@ PROG= ipfw SRCS= ipfw2.c -WARNS?= 0 +WARNS?= 2 MAN= ipfw.8 .include Index: sbin/ipfw/ipfw2.c =================================================================== RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v retrieving revision 1.45 diff -u -r1.45 ipfw2.c --- sbin/ipfw/ipfw2.c 24 Jan 2004 19:20:09 -0000 1.45 +++ sbin/ipfw/ipfw2.c 5 Mar 2004 22:05:38 -0000 @@ -36,6 +36,7 @@ #include #include #include +#include #include #include #include @@ -902,8 +903,9 @@ printf("%05u ", rule->rulenum); if (pcwidth>0 || bcwidth>0) - printf("%*llu %*llu ", pcwidth, align_uint64(&rule->pcnt), - bcwidth, align_uint64(&rule->bcnt)); + printf("%*ju %*ju ", pcwidth, + (uintmax_t)align_uint64(&rule->pcnt), + bcwidth, (uintmax_t)align_uint64(&rule->bcnt)); if (do_time == 2) printf("%10u ", rule->timestamp); @@ -1331,9 +1333,9 @@ bcopy(&d->rule, &rulenum, sizeof(rulenum)); printf("%05d", rulenum); if (pcwidth>0 || bcwidth>0) - printf(" %*llu %*llu (%ds)", pcwidth, - align_uint64(&d->pcnt), bcwidth, - align_uint64(&d->bcnt), d->expire); + printf(" %*ju %*ju (%ds)", pcwidth, + (uintmax_t)align_uint64(&d->pcnt), bcwidth, + (uintmax_t)align_uint64(&d->bcnt), d->expire); switch (d->dyn_type) { case O_LIMIT_PARENT: printf(" PARENT %d", d->count); @@ -1423,12 +1425,12 @@ ina.s_addr = htonl(q[l].id.dst_ip); printf("%15s/%-5d ", inet_ntoa(ina), q[l].id.dst_port); - printf("%4qu %8qu %2u %4u %3u\n", - q[l].tot_pkts, q[l].tot_bytes, + printf("%4ju %8ju %2u %4u %3u\n", + (uintmax_t)q[l].tot_pkts, (uintmax_t)q[l].tot_bytes, q[l].len, q[l].len_bytes, q[l].drops); if (verbose) - printf(" S %20qd F %20qd\n", - q[l].S, q[l].F); + printf(" S %20jd F %20jd\n", + (intmax_t)q[l].S, (intmax_t)q[l].F); } } @@ -1517,7 +1519,7 @@ p->pipe_nr, buf, p->delay); print_flowset_parms(&(p->fs), prefix); if (verbose) - printf(" V %20qd\n", p->V >> MY_M); + printf(" V %20jd\n", (intmax_t)p->V >> MY_M); q = (struct dn_flow_queue *)(p+1); list_queues(&(p->fs), q); @@ -1743,27 +1745,27 @@ if (show_counters) { for (n = 0, r = data; n < nstat; n++, r = NEXT(r)) { /* packet counter */ - width = snprintf(NULL, 0, "%llu", - align_uint64(&r->pcnt)); + width = snprintf(NULL, 0, "%ju", + (uintmax_t)align_uint64(&r->pcnt)); if (width > pcwidth) pcwidth = width; /* byte counter */ - width = snprintf(NULL, 0, "%llu", - align_uint64(&r->bcnt)); + width = snprintf(NULL, 0, "%ju", + (uintmax_t)align_uint64(&r->bcnt)); if (width > bcwidth) bcwidth = width; } } if (do_dynamic && ndyn) { for (n = 0, d = dynrules; n < ndyn; n++, d++) { - width = snprintf(NULL, 0, "%llu", - align_uint64(&d->pcnt)); + width = snprintf(NULL, 0, "%ju", + (uintmax_t)align_uint64(&d->pcnt)); if (width > pcwidth) pcwidth = width; - width = snprintf(NULL, 0, "%llu", - align_uint64(&d->bcnt)); + width = snprintf(NULL, 0, "%ju", + (uintmax_t)align_uint64(&d->bcnt)); if (width > bcwidth) bcwidth = width; } --x+6KMIRAuhnl3hBn-- From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 6 08:26:25 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF2D016A4CE; Sat, 6 Mar 2004 08:26:25 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D25143D1D; Sat, 6 Mar 2004 08:26:25 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i26GQP9Q036794; Sat, 6 Mar 2004 08:26:25 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i26GQPrX036793; Sat, 6 Mar 2004 08:26:25 -0800 (PST) (envelope-from rizzo) Date: Sat, 6 Mar 2004 08:26:25 -0800 From: Luigi Rizzo To: Johan Karlsson Message-ID: <20040306082625.B34490@xorpc.icir.org> References: <20040306111922.GA64109@numeri.campus.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040306111922.GA64109@numeri.campus.luth.se>; from johan@freebsd.org on Sat, Mar 06, 2004 at 12:19:22PM +0100 cc: ipfw@freebsd.org Subject: Re: WARNS cleanup for ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2004 16:26:25 -0000 On Sat, Mar 06, 2004 at 12:19:22PM +0100, Johan Karlsson wrote: > Hi > > the attached patch makes ipfw WARNS=2 clean by using the > %j/(uintmax_t) combo where so needed. If there are no > objections I intend to commit this patch. if align_uint64() is always cast to uintmax_t, why don't you define it to return the proper type instead ? Also, where do %j/uintmax_t stand in terms of standards ? certainly the gcc in 4.x does not like them... cheers luigi > take care > /Johan K > > -- > Johan Karlsson mailto:johan@FreeBSD.org > Index: sbin/ipfw/Makefile > =================================================================== > RCS file: /home/ncvs/src/sbin/ipfw/Makefile,v > retrieving revision 1.12 > diff -u -r1.12 Makefile > --- sbin/ipfw/Makefile 11 Jul 2002 17:33:37 -0000 1.12 > +++ sbin/ipfw/Makefile 5 Mar 2004 22:06:10 -0000 > @@ -2,7 +2,7 @@ > > PROG= ipfw > SRCS= ipfw2.c > -WARNS?= 0 > +WARNS?= 2 > MAN= ipfw.8 > > .include > Index: sbin/ipfw/ipfw2.c > =================================================================== > RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v > retrieving revision 1.45 > diff -u -r1.45 ipfw2.c > --- sbin/ipfw/ipfw2.c 24 Jan 2004 19:20:09 -0000 1.45 > +++ sbin/ipfw/ipfw2.c 5 Mar 2004 22:05:38 -0000 > @@ -36,6 +36,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -902,8 +903,9 @@ > printf("%05u ", rule->rulenum); > > if (pcwidth>0 || bcwidth>0) > - printf("%*llu %*llu ", pcwidth, align_uint64(&rule->pcnt), > - bcwidth, align_uint64(&rule->bcnt)); > + printf("%*ju %*ju ", pcwidth, > + (uintmax_t)align_uint64(&rule->pcnt), > + bcwidth, (uintmax_t)align_uint64(&rule->bcnt)); > > if (do_time == 2) > printf("%10u ", rule->timestamp); > @@ -1331,9 +1333,9 @@ > bcopy(&d->rule, &rulenum, sizeof(rulenum)); > printf("%05d", rulenum); > if (pcwidth>0 || bcwidth>0) > - printf(" %*llu %*llu (%ds)", pcwidth, > - align_uint64(&d->pcnt), bcwidth, > - align_uint64(&d->bcnt), d->expire); > + printf(" %*ju %*ju (%ds)", pcwidth, > + (uintmax_t)align_uint64(&d->pcnt), bcwidth, > + (uintmax_t)align_uint64(&d->bcnt), d->expire); > switch (d->dyn_type) { > case O_LIMIT_PARENT: > printf(" PARENT %d", d->count); > @@ -1423,12 +1425,12 @@ > ina.s_addr = htonl(q[l].id.dst_ip); > printf("%15s/%-5d ", > inet_ntoa(ina), q[l].id.dst_port); > - printf("%4qu %8qu %2u %4u %3u\n", > - q[l].tot_pkts, q[l].tot_bytes, > + printf("%4ju %8ju %2u %4u %3u\n", > + (uintmax_t)q[l].tot_pkts, (uintmax_t)q[l].tot_bytes, > q[l].len, q[l].len_bytes, q[l].drops); > if (verbose) > - printf(" S %20qd F %20qd\n", > - q[l].S, q[l].F); > + printf(" S %20jd F %20jd\n", > + (intmax_t)q[l].S, (intmax_t)q[l].F); > } > } > > @@ -1517,7 +1519,7 @@ > p->pipe_nr, buf, p->delay); > print_flowset_parms(&(p->fs), prefix); > if (verbose) > - printf(" V %20qd\n", p->V >> MY_M); > + printf(" V %20jd\n", (intmax_t)p->V >> MY_M); > > q = (struct dn_flow_queue *)(p+1); > list_queues(&(p->fs), q); > @@ -1743,27 +1745,27 @@ > if (show_counters) { > for (n = 0, r = data; n < nstat; n++, r = NEXT(r)) { > /* packet counter */ > - width = snprintf(NULL, 0, "%llu", > - align_uint64(&r->pcnt)); > + width = snprintf(NULL, 0, "%ju", > + (uintmax_t)align_uint64(&r->pcnt)); > if (width > pcwidth) > pcwidth = width; > > /* byte counter */ > - width = snprintf(NULL, 0, "%llu", > - align_uint64(&r->bcnt)); > + width = snprintf(NULL, 0, "%ju", > + (uintmax_t)align_uint64(&r->bcnt)); > if (width > bcwidth) > bcwidth = width; > } > } > if (do_dynamic && ndyn) { > for (n = 0, d = dynrules; n < ndyn; n++, d++) { > - width = snprintf(NULL, 0, "%llu", > - align_uint64(&d->pcnt)); > + width = snprintf(NULL, 0, "%ju", > + (uintmax_t)align_uint64(&d->pcnt)); > if (width > pcwidth) > pcwidth = width; > > - width = snprintf(NULL, 0, "%llu", > - align_uint64(&d->bcnt)); > + width = snprintf(NULL, 0, "%ju", > + (uintmax_t)align_uint64(&d->bcnt)); > if (width > bcwidth) > bcwidth = width; > } > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 6 10:29:07 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F063216A4CE for ; Sat, 6 Mar 2004 10:29:06 -0800 (PST) Received: from mx2.ndsoftware.net (ns2.ndsoftware.net [195.140.149.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63ADE43D3F for ; Sat, 6 Mar 2004 10:29:06 -0800 (PST) (envelope-from nicolas.deffayet@ndsoftware.net) Received: from nat.gw1.par1.fr.corp.ndsoftware.net ([195.140.149.50] helo=w1-par1-fr.corp.ndsoftware.com) by mx2.ndsoftware.net with esmtp (Exim 3.35 #1 (Debian)) id 1AzgXp-0000R8-00 for ; Sat, 06 Mar 2004 19:29:05 +0100 From: Nicolas DEFFAYET To: freebsd-ipfw@freebsd.org Content-Type: text/plain Organization: NDSoftware Message-Id: <1078597745.1981.15.camel@w1-par1-fr.corp.ndsoftware.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 06 Mar 2004 19:29:05 +0100 Content-Transfer-Encoding: 7bit Subject: Latency problem with traffic shaping X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2004 18:29:07 -0000 Hello, I have latency problem when i do traffic shaping with ipfw: $ ping -c 10 xxx.xxx.xx1.2 PING xxx.xxx.xx1.2 (xxx.xxx.xx1.2): 56 data bytes 64 bytes from xxx.xxx.xx1.2: icmp_seq=0 ttl=64 time=1.037 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=1 ttl=64 time=1.951 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=2 ttl=64 time=1.924 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=3 ttl=64 time=1.852 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=4 ttl=64 time=2.779 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=5 ttl=64 time=1.982 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=6 ttl=64 time=1.778 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=7 ttl=64 time=1.866 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=8 ttl=64 time=1.777 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=9 ttl=64 time=1.876 ms --- xxx.xxx.xx1.2 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.037/1.882/2.779/0.395 ms Current maximum traffic is 6 Mbit/s, shapping is at 35 Mbit/s. I use a vlan interface but i have same problem with a physical interface: $ ifconfig vlan3 vlan3: flags=8843 mtu 1500 inet xxx.xxx.xx1.1 netmask 0xfffffffc broadcast xxx.xxx.xx1.3 I use very simple rules: # ipfw sh 03000 195958827 88359539155 pipe 1 ip from any to any out via vlan3 03000 145717180 37638278479 pipe 1 ip from any to any in via vlan3 65535 7732545351 2700054229295 allow ip from any to any # ipfw pipe sh 00001: 35.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 igmp xxx.xxx.xx1.1/0 224.0.0.5/0 341678025 125998357178 0 0 295 If the rule 3000 of ipfw is deleted, latency is good and normal; but i don't have shaping: $ ping -c 10 xxx.xxx.xx1.2 PING xxx.xxx.xx1.2 (xxx.xxx.xx1.2): 56 data bytes 64 bytes from xxx.xxx.xx1.2: icmp_seq=0 ttl=64 time=0.375 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=1 ttl=64 time=0.219 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=2 ttl=64 time=0.251 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=3 ttl=64 time=0.281 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=4 ttl=64 time=0.290 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=5 ttl=64 time=0.308 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=6 ttl=64 time=0.380 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=7 ttl=64 time=0.254 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=8 ttl=64 time=0.227 ms 64 bytes from xxx.xxx.xx1.2: icmp_seq=9 ttl=64 time=0.227 ms --- xxx.xxx.xx1.2 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.219/0.281/0.380/0.055 ms I don't have the problem with FreeBSD 5.0-RELEASE. I have the problem with FreeBSD 5.1-RELEASE, FreeBSD 5.2-RELEASE, FreeBSD 5.2.1-RELEASE. I use a custom kernel with: options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPV6FIREWALL #firewall for IPv6 options IPV6FIREWALL_VERBOSE options IPV6FIREWALL_VERBOSE_LIMIT=100 options IPV6FIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT #divert sockets options DUMMYNET options BRIDGE How fix this latency problem ? Thanks Best regards, -- Nicolas DEFFAYET, NDSoftware NDSoftware IP Network: http://www.ip.ndsoftware.net/ FNIX6 (French National Internet Exchange IPv6): http://www.fnix6.net/ From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 6 15:31:31 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD0C216A4CE for ; Sat, 6 Mar 2004 15:31:31 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7856943D1F for ; Sat, 6 Mar 2004 15:31:31 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i26NVV9Q046273; Sat, 6 Mar 2004 15:31:31 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i26NVVOF046272; Sat, 6 Mar 2004 15:31:31 -0800 (PST) (envelope-from rizzo) Date: Sat, 6 Mar 2004 15:31:31 -0800 From: Luigi Rizzo To: Nicolas DEFFAYET Message-ID: <20040306153131.A46112@xorpc.icir.org> References: <1078597745.1981.15.camel@w1-par1-fr.corp.ndsoftware.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: <1078597745.1981.15.camel@w1-par1-fr.corp.ndsoftware.com>; from nicolas.deffayet@ndsoftware.net on Sat, Mar 06, 2004 at 07:29:05PM +0100 cc: freebsd-ipfw@freebsd.org Subject: Re: Latency problem with traffic shaping X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2004 23:31:31 -0000 so where is the problem ? 1ms is the granularity of the timer, so it is hard to go below, and any packet that you happen to find in front of you might cause further delay. (1500bytes = 12000 bit = 0.3ms for your 35Mbit pipe). Additionally, you have a curious ipfw config, with both input and output traffic competing for the same pipe (and, "in via" and "out via" are probably not what you want). cheers luigi On Sat, Mar 06, 2004 at 07:29:05PM +0100, Nicolas DEFFAYET wrote: > Hello, > > I have latency problem when i do traffic shaping with ipfw: > > $ ping -c 10 xxx.xxx.xx1.2 > PING xxx.xxx.xx1.2 (xxx.xxx.xx1.2): 56 data bytes > 64 bytes from xxx.xxx.xx1.2: icmp_seq=0 ttl=64 time=1.037 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=1 ttl=64 time=1.951 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=2 ttl=64 time=1.924 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=3 ttl=64 time=1.852 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=4 ttl=64 time=2.779 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=5 ttl=64 time=1.982 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=6 ttl=64 time=1.778 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=7 ttl=64 time=1.866 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=8 ttl=64 time=1.777 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=9 ttl=64 time=1.876 ms > > --- xxx.xxx.xx1.2 ping statistics --- > 10 packets transmitted, 10 packets received, 0% packet loss > round-trip min/avg/max/stddev = 1.037/1.882/2.779/0.395 ms > > Current maximum traffic is 6 Mbit/s, shapping is at 35 Mbit/s. > > > I use a vlan interface but i have same problem with a physical > interface: > > $ ifconfig vlan3 > vlan3: flags=8843 mtu 1500 > inet xxx.xxx.xx1.1 netmask 0xfffffffc broadcast xxx.xxx.xx1.3 > > > > I use very simple rules: > > # ipfw sh > 03000 195958827 88359539155 pipe 1 ip from any to any out via vlan3 > 03000 145717180 37638278479 pipe 1 ip from any to any in via vlan3 > 65535 7732545351 2700054229295 allow ip from any to any > > # ipfw pipe sh > 00001: 35.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 0 igmp xxx.xxx.xx1.1/0 224.0.0.5/0 341678025 > 125998357178 0 0 295 > > > If the rule 3000 of ipfw is deleted, latency is good and normal; but i > don't have shaping: > > $ ping -c 10 xxx.xxx.xx1.2 > PING xxx.xxx.xx1.2 (xxx.xxx.xx1.2): 56 data bytes > 64 bytes from xxx.xxx.xx1.2: icmp_seq=0 ttl=64 time=0.375 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=1 ttl=64 time=0.219 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=2 ttl=64 time=0.251 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=3 ttl=64 time=0.281 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=4 ttl=64 time=0.290 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=5 ttl=64 time=0.308 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=6 ttl=64 time=0.380 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=7 ttl=64 time=0.254 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=8 ttl=64 time=0.227 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=9 ttl=64 time=0.227 ms > > --- xxx.xxx.xx1.2 ping statistics --- > 10 packets transmitted, 10 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.219/0.281/0.380/0.055 ms > > > I don't have the problem with FreeBSD 5.0-RELEASE. > I have the problem with FreeBSD 5.1-RELEASE, FreeBSD 5.2-RELEASE, > FreeBSD 5.2.1-RELEASE. > > I use a custom kernel with: > > options IPFIREWALL #firewall > options IPFIREWALL_VERBOSE #enable logging to syslogd(8) > options IPFIREWALL_FORWARD #enable transparent proxy > support > options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity > options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by > default > options IPV6FIREWALL #firewall for IPv6 > options IPV6FIREWALL_VERBOSE > options IPV6FIREWALL_VERBOSE_LIMIT=100 > options IPV6FIREWALL_DEFAULT_TO_ACCEPT > options IPDIVERT #divert sockets > options DUMMYNET > options BRIDGE > > > How fix this latency problem ? > > > Thanks > > Best regards, > > -- > Nicolas DEFFAYET, NDSoftware > NDSoftware IP Network: http://www.ip.ndsoftware.net/ > FNIX6 (French National Internet Exchange IPv6): http://www.fnix6.net/ > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 6 16:11:30 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A11516A4CE for ; Sat, 6 Mar 2004 16:11:30 -0800 (PST) Received: from oahu.WURLDLINK.NET (oahu.wurldlink.net [66.193.144.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8F6143D1D for ; Sat, 6 Mar 2004 16:11:29 -0800 (PST) (envelope-from vince@oahu.WURLDLINK.NET) Received: from oahu.WURLDLINK.NET (vince@localhost.WURLDLINK.NET [127.0.0.1]) by oahu.WURLDLINK.NET (8.12.9/8.12.9) with ESMTP id i270AZqQ070393; Sat, 6 Mar 2004 14:10:45 -1000 (HST) Received: from localhost (vince@localhost)i270AYpN070390; Sat, 6 Mar 2004 14:10:35 -1000 (HST) Date: Sat, 6 Mar 2004 14:10:34 -1000 (HST) From: Vincent Poy To: Nicolas DEFFAYET In-Reply-To: <1078597745.1981.15.camel@w1-par1-fr.corp.ndsoftware.com> Message-ID: <20040306140955.T8264-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-ipfw@freebsd.org Subject: Re: Latency problem with traffic shaping X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2004 00:11:30 -0000 On Sat, 6 Mar 2004, Nicolas DEFFAYET wrote: > Hello, > > I have latency problem when i do traffic shaping with ipfw: > > $ ping -c 10 xxx.xxx.xx1.2 > PING xxx.xxx.xx1.2 (xxx.xxx.xx1.2): 56 data bytes > 64 bytes from xxx.xxx.xx1.2: icmp_seq=0 ttl=64 time=1.037 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=1 ttl=64 time=1.951 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=2 ttl=64 time=1.924 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=3 ttl=64 time=1.852 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=4 ttl=64 time=2.779 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=5 ttl=64 time=1.982 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=6 ttl=64 time=1.778 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=7 ttl=64 time=1.866 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=8 ttl=64 time=1.777 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=9 ttl=64 time=1.876 ms > > --- xxx.xxx.xx1.2 ping statistics --- > 10 packets transmitted, 10 packets received, 0% packet loss > round-trip min/avg/max/stddev = 1.037/1.882/2.779/0.395 ms > > Current maximum traffic is 6 Mbit/s, shapping is at 35 Mbit/s. > > > I use a vlan interface but i have same problem with a physical > interface: > > $ ifconfig vlan3 > vlan3: flags=8843 mtu 1500 > inet xxx.xxx.xx1.1 netmask 0xfffffffc broadcast xxx.xxx.xx1.3 > > > > I use very simple rules: > > # ipfw sh > 03000 195958827 88359539155 pipe 1 ip from any to any out via vlan3 > 03000 145717180 37638278479 pipe 1 ip from any to any in via vlan3 > 65535 7732545351 2700054229295 allow ip from any to any > > # ipfw pipe sh > 00001: 35.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 0 igmp xxx.xxx.xx1.1/0 224.0.0.5/0 341678025 > 125998357178 0 0 295 > > > If the rule 3000 of ipfw is deleted, latency is good and normal; but i > don't have shaping: > > $ ping -c 10 xxx.xxx.xx1.2 > PING xxx.xxx.xx1.2 (xxx.xxx.xx1.2): 56 data bytes > 64 bytes from xxx.xxx.xx1.2: icmp_seq=0 ttl=64 time=0.375 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=1 ttl=64 time=0.219 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=2 ttl=64 time=0.251 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=3 ttl=64 time=0.281 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=4 ttl=64 time=0.290 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=5 ttl=64 time=0.308 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=6 ttl=64 time=0.380 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=7 ttl=64 time=0.254 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=8 ttl=64 time=0.227 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=9 ttl=64 time=0.227 ms > > --- xxx.xxx.xx1.2 ping statistics --- > 10 packets transmitted, 10 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.219/0.281/0.380/0.055 ms > > > I don't have the problem with FreeBSD 5.0-RELEASE. > I have the problem with FreeBSD 5.1-RELEASE, FreeBSD 5.2-RELEASE, > FreeBSD 5.2.1-RELEASE. > > I use a custom kernel with: > > options IPFIREWALL #firewall > options IPFIREWALL_VERBOSE #enable logging to syslogd(8) > options IPFIREWALL_FORWARD #enable transparent proxy > support > options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity > options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by > default > options IPV6FIREWALL #firewall for IPv6 > options IPV6FIREWALL_VERBOSE > options IPV6FIREWALL_VERBOSE_LIMIT=100 > options IPV6FIREWALL_DEFAULT_TO_ACCEPT > options IPDIVERT #divert sockets > options DUMMYNET > options BRIDGE > > > How fix this latency problem ? Not much except maybe read dummynet(4) manpage and look at the HZ option in the kernel. Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 6 21:22:34 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98FD416A4CE; Sat, 6 Mar 2004 21:22:34 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B5FC43D1F; Sat, 6 Mar 2004 21:22:34 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i275MX9Q057340; Sat, 6 Mar 2004 21:22:33 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i275MXba057339; Sat, 6 Mar 2004 21:22:33 -0800 (PST) (envelope-from rizzo) Date: Sat, 6 Mar 2004 21:22:33 -0800 From: Luigi Rizzo To: Johan Karlsson Message-ID: <20040306212233.A56351@xorpc.icir.org> References: <20040306111922.GA64109@numeri.campus.luth.se> <20040306082625.B34490@xorpc.icir.org> <20040306173219.GB64109@numeri.campus.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040306173219.GB64109@numeri.campus.luth.se>; from johan@freebsd.org on Sat, Mar 06, 2004 at 06:32:19PM +0100 cc: ipfw@freebsd.org Subject: Re: where do %j/uintmax_t stand in terms of standards? [WAS: Re: WARNS cleanup for ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2004 05:22:34 -0000 On Sat, Mar 06, 2004 at 06:32:19PM +0100, Johan Karlsson wrote: > [lets move this from ipfw@ to standars@ to get an answer] > > > On Sat, Mar 06, 2004 at 08:26 (-0800) +0000, Luigi Rizzo wrote: > > On Sat, Mar 06, 2004 at 12:19:22PM +0100, Johan Karlsson wrote: > > > Hi > > > > > > the attached patch makes ipfw WARNS=2 clean by using the > > > %j/(uintmax_t) combo where so needed. If there are no > > > objections I intend to commit this patch. > > First of all, %j/uintmax_t is used since uint64_t does not match > long long on all our platforms. Hence to print this without warning > we need to do this. ok, given that our counters _are_ 64 bits on all platforms, and that it would be nice to use the same code on 4.x and 5.x (at least, I'd hate to see a large number of differences for something trivial as a printf specifier), i suggest to leave the print format as "%llu", which is supported on all versions and platforms, and change align_uint64() as following: -static __inline uint64_t +static unsigned long long align_uint64(uint64_t *pll) { uint64_t ret; + /* make sure the value is correctly aligned, as pll might be not */ bcopy (pll, &ret, sizeof(ret)); - return ret; + return (unsigned long long)ret; }; (we do not care about __inline since this is always called within a *printf() which is way more expensive). This should close the issue, and is a lot more readable and portable than the proposed patch or my previous suggestion. cheers luigi