From owner-freebsd-net Sun Jul 1 10: 0:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72]) by hub.freebsd.org (Postfix) with ESMTP id 7EA1137B401; Sun, 1 Jul 2001 10:00:29 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by tonnant.cnchost.com id NAA07500; Sun, 1 Jul 2001 13:00:19 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200107011700.NAA07500@tonnant.cnchost.com> To: Wes Peters Cc: Ruslan Ermilov , Deepak Jain , net@FreeBSD.org, hackers@FreeBSD.org Subject: Re: fastforwarding? In-reply-to: Your message of "Wed, 27 Jun 2001 22:39:20 MDT." <3B3AB4F8.184A2EFE@softweyr.com> Date: Sun, 01 Jul 2001 10:00:19 -0700 From: Bakul Shah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > What does the fastforwarding option do that the normal forwarding option > > doesn't? > The description there isn't very forthcoming. fastforwarding caches > the results of a route lookup for destination addresses that are not > on the local machine, and uses the cached route to short-circuit the > normal (relatively slow) route lookup process. The packet flows > directly from one layer2 input routine directly to the opposing > layer2 output routine without traversing the IP layer. You do have to look at the destination ip address so strictly speaking the cache belongs to the ip "layer". I haven't looked at this fastforwarding code but it likely complicates route adding/deleting at you have to look at it for *any* route add/delete. For example, for dest addr 1.2.3.4, you cached the result of route lookup (which may be 1.2.x.x/16) and now a route for 1.2.?.x/24 is added. You may have to invalidate the cache entry since the new route may have to be used. Similarly for deletes. Even the old single entry cache in the std 4.4bsd had/has a related bug. IMHO you are better off using a recent route lookup algorithm than messing with caches. The PATRICIA tree algorithm is what 33 years old now? There has been a lot of research done in this area in the last few years. On a modern machine with some of the recent algorithms you should be able to easily do a lookup in a just a few memory accesses. The changeover is not easy and quite pervasive in the networking code but long overdue. If anyone decides to do this, please make the changes so that any algorithm can be pluuged in. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 1 14:11:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id 38EBF37B406; Sun, 1 Jul 2001 14:11:11 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost.softweyr.com ([127.0.0.1] helo=softweyr.com ident=b4004fd9460c57e7fc99d9894ba5bdd5) by softweyr.com with esmtp (Exim 3.16 #1) id 15GoZQ-0000Td-00; Sun, 01 Jul 2001 15:15:56 -0600 Message-ID: <3B3F930C.320CC3DC@softweyr.com> Date: Sun, 01 Jul 2001 15:15:56 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: Dag-Erling Smorgrav , Deepak Jain , net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: fastforwarding? References: <20010626093545.D49992@sunbay.com> <3B3AB4F8.184A2EFE@softweyr.com> <20010629112757.F91115@sunbay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ruslan Ermilov wrote: > > BTW, Wes, I'm still waiting for a working example of an indirect route > with also indirect gateway. Any indirect route via the opposite end of a point-to-point connection. Right? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 1 14:48: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id B703637B401; Sun, 1 Jul 2001 14:48:03 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost.softweyr.com ([127.0.0.1] helo=softweyr.com ident=0d3067936644647a06e6a8eeb376984c) by softweyr.com with esmtp (Exim 3.16 #1) id 15Gp92-0000Uy-00; Sun, 01 Jul 2001 15:52:44 -0600 Message-ID: <3B3F9BAC.782B8E00@softweyr.com> Date: Sun, 01 Jul 2001 15:52:44 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Bakul Shah Cc: Ruslan Ermilov , Deepak Jain , net@FreeBSD.org, hackers@FreeBSD.org Subject: Re: fastforwarding? References: <200107011700.NAA07500@tonnant.cnchost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bakul Shah wrote: > > IMHO you are better off using a recent route lookup algorithm > than messing with caches. The PATRICIA tree algorithm is > what 33 years old now? Not true. Any routing algorithm takes longer because they are by definition a "fuzzy match." The fastforward algorithm is not, it is a simple destination address lookup; the cached route is either there or it is not. Fast hashing algorithms are quite effective in locating the route if it has been cached. Routing switches usually speed up the lookup even further by using Content Addressable Memory to map the destination address to a cached route or interface pointer; it would be interesting to experiment with something like that in FreeBSD. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 1 19:45:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 3BEA037B403 for ; Sun, 1 Jul 2001 19:45:48 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 1683 invoked by uid 1000); 2 Jul 2001 02:45:47 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Jul 2001 02:45:47 -0000 Date: Sun, 1 Jul 2001 21:45:47 -0500 (CDT) From: Mike Silbersack To: Jonathan Lemon Cc: Glenn Johnson , , , Gilbert Gong Subject: Re: select fails to return incoming connect on FreeBSD-4.3 In-Reply-To: <20010627220031.B10008@prism.flugsvamp.com> Message-ID: <20010701214104.V1087-200000@achilles.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1989767161-994041947=:1087" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1989767161-994041947=:1087 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 27 Jun 2001, Jonathan Lemon wrote: > I don't object; while the security provided by the new scheme is nice, > breaking TIME_WAIT assassination is a serious bug in some environments, > and there should be a way to work around it now. > -- > Jonathan Ok, attached is a patch for 4.3-stable which makes the generation scheme sysctl selectable. You use the sysctl net.inet.tcp.tcp_seq_genscheme to set which scheme you want. 0 is the old random positive increments scheme, 1 is the more random OpenBSD scheme. 1 is the default setting, so those encountering the TIME_WAIT problem will have to put something in a boot script to set the variable to 0. There's one slight difference in this implementation of the old scheme versus the old implementation of it. Before, we used TCP_ISSINCR/2 for outgoing incrementations, and /4 for incoming. We use /2 in both cases now, for simplicity's sake. Please review, especially if you're experiencing the TIME_WAIT problem. Thanks, Mike "Silby" Silbersack --0-1989767161-994041947=:1087 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="multiple_isn_schemes.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20010701214547.P1087@achilles.silby.com> Content-Description: Content-Disposition: attachment; filename="multiple_isn_schemes.patch" ZGlmZiAtdSAtciBuZXRpbmV0Lm9sZC90Y3BfaW5wdXQuYyBuZXRpbmV0L3Rj cF9pbnB1dC5jDQotLS0gbmV0aW5ldC5vbGQvdGNwX2lucHV0LmMJU3VuIEp1 bCAgMSAyMDo0NDo1MCAyMDAxDQorKysgbmV0aW5ldC90Y3BfaW5wdXQuYwlT dW4gSnVsICAxIDIxOjE3OjU4IDIwMDENCkBAIC0xMDgwLDcgKzEwODAsNyBA QA0KIAkJaWYgKGlzcykNCiAJCQl0cC0+aXNzID0gaXNzOw0KIAkJZWxzZSB7 DQotCQkJdHAtPmlzcyA9IHRjcF9ybmRpc3NfbmV4dCgpOw0KKwkJCXRwLT5p c3MgPSB0Y3BfbmV3X2lzbigpOw0KICAJCX0NCiAJCXRwLT5pcnMgPSB0aC0+ dGhfc2VxOw0KIAkJdGNwX3NlbmRzZXFpbml0KHRwKTsNCkBAIC0xNjEyLDcg KzE2MTIsNyBAQA0KIAkJCWlmICh0aGZsYWdzICYgVEhfU1lOICYmDQogCQkJ ICAgIHRwLT50X3N0YXRlID09IFRDUFNfVElNRV9XQUlUICYmDQogCQkJICAg IFNFUV9HVCh0aC0+dGhfc2VxLCB0cC0+cmN2X254dCkpIHsNCi0JCQkJaXNz ID0gdGNwX3JuZGlzc19uZXh0KCk7DQorCQkJCWlzcyA9IHRjcF9uZXdfaXNu KCk7DQogCQkJCXRwID0gdGNwX2Nsb3NlKHRwKTsNCiAJCQkJZ290byBmaW5k cGNiOw0KIAkJCX0NCmRpZmYgLXUgLXIgbmV0aW5ldC5vbGQvdGNwX3NlcS5o IG5ldGluZXQvdGNwX3NlcS5oDQotLS0gbmV0aW5ldC5vbGQvdGNwX3NlcS5o CVN1biBKdWwgIDEgMjA6NDQ6NTAgMjAwMQ0KKysrIG5ldGluZXQvdGNwX3Nl cS5oCVN1biBKdWwgIDEgMjE6MDg6MDIgMjAwMQ0KQEAgLTgxLDYgKzgxLDI0 IEBADQogI2lmZGVmIF9LRVJORUwNCiBleHRlcm4gdGNwX2NjCXRjcF9jY2dl bjsJCS8qIGdsb2JhbCBjb25uZWN0aW9uIGNvdW50ICovDQogDQorLyoNCisg KiBJbmNyZW1lbnQgZm9yIHRjcF9pc3MgZWFjaCBzZWNvbmQuDQorICogVGhp cyBpcyBkZXNpZ25lZCB0byBpbmNyZW1lbnQgYXQgdGhlIHN0YW5kYXJkIDI1 MCBLQi9zLA0KKyAqIGJ1dCB3aXRoIGEgcmFuZG9tIGNvbXBvbmVudCBhdmVy YWdpbmcgMTI4IEtCLg0KKyAqIFdlIGFsc28gaW5jcmVtZW50IHRjcF9pc3Mg YnkgYSBxdWFydGVyIG9mIHRoaXMgYW1vdW50DQorICogZWFjaCB0aW1lIHdl IHVzZSB0aGUgdmFsdWUgZm9yIGEgbmV3IGNvbm5lY3Rpb24uDQorICogSWYg ZGVmaW5lZCwgdGhlIHRjcF9yYW5kb20xOCgpIG1hY3JvIHNob3VsZCBwcm9k dWNlIGENCisgKiBudW1iZXIgaW4gdGhlIHJhbmdlIFswLTB4M2ZmZmZdIHRo YXQgaXMgaGFyZCB0byBwcmVkaWN0Lg0KKyAqIA0KKyAqIFRoZSB2YXJpYWJs ZSB0Y3BfaXNzIGFuZCB0Y3BfcmFuZG9tMTgoKSBhcmUgb25seSB1c2VkDQor ICogYnkgc2VxdWVuY2UgbnVtYmVyIGdlbmVyYXRpb24gc2NoZW1lIDAuDQor ICovDQorI2lmbmRlZiB0Y3BfcmFuZG9tMTgNCisjZGVmaW5lCXRjcF9yYW5k b20xOCgpCShhcmM0cmFuZG9tKCkgJiAweDNmZmZmKQ0KKyNlbmRpZg0KKyNk ZWZpbmUJVENQX0lTU0lOQ1IJKDEyMioxMDI0ICsgdGNwX3JhbmRvbTE4KCkp DQorDQorZXh0ZXJuIHRjcF9zZXEJdGNwX2lzczsNCiAjZWxzZQ0KICNkZWZp bmUJVENQX0lTU0lOQ1IJKDI1MCoxMDI0KQkvKiBpbmNyZW1lbnQgZm9yIHRj cF9pc3MgZWFjaCBzZWNvbmQgKi8NCiAjZW5kaWYgLyogX0tFUk5FTCAqLw0K ZGlmZiAtdSAtciBuZXRpbmV0Lm9sZC90Y3Bfc3Vici5jIG5ldGluZXQvdGNw X3N1YnIuYw0KLS0tIG5ldGluZXQub2xkL3RjcF9zdWJyLmMJU3VuIEp1bCAg MSAyMDo0NDo1MCAyMDAxDQorKysgbmV0aW5ldC90Y3Bfc3Vici5jCVN1biBK dWwgIDEgMjE6MzU6MTQgMjAwMQ0KQEAgLTEzOSw2ICsxMzksMTAgQEANCiBT WVNDVExfSU5UKF9uZXRfaW5ldF90Y3AsIE9JRF9BVVRPLCBpY21wX21heV9y c3QsIENUTEZMQUdfUlcsICZpY21wX21heV9yc3QsIDAsIA0KICAgICAiQ2Vy dGFpbiBJQ01QIHVucmVhY2hhYmxlIG1lc3NhZ2VzIG1heSBhYm9ydCBjb25u ZWN0aW9ucyBpbiBTWU5fU0VOVCIpOw0KIA0KK3N0YXRpYyBpbnQJdGNwX3Nl cV9nZW5zY2hlbWUgPSAxOw0KK1NZU0NUTF9JTlQoX25ldF9pbmV0X3RjcCwg T0lEX0FVVE8sIHRjcF9zZXFfZ2Vuc2NoZW1lLCBDVExGTEFHX1JXLA0KKyAg ICAmdGNwX3NlcV9nZW5zY2hlbWUsIDAsICJUQ1AgSVNOIGdlbmVyYXRpb24g c2NoZW1lIik7DQorDQogc3RhdGljIHZvaWQJdGNwX2NsZWFydGFvY2FjaGUg X19QKCh2b2lkKSk7DQogc3RhdGljIHZvaWQJdGNwX25vdGlmeSBfX1AoKHN0 cnVjdCBpbnBjYiAqLCBpbnQpKTsNCiANCkBAIC0xODIsNiArMTg2LDcgQEAN CiB7DQogCWludCBoYXNoc2l6ZTsNCiAJDQorCXRjcF9pc3MgPSBhcmM0cmFu ZG9tKCk7CS8qIHdyb25nLCBidXQgYmV0dGVyIHRoYW4gYSBjb25zdGFudCAq Lw0KIAl0Y3BfY2NnZW4gPSAxOw0KIAl0Y3BfY2xlYXJ0YW9jYWNoZSgpOw0K IA0KQEAgLTEwODYsNiArMTA5MSwyNiBAQA0KIAkJCSAgICAgIDAsIGNtZCwg bm90aWZ5KTsNCiB9DQogI2VuZGlmIC8qIElORVQ2ICovDQorDQordGNwX3Nl cQ0KK3RjcF9uZXdfaXNuKCkNCit7DQorCWlmICgodGNwX3NlcV9nZW5zY2hl bWUgPiAxKSB8fCAodGNwX3NlcV9nZW5zY2hlbWUgPCAwKSkNCisJCXRjcF9z ZXFfZ2Vuc2NoZW1lID0gMTsNCisNCisJc3dpdGNoICh0Y3Bfc2VxX2dlbnNj aGVtZSkgew0KKwkJY2FzZSAwOgkvKg0KKwkJCSAqIFJhbmRvbSBwb3NpdGl2 ZSBpbmNyZW1lbnRzDQorCQkJICovDQorCQkJdGNwX2lzcyArPSBUQ1BfSVNT SU5DUi8yOw0KKwkJCXJldHVybiB0Y3BfaXNzOw0KKwkJY2FzZSAxOgkvKg0K KwkJCSAqIE9wZW1CU0QgcmFuZG9taXplZCBzY2hlbWUNCisJCQkgKi8NCisJ CQlyZXR1cm4gdGNwX3JuZGlzc19uZXh0KCk7DQorCX0NCisNCit9DQogDQog I2RlZmluZSBUQ1BfUk5ESVNTX1JPVU5EUwkxNg0KICNkZWZpbmUgVENQX1JO RElTU19PVVQJNzIwMA0KZGlmZiAtdSAtciBuZXRpbmV0Lm9sZC90Y3BfdGlt ZXIuYyBuZXRpbmV0L3RjcF90aW1lci5jDQotLS0gbmV0aW5ldC5vbGQvdGNw X3RpbWVyLmMJU3VuIEp1bCAgMSAyMDo0NDo1MCAyMDAxDQorKysgbmV0aW5l dC90Y3BfdGltZXIuYwlTdW4gSnVsICAxIDIxOjEyOjE2IDIwMDENCkBAIC0x MzIsNiArMTMyLDggQEANCiANCiAJdGNwX21heGlkbGUgPSB0Y3Bfa2VlcGNu dCAqIHRjcF9rZWVwaW50dmw7DQogDQorCXRjcF9pc3MgKz0gVENQX0lTU0lO Q1IvUFJfU0xPV0haOw0KKw0KIAlzcGx4KHMpOw0KIH0NCiANCmRpZmYgLXUg LXIgbmV0aW5ldC5vbGQvdGNwX3VzcnJlcS5jIG5ldGluZXQvdGNwX3VzcnJl cS5jDQotLS0gbmV0aW5ldC5vbGQvdGNwX3VzcnJlcS5jCVN1biBKdWwgIDEg MjA6NDQ6NTAgMjAwMQ0KKysrIG5ldGluZXQvdGNwX3VzcnJlcS5jCVN1biBK dWwgIDEgMjE6MTg6MjAgMjAwMQ0KQEAgLTc1OSw3ICs3NTksNyBAQA0KIAl0 Y3BzdGF0LnRjcHNfY29ubmF0dGVtcHQrKzsNCiAJdHAtPnRfc3RhdGUgPSBU Q1BTX1NZTl9TRU5UOw0KIAljYWxsb3V0X3Jlc2V0KHRwLT50dF9rZWVwLCB0 Y3Bfa2VlcGluaXQsIHRjcF90aW1lcl9rZWVwLCB0cCk7DQotCXRwLT5pc3Mg PSB0Y3Bfcm5kaXNzX25leHQoKTsNCisJdHAtPmlzcyA9IHRjcF9uZXdfaXNu KCk7DQogCXRjcF9zZW5kc2VxaW5pdCh0cCk7DQogDQogCS8qDQpAQCAtODUx LDcgKzg1MSw3IEBADQogCXRjcHN0YXQudGNwc19jb25uYXR0ZW1wdCsrOw0K IAl0cC0+dF9zdGF0ZSA9IFRDUFNfU1lOX1NFTlQ7DQogCWNhbGxvdXRfcmVz ZXQodHAtPnR0X2tlZXAsIHRjcF9rZWVwaW5pdCwgdGNwX3RpbWVyX2tlZXAs IHRwKTsNCi0JdHAtPmlzcyA9IHRjcF9ybmRpc3NfbmV4dCgpOw0KKwl0cC0+ aXNzID0gdGNwX25ld19pc24oKTsNCiAJdGNwX3NlbmRzZXFpbml0KHRwKTsN CiANCiAJLyoNCmRpZmYgLXUgLXIgbmV0aW5ldC5vbGQvdGNwX3Zhci5oIG5l dGluZXQvdGNwX3Zhci5oDQotLS0gbmV0aW5ldC5vbGQvdGNwX3Zhci5oCVN1 biBKdWwgIDEgMjA6NDQ6NTAgMjAwMQ0KKysrIG5ldGluZXQvdGNwX3Zhci5o CVN1biBKdWwgIDEgMjE6MTM6MjUgMjAwMQ0KQEAgLTQxMyw2ICs0MTMsNyBA QA0KIHRjcF9zZXEJdGNwX3JuZGlzc19uZXh0IF9fUCgodm9pZCkpOw0KIHVf aW50MTZfdA0KIAl0Y3Bfcm5kaXNzX2VuY3J5cHQgX19QKCh1X2ludDE2X3Qp KTsNCit0Y3Bfc2VxIHRjcF9uZXdfaXNuIF9fUCgodm9pZCkpOw0KIA0KICNl bmRpZiAvKiBfS0VSTkVMICovDQogDQo= --0-1989767161-994041947=:1087-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 1 23:27:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 592EA37B401 for ; Sun, 1 Jul 2001 23:27:37 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id PAA12935; Mon, 2 Jul 2001 15:28:47 +0900 (JST) Date: Mon, 02 Jul 2001 15:27:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Kevin Oberman" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Odd IPv6 behavior when not connected to IPv6 net In-Reply-To: <200106291628.f5TGSsc13240@ptavv.es.net> References: <200106291628.f5TGSsc13240@ptavv.es.net> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 41 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Fri, 29 Jun 2001 09:28:54 -0700, >>>>> "Kevin Oberman" said: >> That is, if we do not have any default router (hear from RA), we >> should regard all IPv6 prefixes as on-link. To implement this trick, >> we use the "default interface", and install the default route as an >> interface direct route to the interface. > I think the basic idea in the RFC may be reasonable. It only breaks > when the link selected is loopback. Had the stack tried to connect to > a physical link, this would have worked as intended, but loopback will > always be the wrong answer if it is the link used. Just to make it sure, even if you specify a non-loopback interface as the default, you should still (usually) see a long delay before the connection attempt by IPv6 fails, because this type of error is not a hard error for TCP (like "no route to host"). The delay would be about 1 minute. I don't think most users do not tolerate the delay, especially when the IPv4 connection can be established. >> Thus, for the moment, I agree that we should turn the default >> interface off by default. For a longer term solution, we might have >> to consider a better source address selection algorithm, >> e.g. described in draft-ietf-ipngwg-default-addr-select-04.txt. Then >> IPv4 would be preferred in this case. > This is certainly reasonable, too. But the step of not allowing the lo > interface to qualify as the link for the default route seems like > something that should be done as well. > Of course, there may be some reason to want default to point at lo, > but I can't think of a good one. I don't have any objection to changing the default interface to a non-loopback one, *if the default is ever defined*. I'm arguing that it would be safe *not to specify the default interface by default*. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 1 23:33:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 43CC737B405 for ; Sun, 1 Jul 2001 23:33:08 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id PAA12968 for ; Mon, 2 Jul 2001 15:34:28 +0900 (JST) Date: Mon, 02 Jul 2001 15:33:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: freebsd-net@FreeBSD.ORG Subject: Re: Odd IPv6 behavior when not connected to IPv6 net In-Reply-To: References: <200106291628.f5TGSsc13240@ptavv.es.net> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 29 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Mon, 02 Jul 2001 15:27:26 +0900, >>>>> JINMEI Tatuya said: >>>>> On Fri, 29 Jun 2001 09:28:54 -0700, >>>>> "Kevin Oberman" said: >>> That is, if we do not have any default router (hear from RA), we >>> should regard all IPv6 prefixes as on-link. To implement this trick, >>> we use the "default interface", and install the default route as an >>> interface direct route to the interface. >> I think the basic idea in the RFC may be reasonable. It only breaks >> when the link selected is loopback. Had the stack tried to connect to >> a physical link, this would have worked as intended, but loopback will >> always be the wrong answer if it is the link used. > Just to make it sure, even if you specify a non-loopback interface as > the default, you should still (usually) see a long delay before the > connection attempt by IPv6 fails, because this type of error is not a > hard error for TCP (like "no route to host"). The delay would be > about 1 minute. I don't think most users do not tolerate the delay, ^^^^^^should be removed. sorry for the bad wording. > especially when the IPv4 connection can be established. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 1:37:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from star.rila.bg (star.rila.bg [212.39.75.32]) by hub.freebsd.org (Postfix) with ESMTP id 5FA1037B403 for ; Mon, 2 Jul 2001 01:37:26 -0700 (PDT) (envelope-from vlady@star.rila.bg) Received: from star.rila.bg (vlady@localhost [127.0.0.1]) by star.rila.bg (8.9.3/8.9.3) with ESMTP id LAA37120 for ; Mon, 2 Jul 2001 11:37:16 +0300 (EEST) (envelope-from vlady@star.rila.bg) Message-Id: <200107020837.LAA37120@star.rila.bg> X-Mailer: exmh version 2.4 05/15/2001 with nmh-1.0.3 To: freebsd-net@freebsd.org From: "Vladimir Terziev" Subject: Cisco Aironet 340 Series Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Jul 2001 11:37:16 +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, I'm planning to setup a Intranet network, based on wireless connections. I think to use Cisco Aironet 340 Series cards for client access. Is FreeBSD supports Cisco Aironet 340 Series cards ? regards, Vladimir To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 1:52: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id ED28C37B409 for ; Mon, 2 Jul 2001 01:51:49 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f628pTb68472; Mon, 2 Jul 2001 11:51:29 +0300 (EEST) (envelope-from ru) Date: Mon, 2 Jul 2001 11:51:29 +0300 From: Ruslan Ermilov To: Wes Peters Cc: net@FreeBSD.ORG Subject: Indirect route with also indirect gateway (was: Re: fastforwarding?) Message-ID: <20010702115129.A67459@sunbay.com> Mail-Followup-To: Wes Peters , net@FreeBSD.ORG References: <20010626093545.D49992@sunbay.com> <3B3AB4F8.184A2EFE@softweyr.com> <20010629112757.F91115@sunbay.com> <3B3F930C.320CC3DC@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B3F930C.320CC3DC@softweyr.com>; from wes@softweyr.com on Sun, Jul 01, 2001 at 03:15:56PM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Jul 01, 2001 at 03:15:56PM -0600, Wes Peters wrote: > Ruslan Ermilov wrote: > > > > BTW, Wes, I'm still waiting for a working example of an indirect route > > with also indirect gateway. > > Any indirect route via the opposite end of a point-to-point connection. > Right? > You probably meant that the gateway is accessible via the opposite end. But the gateway value on a P2P link is a no-op. Whatever gateway you specify, the actual gateway is always the "opposite end". Here, the gateway only helps the routing code to select the right interface. I.e., on a 1.1.1.1 -> 2.2.2.2 configured tun0 interface, the following two commands are equivalent: route add -net 10 2.2.2.2 route add -net 10 -iface tun0 Funny though that you're giving this example, as it only works starting with revision 1.62 (from June 4, 2001) of sys/net/route.c. Before this, routing code incorrectly set up the interface based on destination, not the gateway: # ifconfig tun0 tun0: flags=8051 mtu 1500 inet 1.1.1.1 --> 2.2.2.2 netmask 0xff000000 # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.4.65 UGSc 1 0 rl0 2.2.2.2 1.1.1.1 UH 0 0 tun0 3.3.3.3 tun0 UHS 1 0 tun0 127.0.0.1 127.0.0.1 UH 1 6 lo0 192.168.4 link#1 UC 3 0 rl0 => 192.168.4.65 0:d0:b7:16:9c:c6 UHLW 2 1576 rl0 899 192.168.4.115 0:c0:df:3:2d:79 UHLW 2 2 lo0 # route add -net 10 3.3.3.3 add net 10: gateway 3.3.3.3 # netstat -rn | grep 3.3.3.3 3.3.3.3 tun0 UHS 1 0 tun0 10 3.3.3.3 UGSc 0 0 rl0 ^^^^ oops I still think we should disallow such routes on non-P2P interfaces, at least. What do you think? Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 2:50: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from shadow.otel.net (JuDiCaToR.OTEL.net [212.36.9.113]) by hub.freebsd.org (Postfix) with ESMTP id 7AA4237B407; Mon, 2 Jul 2001 02:49:50 -0700 (PDT) (envelope-from tbyte@tbyte.org) Received: from localhost (localhost [127.0.0.1]) by shadow.otel.net (8.11.4/8.11.1) with ESMTP id f629niK08434; Mon, 2 Jul 2001 12:49:46 +0300 (EEST) (envelope-from tbyte@tbyte.org) Date: Mon, 2 Jul 2001 12:49:44 +0300 (EEST) From: Iasen Kostoff X-Sender: tbyte@shadow.otel.net To: Ruslan Ermilov Cc: Wes Peters , net@FreeBSD.ORG Subject: Re: Indirect route with also indirect gateway (was: Re: fastforwarding?) In-Reply-To: <20010702115129.A67459@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 2 Jul 2001, Ruslan Ermilov wrote: > On Sun, Jul 01, 2001 at 03:15:56PM -0600, Wes Peters wrote: > > Ruslan Ermilov wrote: > > > > > > BTW, Wes, I'm still waiting for a working example of an indirect route > > > with also indirect gateway. > > > > Any indirect route via the opposite end of a point-to-point connection. > > Right? > > > You probably meant that the gateway is accessible via the opposite end. > > But the gateway value on a P2P link is a no-op. Whatever gateway you > specify, the actual gateway is always the "opposite end". Here, the > gateway only helps the routing code to select the right interface. > I.e., on a 1.1.1.1 -> 2.2.2.2 configured tun0 interface, the following > two commands are equivalent: > > route add -net 10 2.2.2.2 > route add -net 10 -iface tun0 > > Funny though that you're giving this example, as it only works starting > with revision 1.62 (from June 4, 2001) of sys/net/route.c. Before this, > routing code incorrectly set up the interface based on destination, not > the gateway: > > # ifconfig tun0 > tun0: flags=8051 mtu 1500 > inet 1.1.1.1 --> 2.2.2.2 netmask 0xff000000 > > # netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 192.168.4.65 UGSc 1 0 rl0 > 2.2.2.2 1.1.1.1 UH 0 0 tun0 > 3.3.3.3 tun0 UHS 1 0 tun0 > 127.0.0.1 127.0.0.1 UH 1 6 lo0 > 192.168.4 link#1 UC 3 0 rl0 => > 192.168.4.65 0:d0:b7:16:9c:c6 UHLW 2 1576 rl0 899 > 192.168.4.115 0:c0:df:3:2d:79 UHLW 2 2 lo0 > > # route add -net 10 3.3.3.3 > add net 10: gateway 3.3.3.3 > > # netstat -rn | grep 3.3.3.3 > 3.3.3.3 tun0 UHS 1 0 tun0 > 10 3.3.3.3 UGSc 0 0 rl0 > ^^^^ oops > > I still think we should disallow such routes on non-P2P interfaces, at > least. What do you think? > > > > Cheers, > -- > Ruslan Ermilov Oracle Developer/DBA, > ru@sunbay.com Sunbay Software AG, > ru@FreeBSD.org FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve > http://www.oracle.com Enabling The Information Age > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > If you speek about disallowing routes like : route add -net 10 3.3.3.3 I don't think we should. I'm using such routes now (ethernet bridges for leased lines) and don't want to loose this functionality. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 5:27: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 654AB37B401 for ; Mon, 2 Jul 2001 05:26:52 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f62CQVe96273; Mon, 2 Jul 2001 15:26:31 +0300 (EEST) (envelope-from ru) Date: Mon, 2 Jul 2001 15:26:31 +0300 From: Ruslan Ermilov To: Iasen Kostoff Cc: net@FreeBSD.org Subject: Re: Indirect route with also indirect gateway Message-ID: <20010702152631.C77685@sunbay.com> Mail-Followup-To: Iasen Kostoff , net@FreeBSD.org References: <20010702130910.A77685@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tbyte@tbyte.org on Mon, Jul 02, 2001 at 01:16:19PM +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jul 02, 2001 at 01:16:19PM +0300, Iasen Kostoff wrote: > > > On Mon, 2 Jul 2001, Ruslan Ermilov wrote: > > > On Mon, Jul 02, 2001 at 12:49:44PM +0300, Iasen Kostoff wrote: > > > > > > > > > On Mon, 2 Jul 2001, Ruslan Ermilov wrote: > > > > > > > On Sun, Jul 01, 2001 at 03:15:56PM -0600, Wes Peters wrote: > > > > > Ruslan Ermilov wrote: > > > > > > > > > > > > BTW, Wes, I'm still waiting for a working example of an indirect route > > > > > > with also indirect gateway. > > > > > > > > > > Any indirect route via the opposite end of a point-to-point connection. > > > > > Right? > > > > > > > > > You probably meant that the gateway is accessible via the opposite end. > > > > > > > > But the gateway value on a P2P link is a no-op. Whatever gateway you > > > > specify, the actual gateway is always the "opposite end". Here, the > > > > gateway only helps the routing code to select the right interface. > > > > I.e., on a 1.1.1.1 -> 2.2.2.2 configured tun0 interface, the following > > > > two commands are equivalent: > > > > > > > > route add -net 10 2.2.2.2 > > > > route add -net 10 -iface tun0 > > > > > > > > Funny though that you're giving this example, as it only works starting > > > > with revision 1.62 (from June 4, 2001) of sys/net/route.c. Before this, > > > > routing code incorrectly set up the interface based on destination, not > > > > the gateway: > > > > > > > > # ifconfig tun0 > > > > tun0: flags=8051 mtu 1500 > > > > inet 1.1.1.1 --> 2.2.2.2 netmask 0xff000000 > > > > > > > > # netstat -rn > > > > Routing tables > > > > > > > > Internet: > > > > Destination Gateway Flags Refs Use Netif Expire > > > > default 192.168.4.65 UGSc 1 0 rl0 > > > > 2.2.2.2 1.1.1.1 UH 0 0 tun0 > > > > 3.3.3.3 tun0 UHS 1 0 tun0 > > > > 127.0.0.1 127.0.0.1 UH 1 6 lo0 > > > > 192.168.4 link#1 UC 3 0 rl0 => > > > > 192.168.4.65 0:d0:b7:16:9c:c6 UHLW 2 1576 rl0 899 > > > > 192.168.4.115 0:c0:df:3:2d:79 UHLW 2 2 lo0 > > > > > > > > # route add -net 10 3.3.3.3 > > > > add net 10: gateway 3.3.3.3 > > > > > > > > # netstat -rn | grep 3.3.3.3 > > > > 3.3.3.3 tun0 UHS 1 0 tun0 > > > > 10 3.3.3.3 UGSc 0 0 rl0 > > > > ^^^^ oops > > > > > > > > I still think we should disallow such routes on non-P2P interfaces, at > > > > least. What do you think? > > > > > > > If you speek about disallowing routes like : route add -net 10 3.3.3.3 > > > I don't think we should. I'm using such routes now (ethernet bridges for > > > leased lines) and don't want to loose this functionality. > > > > > Could you please describe your setup in more details? > > > > I would like to disallow such routes for broadcast-like interfaces like > > Ethernet, because on these interfaces, adding such a route results in: > > > > arplookup 3.3.3.3 failed: host is not on local network > > arpresolve: can't allocate llinfo for 3.3.3.3rt > > > > It is a MUST here that the gateway should be directly connected > > (via ARP). > > > If you have this route : > 3.3.3.3 link#1 UC 1 0 rl0 => > > it won't result in this error message. > Having this host entry with the RTF_CLONING flag set, as you have shown it, is impossible. It could only have been "cloned" from a network-type routing table entry, as shown in the commit log for revision 1.50 of route/route.c, and this case shouldn't be affected by that change. Or like this: 3.3.3/24 link#1 UCSc 1 0 rl0 3.3.3.3 link#1 UHLW 1 1 rl0 10 3.3.3.3 UGSc 0 11 rl0 But then again, this means that the gateway (3.3.3.3) is directly reachable (think one hop) on one of the attached networks (rl0), but the ARP reply haven't been (yet) received, due to the host being down, as indicated by ping(8): # ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host ^C --- 10.0.0.1 ping statistics --- 6 packets transmitted, 0 packets received, 100% packet loss 3.3.3.3 link#1 UHRLW 1 0 rl0 (Note that `R' (RTF_REJECT) flag is set by arpresolve() after net.link.ether.inet.maxtries unsuccessful ARP request tries.) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 6:34:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from shadow.otel.net (JuDiCaToR.OTEL.net [212.36.9.113]) by hub.freebsd.org (Postfix) with ESMTP id A35D537B401; Mon, 2 Jul 2001 06:34:44 -0700 (PDT) (envelope-from tbyte@tbyte.org) Received: from localhost (localhost [127.0.0.1]) by shadow.otel.net (8.11.4/8.11.1) with ESMTP id f62DYeK33584; Mon, 2 Jul 2001 16:34:43 +0300 (EEST) (envelope-from tbyte@tbyte.org) Date: Mon, 2 Jul 2001 16:34:40 +0300 (EEST) From: Iasen Kostoff X-Sender: tbyte@shadow.otel.net To: Ruslan Ermilov Cc: net@FreeBSD.ORG Subject: Re: Indirect route with also indirect gateway In-Reply-To: <20010702152631.C77685@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 2 Jul 2001, Ruslan Ermilov wrote: > On Mon, Jul 02, 2001 at 01:16:19PM +0300, Iasen Kostoff wrote: > > > > > > On Mon, 2 Jul 2001, Ruslan Ermilov wrote: > > > > > On Mon, Jul 02, 2001 at 12:49:44PM +0300, Iasen Kostoff wrote: > > > > > > > > > > > > On Mon, 2 Jul 2001, Ruslan Ermilov wrote: > > > > > > > > > On Sun, Jul 01, 2001 at 03:15:56PM -0600, Wes Peters wrote: > > > > > > Ruslan Ermilov wrote: > > > > > > > > > > > > > > BTW, Wes, I'm still waiting for a working example of an indirect route > > > > > > > with also indirect gateway. > > > > > > > > > > > > Any indirect route via the opposite end of a point-to-point connection. > > > > > > Right? > > > > > > > > > > > You probably meant that the gateway is accessible via the opposite end. > > > > > > > > > > But the gateway value on a P2P link is a no-op. Whatever gateway you > > > > > specify, the actual gateway is always the "opposite end". Here, the > > > > > gateway only helps the routing code to select the right interface. > > > > > I.e., on a 1.1.1.1 -> 2.2.2.2 configured tun0 interface, the following > > > > > two commands are equivalent: > > > > > > > > > > route add -net 10 2.2.2.2 > > > > > route add -net 10 -iface tun0 > > > > > > > > > > Funny though that you're giving this example, as it only works starting > > > > > with revision 1.62 (from June 4, 2001) of sys/net/route.c. Before this, > > > > > routing code incorrectly set up the interface based on destination, not > > > > > the gateway: > > > > > > > > > > # ifconfig tun0 > > > > > tun0: flags=8051 mtu 1500 > > > > > inet 1.1.1.1 --> 2.2.2.2 netmask 0xff000000 > > > > > > > > > > # netstat -rn > > > > > Routing tables > > > > > > > > > > Internet: > > > > > Destination Gateway Flags Refs Use Netif Expire > > > > > default 192.168.4.65 UGSc 1 0 rl0 > > > > > 2.2.2.2 1.1.1.1 UH 0 0 tun0 > > > > > 3.3.3.3 tun0 UHS 1 0 tun0 > > > > > 127.0.0.1 127.0.0.1 UH 1 6 lo0 > > > > > 192.168.4 link#1 UC 3 0 rl0 => > > > > > 192.168.4.65 0:d0:b7:16:9c:c6 UHLW 2 1576 rl0 899 > > > > > 192.168.4.115 0:c0:df:3:2d:79 UHLW 2 2 lo0 > > > > > > > > > > # route add -net 10 3.3.3.3 > > > > > add net 10: gateway 3.3.3.3 > > > > > > > > > > # netstat -rn | grep 3.3.3.3 > > > > > 3.3.3.3 tun0 UHS 1 0 tun0 > > > > > 10 3.3.3.3 UGSc 0 0 rl0 > > > > > ^^^^ oops > > > > > > > > > > I still think we should disallow such routes on non-P2P interfaces, at > > > > > least. What do you think? > > > > > > > > > If you speek about disallowing routes like : route add -net 10 3.3.3.3 > > > > I don't think we should. I'm using such routes now (ethernet bridges for > > > > leased lines) and don't want to loose this functionality. > > > > > > > Could you please describe your setup in more details? > > > > > > I would like to disallow such routes for broadcast-like interfaces like > > > Ethernet, because on these interfaces, adding such a route results in: > > > > > > arplookup 3.3.3.3 failed: host is not on local network > > > arpresolve: can't allocate llinfo for 3.3.3.3rt > > > > > > It is a MUST here that the gateway should be directly connected > > > (via ARP). > > > > > If you have this route : > > 3.3.3.3 link#1 UC 1 0 rl0 => > > > > it won't result in this error message. > > > Having this host entry with the RTF_CLONING flag set, as you have shown > it, is impossible. It could only have been "cloned" from a network-type > routing table entry, as shown in the commit log for revision 1.50 of > route/route.c, and this case shouldn't be affected by that change. > Or like this: > > 3.3.3/24 link#1 UCSc 1 0 rl0 > 3.3.3.3 link#1 UHLW 1 1 rl0 > 10 3.3.3.3 UGSc 0 11 rl0 > > But then again, this means that the gateway (3.3.3.3) is directly reachable > (think one hop) on one of the attached networks (rl0), but the ARP reply > haven't been (yet) received, due to the host being down, as indicated by > ping(8): > > # ping 10.0.0.1 > PING 10.0.0.1 (10.0.0.1): 56 data bytes > ping: sendto: No route to host > ping: sendto: No route to host > ^C > --- 10.0.0.1 ping statistics --- > 6 packets transmitted, 0 packets received, 100% packet loss > > 3.3.3.3 link#1 UHRLW 1 0 rl0 > > (Note that `R' (RTF_REJECT) flag is set by arpresolve() after > net.link.ether.inet.maxtries unsuccessful ARP request tries.) > > That is my interface config: xl0: flags=8843 mtu 1500 inet 212.36.9.113 netmask 0xffffff00 broadcast 212.36.9.255 ether 00:04:76:22:15:83 media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UT P 10baseT/UTP 100baseTX xl1: flags=8843 mtu 1500 inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 ether 00:10:5a:21:73:55 media: autoselect (100baseTX) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UT P 10baseT/UTP 100baseTX xl2: flags=8843 mtu 1500 inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 ether 00:10:4b:b8:65:2c media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UT P 10baseT/UTP 100baseTX ed0: flags=8843 mtu 1500 inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 ether 00:40:05:60:f8:d8 and the static routes: #:> netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 212.36.8.129 UGSc 16 1612418 xl0 127.0.0.1 127.0.0.1 UH 4 14226 lo0 212.36.8 link#1 UCSc 28 0 xl0 => 212.36.9 link#1 UC 4 0 xl0 => 212.36.9.113 0:10:5a:21:73:55 UHLW 0 123 lo0 => 212.36.9.113/32 link#2 UC 1 0 xl1 => 212.36.9.114 0:0:b4:59:dc:91 UHLS 2 1257089 ed0 212.36.9.115 0:0:b4:59:dc:91 UHLS 0 21764 ed0 212.36.9.119 0:80:ad:7c:2c:8c UHLS 0 616255 xl1 212.36.9.126/31 212.36.9.124 UGSc 0 40 xl0 212.36.9.128/31 212.36.9.124 UGSc 0 0 xl0 212.36.9.130/31 link#3 UCSc 1 0 xl2 => You see that I don't have iface from 212.36.8 network but just a route to it (that is an example I know taht I can set netmask /23 but if other net is 193.xxx.xxx or something ?) and default gw is from that (212.36.8) net (which ofcourse is directly reachable)(ofcourse there was a problem setting that route before I write a patch which you commit (kern/27852)) And there is a problem whith setting route : route add -host foo -iface bar It set the GW to this host foo to be iface bar but not to route packet throw this iface to host foo.If you want to set this route you should set the lladdr of host foo in arp table by hand (in cisco routers you should'n do it that way , there it's straight forward routine) The right way (cisco's way) setting a route throw gw that is not local(mean from it's subnet) to any iface but is direcly reachable should be : route add -host foo_gw -iface bar route add -net foo_net foo-gw To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 6:58:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id B9C0837B401 for ; Mon, 2 Jul 2001 06:58:41 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f62DwIh07628; Mon, 2 Jul 2001 16:58:18 +0300 (EEST) (envelope-from ru) Date: Mon, 2 Jul 2001 16:58:18 +0300 From: Ruslan Ermilov To: Iasen Kostoff Cc: net@FreeBSD.ORG Subject: Re: Indirect route with also indirect gateway Message-ID: <20010702165817.B96697@sunbay.com> Mail-Followup-To: Iasen Kostoff , net@FreeBSD.ORG References: <20010702152631.C77685@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tbyte@tbyte.org on Mon, Jul 02, 2001 at 04:34:40PM +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jul 02, 2001 at 04:34:40PM +0300, Iasen Kostoff wrote: > > > On Mon, 2 Jul 2001, Ruslan Ermilov wrote: > > > On Mon, Jul 02, 2001 at 01:16:19PM +0300, Iasen Kostoff wrote: > > > > > > > > > On Mon, 2 Jul 2001, Ruslan Ermilov wrote: > > > > > > > On Mon, Jul 02, 2001 at 12:49:44PM +0300, Iasen Kostoff wrote: > > > > > > > > > > > > > > > On Mon, 2 Jul 2001, Ruslan Ermilov wrote: > > > > > > > > > > > On Sun, Jul 01, 2001 at 03:15:56PM -0600, Wes Peters wrote: > > > > > > > Ruslan Ermilov wrote: > > > > > > > > > > > > > > > > BTW, Wes, I'm still waiting for a working example of an indirect route > > > > > > > > with also indirect gateway. > > > > > > > > > > > > > > Any indirect route via the opposite end of a point-to-point connection. > > > > > > > Right? > > > > > > > > > > > > > You probably meant that the gateway is accessible via the opposite end. > > > > > > > > > > > > But the gateway value on a P2P link is a no-op. Whatever gateway you > > > > > > specify, the actual gateway is always the "opposite end". Here, the > > > > > > gateway only helps the routing code to select the right interface. > > > > > > I.e., on a 1.1.1.1 -> 2.2.2.2 configured tun0 interface, the following > > > > > > two commands are equivalent: > > > > > > > > > > > > route add -net 10 2.2.2.2 > > > > > > route add -net 10 -iface tun0 > > > > > > > > > > > > Funny though that you're giving this example, as it only works starting > > > > > > with revision 1.62 (from June 4, 2001) of sys/net/route.c. Before this, > > > > > > routing code incorrectly set up the interface based on destination, not > > > > > > the gateway: > > > > > > > > > > > > # ifconfig tun0 > > > > > > tun0: flags=8051 mtu 1500 > > > > > > inet 1.1.1.1 --> 2.2.2.2 netmask 0xff000000 > > > > > > > > > > > > # netstat -rn > > > > > > Routing tables > > > > > > > > > > > > Internet: > > > > > > Destination Gateway Flags Refs Use Netif Expire > > > > > > default 192.168.4.65 UGSc 1 0 rl0 > > > > > > 2.2.2.2 1.1.1.1 UH 0 0 tun0 > > > > > > 3.3.3.3 tun0 UHS 1 0 tun0 > > > > > > 127.0.0.1 127.0.0.1 UH 1 6 lo0 > > > > > > 192.168.4 link#1 UC 3 0 rl0 => > > > > > > 192.168.4.65 0:d0:b7:16:9c:c6 UHLW 2 1576 rl0 899 > > > > > > 192.168.4.115 0:c0:df:3:2d:79 UHLW 2 2 lo0 > > > > > > > > > > > > # route add -net 10 3.3.3.3 > > > > > > add net 10: gateway 3.3.3.3 > > > > > > > > > > > > # netstat -rn | grep 3.3.3.3 > > > > > > 3.3.3.3 tun0 UHS 1 0 tun0 > > > > > > 10 3.3.3.3 UGSc 0 0 rl0 > > > > > > ^^^^ oops > > > > > > > > > > > > I still think we should disallow such routes on non-P2P interfaces, at > > > > > > least. What do you think? > > > > > > > > > > > If you speek about disallowing routes like : route add -net 10 3.3.3.3 > > > > > I don't think we should. I'm using such routes now (ethernet bridges for > > > > > leased lines) and don't want to loose this functionality. > > > > > > > > > Could you please describe your setup in more details? > > > > > > > > I would like to disallow such routes for broadcast-like interfaces like > > > > Ethernet, because on these interfaces, adding such a route results in: > > > > > > > > arplookup 3.3.3.3 failed: host is not on local network > > > > arpresolve: can't allocate llinfo for 3.3.3.3rt > > > > > > > > It is a MUST here that the gateway should be directly connected > > > > (via ARP). > > > > > > > If you have this route : > > > 3.3.3.3 link#1 UC 1 0 rl0 => > > > > > > it won't result in this error message. > > > > > Having this host entry with the RTF_CLONING flag set, as you have shown > > it, is impossible. It could only have been "cloned" from a network-type > > routing table entry, as shown in the commit log for revision 1.50 of > > route/route.c, and this case shouldn't be affected by that change. > > Or like this: > > > > 3.3.3/24 link#1 UCSc 1 0 rl0 > > 3.3.3.3 link#1 UHLW 1 1 rl0 > > 10 3.3.3.3 UGSc 0 11 rl0 > > > > But then again, this means that the gateway (3.3.3.3) is directly reachable > > (think one hop) on one of the attached networks (rl0), but the ARP reply > > haven't been (yet) received, due to the host being down, as indicated by > > ping(8): > > > > # ping 10.0.0.1 > > PING 10.0.0.1 (10.0.0.1): 56 data bytes > > ping: sendto: No route to host > > ping: sendto: No route to host > > ^C > > --- 10.0.0.1 ping statistics --- > > 6 packets transmitted, 0 packets received, 100% packet loss > > > > 3.3.3.3 link#1 UHRLW 1 0 rl0 > > > > (Note that `R' (RTF_REJECT) flag is set by arpresolve() after > > net.link.ether.inet.maxtries unsuccessful ARP request tries.) > > > > > That is my interface config: > > xl0: flags=8843 mtu 1500 > inet 212.36.9.113 netmask 0xffffff00 broadcast 212.36.9.255 > ether 00:04:76:22:15:83 > media: autoselect (100baseTX ) status: active > supported media: autoselect 100baseTX 100baseTX > 10baseT/UT > P 10baseT/UTP 100baseTX > xl1: flags=8843 mtu 1500 > inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 > ether 00:10:5a:21:73:55 > media: autoselect (100baseTX) status: active > supported media: autoselect 100baseTX 100baseTX > 10baseT/UT > P 10baseT/UTP 100baseTX > xl2: flags=8843 mtu 1500 > inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 > ether 00:10:4b:b8:65:2c > media: autoselect (10baseT/UTP) status: active > supported media: autoselect 100baseTX 100baseTX > 10baseT/UT > P 10baseT/UTP 100baseTX > ed0: flags=8843 mtu 1500 > inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 > ether 00:40:05:60:f8:d8 > > > and the static routes: > [...] > default 212.36.8.129 UGSc 16 1612418 xl0 > 212.36.8 link#1 UCSc 28 0 xl0 => > This case indeed should be allowed. Your ``default'' route isn't with "indirect gateway", because the gateway route (route to 212.36.8.129) doesn't have the `G' flag set. An example of "indirect route with also indirect gateway" would be: # route -n get -net 10 route to: 10.0.0.0 destination: 10.0.0.0 mask: 255.0.0.0 gateway: 1.2.3.4 interface: rl0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 # route -n get 1.2.3.4 route to: 1.2.3.4 destination: default mask: default gateway: 192.168.4.65 interface: rl0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 Or, in netstat(1) equivalent: default 192.168.4.65 UGSc 4 0 rl0 10 1.2.3.4 UGSc 0 0 rl0 192.168.4.65 0:d0:b7:16:9c:c6 UHLW 3 4055 rl0 1108 I.e., the gateway for net 10 is 1.2.3.4, where 1.2.3.4 is *indirectly* reachable via the `default' route with gateway 192.168.4.65. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 7:27:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from shadow.otel.net (JuDiCaToR.OTEL.net [212.36.9.113]) by hub.freebsd.org (Postfix) with ESMTP id F184837B408; Mon, 2 Jul 2001 07:27:29 -0700 (PDT) (envelope-from tbyte@tbyte.org) Received: from localhost (localhost [127.0.0.1]) by shadow.otel.net (8.11.4/8.11.1) with ESMTP id f62ERSK33667; Mon, 2 Jul 2001 17:27:28 +0300 (EEST) (envelope-from tbyte@tbyte.org) Date: Mon, 2 Jul 2001 17:27:28 +0300 (EEST) From: Iasen Kostoff X-Sender: tbyte@shadow.otel.net To: Ruslan Ermilov Cc: net@FreeBSD.ORG Subject: Re: Indirect route with also indirect gateway In-Reply-To: <20010702165817.B96697@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 2 Jul 2001, Ruslan Ermilov wrote: > On Mon, Jul 02, 2001 at 04:34:40PM +0300, Iasen Kostoff wrote: > > > > > > On Mon, 2 Jul 2001, Ruslan Ermilov wrote: > > > > > On Mon, Jul 02, 2001 at 01:16:19PM +0300, Iasen Kostoff wrote: > > > > > > > > > > > > On Mon, 2 Jul 2001, Ruslan Ermilov wrote: > > > > > > > > > On Mon, Jul 02, 2001 at 12:49:44PM +0300, Iasen Kostoff wrote: > > > > > > > > > > > > > > > > > > On Mon, 2 Jul 2001, Ruslan Ermilov wrote: > > > > > > > > > > > > > On Sun, Jul 01, 2001 at 03:15:56PM -0600, Wes Peters wrote: > > > > > > > > Ruslan Ermilov wrote: > > > > > > > > > > > > > > > > > > BTW, Wes, I'm still waiting for a working example of an indirect route > > > > > > > > > with also indirect gateway. > > > > > > > > > > > > > > > > Any indirect route via the opposite end of a point-to-point connection. > > > > > > > > Right? > > > > > > > > > > > > > > > You probably meant that the gateway is accessible via the opposite end. > > > > > > > > > > > > > > But the gateway value on a P2P link is a no-op. Whatever gateway you > > > > > > > specify, the actual gateway is always the "opposite end". Here, the > > > > > > > gateway only helps the routing code to select the right interface. > > > > > > > I.e., on a 1.1.1.1 -> 2.2.2.2 configured tun0 interface, the following > > > > > > > two commands are equivalent: > > > > > > > > > > > > > > route add -net 10 2.2.2.2 > > > > > > > route add -net 10 -iface tun0 > > > > > > > > > > > > > > Funny though that you're giving this example, as it only works starting > > > > > > > with revision 1.62 (from June 4, 2001) of sys/net/route.c. Before this, > > > > > > > routing code incorrectly set up the interface based on destination, not > > > > > > > the gateway: > > > > > > > > > > > > > > # ifconfig tun0 > > > > > > > tun0: flags=8051 mtu 1500 > > > > > > > inet 1.1.1.1 --> 2.2.2.2 netmask 0xff000000 > > > > > > > > > > > > > > # netstat -rn > > > > > > > Routing tables > > > > > > > > > > > > > > Internet: > > > > > > > Destination Gateway Flags Refs Use Netif Expire > > > > > > > default 192.168.4.65 UGSc 1 0 rl0 > > > > > > > 2.2.2.2 1.1.1.1 UH 0 0 tun0 > > > > > > > 3.3.3.3 tun0 UHS 1 0 tun0 > > > > > > > 127.0.0.1 127.0.0.1 UH 1 6 lo0 > > > > > > > 192.168.4 link#1 UC 3 0 rl0 => > > > > > > > 192.168.4.65 0:d0:b7:16:9c:c6 UHLW 2 1576 rl0 899 > > > > > > > 192.168.4.115 0:c0:df:3:2d:79 UHLW 2 2 lo0 > > > > > > > > > > > > > > # route add -net 10 3.3.3.3 > > > > > > > add net 10: gateway 3.3.3.3 > > > > > > > > > > > > > > # netstat -rn | grep 3.3.3.3 > > > > > > > 3.3.3.3 tun0 UHS 1 0 tun0 > > > > > > > 10 3.3.3.3 UGSc 0 0 rl0 > > > > > > > ^^^^ oops > > > > > > > > > > > > > > I still think we should disallow such routes on non-P2P interfaces, at > > > > > > > least. What do you think? > > > > > > > > > > > > > If you speek about disallowing routes like : route add -net 10 3.3.3.3 > > > > > > I don't think we should. I'm using such routes now (ethernet bridges for > > > > > > leased lines) and don't want to loose this functionality. > > > > > > > > > > > Could you please describe your setup in more details? > > > > > > > > > > I would like to disallow such routes for broadcast-like interfaces like > > > > > Ethernet, because on these interfaces, adding such a route results in: > > > > > > > > > > arplookup 3.3.3.3 failed: host is not on local network > > > > > arpresolve: can't allocate llinfo for 3.3.3.3rt > > > > > > > > > > It is a MUST here that the gateway should be directly connected > > > > > (via ARP). > > > > > > > > > If you have this route : > > > > 3.3.3.3 link#1 UC 1 0 rl0 => > > > > > > > > it won't result in this error message. > > > > > > > Having this host entry with the RTF_CLONING flag set, as you have shown > > > it, is impossible. It could only have been "cloned" from a network-type > > > routing table entry, as shown in the commit log for revision 1.50 of > > > route/route.c, and this case shouldn't be affected by that change. > > > Or like this: > > > > > > 3.3.3/24 link#1 UCSc 1 0 rl0 > > > 3.3.3.3 link#1 UHLW 1 1 rl0 > > > 10 3.3.3.3 UGSc 0 11 rl0 > > > > > > But then again, this means that the gateway (3.3.3.3) is directly reachable > > > (think one hop) on one of the attached networks (rl0), but the ARP reply > > > haven't been (yet) received, due to the host being down, as indicated by > > > ping(8): > > > > > > # ping 10.0.0.1 > > > PING 10.0.0.1 (10.0.0.1): 56 data bytes > > > ping: sendto: No route to host > > > ping: sendto: No route to host > > > ^C > > > --- 10.0.0.1 ping statistics --- > > > 6 packets transmitted, 0 packets received, 100% packet loss > > > > > > 3.3.3.3 link#1 UHRLW 1 0 rl0 > > > > > > (Note that `R' (RTF_REJECT) flag is set by arpresolve() after > > > net.link.ether.inet.maxtries unsuccessful ARP request tries.) > > > > > > > > That is my interface config: > > > > xl0: flags=8843 mtu 1500 > > inet 212.36.9.113 netmask 0xffffff00 broadcast 212.36.9.255 > > ether 00:04:76:22:15:83 > > media: autoselect (100baseTX ) status: active > > supported media: autoselect 100baseTX 100baseTX > > 10baseT/UT > > P 10baseT/UTP 100baseTX > > xl1: flags=8843 mtu 1500 > > inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 > > ether 00:10:5a:21:73:55 > > media: autoselect (100baseTX) status: active > > supported media: autoselect 100baseTX 100baseTX > > 10baseT/UT > > P 10baseT/UTP 100baseTX > > xl2: flags=8843 mtu 1500 > > inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 > > ether 00:10:4b:b8:65:2c > > media: autoselect (10baseT/UTP) status: active > > supported media: autoselect 100baseTX 100baseTX > > 10baseT/UT > > P 10baseT/UTP 100baseTX > > ed0: flags=8843 mtu 1500 > > inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 > > ether 00:40:05:60:f8:d8 > > > > > > and the static routes: > > > [...] > > default 212.36.8.129 UGSc 16 1612418 xl0 > > 212.36.8 link#1 UCSc 28 0 xl0 => > > > This case indeed should be allowed. Your ``default'' route isn't with > "indirect gateway", because the gateway route (route to 212.36.8.129) > doesn't have the `G' flag set. > > An example of "indirect route with also indirect gateway" would be: > > # route -n get -net 10 > route to: 10.0.0.0 > destination: 10.0.0.0 > mask: 255.0.0.0 > gateway: 1.2.3.4 > interface: rl0 > flags: > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire > 0 0 0 0 0 0 1500 0 > > # route -n get 1.2.3.4 > route to: 1.2.3.4 > destination: default > mask: default > gateway: 192.168.4.65 > interface: rl0 > flags: > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire > 0 0 0 0 0 0 1500 0 > > Or, in netstat(1) equivalent: > > default 192.168.4.65 UGSc 4 0 rl0 > 10 1.2.3.4 UGSc 0 0 rl0 > 192.168.4.65 0:d0:b7:16:9c:c6 UHLW 3 4055 rl0 1108 > > I.e., the gateway for net 10 is 1.2.3.4, where 1.2.3.4 is *indirectly* > reachable via the `default' route with gateway 192.168.4.65. > > Yes the gateway should be directly reachable throw interface. And I'm agree that this indirect gateway should be disallowed by some error message like : "gateway is not direcly reachable" or something. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 7:40:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from shadow.otel.net (JuDiCaToR.OTEL.net [212.36.9.113]) by hub.freebsd.org (Postfix) with ESMTP id 1951C37B406 for ; Mon, 2 Jul 2001 07:40:11 -0700 (PDT) (envelope-from tbyte@tbyte.org) Received: from localhost (localhost [127.0.0.1]) by shadow.otel.net (8.11.4/8.11.1) with ESMTP id f62Ee7K33691 for ; Mon, 2 Jul 2001 17:40:09 +0300 (EEST) (envelope-from tbyte@tbyte.org) Date: Mon, 2 Jul 2001 17:40:07 +0300 (EEST) From: Iasen Kostoff X-Sender: tbyte@shadow.otel.net To: freebsd-net@freebsd.org Subject: adding a route to host via interface Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Problem is that adding a route to host throw interface adds inerface as gateway (iface's lladdr). And you should manualy change lladdr of this route to the real lladdr. this is it: route add -host foo -iface bar arp -s foo real_lladdr_of_foo Is that realy a problem or I'm missing something ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 8:33:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from updraft.jp.freebsd.org (updraft.jp.FreeBSD.ORG [210.157.158.42]) by hub.freebsd.org (Postfix) with ESMTP id 61E0937B401 for ; Mon, 2 Jul 2001 08:33:35 -0700 (PDT) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by updraft.jp.freebsd.org (8.11.3+3.4W/8.11.3) with ESMTP/inet id f62FXVa45538 for ; Tue, 3 Jul 2001 00:33:31 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) X-Face: '*aj"d@ijeQ:/X}]oM5c5Uz{ZZZk90WPt>a^y4$cGQp8:!H\W=hSM;PuNiidkc]/%,;6VGu e+`&APmz|P;F~OL/QK%;P2vU>\j4X.8@i%j6[%DTs_3J,Fff0)*oHg$A.cDm&jc#pD24WK@{,"Ef!0 P\):.2}8jo-BiZ?X&t$V X-User-Agent: Mew/1.94.2 XEmacs/21.5 (alfalfa) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 200 From: Makoto MATSUSHITA To: net@FreeBSD.org Subject: [patch] Add 'ipv6' (protocol 41) support for ppp(8) Date: Tue, 03 Jul 2001 00:33:09 +0900 Message-Id: <20010703003309K.matusita@jp.FreeBSD.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm ADSL subscriber, and using ppp(8) to PPPoE to my ISP. I'm also want to get a IPv6 tunnel for my home network, but I find that ppp(8) does filter-out my IPv6 tunneling packet by implicit ruleset. This is because ppp(8) does filter out if not specified, and there is no way to specify ipv6 tunneling packet. It's not welcomed for me, so I write a patch attached below. This patch does teach ppp(8) about 'ipv6' protocol (protocol number 41) to filter. This patch also fixes not-initializing 'f_dstop' variable for other protocols. Anybody review my patch for me ? If it works well, I'll try to send a PR to include this patch to ppp(8) itself. -- - Makoto MATSUSHITA Index: command.c =================================================================== RCS file: /pub/cvsup/FreeBSD.cvs/src/usr.sbin/ppp/command.c,v retrieving revision 1.259 diff -u -r1.259 command.c --- command.c 2001/06/18 15:00:20 1.259 +++ command.c 2001/07/01 18:25:16 @@ -2120,7 +2120,7 @@ "escape characters", "set escape hex-digit ..."}, {"filter", NULL, filter_Set, LOCAL_AUTH, "packet filters", "set filter alive|dial|in|out rule-no permit|deny " - "[src_addr[/width]] [dst_addr[/width]] [tcp|udp|icmp|ospf|igmp " + "[src_addr[/width]] [dst_addr[/width]] [tcp|udp|icmp|ospf|igmp|ipv6 " "[src [lt|eq|gt port]] [dst [lt|eq|gt port]] [estab] [syn] [finrst]]"}, {"hangup", NULL, SetVariable, LOCAL_AUTH | LOCAL_CX, "hangup script", "set hangup chat-script", (const void *) VAR_HANGUP}, Index: filter.c =================================================================== RCS file: /pub/cvsup/FreeBSD.cvs/src/usr.sbin/ppp/filter.c,v retrieving revision 1.48 diff -u -r1.48 filter.c --- filter.c 2001/06/13 21:52:16 1.48 +++ filter.c 2001/07/02 14:47:46 @@ -197,7 +197,7 @@ switch (argc) { case 0: /* permit/deny all ICMP types */ - tgt->f_srcop = OP_NONE; + tgt->f_srcop = tgt->f_dstop = OP_NONE; break; case 3: @@ -209,6 +209,7 @@ } tgt->f_srcop = OP_EQ; tgt->f_srcport = type; + tgt->f_dstop = OP_NONE; } break; @@ -286,11 +287,27 @@ log_Printf(LogWARN, "ParseIgmp: Too many parameters\n"); return 0; } else - tgt->f_srcop = OP_NONE; + tgt->f_srcop = tgt->f_dstop = OP_NONE; return 1; } +static int +ParseIPv6(int argc, char const * const *argv, struct filterent *tgt) +{ + /* + * Filter currently is a catch-all. Requests are either permitted or + * dropped. + */ + if (argc != 0) { + log_Printf(LogWARN, "ParseIPv6: Too many parameters\n"); + return 0; + } else + tgt->f_srcop = tgt->f_dstop = OP_NONE; + + return 1; +} + #ifdef P_GRE static int ParseGRE(int argc, char const * const *argv, struct filterent *tgt) @@ -303,7 +320,7 @@ log_Printf(LogWARN, "ParseGRE: Too many parameters\n"); return 0; } else - tgt->f_srcop = OP_NONE; + tgt->f_srcop = tgt->f_dstop = OP_NONE; return 1; } @@ -321,7 +338,7 @@ log_Printf(LogWARN, "ParseOspf: Too many parameters\n"); return 0; } else - tgt->f_srcop = OP_NONE; + tgt->f_srcop = tgt->f_dstop = OP_NONE; return 1; } @@ -495,6 +512,9 @@ case P_IPIP: val = ParseUdpOrTcp(argc, argv, P_IPIP, &filterdata); break; + case P_IPV6: + val = ParseIPv6(argc, argv, &filterdata); + break; case P_ICMP: val = ParseIcmp(argc, argv, &filterdata); break; @@ -653,7 +673,8 @@ } static const char * const protoname[] = { - "none", "tcp", "udp", "icmp", "ospf", "igmp", "gre", "ipip" + "none", "tcp", "udp", "icmp", "ospf", "igmp", + "gre", "esp", "ah", "ipip", "ipv6" }; const char * Index: filter.h =================================================================== RCS file: /pub/cvsup/FreeBSD.cvs/src/usr.sbin/ppp/filter.h,v retrieving revision 1.27 diff -u -r1.27 filter.h --- filter.h 2001/06/13 21:52:16 1.27 +++ filter.h 2001/07/01 18:09:41 @@ -43,6 +43,7 @@ #define P_ESP 7 #define P_AH 8 #define P_IPIP 9 +#define P_IPV6 10 /* Operations - f_srcop, f_dstop */ #define OP_NONE 0 Index: ip.c =================================================================== RCS file: /pub/cvsup/FreeBSD.cvs/src/usr.sbin/ppp/ip.c,v retrieving revision 1.93 diff -u -r1.93 ip.c --- ip.c 2001/06/18 15:00:22 1.93 +++ ip.c 2001/07/02 14:43:57 @@ -289,6 +289,15 @@ sport = dport = 0; estab = syn = finrst = -1; break; + case IPPROTO_IPV6: + cproto = P_IPV6; + if (datalen < 20) { /* RFC2893 Section 3.5: 5 * 32bit words */ + log_Printf(LogFILTER, " error: IPV6 header incorrect\n"); + return 1; + } + sport = dport = 0; + estab = syn = finrst = -1; + break; case IPPROTO_UDP: cproto = P_UDP; if (datalen < 8) { /* UDP header is 8 octets */ @@ -640,6 +649,20 @@ len = ntohs(pip->ip_len) - (pip->ip_hl << 2); snprintf(logbuf + loglen, sizeof logbuf - loglen, "OSPF: %s ---> ", inet_ntoa(pip->ip_src)); + loglen += strlen(logbuf + loglen); + snprintf(logbuf + loglen, sizeof logbuf - loglen, + "%s (%d/%d)", inet_ntoa(pip->ip_dst), len, nb); + loglen += strlen(logbuf + loglen); + } + break; +#endif + +#ifdef IPPROTO_IPV6 + case IPPROTO_IPV6: + if (logit && loglen < sizeof logbuf) { + len = ntohs(pip->ip_len) - (pip->ip_hl << 2); + snprintf(logbuf + loglen, sizeof logbuf - loglen, + "IPv6: %s ---> ", inet_ntoa(pip->ip_src)); loglen += strlen(logbuf + loglen); snprintf(logbuf + loglen, sizeof logbuf - loglen, "%s (%d/%d)", inet_ntoa(pip->ip_dst), len, nb); Index: ppp.8 =================================================================== RCS file: /pub/cvsup/FreeBSD.cvs/src/usr.sbin/ppp/ppp.8,v retrieving revision 1.267 diff -u -r1.267 ppp.8 --- ppp.8 2001/06/20 19:55:58 1.267 +++ ppp.8 2001/07/02 03:56:11 @@ -1746,6 +1746,7 @@ .Sq icmp , .Sq igmp , .Sq ipip , +.Sq ipv6 , .Sq ospf , .Sq udp or To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 10: 9:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id CDB1037B403 for ; Mon, 2 Jul 2001 10:09:46 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f62H9gJ17386; Mon, 2 Jul 2001 10:09:42 -0700 Date: Mon, 2 Jul 2001 10:09:42 -0700 From: Brooks Davis To: Vladimir Terziev Cc: freebsd-net@FreeBSD.ORG Subject: Re: Cisco Aironet 340 Series Message-ID: <20010702100942.B10075@Odin.AC.HMC.Edu> References: <200107020837.LAA37120@star.rila.bg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7ZAtKRhVyVSsbBD2" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107020837.LAA37120@star.rila.bg>; from vlady@rila.bg on Mon, Jul 02, 2001 at 11:37:16AM +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --7ZAtKRhVyVSsbBD2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 02, 2001 at 11:37:16AM +0300, Vladimir Terziev wrote: > I'm planning to setup a Intranet network, based on wireless connections= . I=20 > think to use Cisco Aironet 340 Series cards for client access. >=20 > Is FreeBSD supports Cisco Aironet 340 Series cards ? They work quite well. Just be sure to use a recent version of FreeBSD as there have been issues in older versions. -- 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 --7ZAtKRhVyVSsbBD2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7QKrVXY6L6fI4GtQRAqShAJ93c385yTjWAvs+cXxCiTmGSRZzQQCgjAwA L7NI5cCY/9yd9vhUzkyh4fY= =YeT1 -----END PGP SIGNATURE----- --7ZAtKRhVyVSsbBD2-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 10:15:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by hub.freebsd.org (Postfix) with ESMTP id 2B0A237B403 for ; Mon, 2 Jul 2001 10:15:26 -0700 (PDT) (envelope-from oberman@ptavv.es.net) Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.10.1/8.10.1) with ESMTP id f62HFLc25924; Mon, 2 Jul 2001 10:15:21 -0700 (PDT) Message-Id: <200107021715.f62HFLc25924@ptavv.es.net> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: freebsd-net@FreeBSD.ORG Subject: Re: Odd IPv6 behavior when not connected to IPv6 net In-reply-to: Your message of "Mon, 02 Jul 2001 15:27:26 +0900." Date: Mon, 02 Jul 2001 10:15:21 -0700 From: "Kevin Oberman" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Date: Mon, 02 Jul 2001 15:27:26 +0900 > From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= > Sender: owner-freebsd-net@FreeBSD.ORG > > >>>>> On Fri, 29 Jun 2001 09:28:54 -0700, > >>>>> "Kevin Oberman" said: > > >> That is, if we do not have any default router (hear from RA), we > >> should regard all IPv6 prefixes as on-link. To implement this trick, > >> we use the "default interface", and install the default route as an > >> interface direct route to the interface. > > > I think the basic idea in the RFC may be reasonable. It only breaks > > when the link selected is loopback. Had the stack tried to connect to > > a physical link, this would have worked as intended, but loopback will > > always be the wrong answer if it is the link used. > > Just to make it sure, even if you specify a non-loopback interface as > the default, you should still (usually) see a long delay before the > connection attempt by IPv6 fails, because this type of error is not a > hard error for TCP (like "no route to host"). The delay would be > about 1 minute. I don't think most users will tolerate the delay, > especially when the IPv4 connection can be established. I absolutely agree. I have users up in arms when there is an 8 second delay due to a DNS failure. 1 minute is a complete non-starter. > >> Thus, for the moment, I agree that we should turn the default > >> interface off by default. For a longer term solution, we might have > >> to consider a better source address selection algorithm, > >> e.g. described in draft-ietf-ipngwg-default-addr-select-04.txt. Then > >> IPv4 would be preferred in this case. > > > This is certainly reasonable, too. But the step of not allowing the lo > > interface to qualify as the link for the default route seems like > > something that should be done as well. > > > Of course, there may be some reason to want default to point at lo, > > but I can't think of a good one. > > I don't have any objection to changing the default interface to a > non-loopback one, *if the default is ever defined*. I'm arguing that > it would be safe *not to specify the default interface by default*. Ah. I guess I missed your obvious point. I'm still thinking about the possible effects of not specifying a default route by default. At the moment I don't see any other "solution" to the problem. I think it's a "wrong" answer, but less "wrong" than any other answer I've seen. The real issue, from my perspective, is that nothing that discourages the use of IPv6 should be done. Default to loopback is unacceptable on both POLA and simple functional basis. (And I was VERY astonished!) A one minute delay is also unacceptable. So, we're stuck with whatever is left. I am a bit unclear why the timeout for a "local" connection should be as long as a minute, but even if it was significantly reduced, it would remain unacceptable, so I guess I won't worry about it. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 10:35:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id B618737B401 for ; Mon, 2 Jul 2001 10:35:41 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA17615 for ; Tue, 3 Jul 2001 02:36:55 +0900 (JST) Date: Tue, 03 Jul 2001 02:35:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: freebsd-net@FreeBSD.ORG Subject: Re: Odd IPv6 behavior when not connected to IPv6 net In-Reply-To: <200107021715.f62HFLc25924@ptavv.es.net> References: <200107021715.f62HFLc25924@ptavv.es.net> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 50 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Mon, 02 Jul 2001 10:15:21 -0700, >>>>> "Kevin Oberman" said: >> I don't have any objection to changing the default interface to a >> non-loopback one, *if the default is ever defined*. I'm arguing that >> it would be safe *not to specify the default interface by default*. > Ah. I guess I missed your obvious point. I'm still thinking about the > possible effects of not specifying a default route by default. At the > moment I don't see any other "solution" to the problem. I think it's a > "wrong" answer, but less "wrong" than any other answer I've seen. > The real issue, from my perspective, is that nothing that discourages > the use of IPv6 should be done. Default to loopback is unacceptable on > both POLA and simple functional basis. (And I was VERY astonished!) A > one minute delay is also unacceptable. So, we're stuck with whatever > is left. I'd recommend to simply disable the following part in rc.network6. # Disable installing the default interface with the # case net.inet6.ip6.forwarding=0 and # net.inet6.ip6.accept_rtadv=0, due to avoid conflict # between the default router list and the manual # configured default route. case ${ipv6_gateway_enable} in [Yy][Ee][Ss]) ;; *) if [ `sysctl -n net.inet6.ip6.accept_rtadv` -eq 1 ] then ----> ndp -I ${ipv6_default_interface} fi Actually, disabling this part has almost no bad effect. The only possible bad effect is that we cannot make communication in the following case: - we do not have any default router that advertises Router Advertisements. - the destination node should be on-link, but does not share address prefix with us. I strongly believe such a situation is very rare, and can be ignored in normal cases. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 12: 3:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from node7.cluster.srrc.usda.gov (symbion.srrc.usda.gov [199.133.86.40]) by hub.freebsd.org (Postfix) with ESMTP id 62CD637B401; Mon, 2 Jul 2001 12:03:21 -0700 (PDT) (envelope-from gjohnson@srrc.ars.usda.gov) Received: (from glenn@localhost) by node7.cluster.srrc.usda.gov (8.11.4/8.11.4) id f62J30Q00843; Mon, 2 Jul 2001 14:03:00 -0500 (CDT) (envelope-from glenn) Date: Mon, 2 Jul 2001 14:02:59 -0500 From: Glenn Johnson To: Mike Silbersack Cc: Jonathan Lemon , net@freebsd.org, kris@freebsd.org, Gilbert Gong Subject: Re: select fails to return incoming connect on FreeBSD-4.3 Message-ID: <20010702140259.A639@node7.cluster.srrc.usda.gov> References: <20010627220031.B10008@prism.flugsvamp.com> <20010701214104.V1087-200000@achilles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010701214104.V1087-200000@achilles.silby.com>; from silby@silby.com on Sun, Jul 01, 2001 at 09:45:47PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Jul 01, 2001 at 09:45:47PM -0500, Mike Silbersack wrote: > On Wed, 27 Jun 2001, Jonathan Lemon wrote: > > > I don't object; while the security provided by the new scheme is > > nice, breaking TIME_WAIT assassination is a serious bug in some > > environments, and there should be a way to work around it now. > > -- > > Jonathan > > Ok, attached is a patch for 4.3-stable which makes the > generation scheme sysctl selectable. You use the sysctl > net.inet.tcp.tcp_seq_genscheme to set which scheme you want. 0 is the > old random positive increments scheme, 1 is the more random OpenBSD > scheme. 1 is the default setting, so those encountering the TIME_WAIT > problem will have to put something in a boot script to set the > variable to 0. > > There's one slight difference in this implementation of the old scheme > versus the old implementation of it. Before, we used TCP_ISSINCR/2 > for outgoing incrementations, and /4 for incoming. We use /2 in both > cases now, for simplicity's sake. > > Please review, especially if you're experiencing the TIME_WAIT > problem. I just tested this and it looks fine to me. It gets the sample code in PR misc/27880 working and more importantly it gets PBS (Portable Batch System) working again. Once this is merged into 4.3-STABLE I will send a message to the pbs mail list to let the FreeBSD users know what to do. Thank you very much for fixing this. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: gjohnson@srrc.ars.usda.gov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 12:55: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from goliath.cnchost.com (goliath.cnchost.com [207.155.252.47]) by hub.freebsd.org (Postfix) with ESMTP id D95E037B401; Mon, 2 Jul 2001 12:54:59 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by goliath.cnchost.com id PAA25927; Mon, 2 Jul 2001 15:54:49 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200107021954.PAA25927@goliath.cnchost.com> To: Wes Peters Cc: Ruslan Ermilov , Deepak Jain , net@FreeBSD.org Subject: Re: fastforwarding? In-reply-to: Your message of "Sun, 01 Jul 2001 15:52:44 MDT." <3B3F9BAC.782B8E00@softweyr.com> Date: Mon, 02 Jul 2001 12:54:49 -0700 From: Bakul Shah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > IMHO you are better off using a recent route lookup algorithm > > than messing with caches. The PATRICIA tree algorithm is > > what 33 years old now? > > Not true. Any routing algorithm takes longer because they are by > definition a "fuzzy match." The fastforward algorithm is not, it By defn the best match is the longest prefix match. > is a simple destination address lookup; the cached route is either > there or it is not. Fast hashing algorithms are quite effective > in locating the route if it has been cached. Routing switches A simple hashtable will be faster but not significantly so compared to some of the recent trie algorithms. And both are faster than the radix tree used in *BSD. With a trie you can do just a single route lookup (currently an input packet's dest. ip addr. is matched against the list of broadcast addresses for the machine -- this check is free with a trie). And you don't have to worry about the size of the cache blowing up (or deleting stale cache entries) or having to check the cache for every route add/delete. At present the cache size is not bound so over a period of time it will blow up in size. since the cache size is a function of distinct IP addresses forwarded to, a user on another host can eat up all memory of (or worse, crash) a freebsd based router by doing an IP address scan. So *overall* you are better off using a trie algorithm. BTW, the current fastforward code doesn't handle route add/delete and hence has the same bug I mentioned in my previous msg. > usually speed up the lookup even further by using Content Addressable > Memory to map the destination address to a cached route or interface > pointer; it would be interesting to experiment with something like > that in FreeBSD. Even if it takes 0 ns to do a route lookup, a stock freebsd system can't do more than 20K ~ 100K pkts/second due to many bottlenecks. In a hardware accelrated router one can easily do 10M route lookups *without* using an expensive & power hungry fancy CAM. But they may be worth it if you want to route 1M+ pkts/second *and* you want to do packet matching. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 13:40:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from pltn13.pbi.net (mta8.pltn13.pbi.net [64.164.98.22]) by hub.freebsd.org (Postfix) with ESMTP id 36FFF37B406 for ; Mon, 2 Jul 2001 13:40:15 -0700 (PDT) (envelope-from hsu@FreeBSD.org) Received: from FreeBSD.org ([63.193.112.125]) by mta8.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GFV00LBS5EXRH@mta8.pltn13.pbi.net> for freebsd-net@freebsd.org; Mon, 02 Jul 2001 13:40:09 -0700 (PDT) Date: Mon, 02 Jul 2001 13:39:54 -0700 From: Jeffrey Hsu Subject: Re: fastforwarding? In-reply-to: "Your message of Mon, 02 Jul 2001 12:54:49 PDT." <200107021954.PAA25927@goliath.cnchost.com> To: Bakul Shah Cc: freebsd-net@freebsd.org Message-id: <0GFV00LBT5EXRH@mta8.pltn13.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.1.1 10/15/1999 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > a stock freebsd system can't do more than 20K ~ 100K pkts/second due to > many bottlenecks I'd be interested in knowing where those bottlenecks were and fixing them. I currently hit the packets/sec limit running on gigabit ethernet cards, but so far I've been blaming it on the relatively old firm-ware based Tigon II NIC and not the BSD stack. > Even if it takes 0 ns to do a route lookup, So are you saying route lookup is not the bottleneck? > So *overall* you are better off using a trie algorithm. I'm thinking of the probability-shifted lc-trie algorithm described in http://klamath.stanford.edu/~pankaj/research.html Do you have a better algorithm in mind? Jeffrey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 14:11:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by hub.freebsd.org (Postfix) with ESMTP id 32D1F37B403 for ; Mon, 2 Jul 2001 14:11:08 -0700 (PDT) (envelope-from mcambria@avaya.com) Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 17:10:54 -0400 Message-ID: <3A6D367EA1EFD4118C9B00A0C9DD99D7064F5E@rerun.lucentctc.com> From: "Cambria, Mike" To: snap-users@kame.net, "'freebsd-net@freebsd.org'" Subject: Can I define a SPD per interface? Date: Mon, 2 Jul 2001 17:10:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I can only find a way to define a global SPD using setkey. Is it possible to define an (IPv4) SPD on a per interface basis using KAME / FreeBSD4? If not, are there any plans to add this in the future? Is there any reason one wouldn't want to have this? Thanks, MikeC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 14:15: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 0B98E37B405; Mon, 2 Jul 2001 14:15:02 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id XAA38398; Mon, 2 Jul 2001 23:09:45 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200107022109.XAA38398@info.iet.unipi.it> Subject: Re: fastforwarding? In-Reply-To: <0GFV00LBT5EXRH@mta8.pltn13.pbi.net> from Jeffrey Hsu at "Jul 2, 2001 01:39:54 pm" To: Jeffrey Hsu Date: Mon, 2 Jul 2001 23:09:45 +0200 (CEST) Cc: Bakul Shah , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > a stock freebsd system can't do more than 20K ~ 100K pkts/second due to > > many bottlenecks > > I'd be interested in knowing where those bottlenecks were and fixing them. one of them is the (relatively high) interrupt overhead, as reported by many. There is a good description of the problem in the Click's paper at http://www.pdos.lcs.mit.edu/click/ and in the Mogul's paper referenced in there. In line with what is suggested above, reducing this overhead requires a solution that involves some form of polling. This gives you a lot of improvement in performance, maybe by a factor of 3 or so. The approach we are trying is based on some very simple modifications to the interrupt dispatcher. Basically the idea is to run with e.g. HZ=2000 or so, and disable interrupts on a line for the rest of a tick after you get more than X interrupts per tick (with small X). The system remains decently responsive, because you are re-enabling ints at the next clock tick (in 500us or less), or when you enter the idle loop; and when you happen to call ether_output() you have a chance to poll the device. The advantage of this approach is that you don't have to implement a real polling system (which can become expensive when the number of cards in a box becomes large), and that modifications are relatively small and, especially, device-independent. Hopefully we will be able to post them soon, after a bit more experiments. After this change, using FASTFORWARDING seems to save another 20-30% on the per-packet processing time. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 15:23: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 558) id 29F3337B401; Mon, 2 Jul 2001 15:22:59 -0700 (PDT) To: luigi@info.iet.unipi.it Subject: Re: fastforwarding? Cc: freebsd-net@freebsd.org In-Reply-To: <200107022109.XAA38398@info.iet.unipi.it> Message-Id: <20010702222259.29F3337B401@hub.freebsd.org> Date: Mon, 2 Jul 2001 15:22:59 -0700 (PDT) From: hsu@FreeBSD.ORG (Jeffrey Hsu) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > one of them is the (relatively high) interrupt overhead > as reported by many. There is a good description of the problem > in the Click's paper at http://www.pdos.lcs.mit.edu/click/ and > in the Mogul's paper referenced in there. > The advantage of this approach is that you don't have to implement > a real polling system (which can become expensive when the number > of cards in a box becomes large), and that modifications are > relatively small and, especially, device-independent. Hopefully > we will be able to post them soon, after a bit more experiments. Interesting. We've been working on the Lazy Receiver Processing approach (http://www.cs.rice.edu/CS/Systems/LRP) to this problem in combination with polling after processing as suggested by Mogul's paper. As I understand it, your approach has the benefit of simplicity over the LRP approach. Jeffrey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 15:42:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id B466937B403; Mon, 2 Jul 2001 15:42:11 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id AAA39077; Tue, 3 Jul 2001 00:36:57 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200107022236.AAA39077@info.iet.unipi.it> Subject: Re: fastforwarding? In-Reply-To: <20010702222259.29F3337B401@hub.freebsd.org> from Jeffrey Hsu at "Jul 2, 2001 03:22:59 pm" To: Jeffrey Hsu Date: Tue, 3 Jul 2001 00:36:57 +0200 (CEST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > one of them is the (relatively high) interrupt overhead ... > Interesting. We've been working on the Lazy Receiver Processing > approach (http://www.cs.rice.edu/CS/Systems/LRP) to this problem > in combination with polling after processing as suggested by Mogul's > paper. As I understand it, your approach has the benefit of simplicity > over the LRP approach. well, it is simpler because it targets a simpler problem, namely forwarding from one interface to another one. But certainly, cutting off a fair amount of interrupt processing time frees some CPU for protocol processing. At a quick glance at the URL you mention, LRP seems to look at higher level protocol processing, and at giving a more fair treatment to different flows. This problem is a bit more complex to handle, as it requires modifications in the protocol stack (and maybe the CPU scheduler) as well. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 16:12: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from starfruit.itojun.org (dial-108-D01.QXO1.equant.net [57.72.131.108]) by hub.freebsd.org (Postfix) with ESMTP id 857BE37B403 for ; Mon, 2 Jul 2001 16:12:04 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id F0BF37BC; Tue, 3 Jul 2001 08:12:00 +0900 (JST) To: "Cambria, Mike" To: snap-users@kame.net Cc: "'freebsd-net@freebsd.org'" In-reply-to: mcambria's message of Mon, 02 Jul 2001 17:10:47 -0400. <3A6D367EA1EFD4118C9B00A0C9DD99D7064F5E@rerun.lucentctc.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: (KAME-snap 5064) Can I define a SPD per interface? From: Jun-ichiro itojun Hagino Date: Tue, 03 Jul 2001 08:12:00 +0900 Message-Id: <20010702231200.F0BF37BC@starfruit.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >I can only find a way to define a global SPD using setkey. Is it possible >to define an (IPv4) SPD on a per interface basis using KAME / FreeBSD4? >If not, are there any plans to add this in the future? >Is there any reason one wouldn't want to have this? no. do you want SPD per interface, or IPsec SPI per interface? anyway, IPsec architecture is not interface-oriented (it lives on top of IP, and the information on interface is already gone) so your suggestion does not fit nicely to the current architecture... why do you want that? like you want to setup a tricky VPN gateway? itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 16:52:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from warspite.cnchost.com (warspite.concentric.net [207.155.248.9]) by hub.freebsd.org (Postfix) with ESMTP id 1F14C37B401; Mon, 2 Jul 2001 16:52:25 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by warspite.cnchost.com id TAA11491; Mon, 2 Jul 2001 19:52:24 -0400 (EDT) [ConcentricHost SMTP Relay 1.13] Message-ID: <200107022352.TAA11491@warspite.cnchost.com> To: Jeffrey Hsu Cc: freebsd-net@freebsd.org Subject: Re: fastforwarding? In-reply-to: Your message of "Mon, 02 Jul 2001 13:39:54 PDT." <0GFV00LBT5EXRH@mta8.pltn13.pbi.net> Date: Mon, 02 Jul 2001 16:52:24 -0700 From: Bakul Shah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > a stock freebsd system can't do more than 20K ~ 100K pkts/second due to > > many bottlenecks > > I'd be interested in knowing where those bottlenecks were and fixing them. > I currently hit the packets/sec limit running on gigabit ethernet cards, but > so far I've been blaming it on the relatively old firm-ware based Tigon II NIC > and not the BSD stack. > > > Even if it takes 0 ns to do a route lookup, > > So are you saying route lookup is not the bottleneck? The radix tree lookup is definitely slow. My point was that you need to look at the entire forwarding path to improve performance even if you replace the radix tree with something faster. For instance, - interrupt overhead as Luigi (and others) have noted - an input packet is queued twice: once on the device queue and once on the ip input queue. - If your router has a many interfaces, the input packet is checked against the directed broadcast address for every interface. - mbuf processing. - processing the same packet multiple times. For example, checking that 127.x.x.x does not come in from outside. bpf. ipfilter, ipfw, dummynet etc. - The cost of modularity and layering. Probably better to use inlining judiciously so that the compiler can flatten out call sequences. - The common case is not optimized. For a router the common case is forwarding a packet, for a host it is not. You need two different routines optimizing each case and plug in the right function, depending on the application. Similarly for firewalls etc. you have different common cases. Not rocket science, mostly compiler tricks! Just what you can do by removing duplication, knowing and optimizing the common case, code movement (move processing from per packet to route add/delete etc.), use brute force (switch or jumptable instead of a bunch of if-then-elses), strength reduction (use a cheaper operation), all based on measuring hotspots. Most of this is just plain old boring engineering so likely there are not many papers on them :-) > > So *overall* you are better off using a trie algorithm. > > I'm thinking of the probability-shifted lc-trie algorithm described in > http://klamath.stanford.edu/~pankaj/research.html > Do you have a better algorithm in mind? That or even simpler algorithms will suffice. Once you bring the cost of route lookup below 1 to 5% it doesn't matter much. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 17:49: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 0655D37B403 for ; Mon, 2 Jul 2001 17:48:59 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 4820 invoked by uid 1000); 3 Jul 2001 00:48:56 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 3 Jul 2001 00:48:56 -0000 Date: Mon, 2 Jul 2001 19:48:56 -0500 (CDT) From: Mike Silbersack To: Glenn Johnson Cc: Jonathan Lemon , , , Gilbert Gong Subject: Re: select fails to return incoming connect on FreeBSD-4.3 In-Reply-To: <20010702140259.A639@node7.cluster.srrc.usda.gov> Message-ID: <20010702194712.C4818-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 2 Jul 2001, Glenn Johnson wrote: > I just tested this and it looks fine to me. It gets the sample code in > PR misc/27880 working and more importantly it gets PBS (Portable Batch > System) working again. Once this is merged into 4.3-STABLE I will send > a message to the pbs mail list to let the FreeBSD users know what to do. > > Thank you very much for fixing this. > > -- > Glenn Johnson Good. Once I hear back from another -net committer on this, I'll get it committed. Thanks for the quick test. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 19:37: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 4F2C537B405 for ; Mon, 2 Jul 2001 19:37:05 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f632axG25942; Mon, 2 Jul 2001 19:36:59 -0700 (PDT) Message-ID: <3B412FCB.4070609@isi.edu> Date: Mon, 02 Jul 2001 19:36:59 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD 4.2-RELEASE i386; en-US; rv:0.9) Gecko/20010529 X-Accept-Language: en, de MIME-Version: 1.0 To: snap-users@kame.net Cc: "'freebsd-net@freebsd.org'" Subject: Re: (KAME-snap 5064) Can I define a SPD per interface? References: <3A6D367EA1EFD4118C9B00A0C9DD99D7064F5E@rerun.lucentctc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Cambria, Mike wrote: > I can only find a way to define a global SPD using setkey. Is it possible > to define an (IPv4) SPD on a per interface basis using KAME / FreeBSD4? Don't your interfaces have different source addresses that you can match on? Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 21:11:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by hub.freebsd.org (Postfix) with ESMTP id F0ACD37B407 for ; Mon, 2 Jul 2001 21:11:12 -0700 (PDT) (envelope-from bjf@samurai.com) Received: from [192.168.1.34] ([65.92.109.138]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010703041111.KJAL3306.tomts8-srv.bellnexxia.net@[192.168.1.34]> for ; Tue, 3 Jul 2001 00:11:11 -0400 Mime-Version: 1.0 X-Sender: bjf@mail.samurai.com Message-Id: Date: Tue, 3 Jul 2001 00:09:14 -0400 To: net@freebsd.org From: Bryan Fullerton Subject: PPPoE latency Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Howdy, I've been wondering why the latency is higher in FreeBSD's PPPoE implementation. From what I've seen, ping times via my gateway box are significantly higher than what friends are seeing with dedicated router boxes (ie Linksys) on the same DSL provider. Here's what I'm seeing to the other end of my connection, no other meaningful traffic going on: --- 65.92.109.1 ping statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max/stddev = 53.982/65.063/102.373/7.478 ms Here's a ping on my friend's machine (Mac ping, sorry for lack of precision): Packets out/in/bad/%loss = 64/64/0/0.0 Round Trip Time (ms) min/avg/max = 14/24/59 My box should be fine cpu-wise, it's a Celeron/300, and isn't doing anything else. The card PPPoE is running over is an ISA 10BaseT D-Link card using the ed(4) driver, if that makes any difference. I track STABLE with this box, it's currently at: FreeBSD katana.apt.samurai.com 4.3-STABLE FreeBSD 4.3-STABLE #13: Sun Jun 24 01:43:39 EDT 2001 Any thoughts? I can live with this, the connection is rock solid and has been for over a year now, just curious as to why. Apologies if this has come up before, I searched the list archives and the bug list. Thanks, Bryan -- Bryan Fullerton http://bryanfullerton.com/ Core Competence uunet.ca!gts!cspace!bjf Samurai Consulting Can you feel the Ohmu call? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 21:36:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id F0A1637B401 for ; Mon, 2 Jul 2001 21:36:16 -0700 (PDT) (envelope-from bright@sneakerz.org) Received: by sneakerz.org (Postfix, from userid 1092) id 65A0D5D010; Mon, 2 Jul 2001 23:36:06 -0500 (CDT) Date: Mon, 2 Jul 2001 23:36:06 -0500 From: Alfred Perlstein To: Bryan Fullerton Cc: net@freebsd.org Subject: Re: PPPoE latency Message-ID: <20010702233606.A84523@sneakerz.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from bjf@samurai.com on Tue, Jul 03, 2001 at 12:09:14AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Bryan Fullerton [010702 23:11] wrote: > > Howdy, > > I've been wondering why the latency is higher in FreeBSD's PPPoE > implementation. From what I've seen, ping times via my gateway box > are significantly higher than what friends are seeing with dedicated > router boxes (ie Linksys) on the same DSL provider. [snip config/bench] Without a real idea of what's in the dedicated equipment it's hard to say. A couple things about your configuration really say "low-end" equipment, especially the NIC being used. There's also the possibility that if you're using NAT you're using NATd which because of the way it works (userland process that must double copy all packets) you're not getting the best performance from that as well. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 21:43:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from bilver.wjv.com (dhcp-1-86.n01.orldfl01.us.ra.verio.net [157.238.210.86]) by hub.freebsd.org (Postfix) with ESMTP id BE90837B401 for ; Mon, 2 Jul 2001 21:43:37 -0700 (PDT) (envelope-from bill@bilver.wjv.com) Received: (from bill@localhost) by bilver.wjv.com (8.11.1/8.11.1) id f634hGW02675; Tue, 3 Jul 2001 00:43:16 -0400 (EDT) (envelope-from bill) Date: Tue, 3 Jul 2001 00:43:07 -0400 From: Bill Vermillion To: Bryan Fullerton Cc: net@FreeBSD.ORG Subject: Re: PPPoE latency Message-ID: <20010703004307.E2458@wjv.com> Reply-To: bv@wjv.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bjf@samurai.com on Tue, Jul 03, 2001 at 12:09:14AM -0400 Organization: W.J.Vermillion / Orlando - Winter Park Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 03, 2001 at 12:09:14AM -0400, Bryan Fullerton thus sprach: > I've been wondering why the latency is higher in FreeBSD's PPPoE > implementation. From what I've seen, ping times via my gateway box > are significantly higher than what friends are seeing with dedicated > router boxes (ie Linksys) on the same DSL provider. The only way to be sure it is OS related [and I suspect it is not] is to take your machine to their location. DSL can vary in speed from location to location. > Here's what I'm seeing to the other end of my connection, no other > meaningful traffic going on: > --- 65.92.109.1 ping statistics --- > 100 packets transmitted, 100 packets received, 0% packet loss > round-trip min/avg/max/stddev = 53.982/65.063/102.373/7.478 ms > Here's a ping on my friend's machine (Mac ping, sorry for lack of precision): > Packets out/in/bad/%loss = 64/64/0/0.0 > Round Trip Time (ms) min/avg/max = 14/24/59 My BSD runs 19.447/19.874/20.255/0.322 on my DSL. Since the first link to the DSL is not your system but the box above it, I really suspect that is the problem. BTW I am NOT using PPPoE but PPoA. That link is a 512/128. I just telneted into another DSL I have - at a different location - and that is 14.881/15.613/16.369/0.547 It is the same provider - the ISP I help run. But the first link is a Sprint DSL [PPoA], and the second is BellSouth in a bridge mode. Both go to the same router - but use two different transport links. We resell their connections instead of putting in hardware at the CO. > Any thoughts? I can live with this, the connection is rock solid and > has been for over a year now, just curious as to why. Apologies if > this has come up before, I searched the list archives and the bug > list. While not using DSL for that length of time, I really don't think it is the FreeBSD. Taking your machine to your friends place is the only way to check - as only then will you be using the same routing all the way, both connecting to the same DSLAM, etcetera. BTW - my link at 512K qualifies for 3MB but that costs more, priced by speed, but the one at the office [that I telneted to and then timed going out] is running about 1MB, and the only thing guaranteed is something below 512 - perhaps 380 - but the closer you are the faster you go. Those are marketing decisions made by the respective companies. Bill -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 21:50:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by hub.freebsd.org (Postfix) with ESMTP id 8558737B401 for ; Mon, 2 Jul 2001 21:50:17 -0700 (PDT) (envelope-from bjf@samurai.com) Received: from [192.168.1.34] ([65.92.109.138]) by tomts13-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010703045016.PXEQ7196.tomts13-srv.bellnexxia.net@[192.168.1.34]>; Tue, 3 Jul 2001 00:50:16 -0400 Mime-Version: 1.0 X-Sender: bjf@mail.samurai.com Message-Id: In-Reply-To: <20010702233606.A84523@sneakerz.org> References: <20010702233606.A84523@sneakerz.org> Date: Tue, 3 Jul 2001 00:50:03 -0400 To: Alfred Perlstein From: Bryan Fullerton Subject: Re: PPPoE latency Cc: net@freebsd.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 11:36 PM -0500 7/2/01, Alfred Perlstein wrote: > >Without a real idea of what's in the dedicated equipment it's hard >to say. A couple things about your configuration really say >"low-end" equipment, especially the NIC being used. It's absolutely not high-end stuff, but this is only a residential 1Mb/120Kb DSL line, shouldn't really be taxing the NIC. If there's anything else about the config you'd like to know, I'd be happy to provide details. If you really think switching to a better ethernet card will help, I have a 3C905B sitting here that I can try. >There's also >the possibility that if you're using NAT you're using NATd which >because of the way it works (userland process that must double copy >all packets) you're not getting the best performance from that as >well. Nope, ppp -nat, no natd. Bryan -- Bryan Fullerton http://bryanfullerton.com/ Core Competence uunet.ca!gts!cspace!bjf Samurai Consulting Can you feel the Ohmu call? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 21:54:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id 156EE37B401 for ; Mon, 2 Jul 2001 21:54:35 -0700 (PDT) (envelope-from bright@sneakerz.org) Received: by sneakerz.org (Postfix, from userid 1092) id 7D8875D010; Mon, 2 Jul 2001 23:54:34 -0500 (CDT) Date: Mon, 2 Jul 2001 23:54:34 -0500 From: Alfred Perlstein To: Bryan Fullerton Cc: net@freebsd.org Subject: Re: PPPoE latency Message-ID: <20010702235434.B84523@sneakerz.org> References: <20010702233606.A84523@sneakerz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from bjf@samurai.com on Tue, Jul 03, 2001 at 12:50:03AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Bryan Fullerton [010702 23:50] wrote: > At 11:36 PM -0500 7/2/01, Alfred Perlstein wrote: > > > >Without a real idea of what's in the dedicated equipment it's hard > >to say. A couple things about your configuration really say > >"low-end" equipment, especially the NIC being used. > > It's absolutely not high-end stuff, but this is only a residential > 1Mb/120Kb DSL line, shouldn't really be taxing the NIC. If there's > anything else about the config you'd like to know, I'd be happy to > provide details. > > If you really think switching to a better ethernet card will help, I > have a 3C905B sitting here that I can try. It may. > >There's also > >the possibility that if you're using NAT you're using NATd which > >because of the way it works (userland process that must double copy > >all packets) you're not getting the best performance from that as > >well. > > Nope, ppp -nat, no natd. Same difference, ppp is implemented as a userland process, nearly the same amount of work must be done for either natd or ppp. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 22: 2:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by hub.freebsd.org (Postfix) with ESMTP id E4AF837B405 for ; Mon, 2 Jul 2001 22:02:28 -0700 (PDT) (envelope-from bjf@samurai.com) Received: from [192.168.1.34] ([65.92.109.138]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010703050228.UOTZ17517.tomts5-srv.bellnexxia.net@[192.168.1.34]>; Tue, 3 Jul 2001 01:02:28 -0400 Mime-Version: 1.0 X-Sender: bjf@mail.samurai.com Message-Id: In-Reply-To: <20010703004307.E2458@wjv.com> References: <20010703004307.E2458@wjv.com> Date: Tue, 3 Jul 2001 01:02:22 -0400 To: bv@wjv.com From: Bryan Fullerton Subject: Re: PPPoE latency Cc: net@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 12:43 AM -0400 7/3/01, Bill Vermillion wrote: >The only way to be sure it is OS related [and I suspect it is not] >is to take your machine to their location. DSL can vary in speed >from location to location. Ah - here I should mention that I had similar ping times with this same provider when I was on the other side of the city (moved in March). Before I moved, I was approximately 5 blocks from the CO. Not really sure where I am in relation to the CO now, but transfer speed (which I'm happy with) has been the max they provide over this link. >Since the first link to the DSL is not your system but the box >above it, I really suspect that is the problem. The pings that I provided were to the first hop, ie my gateway at the other end of the connection. It could be latency in my provider's network, I suppose, but seems unlikely it'd affect me in two locations and not my friend in a third (also downtown). But certainly possible. > BTW I am NOT using PPPoE but PPoA. So.. not actually doing packet encapsulation and authentication with FreeBSD PPP then? If so, then we're not comparing apples to apples. Thanks, Bryan -- Bryan Fullerton http://bryanfullerton.com/ Core Competence uunet.ca!gts!cspace!bjf Samurai Consulting Can you feel the Ohmu call? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 22:12: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts6-srv.bellnexxia.net (tomts6.bellnexxia.net [209.226.175.26]) by hub.freebsd.org (Postfix) with ESMTP id 241E137B410 for ; Mon, 2 Jul 2001 22:12:05 -0700 (PDT) (envelope-from bjf@samurai.com) Received: from [192.168.1.34] ([65.92.109.138]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010703051204.KCFI15384.tomts6-srv.bellnexxia.net@[192.168.1.34]>; Tue, 3 Jul 2001 01:12:04 -0400 Mime-Version: 1.0 X-Sender: bjf@mail.samurai.com (Unverified) Message-Id: In-Reply-To: <20010702235434.B84523@sneakerz.org> References: <20010702233606.A84523@sneakerz.org> <20010702235434.B84523@sneakerz.org> Date: Tue, 3 Jul 2001 01:11:49 -0400 To: Alfred Perlstein From: Bryan Fullerton Subject: Re: PPPoE latency Cc: net@freebsd.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 11:54 PM -0500 7/2/01, Alfred Perlstein wrote: > > If you really think switching to a better ethernet card will help, I > > have a 3C905B sitting here that I can try. > >It may. Ok, I'll try that tomorrow then. Perhaps the varying cruft levels in ed(4) vs xl(4), or ISA vs PCI architecture, will help. :) > > Nope, ppp -nat, no natd. > >Same difference, ppp is implemented as a userland process, nearly the >same amount of work must be done for either natd or ppp. Well, I certainly can't get around needing NAT. Would it really add that much overhead in processing? I only have three active machines on the private network, though I do have 10 port forwarding rules as well. ppp is a busy little process on this machine, but it's not eating that much CPU percentage wise (maybe 5-10% during peak bandwidth usage). root 115 0.0 0.9 2524 544 ?? Ss 24Jun01 228:03.06 /usr/sbin/ppp -quiet -background -nat hse I do download a bit. :) 03000 55837770 52756978271 allow tcp from any to any established Bryan -- Bryan Fullerton http://bryanfullerton.com/ Core Competence uunet.ca!gts!cspace!bjf Samurai Consulting Can you feel the Ohmu call? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 22:15:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id DE0A337B401 for ; Mon, 2 Jul 2001 22:15:34 -0700 (PDT) (envelope-from bright@sneakerz.org) Received: by sneakerz.org (Postfix, from userid 1092) id 80F645D010; Tue, 3 Jul 2001 00:15:34 -0500 (CDT) Date: Tue, 3 Jul 2001 00:15:34 -0500 From: Alfred Perlstein To: Bryan Fullerton Cc: net@freebsd.org Subject: Re: PPPoE latency Message-ID: <20010703001534.D84523@sneakerz.org> References: <20010702233606.A84523@sneakerz.org> <20010702235434.B84523@sneakerz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from bjf@samurai.com on Tue, Jul 03, 2001 at 01:11:49AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Bryan Fullerton [010703 00:12] wrote: > At 11:54 PM -0500 7/2/01, Alfred Perlstein wrote: > > > If you really think switching to a better ethernet card will help, I > > > have a 3C905B sitting here that I can try. > > > >It may. > > Ok, I'll try that tomorrow then. Perhaps the varying cruft levels in > ed(4) vs xl(4), or ISA vs PCI architecture, will help. :) A boatload. :) ISA is _really_ slow. :) > > > > Nope, ppp -nat, no natd. > > > >Same difference, ppp is implemented as a userland process, nearly the > >same amount of work must be done for either natd or ppp. > > Well, I certainly can't get around needing NAT. Would it really add > that much overhead in processing? I only have three active machines > on the private network, though I do have 10 port forwarding rules as > well. PPP runs as a userland process, with or without NAT it requires copying of data as well as system call overhead to process packets. Latency sucks, but as long as you're getting the just about the full bandwidth of your pipe, it shouldn't make much of a difference, unless you're a gamer that is, you're not a gamer are you? >;) -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 2 22:42:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by hub.freebsd.org (Postfix) with ESMTP id 990CF37B401 for ; Mon, 2 Jul 2001 22:42:38 -0700 (PDT) (envelope-from bjf@samurai.com) Received: from [192.168.1.34] ([65.92.109.138]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010703054237.KWTO216.tomts7-srv.bellnexxia.net@[192.168.1.34]>; Tue, 3 Jul 2001 01:42:37 -0400 Mime-Version: 1.0 X-Sender: bjf@mail.samurai.com Message-Id: In-Reply-To: <20010703001534.D84523@sneakerz.org> References: <20010702233606.A84523@sneakerz.org> <20010702235434.B84523@sneakerz.org> <20010703001534.D84523@sneakerz.org> Date: Tue, 3 Jul 2001 01:42:29 -0400 To: Alfred Perlstein From: Bryan Fullerton Subject: Re: PPPoE latency Cc: net@freebsd.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 12:15 AM -0500 7/3/01, Alfred Perlstein wrote: >* Bryan Fullerton [010703 00:12] wrote: > > Ok, I'll try that tomorrow then. Perhaps the varying cruft levels in >> ed(4) vs xl(4), or ISA vs PCI architecture, will help. :) > >A boatload. :) ISA is _really_ slow. :) Hmm, knew it was slow, didn't think it was _that_ slow. Ok, will try the 3com card tomorrow, let you know how that goes. >Latency sucks, but as long as you're getting the just about the >full bandwidth of your pipe, it shouldn't make much of a difference, I have no complaints on the bandwidth side, I can pretty much max out my link 7x24. And I do try to. :) >unless you're a gamer that is, you're not a gamer are you? >;) Only on weekends. If it's any consolation, our Quake3 server is a FreeBSD box. ;) Bryan -- Bryan Fullerton http://bryanfullerton.com/ Core Competence uunet.ca!gts!cspace!bjf Samurai Consulting Can you feel the Ohmu call? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 0:57:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 7CC1837B449 for ; Tue, 3 Jul 2001 00:57:44 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f637un710085; Tue, 3 Jul 2001 10:56:49 +0300 (EEST) (envelope-from ru) Date: Tue, 3 Jul 2001 10:56:49 +0300 From: Ruslan Ermilov To: Iasen Kostoff Cc: freebsd-net@FreeBSD.ORG Subject: Re: adding a route to host via interface Message-ID: <20010703105649.A6517@sunbay.com> Mail-Followup-To: Iasen Kostoff , freebsd-net@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tbyte@tbyte.org on Mon, Jul 02, 2001 at 05:40:07PM +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jul 02, 2001 at 05:40:07PM +0300, Iasen Kostoff wrote: > > Problem is that adding a route to host throw interface adds > inerface as gateway (iface's lladdr). And you should manualy change lladdr > of this route to the real lladdr. > > this is it: > > route add -host foo -iface bar > arp -s foo real_lladdr_of_foo > > Is that realy a problem or I'm missing something ? > Try this: route add -host foo -link bar:real_lladdr_of_foo -llinfo -interface Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 1: 9:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from gvr.gvr.org (gvr.gvr.org [212.61.40.17]) by hub.freebsd.org (Postfix) with ESMTP id 7F35E37B401 for ; Tue, 3 Jul 2001 01:09:19 -0700 (PDT) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 4C083584D; Tue, 3 Jul 2001 10:09:18 +0200 (CEST) Date: Tue, 3 Jul 2001 10:09:18 +0200 From: Guido van Rooij To: freebsd-net@freebsd.org Cc: Phil Regnauld Subject: 802.2/802.3 encapsulation of IP packets not supported? Message-ID: <20010703100918.A95483@gvr.gvr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a wireless basestation that translates ip packets using RC894 encapsulation into IEEE802.2/802.3 encapsulation (RFC1042). Yes..I think that is gross too, but nevertheless I;d like to get it to work. THe host requirements RFC states that a host SHOULD be able to receive RFC894 packets. Currently it seems that FreeBSD does not do that. Yes, there is the ef pseudo-interface but that has no code to handle 802.2/802.3 IP packets (or ARP packets). And besides, I think it should be handled transparently. Is there a way to configure netgraph to handle this correctly? If not, I'm going to implement it in ether_demux(). -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 1:53:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by hub.freebsd.org (Postfix) with ESMTP id A100737B401; Tue, 3 Jul 2001 01:53:43 -0700 (PDT) (envelope-from anders.lowinger@xelerated.com) Received: from xelerated.com (10.16.5.13 [10.16.5.13]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 31DSBYA9; Tue, 3 Jul 2001 10:53:35 +0200 Message-ID: <3B4188F8.5040202@xelerated.com> Date: Tue, 03 Jul 2001 10:57:28 +0200 From: Anders Lowinger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010628 X-Accept-Language: en-us MIME-Version: 1.0 To: Luigi Rizzo Cc: Jeffrey Hsu , Bakul Shah , freebsd-net@FreeBSD.ORG Subject: Re: fastforwarding? References: <200107022109.XAA38398@info.iet.unipi.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Another way to do it is to switch/route multiple packets per interrupt. This is a solution a large router vendor does... -Anders > one of them is the (relatively high) interrupt overhead, > as reported by many. There is a good description of the problem > in the Click's paper at http://www.pdos.lcs.mit.edu/click/ and > in the Mogul's paper referenced in there. > > In line with what is suggested above, reducing this overhead requires > a solution that involves some form of polling. This gives you > a lot of improvement in performance, maybe by a factor of 3 or so. > > The approach we are trying is based on some very simple modifications > to the interrupt dispatcher. Basically the idea is to run with > e.g. HZ=2000 or so, and disable interrupts on a line for the rest > of a tick after you get more than X interrupts per tick (with small > X). > > The system remains decently responsive, because you are re-enabling > ints at the next clock tick (in 500us or less), or when you enter > the idle loop; and when you happen to call ether_output() you have > a chance to poll the device. > > The advantage of this approach is that you don't have to implement > a real polling system (which can become expensive when the number > of cards in a box becomes large), and that modifications are > relatively small and, especially, device-independent. Hopefully > we will be able to post them soon, after a bit more experiments. > > After this change, using FASTFORWARDING seems to save > another 20-30% on the per-packet processing time. > > cheers > luigi > -----------------------------------+------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > Mobile +39-347-0373137 > -----------------------------------+------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 2: 1:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 1F44337B403; Tue, 3 Jul 2001 02:01:07 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id KAA43664; Tue, 3 Jul 2001 10:55:42 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200107030855.KAA43664@info.iet.unipi.it> Subject: Re: fastforwarding? In-Reply-To: <3B4188F8.5040202@xelerated.com> from Anders Lowinger at "Jul 3, 2001 10:57:28 am" To: Anders Lowinger Date: Tue, 3 Jul 2001 10:55:42 +0200 (CEST) Cc: Jeffrey Hsu , Bakul Shah , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Another way to do it is to switch/route multiple packets > per interrupt. This is a solution a large router vendor as long as you have hardware support for it... The problem is that most devices give you an interrupt when you get the first packet. If your CPU is fast, you are done before the next interrupt comes in from the same interface, and in the meantime you have wasted a lot of time. Some versions of the 21143 have a "interrupt mitigation" register which acts more or less as the VMIN/VTIME termios fields. But the 21143 is hard to find these days, and it is the only one i know with this feature. So in the end you need to resort to some form of polling (as below). cheers luigi > does... > > -Anders > > > one of them is the (relatively high) interrupt overhead, > > as reported by many. There is a good description of the problem > > in the Click's paper at http://www.pdos.lcs.mit.edu/click/ and > > in the Mogul's paper referenced in there. > > > > In line with what is suggested above, reducing this overhead requires > > a solution that involves some form of polling. This gives you > > a lot of improvement in performance, maybe by a factor of 3 or so. > > > > The approach we are trying is based on some very simple modifications > > to the interrupt dispatcher. Basically the idea is to run with > > e.g. HZ=2000 or so, and disable interrupts on a line for the rest > > of a tick after you get more than X interrupts per tick (with small > > X). > > > > The system remains decently responsive, because you are re-enabling > > ints at the next clock tick (in 500us or less), or when you enter > > the idle loop; and when you happen to call ether_output() you have > > a chance to poll the device. > > > > The advantage of this approach is that you don't have to implement > > a real polling system (which can become expensive when the number > > of cards in a box becomes large), and that modifications are > > relatively small and, especially, device-independent. Hopefully > > we will be able to post them soon, after a bit more experiments. > > > > After this change, using FASTFORWARDING seems to save > > another 20-30% on the per-packet processing time. > > > > cheers > > luigi > > -----------------------------------+------------------------------------- > > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > > Mobile +39-347-0373137 > > -----------------------------------+------------------------------------- > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 2:17:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by hub.freebsd.org (Postfix) with ESMTP id 0655D37B401 for ; Tue, 3 Jul 2001 02:17:34 -0700 (PDT) (envelope-from hsu@FreeBSD.org) Received: from FreeBSD.org ([63.193.112.125]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GFW00BTA4H5QP@mta5.snfc21.pbi.net> for freebsd-net@FreeBSD.ORG; Tue, 03 Jul 2001 02:17:30 -0700 (PDT) Date: Tue, 03 Jul 2001 02:17:19 -0700 From: Jeffrey Hsu Subject: Re: fastforwarding? In-reply-to: Message from Luigi Rizzo "of Tue, 03 Jul 2001 10:55:42 +0200." <200107030855.KAA43664@info.iet.unipi.it> To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Message-id: <0GFW00BTB4H5QP@mta5.snfc21.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.1.1 10/15/1999 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Some versions of the 21143 have a "interrupt mitigation" register > which acts more or less as the VMIN/VTIME termios fields. > But the 21143 is hard to find these days, and it is the > only one i know with this feature. Both the Alteon Tigon II (if_ti) and the National Semiconductor (if_nge) gigabit NICs have some form of interrupt coalescing or interrupt moderation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 2:42:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 59A7737B405; Tue, 3 Jul 2001 02:42:16 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id LAA44045; Tue, 3 Jul 2001 11:37:00 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200107030937.LAA44045@info.iet.unipi.it> Subject: Re: fastforwarding? In-Reply-To: <0GFW00BTB4H5QP@mta5.snfc21.pbi.net> from Jeffrey Hsu at "Jul 3, 2001 02:17:19 am" To: Jeffrey Hsu Date: Tue, 3 Jul 2001 11:37:00 +0200 (CEST) Cc: freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Some versions of the 21143 have a "interrupt mitigation" register > > which acts more or less as the VMIN/VTIME termios fields. > > But the 21143 is hard to find these days, and it is the > > only one i know with this feature. > Both the Alteon Tigon II (if_ti) and the National Semiconductor (if_nge) > gigabit NICs have some form of interrupt coalescing or interrupt moderation. you are right, i meant among 100Mbit chips... luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 4:17:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from paprika.michvhf.com (adsl-pool24-253.detroit.mi.ameritech.net [64.108.57.253]) by hub.freebsd.org (Postfix) with SMTP id 0889E37B401 for ; Tue, 3 Jul 2001 04:17:15 -0700 (PDT) (envelope-from vev@michvhf.com) Received: (qmail 57010 invoked by uid 1001); 3 Jul 2001 11:17:15 -0000 Date: Tue, 3 Jul 2001 07:17:15 -0400 (EDT) From: Vince Vielhaber To: Bryan Fullerton Cc: Subject: Re: PPPoE latency In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 3 Jul 2001, Bryan Fullerton wrote: > >Since the first link to the DSL is not your system but the box > >above it, I really suspect that is the problem. > > The pings that I provided were to the first hop, ie my gateway at the > other end of the connection. It could be latency in my provider's > network, I suppose, but seems unlikely it'd affect me in two > locations and not my friend in a third (also downtown). But certainly > possible. > > > BTW I am NOT using PPPoE but PPoA. > > So.. not actually doing packet encapsulation and authentication with > FreeBSD PPP then? If so, then we're not comparing apples to apples. Here's apples to apples. PPPoE, nat, webserver running about 2000 hits/day, 768/128 Ameritech DSL - dynamic IP. The computer is a 233 PII with 64MB ram and FreeBSD 4.1.1 (with the tcpmssd patch to ppp) but the network cards are both CNET 100Base-TX cards. The below ping times are pretty much normal, even tho I'm in the middle of a file transfer. round-trip min/avg/max/stddev = 24.203/28.876/35.084/4.076 ms One thing you might want to try is bringing their router to your place and see what happens. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ========================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 4:30:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from shadow.otel.net (JuDiCaToR.OTEL.net [212.36.9.113]) by hub.freebsd.org (Postfix) with ESMTP id 0070E37B403; Tue, 3 Jul 2001 04:30:51 -0700 (PDT) (envelope-from tbyte@tbyte.org) Received: from localhost (localhost [127.0.0.1]) by shadow.otel.net (8.11.4/8.11.1) with ESMTP id f63BUmK35585; Tue, 3 Jul 2001 14:30:49 +0300 (EEST) (envelope-from tbyte@tbyte.org) Date: Tue, 3 Jul 2001 14:30:48 +0300 (EEST) From: Iasen Kostoff X-Sender: tbyte@shadow.otel.net To: Ruslan Ermilov Cc: freebsd-net@FreeBSD.ORG Subject: Re: adding a route to host via interface In-Reply-To: <20010703105649.A6517@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 3 Jul 2001, Ruslan Ermilov wrote: > On Mon, Jul 02, 2001 at 05:40:07PM +0300, Iasen Kostoff wrote: > > > > Problem is that adding a route to host throw interface adds > > inerface as gateway (iface's lladdr). And you should manualy change lladdr > > of this route to the real lladdr. > > > > this is it: > > > > route add -host foo -iface bar > > arp -s foo real_lladdr_of_foo > > > > Is that realy a problem or I'm missing something ? > > > Try this: > > route add -host foo -link bar:real_lladdr_of_foo -llinfo -interface > But if I don't know the lladdr - because now I should use tcpsump(1) with -i iface -e to see the lladdr of the client and when they change their GW computer or its Lan card I should do that again (and if am not around they don't have inet ofcourse) but if they are connected on cisco router that do not hapen because I'm not routing to lladdr but throw iface. Can that be fixed some how ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 5: 5:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 9055037B403 for ; Tue, 3 Jul 2001 05:05:22 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f63C4gw42133; Tue, 3 Jul 2001 15:04:42 +0300 (EEST) (envelope-from ru) Date: Tue, 3 Jul 2001 15:04:41 +0300 From: Ruslan Ermilov To: Iasen Kostoff Cc: freebsd-net@FreeBSD.ORG Subject: Re: adding a route to host via interface Message-ID: <20010703150441.B39090@sunbay.com> Mail-Followup-To: Iasen Kostoff , freebsd-net@FreeBSD.ORG References: <20010703105649.A6517@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tbyte@tbyte.org on Tue, Jul 03, 2001 at 02:30:48PM +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 03, 2001 at 02:30:48PM +0300, Iasen Kostoff wrote: > > > On Tue, 3 Jul 2001, Ruslan Ermilov wrote: > > > On Mon, Jul 02, 2001 at 05:40:07PM +0300, Iasen Kostoff wrote: > > > > > > Problem is that adding a route to host throw interface adds > > > inerface as gateway (iface's lladdr). And you should manualy change lladdr > > > of this route to the real lladdr. > > > > > > this is it: > > > > > > route add -host foo -iface bar > > > arp -s foo real_lladdr_of_foo > > > > > > Is that realy a problem or I'm missing something ? > > > > > Try this: > > > > route add -host foo -link bar:real_lladdr_of_foo -llinfo -interface > > > But if I don't know the lladdr - because now I should use tcpsump(1) with > -i iface -e to see the lladdr of the client and when they change their GW > computer or its Lan card I should do that again (and if am not around they > don't have inet ofcourse) but if they are connected on cisco router that > do not hapen because I'm not routing to lladdr but throw iface. > > Can that be fixed some how ? > I apparently lost the context here. What are you trying to do? You want the host ``foo'' to be resolved through ARP? If that is the case, this is somewhat tricky, but still possible: route add foo/32 -iface bar -cloning Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 5:34:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from shadow.otel.net (JuDiCaToR.OTEL.net [212.36.9.113]) by hub.freebsd.org (Postfix) with ESMTP id 7AF6637B401; Tue, 3 Jul 2001 05:34:16 -0700 (PDT) (envelope-from tbyte@tbyte.org) Received: from localhost (localhost [127.0.0.1]) by shadow.otel.net (8.11.4/8.11.1) with ESMTP id f63CYEK35683; Tue, 3 Jul 2001 15:34:15 +0300 (EEST) (envelope-from tbyte@tbyte.org) Date: Tue, 3 Jul 2001 15:34:14 +0300 (EEST) From: Iasen Kostoff X-Sender: tbyte@shadow.otel.net To: Ruslan Ermilov Cc: freebsd-net@FreeBSD.ORG Subject: Re: adding a route to host via interface In-Reply-To: <20010703150441.B39090@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 3 Jul 2001, Ruslan Ermilov wrote: > On Tue, Jul 03, 2001 at 02:30:48PM +0300, Iasen Kostoff wrote: > > > > > > On Tue, 3 Jul 2001, Ruslan Ermilov wrote: > > > > > On Mon, Jul 02, 2001 at 05:40:07PM +0300, Iasen Kostoff wrote: > > > > > > > > Problem is that adding a route to host throw interface adds > > > > inerface as gateway (iface's lladdr). And you should manualy change lladdr > > > > of this route to the real lladdr. > > > > > > > > this is it: > > > > > > > > route add -host foo -iface bar > > > > arp -s foo real_lladdr_of_foo > > > > > > > > Is that realy a problem or I'm missing something ? > > > > > > > Try this: > > > > > > route add -host foo -link bar:real_lladdr_of_foo -llinfo -interface > > > > > But if I don't know the lladdr - because now I should use tcpsump(1) with > > -i iface -e to see the lladdr of the client and when they change their GW > > computer or its Lan card I should do that again (and if am not around they > > don't have inet ofcourse) but if they are connected on cisco router that > > do not hapen because I'm not routing to lladdr but throw iface. > > > > Can that be fixed some how ? > > > I apparently lost the context here. What are you trying to do? > You want the host ``foo'' to be resolved through ARP? If that > is the case, this is somewhat tricky, but still possible: > > route add foo/32 -iface bar -cloning > > I tried - route add foo -iface bar -cloning and it didin't work ofcourse :). I think route(8) or /sys/net/route.c should reject that kind of route I tried to set or convert it to -net route - foo/32(I think the second way is better, what you think ?). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 6:15:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from bilver.wjv.com (dhcp-1-86.n01.orldfl01.us.ra.verio.net [157.238.210.86]) by hub.freebsd.org (Postfix) with ESMTP id C6BBE37B406 for ; Tue, 3 Jul 2001 06:15:20 -0700 (PDT) (envelope-from bill@bilver.wjv.com) Received: (from bill@localhost) by bilver.wjv.com (8.11.1/8.11.1) id f63DF8L06265; Tue, 3 Jul 2001 09:15:08 -0400 (EDT) (envelope-from bill) Date: Tue, 3 Jul 2001 09:14:56 -0400 From: Bill Vermillion To: Bryan Fullerton Cc: bv@wjv.com, net@FreeBSD.ORG Subject: Re: PPPoE latency Message-ID: <20010703091456.E5516@wjv.com> Reply-To: bv@wjv.com References: <20010703004307.E2458@wjv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bjf@samurai.com on Tue, Jul 03, 2001 at 01:02:22AM -0400 Organization: W.J.Vermillion / Orlando - Winter Park Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 03, 2001 at 01:02:22AM -0400, Bryan Fullerton thus sprach: > At 12:43 AM -0400 7/3/01, Bill Vermillion wrote: > >The only way to be sure it is OS related [and I suspect it is not] > >is to take your machine to their location. DSL can vary in speed > >from location to location. > Ah - here I should mention that I had similar ping times with this > same provider when I was on the other side of the city (moved in > March). You neglected to say that. .... > The pings that I provided were to the first hop, ie my gateway at the > other end of the connection. It could be latency in my provider's > network, I suppose, but seems unlikely it'd affect me in two > locations and not my friend in a third (also downtown). But certainly > possible. Well in the above instance I am the provider and I get different ping times at the different locations. [Just bringing this all up and only got one running late Wednesay night]. If you provider is not the lowest link in the chain, eg the telco providing service to your location, you could see all sorts of speed differernces. And customers we bring up could come back over a pipe inside our DS3 to Bell or the ATM link to Sprint. I saw racks across the room from Telocity and I don't know whether they were reselling or had their own equipment in the COs and then back-hauling to the facility I have my rack space in. [big place - in the area in back where I only get to go when being walked through by a tech en route to somewhere else] I saw banks of Ascend/Lucent Maxes - and a rough guess is 30-35K worth of digital modems. I believe 15K of those was being routed from another city back to the central transport. I think about 1/2 of those [at least 15,000] are for AOL. > > BTW I am NOT using PPPoE but PPoA. > So.. not actually doing packet encapsulation and authentication with > FreeBSD PPP then? If so, then we're not comparing apples to apples. But I was tyring to point out - and not very well at that - that just being from the same provider doesn't mean all that much. Before Northpoint folded a lot of the local ISP's were just reselling their services. One ISP also dropped their own DSLAM into a few large business type locations and back-hauled to their central site - and they only have DS3 to the outside world and at times those get overloaded. So things could vary greatly with the same provider at different location points depending on how they link back to their connects. -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 6:24:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by hub.freebsd.org (Postfix) with ESMTP id B22BA37B401 for ; Tue, 3 Jul 2001 06:24:10 -0700 (PDT) (envelope-from mcambria@avaya.com) Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Jul 2001 09:24:07 -0400 Message-ID: <3A6D367EA1EFD4118C9B00A0C9DD99D7064F5F@rerun.lucentctc.com> From: "Cambria, Mike" To: 'Jun-ichiro itojun Hagino' , "Cambria, Mike" , snap-users@kame.net Cc: "'freebsd-net@freebsd.org'" Subject: RE: (KAME-snap 5064) Can I define a SPD per interface? Date: Tue, 3 Jul 2001 09:23:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >I can only find a way to define a global SPD using setkey. Is it possible >to define an (IPv4) SPD on a per interface basis using KAME / FreeBSD4? >If not, are there any plans to add this in the future? >Is there any reason one wouldn't want to have this? no. do you want SPD per interface, or IPsec SPI per interface? anyway, IPsec architecture is not interface-oriented (it lives on top of IP, and the information on interface is already gone) so your suggestion does not fit nicely to the current architecture... I read RFC2401 (pg 13) differently, which is why I asked. "Each interface for which IPsec is enabled requires nominally separate inbound vs. outbound databases (SAD and SPD)" and further down on pg 13 "...SG had multiple external interfaces, it might be necessary to have separate SAD and SPD pairs for each interface." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 6:29:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 81F3837B405 for ; Tue, 3 Jul 2001 06:29:20 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f63DPuu52909; Tue, 3 Jul 2001 16:25:56 +0300 (EEST) (envelope-from ru) Date: Tue, 3 Jul 2001 16:25:56 +0300 From: Ruslan Ermilov To: Iasen Kostoff Cc: freebsd-net@FreeBSD.ORG Subject: Re: adding a route to host via interface Message-ID: <20010703162556.E39090@sunbay.com> Mail-Followup-To: Iasen Kostoff , freebsd-net@FreeBSD.ORG References: <20010703150441.B39090@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tbyte@tbyte.org on Tue, Jul 03, 2001 at 03:34:14PM +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 03, 2001 at 03:34:14PM +0300, Iasen Kostoff wrote: > > > On Tue, 3 Jul 2001, Ruslan Ermilov wrote: > > > On Tue, Jul 03, 2001 at 02:30:48PM +0300, Iasen Kostoff wrote: > > > > > > > > > On Tue, 3 Jul 2001, Ruslan Ermilov wrote: > > > > > > > On Mon, Jul 02, 2001 at 05:40:07PM +0300, Iasen Kostoff wrote: > > > > > > > > > > Problem is that adding a route to host throw interface adds > > > > > inerface as gateway (iface's lladdr). And you should manualy change lladdr > > > > > of this route to the real lladdr. > > > > > > > > > > this is it: > > > > > > > > > > route add -host foo -iface bar > > > > > arp -s foo real_lladdr_of_foo > > > > > > > > > > Is that realy a problem or I'm missing something ? > > > > > > > > > Try this: > > > > > > > > route add -host foo -link bar:real_lladdr_of_foo -llinfo -interface > > > > > > > But if I don't know the lladdr - because now I should use tcpsump(1) with > > > -i iface -e to see the lladdr of the client and when they change their GW > > > computer or its Lan card I should do that again (and if am not around they > > > don't have inet ofcourse) but if they are connected on cisco router that > > > do not hapen because I'm not routing to lladdr but throw iface. > > > > > > Can that be fixed some how ? > > > > > I apparently lost the context here. What are you trying to do? > > You want the host ``foo'' to be resolved through ARP? If that > > is the case, this is somewhat tricky, but still possible: > > > > route add foo/32 -iface bar -cloning > > > > > I tried - route add foo -iface bar -cloning and it didin't work ofcourse :). > Yup, should be ``arp: couldn't allocate llinfo for rt''. > I think route(8) or /sys/net/route.c should reject that kind of route. > I tried to set or convert it to -net route - foo/32(I think the second way is > better, what you think ?). > You can't change host route to network route, or vise versa; destination is the Patricia's tree key, and it can't be changed. The only possible way is like I suggested: ``route add foo/32 -iface bar -cloning''. You still did not tell me what are you trying to do. :-) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 6:46:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by hub.freebsd.org (Postfix) with ESMTP id AF02237B401; Tue, 3 Jul 2001 06:46:44 -0700 (PDT) (envelope-from anders.lowinger@xelerated.com) Received: from xelerated.com (XEL-ANDERSLO01 [10.0.9.55]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 31DSB5TH; Tue, 3 Jul 2001 15:46:46 +0200 Message-ID: <3B41CC2C.6050607@xelerated.com> Date: Tue, 03 Jul 2001 15:44:12 +0200 From: Anders Lowinger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010628 X-Accept-Language: en-us MIME-Version: 1.0 To: Luigi Rizzo Cc: Jeffrey Hsu , freebsd-net@FreeBSD.org Subject: Re: fastforwarding? References: <200107030937.LAA44045@info.iet.unipi.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > you are right, i meant among 100Mbit chips... Can't we just mask the IRQ while in the IRQ handler so we ignore more IRQ's? Then before we leave the IRQ handler we check if there is any more packets via polling. The number of packets that should be routed needs to be tunable, as well as an upper limit on how many IRQ's there may be per second to allow other processes to run. Of course that don't work that well if it is a shared IRQ. I would suggest that all NIC's in which you should route between should have the same IRQ to get some fairness. -Anders To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 6:54:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from shadow.otel.net (JuDiCaToR.OTEL.net [212.36.9.113]) by hub.freebsd.org (Postfix) with ESMTP id 51D5E37B401; Tue, 3 Jul 2001 06:54:31 -0700 (PDT) (envelope-from tbyte@tbyte.org) Received: from localhost (localhost [127.0.0.1]) by shadow.otel.net (8.11.4/8.11.1) with ESMTP id f63DsTK35863; Tue, 3 Jul 2001 16:54:30 +0300 (EEST) (envelope-from tbyte@tbyte.org) Date: Tue, 3 Jul 2001 16:54:29 +0300 (EEST) From: Iasen Kostoff X-Sender: tbyte@shadow.otel.net To: Ruslan Ermilov Cc: freebsd-net@FreeBSD.ORG Subject: Re: adding a route to host via interface In-Reply-To: <20010703162556.E39090@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 3 Jul 2001, Ruslan Ermilov wrote: > On Tue, Jul 03, 2001 at 03:34:14PM +0300, Iasen Kostoff wrote: > > > > > > On Tue, 3 Jul 2001, Ruslan Ermilov wrote: > > > > > On Tue, Jul 03, 2001 at 02:30:48PM +0300, Iasen Kostoff wrote: > > > > > > > > > > > > On Tue, 3 Jul 2001, Ruslan Ermilov wrote: > > > > > > > > > On Mon, Jul 02, 2001 at 05:40:07PM +0300, Iasen Kostoff wrote: > > > > > > > > > > > > Problem is that adding a route to host throw interface adds > > > > > > inerface as gateway (iface's lladdr). And you should manualy change lladdr > > > > > > of this route to the real lladdr. > > > > > > > > > > > > this is it: > > > > > > > > > > > > route add -host foo -iface bar > > > > > > arp -s foo real_lladdr_of_foo > > > > > > > > > > > > Is that realy a problem or I'm missing something ? > > > > > > > > > > > Try this: > > > > > > > > > > route add -host foo -link bar:real_lladdr_of_foo -llinfo -interface > > > > > > > > > But if I don't know the lladdr - because now I should use tcpsump(1) with > > > > -i iface -e to see the lladdr of the client and when they change their GW > > > > computer or its Lan card I should do that again (and if am not around they > > > > don't have inet ofcourse) but if they are connected on cisco router that > > > > do not hapen because I'm not routing to lladdr but throw iface. > > > > > > > > Can that be fixed some how ? > > > > > > > I apparently lost the context here. What are you trying to do? > > > You want the host ``foo'' to be resolved through ARP? If that > > > is the case, this is somewhat tricky, but still possible: > > > > > > route add foo/32 -iface bar -cloning > > > > > > > > I tried - route add foo -iface bar -cloning and it didin't work ofcourse :). > > > Yup, should be ``arp: couldn't allocate llinfo for rt''. > > > I think route(8) or /sys/net/route.c should reject that kind of route. > > I tried to set or convert it to -net route - foo/32(I think the second way is > > better, what you think ?). > > > You can't change host route to network route, or vise versa; destination > is the Patricia's tree key, and it can't be changed. The only possible > way is like I suggested: ``route add foo/32 -iface bar -cloning''. Yes I know, but ``route add foo -iface bar -cloning`` is meanless, I think, because host route could not be cloned and I kernel should auto set foo to foo/32 because of meanlessness of -host foo. And is route add -host foo -iface bar (without -cloning) could be used for something ? > > > You still did not tell me what are you trying to do. :-) > > I'm trying to make routing on FreeBSD as easier and streight forward as it is in cisco's routers(and may be better). :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 7: 2:13 2001 Delivered-To: freebsd-net@hub.freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A67E237B401; Tue, 3 Jul 2001 07:02:09 -0700 (PDT) (envelope-from ru@FreeBSD.org) Received: (from ru@localhost) by freefall.freebsd.org (8.11.3/8.11.3) id f63E29N95473; Tue, 3 Jul 2001 07:02:09 -0700 (PDT) (envelope-from ru) Date: Tue, 3 Jul 2001 07:02:09 -0700 (PDT) From: Message-Id: <200107031402.f63E29N95473@freefall.freebsd.org> To: ru@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/20600: getpeereid obtains credentials from connect() Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Synopsis: getpeereid obtains credentials from connect() Responsible-Changed-From-To: freebsd-net->freebsd-bugs Responsible-Changed-By: ru Responsible-Changed-When: Tue Jul 3 07:00:17 PDT 2001 Responsible-Changed-Why: Experiment has failed. peter's script can't handle this. It skips ^(freebsd|gnats) responsibles. Except a few special ones like freebsd-bugs, freebsd-doc, and freebsd-ports. http://www.FreeBSD.org/cgi/query-pr.cgi?pr=20600 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 8:11:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 92A8637B401 for ; Tue, 3 Jul 2001 08:11:19 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f63FAWW67715; Tue, 3 Jul 2001 18:10:32 +0300 (EEST) (envelope-from ru) Date: Tue, 3 Jul 2001 18:10:32 +0300 From: Ruslan Ermilov To: Iasen Kostoff Cc: freebsd-net@FreeBSD.ORG Subject: Re: adding a route to host via interface Message-ID: <20010703181032.A65571@sunbay.com> Mail-Followup-To: Iasen Kostoff , freebsd-net@FreeBSD.ORG References: <20010703162556.E39090@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tbyte@tbyte.org on Tue, Jul 03, 2001 at 04:54:29PM +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jul 03, 2001 at 04:54:29PM +0300, Iasen Kostoff wrote: > [...] > > You can't change host route to network route, or vise versa; destination > > is the Patricia's tree key, and it can't be changed. The only possible > > way is like I suggested: ``route add foo/32 -iface bar -cloning''. > > Yes I know, but ``route add foo -iface bar -cloning`` is meanless, I > think, because host route could not be cloned and I kernel should auto set > foo to foo/32 because of meanlessness of -host foo. > Could you please try the attached patch? It disallows cloning for host entries. > And is route add -host > foo -iface bar (without -cloning) could be used for something ? > Yes, it is currently used for proxy ARP type 1 entries: # arp -s 192.168.4.200 1:2:3:4:5:6 pub # netstat -rn | grep 192.168.4.200 192.168.4.200/32 1:2:3:4:5:6 ULS2c 0 0 rl0 The purpose of /32 here is to allow the call to rtalloc1() in arplookup() to match this route even if the SIN_PROXY flag (proxy ARP type 2; aka published (proxy only)) is set in the sin_other member of the sockaddr_inarp structure. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: route.c =================================================================== RCS file: /home/ncvs/src/sys/net/route.c,v retrieving revision 1.59.2.2 diff -u -p -r1.59.2.2 route.c --- route.c 2001/05/14 08:23:48 1.59.2.2 +++ route.c 2001/07/03 15:08:41 @@ -476,10 +476,12 @@ rtrequest(req, dst, gateway, netmask, fl senderr(ESRCH); /* * If we are adding a host route then we don't want to put - * a netmask in the tree + * a netmask in the tree, not do we want to clone it. */ - if (flags & RTF_HOST) + if (flags & RTF_HOST) { netmask = 0; + flags &= ~(RTF_CLONING | RTF_PRCLONING); + } switch (req) { case RTM_DELETE: /* --Q68bSM7Ycu6FN28Q-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 8:51:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from fubar.net-ninja.com (cc260960-a.mdlvly1.tn.home.com [65.14.125.177]) by hub.freebsd.org (Postfix) with ESMTP id ACDB537B401 for ; Tue, 3 Jul 2001 08:51:26 -0700 (PDT) (envelope-from sz@cdc.net) Received: by fubar.net-ninja.com (Postfix, from userid 100) id A83AA88A63; Tue, 3 Jul 2001 11:51:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by fubar.net-ninja.com (Postfix) with ESMTP id 89C6F43763 for ; Tue, 3 Jul 2001 11:51:02 -0400 (EDT) Date: Tue, 3 Jul 2001 11:51:02 -0400 (EDT) From: Eric Parker X-X-Sender: To: Subject: PCMCIA Card in FreeBSD 4.3 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm having some problems with a couple of PCMCIA ethernet card in FreeBSD 4.3. First, a quick history of what I have done. I have 2 Vaio laptop computers, a Cisco Aironet 340 series wireless card, and a LinkSys 10/100 PC Card (PCM100). I tested the LinkSys card in my laptop when I first got it and it worked flawlessly (pccard.conf already has 0x80000 in it), then I started working on the wireless card. I now have the wireless card working perfectly, but when I try to get the LinkSys card to work now, funky things start to happen. If I just boot straight up with the LinkSys card, I get the following error message: ed1: device timeout But, if I remove it, put in the wireless card, then put back in the LinkSys card, it works fine. It's seems like some odd IRQ issue that the wireless card fixes. Now for the weird part. I have tried to get the wireless card working on another laptop running the same FreeBSD install and get the same error message as with the LinkSys on mine: device timeout. This leads me to believe I am missing something during the setup somewhere. I have racked my brain trying to figure out what I am missing, but I can't seem to figure it out. Help! :) ------ Eric Parker Network Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 8:52:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id 844CC37B403; Tue, 3 Jul 2001 08:52:48 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost.softweyr.com ([127.0.0.1] helo=softweyr.com ident=1649b7c0712cdb73cae8b259f0fd5ed8) by softweyr.com with esmtp (Exim 3.16 #1) id 15HSYG-0000mZ-00; Tue, 03 Jul 2001 09:57:24 -0600 Message-ID: <3B41EB64.3B753DDE@softweyr.com> Date: Tue, 03 Jul 2001 09:57:24 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Bakul Shah Cc: Ruslan Ermilov , Deepak Jain , net@FreeBSD.org Subject: Re: fastforwarding? References: <200107021954.PAA25927@goliath.cnchost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bakul Shah wrote: > > > > IMHO you are better off using a recent route lookup algorithm > > > than messing with caches. The PATRICIA tree algorithm is > > > what 33 years old now? > > > > Not true. Any routing algorithm takes longer because they are by > > definition a "fuzzy match." The fastforward algorithm is not, it > > By defn the best match is the longest prefix match. > > > is a simple destination address lookup; the cached route is either > > there or it is not. Fast hashing algorithms are quite effective > > in locating the route if it has been cached. Routing switches > > A simple hashtable will be faster but not significantly so > compared to some of the recent trie algorithms. The implementation I'm most familiar with uses a hardware has (Content Addressable Memory) that always completes the lookup in one clock cycle, so my experience is slightly different. ;^) > And both are > faster than the radix tree used in *BSD. With a trie you can > do just a single route lookup (currently an input packet's > dest. ip addr. is matched against the list of broadcast > addresses for the machine -- this check is free with a trie). So this would be applicable to the fastforwarding code, which has a lot of other advantages besides avoiding the route lookup. In particular, it cuts out a lot of the ip forwarding code path, that's why it's called FAST forwarding. > BTW, the current fastforward code doesn't handle route > add/delete and hence has the same bug I mentioned in my > previous msg. > > > usually speed up the lookup even further by using Content Addressable > > Memory to map the destination address to a cached route or interface > > pointer; it would be interesting to experiment with something like > > that in FreeBSD. > > Even if it takes 0 ns to do a route lookup, a stock freebsd > system can't do more than 20K ~ 100K pkts/second due to many > bottlenecks. In a hardware accelrated router one can easily > do 10M route lookups *without* using an expensive & power > hungry fancy CAM. But they may be worth it if you want to > route 1M+ pkts/second *and* you want to do packet matching. Such as a routing switch would do. Plus you have the added advantage that the route caches scale well to multiple indepdendant "smart" interfaces, which is not likely to be added to a generic FreeBSD system. Except there are all these PCI based smart network cards popping up on the market these days, and it would be possible to scale the fastforwarding code directly onto the network cards... -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 9: 6:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id 45DC837B401 for ; Tue, 3 Jul 2001 09:06:39 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost.softweyr.com ([127.0.0.1] helo=softweyr.com ident=b7dcfccaecff6acf01d70debe51a7786) by softweyr.com with esmtp (Exim 3.16 #1) id 15HSlj-0000nU-00; Tue, 03 Jul 2001 10:11:19 -0600 Message-ID: <3B41EEA7.81434ED5@softweyr.com> Date: Tue, 03 Jul 2001 10:11:19 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Brooks Davis Cc: Vladimir Terziev , freebsd-net@FreeBSD.ORG Subject: Re: Cisco Aironet 340 Series References: <200107020837.LAA37120@star.rila.bg> <20010702100942.B10075@Odin.AC.HMC.Edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Brooks Davis wrote: > > On Mon, Jul 02, 2001 at 11:37:16AM +0300, Vladimir Terziev wrote: > > I'm planning to setup a Intranet network, based on wireless connections. I > > think to use Cisco Aironet 340 Series cards for client access. > > > > Is FreeBSD supports Cisco Aironet 340 Series cards ? > > They work quite well. Just be sure to use a recent version of FreeBSD > as there have been issues in older versions. My gateway to the internet is an Aironet 340 with PCI interface and a 24db "fruit basket" antenna. I'm hitting an omni antenna on a large cement silo about 3.5 miles/5 km away without an amplifier. Typical throughput is about 1 mpbs. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 9:18:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id F384837B407 for ; Tue, 3 Jul 2001 09:18:03 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA18036; Tue, 3 Jul 2001 10:41:56 -0700 (PDT) Message-ID: <3B41EB3C.EF185F3F@elischer.org> Date: Tue, 03 Jul 2001 08:56:44 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Bryan Fullerton Cc: net@freebsd.org Subject: Re: PPPoE latency References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bryan Fullerton wrote: > > Howdy, > > I've been wondering why the latency is higher in FreeBSD's PPPoE > implementation. From what I've seen, ping times via my gateway box > are significantly higher than what friends are seeing with dedicated > router boxes (ie Linksys) on the same DSL provider. > > Here's what I'm seeing to the other end of my connection, no other > meaningful traffic going on: > > --- 65.92.109.1 ping statistics --- > 100 packets transmitted, 100 packets received, 0% packet loss > round-trip min/avg/max/stddev = 53.982/65.063/102.373/7.478 ms > > Here's a ping on my friend's machine (Mac ping, sorry for lack of precision): > > Packets out/in/bad/%loss = 64/64/0/0.0 > Round Trip Time (ms) min/avg/max = 14/24/59 > > My box should be fine cpu-wise, it's a Celeron/300, and isn't doing > anything else. The card PPPoE is running over is an ISA 10BaseT > D-Link card using the ed(4) driver, if that makes any difference. I > track STABLE with this box, it's currently at: > > FreeBSD katana.apt.samurai.com 4.3-STABLE FreeBSD 4.3-STABLE #13: Sun > Jun 24 01:43:39 EDT 2001 > > Any thoughts? I can live with this, the connection is rock solid and > has been for over a year now, just curious as to why. Apologies if > this has come up before, I searched the list archives and the bug > list. you may be a good test case for us.. we have heard of this negraph latency for a while but have never had a good test case.. if I send you test code can you run it for me? > > Thanks, > > Bryan > -- > Bryan Fullerton http://bryanfullerton.com/ > Core Competence uunet.ca!gts!cspace!bjf > Samurai Consulting > Can you feel the Ohmu call? > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 9:58:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.chem.msu.ru (mail.chem.msu.ru [195.208.208.19]) by hub.freebsd.org (Postfix) with ESMTP id ED45637B403; Tue, 3 Jul 2001 09:58:20 -0700 (PDT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su ([158.250.32.97]) by mail.chem.msu.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NHPRVMYP; Tue, 3 Jul 2001 20:52:09 +0400 Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id f63GvoN31444; Tue, 3 Jul 2001 20:57:50 +0400 (MSD) (envelope-from yar) Date: Tue, 3 Jul 2001 20:57:50 +0400 From: Yar Tikhiy To: audit@freebsd.org, net@freebsd.org Subject: ipfw ipprecedence option Message-ID: <20010703205750.A29370@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi there, Current ipfw implementation doesn't allow for matching IP packets by their precedence field while there exist real-life cases when it would be a rather useful feature. Please review the following patches against -current that add the feature: ipfw.diff for the utility, ip_fw.diff for kernel. As for me, they worked without any problems. -- Yar --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipfw.diff" diff -u --exclude=*orig /usr/src/sbin/ipfw/ipfw.8 ipfw/ipfw.8 --- /usr/src/sbin/ipfw/ipfw.8 Thu Jun 7 00:56:56 2001 +++ ipfw/ipfw.8 Sun Jul 1 15:03:47 2001 @@ -667,6 +667,9 @@ .It Cm ipversion Ar ver Match if the IP header version is .Ar ver . +.It Cm ipprecedence Ar precedence +Match if the numeric value of IP datagram's precedence is equal to +.Ar precedence . .It Cm iptos Ar spec Match if the IP header contains the comma separated list of service types specified in diff -u --exclude=*orig /usr/src/sbin/ipfw/ipfw.c ipfw/ipfw.c --- /usr/src/sbin/ipfw/ipfw.c Tue Jun 5 03:56:26 2001 +++ ipfw/ipfw.c Sun Jul 1 15:34:42 2001 @@ -432,6 +432,8 @@ printf(" iplen %u", chain->fw_iplen); if (chain->fw_ipflg & IP_FW_IF_IPID) printf(" ipid %#x", chain->fw_ipid); + if (chain->fw_ipflg & IP_FW_IF_IPPRE) + printf(" ipprecedence %u", (chain->fw_iptos & 0xe0) >> 5); if (chain->fw_ipflg & IP_FW_IF_IPTOS) { int _opt_printed = 0; @@ -909,6 +911,7 @@ " ipoptions [!]{ssrr|lsrr|rr|ts}, ...\n" " iplen {length}\n" " ipid {identification number}\n" +" ipprecedence {precedence}\n" " iptos [!]{lowdelay|throughput|reliability|mincost|congestion}, ...\n" " ipttl {time to live}\n" " ipversion {version number}\n" @@ -2058,6 +2061,24 @@ show_usage("argument to ipid out of range"); rule.fw_ipflg |= IP_FW_IF_IPID; rule.fw_ipid = (u_short)ipid; + av++; ac--; + } else if (!strncmp(*av, "ipprecedence", strlen(*av))) { + u_long ippre; + char *c; + + av++; ac--; + if (!ac) + show_usage("missing argument" + " for ``ipprecedence''"); + ippre = strtoul(*av, &c, 0); + if (*c != '\0') + show_usage("argument to ipprecedence" + " must be numeric"); + if (ippre > 7) + show_usage("argument to ipprecedence" + " out of range"); + rule.fw_ipflg |= IP_FW_IF_IPPRE; + rule.fw_iptos |= ((u_short)ippre) << 5; av++; ac--; } else if (!strncmp(*av, "iptos", strlen(*av))) { av++; ac--; --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ip_fw.diff" diff -u --exclude=*orig /usr/src/sys/netinet.orig/ip_fw.c netinet/ip_fw.c --- /usr/src/sys/netinet.orig/ip_fw.c Fri Apr 6 10:52:25 2001 +++ netinet/ip_fw.c Sun Jul 1 15:40:52 2001 @@ -373,7 +373,7 @@ u_int flags = (ip->ip_tos & 0x1f); u_char opts, nopts, nopts_sve; - opts = f->fw_iptos; + opts = (f->fw_iptos & 0x1f); nopts = nopts_sve = f->fw_ipntos; while (flags != 0) { @@ -1162,6 +1162,9 @@ if (f->fw_ipflg & IP_FW_IF_IPLEN && f->fw_iplen != ip_len) continue; if (f->fw_ipflg & IP_FW_IF_IPID && f->fw_ipid != ntohs(ip->ip_id)) + continue; + if (f->fw_ipflg & IP_FW_IF_IPPRE && + (f->fw_iptos & 0xe0) != (ip->ip_tos & 0xe0)) continue; if (f->fw_ipflg & IP_FW_IF_IPTOS && !iptos_match(ip, f)) continue; diff -u --exclude=*orig /usr/src/sys/netinet.orig/ip_fw.h netinet/ip_fw.h --- /usr/src/sys/netinet.orig/ip_fw.h Tue Feb 13 17:12:04 2001 +++ netinet/ip_fw.h Sun Jul 1 15:27:24 2001 @@ -234,7 +234,8 @@ #define IP_FW_IF_IPTOS 0x00000800 /* ip type of service */ #define IP_FW_IF_IPTTL 0x00001000 /* ip time to live */ #define IP_FW_IF_IPVER 0x00002000 /* ip version */ -#define IP_FW_IF_IPMSK 0x00003f00 /* mask of all ip values */ +#define IP_FW_IF_IPPRE 0x00004000 /* ip precedence */ +#define IP_FW_IF_IPMSK 0x00007f00 /* mask of all ip values */ #define IP_FW_IF_MSK 0x0000ffff /* All possible bits mask */ --lrZ03NoBR/3+SXJZ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 10:10:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from excalibur.dotcom.fr (ns.dotcom.fr [195.154.74.11]) by hub.freebsd.org (Postfix) with ESMTP id 5965637B407; Tue, 3 Jul 2001 10:10:30 -0700 (PDT) (envelope-from roman@IPricot.com) Received: from IPricot.com (pc181.fr.ipricot.com [192.168.31.181]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id RAA08068; Tue, 3 Jul 2001 17:10:28 GMT Message-ID: <3B41FC84.8D4F7182@IPricot.com> Date: Tue, 03 Jul 2001 19:10:28 +0200 From: Roman Le Houelleur Organization: IPricot X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net Cc: freebsd-stable Subject: Setting ip addr deletes routes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi, > uname -a FreeBSD roman.fr.ipricot.com 4.3-STABLE FreeBSD 4.3-STABLE #0: \ Tue Jul 3 17:28:04 CEST 2001 \ root@roman.fr.ipricot.com:/usr/src/sys/compile/ROMAN_SB i386 I have only updated src-sys, the rest of the system comes from a 4.3 RC4. > ifconfig -a rl0: flags=8843 mtu 1500 inet 192.168.31.181 netmask 0xffffff00 broadcast 192.168.31.255 ether 00:50:fc:01:a3:3c media: autoselect (100baseTX) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX vr0: flags=8843 mtu 1500 inet 192.168.42.1 netmask 0xffffff00 broadcast 192.168.42.255 ether 00:50:ba:05:9a:8f media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none sl0: flags=c010 mtu 552 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010 mtu 1500 > netstat -rn Destination Gateway Flags Netif Expire default 192.168.31.254 UGSc 0 0 rl0 127.0.0.1 127.0.0.1 UH 0 0 lo0 192.168.31 link#1 UC 2 0 rl0 => 192.168.42 link#2 UC 0 0 vr0 => 195.154.74 link#1 UCSc 1 0 rl0 => > ifconfig rl0 192.168.31.181 netmask 0xffffff00 (yes, this is the same ip addr, but same results with another one) > netstat -rn Destination Gateway Flags Netif Expire 127.0.0.1 127.0.0.1 UH 0 0 lo0 192.168.31 link#1 UC 2 0 rl0 => 192.168.42 link#2 UC 0 0 vr0 => So, here is the question 1. Is this a bug ? 2. or is it a user process I should have updated too ? 3. maybe a new functionnality I don't understand ? thanks, Roman. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 10:55:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from alacran.it.uc3m.es (alacran.it.uc3m.es [163.117.139.44]) by hub.freebsd.org (Postfix) with ESMTP id 1874C37B405 for ; Tue, 3 Jul 2001 10:55:05 -0700 (PDT) (envelope-from jrh@it.uc3m.es) Received: from it.uc3m.es (localhost [127.0.0.1]) by alacran.it.uc3m.es (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id f63Ht3Z29245 for ; Tue, 3 Jul 2001 19:55:03 +0200 X-Authentication-Warning: alacran.it.uc3m.es: Host localhost [127.0.0.1] claimed to be it.uc3m.es Message-ID: <3B4206F3.E75B1E11@it.uc3m.es> Date: Tue, 03 Jul 2001 19:54:59 +0200 From: Juan Fco Rodriguez Hervella X-Mailer: Mozilla 4.74 [es] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.unix.programmer To: Lista Subject: ftp.c understanding Content-Type: multipart/mixed; boundary="------------BF9229A944034D4828AFA463" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Este es un mensaje multipartes en formato MIME. --------------BF9229A944034D4828AFA463 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi: Inside /usr/src/usr.bin/ftp/ftp.c:initconn(), I can not understand the following piece of code: My problem is with SO_REUSEADDR. The first time, sendport = -1, so data_addr.su_port = 0 and SO_REUSEADDR is not call. Then the port is send to the server. If something goes wrong, sendport =0 && goto noport. This time, it is called to SO_REUSEADDR, why is it called now and not the first time ? Also, if sendport = 0 the port is not send to the server, then how is it openned the data connection ? By default, the data connection is on port 20, but the code does not specified any port at bind() call. -- ********************************* Juan F. Rodriguez Hervella Universidad Carlos III de Madrid ******************************** --------------BF9229A944034D4828AFA463 Content-Type: text/plain; charset=us-ascii; name="code.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="code.c" noport: data_addr = myctladdr; if (sendport) data_addr.su_port = 0; /* let system pick one */ if (data != -1) (void)close(data); data = socket(data_addr.su_family, SOCK_STREAM, 0); if (data < 0) { warn("socket"); if (tmpno) sendport = 1; return (1); } if (!sendport) if (setsockopt(data, SOL_SOCKET, SO_REUSEADDR, (char *)&on, sizeof(on)) < 0) { warn("setsockopt (reuse address)"); goto bad; } if (bind(data, (struct sockaddr *)&data_addr, data_addr.su_len) < 0) { warn("bind"); goto bad; } if (options & SO_DEBUG && setsockopt(data, SOL_SOCKET, SO_DEBUG, (char *)&on, sizeof(on)) < 0) warn("setsockopt (ignored)"); len = sizeof(data_addr); if (getsockname(data, (struct sockaddr *)&data_addr, &len) < 0) { warn("getsockname"); goto bad; } if (listen(data, 1) < 0) warn("listen"); if (sendport) { bla...bla...bla.. skip_port: if (result == ERROR && sendport == -1) { sendport = 0; tmpno = 1; goto noport; } return (result != COMPLETE); } if (tmpno) sendport = 1; return (0); bad: (void)close(data), data = -1; if (tmpno) sendport = 1; return (1); } --------------BF9229A944034D4828AFA463-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 11:18:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from alacran.it.uc3m.es (alacran.it.uc3m.es [163.117.139.44]) by hub.freebsd.org (Postfix) with ESMTP id D8E4B37B41D for ; Tue, 3 Jul 2001 11:18:18 -0700 (PDT) (envelope-from jrh@it.uc3m.es) Received: from it.uc3m.es (localhost [127.0.0.1]) by alacran.it.uc3m.es (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id f63IIHZ29299 for ; Tue, 3 Jul 2001 20:18:17 +0200 X-Authentication-Warning: alacran.it.uc3m.es: Host localhost [127.0.0.1] claimed to be it.uc3m.es Message-ID: <3B420C63.41C48FBB@it.uc3m.es> Date: Tue, 03 Jul 2001 20:18:11 +0200 From: Juan Fco Rodriguez Hervella X-Mailer: Mozilla 4.74 [es] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.unix.programmer To: Lista Subject: How to send packets to another interface on the same machine Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dear all: I have the following problem: I would like to send an IPv6 packet using a given interface, to the address that corresponds to another interface of the same machine. This, that seems a bit akward, it would be interesting for obtaining accurate packet latency results to test other systems that could be placed between the two interfaces (routers, etc.). Since the sending and the receiving process share the same physical clock, microsecond precision could be obtained in the measures. The problem is that FreeBSD recognises that the destination address is in the same machine, and routes directly through the loopback interface, without sending actually the packets through the wire. Anyone knows a trick to do this? -- ********************************* Juan F. Rodriguez Hervella Universidad Carlos III de Madrid ******************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 11:29: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id CC4B337B405 for ; Tue, 3 Jul 2001 11:29:01 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f63ISsx26183; Tue, 3 Jul 2001 11:28:54 -0700 Date: Tue, 3 Jul 2001 11:28:54 -0700 From: Brooks Davis To: Juan Fco Rodriguez Hervella Cc: Lista Subject: Re: How to send packets to another interface on the same machine Message-ID: <20010703112854.A25425@Odin.AC.HMC.Edu> References: <3B420C63.41C48FBB@it.uc3m.es> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B420C63.41C48FBB@it.uc3m.es>; from jrh@it.uc3m.es on Tue, Jul 03, 2001 at 08:18:11PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 03, 2001 at 08:18:11PM +0200, Juan Fco Rodriguez Hervella wrote: > I have the following problem: I would like to send an IPv6 packet using > a given=20 > interface, to the address that corresponds to another interface of the > same machine.=20 >=20 > This, that seems a bit akward, it would be interesting for obtaining > accurate=20 > packet latency results to test other systems that could be placed > between the=20 > two interfaces (routers, etc.). Since the sending and the receiving > process share=20 > the same physical clock, microsecond precision could be obtained in the > measures. >=20 > The problem is that FreeBSD recognises that the destination address is > in the same=20 > machine, and routes directly through the loopback interface, without > sending actually > the packets through the wire. >=20 > Anyone knows a trick to do this? I'm working on a project with similar problmes requirements, though without the strict timing requirements. We're using a NAT component in the middle so all the clients have 10.1 addresses, but try to connect to 10.2 addresses. The translation should be more then fast enough four our purposes, but may not work for yours. If you don't care about local IP stack latency measurements, you might try writing RAW packets directly to the wire with libnet. -- 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 --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7Qg7lXY6L6fI4GtQRAhGJAJ98FcnKGSAsRhwjZIO9UXCsXAZA/ACeMqyV Wd21tbm5/gQtKuCd6iaYbIM= =9PbU -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 12:12: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from herbelot.dyndns.org (d020.dhcp212-27.cybercable.fr [212.198.27.20]) by hub.freebsd.org (Postfix) with ESMTP id 3C19B37B406 for ; Tue, 3 Jul 2001 12:12:03 -0700 (PDT) (envelope-from thierry@herbelot.com) Received: from herbelot.com (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id VAA05377; Tue, 3 Jul 2001 21:10:07 +0200 (CEST) (envelope-from thierry@herbelot.com) Message-ID: <3B4218DD.A1DAAB51@herbelot.com> Date: Tue, 03 Jul 2001 21:11:25 +0200 From: Thierry Herbelot X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Juan Fco Rodriguez Hervella Cc: Lista Subject: Re: How to send packets to another interface on the same machine References: <3B420C63.41C48FBB@it.uc3m.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Juan Fco Rodriguez Hervella wrote: > > Dear all: > > I have the following problem: I would like to send an IPv6 packet using > a given > interface, to the address that corresponds to another interface of the > same machine. > > This, that seems a bit akward, it would be interesting for obtaining > accurate > packet latency results to test other systems that could be placed > between the > two interfaces (routers, etc.). Since the sending and the receiving > process share > the same physical clock, microsecond precision could be obtained in the > measures. > > The problem is that FreeBSD recognises that the destination address is > in the same > machine, and routes directly through the loopback interface, without > sending actually > the packets through the wire. > > Anyone knows a trick to do this? I have recently built a similar test bench, but for latency accuracies in the order of 1 ms (instead of some usecs), using ntp to synchronize the machines. This way, I could measure the the travelling time of packets down to a 1 ms accuracy (from one PC to another, both being synchronized to the same NTP master server) HtH -- Thierry Herbelot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 13:24:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from altrade.nijmegen.inter.nl.net (altrade.nijmegen.inter.nl.net [193.67.237.6]) by hub.freebsd.org (Postfix) with ESMTP id 2681137B403 for ; Tue, 3 Jul 2001 13:24:51 -0700 (PDT) (envelope-from Peter.Blok@inter.NL.net) Received: from ntpc by altrade.nijmegen.inter.nl.net via 1Cust174.tnt6.rtm1.nl.uu.net [213.116.106.174] with SMTP for id WAA09542 (8.8.8/1.3); Tue, 3 Jul 2001 22:24:50 +0200 (MET DST) Reply-To: From: "Peter Blok" To: Subject: wireless SMC 2602 and 2632 adapters Date: Tue, 3 Jul 2001 22:21:00 +0200 Message-ID: <000101c103fd$ada02f50$8a02a8c0@ntpc> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Folks, I just wanted to let you know the SMC wireless adapters are working in 4.3-STABLE. Make sure you load the latest - called linux - firmware into the boards. The SMC2602W is a PCI to PCMCIA controller, dedicated for the SMC2632W. I have my SMC2632W in my laptop running windoze2000. I am running 64 bit encryption and use ad-hoc mode. Works great! Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 16:20: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns.itga.com.au (ns.itga.com.au [202.53.40.210]) by hub.freebsd.org (Postfix) with ESMTP id AAEEC37B401; Tue, 3 Jul 2001 16:18:32 -0700 (PDT) (envelope-from gnb@itga.com.au) Received: from lightning.itga.com.au (lightning.itga.com.au [192.168.71.20]) by ns.itga.com.au (8.9.3/8.9.3) with ESMTP id JAA52734; Wed, 4 Jul 2001 09:18:30 +1000 (EST) (envelope-from gnb@itga.com.au) Received: from itga.com.au (lightning.itga.com.au [192.168.71.20]) by lightning.itga.com.au (8.9.3/8.9.3) with ESMTP id JAA22231; Wed, 4 Jul 2001 09:15:59 +1000 (EST) Message-Id: <200107032315.JAA22231@lightning.itga.com.au> X-Mailer: exmh version 2.4 05/15/2001 with nmh-1.0.4 From: Gregory Bond To: Roman Le Houelleur Cc: freebsd-net , freebsd-stable Subject: Re: Setting ip addr deletes routes In-reply-to: Your message of Tue, 03 Jul 2001 19:10:28 +0200. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Jul 2001 09:15:59 +1000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I have only updated src-sys, the rest of the system comes from > a 4.3 RC4. Don't do this. The kernel has to match the userland, or things break. Routing, ps, top and other things with intimate kernel<->userland interfaces are the most likely to break. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 17:31:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 7786437B401 for ; Tue, 3 Jul 2001 17:31:18 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id B1F1B5D79; Wed, 4 Jul 2001 02:31:13 +0200 (CEST) Date: Wed, 4 Jul 2001 02:31:13 +0200 From: Jesper Skriver To: Bryan Fullerton Cc: bv@wjv.com, net@FreeBSD.ORG Subject: Re: PPPoE latency Message-ID: <20010704023113.A40316@skriver.dk> References: <20010703004307.E2458@wjv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bjf@samurai.com on Tue, Jul 03, 2001 at 01:02:22AM -0400 X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 03, 2001 at 01:02:22AM -0400, Bryan Fullerton wrote: > At 12:43 AM -0400 7/3/01, Bill Vermillion wrote: > > >Since the first link to the DSL is not your system but the box > >above it, I really suspect that is the problem. > > The pings that I provided were to the first hop, ie my gateway at the > other end of the connection. You can't use that for measurement, on many router products the process of replying to ICMP echo's (and generating other ICMP messages) is a VERY low priority task, so if it's CPU is loaded with other tasks, you will see a excessive latency in ping's to that router, but you will probably see a much more normal delay to a host behind it. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 20:44:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by hub.freebsd.org (Postfix) with ESMTP id 1F8EF37B405 for ; Tue, 3 Jul 2001 20:44:33 -0700 (PDT) (envelope-from bjf@samurai.com) Received: from [192.168.1.34] ([65.92.97.21]) by tomts13-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010704034432.ZHOF7196.tomts13-srv.bellnexxia.net@[192.168.1.34]>; Tue, 3 Jul 2001 23:44:32 -0400 Mime-Version: 1.0 X-Sender: bjf@mail.samurai.com Message-Id: In-Reply-To: <20010703091456.E5516@wjv.com> References: <20010703004307.E2458@wjv.com> <20010703091456.E5516@wjv.com> Date: Tue, 3 Jul 2001 23:27:18 -0400 To: bv@wjv.com From: Bryan Fullerton Subject: Re: PPPoE latency Cc: net@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 9:14 AM -0400 7/3/01, Bill Vermillion wrote: >Well in the above instance I am the provider and I get different >ping times at the different locations. [Just bringing this all up >and only got one running late Wednesay night]. If you provider is >not the lowest link in the chain, eg the telco providing service to >your location, you could see all sorts of speed differernces. In my case, and the case of the friend I'm referencing, the provider is the telco (Sympatico/Bell Canada). Bryan -- Bryan Fullerton http://bryanfullerton.com/ Core Competence uunet.ca!gts!cspace!bjf Samurai Consulting Can you feel the Ohmu call? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 20:44:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by hub.freebsd.org (Postfix) with ESMTP id D3B5D37B405 for ; Tue, 3 Jul 2001 20:44:38 -0700 (PDT) (envelope-from bjf@samurai.com) Received: from [192.168.1.34] ([65.92.97.21]) by tomts13-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010704034438.ZHOK7196.tomts13-srv.bellnexxia.net@[192.168.1.34]>; Tue, 3 Jul 2001 23:44:38 -0400 Mime-Version: 1.0 X-Sender: bjf@mail.samurai.com Message-Id: In-Reply-To: <20010704023113.A40316@skriver.dk> References: <20010703004307.E2458@wjv.com> <20010704023113.A40316@skriver.dk> Date: Tue, 3 Jul 2001 23:32:15 -0400 To: Jesper Skriver From: Bryan Fullerton Subject: Re: PPPoE latency Cc: bv@wjv.com, net@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 2:31 AM +0200 7/4/01, Jesper Skriver wrote: >You can't use that for measurement, on many router products the >process of replying to ICMP echo's (and generating other ICMP >messages) is a VERY low priority task, so if it's CPU is loaded >with other tasks, you will see a excessive latency in ping's to >that router, but you will probably see a much more normal delay to >a host behind it. Valid point - pinging the other end of my gateway is giving average responses in the 65ms range, pinging the core router behind it returns averages of 55ms. Still high, though. Bryan -- Bryan Fullerton http://bryanfullerton.com/ Core Competence uunet.ca!gts!cspace!bjf Samurai Consulting Can you feel the Ohmu call? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 20:44:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by hub.freebsd.org (Postfix) with ESMTP id 4A77437B405 for ; Tue, 3 Jul 2001 20:44:45 -0700 (PDT) (envelope-from bjf@samurai.com) Received: from [192.168.1.34] ([65.92.97.21]) by tomts13-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010704034444.ZHOV7196.tomts13-srv.bellnexxia.net@[192.168.1.34]>; Tue, 3 Jul 2001 23:44:44 -0400 Mime-Version: 1.0 X-Sender: bjf@mail.samurai.com Message-Id: In-Reply-To: <20010703001534.D84523@sneakerz.org> References: <20010702233606.A84523@sneakerz.org> <20010702235434.B84523@sneakerz.org> <20010703001534.D84523@sneakerz.org> Date: Tue, 3 Jul 2001 23:43:46 -0400 To: Alfred Perlstein From: Bryan Fullerton Subject: Re: PPPoE latency Cc: net@freebsd.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 12:15 AM -0500 7/3/01, Alfred Perlstein wrote: >A boatload. :) ISA is _really_ slow. :) Ok, I swapped in the PCI card, which turns out to be an fxp (Intel Pro 10/100B/100+ Ethernet, according to dmesg), not 3com as I'd thought. I also removed an extra ISA card which wasn't doing anything, so there are now no ISA cards in the box, and also bumped the RAM to 128Mb from 64Mb (an upgrade I'd been planning next time I had the case open). Oh, and I recompiled the kernel and removed "option NETGRAPH", so it wouldn't give me those annoying errors when trying to dynamically load the kernel module. Ping is about the same. This is the other end of my gateway: --- 65.92.97.1 ping statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max/stddev = 54.044/63.657/79.551/5.366 ms Taking Jesper's comments about overloaded edge routers into account, I'm still seeing ~55ms ping times from my ISP's core routers. It's possible their core is overloaded as well as oversubscribing the edge DSL routers, but seems less likely to me. This is into the core (2 hops out from me): --- 206.108.104.98 ping statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max/stddev = 51.851/55.403/59.505/1.589 ms Bryan -- Bryan Fullerton http://bryanfullerton.com/ Core Competence uunet.ca!gts!cspace!bjf Samurai Consulting Can you feel the Ohmu call? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 20:44:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by hub.freebsd.org (Postfix) with ESMTP id 9034D37B401 for ; Tue, 3 Jul 2001 20:44:47 -0700 (PDT) (envelope-from bjf@samurai.com) Received: from [192.168.1.34] ([65.92.97.21]) by tomts13-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010704034446.ZHOY7196.tomts13-srv.bellnexxia.net@[192.168.1.34]>; Tue, 3 Jul 2001 23:44:46 -0400 Mime-Version: 1.0 X-Sender: bjf@mail.samurai.com Message-Id: In-Reply-To: <3B41EB3C.EF185F3F@elischer.org> References: <3B41EB3C.EF185F3F@elischer.org> Date: Tue, 3 Jul 2001 23:44:24 -0400 To: Julian Elischer From: Bryan Fullerton Subject: Re: PPPoE latency Cc: net@freebsd.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 8:56 AM -0700 7/3/01, Julian Elischer wrote: >you may be a good test case for us.. >we have heard of this negraph latency for a while but have never had a good >test case.. if I send you test code can you run it for me? Absolutely. Bryan -- Bryan Fullerton http://bryanfullerton.com/ Core Competence uunet.ca!gts!cspace!bjf Samurai Consulting Can you feel the Ohmu call? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 21:25:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id 5681337B403 for ; Tue, 3 Jul 2001 21:25:28 -0700 (PDT) (envelope-from mike@sentex.net) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.11.2/8.11.1) with SMTP id f644PNY12026; Wed, 4 Jul 2001 00:25:23 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: bjf@samurai.com (Bryan Fullerton) Cc: freebsd-net@freebsd.org Subject: Re: PPPoE latency Date: Wed, 04 Jul 2001 00:25:22 -0400 Message-ID: References: <20010702233606.A84523@sneakerz.org> <20010702235434.B84523@sneakerz.org> In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 3 Jul 2001 01:12:18 -0400, in sentex.lists.freebsd.net you wrote: >> >>Same difference, ppp is implemented as a userland process, nearly the >>same amount of work must be done for either natd or ppp. > >Well, I certainly can't get around needing NAT. Would it really add=20 On my 486 gateway, I found using ipnat made a big difference in overall throughput for my machines behind the DSL box. With a faster CPU, the differences become much less measurable. ---Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 3 23:59:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from bugs.elitsat.net (bugs.elitsat.net [209.239.78.230]) by hub.freebsd.org (Postfix) with ESMTP id 0FCC437B401 for ; Tue, 3 Jul 2001 23:59:23 -0700 (PDT) (envelope-from amour@bugs.elitsat.net) Received: from localhost (amour@localhost) by bugs.elitsat.net (8.11.1/8.11.1) with ESMTP id f646xBv42963 for ; Wed, 4 Jul 2001 09:59:13 +0300 (EEST) (envelope-from amour@bugs.elitsat.net) Date: Wed, 4 Jul 2001 09:59:11 +0300 (EEST) From: Alexander To: freebsd-net@freebsd.org Subject: network monitor Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm looking for some util that is simple to scotty but doesn't require X11. I need it to monitor my network (like sending some packets) and making statistics or sending alarm signals when some host fails. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 4 0: 2:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 741C237B406; Wed, 4 Jul 2001 00:02:22 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f6471qp58392; Wed, 4 Jul 2001 10:01:52 +0300 (EEST) (envelope-from ru) Date: Wed, 4 Jul 2001 10:01:52 +0300 From: Ruslan Ermilov To: Roman Le Houelleur Cc: freebsd-net , freebsd-stable Subject: Re: Setting ip addr deletes routes Message-ID: <20010704100152.B55338@sunbay.com> Mail-Followup-To: Roman Le Houelleur , freebsd-net , freebsd-stable References: <3B41FC84.8D4F7182@IPricot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B41FC84.8D4F7182@IPricot.com>; from roman@IPricot.com on Tue, Jul 03, 2001 at 07:10:28PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 03, 2001 at 07:10:28PM +0200, Roman Le Houelleur wrote: > hi, > > > uname -a > FreeBSD roman.fr.ipricot.com 4.3-STABLE FreeBSD 4.3-STABLE #0: \ > Tue Jul 3 17:28:04 CEST 2001 \ > root@roman.fr.ipricot.com:/usr/src/sys/compile/ROMAN_SB i386 > > I have only updated src-sys, the rest of the system comes from > a 4.3 RC4. > > > ifconfig -a > rl0: flags=8843 mtu 1500 > inet 192.168.31.181 netmask 0xffffff00 broadcast 192.168.31.255 > ether 00:50:fc:01:a3:3c > media: autoselect (100baseTX) status: active > supported media: autoselect 100baseTX 100baseTX > 10baseT/UTP > 10baseT/UTP 100baseTX > vr0: flags=8843 mtu 1500 > inet 192.168.42.1 netmask 0xffffff00 broadcast 192.168.42.255 > ether 00:50:ba:05:9a:8f > media: autoselect (100baseTX ) status: active > supported media: autoselect 100baseTX 100baseTX > 10baseT/UTP > 10baseT/UTP none > sl0: flags=c010 mtu 552 > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > ppp0: flags=8010 mtu 1500 > > > netstat -rn > Destination Gateway Flags Netif Expire > default 192.168.31.254 UGSc 0 0 rl0 > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > 192.168.31 link#1 UC 2 0 rl0 > => > 192.168.42 link#2 UC 0 0 vr0 > => > 195.154.74 link#1 UCSc 1 0 rl0 > => > > > ifconfig rl0 192.168.31.181 netmask 0xffffff00 > (yes, this is the same ip addr, but same results with another one) > > netstat -rn > Destination Gateway Flags Netif Expire > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > 192.168.31 link#1 UC 2 0 rl0 > => > 192.168.42 link#2 UC 0 0 vr0 > => > > So, here is the question > 1. Is this a bug ? > 2. or is it a user process I should have updated too ? > 3. maybe a new functionnality I don't understand ? > This is 3). The second `ifconfig' first deleted IP address from an interface (see `route -vn monitor' output), then assigns the new one. Every routing table entry stores the pointer to the associated interface, and one of interface's addresses (see `route -vn get default' for example). There was a bug: if you changed the IP address of an interface, routes that point to this interface might still use the old IP address, and unnamed (with unspecified source IP address) datagrams used this old IP address. Old IP routing code invalidated only dynamic routes when interface goes down, or address is removed. The routing code has been modified recently to invalidate all routes, including static ones, when the address is deleted. See the comment in the sys/netinet/in_rmx.c file that starts from the words "This zaps old routes" for more details. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 4 2:33:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id EC7F737B403 for ; Wed, 4 Jul 2001 02:33:35 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 71215 invoked by uid 1001); 4 Jul 2001 09:33:33 +0000 (GMT) To: julian@elischer.org Cc: bjf@samurai.com, net@freebsd.org Subject: Re: PPPoE latency From: sthaug@nethelp.no In-Reply-To: Your message of "Tue, 03 Jul 2001 08:56:44 -0700" References: <3B41EB3C.EF185F3F@elischer.org> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 04 Jul 2001 11:33:33 +0200 Message-ID: <71213.994239213@verdi.nethelp.no> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Here's a ping on my friend's machine (Mac ping, sorry for lack of precision): > > > > Packets out/in/bad/%loss = 64/64/0/0.0 > > Round Trip Time (ms) min/avg/max = 14/24/59 > > > > My box should be fine cpu-wise, it's a Celeron/300, and isn't doing > > anything else. The card PPPoE is running over is an ISA 10BaseT > > D-Link card using the ed(4) driver, if that makes any difference. I > > track STABLE with this box, it's currently at: > > > > FreeBSD katana.apt.samurai.com 4.3-STABLE FreeBSD 4.3-STABLE #13: Sun > > Jun 24 01:43:39 EDT 2001 > > > > Any thoughts? I can live with this, the connection is rock solid and > > has been for over a year now, just curious as to why. Apologies if > > this has come up before, I searched the list archives and the bug > > list. > > you may be a good test case for us.. > we have heard of this negraph latency for a while but have never had a good > test case.. if I send you test code can you run it for me? I believe the latency for the basic netgraph code is a complete non-issue. I have an ADSL connection where I can control both ends (this is for an ISP which is just starting to test ADSL). - With straight bridging (RBE on the Cisco at the ISP end), I get ping roundtrip times of 9.2 ms on the average (ping a host reachable through the router, not the router itself). - With PPPoe (and of course netgraph) I get ping roundtrip times of 9.4 ms on the average. Thus the basic netgraph machinery plus userland ppp adds around 0.2 ms to the roundtrip times. I see no reason to complain about this. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 4 3:11:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from shadow.otel.net (JuDiCaToR.OTEL.net [212.36.9.113]) by hub.freebsd.org (Postfix) with ESMTP id 34A7B37B406; Wed, 4 Jul 2001 03:11:50 -0700 (PDT) (envelope-from tbyte@tbyte.org) Received: from localhost (localhost [127.0.0.1]) by shadow.otel.net (8.11.4/8.11.1) with ESMTP id f64ABmK38102; Wed, 4 Jul 2001 13:11:48 +0300 (EEST) (envelope-from tbyte@tbyte.org) Date: Wed, 4 Jul 2001 13:11:48 +0300 (EEST) From: Iasen Kostoff X-Sender: tbyte@shadow.otel.net To: Ruslan Ermilov Cc: freebsd-net@FreeBSD.ORG Subject: Re: adding a route to host via interface In-Reply-To: <20010703181032.A65571@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 3 Jul 2001, Ruslan Ermilov wrote: > On Tue, Jul 03, 2001 at 04:54:29PM +0300, Iasen Kostoff wrote: > > > [...] > > > You can't change host route to network route, or vise versa; destination > > > is the Patricia's tree key, and it can't be changed. The only possible > > > way is like I suggested: ``route add foo/32 -iface bar -cloning''. > > > > Yes I know, but ``route add foo -iface bar -cloning`` is meanless, I > > think, because host route could not be cloned and I kernel should auto set > > foo to foo/32 because of meanlessness of -host foo. > > > Could you please try the attached patch? It disallows cloning for > host entries. > I test it , it works fine. > > And is route add -host > > foo -iface bar (without -cloning) could be used for something ? > > > Yes, it is currently used for proxy ARP type 1 entries: > > # arp -s 192.168.4.200 1:2:3:4:5:6 pub > # netstat -rn | grep 192.168.4.200 > 192.168.4.200/32 1:2:3:4:5:6 ULS2c 0 0 rl0 > > The purpose of /32 here is to allow the call to rtalloc1() in arplookup() > to match this route even if the SIN_PROXY flag (proxy ARP type 2; aka > published (proxy only)) is set in the sin_other member of the > sockaddr_inarp structure. > I think -cloning should be the default when you add route like : route add -net foo/32 -iface bar and may be it's better route(8) to set -net route when you try manualy to set route like : route add foo -iface bar (without specifing -llinfo) because this will add route to your own LAN card lladdr which I don't think could be in use for someone (may be I'm wrong). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 4 6:49: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from mine.kame.net (kame195.kame.net [203.178.141.195]) by hub.freebsd.org (Postfix) with ESMTP id 0B40C37B405 for ; Wed, 4 Jul 2001 06:49:06 -0700 (PDT) (envelope-from sakane@kame.net) Received: from localhost (PPP2543.tokyo-ip.dti.ne.jp [211.132.91.43]) by mine.kame.net (8.11.1/3.7W) with ESMTP id f64EUtY82672; Wed, 4 Jul 2001 23:30:56 +0900 (JST) To: mcambria@avaya.com Cc: snap-users@kame.net, freebsd-net@freebsd.org Subject: RE: (KAME-snap 5064) Can I define a SPD per interface? In-Reply-To: Your message of "Tue, 3 Jul 2001 09:23:58 -0400 " <3A6D367EA1EFD4118C9B00A0C9DD99D7064F5F@rerun.lucentctc.com> References: <3A6D367EA1EFD4118C9B00A0C9DD99D7064F5F@rerun.lucentctc.com> X-Mailer: Cue version 0.6 (010413-1707/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20010704095026X.sakane@kame.net> Date: Wed, 04 Jul 2001 09:50:26 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 27 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > >I can only find a way to define a global SPD using setkey. Is it possible > >to define an (IPv4) SPD on a per interface basis using KAME / FreeBSD4? > >If not, are there any plans to add this in the future? > >Is there any reason one wouldn't want to have this? > no. do you want SPD per interface, or IPsec SPI per interface? > anyway, IPsec architecture is not interface-oriented (it lives on top > of IP, and the information on interface is already gone) > so your suggestion does not fit nicely to the current architecture... the specification strongly supposed about a security gateway which has two interface, namely the internal and the outernal, even though the one considered about a host to be secured. > I read RFC2401 (pg 13) differently, which is why I asked. > "Each interface for which IPsec is enabled requires nominally separate > inbound vs. outbound databases (SAD and SPD)" i think it's implementation design matter. we choiced to implement it like a address based packet filtering, not a interface based. > and further down on pg 13 > "...SG had multiple external interfaces, it might be necessary to have > separate SAD and SPD pairs for each interface." On the router which had multiple interfaces, if we configured IPSec on the interface A, but the kernel decided a packet to forward to the interface B due to routing information, the packet could not be secure. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 4 7: 4:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 74D6D37B409; Wed, 4 Jul 2001 07:04:08 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.3/8.11.3) with ESMTP id f64E44331564; Wed, 4 Jul 2001 10:04:04 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200107041404.f64E44331564@whizzo.transsys.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Wes Peters Cc: Bakul Shah , Ruslan Ermilov , Deepak Jain , net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: fastforwarding? References: <200107021954.PAA25927@goliath.cnchost.com> <3B41EB64.3B753DDE@softweyr.com> In-reply-to: Your message of "Tue, 03 Jul 2001 09:57:24 MDT." <3B41EB64.3B753DDE@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Jul 2001 10:04:04 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Even if it takes 0 ns to do a route lookup, a stock freebsd > > system can't do more than 20K ~ 100K pkts/second due to many > > bottlenecks. In a hardware accelrated router one can easily > > do 10M route lookups *without* using an expensive & power > > hungry fancy CAM. But they may be worth it if you want to > > route 1M+ pkts/second *and* you want to do packet matching. > > Such as a routing switch would do. Plus you have the added advantage that > the route caches scale well to multiple indepdendant "smart" interfaces, > which is not likely to be added to a generic FreeBSD system. Except there > are all these PCI based smart network cards popping up on the market these > days, and it would be possible to scale the fastforwarding code directly > onto the network cards... But beware of what happens when you get cache misses. Perhaps this isn't an issue for 90% of users, but in a router with the entire Internet routing table of 100K+ routes, along with frequent churn, this is very serious. To describe a real example: 4 or 5 years ago, we used Cisco 7000 series routers with a SSE (Silicon Switch Engine) forwarding accelerator. This was essentially a cache-based strategy, where the forwarding tables were computed elsewhere on the main CPU running the routing protocols, and then pushed into the SSE. The problem is that with a router in the default-free part of the Internet, with 100K+ routes, that the routes ARE ALWAYS CHANGING. There is constant churn, and if you don't have sophisticated partial cache invalidatation strategies, you end up tossing the contents of the fowarding cache every few seconds due to the background churn. The cost of a cache miss is high, and this can become high enough to starve the main cpu running the routing protocols until routing adjacencies begin to fail, further introducing more instability into the routing system and driving the system over the cliff into collapse. I've seen this happen, and it's great fun to observe if it's not your network that it's happening to. Most router benchmarks and testing processes these days test forwarding capacity in the face of routing table churn, which is closer to the real-world experience. Personally, I don't buy forwarding cache-based routers because this is a sign that the underlying infrastucture isn't fast enough and you're banking on the cache hit rate being high enough to save your ass. Of course, there are wonderful DoS attacks against cache-based routers which are simply sending a bunch of packets at high rates each to a different address, forcing a cache miss on every packet. Seen that one too. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 4 10: 6:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from ajax.cnchost.com (ajax.cnchost.com [207.155.248.31]) by hub.freebsd.org (Postfix) with ESMTP id 9A34537B401; Wed, 4 Jul 2001 10:06:54 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by ajax.cnchost.com id NAA24238; Wed, 4 Jul 2001 13:06:51 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200107041706.NAA24238@ajax.cnchost.com> To: "Louis A. Mamakos" Cc: Wes Peters , Ruslan Ermilov , Deepak Jain , net@FreeBSD.ORG Subject: Re: fastforwarding? In-reply-to: Your message of "Wed, 04 Jul 2001 10:04:04 EDT." <200107041404.f64E44331564@whizzo.transsys.com> Date: Wed, 04 Jul 2001 10:06:51 -0700 From: Bakul Shah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > Even if it takes 0 ns to do a route lookup, a stock freebsd > > > system can't do more than 20K ~ 100K pkts/second due to many > > > bottlenecks. In a hardware accelrated router one can easily > > > do 10M route lookups *without* using an expensive & power > > > hungry fancy CAM. But they may be worth it if you want to > > > route 1M+ pkts/second *and* you want to do packet matching. > > > > Such as a routing switch would do. Plus you have the added advantage that > > the route caches scale well to multiple indepdendant "smart" interfaces, > > which is not likely to be added to a generic FreeBSD system. Except there > > are all these PCI based smart network cards popping up on the market these > > days, and it would be possible to scale the fastforwarding code directly > > onto the network cards... > > But beware of what happens when you get cache misses. Perhaps this isn't > an issue for 90% of users, but in a router with the entire Internet > routing table of 100K+ routes, along with frequent churn, this is very > serious. Exactly! Small ISPs using generic freebsd box as routers will be tempted to use "fast forwarding" and they need to be aware of potential DoS attacks. They don't even need to keep a full 100K+ entry route table around for this to occur as an entry is added for every destination address successfully sent to. The fastforwarding code should be changed to at least remove stale cache entries so that the DoS slows things down but doesn't crash or hang the system:-) As for smart network cards, downloading the entire forwarding table may make sense (e.g. when infiniband based systems become real or gigE boards) but not a dest. addr cache. But now you are talking about a lot more changes not just a wart of code. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 4 13:47:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from sumdu.edu.ua (sumdu.edu.ua [212.1.122.17]) by hub.freebsd.org (Postfix) with ESMTP id 37DB337B401 for ; Wed, 4 Jul 2001 13:47:17 -0700 (PDT) (envelope-from vlad@infonet.com.ua) Received: from kuzya (kuzya.infonet.com.ua [212.1.122.106]) by sumdu.edu.ua (8.11.3/8.11.3) with SMTP id f64KlBr01804 for ; Wed, 4 Jul 2001 23:47:15 +0300 (EEST) (envelope-from vlad@infonet.com.ua) Message-ID: <023401c104ca$829d0d00$6a7a01d4@kuzya> From: "Vlad Marchenko" To: Subject: Operation now in progress Date: Wed, 4 Jul 2001 23:47:12 +0300 Organization: SUMDU MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, We've got into problems that I have no idea how to solve. Our webcluster consist of one frontend server and several backend servers. FreeBSD 4.3-STABLE and apache 1.3.20 are used everywhere. When a rate of requests from frontend to backend server becomes too high (over 100 rps) backend server starting to behavior weird. This could be illustrated by generating heavy traffic from frontend to backend by ab test performance utility included in apache distribution: ------------ frontend# /usr/local/apache/bin/ab -c 40 -n 10000 "http://backend/page.html" This is ApacheBench, Version 1.3c <$Revision: 1.44 $> apache-1.3 Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/ Benchmarking backend (be patient)... Server timed out : Operation now in progress -------------- this makes 40 concurrent connections with total 10000 requests and as you see, it fails. When I see `top` on backend when ab is started - first several seconds it uses all CPU (0% idle), then it jumps to 100% idle and then ab reports "Server timed out: operation now in progress". There is _nothing_ in apache error.log. Nothing in /var/log/messages. `netstat -m` shows it has enough mbufs. it has enough memory. What's interesting - if I start simultaneously 4 ab "-c 10" each from 4 different hosts to test same backend (i.e. we have same 40 concurrent connections from backend point of view) = it works great. gives 50-60 rps per each started ab = 200+ rps total. I've tried "boa" webserver in place of apache - same problem. I've also tried to run backend on linux (RH 7.1) with same configured apache - runs fine, no "Operation now in progress" problem. This makes me think it's some OS (system) speciffic issue, not apache configuration problem. I would be very thankful to hear any ideas how to fix that. Thanks in advance. Below is config of my kernel and then /boot/loader.conf.local machine i386 cpu I686_CPU ident BACKEND maxusers 256 options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV # install a CDEV entry in /dev options IPFIREWALL options IPFIREWALL_VERBOSE device isa device pci device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device scbus # SCSI bus (required) device da # Direct Access (disks) device pass # Passthrough device (direct SCSI access) device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0 at atkbdc? irq 12 device vga0 at isa? device sc0 at isa? flags 0x100 device npx0 at nexus? port IO_NPX irq 13 device apm0 at nexus? disable flags 0x20 # Advanced Power Management device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 device miibus # MII bus support device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') pseudo-device splash pseudo-device snp 3 pseudo-device loop # Network loopback pseudo-device ether # Ethernet support pseudo-device tun # Packet tunnel. pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device md # Memory "disks" pseudo-device bpf #Berkeley packet filter /boot/loader.conf.local verbose_loading="YES" kern.vm.kmem.size="268435456" # size of kernel memory (bytes) kern.vm.pmap.shpgperproc="1024" # shared pages per process kern.nbuf="16384" # number of pages for buffers kern.maxfiles="16384" # max number of open files kern.maxproc="4096" # max number of processes kern.ncallout="32768" # callout limit kern.ipc.maxsockets="32768" # max number of sockets kern.ipc.nmbclusters="32768" # number of mbuf clusters kern.ipc.nmbufs="65536" # number of mbufs kern.ipc.nsfbufs="4096" # number of sendfile bufs net.inet.tcp.tcbhashsize="16384" # size of tcp pcb hash tables -- Vlad Marchenko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 4 23:36:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns1.infowest.com (ns1.infowest.com [204.17.177.10]) by hub.freebsd.org (Postfix) with ESMTP id 2A06337B405; Wed, 4 Jul 2001 23:36:20 -0700 (PDT) (envelope-from agifford@infowest.com) Received: from ns1.infowest.com (ns1.infowest.com [204.17.177.10]) by ns1.infowest.com (Postfix) with SMTP id A9A31210EC; Thu, 5 Jul 2001 00:36:19 -0600 (MDT) To: FreeBSD-gnats-submit@freebsd.org From: Aaron Gifford Reply-To: Aaron Gifford Subject: NEW IPFW FEATURE [PATCHES]: Dynamic rule expiration lifetime fine-grained control Message-Id: <20010705063619.A9A31210EC@ns1.infowest.com> Date: Thu, 5 Jul 2001 00:36:19 -0600 (MDT) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Please read the bulk of my message in the "Description:" section below... >Submitter-Id: current-users >Originator: Aaron Gifford >Organization: N/A >Confidential: no >Synopsis: NEW IPFW FEATURE [PATCHES]: Dynamic rule expiration lifetime fine-grained control >Severity: non-criticial >Priority: medium >Category: kern >Class: change-request >Release: FreeBSD 4.3-STABLE i386 >Environment: System: FreeBSD my.host.name 4.3-STABLE FreeBSD 4.3-STABLE #0: Thu Jun 21 20:14:40 MDT 2001 root@my.host.name:/usr/obj/usr/src/sys/CUSTOM i386 >Description: NEW FEATURE: Fine-grained control over dynamic rule expiration using an optional per-rule expiration lifetime When using stateful ipfw rules, the dynamic rule expiration times are governed by the values of the net.inet.ip.fw.dyn_*_lifetime variables. This is an excellent attribute of the ipfw stateful rule system. System administrators can tune overall system rule expiration times to tailor ipfw to best suit their needs. Unfortunately, this global tuning of rule expiration times just does not give the ipfw power user the fine-grained control he or she needs or wants. For example, the default 300-second (5-minute) expiration for TCP sessions (governed by the net.inet.ip.fw.dyn_ack_lifetime sysctl variable) in the connected state works well for TCP protocols like HTTP where the TCP session will very likely not idle beyond that default expiration time. But for TCP sessions like telnet or ssh where a user may let his or her connection idle longer than that, it is extremely annoying to discover the session frozen because the firewall expired the dynamic rule for the session. The system administrator could just increase the rule expiration time, but that breaks the elegance of the default (or admin.-tuned) global expiration setting that works well and is desireable for most connections. The solution is quite simple: add an option to override the default sysctl variable settings for TCP sessions in the connected state, and also for UDP sessions. With such an option, ipfw rules that do not use the option behave as they do now. Rules that use the option can override the default sysctl settings on a per-rule basis. Here's an example: OLD IPFW RULES: ipfw add check-state ipfw add deny tcp from any to any established ipfw add allow tcp from me to any keep-state out setup ... ipfw add allow udp from me to any 53 keep-state out ipfw add allow udp from me to ${icq} 4000 keep-state out ... With the above rules, the host can create new outbound TCP sessions using the default expiration times. However, users on the host who make outbound telnet/ssh sessions (or other long-idleing sessions) will be frusterated unless the admin. increases the global default expiration lifetime. And if the admin. does this, he/she increases consumption of system resources in cases of outbound TCP sessions where the remote side of the connection dies during the connected state without any indication or response, leaving the state as connected, the dynamic rule persisting longer than would otherwise be needed. NEW IPFW RULES: ipfw add check-state ipfw add deny tcp from any to any established ipfw add allow tcp from me to any 22,23 keep-state lifetime 3600 out setup ipfw add allow tcp from me to any keep-state out setup ... ipfw add allow udp from me to any 53 keep-state out ipfw add allow udp from me to ${icq} 4000 keep-state lifetime 600 out ... Now the administrator can use the default settings for most TCP and UDP sessions, but override the settings for specific uses. This flexibility is very desirable. This feature is currently in use on several FreeBSD-STABLE machines where I work, as well as on my home machine. I know that several other FreeBSD users have at least downloaded and looked at the patches that add this feature. I do not know if anyone else is using it currently. The patches below implement this feature. The patches included here are against the latest CVS versions of the various files as of Wed. 4 July 2001 8:00 PM MST (-0600). I also have patches against -STABLE if anyone wants them. I have been running this patch (the only changes over time were very minimal, line offsets, etc. to keep the patch working against -STABLE source changes over time) for well over a year now and it has been rock solid on Internet web server hosts as well as on various border firewall machines. IPFW MAINTAINERS: PLEASE, please examine the patches. If there are no glaring errors or omissions, please consider committing them. * The patches update the 'ipfw' man page to document the new feature. * Compatibility: using an unpatched ipfw with a patched kernel or using a patched ipfw with an unpatched kernel should work just fine with normal rules (the 'lifetime' feature will not work). Thank you. Aaron Gifford *** NOTE: Patches to the latest CVS versions of the relevant source *** files are included below in the "Fix:" section. These patches *** should apply cleanly to FreeBSD-CURRENT. Feel free to e-mail *** me for patches that apply cleanly to FreeBSD-STABLE. >How-To-Repeat: N/A - See above description or patches below >Fix: Commit the patches below. --- /usr/src/sys/netinet/ip_fw.h.orig Tue Feb 20 11:39:17 2001 +++ /usr/src/sys/netinet/ip_fw.h Thu Jul 5 03:46:51 2001 @@ -74,6 +74,7 @@ u_short fu_skipto_rule; /* SKIPTO command rule number */ u_short fu_reject_code; /* REJECT response code */ struct sockaddr_in fu_fwd_ip; + u_int32_t fu_dyn_lifetime; /* Explicit dynamic rule lifetime */ } fw_un; u_char fw_prot; /* IP protocol */ /* @@ -122,6 +123,7 @@ #define fw_reject_code fw_un.fu_reject_code #define fw_pipe_nr fw_un.fu_pipe_nr #define fw_fwd_ip fw_un.fu_fwd_ip +#define fw_dyn_lifetime fw_un.fu_dyn_lifetime struct ip_fw_chain { LIST_ENTRY(ip_fw_chain) next; @@ -148,6 +150,7 @@ struct ipfw_flow_id mask ; struct ip_fw_chain *chain ; /* pointer to parent rule */ u_int32_t type ; /* rule type */ + u_int32_t lifetime ; /* per-rule specified lifetime */ u_int32_t expire ; /* expire time */ u_int64_t pcnt, bcnt; /* match counters */ u_int32_t bucket ; /* which bucket in hash table */ --- /usr/src/sys/netinet/ip_fw.c.orig Mon Jul 2 15:50:31 2001 +++ /usr/src/sys/netinet/ip_fw.c Thu Jul 5 03:46:51 2001 @@ -763,7 +763,7 @@ break ; case TH_SYN | (TH_SYN << 8) : /* move to established */ - q->expire = time_second + dyn_ack_lifetime ; + q->expire = time_second + (q->lifetime ? q->lifetime : dyn_ack_lifetime) ; break ; case TH_SYN | (TH_SYN << 8) | TH_FIN : case TH_SYN | (TH_SYN << 8) | (TH_FIN << 8) : @@ -788,7 +788,7 @@ } } else { /* should do something for UDP and others... */ - q->expire = time_second + dyn_short_lifetime ; + q->expire = time_second + (q->lifetime ? q->lifetime : dyn_short_lifetime) ; } if (match_direction) *match_direction = dir ; @@ -834,7 +834,13 @@ if (mask) r->mask = *mask ; r->id = *id ; - r->expire = time_second + dyn_syn_lifetime ; + r->lifetime = chain->rule->fw_dyn_lifetime ; + if (r->lifetime) + r->expire = time_second + r->lifetime ; + else if (r->id.proto == IPPROTO_TCP) + r->expire = time_second + dyn_syn_lifetime ; + else + r->expire = time_second + dyn_short_lifetime ; r->chain = chain ; r->type = ((struct ip_fw_ext *)chain->rule)->dyn_type ; --- /usr/src/sbin/ipfw/ipfw.c.orig Sun Jul 1 22:00:26 2001 +++ /usr/src/sbin/ipfw/ipfw.c Thu Jul 5 03:46:51 2001 @@ -377,6 +377,8 @@ printf(" keep-state %d", (int)chain->next_rule_ptr); else printf(" keep-state"); + if (chain->fw_dyn_lifetime) + printf(" lifetime %d", (int)chain->fw_dyn_lifetime); } /* Direction */ if (chain->fw_flg & IP_FW_BRIDGED) @@ -917,6 +919,7 @@ " tcpack {acknowledgement number}\n" " tcpwin {window size}\n" " icmptypes {type[, type]}...\n" +" keep-state [lifetime {number of seconds}]\n" " pipeconfig:\n" " {bw|bandwidth} {bit/s|Kbit/s|Mbit/s|Bytes/s|KBytes/s|MBytes/s}\n" " {bw|bandwidth} interface_name\n" @@ -1971,6 +1974,15 @@ if (ac > 0 && (type = atoi(*av)) != 0) { (int)rule.next_rule_ptr = type; av++; ac--; + } + if (ac > 0 && !strncmp(*av,"lifetime",strlen(*av))) { + u_long lifetime; + + av++; ac--; + if (ac > 0 && (lifetime = atoi(*av)) != 0) { + rule.fw_dyn_lifetime = lifetime; + av++; ac--; + } } } else if (!strncmp(*av, "bridged", strlen(*av))) { rule.fw_flg |= IP_FW_BRIDGED; --- /usr/src/sbin/ipfw/ipfw.8.orig Wed Jun 6 20:56:56 2001 +++ /usr/src/sbin/ipfw/ipfw.8 Thu Jul 5 03:46:51 2001 @@ -640,18 +640,38 @@ interface. .It Ar options : .Bl -tag -width indent -.It Cm keep-state Op Ar method +.It Xo Cm keep-state Op Ar method +.Op Cm lifetime Ar number +.Xc Upon a match, the firewall will create a dynamic rule, whose -default behaviour is to matching bidirectional traffic between +default behaviour is to match bidirectional traffic between source and destination IP/port using the same protocol. -The rule has a limited lifetime (controlled by a set of +The rule has a limited lifetime controlled by a set of .Xr sysctl 8 -variables), and the lifetime is refreshed every time a matching -packet is found. +variables that may be overridden on a per-rule basis. +The lifetime is refreshed each time a matching packet is +found. .Pp The actual behaviour can be modified by specifying a different .Ar method , although at the moment only the default one is specified. +.Pp +The default rule lifetime may be overridden for a specific +rule by appending +.Cm lifetime Ar number +to explicitly set the number of seconds for the dynamic rule +lifetime. +.Pp +For TCP rules, explicitly setting a rule lifetime overrides the +default setting stored in the +.Xr sysctl 8 +variable +.Em net.inet.ip.fw.dyn_ack_lifetime . +For non-TCP rules, it overrides the +.Xr sysctl 8 +variable +.Em net.inet.ip.fw.dyn_short_lifetime +instead. .It Cm bridged Matches only bridged packets. This can be useful for multicast or broadcast traffic, which To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 5 2:34:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from void.xpert.com (xpert.com [199.203.132.1]) by hub.freebsd.org (Postfix) with ESMTP id 78CD137B403 for ; Thu, 5 Jul 2001 02:34:10 -0700 (PDT) (envelope-from Yonatan@xpert.com) Received: from mailserv.xpert.com ([199.203.132.135]) by void.xpert.com with esmtp (Exim 3.20 #1) id 15I5Va-0006PK-00 for freebsd-net@freebsd.org; Thu, 05 Jul 2001 12:33:14 +0300 Received: by mailserv.xpert.com with Internet Mail Service (5.5.2650.21) id <3GHBY39K>; Thu, 5 Jul 2001 12:33:56 +0300 Message-ID: From: Yonatan Bokovza To: "'freebsd-net@freebsd.org'" Subject: IP layer API Date: Thu, 5 Jul 2001 12:33:49 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="WINDOWS-1255" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, How can I send/receive packets at the IP layer? I read many sockets tutorials, including the one at the dev-handbook, but they only deal with higher level of protocols (TCP/UDP). I need to send out packet where I can control it's ip_checksum, ip_frag etc, and read back the reply. I prefer not to use libnet for that. TIA, Yonatan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 5 3:21:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from shadow.otel.net (JuDiCaToR.OTEL.net [212.36.9.113]) by hub.freebsd.org (Postfix) with ESMTP id 54B3237B401 for ; Thu, 5 Jul 2001 03:21:24 -0700 (PDT) (envelope-from tbyte@tbyte.org) Received: from localhost (localhost [127.0.0.1]) by shadow.otel.net (8.11.4/8.11.1) with ESMTP id f65AL1K74660; Thu, 5 Jul 2001 13:21:02 +0300 (EEST) (envelope-from tbyte@tbyte.org) Date: Thu, 5 Jul 2001 13:21:01 +0300 (EEST) From: Iasen Kostoff X-Sender: tbyte@shadow.otel.net To: Yonatan Bokovza Cc: "'freebsd-net@freebsd.org'" Subject: Re: IP layer API In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 5 Jul 2001, Yonatan Bokovza wrote: > Hi, > How can I send/receive packets at the IP layer? > I read many sockets tutorials, including the > one at the dev-handbook, but they only deal > with higher level of protocols (TCP/UDP). I > need to send out packet where I can control > it's ip_checksum, ip_frag etc, and read back > the reply. > I prefer not to use libnet for that. > You should use raw socket ( SOCK_RAW ) as : s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW); and if you want to manage manualy IP header you should set IP_HDRINCL for this socket : int on=1; setsockopt(s, IPPROTO_IP, IP_HDRINCL, (char *)&on, sizeof(on)) The reason for not including raw socket tutorials I think is that You can do a lot of bad things with it . So don't :-). The other reason may be the lack of usage. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 5 5:11:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from web13305.mail.yahoo.com (web13305.mail.yahoo.com [216.136.175.41]) by hub.freebsd.org (Postfix) with SMTP id E750A37B403 for ; Thu, 5 Jul 2001 05:11:39 -0700 (PDT) (envelope-from nuzrin@yahoo.com) Message-ID: <20010705121139.68943.qmail@web13305.mail.yahoo.com> Received: from [161.142.78.84] by web13305.mail.yahoo.com; Thu, 05 Jul 2001 05:11:39 PDT Date: Thu, 5 Jul 2001 05:11:39 -0700 (PDT) From: nuzrin Reply-To: p9711422@mmu.edu.my Subject: ng_bridge and altq To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi all...i just have one simple question. can altq work with ng_bridge if i were to use both of it to bridge and shape traffic? currently i'm using "options BRIDGE" in my kernel configuration and altq works flawlessly. i haven't got the chance to play around with ng_bridge because it's a production machine :( ohh...and btw, what is the difference between the two bridging implementation, if any, and which one is better? __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 5 10:52:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail4.home.nl (mail4.home.nl [213.51.129.228]) by hub.freebsd.org (Postfix) with ESMTP id 06F6337B405 for ; Thu, 5 Jul 2001 10:52:56 -0700 (PDT) (envelope-from nascar24@home.nl) Received: from testuser ([213.51.193.168]) by mail4.home.nl (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010705151811.CMRM407.mail4.home.nl@testuser> for ; Thu, 5 Jul 2001 16:18:11 +0100 Message-ID: <056b01c10565$9f5d9270$0900a8c0@testuser> From: "Marcel Dijk" To: Subject: samba question Date: Thu, 5 Jul 2001 17:17:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Disposition-Notification-To: "Marcel Dijk" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, If I try to access my Samba server (FreeBSD 4.2) from my Win2k machine I get this error: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The account is not authorized to log in from this station. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ What could it be? Thanks, Marcel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 5 11:34:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 3CD7637B407 for ; Thu, 5 Jul 2001 11:34:26 -0700 (PDT) (envelope-from matt-l@pacbell.net) Received: from fire (1Cust75.tnt1.pasadena.ca.da.uu.net [63.28.226.75]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id LAA18789; Thu, 5 Jul 2001 11:34:16 -0700 (PDT) Message-ID: <004b01c10580$32d97770$6503c23f@XGforce.com> Reply-To: "matt" From: "matt" To: "Yonatan Bokovza" , References: Subject: Re: IP layer API Date: Thu, 5 Jul 2001 11:26:21 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Refer to kernel code of icmp. there're examples regarding how to send packet with ip_output(). ====================================== WWW.XGFORCE.COM The Next Generation Load Balance and Fail Safe Server Clustering Software for the Internet. ====================================== ----- Original Message ----- From: Yonatan Bokovza To: Sent: Thursday, July 05, 2001 2:33 AM Subject: IP layer API > Hi, > How can I send/receive packets at the IP layer? > I read many sockets tutorials, including the > one at the dev-handbook, but they only deal > with higher level of protocols (TCP/UDP). I > need to send out packet where I can control > it's ip_checksum, ip_frag etc, and read back > the reply. > I prefer not to use libnet for that. > > TIA, > Yonatan > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 5 13:49:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from support.euronet.nl (support.euronet.nl [194.134.32.134]) by hub.freebsd.org (Postfix) with ESMTP id 7D7A937B42B for ; Thu, 5 Jul 2001 13:49:18 -0700 (PDT) (envelope-from frans@quanza.net) Received: from localhost (franst@localhost) by support.euronet.nl (8.11.3/8.11.0) with ESMTP id f65KnH370926 for ; Thu, 5 Jul 2001 22:49:17 +0200 (CEST) X-Authentication-Warning: support.euronet.nl: franst owned process doing -bs Date: Thu, 5 Jul 2001 22:49:17 +0200 (CEST) From: Frans ter Borg X-Sender: franst@support.euronet.nl To: net@freebsd.org Subject: multiple bridged networks on one box Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi, I have a box with 6 ethernetports. I would like two of the ports to bridge between eachother and use the other ports as router ports, without bridge processing or otherwise in separate L2 VLANs. I've seen the net.link.ether.bridge_cfg sysctl variable and I was thinking that using that I could possibly do this, but I would like to read up on it. I haven't been able to find a lot of data on this... It seems one can give a L2 vlan number to each port here, which would do this, but once again, I'm not too sure... Cheers, Frans -- Quanza Engineering To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 5 14:35: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 2FD1B37B407 for ; Thu, 5 Jul 2001 14:35:07 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA29243; Thu, 5 Jul 2001 16:05:24 -0700 (PDT) Date: Thu, 5 Jul 2001 16:05:23 -0700 (PDT) From: Julian Elischer To: Frans ter Borg Cc: net@freebsd.org Subject: Re: multiple bridged networks on one box In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org you can do this using netgraph bridging.. start with the example in /usr/share/examples/netgraph. julian On Thu, 5 Jul 2001, Frans ter Borg wrote: > hi, > > I have a box with 6 ethernetports. I would like two of the ports to bridge > between eachother and use the other ports as router ports, without bridge > processing or otherwise in separate L2 VLANs. > > I've seen the net.link.ether.bridge_cfg sysctl variable and I was thinking > that using that I could possibly do this, but I would like to read up on > it. I haven't been able to find a lot of data on this... > > It seems one can give a L2 vlan number to each port here, which would do > this, but once again, I'm not too sure... > > > Cheers, > > Frans > > -- > Quanza Engineering > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 5 15: 5: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns2.sysadmin-inc.com (ns2.sysadmin-inc.com [209.16.228.145]) by hub.freebsd.org (Postfix) with SMTP id C129137B407 for ; Thu, 5 Jul 2001 15:05:04 -0700 (PDT) (envelope-from peter@sysadmin-inc.com) Received: (qmail 1543 invoked by uid 89); 5 Jul 2001 22:05:03 -0000 Message-ID: <20010705220503.1542.qmail@ns2.sysadmin-inc.com> From: "Peter Brezny" To: freebsd-net@freebsd.org Subject: simple mpd-netgraph quesiton Date: Thu, 05 Jul 2001 22:05:03 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've got mpd-netgraph configured to load multiple pptp configurations on startup default: load pptp1 load pptp2 load pptp3 load pptp4 load pptp5 load pptp6 I just noticed today, however, this error message Jul 5 17:59:23 slgw mpd: mpd: bundle "pptp" already exists Jul 5 17:59:24 slgw last message repeated 4 times So I went back into the configuration file... My Question is, is it correct to have the new -i statement pointing to an identical set of information for each pptp configuration? E.G. pptp1: new -i ng0 pptp pptp ... pptp2: new -i ng0 pptp pptp OR, do I need to do something like this? pptp1: new -i ng0 pptp pptp1 ... pptp2: new -i ng1 pptp pptp2 Thanks for your help. Peter Brezny SysAdmin Services Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 5 20: 9:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id 8AC3137B401 for ; Thu, 5 Jul 2001 20:09:43 -0700 (PDT) (envelope-from bright@sneakerz.org) Received: by sneakerz.org (Postfix, from userid 1092) id 195D85D010; Thu, 5 Jul 2001 22:09:33 -0500 (CDT) Date: Thu, 5 Jul 2001 22:09:33 -0500 From: Alfred Perlstein To: net@freebsd.org Subject: checksum offloading Message-ID: <20010705220932.C79818@sneakerz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org How does one specify that an mbuf/mbuf-chain needs or doesn't need to have its IP/TCP checksum calculated? -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 5 23:30:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id 324B737B408; Thu, 5 Jul 2001 23:30:06 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost.softweyr.com ([127.0.0.1] helo=softweyr.com ident=599d54847f6b6c21166e63dfb8d0a377) by softweyr.com with esmtp (Exim 3.16 #1) id 15IPCi-00009m-00; Fri, 06 Jul 2001 00:35:04 -0600 Message-ID: <3B455C18.EB10C5DC@softweyr.com> Date: Fri, 06 Jul 2001 00:35:04 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Louis A. Mamakos" Cc: Bakul Shah , Ruslan Ermilov , Deepak Jain , net@FreeBSD.ORG Subject: Re: fastforwarding? References: <200107021954.PAA25927@goliath.cnchost.com> <3B41EB64.3B753DDE@softweyr.com> <200107041404.f64E44331564@whizzo.transsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Louis A. Mamakos" wrote: > > Most router benchmarks and testing processes these days test forwarding > capacity in the face of routing table churn, which is closer to the > real-world experience. Personally, I don't buy forwarding cache-based > routers because this is a sign that the underlying infrastucture > isn't fast enough and you're banking on the cache hit rate being high > enough to save your ass. Show me a $25,000 router that can route 10,000,000 packets per second and I'll MAYBE agree with you. Compare that to the average router with one or maybe two routes outside the organization, and an interior routing table that is either non-existant or trivial. This discussion has devolved into yet another idiotic bikeshed. Nobody claimed anwhere along the line that fastforwarding was a solution to all routing ills, suitable for use in a core router, or acceptable for any of the wildly esoteric CRAP espoused in the past 10 or 12 messages in this thread. If you don't like fastforwarding, don't use it, but don't get in the way of people who use it and maintain it. Sheesh. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 6 0:56:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from news.esiee.fr (news.esiee.fr [147.215.20.50]) by hub.freebsd.org (Postfix) with ESMTP id 4465437B40A for ; Fri, 6 Jul 2001 00:56:43 -0700 (PDT) (envelope-from bonnetf@news.esiee.fr) Received: by news.esiee.fr (Postfix, from userid 179) id 2FB8915B3C; Fri, 6 Jul 2001 09:56:41 +0200 (CEST) Date: Fri, 6 Jul 2001 09:56:40 +0200 From: Frank Bonnet To: freebsd-net@freebsd.org Subject: DHCP client gateway ? Message-ID: <20010706095640.B1923@news.esiee.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi I would like to setup a gateway for a home network that will be connected to a cable modem on one interface and on the home LAN on another interface. The two interfaces are ethernet boards. The problem is the cable ISP use DHCP to attribute IP addresses to client ( my gateway ) is there a way to build transparent IP gateway that receive a different IP address each time it connect to the Internet thru the cable modem ? Thanks for any info. Frank To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 6 7:16:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns2.sysadmin-inc.com (ns2.sysadmin-inc.com [209.16.228.145]) by hub.freebsd.org (Postfix) with SMTP id EC78537B401 for ; Fri, 6 Jul 2001 07:16:23 -0700 (PDT) (envelope-from peter@sysadmin-inc.com) Received: (qmail 1424 invoked by alias); 6 Jul 2001 14:16:23 -0000 Received: from unknown (HELO 98wkst) (10.10.1.70) by ns2.sysadmin-inc.com with SMTP; 6 Jul 2001 14:16:23 -0000 From: "Peter Brezny" To: Subject: FW: simple mpd-netgraph quesiton Date: Fri, 6 Jul 2001 10:15:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I just found this explained in the latest sample conf file. Sorry for the previous post. The original conf file I was looking at didn't have it as completely explained. Peter Brezny SysAdmin Services Inc. -----Original Message----- From: owner-freebsd-net@FreeBSD.ORG [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Peter Brezny Sent: Thursday, July 05, 2001 6:05 PM To: freebsd-net@freebsd.org Subject: simple mpd-netgraph quesiton I've got mpd-netgraph configured to load multiple pptp configurations on startup default: load pptp1 load pptp2 load pptp3 load pptp4 load pptp5 load pptp6 I just noticed today, however, this error message Jul 5 17:59:23 slgw mpd: mpd: bundle "pptp" already exists Jul 5 17:59:24 slgw last message repeated 4 times So I went back into the configuration file... My Question is, is it correct to have the new -i statement pointing to an identical set of information for each pptp configuration? E.G. pptp1: new -i ng0 pptp pptp ... pptp2: new -i ng0 pptp pptp OR, do I need to do something like this? pptp1: new -i ng0 pptp pptp1 ... pptp2: new -i ng1 pptp pptp2 Thanks for your help. Peter Brezny SysAdmin Services Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 6 10:37:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 8425637B405 for ; Fri, 6 Jul 2001 10:37:16 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA33496; Fri, 6 Jul 2001 12:06:01 -0700 (PDT) Date: Fri, 6 Jul 2001 12:05:59 -0700 (PDT) From: Julian Elischer To: Frank Bonnet Cc: freebsd-net@freebsd.org Subject: Re: DHCP client gateway ? In-Reply-To: <20010706095640.B1923@news.esiee.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I believe NATD now listens to routing sockets and updates it's tables when there is a change of address for an interface. Also I think that dhclient MAY be able to be used (maybe it's output) to trigger a script... On Fri, 6 Jul 2001, Frank Bonnet wrote: > Hi > > I would like to setup a gateway for a home network that will > be connected to a cable modem on one interface and on the > home LAN on another interface. > The two interfaces are ethernet boards. > The problem is the cable ISP use DHCP to attribute IP addresses > to client ( my gateway ) is there a way to build transparent IP > gateway that receive a different IP address each time it connect > to the Internet thru the cable modem ? > > Thanks for any info. > > Frank > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 6 11:37:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from illustrious.cnchost.com (illustrious.concentric.net [207.155.252.7]) by hub.freebsd.org (Postfix) with ESMTP id 5224D37B408; Fri, 6 Jul 2001 11:37:45 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by illustrious.cnchost.com id OAA27501; Fri, 6 Jul 2001 14:37:37 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200107061837.OAA27501@illustrious.cnchost.com> To: Wes Peters Cc: "Louis A. Mamakos" , Ruslan Ermilov , Deepak Jain , net@FreeBSD.ORG Subject: Re: fastforwarding? In-reply-to: Your message of "Fri, 06 Jul 2001 00:35:04 MDT." <3B455C18.EB10C5DC@softweyr.com> Date: Fri, 06 Jul 2001 11:37:37 -0700 From: Bakul Shah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > This discussion has devolved into yet another idiotic bikeshed. Nobody > claimed anwhere along the line that fastforwarding was a solution to > all routing ills, suitable for use in a core router, or acceptable for > any of the wildly esoteric CRAP espoused in the past 10 or 12 messages > in this thread. If you don't like fastforwarding, don't use it, but > don't get in the way of people who use it and maintain it. I don't think you realize that as implemented it is not suitable for *any* router with even a single host that will send to hundreds of thousands of distinct ip addresses over any period of time. It doesn't matter if all the router has is a single default route in its route table because it creates a new cache entry for *every* destination address to which it successfully forwards a packet. Consider H ---- R ----> internet R, a freebsd machine running fastforwarding code, has a single default route to an upstream machine. Now on H all you have to do is something like a = while (a++) { to.sin_addr.s_addr = htonl(a); sendto(s, msg, msglen, 0, (struct sockaddr*)&to, sizeof to); } and R's cache will be filled up real quick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 6 11:42:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from herbelot.dyndns.org (d020.dhcp212-27.cybercable.fr [212.198.27.20]) by hub.freebsd.org (Postfix) with ESMTP id F0CA037B407 for ; Fri, 6 Jul 2001 11:42:49 -0700 (PDT) (envelope-from thierry@herbelot.com) Received: from herbelot.com (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id UAA10988; Fri, 6 Jul 2001 20:41:36 +0200 (CEST) (envelope-from thierry@herbelot.com) Message-ID: <3B46065D.74586950@herbelot.com> Date: Fri, 06 Jul 2001 20:41:33 +0200 From: Thierry Herbelot X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 Cc: Frank Bonnet , freebsd-net@FreeBSD.ORG Subject: Re: DHCP client gateway ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I can confirm that natd can be used even with a DHCP setup (natd -dynamic, this works even in 3.x) - as a matter of fact, that's how I've had my 'net connection for the last three years ;-)) Julian Elischer wrote: > > I believe NATD now listens to routing sockets > and updates it's tables when there is a change of address for an > interface. Also I think that dhclient MAY be able to be used (maybe it's > output) to trigger a script... > > On Fri, 6 Jul 2001, Frank Bonnet wrote: > > > Hi > > > > I would like to setup a gateway for a home network that will > > be connected to a cable modem on one interface and on the > > home LAN on another interface. > > The two interfaces are ethernet boards. > > The problem is the cable ISP use DHCP to attribute IP addresses > > to client ( my gateway ) is there a way to build transparent IP > > gateway that receive a different IP address each time it connect > > to the Internet thru the cable modem ? > > > > Thanks for any info. > > > > Frank -- Thierry Herbelot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 6 12:29:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by hub.freebsd.org (Postfix) with ESMTP id F0A5137B401 for ; Fri, 6 Jul 2001 12:29:36 -0700 (PDT) (envelope-from hsu@FreeBSD.org) Received: from FreeBSD.org ([63.193.112.125]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GG200FKGGTCAO@mta7.pltn13.pbi.net> for freebsd-net@FreeBSD.ORG; Fri, 06 Jul 2001 12:29:36 -0700 (PDT) Date: Fri, 06 Jul 2001 12:29:23 -0700 From: Jeffrey Hsu Subject: Re: Operation now in progress In-reply-to: Message from Vlad Marchenko "of Wed, 04 Jul 2001 23:47:12 +0300." <023401c104ca$829d0d00$6a7a01d4@kuzya> To: Vlad Marchenko Cc: freebsd-net@FreeBSD.ORG Message-id: <0GG200FKHGTCAO@mta7.pltn13.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.1.1 10/15/1999 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org You may have run into the sequence number went backwards problem. Try the recent patch by silby. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 6 18:20:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by hub.freebsd.org (Postfix) with ESMTP id 60E6237B403 for ; Fri, 6 Jul 2001 18:20:38 -0700 (PDT) (envelope-from vijay@iprg.nokia.com) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA12345 for ; Fri, 6 Jul 2001 18:20:38 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f671Kbx13253 for ; Fri, 6 Jul 2001 18:20:37 -0700 X-mProtect: Fri, 6 Jul 2001 18:20:37 -0700 Nokia Silicon Valley Messaging Protection Received: from dhcp-3-142.iprg.nokia.com (205.226.3.142, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdmrLRfS; Fri, 06 Jul 2001 18:20:33 PDT Message-ID: <3B4663D1.878F062F@iprg.nokia.com> Date: Fri, 06 Jul 2001 18:20:17 -0700 From: vijay singh Organization: nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: net@freebsd.org Subject: inetd, select and read Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I have a quick question. If I have a service started by the inetd should I include a select before the first read in the service. In otherwords, does inetd transfer the socket (as stdin, out and err) on a connect call or with after it. thanks vijay To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 7 12: 1:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from h132-197-97-45.gte.com (h132-197-97-45.gte.com [132.197.97.45]) by hub.freebsd.org (Postfix) with ESMTP id 90F6037B406; Sat, 7 Jul 2001 12:01:30 -0700 (PDT) (envelope-from ak03@gte.com) Received: (from ak03@localhost) by h132-197-97-45.gte.com (8.11.4/8.11.4) id f67J1Ta01045; Sat, 7 Jul 2001 15:01:29 -0400 (EDT) (envelope-from ak03) Date: Sat, 7 Jul 2001 15:01:29 -0400 From: "Alexander N. Kabaev" To: freebsd-current@FreeBSD.org Cc: freebsd-net@FreeBSD.org Subject: This can't be right (bug in ip6_output.c) Message-ID: <20010707150129.A910@kanpc.gte.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.19i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following code in netinet6/ip6_output.c:1673 just cannot be right: case IPV6_FW_GET: { struct mbuf *m; struct mbuf **mp = &m; if (ip6_fw_ctl_ptr == NULL) { if (m) (void)m_free(m); return EINVAL; } error = (*ip6_fw_ctl_ptr)(optname, mp); if (error == 0) error = soopt_mcopyout(sopt, m); /* XXX */ if (error == 0 && m) m_freem(m); } break; The m_free call in the ip6_fw_ctl_ptr == NULL case apparently tries to free uninitialized mbuf. -- Alexander Kabaev P.S. Below is the patch to remove bogus m_free call: Index: ip6_output.c =================================================================== RCS file: /usr/ncvs/src/sys/netinet6/ip6_output.c,v retrieving revision 1.28 diff -u -r1.28 ip6_output.c --- ip6_output.c 2001/06/24 20:25:38 1.28 +++ ip6_output.c 2001/07/07 18:57:51 @@ -1668,11 +1668,7 @@ struct mbuf **mp = &m; if (ip6_fw_ctl_ptr == NULL) - { - if (m) - (void)m_free(m); return EINVAL; - } error = (*ip6_fw_ctl_ptr)(optname, mp); if (error == 0) error = soopt_mcopyout(sopt, m); /* XXX */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 7 13: 1: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id 5EB0C37B405; Sat, 7 Jul 2001 13:01:03 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:BwAwNM3a2S3hex8OSDf8AKP4dymDoeVGD5gWnMts9BVdzuJWghQtfhJgjXlrbujo@localhost [::1]) (authenticated as ume with CRAM-MD5) by peace.mahoroba.org (8.11.4/8.11.4/peace) with ESMTP/inet6 id f67K0rv59781; Sun, 8 Jul 2001 05:00:53 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 08 Jul 2001 05:00:49 +0900 (JST) Message-Id: <20010708.050049.74713091.ume@mahoroba.org> To: ak03@gte.com Cc: freebsd-current@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: This can't be right (bug in ip6_output.c) From: Hajimu UMEMOTO In-Reply-To: <20010707150129.A910@kanpc.gte.com> References: <20010707150129.A910@kanpc.gte.com> X-Mailer: xcite1.38> Mew version 1.95b119 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-Operating-System: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Sat, 7 Jul 2001 15:01:29 -0400 >>>>> "Alexander N. Kabaev" said: ak03> The following code in netinet6/ip6_output.c:1673 just cannot be right: ak03> The m_free call in the ip6_fw_ctl_ptr == NULL case apparently tries to free ak03> uninitialized mbuf. Oops, it was my mistake during recent KAME merge. This part is for *BSD other than FreeBSD. I just committed the fix. Thank you for reporting it. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 7 15: 6:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id F056237B405; Sat, 7 Jul 2001 15:06:17 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:Rat3b1V0t2eZLK06oKCv25PwfaRCMPEB5N7LLZ0epVmtfHOeEVnf94pLmF+9hRNK@localhost [::1]) (authenticated as ume with CRAM-MD5) by peace.mahoroba.org (8.11.4/8.11.4/peace) with ESMTP/inet6 id f67M6Df37361; Sun, 8 Jul 2001 07:06:14 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 08 Jul 2001 07:06:10 +0900 (JST) Message-Id: <20010708.070610.74741066.ume@mahoroba.org> To: hackers@freebsd.org, net@freebsd.org Subject: Fw: Fwd: (SIOCAIFADDR) Please help me! From: Hajimu UMEMOTO X-Mailer: Mew version 1.95b119 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-Operating-System: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Jul__8_07:06:10_2001_142)--" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ----Next_Part(Sun_Jul__8_07:06:10_2001_142)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eduardo, your mail host (200.190.143.201) seems to have no PTR RR. ----Next_Part(Sun_Jul__8_07:06:10_2001_142)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: (from uucp@localhost) by mail.mahoroba.org (8.11.4/8.11.4/chaos) with UUCP id f67LotZ10291 for ume@mahoroba.org; Sun, 8 Jul 2001 06:50:55 +0900 (JST) (envelope-from ebf@cwb.fnn.net) Received: from cwb.fnn.net ([200.190.143.201]) by light.imasy.or.jp (8.11.3+3.4W/8.11.3/light) with SMTP/inet id f67Lo2B17435 for ; Sun, 8 Jul 2001 06:50:05 +0900 (JST) (envelope-from ebf@cwb.fnn.net) Received: (qmail 78571 invoked by uid 85); 7 Jul 2001 21:56:36 -0000 Received: from ebf@cwb.fnn.net by aline.cwb.fnn.net with FutureMail-ViruScanner-Por_Eduardo_B._Fonseca-0.96 (uvscan: v4.1.40/v4145. . Clean. Processed in 0.290295 secs); 07 Jul 2001 21:56:36 -0000 Received: from unknown (HELO peugeot206.cwb.fnn.net) (200.190.143.160) by aline.cwb.fnn.net with SMTP; 7 Jul 2001 21:56:36 -0000 Content-Type: text/plain; charset="iso-8859-1" From: "Eduardo B. Fonseca" Organization: A&D Solucoes Ltda. To: Hajimu UMEMOTO Subject: Fwd: (SIOCAIFADDR) Please help me! Date: Sat, 7 Jul 2001 18:50:08 -0300 X-Mailer: KMail [version 1.2] Message-Id: <01070718500804.00297@peugeot206.cwb.fnn.net> X-MIME-Autoconverted: from quoted-printable to 8bit by mail.mahoroba.org id f67LotZ10291 Mime-Version: 1.0 (modified by Mew) Content-Transfer-Encoding: quoted-printable (modified by Mew) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mr. Umemoto, Sorry to bother you. I'm trying to send this e-mail to the mailing lis= t but = (although I'm subscribed) It just doesn't work. Could you please, relay= this = to the freebsd-net and freebsd-hackers list? I can receive any e-mails = to the = list but I can't send. = Thanks a lot! Eduardo. - ---------- Forwarded Message ---------- Subject: (SIOCAIFADDR) Please help me! Date: Sat, 7 Jul 2001 18:37:14 -0300 From: Eduardo B. Fonseca To: freebsd-hackers@freebsd.org, hackers@freebsd.org, = freebsd-net@freebsd.org, net@freebsd.org Hello guys, =A0=A0=A0=A0=A0=A0=A0=A0 Please... What's wrong with the code below? So= metimes it works, sometimes it doesn't. Yesterday, I've tested it and everything worked f= ine... Now, everytime I try to set the machine's IP address with this code, it= does not work... It sets a bogus IP, with a bogus netmask... I'm stumped... I can't find documentation anywhere. void Interface:: AddAddressOnInterface(int sockfd, string ip, string netmsk, string broa= daddr) { =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 struct =A0=A0=A0=A0=A0=A0= =A0=A0 ifaliasreq =A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 request; =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 bzero (&request, sizeof(= struct ifaliasreq)); =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 strcpy(request.ifra_name= ,deviceName.c_str()); =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 request.ifra_addr.sa_fam= ily=A0=A0=A0=A0 =3D AF_INET; =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 inet_pton(AF_INET, ip.c_= str(), &((struct sockaddr_in *)&request.ifra_addr)->sin_addr); =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 inet_pton(AF_INET, netms= k.c_str(), &((struct sockaddr_in *)&request.ifra_mask)->sin_addr); =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 inet_pton(AF_INET, broad= addr.c_str(), &((struct sockaddr_in *)&request.ifra_broadaddr)->sin_addr); =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 ioctl(sockfd,SIOCAIFADDR= ,&request); } Thanks for any help. Regards, Eduardo. - ------------------------------------------------------- - -- = Eduardo B. Fonseca Diretor Regional Curitiba FutureNet Telecomunica=E7=F5es e Inform=E1tica Ltda ebf@cwb.fnn.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7R4QQf9aI6FhScUkRAqj4AJ9R83iKO+qQlzPvEun7tIWxgc+ERgCgrOqG wK5nfbFrAKf2IHK+A93VLl4=3D =3DJEsw -----END PGP SIGNATURE----- ----Next_Part(Sun_Jul__8_07:06:10_2001_142)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 7 18:39:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id EA7F937B405 for ; Sat, 7 Jul 2001 18:39:22 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost.softweyr.com ([127.0.0.1] helo=softweyr.com ident=4cf4f64844ca4c7dd005328c4b295265) by softweyr.com with esmtp (Exim 3.16 #1) id 15J3cj-0000Kj-00; Sat, 07 Jul 2001 19:44:37 -0600 Message-ID: <3B47BB05.36E32094@softweyr.com> Date: Sat, 07 Jul 2001 19:44:37 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Bakul Shah Cc: net@FreeBSD.ORG Subject: Re: fastforwarding? References: <200107061837.OAA27501@illustrious.cnchost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bakul Shah wrote: > > > This discussion has devolved into yet another idiotic bikeshed. Nobody > > claimed anwhere along the line that fastforwarding was a solution to > > all routing ills, suitable for use in a core router, or acceptable for > > any of the wildly esoteric CRAP espoused in the past 10 or 12 messages > > in this thread. If you don't like fastforwarding, don't use it, but > > don't get in the way of people who use it and maintain it. > > I don't think you realize that as implemented it is not > suitable for *any* router with even a single host that will > send to hundreds of thousands of distinct ip addresses over > any period of time. Timeouts? The number of machines in my domain -- either of them -- that run through hundreds of thousands of distinct ip addresses and keep them active for any length of time is ZERO. You're FUDding away on this point because you haven't bothered to read the code. Fastforwarding will create at most IPFLOW_MAX routes, defined as 256 in 4.3-STABLE. It times out unused routes as needed every IPFLOW_ TIMER (default 5 * PR_SLOWHZ) seconds. Please come back when you have actually read the code. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message