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 <wes@softweyr.com>
Cc: Ruslan Ermilov <ru@FreeBSD.org>, Deepak Jain <deepak@ai.net>,
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 <bakul@bitblocks.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <wes@softweyr.com>
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 <ru@FreeBSD.ORG>
Cc: Dag-Erling Smorgrav <des@ofug.org>, Deepak Jain <deepak@ai.net>,
net@FreeBSD.ORG, hackers@FreeBSD.ORG
Subject: Re: fastforwarding?
References: <GPEOJKGHAMKFIOMAGMDICEOJDGAA.deepak@ai.net> <20010626093545.D49992@sunbay.com> <3B3AB4F8.184A2EFE@softweyr.com> <xzp1yo4wdjh.fsf@flood.ping.uio.no> <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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <wes@softweyr.com>
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 <bakul@bitblocks.com>
Cc: Ruslan Ermilov <ru@FreeBSD.org>, Deepak Jain <deepak@ai.net>,
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@freebsd.org>; 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 <silby@silby.com>
To: Jonathan Lemon <jlemon@flugsvamp.com>
Cc: Glenn Johnson <gjohnson@srrc.ars.usda.gov>, <net@freebsd.org>,
<kris@freebsd.org>, Gilbert Gong <ggong@cal.alumni.berkeley.edu>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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: <y7vr8vzkfqp.wl@condor2.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
To: "Kevin Oberman" <oberman@es.net>
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: <y7v1yo4jb9p.wl@condor2.jinmei.org>
<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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
>>>>> On Fri, 29 Jun 2001 09:28:54 -0700,
>>>>> "Kevin Oberman" <oberman@es.net> 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 <freebsd-net@FreeBSD.ORG>; 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 <freebsd-net@FreeBSD.ORG>; Mon, 2 Jul 2001 15:34:28 +0900 (JST)
Date: Mon, 02 Jul 2001 15:33:07 +0900
Message-ID: <y7vpubjkfh8.wl@condor2.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
To: freebsd-net@FreeBSD.ORG
Subject: Re: Odd IPv6 behavior when not connected to IPv6 net
In-Reply-To: <y7vr8vzkfqp.wl@condor2.jinmei.org>
References: <y7v1yo4jb9p.wl@condor2.jinmei.org>
<200106291628.f5TGSsc13240@ptavv.es.net>
<y7vr8vzkfqp.wl@condor2.jinmei.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
>>>>> On Mon, 02 Jul 2001 15:27:26 +0900,
>>>>> JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp.csl.rdc.toshiba.co.jp> said:
>>>>> On Fri, 29 Jun 2001 09:28:54 -0700,
>>>>> "Kevin Oberman" <oberman@es.net> 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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" <vlady@rila.bg>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@FreeBSD.ORG>; 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 <ru@FreeBSD.ORG>
To: Wes Peters <wes@softweyr.com>
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 <wes@softweyr.com>, net@FreeBSD.ORG
References: <GPEOJKGHAMKFIOMAGMDICEOJDGAA.deepak@ai.net> <20010626093545.D49992@sunbay.com> <3B3AB4F8.184A2EFE@softweyr.com> <xzp1yo4wdjh.fsf@flood.ping.uio.no> <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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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<UP,POINTOPOINT,RUNNING,MULTICAST> 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 <tbyte@tbyte.org>
X-Sender: tbyte@shadow.otel.net
To: Ruslan Ermilov <ru@FreeBSD.ORG>
Cc: Wes Peters <wes@softweyr.com>, net@FreeBSD.ORG
Subject: Re: Indirect route with also indirect gateway (was: Re: fastforwarding?)
In-Reply-To: <20010702115129.A67459@sunbay.com>
Message-ID: <Pine.BSF.4.21.0107021208010.8303-100000@shadow.otel.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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<UP,POINTOPOINT,RUNNING,MULTICAST> 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 <net@FreeBSD.org>; 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 <ru@FreeBSD.org>
To: Iasen Kostoff <tbyte@tbyte.org>
Cc: net@FreeBSD.org
Subject: Re: Indirect route with also indirect gateway
Message-ID: <20010702152631.C77685@sunbay.com>
Mail-Followup-To: Iasen Kostoff <tbyte@tbyte.org>, net@FreeBSD.org
References: <20010702130910.A77685@sunbay.com> <Pine.BSF.4.21.0107021312150.8303-100000@shadow.otel.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.BSF.4.21.0107021312150.8303-100000@shadow.otel.net>; from tbyte@tbyte.org on Mon, Jul 02, 2001 at 01:16:19PM +0300
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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<UP,POINTOPOINT,RUNNING,MULTICAST> 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 <tbyte@tbyte.org>
X-Sender: tbyte@shadow.otel.net
To: Ruslan Ermilov <ru@FreeBSD.ORG>
Cc: net@FreeBSD.ORG
Subject: Re: Indirect route with also indirect gateway
In-Reply-To: <20010702152631.C77685@sunbay.com>
Message-ID: <Pine.BSF.4.21.0107021534090.8303-100000@shadow.otel.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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<UP,POINTOPOINT,RUNNING,MULTICAST> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 212.36.9.113 netmask 0xffffff00 broadcast 212.36.9.255
ether 00:04:76:22:15:83
media: autoselect (100baseTX <full-duplex>) status: active
supported media: autoselect 100baseTX <full-duplex> 100baseTX
10baseT/UT
P <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
xl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex> 100baseTX
10baseT/UT
P <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
xl2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex> 100baseTX
10baseT/UT
P <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
ed0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <net@FreeBSD.ORG>; 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 <ru@FreeBSD.ORG>
To: Iasen Kostoff <tbyte@tbyte.org>
Cc: net@FreeBSD.ORG
Subject: Re: Indirect route with also indirect gateway
Message-ID: <20010702165817.B96697@sunbay.com>
Mail-Followup-To: Iasen Kostoff <tbyte@tbyte.org>, net@FreeBSD.ORG
References: <20010702152631.C77685@sunbay.com> <Pine.BSF.4.21.0107021534090.8303-100000@shadow.otel.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.BSF.4.21.0107021534090.8303-100000@shadow.otel.net>; from tbyte@tbyte.org on Mon, Jul 02, 2001 at 04:34:40PM +0300
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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<UP,POINTOPOINT,RUNNING,MULTICAST> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> inet 212.36.9.113 netmask 0xffffff00 broadcast 212.36.9.255
> ether 00:04:76:22:15:83
> media: autoselect (100baseTX <full-duplex>) status: active
> supported media: autoselect 100baseTX <full-duplex> 100baseTX
> 10baseT/UT
> P <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
> xl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex> 100baseTX
> 10baseT/UT
> P <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
> xl2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex> 100baseTX
> 10baseT/UT
> P <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
> ed0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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: <UP,GATEWAY,DONE,STATIC,PRCLONING>
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: <UP,GATEWAY,DONE,STATIC,PRCLONING>
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 <tbyte@tbyte.org>
X-Sender: tbyte@shadow.otel.net
To: Ruslan Ermilov <ru@FreeBSD.ORG>
Cc: net@FreeBSD.ORG
Subject: Re: Indirect route with also indirect gateway
In-Reply-To: <20010702165817.B96697@sunbay.com>
Message-ID: <Pine.BSF.4.21.0107021720180.8303-100000@shadow.otel.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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<UP,POINTOPOINT,RUNNING,MULTICAST> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > inet 212.36.9.113 netmask 0xffffff00 broadcast 212.36.9.255
> > ether 00:04:76:22:15:83
> > media: autoselect (100baseTX <full-duplex>) status: active
> > supported media: autoselect 100baseTX <full-duplex> 100baseTX
> > 10baseT/UT
> > P <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
> > xl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex> 100baseTX
> > 10baseT/UT
> > P <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
> > xl2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex> 100baseTX
> > 10baseT/UT
> > P <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
> > ed0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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: <UP,GATEWAY,DONE,STATIC,PRCLONING>
> 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: <UP,GATEWAY,DONE,STATIC,PRCLONING>
> 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <tbyte@tbyte.org>
X-Sender: tbyte@shadow.otel.net
To: freebsd-net@freebsd.org
Subject: adding a route to host via interface
Message-ID: <Pine.BSF.4.21.0107021727470.8303-100000@shadow.otel.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@FreeBSD.org>; 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 <net@FreeBSD.org>; 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 <matusita@jp.FreeBSD.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <brooks@one-eyed-alien.net>
To: Vladimir Terziev <vlady@rila.bg>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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=?= <jinmei@isl.rdc.toshiba.co.jp>
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."
<y7vr8vzkfqp.wl@condor2.jinmei.org>
Date: Mon, 02 Jul 2001 10:15:21 -0700
From: "Kevin Oberman" <oberman@es.net>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
> Date: Mon, 02 Jul 2001 15:27:26 +0900
> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
> Sender: owner-freebsd-net@FreeBSD.ORG
>
> >>>>> On Fri, 29 Jun 2001 09:28:54 -0700,
> >>>>> "Kevin Oberman" <oberman@es.net> 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 <freebsd-net@FreeBSD.ORG>; 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 <freebsd-net@FreeBSD.ORG>; Tue, 3 Jul 2001 02:36:55 +0900 (JST)
Date: Tue, 03 Jul 2001 02:35:28 +0900
Message-ID: <y7vy9q744kf.wl@condor2.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
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: <y7vr8vzkfqp.wl@condor2.jinmei.org>
<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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
>>>>> On Mon, 02 Jul 2001 10:15:21 -0700,
>>>>> "Kevin Oberman" <oberman@es.net> 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 <gjohnson@srrc.ars.usda.gov>
To: Mike Silbersack <silby@silby.com>
Cc: Jonathan Lemon <jlemon@flugsvamp.com>, net@freebsd.org,
kris@freebsd.org, Gilbert Gong <ggong@cal.alumni.berkeley.edu>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <wes@softweyr.com>
Cc: Ruslan Ermilov <ru@FreeBSD.org>, Deepak Jain <deepak@ai.net>,
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 <bakul@bitblocks.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <hsu@FreeBSD.org>
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 <bakul@bitblocks.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <NMVDVFBB>; Mon, 2 Jul 2001 17:10:54 -0400
Message-ID: <3A6D367EA1EFD4118C9B00A0C9DD99D7064F5E@rerun.lucentctc.com>
From: "Cambria, Mike" <mcambria@avaya.com>
To: snap-users@kame.net,
"'freebsd-net@freebsd.org'" <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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <luigi@info.iet.unipi.it>
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 <hsu@FreeBSD.ORG>
Date: Mon, 2 Jul 2001 23:09:45 +0200 (CEST)
Cc: Bakul Shah <bakul@bitblocks.com>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <luigi@info.iet.unipi.it>
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 <hsu@FreeBSD.ORG>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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" <mcambria@avaya.com>
To: snap-users@kame.net
Cc: "'freebsd-net@freebsd.org'" <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 <itojun@iijlab.net>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <hsu@FreeBSD.org>
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 <bakul@bitblocks.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@freebsd.org>; 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 <silby@silby.com>
To: Glenn Johnson <gjohnson@srrc.ars.usda.gov>
Cc: Jonathan Lemon <jlemon@flugsvamp.com>, <net@freebsd.org>,
<kris@freebsd.org>, Gilbert Gong <ggong@cal.alumni.berkeley.edu>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <larse@ISI.EDU>
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'" <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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <larse@isi.edu> 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 <net@freebsd.org>; 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 <net@freebsd.org>; Tue, 3 Jul 2001 00:11:11 -0400
Mime-Version: 1.0
X-Sender: bjf@mail.samurai.com
Message-Id: <f05101003b766f52ce823@[192.168.1.34]>
Date: Tue, 3 Jul 2001 00:09:14 -0400
To: net@freebsd.org
From: Bryan Fullerton <bjf@samurai.com>
Subject: PPPoE latency
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@freebsd.org>; 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 <bright@sneakerz.org>
To: Bryan Fullerton <bjf@samurai.com>
Cc: net@freebsd.org
Subject: Re: PPPoE latency
Message-ID: <20010702233606.A84523@sneakerz.org>
References: <f05101003b766f52ce823@[192.168.1.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <f05101003b766f52ce823@[192.168.1.34]>; from bjf@samurai.com on Tue, Jul 03, 2001 at 12:09:14AM -0400
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
* Bryan Fullerton <bjf@samurai.com> [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 <net@FreeBSD.ORG>; 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 <bill@wjv.com>
To: Bryan Fullerton <bjf@samurai.com>
Cc: net@FreeBSD.ORG
Subject: Re: PPPoE latency
Message-ID: <20010703004307.E2458@wjv.com>
Reply-To: bv@wjv.com
References: <f05101003b766f52ce823@[192.168.1.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <f05101003b766f52ce823@[192.168.1.34]>; 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@freebsd.org>; 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: <f05101001b766fe1f011f@[192.168.1.34]>
In-Reply-To: <20010702233606.A84523@sneakerz.org>
References: <f05101003b766f52ce823@[192.168.1.34]>
<20010702233606.A84523@sneakerz.org>
Date: Tue, 3 Jul 2001 00:50:03 -0400
To: Alfred Perlstein <bright@sneakerz.org>
From: Bryan Fullerton <bjf@samurai.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@freebsd.org>; 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 <bright@sneakerz.org>
To: Bryan Fullerton <bjf@samurai.com>
Cc: net@freebsd.org
Subject: Re: PPPoE latency
Message-ID: <20010702235434.B84523@sneakerz.org>
References: <f05101003b766f52ce823@[192.168.1.34]> <20010702233606.A84523@sneakerz.org> <f05101001b766fe1f011f@[192.168.1.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <f05101001b766fe1f011f@[192.168.1.34]>; from bjf@samurai.com on Tue, Jul 03, 2001 at 12:50:03AM -0400
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
* Bryan Fullerton <bjf@samurai.com> [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 <net@FreeBSD.ORG>; 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: <f05101002b76700057320@[192.168.1.34]>
In-Reply-To: <20010703004307.E2458@wjv.com>
References: <f05101003b766f52ce823@[192.168.1.34]>
<20010703004307.E2458@wjv.com>
Date: Tue, 3 Jul 2001 01:02:22 -0400
To: bv@wjv.com
From: Bryan Fullerton <bjf@samurai.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@freebsd.org>; 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: <f05101000b767029b0e42@[192.168.1.34]>
In-Reply-To: <20010702235434.B84523@sneakerz.org>
References: <f05101003b766f52ce823@[192.168.1.34]>
<20010702233606.A84523@sneakerz.org>
<f05101001b766fe1f011f@[192.168.1.34]>
<20010702235434.B84523@sneakerz.org>
Date: Tue, 3 Jul 2001 01:11:49 -0400
To: Alfred Perlstein <bright@sneakerz.org>
From: Bryan Fullerton <bjf@samurai.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@freebsd.org>; 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 <bright@sneakerz.org>
To: Bryan Fullerton <bjf@samurai.com>
Cc: net@freebsd.org
Subject: Re: PPPoE latency
Message-ID: <20010703001534.D84523@sneakerz.org>
References: <f05101003b766f52ce823@[192.168.1.34]> <20010702233606.A84523@sneakerz.org> <f05101001b766fe1f011f@[192.168.1.34]> <20010702235434.B84523@sneakerz.org> <f05101000b767029b0e42@[192.168.1.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <f05101000b767029b0e42@[192.168.1.34]>; from bjf@samurai.com on Tue, Jul 03, 2001 at 01:11:49AM -0400
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
* Bryan Fullerton <bjf@samurai.com> [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 <net@freebsd.org>; 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: <f05101001b7670979d3e2@[192.168.1.34]>
In-Reply-To: <20010703001534.D84523@sneakerz.org>
References: <f05101003b766f52ce823@[192.168.1.34]>
<20010702233606.A84523@sneakerz.org>
<f05101001b766fe1f011f@[192.168.1.34]>
<20010702235434.B84523@sneakerz.org>
<f05101000b767029b0e42@[192.168.1.34]>
<20010703001534.D84523@sneakerz.org>
Date: Tue, 3 Jul 2001 01:42:29 -0400
To: Alfred Perlstein <bright@sneakerz.org>
From: Bryan Fullerton <bjf@samurai.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
At 12:15 AM -0500 7/3/01, Alfred Perlstein wrote:
>* Bryan Fullerton <bjf@samurai.com> [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 <freebsd-net@FreeBSD.ORG>; 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 <ru@FreeBSD.ORG>
To: Iasen Kostoff <tbyte@tbyte.org>
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 <tbyte@tbyte.org>,
freebsd-net@FreeBSD.ORG
References: <Pine.BSF.4.21.0107021727470.8303-100000@shadow.otel.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.BSF.4.21.0107021727470.8303-100000@shadow.otel.net>; from tbyte@tbyte.org on Mon, Jul 02, 2001 at 05:40:07PM +0300
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <guido@gvr.org>
To: freebsd-net@freebsd.org
Cc: Phil Regnauld <regnauld@starbsd.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <anders.lowinger@xelerated.com>
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 <luigi@info.iet.unipi.it>
Cc: Jeffrey Hsu <hsu@FreeBSD.ORG>, Bakul Shah <bakul@bitblocks.com>,
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <luigi@info.iet.unipi.it>
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 <anders.lowinger@xelerated.com>
Date: Tue, 3 Jul 2001 10:55:42 +0200 (CEST)
Cc: Jeffrey Hsu <hsu@FreeBSD.ORG>, Bakul Shah <bakul@bitblocks.com>,
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <hsu@FreeBSD.org>
Subject: Re: fastforwarding?
In-reply-to: Message from Luigi Rizzo <luigi@info.iet.unipi.it>
"of Tue, 03 Jul 2001 10:55:42 +0200." <200107030855.KAA43664@info.iet.unipi.it>
To: Luigi Rizzo <luigi@info.iet.unipi.it>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <luigi@info.iet.unipi.it>
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 <hsu@FreeBSD.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@FreeBSD.ORG>; 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 <vev@michvhf.com>
To: Bryan Fullerton <bjf@samurai.com>
Cc: <net@FreeBSD.ORG>
Subject: Re: PPPoE latency
In-Reply-To: <f05101002b76700057320@[192.168.1.34]>
Message-ID: <Pine.BSF.4.30.0107030706130.56876-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <tbyte@tbyte.org>
X-Sender: tbyte@shadow.otel.net
To: Ruslan Ermilov <ru@FreeBSD.ORG>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: adding a route to host via interface
In-Reply-To: <20010703105649.A6517@sunbay.com>
Message-ID: <Pine.BSF.4.21.0107031424440.35452-100000@shadow.otel.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <ru@FreeBSD.ORG>
To: Iasen Kostoff <tbyte@tbyte.org>
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 <tbyte@tbyte.org>,
freebsd-net@FreeBSD.ORG
References: <20010703105649.A6517@sunbay.com> <Pine.BSF.4.21.0107031424440.35452-100000@shadow.otel.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.BSF.4.21.0107031424440.35452-100000@shadow.otel.net>; from tbyte@tbyte.org on Tue, Jul 03, 2001 at 02:30:48PM +0300
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <tbyte@tbyte.org>
X-Sender: tbyte@shadow.otel.net
To: Ruslan Ermilov <ru@FreeBSD.ORG>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: adding a route to host via interface
In-Reply-To: <20010703150441.B39090@sunbay.com>
Message-ID: <Pine.BSF.4.21.0107031514520.35452-100000@shadow.otel.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@FreeBSD.ORG>; 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 <bill@wjv.com>
To: Bryan Fullerton <bjf@samurai.com>
Cc: bv@wjv.com, net@FreeBSD.ORG
Subject: Re: PPPoE latency
Message-ID: <20010703091456.E5516@wjv.com>
Reply-To: bv@wjv.com
References: <f05101003b766f52ce823@[192.168.1.34]> <20010703004307.E2458@wjv.com> <f05101002b76700057320@[192.168.1.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <f05101002b76700057320@[192.168.1.34]>; 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <NMVDVF15>; Tue, 3 Jul 2001 09:24:07 -0400
Message-ID: <3A6D367EA1EFD4118C9B00A0C9DD99D7064F5F@rerun.lucentctc.com>
From: "Cambria, Mike" <mcambria@avaya.com>
To: 'Jun-ichiro itojun Hagino' <itojun@iijlab.net>,
"Cambria, Mike" <mcambria@avaya.com>, snap-users@kame.net
Cc: "'freebsd-net@freebsd.org'" <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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <ru@FreeBSD.ORG>
To: Iasen Kostoff <tbyte@tbyte.org>
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 <tbyte@tbyte.org>,
freebsd-net@FreeBSD.ORG
References: <20010703150441.B39090@sunbay.com> <Pine.BSF.4.21.0107031514520.35452-100000@shadow.otel.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.BSF.4.21.0107031514520.35452-100000@shadow.otel.net>; from tbyte@tbyte.org on Tue, Jul 03, 2001 at 03:34:14PM +0300
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <foo>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''.
<PS>
You still did not tell me what are you trying to do. :-)
</PS>
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 <anders.lowinger@xelerated.com>
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 <luigi@info.iet.unipi.it>
Cc: Jeffrey Hsu <hsu@FreeBSD.org>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
<resending including the list>
> 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 <tbyte@tbyte.org>
X-Sender: tbyte@shadow.otel.net
To: Ruslan Ermilov <ru@FreeBSD.ORG>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: adding a route to host via interface
In-Reply-To: <20010703162556.E39090@sunbay.com>
Message-ID: <Pine.BSF.4.21.0107031644290.35452-100000@shadow.otel.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <foo>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 ?
>
> <PS>
> You still did not tell me what are you trying to do. :-)
> </PS>
>
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: <ru@FreeBSD.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <ru@FreeBSD.ORG>
To: Iasen Kostoff <tbyte@tbyte.org>
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 <tbyte@tbyte.org>,
freebsd-net@FreeBSD.ORG
References: <20010703162556.E39090@sunbay.com> <Pine.BSF.4.21.0107031644290.35452-100000@shadow.otel.net>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="Q68bSM7Ycu6FN28Q"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.BSF.4.21.0107031644290.35452-100000@shadow.otel.net>; from tbyte@tbyte.org on Tue, Jul 03, 2001 at 04:54:29PM +0300
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Tue, 3 Jul 2001 11:51:02 -0400 (EDT)
Date: Tue, 3 Jul 2001 11:51:02 -0400 (EDT)
From: Eric Parker <sz@cdc.net>
X-X-Sender: <sz@fubar.staff>
To: <freebsd-net@freebsd.org>
Subject: PCMCIA Card in FreeBSD 4.3
Message-ID: <Pine.BSF.4.31.0107031150260.19363-100000@fubar.staff>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <wes@softweyr.com>
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 <bakul@bitblocks.com>
Cc: Ruslan Ermilov <ru@FreeBSD.org>, Deepak Jain <deepak@ai.net>,
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <wes@softweyr.com>
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 <brooks@one-eyed-alien.net>
Cc: Vladimir Terziev <vlady@rila.bg>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@freebsd.org>; 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 <julian@elischer.org>
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 <bjf@samurai.com>
Cc: net@freebsd.org
Subject: Re: PPPoE latency
References: <f05101003b766f52ce823@[192.168.1.34]>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <yar@freebsd.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <roman@IPricot.com>
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 <freebsd-net@FreeBSD.org>
Cc: freebsd-stable <freebsd-stable@FreeBSD.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex> 100baseTX
10baseT/UTP
<full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.42.1 netmask 0xffffff00 broadcast 192.168.42.255
ether 00:50:ba:05:9a:8f
media: autoselect (100baseTX <full-duplex>) status: active
supported media: autoselect 100baseTX <full-duplex> 100baseTX
10baseT/UTP
<full-duplex> 10baseT/UTP none
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
ppp0: flags=8010<POINTOPOINT,MULTICAST> 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <jrh@it.uc3m.es>
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 <freebsd-net@freebsd.org>
Subject: ftp.c understanding
Content-Type: multipart/mixed;
boundary="------------BF9229A944034D4828AFA463"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <jrh@it.uc3m.es>
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 <freebsd-net@freebsd.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <brooks@one-eyed-alien.net>
To: Juan Fco Rodriguez Hervella <jrh@it.uc3m.es>
Cc: Lista <freebsd-net@FreeBSD.ORG>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <thierry@herbelot.com>
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 <jrh@it.uc3m.es>
Cc: Lista <freebsd-net@FreeBSD.ORG>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>
id WAA09542 (8.8.8/1.3); Tue, 3 Jul 2001 22:24:50 +0200 (MET DST)
Reply-To: <Peter.Blok@inter.NL.net>
From: "Peter Blok" <Peter.Blok@inter.NL.net>
To: <freebsd-net@freebsd.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <gnb@itga.com.au>
To: Roman Le Houelleur <roman@IPricot.com>
Cc: freebsd-net <freebsd-net@FreeBSD.ORG>,
freebsd-stable <freebsd-stable@FreeBSD.ORG>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@FreeBSD.ORG>; 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 <jesper@skriver.dk>
To: Bryan Fullerton <bjf@samurai.com>
Cc: bv@wjv.com, net@FreeBSD.ORG
Subject: Re: PPPoE latency
Message-ID: <20010704023113.A40316@skriver.dk>
References: <f05101003b766f52ce823@[192.168.1.34]> <20010703004307.E2458@wjv.com> <f05101002b76700057320@[192.168.1.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <f05101002b76700057320@[192.168.1.34]>; 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@FreeBSD.ORG>; 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: <f05101000b7683d03b7fe@[192.168.1.34]>
In-Reply-To: <20010703091456.E5516@wjv.com>
References: <f05101003b766f52ce823@[192.168.1.34]>
<20010703004307.E2458@wjv.com> <f05101002b76700057320@[192.168.1.34]>
<20010703091456.E5516@wjv.com>
Date: Tue, 3 Jul 2001 23:27:18 -0400
To: bv@wjv.com
From: Bryan Fullerton <bjf@samurai.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@FreeBSD.ORG>; 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: <f05101001b7683e5807dc@[192.168.1.34]>
In-Reply-To: <20010704023113.A40316@skriver.dk>
References: <f05101003b766f52ce823@[192.168.1.34]>
<20010703004307.E2458@wjv.com> <f05101002b76700057320@[192.168.1.34]>
<20010704023113.A40316@skriver.dk>
Date: Tue, 3 Jul 2001 23:32:15 -0400
To: Jesper Skriver <jesper@skriver.dk>
From: Bryan Fullerton <bjf@samurai.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@freebsd.org>; 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: <f05101003b7683f514248@[192.168.1.34]>
In-Reply-To: <20010703001534.D84523@sneakerz.org>
References: <f05101003b766f52ce823@[192.168.1.34]>
<20010702233606.A84523@sneakerz.org>
<f05101001b766fe1f011f@[192.168.1.34]>
<20010702235434.B84523@sneakerz.org>
<f05101000b767029b0e42@[192.168.1.34]>
<20010703001534.D84523@sneakerz.org>
Date: Tue, 3 Jul 2001 23:43:46 -0400
To: Alfred Perlstein <bright@sneakerz.org>
From: Bryan Fullerton <bjf@samurai.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@freebsd.org>; 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: <f05101004b7684177c356@[192.168.1.34]>
In-Reply-To: <3B41EB3C.EF185F3F@elischer.org>
References: <f05101003b766f52ce823@[192.168.1.34]>
<3B41EB3C.EF185F3F@elischer.org>
Date: Tue, 3 Jul 2001 23:44:24 -0400
To: Julian Elischer <julian@elischer.org>
From: Bryan Fullerton <bjf@samurai.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <mike@sentex.net>
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: <se65kt8aa3ph960q1lufjqfnaqkg4s82f2@4ax.com>
References: <f05101003b766f52ce823@[192.168.1.34]> <20010702233606.A84523@sneakerz.org> <f05101001b766fe1f011f@[192.168.1.34]> <20010702235434.B84523@sneakerz.org> <SEN.994137137.444294559@news.sentex.net>
In-Reply-To: <SEN.994137137.444294559@news.sentex.net>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <amour@bugs.elitsat.net>
To: freebsd-net@freebsd.org
Subject: network monitor
Message-ID: <Pine.BSF.4.21.0107040957170.42961-100000@bugs.elitsat.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <ru@FreeBSD.ORG>
To: Roman Le Houelleur <roman@IPricot.com>
Cc: freebsd-net <freebsd-net@FreeBSD.ORG>,
freebsd-stable <freebsd-stable@FreeBSD.ORG>
Subject: Re: Setting ip addr deletes routes
Message-ID: <20010704100152.B55338@sunbay.com>
Mail-Followup-To: Roman Le Houelleur <roman@IPricot.com>,
freebsd-net <freebsd-net@FreeBSD.ORG>,
freebsd-stable <freebsd-stable@FreeBSD.ORG>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex> 100baseTX
> 10baseT/UTP
> <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
> vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> inet 192.168.42.1 netmask 0xffffff00 broadcast 192.168.42.255
> ether 00:50:ba:05:9a:8f
> media: autoselect (100baseTX <full-duplex>) status: active
> supported media: autoselect 100baseTX <full-duplex> 100baseTX
> 10baseT/UTP
> <full-duplex> 10baseT/UTP none
> sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
> inet 127.0.0.1 netmask 0xff000000
> ppp0: flags=8010<POINTOPOINT,MULTICAST> 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 <net@freebsd.org>; 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <tbyte@tbyte.org>
X-Sender: tbyte@shadow.otel.net
To: Ruslan Ermilov <ru@FreeBSD.ORG>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: adding a route to host via interface
In-Reply-To: <20010703181032.A65571@sunbay.com>
Message-ID: <Pine.BSF.4.21.0107041250490.38065-100000@shadow.otel.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <sakane@kame.net>
X-Dispatcher: imput version 20000228(IM140)
Lines: 27
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <wes@softweyr.com>
Cc: Bakul Shah <bakul@bitblocks.com>,
Ruslan Ermilov <ru@FreeBSD.ORG>, Deepak Jain <deepak@ai.net>,
net@FreeBSD.ORG
X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg
From: "Louis A. Mamakos" <louie@TransSys.COM>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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" <louie@TransSys.COM>
Cc: Wes Peters <wes@softweyr.com>, Ruslan Ermilov <ru@FreeBSD.ORG>,
Deepak Jain <deepak@ai.net>, 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 <bakul@bitblocks.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <freebsd-net@FreeBSD.ORG>; Wed, 4 Jul 2001 23:47:15 +0300 (EEST)
(envelope-from vlad@infonet.com.ua)
Message-ID: <023401c104ca$829d0d00$6a7a01d4@kuzya>
From: "Vlad Marchenko" <vlad@infonet.com.ua>
To: <freebsd-net@FreeBSD.ORG>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <agifford@infowest.com>
Reply-To: Aaron Gifford <agifford@infowest.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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
<agifford@infowest.com>
*** 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} <number>{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 <freebsd-net@freebsd.org>; 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: <EB513E68D3F5D41191CA00025558810150D4E1@mailserv.xpert.com>
From: Yonatan Bokovza <Yonatan@xpert.com>
To: "'freebsd-net@freebsd.org'" <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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <tbyte@tbyte.org>
X-Sender: tbyte@shadow.otel.net
To: Yonatan Bokovza <Yonatan@xpert.com>
Cc: "'freebsd-net@freebsd.org'" <freebsd-net@FreeBSD.ORG>
Subject: Re: IP layer API
In-Reply-To: <EB513E68D3F5D41191CA00025558810150D4E1@mailserv.xpert.com>
Message-ID: <Pine.BSF.4.21.0107051313470.74646-100000@shadow.otel.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <nuzrin@yahoo.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <freebsd-net@FreeBSD.ORG>; Thu, 5 Jul 2001 16:18:11 +0100
Message-ID: <056b01c10565$9f5d9270$0900a8c0@testuser>
From: "Marcel Dijk" <nascar24@home.nl>
To: <freebsd-net@FreeBSD.ORG>
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" <nascar24@home.nl>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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" <matt-l@pacbell.net>
From: "matt" <matt-l@pacbell.net>
To: "Yonatan Bokovza" <Yonatan@xpert.com>, <freebsd-net@freebsd.org>
References: <EB513E68D3F5D41191CA00025558810150D4E1@mailserv.xpert.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <Yonatan@xpert.com>
To: <freebsd-net@freebsd.org>
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 <net@freebsd.org>; 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 <net@freebsd.org>; 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 <frans@quanza.net>
X-Sender: franst@support.euronet.nl
To: net@freebsd.org
Subject: multiple bridged networks on one box
Message-ID: <Pine.BSF.4.21.0107052244400.70150-100000@support.euronet.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@freebsd.org>; 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 <julian@elischer.org>
To: Frans ter Borg <frans@quanza.net>
Cc: net@freebsd.org
Subject: Re: multiple bridged networks on one box
In-Reply-To: <Pine.BSF.4.21.0107052244400.70150-100000@support.euronet.nl>
Message-ID: <Pine.BSF.4.21.0107051604560.21114-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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" <peter@sysadmin-inc.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@freebsd.org>; 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 <bright@sneakerz.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <wes@softweyr.com>
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" <louie@TransSys.COM>
Cc: Bakul Shah <bakul@bitblocks.com>,
Ruslan Ermilov <ru@FreeBSD.ORG>, Deepak Jain <deepak@ai.net>,
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <bonnetf@news.esiee.fr>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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" <peter@sysadmin-inc.com>
To: <freebsd-net@freebsd.org>
Subject: FW: simple mpd-netgraph quesiton
Date: Fri, 6 Jul 2001 10:15:38 -0400
Message-ID: <NFBBKAEAALGGGFKINBLAAEOPCAAA.peter@sysadmin-inc.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <julian@elischer.org>
To: Frank Bonnet <bonnetf@news.esiee.fr>
Cc: freebsd-net@freebsd.org
Subject: Re: DHCP client gateway ?
In-Reply-To: <20010706095640.B1923@news.esiee.fr>
Message-ID: <Pine.BSF.4.21.0107061201220.33400-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <wes@softweyr.com>
Cc: "Louis A. Mamakos" <louie@TransSys.COM>,
Ruslan Ermilov <ru@FreeBSD.ORG>, Deepak Jain <deepak@ai.net>,
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 <bakul@bitblocks.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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
<init msg>
a = <initial host addr>
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 <freebsd-net@FreeBSD.ORG>; 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 <thierry@herbelot.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
Cc: Frank Bonnet <bonnetf@news.esiee.fr>, freebsd-net@FreeBSD.ORG
Subject: Re: DHCP client gateway ?
References: <Pine.BSF.4.21.0107061201220.33400-100000@InterJet.elischer.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <hsu@FreeBSD.org>
Subject: Re: Operation now in progress
In-reply-to: Message from Vlad Marchenko <vlad@infonet.com.ua>
"of Wed, 04 Jul 2001 23:47:12 +0300." <023401c104ca$829d0d00$6a7a01d4@kuzya>
To: Vlad Marchenko <vlad@infonet.com.ua>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <net@freebsd.org>; 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 <net@freebsd.org>; Fri, 6 Jul 2001 18:20:38 -0700 (PDT)
X-Delivered-For: <net@freebsd.org>
Received: (from root@localhost)
by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f671Kbx13253
for <net@freebsd.org>; 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 <vijay@IPRG.nokia.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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" <ak03@gte.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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 <ume@mahoroba.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
>>>>> On Sat, 7 Jul 2001 15:01:29 -0400
>>>>> "Alexander N. Kabaev" <ak03@gte.com> 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 <ume@mahoroba.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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: <ebf@cwb.fnn.net>
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 <ume@mahoroba.org>; 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" <ebf@cwb.fnn.net>
Organization: A&D Solucoes Ltda.
To: Hajimu UMEMOTO <ume@mahoroba.org>
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 <ebf@cwb.fnn.net>
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 <net@freebsd.org>; 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 <wes@softweyr.com>
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 <bakul@bitblocks.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
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