From owner-freebsd-net Sun Jul 25 6: 2:32 1999 Delivered-To: freebsd-net@freebsd.org Received: from ns1.tu-graz.ac.at (ns1.tu-graz.ac.at [129.27.2.3]) by hub.freebsd.org (Postfix) with ESMTP id E02AA1515A for ; Sun, 25 Jul 1999 06:02:26 -0700 (PDT) (envelope-from mbretter@sbox.tu-graz.ac.at) Received: from babsi.tu-graz.ac.at (teleweb-17.vc-graz.ac.at [193.171.247.17]) by ns1.tu-graz.ac.at (8.9.3/8.9.3) with SMTP id PAA17824 for ; Sun, 25 Jul 1999 15:01:36 +0200 (MET DST) From: Michael Bretterklieber To: freebsd-net@freebsd.org Subject: Routing between logical subnets Date: Sun, 25 Jul 1999 14:55:53 +0200 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99072515060300.00290@babsi.tu-graz.ac.at> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I'd like to configure FreeBSD 3.2 as router between 3 physicals and 2 logical subnets. Here is the network configuration: device vr0: 192.168.101.1 alias 192.168.100.1 device vr1: 192.168.102.1 device xl0: 192.168.103.1 I enabled the "gateway_enable" option in /etc/rc.conf. I can ping from the FreeBSD-router to all pc's in the networks, I can ping from one physical networks to another, but I can't ping into the logical one. What's the solutaion for this problem and waht I've done wrong? Thanx, -- \|/ @ @ +---------------------------oOO-(_)-OOo---------------------------+ Michael Bretterklieber Office: Michael.Bretterklieber@gamed.com Privat: mbretter@sbox.tu-graz.ac.at URL: http://www.sbox.tu-graz.ac.at/home/m/mbretter/ +-----------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 25 10:34:48 1999 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 47B7F151A5 for ; Sun, 25 Jul 1999 10:34:40 -0700 (PDT) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id MAA04788; Sun, 25 Jul 1999 12:33:59 -0500 (CDT) From: Mohit Aron Message-Id: <199907251733.MAA04788@cs.rice.edu> Subject: Re: FreeBSD tuning for webserver performance To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Sun, 25 Jul 1999 12:33:59 -0500 (CDT) Cc: freebsd-net@freebsd.org In-Reply-To: <199907242210.AAA01871@labinfo.iet.unipi.it> from "Luigi Rizzo" at Jul 25, 99 00:10:33 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > this one i'd be a bit careful about. The same parameter is used > for both input (ipqmaxlen = IFQ_MAXLEN) and output queues. On the output > side this means you can have up to 1.5MBytes queued on output on one > interface -- that's over one second on a 10Mbit ethernet. > > If you are sending so much data to fill your 50-slot queues (and this > can only be because of a burst) you do want drops so that you get > immediate feedback and can de-synchronize the flows and avoid further > bursts of the same kind. > The burst might result from SYN packets sent by clients. I don't find it inconceivable that a busy webserver often gets more than 50 connection requests in short succession. At least for benchmarking Apache, I have to setup more than 50 clients connecting simultaneouly to it before the server gets saturated. Even on an input burst of this kind, I don't expect that the output queues would be flooded because TCP takes quite a while (about 150 usec) to setup the connection and respond with a SYN/ACK. Even if the output queues get flooded with SYN/ACK packets, it would only amount to about 40K of data and not 1.5MB. On the other hand, the output queues can only be filled with 1500 byte data packets if the webserver somehow does writes in quick succession across several connections. Such synchronization however seems unlikely because the code path for the webserver involves reading the file, checking for validity etc. For the above reasons I'm not convinced that the output queues would be flooded with 1500 byte packets. However, if it is indeed a concern, then perhaps the solution is to use different values for the input and output interface queue lengths. The IP queue can have a larger length (say 1000) while the interface output queues can remain at 50. - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 25 11: 2:40 1999 Delivered-To: freebsd-net@freebsd.org Received: from spooky.eis.net.au (spooky.eis.net.au [203.12.171.2]) by hub.freebsd.org (Postfix) with ESMTP id D6C6E15217 for ; Sun, 25 Jul 1999 11:02:27 -0700 (PDT) (envelope-from ernie@spooky.eis.net.au) Received: (from ernie@localhost) by spooky.eis.net.au (8.9.3/8.8.3) id EAA90610; Mon, 26 Jul 1999 04:01:10 +1000 (EST) From: Ernie Elu Message-Id: <199907251801.EAA90610@spooky.eis.net.au> Subject: Re: mpd to USR problem In-Reply-To: <199907240351.EAA07608@keep.lan.Awfulhak.org> from Brian Somers at "Jul 24, 99 04:51:28 am" To: brian@Awfulhak.org (Brian Somers) Date: Mon, 26 Jul 1999 04:01:10 +1000 (EST) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > I am trying to do a multilink ppp connection using mpd version 2.0b2 on FreeBSD 2.2.8 > > > > The connection is to a 3COM/USR Total Control rack using a pair of USR 56k > > modems. > > > > The first modem comes up fine, but when the second modem dials in there is > > some problem negotaiting and both links drop. > > > > Here is my config and log entries if someone could please try to point me in > > the right direction. > [.....] > > Jul 24 10:05:46 dns mpd: [modem1] LCP: phase shift AUTHENTICATE --> NETWORK > > Strange - this state machine shouldn't be per link (it isn't in ppp > anyway). > > > Jul 24 10:05:46 dns mpd: [eis.net] up: 2 links, total bandwidth 97333 bps > > Jul 24 10:05:46 dns mpd: [modem1] LCP: LayerUp > > Jul 24 10:05:46 dns mpd: [eis.net] IPCP: rec'd Configure Request #1 (Opened) > > Jul 24 10:05:46 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid > > Jul 24 10:05:46 dns mpd: IPADDR 210.8.64.100 > > Jul 24 10:05:46 dns mpd: 210.8.64.100 is OK > > The peer is misbehaving. It's asking to renegotiate IPCP. You > should report this to 3com and/or your ISP. > > [.....] > > Any suggestions? > > If you're interested in proving this from another ppp implementation, > you can always try ppp too :-) > I have just tried the same connection with user ppp in multi-link mode and it seem to be working except the connection hamgs up often and redials with the following errors in the ppp.log: Jul 26 02:34:15 dns ppp[269]: tun0: Phase: 1: HDLC errors -> FCS: 1, ADDR: 0, COMD: 0, PROTO: 0 Jul 26 02:34:17 dns ppp[269]: tun0: Phase: 2: HDLC errors -> FCS: 1, ADDR: 0, COMD: 0, PROTO: 0 Here is my config: ------------------------------- default: set log Phase Chat Connect LCP IPCP CCP tun command set device /dev/cue7 /dev/cuaa0 set speed 57600 set phone "0392590000" deny lqr set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" set login set authname aickin set authkey "" set timeout 600 set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0 add default HISADDR set mrru 1500 clone 1,2 link 1,2 set mode ddial ------------------------- Does that look about right or have I missed something essential? - Ernie. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 25 15: 6:48 1999 Delivered-To: freebsd-net@freebsd.org Received: from puffer.quadrunner.com (puffer.quadrunner.com [205.166.195.4]) by hub.freebsd.org (Postfix) with ESMTP id 6F5D214BCF for ; Sun, 25 Jul 1999 15:06:46 -0700 (PDT) (envelope-from humble@quadrunner.com) Received: from localhost (humble@localhost) by puffer.quadrunner.com (8.9.2/QUAD-2.1) with ESMTP id PAA08664 for ; Sun, 25 Jul 1999 15:06:05 -0700 (PDT) X-Authentication-Warning: puffer.quadrunner.com: humble owned process doing -bs Date: Sun, 25 Jul 1999 15:06:05 -0700 (PDT) From: Richard Steenbergen To: freebsd-net@freebsd.org Subject: TCBHASHSIZE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hrmm just a thought, perhaps the TCBHASHSIZE should be influenced by maxusers. Something along the lines of nmbclusters * 1.5 + round up to power of two, or whatever would make the hash table most effective. Considering the importance and commonness of tcb hash lookups it seems like a good way to improve performance on systems with large numbers of connections. *** Current local users 1971 Max: 2034 2:58PM up 7 days, 3:42, 1 user, load averages: 0.00, 0.00, 0.00 :P -- Richard Steenbergen humble@EFNet PGP ID: 0x741D0374 PGP Key Fingerprint: C6EF EFA0 83B2 071F 1AB6 B879 1F70 4303 741D 0374 http://users.quadrunner.com/humble To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 25 19: 1: 3 1999 Delivered-To: freebsd-net@freebsd.org Received: from awfulhak.org (dynamic-104.max1-du-ws.dialnetwork.pavilion.co.uk [212.74.8.104]) by hub.freebsd.org (Postfix) with ESMTP id 85F7C1525E for ; Sun, 25 Jul 1999 19:00:49 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (root@keep.lan.Awfulhak.org [172.16.0.8]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id XAA14759; Sun, 25 Jul 1999 23:37:35 +0100 (BST) (envelope-from brian@lan.awfulhak.org) Received: from keep.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id XAA72513; Sun, 25 Jul 1999 23:38:08 +0100 (BST) (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199907252238.XAA72513@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Ernie Elu Cc: brian@Awfulhak.org (Brian Somers), freebsd-net@FreeBSD.ORG Subject: Re: mpd to USR problem In-reply-to: Your message of "Mon, 26 Jul 1999 04:01:10 +1000." <199907251801.EAA90610@spooky.eis.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 Jul 1999 23:38:08 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > > > I am trying to do a multilink ppp connection using mpd version 2.0b2 on FreeBSD 2.2.8 > > > > > > The connection is to a 3COM/USR Total Control rack using a pair of USR 56k > > > modems. > > > > > > The first modem comes up fine, but when the second modem dials in there is > > > some problem negotaiting and both links drop. > > > > > > Here is my config and log entries if someone could please try to point me in > > > the right direction. > > [.....] > > > Jul 24 10:05:46 dns mpd: [modem1] LCP: phase shift AUTHENTICATE --> NETWORK > > > > Strange - this state machine shouldn't be per link (it isn't in ppp > > anyway). > > > > > Jul 24 10:05:46 dns mpd: [eis.net] up: 2 links, total bandwidth 97333 bps > > > Jul 24 10:05:46 dns mpd: [modem1] LCP: LayerUp > > > Jul 24 10:05:46 dns mpd: [eis.net] IPCP: rec'd Configure Request #1 (Opened) > > > Jul 24 10:05:46 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid > > > Jul 24 10:05:46 dns mpd: IPADDR 210.8.64.100 > > > Jul 24 10:05:46 dns mpd: 210.8.64.100 is OK > > > > The peer is misbehaving. It's asking to renegotiate IPCP. You > > should report this to 3com and/or your ISP. > > > > [.....] > > > Any suggestions? > > > > If you're interested in proving this from another ppp implementation, > > you can always try ppp too :-) > > > > I have just tried the same connection with user ppp in multi-link mode and > it seem to be working except the connection hamgs up often and redials with the > following errors in the ppp.log: > > Jul 26 02:34:15 dns ppp[269]: tun0: Phase: 1: HDLC errors -> FCS: 1, ADDR: 0, COMD: 0, PROTO: 0 > Jul 26 02:34:17 dns ppp[269]: tun0: Phase: 2: HDLC errors -> FCS: 1, ADDR: 0, COMD: 0, PROTO: 0 > > Here is my config: > > > ------------------------------- > > default: > set log Phase Chat Connect LCP IPCP CCP tun command > set device /dev/cue7 /dev/cuaa0 > set speed 57600 > set phone "0392590000" > deny lqr > set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" > set login > set authname aickin > set authkey "" > set timeout 600 > set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0 > add default HISADDR > set mrru 1500 > clone 1,2 > link 1,2 set mode ddial > ------------------------- > > Does that look about right or have I missed something essential? You could do with a ``link deflink rm'' after the clone to get rid of the original ``deflink'' and you could probably do with a ``set enddisc'', although this isn't essential. If you're getting hdlc errors and are using a pretty recent version of ppp, ``set log +physical'' may throw some light on the subject. You may see that the HDLC error is the result of the peer quitting - maybe the HDLC error is a login prompt ? > - Ernie. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 25 20:20:26 1999 Delivered-To: freebsd-net@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 1752514CF8 for ; Sun, 25 Jul 1999 20:20:10 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id CAA03166; Mon, 26 Jul 1999 02:53:02 +0200 From: Luigi Rizzo Message-Id: <199907260053.CAA03166@labinfo.iet.unipi.it> Subject: Re: FreeBSD tuning for webserver performance To: aron@cs.rice.edu (Mohit Aron) Date: Mon, 26 Jul 1999 02:53:01 +0200 (MET DST) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <199907251733.MAA04788@cs.rice.edu> from "Mohit Aron" at Jul 25, 99 12:33:40 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2253 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > this one i'd be a bit careful about. The same parameter is used > > for both input (ipqmaxlen = IFQ_MAXLEN) and output queues. On the output > > side this means you can have up to 1.5MBytes queued on output on one > > interface -- that's over one second on a 10Mbit ethernet. ... > The burst might result from SYN packets sent by clients. I don't find it > inconceivable that a busy webserver often gets more than 50 connection requests understand your point about SYN's, and the need to increase the input queue length (and maybe the out queue) a bit, but you are proposing a 20fold increase! But my point is, i assume a fast machine is able to process input packets (such as SYNs) at wire speed hopefully so there shouldn't be any significant queueing of these (i'd be glad to be corrected if you have actual data showing that queues of SYNs do build up). > Even on an input burst of this kind, I don't expect that the output queues > would be flooded because TCP takes quite a while (about 150 usec) to setup the > connection and respond with a SYN/ACK. Even if the output queues get flooded hmm... this is quite a bit of time. how did you measure this and on what hardware ? > 1.5MB. On the other hand, the output queues can only be filled with 1500 byte > data packets if the webserver somehow does writes in quick succession across > several connections. Such synchronization however seems unlikely because > the code path for the webserver involves reading the file, checking for > validity etc. i think this kind of behaviour is very likely as at times (generally when the window suddenly opens e.g. because of recovered losses) you have a burst which can even be large (e.g. some 10-20 packets) and your data are already queued in the socket buffer. 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) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 25 21:42:10 1999 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 83D121526D for ; Sun, 25 Jul 1999 21:42:02 -0700 (PDT) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id XAA11549; Sun, 25 Jul 1999 23:39:26 -0500 (CDT) From: Mohit Aron Message-Id: <199907260439.XAA11549@cs.rice.edu> Subject: Re: FreeBSD tuning for webserver performance To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Sun, 25 Jul 1999 23:39:26 -0500 (CDT) Cc: freebsd-net@freebsd.org In-Reply-To: <199907260053.CAA03166@labinfo.iet.unipi.it> from "Luigi Rizzo" at Jul 26, 99 02:53:01 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > understand your point about SYN's, and the need to increase the input > queue length (and maybe the out queue) a bit, but you are proposing a > 20fold increase! > Well, actually I found the value of 50 too small for experiments. I've been using the value of 1000 and find no problems with it - however the increase can certainly be lesser. The number should be as large as the maximum burst that a busy webserver is willing to tolerate - the number 50 seems rather small. > But my point is, i assume a fast machine is able to process input > packets (such as SYNs) at wire speed hopefully so there shouldn't be > any significant queueing of these (i'd be glad to be corrected if you > have actual data showing that queues of SYNs do build up). > > > Even on an input burst of this kind, I don't expect that the output queues > > would be flooded because TCP takes quite a while (about 150 usec) to setup the > > connection and respond with a SYN/ACK. Even if the output queues get flooded > > hmm... this is quite a bit of time. how did you measure this and on > what hardware ? > I've measure this on a 300MHz Pentium II running FreeBSD-2.2.6. SYN processing takes about 140 usec. This isn't very surprising considering the amount of state that gets initialized - inpcb, tcpcb, socket, route structure to client etc. If connection establishment overhead takes so much time, the IP queue can certainly overlow with bursts of SYN packets. > > i think this kind of behaviour is very likely as at times (generally when > the window suddenly opens e.g. because of recovered losses) you have a > burst which can even be large (e.g. some 10-20 packets) and your data > are already queued in the socket buffer. > Yes, but I still don't see why you think dropping these packets at the driver is a good idea. The CPU has already expended work to process these packets (computing checksums and initializing all the headers). If anything, this particular problem should be fixed by making sure TCP never sends bursts - rather than dropping packets from such bursts by limiting the interface queues. - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 25 22:52:57 1999 Delivered-To: freebsd-net@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id E56D3152C2 for ; Sun, 25 Jul 1999 22:52:45 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id FAA03377; Mon, 26 Jul 1999 05:28:24 +0200 From: Luigi Rizzo Message-Id: <199907260328.FAA03377@labinfo.iet.unipi.it> Subject: Re: FreeBSD tuning for webserver performance To: aron@cs.rice.edu (Mohit Aron) Date: Mon, 26 Jul 1999 05:28:24 +0200 (MET DST) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <199907260439.XAA11549@cs.rice.edu> from "Mohit Aron" at Jul 25, 99 11:39:07 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2865 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > certainly be lesser. The number should be as large as the maximum burst that a > busy webserver is willing to tolerate - the number 50 seems rather small. i fully agree on the need of an increase for the input queue, just how much i am not sure... The data on SYN processing is interesting but really seems a large one! May i ask you how did you measure them -- by instrumenting the code paths, or looking on a tcpdump at the delay between a SYN request on the wire, and the SYN|ACK response. In the latter case, was there any other traffic generated by the server ? A quick experiment locally on a K6-400 w/ 100mbit card (de) running tcpdump shows that there are about 40us between the ping request and response, and some 90-100us between the SYN and the corresponding ACK (this at the bpf level). So the SYN processing overhead appears to be more in the 50us range, the rest being generic packet processing overhead. Surely worth some optimization, though... > ... > > i think this kind of behaviour is very likely as at times (generally when > > the window suddenly opens e.g. because of recovered losses) you have a > > burst which can even be large (e.g. some 10-20 packets) and your data > > are already queued in the socket buffer. > > Yes, but I still don't see why you think dropping these packets at the driver > is a good idea. The CPU has already expended work to process these packets because you get an immediate notification (check tcp_output() -- an error generates a tcp_quench()) reducing the window to a single segment and avoiding further congestion and occurrence of such events (and you already have a full window in transit so there is no performance penalty for your connection -- as ACK come in the window reopens to its full size). Keeping queues short is always useful -- even in the case of your busy web server, just to give one example, you might cause your SYN|ACK for new connections incur a large delay just because you have a huge number of data packets queued for delivery. > (computing checksums and initializing all the headers). If anything, this > particular problem should be fixed by making sure TCP never sends bursts - > rather than dropping packets from such bursts by limiting the interface > queues. unfortunately fixing TCP like you suggest, while desirable is not easy because there is not a fine-grained timer to use. 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) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 26 1:48:54 1999 Delivered-To: freebsd-net@freebsd.org Received: from scam.xcf.berkeley.edu (scam.XCF.Berkeley.EDU [128.32.43.201]) by hub.freebsd.org (Postfix) with SMTP id 6F9651528E for ; Mon, 26 Jul 1999 01:48:50 -0700 (PDT) (envelope-from grady@scam.XCF.Berkeley.EDU) Received: (qmail 27874 invoked by uid 348); 26 Jul 1999 08:48:31 -0000 Received: from localhost (HELO scam.XCF.Berkeley.EDU) (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Jul 1999 08:48:31 -0000 To: freebsd-net@freebsd.org Subject: network hangs From: grady@xcf.berkeley.edu (Steven Grady) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27870.932978910.1@scam.XCF.Berkeley.EDU> Date: Mon, 26 Jul 1999 01:48:31 -0700 Message-Id: <19990726084851.6F9651528E@hub.freebsd.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm getting network hangs on my 3.1-RELEASE system. The configuration looks like: DSL<-->de1:FreeBSD 3.1:de0<-->100 Mbit switch into internal network At the moment, de0 and de1 are both Asante Fast Ethernet adapters (with 21140AE chipsets), but I also tried no-name 10/100 cards using the PNIC chipset (and therefore the pn driver), as well as one of each. The network works fine for an indefinite period before the hang. When the problem occurs, both interfaces hang. Rebooting the gateway fixes the problem, but it then comes back. Sometimes the hang occurs 30 seconds after the reboot, other times it can stay up for hours, handling 25 Meg downloads, ssh sessions, web surfing, etc., with no problems. When the PNIC cards were used, the driver would start issuing the message "Watchdog timeout". With the de driver, no kernel messages are currently showing up. Natd logging is turned on, but no interesting messages are being generated there either. I'm pretty sure this is FreeBSD's fault, and not the DSL provider's (PacBell's), because I never saw this problem connecting the DSL line directly to a Win98 client, or to a hub with Win98 clients configured to use static IP addresses. I can't use that configuration since I need natd (for additional internal hosts), and firewalling... The system is a 150MHz Pentium/P54C with 64 Megs of memory. The kernel differences from GENERIC are: maxusers 64 options "EXT2FS" options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options IPDIVERT pseudo-device bpfilter 4 The network configuration is straightforward, with the interfaces and router configured correctly, as well as: gateway_enable="YES" firewall_enable="YES" firewall_type="open" natd_enable="YES" natd_interface="de1" This is the second system I've tried this on -- we were getting exactly the same behavior on an old 486 with the PNIC cards, although it was running FreeBSD 3.2. We also got it when we used a 4-port hub instead of a 16-port switch. I haven't been able to experiment with it as much as I'd like yet, but it seems like the hang occurs more often if multiple users are using the DSL connection at the same time. It also seems to happen more often (but not always) when a big download is occurring. My only suspicion at this point is that a 150MHz Pentium can't handle a 100 Mbit network. Any chance of that? How can I tell? It seems unlikely, since even when maxing out the connection (with a file coming in at 300K/sec), top reported the CPU time as 7% system, 2% interrupt, 88% idle, with natd also showing 7%... Further information: Output of netstat -m after the hang: 634/640 mbufs in use: 612 mbufs allocated to data 21 mbufs allocated to packet headers 1 mbufs allocated to socket names and addresses 72/144/1536 mbuf clusters in use (current/peak/max) 368 Kbytes allocated to network (60% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Diff of "netstat -m" during a hang, before and after a short ping -f: 1,3c1,3 < 634/640 mbufs in use: < 612 mbufs allocated to data < 21 mbufs allocated to packet headers --- > 626/672 mbufs in use: > 605 mbufs allocated to data > 20 mbufs allocated to packet headers 6c6 < 368 Kbytes allocated to network (60% in use) --- > 372 Kbytes allocated to network (59% in use) Diff of "netstat -s" during a hang, before and after a short ping -f: 20c20 < 34503 packets sent from this host --- > 34908 packets sent from this host 54c54 < 34180 packets sent --- > 34184 packets sent 56c56 < 6 data packets (5700 bytes) retransmitted --- > 10 data packets (11540 bytes) retransmitted 90c90 < 6 retransmit timeouts --- > 10 retransmit timeouts 109c109 < 303 datagrams output --- > 305 datagrams output dmesg output related to networking: de0: rev 0x22 int a irq 12 on pci0.10.0 de0: Asanta 21140A [10-100Mb/s] pass 2.2 de0: address aa:bb:cc:dd:ee:ff de0: enabling 10baseT port de1: rev 0x22 int a irq 12 on pci0.11.0 de1: Asanta 21140A [10-100Mb/s] pass 2.2 de1: address gg:hh:ii:jj:kk:ll de1: enabling 10baseT port ... IP packet filtering initialized, divert enabled, rule-based forwarding enabled, unlimited logging I'd strongly appreciate some pointers on this one. My next step is to install 3.2 on the machine, but I haven't seen anything suggesting that will help. We were darn happy getting our DSL connection a few days ago, but it's getting frustrating having to reboot the gateway a dozen times a day. Thanks muchly for any help. -- Steven grady@xcf.berkeley.edu "Do you think there's a God?" "Well, SOMEbody's out to get me!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 26 8:12:13 1999 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id F34CD14D87 for ; Mon, 26 Jul 1999 08:12:10 -0700 (PDT) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id KAA20768; Mon, 26 Jul 1999 10:10:31 -0500 (CDT) From: Mohit Aron Message-Id: <199907261510.KAA20768@cs.rice.edu> Subject: Re: FreeBSD tuning for webserver performance To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 26 Jul 1999 10:10:31 -0500 (CDT) Cc: freebsd-net@freebsd.org, druschel@cs.rice.edu (Peter Druschel) In-Reply-To: <199907260328.FAA03377@labinfo.iet.unipi.it> from "Luigi Rizzo" at Jul 26, 99 05:28:24 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > The data on SYN processing is interesting but really seems a large one! > > May i ask you how did you measure them -- by instrumenting the code > paths, or looking on a tcpdump at the delay between a SYN request > on the wire, and the SYN|ACK response. In the latter case, was > there any other traffic generated by the server ? > I measured it in two ways - first by instrumenting the code path by using the cycle counter. This gave values of 50 usec when the SYN was received repeatedly (i.e. everything's in the cache) and a value of 150 usec when the SYN was received after a period of time after doing some other processing (i.e. not everything was in the cache). I then measured the connection overhead in a stripped down fast webserver by first measuring the throughput by repeatedly initiating requests on separate connections and second by issuing requests repeatedly on the same connection. The difference in time taken per request approximately gives the TCP connection overhead. This was closer to 150 usec. So I assume in normal webserver processing, connection establishment takes about 150 usec due to cache effects. > A quick experiment locally on a K6-400 w/ 100mbit card (de) > running tcpdump shows that there are about 40us between the ping > request and response, and some 90-100us between the SYN and the > corresponding ACK (this at the bpf level). > So the SYN processing overhead appears to be more in the 50us range, > the rest being generic packet processing overhead. > Surely worth some optimization, though... > Your numbers correspond to mine assuming the SYNs are being sent repeatedly and no other processing is being done. > > because you get an immediate notification (check tcp_output() -- an > error generates a tcp_quench()) reducing the window to a single segment > and avoiding further congestion and occurrence of such events (and > you already have a full window in transit so there is no performance > penalty for your connection -- as ACK come in the window reopens > to its full size). > > Keeping queues short is always useful -- even in the case of your > busy web server, just to give one example, you might cause your > SYN|ACK for new connections incur a large delay just because you > have a huge number of data packets queued for delivery. > I accept your argument but I think short driver output queues might be useful in very limited number of cases. These are when the bottleneck in the path to the clients occurs at the driver. I would imagine that in most cases the bottleneck occurs at some external router (which usually have large queues). > > unfortunately fixing TCP like you suggest, while desirable is not > easy because there is not a fine-grained timer to use. > I have a paper submitted on how to implement very fine-grained timers in an OS with very low overhead. Rate-based pacing is one of the goals of these timers. Hopefully it'll get published soon. :) - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 26 10:41:50 1999 Delivered-To: freebsd-net@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id B4CE114D96 for ; Mon, 26 Jul 1999 10:41:45 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id RAA00474; Mon, 26 Jul 1999 17:04:00 +0200 From: Luigi Rizzo Message-Id: <199907261504.RAA00474@labinfo.iet.unipi.it> Subject: Re: FreeBSD tuning for webserver performance To: aron@cs.rice.edu (Mohit Aron) Date: Mon, 26 Jul 1999 17:04:00 +0200 (MET DST) Cc: freebsd-net@FreeBSD.ORG, druschel@cs.rice.edu In-Reply-To: <199907261510.KAA20768@cs.rice.edu> from "Mohit Aron" at Jul 26, 99 10:10:12 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1665 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I measured it in two ways - first by instrumenting the code path by using the > cycle counter. This gave values of 50 usec when the SYN was received repeatedly > (i.e. everything's in the cache) and a value of 150 usec when the SYN was ok, thanks. ... > > Keeping queues short is always useful -- even in the case of your > > busy web server, just to give one example, you might cause your > > SYN|ACK for new connections incur a large delay just because you > > have a huge number of data packets queued for delivery. > > I accept your argument but I think short driver output queues might be > useful in very limited number of cases. These are when the bottleneck in the > path to the clients occurs at the driver. I would imagine that in most cases > the bottleneck occurs at some external router (which usually have large > queues). usually backbone routers have (or try, or ought to) some active queue management techniques such as RED or fair queueing variants so that per-flow queues are kept short. Try to flood-ping some site behind a bottleneck while you run a regular ping to the same site with a separate connection, and you'll see that in many cases the delay does not increase a lot -- you can even compute the queue size with this technique using different packet sizes. > > unfortunately fixing TCP like you suggest, while desirable is not > > easy because there is not a fine-grained timer to use. > > I have a paper submitted on how to implement very fine-grained timers in an OS > with very low overhead. Rate-based pacing is one of the goals of these timers. > Hopefully it'll get published soon. :) good luck then :) 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 26 11:53:55 1999 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id A9D9414CC2 for ; Mon, 26 Jul 1999 11:53:52 -0700 (PDT) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id NAA28030; Mon, 26 Jul 1999 13:53:02 -0500 (CDT) From: Mohit Aron Message-Id: <199907261853.NAA28030@cs.rice.edu> Subject: Re: FreeBSD tuning for webserver performance To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 26 Jul 1999 13:53:00 -0500 (CDT) Cc: freebsd-net@freebsd.org, druschel@cs.rice.edu In-Reply-To: <199907261504.RAA00474@labinfo.iet.unipi.it> from "Luigi Rizzo" at Jul 26, 99 05:04:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > usually backbone routers have (or try, or ought to) some active > queue management techniques such as RED or fair queueing variants > so that per-flow queues are kept short. Try to flood-ping some site > behind a bottleneck while you run a regular ping to the same site > with a separate connection, and you'll see that in many cases the > delay does not increase a lot -- you can even compute the queue > size with this technique using different packet sizes. > Very interesting. I thought that the deployment of intelligent techniques like RED and fair queuing was still rather thin in Internet routers. My impression was that most still do the naive FIFO queuing. - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 26 13:25:26 1999 Delivered-To: freebsd-net@freebsd.org Received: from des.follo.net (des.follo.net [195.204.143.216]) by hub.freebsd.org (Postfix) with ESMTP id 564F514C40; Mon, 26 Jul 1999 13:25:08 -0700 (PDT) (envelope-from des@des.follo.net) Received: (from des@localhost) by des.follo.net (8.9.3/8.9.3) id WAA54302; Mon, 26 Jul 1999 22:23:42 +0200 (CEST) (envelope-from des) To: net@freebsd.org Subject: TCP/IP hardening Organization: Yes Interactive Visit-Us-At: http://www.yes.no/ From: Dag-Erling Smorgrav Date: 26 Jul 1999 22:23:41 +0200 Message-ID: Lines: 238 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Attached are patches which implement four new sysctl variables: * net.inet.icmp.dropredirect: if set to 1, ignore ICMP REDIRECT packets. * net.inet.icmp.logredirect: if set to 1, log all ICMP REDIRECT packets (before optionally dropping them). * net.inet.tcp.restrict_rst: if set to 1, do not emit TCP RST packets. Conditional on the TCP_RESTRICT_RST kernel option, which defaults to off. * net.inet.tcp.drop_synfin: if set to 1, drop TCP packets with both the SYN and FIN options set. Conditional on the TCP_DROP_SYNFIN kernel option, which defaults to off. The logredirect code uses inet_ntoa, which is a bad idea. I'm open to suggestions for a better solution. Also, these sysctl variables should be described in a man page somewhere, but I'm not sure which one. These patches compile, but are not fully tested. DES -- Dag-Erling Smorgrav - des@yes.no Index: etc/defaults/rc.conf =================================================================== RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.23 diff -u -r1.23 rc.conf --- rc.conf 1999/07/26 10:49:33 1.23 +++ rc.conf 1999/07/26 19:11:51 @@ -48,6 +48,11 @@ tcp_extensions="NO" # Set to Yes to turn on RFC1323 extensions. log_in_vain="NO" # Disallow bad connection logging (or YES). tcp_keepalive="YES" # Kill dead TCP connections (or NO). +tcp_restrict_rst="NO" # Set to YES to restrict emission of RST +tcp_drop_synfin="NO" # Set to YES to drop TCP packets with SYN+FIN + # NOTE: this breaks rfc1644 extensions (T/TCP) +icmp_dropredirect="NO" # Set to YES to ignore ICMP REDIRECT packets +icmp_logredirect="NO" # Set to YES to log ICMP REDIRECT packets network_interfaces="auto" # List of network interfaces (or "auto"). ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. #ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0xffffffff" # Sample alias entry. Index: etc/rc.network =================================================================== RCS file: /home/ncvs/src/etc/rc.network,v retrieving revision 1.52 diff -u -r1.52 rc.network --- rc.network 1999/07/26 15:17:23 1.52 +++ rc.network 1999/07/26 19:11:51 @@ -197,6 +197,16 @@ echo -n ' broadcast ping responses=YES' sysctl -w net.inet.icmp.bmcastecho=1 >/dev/null fi + + if [ "X$icmp_dropredirect" = X"YES" ]; then + echo -n ' ignore ICMP redirect=YES' + sysctl -w net.inet.icmp.dropredirect=1 >/dev/null + fi + + if [ "X$icmp_logredirect" = X"YES" ]; then + echo -n ' log ICMP redirect=YES' + sysctl -w net.inet.icmp.logredirect=1 >/dev/null + fi if [ "X$gateway_enable" = X"YES" ]; then echo -n ' IP gateway=YES' @@ -216,6 +226,16 @@ if [ "X$tcp_keepalive" = X"YES" ]; then echo -n ' TCP keepalive=YES' sysctl -w net.inet.tcp.always_keepalive=1 >/dev/null + fi + + if [ "X$tcp_restrict_rst" = X"YES" ]; then + echo -n ' restrict TCP reset=YES' + sysctl -w net.inet.tcp.restrict_rst=1 >/dev/null + fi + + if [ "X$tcp_drop_synfin" = X"YES" ]; then + echo -n ' drop SYN+FIN packets=YES' + sysctl -w net.inet.tcp.drop_synfin=1 >/dev/null fi if [ "X$ipxgateway_enable" = X"YES" ]; then Index: sys/conf/options =================================================================== RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.144 diff -u -r1.144 options --- options 1999/07/05 20:19:34 1.144 +++ options 1999/07/26 19:11:51 @@ -222,6 +222,8 @@ PPP_FILTER opt_ppp.h TCP_COMPAT_42 opt_compat.h TCPDEBUG +TCP_RESTRICT_RST opt_tcp_input.h +TCP_DROP_SYNFIN opt_tcp_input.h IPFILTER opt_ipfilter.h IPFILTER_LOG opt_ipfilter.h SLIP_IFF_OPTS opt_slip.h Index: sys/i386/conf/LINT =================================================================== RCS file: /home/ncvs/src/sys/i386/conf/LINT,v retrieving revision 1.620 diff -u -r1.620 LINT --- LINT 1999/07/26 05:47:17 1.620 +++ LINT 1999/07/26 19:11:51 @@ -465,9 +465,23 @@ options IPDIVERT #divert sockets options IPFILTER #kernel ipfilter support options IPFILTER_LOG #ipfilter logging -#options IPFILTER_LKM #kernel support for ip_fil.o LKM options IPSTEALTH #support for stealth forwarding +#options IPFILTER_LKM #kernel support for ip_fil.o LKM options TCPDEBUG + +# The following options add sysctl variables for controlling how certain +# TCP packets are handled. +# +# TCP_RESTRICT_RST adds support for blocking the emission of TCP RST packets. +# This is useful on systems which are exposed to SYN floods (e.g. IRC servers) +# or any system which one does not want to be easily portscannable. +# +# TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FIN. This +# prevents nmap et al. from identifying the TCP/IP stack, but breaks support +# for RFC1644 extensions and is not recommended for web servers. +# +options TCP_RESTRICT_RST #restrict emission of TCP RST +options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN # ICMP_BANDLIM enables icmp error response bandwidth limiting. You # typically want this option as it will help protect the machine from Index: sys/netinet/ip_icmp.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.34 diff -u -r1.34 ip_icmp.c --- ip_icmp.c 1999/03/06 23:10:42 1.34 +++ ip_icmp.c 1999/07/26 19:11:51 @@ -69,6 +69,14 @@ SYSCTL_INT(_net_inet_icmp, ICMPCTL_MASKREPL, maskrepl, CTLFLAG_RW, &icmpmaskrepl, 0, ""); +static int logredirect = 0; +SYSCTL_INT(_net_inet_icmp, OID_AUTO, logredirect, CTLFLAG_RW, + &logredirect, 0, ""); + +static int dropredirect = 0; +SYSCTL_INT(_net_inet_icmp, OID_AUTO, dropredirect, CTLFLAG_RW, + &dropredirect, 0, ""); + #ifdef ICMP_BANDLIM /* @@ -462,6 +470,15 @@ return; case ICMP_REDIRECT: + if (logredirect) { + char from[4 * sizeof "123"], dst[4 * sizeof "123"]; + strcpy(from, inet_ntoa(ip->ip_src)); + strcpy(dst, inet_ntoa(icp->icmp_ip.ip_dst)); + printf("icmp_redirect from %s: %s => %s\n", + from, dst, inet_ntoa(icp->icmp_gwaddr)); + } + if (dropredirect) + break; if (code > 3) goto badcode; if (icmplen < ICMP_ADVLENMIN || icmplen < ICMP_ADVLEN(icp) || Index: sys/netinet/tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.87 diff -u -r1.87 tcp_input.c --- tcp_input.c 1999/07/18 14:42:48 1.87 +++ tcp_input.c 1999/07/26 19:11:51 @@ -36,6 +36,7 @@ #include "opt_ipfw.h" /* for ipfw_fwd */ #include "opt_tcpdebug.h" +#include "opt_tcp_input.h" #include #include @@ -89,6 +90,18 @@ &tcp_delack_enabled, 0, "Delay ACK to try and piggyback it onto a data packet"); +#ifdef TCP_RESTRICT_RST +static int restrict_rst = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, restrict_rst, CTLFLAG_RW, + &restrict_rst, 0, "Restrict RST emission"); +#endif + +#ifdef TCP_DROP_SYNFIN +static int drop_synfin = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, drop_synfin, CTLFLAG_RW, + &drop_synfin, 0, "Drop TCP packets with FIN+ACK set"); +#endif + u_long tcp_now; struct inpcbhead tcb; struct inpcbinfo tcbinfo; @@ -336,6 +349,18 @@ } tiflags = ti->ti_flags; +#ifdef TCP_DROP_SYNFIN + /* + * If the drop_synfin option is enabled, drop all packets with + * both the SYN and FIN bits set. This prevents e.g. nmap from + * identifying the TCP/IP stack. + * + * This is incompatible with RFC1644 extensions (T/TCP). + */ + if (drop_synfin && (tiflags & (TH_SYN|TH_FIN)) == TH_SYN|TH_FIN) + goto drop; +#endif + /* * Convert TCP protocol specific fields to host format. */ @@ -1764,6 +1789,10 @@ return; dropwithreset: +#ifdef TCP_RESTRICT_RST + if (restrict_rst) + goto drop; +#endif /* * Generate a RST, dropping incoming segment. * Make ACK acceptable to originator of segment. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 27 3:12: 8 1999 Delivered-To: freebsd-net@freebsd.org Received: from mx2.itb.ac.id (mx2.itb.ac.id [202.249.47.37]) by hub.freebsd.org (Postfix) with SMTP id 724091539B for ; Tue, 27 Jul 1999 03:11:24 -0700 (PDT) (envelope-from waskita@ee.itb.ac.id) Received: (qmail 18246 invoked by uid 1003); 27 Jul 1999 04:44:35 -0000 Received: from mx.ee.itb.ac.id (qmailr@167.205.48.222) by mx2.itb.ac.id with SMTP; 27 Jul 1999 04:44:35 -0000 Received: (qmail 21204 invoked from network); 27 Jul 1999 04:44:34 -0000 Received: from elka.ee.itb.ac.id (qmailr@167.205.48.219) by mx.ee.itb.ac.id with SMTP; 27 Jul 1999 04:44:34 -0000 Received: (qmail 5863 invoked by uid 1033); 27 Jul 1999 04:44:33 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Jul 1999 04:44:33 -0000 Date: Tue, 27 Jul 1999 11:44:33 +0700 (JAVT) From: waskita adijarto To: freebsd-net@FreeBSD.ORG Subject: writing raw ethernet packet in FreeBSD. In-Reply-To: <199907242210.AAA01871@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I want to read & write raw ethernet packet. I can read raw ethernet packet with bpf, but writing to bpf device is not so successful. the ethernet source address always follow the interface's address. Is this the normal behavior of bpf ? I am thinking that I should look at /usr/src/sys/net/bridge.c to create raw ethernet packet ... My FreeBSD box is 2.2.8, my interface card is 3C509 (ep0) & ed0 (some NE2000 compatible) -w- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 27 4:21:42 1999 Delivered-To: freebsd-net@freebsd.org Received: from nexus.plymovent.se (nexus.plymovent.se [212.247.77.253]) by hub.freebsd.org (Postfix) with ESMTP id 56E2E14D1F for ; Tue, 27 Jul 1999 04:21:29 -0700 (PDT) (envelope-from thomas.uhrfelt@plymovent.se) Received: from tu (polaris [192.168.1.21]) by nexus.plymovent.se (8.9.3/8.9.3) with SMTP id NAA58079 for ; Tue, 27 Jul 1999 13:32:19 +0200 (CEST) (envelope-from thomas.uhrfelt@plymovent.se) From: "Thomas Uhrfelt" To: Subject: Usage monitor Date: Tue, 27 Jul 1999 13:20:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am looking for a program that can measure the usage of netresources via our FBSD gateway and display them in an usable manner. Some of the statistics I want to be able to specify is: FTP, HTTP (as in ports) traffic totally and per IP. total traffic based on IP etc.. And then be able to have the program output this to a file so I can mail it to the system administrators on a daily basis. I don't want to run X on this particular machine, so please only textmode programs. Thank you for any help you might supply. Thomas Uhrfelt thomas.uhrfelt@plymovent.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 27 4:25:24 1999 Delivered-To: freebsd-net@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 7E24914D1F for ; Tue, 27 Jul 1999 04:25:20 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id NAA38435; Tue, 27 Jul 1999 13:23:41 +0200 (CEST) (envelope-from des) To: Mohit Aron Cc: freebsd-net@FreeBSD.ORG Subject: Re: FreeBSD tuning for webserver performance References: <199907242205.RAA03294@cs.rice.edu> From: Dag-Erling Smorgrav Date: 27 Jul 1999 13:23:41 +0200 In-Reply-To: Mohit Aron's message of "Sat, 24 Jul 1999 17:05:41 -0500 (CDT)" Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mohit Aron writes: > 3) Increase maxusers (default 10). This allocates more memory to mbuf > pool. This is done in the kernel configuration file. I typically increase > this value to 256. You can tune the size of the mbuf pool and the maximum number of open files separately from maxusers (which also affects stuff like the size of the process table). Read LINT. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 27 4:26:45 1999 Delivered-To: freebsd-net@freebsd.org Received: from des.follo.net (des.follo.net [195.204.143.216]) by hub.freebsd.org (Postfix) with ESMTP id 67A4714DF1; Tue, 27 Jul 1999 04:26:33 -0700 (PDT) (envelope-from des@des.follo.net) Received: (from des@localhost) by des.follo.net (8.9.3/8.9.3) id NAA55736; Tue, 27 Jul 1999 13:26:21 +0200 (CEST) (envelope-from des) To: net@freebsd.org Subject: TCP/IP hardening, take two Organization: Yes Interactive Visit-Us-At: http://www.yes.no/ From: Dag-Erling Smorgrav Date: 27 Jul 1999 13:26:21 +0200 Message-ID: Lines: 308 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I cleaned up the previously posted patches, tested them a little more, and added a sysctl knob for logging SYN+FIN packets (before optionally dropping them). A FreeBSD 4.0-CURRENT machine with these patches and no firewall looks like this to nmap (with tcp.drop_synfin and tcp.restrict_rst enabled): | Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) | Interesting ports on destmp.follo.net (195.204.143.235): | (Not showing ports in state: filtered) | Port State Protocol Service | 22 open tcp ssh | | TCP Sequence Prediction: Class=random positive increments | Difficulty=38742 (Worthy challenge) | No OS matches for host (see http://www.insecure.org/cgi-bin/nmap-submit.cgi). | TCP/IP fingerprint: | TSeq(Class=RI%gcd=2%SI=1429) | TSeq(Class=RI%gcd=1%SI=1026) | TSeq(Class=RI%gcd=1%SI=9756) | T1(Resp=Y%DF=Y%W=402E%ACK=S++%Flags=AS%Ops=M) | T2(Resp=N) | T3(Resp=N) | T4(Resp=N) | T5(Resp=N) | T6(Resp=N) | T7(Resp=N) | PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=F%RIPCK=F%UCK=0%ULEN=134%DAT=E) | | | Nmap run completed -- 1 IP address (1 host up) scanned in 75 seconds Note: The TCP sequence prediction difficulty rating is meaningless, Successive nmap runs show ratings from approx. 5000 to approx. 40000 for the same computer with the same software. DES -- Dag-Erling Smorgrav - des@yes.no Index: etc/defaults/rc.conf =================================================================== RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.23 diff -u -r1.23 rc.conf --- rc.conf 1999/07/26 10:49:33 1.23 +++ rc.conf 1999/07/27 11:18:30 @@ -48,6 +48,12 @@ tcp_extensions="NO" # Set to Yes to turn on RFC1323 extensions. log_in_vain="NO" # Disallow bad connection logging (or YES). tcp_keepalive="YES" # Kill dead TCP connections (or NO). +tcp_drop_synfin="NO" # Set to YES to drop TCP packets with SYN+FIN + # NOTE: this breaks rfc1644 extensions (T/TCP) +tcp_log_synfin="NO" # Set to YES to log TCP packets with SYN+FIN +tcp_restrict_rst="NO" # Set to YES to restrict emission of RST +icmp_dropredirect="NO" # Set to YES to ignore ICMP REDIRECT packets +icmp_logredirect="NO" # Set to YES to log ICMP REDIRECT packets network_interfaces="auto" # List of network interfaces (or "auto"). ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. #ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0xffffffff" # Sample alias entry. Index: etc/rc.network =================================================================== RCS file: /home/ncvs/src/etc/rc.network,v retrieving revision 1.52 diff -u -r1.52 rc.network --- rc.network 1999/07/26 15:17:23 1.52 +++ rc.network 1999/07/27 11:18:30 @@ -197,6 +197,16 @@ echo -n ' broadcast ping responses=YES' sysctl -w net.inet.icmp.bmcastecho=1 >/dev/null fi + + if [ "X$icmp_dropredirect" = X"YES" ]; then + echo -n ' ignore ICMP redirect=YES' + sysctl -w net.inet.icmp.dropredirect=1 >/dev/null + fi + + if [ "X$icmp_logredirect" = X"YES" ]; then + echo -n ' log ICMP redirect=YES' + sysctl -w net.inet.icmp.logredirect=1 >/dev/null + fi if [ "X$gateway_enable" = X"YES" ]; then echo -n ' IP gateway=YES' @@ -216,6 +226,21 @@ if [ "X$tcp_keepalive" = X"YES" ]; then echo -n ' TCP keepalive=YES' sysctl -w net.inet.tcp.always_keepalive=1 >/dev/null + fi + + if [ "X$tcp_drop_synfin" = X"YES" ]; then + echo -n ' drop SYN+FIN packets=YES' + sysctl -w net.inet.tcp.drop_synfin=1 >/dev/null + fi + + if [ "X$tcp_log_synfin" = X"YES" ]; then + echo -n ' log SYN+FIN packets=YES' + sysctl -w net.inet.tcp.log_synfin=1 >/dev/null + fi + + if [ "X$tcp_restrict_rst" = X"YES" ]; then + echo -n ' restrict TCP reset=YES' + sysctl -w net.inet.tcp.restrict_rst=1 >/dev/null fi if [ "X$ipxgateway_enable" = X"YES" ]; then Index: sys/conf/options =================================================================== RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.144 diff -u -r1.144 options --- options 1999/07/05 20:19:34 1.144 +++ options 1999/07/27 11:18:30 @@ -207,6 +207,8 @@ INET opt_inet.h IPDIVERT DUMMYNET opt_ipdn.h +IPFILTER opt_ipfilter.h +IPFILTER_LOG opt_ipfilter.h IPFIREWALL opt_ipfw.h IPFIREWALL_VERBOSE opt_ipfw.h IPFIREWALL_VERBOSE_LIMIT opt_ipfw.h @@ -220,11 +222,11 @@ PPP_BSDCOMP opt_ppp.h PPP_DEFLATE opt_ppp.h PPP_FILTER opt_ppp.h +SLIP_IFF_OPTS opt_slip.h TCP_COMPAT_42 opt_compat.h TCPDEBUG -IPFILTER opt_ipfilter.h -IPFILTER_LOG opt_ipfilter.h -SLIP_IFF_OPTS opt_slip.h +TCP_DROP_SYNFIN opt_tcp_input.h +TCP_RESTRICT_RST opt_tcp_input.h # ATM (HARP version) ATM_CORE opt_atm.h Index: sys/i386/conf/LINT =================================================================== RCS file: /home/ncvs/src/sys/i386/conf/LINT,v retrieving revision 1.620 diff -u -r1.620 LINT --- LINT 1999/07/26 05:47:17 1.620 +++ LINT 1999/07/27 11:18:30 @@ -469,6 +469,20 @@ options IPSTEALTH #support for stealth forwarding options TCPDEBUG +# The following options add sysctl variables for controlling how certain +# TCP packets are handled. +# +# TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FIN. This +# prevents nmap et al. from identifying the TCP/IP stack, but breaks support +# for RFC1644 extensions and is not recommended for web servers. +# +# TCP_RESTRICT_RST adds support for blocking the emission of TCP RST packets. +# This is useful on systems which are exposed to SYN floods (e.g. IRC servers) +# or any system which one does not want to be easily portscannable. +# +options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN +options TCP_RESTRICT_RST #restrict emission of TCP RST + # ICMP_BANDLIM enables icmp error response bandwidth limiting. You # typically want this option as it will help protect the machine from # D.O.S. packet attacks. Index: sys/netinet/ip_icmp.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.34 diff -u -r1.34 ip_icmp.c --- ip_icmp.c 1999/03/06 23:10:42 1.34 +++ ip_icmp.c 1999/07/27 11:18:30 @@ -69,6 +69,14 @@ SYSCTL_INT(_net_inet_icmp, ICMPCTL_MASKREPL, maskrepl, CTLFLAG_RW, &icmpmaskrepl, 0, ""); +static int logredirect = 0; +SYSCTL_INT(_net_inet_icmp, OID_AUTO, logredirect, CTLFLAG_RW, + &logredirect, 0, ""); + +static int dropredirect = 0; +SYSCTL_INT(_net_inet_icmp, OID_AUTO, dropredirect, CTLFLAG_RW, + &dropredirect, 0, ""); + #ifdef ICMP_BANDLIM /* @@ -92,8 +100,8 @@ */ static int icmpbmcastecho = 0; -SYSCTL_INT(_net_inet_icmp, OID_AUTO, bmcastecho, CTLFLAG_RW, &icmpbmcastecho, - 0, ""); +SYSCTL_INT(_net_inet_icmp, OID_AUTO, bmcastecho, CTLFLAG_RW, + &icmpbmcastecho, 0, ""); #ifdef ICMPPRINTFS @@ -462,6 +470,23 @@ return; case ICMP_REDIRECT: + if (logredirect) { + u_long src, dst, gw; + + src = ntohl(ip->ip_src.s_addr); + dst = ntohl(icp->icmp_ip.ip_dst.s_addr); + gw = ntohl(icp->icmp_gwaddr.s_addr); + printf("icmp_redirect from %d.%d.%d.%d: " + "%d.%d.%d.%d => %d.%d.%d.%d\n", + (int)(src >> 24), (int)((src & 0xff0000) >> 16), + (int)((src & 0xff00) >> 8), (int)(src & 0xff), + (int)(dst >> 24), (int)((dst & 0xff0000) >> 16), + (int)((dst & 0xff00) >> 8), (int)(dst & 0xff), + (int)(gw >> 24), (int)((gw & 0xff0000) >> 16), + (int)((gw & 0xff00) >> 8), (int)(gw & 0xff)); + } + if (dropredirect) + break; if (code > 3) goto badcode; if (icmplen < ICMP_ADVLENMIN || icmplen < ICMP_ADVLEN(icp) || Index: sys/netinet/tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.87 diff -u -r1.87 tcp_input.c --- tcp_input.c 1999/07/18 14:42:48 1.87 +++ tcp_input.c 1999/07/27 11:18:30 @@ -36,6 +36,7 @@ #include "opt_ipfw.h" /* for ipfw_fwd */ #include "opt_tcpdebug.h" +#include "opt_tcp_input.h" #include #include @@ -78,7 +79,7 @@ struct tcpstat tcpstat; SYSCTL_STRUCT(_net_inet_tcp, TCPCTL_STATS, stats, CTLFLAG_RD, - &tcpstat , tcpstat, "TCP statistics (struct tcpstat, netinet/tcp_var.h)"); + &tcpstat, tcpstat, "TCP statistics (struct tcpstat, netinet/tcp_var.h)"); static int log_in_vain = 0; SYSCTL_INT(_net_inet_tcp, OID_AUTO, log_in_vain, CTLFLAG_RW, @@ -89,6 +90,21 @@ &tcp_delack_enabled, 0, "Delay ACK to try and piggyback it onto a data packet"); +#ifdef TCP_RESTRICT_RST +static int restrict_rst = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, restrict_rst, CTLFLAG_RW, + &restrict_rst, 0, "Restrict RST emission"); +#endif + +#ifdef TCP_DROP_SYNFIN +static int drop_synfin = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, drop_synfin, CTLFLAG_RW, + &drop_synfin, 0, "Drop TCP packets with SYN+FIN set"); +static int log_synfin = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, log_synfin, CTLFLAG_RW, + &log_synfin, 0, "Log TCP packets with SYN+FIN set"); +#endif + u_long tcp_now; struct inpcbhead tcb; struct inpcbinfo tcbinfo; @@ -336,6 +352,28 @@ } tiflags = ti->ti_flags; +#ifdef TCP_DROP_SYNFIN + /* + * If the drop_synfin option is enabled, drop all packets with + * both the SYN and FIN bits set. This prevents e.g. nmap from + * identifying the TCP/IP stack. + * + * This is incompatible with RFC1644 extensions (T/TCP). + */ + if (tiflags & TH_SYN && tiflags & TH_FIN) { + if (log_synfin) { + u_long src; + + src = ntohl(ti->ti_src.s_addr); + printf("SYN+FIN from %d.%d.%d.%d\n", + (int)(src >> 24), (int)((src & 0xff0000) >> 16), + (int)((src & 0xff00) >> 8), (int)(src & 0xff)); + } + if (drop_synfin) + goto drop; + } +#endif + /* * Convert TCP protocol specific fields to host format. */ @@ -1764,6 +1802,10 @@ return; dropwithreset: +#ifdef TCP_RESTRICT_RST + if (restrict_rst) + goto drop; +#endif /* * Generate a RST, dropping incoming segment. * Make ACK acceptable to originator of segment. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 27 9:15:49 1999 Delivered-To: freebsd-net@freebsd.org Received: from mail.dbitech.bc.ca (i.caniserv.com [139.142.95.1]) by hub.freebsd.org (Postfix) with SMTP id F122E14DAE for ; Tue, 27 Jul 1999 09:15:37 -0700 (PDT) (envelope-from darcy@ok-connect.com) Received: (qmail 24499 invoked from network); 27 Jul 1999 16:29:25 -0000 Received: from ccliii.caniserv.com (HELO dbitech) (darcyb@139.142.95.253) by 139.142.95.10 with SMTP; 27 Jul 1999 16:29:25 -0000 Message-Id: <3.0.32.19990727091747.01696130@mail.ok-connect.com> X-Sender: darcyb@mail.ok-connect.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 27 Jul 1999 09:17:47 -0700 To: freebsd-net@freebsd.org From: Darcy Buskermolen Subject: Re: writing raw ethernet packet in FreeBSD. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Have a look at the following URL it contains examples form a rather good book on how to write raw datagrams using libpcap. http://www.kohala.com/~rstevens/unpv12e.html //DB At 11:44 AM 7/27/99 +0700, you wrote: > >I want to read & write raw ethernet packet. I can read raw ethernet >packet with bpf, but writing to bpf device is not so successful. the >ethernet source address always follow the interface's address. Is this the >normal behavior of bpf ? I am thinking that I should look at >/usr/src/sys/net/bridge.c to create raw ethernet packet ... > >My FreeBSD box is 2.2.8, my interface card is 3C509 (ep0) & ed0 (some >NE2000 compatible) > >-w- > > > >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 27 9:23:13 1999 Delivered-To: freebsd-net@freebsd.org Received: from mail.dbitech.bc.ca (i.caniserv.com [139.142.95.1]) by hub.freebsd.org (Postfix) with SMTP id 5B71E14DB9 for ; Tue, 27 Jul 1999 09:23:09 -0700 (PDT) (envelope-from darcy@ok-connect.com) Received: (qmail 24891 invoked from network); 27 Jul 1999 16:36:42 -0000 Received: from ccliii.caniserv.com (HELO dbitech) (darcyb@139.142.95.253) by 139.142.95.10 with SMTP; 27 Jul 1999 16:36:42 -0000 Message-Id: <3.0.32.19990727092503.016961a0@mail.ok-connect.com> X-Sender: darcyb@mail.ok-connect.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 27 Jul 1999 09:25:04 -0700 To: freebsd-net@freebsd.org From: Darcy Buskermolen Subject: Re: Usage monitor Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org SNMP and MRTG ap prolly the kind of tools you would like. You can use an adition to SNMP (Simple Network Managemnet Protocol) available at http://www.plugcom.ru/~vova/ipfw-snmp.tgz to snmp enable your IPFW accounting rules. You can then use MRTG (Multi Router Traffic Grapher) on a diffrent box to poll the gateway and generare graphs of the usage you are asking for. SNMP is available in /usr/ports/net/ucd-snmp/ MRTG is available in /usr/ports/net/mrtg/ \\DB At 01:20 PM 7/27/99 +0200, you wrote: >I am looking for a program that can measure the usage of netresources via >our FBSD gateway and display them in an usable manner. Some of the >statistics I want to be able to specify is: > >FTP, HTTP (as in ports) traffic totally and per IP. >total traffic based on IP etc.. > >And then be able to have the program output this to a file so I can mail it >to the system administrators on a daily basis. I don't want to run X on this >particular machine, so please only textmode programs. Thank you for any help >you might supply. > > > > >Thomas Uhrfelt >thomas.uhrfelt@plymovent.se > > > >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 27 9:38: 0 1999 Delivered-To: freebsd-net@freebsd.org Received: from nexus.plymovent.se (nexus.plymovent.se [212.247.77.253]) by hub.freebsd.org (Postfix) with ESMTP id E697814D15 for ; Tue, 27 Jul 1999 09:37:55 -0700 (PDT) (envelope-from thomas.uhrfelt@plymovent.se) Received: from tu (polaris [192.168.1.21]) by nexus.plymovent.se (8.9.3/8.9.3) with SMTP id SAA61012; Tue, 27 Jul 1999 18:47:51 +0200 (CEST) (envelope-from thomas.uhrfelt@plymovent.se) From: "Thomas Uhrfelt" To: "Darcy Buskermolen" Cc: Subject: RE: Usage monitor Date: Tue, 27 Jul 1999 18:36:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3.0.32.19990727092503.016961a0@mail.ok-connect.com> Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > SNMP and MRTG ap prolly the kind of tools you would like. > You can use an adition to SNMP (Simple Network Managemnet Protocol) > available at http://www.plugcom.ru/~vova/ipfw-snmp.tgz to snmp enable your > IPFW accounting rules. > You can then use MRTG (Multi Router Traffic Grapher) on a diffrent box to > poll the gateway and generare graphs of the usage you are asking for. > SNMP is available in /usr/ports/net/ucd-snmp/ > MRTG is available in /usr/ports/net/mrtg/ Thanks but I was hoping for some textbased tools, so I could alter the data and present it in a "nice" way to our users (using Perl).. MRTG don't really seem like a sollution for me really. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 27 10:44:56 1999 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 19063152BE for ; Tue, 27 Jul 1999 10:44:47 -0700 (PDT) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id MAA25266; Tue, 27 Jul 1999 12:44:26 -0500 (CDT) From: Mohit Aron Message-Id: <199907271744.MAA25266@cs.rice.edu> Subject: Re: FreeBSD tuning for webserver performance To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Tue, 27 Jul 1999 12:44:25 -0500 (CDT) Cc: freebsd-net@freebsd.org In-Reply-To: from "Dag-Erling Smorgrav" at Jul 27, 99 01:23:41 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > You can tune the size of the mbuf pool and the maximum number of open > files separately from maxusers (which also affects stuff like the size > of the process table). Read LINT. > Thanks, I wasn't aware of this. Whenever the kernel runs out of mbuf clusters it reports "Out of mbuf clusters - increase max users" on the console. I think this might need to get fixed. - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 27 11: 5:18 1999 Delivered-To: freebsd-net@freebsd.org Received: from ryouko.nas.nasa.gov (ryouko.nas.nasa.gov [129.99.34.113]) by hub.freebsd.org (Postfix) with ESMTP id A1573152E9 for ; Tue, 27 Jul 1999 11:05:04 -0700 (PDT) (envelope-from greg@ryouko.nas.nasa.gov) Received: from ryouko.nas.nasa.gov (localhost [127.0.0.1]) by ryouko.nas.nasa.gov (8.9.3/NAS8.8.7n) with ESMTP id LAA09269; Tue, 27 Jul 1999 11:02:18 -0700 (PDT) Message-Id: <199907271802.LAA09269@ryouko.nas.nasa.gov> To: waskita adijarto Cc: freebsd-net@freebsd.org Subject: Re: writing raw ethernet packet in FreeBSD. In-reply-to: Your message of "Tue, 27 Jul 1999 11:44:33 +0700." Date: Tue, 27 Jul 1999 11:02:18 -0700 From: "Gregory P. Smith" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I want to read & write raw ethernet packet. I can read raw ethernet > packet with bpf, but writing to bpf device is not so successful. the > ethernet source address always follow the interface's address. Is this the > normal behavior of bpf ? I am thinking that I should look at > /usr/src/sys/net/bridge.c to create raw ethernet packet ... > > My FreeBSD box is 2.2.8, my interface card is 3C509 (ep0) & ed0 (some > NE2000 compatible) It sounds like you want to write a -completely- raw packet using your own ethernet address? If so, look in the NetBSD bpf.h/bpf.c sources for the BIOC{S,G}HDRCMPLT ioctls. (it doesn't look like anyone ever added this to FreeBSD; its real simple to apply) It allows you to tell the Ethernet driver not to rewrite the device's hardware address into the packet before sending it to the card. Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 27 17:46:27 1999 Delivered-To: freebsd-net@freebsd.org Received: from scam.xcf.berkeley.edu (scam.XCF.Berkeley.EDU [128.32.43.201]) by hub.freebsd.org (Postfix) with SMTP id D441614D97 for ; Tue, 27 Jul 1999 17:46:24 -0700 (PDT) (envelope-from grady@scam.XCF.Berkeley.EDU) Received: (qmail 5026 invoked by uid 348); 28 Jul 1999 00:46:05 -0000 Received: from localhost (HELO scam.XCF.Berkeley.EDU) (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Jul 1999 00:46:05 -0000 To: freebsd-net@freebsd.org Subject: Re: network hangs From: grady@xcf.berkeley.edu (Steven Grady) In-reply-to: Your message of Mon, 26 Jul 1999 07:26:15 -0400 (EDT) <199907261126.HAA93252@bilver.magicnet.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5022.933122764.1@scam.XCF.Berkeley.EDU> Date: Tue, 27 Jul 1999 17:46:05 -0700 Message-Id: <19990728004624.D441614D97@hub.freebsd.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I got a response to my question; I thought I'd reply to the list. > I have a question about this. > > > dmesg output related to networking: > > > > de0: rev 0x22 int a irq 12 on pci0.10.0 > > de0: Asanta 21140A [10-100Mb/s] pass 2.2 > > de0: address aa:bb:cc:dd:ee:ff > > de0: enabling 10baseT port > ^^^^^^^^^^^^^^ > > de1: rev 0x22 int a irq 12 on pci0.11.0 > > de1: Asanta 21140A [10-100Mb/s] pass 2.2 > > de1: address gg:hh:ii:jj:kk:ll > > de1: enabling 10baseT port > ^^^^^^^^^^^^^^^^ > > Shouldn't that be 100baseT? Or does the kernel not report this. I'm not sure, but the connection is definitely 100 Mbit, as verified by a fast transfer of a large file But meanwhile, we reconfigured the interface to talk at 10Mbit, but that didn't help. > It's been so long since I've booted one of my machines I've > forgotten. How I envy you... > I know sometimes some switches have a bit of difficulty in this. > > You mentioned it happened on two different BSD system. The > question is (and I couldn't tell this from your answer) - was > the other BSD system also on this network or was it on a > totally unrelated/unconnected network. If it's the former it might > not be a BSD problem. It was this network, but I still think it's likely to be FreeBSD's fault. Latest data point: when the communication goes down, other machines (Win98, Mac) speaking through a hub directly to the DSL line (as opposed to through the FreeBSD gateway) can still access the network. It's just the FreeBSD machine that stops talking to it. BTW, we are just about out of options. We have installed 3.2, but that hasn't helped. We configured the internal interface to use 10Mbit instead of 100Mbit, and it seems to make the problems occur more rarely, but they still happen. We recompiled if_de.c with some of the debugging flags turned on, but no messages are being generated. Obviously a gateway that need to be rebooted multiple times per day is not an acceptable situation, so we will probably have to switch away from FreeBSD. I hate to switch to Linux, but my guess that if FreeBSD has this problem, then other BSDs do as well. Does anyone have any final suggestions before we give up on FreeBSD for our gateway (what a sad state of affairs)? Steven "You'd better ask yourself `Do I feel lucky?' Well, do you, punk?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 27 19:51: 9 1999 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 7365415314 for ; Tue, 27 Jul 1999 19:50:55 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id WAA06009; Tue, 27 Jul 1999 22:50:50 -0400 (EDT) (envelope-from wollman) Date: Tue, 27 Jul 1999 22:50:50 -0400 (EDT) From: Garrett Wollman Message-Id: <199907280250.WAA06009@khavrinen.lcs.mit.edu> To: Dag-Erling Smorgrav Cc: net@FreeBSD.ORG Subject: TCP/IP hardening In-Reply-To: References: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > * net.inet.tcp.restrict_rst: if set to 1, do not emit TCP RST > packets. Conditional on the TCP_RESTRICT_RST kernel option, which > defaults to off. Why would you want to break the TCP implementation? > * net.inet.tcp.drop_synfin: if set to 1, drop TCP packets with both > the SYN and FIN options set. Conditional on the TCP_DROP_SYNFIN > kernel option, which defaults to off. Again, why would you do that? If it bothers you so much, then go hide behind a firewall. +# TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FIN. This +# prevents nmap et al. from identifying the TCP/IP stack, but breaks support +# for RFC1644 extensions and is not recommended for web servers. It also breaks support for the TCP protocol, regardless of the state of RFC 1644. Any log messages which can be evoked by an attacker should be rate-limited. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 27 20: 9:21 1999 Delivered-To: freebsd-net@freebsd.org Received: from magicnet.magicnet.net (magicnet.magicnet.net [204.96.116.9]) by hub.freebsd.org (Postfix) with ESMTP id 1BABB1518B for ; Tue, 27 Jul 1999 20:09:16 -0700 (PDT) (envelope-from bill@bilver.magicnet.net) Received: (from uucp@localhost) by magicnet.magicnet.net (8.8.6/8.8.8) with UUCP id XAA27091 for freebsd-net@freebsd.org; Tue, 27 Jul 1999 23:07:23 -0400 (EDT) Received: (from bill@localhost) by bilver.magicnet.net (8.9.1/8.9.1) id WAA10638 for freebsd-net@freebsd.org; Tue, 27 Jul 1999 22:43:17 -0400 (EDT) From: Bill Vermillion Message-Id: <199907280243.WAA10638@bilver.magicnet.net> Subject: Re: network hangs In-Reply-To: <19990728004624.D441614D97@hub.freebsd.org> from Steven Grady at "Jul 27, 1999 5:46: 5 pm" To: freebsd-net@freebsd.org Date: Tue, 27 Jul 1999 22:43:16 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Steven Grady recently said: > I got a response to my question; I thought I'd reply to the list. > > I have a question about this. > > > de0: enabling 10baseT port > > ^^^^^^^^^^^^^^ > > Shouldn't that be 100baseT? Or does the kernel not report this. > I'm not sure, but the connection is definitely 100 Mbit, as verified > by a fast transfer of a large file But meanwhile, we reconfigured the > interface to talk at 10Mbit, but that didn't help. I have heard of instances where auto-negotiation failed - and the best bet was to configure the NIC card to be physically at one speed or the other. -- 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 Wed Jul 28 1:58:11 1999 Delivered-To: freebsd-net@freebsd.org Received: from des.follo.net (des.follo.net [195.204.143.216]) by hub.freebsd.org (Postfix) with ESMTP id 2D01A1523E for ; Wed, 28 Jul 1999 01:58:07 -0700 (PDT) (envelope-from des@des.follo.net) Received: (from des@localhost) by des.follo.net (8.9.3/8.9.3) id KAA61450; Wed, 28 Jul 1999 10:56:11 +0200 (CEST) (envelope-from des) To: Garrett Wollman Cc: Dag-Erling Smorgrav , net@FreeBSD.ORG Subject: Re: TCP/IP hardening References: <199907280250.WAA06009@khavrinen.lcs.mit.edu> Organization: Yes Interactive Visit-Us-At: http://www.yes.no/ From: Dag-Erling Smorgrav Date: 28 Jul 1999 10:56:11 +0200 In-Reply-To: Garrett Wollman's message of "Tue, 27 Jul 1999 22:50:50 -0400 (EDT)" Message-ID: Lines: 20 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman writes: > < said: > > * net.inet.tcp.restrict_rst: if set to 1, do not emit TCP RST > > packets. Conditional on the TCP_RESTRICT_RST kernel option, which > > defaults to off. > Why would you want to break the TCP implementation? You've never run an IRC server, have you? > > * net.inet.tcp.drop_synfin: if set to 1, drop TCP packets with both > > the SYN and FIN options set. Conditional on the TCP_DROP_SYNFIN > > kernel option, which defaults to off. > Again, why would you do that? If it bothers you so much, then go > hide behind a firewall. Eats CPU. DES -- Dag-Erling Smorgrav - des@yes.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 28 7:31:43 1999 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id D992314E1D for ; Wed, 28 Jul 1999 07:31:40 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id KAA07927; Wed, 28 Jul 1999 10:31:14 -0400 (EDT) (envelope-from wollman) Date: Wed, 28 Jul 1999 10:31:14 -0400 (EDT) From: Garrett Wollman Message-Id: <199907281431.KAA07927@khavrinen.lcs.mit.edu> To: Dag-Erling Smorgrav Cc: net@FreeBSD.ORG Subject: Re: TCP/IP hardening In-Reply-To: References: <199907280250.WAA06009@khavrinen.lcs.mit.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > You've never run an IRC server, have you? Nope -- never will, either. There's a notion, at least in our legal system, of ``maintaining an attractive nuisance''.... -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 28 8:45:12 1999 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 37DB2154CF for ; Wed, 28 Jul 1999 08:45:09 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id LAA09659; Wed, 28 Jul 1999 11:44:42 -0400 (EDT) (envelope-from wollman) Date: Wed, 28 Jul 1999 11:44:42 -0400 (EDT) From: Garrett Wollman Message-Id: <199907281544.LAA09659@khavrinen.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: net@freebsd.org Subject: Re: cvs commit: src/release/sysinstall tcpip.c In-Reply-To: <5505.932695893@zippy.cdrom.com> References: <99Jul23.070924est.40350@border.alcanet.com.au> <5505.932695893@zippy.cdrom.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I actually share your opinion about the proper defense against > sniffing being proper network design (use switches/vlans/etc) and > not turning off bpf, but I'm not the one you need to convince here. :-) Switches won't help (unless you turn learning off and manually configure every Ethernet address in your entire network into every switch). All an attacker has to do to sniff your packets is to send packets pretending to be you, thereby causing the switches to learn the attacker's location. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 28 9:33:14 1999 Delivered-To: freebsd-net@freebsd.org Received: from carlsbad.idir.net (carlsbad.idir.net [209.172.194.69]) by hub.freebsd.org (Postfix) with ESMTP id 0166614BE2 for ; Wed, 28 Jul 1999 09:33:03 -0700 (PDT) (envelope-from brown61@sutv.com) Received: from mthomure (port04.well1.idir.net [209.172.221.6]) by carlsbad.idir.net (8.8.5/8.7.3) with SMTP id LAA04507 for ; Wed, 28 Jul 1999 11:32:47 -0500 (CDT) Date: Wed, 28 Jul 1999 11:32:47 -0500 (CDT) Message-Id: <199907281632.LAA04507@carlsbad.idir.net> X-Sender: brown61@sutv.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: net@freebsd.org From: brown61@sutv.com (Evan Brown) Subject: firewall/proxy Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ok, im trying to set up a computer to be a "gateway" to the net from my local network. the local network is using a private ip block, and i want to limit who gets to use the net. we are setting up a firewall because we ahve a mainframe computer on here, that we need to keep people out of. the client computers need to be able to connect to this mainframe computer, and the net at the same time though the network connection. how shall i go about setting up this freebsd box? please send all replies to this address admin@wgtn.com thanks Evan Brown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 28 12:21:36 1999 Delivered-To: freebsd-net@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 97ADE15175 for ; Wed, 28 Jul 1999 12:21:34 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA06628; Wed, 28 Jul 1999 12:20:50 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Garrett Wollman Cc: net@FreeBSD.ORG Subject: Re: cvs commit: src/release/sysinstall tcpip.c In-reply-to: Your message of "Wed, 28 Jul 1999 11:44:42 EDT." <199907281544.LAA09659@khavrinen.lcs.mit.edu> Date: Wed, 28 Jul 1999 12:20:50 -0700 Message-ID: <6624.933189650@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Switches won't help (unless you turn learning off and manually > configure every Ethernet address in your entire network into every > switch). All an attacker has to do to sniff your packets is to send > packets pretending to be you, thereby causing the switches to learn > the attacker's location. Gah. Is there any functionality reason why a switch would *need* to behave like that? I'm not going to argue the point that this constitutes a current vulnerability for switches, but I am wondering why it could be considered anything short of brain-damaged for a switch's learning algorithm to behave that way. Sure, let me swap ports, but unlearn the old port assignment before doing so and don't just bridge the two together, as you say, is my general feeling here. Why do switches do this? - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 28 12:44: 6 1999 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id E138714C49 for ; Wed, 28 Jul 1999 12:44:04 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id PAA10505; Wed, 28 Jul 1999 15:43:17 -0400 (EDT) (envelope-from wollman) Date: Wed, 28 Jul 1999 15:43:17 -0400 (EDT) From: Garrett Wollman Message-Id: <199907281943.PAA10505@khavrinen.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: Garrett Wollman , net@FreeBSD.ORG Subject: Re: cvs commit: src/release/sysinstall tcpip.c In-Reply-To: <6624.933189650@zippy.cdrom.com> References: <199907281544.LAA09659@khavrinen.lcs.mit.edu> <6624.933189650@zippy.cdrom.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Gah. Is there any functionality reason why a switch would *need* to > behave like that? I'm not going to argue the point that this > constitutes a current vulnerability for switches, but I am wondering > why it could be considered anything short of brain-damaged for a > switch's learning algorithm to behave that way. Well, there are only two possibilities, each implemented by some set of vendors: 1) Learn the ``new'' location of each station immediately. 2) Learn the ``new'' location of each station when its old entry times out of a cache somewhere. The first is generally preferred by network managers such as myself because otherwise our users would be constantly bothering us to flush caches whenever they moved from one location to another -- and this would wreak havoc with wireless roaming. The second is implemented by vendors who didn't have the hardware skills to implement a wire-speed MAC forwarding table. The way this works out under attack conditions is that switches which implement (1) will send packets to whichever port they last heard that address on, and switches which implement (2) have some level of damping such that the old port has to be quiet (or disconnected) for some time before a new location can be learned. (Actually, the new location is learned immediately, but isn't used until the old location times out from the lower-layer cache.) The end result, in any event, is that an attacker can cause packets intended for one station to be diverted to another for some period of time that depends on the strategy implemented by the switch and the frequency of transmissions by the station under attack. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 28 15: 0: 4 1999 Delivered-To: freebsd-net@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 7A99714C8E for ; Wed, 28 Jul 1999 15:00:02 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: from localhost (billf@localhost) by jade.chc-chimes.com (8.9.3/8.9.3) with ESMTP id RAA16938; Wed, 28 Jul 1999 17:01:21 -0400 (EDT) (envelope-from billf@jade.chc-chimes.com) Date: Wed, 28 Jul 1999 17:01:21 -0400 (EDT) From: Bill Fumerola To: Garrett Wollman Cc: "Jordan K. Hubbard" , net@FreeBSD.ORG Subject: Re: cvs commit: src/release/sysinstall tcpip.c In-Reply-To: <199907281544.LAA09659@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 28 Jul 1999, Garrett Wollman wrote: > Switches won't help (unless you turn learning off and manually > configure every Ethernet address in your entire network into every > switch). All an attacker has to do to sniff your packets is to send > packets pretending to be you, thereby causing the switches to learn > the attacker's location. Not when I tell my switch that port 1 is VLAN 1 and port 2 is VLAN 2. Port 1 will never see port 2's traffic. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 28 19:27:30 1999 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 25094154DB for ; Wed, 28 Jul 1999 19:27:23 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id WAA11541; Wed, 28 Jul 1999 22:26:34 -0400 (EDT) (envelope-from wollman) Date: Wed, 28 Jul 1999 22:26:34 -0400 (EDT) From: Garrett Wollman Message-Id: <199907290226.WAA11541@khavrinen.lcs.mit.edu> To: Bill Fumerola Cc: Garrett Wollman , "Jordan K. Hubbard" , net@FreeBSD.ORG Subject: Re: cvs commit: src/release/sysinstall tcpip.c In-Reply-To: References: <199907281544.LAA09659@khavrinen.lcs.mit.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Not when I tell my switch that port 1 is VLAN 1 and port 2 is VLAN 2. > Port 1 will never see port 2's traffic. It's generally considered something less than manageable to assign a separate /30 to every single machine in your network. Granted, I for one have the address space to burn, but most people I know don't. :-) wollman@khavrinen$ rsh mintaka fgrep ' A ' /etc/named.db/lcs.db | wc -l 4156 Oops... my switches only support 256 router interfaces. I guess I can't use your idea to increase my address-space utilization from 0.5% to 2.1%. Oh well.... -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 29 5:59:44 1999 Delivered-To: freebsd-net@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 0EAA31506E for ; Thu, 29 Jul 1999 05:59:39 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: from localhost (billf@localhost) by jade.chc-chimes.com (8.9.3/8.9.3) with ESMTP id IAA18376; Thu, 29 Jul 1999 08:00:48 -0400 (EDT) (envelope-from billf@jade.chc-chimes.com) Date: Thu, 29 Jul 1999 08:00:48 -0400 (EDT) From: Bill Fumerola To: Garrett Wollman Cc: "Jordan K. Hubbard" , net@FreeBSD.ORG Subject: Re: cvs commit: src/release/sysinstall tcpip.c In-Reply-To: <199907290226.WAA11541@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 28 Jul 1999, Garrett Wollman wrote: > < said: > > > Not when I tell my switch that port 1 is VLAN 1 and port 2 is VLAN 2. > > Port 1 will never see port 2's traffic. > > It's generally considered something less than manageable to assign a > separate /30 to every single machine in your network. Granted, I > for one have the address space to burn, but most people I know don't. > :-) > > wollman@khavrinen$ rsh mintaka fgrep ' A ' /etc/named.db/lcs.db | wc -l > 4156 > > Oops... my switches only support 256 router interfaces. I guess I > can't use your idea to increase my address-space utilization from 0.5% > to 2.1%. Oh well.... I'm not talking about IP level, I'm talking about layer 2. I'll repeat my previous statement: If I put two different machines on seperate VLANs on my switch it doesn't matter what network protocol they run, they will never see each other. VLANs are not dependent on subnets. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - PS. maybe we're talking about different subjects here. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 29 7:34:53 1999 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 3E16814C0A for ; Thu, 29 Jul 1999 07:34:47 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id KAA13492; Thu, 29 Jul 1999 10:34:22 -0400 (EDT) (envelope-from wollman) Date: Thu, 29 Jul 1999 10:34:22 -0400 (EDT) From: Garrett Wollman Message-Id: <199907291434.KAA13492@khavrinen.lcs.mit.edu> To: Bill Fumerola Cc: Garrett Wollman , "Jordan K. Hubbard" , net@FreeBSD.ORG Subject: Re: cvs commit: src/release/sysinstall tcpip.c In-Reply-To: References: <199907290226.WAA11541@khavrinen.lcs.mit.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I'm not talking about IP level, I'm talking about layer 2. I'll repeat my > previous statement: If I put two different machines on seperate VLANs > on my switch it doesn't matter what network protocol they run, they will > never see each other. > VLANs are not dependent on subnets. They are if you expect to run IP and have machines communicate with each other. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 29 12:40:36 1999 Delivered-To: freebsd-net@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id AB652150E6 for ; Thu, 29 Jul 1999 12:40:27 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.224] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 119s1d-0006wI-00; Thu, 29 Jul 1999 09:23:18 -0600 Message-ID: <37A071E3.9E565046@softweyr.com> Date: Thu, 29 Jul 1999 09:23:15 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Bill Vermillion Cc: freebsd-net@FreeBSD.ORG Subject: Re: network hangs References: <199907280243.WAA10638@bilver.magicnet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bill Vermillion wrote: > > Steven Grady recently said: > > I got a response to my question; I thought I'd reply to the list. > > > > I have a question about this. > > > > > de0: enabling 10baseT port > > > ^^^^^^^^^^^^^^ > > > > Shouldn't that be 100baseT? Or does the kernel not report this. > > > I'm not sure, but the connection is definitely 100 Mbit, as verified > > by a fast transfer of a large file But meanwhile, we reconfigured the > > interface to talk at 10Mbit, but that didn't help. > > I have heard of instances where auto-negotiation failed - and > the best bet was to configure the NIC card to be physically at > one speed or the other. And the switch port, too. If you've got a 100BaseTX card plugged into a switch, just hardwire both for 100BaseTX FullDuplex and be happy. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.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 29 17:47:47 1999 Delivered-To: freebsd-net@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 5060414D5F for ; Thu, 29 Jul 1999 17:47:43 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id RAA09280; Thu, 29 Jul 1999 17:46:04 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id RAA22845; Thu, 29 Jul 1999 17:43:50 -0700 Received: from softweyr.com (dyn5.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA02777; Thu, 29 Jul 99 17:46:01 PDT Message-Id: <37A0F5C9.48F4A442@softweyr.com> Date: Thu, 29 Jul 1999 18:46:01 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Garrett Wollman Cc: Bill Fumerola , "Jordan K. Hubbard" , net@FreeBSD.ORG Subject: Re: cvs commit: src/release/sysinstall tcpip.c References: <199907290226.WAA11541@khavrinen.lcs.mit.edu> <199907291434.KAA13492@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman wrote: > > < said: > > > I'm not talking about IP level, I'm talking about layer 2. I'll repeat my > > previous statement: If I put two different machines on seperate VLANs > > on my switch it doesn't matter what network protocol they run, they will > > never see each other. > > > VLANs are not dependent on subnets. > > They are if you expect to run IP and have machines communicate with > each other. If you do that on a VLAN switch, you'll have to route between the two VLANs. The VLANs are seperate networks which happen to share the same physical space, that's why they're called Virtual LANs. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.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 29 17:57:25 1999 Delivered-To: freebsd-net@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 2B13114E96 for ; Thu, 29 Jul 1999 17:57:19 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id RAA09362; Thu, 29 Jul 1999 17:54:36 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id RAA23016; Thu, 29 Jul 1999 17:52:22 -0700 Received: from softweyr.com (dyn5.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA03191; Thu, 29 Jul 99 17:54:34 PDT Message-Id: <37A0F7C9.676F675C@softweyr.com> Date: Thu, 29 Jul 1999 18:54:33 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Bill Fumerola Cc: Garrett Wollman , "Jordan K. Hubbard" , net@FreeBSD.ORG Subject: Re: cvs commit: src/release/sysinstall tcpip.c References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bill Fumerola wrote: > > On Wed, 28 Jul 1999, Garrett Wollman wrote: > > > Switches won't help (unless you turn learning off and manually > > configure every Ethernet address in your entire network into every > > switch). All an attacker has to do to sniff your packets is to send > > packets pretending to be you, thereby causing the switches to learn > > the attacker's location. > > Not when I tell my switch that port 1 is VLAN 1 and port 2 is VLAN 2. > Port 1 will never see port 2's traffic. Or turn on VLAN Authentication, then he CAN'T send any packets as you unless he knows your VLAN password. If he tries, and your MAC and/or IP address is already known in that VLAN, it will turn off the port and send an alert to the Network Management System, too. Oh, how I love this networking stuff. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.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 29 20:16:29 1999 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id E8E251566E for ; Thu, 29 Jul 1999 20:16:15 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id XAA15418; Thu, 29 Jul 1999 23:15:48 -0400 (EDT) (envelope-from wollman) Date: Thu, 29 Jul 1999 23:15:48 -0400 (EDT) From: Garrett Wollman Message-Id: <199907300315.XAA15418@khavrinen.lcs.mit.edu> To: Wes Peters Cc: net@FreeBSD.ORG Subject: Re: cvs commit: src/release/sysinstall tcpip.c In-Reply-To: <37A0F5C9.48F4A442@softweyr.com> References: <199907290226.WAA11541@khavrinen.lcs.mit.edu> <199907291434.KAA13492@khavrinen.lcs.mit.edu> <37A0F5C9.48F4A442@softweyr.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > The VLANs are seperate networks which happen to share the same physical > space, that's why they're called Virtual LANs. What Xylan^H^H^H^H^HPa^H^HAlcatel happens to mean by ``VLAN'' is not necessarily the same thing as other vendor means, is not necessarily the same as the abstract model of IEEE 802.1Q. Aren't standards wonderful? In the hardware we use, VLANs are a strict superset of (logical) router interfaces -- that is to say, you can't route packets except between two VLANs, and you can't comunicate between two VLANs except through a router interface. Billf was suggesting that every host be in its own VLAN, which of course would mean that it could not talk to anything else without the intercession of a router interface, which in turn requires an IP subnet of at least minimum (/30) size, which would waste 75% of one's address space. I pointed out in response to Bill that, while our Lab does in fact have oceans of globally-routeable address space, we could not in practice give a /30 to each one of our four-thousand-someodd machines because our switches support a maximum of 256 router interfaces. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 29 22:35: 6 1999 Delivered-To: freebsd-net@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 64F2F14DD2 for ; Thu, 29 Jul 1999 22:34:55 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: from localhost (billf@localhost) by jade.chc-chimes.com (8.9.3/8.9.3) with ESMTP id AAA01578; Fri, 30 Jul 1999 00:35:37 -0400 (EDT) (envelope-from billf@jade.chc-chimes.com) Date: Fri, 30 Jul 1999 00:35:37 -0400 (EDT) From: Bill Fumerola To: Garrett Wollman Cc: Wes Peters , net@FreeBSD.ORG Subject: Re: cvs commit: src/release/sysinstall tcpip.c In-Reply-To: <199907300315.XAA15418@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 29 Jul 1999, Garrett Wollman wrote: > Billf was suggesting that every host be in its own VLAN, which of > course would mean that it could not talk to anything else without the > intercession of a router interface, which in turn requires an IP > subnet of at least minimum (/30) size, which would waste 75% of one's > address space. I pointed out in response to Bill that, while our Lab > does in fact have oceans of globally-routeable address space, we could > not in practice give a /30 to each one of our four-thousand-someodd > machines because our switches support a maximum of 256 router > interfaces. Just to clarify, I was advocating this for servers that you really, really felt that had to be ultra-secure. I'm not as lucky as the wizards at MIT, I only have a /24 of globally routable space. Naturally, I don't use this in practice, I have a PIX and a lot of DMZ-type VLANs, and this has worked well for me. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 30 3:22:47 1999 Delivered-To: freebsd-net@freebsd.org Received: from des.follo.net (des.follo.net [195.204.143.216]) by hub.freebsd.org (Postfix) with ESMTP id C5CF414E96 for ; Fri, 30 Jul 1999 03:22:43 -0700 (PDT) (envelope-from des@des.follo.net) Received: (from des@localhost) by des.follo.net (8.9.3/8.9.3) id MAA11929; Fri, 30 Jul 1999 12:22:28 +0200 (CEST) (envelope-from des) To: net@freebsd.org Subject: No buffer space available Organization: Yes Interactive Visit-Us-At: http://www.yes.no/ From: Dag-Erling Smorgrav Date: 30 Jul 1999 12:22:26 +0200 Message-ID: Lines: 26 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I get this on a totally idle machine, while trying to run nmap: root@destmp ~# nmap -O -sS destmp2.follo.net Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) sendto in send_tcp_raw: sendto(3, packet, 40, 0, 195.204.143.236, 16) => No buffer space available Sleeping 15 seconds then retrying sendto in send_tcp_raw: sendto(3, packet, 40, 0, 195.204.143.236, 16) => No buffer space available Sleeping 15 seconds then retrying ^Ccaught SIGINT signal, cleaning up root@destmp ~# ifconfig -au ed0: flags=8843 mtu 1500 inet 195.204.143.235 netmask 0xffffff00 broadcast 195.204.143.255 ether 00:20:18:39:08:81 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 root@destmp ~# grep ed0 /var/run/dmesg.boot ed0: irq 11 at device 18.0 on pci0 ed0: address 00:20:18:39:08:81, type NE2000 (16 bit) root@destmp ~# ipfw -a l 00100 6782 298826 allow ip from any to any 65535 12 752 deny ip from any to any DES -- Dag-Erling Smorgrav - des@yes.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 30 5:22:13 1999 Delivered-To: freebsd-net@freebsd.org Received: from nexus.plymovent.se (nexus.plymovent.se [212.247.77.253]) by hub.freebsd.org (Postfix) with ESMTP id 6CBCF15111; Fri, 30 Jul 1999 05:22:04 -0700 (PDT) (envelope-from thomas.uhrfelt@plymovent.se) Received: from tu (polaris [192.168.1.21]) by nexus.plymovent.se (8.9.3/8.9.3) with SMTP id OAA31938; Fri, 30 Jul 1999 14:30:32 +0200 (CEST) (envelope-from thomas.uhrfelt@plymovent.se) From: "Thomas Uhrfelt" To: Cc: Subject: Date: Fri, 30 Jul 1999 14:21:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I solved the problem with the BROKEN tag in the SKIP makefile, this was due to a serious error on my part .. I had cvsup:ed my ports tree with the . tag instead of RELENG_3_2_0, so I was as current I could be, and since the SKIP port is broken in current.. well go figure.. I have backed myself down to 3.2R ports now and when I try to compile this (works great on the 3.2 machine) on a 3.1-R machine (of course with ports from 3.1-R, one only makes this kinda mistake once huh?) I get the following: orion# make clean ===> Cleaning for skip-1.0 orion# make install ===> Extracting for skip-1.0 >> Checksum OK for skipsrc-1.0.tar.Z. ===> skip-1.0 depends on file: /usr/X11R6/lib/libxview.a - found ===> skip-1.0 depends on file: /usr/X11R6/lib/X11/config/XView.cf - found ===> skip-1.0 depends on executable: gmake - found ===> skip-1.0 depends on shared library: xview.3 - found ===> Patching for skip-1.0 ===> Applying FreeBSD patches for skip-1.0 ... Lot's of sucessful compiles here, now on the the troubleling part ... 6/des_ede_ecb.o ../bdcmod/safer/bin.x86/skip_safercbc.o ../bdcmod/safer/bin.x86/safer.o ../common/bin.x86/md5.o modstat: /dev/lkm: Device not configured gmake[2]: *** [bin.x86/skip.o] Error 2 gmake[2]: Leaving directory `/usr/ports/security/skip/work/skip/freebsd' gmake[1]: *** [freebsd] Error 2 gmake[1]: Leaving directory `/usr/ports/security/skip/work/skip' gmake: *** [skip] Error 2 *** Error code 2 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. orion# What is wrong, there is a /dev/lkm, so I have no idea what to do right now? Anyone? Regards, Thomas Uhrfelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 30 6:36:51 1999 Delivered-To: freebsd-net@freebsd.org Received: from alfik.ms.mff.cuni.cz (alfik.ms.mff.cuni.cz [195.113.19.71]) by hub.freebsd.org (Postfix) with ESMTP id D28FC150D4; Fri, 30 Jul 1999 06:36:46 -0700 (PDT) (envelope-from mencl@nenya.ms.mff.cuni.cz) Received: from nenya.ms.mff.cuni.cz by alfik.ms.mff.cuni.cz; (8.8.8/v1.00/19990210.0854) id PAA15339; Fri, 30 Jul 1999 15:35:08 +0200 (MET DST) Received: from localhost (mencl@localhost) by nenya.ms.mff.cuni.cz (8.9.1b+Sun/8.9.1) with ESMTP id PAA13874; Fri, 30 Jul 1999 15:35:08 +0200 (MET DST) Date: Fri, 30 Jul 1999 15:35:08 +0200 (MET DST) From: "Vladimir Mencl, MK, susSED" To: Thomas Uhrfelt Cc: freebsd-net@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 30 Jul 1999, Thomas Uhrfelt wrote: > modstat: /dev/lkm: Device not configured > What is wrong, there is a /dev/lkm, so I have no idea what to do right now? > Anyone? Well, the special file does exist, but device is not configured. That's because in 3.2, LKMs were dropped to change to .ko - kernel objets. That's the new format of kernel modules. You can load a .ko kernel module for loading old LKM kernel modules. kldload /modules/lkm.ko Now, the lkm interface should be up, and you should be able to succeed with SKIP. I hope there's no collisinion between the two schemes of kernel modules. Vladimir Mencl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 30 18:59:51 1999 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id BE4A614D40; Fri, 30 Jul 1999 18:59:47 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id SAA31040; Fri, 30 Jul 1999 18:59:07 -0700 (PDT) From: Archie Cobbs Message-Id: <199907310159.SAA31040@bubba.whistle.com> Subject: Re: skip port In-Reply-To: from Will Andrews at "Jul 30, 1999 03:13:24 pm" To: andrews@TECHNOLOGIST.COM (Will Andrews) Date: Fri, 30 Jul 1999 18:59:07 -0700 (PDT) Cc: thomas.uhrfelt@plymovent.se (Thomas Uhrfelt), freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG, archie@whistle.com (Archie Cobbs) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Will Andrews writes: > According to ports/9949, this program was remade as a KLD.. thus you wouldn't > be using /dev/lkm.. (as far as I know :) > > Would Archie Cobbs like to take over explaining this? :) Sure.. there are two separate things going on. When FreeBSD switched from LKM -> KLD, the skip port broke (in -current) and was subsequently fixed by me. That was 6 months ago or so. More recently (in the past couple of weeks) the skip port was broken again (again, in -current only) due to the changes to the dev_t stuff. So as it stands now, it is broken for -current. However, it will work for 3.2 *but* you of course must get the right version of the port. Or you can get the head version and uncomment the BROKEN= line. That's the information I have :-) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 31 2:38:40 1999 Delivered-To: freebsd-net@freebsd.org Received: from alice.gba.oz.au (gba-254.tmx.com.au [203.9.155.254]) by hub.freebsd.org (Postfix) with SMTP id 2A067151CE for ; Sat, 31 Jul 1999 02:38:30 -0700 (PDT) (envelope-from gjb-freebsd@gba.oz.au) Received: (qmail 17513 invoked by uid 1001); 31 Jul 1999 19:36:13 +1000 Message-ID: <19990731093613.17512.qmail@alice.gba.oz.au> X-Posted-By: GBA-Post 1.03 20-Sep-1998 X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 Date: Sat, 31 Jul 1999 19:36:12 +1000 From: Greg Black To: freebsd-net@FreeBSD.ORG Subject: Does the ep driver work under 3.2-release? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have just put together a box around an Asus P2B-F motherboard and installed 3.2-release from the WC CDROMs. Works fine, but I'm having no luck with a 3C509-combo ethernet card. The card has been working fine in a different box under a different OS, and is back in that box and still working now, so the problem is not the card or the cabling. The relevant part of my dmesg is: 1 3C5x9 board(s) on ISA found at 0x300 ep0 at 0x300-0x30f irq 10 on ISA ep0: aui/utp/bnc[*UTP*] address 00:60:08:ac:d7:1b After boot, "ifconfig ep0" gives: ep0: flags=8802 mtu 1500 ether 00:60:08:ac:d7:1b After "ifconfig ep0 inet 192.168.1.1", it becomes: ep0: flags=8843 mtu 1500 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:60:08:ac:d7:1b If I try to ping any of the other live machines on my 192.168.1 LAN, I see the expected flashes from the correct lights on the hubs, but there are no responses reported by ping. Same deal if I try to ping from the other boxes into this one. If anybody is using one of these and knows what I've done wrong, please let me know. Alternatively, if anybody knows that the driver is a dud, that would be helpful to know -- although not welcome news :-) If I've left out the really important bit of information, please yell at me so I can fix that. And thanks in advance for any brilliant ideas. -- Greg Black -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 31 7:43:51 1999 Delivered-To: freebsd-net@freebsd.org Received: from vortex.greycat.com (vortex.greycat.com [207.173.133.4]) by hub.freebsd.org (Postfix) with SMTP id D8F0114C4B for ; Sat, 31 Jul 1999 07:43:47 -0700 (PDT) (envelope-from dann@greycat.com) Received: (qmail 15310 invoked from network); 31 Jul 1999 14:43:46 -0000 Received: from bigphred.greycat.com (HELO greycat.com) (207.173.133.2) by vortex.greycat.com with SMTP; 31 Jul 1999 14:43:46 -0000 Message-ID: <37A30BED.30251E20@greycat.com> Date: Sat, 31 Jul 1999 07:45:01 -0700 From: Dann Lunsford Organization: You're kidding, right? X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Greg Black , net@freebsd.org Subject: Re: Does the ep driver work under 3.2-release? References: <19990731093613.17512.qmail@alice.gba.oz.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greg Black wrote: > [snip] The relevant part of my dmesg is: > > 1 3C5x9 board(s) on ISA found at 0x300 > ep0 at 0x300-0x30f irq 10 on ISA > ep0: aui/utp/bnc[*UTP*] address 00:60:08:ac:d7:1b > > After boot, "ifconfig ep0" gives: > > ep0: flags=8802 mtu 1500 > ether 00:60:08:ac:d7:1b > > After "ifconfig ep0 inet 192.168.1.1", it becomes: > > ep0: flags=8843 mtu 1500 > inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 > ether 00:60:08:ac:d7:1b > > If I try to ping any of the other live machines on my 192.168.1 > LAN, I see the expected flashes from the correct lights on the > hubs, but there are no responses reported by ping. Same deal if > I try to ping from the other boxes into this one. > Make sure that the routing tables in the other machines know about this one. I've seen this happen before, and it was almost always a bad route: The replying machines didn't know how to route the replies back to the sender. As for the 3c, I've got them in 4 machines here, not a single problem. Not the fastest card on the planet, but, in my experience, rock stable. No problems with the ep driver, either. HTH. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message