From owner-freebsd-net Sun Mar 19 7:25:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.surfamerica.net (mail.surfamerica.net [63.65.219.67]) by hub.freebsd.org (Postfix) with SMTP id AC5D337B7B0 for ; Sun, 19 Mar 2000 07:25:44 -0800 (PST) (envelope-from admin@surfamerica.net) Received: (qmail 28289 invoked from network); 19 Mar 2000 21:22:53 -0000 Received: from www.surfamerica.net (HELO surfamerica.net) (63.65.219.66) by mail.mail.surfamerica.net with SMTP; 19 Mar 2000 21:22:53 -0000 Message-ID: <38D4F11F.61E63146@surfamerica.net> Date: Sun, 19 Mar 2000 09:24:16 -0600 From: Paul Rice Organization: SurfAmerica Internet Services X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 19 8:33: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by hub.freebsd.org (Postfix) with SMTP id 214C737B67F for ; Sun, 19 Mar 2000 08:33:01 -0800 (PST) (envelope-from barney@databus.databus.com) From: Barney Wolff To: freebsd-net@freebsd.org Date: Sun, 19 Mar 2000 11:32 EST Subject: Re: RIP troubles Content-Length: 1381 Content-Type: text/plain Message-ID: <38d501390.6a9b@databus.databus.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, ripv1 doesn't know about netmasks, assumes addresses are class-ful. Barney Wolff > Date: Sun, 19 Mar 2000 02:19:43 -0500 (EST) > From: Mike Nowlin > To: freebsd-net@freebsd.org > Subject: RIP troubles > Content-Length: 1047 > > > OK... I've been playing with routed/gated and RIP off and on for a couple > of months in the hope that it will help ease my suffering when it comes to > maintaining eight zillion routing entries on various machines. I keep > coming up with the same problem: > > (tcpdump grab) > 20:44:37.760592 tarkin.smlab.com.router > 192.168.2.255.router: rip-resp > 5: 192.168.2.0(1) core1-akron.raex.net(1) 208.132.36.0(1) 10.0.0.0(2) > 0.0.0.0(1) [ttl 1] (id 8214) > > The problem is that 10.0.0.0/8 route that keeps getting sent around. I > have several 10.x.0.0/16 and 10.x.y.0/24 routes being used, but the /8 is > what's being advertised... This is why I usually give up and do all the > routing manually. :( (There are no /8's defined, other than what RIP > puts into the routing tables.) > > I admit that my gut feeling is that I'm missing something stupid, but is > it possible that this is a "feature" of RIP? > > (BTW: I've tried both RIPv1 and RIPv2) > > --mike > > > > > 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 Sun Mar 19 12:37: 2 2000 Delivered-To: freebsd-net@freebsd.org Received: from krell.webweaver.net (krell.webweaver.net [206.24.105.170]) by hub.freebsd.org (Postfix) with ESMTP id 86C0F37B6C6; Sun, 19 Mar 2000 12:36:55 -0800 (PST) (envelope-from nicole@unixgirl.com) Received: from xwin.nmhtech.com (xwin.nmhtech.com [208.138.46.10]) by krell.webweaver.net (Postfix) with ESMTP id E1A6020F04; Sun, 19 Mar 2000 11:47:18 -0800 (PST) Content-Length: 2499 Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 19 Mar 2000 12:36:54 -0800 (PST) From: "Nicole Harrington." To: freebsd-isp@freebsd.org, freebsd-net@freebsd.org Subject: NFS disconnecting - HELP Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greetings all I have two servers running FreeBSD 3.4-STABLE connected via NFS via independedent Intel pro 10/100 Nic cards (using a 10.0.0.1 type of network) and an intel switch. The directory structure is rather large but the traffic should not be that heavy. I was rather suprised to start seeing the disconnection notices below. I have had similar problem with NFS locking up on large/deep directories, however I was able to correct it by lowing the mount MTU to 1250 which didn't seem to make any difference on this system. Any advice on what to try would be greatly appreciatted! Please CC me in response. Thanks! Nicole Mar 17 15:52:11 www /kernel: nfs server pi.p.com:/home/web/WWW: not responding Mar 17 15:52:12 www /kernel: nfs server pi.p.com:/home/web/WWW: is alive again Mar 17 15:52:16 www /kernel: nfs server pi.p.com:/home/web/WWW: not responding Mar 17 15:52:16 www /kernel: nfs server pi.p.com:/home/web/WWW: is alive again Mar 17 15:52:54 www /kernel: nfs server pi.p.com:/home/web/WWW: not responding Mar 17 15:52:54 www /kernel: nfs server pi.p.com:/home/web/WWW: is alive again Mar 17 15:56:20 www /kernel: nfs server pi.p.com:/home/web/WWW: not responding Mar 17 15:56:20 www /kernel: nfs server pi.p.com:/home/web/WWW: is alive again Mar 17 16:03:48 www /kernel: nfs server pi.p.com:/home/web/WWW: not responding Mar 17 16:03:48 www /kernel: nfs server pi.p.com:/home/web/WWW: is alive again Mar 17 16:04:42 www /kernel: nfs server pi.p.com:/home/web/WWW: not responding Mar 17 16:04:43 www /kernel: nfs server pi.p.com:/home/web/WWW: is alive again Mar 17 16:07:59 www /kernel: nfs server pi.p.com:/home/web/WWW: not responding nicole@unixgirl.com |\ __ /| (`\ http://www.unixgirl.com/ webmistress@dangermouse.org | o_o |__ ) ) http://www.dangermouse.org/ // \\ ---------------------------(((---(((----------------------------------------- -- Powered by Coka-Cola and FreeBSD -- -- Stong enough for a man - But made for a Woman -- -- Microsoft: What bug would you like today? -- ------------------------------------------------------------------------------- -- As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. -- OWNED? MS: Who's Been In Your Computer Today? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 19 12:41:12 2000 Delivered-To: freebsd-net@freebsd.org Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id 9061637B5AD; Sun, 19 Mar 2000 12:41:03 -0800 (PST) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id OAA26182; Sun, 19 Mar 2000 14:40:55 -0600 (CST) (envelope-from toasty) From: Kevin Day Message-Id: <200003192040.OAA26182@celery.dragondata.com> Subject: Re: NFS disconnecting - HELP To: nicole@unixgirl.com (Nicole Harrington.) Date: Sun, 19 Mar 2000 14:40:55 -0600 (CST) Cc: freebsd-isp@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: from "Nicole Harrington." at Mar 19, 2000 12:36:54 PM X-Mailer: ELM [version 2.5 PL1] 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 > > > Greetings all > I have two servers running FreeBSD 3.4-STABLE connected via NFS via > independedent Intel pro 10/100 Nic cards (using a 10.0.0.1 type of network) and > an intel switch. The directory structure is rather large but the traffic should > not be that heavy. I was rather suprised to start seeing the disconnection > notices below. > I have had similar problem with NFS locking up on large/deep directories, > however I was able to correct it by lowing the mount MTU to 1250 which didn't > seem to make any difference on this system. > > Any advice on what to try would be greatly appreciatted! > Please CC me in response. > > > Thanks! > > Nicole > > Mar 17 15:52:11 www /kernel: nfs server pi.p.com:/home/web/WWW: not responding > Mar 17 15:52:12 www /kernel: nfs server pi.p.com:/home/web/WWW: is alive again > Mar 17 15:52:16 www /kernel: nfs server pi.p.com:/home/web/WWW: not responding > Mar 17 15:52:16 www /kernel: nfs server pi.p.com:/home/web/WWW: is alive again > Mar 17 15:52:54 www /kernel: nfs server pi.p.com:/home/web/WWW: not responding > Mar 17 15:52:54 www /kernel: nfs server pi.p.com:/home/web/WWW: is alive again > Mar 17 15:56:20 www /kernel: nfs server pi.p.com:/home/web/WWW: not responding > Mar 17 15:56:20 www /kernel: nfs server pi.p.com:/home/web/WWW: is alive again > Mar 17 16:03:48 www /kernel: nfs server pi.p.com:/home/web/WWW: not responding > Mar 17 16:03:48 www /kernel: nfs server pi.p.com:/home/web/WWW: is alive again > Mar 17 16:04:42 www /kernel: nfs server pi.p.com:/home/web/WWW: not responding > Mar 17 16:04:43 www /kernel: nfs server pi.p.com:/home/web/WWW: is alive again > Mar 17 16:07:59 www /kernel: nfs server pi.p.com:/home/web/WWW: not responding Mount the nfs filesystem (on the client side) with the '-d' option. I'm actually working on a fix for this, though. Example: nfs:/home /home nfs rw,-b,-d,noatime 1 1 Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 19 17: 4:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from mta02.onebox.com (mta02.onebox.com [216.33.158.209]) by hub.freebsd.org (Postfix) with ESMTP id A750A37B7AF; Sun, 19 Mar 2000 17:04:23 -0800 (PST) (envelope-from chutima_s@zdnetonebox.com) Received: from onebox.com ([216.33.158.154]) by mta02.onebox.com (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20000320010422.RWHK28925.mta02.onebox.com@onebox.com>; Sun, 19 Mar 2000 17:04:22 -0800 Received: from [203.107.232.70] by onebox.com with HTTP; Sun, 19 Mar 2000 17:04:22 -0800 Date: Sun, 19 Mar 2000 17:04:22 -0800 Subject: Multiple process run from rc.conf.local From: "Chutima S." To: freebsd-security@FreeBSD.ORG Cc: freebsd-net@FreeBSD.ORG Message-Id: <20000320010422.RWHK28925.mta02.onebox.com@onebox.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear all, I'm running FreeBSD-3.4-Stable, I created rc.conf.local for run additional process for starup time. But I found that all processes in file rc.conf.local was restarted every day and every week (look like daily and weekly routine check for system start them). What happen? Do I misuse of rc.conf.local? Should I move my startup script to /usr/local/etc/rc.d instead? Thanks, -- Chutima Subsirin chutima_s@zdnetonebox.com - email ___________________________________________________________________ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 19 19:29:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id 434B737B868; Sun, 19 Mar 2000 19:29:12 -0800 (PST) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id WAA79059; Sun, 19 Mar 2000 22:29:08 -0500 (EST) (envelope-from cjc) Date: Sun, 19 Mar 2000 22:29:08 -0500 From: "Crist J. Clark" To: "Chutima S." Subject: Re: Multiple process run from rc.conf.local Message-ID: <20000319222908.G78153@cc942873-a.ewndsr1.nj.home.com> Reply-To: cjclark@home.com References: <20000320010422.RWHK28925.mta02.onebox.com@onebox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000320010422.RWHK28925.mta02.onebox.com@onebox.com>; from chutima_s@zdnetonebox.com on Sun, Mar 19, 2000 at 05:04:22PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Mar 19, 2000 at 05:04:22PM -0800, Chutima S. wrote: > Dear all, > > I'm running FreeBSD-3.4-Stable, I created rc.conf.local for run additional > process for starup time. But I found that all processes in file rc.conf.local > was restarted every day and every week (look like daily and weekly routine > check for system start them). What happen? Do I misuse of rc.conf.local? Yes. rc.conf.local should only set values used by other scripts. The periodic(8) scripts load the values in defaults/rc.conf, rc.conf, and if you have one, rc.local.conf. > Should I move my startup script to /usr/local/etc/rc.d instead? Yes. It belongs there or in rc.local (although the latter is officially depricated). And this really should have gone to -questions rather than either -security and -net. -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 20 2:33: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id BE51A37B594 for ; Mon, 20 Mar 2000 02:33:01 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (tun.AwfulHak.org [194.242.139.173] (may be forged)) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id KAA33664; Mon, 20 Mar 2000 10:32:58 GMT (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id IAA00371; Mon, 20 Mar 2000 08:35:30 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200003200835.IAA00371@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Dermot McNally Cc: freebsd-net@FreeBSD.ORG Subject: Re: NAT issues with ppp - a fix In-Reply-To: Message from Brian Somers of "Sun, 05 Mar 2000 22:13:39 GMT." <200003052213.WAA07676@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Mar 2000 08:35:30 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > At 02:18 04.03.2000 +0000, Brian Somers wrote: > > > > >Hi, > > > > > > > > > >Because of a recent change in the way I connect to the net > > > > >(PPPoUDPoPPPoISDN), I'm now seeing this problem ! > > > > > > > > > >Can you try the attached patch ? I believe this fixes the problem ! > > > > > > > > Bad news on my side - it doesn't appear to have helped. My test case: > > > > Before applying the patch, I cvsupped to today's current and rebuilt the > > > > world. Then I set the gateway box and a FreeBSD alpha box on my internal > > > > network back to an MTU of 1500. I connected to confirm that the problem was > > > > still there (it was). > > > > > > > > Then I applied the patch, rebuilt and installed ppp. Same test. Same > > > > problem - well, same symptoms anyway. My two tests were, using Lynx to > > > > connect to effectively any WWW site and using fetch to download a biggish > > > > file. Fetch determines the file size (which I don't recall it managing to > > > > do before), but doesn't actually get any further with the download. Lynx > > > > manages to look up the site to which I try to connect, but then hangs at > > > > the "waiting for response" stage. > > > > > > > > I can packet sniff this if you think it will help - my setup is slightly > > > > different to yours: PPPoE via a DSL "modem". > > > > > > Mine is even more tricky... I've been battling this for some time > > > now. > > > > > > I've actually got > > > > > > laptop -ethernet-gate-PPPoUDPoPPPoISDN- - PPPoISDN gateway - 'net - - PPPoUDP gateway - 'net > > > > > > The tricky bit is that I have to run the PPPoUDP link in MP mode using > > > a 1466 byte MRRU. This will make the IP layer fragment the traffic to > > > 1466 bytes, allowing ppp to pile a UDP/IP header of 28 bytes back on > > > the front (and to add the 2/4 byte MP header and 1/2 byte protocol > > > header) before sending out the UDP datagram. I should correct myself here. I don't *have* to run MP. I thought I did because I was somehow under the misconception that UDP packets wouldn't fragment :-/ I don't know why.... > > > It's vital that the PPP/UDP/IP packet is no more than 1500 bytes as > > > it's going to pop up at my gateway and then must travel across the > > > 'net to the PPP/UDP gateway before it's unpacked and reassembled into > > > what was sent out originally. *sigh*, excuse the rantings. > > > I *think* this should work now - assuming the fragmentation side of > > > things is functional. I haven't proven things yet though. > > > > > > I'll follow up.... [.....] > > I guess I'm gonna have to try to set up a proper PPPoE environment > > here. I'll follow-up when I can. > > Hmm, I take that back. I'm still having problems. The problems can > be circumvented with an MRU/MTU of 1000 and an MRRU of 1500 - causing > ppp to set the iface to 1500 and chop the results up into 1000 byte > frames. > > This'll need more testing before I can even look at trying to > reproduce something consistently :-/ [.....] Still ranting (but with a reduced cc list).... It looks like this has nothing to do with fragmentation - not in my case anyway. I've added diagnostics to the fragmentation code in nat_cmd.c, and there is no unexpected lossage. Is anyone in a position to try this (or a similar) scenario *without* -nat (with real IP numbers - something I haven't got enough of) ? Do things behave strangely ? One other thing, I found this in my daily report this morning: > ipfw: -1 Refuse TCP 199.185.137.3 172.16.0.12 in via tun0 Fragment = 184 > ipfw: -1 Refuse TCP 199.185.137.3 172.16.0.12 in via tun0 Fragment = 184 > ipfw: -1 Refuse TCP 199.185.137.3 172.16.0.12 in via tun0 Fragment = 184 > ipfw: -1 Refuse TCP 199.185.137.3 172.16.0.12 in via tun0 Fragment = 184 > ipfw: -1 Refuse TCP 199.185.137.3 172.16.0.12 in via tun0 Fragment = 184 while ipfw list says: 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 65535 allow ip from any to any This is very strange (172.16.0.12 is the interior machine), but not even close in volume to being the cause of my dodgy connections.... Oh well, still looking. -- 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 Mon Mar 20 3:39:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from sasi.com (sasi.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id C247237B585 for ; Mon, 20 Mar 2000 03:39:52 -0800 (PST) (envelope-from gbnaidu@sasi.com) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id RAA11170 for ; Mon, 20 Mar 2000 17:11:15 +0530 (IST) Received: from hpd14.sasi.com ([10.0.16.14]) by samar.sasi.com; Mon, 20 Mar 2000 17:11:14 +0000 (IST) Received: from localhost (gbnaidu@localhost) by hpd14.sasi.com (8.9.1/8.9.1) with ESMTP id RAA02362 for ; Mon, 20 Mar 2000 17:20:02 +0530 (IST) Date: Mon, 20 Mar 2000 17:20:02 +0530 (IST) From: "G.B.Naidu" To: freebsd-net@FreeBSD.ORG Subject: Test mail......[please ignore] 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 20 4:14:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hub.freebsd.org (Postfix) with ESMTP id 3C64C37B70E for ; Mon, 20 Mar 2000 04:10:39 -0800 (PST) (envelope-from rik@cronyx.ru) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id PAA60896; (8.9.3/vak/2.1) Mon, 20 Mar 2000 15:14:22 +0300 (MSK) Message-ID: <38D61561.EADEDB6A@cronyx.ru> Date: Mon, 20 Mar 2000 15:11:13 +0300 From: Kurakin Roman Organization: Cronyx X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: freebsd-net@FreeBSD.ORG Subject: Re: Patch to introduce bpfdetach(), Re: BPF question (FreeBSD 40) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson wrote: > On Sat, 18 Mar 2000, Kurakin Roman wrote: > > > I have question about using bpf in my KLD module driver. At attach I > > call > > bpfattach function. What should I call at detach? > > Could some one describe to me how bpf is work (function calls, not bpf > > as pf :)). > > I noticed the same behavior a few weeks ago when using tcpdump in wi0 and > ejecting the card. This occurs if there are open bpf descriptors for the > device, and ifdetach is called (freeing the ifnet structure), at the > bp_bif pointer is not set to NULL. So, the problems would be if bpf was opened while we tried to detach driver? If so, I have another solution. Driver should return EBUSY, if bpf is open at the moment we try to detach driver. User should close all references to the device before its unloading. But I don't know what would be if I try to open bpf after I removed my driver from the kernel. At this moment I can only give some ideas. I never worked with bpf as user :( Thank you for your answer. Kurakin Roman > I've been running a bpf patch for the last few hours that attempts to > clean this behavior up. It introduces a bpfdetach(ifp), which should be > called just prior to ifdetach(ifp). If there are any open descriptors on > the interface, it sets the bif pointer to NULL, and wakes up listeners. > In the bpfread loop, if there are no remaining buffers on the bpf > descriptor, and it sees a bp_bif of NULL, it now returns ENXIO to the > caller. The remaining fd calls already appeared to have NULL checks for > bp_bif, just not bpfread in its wait loop. After this, it frees the > bpf_desc structure. > > It appears to clean up the wi0 tcpdump crash, but I haven't tested it much > more than that. Needless to say, any location where ifdetach() is called > (that had a matching bpfattach) should now also call bpfdetach(). I have > only updated if_wi.c in my patch, as that's all I have on hand right now. > > Pccard drivers such as ep0 don't require the patch, as they never > ifdetach(), leaving the ifnet epX around but unbound. > > One file attached patches src/sys/net to add the bpfdetach code > (bpfdetach.diff). The other patch patches if_wi.c to call bpfdetach > (if_wi.diff) Once it's adequately tested (volunteers welcome), I'll > commit it to 5.0-CURRENT. > > > Hi, > > > > Kurakin Roman > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > ------------------------------------------------------------------------ > Only in /data/fbsd-commit/src/sys/net: CVS > diff -u /data/fbsd-commit/src/sys/net/bpf.c ./bpf.c > --- /data/fbsd-commit/src/sys/net/bpf.c Sat Mar 18 01:30:41 2000 > +++ ./bpf.c Sat Mar 18 21:17:20 2000 > @@ -477,6 +477,18 @@ > ROTATE_BUFFERS(d); > break; > } > + > + /* > + * No data is available, check to see if the bpf device > + * is still pointed at a real interface. If not, return > + * ENXIO so that the userland process knows to rebind > + * it before using it again. > + */ > + if (d->bd_bif == NULL) { > + splx(s); > + return (ENXIO); > + } > + > if (ioflag & IO_NDELAY) > error = EWOULDBLOCK; > else > @@ -1285,6 +1297,60 @@ > > if (bootverbose) > printf("bpf: %s%d attached\n", ifp->if_name, ifp->if_unit); > +} > + > +/* > + * Detach bpf from an interface. This involves detaching each descriptor > + * associated with the interface, and leaving bd_bif NULL. Notify each > + * descriptor as it's detached so that any sleepers wake up and get > + * ENXIO. > + */ > +void > +bpfdetach(ifp) > + struct ifnet *ifp; > +{ > + struct bpf_if *bp, *bp_prev; > + struct bpf_d *d; > + int s; > + > + printf("bpfdetach: %s%d is being detached\n", ifp->if_name, > + ifp->if_unit); > + > + /* XXX is this needed? Is it right? */ > + s = splimp(); > + > + /* Locate BPF interface information */ > + bp_prev = NULL; > + for (bp = bpf_iflist; bp != NULL; bp = bp->bif_next) { > + if (ifp == bp->bif_ifp) > + break; > + bp_prev = bp; > + } > + > + /* Interface wasn't attached */ > + if (bp->bif_ifp == NULL) { > + splx(s); > + printf("bpfdetach: %s%d was not attached\n", ifp->if_name, > + ifp->if_unit); > + return; > + } > + > + while ((d = bp->bif_dlist) != NULL) { > + bpf_detachd(d); > + bpf_wakeup(d); > + } > + > + if (bp_prev) { > + bp_prev->bif_next = bp->bif_next; > + } else { > + bpf_iflist = bp->bif_next; > + } > + > + free(bp, M_BPF); > + > + splx(s); > + > + printf("bpfdetach: %s%d is detached\n", ifp->if_name, ifp->if_unit); > } > > static void bpf_drvinit __P((void *unused)); > diff -u /data/fbsd-commit/src/sys/net/bpf.h ./bpf.h > --- /data/fbsd-commit/src/sys/net/bpf.h Sat Mar 18 01:30:42 2000 > +++ ./bpf.h Sat Mar 18 21:16:33 2000 > @@ -232,6 +232,8 @@ > void bpf_tap __P((struct ifnet *, u_char *, u_int)); > void bpf_mtap __P((struct ifnet *, struct mbuf *)); > void bpfattach __P((struct ifnet *, u_int, u_int)); > +void bpfdetach __P((struct ifnet *)); > + > void bpfilterattach __P((int)); > u_int bpf_filter __P((const struct bpf_insn *, u_char *, u_int, u_int)); > #endif > > ------------------------------------------------------------------------ > --- if_wi.c Wed Feb 2 12:59:12 2000 > +++ /tmp/if_wi.c Sat Mar 18 21:19:39 2000 > @@ -214,6 +214,8 @@ > } > > wi_stop(sc); > + > + bpfdetach(ifp); > if_detach(ifp); > bus_teardown_intr(dev, sc->irq, sc->wi_intrhand); > wi_free(dev); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 20 5:55: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3F49937B6FA; Mon, 20 Mar 2000 05:54:58 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id IAA11645; Mon, 20 Mar 2000 08:54:33 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 20 Mar 2000 08:54:33 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Kurakin Roman Cc: freebsd-net@FreeBSD.ORG Subject: Re: Patch to introduce bpfdetach(), Re: BPF question (FreeBSD 40) In-Reply-To: <38D61561.EADEDB6A@cronyx.ru> 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 Mon, 20 Mar 2000, Kurakin Roman wrote: > Robert Watson wrote: > > > On Sat, 18 Mar 2000, Kurakin Roman wrote: > > > > > I have question about using bpf in my KLD module driver. At attach I > > > call > > > bpfattach function. What should I call at detach? > > > Could some one describe to me how bpf is work (function calls, not bpf > > > as pf :)). > > > > I noticed the same behavior a few weeks ago when using tcpdump in wi0 and > > ejecting the card. This occurs if there are open bpf descriptors for the > > device, and ifdetach is called (freeing the ifnet structure), at the > > bp_bif pointer is not set to NULL. > > So, the problems would be if bpf was opened while we tried to detach > driver? If so, I have another solution. Driver should return EBUSY, if > bpf is open at the moment we try to detach driver. User should close all > references to the device before its unloading. But I don't know what > would be if I try to open bpf after I removed my driver from the kernel. > At this moment I can only give some ideas. I never worked with bpf as > user :( BPF provides a file-like interface to packet streams. You open the first available /dev/bpfX, and then use some ioctl calls to indicate: - What interface to attach to (identified in an ifreq) - Buffer size - Promiscuous or not - What packets you're interested in So the problem isn't so much the bpf open, as much as whether there is currently a bpf device actively monitoring the interface on which ifdetach() is called. Once if_detach is called, the interface is no longer available for bpf to attach to, so if the ioctl is called to connect to the detached interface, ENXIO will be returned. I.e., the device has literally ceased to be configured (it doesn't turn up in ifconfig -a, ifconfig returns ENXIO, etc). The problem is those open BPF sessions, because the BPF descriptor for the session maintains a pointer to the ifnet structure describing the interface in the kernel. This structure is not refcounted, and one of the actions performed in if_detach() is to free that structure. The two obvious fixes are: 1) locate all references and remove them, and 2) add refcounting. I chose (1) as it appears to be more consistent. It doesn't make sense to be sniffing an interface that isn't there, especially if you don't know if it's coming back. It makes more sense to notify the userland application that it no longer exists, so the application can do something different, rather than being stuck blocked in a read() or select(). (2) would involve more work to implement, and doesn't necessarily add any benefit. In particular, if you did do this, you'd probably want to reconnect the sniffing application to the interface if it was recreated--however, most drivers re-malloc their interface structure in each pass, so you'd still need to rewrite pointers to interface structures. I suspect that bpfdetach(ifp) is the most consistent way to do this. When the interface is attached, it is registered with bpf. When it is detached, it is unregistered, and listeners are notified. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 20 9:36:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.surf1.de (mail.Surf1.de [194.25.165.21]) by hub.freebsd.org (Postfix) with ESMTP id CFE5437B88C for ; Mon, 20 Mar 2000 09:36:51 -0800 (PST) (envelope-from alex@cichlids.com) Received: from cichlids.com (postfix@pC19F5488.dip0.t-ipconnect.de [193.159.84.136]) by mail.surf1.de (8.9.3/8.9.3) with ESMTP id RAA28062 for ; Mon, 20 Mar 2000 17:37:13 +0100 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by cichlids.com (Postfix) with ESMTP id 7C4FAAC2F for ; Mon, 20 Mar 2000 18:37:58 +0100 (CET) Received: (from alex@localhost) by cichlids.cichlids.com (8.9.3/8.9.3) id SAA09456 for freebsd-net@freebsd.org; Mon, 20 Mar 2000 18:36:45 +0100 (CET) (envelope-from alex) Date: Mon, 20 Mar 2000 18:36:44 +0100 From: Alexander Langer To: freebsd-net@freebsd.org Subject: ipfw fwd to requester's ip Message-ID: <20000320183644.J2721@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello! What does one have to use to fwd an tcp/udp packet to a given port back to the requester's address? I'm getting a whole bunch of 1234, 27374 and other trojaner's attacks these days, and I want to fwd back these packets to the attackers :-) (I want to see her faces :P) So, is this possible? I didn't found it in the manpage. If not, I should take a look at it. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 20 14:22:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from elwood.akitanet.co.uk (elwood.akitanet.co.uk [212.1.130.149]) by hub.freebsd.org (Postfix) with ESMTP id 571BC37BCAC for ; Mon, 20 Mar 2000 14:22:03 -0800 (PST) (envelope-from wigstah@akitanet.co.uk) Received: from jake.akitanet.co.uk (jake.akitanet.co.uk [212.1.130.131]) by elwood.akitanet.co.uk (8.9.3/8.9.1) with ESMTP id WAA48055; Mon, 20 Mar 2000 22:30:55 GMT Date: Mon, 20 Mar 2000 23:12:25 +0000 (GMT) From: Paul Robinson To: Alexander Langer Cc: freebsd-net@FreeBSD.ORG Subject: Re: ipfw fwd to requester's ip In-Reply-To: <20000320183644.J2721@cichlids.cichlids.com> 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 Mon, 20 Mar 2000, Alexander Langer wrote: > Hello! Hi, > What does one have to use to fwd an tcp/udp packet to a given port > back to the requester's address? OK, I'll sort of answer this, but please read all the mail, because what I think you're proposing is bad for soooooo many reasons. Well, I read about 3 screens down the ipfw man page, and found a useful section on fwd ipaddr [,port], although how you would specify the sender's ip address and port in here dynamically is unknown to me at the moment, and I suspect it can't be done. If you can find a way of logging the packet (bad idea, see below), then you could have something watching the log output, then fires off a script. You can use IPFIREWALL_VERBOSE to help you do this, if you really want to, which you don't as I'm about to explain: :) > I'm getting a whole bunch of 1234, 27374 and other trojaner's attacks > these days, and I want to fwd back these packets to the attackers :-) > (I want to see her faces :P) OK, this is possibly the worst thing you can do in this situation. I have an IDS in place which throws up scans every now and again, and by far the best way to do this is to capture the packets with accurate timestamps using something like snort (http://www.clark.net/~roesch/security.html) which will happily capture full packets that match the patterns you describe. You then find out the administrators responsible for the IP address you are looking at (whois -h whois.ripe.net XXX.XXX.XXX.XXX in Europe, and IIRC it's whois.arin.net for US?), and send to abuse@domainname.com... You see there are several reasons for doing this. First of all administrators like me understand our users misbehave, and are of course happy to scrape them over the hot coals as a result. Yes it's extra workload, but in the same way I'll deal with my users, other admins will deal with their users when they continually prod my servers for Back Orifice. Also, it can actually signal a compromised server, i.e. it's one of the admins servers that has been hacked, and this sort of prompting will help them enormously. There is also the legal implications of what you're suggesting. In the UK at least, a probe to a port that is not advertised as being available to the public is illegal. In fact, it's the onus of the connector to a host to show they are authorised to do so in a given manner. I.e, anybody in the UK doing scanning can, theoretically, be prosecuted. If I start firing packets back at them, they can prosecute them. It's best I just let the packet get logged, and complain to their admins as netiquette suggests. Also, let's talk about the security implications in terms of Denial-of-Service attacks here. I compromise box A, and I don't like you who owns box B, so I start sending you 1,000 SYNs/sec to 31337 on box B from box A. Not only do I run a good chance of DoS'ing you, because you're processing and handling all this in the kernel in a special manner, but I also DoS box A. Nice. Logging of these packets alone is mildly risky, as theoretically filling up /var could be done by an attacker, but this is nowhere near as bad as DoS'ing not only your own box, but somebody elses, for which you will be blamed, you'll be the one that gets pulled off the network, etc.... In short, yes it can theoretically be done, but you haven't looked hard enough at the options available to you to do this, you haven't thought about the implications, and when you do, you'll realise this is actually quite a bad idea. Please, for your own sake, go and download and install snort. It has the disadvantage of having to put the NIC into promiscuous mode (which requires bpf devices to be enabled in the kernel and MAKEDEV'd), which *slightly* slows the stack down, but otherwise it helps you produce hard evidence to complain with in style about these morons. :) Although it would be nice to 'see their faces', you won't because they're miles away. What you will see is your box grind as it starts doing all this dynamic processing, and lots of e-mail telling you you're a very naughty man, and you're no better than the rest of the prats who do this. :) -- Paul Robinson - Developer/Systems Administrator @ Akitanet Internet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 21 4: 2:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.surf1.de (mail.Surf1.de [194.25.165.21]) by hub.freebsd.org (Postfix) with ESMTP id 7715737B889 for ; Tue, 21 Mar 2000 04:02:11 -0800 (PST) (envelope-from alex@cichlids.com) Received: from cichlids.com (pC19F546B.dip0.t-ipconnect.de [193.159.84.107]) by mail.surf1.de (8.9.3/8.9.3) with ESMTP id MAA08770; Tue, 21 Mar 2000 12:02:30 +0100 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by cichlids.com (Postfix) with ESMTP id 58665AC2C; Tue, 21 Mar 2000 13:03:21 +0100 (CET) Received: (from alex@localhost) by cichlids.cichlids.com (8.9.3/8.9.3) id NAA06604; Tue, 21 Mar 2000 13:02:03 +0100 (CET) (envelope-from alex) Date: Tue, 21 Mar 2000 13:02:03 +0100 From: Alexander Langer To: Paul Robinson Cc: freebsd-net@FreeBSD.ORG Subject: Re: ipfw fwd to requester's ip Message-ID: <20000321130203.C2166@cichlids.cichlids.com> References: <20000320183644.J2721@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from wigstah@akitanet.co.uk on Mon, Mar 20, 2000 at 11:12:25PM +0000 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thus spake Paul Robinson (wigstah@akitanet.co.uk): > Well, I read about 3 screens down the ipfw man page, and found a useful > section on fwd ipaddr [,port], although how you would specify the sender's Yes, I found that, too... > ip address and port in here dynamically is unknown to me at the ... the dynamic part is the problem. > address you are looking at (whois -h whois.ripe.net XXX.XXX.XXX.XXX in > Europe, and IIRC it's whois.arin.net for US?), and send to > abuse@domainname.com... Yes. You don't need an extra tool for that. I'm filtering all unknown ports at the moment and have written a script, that mails me unknown port-attacks. At the momehnt, that means, I'm getting around 40 requests from different people to my host, which really buggs me. I mailed abuse@ when this happend approx 2 times a day, at the moment it's just too much and I'm tired of doing this. (I think I'm the reason at least 50 users lost their accounts before *eg*) Ok. It seems, that at the momennt I'll just turn of logging for ports 1234 and the other one. > Denial-of-Service attacks here. I compromise box A, and I don't like you the DoS thing is a good reason not to do that. > Although it would be nice to 'see their faces', you won't because they're hehe. I know :) It was just a nice dream. I turned logging of now *sigh* Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 21 4:20:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from apollo.ocsny.com (apollo.ocsny.com [204.107.76.2]) by hub.freebsd.org (Postfix) with ESMTP id 546E837B677 for ; Tue, 21 Mar 2000 04:20:07 -0800 (PST) (envelope-from mikel@upan.org) Received: from upan.org (thoth.upan.org [204.107.76.16]) by apollo.ocsny.com (8.9.2/8.9.3) with ESMTP id HAA31134; Tue, 21 Mar 2000 07:18:00 -0500 (EST) Message-ID: <38D76AE9.3375FE3B@upan.org> Date: Tue, 21 Mar 2000 07:28:25 -0500 From: Mikel Organization: Optimized Computer Solutions, Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,it MIME-Version: 1.0 To: Paul Robinson Cc: Alexander Langer , freebsd-net@FreeBSD.ORG Subject: Re: ipfw fwd to requester's ip References: Content-Type: multipart/mixed; boundary="------------4E265260EC0A3E84013830CB" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------4E265260EC0A3E84013830CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit As a admin for a moderately sized isp, it is nice to be able to capure all of that information, et ceterra... And there are enough simple methods of doing so, but unfortunately of the past 10 occurances...I've only receive 1 satifactory notice of termination from the offenders isp...most are sadly colo facilities that do not seem to take these things seriousl enough. On a side note, you can run ipfw/divert/stealth in combonation with tcpwrappers to accomplish any of these tasks. Wether it be recording the time stamp et ceterra, or altering your ruleset to reroute the scanners scans back at them...personally as much of a nusaince as it it is I prefer to let them scan and I still contact the offenders isp and go all through the motions...I just don't hold my breath any more...;| Paul Robinson wrote: > On Mon, 20 Mar 2000, Alexander Langer wrote: > > > Hello! > > Hi, > > > What does one have to use to fwd an tcp/udp packet to a given port > > back to the requester's address? > > OK, I'll sort of answer this, but please read all the mail, because what I > think you're proposing is bad for soooooo many reasons. > > Well, I read about 3 screens down the ipfw man page, and found a useful > section on fwd ipaddr [,port], although how you would specify the sender's > ip address and port in here dynamically is unknown to me at the > moment, and I suspect it can't be done. If you can find a way of logging > the packet (bad idea, see below), then you could have something watching > the log output, then fires off a script. You can use IPFIREWALL_VERBOSE to > help you do this, if you really want to, which you don't as I'm about to > explain: :) > > > I'm getting a whole bunch of 1234, 27374 and other trojaner's attacks > > these days, and I want to fwd back these packets to the attackers :-) > > (I want to see her faces :P) > > OK, this is possibly the worst thing you can do in this situation. I have > an IDS in place which throws up scans every now and again, and by far the > best way to do this is to capture the packets with accurate timestamps > using something like snort (http://www.clark.net/~roesch/security.html) > which will happily capture full packets that match the patterns you > describe. You then find out the administrators responsible for the IP > address you are looking at (whois -h whois.ripe.net XXX.XXX.XXX.XXX in > Europe, and IIRC it's whois.arin.net for US?), and send to > abuse@domainname.com... > > You see there are several reasons for doing this. First of all > administrators like me understand our users misbehave, and are of course > happy to scrape them over the hot coals as a result. Yes it's extra > workload, but in the same way I'll deal with my users, other admins will > deal with their users when they continually prod my servers for Back > Orifice. Also, it can actually signal a compromised server, i.e. it's one > of the admins servers that has been hacked, and this sort of prompting > will help them enormously. > > There is also the legal implications of what you're suggesting. In the UK > at least, a probe to a port that is not advertised as being available to > the public is illegal. In fact, it's the onus of the connector to a host > to show they are authorised to do so in a given manner. I.e, anybody in > the UK doing scanning can, theoretically, be prosecuted. If I start firing > packets back at them, they can prosecute them. It's best I just let the > packet get logged, and complain to their admins as netiquette suggests. > > Also, let's talk about the security implications in terms of > Denial-of-Service attacks here. I compromise box A, and I don't like you > who owns box B, so I start sending you 1,000 SYNs/sec to 31337 on box B > from box A. Not only do I run a good chance of DoS'ing you, because you're > processing and handling all this in the kernel in a special manner, but I > also DoS box A. Nice. Logging of these packets alone is mildly risky, as > theoretically filling up /var could be done by an attacker, but this is > nowhere near as bad as DoS'ing not only your own box, but somebody elses, > for which you will be blamed, you'll be the one that gets pulled off the > network, etc.... > > In short, yes it can theoretically be done, but you haven't looked hard > enough at the options available to you to do this, you haven't thought > about the implications, and when you do, you'll realise this is actually > quite a bad idea. Please, for your own sake, go and download and install > snort. It has the disadvantage of having to put the NIC into promiscuous > mode (which requires bpf devices to be enabled in the kernel and > MAKEDEV'd), which *slightly* slows the stack down, but otherwise it helps > you produce hard evidence to complain with in style about these > morons. :) > > Although it would be nice to 'see their faces', you won't because they're > miles away. What you will see is your box grind as it starts doing all > this dynamic processing, and lots of e-mail telling you you're a very > naughty man, and you're no better than the rest of the prats who do > this. :) > > -- > Paul Robinson - Developer/Systems Administrator @ Akitanet Internet > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Cheers, Mikel +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Optimized Computer Solutions, Inc http://www.ocsny.com | 39 W14th Street, Suite 203 212 727 2238 x132 | New York, NY 10011 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Labor rates: Tech $125 hourly | Net Engineer $150 hourly | Phone Support $ 33 quarter hourly | Lost Password $ 45 per incedent +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | http://www.ocsny.com/~mikel +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ --------------4E265260EC0A3E84013830CB Content-Type: text/x-vcard; charset=us-ascii; name="mikel.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Mikel Content-Disposition: attachment; filename="mikel.vcf" begin:vcard n:King;Mikel x-mozilla-html:TRUE org:Optimized Computer Solutions version:2.1 email;internet:mikel@ocsny.com title:Procurement Manager tel;fax:2124638402 tel;home:http://www.upan.org/vizkr tel;work:2127272100 adr;quoted-printable:;;39 W14th St.=0D=0ASte 203;New York;NY;10011;US x-mozilla-cpt:;0 fn:Mikel King end:vcard --------------4E265260EC0A3E84013830CB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 21 6:35:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by hub.freebsd.org (Postfix) with ESMTP id 7861037B933 for ; Tue, 21 Mar 2000 06:35:22 -0800 (PST) (envelope-from thierry.herbelot@telspace.alcatel.fr) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id PAA18899 for ; Tue, 21 Mar 2000 15:27:14 +0100 Received: from lune.telspace.alcatel.fr (lune.telspace.alcatel.fr [155.132.144.65]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id PAA23483 for ; Tue, 21 Mar 2000 15:31:37 +0100 (MET) Received: from telss1 (telss1.telspace.alcatel.fr [155.132.51.4]) by lune.telspace.alcatel.fr (8.9.3/8.9.3) with ESMTP id PAA20247 for ; Tue, 21 Mar 2000 15:30:51 +0100 (MET) Received: from telspace.alcatel.fr by telss1 (8.8.8+Sun/SMI-SVR4) id PAA24389; Tue, 21 Mar 2000 15:27:45 +0100 (MET) Message-ID: <38D786E0.15EC21BC@telspace.alcatel.fr> Date: Tue, 21 Mar 2000 15:27:44 +0100 From: Thierry Herbelot Reply-To: thierry.herbelot@alcatel.fr Organization: Alcatel CIT Nanterre X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: net@freebsd.org Subject: [long] test report for 4.0 and dc(4) Content-Type: multipart/mixed; boundary="------------C55FE8DAD3504E95972DBCFA" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------C55FE8DAD3504E95972DBCFA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I have a "SmartBits" test equipment on lease and I've played a little with it and a Compaq PC with a 4-port 100Mbit NIC (DLINK DFE-570) The result is quite interesting : I've been able to route 4 full duplex 50 Mbps flows with large frames (1500 bytes) with a negligible trafic loss (see enclosed test_600x4.csv - comma-separated values) The first test bombed (this was with the GENERIC kernel), but everything went fine with an "adapted" kernel config. the second test was a bit more difficult : the SmartBits was only sending one flow of small Ethernet frames (64 bytes) at up to 36 Mbps for the Compaq to route them from one port to another (the IP addresses were fixed and the same for all frames) In this test, there is an interesting pattern : - for less than 28 Mbps, the packet loss is acceptable (12 out of 386892 for example), - for 28,30 and 32 Mbps, the packet loss is very high (up to 80 % loss, for example) - for 34 and 36, the loss is back to normal (16 packets lost over 25 secs) (full results in test_25Mx64x1.csv, enclosed) when routing high numbers of small frames, the interrupt processing time ends up taking all available ressource (according to systat -vmstat 1) All of the tests have been run without any "ipfw" processing. In fact, my test was to know wether a "normal" PC could do some traffic shaping on a full 100 Mbps link. It seems the answer is "maybe", but not with a standard PC (let's go to PCI 64bits - 66MHz and a fast FSB ?) TfH here is the dmesg : Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-20000314-CURRENT #0: Mon Mar 20 18:22:33 CET 2000 herbelot@pc-bsd28.val9900.telspace.alcatel.fr:/usr/src/sys/compile/P6-dc Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 448054389 Hz CPU: Pentium III/Pentium III Xeon (448.05-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x383f9ff real memory = 67108864 (65536K bytes) config> q avail memory = 62193664 (60736K bytes) Preloaded elf kernel "kernel" at 0xc02bd000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc02bd09c. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 11 xl0: <3Com 3c900B-TPO Etherlink XL> port 0x2000-0x207f mem 0x42000000-0x4200007f irq 11 at device 14.0 on pci0 xl0: Ethernet address: 00:50:04:3f:09:0b xl0: selecting 10baseT transceiver, half duplex pcib2: at device 15.0 on pci0 pci2: on pcib2 dc0: port 0x1000-0x107f mem 0x40000000-0x400003ff irq 11 at device 4.0 on pci2 dc0: Ethernet address: 00:80:c8:c9:88:bc miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ... other dc ports isab0: at device 20.0 on pci0 isa0: on isab0 atapci0: port 0x20a0-0x20af at device 20.1 on pci 0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 20.2 irq 11 chip1: port 0xfc00-0xfc0f at device 20.3 on pci0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppi0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port plip0: on ppbus0 ata1-slave: ata_command: timeout waiting for intr ata1-slave: identify failed ad0: 6149MB [13328/15/63] at ata0-master using UDMA33 acd0: CDROM at ata1-master using PIO4 Mounting root from ufs:/dev/ad0s2a dc1: TX underrun -- increasing TX threshold dc0: TX underrun -- increasing TX threshold dc2: TX underrun -- increasing TX threshold dc3: TX underrun -- increasing TX threshold dc2: TX underrun -- increasing TX threshold dc3: TX underrun -- increasing TX threshold dc0: TX underrun -- increasing TX threshold dc1: TX underrun -- increasing TX threshold -- Thierry Herbelot (+33) 1 46 52 47 23 --------------C55FE8DAD3504E95972DBCFA Content-Type: application/octet-stream; name="test_600x4.csv" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="test_600x4.csv" TmFtZSxMb2FkICglKSxTZW50LFJlY2VpdmVkLExvc3QsT3V0IE9mIFNlcXVlbmNlLE1pbiBM YXRlbmN5ICh1U2VjcyksQXZnIExhdGVuY3kgKHVTZWNzKSxNYXggTGF0ZW5jeSAodVNlY3Mp LFN0YW5kYXJkIERldmlhdGlvbiAodVNlY3MpLCwsLCwsLCwsLCwsLCwsLA0KVG90YWwsMTAu MDAwMCw4MDY0NCw4MDYzNiw4LDQsNzkuNSwxNDYuMCwyNjIuOSw1Ny40LCwsLCwsLCwsLCws LCwsLA0KMTAwLTEwMSwxMC4wMDAwLDIwMTYxLDIwMTU5LDIsMSw4MC44LDE0OC4zLDIzNy42 LDc1LjUsLCwsLCwsLCwsLCwsLCwsDQoxMDEtMTAwLDEwLjAwMDAsMjAxNjEsMjAxNTksMiwx LDg5LjQsMTM1LjQsMjEzLjEsNjQuMywsLCwsLCwsLCwsLCwsLCwNCjEwMi0xMDMsMTAuMDAw MCwyMDE2MSwyMDE1OSwyLDEsODAuMSwxNDUuNiwyMDkuNyw1MC41LCwsLCwsLCwsLCwsLCws LA0KMTAzLTEwMiwxMC4wMDAwLDIwMTYxLDIwMTU5LDIsMSw3OS41LDE1NC43LDI2Mi45LDIx LjUsLCwsLCwsLCwsLCwsLCwsDQpUb3RhbCwyMC4wMDAwLDE2MTI4OCwxNjEyODAsOCw0LDc5 LjgsMTUwLjIsMjQ3LjksNTIuMywsLCwsLCwsLCwsLCwsLCwNCjEwMC0xMDEsMjAuMDAwMCw0 MDMyMiw0MDMyMCwyLDEsODAuNSwxNjcuNywyNDcuOSw0Ni42LCwsLCwsLCwsLCwsLCwsLA0K MTAxLTEwMCwyMC4wMDAwLDQwMzIyLDQwMzIwLDIsMSw4NC40LDEzNS4wLDI0NS44LDY4LjEs LCwsLCwsLCwsLCwsLCwsDQoxMDItMTAzLDIwLjAwMDAsNDAzMjIsNDAzMjAsMiwxLDc5Ljgs MTQzLjIsMjM2LjUsNTkuNCwsLCwsLCwsLCwsLCwsLCwNCjEwMy0xMDIsMjAuMDAwMCw0MDMy Miw0MDMyMCwyLDEsODEuMSwxNTQuOCwyMzguMSwyMC4wLCwsLCwsLCwsLCwsLCwsLA0KVG90 YWwsMzAuMDAwMCwyNDE5MzIsMjQxOTI0LDgsNCw3OC4wLDE1NS4wLDMwMS40LDU1LjMsLCws LCwsLCwsLCwsLCwsDQoxMDAtMTAxLDMwLjAwMDAsNjA0ODMsNjA0ODEsMiwxLDc5LjUsMTY5 LjcsMjU3LjcsNTIuMCwsLCwsLCwsLCwsLCwsLCwNCjEwMS0xMDAsMzAuMDAwMCw2MDQ4Myw2 MDQ4MSwyLDEsODUuMSwxNDQuOCwzMDEuNCw0MC42LCwsLCwsLCwsLCwsLCwsLA0KMTAyLTEw MywzMC4wMDAwLDYwNDgzLDYwNDgxLDIsMSw4Mi44LDE1NS42LDI3NS42LDcxLjcsLCwsLCws LCwsLCwsLCwsDQoxMDMtMTAyLDMwLjAwMDAsNjA0ODMsNjA0ODEsMiwxLDc4LjAsMTQ5Ljks MjM3LjgsNTEuMiwsLCwsLCwsLCwsLCwsLCwNClRvdGFsLDQwLjAwMDAsMzIyNTgwLDI2Mjg1 OCw1OTcyMiwzNjc4NCw4MC4xLDMyNTUuNiwxMDA5MTA4LjgsNDYyNC4xLCwsLCwsLCwsLCws LCwsLA0KMTAwLTEwMSw0MC4wMDAwLDgwNjQ1LDYwMzU4LDIwMjg3LDEwMTM0LDg5LjIsNTU4 OC4zLDEwMDY4MTUuNyw2NjI4LjQsLCwsLCwsLCwsLCwsLCwsDQoxMDEtMTAwLDQwLjAwMDAs ODA2NDUsNzQxOTEsNjQ1NCw1MzQ3LDgwLjEsMTI5Ni41LDE0ODM1LjAsMTUxMy45LCwsLCws LCwsLCwsLCwsLA0KMTAyLTEwMyw0MC4wMDAwLDgwNjQ1LDcxMzE5LDkzMjYsODYyMCw4Ni4y LDEyODguNiwxMzU2NS44LDE1MjUuMCwsLCwsLCwsLCwsLCwsLCwNCjEwMy0xMDIsNDAuMDAw MCw4MDY0NSw1Njk5MCwyMzY1NSwxMjY4Myw4OC4xLDU3OTcuMiwxMDA5MTA4LjgsNjc2OC4x LCwsLCwsLCwsLCwsLCwsLA0KVG90YWwsNTAuMDAwMCw0MDMyMjQsMTk2MDM4LDIwNzE4Niwx MDg0NTYsMTA3LjUsMjY2OS4wLDQxNzEuNiwxOTYuNCwsLCwsLCwsLCwsLCwsLCwNCjEwMC0x MDEsNTAuMDAwMCwxMDA4MDYsNTQ3MTgsNDYwODgsMjgwNDMsMTA3LjUsMjcwNy42LDQxMzMu OSwxODUuNywsLCwsLCwsLCwsLCwsLCwNCjEwMS0xMDAsNTAuMDAwMCwxMDA4MDYsNTU4Nzcs NDQ5MjksMjYyNDcsMTEyLjAsMjY3NS44LDQxNzEuNiwxODQuNCwsLCwsLCwsLCwsLCwsLCwN CjEwMi0xMDMsNTAuMDAwMCwxMDA4MDYsNTA1NDIsNTAyNjQsMzAzODAsMTMxLjYsMjY4NS40 LDQwODUuNiwxOTMuMywsLCwsLCwsLCwsLCwsLCwNCjEwMy0xMDIsNTAuMDAwMCwxMDA4MDYs MzQ5MDEsNjU5MDUsMjM3ODYsMTI3LjAsMjU3NC4wLDQwODEuMCwyMzIuNCwsLCwsLCwsLCws LCwsLCwNClRvdGFsLDYwLjAwMDAsNDgzODY4LDQ4Mzg1MiwxNiw4LDEyNC4yLDI1OC44LDQx Ni42LDAuMCwsLCwsLCwsLCwsLCwsLCwNCjEwMC0xMDEsNjAuMDAwMCwxMjA5NjcsMTIwOTYz LDQsMiwxMjQuMiwyNjIuOCw0MTYuNiwwLjAsLCwsLCwsLCwsLCwsLCwsDQoxMDEtMTAwLDYw LjAwMDAsMTIwOTY3LDEyMDk2Myw0LDIsMTY1LjAsMjUyLjMsNDA1LjgsMC4wLCwsLCwsLCws LCwsLCwsLA0KMTAyLTEwMyw2MC4wMDAwLDEyMDk2NywxMjA5NjMsNCwyLDE2MC41LDI2My45 LDQwNC41LDAuMCwsLCwsLCwsLCwsLCwsLCwNCjEwMy0xMDIsNjAuMDAwMCwxMjA5NjcsMTIw OTYzLDQsMiwxNjAuNCwyNTYuMiw0MDUuMywwLjAsLCwsLCwsLCwsLCwsLCwsDQpUb3RhbCw3 MC4wMDAwLDU2NDUxNiwyODQ1OTUsMjc5OTIxLDExLDE1Ni43LDE3NjQzLjYsOTkwMzExMy40 LDQ3NTguOCwsLCwsLCwsLCwsLCwsLCwNCjEwMC0xMDEsNzAuMDAwMCwxNDExMjksMTUxMiwx Mzk2MTcsMywxOTUuMCwxNTc0OTQxLjUsOTkwMzExMy40LDM0MDc3LjAsLCwsLCwsLCwsLCws LCwsDQoxMDEtMTAwLDcwLjAwMDAsMTQxMTI5LDE1MTgsMTM5NjExLDIsMjM1LjYsMTY1OTky OC41LDk5MDE0OTQuOSwzNDY2Ni43LCwsLCwsLCwsLCwsLCwsLA0KMTAyLTEwMyw3MC4wMDAw LDE0MTEyOSwxNDA3ODgsMzQxLDMsMTY3LjcsNDQ0LjEsMzQ3MzUuMSwxOTQ1LjcsLCwsLCws LCwsLCwsLCwsDQoxMDMtMTAyLDcwLjAwMDAsMTQxMTI5LDE0MDc3NywzNTIsMywxNTYuNyw0 MDkuNywzMzMwNy40LDE4NzAuOSwsLCwsLCwsLCwsLCwsLCwNClRvdGFsLDgwLjAwMDAsNjQ1 MTYwLDEzMjIwNSw1MTI5NTUsMzc4MiwxODkuMCw2OTE2NS4wLDk5Njg4MzYuMyw2MTgyLjcs LCwsLCwsLCwsLCwsLCwsDQoxMDAtMTAxLDgwLjAwMDAsMTYxMjkwLDEyOTc5MiwzMTQ5OCwz Nzc1LDMyMy43LDEyNjQ5LjMsNTIxNjQuMywyMjQ4LjUsLCwsLCwsLCwsLCwsLCwsDQoxMDEt MTAwLDgwLjAwMDAsMTYxMjkwLDgxNCwxNjA0NzYsMiwxODkuMCwzMTEzMDczLjAsOTk2ODgz Ni4zLDQxNjgxLjUsLCwsLCwsLCwsLCwsLCwsDQoxMDItMTAzLDgwLjAwMDAsMTYxMjkwLDgw OCwxNjA0ODIsMywyMDcuMiwzMDEyMTU5LjIsOTk2NjQ5NS4xLDQxMjQ3LjcsLCwsLCwsLCws LCwsLCwsDQoxMDMtMTAyLDgwLjAwMDAsMTYxMjkwLDc5MSwxNjA0OTksMiwyMzMuMCwzMjAz OTMyLjAsOTk2NjUxOC4zLDQxNjE3LjAsLCwsLCwsLCwsLCwsLCwsDQpUb3RhbCw5MC4wMDAw LDcyNTgwNCwxNzY5LDcyNDAzNSwwLDE3Ni45LDk5NjYuOCwyMTg4Ny40LDEyNTQ1LjUsLCws LCwsLCwsLCwsLCwsDQoxMDAtMTAxLDkwLjAwMDAsMTgxNDUxLDQzNiwxODEwMTUsMCwxNzYu OSwxMDAzNS4xLDIxNjY5LjEsMTI2MDUuNCwsLCwsLCwsLCwsLCwsLCwNCjEwMS0xMDAsOTAu MDAwMCwxODE0NTEsNDM5LDE4MTAxMiwwLDIzNS4zLDk5MTcuMCwyMTczNy4yLDEyNTA3LjIs LCwsLCwsLCwsLCwsLCwsDQoxMDItMTAzLDkwLjAwMDAsMTgxNDUxLDQ0MywxODEwMDgsMCwy NzEuOSwxMDEzMy4xLDIxODg3LjQsMTI1NDUuMSwsLCwsLCwsLCwsLCwsLCwNCjEwMy0xMDIs OTAuMDAwMCwxODE0NTEsNDUxLDE4MTAwMCwwLDM1MC41LDk3ODYuMCwyMTM4NC42LDEyNTA4 LjgsLCwsLCwsLCwsLCwsLCwsDQpUb3RhbCwxMDAuMDAwMCw4MDY0NDgsMCw4MDY0NDgsMCww LjAsMC4wLDAuMCwwLjAsLCwsLCwsLCwsLCwsLCwsDQoxMDAtMTAxLDEwMC4wMDAwLDIwMTYx MiwwLDIwMTYxMiwwLDAuMCwwLjAsMC4wLDAuMCwsLCwsLCwsLCwsLCwsLCwNCjEwMS0xMDAs MTAwLjAwMDAsMjAxNjEyLDAsMjAxNjEyLDAsMC4wLDAuMCwwLjAsMC4wLCwsLCwsLCwsLCws LCwsLA0KMTAyLTEwMywxMDAuMDAwMCwyMDE2MTIsMCwyMDE2MTIsMCwwLjAsMC4wLDAuMCww LjAsLCwsLCwsLCwsLCwsLCwsDQoxMDMtMTAyLDEwMC4wMDAwLDIwMTYxMiwwLDIwMTYxMiww LDAuMCwwLjAsMC4wLDAuMCwsLCwsLCwsLCwsLCwsLCwNCg== --------------C55FE8DAD3504E95972DBCFA Content-Type: application/octet-stream; name="test_25Mx64x1.csv" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="test_25Mx64x1.csv" TmFtZSxMb2FkICglKSxTZW50LFJlY2VpdmVkLExvc3QsT3V0IE9mIFNlcXVlbmNlLE1pbiBM YXRlbmN5ICh1U2VjcyksQXZnIExhdGVuY3kgKHVTZWNzKSxNYXggTGF0ZW5jeSAodVNlY3Mp LFN0YW5kYXJkIERldmlhdGlvbiAodVNlY3MpLCwsLCwsLCwsLCwsLCwsLA0KVG90YWwsMTAu MDAwMCwxNDg4MDksMTQ4ODAzLDYsMywyOS4xLDY1LjQsMTIxLjUsNjIuMSwsLCwsLCwsLCws LCwsLCwNCjEwMC0xMDEsMTAuMDAwMCwxNDg4MDksMTQ4ODAzLDYsMywyOS4xLDY1LjQsMTIx LjUsNjIuMSwsLCwsLCwsLCwsLCwsLCwNClRvdGFsLDEyLjAwMDAsMTc4NTcxLDE3ODU2NSw2 LDMsMjguOCw2Ni4zLDExOC40LDU2LjcsLCwsLCwsLCwsLCwsLCwsDQoxMDAtMTAxLDEyLjAw MDAsMTc4NTcxLDE3ODU2NSw2LDMsMjguOCw2Ni4zLDExOC40LDU2LjcsLCwsLCwsLCwsLCws LCwsDQpUb3RhbCwxNC4wMDAwLDIwODMzMywyMDgzMjcsNiwzLDI4LjcsNjYuOCwxMjYuNiw1 NS41LCwsLCwsLCwsLCwsLCwsLA0KMTAwLTEwMSwxNC4wMDAwLDIwODMzMywyMDgzMjcsNiwz LDI4LjcsNjYuOCwxMjYuNiw1NS41LCwsLCwsLCwsLCwsLCwsLA0KVG90YWwsMTYuMDAwMCwy MzgwOTUsMjM4MDg3LDgsNCwyOC43LDY1LjYsMjU3LjQsNTAuOSwsLCwsLCwsLCwsLCwsLCwN CjEwMC0xMDEsMTYuMDAwMCwyMzgwOTUsMjM4MDg3LDgsNCwyOC43LDY1LjYsMjU3LjQsNTAu OSwsLCwsLCwsLCwsLCwsLCwNClRvdGFsLDE4LjAwMDAsMjY3ODU3LDI2Nzg0OSw4LDQsMjku OSw2My4yLDI3NC4xLDE2LjgsLCwsLCwsLCwsLCwsLCwsDQoxMDAtMTAxLDE4LjAwMDAsMjY3 ODU3LDI2Nzg0OSw4LDQsMjkuOSw2My4yLDI3NC4xLDE2LjgsLCwsLCwsLCwsLCwsLCwsDQpU b3RhbCwyMC4wMDAwLDI5NzYxOSwyOTc2MDksMTAsNSwyOS4zLDY0LjEsMjU3LjMsMTUuNSws LCwsLCwsLCwsLCwsLCwNCjEwMC0xMDEsMjAuMDAwMCwyOTc2MTksMjk3NjA5LDEwLDUsMjku Myw2NC4xLDI1Ny4zLDE1LjUsLCwsLCwsLCwsLCwsLCwsDQpUb3RhbCwyMi4wMDAwLDMyNzM4 MCwzMjczNzAsMTAsNSwzMC40LDY1LjAsMjA0LjUsMTQuNiwsLCwsLCwsLCwsLCwsLCwNCjEw MC0xMDEsMjIuMDAwMCwzMjczODAsMzI3MzcwLDEwLDUsMzAuNCw2NS4wLDIwNC41LDE0LjYs LCwsLCwsLCwsLCwsLCwsDQpUb3RhbCwyNC4wMDAwLDM1NzE0MiwzNTcxMzAsMTIsNiwzMC4x LDYzLjIsMTk4LjAsMjQuMSwsLCwsLCwsLCwsLCwsLCwNCjEwMC0xMDEsMjQuMDAwMCwzNTcx NDIsMzU3MTMwLDEyLDYsMzAuMSw2My4yLDE5OC4wLDI0LjEsLCwsLCwsLCwsLCwsLCwsDQpU b3RhbCwyNi4wMDAwLDM4NjkwNCwzODY4OTIsMTIsNiwzMC43LDY5LjYsMjY2LjEsNTAuNyws LCwsLCwsLCwsLCwsLCwNCjEwMC0xMDEsMjYuMDAwMCwzODY5MDQsMzg2ODkyLDEyLDYsMzAu Nyw2OS42LDI2Ni4xLDUwLjcsLCwsLCwsLCwsLCwsLCwsDQpUb3RhbCwyOC4wMDAwLDQxNjY2 NiwyNzk5MjQsMTM2NzQyLDg3NTU5LDM0LjUsMTg0NS45LDIyNDQuMSwxMDguOSwsLCwsLCws LCwsLCwsLCwNCjEwMC0xMDEsMjguMDAwMCw0MTY2NjYsMjc5OTI0LDEzNjc0Miw4NzU1OSwz NC41LDE4NDUuOSwyMjQ0LjEsMTA4LjksLCwsLCwsLCwsLCwsLCwsDQpUb3RhbCwzMC4wMDAw LDQ0NjQyOCwxNjk2NzcsMjc2NzUxLDg5NTE1LDMyLjMsMzAxMi44LDM3NzkuMiwzNzguNCws LCwsLCwsLCwsLCwsLCwNCjEwMC0xMDEsMzAuMDAwMCw0NDY0MjgsMTY5Njc3LDI3Njc1MSw4 OTUxNSwzMi4zLDMwMTIuOCwzNzc5LjIsMzc4LjQsLCwsLCwsLCwsLCwsLCwsDQpUb3RhbCwz Mi4wMDAwLDQ3NjE5MCw2Nzc2OSw0MDg0MjEsNjAwMjIsMzEuNiw3NDU3LjYsOTQ2Ny4yLDE0 NzguNiwsLCwsLCwsLCwsLCwsLCwNCjEwMC0xMDEsMzIuMDAwMCw0NzYxOTAsNjc3NjksNDA4 NDIxLDYwMDIyLDMxLjYsNzQ1Ny42LDk0NjcuMiwxNDc4LjYsLCwsLCwsLCwsLCwsLCwsDQpU b3RhbCwzNC4wMDAwLDUwNTk1Miw1MDU5MzYsMTYsOCwzMi4wLDY4LjcsMTM4LjYsNTAuNSws LCwsLCwsLCwsLCwsLCwNCjEwMC0xMDEsMzQuMDAwMCw1MDU5NTIsNTA1OTM2LDE2LDgsMzIu MCw2OC43LDEzOC42LDUwLjUsLCwsLCwsLCwsLCwsLCwsDQpUb3RhbCwzNi4wMDAwLDUzNTcx NCw1MzU2OTgsMTYsOCwzMS44LDY3LjUsMTM5LjcsNDIuOSwsLCwsLCwsLCwsLCwsLCwNCjEw MC0xMDEsMzYuMDAwMCw1MzU3MTQsNTM1Njk4LDE2LDgsMzEuOCw2Ny41LDEzOS43LDQyLjks LCwsLCwsLCwsLCwsLCwsDQo= --------------C55FE8DAD3504E95972DBCFA-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 21 6:48: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from elwood.akitanet.co.uk (elwood.akitanet.co.uk [212.1.130.149]) by hub.freebsd.org (Postfix) with ESMTP id 3FAB137B705 for ; Tue, 21 Mar 2000 06:48:05 -0800 (PST) (envelope-from wigstah@akitanet.co.uk) Received: from jake.akitanet.co.uk (jake.akitanet.co.uk [212.1.130.131]) by elwood.akitanet.co.uk (8.9.3/8.9.1) with ESMTP id OAA66008; Tue, 21 Mar 2000 14:57:17 GMT Date: Tue, 21 Mar 2000 15:38:42 +0000 (GMT) From: Paul Robinson To: Mikel Cc: Alexander Langer , freebsd-net@FreeBSD.ORG Subject: Re: ipfw fwd to requester's ip In-Reply-To: <38D76AE9.3375FE3B@upan.org> 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 Tue, 21 Mar 2000, Mikel wrote: > On a side note, you can run ipfw/divert/stealth in combonation with > tcpwrappers to accomplish any of these tasks. Wether it be recording the time > stamp et ceterra, or altering your ruleset to reroute the scanners scans back > at them...personally as much of a nusaince as it it is I prefer to let them > scan and I still contact the offenders isp and go all through the motions...I > just don't hold my breath any more...;| Again, there is a DoS problem inherent in dynamically updating rulesets. First of it requires additional processing to add the ruleset and secondly it requires additional processing incoming traffic. Distributed Denial-of-Service tools would be able to get your box down to a grind far quicker than if you just let them flood you with traffic. The solution here, is rahter than update the rulesets on the box itself, update them one hop up at the router. This way, your box stays alive, you're protected against the DoS and you're going to be adding additional load to your server (which is what the attackers want). I have to say at the moment I let most of the scans go un-noticed unless it's one of my own users. I will however retain all the packets and try and do a little bit of pattern matching - same host scans every night etc., and try and inform in those situations as it could be a signature of a compromised host. -- Paul Robinson - Developer/Systems Administrator @ Akitanet Internet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 21 13:37:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from gto.networkphysics.com (DNS1.networkphysics.com [63.194.71.40]) by hub.freebsd.org (Postfix) with ESMTP id 6FCE837BEF5 for ; Tue, 21 Mar 2000 13:37:56 -0800 (PST) (envelope-from pavel@hemi.networkphysics.com) Received: from hemi.networkphysics.com (hemi.networkphysics.com [10.1.0.30]) by gto.networkphysics.com (8.9.3/8.9.3) with ESMTP id NAA37883 for ; Tue, 21 Mar 2000 13:37:56 -0800 (PST) (envelope-from pavel@hemi.networkphysics.com) Message-Id: <200003212137.NAA37883@gto.networkphysics.com> To: freebsd-net@FreeBSD.ORG Subject: Netgraph and promiscuous interfaces Reply-To: pavel@alum.mit.edu X-Face: 3Y45fK2P',OZ{p{%jFQfsYLQA)-,d1K+cx@v"K(1.9^"Cx-J*93m!X9nsl*8C\'.tt} ;X+GO]HCw8n=+Dn Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Encouraged by my hard-won success at getting the trivial "nghook -a de3: divert" example working (see my Mar 16 message on KLD problems with netgraph), I have moved on in my effort to convert a BPF-based userland app into netgraph-based kernel processing. I discovered that nghook will show me only ARPs and packets directed to my interfaces' IP address. Well, of course, the interface is not in promiscuous mode... So, I discovered that the "mtest" program provides a simple way to set promiscuous mode on an interface, saving me the trouble of writing a program to do the SIOCSIFFLAGS ioctl. Afterwards, ifconfig indeed shows me the PROMISC flag. It turns out, however, that my strategy of replacing BPF with netgraph is flawed. All of the drivers I looked at contain code something like this (from if_de.c): if ((sc->tulip_flags & (TULIP_PROMISC|TULIP_HASHONLY)) && (eh.ether_dhost[0] & 1) == 0 && !TULIP_ADDREQUAL(eh.ether_dhost, sc->tulip_enaddr)) goto next; accept = 1; ... next: ... if (accept) ether_input(ifp, &eh, ms); Clearly, the idea is that BPF is the only consumer of promiscuous-mode packets and that ether_input() should not be called with packets that wouldn't otherwise be seen when the interface is in promiscuous mode. So, I'm trying to understand how all these pieces fit together. Is it the responsibility of every network driver to keep ether_input() from seeing all these promiscuous-mode only packets? Wouldn't it be more efficient to collect these tests inside the ether_input() routine? Of course, this would then make it easier for me to move the ngether_send() call up before the IFF_PROMISC test and discard of the packets. Has no one ever tried netgraph with a promiscuous interface before? Naturally, this would not be the usual PPPoE setup, but I thought netgraph is supposed to be useful for myriad network tasks beyond just PPPoE or HDLC. Am I the only one ambitious enough to try something like this? I'll be pondering further how to make things work, but I could certainly use some pointers and some architectural insight... Tom Pavel Network Physics pavel@networkphysics.com / pavel@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 21 15:32:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by hub.freebsd.org (Postfix) with ESMTP id 99F4637BD42 for ; Tue, 21 Mar 2000 15:32:11 -0800 (PST) (envelope-from dermot@mcnally.de) Received: from TIGGER (p3E9B8FCD.dip.t-dialin.net [62.155.143.205]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id PAA15540; Tue, 21 Mar 2000 15:28:34 -0800 (PST) Message-Id: <4.2.0.58.20000322002243.028deef8@tim> X-Sender: dermot@tim X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 22 Mar 2000 00:31:48 +0100 To: Brian Somers From: Dermot McNally Subject: Re: NAT issues with ppp - a fix Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <200003200835.IAA00371@hak.lan.Awfulhak.org> References: <200003052213.WAA07676@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:35 20.03.2000 +0000, Brian Somers wrote: >Still ranting (but with a reduced cc list).... > >It looks like this has nothing to do with fragmentation - not in my >case anyway. I've added diagnostics to the fragmentation code in >nat_cmd.c, and there is no unexpected lossage. > >Is anyone in a position to try this (or a similar) scenario *without* >-nat (with real IP numbers - something I haven't got enough of) ? Do >things behave strangely ? Not me, unfortunately - I have precisely one real IP address when connected over DSL, and that's the one I get randomly allocated at connect time. I _can_ tell you that things always worked hunky dory from the actual FreeBSD box that makes the connection, but I don't think that's news to anyone... Anyway, while I have your attention, Maybe you could offer your opinion of the following log extract. Basically, this is the kind of thing I see when my connection has just dropped without me doing anything (and without the link being idle). It looks to me like the remote host is shutting down the connection. Is this the casE? If so, Deutsche Telekom will be getting snotty mails from me. I suspect that they have things set up to terminate your connection if they haven't heard from their proprietary Windows dialler thingy after a certain time - not surprising, since I only ever used it once to test the connection. Mar 4 11:06:16 tim ppp[19247]: tun0: LCP: deflink: RecvEchoRequest(86) state = Opened Mar 4 11:06:16 tim ppp[19247]: tun0: LCP: deflink: SendEchoReply(86) state = Opened Mar 4 11:06:19 tim ppp[19247]: tun0: LCP: deflink: RecvEchoRequest(87) state = Opened Mar 4 11:06:19 tim ppp[19247]: tun0: LCP: deflink: SendEchoReply(87) state = Opened Mar 4 11:06:22 tim ppp[19247]: tun0: LCP: deflink: RecvEchoRequest(88) state = Opened Mar 4 11:06:22 tim ppp[19247]: tun0: LCP: deflink: SendEchoReply(88) state = Opened Mar 4 11:06:25 tim ppp[19247]: tun0: LCP: deflink: RecvEchoRequest(89) state = Opened Mar 4 11:06:25 tim ppp[19247]: tun0: LCP: deflink: SendEchoReply(89) state = Opened Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: Received NGM_PPPOE_CLOSE (hook "tun0") Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: Device disconnected Mar 4 11:06:28 tim ppp[19247]: tun0: LCP: deflink: LayerDown Mar 4 11:06:28 tim ppp[19247]: tun0: LCP: deflink: State change Opened --> Starting Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: open -> lcp Mar 4 11:06:28 tim ppp[19247]: tun0: LCP: deflink: LayerFinish Mar 4 11:06:28 tim ppp[19247]: tun0: LCP: deflink: State change Starting --> Initial Mar 4 11:06:28 tim ppp[19247]: tun0: IPCP: deflink: LayerDown: 62.158.207.177 Mar 4 11:06:28 tim ppp[19247]: tun0: IPCP: deflink: State change Opened --> Starting Mar 4 11:06:28 tim ppp[19247]: tun0: IPCP: deflink: LayerFinish. Mar 4 11:06:28 tim ppp[19247]: tun0: IPCP: Connect time: 270 secs: 282245 octets in, 102550 octets out Mar 4 11:06:28 tim ppp[19247]: tun0: IPCP: total 1425 bytes/sec, peak 9374 bytes/sec on Sat Mar 4 11:06:28 2000 Mar 4 11:06:28 tim ppp[19247]: tun0: IPCP: deflink: State change Starting --> Initial Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: bundle: Terminate Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: Disconnected! Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: lcp -> logout Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: Disconnected! Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: logout -> hangup Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: Connect time: 271 secs: 285204 octets in, 105566 octets out Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: total 1441 bytes/sec, peak 9458 bytes/sec on Sat Mar 4 11:06:28 2000 Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: hangup -> closed Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: bundle: Dead To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 21 18:38:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from dustdevil.waterspout.com (dustdevil.waterspout.com [208.13.60.151]) by hub.freebsd.org (Postfix) with ESMTP id 1ECEB37BF4C for ; Tue, 21 Mar 2000 18:38:13 -0800 (PST) (envelope-from csg@waterspout.com) Received: from waterspout.com (csg@localhost [127.0.0.1]) by dustdevil.waterspout.com (8.9.3/8.9.3) with ESMTP id VAA01543 for ; Tue, 21 Mar 2000 21:39:25 -0500 (EST) (envelope-from csg@waterspout.com) Message-Id: <200003220239.VAA01543@dustdevil.waterspout.com> To: freebsd-net@freebsd.org From: "C. Stephen Gunn" Subject: Trimming ether_header before ether_input() MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1539.953692765.1@waterspout.com> Date: Tue, 21 Mar 2000 21:39:25 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In my wanderings through the FreeBSD networking code, I've noticed something peculiar in all ethernet drivers. Is there a historical reason that the ethernet header is trimmed from the mbuf chain before its passed to ether_input()? I can only assume that (at one time) there were ethernet devices (back in the IMP days) that handed you the link header and the payload in separate buffers. Today, _EVERY_ ethernet driver in FreeBSD does something like this in its receive routine: m_adj(m, sizeof(struct ether_header)); ether_input(ifp, eh, m); Why not simply pass the entire frame to ether_input(), and let it remove it when appropriate? This would make the following cleanups/improvements: - A clean line between the device, which puts frames onto and receives frames from the physical (or logical) wire, and generalized ethernet support code, that parses/removes the local net header. - Lots of duplicated effort in drivers could be centralized into the common ethernet code. Mostly BPF taps, but not limited to those. - Some layer-2 protocols require the frame header. Right now ether_input copies this data back into the mbuf before queing a NETISR for the protocol stack. Comments? Suggestions? Blatant mis-observations? - Steve -- C. Stephen Gunn URL: http://www.waterspout.com/ WaterSpout Communications, Inc. Email: csg@waterspout.com 427 North 6th Street Phone: +1 765.742.6628 Lafayette, IN 47901 Fax: +1 765.742.0646 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 21 19:27:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from awfulhak.org (dynamic-38.max4-du-ws.dialnetwork.pavilion.co.uk [212.74.9.166]) by hub.freebsd.org (Postfix) with ESMTP id 9346637BD89 for ; Tue, 21 Mar 2000 19:27:11 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id DAA23428; Wed, 22 Mar 2000 03:17:00 GMT (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id DAA06556; Wed, 22 Mar 2000 03:16:59 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200003220316.DAA06556@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Dermot McNally Cc: Brian Somers , freebsd-net@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: NAT issues with ppp - a fix In-Reply-To: Message from Dermot McNally of "Wed, 22 Mar 2000 00:31:48 +0100." <4.2.0.58.20000322002243.028deef8@tim> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Mar 2000 03:16:59 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [.....] > Anyway, while I have your attention, Maybe you could offer your opinion of > the following log extract. Basically, this is the kind of thing I see when > my connection has just dropped without me doing anything (and without the > link being idle). It looks to me like the remote host is shutting down the > connection. Is this the casE? If so, Deutsche Telekom will be getting > snotty mails from me. I suspect that they have things set up to terminate > your connection if they haven't heard from their proprietary Windows > dialler thingy after a certain time - not surprising, since I only ever > used it once to test the connection. > > Mar 4 11:06:16 tim ppp[19247]: tun0: LCP: deflink: RecvEchoRequest(86) > state = Opened > Mar 4 11:06:16 tim ppp[19247]: tun0: LCP: deflink: SendEchoReply(86) state > = Opened > Mar 4 11:06:19 tim ppp[19247]: tun0: LCP: deflink: RecvEchoRequest(87) > state = Opened > Mar 4 11:06:19 tim ppp[19247]: tun0: LCP: deflink: SendEchoReply(87) state > = Opened > Mar 4 11:06:22 tim ppp[19247]: tun0: LCP: deflink: RecvEchoRequest(88) > state = Opened > Mar 4 11:06:22 tim ppp[19247]: tun0: LCP: deflink: SendEchoReply(88) state > = Opened > Mar 4 11:06:25 tim ppp[19247]: tun0: LCP: deflink: RecvEchoRequest(89) > state = Opened > Mar 4 11:06:25 tim ppp[19247]: tun0: LCP: deflink: SendEchoReply(89) state > = Opened > Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: Received NGM_PPPOE_CLOSE (hook > "tun0") > Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: Device disconnected > Mar 4 11:06:28 tim ppp[19247]: tun0: LCP: deflink: LayerDown > Mar 4 11:06:28 tim ppp[19247]: tun0: LCP: deflink: State change Opened --> > Starting > Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: open -> lcp > Mar 4 11:06:28 tim ppp[19247]: tun0: LCP: deflink: LayerFinish > Mar 4 11:06:28 tim ppp[19247]: tun0: LCP: deflink: State change Starting > --> Initial > Mar 4 11:06:28 tim ppp[19247]: tun0: IPCP: deflink: LayerDown: 62.158.207.177 > Mar 4 11:06:28 tim ppp[19247]: tun0: IPCP: deflink: State change Opened > --> Starting > Mar 4 11:06:28 tim ppp[19247]: tun0: IPCP: deflink: LayerFinish. > Mar 4 11:06:28 tim ppp[19247]: tun0: IPCP: Connect time: 270 secs: 282245 > octets in, 102550 octets out > Mar 4 11:06:28 tim ppp[19247]: tun0: IPCP: total 1425 bytes/sec, peak > 9374 bytes/sec on Sat Mar 4 11:06:28 2000 > Mar 4 11:06:28 tim ppp[19247]: tun0: IPCP: deflink: State change Starting > --> Initial > Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: bundle: Terminate > Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: Disconnected! > Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: lcp -> logout > Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: Disconnected! > Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: logout -> hangup > Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: Connect time: 271 > secs: 285204 octets in, 105566 octets out > Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: total 1441 bytes/sec, peak > 9458 bytes/sec on Sat Mar 4 11:06:28 2000 > Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: deflink: hangup -> closed > Mar 4 11:06:28 tim ppp[19247]: tun0: Phase: bundle: Dead Can you try with the latest code (committed about 20 minutes ago) ? There were some issues with how things were being shut down that are now a bit more correct. If you don't cvsup -current, the latest archive (000322) should be there shortly. Ta. -- 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 Wed Mar 22 9: 8:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from gw.errno.com (node-d1d4bd7a.powerinter.net [209.212.189.122]) by hub.freebsd.org (Postfix) with ESMTP id EAC6B37B9F8 for ; Wed, 22 Mar 2000 09:08:49 -0800 (PST) (envelope-from sam@errno.com) Received: from MELANGE (melange.errno.com [209.212.166.36]) by gw.errno.com (8.9.0/8.9.0) with SMTP id JAA10023; Wed, 22 Mar 2000 09:04:18 -0800 (PST) Message-ID: <005301bf9420$a53ebdc0$0132a8c0@MELANGE> From: "Sam Leffler" To: , "C. Stephen Gunn" References: <200003220239.VAA01543@dustdevil.waterspout.com> Subject: Re: Trimming ether_header before ether_input() Date: Wed, 22 Mar 2000 09:04:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ----- Original Message ----- From: "C. Stephen Gunn" To: Sent: Tuesday, March 21, 2000 6:39 PM Subject: Trimming ether_header before ether_input() > In my wanderings through the FreeBSD networking code, I've noticed > something peculiar in all ethernet drivers. Is there a historical > reason that the ethernet header is trimmed from the mbuf chain > before its passed to ether_input()? > > I can only assume that (at one time) there were ethernet devices > (back in the IMP days) that handed you the link header and the > payload in separate buffers. > When all this code was written there was a link layer encapsulation called a trailer protocol that placed the Ethernet header at the end of the packet. I think it's described in the "real BSD book" (the 4.2 one, not a later one :-)); if not there is an RFC that describes it. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 22 9:11:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id 92F5A37C0C3 for ; Wed, 22 Mar 2000 09:11:13 -0800 (PST) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 8E7E51E012; Wed, 22 Mar 2000 12:11:08 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA21690; Wed, 22 Mar 2000 12:11:07 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id JAA25152; Wed, 22 Mar 2000 09:10:23 -0800 (PST) Message-Id: <200003221710.JAA25152@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: mike@argos.org Subject: Re: RIP troubles Cc: freebsd-net@freebsd.org Date: Wed, 22 Mar 2000 09:10:22 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Have you tried "no_ag" in /etc/gateways? You need to use RIPv2 if you want to advertise variable length netmasks, since RIPv1 didn't carry netmasks. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 22 10:57: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from dustdevil.waterspout.com (fourier.physics.purdue.edu [128.210.146.43]) by hub.freebsd.org (Postfix) with ESMTP id A9F8037C1E8 for ; Wed, 22 Mar 2000 10:57:04 -0800 (PST) (envelope-from csg@dustdevil.waterspout.com) Received: (from csg@localhost) by dustdevil.waterspout.com (8.9.3/8.9.3) id NAA05037; Wed, 22 Mar 2000 13:58:00 -0500 (EST) (envelope-from csg) Date: Wed, 22 Mar 2000 13:57:59 -0500 From: "C. Stephen Gunn" To: Sam Leffler Cc: freebsd-net@freebsd.org Subject: Re: Trimming ether_header before ether_input() Message-ID: <20000322135759.A5013@waterspout.com> References: <200003220239.VAA01543@dustdevil.waterspout.com> <005301bf9420$a53ebdc0$0132a8c0@MELANGE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <005301bf9420$a53ebdc0$0132a8c0@MELANGE>; from sam@errno.com on Wed, Mar 22, 2000 at 09:04:07AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Mar 22, 2000 at 09:04:07AM -0800, Sam Leffler wrote: > When all this code was written there was a link layer encapsulation > called a trailer protocol that placed the Ethernet header at the > end of the packet. I think it's described in the "real BSD book" > (the 4.2 one, not a later one :-)); if not there is an RFC that > describes it. Hmm.. I don't have the 4.2 book around... I'm too young for that. Is it fair to say that while the current implementation is historically rooted, but the historical reasons currently apply? I'll try to work up a patch for this... - Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 22 11: 4:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from gw.errno.com (node-d1d4bd7a.powerinter.net [209.212.189.122]) by hub.freebsd.org (Postfix) with ESMTP id 36A5E37C267 for ; Wed, 22 Mar 2000 11:04:23 -0800 (PST) (envelope-from sam@errno.com) Received: from MELANGE (melange.errno.com [209.212.166.36]) by gw.errno.com (8.9.0/8.9.0) with SMTP id KAA10346; Wed, 22 Mar 2000 10:59:53 -0800 (PST) Message-ID: <010101bf9430$c8e364f0$0132a8c0@MELANGE> From: "Sam Leffler" To: "C. Stephen Gunn" Cc: References: <200003220239.VAA01543@dustdevil.waterspout.com> <005301bf9420$a53ebdc0$0132a8c0@MELANGE> <20000322135759.A5013@waterspout.com> Subject: Re: Trimming ether_header before ether_input() Date: Wed, 22 Mar 2000 10:59:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you're asking, can this still happen; then the answer is it's very unlikely and it's probably safe to assume the link layer header is contiguous with the payload. But I haven't touched a BSD network driver in years so I defer to others. Sam ----- Original Message ----- From: "C. Stephen Gunn" To: "Sam Leffler" Cc: Sent: Wednesday, March 22, 2000 10:57 AM Subject: Re: Trimming ether_header before ether_input() > On Wed, Mar 22, 2000 at 09:04:07AM -0800, Sam Leffler wrote: > > > When all this code was written there was a link layer encapsulation > > called a trailer protocol that placed the Ethernet header at the > > end of the packet. I think it's described in the "real BSD book" > > (the 4.2 one, not a later one :-)); if not there is an RFC that > > describes it. > > Hmm.. I don't have the 4.2 book around... I'm too young for that. > > Is it fair to say that while the current implementation is historically > rooted, but the historical reasons currently apply? > > I'll try to work up a patch for this... > > - Steve > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 22 11:12: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from guard.polynet.lviv.ua (Guard.PolyNet.Lviv.UA [209.58.62.194]) by hub.freebsd.org (Postfix) with SMTP id 869BE37C1E2 for ; Wed, 22 Mar 2000 11:11:42 -0800 (PST) (envelope-from akorud@polynet.lviv.ua) Received: (qmail 597 invoked from network); 22 Mar 2000 19:11:38 -0000 Received: from unknown (HELO postoffice.polynet.lviv.ua) (unknown) by unknown with SMTP; 22 Mar 2000 19:11:38 -0000 Received: (qmail 8609 invoked from network); 22 Mar 2000 19:11:38 -0000 Received: (ofmipd unknown); 22 Mar 2000 19:11:16 -0000 Date: 22 Mar 2000 21:11:47 +0200 Message-ID: From: "Andriy Korud" To: freebsd-net@freebsd.org Subject: ALTQ and PPP MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" 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 Hi all, I need to setup the following router: 1. Cronyx Tau-PCI/G.703 (first channel) - ulplink to provider (Cisco) 2. Cronyx Tau-PCI/G.703 (second channel) - client 3. Ethernet (IntelEtherExpress) - client 4. Async PPP at 115kbps - client I need to prioritize traffic from 1 to 2,3,4 (and correspondingly from 2,3,4 to 1) with different priorities. I know I have to look at ALTQ but not sure all this will work. Can anybody help me? May be Linux is better suited for this? It's all the same for me what to use, but I'd prefer FreeBSD if it can handle this task. Thanks in advance, Andriy Korud, Lviv, Ukraine To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 22 11:14:58 2000 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 85F1F37BF54 for ; Wed, 22 Mar 2000 11:14:34 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA27909; Wed, 22 Mar 2000 14:14:24 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Mar 2000 14:14:24 -0500 (EST) From: Garrett Wollman Message-Id: <200003221914.OAA27909@khavrinen.lcs.mit.edu> To: "Sam Leffler" Cc: "C. Stephen Gunn" , Subject: Re: Trimming ether_header before ether_input() In-Reply-To: <010101bf9430$c8e364f0$0132a8c0@MELANGE> References: <200003220239.VAA01543@dustdevil.waterspout.com> <005301bf9420$a53ebdc0$0132a8c0@MELANGE> <20000322135759.A5013@waterspout.com> <010101bf9430$c8e364f0$0132a8c0@MELANGE> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > If you're asking, can this still happen; then the answer is it's very > unlikely and it's probably safe to assume the link layer header is > contiguous with the payload. But I haven't touched a BSD network driver in > years so I defer to others. The support for the trailer encapsulation was ripped out, IIRC, between Net-2 and 4.4-Lite. We don't even have an IFF_TRAILERS flag any more. There are some network interfaces which can return the header separately, but I don't see any particularly good reason to cater to them. -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 Mar 22 11:15:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from chai.torrentnet.com (chai.torrentnet.com [198.78.51.73]) by hub.freebsd.org (Postfix) with ESMTP id C53DB37C1E9 for ; Wed, 22 Mar 2000 11:15:10 -0800 (PST) (envelope-from bakul@torrentnet.com) Received: from chai.torrentnet.com (localhost [127.0.0.1]) by chai.torrentnet.com (8.8.8/8.8.5) with ESMTP id OAA21851; Wed, 22 Mar 2000 14:15:02 -0500 (EST) Message-Id: <200003221915.OAA21851@chai.torrentnet.com> To: "Sam Leffler" Cc: freebsd-net@FreeBSD.ORG, "C. Stephen Gunn" Subject: Re: Trimming ether_header before ether_input() In-reply-to: Your message of "Wed, 22 Mar 2000 09:04:07 PST." <005301bf9420$a53ebdc0$0132a8c0@MELANGE> Date: Wed, 22 Mar 2000 14:15:02 -0500 From: Bakul Shah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > something peculiar in all ethernet drivers. Is there a historical > > reason that the ethernet header is trimmed from the mbuf chain > > before its passed to ether_input()? > > > > I can only assume that (at one time) there were ethernet devices > > (back in the IMP days) that handed you the link header and the > > payload in separate buffers. > > > > When all this code was written there was a link layer encapsulation called a > trailer protocol that placed the Ethernet header at the end of the packet. ^^^^^^^^^^^^^^^ > I think it's described in the "real BSD book" (the 4.2 one, not a later one > :-)); if not there is an RFC that describes it. Perhaps you mean ``protocol header(s) above the ethernet level at the end of the packet''? The 14 byte ethernet header has to be at the front (unless you had significantly simpler devices than that old seeq8005). A separate arg for the ethernet header may have something to do with a device where the header was in a separate place that could not be an mbuf struct? Another reason may have to do with alignment. Some devices may prefer to put ethernet payload as well as header on a 4 byte boundary. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 22 11:29:21 2000 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 664E337C1DA for ; Wed, 22 Mar 2000 11:29:15 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA27992; Wed, 22 Mar 2000 14:29:12 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Mar 2000 14:29:12 -0500 (EST) From: Garrett Wollman Message-Id: <200003221929.OAA27992@khavrinen.lcs.mit.edu> To: "C. Stephen Gunn" Cc: freebsd-net@FreeBSD.ORG Subject: Trimming ether_header before ether_input() In-Reply-To: <200003220239.VAA01543@dustdevil.waterspout.com> References: <200003220239.VAA01543@dustdevil.waterspout.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Comments? Suggestions? Blatant mis-observations? Go for it! -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 Mar 22 13:34: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from gw.errno.com (node-d1d4bd7a.powerinter.net [209.212.189.122]) by hub.freebsd.org (Postfix) with ESMTP id 1D23A37B89A for ; Wed, 22 Mar 2000 13:34:02 -0800 (PST) (envelope-from sam@errno.com) Received: from MELANGE (melange.errno.com [209.212.166.36]) by gw.errno.com (8.9.0/8.9.0) with SMTP id NAA10798; Wed, 22 Mar 2000 13:29:26 -0800 (PST) Message-ID: <011001bf9445$adaca3d0$0132a8c0@MELANGE> From: "Sam Leffler" To: "Bakul Shah" Cc: , "C. Stephen Gunn" References: <200003221915.OAA21851@chai.torrentnet.com> Subject: Re: Trimming ether_header before ether_input() Date: Wed, 22 Mar 2000 13:29:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you read the RFC or the book you'll see that the original Ethernet header was copied to the end (the "trailer") and a new one was created. The purpose was to get the payload page-aligned on receipt so we could do page flipping tricks with the Unibus adapter. Worked very well for it's time; but people frowned on it because it wasn't standard and so led to interoperability problems. Sam ----- Original Message ----- From: "Bakul Shah" To: "Sam Leffler" Cc: ; "C. Stephen Gunn" Sent: Wednesday, March 22, 2000 11:15 AM Subject: Re: Trimming ether_header before ether_input() > > > something peculiar in all ethernet drivers. Is there a historical > > > reason that the ethernet header is trimmed from the mbuf chain > > > before its passed to ether_input()? > > > > > > I can only assume that (at one time) there were ethernet devices > > > (back in the IMP days) that handed you the link header and the > > > payload in separate buffers. > > > > > > > When all this code was written there was a link layer encapsulation called a > > trailer protocol that placed the Ethernet header at the end of the packet. > ^^^^^^^^^^^^^^^ > > I think it's described in the "real BSD book" (the 4.2 one, not a later one > > :-)); if not there is an RFC that describes it. > > Perhaps you mean ``protocol header(s) above the ethernet > level at the end of the packet''? The 14 byte ethernet header > has to be at the front (unless you had significantly simpler > devices than that old seeq8005). A separate arg for the > ethernet header may have something to do with a device where > the header was in a separate place that could not be an mbuf > struct? Another reason may have to do with alignment. > Some devices may prefer to put ethernet payload as well as > header on a 4 byte boundary. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 22 13:53:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by hub.freebsd.org (Postfix) with ESMTP id C5F3C37B692 for ; Wed, 22 Mar 2000 13:53:25 -0800 (PST) (envelope-from dermot@mcnally.de) Received: from TIGGER (p3E9B8FD4.dip.t-dialin.net [62.155.143.212]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id NAA18816; Wed, 22 Mar 2000 13:49:48 -0800 (PST) Message-Id: <4.2.0.58.20000322225052.0296b6d0@tim> X-Sender: dermot@tim X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 22 Mar 2000 22:53:24 +0100 To: Brian Somers From: Dermot McNally Subject: Re: NAT issues with ppp - a fix Cc: freebsd-net@FreeBSD.ORG, brian@hak.lan.Awfulhak.org In-Reply-To: <200003220316.DAA06556@hak.lan.Awfulhak.org> References: <4.2.0.58.20000322002243.028deef8@tim> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 03:16 22.03.2000 +0000, Brian Somers wrote: >Can you try with the latest code (committed about 20 minutes ago) ? >There were some issues with how things were being shut down that are >now a bit more correct. Yup, am now trying, if I don't get kicked, we'll know... >If you don't cvsup -current, the latest archive (000322) should be >there shortly. Well, like a lot of folk, I just stopped cvsupping -current when it went 5.0. I suppose if this lot turns out to work, it will be merged? Dermot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 22 14: 1:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 6A4F337C2A2 for ; Wed, 22 Mar 2000 14:01:40 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id WAA29655; Wed, 22 Mar 2000 22:01:09 GMT (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id WAA03268; Wed, 22 Mar 2000 22:01:06 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200003222201.WAA03268@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Dermot McNally Cc: Brian Somers , freebsd-net@FreeBSD.ORG, brian@hak.lan.awfulhak.org, brian@hak.lan.awfulhak.org Subject: Re: NAT issues with ppp - a fix In-Reply-To: Message from Dermot McNally of "Wed, 22 Mar 2000 22:53:24 +0100." <4.2.0.58.20000322225052.0296b6d0@tim> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Mar 2000 22:01:06 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > At 03:16 22.03.2000 +0000, Brian Somers wrote: > > >Can you try with the latest code (committed about 20 minutes ago) ? > >There were some issues with how things were being shut down that are > >now a bit more correct. > > Yup, am now trying, if I don't get kicked, we'll know... > > >If you don't cvsup -current, the latest archive (000322) should be > >there shortly. > > Well, like a lot of folk, I just stopped cvsupping -current when it went > 5.0. I suppose if this lot turns out to work, it will be merged? Yep. The stuff I committed last night can only be classed as bug fixes. But that area of the code is pretty dangerous, so I'd like to give it a little more exposure in -current for a while. > Dermot -- 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 Thu Mar 23 5:49:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from netcom.com (netcom14.netcom.com [199.183.9.114]) by hub.freebsd.org (Postfix) with ESMTP id 4A73B37C455 for ; Thu, 23 Mar 2000 05:49:53 -0800 (PST) (envelope-from stanb@netcom.com) Received: (from stanb@localhost) by netcom.com (8.9.3/8.9.3) id FAA03184 for freebsd-net@FreeBSD.ORG; Thu, 23 Mar 2000 05:49:51 -0800 (PST) From: Stan Brown Message-Id: <200003231349.FAA03184@netcom.com> Subject: OACTIBE problems To: freebsd-net@FreeBSD.ORG (FreeBSD Networking) Date: Thu, 23 Mar 2000 08:49:51 -0500 (EST) X-Mailer: ELM [version 2.5 PL3] 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 have build a FreeBSD 3.4 machine to work as a firewall between a control systems network and the corporate network. Yhe machine contains 2 3COM Etherlin III catds. The Networks on both sides are 10baseT. As usual with FreeBSD, this machine was easy to set upop and get going. However I am now having a problem which I can't figure out. When the machine is subjected to sustained heavy network trafic (amanda backups). The card on teh control system side hangs in an OACRIVE state. I have at this point in time, changed the 3COM card on that side, swaped the hubs between sides, and even upgarded the computer fomr a 486/66 to a P75. If anything the P75 seems to habg sooner. Cany anyone make any sugestiosn as to what to ty next? -- Stan Brown stanb@netcom.com 404-996-6955 Factory Automation Systems Atlanta Ga. -- Look, look, see Windows 95. Buy, lemmings, buy! Pay no attention to that cliff ahead... Henry Spencer (c) 1998 Stan Brown. Redistribution via the Microsoft Network is prohibited. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 23 8:48:30 2000 Delivered-To: freebsd-net@freebsd.org Received: from inetfw.sonycsl.co.jp (inetfw.SonyCSL.Co.Jp [203.137.129.4]) by hub.freebsd.org (Postfix) with ESMTP id 8341E37C4BC for ; Thu, 23 Mar 2000 08:48:25 -0800 (PST) (envelope-from kjc@csl.sony.co.jp) Received: from hotaka.csl.sony.co.jp (root@hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.9.3+3.2W/3.7Ws3/inetfw/2000030111/smtpfeed 1.01) with ESMTP id BAA90136; Fri, 24 Mar 2000 01:48:13 +0900 (JST) Received: from localhost (kjc@[127.0.0.1]) by hotaka.csl.sony.co.jp (8.8.8/3.7Ws3/hotaka/2000030111) with ESMTP id BAA14357; Fri, 24 Mar 2000 01:48:12 +0900 (JST) To: akorud@polynet.lviv.ua Cc: freebsd-net@freebsd.org, altq@csl.sony.co.jp Subject: Re: ALTQ and PPP In-Reply-To: References: X-Mailer: Mew version 1.95b3 on Emacs 20.5 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000324014812T.kjc@csl.sony.co.jp> Date: Fri, 24 Mar 2000 01:48:12 +0900 From: Kenjiro Cho X-Dispatcher: imput version 991025(IM133) Lines: 25 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andriy Korud wrote: > Hi all, > I need to setup the following router: > 1. Cronyx Tau-PCI/G.703 (first channel) - ulplink to provider (Cisco) > 2. Cronyx Tau-PCI/G.703 (second channel) - client > 3. Ethernet (IntelEtherExpress) - client > 4. Async PPP at 115kbps - client > > I need to prioritize traffic from 1 to 2,3,4 (and correspondingly from 2,3,4 > to 1) with different priorities. I know I have to look at ALTQ but not sure > all this will work. I'm not sure what you mean by "prioritize" but, if you want to simply limit bandwidth use, try dummynet. If you want to distribute excess bandwidth, you'll need ALTQ. Note that managing traffic from 1 to 2, 3, 4 is quite different from managing traffic from 2, 3, 4, to 1 since you can't do much about incoming traffic from a bottleneck. Another issue is that, as I understand it, the third party driver for Cronyx Tau replaces "sys/net/if_spppsubr.c" by its own version and you'll need to merge the ALTQ support by hand. -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 23 9:13:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from guard.polynet.lviv.ua (Guard.PolyNet.Lviv.UA [209.58.62.194]) by hub.freebsd.org (Postfix) with SMTP id 3F7C437B649 for ; Thu, 23 Mar 2000 09:13:09 -0800 (PST) (envelope-from akorud@polynet.lviv.ua) Received: (qmail 76519 invoked from network); 23 Mar 2000 17:06:13 -0000 Received: from unknown (HELO postoffice.polynet.lviv.ua) (unknown) by unknown with SMTP; 23 Mar 2000 17:06:13 -0000 Received: (qmail 62624 invoked from network); 23 Mar 2000 17:06:12 -0000 Received: (ofmipd unknown); 23 Mar 2000 17:05:50 -0000 Date: 23 Mar 2000 19:06:21 +0200 Message-ID: From: "Andriy Korud" To: "Kenjiro Cho" Cc: freebsd-net@freebsd.org, " " Subject: RE: ALTQ and PPP 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) In-Reply-To: <20000324014812T.kjc@csl.sony.co.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Andriy Korud wrote: > > Hi all, > > I need to setup the following router: > > 1. Cronyx Tau-PCI/G.703 (first channel) - ulplink to provider (Cisco) > > 2. Cronyx Tau-PCI/G.703 (second channel) - client > > 3. Ethernet (IntelEtherExpress) - client > > 4. Async PPP at 115kbps - client > > > > I need to prioritize traffic from 1 to 2,3,4 (and > correspondingly from 2,3,4 > > to 1) with different priorities. I know I have to look at ALTQ > but not sure > > all this will work. > > I'm not sure what you mean by "prioritize" but, if you want to simply > limit bandwidth use, try dummynet. If you want to distribute excess > bandwidth, you'll need ALTQ. > Note that managing traffic from 1 to 2, 3, 4 is quite different from > managing traffic from 2, 3, 4, to 1 since you can't do much about > incoming traffic from a bottleneck. > It seems that I really need ALTQ. Here I try to describe my needs more detailed: On other side of PPP interface (4) I'll have two clients, 4.1 and 4.2 I'll have the following data flows in my system (sorted by priority) 1. Internet via (1) <-> 3; (highest priority) 2. 3 <-> 4.1; 3. Internet via (1) <-> 4.2; 4. Internet via (1) <-> 2; I need to make rules like: if we have packet from 3 to Internet, all other will wait; If we have packet from 3 to 4.1 via PPP, other PPP traffic (to 4.2) will wait. etc I suppose that the hardest part will be to regulate incoming traffic from 1. On opposite side of 2,4 I plan to setup FreeBSD routers with ALTQ - this should help me. Thanks in advance, Andriy Korud, Lviv, Ukraine To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 23 16:16:17 2000 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 5399337B942 for ; Thu, 23 Mar 2000 16:16:08 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id QAA37807; Thu, 23 Mar 2000 16:15:30 -0800 (PST) From: Archie Cobbs Message-Id: <200003240015.QAA37807@bubba.whistle.com> Subject: Re: BPF question (FreeBSD 40) In-Reply-To: <38D39537.867C357C@cronyx.ru> from Kurakin Roman at "Mar 18, 2000 05:39:51 pm" To: rik@cronyx.ru (Kurakin Roman) Date: Thu, 23 Mar 2000 16:15:30 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG 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 Kurakin Roman writes: > I have question about using bpf in my KLD module driver. At attach I > call > bpfattach function. What should I call at detach? In -current there is now a new function bpfdetach() that you should call. -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 Thu Mar 23 17:38:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f330.law8.hotmail.com [216.33.240.205]) by hub.freebsd.org (Postfix) with SMTP id 7C7CE37BA3A for ; Thu, 23 Mar 2000 17:38:35 -0800 (PST) (envelope-from hotkaveh@hotmail.com) Received: (qmail 24626 invoked by uid 0); 24 Mar 2000 01:38:35 -0000 Message-ID: <20000324013835.24625.qmail@hotmail.com> Received: from 193.10.115.109 by www.hotmail.com with HTTP; Thu, 23 Mar 2000 17:38:35 PST X-Originating-IP: [193.10.115.109] From: "Kave p.Ram" To: freebsd-net@freebsd.org Subject: kernel message and default gateway Date: Fri, 24 Mar 2000 01:38:35 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi ! the ip number of our Default Gateway is : 10.252.35.254 and i use vr0 as the ethernet card on my machine=(10.252.32.164) I got this message in an email sent to me by cron (on my machine) about kernel messages today: /kernel arp: 10.252.35.254 moved from 00:20:18:8e:20:4b to 00:90:92:7f:dc:00 on vr0 what does this exactly mean ? I run FreeBSD 3.4 on my machine . Thanx for any suggestion, /kave ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 23 18: 3:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 352B637B650 for ; Thu, 23 Mar 2000 18:03:10 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id VAA82177; Thu, 23 Mar 2000 21:03:07 -0500 (EST) Date: Thu, 23 Mar 2000 21:03:07 -0500 (EST) From: "Matthew N. Dodd" To: Stan Brown Cc: FreeBSD Networking Subject: Re: OACTIBE problems In-Reply-To: <200003231349.FAA03184@netcom.com> 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, 23 Mar 2000, Stan Brown wrote: > I have build a FreeBSD 3.4 machine to work as a firewall between a > control systems network and the corporate network. Yhe machine contains > 2 3COM Etherlin III catds. The Networks on both sides are 10baseT. The 'ep' driver has received a bit more attention in 4.0 and -CURRENT. You might try to reproduce the problem under 4.0/4-STABLE. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 23 23:34:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from web3706.mail.yahoo.com (web3706.mail.yahoo.com [204.71.203.135]) by hub.freebsd.org (Postfix) with SMTP id 670ED37B56D for ; Thu, 23 Mar 2000 23:34:15 -0800 (PST) (envelope-from hiwaygao@yahoo.com.cn) Message-ID: <20000324073413.1602.qmail@web3706.mail.yahoo.com> Received: from [202.106.77.129] by web3706.mail.yahoo.com; Fri, 24 Mar 2000 15:34:13 CST Date: Fri, 24 Mar 2000 15:34:13 +0800 (CST) From: =?gb2312?q?l=20g?= Subject: SOS!about freebsd core constrution To: questions@FreeBSD.org, alex@big.endian.de, general@freebsdzine.org, jsutton@freebsdzine.org, akorud@polynet.lviv.ua, editors@freebsdzine.org, freebsd-net@freebsd.org, brian@Awfulhak.org, toasty@dragondata.com, freebsd-isp@FreeBSD.ORG, wigstah@akitanet.co.uk, sam@errno.com, rik@cronyx.ru, fenner@research.att.com, winter@jurai.net, barney@databus.com, cjc@cc942873-a.ewndsr1.nj.home.com, dermot@mcnally.de, chutima_s@zdnetonebox.com MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hi!every body!I'm a chinese student.I'm learning freebsd,because I have a project about core program.I need a mini core and add something about pppoe,QOS ,other protocol on the base of mini core.but I don't know the constrution of freebsd core and don't know how to add the model of protocol,and how to compile them .If you know the method or way ,please send a help message to hiwaygao@yahoo.com.cn. or If you know other understand it ,please send it .thank you _________________________________________________________ Do You Yahoo!? ΅ΗΒΌΓβ·Ρ΅ηΣΚΥΚΊΕ Get your free @yahoo.com.CN address at http://mail.yahoo.com.cn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 24 17:40:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from basic.maxnet.ru (ns.maxnet.ru [195.112.97.17]) by hub.freebsd.org (Postfix) with ESMTP id 0E18B37B78C for ; Fri, 24 Mar 2000 17:40:34 -0800 (PST) (envelope-from techsup@maxnet.ru) Received: from pshome (pshome.obninsk.ru [195.112.102.2]) by basic.maxnet.ru (8.9.3/8.9.0) with SMTP id EAA04669; Sat, 25 Mar 2000 04:40:12 +0300 (MSK) Message-ID: <013001bf95fb$2fc17240$026670c3@obninsk.ru> From: "MAXnet Technical Support" To: , "Kenjiro Cho" Cc: , References: Subject: Re: [altq 381] RE: ALTQ and PPP Date: Sat, 25 Mar 2000 04:41:04 +0300 Organization: MAXnet Systems Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Andriy I've got two comments to Your problem: 1. With ALTQ You can control only _OUTGOING_ traffic but not incoming. So the only way to contol incoming traffic on 1) is shaping of outgoing traffic on other interfaces. 2. You have to make drivers for Cronyx Tau compatible with ALTQ in order to achive Your goal. If You'll do so - please let me know 8) Paul Sokolovsky MAXnet Systems Russia ----- Original Message ----- From: "Andriy Korud" To: "Kenjiro Cho" Cc: ; Sent: 23 ????? 2000 ?. 20:06 Subject: [altq 381] RE: ALTQ and PPP > > > > Andriy Korud wrote: > > > Hi all, > > > I need to setup the following router: > > > 1. Cronyx Tau-PCI/G.703 (first channel) - ulplink to provider (Cisco) > > > 2. Cronyx Tau-PCI/G.703 (second channel) - client > > > 3. Ethernet (IntelEtherExpress) - client > > > 4. Async PPP at 115kbps - client > > > > > > I need to prioritize traffic from 1 to 2,3,4 (and > > correspondingly from 2,3,4 > > > to 1) with different priorities. I know I have to look at ALTQ > > but not sure > > > all this will work. > > > > I'm not sure what you mean by "prioritize" but, if you want to simply > > limit bandwidth use, try dummynet. If you want to distribute excess > > bandwidth, you'll need ALTQ. > > Note that managing traffic from 1 to 2, 3, 4 is quite different from > > managing traffic from 2, 3, 4, to 1 since you can't do much about > > incoming traffic from a bottleneck. > > > It seems that I really need ALTQ. > Here I try to describe my needs more detailed: > On other side of PPP interface (4) I'll have two clients, 4.1 and 4.2 > I'll have the following data flows in my system (sorted by priority) > 1. Internet via (1) <-> 3; (highest priority) > 2. 3 <-> 4.1; > 3. Internet via (1) <-> 4.2; > 4. Internet via (1) <-> 2; > > I need to make rules like: if we have packet from 3 to Internet, all other > will wait; > If we have packet from 3 to 4.1 via PPP, other PPP traffic (to 4.2) will > wait. etc > > I suppose that the hardest part will be to regulate incoming traffic from 1. > On opposite side of 2,4 I plan to setup FreeBSD routers with ALTQ - this > should help me. > > Thanks in advance, > Andriy Korud, Lviv, Ukraine > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 24 19:38: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by hub.freebsd.org (Postfix) with ESMTP id EE69937B522 for ; Fri, 24 Mar 2000 19:37:55 -0800 (PST) (envelope-from mgtak@crosswinds.net) Received: from r7a002503as.hlb.cable.rcn.com ([216.164.33.51] helo=vira) by smtp01.mrf.mail.rcn.net with smtp (Exim 2.12 #3) id 12YhO0-00079B-00 for net@freebsd.org; Fri, 24 Mar 2000 22:37:17 -0500 From: "MG_Tak" To: Subject: DHCP server, gateways and different networks Date: Fri, 24 Mar 2000 22:37:04 -0500 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 In-Reply-To: <013001bf95fb$2fc17240$026670c3@obninsk.ru> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, ------- Brief problem description: ------- Assigned by DHCP: NIC IP is of type 216.*.*.* Cable modem IP is of type 10.*.*.* Subnet (reported by winipcfg) : 255.255.255.0 Since they're not on the same subnet, FreeBSD's TCP/IP can't get the packets through between NIC and cable modem. I get 'no route to host' on ping, telnet, nslookup, etc... I need to find a way to get the NIC and modem to exchange packets succesfuly. -------------------------------------------- More detailed description: First of all, sorry for the somewhat meaningless subject, it's sort of hard to describe my problem in just one line. I'm connect to the net via a cable-modem. When I boot, the OS/NIC uses the DHCP protocol to get an IP address from the cable modem. This worked fine (although I had to manually cancel the lease on the IP whenever I turned my computer off, so as to be able to get it again when I boot) until my ISP changed the way the IP addresses were assigned. Now, my NIC's assigned IP is your average 216.*.*.* (for example) but my 'gateway' (which happens to be my cable modem) has an IP on the 'private' IP class 10.*.*.* . Now, if I remember correctly, 216.* and 10.* aren't on the same network, and naturally, I get a 'no route to host' whenever I try to do anything, whether it be ping, nslookup, or telnet. I need to find a way to get my system to understand that what's on the other end of the NIC is the gateway. I've been told that a command like 'route add 10.(whatever) netmask 255.255.255.255 metric 1' should work. Here is a little extra info: the 'subnet mask' reported by winipcfg is 255.255.255.0 As weird as it may be, the DHCP client in Win98 doesn't have any problems and doesn't even notice that the gateway isn't on the same subnet as the NIC. So if anyone's got an idea, I really would appreciate the help. Thanks for your time, MG_Tak To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 25 0: 8:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from eeyore.local.dohd.cx (d0030.dtk.chello.nl [213.46.0.30]) by hub.freebsd.org (Postfix) with ESMTP id BD47F37B6A1 for ; Sat, 25 Mar 2000 00:08:09 -0800 (PST) (envelope-from freebsd@dohd.cx) Received: from tiggr.local.dohd.cx (tiggr.local.dohd.cx [::ffff:10.0.0.10]) by eeyore.local.dohd.cx (Postfix) with ESMTP id 1E4B9BA9D for ; Sat, 25 Mar 2000 09:08:03 +0100 (MET) Received: by tiggr.local.dohd.cx (Postfix, from userid 1008) id C5E3ED0; Sat, 25 Mar 2000 09:08:02 +0100 (CET) Date: Sat, 25 Mar 2000 09:08:02 +0100 From: Mark Huizer To: net@freebsd.org Subject: Re: Default gateway outside range but on LAN... howto? Message-ID: <20000325090802.A44530@dohd.cx> References: <200003242220.RAA36174@larryboy.graphics.cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.4i In-Reply-To: <200003242220.RAA36174@larryboy.graphics.cornell.edu>; from mkc@Graphics.Cornell.EDU on Fri, Mar 24, 2000 at 05:20:32PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > It may be on the same layer 2 lan, but it's not on the same layer 3 > subnet. Something is really fubar here. The router *has* to be in > the same subnet. IP just plain won't work otherwise. You need to > either: I know it sucks. But a. the provider sets it up this way and it's not their first network delivered. b. Linux and various other pieces of hardware have no trouble configuring it this way. What kind of argument do you think you are making if you say "I know it works for your other customers, but it's wrong, and FreeBSD doesn't like it so fix it..." > > A. change your subnet to 10.0.0.0/28, which includes the router; that implies having to do weird stuff so the IP's that are not in our range can still be reached (using the router) > > or > > B. change the router's address so it's in your subnet? That was a possible solution, yes, take some IP address in our range, add an ARP entry for that IP in each hosts arp table, and route to that IP. Somehow I don't like having to set arp addresses on each host :-( > > If they've for some reason intentionally set up multiple subnets on a > single lan, which is perfectly permissible, then they need to configure > more than one IP address on that interface on the router, one for each > subnet. well, that seems to be the weird thing, it probably isn't one lan, but each segment is a seperate wire. Just this router is not in each lan. > > If the network administrator is really not allowing any of these then > he/she is highly incompetent for the job. Which probably wouldn't > be a first... hmm... I wasn't gonna say those things :-) Or type... but in the privacy of my brains... hmm... etc :-) > > Even if you were to try to kludge the routing by grabbing an ip address > in 10.0.0.0/29, which the router will talk to, and setting up a router > there for your subnet, you'd still have to convince it to send all > 10.0.0.9/29 traffic _to_ your router. As mentioned before: add -s $FAKEIP $HISMAC route add default $FAKEIP should work (but I haven't tested it actually, will do in a few minutes) > If you know (or can guess) what > routing protocol it listens to you can send announcements in that > protocol and see if it will pick them up, which it might not depending > on how it's configured, but I'm guessing this is far more complications > than you what you're looking for in an answer. yep :-) Thanks anyway Mark -- Nice testing in little China... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 25 11:33:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 0FC6437B66E; Sat, 25 Mar 2000 11:33:16 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id NAA19618; Sat, 25 Mar 2000 13:35:53 -0600 (CST) (envelope-from jlemon) Date: Sat, 25 Mar 2000 13:35:53 -0600 From: Jonathan Lemon To: net@freebsd.org, hackers@freebsd.org Subject: Request for review (HW checksum patches) Message-ID: <20000325133553.D71371@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a set of patches which allows offloading checksums to NICs which support it (right now, only the Alteon based cards). The patch is at . Note that the alpha bits are currently untested. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 25 12:50:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by hub.freebsd.org (Postfix) with ESMTP id 7419A37B936; Sat, 25 Mar 2000 12:50:51 -0800 (PST) (envelope-from justin@apple.com) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id MAA15611; Sat, 25 Mar 2000 12:50:41 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Sat, 25 Mar 2000 12:50:36 -0800 Received: from grinch ([17.219.158.67]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id MAA08969; Sat, 25 Mar 2000 12:50:40 -0800 (PST) Message-Id: <200003252050.MAA08969@scv1.apple.com> To: hackers@freebsd.org, net@freebsd.org Subject: Re: Request for review (HW checksum patches) Date: Sat, 25 Mar 2000 12:49:07 -0800 From: "Justin C. Walker" Reply-To: justin@apple.com X-Mailer: Apple Mail (2.303) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > From: Jonathan Lemon > Date: Sat, 25 Mar 2000 13:35:53 -0600 > To: net@FreeBSD.ORG, hackers@FreeBSD.ORG > Subject: Request for review (HW checksum patches) > X-Mailer: Mutt 1.0pre2i > Delivered-to: freebsd-net@freebsd.org > X-Loop: FreeBSD.org > > I have a set of patches which allows offloading checksums to > NICs which support it (right now, only the Alteon based cards). > The patch is at . This prompts a question on a related issue: there seems to be an increase in support of protocol operations on NICs (e.g., tickle/keep-alive support while the system is sleeping; IPSec; ...). Is there enough there to let us build a general mechanism for communication between stack and driver for this sort of thing (e.g., a "meta-data" slot in the packet header which points to an mbuf, or other structure, that contains the details)? We're currently trying to deal with this in Mac OS X, and it'd be nice to avoid having multiple wheels of different size and shape in the same source base. Regards, Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 25 12:53: 1 2000 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 1AC4537B9CB for ; Sat, 25 Mar 2000 12:52:58 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA64312; Sat, 25 Mar 2000 15:52:54 -0500 (EST) (envelope-from wollman) Date: Sat, 25 Mar 2000 15:52:54 -0500 (EST) From: Garrett Wollman Message-Id: <200003252052.PAA64312@khavrinen.lcs.mit.edu> To: justin@apple.com Cc: net@FreeBSD.ORG Subject: Re: Request for review (HW checksum patches) In-Reply-To: <200003252050.MAA08969@scv1.apple.com> References: <200003252050.MAA08969@scv1.apple.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > This prompts a question on a related issue: there seems to be an increase > in support of protocol operations on NICs The cycle of reincarnation turns again.... -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 Sat Mar 25 12:55:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E10237B6D1 for ; Sat, 25 Mar 2000 12:55:24 -0800 (PST) (envelope-from justin@apple.com) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id MAA21681 for ; Sat, 25 Mar 2000 12:55:16 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Sat, 25 Mar 2000 12:55:07 -0800 Received: from grinch ([17.219.158.67]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id MAA09221; Sat, 25 Mar 2000 12:55:12 -0800 (PST) Message-Id: <200003252055.MAA09221@scv1.apple.com> To: Garrett Wollman Subject: Re: Request for review (HW checksum patches) Cc: justin@apple.com, net@freebsd.org Date: Sat, 25 Mar 2000 12:53:38 -0800 From: "Justin C. Walker" Reply-To: justin@apple.com X-Mailer: Apple Mail (2.303) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Saturday, March 25, 2000, at 12:52 PM, Garrett Wollman wrote: > < said: > > > This prompts a question on a related issue: there seems to be an increase > > in support of protocol operations on NICs > > The cycle of reincarnation turns again.... I do recall a comment someone made about history, and learning, but it escapes me at the moment. Regards, Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 25 15:16: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from gw.errno.com (node-d1d4bd7a.powerinter.net [209.212.189.122]) by hub.freebsd.org (Postfix) with ESMTP id D8A1C37B921; Sat, 25 Mar 2000 15:16:03 -0800 (PST) (envelope-from sam@errno.com) Received: from MELANGE (melange.errno.com [209.212.166.36]) by gw.errno.com (8.9.0/8.9.0) with SMTP id PAA22995; Sat, 25 Mar 2000 15:16:01 -0800 (PST) Message-ID: <077a01bf96af$73dab720$0132a8c0@MELANGE> From: "Sam Leffler" To: , , References: <200003252050.MAA08969@scv1.apple.com> Subject: Re: Request for review (HW checksum patches) Date: Sat, 25 Mar 2000 15:11:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org FWIW, Win2000 has a mechanism for dealing with what they call task offloading. If you decide to attack the problem, an inexpensive device you can use for testing is the 3C905B; it does IP+TCP checksums. Sam ----- Original Message ----- From: "Justin C. Walker" To: ; Sent: Saturday, March 25, 2000 12:49 PM Subject: Re: Request for review (HW checksum patches) > > From: Jonathan Lemon > > Date: Sat, 25 Mar 2000 13:35:53 -0600 > > To: net@FreeBSD.ORG, hackers@FreeBSD.ORG > > Subject: Request for review (HW checksum patches) > > X-Mailer: Mutt 1.0pre2i > > Delivered-to: freebsd-net@freebsd.org > > X-Loop: FreeBSD.org > > > > I have a set of patches which allows offloading checksums to > > NICs which support it (right now, only the Alteon based cards). > > The patch is at . > > This prompts a question on a related issue: there seems to be an increase > in support of protocol operations on NICs (e.g., tickle/keep-alive support > while the system is sleeping; IPSec; ...). Is there enough there to let us > build a general mechanism for communication between stack and driver for > this sort of thing (e.g., a "meta-data" slot in the packet header which > points to an mbuf, or other structure, that contains the details)? > > We're currently trying to deal with this in Mac OS X, and it'd be nice to > avoid having multiple wheels of different size and shape in the same source > base. > > Regards, > > Justin > > > 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 Sat Mar 25 16: 3:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from Hydro.CAM.ORG (Hydro.CAM.ORG [198.168.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 0217637B601 for ; Sat, 25 Mar 2000 16:03:37 -0800 (PST) (envelope-from intmktg@CAM.ORG) Received: from cam.org (Dialup-1018.HIP.CAM.ORG [205.205.139.69]) by Hydro.CAM.ORG (8.8.8/8.8.4) with ESMTP id TAA18419 for ; Sat, 25 Mar 2000 19:03:34 -0500 (EST) Message-ID: <38DD50E4.DD1298C8@cam.org> Date: Sat, 25 Mar 2000 18:51:01 -0500 From: Claude Tardif X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: dumb terminal on db9 serial port Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I can't seem to get a login prompt on a wyse 60 connected to a 486dx2 running freebsd 3.4. I read the documentation: http://www.freebsd.org/handbook/term.html and these are the steps I have accomplished so far: 1. made sure both my db9 serial ports are recognised properly in dmesg: # dmesg | grep sio sio0 at 0x3f8-0x3ff irq4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq3 on isa sio1: type 16550A 2. edited the following lines in /etc/ttys ttyd0 "/usr/libexec/getty std.19200" wy60 on secure ttyd1 "/usr/libexec/getty std.19200" wy60 on secure 3. forced init to re-read /etc/ttys kill -HUP 1 4. wired my own null-modem cable (double-checked using a multi-meter), taken from: http://www.linux.org/help/ldp/howto/Text-Terminal-HOWTO-11.html#ss11.2 PC DB9 Terminal DB25 RxD Receive Data 2 <-- 2 TxD Transmit Data TxD Transmit Data 3 --> 3 RxD Receive Data SG Signal Ground 5 --- 7 SG Signal Ground CTS Clear To Send 8 <--20 DTR Data Terminal Ready RTS Request To Send 7 --> 6 DSR Data Set Ready 5. connected the wyse terminal to the first serial port and made sure the terminal was also set to 19200 bps (also tried the second serial port) At that point, I would expect to get a login prompt or at least some garbage on the dumb terminal, but no such luck. What could be the problem? Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message