From owner-freebsd-net@FreeBSD.ORG Sun Jan 9 09:23:25 2005 Return-Path: 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 3FEB216A4CE for ; Sun, 9 Jan 2005 09:23:25 +0000 (GMT) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 959F743D49 for ; Sun, 9 Jan 2005 09:23:24 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 6323 invoked from network); 9 Jan 2005 09:23:22 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 9 Jan 2005 09:23:22 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 9 Jan 2005 03:23:21 -0600 (CST) From: Mike Silbersack To: net@freebsd.org Message-ID: <20050109031431.H2669@odysseus.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-835642382-1105262178=:2669" Content-ID: <20050109031637.R2669@odysseus.silby.com> Subject: Slipping in the window update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 09:23:25 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-835642382-1105262178=:2669 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: <20050109031637.E2669@odysseus.silby.com> Ok, here's an updated patch for the SYN case. I've included the patch relative to 6.x, and some text from a tcpdump showing it in action. It responds to each SYN with an ACK like the latest tcpsecure document states, but it uses a global counter to rate limit the number of ACKs of this type that it will send to 200 per second. I was unable to incorporate the connect idle heuristic I wanted to because right now the incoming spoofed syns would reset the idle counter, which sounds like it could cause a problem somehow... best not to use it for now. Maybe a future change can clean up that along with the dropafterack case in tcp_input, but that would make this patch far too complex. Please take a look at the patch and the abbreviated tcpdump from my test and see if it looks correct. Thanks, Mike "Silby" Silbersack --0-835642382-1105262178=:2669 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="syn_fix.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20050109031618.H2669@odysseus.silby.com> Content-Description: Content-Disposition: ATTACHMENT; FILENAME="syn_fix.patch" ZGlmZiAtdSAtciAvdXNyL3NyYy9zeXMub2xkL25ldGluZXQvaWNtcF92YXIu aCAvdXNyL3NyYy9zeXMvbmV0aW5ldC9pY21wX3Zhci5oDQotLS0gL3Vzci9z cmMvc3lzLm9sZC9uZXRpbmV0L2ljbXBfdmFyLmgJTW9uIEphbiAgMyAwMDow MzozMSAyMDA1DQorKysgL3Vzci9zcmMvc3lzL25ldGluZXQvaWNtcF92YXIu aAlTdW4gSmFuICA5IDAyOjQ3OjEyIDIwMDUNCkBAIC04MCw5ICs4MCwxMCBA QA0KICNkZWZpbmUgQkFORExJTV9JQ01QX1VOUkVBQ0ggMA0KICNkZWZpbmUg QkFORExJTV9JQ01QX0VDSE8gMQ0KICNkZWZpbmUgQkFORExJTV9JQ01QX1RT VEFNUCAyDQotI2RlZmluZSBCQU5ETElNX1JTVF9DTE9TRURQT1JUIDMgLyog Tm8gY29ubmVjdGlvbiwgYW5kIG5vIGxpc3RlbmVycyAqLw0KLSNkZWZpbmUg QkFORExJTV9SU1RfT1BFTlBPUlQgNCAgIC8qIE5vIGNvbm5lY3Rpb24sIGxp c3RlbmVyICovDQotI2RlZmluZSBCQU5ETElNX01BWCA0DQorI2RlZmluZSBC QU5ETElNX1JTVF9DTE9TRURQT1JUIDMgIC8qIE5vIGNvbm5lY3Rpb24sIGFu ZCBubyBsaXN0ZW5lcnMgKi8NCisjZGVmaW5lIEJBTkRMSU1fUlNUX09QRU5Q T1JUIDQgICAgLyogTm8gY29ubmVjdGlvbiwgbGlzdGVuZXIgKi8NCisjZGVm aW5lIEJBTkRMSU1fU1lOX0VTVEFCTElTSEVEIDUgLyogRXN0YWJsaXNoZWQg Y29ubmVjdCwgU1lOIHJlY2lldmVkICovDQorI2RlZmluZSBCQU5ETElNX01B WCA1DQogI2VuZGlmDQogDQogI2VuZGlmDQpkaWZmIC11IC1yIC91c3Ivc3Jj L3N5cy5vbGQvbmV0aW5ldC9pcF9pY21wLmMgL3Vzci9zcmMvc3lzL25ldGlu ZXQvaXBfaWNtcC5jDQotLS0gL3Vzci9zcmMvc3lzLm9sZC9uZXRpbmV0L2lw X2ljbXAuYwlNb24gSmFuICAzIDAwOjAzOjMxIDIwMDUNCisrKyAvdXNyL3Ny Yy9zeXMvbmV0aW5ldC9pcF9pY21wLmMJU3VuIEphbiAgOSAwMjo0ODo0MCAy MDA1DQpAQCAtODk3LDcgKzg5Nyw4IEBADQogCQl7ICJpY21wIHBpbmcgcmVz cG9uc2UiIH0sDQogCQl7ICJpY21wIHRzdGFtcCByZXNwb25zZSIgfSwNCiAJ CXsgImNsb3NlZCBwb3J0IFJTVCByZXNwb25zZSIgfSwNCi0JCXsgIm9wZW4g cG9ydCBSU1QgcmVzcG9uc2UiIH0NCisJCXsgIm9wZW4gcG9ydCBSU1QgcmVz cG9uc2UiIH0sDQorCQl7ICJBQ0sgZm9yIHVuZXhwZWN0ZWQgU1lOIiB9DQog CX07DQogDQogCS8qDQpkaWZmIC11IC1yIC91c3Ivc3JjL3N5cy5vbGQvbmV0 aW5ldC90Y3BfaW5wdXQuYyAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfaW5w dXQuYw0KLS0tIC91c3Ivc3JjL3N5cy5vbGQvbmV0aW5ldC90Y3BfaW5wdXQu YwlNb24gSmFuICAzIDAxOjExOjQwIDIwMDUNCisrKyAvdXNyL3NyYy9zeXMv bmV0aW5ldC90Y3BfaW5wdXQuYwlTdW4gSmFuICA5IDAyOjUxOjE3IDIwMDUN CkBAIC0xMzYsNiArMTM2LDExIEBADQogICAgICZ0Y3BfaW5zZWN1cmVfcnN0 LCAwLA0KICAgICAiRm9sbG93IHRoZSBvbGQgKGluc2VjdXJlKSBjcml0ZXJp YSBmb3IgYWNjZXB0aW5nIFJTVCBwYWNrZXRzLiIpOw0KIA0KK3N0YXRpYyBp bnQgdGNwX2luc2VjdXJlX3N5biA9IDA7DQorU1lTQ1RMX0lOVChfbmV0X2lu ZXRfdGNwLCBPSURfQVVUTywgaW5zZWN1cmVfc3luLCBDVExGTEFHX1JXLA0K KyAgICAmdGNwX2luc2VjdXJlX3N5biwgMCwNCisgICAgIkZvbGxvdyB0aGUg b2xkIGNyaXRlcmlhIGFsbG93aW5nIFNZTiBwYWNrZXRzIHRvIHJlc2V0IGEg Y29ubmVjdGlvbi4iKTsNCisNCiBTWVNDVExfTk9ERShfbmV0X2luZXRfdGNw LCBPSURfQVVUTywgcmVhc3MsIENUTEZMQUdfUlcsIDAsDQogCSAgICAiVENQ IFNlZ21lbnQgUmVhc3NlbWJseSBRdWV1ZSIpOw0KIA0KQEAgLTE1NjAsNiAr MTU2NSwyMSBAQA0KIAkJCX0NCiAJCX0NCiAJCWdvdG8gZHJvcDsNCisJfQ0K Kw0KKwlpZiAodGhmbGFncyAmIFRIX1NZTikgew0KKwkJaWYgKHRwLT50X3N0 YXRlID09IFRDUFNfRVNUQUJMSVNIRUQgJiYNCisJCSAgICB0Y3BfaW5zZWN1 cmVfc3luID09IDApIHsNCisJCQlpZiAoYmFkcG9ydF9iYW5kbGltKEJBTkRM SU1fU1lOX0VTVEFCTElTSEVEKSA8IDApDQorCQkJCWdvdG8gZHJvcDsNCisJ CQl0Y3BfcmVzcG9uZCh0cCwgbXRvZChtLCB2b2lkICopLCB0aCwgbSwgdHAt PnJjdl9ueHQsDQorCQkJCXRwLT5zbmRfdW5hLCBUSF9BQ0spOw0KKwkJCWlm ICh0cCkNCisJCQkJSU5QX1VOTE9DSyhpbnApOw0KKwkJCWlmIChoZWFkbG9j a2VkKQ0KKwkJCQlJTlBfSU5GT19XVU5MT0NLKCZ0Y2JpbmZvKTsNCisJCQly ZXR1cm47DQorCQl9DQogCX0NCiANCiAJLyoNCg== --0-835642382-1105262178=:2669 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="syn_fix-test.txt" Content-Transfer-Encoding: BASE64 Content-ID: <20050109031618.P2669@odysseus.silby.com> Content-Description: Content-Disposition: ATTACHMENT; FILENAME="syn_fix-test.txt" MDI6NTY6MDMuMzQzNDE5IElQIDEwLjEuMS42LjIyID4gMTAuMS4xLjE1LjMw NDM6IFAgMTcwODk1NTk1OjE3MDg5NTcyMygxMjgpIGFjayAzMzIwNTQ0NTcg d2luIDY1NTM1DQowMjo1NjowMy4zNDM4MDYgSVAgMTAuMS4xLjE1LjMwNDMg PiAxMC4xLjEuNi4yMjogLiBhY2sgMTI4IHdpbiA2NDkxMQ0KMDI6NTY6MDQu MjIzMDQ3IElQIDEwLjEuMS4xNS4zMDQzID4gMTAuMS4xLjYuMjI6IFAgMTo0 OSg0OCkgYWNrIDEyOCB3aW4gNjQ5MTENCjAyOjU2OjA0LjIyMzU1NCBJUCAx MC4xLjEuNi4yMiA+IDEwLjEuMS4xNS4zMDQzOiBQIDEyODoxNzYoNDgpIGFj ayA0OSB3aW4gNjU1MzUNCjAyOjU2OjA0LjIyNDYyOSBJUCAxMC4xLjEuMTUu MzA0MyA+IDEwLjEuMS42LjIyOiBQIDQ5Ojk3KDQ4KSBhY2sgMTc2IHdpbiA2 NDg2Mw0KMDI6NTY6MDQuMjI0OTM3IElQIDEwLjEuMS42LjIyID4gMTAuMS4x LjE1LjMwNDM6IFAgMTc2OjIyNCg0OCkgYWNrIDk3IHdpbiA2NTUzNQ0KMDI6 NTY6MDQuMjI2MjQyIElQIDEwLjEuMS4xNS4zMDQzID4gMTAuMS4xLjYuMjI6 IFAgOTc6MTQ1KDQ4KSBhY2sgMjI0IHdpbiA2NDgxNQ0KMDI6NTY6MDQuMjI2 NTMwIElQIDEwLjEuMS42LjIyID4gMTAuMS4xLjE1LjMwNDM6IFAgMjI0OjI3 Mig0OCkgYWNrIDE0NSB3aW4gNjU1MzUNCjAyOjU2OjA0LjM0OTY5OSBJUCAx MC4xLjEuMTUuMzA0MyA+IDEwLjEuMS42LjIyOiAuIGFjayAyNzIgd2luIDY0 NzY3DQowMjo1NjowNC43NTcwMTIgSVAgMTAuMS4xLjE1LjMwNDMgPiAxMC4x LjEuNi4yMjogUCAxNDU6MTkzKDQ4KSBhY2sgMjcyIHdpbiA2NDc2Nw0KMDI6 NTY6MDQuNzU3MzAzIElQIDEwLjEuMS42LjIyID4gMTAuMS4xLjE1LjMwNDM6 IFAgMjcyOjMyMCg0OCkgYWNrIDE5MyB3aW4gNjU1MzUNCjAyOjU2OjA0Ljg5 NjMyOCBJUCAxMC4xLjEuMTUuMzA0MyA+IDEwLjEuMS42LjIyOiAuIGFjayAz MjAgd2luIDY0NzE5DQowMjo1NjowNS4wMDA0MTAgSVAgMTAuMS4xLjE1LjMw NDMgPiAxMC4xLjEuNi4yMjogUCAxOTM6MjQxKDQ4KSBhY2sgMzIwIHdpbiA2 NDcxOQ0KMDI6NTY6MDUuMDAwNzA5IElQIDEwLjEuMS42LjIyID4gMTAuMS4x LjE1LjMwNDM6IFAgMzIwOjM2OCg0OCkgYWNrIDI0MSB3aW4gNjU1MzUNCjAy OjU2OjA1LjA5MjU2NCBJUCAxMC4xLjEuMTUuMzA0MyA+IDEwLjEuMS42LjIy OiBQIDI0MToyODkoNDgpIGFjayAzNjggd2luIDY0NjcxDQowMjo1NjowNS4w OTI4NTUgSVAgMTAuMS4xLjYuMjIgPiAxMC4xLjEuMTUuMzA0MzogUCAzNjg6 NDE2KDQ4KSBhY2sgMjg5IHdpbiA2NTUzNQ0KMDI6NTY6MDUuMTA2NDk3IElQ IDEwLjEuMS4xNS4zMDQzID4gMTAuMS4xLjYuMjI6IFAgMjg5OjMzNyg0OCkg YWNrIDQxNiB3aW4gNjQ2MjMNCjAyOjU2OjA1LjEwNjc4NCBJUCAxMC4xLjEu Ni4yMiA+IDEwLjEuMS4xNS4zMDQzOiBQIDQxNjo0NjQoNDgpIGFjayAzMzcg d2luIDY1NTM1DQowMjo1NjowNS4xMDgxNDQgSVAgMTAuMS4xLjE1LjMwNDMg PiAxMC4xLjEuNi4yMjogUCAzMzc6Mzg1KDQ4KSBhY2sgNDY0IHdpbiA2NDU3 NQ0KMDI6NTY6MDUuMTA4NDQ1IElQIDEwLjEuMS42LjIyID4gMTAuMS4xLjE1 LjMwNDM6IFAgNDY0OjUxMig0OCkgYWNrIDM4NSB3aW4gNjU1MzUNCjAyOjU2 OjA1LjIxNjgxMyBJUCAxMC4xLjEuMTUuMzA0MyA+IDEwLjEuMS42LjIyOiBQ IDM4NTo0MzMoNDgpIGFjayA1MTIgd2luIDY0NTI3DQowMjo1NjowNS4yMTcx MDEgSVAgMTAuMS4xLjYuMjIgPiAxMC4xLjEuMTUuMzA0MzogUCA1MTI6NTYw KDQ4KSBhY2sgNDMzIHdpbiA2NTUzNQ0KMDI6NTY6MDUuMzAwNTY0IElQIDEw LjEuMS4xNS4zMDQzID4gMTAuMS4xLjYuMjI6IFAgNDMzOjQ4MSg0OCkgYWNr IDU2MCB3aW4gNjQ0NzkNCjAyOjU2OjA1LjMwMDg1MyBJUCAxMC4xLjEuNi4y MiA+IDEwLjEuMS4xNS4zMDQzOiBQIDU2MDo2MDgoNDgpIGFjayA0ODEgd2lu IDY1NTM1DQowMjo1NjowNS4zMDIyMDYgSVAgMTAuMS4xLjE1LjMwNDMgPiAx MC4xLjEuNi4yMjogUCA0ODE6NTI5KDQ4KSBhY2sgNjA4IHdpbiA2NDQzMQ0K MDI6NTY6MDUuMzAyNDk4IElQIDEwLjEuMS42LjIyID4gMTAuMS4xLjE1LjMw NDM6IFAgNjA4OjY1Nig0OCkgYWNrIDUyOSB3aW4gNjU1MzUNCjAyOjU2OjA1 LjQwOTUyNyBJUCAxMC4xLjEuMTUuMzA0MyA+IDEwLjEuMS42LjIyOiBQIDUy OTo1NzcoNDgpIGFjayA2NTYgd2luIDY0MzgzDQowMjo1NjowNS40MDk4MjAg SVAgMTAuMS4xLjYuMjIgPiAxMC4xLjEuMTUuMzA0MzogUCA2NTY6NzA0KDQ4 KSBhY2sgNTc3IHdpbiA2NTUzNQ0KMDI6NTY6MDUuNDY5NTgwIElQIDEwLjEu MS4xNS4zMDQzID4gMTAuMS4xLjYuMjI6IFAgNTc3OjYyNSg0OCkgYWNrIDcw NCB3aW4gNjQzMzUNCjAyOjU2OjA1LjQ2OTg2NyBJUCAxMC4xLjEuNi4yMiA+ IDEwLjEuMS4xNS4zMDQzOiBQIDcwNDo3NTIoNDgpIGFjayA2MjUgd2luIDY1 NTM1DQowMjo1NjowNS40ODI4MzUgSVAgMTAuMS4xLjE1LjMwNDMgPiAxMC4x LjEuNi4yMjogUCA2MjU6NjczKDQ4KSBhY2sgNzUyIHdpbiA2NDI4Nw0KMDI6 NTY6MDUuNDgzMTI4IElQIDEwLjEuMS42LjIyID4gMTAuMS4xLjE1LjMwNDM6 IFAgNzUyOjgwMCg0OCkgYWNrIDY3MyB3aW4gNjU1MzUNCjAyOjU2OjA1LjU2 MDEyNSBJUCAxMC4xLjEuMTUuMzA0MyA+IDEwLjEuMS42LjIyOiBQIDY3Mzo3 MjEoNDgpIGFjayA4MDAgd2luIDY0MjM5DQowMjo1NjowNS41NjA0MTMgSVAg MTAuMS4xLjYuMjIgPiAxMC4xLjEuMTUuMzA0MzogUCA4MDA6ODQ4KDQ4KSBh Y2sgNzIxIHdpbiA2NTUzNQ0KMDI6NTY6MDUuNjUzMjM1IElQIDEwLjEuMS4x NS4zMDQzID4gMTAuMS4xLjYuMjI6IFAgNzIxOjc2OSg0OCkgYWNrIDg0OCB3 aW4gNjQxOTENCjAyOjU2OjA1LjY1MzUyNSBJUCAxMC4xLjEuNi4yMiA+IDEw LjEuMS4xNS4zMDQzOiBQIDg0ODo4OTYoNDgpIGFjayA3Njkgd2luIDY1NTM1 DQowMjo1NjowNS42NjY1ODMgSVAgMTAuMS4xLjE1LjMwNDMgPiAxMC4xLjEu Ni4yMjogUCA3Njk6ODE3KDQ4KSBhY2sgODk2IHdpbiA2NDE0Mw0KMDI6NTY6 MDUuNjY2ODY5IElQIDEwLjEuMS42LjIyID4gMTAuMS4xLjE1LjMwNDM6IFAg ODk2Ojk0NCg0OCkgYWNrIDgxNyB3aW4gNjU1MzUNCjAyOjU2OjA1LjY3OTk0 NCBJUCAxMC4xLjEuMTUuMzA0MyA+IDEwLjEuMS42LjIyOiBQIDgxNzo4NjUo NDgpIGFjayA5NDQgd2luIDY0MDk1DQowMjo1NjowNS42ODAyNDUgSVAgMTAu MS4xLjYuMjIgPiAxMC4xLjEuMTUuMzA0MzogUCA5NDQ6OTkyKDQ4KSBhY2sg ODY1IHdpbiA2NTUzNQ0KMDI6NTY6MDUuNzM3OTA0IElQIDEwLjEuMS4xNS4z MDQzID4gMTAuMS4xLjYuMjI6IFAgODY1OjkxMyg0OCkgYWNrIDk5MiB3aW4g NjU1MzUNCjAyOjU2OjA1LjczODE5OSBJUCAxMC4xLjEuNi4yMiA+IDEwLjEu MS4xNS4zMDQzOiBQIDk5MjoxMDQwKDQ4KSBhY2sgOTEzIHdpbiA2NTUzNQ0K MDI6NTY6MDUuNzM5NTMzIElQIDEwLjEuMS4xNS4zMDQzID4gMTAuMS4xLjYu MjI6IFAgOTEzOjk2MSg0OCkgYWNrIDEwNDAgd2luIDY1NDg3DQowMjo1Njow NS43Mzk4MTkgSVAgMTAuMS4xLjYuMjIgPiAxMC4xLjEuMTUuMzA0MzogUCAx MDQwOjEwODgoNDgpIGFjayA5NjEgd2luIDY1NTM1DQowMjo1NjowNS44MjQx ODAgSVAgMTAuMS4xLjE1LjMwNDMgPiAxMC4xLjEuNi4yMjogUCA5NjE6MTAw OSg0OCkgYWNrIDEwODggd2luIDY1NDM5DQowMjo1NjowNS44MjQ0NjcgSVAg MTAuMS4xLjYuMjIgPiAxMC4xLjEuMTUuMzA0MzogUCAxMDg4OjExMzYoNDgp IGFjayAxMDA5IHdpbiA2NTUzNQ0KMDI6NTY6MDUuODI1ODQwIElQIDEwLjEu MS4xNS4zMDQzID4gMTAuMS4xLjYuMjI6IFAgMTAwOToxMDU3KDQ4KSBhY2sg MTEzNiB3aW4gNjUzOTENCjAyOjU2OjA1LjgyNjEzNSBJUCAxMC4xLjEuNi4y MiA+IDEwLjEuMS4xNS4zMDQzOiBQIDExMzY6MTE4NCg0OCkgYWNrIDEwNTcg d2luIDY1NTM1DQowMjo1NjowNS45MDA0MTUgSVAgMTAuMS4xLjE1LjMwNDMg PiAxMC4xLjEuNi4yMjogUCAxMDU3OjExMDUoNDgpIGFjayAxMTg0IHdpbiA2 NTM0Mw0KMDI6NTY6MDUuOTAwNzA0IElQIDEwLjEuMS42LjIyID4gMTAuMS4x LjE1LjMwNDM6IFAgMTE4NDoxMjMyKDQ4KSBhY2sgMTEwNSB3aW4gNjU1MzUN CjAyOjU2OjA1LjkxMzY3OCBJUCAxMC4xLjEuMTUuMzA0MyA+IDEwLjEuMS42 LjIyOiBQIDExMDU6MTE1Myg0OCkgYWNrIDEyMzIgd2luIDY1Mjk1DQowMjo1 NjowNS45MTM5NzggSVAgMTAuMS4xLjYuMjIgPiAxMC4xLjEuMTUuMzA0Mzog UCAxMjMyOjEyODAoNDgpIGFjayAxMTUzIHdpbiA2NTUzNQ0KMDI6NTY6MDYu MDk4OTI3IElQIDEwLjEuMS4xNS4zMDQzID4gMTAuMS4xLjYuMjI6IC4gYWNr IDEyODAgd2luIDY1MjQ3DQowMjo1NjowOC43MTkzMjQgSVAgMTAuMS4xLjE1 LjMwNDMgPiAxMC4xLjEuNi4yMjogUyAwOjAoMCkgd2luIDANCjAyOjU2OjA4 LjcxOTg1MSBJUCAxMC4xLjEuNi4yMiA+IDEwLjEuMS4xNS4zMDQzOiAuIGFj ayAxMTUzIHdpbiA2NTUzNQ0KMDI6NTY6MDguNzE5ODczIElQIDEwLjEuMS4x NS4zMDQzID4gMTAuMS4xLjYuMjI6IFMgMTYzODQ6MTYzODQoMCkgd2luIDAN CjAyOjU2OjA4LjcxOTg4OCBJUCAxMC4xLjEuMTUuMzA0MyA+IDEwLjEuMS42 LjIyOiBTIDMyNzY4OjMyNzY4KDApIHdpbiAwDQowMjo1NjowOC43MTk5MDIg SVAgMTAuMS4xLjE1LjMwNDMgPiAxMC4xLjEuNi4yMjogUyA0OTE1Mjo0OTE1 MigwKSB3aW4gMA0KMDI6NTY6MDguNzE5OTE1IElQIDEwLjEuMS4xNS4zMDQz ID4gMTAuMS4xLjYuMjI6IFMgNjU1MzY6NjU1MzYoMCkgd2luIDANCjAyOjU2 OjA4LjcxOTkyOSBJUCAxMC4xLjEuMTUuMzA0MyA+IDEwLjEuMS42LjIyOiBT IDgxOTIwOjgxOTIwKDApIHdpbiAwDQowMjo1NjowOC43MTk5NDMgSVAgMTAu MS4xLjE1LjMwNDMgPiAxMC4xLjEuNi4yMjogUyA5ODMwNDo5ODMwNCgwKSB3 aW4gMA0KMDI6NTY6MDguNzE5OTU2IElQIDEwLjEuMS4xNS4zMDQzID4gMTAu MS4xLjYuMjI6IFMgMTE0Njg4OjExNDY4OCgwKSB3aW4gMA0KMDI6NTY6MDgu NzE5OTcwIElQIDEwLjEuMS4xNS4zMDQzID4gMTAuMS4xLjYuMjI6IFMgMTMx MDcyOjEzMTA3MigwKSB3aW4gMA0KMDI6NTY6MDguNzE5OTgzIElQIDEwLjEu MS4xNS4zMDQzID4gMTAuMS4xLjYuMjI6IFMgMTQ3NDU2OjE0NzQ1NigwKSB3 aW4gMA0KMDI6NTY6MDguNzIwMDAxIElQIDEwLjEuMS4xNS4zMDQzID4gMTAu MS4xLjYuMjI6IFMgMTYzODQwOjE2Mzg0MCgwKSB3aW4gMA0KMDI6NTY6MDgu NzIwMDg0IElQIDEwLjEuMS42LjIyID4gMTAuMS4xLjE1LjMwNDM6IC4gYWNr IDExNTMgd2luIDY1NTM1DQowMjo1NjowOC43MjAxNDIgSVAgMTAuMS4xLjYu MjIgPiAxMC4xLjEuMTUuMzA0MzogLiBhY2sgMTE1MyB3aW4gNjU1MzUNCjAy OjU2OjA4LjcyMDIwMCBJUCAxMC4xLjEuNi4yMiA+IDEwLjEuMS4xNS4zMDQz OiAuIGFjayAxMTUzIHdpbiA2NTUzNQ0KMDI6NTY6MDguNzIwMjU4IElQIDEw LjEuMS42LjIyID4gMTAuMS4xLjE1LjMwNDM6IC4gYWNrIDExNTMgd2luIDY1 NTM1DQowMjo1NjowOC43MjAzMTUgSVAgMTAuMS4xLjYuMjIgPiAxMC4xLjEu MTUuMzA0MzogLiBhY2sgMTE1MyB3aW4gNjU1MzUNCjAyOjU2OjA4LjcyMDM3 MyBJUCAxMC4xLjEuNi4yMiA+IDEwLjEuMS4xNS4zMDQzOiAuIGFjayAxMTUz IHdpbiA2NTUzNQ0KMDI6NTY6MDguNzIwNDMxIElQIDEwLjEuMS42LjIyID4g MTAuMS4xLjE1LjMwNDM6IC4gYWNrIDExNTMgd2luIDY1NTM1DQowMjo1Njow OC43MjA0ODggSVAgMTAuMS4xLjYuMjIgPiAxMC4xLjEuMTUuMzA0MzogLiBh Y2sgMTE1MyB3aW4gNjU1MzUNCjAyOjU2OjA4LjcyMDU0NiBJUCAxMC4xLjEu Ni4yMiA+IDEwLjEuMS4xNS4zMDQzOiAuIGFjayAxMTUzIHdpbiA2NTUzNQ0K MDI6NTY6MDguNzIwNjAzIElQIDEwLjEuMS42LjIyID4gMTAuMS4xLjE1LjMw NDM6IC4gYWNrIDExNTMgd2luIDY1NTM1DQowMjo1NjowOC43MjA2MjQgSVAg MTAuMS4xLjE1LjMwNDMgPiAxMC4xLjEuNi4yMjogUyAxODAyMjQ6MTgwMjI0 KDApIHdpbiAwDQowMjo1NjowOC43MjA2MzggSVAgMTAuMS4xLjE1LjMwNDMg PiAxMC4xLjEuNi4yMjogUyAxOTY2MDg6MTk2NjA4KDApIHdpbiAwDQowMjo1 NjowOC43MjA2NTIgSVAgMTAuMS4xLjE1LjMwNDMgPiAxMC4xLjEuNi4yMjog UyAyMTI5OTI6MjEyOTkyKDApIHdpbiAwDQowMjo1NjowOC43MjA2NjYgSVAg MTAuMS4xLjE1LjMwNDMgPiAxMC4xLjEuNi4yMjogUyAyMjkzNzY6MjI5Mzc2 KDApIHdpbiAwDQowMjo1NjowOC43MjA2ODAgSVAgMTAuMS4xLjE1LjMwNDMg PiAxMC4xLjEuNi4yMjogUyAyNDU3NjA6MjQ1NzYwKDApIHdpbiAwDQowMjo1 NjowOC43MjA2OTQgSVAgMTAuMS4xLjE1LjMwNDMgPiAxMC4xLjEuNi4yMjog UyAyNjIxNDQ6MjYyMTQ0KDApIHdpbiAwDQowMjo1NjowOC43MjA3MDggSVAg MTAuMS4xLjE1LjMwNDMgPiAxMC4xLjEuNi4yMjogUyAyNzg1Mjg6Mjc4NTI4 KDApIHdpbiAwDQowMjo1NjowOC43MjA3MjIgSVAgMTAuMS4xLjE1LjMwNDMg PiAxMC4xLjEuNi4yMjogUyAyOTQ5MTI6Mjk0OTEyKDApIHdpbiAwDQowMjo1 NjowOC43MjA3MzYgSVAgMTAuMS4xLjE1LjMwNDMgPiAxMC4xLjEuNi4yMjog UyAzMTEyOTY6MzExMjk2KDApIHdpbiAwDQowMjo1NjowOC43MjA3NTAgSVAg MTAuMS4xLjE1LjMwNDMgPiAxMC4xLjEuNi4yMjogUyAzMjc2ODA6MzI3Njgw KDApIHdpbiAwDQowMjo1NjowOC43MjA3NjMgSVAgMTAuMS4xLjE1LjMwNDMg PiAxMC4xLjEuNi4yMjogUyAzNDQwNjQ6MzQ0MDY0KDApIHdpbiAwDQowMjo1 NjowOC43MjA3OTYgSVAgMTAuMS4xLjE1LjMwNDMgPiAxMC4xLjEuNi4yMjog UyAzNjA0NDg6MzYwNDQ4KDApIHdpbiAwDQowMjo1NjowOC43MjA4NjYgSVAg MTAuMS4xLjYuMjIgPiAxMC4xLjEuMTUuMzA0MzogLiBhY2sgMTE1MyB3aW4g NjU1MzUNCjAyOjU2OjA4LjcyMDkyNCBJUCAxMC4xLjEuNi4yMiA+IDEwLjEu MS4xNS4zMDQzOiAuIGFjayAxMTUzIHdpbiA2NTUzNQ0KMDI6NTY6MDguNzIw OTgyIElQIDEwLjEuMS42LjIyID4gMTAuMS4xLjE1LjMwNDM6IC4gYWNrIDEx NTMgd2luIDY1NTM1DQowMjo1NjowOC43MjEwNDQgSVAgMTAuMS4xLjYuMjIg PiAxMC4xLjEuMTUuMzA0MzogLiBhY2sgMTE1MyB3aW4gNjU1MzUNCjAyOjU2 OjA4LjcyMTEwMSBJUCAxMC4xLjEuNi4yMiA+IDEwLjEuMS4xNS4zMDQzOiAu IGFjayAxMTUzIHdpbiA2NTUzNQ0K --0-835642382-1105262178=:2669-- From owner-freebsd-net@FreeBSD.ORG Sun Jan 9 10:41:06 2005 Return-Path: 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 AAEF616A4CE; Sun, 9 Jan 2005 10:41:06 +0000 (GMT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3561A43D4C; Sun, 9 Jan 2005 10:41:06 +0000 (GMT) (envelope-from hydros@mail.ru) Received: from [217.118.66.254] (port=19878 helo=turtle) by mx2.mail.ru with esmtp id 1CnaVL-000578-00; Sun, 09 Jan 2005 13:41:04 +0300 Date: Sun, 9 Jan 2005 13:40:50 +0300 From: hydros X-Mailer: The Bat! (v3.0) Professional X-Priority: 3 (Normal) Message-ID: <1116933942.20050109134050@mail.ru> To: freebsd-performance@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: Not detected cc: freebsd-net@freebsd.org Subject: pppoe perfomance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hydros List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 10:41:06 -0000 Hi all. Does anyone tested a perfomance of pppoe+freebsd as server? How much cpu\ram does it east with a different vpn load. I`m trying to make a server and not sure does the hardware would be able to serve my LAN users server pII-450 ram 256mb hdd 10gb NIC realtek rl0 10\100mbit(working at 10mbit speed) -- Best regards, hydros mailto:hydros@mail.ru From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 08:50:14 2005 Return-Path: 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 44E0A16A4CE for ; Mon, 10 Jan 2005 08:50:14 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C352443D3F for ; Mon, 10 Jan 2005 08:50:13 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j0A8o6FY019623; Mon, 10 Jan 2005 00:50:10 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200501100850.j0A8o6FY019623@gw.catspoiler.org> Date: Mon, 10 Jan 2005 00:50:06 -0800 (PST) From: Don Lewis To: silby@silby.com In-Reply-To: <20050109031431.H2669@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: net@FreeBSD.org Subject: Re: Slipping in the window update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 08:50:14 -0000 On 9 Jan, Mike Silbersack wrote: > > Ok, here's an updated patch for the SYN case. I've included the patch > relative to 6.x, and some text from a tcpdump showing it in action. > > It responds to each SYN with an ACK like the latest tcpsecure document > states, but it uses a global counter to rate limit the number of ACKs of > this type that it will send to 200 per second. > > I was unable to incorporate the connect idle heuristic I wanted to because > right now the incoming spoofed syns would reset the idle counter, which > sounds like it could cause a problem somehow... best not to use it for > now. Maybe a future change can clean up that along with the dropafterack > case in tcp_input, but that would make this patch far too complex. > > Please take a look at the patch and the abbreviated tcpdump from my test > and see if it looks correct. > + if (thflags & TH_SYN) { > + if (tp->t_state == TCPS_ESTABLISHED && > + tcp_insecure_syn == 0) { Any good reason for the extra level of nesting? Testing the SYN flag first is probably optimum, since in normal operation the vast majority of segments won't have this flag set. > + if (tp) > + INP_UNLOCK(inp); If we've successfully dereferenced tp->t_state, it should not be necessary to protect INP_UNLOCK() with if (tp) > + if (headlocked) > + INP_INFO_WUNLOCK(&tcbinfo); I suspect that the headlocked flag is also known at this point in the code. Ordinary data segments will have the TH_SYN checked twice. The first time in this new code, and the second time after the segment has been trimmed to fit the window. /* * If a SYN is in the window, then this is an * error and we send an RST and drop the connection. */ if (thflags & TH_SYN) { tp = tcp_drop(tp, ECONNRESET); rstreason = BANDLIM_UNLIMITED; goto drop; } This could make a bit of a performance difference at high speeds, for instance gigabit Ethernet in a compute cluster. An alternate fix would be to modify the latter block of code as follows: if (thflags & TH_SYN) { + if (tp->t_state == TCPS_ESTABLISHED && + tcp_insecure_syn == 0) + goto dropafterack; tp = tcp_drop(tp, ECONNRESET); rstreason = BANDLIM_UNLIMITED; goto drop; } and then after the dropafterack label add the code: + if (thflags & TH_SYN) { + if (tp->t_state == TCPS_ESTABLISHED && + tcp_insecure_syn == 0) { + if (badport_bandlim(BANDLIM_SYN_ESTABLISHED) < 0) + goto drop; + tcp_respond(tp, mtod(m, void *), th, m, tp->rcv_nxt, + tp->snd_una, TH_ACK); [snip] I don't think this fix would be complete from the response rate limiting point of view because this chunk of code in the block that trims to the left window edge tosses the TH_SYN flag. todrop = tp->rcv_nxt - th->th_seq; if (todrop > 0) { if (thflags & TH_SYN) { thflags &= ~TH_SYN; th->th_seq++; if (th->th_urp > 1) th->th_urp--; else thflags &= ~TH_URG; todrop--; } and this block of code doesn't jump to dropafterack, even in the case where the entire segment is to the left of the window. Something else would have to be done to implement rate limiting for this half of the sequence space. Now that I've looked at the above case, it looks to me like your suggested patch might affect the response to a legitimate duplicate SYN. It will definitely follow a different code path. From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 09:13:11 2005 Return-Path: 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 BC8CC16A4CE for ; Mon, 10 Jan 2005 09:13:11 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7873643D2D for ; Mon, 10 Jan 2005 09:13:11 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j0A9D4ji019676; Mon, 10 Jan 2005 01:13:08 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200501100913.j0A9D4ji019676@gw.catspoiler.org> Date: Mon, 10 Jan 2005 01:13:04 -0800 (PST) From: Don Lewis To: silby@silby.com In-Reply-To: <200501100850.j0A8o6FY019623@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: net@FreeBSD.org Subject: Re: Slipping in the window update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 09:13:11 -0000 After a bit more thinking ... On 10 Jan, Don Lewis wrote: > and then after the dropafterack label add the code: > > + if (thflags & TH_SYN) { > + if (tp->t_state == TCPS_ESTABLISHED && > + tcp_insecure_syn == 0) { > + if (badport_bandlim(BANDLIM_SYN_ESTABLISHED) < 0) > + goto drop; > + tcp_respond(tp, mtod(m, void *), th, m, tp->rcv_nxt, > + tp->snd_una, TH_ACK); > [snip] > > I don't think this fix would be complete from the response rate limiting > point of view because this chunk of code in the block that trims to the > left window edge tosses the TH_SYN flag. > > todrop = tp->rcv_nxt - th->th_seq; > if (todrop > 0) { > if (thflags & TH_SYN) { > thflags &= ~TH_SYN; > th->th_seq++; > if (th->th_urp > 1) > th->th_urp--; > else > thflags &= ~TH_URG; > todrop--; > } > > and this block of code doesn't jump to dropafterack, even in the case > where the entire segment is to the left of the window. Something else > would have to be done to implement rate limiting for this half of the > sequence space. I think this problem could be solved by a minor addition to the above block of code. If the SYN flag is set and the sequence number of the segment doesn't match the initial received sequence number of the connection, then we know this is not a duplicate SYN. todrop = tp->rcv_nxt - th->th_seq; if (todrop > 0) { if (thflags & TH_SYN) { + if (th->th_seq != tp->irs) + goto dropafterack; thflags &= ~TH_SYN; th->th_seq++; if (th->th_urp > 1) th->th_urp--; else thflags &= ~TH_URG; todrop--; } From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 09:56:34 2005 Return-Path: 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 AD6FB16A4CF for ; Mon, 10 Jan 2005 09:56:34 +0000 (GMT) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id F1E4D43D54 for ; Mon, 10 Jan 2005 09:56:33 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 23840 invoked from network); 10 Jan 2005 09:56:33 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 10 Jan 2005 09:56:33 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 10 Jan 2005 03:56:31 -0600 (CST) From: Mike Silbersack To: Don Lewis In-Reply-To: <200501100850.j0A8o6FY019623@gw.catspoiler.org> Message-ID: <20050110034422.C9716@odysseus.silby.com> References: <200501100850.j0A8o6FY019623@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: net@FreeBSD.org Subject: Re: Slipping in the window update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 09:56:34 -0000 On Mon, 10 Jan 2005, Don Lewis wrote: > Now that I've looked at the above case, it looks to me like your > suggested patch might affect the response to a legitimate duplicate SYN. > It will definitely follow a different code path. You're right, I neglected to handle the duplicate SYN case. Couldn't we centralize all SYN handling right after trimthenstep6:? We could do something there like if (th->th_seq != tp->irs) { goto dropafterack; /* Or however we handle these bad syns */ } else { thflags &= ~TH_SYN; th->th_seq++; if (th->th_urp > 1) th->th_urp--; else thflags &= ~TH_URG; todrop--; } And then we could tear out all the two places TH_SYN is mentioned below, the place I copied from, and the place where there the tcp_drop() is. If we made that change, then we'd still be doing only one check for TH_SYN, but the code would be a lot easier to comprehend. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 10:01:34 2005 Return-Path: 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 2012B16A4CE for ; Mon, 10 Jan 2005 10:01:34 +0000 (GMT) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 8D4D243D5C for ; Mon, 10 Jan 2005 10:01:31 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 25240 invoked from network); 10 Jan 2005 10:01:30 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 10 Jan 2005 10:01:30 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 10 Jan 2005 04:01:29 -0600 (CST) From: Mike Silbersack To: Don Lewis In-Reply-To: <20050110034422.C9716@odysseus.silby.com> Message-ID: <20050110040019.W12176@odysseus.silby.com> References: <200501100850.j0A8o6FY019623@gw.catspoiler.org> <20050110034422.C9716@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: net@FreeBSD.org Subject: Re: Slipping in the window update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 10:01:34 -0000 On Mon, 10 Jan 2005, Mike Silbersack wrote: > We could do something there like > > if (th->th_seq != tp->irs) { > goto dropafterack; /* Or however we handle these bad syns */ > } else { > thflags &= ~TH_SYN; > th->th_seq++; > if (th->th_urp > 1) > th->th_urp--; > else > thflags &= ~TH_URG; > todrop--; > } Uh, I greatly oversimplified the changes that would be needed there, so that implementation would be totally wrong. I'll go get some sleep and then think about the implementation... Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 10:46:52 2005 Return-Path: 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 7578816A4CE for ; Mon, 10 Jan 2005 10:46:52 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3830743D39 for ; Mon, 10 Jan 2005 10:46:52 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j0AAkilD019867; Mon, 10 Jan 2005 02:46:48 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200501101046.j0AAkilD019867@gw.catspoiler.org> Date: Mon, 10 Jan 2005 02:46:44 -0800 (PST) From: Don Lewis To: silby@silby.com In-Reply-To: <20050110034422.C9716@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: net@FreeBSD.org Subject: Re: Slipping in the window update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 10:46:52 -0000 On 10 Jan, Mike Silbersack wrote: > > On Mon, 10 Jan 2005, Don Lewis wrote: > >> Now that I've looked at the above case, it looks to me like your >> suggested patch might affect the response to a legitimate duplicate SYN. >> It will definitely follow a different code path. > > You're right, I neglected to handle the duplicate SYN case. > > Couldn't we centralize all SYN handling right after trimthenstep6:? > > We could do something there like > > if (th->th_seq != tp->irs) { > goto dropafterack; /* Or however we handle these bad syns */ > } else { > thflags &= ~TH_SYN; > th->th_seq++; > if (th->th_urp > 1) > th->th_urp--; > else > thflags &= ~TH_URG; > todrop--; > } My thinking is that the security problem is confined to the following block of code: /* * If a SYN is in the window, then this is an * error and we send an RST and drop the connection. */ if (thflags & TH_SYN) { tp = tcp_drop(tp, ECONNRESET); rstreason = BANDLIM_UNLIMITED; goto drop; } and that to implement the recommendation in the Internet Draft, it is only necessary to change the actions taken inside this "if" block. If response rate limiting is implemented, I'd actually prefer a more general solution that is at least somewhat independent of the SYN flag, since if the goal of an attacker is to cause an flood of ACK responses, he can just as easily trigger it by sending spoofed packets that don't have the SYN flag set. The SYN flag could be used as a hint, but the solution should be more general. From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 11:03:04 2005 Return-Path: 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 8BD9216A4CF for ; Mon, 10 Jan 2005 11:03:04 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64DC243D39 for ; Mon, 10 Jan 2005 11:03:04 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0AB34WC095495 for ; Mon, 10 Jan 2005 11:03:04 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0AB32uK095489 for freebsd-net@freebsd.org; Mon, 10 Jan 2005 11:03:02 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 10 Jan 2005 11:03:02 GMT Message-Id: <200501101103.j0AB32uK095489@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 11:03:04 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 16:54:03 2005 Return-Path: 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 3F0A416A523; Mon, 10 Jan 2005 16:54:03 +0000 (GMT) Received: from mgw1.MEIway.com (mgw1.meiway.com [81.255.84.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9871E43D3F; Mon, 10 Jan 2005 16:54:00 +0000 (GMT) (envelope-from LConrad@Go2France.com) Received: from VirusGate.MEIway.com (virusgate.meiway.com [81.255.84.76]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id 0C91B4718CF; Mon, 10 Jan 2005 17:59:06 +0100 (CET) (envelope-from LConrad@Go2France.com) Received: from localhost (localhost.MEIWay.com [127.0.0.1]) by VirusGate.MEIway.com (Postfix) with SMTP id 53CBA3866E6; Mon, 10 Jan 2005 17:54:02 +0100 (CET) (envelope-from LConrad@Go2France.com) X-AV-Checked: Mon Jan 10 17:54:02 2005 virusgate.meiway.com Received: from mail.Go2France.com (ms1.meiway.com [81.255.84.73]) by VirusGate.MEIway.com (Postfix) with ESMTP id 4898E38665C; Mon, 10 Jan 2005 17:54:02 +0100 (CET) (envelope-from LConrad@Go2France.com) Received: from tx2.Go2France.com [24.227.147.226] by mail.Go2France.com with ESMTP (SMTPD32-7.07) id A0CE55050066; Mon, 10 Jan 2005 17:43:58 +0100 Message-Id: <6.1.1.1.2.20050110103857.045a9a68@81.255.84.73> X-Sender: LConrad@Go2France.com@81.255.84.73 X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Mon, 10 Jan 2005 10:53:39 -0600 To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org From: Len Conrad Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: buildup of Windows time_wait talking to fbsd 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 16:54:03 -0000 We have a windows mailserver that relays its outbound to a fbsd gateway. We changed to a different fbsd gateway running 4.10. Windows then began having trouble sending to 4.10. Windows "netstat -an" shows dozens of lines like this: source IP desitination IP ====================================================================== TCP 10.1.16.3:1403 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1407 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1415 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1419 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1435 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1462 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1470 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1473 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1478 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1493 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1504 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1507 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1508 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1521 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1526 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1546 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1550 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1568 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1571 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1589 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1592 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1616 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1620 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1629 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1644 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1647 192.168.200.59:25 TIME_WAIT TCP 10.1.16.3:1654 192.168.200.59:25 TIME_WAIT Eventually, the windows SMTP logs line like "cannot connect to remote IP" or "address already in use" because no local tcp/ip sockets are available, we think. The new gateway/fbsd 4.10 "sockstat -4" shows no corresponding tcp connections when the Windows server is showing as above. On the fbsd 4.10 machines, smtp logs, syslog, and dmesg show no errors. We switch the windows box to smtp gateway towards the old box/fbsd 4.7, all is cool. Suggestions with how to proceed debugging, please. I'm trying to get the dmesg.boot for the 4.7 and 4.10 boxes now, sorry. Len From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 16:59:20 2005 Return-Path: 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 2B95816A4CF for ; Mon, 10 Jan 2005 16:59:20 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8056543D48 for ; Mon, 10 Jan 2005 16:59:19 +0000 (GMT) (envelope-from nocmonkey@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so20482rne for ; Mon, 10 Jan 2005 08:59:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=St2E0eI8KshTCLs8ItkEHX3dm4sKDsXNXSM2NAksIzcVRJJoJ5Qr609yGuCXfmnBqgc6O5edfdLRkdvZhF0vAHwh5Xk6KIsbpUebMfIrVUvGs7FZhHHkqbTNY/PMOdNel9eEjoGQaW8WrNjTFrJpItrMVVrcfsIBIDJ0iUo4TV8= Received: by 10.38.90.66 with SMTP id n66mr69124rnb; Mon, 10 Jan 2005 08:59:18 -0800 (PST) Received: by 10.38.22.74 with HTTP; Mon, 10 Jan 2005 08:59:18 -0800 (PST) Message-ID: Date: Mon, 10 Jan 2005 11:59:18 -0500 From: Danny To: Len Conrad In-Reply-To: <6.1.1.1.2.20050110103857.045a9a68@81.255.84.73> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <6.1.1.1.2.20050110103857.045a9a68@81.255.84.73> cc: freebsd-net@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: buildup of Windows time_wait talking to fbsd 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Danny List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 16:59:20 -0000 On Mon, 10 Jan 2005 10:53:39 -0600, Len Conrad wrote: > > We have a windows mailserver that relays its outbound to a fbsd > gateway. We changed to a different fbsd gateway running 4.10. Windows then > began having trouble sending to 4.10. Windows "netstat -an" shows dozens > of lines like this: > > source IP desitination IP > ====================================================================== > TCP 10.1.16.3:1403 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1407 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1415 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1419 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1435 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1462 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1470 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1473 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1478 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1493 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1504 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1507 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1508 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1521 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1526 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1546 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1550 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1568 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1571 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1589 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1592 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1616 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1620 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1629 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1644 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1647 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1654 192.168.200.59:25 TIME_WAIT > > Eventually, the windows SMTP logs line like "cannot connect to remote IP" > or "address already in use" because no local tcp/ip sockets are available, > we think. > > The new gateway/fbsd 4.10 "sockstat -4" shows no corresponding tcp > connections when the Windows server is showing as above. On the fbsd 4.10 > machines, smtp logs, syslog, and dmesg show no errors. > > We switch the windows box to smtp gateway towards the old box/fbsd 4.7, all > is cool. > > Suggestions with how to proceed debugging, please. > > I'm trying to get the dmesg.boot for the 4.7 and 4.10 boxes now, sorry. What shows up when you run a network sniffer on either machines? ...D From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 17:12:02 2005 Return-Path: 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 D215216A4CE; Mon, 10 Jan 2005 17:12:02 +0000 (GMT) Received: from mail.foolishgames.com (mail.foolishgames.com [216.55.178.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9430243D1D; Mon, 10 Jan 2005 17:12:02 +0000 (GMT) (envelope-from laffer1@mail.foolishgames.com) Received: from mail.foolishgames.com (localhost.dedicated.abac.net [127.0.0.1])j0AIFnL5013271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jan 2005 10:15:49 -0800 (PST) (envelope-from laffer1@mail.foolishgames.com) X-Authentication-Warning: mail.foolishgames.com: Host localhost.dedicated.abac.net [127.0.0.1] claimed to be mail.foolishgames.com Received: from localhost (laffer1@localhost)j0AIFnTX013268; Mon, 10 Jan 2005 10:15:49 -0800 (PST) (envelope-from laffer1@mail.foolishgames.com) Date: Mon, 10 Jan 2005 10:15:49 -0800 (PST) From: laffer1 To: Len Conrad In-Reply-To: <6.1.1.1.2.20050110103857.045a9a68@81.255.84.73> Message-ID: <20050110101200.W13168@mail.foolishgames.com> References: <6.1.1.1.2.20050110103857.045a9a68@81.255.84.73> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: buildup of Windows time_wait talking to fbsd 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 17:12:03 -0000 On Mon, 10 Jan 2005, Len Conrad wrote: > > We have a windows mailserver that relays its outbound to a fbsd gateway. We > changed to a different fbsd gateway running 4.10. Windows then began having > trouble sending to 4.10. Windows "netstat -an" shows dozens of lines like > this: > > source IP desitination IP > ====================================================================== > TCP 10.1.16.3:1403 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1407 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1415 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1419 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1435 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1462 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1470 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1473 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1478 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1493 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1504 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1507 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1508 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1521 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1526 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1546 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1550 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1568 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1571 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1589 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1592 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1616 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1620 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1629 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1644 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1647 192.168.200.59:25 TIME_WAIT > TCP 10.1.16.3:1654 192.168.200.59:25 TIME_WAIT > > Eventually, the windows SMTP logs line like "cannot connect to remote IP" or > "address already in use" because no local tcp/ip sockets are available, we > think. > > The new gateway/fbsd 4.10 "sockstat -4" shows no corresponding tcp > connections when the Windows server is showing as above. On the fbsd 4.10 > machines, smtp logs, syslog, and dmesg show no errors. > > We switch the windows box to smtp gateway towards the old box/fbsd 4.7, all > is cool. > > Suggestions with how to proceed debugging, please. > > I'm trying to get the dmesg.boot for the 4.7 and 4.10 boxes now, sorry. > > Len Just off the top of my head... You mentioned the freebsd machine is the gateway. Do you have a firewall on the host blocking connections from the windows machine? Do you have a different kernel configuration between 4.7 and 4.10? i.e. do you have something like ipdivert, etc in the kernel on one box and not the other? Can the windows machine ping the ip 192.168.200.59 as its a different class C? Luke From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 17:26:21 2005 Return-Path: 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 40B8C16A4CE; Mon, 10 Jan 2005 17:26:21 +0000 (GMT) Received: from mgw1.MEIway.com (mgw1.meiway.com [81.255.84.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6D1043D2F; Mon, 10 Jan 2005 17:26:20 +0000 (GMT) (envelope-from LConrad@Go2France.com) Received: from VirusGate.MEIway.com (virusgate.meiway.com [81.255.84.76]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id DB5E64718C1; Mon, 10 Jan 2005 18:31:26 +0100 (CET) (envelope-from LConrad@Go2France.com) Received: from localhost (localhost.MEIWay.com [127.0.0.1]) by VirusGate.MEIway.com (Postfix) with SMTP id 3320F3866FB; Mon, 10 Jan 2005 18:26:23 +0100 (CET) (envelope-from LConrad@Go2France.com) X-AV-Checked: Mon Jan 10 18:26:23 2005 virusgate.meiway.com Received: from mail.Go2France.com (ms1.meiway.com [81.255.84.73]) by VirusGate.MEIway.com (Postfix) with ESMTP id 240D138665C; Mon, 10 Jan 2005 18:26:23 +0100 (CET) (envelope-from LConrad@Go2France.com) Received: from tx2.Go2France.com [24.227.147.226] by mail.Go2France.com with ESMTP (SMTPD32-7.07) id A86355FB0066; Mon, 10 Jan 2005 18:16:19 +0100 Message-Id: <6.1.1.1.2.20050110112254.0486dec0@81.255.84.73> X-Sender: LConrad@Go2France.com@81.255.84.73 X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Mon, 10 Jan 2005 11:26:16 -0600 To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org From: Len Conrad In-Reply-To: <20050110101200.W13168@mail.foolishgames.com> References: <6.1.1.1.2.20050110103857.045a9a68@81.255.84.73> <20050110101200.W13168@mail.foolishgames.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: buildup of Windows time_wait talking to fbsd 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 17:26:21 -0000 > >Just off the top of my head... > >You mentioned the freebsd machine is the gateway. Do you have a firewall >on the host blocking connections from the windows machine? a forgotten detail is that the windows machine sends just fine to the 4.10 gateway for a few minutes, but the time_wait inevitably builds up, so smtp access from windows to either gateway is ok. > Do you have a different kernel configuration between 4.7 and 4.10? both GENERIC > i.e. do you have something like ipdivert, etc in the kernel on one box > and not the other? Can the windows machine ping the ip 192.168.200.59 as > its a different class C? sure, basic connectivity is ok. Len _____________________________________________________________________ http://IMGate.MEIway.com : free anti-spam gateway, runs on 1000's of sites From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 17:44:48 2005 Return-Path: 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 4FA4716A4CE; Mon, 10 Jan 2005 17:44:48 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B215843D3F; Mon, 10 Jan 2005 17:44:46 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])j0AHiifg026312; Mon, 10 Jan 2005 19:44:45 +0200 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) j0AHiiNg001331; Mon, 10 Jan 2005 19:44:44 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost)j0AHiiAq001330; Mon, 10 Jan 2005 19:44:44 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Mon, 10 Jan 2005 19:44:44 +0200 From: Giorgos Keramidas To: Len Conrad Message-ID: <20050110174444.GA1294@orion.daedalusnetworks.priv> References: <6.1.1.1.2.20050110103857.045a9a68@81.255.84.73> <20050110101200.W13168@mail.foolishgames.com> <6.1.1.1.2.20050110112254.0486dec0@81.255.84.73> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.1.1.2.20050110112254.0486dec0@81.255.84.73> cc: freebsd-net@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: buildup of Windows time_wait talking to fbsd 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 17:44:48 -0000 On 2005-01-10 11:26, Len Conrad wrote: >> Just off the top of my head... >> >> You mentioned the freebsd machine is the gateway. Do you have a >> firewall on the host blocking connections from the windows machine? > > a forgotten detail is that the windows machine sends just fine to > the 4.10 gateway for a few minutes, but the time_wait inevitably > builds up, so smtp access from windows to either gateway is ok. > >> Do you have a different kernel configuration between 4.7 and 4.10? > > both GENERIC > >> i.e. do you have something like ipdivert, etc in the kernel on one >> box and not the other? Can the windows machine ping the ip >> 192.168.200.59 as its a different class C? > > sure, basic connectivity is ok. Are you using a firewall? If yes, is it stateful? Can we see the ruleset? From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 01:37:52 2005 Return-Path: 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 C695B16A4CE for ; Tue, 11 Jan 2005 01:37:52 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 360E143D49 for ; Tue, 11 Jan 2005 01:37:52 +0000 (GMT) (envelope-from grayas@gmail.com) Received: by rproxy.gmail.com with SMTP id z35so40964rne for ; Mon, 10 Jan 2005 17:37:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=N+qEoV/VgJviQW02Oie2+iJIDfo0wExU+UlDBPTh8v0YjvlXO3NNrZZ3Yekc+Vo0nQJOmO6ysbkHp7RRjpKoD9VX0YnF1Z5lmShMLfwRGxmficRXWFjeCpJV4/M6l8Lp1qyKA11G13gSqi3COLm1vg0ZsjNA1q7BDCX/zmJ75Os= Received: by 10.38.82.44 with SMTP id f44mr85544rnb; Mon, 10 Jan 2005 17:37:51 -0800 (PST) Received: by 10.38.96.13 with HTTP; Mon, 10 Jan 2005 17:37:51 -0800 (PST) Message-ID: <9c9fb1860501101737268508be@mail.gmail.com> Date: Mon, 10 Jan 2005 17:37:51 -0800 From: Girish Rayas To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Bug in TCP window update? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Girish Rayas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 01:37:52 -0000 In tcp_input.c, window is updated when below condition is true, if ((thflags & TH_ACK) && (SEQ_LT(tp->snd_wl1, th->th_seq) || (tp->snd_wl1 == th->th_seq && (SEQ_LT(tp->snd_wl2, th->th_ack) || (tp->snd_wl2 == th->th_ack && tiwin > tp->snd_wnd))))) This check is to prevent old segments from affecting the send window. But, left trim logic that was executed earlier in tcp_input.c sets the th->th_seq to tp->rcv_nxt for old segments. In many scenarios this effectively causes snd_wl1 < th_seq and results in incorrect window update by old segments. Using actual sequence number of received segment in the above if statement will fix the problem. Any comments? From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 02:23:45 2005 Return-Path: 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 5ED9B16A4CF for ; Tue, 11 Jan 2005 02:23:45 +0000 (GMT) Received: from electra.nolink.net (electra.nolink.net [195.139.204.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30BDC43D1F for ; Tue, 11 Jan 2005 02:23:44 +0000 (GMT) (envelope-from lerik@nolink.net) Received: (qmail 92385 invoked by uid 1000); 11 Jan 2005 02:23:42 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Jan 2005 02:23:42 -0000 Date: Tue, 11 Jan 2005 03:23:42 +0100 (CET) From: Lars Erik Gullerud To: Len Conrad In-Reply-To: <6.1.1.1.2.20050110103857.045a9a68@81.255.84.73> Message-ID: <20050111025252.L88996@electra.nolink.net> References: <6.1.1.1.2.20050110103857.045a9a68@81.255.84.73> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org Subject: Re: buildup of Windows time_wait talking to fbsd 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 02:23:45 -0000 On Mon, 10 Jan 2005, Len Conrad wrote: > We have a windows mailserver that relays its outbound to a fbsd gateway. We > changed to a different fbsd gateway running 4.10. Windows then began having > trouble sending to 4.10. Windows "netstat -an" shows dozens of lines like > this: > > source IP desitination IP > ====================================================================== > TCP 10.1.16.3:1403 192.168.200.59:25 TIME_WAIT [snip] > Eventually, the windows SMTP logs line like "cannot connect to remote IP" or > "address already in use" because no local tcp/ip sockets are available, we > think. > > The new gateway/fbsd 4.10 "sockstat -4" shows no corresponding tcp > connections when the Windows server is showing as above. On the fbsd 4.10 > machines, smtp logs, syslog, and dmesg show no errors. > > We switch the windows box to smtp gateway towards the old box/fbsd 4.7, all > is cool. OK, let me play a wild hunch here - if you look at netstat -na output on the 4.7 machine (the one that works) when you are using that one, you see a large number of connections in the TIME_WAIT state on that side, while none on the Windows-server? I had a similar situation with an application we use that also opens a large number of TCP sessions from a Windows server to a FreeBSD server - that suddenly stopped working when the application in question was upgraded on the server it connected to. In our case, it turns it it was a timing issue that changed on the new version of the application. When a TCP connection is closing, one side of the connection typically initiates the close, and sends a FIN,ACK packet to the other side. After going through the steps of closing down the socket, the side that initiated the close, will leave the socket in TIME-WAIT state for 2 MSL (Maximum Segment Lifetime - which defaults to 2 mins, so 4 min wait) - while the other end transitions to CLOSED state (and tears down the socket) immediately, without this wait period. (The exception being if both ends send FIN,ACK at the same time, in which case they both go to TIME-WAIT). What happened with in our case, on the old version of the application, was that as soon as the client started to log off the session, the server-side application (on the FreeBSD server) would initiate closing of the TCP-session, and thereby being the originator (and getting a large number of sessions in TIME-WAIT - which was not a problem for the BSD box). While the Windows machine closed it's socket immediately and was happy all the time. However, after we upgraded the application, when the client logged off at the application level, the server-side app would first take 2-3 seconds to process various shutdown-related activities, and the client end (on the Windows machine) got "impatient" and initiated the TCP session close from it's side. Leaving all the TIME-WAIT sockets hanging on the Windows side, rather than the FreeBSD side. Now, newer versions of Windows have a ridiculously low number of max simultaneous connections configured, and we started seeing exactly the same kinds of errors you are describing, due to a large number of TIME-WAIT sockets. We had to adjust the server-side application to tear down the TCP socket first, THEN do its internal shutdown processing, in order to not leave the Windows client in a jam. The alternative was to increase the number of simultaneous connections on the Windows machine, which involves some registry black magic, and we found this to be the easier way out (then - we will probably hack the Windows regkeys if we start seeing the issue again). You didn't mention what MTA you are using, so I don't know if this is a similar (application-level) issue, or if it's FreeBSD 4.10 that causes some additional delay before initiating a TCP CLOSE, but either way, this might be the behaviour you are observing, in which case you will need to figure out how to get the FreeBSD side to tear down the connection, or preferably you should look at tuning some registry stuff on your Windows server - like setting the MSL time (default 2 minutes) to a much lower value, and perhaps upping the no. of max simultaneous connections. HTH, /leg From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 18:50:33 2005 Return-Path: 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 8940716A4CE for ; Tue, 11 Jan 2005 18:50:33 +0000 (GMT) Received: from web80602.mail.yahoo.com (web80602.mail.yahoo.com [66.218.79.91]) by mx1.FreeBSD.org (Postfix) with SMTP id 52E0943D39 for ; Tue, 11 Jan 2005 18:50:33 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Message-ID: <20050111185033.73879.qmail@web80602.mail.yahoo.com> Received: from [209.79.44.104] by web80602.mail.yahoo.com via HTTP; Tue, 11 Jan 2005 10:50:33 PST Date: Tue, 11 Jan 2005 10:50:33 -0800 (PST) From: Mohan Srinivasan To: freebsd-net@freebsd.org, jbehl@fastclick.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: %cpu in system - squid performance in FreeBSD 5.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 18:50:33 -0000 Following up to a mail from Jeff Behl and Sean Chittenden back in Dec. http://lists.freebsd.org/pipermail/freebsd-net/2004-December/006074.html >From your description, it looks like moving a kqueue based Squid will help considerably (it looks like there is a version of Squid that is kqueue based - not sure how stable that is though). If you drop a quick kernel profile, you will see most of the system CPU being spent in select() caused polling of descriptors. In my previous experience with a Squid-based proxy several years ago, once you dropped more than a couple of hundred connections into select(), CPU utilization spiked sharply because of the descriptor polling. We then hoisted Squid on top of a (homebrew) version of kqueue, which caused system CPU to drop dramatically, because all the descriptor polling was avoided. mohan From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 19:14:39 2005 Return-Path: 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 EB4EA16A4CE for ; Tue, 11 Jan 2005 19:14:39 +0000 (GMT) Received: from sb.santaba.com (sb.santaba.com [207.154.84.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id A46E143D39 for ; Tue, 11 Jan 2005 19:14:39 +0000 (GMT) (envelope-from jbehl@fastclick.com) Received: from [192.168.3.100] (unknown [205.180.85.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sb.santaba.com (Postfix) with ESMTP id 0F29128433; Tue, 11 Jan 2005 11:14:39 -0800 (PST) Message-ID: <41E425BD.709@fastclick.com> Date: Tue, 11 Jan 2005 11:15:09 -0800 From: Jeff Behl User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Srinivasan References: <20050111185033.73879.qmail@web80602.mail.yahoo.com> In-Reply-To: <20050111185033.73879.qmail@web80602.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: %cpu in system - squid performance in FreeBSD 5.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 19:14:40 -0000 Yes, I believe the kqueue version of squid would show much better results. Unfortunately it fails to compile and I have yet the time to try mucking with it more. I'll get back to the list when I am able to get it up and running... jeff Mohan Srinivasan wrote: >Following up to a mail from Jeff Behl and Sean Chittenden back in Dec. > >http://lists.freebsd.org/pipermail/freebsd-net/2004-December/006074.html > >From your description, it looks like moving a kqueue based Squid will >help considerably (it looks like there is a version of Squid that >is kqueue based - not sure how stable that is though). If you drop a quick >kernel profile, you will see most of the system CPU being spent in select() >caused polling of descriptors. In my previous experience with a Squid-based >proxy several years ago, once you dropped more than a couple of hundred >connections into select(), CPU utilization spiked sharply because of >the descriptor polling. > >We then hoisted Squid on top of a (homebrew) version of kqueue, which >caused system CPU to drop dramatically, because all the descriptor polling >was avoided. > >mohan > > > From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 21:56:41 2005 Return-Path: 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 B478A16A4CE; Tue, 11 Jan 2005 21:56:41 +0000 (GMT) Received: from mgw1.MEIway.com (mgw1.meiway.com [81.255.84.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2FEB43D46; Tue, 11 Jan 2005 21:56:38 +0000 (GMT) (envelope-from LConrad@Go2France.com) Received: from VirusGate.MEIway.com (virusgate.meiway.com [81.255.84.76]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id 6B1E2471835; Tue, 11 Jan 2005 23:01:48 +0100 (CET) (envelope-from LConrad@Go2France.com) Received: from localhost (localhost.MEIWay.com [127.0.0.1]) by VirusGate.MEIway.com (Postfix) with SMTP id 68230386727; Tue, 11 Jan 2005 22:56:41 +0100 (CET) (envelope-from LConrad@Go2France.com) X-AV-Checked: Tue Jan 11 22:56:41 2005 virusgate.meiway.com Received: from mail.Go2France.com (ms1.meiway.com [81.255.84.73]) by VirusGate.MEIway.com (Postfix) with ESMTP id E9CC33866FB; Tue, 11 Jan 2005 22:56:36 +0100 (CET) (envelope-from LConrad@Go2France.com) Received: from tx2.Go2France.com [24.227.147.226] by mail.Go2France.com with ESMTP (SMTPD32-7.07) id A9367AE40066; Tue, 11 Jan 2005 22:46:30 +0100 Message-Id: <6.1.1.1.2.20050111154955.03efd268@81.255.84.73> X-Sender: LConrad@Go2France.com@81.255.84.73 X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Tue, 11 Jan 2005 15:56:29 -0600 To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org From: Len Conrad In-Reply-To: <20050110101200.W13168@mail.foolishgames.com> References: <6.1.1.1.2.20050110103857.045a9a68@81.255.84.73> <20050110101200.W13168@mail.foolishgames.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: buildup of Windows time_wait talking to fbsd 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 21:56:41 -0000 >>We have a windows mailserver that relays its outbound to a fbsd >>gateway. We changed to a different fbsd gateway running 4.10. Windows >>then began having trouble sending to 4.10. Windows "netstat -an" >>shows dozens of lines like this: >> >> source IP desitination IP >>====================================================================== >> TCP 10.1.16.3:1403 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1407 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1415 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1419 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1435 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1462 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1470 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1473 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1478 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1493 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1504 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1507 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1508 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1521 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1526 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1546 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1550 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1568 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1571 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1589 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1592 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1616 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1620 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1629 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1644 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1647 192.168.200.59:25 TIME_WAIT >> TCP 10.1.16.3:1654 192.168.200.59:25 TIME_WAIT >> >>Eventually, the windows SMTP logs line like "cannot connect to remote IP" >>or "address already in use" because no local tcp/ip sockets are >>available, we think. >> >>The new gateway/fbsd 4.10 "sockstat -4" shows no corresponding tcp >>connections when the Windows server is showing as above. On the fbsd >>4.10 machines, smtp logs, syslog, and dmesg show no errors. >> >>We switch the windows box to smtp gateway towards the old box/fbsd 4.7, >>all is cool. >> >>Suggestions with how to proceed debugging, please. >> >>I'm trying to get the dmesg.boot for the 4.7 and 4.10 boxes now, sorry. >> >>Len > >Just off the top of my head... > >You mentioned the freebsd machine is the gateway. Do you have a firewall >on the host blocking connections from the windows machine? the two mail servers that send outbound to the fbsd gateway are on the subnet, same rules. the firewall is "outside" the subnets of the mail servers and gateways. We haven't put a sniffer yet. there's none on windows boxes, and tcpview on the fbsd boxes. We going to start changing NIC model/brands. thanks Len _____________________________________________________________________ http://IMGate.MEIway.com : free anti-spam gateway, runs on 1000's of sites From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 22:01:30 2005 Return-Path: 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 20BA116A4CE for ; Tue, 11 Jan 2005 22:01:30 +0000 (GMT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id C855143D1D for ; Tue, 11 Jan 2005 22:01:29 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465; Tue, 11 Jan 2005 14:01:29 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 356815D07; Tue, 11 Jan 2005 14:01:29 -0800 (PST) To: freebsd-net@freebsd.org Date: Tue, 11 Jan 2005 14:01:29 -0800 From: "Kevin Oberman" Message-Id: <20050111220129.356815D07@ptavv.es.net> cc: nesg@es.net Subject: IPv6 TCP transfers are hanging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 22:01:30 -0000 I think I have found a problem with TCP when run over IPv6. I set my MSS for TCP to 1460 to allow a full 1500 byte MTU to be utilized on my systems. (Yes, I see that this does break some things like communicating via links where PMTUD is blocked and one or more links restrict MTU to some size less than 1500 bytes. What I am specifically seeing is a packet being sent out with a TCP length of 1460. While this is fine for IPv4, it's too back for IPv6 and, as you might expect, the far end never receives this packet. There is a sysctl for net.inet.tcp.v6mssdflt which is set to 1024. This should be fine, but it appears that it is not being honored and the V4 value is always used. Am I mis-analyzing things or is TCP at least a bit broken when running over V6? (Or am I at fault for setting the large MSS because ti is honored with v6 even though there is a separate sysctl for IPv6? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 22:24:05 2005 Return-Path: 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 7455D16A4CE for ; Tue, 11 Jan 2005 22:24:05 +0000 (GMT) Received: from thor-new.fsklaw.com (adsl-64-174-116-34.dsl.lsan03.pacbell.net [64.174.116.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24A0E43D4C for ; Tue, 11 Jan 2005 22:24:05 +0000 (GMT) (envelope-from tms3@fsklaw.com) Received: from lildude.fsklaw.net [192.168.62.67] by thor-new.fsklaw.com (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.6.0)); Tue, 11 Jan 2005 14:25:10 -0800 Message-ID: <41E451D0.9080302@fsklaw.com> Date: Tue, 11 Jan 2005 14:23:12 -0800 From: Tom Skeren User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041103 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ArGoMail-Authenticated: tms3 Subject: gif's X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 22:24:05 -0000 Been pulling my hair out. Anybody know of a resource for a fairly complex tunneling scheme. My needs are such that a central hub "Star" style tunneling scheme simply will not be efficient. Any info would be appreciated. TMS III From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 01:59:49 2005 Return-Path: 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 31CD016A4CE for ; Wed, 12 Jan 2005 01:59:49 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFAE243D3F for ; Wed, 12 Jan 2005 01:59:48 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] (pool-68-160-208-232.ny325.east.verizon.net [68.160.208.232]) by pi.codefab.com (8.12.11/8.12.11) with ESMTP id j0C1xhDw017440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jan 2005 20:59:45 -0500 (EST) Message-ID: <41E48472.5000909@mac.com> Date: Tue, 11 Jan 2005 20:59:14 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Skeren References: <41E451D0.9080302@fsklaw.com> In-Reply-To: <41E451D0.9080302@fsklaw.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.8 required=5.5 tests=AWL,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=disabled version=3.0.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on pi.codefab.com cc: freebsd-net@freebsd.org Subject: Re: gif's X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 01:59:49 -0000 Tom Skeren wrote: > Been pulling my hair out. Anybody know of a resource for a fairly > complex tunneling scheme. My needs are such that a central hub "Star" > style tunneling scheme simply will not be efficient. At some point, complex VPN configurations become more work to setup and maintain than switching to IPsec or increasing the # publicly available services, hopefully switching to more secure protocols at the same time. By the last I mean, many people want a VPN to do filesharing from home to work, or access email and such "securely" over the encrypted tunnel, but people tend to terminate VPN endpoints inside the network rather than in a semi-trusted perimeter zone, and the more VPN connections you add, the greater the exposure of various external networks to the inside and to each other. Switching to HTTPS+WebDAV (eg SubVersion) for a filesharing/publishing mechanism to replace direct CIFS/Samba access, or accessing mail via IMAPS rather than firing up Outlook against the company's MS-Exchange server over the VPN might actually result in a more secure configuration. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 03:30:57 2005 Return-Path: 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 AE5E216A4CE for ; Wed, 12 Jan 2005 03:30:57 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2155443D5A for ; Wed, 12 Jan 2005 03:30:57 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4A06815210; Wed, 12 Jan 2005 12:30:55 +0900 (JST) Date: Wed, 12 Jan 2005 12:31:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Kevin Oberman" In-Reply-To: <20050111220129.356815D07@ptavv.es.net> References: <20050111220129.356815D07@ptavv.es.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org cc: nesg@es.net Subject: Re: IPv6 TCP transfers are hanging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 03:30:58 -0000 >>>>> On Tue, 11 Jan 2005 14:01:29 -0800, >>>>> "Kevin Oberman" said: > I think I have found a problem with TCP when run over IPv6. > I set my MSS for TCP to 1460 to allow a full 1500 byte MTU to be > utilized on my systems. (Yes, I see that this does break some things > like communicating via links where PMTUD is blocked and one or more > links restrict MTU to some size less than 1500 bytes. > What I am specifically seeing is a packet being sent out with a TCP > length of 1460. While this is fine for IPv4, it's too back for IPv6 and, > as you might expect, the far end never receives this packet. Two questions to clarify things: 1. Which version of FreeBSD are you using? 2. How did you set the MSS? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 09:43:30 2005 Return-Path: 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 5799E16A4CE; Wed, 12 Jan 2005 09:43:30 +0000 (GMT) Received: from mccinet.ru (relay.cell.ru [212.119.96.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFBB143D3F; Wed, 12 Jan 2005 09:43:28 +0000 (GMT) (envelope-from dolgop@mccinet.ru) Received: from [212.1.235.150] (HELO server.dep624) by mccinet.ru (CommuniGate Pro SMTP 4.2.7) with ESMTP-TLS id 15308640; Wed, 12 Jan 2005 12:43:27 +0300 From: Evgeny Dolgopiat To: Maxim Sobolev Date: Wed, 12 Jan 2005 12:43:56 +0300 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501121243.56305.dolgop@mccinet.ru> cc: freebsd-net@freebsd.org cc: "Rogier R.Mulhuijzen" cc: freebsd-cluster@freebsd.org Subject: New failure detection algorithm for ng_one2many. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: evg_dolgop@mail.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 09:43:30 -0000 I wrote new failure detection algorithm based on heartbeat signal for ng_one2many node. Features: - automatic detection of failures; - automatic detection of recoveries; - detection of point of failure (see diagnostics in man page); - configurable timing parameters of failure and recovery detection; - you can create your own heartbeat packet or use default; - you can set your rules for detecting that incoming packet is hearbeat packet; - heartbeat algorithm can be used for different network layers (not only ethernet layer). Patches for src and man page at http://www.watson.org/~ilmar/download/ng_one2many.tgz These patches for CURRENT, but you can compile patched files in 5.3. From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 10:26:59 2005 Return-Path: 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 7011916A4CE; Wed, 12 Jan 2005 10:26:59 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id A920943D1F; Wed, 12 Jan 2005 10:26:58 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j0CAQqDY000578; Wed, 12 Jan 2005 13:26:52 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Wed, 12 Jan 2005 13:26:52 +0300 (MSK) From: Maxim Konovalov To: Andre Oppermann In-Reply-To: <41BAD2BA.C030B6DD@freebsd.org> Message-ID: <20050112132627.A309@mp2.macomnet.net> References: <200412021322.iB2DMxLj066304@freefall.freebsd.org> <20041202134041.GB32699@cell.sick.ru> <41B2200F.FB46E28A@freebsd.org> <20041204221449.GC49503@cell.sick.ru> <20041211101622.GA1430@k7.mavetju> <41BAD2BA.C030B6DD@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Info: Profile: Formal (192/041231) X-SpamTest-Info: Profile: Detect Hard (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking - Keywords (2/030321) X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], SpamtestISP/Release cc: Edwin Groothuis cc: net@freebsd.org Subject: Re: kern/73129: [patch] IPFW misbehaviour in RELENG_5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 10:26:59 -0000 On Sat, 11 Dec 2004, 11:58+0100, Andre Oppermann wrote: > Edwin Groothuis wrote: > > > > On Sun, Dec 05, 2004 at 01:14:49AM +0300, Gleb Smirnoff wrote: > > > On Sun, Dec 05, 2004 at 12:53:52AM +0300, Maxim Konovalov wrote: > > > M> IMHO restoring the historic behaviour (even broken in some respects) > > > M> is the best thing we can do at the moment. > > > > > > + my vote. > > > > Mine too. > > I'll change it shortly. Knock-knock, b/b home? :-) -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 10:41:04 2005 Return-Path: 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 61A3F16A4CE; Wed, 12 Jan 2005 10:41:04 +0000 (GMT) Received: from mail2out.barnet.com.au (mail2out.barnet.com.au [202.83.176.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1541043D39; Wed, 12 Jan 2005 10:41:04 +0000 (GMT) (envelope-from edwin@mavetju.org) Received: by mail2out.barnet.com.au (Postfix, from userid 27) id 58271707446; Wed, 12 Jan 2005 21:41:03 +1100 (EST) X-Viruscan-Id: <41E4FEBF00005DD06983F9@BarNet> Received: from mail2-auth.barnet.com.au (mail2.barnet.com.au [202.83.176.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by mail2.barnet.com.au (Postfix) with ESMTP id 0CA30707445; Wed, 12 Jan 2005 21:41:03 +1100 (EST) Received: from k7.mavetju (edwin-3.int.barnet.com.au [10.10.12.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Certificate Authority" (verified OK)) by mail2-auth.barnet.com.au (Postfix) with ESMTP id 762A7707443; Wed, 12 Jan 2005 21:41:02 +1100 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 1E741610F; Wed, 12 Jan 2005 21:41:01 +1100 (EST) Date: Wed, 12 Jan 2005 21:41:01 +1100 From: Edwin Groothuis To: Maxim Konovalov Message-ID: <20050112104100.GA1035@k7.mavetju> References: <200412021322.iB2DMxLj066304@freefall.freebsd.org> <20041202134041.GB32699@cell.sick.ru> <41B2200F.FB46E28A@freebsd.org> <20041204221449.GC49503@cell.sick.ru> <20041211101622.GA1430@k7.mavetju> <41BAD2BA.C030B6DD@freebsd.org> <20050112132627.A309@mp2.macomnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050112132627.A309@mp2.macomnet.net> User-Agent: Mutt/1.5.6i cc: Andre Oppermann cc: net@freebsd.org Subject: Re: kern/73129: [patch] IPFW misbehaviour in RELENG_5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 10:41:04 -0000 On Wed, Jan 12, 2005 at 01:26:52PM +0300, Maxim Konovalov wrote: > On Sat, 11 Dec 2004, 11:58+0100, Andre Oppermann wrote: > > > Edwin Groothuis wrote: > > > > > > On Sun, Dec 05, 2004 at 01:14:49AM +0300, Gleb Smirnoff wrote: > > > > On Sun, Dec 05, 2004 at 12:53:52AM +0300, Maxim Konovalov wrote: > > > > M> IMHO restoring the historic behaviour (even broken in some respects) > > > > M> is the best thing we can do at the moment. > > > > > > > > + my vote. > > > > > > Mine too. > > > > I'll change it shortly. > > Knock-knock, b/b home? :-) I was hoping somebody was going to tell me it was fixed! Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://weblog.barnet.com.au/edwin/ From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 20:00:37 2005 Return-Path: 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 E936116A4CF for ; Wed, 12 Jan 2005 20:00:37 +0000 (GMT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6AB343D45 for ; Wed, 12 Jan 2005 20:00:37 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465; Wed, 12 Jan 2005 12:00:37 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id B058C5D07; Wed, 12 Jan 2005 12:00:36 -0800 (PST) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-reply-to: Your message of "Wed, 12 Jan 2005 12:31:19 +0900." Date: Wed, 12 Jan 2005 12:00:36 -0800 From: "Kevin Oberman" Message-Id: <20050112200036.B058C5D07@ptavv.es.net> cc: freebsd-net@freebsd.org cc: nesg@es.net Subject: Re: IPv6 TCP transfers are hanging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 20:00:38 -0000 > Date: Wed, 12 Jan 2005 12:31:19 +0900 > From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= > > >>>>> On Tue, 11 Jan 2005 14:01:29 -0800, > >>>>> "Kevin Oberman" said: > > > I think I have found a problem with TCP when run over IPv6. > > I set my MSS for TCP to 1460 to allow a full 1500 byte MTU to be > > utilized on my systems. (Yes, I see that this does break some things > > like communicating via links where PMTUD is blocked and one or more > > links restrict MTU to some size less than 1500 bytes. > > > What I am specifically seeing is a packet being sent out with a TCP > > length of 1460. While this is fine for IPv4, it's too back for IPv6 and, > > as you might expect, the far end never receives this packet. > > Two questions to clarify things: > > 1. Which version of FreeBSD are you using? Shows up on 4.11-Release, 4-stable (about a week old), and 5.3-Stable (about a month old) > 2. How did you set the MSS? sysctl.conf More information. I lowered the value of mssdflt to 1400 on both systems and I am still seeing attempts to send 1460 byte packets. These, of course, never make it to the far side of the 1500 byte MTU link. I am now guessing that PMTUD is finding the MTU to be 1500 and calculating an MSS of 1460 event hough IPv6 requires 20 added bytes of header. Also, the problem seems to show up over ssh connections. I have never seen it over any other link, but I don't use many other things over IPv6. I have never had a problem with gkrellmd running over IPv6. (gkrellmd is the network daemon for the gkrellm system monitor.) Here is the packet that is failing: 08:20:12.680313 aaa.es.net.ssh > bbb.es.net.54854: . 10145:11573(1428) ack 31040 win 58548 [flowlabel 0x6ae53] (len 1460, hlim 64) I am also seeing a number of slightly shorter packets which work fine: 08:19:54.222301 bbb.es.net.54854 > aaa.es.net.ssh: . [tcp sum ok] 23616:25020(1404) ack 5073 win 32844 [flowlabel 0x19ed] (len 1436, hlim 64) I cannot confirm the problem occurring when the source is a V5 system. It is possible that only V4 systems are doing this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 21:15:39 2005 Return-Path: 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 9A26816A4CE for ; Wed, 12 Jan 2005 21:15:39 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60F4C43D3F for ; Wed, 12 Jan 2005 21:15:38 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id j0CLCWZm019877 for freebsd-net@freebsd.org.checked; Thu, 13 Jan 2005 00:12:32 +0300 (MSK) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id j0CLA1OD019837; Thu, 13 Jan 2005 00:10:01 +0300 (MSK) (envelope-from rik@cronyx.ru) Message-ID: <41E58FF4.5000404@cronyx.ru> Date: Thu, 13 Jan 2005 00:00:36 +0300 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: evg_dolgop@mail.ru References: <200501121243.56305.dolgop@mccinet.ru> In-Reply-To: <200501121243.56305.dolgop@mccinet.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Maxim Sobolev cc: "Rogier R.Mulhuijzen" cc: freebsd-cluster@freebsd.org Subject: Re: New failure detection algorithm for ng_one2many. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 21:15:39 -0000 Evgeny Dolgopiat: >I wrote new failure detection algorithm based on heartbeat signal for >ng_one2many node. Features: > >- automatic detection of failures; >- automatic detection of recoveries; >- detection of point of failure (see diagnostics in man page); >- configurable timing parameters of failure and recovery detection; >- you can create your own heartbeat packet or use default; >- you can set your rules for detecting that incoming packet is hearbeat >packet; >- heartbeat algorithm can be used for different network layers (not only >ethernet layer). > Is it possible to turn it off so that it wouldn't work at all? rik > >Patches for src and man page at >http://www.watson.org/~ilmar/download/ng_one2many.tgz >These patches for CURRENT, but you can compile patched files in 5.3. > >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 22:44:30 2005 Return-Path: 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 C068416A4CE for ; Wed, 12 Jan 2005 22:44:30 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CD9143D2F for ; Wed, 12 Jan 2005 22:44:30 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Wed, 12 Jan 2005 14:44:30 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id D590B5D08; Wed, 12 Jan 2005 14:44:29 -0800 (PST) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-reply-to: Your message of "Wed, 12 Jan 2005 12:00:36 PST." <20050112200036.B058C5D07@ptavv.es.net> Date: Wed, 12 Jan 2005 14:44:29 -0800 From: "Kevin Oberman" Message-Id: <20050112224429.D590B5D08@ptavv.es.net> cc: freebsd-net@freebsd.org cc: nesg@es.net Subject: Re: [nesg] Re: IPv6 TCP transfers are hanging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 22:44:31 -0000 Tatuya-san, I think this is almost certainly a network issue. I suspect that the MTU is really NOT 1500. It's probably a couple of bytes less due to tunneling or something similar. Unfortunately when I tried ping6 to test with various packet sizes, my FreeBSD 5.3-Stable box did a reboot. (No panic or dump.) Not very nice. Guess I need to look at this. Sorry to have wasted people's time on this. If it turns out that I am wrong about this, I'll send another report. Thanks for your time! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 01:07:36 2005 Return-Path: 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 C2F7216A4CE for ; Thu, 13 Jan 2005 01:07:36 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A572A43D41 for ; Thu, 13 Jan 2005 01:07:36 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id A2F7A7A403 for ; Wed, 12 Jan 2005 17:07:36 -0800 (PST) Message-ID: <41E5C9D8.4090209@elischer.org> Date: Wed, 12 Jan 2005 17:07:36 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: TCP out-of-order packets. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 01:07:36 -0000 I have a link which is provided by someone else that is 7 x E1s aggregated. At leat it looks that way to me when I get to see it. however I have only been able to get 60kB.sec across this, despite having a tcp window size of 131072 bytes.. After investigation it appears that the link is massively re-orderring packets. groups of upto 10 packets may appear in random order. (Maybe more, bu tI have seen 10) in fact packets are rarely IN order. This plays havoc with the tcp sessions. I was thinking of writing a hacked up version of NATD that instead of doing NAT, just did a pre-sort on packets from each session, so that the receiver would see a stream of IN-order packets, with occasional delays. firstly, does anyone have any tools to do this already (why build when you can borrow) and secondly, does anyone have any experience with this sort of problem? I have no control over or access to the link.. all I have is a promise that they will deliver 14Mb/Sec. with approc 300mSec. RTT to me but there is no promise about packet order. I just get a 100Mb ethernet cable. From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 01:31:01 2005 Return-Path: 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 DF90916A4CE for ; Thu, 13 Jan 2005 01:31:01 +0000 (GMT) Received: from mx2.nersc.gov (mx2.nersc.gov [128.55.6.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id B813043D48 for ; Thu, 13 Jan 2005 01:31:01 +0000 (GMT) (envelope-from dart@nersc.gov) Received: by mx2.nersc.gov (Postfix, from userid 4002) id 83D8677A2; Wed, 12 Jan 2005 17:31:01 -0800 (PST) Received: from mx2.nersc.gov (localhost [127.0.0.1]) by localhost.nersc.gov (Postfix) with ESMTP id BC43277A3; Wed, 12 Jan 2005 17:30:57 -0800 (PST) Received: from gemini.nersc.gov (gemini.nersc.gov [128.55.16.111]) by mx2.nersc.gov (Postfix) with ESMTP id 734F077A2; Wed, 12 Jan 2005 17:30:57 -0800 (PST) Received: from gemini.nersc.gov (localhost [127.0.0.1]) by gemini.nersc.gov (Postfix) with ESMTP id 4D3E5F987; Wed, 12 Jan 2005 17:30:57 -0800 (PST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Julian Elischer In-Reply-To: Message from Julian Elischer of "Wed, 12 Jan 2005 17:07:36 PST." <41E5C9D8.4090209@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_697650595P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 12 Jan 2005 17:30:57 -0800 From: Eli Dart Message-Id: <20050113013057.4D3E5F987@gemini.nersc.gov> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mx2.nersc.gov X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60 X-Spam-Level: cc: net@freebsd.org Subject: Re: TCP out-of-order packets. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 01:31:02 -0000 --==_Exmh_697650595P Content-Type: text/plain; charset=us-ascii In reply to Julian Elischer : > I have no control over or access to the link.. all I have is a promise > that they will deliver > 14Mb/Sec. with approc 300mSec. RTT to me but there is no promise about > packet order. My guess is that they are doing round-robin load balancing, instead of per-flow load balancing. You may not have access to the link's config, but do you have someone that you could ask to change the load-sharing algorithm? (I expect you've thought of this, but figured I'd ask). If they are doing this with the idea that one could get more than an E1's worth of bandwidth out of a single flow, it sounds like they are misguided.... --eli > > I just get a 100Mb ethernet cable. > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --==_Exmh_697650595P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQFB5c9RLTFEeF+CsrMRArb0AKDotRfTeaJYAU8ADh6qAvHQwIOhnQCffDri El1W146ZwRwbdEN6Kd1G4A0= =N3sy -----END PGP SIGNATURE----- --==_Exmh_697650595P-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 02:09:23 2005 Return-Path: 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 04F1B16A4CE for ; Thu, 13 Jan 2005 02:09:23 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A439F43D53 for ; Thu, 13 Jan 2005 02:09:22 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 86F957A403; Wed, 12 Jan 2005 18:09:22 -0800 (PST) Message-ID: <41E5D852.8070609@elischer.org> Date: Wed, 12 Jan 2005 18:09:22 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Eli Dart References: <20050113013057.4D3E5F987@gemini.nersc.gov> In-Reply-To: <20050113013057.4D3E5F987@gemini.nersc.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: TCP out-of-order packets. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 02:09:23 -0000 Eli Dart wrote: >In reply to Julian Elischer : > > > > >>I have no control over or access to the link.. all I have is a promise >>that they will deliver >>14Mb/Sec. with approc 300mSec. RTT to me but there is no promise about >>packet order. >> >> > >My guess is that they are doing round-robin load balancing, instead >of per-flow load balancing. > >You may not have access to the link's config, but do you have someone >that you could ask to change the load-sharing algorithm? (I expect >you've thought of this, but figured I'd ask). If they are doing this >with the idea that one could get more than an E1's worth of bandwidth >out of a single flow, it sounds like they are misguided.... > well I've asked but I don't expect a quick answer.. > > --eli > > > > >>I just get a 100Mb ethernet cable. >> >> >> >>_______________________________________________ >>freebsd-net@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-net >>To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> >> > > > > From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 05:48:16 2005 Return-Path: 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 2933F16A4CE for ; Thu, 13 Jan 2005 05:48:16 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0F3643D31 for ; Thu, 13 Jan 2005 05:48:15 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j0D5pBnu028459; Wed, 12 Jan 2005 21:51:11 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j0D5pBf0028458; Wed, 12 Jan 2005 21:51:11 -0800 Date: Wed, 12 Jan 2005 21:51:11 -0800 From: Brooks Davis To: Julian Elischer Message-ID: <20050113055111.GA11141@odin.ac.hmc.edu> References: <41E5C9D8.4090209@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <41E5C9D8.4090209@elischer.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: net@freebsd.org Subject: Re: TCP out-of-order packets. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 05:48:16 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 12, 2005 at 05:07:36PM -0800, Julian Elischer wrote: >=20 > I have a link which is provided by someone else that is 7 x E1s aggregate= d. > At leat it looks that way to me when I get to see it. however I have=20 > only been able to get > 60kB.sec across this, despite having a tcp window size of 131072 bytes.. > After investigation it appears that the link is massively re-orderring=20 > packets. > groups of upto 10 packets may appear in random order. (Maybe more, bu tI= =20 > have seen 10) >=20 > in fact packets are rarely IN order. >=20 > This plays havoc with the tcp sessions. >=20 > I was thinking of writing a hacked up version of NATD that > instead of doing NAT, just did a pre-sort on packets from each session,= =20 > so that the receiver would > see a stream of IN-order packets, with occasional delays. >=20 > firstly, does anyone have any tools to do this already (why build when=20 > you can borrow) > and secondly, does anyone have any experience with this sort of problem? >=20 > I have no control over or access to the link.. all I have is a promise=20 > that they will deliver > 14Mb/Sec. with approc 300mSec. RTT to me but there is no promise about=20 > packet order. >=20 > I just get a 100Mb ethernet cable. Have you tried Andre's TCP reassembly rewrite? He says he saw significant improvements in the face of major reordering. http://www.mail-archive.com/freebsd-net@freebsd.org/msg14064.html -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB5gxPXY6L6fI4GtQRAm4uAKCeE/xte3E5E3iceWBBjvzd5lpp3ACgiEo3 mF9X3uBOdAHXYB/Nd/1xkQ0= =P+o4 -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 05:51:23 2005 Return-Path: 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 83A4116A4CE for ; Thu, 13 Jan 2005 05:51:23 +0000 (GMT) Received: from smtp4.wlink.com.np (smtp4.wlink.com.np [202.79.32.87]) by mx1.FreeBSD.org (Postfix) with SMTP id 2449A43D1F for ; Thu, 13 Jan 2005 05:51:20 +0000 (GMT) (envelope-from bikrant_ml@wlink.com.np) Received: (qmail 90380 invoked from network); 13 Jan 2005 05:51:14 -0000 Received: from unknown (HELO qmail-scanner.wlink.com.np) (202.79.32.74) by 0 with SMTP; 13 Jan 2005 05:51:14 -0000 Received: (qmail 48676 invoked by uid 1008); 13 Jan 2005 05:51:14 -0000 Received: from bikrant_ml@wlink.com.np by qmail-scanner.wlink.com.np by uid 1002 with qmail-scanner-1.20 (clamscan: 0.70. Clear:RC:1(202.79.32.76):. Processed in 0.021185 secs); 13 Jan 2005 05:51:14 -0000 Received: from smtp1.wlink.com.np (202.79.32.76) by qmail-scanner.wlink.com.np with SMTP; 13 Jan 2005 05:51:14 -0000 Received: (qmail 25219 invoked by uid 508); 13 Jan 2005 05:51:14 -0000 Received: from [202.79.36.168] (HELO bikrant.org.np) by smtp1.wlink.com.np (qmail-smtpd) with SMTP; 13 Jan 2005 05:51:13 -0000 (Thu, 13 Jan 2005 11:36:13 +0545) From: Bikrant Neupane To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Disposition: inline Date: Thu, 13 Jan 2005 11:36:11 +0545 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200501131136.11550.bikrant_ml@wlink.com.np> X-Spam-Check-By: smtp1.wlink.com.np Spam: No ; -4.9 / 5.0 X-Spam-Status-WL: No, hits=-4.9 required=5.0 Subject: Default LQR timeout period X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 05:51:23 -0000 Hi We have pppoe server running on FreeBSD 4.9 and 90% of our wireless clients are using MS Windows OS to access the service. I have noticed that when ever there is some problem in the link ( due to AP or SM reboot, switch reboot etc etc ) the pppoe connection closes. I have also noticed that the MS Windows client closes connection at 40-45 seconds after the link is down. I tried to increase default LQR timeout period at Server by using set lqrtimeout to some higher values. That did affected the serverside ppp process but the MS client still disconnected at 40-45 seconds. :( I prefer to set the timeout period somewhere between 120-150 seconds so that even if there is problem in the link the client doesn't get the disconnect notice and have to reconnect again and the client and servers are able to continue same session. Is there any way to control the default LQR timeout period of the Client from the Server end?? My question is more related with ms windows still I am asking this question to freebsd group so that I can solve the problem from the server end ;) regards, Bikrant From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 06:38:07 2005 Return-Path: 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 4F0B316A4CE; Thu, 13 Jan 2005 06:38:07 +0000 (GMT) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id D536043D45; Thu, 13 Jan 2005 06:38:06 +0000 (GMT) (envelope-from tedm@toybox.placo.com) Received: from tedwin2k (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) j0D6btj70869; Wed, 12 Jan 2005 22:37:55 -0800 (PST) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: "Bikrant Neupane" , , Date: Wed, 12 Jan 2005 22:37:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <200501131136.11550.bikrant_ml@wlink.com.np> Subject: RE: Default LQR timeout period X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 06:38:07 -0000 Open up your registry editor and go to HEKY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Modem\XXXX\Set tings where XXXX is the number of your modem (example: 0001). On the right pane search for a string value named InactivityTimeout. Enter the new timeout rate in minutes. For example enter 30 for a 30 minutes timeout. From: http://www.activewin.com/tips/reg/connect_1.shtml Time it took me to find this - 45 seconds. It took you longer to post the request than to type it into a search engine. Ted > -----Original Message----- > From: owner-freebsd-questions@freebsd.org > [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of > Bikrant Neupane > Sent: Wednesday, January 12, 2005 9:51 PM > To: freebsd-questions@freebsd.org; freebsd-net@freebsd.org > Subject: Default LQR timeout period > > > Hi > > We have pppoe server running on FreeBSD 4.9 and 90% of our > wireless clients > are using MS Windows OS to access the service. I have noticed > that when ever > there is some problem in the link ( due to AP or SM reboot, > switch reboot etc > etc ) the pppoe connection closes. I have also noticed that > the MS Windows > client closes connection at 40-45 seconds after the link is > down. I tried to > increase default LQR timeout period at Server by using set > lqrtimeout to some > higher values. That did affected the serverside ppp process > but the MS client > still disconnected at 40-45 seconds. :( > > I prefer to set the timeout period somewhere between 120-150 > seconds so that > even if there is problem in the link the client doesn't get > the disconnect > notice and have to reconnect again and the client and servers > are able to > continue same session. > > Is there any way to control the default LQR timeout period of > the Client from > the Server end?? > > My question is more related with ms windows still I am asking > this question to > freebsd group so that I can solve the problem from the server end ;) > > regards, > Bikrant > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 13:58:01 2005 Return-Path: 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 97F8B16A4CE for ; Thu, 13 Jan 2005 13:58:01 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D38043D31 for ; Thu, 13 Jan 2005 13:58:01 +0000 (GMT) (envelope-from fehwalker@gmail.com) Received: by wproxy.gmail.com with SMTP id 40so875542wri for ; Thu, 13 Jan 2005 05:58:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=oSxmLjxGDP3tdpbmDpU+ScX0qtJKBbD/DNeAyb2a86tVtbOoNXfFBF47vDkoGI+FNYrg0ZVm0rXKpp+iJoHwVRZNvdCjmnr4SkPee3TFri8nJjSZzE2VrhE2RbecLfxiWmhLoLVHPaqowzFEEfJGigvsulJKR/eclLUbRD4LKKo= Received: by 10.54.59.25 with SMTP id h25mr129316wra; Thu, 13 Jan 2005 05:58:00 -0800 (PST) Received: by 10.54.19.59 with HTTP; Thu, 13 Jan 2005 05:58:00 -0800 (PST) Message-ID: <35de0c3005011305585b2a83f8@mail.gmail.com> Date: Thu, 13 Jan 2005 08:58:00 -0500 From: Bryan Fullerton To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: em0 and pci interrupt routing? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bryan Fullerton List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 13:58:01 -0000 Howdy, I'm having some issues with a new server, and was wondering if the interrupt routing message below could be indicating a problem that needs investigation. pci0: on pcib0 pcib1: at device 3.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P2 - AE_NOT_FOUND pci1: on pcib1 em0: port 0xcc00-0xcc1f mem 0xfb4e0000-0xfb4fffff irq 18 at device 1.0 on pci1 em0: Ethernet address: 00:02:b3:ea:28:20 em0: Speed:N/A Duplex:N/A The machine is using an Intel SE7210TP1-E motherboard, and the em0 interface is onboard. I don't see any other PCI interrupt routing messages in dmesg. Thanks, Bryan From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 15:30:19 2005 Return-Path: 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 BA9AC16A4D1 for ; Thu, 13 Jan 2005 15:30:19 +0000 (GMT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 728AC43D54 for ; Thu, 13 Jan 2005 15:30:19 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465; Thu, 13 Jan 2005 07:30:19 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id D2B4B5D07; Thu, 13 Jan 2005 07:30:18 -0800 (PST) To: Marian Durkovic In-reply-to: Your message of "Thu, 13 Jan 2005 07:51:16 +0100." <20050113065116.GA19940@us.svf.stuba.sk> Date: Thu, 13 Jan 2005 07:30:18 -0800 From: "Kevin Oberman" Message-Id: <20050113153018.D2B4B5D07@ptavv.es.net> cc: freebsd-net@freebsd.org Subject: Re: IPv6 TCP transfers are hanging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 15:30:19 -0000 > Date: Thu, 13 Jan 2005 07:51:16 +0100 > From: Marian Durkovic > > Hi, > > > 08:20:12.680313 aaa.es.net.ssh > bbb.es.net.54854: . 10145:11573(1428) > > ack 31040 win 58548 [flowlabel 0x6ae53] > > len 1460, hlim 64) > > 1428 bytes is the proper payload length for TCPv6 with options > 1448 bytes is the same for TCPv4 > > 1440 bytes is the payload length for TCPv6 without options > 1460 byts is the same for TCPv4 > > If such packets are failing, your path MTU is probably not 1500 bytes but > smaller. Indeed, that is the case. One link is via a GRE tunnel and that is restricting MTU. What I don't understand is how this is happening. tcp.mssdflt is set to 1400 bytes and tcp.v6mssdflt is only 1024. If PMTU discovery was working, this should not be a problem. If PMTU discovery is not used, the MSS defaults should keep the packets small enough to work over the tunnel. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 17:03:49 2005 Return-Path: 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 E436316A4CE for ; Thu, 13 Jan 2005 17:03:49 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8366C43D55 for ; Thu, 13 Jan 2005 17:03:49 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] (pool-68-160-208-232.ny325.east.verizon.net [68.160.208.232]) by pi.codefab.com (8.12.11/8.12.11) with ESMTP id j0DH3Xc5089810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jan 2005 12:03:34 -0500 (EST) Message-ID: <41E6A9BC.9000406@mac.com> Date: Thu, 13 Jan 2005 12:02:52 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20050113153018.D2B4B5D07@ptavv.es.net> In-Reply-To: <20050113153018.D2B4B5D07@ptavv.es.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.8 required=5.5 tests=AWL,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=disabled version=3.0.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on pi.codefab.com cc: freebsd-net@freebsd.org Subject: Re: IPv6 TCP transfers are hanging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 17:03:50 -0000 Kevin Oberman wrote: > What I don't understand is how this is happening. tcp.mssdflt is set to > 1400 bytes and tcp.v6mssdflt is only 1024. If PMTU discovery was > working, this should not be a problem. If PMTU discovery is not used, > the MSS defaults should keep the packets small enough to work over the > tunnel. Doesn't IPv6 require a minimum MTU of 1280 bytes? Try setting the IPv6 TCP MSS to 1350 or so, bigger than IPv6 code requires, but small enough to fit into the ~1400+ byte MTU effectively available when you tunnel the traffic. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 19:00:54 2005 Return-Path: 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 ED9C516A5DE for ; Thu, 13 Jan 2005 19:00:54 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7A2143D2D for ; Thu, 13 Jan 2005 19:00:52 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 527867A403; Thu, 13 Jan 2005 11:00:52 -0800 (PST) Message-ID: <41E6C564.50005@elischer.org> Date: Thu, 13 Jan 2005 11:00:52 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Brooks Davis References: <41E5C9D8.4090209@elischer.org> <20050113055111.GA11141@odin.ac.hmc.edu> In-Reply-To: <20050113055111.GA11141@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: TCP out-of-order packets. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 19:00:55 -0000 Brooks Davis wrote: >On Wed, Jan 12, 2005 at 05:07:36PM -0800, Julian Elischer wrote: > > >>I have a link which is provided by someone else that is 7 x E1s aggregated. >>At leat it looks that way to me when I get to see it. however I have >>only been able to get >>60kB.sec across this, despite having a tcp window size of 131072 bytes.. >>After investigation it appears that the link is massively re-orderring >>packets. >>groups of upto 10 packets may appear in random order. (Maybe more, bu tI >>have seen 10) >> >>in fact packets are rarely IN order. >> >>This plays havoc with the tcp sessions. >> >>I was thinking of writing a hacked up version of NATD that >>instead of doing NAT, just did a pre-sort on packets from each session, >>so that the receiver would >>see a stream of IN-order packets, with occasional delays. >> >>firstly, does anyone have any tools to do this already (why build when >>you can borrow) >>and secondly, does anyone have any experience with this sort of problem? >> >>I have no control over or access to the link.. all I have is a promise >>that they will deliver >>14Mb/Sec. with approc 300mSec. RTT to me but there is no promise about >>packet order. >> >>I just get a 100Mb ethernet cable. >> >> > >Have you tried Andre's TCP reassembly rewrite? He says he saw >significant improvements in the face of major reordering. > > I don't think it's a problem with reassembly overhead, but rather a symptom of sender backoff when confronted with multiple duplicate acks due to the receiver getting the packets out of order. I wonder if there's a way to turn off the sender backoff? >http://www.mail-archive.com/freebsd-net@freebsd.org/msg14064.html > These machines are production machines on a custommer site.. running 4.8 it would be significant work to put the rewrite in (to 4.8) and a lot of red tape to reboot one to the new kernel.. :-/ > >-- Brooks > > > From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 19:06:50 2005 Return-Path: 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 A94E616A4CF for ; Thu, 13 Jan 2005 19:06:50 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C6AE43D46 for ; Thu, 13 Jan 2005 19:06:50 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j0DJ9r1P002919; Thu, 13 Jan 2005 11:09:53 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j0DJ9rWD002918; Thu, 13 Jan 2005 11:09:53 -0800 Date: Thu, 13 Jan 2005 11:09:53 -0800 From: Brooks Davis To: Julian Elischer Message-ID: <20050113190953.GC28303@odin.ac.hmc.edu> References: <41E5C9D8.4090209@elischer.org> <20050113055111.GA11141@odin.ac.hmc.edu> <41E6C564.50005@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TiqCXmo5T1hvSQQg" Content-Disposition: inline In-Reply-To: <41E6C564.50005@elischer.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: net@freebsd.org Subject: Re: TCP out-of-order packets. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 19:06:50 -0000 --TiqCXmo5T1hvSQQg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 13, 2005 at 11:00:52AM -0800, Julian Elischer wrote: >=20 >=20 > Brooks Davis wrote: >=20 > >On Wed, Jan 12, 2005 at 05:07:36PM -0800, Julian Elischer wrote: > >=20 > > > >>I have a link which is provided by someone else that is 7 x E1s=20 > >>aggregated. > >>At leat it looks that way to me when I get to see it. however I have=20 > >>only been able to get > >>60kB.sec across this, despite having a tcp window size of 131072 bytes.. > >>After investigation it appears that the link is massively re-orderring= =20 > >>packets. > >>groups of upto 10 packets may appear in random order. (Maybe more, bu t= I=20 > >>have seen 10) > >> > >>in fact packets are rarely IN order. > >> > >>This plays havoc with the tcp sessions. > >> > >>I was thinking of writing a hacked up version of NATD that > >>instead of doing NAT, just did a pre-sort on packets from each session,= =20 > >>so that the receiver would > >>see a stream of IN-order packets, with occasional delays. > >> > >>firstly, does anyone have any tools to do this already (why build when= =20 > >>you can borrow) > >>and secondly, does anyone have any experience with this sort of problem? > >> > >>I have no control over or access to the link.. all I have is a promise= =20 > >>that they will deliver > >>14Mb/Sec. with approc 300mSec. RTT to me but there is no promise about= =20 > >>packet order. > >> > >>I just get a 100Mb ethernet cable. > >> =20 > >> > > > >Have you tried Andre's TCP reassembly rewrite? He says he saw > >significant improvements in the face of major reordering. > >=20 > > >=20 > I don't think it's a problem with reassembly overhead, but rather a=20 > symptom of sender > backoff when confronted with multiple duplicate acks due to the receiver > getting the packets out of order. >=20 > I wonder if there's a way to turn off the sender backoff? >=20 > >http://www.mail-archive.com/freebsd-net@freebsd.org/msg14064.html > > >=20 > These machines are production machines on a custommer site.. running 4.8 > it would be significant work to put the rewrite in (to 4.8) and a lot=20 > of red tape to > reboot one to the new kernel.. :-/ Hmm, what about using a bridge with pf's TCP normalizer? You'd probably have to raise your socket buffer sizes to handle the added latency (not sure how much that is), but that might be an option (assuming adding another machine wasn't harder then installing a new kernel). That code is at least already written so you could also potentially crib from it for the hacked up natd idea. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --TiqCXmo5T1hvSQQg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB5seAXY6L6fI4GtQRAt6KAJ0fIJjLOwv1jpuGGXaps0R/MM+AfACg1BU6 F7Gx8BH6IzU/ni3K74O5nl8= =UVvx -----END PGP SIGNATURE----- --TiqCXmo5T1hvSQQg-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 19:13:03 2005 Return-Path: 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 72B9316A4CE for ; Thu, 13 Jan 2005 19:13:03 +0000 (GMT) Received: from kyoto.netlab.nec.de (kyoto.netlab.nec.de [195.37.70.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63D3843D48 for ; Thu, 13 Jan 2005 19:13:02 +0000 (GMT) (envelope-from lars.eggert@netlab.nec.de) Received: from [10.1.1.112] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6D6C11BACA9; Thu, 13 Jan 2005 20:12:57 +0100 (CET) Message-ID: <41E6C837.1020503@netlab.nec.de> Date: Thu, 13 Jan 2005 20:12:55 +0100 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: [Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O) Gecko/20040906 Camino/0.8+] X-Accept-Language: en,de,es,ja,fr,it,nl,sv,no,da,fi,pt,zh-cn,zh-tw,ko MIME-Version: 1.0 To: Julian Elischer References: <41E5C9D8.4090209@elischer.org> <20050113055111.GA11141@odin.ac.hmc.edu> <41E6C564.50005@elischer.org> In-Reply-To: <41E6C564.50005@elischer.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070605090401070409060605" cc: net@freebsd.org Subject: Re: TCP out-of-order packets. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 19:13:03 -0000 This is a cryptographically signed message in MIME format. --------------ms070605090401070409060605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >>> I have a link which is provided by someone else that is 7 x E1s >>> aggregated. At leat it looks that way to me when I get to see it. >>> however I have only been able to get 60kB.sec across this, >>> despite having a tcp window size of 131072 bytes.. After >>> investigation it appears that the link is massively re-orderring >>> packets. groups of upto 10 packets may appear in random order. >>> (Maybe more, bu tI have seen 10) >>> >>> in fact packets are rarely IN order. >>> This plays havoc with the tcp sessions. A gap or jump in the ACK stream looks to TCP like a loss, no matter that it's caused by reordering. Multiple such things per window look like multiple losses and trigger a slow start under Reno. TCP/SACK should be more robust against reorderings (up to a degree, at least.) Does 4.x have the SACK code yet? What sort of link multiplexer is this? Decent ones jump through all sorts of hoops to try and reestablish the original packet order. Lars -- Lars Eggert NEC Network Laboratories --------------ms070605090401070409060605 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJpzCC Ay4wggKXoAMCAQICAwyFWjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNjE3MDcyMjAzWhcNMDUwNjE3MDcyMjAz WjCBhDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTEiMCAGCSqG SIb3DQEJARYTbGFycy5lZ2dlcnRAZ214Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAOowMZjwQREXIdWxQacJDyqczykKpfIVmid2m8xBuUO53uWgnK3F8R20u/7PVugU zjNNqaivnU6qHtr/jdAn1UnyXzA/4Re+AqsKNiw8hZkVonkJ+G4O0TFzMNeWUdrjX1FaSAsL uAPA6661cN4YDzrOYC3O3zgGtVvJAra0+iw9eD2qWsnH0AVLFtq7H5ZFhz5zeOeCrrayqEhf S6tnTSjBzaH8SOdeemPTxdLRbMptLSy7lEFo8f1xisltw2eRT0txoUCqq0mjFEp8LgJ+s6p1 4M4cG3CDkKd5kNjdTWaokAo4qmpfF9IyA7uheaAHAz8UOH5GsH+Vkjbz5yFO1SsCAwEAAaNL MEkwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYETbGFycy5lZ2dlcnRA Z214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAE9rOnUtJERYLNbDztLI sH4AolAWkvNKoj7Ikst1M1X3myXqxYAHa9bsoPJy15qEV2B4ftOmJLrZL9kb8RZnzGBii8a/ XQ5wqaHZAJYcxQ6lp6UDTabhQN7J1trAOKgs+PFlF3lm6NOkXygiQH5PPO5kIHRjNvXpNGYe C7S3K8YsMIIDLjCCApegAwIBAgIDDIVaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA2MTcwNzIyMDNaFw0wNTA2 MTcwNzIyMDNaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMT C0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRl MSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6jAxmPBBERch1bFBpwkPKpzPKQql8hWaJ3abzEG5Q7ne5aCcrcXx HbS7/s9W6BTOM02pqK+dTqoe2v+N0CfVSfJfMD/hF74Cqwo2LDyFmRWieQn4bg7RMXMw15ZR 2uNfUVpICwu4A8DrrrVw3hgPOs5gLc7fOAa1W8kCtrT6LD14PapaycfQBUsW2rsflkWHPnN4 54KutrKoSF9Lq2dNKMHNofxI5156Y9PF0tFsym0tLLuUQWjx/XGKyW3DZ5FPS3GhQKqrSaMU SnwuAn6zqnXgzhwbcIOQp3mQ2N1NZqiQCjiqal8X0jIDu6F5oAcDPxQ4fkawf5WSNvPnIU7V KwIDAQABo0swSTA5BgNVHREEMjAwgRlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlgRNsYXJz LmVnZ2VydEBnbXgubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAT2s6dS0k RFgs1sPO0siwfgCiUBaS80qiPsiSy3UzVfebJerFgAdr1uyg8nLXmoRXYHh+06Ykutkv2Rvx FmfMYGKLxr9dDnCpodkAlhzFDqWnpQNNpuFA3snW2sA4qCz48WUXeWbo06RfKCJAfk887mQg dGM29ek0Zh4LtLcrxiwwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyFWjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NTAxMTMxOTEyNTVaMCMGCSqGSIb3DQEJBDEWBBRMRoBzxh1zcCjTnm7KuznSZPAhWjBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQCaHGrDQ0r24m2/C05B99GGR8xPdAyOhBn/vru+RzF20N3x jxZJmZkZO83LQrQ0mgz1hsQDbL/sXt+qTztPyOpZ/OlxarHGjgDmOO/s6DJ8lfDPM/1MhbsE tbgjoAIsVW6u60j4Ekt0w0r9uQAWyFYLJDmWSBMxO9BpVgGVBIiroZbNpYPyKvyyaSIH43yH Y+GNOukbGF9VaHteCp/y+6qnbp8znjWCCojLy7T6LRUhaDjGV0fvQUD+mcVOyseHRGXYkT82 K0dyf12kF83SBuBMO30DCYem/i4kN7W9z0euKQDlTBR8jwpZa1pY4sk8c1gow4DkMBLwQ4sf FlykjH+kAAAAAAAA --------------ms070605090401070409060605-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 19:31:38 2005 Return-Path: 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 65F7916A4CE for ; Thu, 13 Jan 2005 19:31:38 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3111C43D39 for ; Thu, 13 Jan 2005 19:31:36 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 217FA7A403; Thu, 13 Jan 2005 11:31:36 -0800 (PST) Message-ID: <41E6CC97.90603@elischer.org> Date: Thu, 13 Jan 2005 11:31:35 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Brooks Davis References: <41E5C9D8.4090209@elischer.org> <20050113055111.GA11141@odin.ac.hmc.edu> <41E6C564.50005@elischer.org> <20050113190953.GC28303@odin.ac.hmc.edu> In-Reply-To: <20050113190953.GC28303@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: TCP out-of-order packets. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 19:31:38 -0000 Brooks Davis wrote: >On Thu, Jan 13, 2005 at 11:00:52AM -0800, Julian Elischer wrote: > > >>Brooks Davis wrote: >> >> >> >>>On Wed, Jan 12, 2005 at 05:07:36PM -0800, Julian Elischer wrote: >>> >>> >>> >>> >>>>I have a link which is provided by someone else that is 7 x E1s >>>>aggregated. >>>>At leat it looks that way to me when I get to see it. however I have >>>>only been able to get >>>>60kB.sec across this, despite having a tcp window size of 131072 bytes.. >>>>After investigation it appears that the link is massively re-orderring >>>>packets. >>>>groups of upto 10 packets may appear in random order. (Maybe more, bu tI >>>>have seen 10) >>>> >>>>in fact packets are rarely IN order. >>>> >>>>This plays havoc with the tcp sessions. >>>> >>>>I was thinking of writing a hacked up version of NATD that >>>>instead of doing NAT, just did a pre-sort on packets from each session, >>>>so that the receiver would >>>>see a stream of IN-order packets, with occasional delays. >>>> >>>>firstly, does anyone have any tools to do this already (why build when >>>>you can borrow) >>>>and secondly, does anyone have any experience with this sort of problem? >>>> >>>>I have no control over or access to the link.. all I have is a promise >>>>that they will deliver >>>>14Mb/Sec. with approc 300mSec. RTT to me but there is no promise about >>>>packet order. >>>> >>>>I just get a 100Mb ethernet cable. >>>> >>>> >>>> >>>> >>>Have you tried Andre's TCP reassembly rewrite? He says he saw >>>significant improvements in the face of major reordering. >>> >>> >>> >>> >>I don't think it's a problem with reassembly overhead, but rather a >>symptom of sender >>backoff when confronted with multiple duplicate acks due to the receiver >>getting the packets out of order. >> >>I wonder if there's a way to turn off the sender backoff? >> >> >> >>>http://www.mail-archive.com/freebsd-net@freebsd.org/msg14064.html >>> >>> >>> >>These machines are production machines on a custommer site.. running 4.8 >>it would be significant work to put the rewrite in (to 4.8) and a lot >>of red tape to >>reboot one to the new kernel.. :-/ >> >> > >Hmm, what about using a bridge with pf's TCP normalizer? You'd probably >have to raise your socket buffer sizes to handle the added latency (not >sure how much that is), but that might be an option (assuming adding >another machine wasn't harder then installing a new kernel). That code >is at least already written so you could also potentially crib from it >for the hacked up natd idea. > I have remote access to a handful of machines on a switch. I do not have access ot the switch or the wiring or the link.. for added points the machines are in India. > >-- Brooks > > > From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 21:40:43 2005 Return-Path: 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 AB35616A4CE for ; Thu, 13 Jan 2005 21:40:43 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E03C643D1F for ; Thu, 13 Jan 2005 21:40:42 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 88590 invoked from network); 13 Jan 2005 21:24:05 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Jan 2005 21:24:05 -0000 Message-ID: <41E6EADC.2AFAEA47@freebsd.org> Date: Thu, 13 Jan 2005 22:40:44 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer References: <41E5C9D8.4090209@elischer.org> <41E6C564.50005@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: TCP out-of-order packets. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 21:40:43 -0000 Julian Elischer wrote: > > Brooks Davis wrote: > > >On Wed, Jan 12, 2005 at 05:07:36PM -0800, Julian Elischer wrote: > > > > > >>I have a link which is provided by someone else that is 7 x E1s aggregated. > >>At leat it looks that way to me when I get to see it. however I have > >>only been able to get > >>60kB.sec across this, despite having a tcp window size of 131072 bytes.. > >>After investigation it appears that the link is massively re-orderring > >>packets. > >>groups of upto 10 packets may appear in random order. (Maybe more, bu tI > >>have seen 10) > >> > >>in fact packets are rarely IN order. > >> > >>This plays havoc with the tcp sessions. > >> > >>I was thinking of writing a hacked up version of NATD that > >>instead of doing NAT, just did a pre-sort on packets from each session, > >>so that the receiver would > >>see a stream of IN-order packets, with occasional delays. > >> > >>firstly, does anyone have any tools to do this already (why build when > >>you can borrow) > >>and secondly, does anyone have any experience with this sort of problem? > >> > >>I have no control over or access to the link.. all I have is a promise > >>that they will deliver > >>14Mb/Sec. with approc 300mSec. RTT to me but there is no promise about > >>packet order. > >> > >>I just get a 100Mb ethernet cable. > >> > >> > > > >Have you tried Andre's TCP reassembly rewrite? He says he saw > >significant improvements in the face of major reordering. > > > > > > I don't think it's a problem with reassembly overhead, but rather a > symptom of sender > backoff when confronted with multiple duplicate acks due to the receiver > getting the packets out of order. > > I wonder if there's a way to turn off the sender backoff? Not directly. What you actually want is to delay the generating of ACK's for a certain amount of time (some milli-seconds) to aggregate the out-of-order packets into one ACK and to avoid the backoff from the other side. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 21:55:36 2005 Return-Path: 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 63B7516A4CE for ; Thu, 13 Jan 2005 21:55:36 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 657C343D46 for ; Thu, 13 Jan 2005 21:55:35 +0000 (GMT) (envelope-from oppermann@networx.ch) Received: (qmail 88718 invoked from network); 13 Jan 2005 21:38:57 -0000 Received: from unknown (HELO networx.ch) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Jan 2005 21:38:57 -0000 Message-ID: <41E6EE58.EBF168A4@networx.ch> Date: Thu, 13 Jan 2005 22:55:36 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Girish Rayas References: <9c9fb1860501101737268508be@mail.gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Bug in TCP window update? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 21:55:36 -0000 Girish Rayas wrote: > > In tcp_input.c, window is updated when below condition is true, > > if ((thflags & TH_ACK) && > (SEQ_LT(tp->snd_wl1, th->th_seq) || > (tp->snd_wl1 == th->th_seq && (SEQ_LT(tp->snd_wl2, th->th_ack) || > (tp->snd_wl2 == th->th_ack && tiwin > tp->snd_wnd))))) > > This check is to prevent old segments from affecting the send window. > But, left trim logic that was executed earlier in tcp_input.c sets the > th->th_seq to > tp->rcv_nxt for old segments. In many scenarios this effectively causes > snd_wl1 < th_seq and results in incorrect window update by old > segments. > > Using actual sequence number of received segment in the above if > statement will fix the problem. Any comments? Please file a PR and post the PR number so we can track this properly. Thanks -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 23:04:03 2005 Return-Path: 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 F2ACF16A4CE for ; Thu, 13 Jan 2005 23:04:02 +0000 (GMT) Received: from thor-new.fsklaw.com (adsl-64-174-116-34.dsl.lsan03.pacbell.net [64.174.116.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 844B143D2F for ; Thu, 13 Jan 2005 23:04:02 +0000 (GMT) (envelope-from tms3@fskklaw.com) Received: from prism.fsklaw.net [24.199.7.138] by thor-new.fsklaw.com (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.6.0)); Thu, 13 Jan 2005 15:05:07 -0800 Message-ID: <41E6FE9E.5070005@fskklaw.com> Date: Thu, 13 Jan 2005 15:05:02 -0800 From: "Thomas M. Skeren III" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ArGoMail-Authenticated: tms3 Subject: SMBFS with AMD64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 23:04:03 -0000 Trying to compile AMD64 with smbfs. Added options SMBFS options NETSMB got a lot of errors like this: smb_usr.o(.text+0x5ae): In function `smb_usr_simplerequest': : undefined reference to `md_get_mem' smb_usr.o(.text+0x5c3): In function `smb_usr_simplerequest': : undefined reference to `md_get_uint16le' smb_usr.o(.text+0x5f3): In function `smb_usr_simplerequest': : undefined reference to `md_get_mem' smb_usr.o(.text+0x674): In function `smb_cpdatain': : undefined reference to `mb_init' smb_usr.o(.text+0x82b): In function `smb_usr_t2request': : undefined reference to `md_get_mem' smb_usr.o(.text+0x86b): In function `smb_usr_t2request': : undefined reference to `md_get_mem' smb_usr.o(.text+0x69c): In function `smb_cpdatain': : undefined reference to `mb_put_mem' *** Error code 1 Stop in /usr/obj/usr/src/sys/NATELF. *** Error code 1 Stop in /usr/src. *** Error code 1 I'm just a humble sysadmin. Anyone got any thing to help on this? A link to a manual would be more than enough. Any help is appreciated. TMS III From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 23:17:08 2005 Return-Path: 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 0EA5B16A4CE for ; Thu, 13 Jan 2005 23:17:08 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C33143D45 for ; Thu, 13 Jan 2005 23:17:07 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B9067512C4; Thu, 13 Jan 2005 15:17:06 -0800 (PST) Date: Thu, 13 Jan 2005 15:17:06 -0800 From: Kris Kennaway To: "Thomas M. Skeren III" Message-ID: <20050113231706.GA19106@xor.obsecurity.org> References: <41E6FE9E.5070005@fskklaw.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <41E6FE9E.5070005@fskklaw.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-net@freebsd.org Subject: Re: SMBFS with AMD64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 23:17:08 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 13, 2005 at 03:05:02PM -0800, Thomas M. Skeren III wrote: > Trying to compile AMD64 with smbfs. >=20 > Added >=20 > options SMBFS > options NETSMB >=20 > got a lot of errors like this: >=20 >=20 > smb_usr.o(.text+0x5ae): In function `smb_usr_simplerequest': > : undefined reference to `md_get_mem' > smb_usr.o(.text+0x5c3): In function `smb_usr_simplerequest': This almost always means that you omitted something mandatory for your kernel configuration. Go back to GENERIC or carefully compare your modified config file to GENERIC and NOTES to look for what you missed. Kris --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB5wFyWry0BWjoQKURAoKLAJ96SzSSYRbJeb2gZIfjrrvRaoXqywCg1W5h 0jJuBReOl8mx+ueKJMNQc+s= =lk+P -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 23:30:23 2005 Return-Path: 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 492E116A4CE for ; Thu, 13 Jan 2005 23:30:23 +0000 (GMT) Received: from thor-new.fsklaw.com (adsl-64-174-116-34.dsl.lsan03.pacbell.net [64.174.116.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id F238043D41 for ; Thu, 13 Jan 2005 23:30:22 +0000 (GMT) (envelope-from tms3@fskklaw.com) Received: from prism.fsklaw.net [24.199.7.138] by thor-new.fsklaw.com (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.6.0)); Thu, 13 Jan 2005 15:31:29 -0800 Message-ID: <41E704CA.1000405@fskklaw.com> Date: Thu, 13 Jan 2005 15:31:22 -0800 From: "Thomas M. Skeren III" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <41E6FE9E.5070005@fskklaw.com> <20050113231706.GA19106@xor.obsecurity.org> In-Reply-To: <20050113231706.GA19106@xor.obsecurity.org> X-ArGoMail-Authenticated: tms3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-net@freebsd.org Subject: Re: SMBFS with AMD64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 23:30:23 -0000 Kris Kennaway wrote: >On Thu, Jan 13, 2005 at 03:05:02PM -0800, Thomas M. Skeren III wrote: > > >>Trying to compile AMD64 with smbfs. >> >>Added >> >>options SMBFS >>options NETSMB >> >>got a lot of errors like this: >> >> >>smb_usr.o(.text+0x5ae): In function `smb_usr_simplerequest': >>: undefined reference to `md_get_mem' >>smb_usr.o(.text+0x5c3): In function `smb_usr_simplerequest': >> >> > >This almost always means that you omitted something mandatory for your >kernel configuration. Go back to GENERIC or carefully compare your >modified config file to GENERIC and NOTES to look for what you missed. > > Will do, however, I copied GENERIC to NAT and just add the two options, and deleted the scsi devices as I don't have SCSI. Here's the diff: COr# diff GENERIC NATELF 59c59,60 < --- > options SMBFS > options NETSMB >Kris > > From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 23:34:06 2005 Return-Path: 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 B63D616A4CE; Thu, 13 Jan 2005 23:34:06 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C28EE43D46; Thu, 13 Jan 2005 23:34:05 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 8CA887A403; Thu, 13 Jan 2005 15:34:04 -0800 (PST) Message-ID: <41E7056B.4010805@elischer.org> Date: Thu, 13 Jan 2005 15:34:03 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Andre Oppermann References: <41E5C9D8.4090209@elischer.org> <20050113055111.GA11141@odin.ac.hmc.edu> <41E6C564.50005@elischer.org> <41E6EADC.2AFAEA47@freebsd.org> In-Reply-To: <41E6EADC.2AFAEA47@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: TCP out-of-order packets. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 23:34:06 -0000 Andre Oppermann wrote: >Julian Elischer wrote: > > >>Brooks Davis wrote: >> >> >> >>>On Wed, Jan 12, 2005 at 05:07:36PM -0800, Julian Elischer wrote: >>> >>> >>> >>> >>>>I have a link which is provided by someone else that is 7 x E1s aggregated. >>>>At leat it looks that way to me when I get to see it. however I have >>>>only been able to get >>>>60kB.sec across this, despite having a tcp window size of 131072 bytes.. >>>>After investigation it appears that the link is massively re-orderring >>>>packets. >>>>groups of upto 10 packets may appear in random order. (Maybe more, bu tI >>>>have seen 10) >>>> >>>>in fact packets are rarely IN order. >>>> >>>>This plays havoc with the tcp sessions. >>>> >>>>I was thinking of writing a hacked up version of NATD that >>>>instead of doing NAT, just did a pre-sort on packets from each session, >>>>so that the receiver would >>>>see a stream of IN-order packets, with occasional delays. >>>> >>>>firstly, does anyone have any tools to do this already (why build when >>>>you can borrow) >>>>and secondly, does anyone have any experience with this sort of problem? >>>> >>>>I have no control over or access to the link.. all I have is a promise >>>>that they will deliver >>>>14Mb/Sec. with approc 300mSec. RTT to me but there is no promise about >>>>packet order. >>>> >>>>I just get a 100Mb ethernet cable. >>>> >>>> >>>> >>>> >>>> >>>>I wonder if there's a way to turn off the sender backoff? >>>> >>>> > >Not directly. What you actually want is to delay the generating of >ACK's for a certain amount of time (some milli-seconds) to aggregate >the out-of-order packets into one ACK and to avoid the backoff from >the other side. > > yes, here's a trace from the receiver's end showing the order of received packets.. RTT on this link is about 300mSec. My original answer would be to hack NATD to re-order the packets. and use DIVERT to it. DeltaT SEQ-SRTR:SEQ_END packet# ------------------------------------------ 346853 2856:2920(64) 1 370821 2920:4368(1448) 2 004410 8712:10160(1448) 6 007848 12608:14056(1448) 9 007057 18400:19848(1448) 13 004027 11160:12608(1448) 8 005553 4368:5816(1448) 3 002390 16952:18400(1448) 12 005745 7264:8712(1448) 5 001204 5816:7264(1448) 4 008326 14056:15504(1448) 10 002555 10160:11160(1000) 7 004091 19848:21296(1448) 14 004287 15504:16952(1448) 11 358289 22744:24192(1448) 16 001891 21296:22744(1448) 15 048289 4368:5816(1448) DUP of 3 025538 5816:7264(1448) DUP of 4 018761 10160:11608(1448) DUP of 7 062939 25640:27088(1448) 18 005493 15504:16952(1448) DUP of 11 007903 24192:25640(1448) 17 002207 27088:28536(1448) 19 028675 21296:22744(1448) DUP of 15 176400 28536:29984(1448) 20 020889 29984:31432(1448) 21 092304 24192:25640(1448) DUP of 17 038396 31432:32880(1448) 22 015146 32880:34328(1448) 23 010362 27088:28536(1448) DUP of 19 027400 35776:37224(1448) 25 008269 28536:29984(1448) DUP of 20 012537 34328:35776(1448) 24 294035 37224:38672(1448) 26 078059 34328:35776(1448) DUP of 24 267701 40120:41568(1448) 28 017393 38672:40120(1448) 27 019769 41568:43016(1448) 29 339347 44464:45912(1448) 31 003887 43016:44464(1448) 30 123755 45912:47360(1448) 32 228883 47360:48808(1448) 33 013437 48808:50256(1448) 34 219579 50256:51704(1448) 35 144501 51704:53152(1448) 36 001200 53152:54600(1448) 37 029175 54600:56048(1448) 38 183158 56048:57496(1448) 39 157127 58944:60392(1448) 40 By here the sender has backed right off. > > > From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 00:00:15 2005 Return-Path: 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 54CF616A4CE for ; Fri, 14 Jan 2005 00:00:15 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DB3143D49 for ; Fri, 14 Jan 2005 00:00:13 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id j0DNwxAr001598 for ; Fri, 14 Jan 2005 10:28:59 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Fri, 14 Jan 2005 10:30:01 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id j0DNoTQ04704 for ; Fri, 14 Jan 2005 10:20:29 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YK38CXMN; Fri, 14 Jan 2005 10:20:10 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id j0DNp8ZJ049802 for ; Fri, 14 Jan 2005 10:21:08 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id j0DNp8gw049801 for net@freebsd.org; Fri, 14 Jan 2005 10:21:08 +1030 (CST) (envelope-from wilkinsa) Date: Fri, 14 Jan 2005 10:21:08 +1030 From: "Wilkinson, Alex" To: net@freebsd.org Message-ID: <20050113235108.GJ49309@squash.dsto.defence.gov.au> Mail-Followup-To: net@freebsd.org References: <41E5C9D8.4090209@elischer.org> <20050113055111.GA11141@odin.ac.hmc.edu> <41E6C564.50005@elischer.org> <41E6EADC.2AFAEA47@freebsd.org> <41E7056B.4010805@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <41E7056B.4010805@elischer.org> User-Agent: Mutt/1.5.6i Subject: Re: TCP out-of-order packets. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 00:00:15 -0000 0n Thu, Jan 13, 2005 at 03:34:03PM -0800, Julian Elischer wrote: >DeltaT SEQ-SRTR:SEQ_END packet# >------------------------------------------ >346853 2856:2920(64) 1 >370821 2920:4368(1448) 2 >004410 8712:10160(1448) 6 >007848 12608:14056(1448) 9 >007057 18400:19848(1448) 13 >004027 11160:12608(1448) 8 >005553 4368:5816(1448) 3 >002390 16952:18400(1448) 12 >005745 7264:8712(1448) 5 >001204 5816:7264(1448) 4 >008326 14056:15504(1448) 10 >002555 10160:11160(1000) 7 >004091 19848:21296(1448) 14 >004287 15504:16952(1448) 11 >358289 22744:24192(1448) 16 >001891 21296:22744(1448) 15 >048289 4368:5816(1448) DUP of 3 >025538 5816:7264(1448) DUP of 4 >018761 10160:11608(1448) DUP of 7 >062939 25640:27088(1448) 18 >005493 15504:16952(1448) DUP of 11 >007903 24192:25640(1448) 17 >002207 27088:28536(1448) 19 >028675 21296:22744(1448) DUP of 15 >176400 28536:29984(1448) 20 >020889 29984:31432(1448) 21 >092304 24192:25640(1448) DUP of 17 >038396 31432:32880(1448) 22 >015146 32880:34328(1448) 23 >010362 27088:28536(1448) DUP of 19 >027400 35776:37224(1448) 25 >008269 28536:29984(1448) DUP of 20 >012537 34328:35776(1448) 24 >294035 37224:38672(1448) 26 >078059 34328:35776(1448) DUP of 24 >267701 40120:41568(1448) 28 >017393 38672:40120(1448) 27 >019769 41568:43016(1448) 29 >339347 44464:45912(1448) 31 >003887 43016:44464(1448) 30 >123755 45912:47360(1448) 32 >228883 47360:48808(1448) 33 >013437 48808:50256(1448) 34 >219579 50256:51704(1448) 35 >144501 51704:53152(1448) 36 >001200 53152:54600(1448) 37 >029175 54600:56048(1448) 38 >183158 56048:57496(1448) 39 >157127 58944:60392(1448) 40 > >By here the sender has backed right off. What tool did u use to gather these stats ? - aW From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 00:22:05 2005 Return-Path: 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 E64C216A4CE; Fri, 14 Jan 2005 00:22:05 +0000 (GMT) Received: from one.valcatohosting.com (one.valcatohosting.com [67.19.219.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB7C343D1D; Fri, 14 Jan 2005 00:22:05 +0000 (GMT) (envelope-from adam@moosoft.net) Received: from cpc3-nthc1-4-0-cust42.nrth.cable.ntl.com ([213.107.150.42] helo=[192.168.1.100]) by one.valcatohosting.com with esmtpa (Exim 4.43) id 1CpA8a-00040z-4K; Thu, 13 Jan 2005 18:56:05 +0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <03FAB198-6595-11D9-96E8-000D93B7419E@moosoft.net> Content-Transfer-Encoding: 7bit From: Adam McMaster Date: Thu, 13 Jan 2005 18:57:47 +0000 To: freebsd-net@freebsd.org, freebsd-hardware@freebsd.org X-Mailer: Apple Mail (2.619) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - one.valcatohosting.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - moosoft.net X-Source: X-Source-Args: X-Source-Dir: Subject: if_ndis with custom CPUTYPE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 00:22:06 -0000 Hey, I've recently had a confusing problem using the NDIS modules and thought it might be of interest to someone. On Sunday I decided to update to the latest RELENG_5_3, since there have been some patches since the initial release. Everything seemed to work perfectly after everything was rebuilt and installed, until the next morning when I discovered that the PC was no longer able to connect to my wireless network. I'm still not sure exactly what the problem was, all I can say is that I never got an "ndis0: link up" message. After some thinking, I realised that I had customised the CPUTYPE and CFLAGS variables in make.conf since last time I built FreeBSD, and after some experimenting I managed to get it to work by rebuilding the ndis and if_ndis modules without the CPUTYPE variable set. So my assumption is that something GCC did with the CPUTYPE variable broke the ndis modules (or at least one of them). Interestingly, the card continued to work after a reboot. It was only after the PC was actually powered off (i.e. when I went to bed that night) and powered back on that the problem occurred. If it helps, the card is a Belkin F5D6020 ver 3, and I'm using the rtl8180 driver (available from the RealTek web site). In make.conf I had CPUTYPE=athlon, and here is the output of uname -a: FreeBSD phoenix 5.3-RELEASE-p4 FreeBSD 5.3-RELEASE-p4 #0: Sun Jan 9 17:10:20 GMT 2005 root@phoenix:/usr/obj/usr/src/sys/GENERIC i386 That's all I've got to say; hopefully this can be helpful to someone in the future. -- - Adam McMaster From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 01:18:55 2005 Return-Path: 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 5FC6616A4CE for ; Fri, 14 Jan 2005 01:18:55 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F9E243D2F for ; Fri, 14 Jan 2005 01:18:53 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 0B8727A403; Thu, 13 Jan 2005 17:18:53 -0800 (PST) Message-ID: <41E71DFC.1060106@elischer.org> Date: Thu, 13 Jan 2005 17:18:52 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: "Wilkinson, Alex" References: <41E5C9D8.4090209@elischer.org> <20050113055111.GA11141@odin.ac.hmc.edu> <41E6C564.50005@elischer.org> <41E6EADC.2AFAEA47@freebsd.org> <41E7056B.4010805@elischer.org> <20050113235108.GJ49309@squash.dsto.defence.gov.au> In-Reply-To: <20050113235108.GJ49309@squash.dsto.defence.gov.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: TCP out-of-order packets. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 01:18:55 -0000 Wilkinson, Alex wrote: > 0n Thu, Jan 13, 2005 at 03:34:03PM -0800, Julian Elischer wrote: > > >DeltaT SEQ-SRTR:SEQ_END packet# > >------------------------------------------ > >346853 2856:2920(64) 1 > >370821 2920:4368(1448) 2 > >004410 8712:10160(1448) 6 > >007848 12608:14056(1448) 9 > >007057 18400:19848(1448) 13 > >004027 11160:12608(1448) 8 > >005553 4368:5816(1448) 3 > >002390 16952:18400(1448) 12 > >005745 7264:8712(1448) 5 > >001204 5816:7264(1448) 4 > >008326 14056:15504(1448) 10 > >002555 10160:11160(1000) 7 > >004091 19848:21296(1448) 14 > >004287 15504:16952(1448) 11 > >358289 22744:24192(1448) 16 > >001891 21296:22744(1448) 15 > >048289 4368:5816(1448) DUP of 3 > >025538 5816:7264(1448) DUP of 4 > >018761 10160:11608(1448) DUP of 7 > >062939 25640:27088(1448) 18 > >005493 15504:16952(1448) DUP of 11 > >007903 24192:25640(1448) 17 > >002207 27088:28536(1448) 19 > >028675 21296:22744(1448) DUP of 15 > >176400 28536:29984(1448) 20 > >020889 29984:31432(1448) 21 > >092304 24192:25640(1448) DUP of 17 > >038396 31432:32880(1448) 22 > >015146 32880:34328(1448) 23 > >010362 27088:28536(1448) DUP of 19 > >027400 35776:37224(1448) 25 > >008269 28536:29984(1448) DUP of 20 > >012537 34328:35776(1448) 24 > >294035 37224:38672(1448) 26 > >078059 34328:35776(1448) DUP of 24 > >267701 40120:41568(1448) 28 > >017393 38672:40120(1448) 27 > >019769 41568:43016(1448) 29 > >339347 44464:45912(1448) 31 > >003887 43016:44464(1448) 30 > >123755 45912:47360(1448) 32 > >228883 47360:48808(1448) 33 > >013437 48808:50256(1448) 34 > >219579 50256:51704(1448) 35 > >144501 51704:53152(1448) 36 > >001200 53152:54600(1448) 37 > >029175 54600:56048(1448) 38 > >183158 56048:57496(1448) 39 > >157127 58944:60392(1448) 40 > > > >By here the sender has backed right off. > >What tool did u use to gather these stats ? > tcpdump, awk and vi :-) (would have been nice if it had been automatic but it was manual..) > > - aW >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 02:51:23 2005 Return-Path: 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 6C78916A4CE for ; Fri, 14 Jan 2005 02:51:23 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9412B43D4C for ; Fri, 14 Jan 2005 02:51:22 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 357B851458; Thu, 13 Jan 2005 18:51:20 -0800 (PST) Date: Thu, 13 Jan 2005 18:51:20 -0800 From: Kris Kennaway To: "Thomas M. Skeren III" Message-ID: <20050114025120.GA66894@xor.obsecurity.org> References: <41E6FE9E.5070005@fskklaw.com> <20050113231706.GA19106@xor.obsecurity.org> <41E704CA.1000405@fskklaw.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: <41E704CA.1000405@fskklaw.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-net@freebsd.org cc: Kris Kennaway Subject: Re: SMBFS with AMD64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 02:51:23 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 13, 2005 at 03:31:22PM -0800, Thomas M. Skeren III wrote: > Kris Kennaway wrote: >=20 > >On Thu, Jan 13, 2005 at 03:05:02PM -0800, Thomas M. Skeren III wrote: > >=20 > > > >>Trying to compile AMD64 with smbfs. > >> > >>Added > >> > >>options SMBFS > >>options NETSMB > >> > >>got a lot of errors like this: > >> > >> > >>smb_usr.o(.text+0x5ae): In function `smb_usr_simplerequest': > >>: undefined reference to `md_get_mem' > >>smb_usr.o(.text+0x5c3): In function `smb_usr_simplerequest': > >> =20 > >> > > > >This almost always means that you omitted something mandatory for your > >kernel configuration. Go back to GENERIC or carefully compare your > >modified config file to GENERIC and NOTES to look for what you missed. > >=20 > > > Will do, however, I copied GENERIC to NAT and just add the two options,= =20 > and deleted the scsi devices as I don't have SCSI. >=20 > Here's the diff: >=20 > COr# diff GENERIC NATELF > 59c59,60 > < > --- > > options SMBFS > > options NETSMB=20 OK, so follow the advice I gave ("carefully compare your modified config file to GENERIC and NOTES to look for what you missed"). ^^^^^^^^^ Kris --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB5zOnWry0BWjoQKURAv3EAKCObvq00df724dcBt0LwYWdgPPXhwCg5AZq aDBgkVIOZInr6XO/oDCzcig= =a+m/ -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 03:01:30 2005 Return-Path: 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 5AA7716A4CF for ; Fri, 14 Jan 2005 03:01:30 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FE3643D49 for ; Fri, 14 Jan 2005 03:01:10 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) j0E313V3018293; Thu, 13 Jan 2005 19:01:03 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.10/8.12.10/meer) with ESMTP id j0E30uBP007590; Thu, 13 Jan 2005 19:00:57 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Fri, 14 Jan 2005 12:00:51 +0900 Message-ID: From: gnn@freebsd.org To: Julian Elischer In-Reply-To: <41E5C9D8.4090209@elischer.org> References: <41E5C9D8.4090209@elischer.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: net@freebsd.org Subject: Re: TCP out-of-order packets. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 03:01:30 -0000 At Wed, 12 Jan 2005 17:07:36 -0800, julian wrote: > > and secondly, does anyone have any experience with this sort of problem? > Here is a paper on the subject: http://www.postel.org/pipermail/end2end-interest/2002-January/001705.html Later, George From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 03:05:06 2005 Return-Path: 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 A717D16A4CE for ; Fri, 14 Jan 2005 03:05:06 +0000 (GMT) Received: from perth-gateway.bluestonetin.com.au (perth-gateway.bluestonetin.com.au [203.59.135.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E9F643D1D for ; Fri, 14 Jan 2005 03:05:06 +0000 (GMT) (envelope-from david@okeby.com) Received: from [192.168.10.81] (unknown [192.168.10.81])C64511705D for ; Fri, 14 Jan 2005 11:05:04 +0800 (WST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <16039AC4-65D9-11D9-B661-000D932B7932@okeby.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-net@freebsd.org From: David Okeby Date: Fri, 14 Jan 2005 11:05:03 +0800 X-Mailer: Apple Mail (2.619) Subject: bge w/ altq support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 03:05:06 -0000 Are there any plans to bring the ALTQ support for the bge driver (rev 1.79) to RELENG_5? Thanks Dave -- david@okeby.com From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 07:27:16 2005 Return-Path: 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 80C7316A4CE for ; Fri, 14 Jan 2005 07:27:16 +0000 (GMT) Received: from smtp4.wlink.com.np (smtp4.wlink.com.np [202.79.32.87]) by mx1.FreeBSD.org (Postfix) with SMTP id 3605E43D1D for ; Fri, 14 Jan 2005 07:27:13 +0000 (GMT) (envelope-from bikrant_ml@wlink.com.np) Received: (qmail 27898 invoked from network); 14 Jan 2005 07:27:08 -0000 Received: from unknown (HELO qmail-scanner.wlink.com.np) (202.79.32.74) by 0 with SMTP; 14 Jan 2005 07:27:08 -0000 Received: (qmail 67910 invoked by uid 1008); 14 Jan 2005 07:27:08 -0000 Received: from bikrant_ml@wlink.com.np by qmail-scanner.wlink.com.np by uid 1002 with qmail-scanner-1.20 (clamscan: 0.70. Clear:RC:1(202.79.32.76):. Processed in 0.122382 secs); 14 Jan 2005 07:27:08 -0000 Received: from smtp1.wlink.com.np (202.79.32.76) by qmail-scanner.wlink.com.np with SMTP; 14 Jan 2005 07:27:07 -0000 Received: (qmail 13160 invoked by uid 508); 14 Jan 2005 07:27:07 -0000 Received: from [202.79.36.168] (HELO bikrant.org.np) by smtp1.wlink.com.np (qmail-smtpd) with SMTP; 14 Jan 2005 07:27:06 -0000 (Fri, 14 Jan 2005 13:12:06 +0545) From: Bikrant Neupane To: freebsd-questions@freebsd.org Date: Fri, 14 Jan 2005 13:12:00 +0545 User-Agent: KMail/1.7.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501141312.00737.bikrant_ml@wlink.com.np> X-Spam-Check-By: smtp1.wlink.com.np Spam: No ; -4.9 / 5.0 X-Spam-Status-WL: No, hits=-4.9 required=5.0 cc: freebsd-net@freebsd.org cc: Ted Mittelstaedt Subject: Re: Default LQR timeout period X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 07:27:16 -0000 Hi thanks for the answer. However I am trying to find solution from the server end if that is possible. Also I tried setting the InactivityTimeout to different values but still I am getting time out at 40-45 seconds :( regards, Bikrant On Thursday 13 January 2005 12:22, Ted Mittelstaedt wrote: > Open up your registry editor and go to > HEKY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Modem\XXXX\Set > tings where XXXX is the number of your modem (example: 0001). On the > right pane search for a string value named InactivityTimeout. Enter the > new timeout rate in minutes. For example enter 30 for a 30 minutes > timeout. > > From: > > http://www.activewin.com/tips/reg/connect_1.shtml > > Time it took me to find this - 45 seconds. It took you longer > to post the request than to type it into a search engine. > > Ted > > > -----Original Message----- > > From: owner-freebsd-questions@freebsd.org > > [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of > > Bikrant Neupane > > Sent: Wednesday, January 12, 2005 9:51 PM > > To: freebsd-questions@freebsd.org; freebsd-net@freebsd.org > > Subject: Default LQR timeout period > > > > > > Hi > > > > We have pppoe server running on FreeBSD 4.9 and 90% of our > > wireless clients > > are using MS Windows OS to access the service. I have noticed > > that when ever > > there is some problem in the link ( due to AP or SM reboot, > > switch reboot etc > > etc ) the pppoe connection closes. I have also noticed that > > the MS Windows > > client closes connection at 40-45 seconds after the link is > > down. I tried to > > increase default LQR timeout period at Server by using set > > lqrtimeout to some > > higher values. That did affected the serverside ppp process > > but the MS client > > still disconnected at 40-45 seconds. :( > > > > I prefer to set the timeout period somewhere between 120-150 > > seconds so that > > even if there is problem in the link the client doesn't get > > the disconnect > > notice and have to reconnect again and the client and servers > > are able to > > continue same session. > > > > Is there any way to control the default LQR timeout period of > > the Client from > > the Server end?? > > > > My question is more related with ms windows still I am asking > > this question to > > freebsd group so that I can solve the problem from the server end ;) > > > > regards, > > Bikrant > > _______________________________________________ > > freebsd-questions@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to > > "freebsd-questions-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org"