From owner-freebsd-net Sun Jun 27 0: 8: 5 1999 Delivered-To: freebsd-net@freebsd.org Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (Postfix) with ESMTP id 48A9014BFE for ; Sun, 27 Jun 1999 00:08:02 -0700 (PDT) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.8/8.8.5) with SMTP id DAA10386; Sun, 27 Jun 1999 03:05:44 -0400 (EDT) Date: Sun, 27 Jun 1999 03:05:44 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: Wes Peters Cc: Tetsuya Watanabe , freebsd-net@FreeBSD.ORG Subject: Re: ADSL question after I searched mail archives and still have questions re DSL In-Reply-To: <37724073.CA69987B@softweyr.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, 24 Jun 1999, Wes Peters wrote: > Tetsuya Watanabe wrote: > FreeBSD doesn't know about the ADSL, it just sees a router. Your "ADSL > modem" is really an ethernet to ATM router, and should answer the DHCP > request for you. Doesn't it? Probably not. I understand most of the cable modems work that way, but even the one I've seen still then acts as a DHCP *server* to the PC. As far as cheap-o ADSL services go, they usually give you a bridge (Westell, Alcatel) which is a completely dumb piece of hardware that just bridges every ethernet frame to the DSLAM and beyond. If that's the case, then you need to listen to whatever some dhcp server behind the ISP's router is handing out (the router is likely set up as a DHCP helper). That's at least how they do it here in Bell Atlantic land... Another thing to note is that somewhere along the line they may be filtering by MAC address and they may have forgot to get that info from you. Here you cannot do a thing until they've stuck your MAC address in the switch that aggregates all the customers together... Good luck, Charles > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > http://www.softweyr.com/~softweyr wes@softweyr.com > > > 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 Jun 27 13:36:30 1999 Delivered-To: freebsd-net@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 6B6BD14DD7 for ; Sun, 27 Jun 1999 13:36:25 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id OAA22034; Sun, 27 Jun 1999 14:36:12 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <37768B3B.6C997C1@softweyr.com> Date: Sun, 27 Jun 1999 14:36:11 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: spork Cc: Tetsuya Watanabe , freebsd-net@FreeBSD.ORG Subject: Re: ADSL question after I searched mail archives and still have questions re DSL References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org spork wrote: > > On Thu, 24 Jun 1999, Wes Peters wrote: > > > Tetsuya Watanabe wrote: > > > FreeBSD doesn't know about the ADSL, it just sees a router. Your "ADSL > > modem" is really an ethernet to ATM router, and should answer the DHCP > > request for you. Doesn't it? > > Probably not. I understand most of the cable modems work that way, but > even the one I've seen still then acts as a DHCP *server* to the PC. Precisely what I expected. > As > far as cheap-o ADSL services go, they usually give you a bridge (Westell, > Alcatel) which is a completely dumb piece of hardware that just bridges > every ethernet frame to the DSLAM and beyond. If that's the case, then > you need to listen to whatever some dhcp server behind the ISP's router is > handing out (the router is likely set up as a DHCP helper). Ugh. I'm only familiar with the USWest service, which uses the NetSpeed (now Cisco) router. Bridging your entire LAN onto the DSL line seems like a pessimal solution. > That's at least how they do it here in Bell Atlantic land... Another > thing to note is that somewhere along the line they may be filtering by > MAC address and they may have forgot to get that info from you. Here you > cannot do a thing until they've stuck your MAC address in the switch that > aggregates all the customers together... Duh. And I'll just bet their customer service people are polite and well-trained, right? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 28 3:18:50 1999 Delivered-To: freebsd-net@freebsd.org Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by hub.freebsd.org (Postfix) with ESMTP id EEB2614E43 for ; Mon, 28 Jun 1999 03:18:40 -0700 (PDT) (envelope-from kbracey@e-14.com) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id LAA27702 for ; Mon, 28 Jun 1999 11:18:38 +0100 (BST) Date: Mon, 28 Jun 1999 11:18:15 +0100 From: Kevin Bracey To: freebsd-net@freebsd.org Subject: Old IP addresses hanging around in routes Message-ID: <5210331949%kbracey@kbracey.acorn.co.uk> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Our systems use a FreeBSD-derived networking stack, which has served us well for many years. However, during testing of some new DHCP client code, I appear to have opened up a can of worms with regard to interface IP addresses referenced in routing table entries. Our particular problem is that if you change the IP address of an interface, you end up with severe communication difficulties. The reason for this is that the routing table is full of references to struct ifaddrs containing our previous IP address - in particular the cloned link-level routes, our default route and any protocol-cloned TCP routes. This is not a FreeBSD-specific problem - it affects all 4.4BSD derivatives, but I'm posting here in the hope that I can find someone knowledgable enough to help work through a solution - comp.protocols.tcp-ip et al are no use whatsoever :) Note that a specific instance of this problem has been reported as kern/2991. -- Kevin Bracey, Senior Software Engineer Pace Micro Technology plc Tel: +44 (0) 1223 725228 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 28 5:16:17 1999 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (wya-lfd72.hotmail.com [207.82.252.136]) by hub.freebsd.org (Postfix) with SMTP id CC8A115413 for ; Mon, 28 Jun 1999 05:15:12 -0700 (PDT) (envelope-from gtsirt@hotmail.com) Received: (qmail 2446 invoked by uid 0); 28 Jun 1999 12:15:12 -0000 Message-ID: <19990628121512.2445.qmail@hotmail.com> Received: from 132.146.249.143 by www.hotmail.com with HTTP; Mon, 28 Jun 1999 05:15:11 PDT X-Originating-IP: [132.146.249.143] From: To: wes@softweyr.com Cc: tetsuya1@prodigy.net, freebsd-net@FreeBSD.ORG Subject: Date: Mon, 28 Jun 1999 05:15:11 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I was looking at prices for DSL modems (Routers and Bridges) and I could not find anything cheaper than 400-500USD! Does anyone know a cheaper source? (on-line preferably...) Thanks George spork wrote: > >On Thu, 24 Jun 1999, Wes Peters wrote: > > > Tetsuya Watanabe wrote: > > > FreeBSD doesn't know about the ADSL, it just sees a router. Your "ADSL > > modem" is really an ethernet to ATM router, and should answer the DHCP > > request for you. Doesn't it? > >Probably not. I understand most of the cable modems work that way, but >even the one I've seen still then acts as a DHCP *server* to the PC. Precisely what I expected. >As >far as cheap-o ADSL services go, they usually give you a bridge (Westell, >Alcatel) which is a completely dumb piece of hardware that just bridges >every ethernet frame to the DSLAM and beyond. If that's the case, then >you need to listen to whatever some dhcp server behind the ISP's router is >handing out (the router is likely set up as a DHCP helper). Ugh. I'm only familiar with the USWest service, which uses the NetSpeed (now Cisco) router. Bridging your entire LAN onto the DSL line seems like a pessimal solution. >That's at least how they do it here in Bell Atlantic land... Another >thing to note is that somewhere along the line they may be filtering by >MAC address and they may have forgot to get that info from you. Here you >cannot do a thing until they've stuck your MAC address in the switch that >aggregates all the customers together... Duh. And I'll just bet their customer service people are polite and well-trained, right? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message ______________________________________________________ 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 Mon Jun 28 7:40:58 1999 Delivered-To: freebsd-net@freebsd.org Received: from retribution.net (retribution.net [207.96.1.17]) by hub.freebsd.org (Postfix) with ESMTP id F105814FC8 for ; Mon, 28 Jun 1999 07:40:56 -0700 (PDT) (envelope-from mjoseff@retribution.net) Received: from retribution.net (retribution.net [207.96.1.17]) by retribution.net (8.9.3/8.9.1) with ESMTP id KAA75125; Mon, 28 Jun 1999 10:42:11 -0500 (EST) Date: Mon, 28 Jun 1999 10:42:11 -0500 (EST) From: Matthew Joseff To: Jim Cassata Cc: FreeBSD Net Subject: Re: frontpage extensions on 3.2 (aaargh!) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 25 Jun 1999, Jim Cassata wrote: }What is the accepted way to get Frontpage 4.0 extensions working on a }3.2 server? I know in the past (Frontpage 3.0 extensions) we }installed the BSDI version on 2.2.x servers, but it seems not to be }working now with FPext4.0 on 3.2. Has anyone gotten any FP extensions }to install?? I *finally* got mine working. I had to copy author.exe and shtml.exe from the fp4.0 directory to the root directory of each web. Also, when you use fpadmin.exe in the fp4.0 "bin" directory, it will modify your apache.conf file with a bunch of "ScriptAlias"es. You have to copy these to each Virtual Host and "apachectl graceful". ScriptAlias /_vti_bin/ /usr/local/www/data/_vti_bin/ ScriptAlias /_vti_bin/_vti_adm/ /usr/local/www/data/_vti_bin/_vti_adm/ ScriptAlias /_vti_bin/_vti_aut/ /usr/local/www/data//_vti_bin/_vti_aut/ etc. .. . -- Matthew Joseff, Sr. Web Developer RCN Corp. 703-321-2410 www.rcn.com NASDAQ: RCNC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 28 9:12:29 1999 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 5D91E1530C for ; Mon, 28 Jun 1999 09:12:22 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id MAA17098; Mon, 28 Jun 1999 12:12:10 -0400 (EDT) (envelope-from wollman) Date: Mon, 28 Jun 1999 12:12:10 -0400 (EDT) From: Garrett Wollman Message-Id: <199906281612.MAA17098@khavrinen.lcs.mit.edu> To: Kevin Bracey Cc: freebsd-net@freebsd.org Subject: Old IP addresses hanging around in routes In-Reply-To: <5210331949%kbracey@kbracey.acorn.co.uk> References: <5210331949%kbracey@kbracey.acorn.co.uk> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Our particular problem is that if you change the IP address of an interface, > you end up with severe communication difficulties. The reason for this is > that the routing table is full of references to struct ifaddrs containing > our previous IP address - in particular the cloned link-level routes, our > default route and any protocol-cloned TCP routes. There is supposed to be code in there to delete all of the (non-static) routes which refer to a specific interface when that interface goes down. At least, I feel fairly certain that I wrote code to do that; I can't seem to find it right now. I think in_ifscrub ought to be doing it, but I don't see the code that would, either there or in rtinit. The cloned-route cleanup in rtrequest(RTM_DELETE,...) ought to take care of it too. You are correct that 4.4BSD did not have any such code. -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 Mon Jun 28 9:34:58 1999 Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 1231914E12 for ; Mon, 28 Jun 1999 09:34:56 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id JAA21042; Mon, 28 Jun 1999 09:34:50 -0700 (PDT) Date: Mon, 28 Jun 1999 09:34:49 -0700 (PDT) From: Julian Elischer To: Kevin Bracey Cc: freebsd-net@FreeBSD.ORG Subject: Re: Old IP addresses hanging around in routes In-Reply-To: <5210331949%kbracey@kbracey.acorn.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I cahcked in a set of changes for this back in 1997 they are in a branch marked "WHISTLE_NET_BRANCH" or something similar. use the CVS web interface to check some of teh files (like if.c) to find the tag and then exctact out the differences.. I have decided that I will resurect those changes some day and apply the m to current.. what they do is: reference count a lot more networking structures. remove all references from routes directly to interfaces (they go via the ifaddrs only) add code to notice when ifaddrs are invalid and remove the reference. (the ifaddr is freed when it's last reference goes away) julian On Mon, 28 Jun 1999, Kevin Bracey wrote: > Our systems use a FreeBSD-derived networking stack, which has served us > well for many years. However, during testing of some new DHCP client code, > I appear to have opened up a can of worms with regard to interface IP > addresses referenced in routing table entries. > > Our particular problem is that if you change the IP address of an interface, > you end up with severe communication difficulties. The reason for this is > that the routing table is full of references to struct ifaddrs containing > our previous IP address - in particular the cloned link-level routes, our > default route and any protocol-cloned TCP routes. > > This is not a FreeBSD-specific problem - it affects all 4.4BSD derivatives, > but I'm posting here in the hope that I can find someone knowledgable enough > to help work through a solution - comp.protocols.tcp-ip et al are no use > whatsoever :) > > Note that a specific instance of this problem has been reported as kern/2991. > > -- > Kevin Bracey, Senior Software Engineer > Pace Micro Technology plc Tel: +44 (0) 1223 725228 > 645 Newmarket Road Fax: +44 (0) 1223 725328 > Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ > > > 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 Mon Jun 28 9:35:34 1999 Delivered-To: freebsd-net@freebsd.org Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by hub.freebsd.org (Postfix) with ESMTP id 103E615303 for ; Mon, 28 Jun 1999 09:35:20 -0700 (PDT) (envelope-from kbracey@e-14.com) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id RAA03412 for ; Mon, 28 Jun 1999 17:35:18 +0100 (BST) Date: Mon, 28 Jun 1999 17:35:02 +0100 From: Kevin Bracey To: freebsd-net@freebsd.org Subject: Re: Old IP addresses hanging around in routes Message-ID: <708f551949%kbracey@kbracey.acorn.co.uk> In-Reply-To: <199906281612.MAA17098@khavrinen.lcs.mit.edu> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199906281612.MAA17098@khavrinen.lcs.mit.edu> Garrett Wollman wrote: > > There is supposed to be code in there to delete all of the > (non-static) routes which refer to a specific interface when that > interface goes down. At least, I feel fairly certain that I wrote > code to do that; I can't seem to find it right now. I think > in_ifscrub ought to be doing it, but I don't see the code that would, > either there or in rtinit. The cloned-route cleanup in > rtrequest(RTM_DELETE,...) ought to take care of it too. The only code that appears to attempt a clean-up is the bit that cleans up protocol-cloned routes. That correctly catches this case: route add default my-router telnet machine.outside.router (TCP clones route) route delete default (cloned route deleted) However, the cases that don't seem to be caught are: A) ifconfig eh0 192.168.0.1 (interface route created) ping 192.168.0.5 (cloned route with ARP info created) ifconfig eh0 192.168.0.2 (old interface route deleted, new one created, cloned route left untouched) ping 192.168.0.5 (doesn't work - outgoing packets have wrong source IP) ping 192.168.0.6 (works ok) B) ifconfig eh0 192.168.0.1 (interface route created) route add default 192.168.1.0 telnet 3.3.3.3 (TCP clones route) ifconfig eh0 192.168.0.2 (default route and cloned route untouched) telnet 3.3.3.3 (doesn't work - local address of connection is 192.168.0.1) ping 4.4.4.4 (doesn't work - outgoing packets have source IP 192.168.0.1) Case (A) is dealt with by Andreyev's code in the kern/2991 bug report. Case (B) is harder. In both cases, the untouched routes contain the old IP address, so in_pcbladdr() and ip_output() both come up with that address for the address of the outgoing interface. I've just had a response from Kevin Rowett , who said (edited): "I ran into exactly the same problem, for the same reason. Added DHCP client to a stack derived from the BSD networking stack. It's a real nightmare to sort out. It required almost as much code as the DHCP client. To be completely safe, I parse the existing route table, delete all the routes, and then re-add them, using the route add mechanism." Which is a solution of sorts, but the kernel really should be able to figure this out for itself. Maybe whenever an interface route is removed, the routing table can be searched for entries referencing that ifaddr, and those ifaddr pointers could be set to NULL. Future routing lookups could then spot NULL pointers and figure out the interface anew. I'm not sure if that's practical. -- Kevin Bracey, Senior Software Engineer Pace Micro Technology plc Tel: +44 (0) 1223 725228 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 28 16:10:37 1999 Delivered-To: freebsd-net@freebsd.org Received: from mail0.index.com.jo (mail0.index.com.jo [212.38.128.13]) by hub.freebsd.org (Postfix) with ESMTP id 2E82715341 for ; Mon, 28 Jun 1999 16:10:11 -0700 (PDT) (envelope-from rsodah@index.com.jo) Received: from index.com.jo ([212.38.128.140]) by mail0.index.com.jo (Netscape Messaging Server 3.62) with ESMTP id 454 for ; Tue, 29 Jun 1999 01:07:22 +0200 Message-ID: <37787EE8.9A37E767@index.com.jo> Date: Tue, 29 Jun 1999 01:08:08 -0700 From: "Rami Soudah" X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Subject: ping Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greetings I made my BSD box so that it dials to my ISP, at the moment I have 1 Win computer connected to the BSD box, like the following: ISP <-----modem--->BSD (earth) | Win (metro) WIN-Hostname = metro = 192.168.0.2 BSD-Hostname = earth = 192.168.0.1 I configured the BSD as Gateway for my Win box. I was able to dial-up from the BSD and browse via netscape at both machienes... etc :-) To verify the above, I did ping but I recorded one strange behaviour: I could ping 'earth' 'metro' and 'localhost' from the BSD box, and and I did the same at Win box, I was able to ping 'earth' 'localhost' from the Win box without having any troubles, but _not_ 'metro'. c:\windows>ping metro Pinging metro [4.0.0.3] with 32 bytes of data: Reply from 192.168.0.1: Destination host unreachable. Reply from 192.168.0.1: Destination host unreachable. Reply from 192.168.0.1: Destination host unreachable. Reply from 192.168.0.1: Destination host unreachable. Ping statistics for 4.0.0.3: Packets: Sent 4, Received = 4 ... bla bla blaaa *) I was wondering from where 4.0.0.3 comes?? *) Why I keep getting 'Reply from 192.168.0.1'? i am not pinging 192.168.0.1 it should be 192.168.0.2. What could be wrong? my /etc/hosts (BSD) 127.0.0.1 localhost 192.168.0.1 earth earth.my.domain 192.168.0.2 metro metro.my.domain c:\windows\hosts (Win) 127.0.0.1 localhost 192.168.0.1 earth earth.my.domain 192.168.0.2 metro metro.my.domain Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 127.0.0.1 127.0.0.1 UH 0 30 lo0 192.168 link#1 UC 0 0 ed1 192.168.0.1 0:c0:df:e6:7b:51 UHLW 0 100 lo0 192.168.0.2 0:0:e8:61:2:39 UHLW 2 2536 ed1 1188 192.168.0.255 ff:ff:ff:ff:ff:ff UHLWb 2 154 ed1 bash-2.02$ Thanks in advance. -Pons P.S. If I ping the IP's I dont have any troubles in both machines. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 28 16:16:43 1999 Delivered-To: freebsd-net@freebsd.org Received: from mu.egroups.com (mu.egroups.com [207.138.41.151]) by hub.freebsd.org (Postfix) with SMTP id 346FD15483 for ; Mon, 28 Jun 1999 16:16:41 -0700 (PDT) (envelope-from maillist@xinetron.com) Received: from [10.1.1.19] by mu.egroups.com with NNFMP; 29 Jun 1999 00:16:42 -0000 Date: Mon, 28 Jun 1999 16:16:37 -0700 From: maillist@xinetron.com To: freebsd-net@freebsd.org Subject: Frame Relay Driver? Message-ID: <7l8vol$nbqe@eGroups.com> User-Agent: eGroups-EW/0.73 Content-Length: 460 X-Mailer: www.eGroups.com Message Poster Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Group, Is there any "traditional" frame relay driver available for FreeBSD. I know that NetGraph supports frame relay, but I am really not ready to bring in an entire new network architecture just to support Frame Relay. I am looking for some "traditional" driver for frame relay, like those used with ETinc sync cards. Does the ET cards come with driver source code? Is there any DLCI device driver like that in Linux (dlci and dlcicfg)? TIA, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 28 18:39: 5 1999 Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id B5FC214E29 for ; Mon, 28 Jun 1999 18:39:03 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id SAA52269; Mon, 28 Jun 1999 18:39:01 -0700 (PDT) Date: Mon, 28 Jun 1999 18:39:00 -0700 (PDT) From: Julian Elischer To: maillist@xinetron.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: Frame Relay Driver? In-Reply-To: <7l8vol$nbqe@eGroups.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 Netgraph isn't as big a deal as you think.. (though it may not compile on 4.0 at the moment as we've been busy and other things have been changed since we last di an update) On Mon, 28 Jun 1999 maillist@xinetron.com wrote: > Hi Group, > > Is there any "traditional" frame relay driver available for FreeBSD. I know that NetGraph supports frame relay, but I am really not ready to bring in an entire new network architecture just to support Frame Relay. I am looking for some "traditional" driver for frame relay, like those used with ETinc sync cards. Does the ET cards come with driver source code? Is there any DLCI device driver like that in Linux (dlci and dlcicfg)? > > TIA, > > Jeff > > > > > 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 Mon Jun 28 19:25:27 1999 Delivered-To: freebsd-net@freebsd.org Received: from rip.ops.neosoft.com (rip.ops.NeoSoft.COM [206.109.4.20]) by hub.freebsd.org (Postfix) with ESMTP id F07E714C23 for ; Mon, 28 Jun 1999 19:25:21 -0700 (PDT) (envelope-from awsmith@rip.ops.neosoft.com) Received: (from awsmith@localhost) by rip.ops.neosoft.com (8.9.2/8.9.1) id VAA14735 for freebsd-net@freebsd.org; Mon, 28 Jun 1999 21:24:47 -0500 (CDT) (envelope-from awsmith) From: "Andrew W. Smith" Message-Id: <199906290224.VAA14735@rip.ops.neosoft.com> Subject: 16 bit int for interface "reference count" To: freebsd-net@freebsd.org Date: Mon, 28 Jun 1999 21:24:47 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From the NANOG list ... has this been patched in FreeBSD before I again start pumping a full table into one of my boxen? --------------- Date: Mon, 28 Jun 1999 09:29:50 +0100 From: Peter Galbavy Subject: Re: The Cidr Report On the subject of the general number of routes increasing, has everyone involved in the development or maintainence of their routers checked that the 2^16 (65536) limit is not going to hit them. I know that for those using PC routers, like my old colleagues at Demon, it is important that you make sure that your OS is upgraded to use a >16 bit int for a "reference count" to an interface. Andrew Bangs @ Demon spotted this a while back and submitted patch to the *BSD groups, of which I know OpenBSD has changed the reference count to a 32 bit. Once you add some IGP routes the 2^16 is coming up fast. On Fri, Jun 25, 1999 at 12:00:02PM -0700, Tony Bates wrote: > 0) General Status > > Table History > ------------- > > Date Prefixes > 180699 60164 > 190699 60219 > 200699 60266 > 210699 60373 > 220699 60763 > 230699 60904 > 240699 61044 > 250699 61068 - -- Peter Galbavy Knowledge Matters Ltd http://www.knowledge.com/ ---------- --------------------------------------------------------------------------- ** Andrew W. Smith ** awsmith@neosoft.com ** Chief Network Engineer ** ** http://www.neosoft.com/neosoft/staff/andrew ** 1-888-NEOSOFT ** ** "Opportunities multiply as they are seized" - Sun Tzu ** --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 28 22: 7: 4 1999 Delivered-To: freebsd-net@freebsd.org Received: from tch.org (tacostand.tch.org [199.74.220.9]) by hub.freebsd.org (Postfix) with ESMTP id CFF5F15186 for ; Mon, 28 Jun 1999 22:07:00 -0700 (PDT) (envelope-from ser@tch.org) Received: (from ser@localhost) by tch.org (8.9.1/8.9.1) id WAA16072; Mon, 28 Jun 1999 22:06:56 -0700 (PDT) (envelope-from ser) Date: Mon, 28 Jun 1999 22:06:56 -0700 From: Steve Rubin To: "Andrew W. Smith" Cc: freebsd-net@FreeBSD.ORG Subject: Re: 16 bit int for interface "reference count" Message-ID: <19990628220656.B15990@tch.org> References: <199906290224.VAA14735@rip.ops.neosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199906290224.VAA14735@rip.ops.neosoft.com>; from Andrew W. Smith on Mon, Jun 28, 1999 at 09:24:47PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org main() { printf("%d\n",sizeof(int)); } tacostand: {136} % ./foo 4 On Mon, Jun 28, 1999 at 09:24:47PM -0500, Andrew W. Smith wrote: > > >From the NANOG list ... has this been patched in FreeBSD before > I again start pumping a full table into one of my boxen? > > --------------- > > Date: Mon, 28 Jun 1999 09:29:50 +0100 > From: Peter Galbavy > Subject: Re: The Cidr Report > > On the subject of the general number of routes increasing, has > everyone involved in the development or maintainence of their routers > checked that the 2^16 (65536) limit is not going to hit them. > > I know that for those using PC routers, like my old colleagues at > Demon, it is important that you make sure that your OS is upgraded > to use a >16 bit int for a "reference count" to an interface. Andrew > Bangs @ Demon spotted this a while back and submitted patch to the > *BSD groups, of which I know OpenBSD has changed the reference count > to a 32 bit. > > Once you add some IGP routes the 2^16 is coming up fast. > > On Fri, Jun 25, 1999 at 12:00:02PM -0700, Tony Bates wrote: > > 0) General Status > > > > Table History > > ------------- > > > > Date Prefixes > > 180699 60164 > > 190699 60219 > > 200699 60266 > > 210699 60373 > > 220699 60763 > > 230699 60904 > > 240699 61044 > > 250699 61068 > > - -- > Peter Galbavy > Knowledge Matters Ltd > http://www.knowledge.com/ > > ---------- > > --------------------------------------------------------------------------- > ** Andrew W. Smith ** awsmith@neosoft.com ** Chief Network Engineer ** > ** http://www.neosoft.com/neosoft/staff/andrew ** 1-888-NEOSOFT ** > ** "Opportunities multiply as they are seized" - Sun Tzu ** > --------------------------------------------------------------------------- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Steve Rubin - ser@tch.org - http://www.tch.org/~ser/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 28 22:39: 9 1999 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 2635215193 for ; Mon, 28 Jun 1999 22:39:04 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id WAA11089; Mon, 28 Jun 1999 22:36:57 -0700 (PDT) Message-Id: <199906290536.WAA11089@implode.root.com> To: "Andrew W. Smith" Cc: freebsd-net@FreeBSD.ORG Subject: Re: 16 bit int for interface "reference count" In-reply-to: Your message of "Mon, 28 Jun 1999 21:24:47 CDT." <199906290224.VAA14735@rip.ops.neosoft.com> From: David Greenman Reply-To: dg@root.com Date: Mon, 28 Jun 1999 22:36:57 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>From the NANOG list ... has this been patched in FreeBSD before >I again start pumping a full table into one of my boxen? > >--------------- > >Date: Mon, 28 Jun 1999 09:29:50 +0100 >From: Peter Galbavy >Subject: Re: The Cidr Report > >On the subject of the general number of routes increasing, has >everyone involved in the development or maintainence of their routers >checked that the 2^16 (65536) limit is not going to hit them. > >I know that for those using PC routers, like my old colleagues at >Demon, it is important that you make sure that your OS is upgraded >to use a >16 bit int for a "reference count" to an interface. Andrew >Bangs @ Demon spotted this a while back and submitted patch to the >*BSD groups, of which I know OpenBSD has changed the reference count >to a 32 bit. > >Once you add some IGP routes the 2^16 is coming up fast. It's hard to say if the 16bit refcnt will a real problem for Internet routers. It might be if there is a default route, but routes don't normally hold references to other routes. This is coming close to being an issue on wcarchive, however, as it has a large number of TCP connections (and each one holds a reference). In any case, it is currently 16bits in FreeBSD and should be increased to 32bits. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 29 6:54:37 1999 Delivered-To: freebsd-net@freebsd.org Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 61CA314DB9 for ; Tue, 29 Jun 1999 06:54:34 -0700 (PDT) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.9.3/8.9.3) with SMTP id JAA18454; Tue, 29 Jun 1999 09:50:16 -0400 (EDT) Message-Id: <199906291350.JAA18454@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 29 Jun 1999 08:46:44 -0400 To: maillist@xinetron.com From: Dennis Subject: Re: Frame Relay Driver? Cc: freebsd-net@freebsd.org In-Reply-To: <7l8vol$nbqe@eGroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 04:16 PM 6/28/99 -0700, you wrote: >Hi Group, > >Is there any "traditional" frame relay driver available for FreeBSD. I know that NetGraph supports frame relay, but I am really not ready to bring in an entire new network architecture just to support Frame Relay. I am looking for some "traditional" driver for frame relay, like those used with ETinc sync cards. Does the ET cards come with driver source code? Is there any DLCI device driver like that in Linux (dlci and dlcicfg)? What is "traditional"? The DLCI driver for linux is more of a kludge than a frame relay protocol driver. There are different philosophies for implementing protocols, ours is to make is as transparent (and painless) as possible for the user without sacrificing functionality. Unfortunately the most common frame relay switch available (cascades) are very much broken, so its a lot of fun supporting frame. Dennis Emerging Technologies, Inc. http://www.etinc.com ISA and PCI T1/T3/V35/HSSI Cards for FreeBSD and LINUX HSSI/T3 UNIX-based Routers Bandwidth Manager http://www.etinc.com/bwmgr.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 29 7:30:35 1999 Delivered-To: freebsd-net@freebsd.org Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by hub.freebsd.org (Postfix) with ESMTP id 4A72314E12 for ; Tue, 29 Jun 1999 07:30:10 -0700 (PDT) (envelope-from kbracey@e-14.com) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id PAA15405 for ; Tue, 29 Jun 1999 15:30:07 +0100 (BST) Date: Tue, 29 Jun 1999 15:29:58 +0100 From: Kevin Bracey To: freebsd-net@freebsd.org Subject: Re: Old IP addresses hanging around in routes Message-ID: In-Reply-To: X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Julian Elischer wrote: > I cahcked in a set of changes for this back in 1997 > they are in a branch marked "WHISTLE_NET_BRANCH" or something similar. > > use the CVS web interface to check some of teh files (like if.c) > to find the tag and then exctact out the differences.. > I have decided that I will resurect those changes some day and apply the m > to current.. > what they do is: > > reference count a lot more networking structures. > remove all references from routes directly to interfaces (they go via the > ifaddrs only) > > add code to notice when ifaddrs are invalid and remove the reference. > (the ifaddr is freed when it's last reference goes away) > I've had a little look at this. It seems a little severe - if I understand it correctly then any static routes through an interface will be totally deleted if that interface route is deleted. Is this interpretation correct? -- Kevin Bracey, Senior Software Engineer Pace Micro Technology plc Tel: +44 (0) 1223 725228 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 29 8:20:30 1999 Delivered-To: freebsd-net@freebsd.org Received: from enst.enst.fr (enst.enst.fr [137.194.2.16]) by hub.freebsd.org (Postfix) with ESMTP id DF7BF14E12 for ; Tue, 29 Jun 1999 08:20:25 -0700 (PDT) (envelope-from beyssac@enst.fr) Received: from bofh.enst.fr (bofh-2.enst.fr [137.194.2.37]) by enst.enst.fr (8.9.1a/8.9.1) with ESMTP id RAA07990; Tue, 29 Jun 1999 17:20:00 +0200 (MET DST) Received: by bofh.enst.fr (Postfix, from userid 12426) id A38A3D21A; Tue, 29 Jun 1999 17:19:59 +0200 (CEST) Message-ID: <19990629171959.A87648@enst.fr> Date: Tue, 29 Jun 1999 17:19:59 +0200 From: Pierre Beyssac To: dg@root.com, "Andrew W. Smith" Cc: freebsd-net@FreeBSD.ORG Subject: Re: 16 bit int for interface "reference count" References: <199906290224.VAA14735@rip.ops.neosoft.com> <199906290536.WAA11089@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199906290536.WAA11089@implode.root.com>; from David Greenman on Mon, Jun 28, 1999 at 10:36:57PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jun 28, 1999 at 10:36:57PM -0700, David Greenman wrote: > on wcarchive, however, as it has a large number of TCP connections (and > each one holds a reference). In any case, it is currently 16bits in > FreeBSD and should be increased to 32bits. It's been changed to 32 bits a while ago (shortly after 3.2-RELEASE), both on -current and -stable. Anyway the fix is pretty trivial if anyone using 3.2 or before is affected: you apparently just need to recompile a kernel. revision 1.13 date: 1999/05/16 17:09:20; author: pb; state: Exp; lines: +2 -2 PR: kern/10570 Submitted by: adrian@freebsd.org Change reference count in struct ifaddr to a u_int, to be able to handle more than 2^16 routes to the same interface. Fix suggested by Andrew Bangs in PR kern/10570. Tested by and me under -current. -- Pierre Beyssac pb@enst.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 29 9:19:45 1999 Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id EBA2615267 for ; Tue, 29 Jun 1999 09:19:42 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id JAA72335; Tue, 29 Jun 1999 09:19:39 -0700 (PDT) Date: Tue, 29 Jun 1999 09:19:38 -0700 (PDT) From: Julian Elischer To: Kevin Bracey Cc: freebsd-net@FreeBSD.ORG Subject: Re: Old IP addresses hanging around in routes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org well yes, if you delete an interface, why would you keep a route that points through it? You want to re-evaluate that route next time you try to reach that destination. These changes are aimed evemtially at making interfaced dynamic. (e.g. if you add a frame relay circuit, it will gnerate a new interface to represent that circuit, but if you turn off that PVC, you cannot at the moment EVER delete that interface again, because there may be (an unknown number of) routes floating out there on sockets, that will reference that interface.) your problems are a subset of this problem You want On Tue, 29 Jun 1999, Kevin Bracey wrote: > In message > Julian Elischer wrote: > > > I checked in a set of changes for this back in 1997 > > they are in a branch marked "WHISTLE_NET_BRANCH" or something similar. > > > > use the CVS web interface to check some of teh files (like if.c) > > to find the tag and then exctact out the differences.. > > I have decided that I will resurect those changes some day and apply the m > > to current.. > > what they do is: > > > > reference count a lot more networking structures. > > remove all references from routes directly to interfaces (they go via the > > ifaddrs only) > > > > add code to notice when ifaddrs are invalid and remove the reference. > > (the ifaddr is freed when it's last reference goes away) > > > > I've had a little look at this. It seems a little severe - if I understand > it correctly then any static routes through an interface will be totally > deleted if that interface route is deleted. Is this interpretation correct? > > -- > Kevin Bracey, Senior Software Engineer > Pace Micro Technology plc Tel: +44 (0) 1223 725228 > 645 Newmarket Road Fax: +44 (0) 1223 725328 > Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 29 9:26: 2 1999 Delivered-To: freebsd-net@freebsd.org Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by hub.freebsd.org (Postfix) with ESMTP id 50DFA152DA for ; Tue, 29 Jun 1999 09:25:56 -0700 (PDT) (envelope-from kbracey@e-14.com) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id RAA16994 for ; Tue, 29 Jun 1999 17:25:53 +0100 (BST) Date: Tue, 29 Jun 1999 17:26:06 +0100 From: Kevin Bracey To: freebsd-net@freebsd.org Subject: Re: Old IP addresses hanging around in routes Message-ID: In-Reply-To: X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Julian Elischer wrote: > well yes, > > if you delete an interface, why would you keep a route that points > through it? You want to re-evaluate that route next time you try to reach > that destination. These changes are aimed evemtially at making interfaced > dynamic. I may have misunderstood. In the case where you do something like: ifconfig eh0 10.0.4.1 route add default 10.0.0.1 ifconfig eh0 10.0.4.2 your change would remove the default route outright, as I read it. It certainly needs to be reevaluated as to how we actually get to 10.0.0.1 following the reconfiguration of the interface route, but should we remove the default route altogether? -- Kevin Bracey, Senior Software Engineer Pace Micro Technology plc Tel: +44 (0) 1223 725228 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 29 9:34:10 1999 Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 77C8615378 for ; Tue, 29 Jun 1999 09:34:07 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id JAA73189; Tue, 29 Jun 1999 09:34:03 -0700 (PDT) Date: Tue, 29 Jun 1999 09:34:02 -0700 (PDT) From: Julian Elischer To: Kevin Bracey Cc: freebsd-net@FreeBSD.ORG Subject: Re: Old IP addresses hanging around in routes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org you have a point and I admit that I can't remember exactly what I do in this case. what about: ifconfig eh0 10.0.4.1 route add default 10.0.0.1 ifconfig eh0 down delete now what about the default route? On Tue, 29 Jun 1999, Kevin Bracey wrote: > In message > Julian Elischer wrote: > > > well yes, > > > > if you delete an interface, why would you keep a route that points > > through it? You want to re-evaluate that route next time you try to reach > > that destination. These changes are aimed evemtially at making interfaced > > dynamic. > > I may have misunderstood. In the case where you do something like: > > ifconfig eh0 10.0.4.1 > route add default 10.0.0.1 > ifconfig eh0 10.0.4.2 > > your change would remove the default route outright, as I read it. It > certainly needs to be reevaluated as to how we actually get to 10.0.0.1 > following the reconfiguration of the interface route, but should we remove > the default route altogether? > > -- > Kevin Bracey, Senior Software Engineer > Pace Micro Technology plc Tel: +44 (0) 1223 725228 > 645 Newmarket Road Fax: +44 (0) 1223 725328 > Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 29 9:41:26 1999 Delivered-To: freebsd-net@freebsd.org Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by hub.freebsd.org (Postfix) with ESMTP id 45899154C3 for ; Tue, 29 Jun 1999 09:41:15 -0700 (PDT) (envelope-from kbracey@e-14.com) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id RAA17090 for ; Tue, 29 Jun 1999 17:41:02 +0100 (BST) Date: Tue, 29 Jun 1999 17:41:00 +0100 From: Kevin Bracey To: freebsd-net@freebsd.org Subject: Re: Old IP addresses hanging around in routes Message-ID: <4cf1d91949%kbracey@kbracey.acorn.co.uk> In-Reply-To: X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Julian Elischer wrote: > you have a point and I admit that I can't remember exactly what I do in > this case. what about: > > ifconfig eh0 10.0.4.1 > route add default 10.0.0.1 > ifconfig eh0 down delete > > now what about the default route? > Still through 10.0.0.1, in the absence of any other information. If the interface comes back up, it will still be there. When we come to use the route with the interface down, we will find that we can't actually get to 10.0.0.1 so will have to back out. How this would be implemented is less clear. What did 4.3BSD do in this case? -- Kevin Bracey, Senior Software Engineer Pace Micro Technology plc Tel: +44 (0) 1223 725228 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 29 9:51:52 1999 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id A4D6314EDA for ; Tue, 29 Jun 1999 09:51:25 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id JAA12174; Tue, 29 Jun 1999 09:48:44 -0700 (PDT) Message-Id: <199906291648.JAA12174@implode.root.com> To: Pierre Beyssac Cc: "Andrew W. Smith" , freebsd-net@FreeBSD.ORG Subject: Re: 16 bit int for interface "reference count" In-reply-to: Your message of "Tue, 29 Jun 1999 17:19:59 +0200." <19990629171959.A87648@enst.fr> From: David Greenman Reply-To: dg@root.com Date: Tue, 29 Jun 1999 09:48:44 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >On Mon, Jun 28, 1999 at 10:36:57PM -0700, David Greenman wrote: >> on wcarchive, however, as it has a large number of TCP connections (and >> each one holds a reference). In any case, it is currently 16bits in >> FreeBSD and should be increased to 32bits. > >It's been changed to 32 bits a while ago (shortly after 3.2-RELEASE), >both on -current and -stable. > >Anyway the fix is pretty trivial if anyone using 3.2 or before is >affected: you apparently just need to recompile a kernel. > >revision 1.13 >date: 1999/05/16 17:09:20; author: pb; state: Exp; lines: +2 -2 >PR: kern/10570 >Submitted by: adrian@freebsd.org > >Change reference count in struct ifaddr to a u_int, to be able >to handle more than 2^16 routes to the same interface. > >Fix suggested by Andrew Bangs in PR kern/10570. >Tested by and me under -current. Actually, I was looking at the rt_refcnt element in struct rtentry which is still 16 bits. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 29 14:16:15 1999 Delivered-To: freebsd-net@freebsd.org Received: from mu.egroups.com (mu.egroups.com [207.138.41.151]) by hub.freebsd.org (Postfix) with SMTP id 0B87F14F92 for ; Tue, 29 Jun 1999 14:16:11 -0700 (PDT) (envelope-from maillist@xinetron.com) Received: from [10.1.2.25] by mu.egroups.com with NNFMP; 29 Jun 1999 22:16:10 -0000 Date: Tue, 29 Jun 1999 14:16:04 -0700 From: maillist@xinetron.com To: freebsd-net@freebsd.org Subject: Re: Frame Relay Driver? Message-ID: <7lbd2k$ni4f@eGroups.com> In-Reply-To: <199906291350.JAA18454@etinc.com> User-Agent: eGroups-EW/0.73 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Length: 1202 X-Mailer: www.eGroups.com Message Poster Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks for the info. I looked at the if_cx.c and cx.c code. It seems that= Frame Relay (RFC1490) is handled by the card hardware, or did I miss someth= ing? Dennis, does the ET card handle the Frame Relay protocol in hardware or in = driver? Is the driver open-source? Thanks again. --Jeff Subject: Re: Frame Relay Driver? Date: Tue, 29 Jun 1999 12:46:44 +0700 (OSS) From: Eugeny Kuzakov Organization: CoreDumped Technologies Ltd. To: maillist@xinetron.com =F7=D9 =D0=C9=D3=C1=CC=C9: Look into cx driver. This cards works with frame relay too. Latest drivers avaiable from ftp.cronyx.ru. > Hi Group, > Is there any "traditional" frame relay driver available for FreeBSD. I k= now that NetGraph supports frame relay, but I am really not ready to bring in a= n entire new network architecture just to support Frame Relay. I am looking = for some "traditional" driver for frame relay, like those used with ETinc sync cards. Does the ET cards come with driver source code? Is there any DLCI device driver like that in Linux (dlci and dlcicfg)? > TIA, > Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 29 17:10:41 1999 Delivered-To: freebsd-net@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id A7DA9151C7 for ; Tue, 29 Jun 1999 17:10:39 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id RAA14507; Tue, 29 Jun 1999 17:10:15 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id RAA03493; Tue, 29 Jun 1999 17:10:14 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA17397; Tue, 29 Jun 99 17:10:13 PDT Message-Id: <37796062.63879A32@softweyr.com> Date: Tue, 29 Jun 1999 18:10:10 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Kevin Bracey Cc: freebsd-net@FreeBSD.ORG Subject: Re: Old IP addresses hanging around in routes References: <4cf1d91949%kbracey@kbracey.acorn.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kevin Bracey wrote: > > In message > Julian Elischer wrote: > > > you have a point and I admit that I can't remember exactly what I do in > > this case. what about: > > > > ifconfig eh0 10.0.4.1 > > route add default 10.0.0.1 > > ifconfig eh0 down delete > > > > now what about the default route? > > > > Still through 10.0.0.1, in the absence of any other information. If the > interface comes back up, it will still be there. When we come to use the > route with the interface down, we will find that we can't actually get to > 10.0.0.1 so will have to back out. How this would be implemented is less > clear. > > What did 4.3BSD do in this case? 4.2BSD retained a pointer in the routing table to an ifnet structure that was no longer there. Ugh. I haven't looked at the 4.3 code, but this problem gets really ugly in the face of the example given above. You CANNOT keep the route, because the route has to refer to either an interface or an address, and if the address or interface doesn't exist anymore, the route cannot continue to exist. The moral of the story is to use a routing daemon. The other moral of the story is that routing daemons are evil, and difficult to configure properly. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 29 17:43:45 1999 Delivered-To: freebsd-net@freebsd.org Received: from ns1.elpn.com (ns1.elpn.com [209.194.74.2]) by hub.freebsd.org (Postfix) with ESMTP id 0578E151C9 for ; Tue, 29 Jun 1999 17:43:43 -0700 (PDT) (envelope-from rosteen@elpn.com) Received: from elpn.com (cox.com [206.98.143.200]) by ns1.elpn.com (8.8.8/8.8.8) with ESMTP id SAA20560 for ; Tue, 29 Jun 1999 18:48:34 -0600 (MDT) (envelope-from rosteen@elpn.com) Message-ID: <3779680A.E03D1F26@elpn.com> Date: Tue, 29 Jun 1999 20:42:50 -0400 From: rosteen Reply-To: rosteen@elpn.com X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: version 3.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Has anyone installed this version OS onto a multi-processor server? If so, what are the gotcha's and does it run stable? Thanks for any help, Rick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 30 4:32:31 1999 Delivered-To: freebsd-net@freebsd.org Received: from main.piter.net (main.piter.net [195.201.22.10]) by hub.freebsd.org (Postfix) with ESMTP id D702114C91 for ; Wed, 30 Jun 1999 04:32:26 -0700 (PDT) (envelope-from cyril@main.piter.net) Received: (from cyril@localhost) by main.piter.net (8.9.3/8.5.2/sply) id PAA06099; Wed, 30 Jun 1999 15:34:11 +0400 (MSD) Date: Wed, 30 Jun 1999 15:34:11 +0400 (MSD) From: "Cyril A. Vechera" Message-Id: <199906301134.PAA06099@main.piter.net> To: freebsd-net@FreeBSD.ORG, maillist@xinetron.com Subject: Re: Frame Relay Driver? Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > From owner-freebsd-net@FreeBSD.ORG Wed Jun 30 01:19:21 1999 > Date: Tue, 29 Jun 1999 14:16:04 -0700 > From: maillist@xinetron.com > To: freebsd-net@FreeBSD.ORG > Subject: Re: Frame Relay Driver? > > Thanks for the info. I looked at the if_cx.c and cx.c code. > It seems that Frame Relay (RFC1490) is handled by the card hardware, > or did I miss something? Not hardware level, it handles frame relay on the driver layer. Sincerely your, Cyril A. Vechera email:cyril@piter.net --------- http://sply.piter.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 30 20:46:59 1999 Delivered-To: freebsd-net@freebsd.org Received: from public1.ptt.js.cn (unknown [202.102.13.144]) by hub.freebsd.org (Postfix) with ESMTP id 2A7FC14CBE; Wed, 30 Jun 1999 20:45:21 -0700 (PDT) (envelope-from witman@iname.com) Received: from heart (tnt3-66-215.nj.js.cn [202.102.66.215]) by public1.ptt.js.cn (8.9.1/8.9.1) with SMTP id KAA19052; Thu, 1 Jul 1999 10:41:53 +0800 (CST) Message-ID: <000101bec374$30e06eb0$010000c8@heart.witman.com> From: "Witman Peng" To: Cc: Subject: IP reassemble fails if it contains more that 20 bytes options? Date: Thu, 1 Jul 1999 11:42:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, All I am developing an application based on 4.4BSD-Lite source code. When I port the code in file netinet/ip_input.c, I found a problem. But I have no chance to install FreeBSD and test it, so I am not sure whether it'a bug or not. The following are the code to reassemble the IP fragments from ip_input.c: From routine ipintr: if (ip->ip_off &~ IP_DF) { if (m->m_flags & M_EXT) { /* XXX */ if ((m = m_pullup(m, sizeof (struct ip))) == 0) { ipstat.ips_toosmall++; goto next; } ip = mtod(m, struct ip *); } From routine ip_reass: int hlen = ip->ip_hl << 2; int i, next; m->m_data += hlen; m->m_len -= hlen; Suppose a fragment with more that 208 bytes and 40 bytes IP option, it will be stored in the cluster but not mbuf. In routine ipintr, function pullup just pullup sizeof(struct ip) (maybe 40 bytes for tcp header) bytes into a new mbuf. However, the IP header is 60 (20 + 40) bytes, so the complete IP header cannot be stored in this mbuf. Then in routine ip_reass, after run the above code, m->m_data will pointer to an incorrect address. Dose it seems right? Any inputs would be apprecaited. BR, Witman Peng To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 1 7:41:27 1999 Delivered-To: freebsd-net@freebsd.org Received: from babelbrox.axion.bt.co.uk (babelbrox.axion.bt.co.uk [132.146.16.6]) by hub.freebsd.org (Postfix) with ESMTP id E585C14CA4 for ; Thu, 1 Jul 1999 07:41:22 -0700 (PDT) (envelope-from graeme.n.brown@bt.com) Received: from cbtlipnt02.btlabs.bt.co.uk by babelbrox.axion.bt.co.uk (local) with ESMTP; Thu, 1 Jul 1999 15:40:58 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2448.0) id ; Thu, 1 Jul 1999 15:40:49 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A9402B5A24C@mbtlipnt01.btlabs.bt.co.uk> From: graeme.n.brown@bt.com To: freebsd-net@freebsd.org Subject: debug print out from the kernel under FreeBSD-3.2 Date: Thu, 1 Jul 1999 15:40:43 +0100 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Folks Has the means/configuration to print debug messages from kernel code to the console or to system log file changed since FreeBSD-2.2.x ? I am trying to debug a modified version of netinet/ip_mroute.c with support for Core Based Trees multicast forwarding. Under FreeBSD 2.2.x I used log(LOG_DEBUG, "debug message....") ; or printf( ... ) ; Trying the same on a FreeBSD-3.2 kernel, I do not get any debug messages printed on console or in system log ( var/log/messages). Has something changed since FreeBSD-2.2.x that I may not be ware of ? Can anyone suggest what I may have overlooked ? TIA Graeme N Brown BT Adastral Park, UK email: graeme.n.brown@bt.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 1 8: 2:47 1999 Delivered-To: freebsd-net@freebsd.org Received: from ausmail2.austin.ibm.com (ausmail2.austin.ibm.com [192.35.232.11]) by hub.freebsd.org (Postfix) with ESMTP id 877BB14D50 for ; Thu, 1 Jul 1999 08:02:40 -0700 (PDT) (envelope-from venkats@austin.ibm.com) Received: from netmail.austin.ibm.com (netmail.austin.ibm.com [9.53.250.98]) by ausmail2.austin.ibm.com (8.9.1/8.8.5) with ESMTP id JAA74388 for ; Thu, 1 Jul 1999 09:58:42 -0500 Received: from ambika.austin.ibm.com (ambika.austin.ibm.com [9.53.150.77]) by netmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id KAA42930; Thu, 1 Jul 1999 10:02:38 -0500 Received: from austin.ibm.com (localhost.austin.ibm.com [127.0.0.1]) by ambika.austin.ibm.com (AIX4.3/UCB 8.8.8/8.7-client1.01) with ESMTP id KAA21874; Thu, 1 Jul 1999 10:02:37 -0500 Message-ID: <377B830C.EE4A82E7@austin.ibm.com> Date: Thu, 01 Jul 1999 10:02:36 -0500 From: venkat venkatsubra Organization: IBM X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.3) MIME-Version: 1.0 To: Witman Peng Cc: freebsd-net@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: IP reassemble fails if it contains more that 20 bytes options? References: <000101bec374$30e06eb0$010000c8@heart.witman.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Witman, Isn't this taken care of early in ipintr ? -------------------------- if (hlen > m->m_len) { if ((m = m_pullup(m, hlen)) == 0) { ipstat.ips_badhlen++; goto next; } ip = mtod(m, struct ip *); } --------------------------- Venkat Witman Peng wrote: > Hi, All > > I am developing an application based on 4.4BSD-Lite source code. When I port > the code in file netinet/ip_input.c, I found a problem. But I have no chance > to install FreeBSD and test it, so I am not sure whether it'a bug or not. > The following are the code to reassemble the IP fragments from ip_input.c: > > >From routine ipintr: > if (ip->ip_off &~ IP_DF) { > if (m->m_flags & M_EXT) { /* XXX */ > if ((m = m_pullup(m, sizeof (struct ip))) == 0) { > ipstat.ips_toosmall++; > goto next; > } > ip = mtod(m, struct ip *); > } > > >From routine ip_reass: > int hlen = ip->ip_hl << 2; > int i, next; > > m->m_data += hlen; > m->m_len -= hlen; > > Suppose a fragment with more that 208 bytes and 40 bytes IP option, it will > be stored in the cluster but not mbuf. In routine ipintr, function pullup > just pullup sizeof(struct ip) (maybe 40 bytes for tcp header) bytes into a > new mbuf. However, the IP header is 60 (20 + 40) bytes, so the complete IP > header cannot be stored in this mbuf. Then in routine ip_reass, after run > the above code, m->m_data will pointer to an incorrect address. > > Dose it seems right? Any inputs would be apprecaited. > > BR, > Witman Peng > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 1 8:39:23 1999 Delivered-To: freebsd-net@freebsd.org Received: from dpx20.tu-varna.acad.bg (unknown [194.12.234.4]) by hub.freebsd.org (Postfix) with ESMTP id F1D1E14C11 for ; Thu, 1 Jul 1999 08:38:49 -0700 (PDT) (envelope-from root@www.koral.bg) Received: from www.bgzone.com (ns.bgzone.com [194.12.235.81]) by dpx20.tu-varna.acad.bg (8.9.3/8.9.3) with ESMTP id SAA51146 for ; Thu, 1 Jul 1999 18:36:15 +0300 Received: from www.koral.bg (koral [194.12.235.94]) by www.bgzone.com (8.8.8/8.8.5) with ESMTP id RAA06211 for ; Thu, 1 Jul 1999 17:37:44 +0300 (EEST) Received: from www (localhost [127.0.0.1]) by www.koral.bg (8.9.2/8.8.5) with ESMTP id SAA00776 for ; Thu, 1 Jul 1999 18:39:20 +0300 (EEST) Message-Id: <199907011539.SAA00776@www.koral.bg> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-net@freebsd.org Subject: strange things on my host Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Jul 1999 18:39:20 +0300 From: Dimitar Peikov Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I installed FreeBSD 3.1 serving as a gateway for our private network (ethernet - ed0) to Inet(ppp0). Last 2-3 days I found strange behavior of that host. I can establish connection to any host I want to, even from local network to Inet. When system boots, everything is ok, but after several hours no one from Inet cannot connect to me if they want to create the connection. I've use natd to transport local IP to the Inet dealing convertion using modem IP. Here is my ipfw rules: 00100 allow ip from any to any via lo0 00100 divert ip from any to any via ppp0 00200 deny ip from any to 127.0.0.0/8 65000 allow ip from any to any 65535 allow ip from any to any I can't understand whats up! It's funny that several hours everything is ok..... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 1 9:25:27 1999 Delivered-To: freebsd-net@freebsd.org Received: from dpx20.tu-varna.acad.bg (unknown [194.12.234.4]) by hub.freebsd.org (Postfix) with ESMTP id DA88A14BF5; Thu, 1 Jul 1999 09:25:13 -0700 (PDT) (envelope-from mitko@www.koral.bg) Received: from www.bgzone.com (ns.bgzone.com [194.12.235.81]) by dpx20.tu-varna.acad.bg (8.9.3/8.9.3) with ESMTP id TAA50516; Thu, 1 Jul 1999 19:22:43 +0300 Received: from www.koral.bg (koral [194.12.235.94]) by www.bgzone.com (8.8.8/8.8.5) with ESMTP id SAA06769; Thu, 1 Jul 1999 18:24:11 +0300 (EEST) Received: from www (localhost [127.0.0.1]) by www.koral.bg (8.9.2/8.8.5) with ESMTP id TAA01301; Thu, 1 Jul 1999 19:25:47 +0300 (EEST) Message-Id: <199907011625.TAA01301@www.koral.bg> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-net@freebsd.org Cc: freebsd-ipfwt@freebsd.org Subject: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Jul 1999 19:25:47 +0300 From: Dimitar Peikov Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> I installed FreeBSD 3.1 serving as a gateway for our private network >> (ethernet - ed0) to Inet(ppp0). Last 2-3 days I found strange behavior of that >> host. I can establish connection to any host I want to, even from local >> network to Inet. When system boots, everything is ok, but after several hours >> no one from Inet cannot connect to me if they want to create the connection. >> I've use natd to transport local IP to the Inet dealing convertion using modem >> IP. Here is my ipfw rules: >> 00100 allow ip from any to any via lo0 >> 00100 divert ip from any to any via ppp0 >> 00200 deny ip from any to 127.0.0.0/8 >> 65000 allow ip from any to any >> 65535 allow ip from any to any > >Not sure if it is related or not, but you need to put a port number in the >ipfw divert line. You might want to make sure you arn't using ppp -alias when >you start ppp. Natd and -alias don't like each other > Sorry, I didn't use aliasing here. I use pppd instead of ppp. I'n not sure that tha problem is here in natd, but what I see is correct. That's right that I am skipping port in divert line, because I stopped natd for now (when write email), to proove is the problem in it, otherwise ipfw screems for a missing parameter. Mitko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 1 9:58:41 1999 Delivered-To: freebsd-net@freebsd.org Received: from dpx20.tu-varna.acad.bg (unknown [194.12.234.4]) by hub.freebsd.org (Postfix) with ESMTP id 579B514D71 for ; Thu, 1 Jul 1999 09:58:17 -0700 (PDT) (envelope-from mitko@www.koral.bg) Received: from www.bgzone.com (ns.bgzone.com [194.12.235.81]) by dpx20.tu-varna.acad.bg (8.9.3/8.9.3) with ESMTP id TAA19756 for ; Thu, 1 Jul 1999 19:55:45 +0300 Received: from www.koral.bg (koral [194.12.235.94]) by www.bgzone.com (8.8.8/8.8.5) with ESMTP id SAA07075 for ; Thu, 1 Jul 1999 18:57:13 +0300 (EEST) Received: from www (localhost [127.0.0.1]) by www.koral.bg (8.9.2/8.8.5) with ESMTP id TAA01538 for ; Thu, 1 Jul 1999 19:58:48 +0300 (EEST) Message-Id: <199907011658.TAA01538@www.koral.bg> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-net@FreeBSD.ORG Subject: RE:strange things Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Jul 1999 19:58:48 +0300 From: Dimitar Peikov Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I installed FreeBSD 3.1 serving as a gateway for our private network (ethernet - ed0) to Inet(ppp0). Last 2-3 days I found strange behavior of that host. I can establish connection to any host I want to, even from local network to Inet. When system boots, everything is ok, but after several hours no one from Inet cannot connect to me if they want to create the connection. I've use natd to transport local IP to the Inet dealing convertion using modem IP. Here is my ipfw rules: 00100 allow ip from any to any via lo0 00100 divert ip from any to any via ppp0 00200 deny ip from any to 127.0.0.0/8 65000 allow ip from any to any 65535 allow ip from any to any I can't understand whats up! It's funny that several hours everything is ok..... I think the problem is in divert. When I remove it from ipfw rules things runs again????????? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 1 11:41:41 1999 Delivered-To: freebsd-net@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 8670E15071 for ; Thu, 1 Jul 1999 11:41:36 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id NAA19069 for ; Thu, 1 Jul 1999 13:41:32 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id NAA10531; Thu, 1 Jul 1999 13:41:31 -0500 Message-ID: <19990701134131.58921@right.PCS> Date: Thu, 1 Jul 1999 13:41:31 -0500 From: Jonathan Lemon To: net@freebsd.org Subject: Slow start? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm slightly confused; is slow-start still required if both hosts are on the same "LAN"? Note that a bridged environment is still considered a single LAN for ethernet purposes, even though the hosts may be separated by (say) an ISDN bridge. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 1 14: 1:52 1999 Delivered-To: freebsd-net@freebsd.org Received: from stennis.ca.sandia.gov (stennis.ca.sandia.gov [146.246.243.44]) by hub.freebsd.org (Postfix) with ESMTP id B629C14F4A for ; Thu, 1 Jul 1999 14:01:47 -0700 (PDT) (envelope-from bmah@stennis.ca.sandia.gov) Received: (from bmah@localhost) by stennis.ca.sandia.gov (8.9.3/8.9.3) id OAA05102; Thu, 1 Jul 1999 14:01:42 -0700 (PDT) Message-Id: <199907012101.OAA05102@stennis.ca.sandia.gov> X-Mailer: exmh version 2.1.0 06/10/1999 To: Jonathan Lemon Cc: net@FreeBSD.ORG Subject: Re: Slow start? In-Reply-To: Your message of "Thu, 01 Jul 1999 13:41:31 CDT." <19990701134131.58921@right.PCS> From: bmah@CA.Sandia.GOV (Bruce A. Mah) Reply-To: bmah@CA.Sandia.GOV X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Url: http://www.ca.sandia.gov/~bmah/ Mime-Version: 1.0 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-963475294P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 01 Jul 1999 14:01:42 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --==_Exmh_-963475294P Content-Type: text/plain; charset=us-ascii If memory serves me right, Jonathan Lemon wrote: > I'm slightly confused; is slow-start still required if both hosts > are on the same "LAN"? Note that a bridged environment is still > considered a single LAN for ethernet purposes, even though the hosts > may be separated by (say) an ISDN bridge. For a host sending to another host on the same *subnet*, no, the sender doesn't go through slow-start. (In BSD-derived TCP stacks.) "Another host on the same subnet" means that the sender doesn't need to forward packets through a router to get to the destination, which is a slightly broader case than "the same 'LAN'". Bruce. --==_Exmh_-963475294P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBN3vXNajOOi0j7CY9AQFTmwP/d4hYOep50tDuYbuMmA037Uh/JKBk9pic 2hwC26UBYUobk+/WnNGZtB6s2IrHzDoU7tFiUJfqLM1aIMjT7szse4YD3yNPvGfd utStzkkbLcKHCe1w7TAzgVoyn0qff35oR1UHDw6wbPxIZWHRQ1vnLQ086wzU1CnZ xlWFyYd9DWk= =jUMj -----END PGP MESSAGE----- --==_Exmh_-963475294P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 1 14:16:47 1999 Delivered-To: freebsd-net@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 33D3D150C4 for ; Thu, 1 Jul 1999 14:16:42 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id QAA20234; Thu, 1 Jul 1999 16:16:41 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id QAA04701; Thu, 1 Jul 1999 16:16:40 -0500 Message-ID: <19990701161639.29611@right.PCS> Date: Thu, 1 Jul 1999 16:16:39 -0500 From: Jonathan Lemon To: bmah@CA.Sandia.GOV Cc: net@FreeBSD.ORG Subject: Re: Slow start? References: <19990701134131.58921@right.PCS> <199907012101.OAA05102@stennis.ca.sandia.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <199907012101.OAA05102@stennis.ca.sandia.gov>; from Bruce A. Mah on Jul 07, 1999 at 02:01:42PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jul 07, 1999 at 02:01:42PM -0700, Bruce A. Mah wrote: > If memory serves me right, Jonathan Lemon wrote: > > > I'm slightly confused; is slow-start still required if both hosts > > are on the same "LAN"? Note that a bridged environment is still > > considered a single LAN for ethernet purposes, even though the hosts > > may be separated by (say) an ISDN bridge. > > For a host sending to another host on the same *subnet*, no, the sender > doesn't go through slow-start. (In BSD-derived TCP stacks.) > > "Another host on the same subnet" means that the sender doesn't need to > forward packets through a router to get to the destination, which is a > slightly broader case than "the same 'LAN'". Yeah, digging around, I just found the relevant subroutine: in_localaddr(). I was suprised, since I expected slow start in all cases. While I can understand why slow start may not be desirable on a "local subnet", some of this code seems dated. I mean, it still calculates the netmask as CLASS_A(), CLASS_B(), etc. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 1 16: 1:53 1999 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 30347150A3 for ; Thu, 1 Jul 1999 16:01:50 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id QAA69966; Thu, 1 Jul 1999 16:01:44 -0700 (PDT) From: Archie Cobbs Message-Id: <199907012301.QAA69966@bubba.whistle.com> Subject: Re: debug print out from the kernel under FreeBSD-3.2 In-Reply-To: <71DA16F18D32D2119A1D0000F8FE9A9402B5A24C@mbtlipnt01.btlabs.bt.co.uk> from "graeme.n.brown@bt.com" at "Jul 1, 99 03:40:43 pm" To: graeme.n.brown@bt.com Date: Thu, 1 Jul 1999 16:01:44 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (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 graeme.n.brown@bt.com writes: > log(LOG_DEBUG, "debug message....") ; > > or > > printf( ... ) ; > > Trying the same on a FreeBSD-3.2 kernel, I do not get any debug messages > printed on console or in system log ( var/log/messages). > Has something changed since FreeBSD-2.2.x that I may not be ware of ? > Can anyone suggest what I may have overlooked ? I don't think anything's changed, except possibly the location of the log device (at one point it moved from /dev to /var/log). Why not run syslogd in debug mode to make sure it's receiving the messages.. also check /etc/syslog.conf .. -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 Jul 1 16:43:52 1999 Delivered-To: freebsd-net@freebsd.org Received: from the.oneinsane.net (the.oneinsane.net [207.113.133.228]) by hub.freebsd.org (Postfix) with ESMTP id 2EE2D14D94; Thu, 1 Jul 1999 16:43:48 -0700 (PDT) (envelope-from insane@lunatic.oneinsane.net) Received: from lunatic.oneinsane.net (insane@lunatic.oneinsane.net [207.113.133.231]) by the.oneinsane.net (8.9.3/8.9.3) with ESMTP id QAA18269; Thu, 1 Jul 1999 16:43:48 -0700 (PDT) Received: (from insane@localhost) by lunatic.oneinsane.net (8.9.3/8.9.3) id QAA22508; Thu, 1 Jul 1999 16:43:48 -0700 (PDT) (envelope-from insane) Date: Thu, 1 Jul 1999 16:43:48 -0700 From: "Ron 'The InSaNe One' Rosson" To: freebsd-ipfw@freebsd.org Cc: freebsd-net@freebsd.org Subject: NATD/VPN using -pptpalias Message-ID: <19990701164347.B22149@lunatic.oneinsane.net> Reply-To: Ron Rosson Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i X-Operating-System: FreeBSD lunatic.oneinsane.net 3.2-STABLE X-Opinion: What you read here is my IMHO X-Disclaimer: I am a firm believer in RTFM X-WWW: http://www.oneinsane.net X-PGP-KEY: http://www.oneinsane.net/~insane/insane-pgp5i.txt X-Uptime: 4:43PM up 16:40, 3 users, load averages: 0.09, 0.06, 0.01 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am tring to get a FreeBSD 3.2-STABLE as of Last week to pass a VPN connection from a client behind the NATD box to a Server out on the internet. At this time I am getting erro, timeout exceeded while waiting for reply. excerpt from rc.conf natd_enable="YES" natd_interface="ed0" natd_flags="-pptpalias 192.168.2.7" excerpt from rc.firewall if [ "X${natd_enable}" = X"YES" -a "X${natd_interface}" != X"" ]; then $fwcmd add divert natd all from any to any via ${natd_interface} fi edo is the line out to my cable modem and ed1 goes for my private network using addresses <192.168.x.x> If someone has this working I would be greatful to see how you did it. -- ------------------------------------------------------------------- Ron Rosson ... and a UNIX user said ... The InSaNe One rm -rf * insane@oneinsane.net and all was null and void ------------------------------------------------------------------- This person has performed an illegal operation and will be shot down. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 1 17:50:54 1999 Delivered-To: freebsd-net@freebsd.org Received: from netsjcms01.i-drive.com (netsjcms01.i-drive.com [216.32.226.133]) by hub.freebsd.org (Postfix) with ESMTP id 361D715170; Thu, 1 Jul 1999 17:50:45 -0700 (PDT) (envelope-from christian@i-drive.com) Received: from win95.sung.org (goliath.sung.org.i-drive.com [216.102.91.184]) by netsjcms01.i-drive.com (8.9.3/8.9.3) with ESMTP id RAA01387; Thu, 1 Jul 1999 17:50:18 -0700 (PDT) (envelope-from christian@i-drive.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19990701164347.B22149@lunatic.oneinsane.net> Date: Thu, 01 Jul 1999 17:50:17 -0700 (PDT) Organization: i-drive.com From: Christian Sung To: "Ron 'The InSaNe One' Rosson" Subject: RE: NATD/VPN using -pptpalias Cc: freebsd-net@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 01-Jul-99 Ron 'The InSaNe One' Rosson wrote: > I am tring to get a FreeBSD 3.2-STABLE as of Last week to pass a VPN > connection > from a client behind the NATD box to a Server out on the internet. At this > time > I am getting erro, timeout exceeded while waiting for reply. > > excerpt from rc.conf > natd_enable="YES" > natd_interface="ed0" > natd_flags="-pptpalias 192.168.2.7" > > excerpt from rc.firewall > if [ "X${natd_enable}" = X"YES" -a "X${natd_interface}" != X"" ]; then > $fwcmd add divert natd all from any to any via ${natd_interface} > fi > > edo is the line out to my cable modem and ed1 goes for my private network > using > addresses <192.168.x.x> > --- Ron, Try this: natd_interface="ed0" # Public interface to use with natd. natd_flags="-u" and make sure NATD is started *BEFORE* loading up the firewall rules. I do so inside rc-firewall itself (it used to be started in rc.network, but that was too late in the startup process). It works like a charm for me :-) # Network Address Translation daemon if [ "X${natd_enable}" = X"YES" -a X"${natd_interface}" != X"" \ -a X"${firewall_enable}" = X"YES" ]; then if echo ${natd_interface} | \ grep -q -E '^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$'; then natd_ifarg="-a ${natd_interface}" else natd_ifarg="-n ${natd_interface}" fi echo 'Starting Network Address Translation daemon (natd)' natd ${natd_flags} ${natd_ifarg} fi # Network Address Translation daemon if [ "X${natd_enable}" = X"YES" -a X"${natd_interface}" != X"" \ -a X"${firewall_enable}" = X"YES" ]; then if echo ${natd_interface} | \ grep -q -E '^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$'; then natd_ifarg="-a ${natd_interface}" else natd_ifarg="-n ${natd_interface}" fi echo 'Starting Network Address Translation daemon (natd)' natd ${natd_flags} ${natd_ifarg} fi -christian Christian W. Sung =============================================================== PGP Key Fingerprint: F6E2 0372 F765 28B6 6D34 7DF4 A928 A7AF 59A0 04CD =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 1 19:44: 7 1999 Delivered-To: freebsd-net@freebsd.org Received: from public1.ptt.js.cn (unknown [202.102.13.144]) by hub.freebsd.org (Postfix) with ESMTP id A2D11156C9; Thu, 1 Jul 1999 19:42:40 -0700 (PDT) (envelope-from witman@iname.com) Received: from heart (tnt3-66-92.nj.js.cn [202.102.66.92]) by public1.ptt.js.cn (8.9.1/8.9.1) with SMTP id JAA20081; Fri, 2 Jul 1999 09:38:15 +0800 (CST) Message-ID: <008f01bec434$82154c90$010000c8@heart.witman.com> From: "Witman Peng" To: "venkat venkatsubra" Cc: , Subject: Re: IP reassemble fails if it contains more that 20 bytes options? Date: Fri, 2 Jul 1999 10:42:05 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org But if this packet is stored in a cluster, hlen is always less than m->len (which is greater that 207). So the following code will never be run. BR Witman Peng -----Original Message----- From: venkat venkatsubra To: Witman Peng Cc: freebsd-net@FreeBSD.ORG ; freebsd-bugs@FreeBSD.ORG Date: 1999?7?1? 22:00 Subject: Re: IP reassemble fails if it contains more that 20 bytes options? >Witman, > Isn't this taken care of early in ipintr ? >-------------------------- >if (hlen > m->m_len) { > if ((m = m_pullup(m, hlen)) == 0) { > ipstat.ips_badhlen++; > goto next; > } > ip = mtod(m, struct ip *); > } >--------------------------- > >Venkat > >Witman Peng wrote: > >> Hi, All >> >> I am developing an application based on 4.4BSD-Lite source code. When I port >> the code in file netinet/ip_input.c, I found a problem. But I have no chance >> to install FreeBSD and test it, so I am not sure whether it'a bug or not. >> The following are the code to reassemble the IP fragments from ip_input.c: >> >> >From routine ipintr: >> if (ip->ip_off &~ IP_DF) { >> if (m->m_flags & M_EXT) { /* XXX */ >> if ((m = m_pullup(m, sizeof (struct ip))) == 0) { >> ipstat.ips_toosmall++; >> goto next; >> } >> ip = mtod(m, struct ip *); >> } >> >> >From routine ip_reass: >> int hlen = ip->ip_hl << 2; >> int i, next; >> >> m->m_data += hlen; >> m->m_len -= hlen; >> >> Suppose a fragment with more that 208 bytes and 40 bytes IP option, it will >> be stored in the cluster but not mbuf. In routine ipintr, function pullup >> just pullup sizeof(struct ip) (maybe 40 bytes for tcp header) bytes into a >> new mbuf. However, the IP header is 60 (20 + 40) bytes, so the complete IP >> header cannot be stored in this mbuf. Then in routine ip_reass, after run >> the above code, m->m_data will pointer to an incorrect address. >> >> Dose it seems right? Any inputs would be apprecaited. >> >> BR, >> Witman Peng >> >> 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 2 0:36:45 1999 Delivered-To: freebsd-net@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 6790415119 for ; Fri, 2 Jul 1999 00:36:39 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id HAA11523; Fri, 2 Jul 1999 07:04:31 +0200 From: Luigi Rizzo Message-Id: <199907020504.HAA11523@labinfo.iet.unipi.it> Subject: Re: Slow start? To: jlemon@americantv.com (Jonathan Lemon) Date: Fri, 2 Jul 1999 07:04:30 +0200 (MET DST) Cc: bmah@CA.Sandia.GOV, net@FreeBSD.ORG In-Reply-To: <19990701161639.29611@right.PCS> from "Jonathan Lemon" at Jul 1, 99 04:16:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 731 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > For a host sending to another host on the same *subnet*, no, the sender > > doesn't go through slow-start. (In BSD-derived TCP stacks.) ... > Yeah, digging around, I just found the relevant subroutine: in_localaddr(). i reported this problem about three years ago i think (but then forgot about it and did not fix...) cheers luigi > I was suprised, since I expected slow start in all cases. While I > can understand why slow start may not be desirable on a "local subnet", > some of this code seems dated. I mean, it still calculates the > netmask as CLASS_A(), CLASS_B(), etc. > -- > Jonathan > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 2 8: 8:38 1999 Delivered-To: freebsd-net@freebsd.org Received: from ausmail2.austin.ibm.com (ausmail2.austin.ibm.com [192.35.232.11]) by hub.freebsd.org (Postfix) with ESMTP id 300AC150E1 for ; Fri, 2 Jul 1999 08:08:30 -0700 (PDT) (envelope-from venkats@austin.ibm.com) Received: from netmail.austin.ibm.com (netmail.austin.ibm.com [9.53.250.98]) by ausmail2.austin.ibm.com (8.9.1/8.8.5) with ESMTP id KAA78450 for ; Fri, 2 Jul 1999 10:04:33 -0500 Received: from ambika.austin.ibm.com (ambika.austin.ibm.com [9.53.150.77]) by netmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id KAA36926; Fri, 2 Jul 1999 10:08:29 -0500 Received: from austin.ibm.com (localhost.austin.ibm.com [127.0.0.1]) by ambika.austin.ibm.com (AIX4.3/UCB 8.8.8/8.7-client1.01) with ESMTP id KAA27728; Fri, 2 Jul 1999 10:08:27 -0500 Message-ID: <377CD5EA.9F1E14BF@austin.ibm.com> Date: Fri, 02 Jul 1999 10:08:26 -0500 From: venkat venkatsubra Organization: IBM X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.3) MIME-Version: 1.0 To: Witman Peng Cc: freebsd-net@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: IP reassemble fails if it contains more that 20 bytes options? References: <008f01bec434$82154c90$010000c8@heart.witman.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Witman, Looks like a problem. I don't know if it is fixed in later versions. Venkat Witman Peng wrote: > But if this packet is stored in a cluster, hlen is always less than m->len > (which is greater that 207). So the following code will never be run. > > BR > Witman Peng > -----Original Message----- > From: venkat venkatsubra > To: Witman Peng > Cc: freebsd-net@FreeBSD.ORG ; > freebsd-bugs@FreeBSD.ORG > Date: 1999?7?1? 22:00 > Subject: Re: IP reassemble fails if it contains more that 20 bytes options? > > >Witman, > > Isn't this taken care of early in ipintr ? > >-------------------------- > >if (hlen > m->m_len) { > > if ((m = m_pullup(m, hlen)) == 0) { > > ipstat.ips_badhlen++; > > goto next; > > } > > ip = mtod(m, struct ip *); > > } > >--------------------------- > > > >Venkat > > > >Witman Peng wrote: > > > >> Hi, All > >> > >> I am developing an application based on 4.4BSD-Lite source code. When I > port > >> the code in file netinet/ip_input.c, I found a problem. But I have no > chance > >> to install FreeBSD and test it, so I am not sure whether it'a bug or not. > >> The following are the code to reassemble the IP fragments from > ip_input.c: > >> > >> >From routine ipintr: > >> if (ip->ip_off &~ IP_DF) { > >> if (m->m_flags & M_EXT) { /* XXX */ > >> if ((m = m_pullup(m, sizeof (struct ip))) == 0) { > >> ipstat.ips_toosmall++; > >> goto next; > >> } > >> ip = mtod(m, struct ip *); > >> } > >> > >> >From routine ip_reass: > >> int hlen = ip->ip_hl << 2; > >> int i, next; > >> > >> m->m_data += hlen; > >> m->m_len -= hlen; > >> > >> Suppose a fragment with more that 208 bytes and 40 bytes IP option, it > will > >> be stored in the cluster but not mbuf. In routine ipintr, function pullup > >> just pullup sizeof(struct ip) (maybe 40 bytes for tcp header) bytes into > a > >> new mbuf. However, the IP header is 60 (20 + 40) bytes, so the complete > IP > >> header cannot be stored in this mbuf. Then in routine ip_reass, after run > >> the above code, m->m_data will pointer to an incorrect address. > >> > >> Dose it seems right? Any inputs would be apprecaited. > >> > >> BR, > >> Witman Peng > >> > >> 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 > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 2 13:27:13 1999 Delivered-To: freebsd-net@freebsd.org Received: from mail.snowcrest.net (mail.snowcrest.net [216.102.43.227]) by hub.freebsd.org (Postfix) with ESMTP id 2EF3E15306 for ; Fri, 2 Jul 1999 13:27:02 -0700 (PDT) (envelope-from djewett@snowcrest.net) Received: from ws2983 (oakfrA111.snowcrest.net [216.102.4.111]) by mail.snowcrest.net (8.9.0/8.9.0) with SMTP id NAA18413 for ; Fri, 2 Jul 1999 13:27:01 -0700 (PDT) Message-ID: <000e01bec4c9$153ecb60$5515a8c0@ws2983> From: "Derek Jewett" To: Subject: Secure FTP... Date: Fri, 2 Jul 1999 13:25:52 -0700 Organization: Shasta County MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01BEC48E.67FC4A20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_000B_01BEC48E.67FC4A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Using 3.1-R I need to provide a secure ftp login for an account. I want = the user to have write only access to their usr/home/user directory... I = perused the man page for chown and chgrp, and found how to change rights = on indevidual files but not directories... Could someone steer me to = the man page I need.. Thanks ------=_NextPart_000_000B_01BEC48E.67FC4A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
Using 3.1-R I need to provide a secure = ftp login=20 for an account. I want the user to have write only access to their = usr/home/user=20 directory... I perused the man page for chown and chgrp, and found how = to change=20 rights on indevidual files but not directories...  Could someone = steer me=20 to the man page I need.. Thanks
------=_NextPart_000_000B_01BEC48E.67FC4A20-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 2 13:35:50 1999 Delivered-To: freebsd-net@freebsd.org Received: from mail.skynetweb.com (mail.hecenter.com [208.231.1.17]) by hub.freebsd.org (Postfix) with ESMTP id 2CC2414CCF for ; Fri, 2 Jul 1999 13:35:41 -0700 (PDT) (envelope-from pryker@skynetweb.com) Received: from skynetweb.com [208.231.1.80] by mail.skynetweb.com with ESMTP (SMTPD32-5.04) id A6ACC3012A; Sat, 03 Jul 1999 04:42:36 +0500 Message-ID: <377CD992.DAB3BD3@skynetweb.com> Date: Fri, 02 Jul 1999 16:24:02 +0100 From: Phillip Ryker Organization: SkyNetWEB Ltd. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Derek Jewett , freebsd-net@freebsd.org Subject: Re: Secure FTP... References: <000e01bec4c9$153ecb60$5515a8c0@ws2983> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Derek, You will probably want to look at the Proftpd package available at: www.proftpd.org There are more config options available with it. Thank you > Derek Jewett wrote: > > > > Using 3.1-R I need to provide a secure ftp login for an account. I > want the user to have write only access to their usr/home/user > directory... I perused the man page for chown and chgrp, and found how > to change rights on indevidual files but not directories... Could > someone steer me to the man page I need.. Thanks -- Phillip Ryker SkyNetWEB Ltd. 1301 S. Baylis Street Baltimore Maryland 21224 Phone: 410.563.6384 Ext 12 Fax: 410.563.5457 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 2 13:40:18 1999 Delivered-To: freebsd-net@freebsd.org Received: from sigem.ca (unknown [216.58.26.35]) by hub.freebsd.org (Postfix) with SMTP id 026CD14CDF for ; Fri, 2 Jul 1999 13:40:10 -0700 (PDT) (envelope-from jordan@sigem.dyndns.org) Received: (qmail 1507 invoked from network); 2 Jul 1999 20:38:33 -0000 Received: from unknown (HELO jordanw) (216.58.26.55) by 216.58.26.35 with SMTP; 2 Jul 1999 20:38:33 -0000 Message-ID: <005701bec4ca$cfc848c0$371a3ad8@jordanw.office.sigem.ca> From: "Jordan Williams" To: Subject: Multiple Subnets, one gateway Date: Fri, 2 Jul 1999 16:38:15 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01BEC4A9.48951700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0054_01BEC4A9.48951700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable G'day All.... I have a situation that i'm somewhat boggled on how to = solve. Here's the layout of the system.... I have 4 subnets 192.168.0.0/32 192.168.1.0/32 192.168.2.0/32 and = 192.168.4.0/32. I have a NAT/named/httpd/ftp-fp/qmail system all one system. The first subnet is used for servers and other service providing = computers, the other three are different departments in my building. My problem is figuring out how I can allow the different subnets to see = all the computers on 192.168.0.0/32 but not to each other, (somewhat = separated, but visible to the gateway) How do I approach this? Some = people have told me to use routed, but i'm just learning about routing = and whatnot, so i'm in a hole... any help or input would be = appreciated. Thanks ------=_NextPart_000_0054_01BEC4A9.48951700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
G'day All.... I have a situation = that i'm=20 somewhat boggled on how to solve.  Here's the layout of the=20 system....
 
I have 4 subnets 192.168.0.0/32 = 192.168.1.0/32=20 192.168.2.0/32 and 192.168.4.0/32.
 
I have a NAT/named/httpd/ftp-fp/qmail system all one = system.
 
The first subnet is used for servers and other = service=20 providing computers, the other three are different departments in my=20 building.
 
My problem is figuring out how I can = allow the=20 different subnets to see all the computers on 192.168.0.0/32 but not to = each=20 other, (somewhat separated, but visible to the gateway)  How do I = approach=20 this?  Some people have told me to use routed, but i'm just = learning about=20 routing and whatnot, so i'm in a hole...  any help or input would = be=20 appreciated.
 
Thanks
 
------=_NextPart_000_0054_01BEC4A9.48951700-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 3 0:43:49 1999 Delivered-To: freebsd-net@freebsd.org Received: from public1.ptt.js.cn (unknown [202.102.13.144]) by hub.freebsd.org (Postfix) with ESMTP id 748311534F for ; Sat, 3 Jul 1999 00:42:19 -0700 (PDT) (envelope-from witman@iname.com) Received: from heart (tnt3-66-4.nj.js.cn [202.102.66.4]) by public1.ptt.js.cn (8.9.1/8.9.1) with SMTP id OAA14672; Sat, 3 Jul 1999 14:37:34 +0800 (CST) Message-ID: <005201bec527$88e49230$010000c8@heart.witman.com> From: "Witman Peng" To: "venkat venkatsubra" Cc: Subject: Re: IP reassemble fails if it contains more that 20 bytes options? Date: Sat, 3 Jul 1999 15:41:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Venkat, Do you know what's the latest version of 4.4BSD-Lite? Where can I get it? From ftp.cdrom.com I download 4.4BSD-Lite2, but I don't know what's the difference between 4.4BSD-Lite and 4.4BSD-Lite2. BR, Witman Peng -----Original Message----- From: venkat venkatsubra To: Witman Peng Cc: freebsd-net@FreeBSD.ORG ; freebsd-bugs@FreeBSD.ORG Date: 1999?7?2? 22:04 Subject: Re: IP reassemble fails if it contains more that 20 bytes options? >Witman, > Looks like a problem. I don't know if it is fixed in > later versions. >Venkat > >Witman Peng wrote: > >> But if this packet is stored in a cluster, hlen is always less than m->len >> (which is greater that 207). So the following code will never be run. >> >> BR >> Witman Peng To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 3 2:52:50 1999 Delivered-To: freebsd-net@freebsd.org Received: from des.follo.net (des.follo.net [195.204.143.216]) by hub.freebsd.org (Postfix) with ESMTP id 9FA4C14D03; Sat, 3 Jul 1999 02:50:41 -0700 (PDT) (envelope-from des@des.follo.net) Received: (from des@localhost) by des.follo.net (8.9.3/8.9.3) id LAA54550; Sat, 3 Jul 1999 11:50:32 +0200 (CEST) (envelope-from des) To: hackers@freebsd.org Subject: bpfilter -> bpf patches [LONG] Organization: Yes Interactive Visit-Us-At: http://www.yes.no/ From: Dag-Erling Smorgrav Date: 03 Jul 1999 11:50:32 +0200 Message-ID: Lines: 3294 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Bcc:ed to net, committers; please follow up on hackers] Attached are patches for renaming 'pseudo-device bpfilter' to 'peudo-device bpf', courtesy of glimpse(1) and ed(1). LINT and GENERIC build fine with these patches; I haven't tried to run a kernel built with them, though. Also, although I caught and corrected a few spacing nits caused by chopping off five letters, there may be some I didn't catch. If no-one objects, I'll commit this to -CURRENT in a few days. DES -- Dag-Erling Smorgrav - des@yes.no Index: src/release/picobsd/router/conf/PICOBSD =================================================================== RCS file: /home/ncvs/src/release/picobsd/router/conf/PICOBSD,v retrieving revision 1.14 diff -u -r1.14 PICOBSD --- PICOBSD 1999/05/24 17:27:30 1.14 +++ PICOBSD 1999/07/02 08:10:05 @@ -94,7 +94,7 @@ pseudo-device ether #pseudo-device tun 2 #pseudo-device vn -#pseudo-device bpfilter 4 +#pseudo-device bpf 4 pseudo-device ppp 4 pseudo-device pty 16 #pseudo-device gzip # Exec gzipped a.out's Index: src/release/scripts/dokern.sh =================================================================== RCS file: /home/ncvs/src/release/scripts/dokern.sh,v retrieving revision 1.14 diff -u -r1.14 dokern.sh --- dokern.sh 1999/06/09 09:08:22 1.14 +++ dokern.sh 1999/07/02 08:10:05 @@ -12,7 +12,7 @@ -e 's/GENERIC/BOOTMFS/g' # So dhclient will work (just on boot floppy). -echo "pseudo-device bpfilter 4" +echo "pseudo-device bpf 4" echo "options NFS_NOSERVER" echo "options SCSI_NO_OP_STRINGS" Index: src/share/man/man4/bpf.4 =================================================================== RCS file: /home/ncvs/src/share/man/man4/bpf.4,v retrieving revision 1.16 diff -u -r1.16 bpf.4 --- bpf.4 1999/01/10 04:59:59 1.16 +++ bpf.4 1999/07/02 08:10:05 @@ -29,7 +29,7 @@ .Nm bpf .Nd Berkeley Packet Filter .Sh SYNOPSIS -.Cd pseudo-device bpfilter +.Cd pseudo-device bpf .Sh DESCRIPTION The Berkeley Packet Filter provides a raw interface to data link layers in a protocol Index: src/sys/alpha/tc/am7990.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/tc/am7990.c,v retrieving revision 1.3 diff -u -r1.3 am7990.c --- am7990.c 1999/05/10 15:48:01 1.3 +++ am7990.c 1999/07/02 08:08:50 @@ -78,7 +78,7 @@ */ #include "opt_inet.h" -#if NBPFILTER > 0 +#if NBPF > 0 #include #include #endif @@ -229,7 +229,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(&ifp->if_bpf, ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -318,7 +318,7 @@ struct letmd tmd; u_int8_t *myaddr; -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_flags & IFF_PROMISC) init.init_mode = LE_MODE_NORMAL | LE_MODE_PROM; else @@ -565,7 +565,7 @@ /* We assume that the header fit entirely in one mbuf. */ eh = mtod(m, struct ether_header *); -#if NBPFILTER > 0 +#if NBPF > 0 /* * Check if there's a BPF listener on this interface. * If so, hand off the raw packet to BPF. @@ -923,7 +923,7 @@ if (m == 0) break; -#if NBPFILTER > 0 +#if NBPF > 0 /* * If BPF is listening on this interface, let it see the packet * before we commit it to the wire. Index: src/sys/alpha/tc/if_le_dec.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/tc/if_le_dec.c,v retrieving revision 1.1 diff -u -r1.1 if_le_dec.c --- if_le_dec.c 1998/08/20 08:27:10 1.1 +++ if_le_dec.c 1999/07/02 08:09:11 @@ -41,7 +41,7 @@ * @(#)if_le.c 8.2 (Berkeley) 11/16/93 */ -#include "bpfilter.h" +#include "bpf.h" #include #include #include Index: src/sys/conf/files =================================================================== RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.223 diff -u -r1.223 files --- files 1999/06/24 03:44:10 1.223 +++ files 1999/07/02 08:09:11 @@ -391,7 +391,7 @@ ntfs/ntfs_compr.c optional ntfs ntfs/ntfs_ihash.c optional ntfs net/bpf.c standard -net/bpf_filter.c optional bpfilter +net/bpf_filter.c optional bpf net/bridge.c optional bridge net/bsd_comp.c optional ppp_bsdcomp #net/hostcache.c standard Index: src/sys/contrib/dev/oltr/if_oltr.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/dev/oltr/if_oltr.c,v retrieving revision 1.5 diff -u -r1.5 if_oltr.c --- if_oltr.c 1999/05/09 17:07:24 1.5 +++ if_oltr.c 1999/07/02 08:09:11 @@ -37,7 +37,7 @@ #include "pci.h" #include "oltr.h" #include "opt_inet.h" -#include "bpfilter.h" +#include "bpf.h" #if (NOLTR + NPCI) > 0 @@ -90,7 +90,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -632,7 +632,7 @@ if_attach(ifp); iso88025_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_IEEE802, sizeof(struct iso88025_header)); #endif @@ -949,7 +949,7 @@ goto bad; } -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) bpf_mtap(ifp, m0); #endif @@ -1351,7 +1351,7 @@ } ifp->if_ipackets++; -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) bpf_mtap(ifp, m0); #endif Index: src/sys/dev/en/midway.c =================================================================== RCS file: /home/ncvs/src/sys/dev/en/midway.c,v retrieving revision 1.16 diff -u -r1.16 midway.c --- midway.c 1999/05/08 14:23:00 1.16 +++ midway.c 1999/07/02 08:09:11 @@ -169,8 +169,8 @@ #endif /* __FreeBSD__ */ -#include "bpfilter.h" -#if NBPFILTER > 0 +#include "bpf.h" +#if NBPF > 0 #include #ifdef __FreeBSD__ #define BPFATTACH(ifp, dlt, hlen) bpfattach((ifp), (dlt), (hlen)) @@ -179,7 +179,7 @@ #define BPFATTACH(ifp, dlt, hlen) bpfattach(&(ifp)->if_bpf, (ifp), (dlt), (hlen)) #define BPF_MTAP(ifp, m) bpf_mtap((ifp)->if_bpf, (m)) #endif -#endif /* NBPFILTER > 0 */ +#endif /* NBPF > 0 */ /* * params @@ -820,7 +820,7 @@ if_attach(ifp); atm_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 BPFATTACH(ifp, DLT_ATM_RFC1483, sizeof(struct atmllc)); #endif } @@ -2120,7 +2120,7 @@ en_txlaunch(sc, chan, &launch); -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) { /* * adjust the top of the mbuf to skip the pseudo atm header @@ -2139,7 +2139,7 @@ launch.t->m_data -= size; launch.t->m_len += size; } -#endif /* NBPFILTER > 0 */ +#endif /* NBPF > 0 */ /* * do some housekeeping and get the next packet */ @@ -2709,7 +2709,7 @@ ifp = &sc->enif; ifp->if_ipackets++; -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) BPF_MTAP(ifp, m); #endif Index: src/sys/dev/iicbus/if_ic.c =================================================================== RCS file: /home/ncvs/src/sys/dev/iicbus/if_ic.c,v retrieving revision 1.4 diff -u -r1.4 if_ic.c --- if_ic.c 1999/05/08 21:59:03 1.4 +++ if_ic.c 1999/07/02 08:09:11 @@ -59,9 +59,9 @@ #include #include -#include "bpfilter.h" +#include "bpf.h" -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -151,7 +151,7 @@ if_attach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_NULL, ICHDRLEN); #endif @@ -322,7 +322,7 @@ sc->ic_if.if_ipackets ++; sc->ic_if.if_ibytes += len; -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->ic_if.if_bpf) bpf_tap(&sc->ic_if, sc->ic_ifbuf, len + ICHDRLEN); #endif @@ -417,7 +417,7 @@ } while ((mm = mm->m_next)); -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) { struct mbuf m0, *n = m; Index: src/sys/dev/pccard/if_xe.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pccard/if_xe.c,v retrieving revision 1.5 diff -u -r1.5 if_xe.c --- if_xe.c 1999/06/22 19:21:00 1.5 +++ if_xe.c 1999/07/02 08:09:11 @@ -106,7 +106,7 @@ #include "xe.h" #include "card.h" #include "apm.h" -#include "bpfilter.h" +#include "bpf.h" #if NXE > 0 @@ -131,9 +131,9 @@ #include #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include -#endif /* NBPFILTER > 0 */ +#endif /* NBPF > 0 */ #include #include @@ -808,7 +808,7 @@ if_attach(scp->ifp); ether_ifattach(scp->ifp); -#if NBPFILTER > 0 +#if NBPF > 0 /* If BPF is in the kernel, call the attach for it */ #if XE_DEBUG > 1 printf("xe%d: BPF listener attached\n", scp->unit); @@ -944,7 +944,7 @@ return; } -#if NBPFILTER > 0 +#if NBPF > 0 /* Tap off here if there is a bpf listener */ if (ifp->if_bpf) { #if XE_DEBUG > 1 @@ -952,7 +952,7 @@ #endif bpf_mtap(ifp, mbp); } -#endif /* NBPFILTER > 0 */ +#endif /* NBPF > 0 */ ifp->if_timer = 5; /* In case we don't hear from the card again */ scp->tx_queued++; @@ -1266,7 +1266,7 @@ else insw(scp->dev->id_iobase+XE_EDP, ehp, len >> 1); -#if NBPFILTER > 0 +#if NBPF > 0 /* * Check if there's a BPF listener on this interface. If so, hand * off the raw packet to bpf. @@ -1289,7 +1289,7 @@ mbp = NULL; } } -#endif /* NBPFILTER > 0 */ +#endif /* NBPF > 0 */ if (mbp != NULL) { mbp->m_pkthdr.len = mbp->m_len = len - ETHER_HDR_LEN; Index: src/sys/dev/pdq/pdq_ifsubr.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pdq/pdq_ifsubr.c,v retrieving revision 1.7 diff -u -r1.7 pdq_ifsubr.c --- pdq_ifsubr.c 1998/02/20 13:11:45 1.7 +++ pdq_ifsubr.c 1999/07/02 08:09:11 @@ -45,8 +45,8 @@ #include #include -#include "bpfilter.h" -#if NBPFILTER > 0 +#include "bpf.h" +#if NBPF > 0 #include #endif @@ -186,7 +186,7 @@ struct fddi_header *fh = mtod(m, struct fddi_header *); sc->sc_if.if_ipackets++; -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->sc_bpf != NULL) PDQ_BPF_MTAP(sc, m); if ((fh->fddi_fc & (FDDIFC_L|FDDIFC_F)) != FDDIFC_LLC_ASYNC) { @@ -222,7 +222,7 @@ struct mbuf *m) { pdq_softc_t *sc = (pdq_softc_t *) pdq->pdq_os_ctx; -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->sc_bpf != NULL) PDQ_BPF_MTAP(sc, m); #endif @@ -384,7 +384,7 @@ if_attach(ifp); fddi_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 PDQ_BPFATTACH(sc, DLT_FDDI, sizeof(struct fddi_header)); #endif } Index: src/sys/dev/ppbus/if_plip.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ppbus/if_plip.c,v retrieving revision 1.12 diff -u -r1.12 if_plip.c --- if_plip.c 1999/02/14 16:19:16 1.12 +++ if_plip.c 1999/07/02 08:09:11 @@ -93,8 +93,8 @@ #include #include -#include "bpfilter.h" -#if NBPFILTER > 0 +#include "bpf.h" +#if NBPF > 0 #include #endif @@ -256,7 +256,7 @@ ifp->if_snd.ifq_maxlen = IFQ_MAXLEN; if_attach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_NULL, sizeof(u_int32_t)); #endif @@ -446,7 +446,7 @@ return (ctrecvl[cl] | ctrecvh[c]); } -#if NBPFILTER > 0 +#if NBPF > 0 static void lptap(struct ifnet *ifp, struct mbuf *m) { @@ -525,7 +525,7 @@ sc->sc_if.if_ibytes += len; top = m_devget(sc->sc_ifbuf + CLPIPHDRLEN, len, 0, &sc->sc_if, 0); if (top) { -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->sc_if.if_bpf) lptap(&sc->sc_if, top); #endif @@ -578,7 +578,7 @@ sc->sc_if.if_ibytes += len; top = m_devget(sc->sc_ifbuf + LPIPHDRLEN, len, 0, &sc->sc_if, 0); if (top) { -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->sc_if.if_bpf) lptap(&sc->sc_if, top); #endif @@ -715,7 +715,7 @@ } else { ifp->if_opackets++; ifp->if_obytes += m->m_pkthdr.len; -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) lptap(ifp, m); #endif @@ -762,7 +762,7 @@ } else { ifp->if_opackets++; ifp->if_obytes += m->m_pkthdr.len; -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) lptap(ifp, m); #endif Index: src/sys/dev/vx/if_vx.c =================================================================== RCS file: /home/ncvs/src/sys/dev/vx/if_vx.c,v retrieving revision 1.20 diff -u -r1.20 if_vx.c --- if_vx.c 1999/01/27 20:09:20 1.20 +++ if_vx.c 1999/07/02 08:09:11 @@ -62,7 +62,7 @@ #define NVX 4 #endif -#include "bpfilter.h" +#include "bpf.h" #include #include @@ -76,7 +76,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -216,7 +216,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -496,7 +496,7 @@ outw(BASE + VX_COMMAND, SET_TX_START_THRESH | ((len / 4 + sc->tx_start_thresh) >> 2)); -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->arpcom.ac_if.if_bpf) { bpf_mtap(&sc->arpcom.ac_if, m0); } @@ -745,7 +745,7 @@ /* We assume the header fit entirely in one mbuf. */ eh = mtod(m, struct ether_header *); -#if NBPFILTER > 0 +#if NBPF > 0 /* * Check if there's a BPF listener on this interface. * If so, hand off the raw packet to BPF. Index: src/sys/i386/conf/GENERIC =================================================================== RCS file: /home/ncvs/src/sys/i386/conf/GENERIC,v retrieving revision 1.175 diff -u -r1.175 GENERIC --- GENERIC 1999/06/29 18:55:53 1.175 +++ GENERIC 1999/07/03 09:40:42 @@ -197,9 +197,9 @@ pseudo-device pty 16 # Pseudo-ttys (telnet etc) pseudo-device gzip # Exec gzipped a.out's -# The `bpfilter' pseudo-device enables the Berkeley Packet Filter. +# The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the legal and administrative consequences of enabling this! -#pseudo-device bpfilter 4 #Berkeley packet filter +#pseudo-device bpf 4 #Berkeley packet filter # USB support #controller uhci0 # UHCI PCI->USB interface Index: src/sys/i386/conf/LINT =================================================================== RCS file: /home/ncvs/src/sys/i386/conf/LINT,v retrieving revision 1.613 diff -u -r1.613 LINT --- LINT 1999/06/29 21:52:07 1.613 +++ LINT 1999/07/03 09:40:35 @@ -381,7 +381,7 @@ # of synchronous PPP links (like `cx', `ar'). # The `sl' pseudo-device implements the Serial Line IP (SLIP) service. # The `ppp' pseudo-device implements the Point-to-Point Protocol. -# The `bpfilter' pseudo-device enables the Berkeley Packet Filter. Be +# The `bpf' pseudo-device enables the Berkeley Packet Filter. Be # aware of the legal and administrative consequences of enabling this # option. The number of devices determines the maximum number of # simultaneous BPF clients programs runnable. @@ -394,7 +394,7 @@ # The PPP_BSDCOMP option enables support for compress(1) style entire # packet compression, the PPP_DEFLATE is for zlib/gzip style compression. # PPP_FILTER enables code for filtering the ppp data stream and selecting -# events for resetting the demand dial activity timer - requires bpfilter. +# events for resetting the demand dial activity timer - requires bpf. # See pppd(8) for more details. # pseudo-device ether #Generic Ethernet @@ -402,7 +402,7 @@ pseudo-device fddi #Generic FDDI pseudo-device sppp #Generic Synchronous PPP pseudo-device loop #Network loopback device -pseudo-device bpfilter 4 #Berkeley packet filter +pseudo-device bpf 4 #Berkeley packet filter pseudo-device disc #Discard device pseudo-device tun 1 #Tunnel driver (ppp(8), nos-tun(8)) pseudo-device sl 2 #Serial Line IP @@ -410,7 +410,7 @@ pseudo-device streams options PPP_BSDCOMP #PPP BSD-compress support options PPP_DEFLATE #PPP zlib/deflate/gzip support -options PPP_FILTER #enable bpf filtering (needs bpfilter) +options PPP_FILTER #enable bpf filtering (needs bpf) # # Internet family options: Index: src/sys/i386/conf/PCCARD =================================================================== RCS file: /home/ncvs/src/sys/i386/conf/PCCARD,v retrieving revision 1.11 diff -u -r1.11 PCCARD --- PCCARD 1999/06/17 23:53:20 1.11 +++ PCCARD 1999/07/02 08:09:11 @@ -201,11 +201,11 @@ options SYSVMSG options SYSVSEM -# The `bpfilter' pseudo-device enables the Berkeley Packet Filter. Be +# The `bpf' pseudo-device enables the Berkeley Packet Filter. Be # aware of the legal and administrative consequences of enabling this # option. The number of devices determines the maximum number of # simultaneous BPF clients programs runnable. -#pseudo-device bpfilter 4 #Berkeley packet filter +#pseudo-device bpf 4 #Berkeley packet filter # USB support #controller uhci0 Index: src/sys/i386/isa/if_ar.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_ar.c,v retrieving revision 1.26 diff -u -r1.26 if_ar.c --- if_ar.c 1999/05/06 18:58:04 1.26 +++ if_ar.c 1999/07/02 08:09:11 @@ -49,7 +49,7 @@ */ #include "ar.h" -#include "bpfilter.h" +#include "bpf.h" #include #include @@ -61,7 +61,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -357,7 +357,7 @@ sppp_attach((struct ifnet *)&sc->ifsppp); if_attach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_PPP, PPP_HEADER_LEN); #endif } @@ -537,7 +537,7 @@ txdata += AR_BUF_SIZ; i++; -#if NBPFILTER > 0 +#if NBPF > 0 if(ifp->if_bpf) bpf_mtap(ifp, mtx); #endif @@ -1299,7 +1299,7 @@ } } ar_copy_rxbuf(m, sc, len); -#if NBPFILTER > 0 +#if NBPF > 0 if(sc->ifsppp.pp_if.if_bpf) bpf_mtap(&sc->ifsppp.pp_if, m); #endif Index: src/sys/i386/isa/if_cs.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_cs.c,v retrieving revision 1.10 diff -u -r1.10 if_cs.c --- if_cs.c 1999/04/16 21:22:20 1.10 +++ if_cs.c 1999/07/02 08:09:12 @@ -35,7 +35,7 @@ /* #define CS_DEBUG */ #include "cs.h" -#include "bpfilter.h" +#include "bpf.h" #include #include @@ -52,7 +52,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -620,7 +620,7 @@ printf(CS_NAME"%d: ethernet address %6D\n", ifp->if_unit, sc->arpcom.ac_enaddr, ":"); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof (struct ether_header)); #endif return 1; @@ -777,7 +777,7 @@ eh = mtod(m, struct ether_header *); -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) bpf_mtap(ifp, m); #endif @@ -950,7 +950,7 @@ cs_write_mbufs(sc, m); -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) { bpf_mtap(ifp, m); } Index: src/sys/i386/isa/if_cx.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_cx.c,v retrieving revision 1.28 diff -u -r1.28 if_cx.c --- if_cx.c 1999/04/02 13:58:01 1.28 +++ if_cx.c 1999/07/02 08:09:12 @@ -19,7 +19,7 @@ #undef DEBUG #include "cx.h" -#include "bpfilter.h" +#include "bpf.h" #include "opt_devfs.h" #include "sppp.h" @@ -38,7 +38,7 @@ #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -285,7 +285,7 @@ sppp_attach (c->ifp); if_attach (c->ifp); sp = (struct sppp*) c->ifp; -#if NBPFILTER > 0 +#if NBPF > 0 /* If BPF is in the kernel, call the attach for it. */ bpfattach (c->ifp, DLT_PPP, PPP_HEADER_LEN); #endif @@ -481,7 +481,7 @@ return; } m_copydata (m, 0, len, buf); -#if NBPFILTER > 0 +#if NBPF > 0 if (c->ifp->if_bpf) bpf_mtap (c->ifp, m); #endif @@ -805,7 +805,7 @@ printmbuf (m); #endif -#if NBPFILTER > 0 +#if NBPF > 0 /* * Check if there's a BPF listener on this interface. * If so, hand off the raw packet to bpf. Index: src/sys/i386/isa/if_ed.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_ed.c,v retrieving revision 1.152 diff -u -r1.152 if_ed.c --- if_ed.c 1999/05/09 23:24:45 1.152 +++ if_ed.c 1999/07/02 08:09:12 @@ -38,7 +38,7 @@ */ #include "ed.h" -#include "bpfilter.h" +#include "bpf.h" #include "pnp.h" #ifndef EXTRA_ED @@ -65,7 +65,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif #include "opt_bdg.h" @@ -1721,7 +1721,7 @@ /* * If BPF is in the kernel, call the attach for it */ -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif return 1; @@ -2179,7 +2179,7 @@ /* * Tap off here if there is a bpf listener. */ -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) { bpf_mtap(ifp, m0); } @@ -2621,7 +2621,7 @@ } } -#if NBPFILTER > 0 +#if NBPF > 0 /* * Promiscuous flag may have changed, so reprogram the RCR. @@ -2752,7 +2752,7 @@ struct ifnet *ifp ; int need_more = 1 ; /* in case not bpf */ -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->arpcom.ac_if.if_bpf) { need_more = 0 ; ed_ring_copy(sc, buf, (char *)eh, len); @@ -2783,7 +2783,7 @@ */ ed_ring_copy(sc, buf, (char *)eh, len); -#if NBPFILTER > 0 +#if NBPF > 0 /* * Check if there's a BPF listener on this interface. If so, hand off Index: src/sys/i386/isa/if_el.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_el.c,v retrieving revision 1.40 diff -u -r1.40 if_el.c --- if_el.c 1999/01/12 01:29:42 1.40 +++ if_el.c 1999/07/02 08:09:12 @@ -20,7 +20,7 @@ * - Does not currently support multicasts */ #include "el.h" -#include "bpfilter.h" +#include "bpf.h" #include "opt_inet.h" #include "opt_ipx.h" @@ -48,7 +48,7 @@ #include #endif -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -213,7 +213,7 @@ sc->arpcom.ac_enaddr, ":"); /* Finally, attach to bpf filter if it is present. */ -#if NBPFILTER > 0 +#if NBPF > 0 dprintf(("Attaching to BPF...\n")); bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -348,7 +348,7 @@ len = max(len,ETHER_MIN_LEN); /* Give the packet to the bpf, if any */ -#if NBPFILTER > 0 +#if NBPF > 0 if(sc->arpcom.ac_if.if_bpf) bpf_tap(&sc->arpcom.ac_if, sc->el_pktbuf, len); #endif @@ -438,7 +438,7 @@ eh = (struct ether_header *)buf; -#if NBPFILTER > 0 +#if NBPF > 0 /* * Check if there's a bpf filter listening on this interface. * If so, hand off the raw packet to bpf. Index: src/sys/i386/isa/if_ep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_ep.c,v retrieving revision 1.79 diff -u -r1.79 if_ep.c --- if_ep.c 1999/01/31 22:41:51 1.79 +++ if_ep.c 1999/07/02 08:09:12 @@ -59,7 +59,7 @@ #include "ep.h" #if NEP > 0 -#include "bpfilter.h" +#include "bpf.h" #include "opt_inet.h" #include "opt_ipx.h" @@ -93,7 +93,7 @@ #include #endif -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -635,7 +635,7 @@ ep_fset(F_RX_FIRST); sc->top = sc->mcur = 0; -#if NBPFILTER > 0 +#if NBPF > 0 if (!attached) { bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); } @@ -871,7 +871,7 @@ while (pad--) outb(BASE + EP_W1_TX_PIO_WR_1, 0); /* Padding */ -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) { bpf_mtap(ifp, top); } @@ -1137,7 +1137,7 @@ top->m_pkthdr.rcvif = &sc->arpcom.ac_if; top->m_pkthdr.len = sc->cur_len; -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) { bpf_mtap(ifp, top); Index: src/sys/i386/isa/if_ex.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_ex.c,v retrieving revision 1.15 diff -u -r1.15 if_ex.c --- if_ex.c 1999/05/02 22:01:24 1.15 +++ if_ex.c 1999/07/02 08:09:12 @@ -37,7 +37,7 @@ #include "ex.h" #if NEX > 0 -#include "bpfilter.h" +#include "bpf.h" #include "opt_inet.h" #include "opt_ipx.h" @@ -65,7 +65,7 @@ #include #endif -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -294,7 +294,7 @@ /* * If BPF is in the kernel, call the attach for it */ -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif DODEBUG(Start_End, printf("ex_attach%d: finish\n", unit);); @@ -520,7 +520,7 @@ sc->tx_last = dest; sc->tx_tail = next; -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf != NULL) bpf_mtap(ifp, opkt); #endif @@ -727,7 +727,7 @@ } /* QQQ */ } #endif -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf != NULL) { bpf_mtap(ifp, ipkt); Index: src/sys/i386/isa/if_fe.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_fe.c,v retrieving revision 1.50 diff -u -r1.50 if_fe.c --- if_fe.c 1999/05/04 12:59:59 1.50 +++ if_fe.c 1999/07/02 08:09:12 @@ -70,7 +70,7 @@ */ #include "fe.h" -#include "bpfilter.h" +#include "bpf.h" #include "opt_fe.h" #include "opt_inet.h" #include "opt_ipx.h" @@ -110,7 +110,7 @@ #include #endif -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -2763,7 +2763,7 @@ sc->sc_unit); } -#if NBPFILTER > 0 +#if NBPF > 0 /* If BPF is in the kernel, call the attach for it. */ bpfattach(&sc->sc_if, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -3132,7 +3132,7 @@ * and only if it is in "receive everything" * mode.) */ -#if NBPFILTER > 0 +#if NBPF > 0 if ( sc->sc_if.if_bpf && !( sc->sc_if.if_flags & IFF_PROMISC ) ) { bpf_mtap( &sc->sc_if, m ); @@ -3764,7 +3764,7 @@ #define ETHER_ADDR_IS_MULTICAST(A) (*(char *)(A) & 1) -#if NBPFILTER > 0 +#if NBPF > 0 /* * Check if there's a BPF listener on this interface. * If it is, hand off the raw packet to bpf. Index: src/sys/i386/isa/if_ie.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_ie.c,v retrieving revision 1.60 diff -u -r1.60 if_ie.c --- if_ie.c 1999/05/13 12:21:41 1.60 +++ if_ie.c 1999/07/02 08:09:12 @@ -125,7 +125,7 @@ #include #include -#include "bpfilter.h" +#include "bpf.h" #ifdef INET #include @@ -153,7 +153,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -842,7 +842,7 @@ if (ie->hard_type == IE_EE16) at_shutdown(ee16_shutdown, ie, SHUTDOWN_POST_SYNC); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -1101,7 +1101,7 @@ * Receiving all multicasts, but no unicasts except those * destined for us. */ -#if NBPFILTER > 0 +#if NBPF > 0 /* BPF gets this packet if anybody cares */ *to_bpf = (ie->arpcom.ac_if.if_bpf != 0); #endif @@ -1117,14 +1117,14 @@ * Receiving all packets. These need to be passed on to * BPF. */ -#if NBPFILTER > 0 +#if NBPF > 0 *to_bpf = (ie->arpcom.ac_if.if_bpf != 0); #endif /* If for us, accept and hand up to BPF */ if (ether_equal(eh->ether_dhost, ie->arpcom.ac_enaddr)) return (1); -#if NBPFILTER > 0 +#if NBPF > 0 if (*to_bpf) *to_bpf = 2; /* we don't need to see it */ #endif @@ -1142,7 +1142,7 @@ for (i = 0; i < ie->mcast_count; i++) { if (ether_equal(eh->ether_dhost, (u_char *)&ie->mcast_addrs[i])) { -#if NBPFILTER > 0 +#if NBPF > 0 if (*to_bpf) *to_bpf = 1; #endif @@ -1156,7 +1156,7 @@ * Acting as a multicast router, and BPF running at the same * time. Whew! (Hope this is a fast machine...) */ -#if NBPFILTER > 0 +#if NBPF > 0 *to_bpf = (ie->arpcom.ac_if.if_bpf != 0); #endif /* We want to see multicasts. */ @@ -1168,7 +1168,7 @@ return (1); /* Anything else goes to BPF but nothing else. */ -#if NBPFILTER > 0 +#if NBPF > 0 if (*to_bpf) *to_bpf = 2; #endif @@ -1183,7 +1183,7 @@ * for the multicast filter), but it will do in this case, * and we want to get out of here as quickly as possible. */ -#if NBPFILTER > 0 +#if NBPF > 0 *to_bpf = (ie->arpcom.ac_if.if_bpf != 0); #endif return (1); @@ -1420,7 +1420,7 @@ struct mbuf *m = 0; struct ether_header eh; -#if NBPFILTER > 0 +#if NBPF > 0 int bpf_gets_it = 0; #endif @@ -1439,7 +1439,7 @@ ie->rfhead = (ie->rfhead + 1) % ie->nframes; if (rfd.ie_fd_status & IE_FD_OK) { -#if NBPFILTER > 0 +#if NBPF > 0 if (ieget(unit, ie, &m, &eh, &bpf_gets_it)) { #else if (ieget(unit, ie, &m, &eh, (int *)0)) { @@ -1466,7 +1466,7 @@ m_freem(last_not_for_us); last_not_for_us = 0; } -#if NBPFILTER > 0 +#if NBPF > 0 /* * Check for a BPF filter; if so, hand it up. Note that we have to * stick an extra mbuf up front, because bpf_mtap expects to have @@ -1494,7 +1494,7 @@ last_not_for_us = m; return; } -#endif /* NBPFILTER > 0 */ +#endif /* NBPF > 0 */ /* * In here there used to be code to check destination addresses upon * receipt of a packet. We have deleted that code, and replaced it @@ -1578,7 +1578,7 @@ m_freem(m0); len = max(len, ETHER_MIN_LEN); -#if NBPFILTER > 0 +#if NBPF > 0 /* * See if bpf is listening on this interface, let it see the * packet before we commit it to the wire. Index: src/sys/i386/isa/if_le.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_le.c,v retrieving revision 1.50 diff -u -r1.50 if_le.c --- if_le.c 1999/05/11 19:54:12 1.50 +++ if_le.c 1999/07/02 08:09:12 @@ -52,7 +52,7 @@ #include #include -#include "bpfilter.h" +#include "bpf.h" #ifdef INET #include @@ -77,7 +77,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -370,7 +370,7 @@ ifp->if_addrlen = 6; ifp->if_hdrlen = 14; -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -412,7 +412,7 @@ } MEMCPY(&eh, seg1, sizeof(eh)); -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->le_if.if_bpf != NULL && seg2 == NULL) { bpf_tap(&sc->le_if, seg1, total_len); /* @@ -469,7 +469,7 @@ MEMCPY(mtod(m, caddr_t), seg1, len1); if (seg2 != NULL) MEMCPY(mtod(m, caddr_t) + len1, seg2, total_len - len1); -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->le_if.if_bpf != NULL && seg2 != NULL) { bpf_mtap(&sc->le_if, m); /* @@ -1142,7 +1142,7 @@ LE_OUTB(sc, LEMAC_REG_TQ, tx_pg); /* tell chip to transmit this packet */ -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->le_if.if_bpf) bpf_mtap(&sc->le_if, m); #endif Index: src/sys/i386/isa/if_lnc.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_lnc.c,v retrieving revision 1.60 diff -u -r1.60 if_lnc.c --- if_lnc.c 1999/05/09 23:24:47 1.60 +++ if_lnc.c 1999/07/02 08:09:12 @@ -64,7 +64,7 @@ #include "lnc.h" #if NLNC > 0 -#include "bpfilter.h" +#include "bpf.h" #include "opt_inet.h" /* Some defines that should really be in generic locations */ @@ -88,7 +88,7 @@ #include #endif -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -613,7 +613,7 @@ eh = (struct ether_header *) head->m_data; -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->arpcom.ac_if.if_bpf) bpf_mtap(&sc->arpcom.ac_if, head); #endif @@ -1295,7 +1295,7 @@ printf("%s", ic_ident[sc->nic.ic]); printf(" address %6D\n", sc->arpcom.ac_enaddr, ":"); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(&sc->arpcom.ac_if, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -1809,7 +1809,7 @@ ifp->if_timer = 2; -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->arpcom.ac_if.if_bpf) bpf_mtap(&sc->arpcom.ac_if, head); #endif Index: src/sys/i386/isa/if_lnc.h =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_lnc.h,v retrieving revision 1.10 diff -u -r1.10 if_lnc.h --- if_lnc.h 1999/01/31 00:56:32 1.10 +++ if_lnc.h 1999/07/02 08:08:52 @@ -39,7 +39,7 @@ * Initialize multicast address hashing registers to accept * all multicasts (only used when in promiscuous mode) */ -#if NBPFILTER > 0 +#if NBPF > 0 #define MULTI_INIT_ADDR 0xff #else #define MULTI_INIT_ADDR 0 Index: src/sys/i386/isa/if_rdp.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_rdp.c,v retrieving revision 1.3 diff -u -r1.3 if_rdp.c --- if_rdp.c 1999/01/12 00:36:31 1.3 +++ if_rdp.c 1999/07/02 08:09:12 @@ -62,7 +62,7 @@ */ #include "rdp.h" -#include "bpfilter.h" +#include "bpf.h" #include #include @@ -89,7 +89,7 @@ #include #endif -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -629,7 +629,7 @@ /* * If BPF is in the kernel, call the attach for it */ -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif return 1; @@ -814,7 +814,7 @@ /* * Tap off here if there is a bpf listener. */ -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) { bpf_mtap(ifp, m); } @@ -862,7 +862,7 @@ } } -#if NBPFILTER > 0 +#if NBPF > 0 /* * Promiscuous flag may have changed, propagage this * to the NIC. @@ -1164,7 +1164,7 @@ outb(sc->baseaddr + lpt_control, Ctrl_SelData); WrNib(sc, CMR1, CMR1_RDPAC); -#if NBPFILTER > 0 +#if NBPF > 0 /* * Check if there's a BPF listener on this interface. If so, hand off Index: src/sys/i386/isa/if_sr.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_sr.c,v retrieving revision 1.23 diff -u -r1.23 if_sr.c --- if_sr.c 1999/05/06 22:14:46 1.23 +++ if_sr.c 1999/07/02 08:09:13 @@ -53,7 +53,7 @@ #else #define NFR 0 #endif -#include "bpfilter.h" +#include "bpf.h" #include "sppp.h" #if NSPPP <= 0 @@ -71,7 +71,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -848,7 +848,7 @@ if_attach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_PPP, PPP_HEADER_LEN); #endif } @@ -1119,7 +1119,7 @@ sc->unit, mtx, len); #endif -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) bpf_mtap(ifp, mtx); #endif @@ -2462,7 +2462,7 @@ */ sr_copy_rxbuf(m, sc, len); /* copy from DPRAM */ -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) bpf_mtap(ifp, m); #endif Index: src/sys/i386/isa/if_wi.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_wi.c,v retrieving revision 1.6 diff -u -r1.6 if_wi.c --- if_wi.c 1999/06/06 16:44:04 1.6 +++ if_wi.c 1999/07/02 08:09:13 @@ -67,7 +67,7 @@ #define WI_HERMES_AUTOINC_WAR /* Work around data write autoinc bug. */ #define WI_HERMES_STATS_WAR /* Work around stats counter bug. */ -#include "bpfilter.h" +#include "bpf.h" #include "card.h" #include "wi.h" @@ -94,7 +94,7 @@ #include #endif -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -363,7 +363,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -446,7 +446,7 @@ ifp->if_ipackets++; -#if NBPFILTER > 0 +#if NBPF > 0 /* Handle BPF listeners. */ if (ifp->if_bpf) { bpf_mtap(ifp, m); @@ -1222,7 +1222,7 @@ m0->m_pkthdr.len + 2); } -#if NBPFILTER > 0 +#if NBPF > 0 /* * If there's a BPF listner, bounce a copy of * this frame to him. Index: src/sys/i386/isa/if_wl.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_wl.c,v retrieving revision 1.21 diff -u -r1.21 if_wl.c --- if_wl.c 1999/04/27 11:15:02 1.21 +++ if_wl.c 1999/07/02 08:09:13 @@ -190,7 +190,7 @@ #include "wl.h" #include "opt_wavelan.h" -#include "bpfilter.h" +#include "bpf.h" #include "opt_inet.h" #include @@ -214,7 +214,7 @@ #include #endif -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -510,7 +510,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -895,7 +895,7 @@ ifp = &(sc->wl_if); IF_DEQUEUE(&ifp->if_snd, m); if (m != (struct mbuf *)0) { -#if NBPFILTER > 0 +#if NBPF > 0 /* let BPF see it before we commit it */ if (ifp->if_bpf) { bpf_mtap(ifp, m); @@ -1080,7 +1080,7 @@ m->m_pkthdr.len = clen; -#if NBPFILTER > 0 +#if NBPF > 0 /* * Check if there's a BPF listener on this interface. If so, hand off * the raw packet to bpf. Index: src/sys/i386/isa/if_ze.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_ze.c,v retrieving revision 1.58 diff -u -r1.58 if_ze.c --- if_ze.c 1999/05/06 18:43:58 1.58 +++ if_ze.c 1999/07/02 08:09:13 @@ -64,7 +64,7 @@ #include "ze.h" #if NZE > 0 -#include "bpfilter.h" +#include "bpf.h" #include "opt_inet.h" #include "opt_ipx.h" @@ -92,7 +92,7 @@ #include #endif -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -650,7 +650,7 @@ /* * If BPF is in the kernel, call the attach for it */ -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -871,7 +871,7 @@ for (i = 0; i < ETHER_ADDR_LEN; ++i) outb(sc->nic_addr + ED_P1_PAR0 + i, sc->arpcom.ac_enaddr[i]); -#if NBPFILTER > 0 +#if NBPF > 0 /* * Initialize multicast address hashing registers to accept * all multicasts (only used when in promiscuous mode) @@ -1042,7 +1042,7 @@ /* * If there is BPF support in the configuration, tap off here. */ -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) { bpf_mtap(ifp, m0); } @@ -1434,7 +1434,7 @@ ((ifp->if_flags & IFF_RUNNING) == 0)) ze_init(ifp->if_unit); } -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_flags & IFF_PROMISC) { /* * Set promiscuous mode on interface. @@ -1518,7 +1518,7 @@ m = ze_ring_to_mbuf(sc, buf, m, len); if (m == NULL) goto bad; -#if NBPFILTER > 0 +#if NBPF > 0 /* * Check if there's a BPF listener on this interface. * If so, hand off the raw packet to bpf. Index: src/sys/i386/isa/if_zp.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_zp.c,v retrieving revision 1.51 diff -u -r1.51 if_zp.c --- if_zp.c 1999/04/19 06:56:24 1.51 +++ if_zp.c 1999/07/02 08:09:13 @@ -114,7 +114,7 @@ #include "zp.h" -#include "bpfilter.h" +#include "bpf.h" #include "opt_inet.h" #include "opt_ipx.h" @@ -145,7 +145,7 @@ #include #endif -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -568,7 +568,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif #if NAPM > 0 @@ -761,7 +761,7 @@ while (pad--) outb(BASE + EP_W1_TX_PIO_WR_1, 0); /* Padding */ -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->arpcom.ac_if.if_bpf) { bpf_mtap(&sc->arpcom.ac_if, top); } @@ -975,7 +975,7 @@ outw(BASE + EP_COMMAND, RX_DISCARD_TOP_PACK); while (inw(BASE + EP_STATUS) & S_COMMAND_IN_PROGRESS); ++sc->arpcom.ac_if.if_ipackets; -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->arpcom.ac_if.if_bpf) { bpf_mtap(&sc->arpcom.ac_if, top); Index: src/sys/i4b/driver/i4b_ipr.c =================================================================== RCS file: /home/ncvs/src/sys/i4b/driver/i4b_ipr.c,v retrieving revision 1.4 diff -u -r1.4 i4b_ipr.c --- i4b_ipr.c 1999/05/20 10:08:58 1.4 +++ i4b_ipr.c 1999/07/02 08:09:13 @@ -110,8 +110,8 @@ /* undef to uncompress in the mbuf itself */ #endif /* IPR_VJ */ -#include "bpfilter.h" -#if NBPFILTER > 0 +#include "bpf.h" +#if NBPF > 0 #include #include #endif @@ -350,7 +350,7 @@ if_attach(&sc->sc_if); -#if NBPFILTER > 0 +#if NBPF > 0 #ifdef __FreeBSD__ bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int)); #else @@ -994,7 +994,7 @@ sc->sc_inb += m->m_pkthdr.len; #endif -#if NBPFILTER > 0 +#if NBPF > 0 if(sc->sc_if.if_bpf) { /* prepend the address family as a four byte field */ @@ -1010,7 +1010,7 @@ bpf_mtap(sc->sc_if.if_bpf, &mm); #endif } -#endif /* NBPFILTER > 0 */ +#endif /* NBPF > 0 */ if(IF_QFULL(&ipintrq)) { @@ -1062,7 +1062,7 @@ microtime(&sc->sc_if.if_lastchange); -#if NBPFILTER > 0 +#if NBPF > 0 if(sc->sc_if.if_bpf) { /* prepend the address family as a four byte field */ @@ -1079,7 +1079,7 @@ bpf_mtap(sc->sc_if.if_bpf, &mm); #endif } -#endif /* NBPFILTER */ +#endif /* NBPF */ #if I4BIPRACCT sc->sc_outb += m->m_pkthdr.len; /* size before compression */ Index: src/sys/i4b/driver/i4b_isppp.c =================================================================== RCS file: /home/ncvs/src/sys/i4b/driver/i4b_isppp.c,v retrieving revision 1.3 diff -u -r1.3 i4b_isppp.c --- i4b_isppp.c 1999/05/20 10:09:01 1.3 +++ i4b_isppp.c 1999/07/02 08:09:13 @@ -74,8 +74,8 @@ #include #include -#include "bpfilter.h" -#if NBPFILTER > 0 +#include "bpf.h" +#if NBPF > 0 #include #include #endif @@ -290,7 +290,7 @@ sppp_attach(&sc->sc_if); if_attach(&sc->sc_if); -#if NBPFILTER > 0 +#if NBPF > 0 #ifdef __FreeBSD__ bpfattach(&sc->sc_if, DLT_PPP, PPP_HDRLEN); CALLOUT_INIT(&sc->sc_ch); @@ -361,7 +361,7 @@ while ((m = sppp_dequeue(&sc->sc_if)) != NULL) { -#if NBPFILTER > 0 +#if NBPF > 0 #ifdef __FreeBSD__ if (ifp->if_bpf) bpf_mtap(ifp, m); @@ -371,7 +371,7 @@ if (ifp->if_bpf) bpf_mtap(ifp->if_bpf, m); #endif -#endif /* NBPFILTER > 0 */ +#endif /* NBPF > 0 */ microtime(&ifp->if_lastchange); @@ -654,7 +654,7 @@ printf("i4bisppp_rx_data_ready: received packet!\n"); #endif -#if NBPFILTER > 0 +#if NBPF > 0 #ifdef __FreeBSD__ if(sc->sc_if.if_bpf) @@ -666,7 +666,7 @@ bpf_mtap(sc->sc_if.if_bpf, m); #endif -#endif /* NBPFILTER > 0 */ +#endif /* NBPF > 0 */ s = splimp(); Index: src/sys/modules/fxp/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/fxp/Makefile,v retrieving revision 1.2 diff -u -r1.2 Makefile --- Makefile 1999/04/18 13:31:23 1.2 +++ Makefile 1999/07/02 08:09:13 @@ -3,15 +3,15 @@ S = ${.CURDIR}/../.. .PATH: $S/pci KMOD = fxp -SRCS = if_fxp.c fxp.h bpfilter.h opt_bdg.h device_if.h bus_if.h pci_if.h -CLEANFILES += fxp.h bpfilter.h opt_bdg.h device_if.h bus_if.h pci_if.h +SRCS = if_fxp.c fxp.h bpf.h opt_bdg.h device_if.h bus_if.h pci_if.h +CLEANFILES += fxp.h bpf.h opt_bdg.h device_if.h bus_if.h pci_if.h CFLAGS += ${DEBUG_FLAGS} fxp.h: echo "#define NFXP 1" > fxp.h -bpfilter.h: - echo "#define NBPFILTER 0" > bpfilter.h +bpf.h: + echo "#define NBPF 0" > bpf.h opt_bdg.h: touch opt_bdg.h Index: src/sys/modules/if_disc/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/if_disc/Makefile,v retrieving revision 1.7 diff -u -r1.7 Makefile --- Makefile 1999/04/28 01:17:58 1.7 +++ Makefile 1999/07/02 08:09:13 @@ -2,16 +2,16 @@ .PATH: ${.CURDIR}/../../net KMOD= if_disc -SRCS= if_disc.c bpfilter.h opt_inet.h +SRCS= if_disc.c bpf.h opt_inet.h NOMAN= -NBPFILTER?= 1 +NBPF?= 1 CFLAGS+= ${PROTOS} -CLEANFILES+= bpfilter.h opt_inet.h +CLEANFILES+= bpf.h opt_inet.h -bpfilter.h: - echo "#define NBPFILTER ${NBPFILTER}" > bpfilter.h +bpf.h: + echo "#define NBPF ${NBPF}" > bpf.h opt_inet.h: echo "#define INET 1" > opt_inet.h Index: src/sys/modules/if_ppp/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/if_ppp/Makefile,v retrieving revision 1.17 diff -u -r1.17 Makefile --- Makefile 1999/04/28 01:18:02 1.17 +++ Makefile 1999/07/02 08:09:13 @@ -3,7 +3,7 @@ .PATH: ${.CURDIR}/../../net KMOD= if_ppp SRCS= if_ppp.c ppp_tty.c slcompress.c \ - bpfilter.h ppp.h opt_inet.h opt_ipx.h opt_ppp.h vnode_if.h + bpf.h ppp.h opt_inet.h opt_ipx.h opt_ppp.h vnode_if.h NOMAN= CLEANFILES+= vnode_if.c vnode_if.h @@ -23,10 +23,10 @@ SRCS+= ppp_deflate.c zlib.c .endif -CLEANFILES+= bpfilter.h opt_inet.h opt_ipx.h opt_ppp.h ppp.h +CLEANFILES+= bpf.h opt_inet.h opt_ipx.h opt_ppp.h ppp.h -bpfilter.h: - echo "#define NBPFILTER ${PPP_FILTER}" > bpfilter.h +bpf.h: + echo "#define NBPF ${PPP_FILTER}" > bpf.h ppp.h: echo "#define NPPP ${NPPP}" > ppp.h Index: src/sys/modules/if_sl/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/if_sl/Makefile,v retrieving revision 1.8 diff -u -r1.8 Makefile --- Makefile 1999/04/28 01:18:05 1.8 +++ Makefile 1999/07/02 08:09:13 @@ -2,18 +2,18 @@ .PATH: ${.CURDIR}/../../net KMOD= if_sl -SRCS= if_sl.c slcompress.c bpfilter.h opt_inet.h sl.h +SRCS= if_sl.c slcompress.c bpf.h opt_inet.h sl.h NOMAN= -NBPFILTER?= 1 +NBPF?= 1 NSL?= 2 PROTOS?= -DINET CFLAGS+= ${PROTOS} -CLEANFILES+= bpfilter.h opt_inet.h sl.h +CLEANFILES+= bpf.h opt_inet.h sl.h -bpfilter.h: - echo "#define NBPFILTER ${NBPFILTER}" > bpfilter.h +bpf.h: + echo "#define NBPF ${NBPF}" > bpf.h opt_inet.h: echo "#define INET 1" > opt_inet.h Index: src/sys/modules/if_tun/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/if_tun/Makefile,v retrieving revision 1.9 diff -u -r1.9 Makefile --- Makefile 1999/04/28 01:18:08 1.9 +++ Makefile 1999/07/02 08:09:13 @@ -2,18 +2,18 @@ .PATH: ${.CURDIR}/../../net KMOD= if_tun -SRCS= if_tun.c bpfilter.h opt_devfs.h opt_inet.h tun.h vnode_if.h +SRCS= if_tun.c bpf.h opt_devfs.h opt_inet.h tun.h vnode_if.h NOMAN= CLEANFILES+= vnode_if.h vnode_if.c -NBPFILTER?= 1 +NBPF?= 1 NTUN?= 2 CFLAGS+= ${PROTOS} -CLEANFILES+= bpfilter.h opt_devfs.h opt_inet.h tun.h +CLEANFILES+= bpf.h opt_devfs.h opt_inet.h tun.h -bpfilter.h: - echo "#define NBPFILTER ${NBPFILTER}" > bpfilter.h +bpf.h: + echo "#define NBPF ${NBPF}" > bpf.h opt_devfs.h: touch opt_devfs.h Index: src/sys/net/bpf.c =================================================================== RCS file: /home/ncvs/src/sys/net/bpf.c,v retrieving revision 1.51 diff -u -r1.51 bpf.c --- bpf.c 1999/05/31 11:28:08 1.51 +++ bpf.c 1999/07/02 08:09:13 @@ -40,7 +40,7 @@ * $Id: bpf.c,v 1.51 1999/05/31 11:28:08 phk Exp $ */ -#include "bpfilter.h" +#include "bpf.h" #ifndef __GNUC__ #define inline @@ -84,7 +84,7 @@ #include #endif /*DEVFS*/ -#if NBPFILTER > 0 +#if NBPF > 0 /* * Older BSDs don't have kernel malloc. @@ -114,7 +114,7 @@ * bpf_dtab holds the descriptors, indexed by minor device # */ static struct bpf_if *bpf_iflist; -static struct bpf_d bpf_dtab[NBPFILTER]; +static struct bpf_d bpf_dtab[NBPF]; static int bpf_dtab_init; static int bpf_allocbufs __P((struct bpf_d *)); @@ -366,7 +366,7 @@ if (p->p_prison) return (EPERM); - if (minor(dev) >= NBPFILTER) + if (minor(dev) >= NBPF) return (ENXIO); /* * Each minor can be opened by only one process. If the requested @@ -1286,7 +1286,7 @@ * Mark all the descriptors free if this hasn't been done. */ if (!bpf_dtab_init) { - for (i = 0; i < NBPFILTER; ++i) + for (i = 0; i < NBPF; ++i) D_MARKFREE(&bpf_dtab[i]); bpf_dtab_init = 1; } @@ -1296,7 +1296,7 @@ } #ifdef DEVFS -static void *bpf_devfs_token[NBPFILTER]; +static void *bpf_devfs_token[NBPF]; #endif static int bpf_devsw_installed; @@ -1315,7 +1315,7 @@ bpf_devsw_installed = 1; #ifdef DEVFS - for ( i = 0 ; i < NBPFILTER ; i++ ) { + for ( i = 0 ; i < NBPF ; i++ ) { bpf_devfs_token[i] = devfs_add_devswf(&bpf_cdevsw, i, DV_CHR, 0, 0, 0600, "bpf%d", i); @@ -1326,7 +1326,7 @@ SYSINIT(bpfdev,SI_SUB_DRIVERS,SI_ORDER_MIDDLE+CDEV_MAJOR,bpf_drvinit,NULL) -#else /* !BPFILTER */ +#else /* !BPF */ /* * NOP stubs to allow bpf-using drivers to load and function. * Index: src/sys/net/if_disc.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_disc.c,v retrieving revision 1.21 diff -u -r1.21 if_disc.c --- if_disc.c 1998/12/14 01:59:16 1.21 +++ if_disc.c 1999/07/02 08:09:14 @@ -51,7 +51,7 @@ #include #include -#include "bpfilter.h" +#include "bpf.h" #include "opt_inet.h" #ifdef TINY_DSMTU @@ -85,7 +85,7 @@ ifp->if_hdrlen = 0; ifp->if_addrlen = 0; if_attach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_NULL, sizeof(u_int)); #endif } @@ -99,7 +99,7 @@ { if ((m->m_flags & M_PKTHDR) == 0) panic("discoutput no HDR"); -#if NBPFILTER > 0 +#if NBPF > 0 /* BPF write needs to be handled specially */ if (dst->sa_family == AF_UNSPEC) { dst->sa_family = *(mtod(m, int *)); Index: src/sys/net/if_fddisubr.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_fddisubr.c,v retrieving revision 1.34 diff -u -r1.34 if_fddisubr.c --- if_fddisubr.c 1999/01/27 22:42:13 1.34 +++ if_fddisubr.c 1999/07/02 08:09:14 @@ -105,7 +105,7 @@ extern struct ifqueue pkintrq; #endif -#include "bpfilter.h" +#include "bpf.h" #define senderr(e) { error = (e); goto bad;} @@ -309,7 +309,7 @@ break; } -#if NBPFILTER > 0 +#if NBPF > 0 case AF_IMPLINK: { fh = mtod(m, struct fddi_header *); Index: src/sys/net/if_iso88025subr.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_iso88025subr.c,v retrieving revision 1.2 diff -u -r1.2 if_iso88025subr.c --- if_iso88025subr.c 1999/03/10 10:11:43 1.2 +++ if_iso88025subr.c 1999/07/02 08:08:54 @@ -68,7 +68,7 @@ #include #endif -#if NBPFILTER > 0 +#if NBPF > 0 #include #include #endif Index: src/sys/net/if_loop.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_loop.c,v retrieving revision 1.38 diff -u -r1.38 if_loop.c --- if_loop.c 1999/02/20 21:03:53 1.38 +++ if_loop.c 1999/07/02 08:09:14 @@ -82,8 +82,8 @@ #include #endif NETATALK -#include "bpfilter.h" -#if NBPFILTER > 0 +#include "bpf.h" +#if NBPF > 0 #include #endif @@ -122,7 +122,7 @@ ifp->if_type = IFT_LOOP; ifp->if_snd.ifq_maxlen = ifqmaxlen; if_attach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_NULL, sizeof(u_int)); #endif } @@ -186,7 +186,7 @@ if ((m->m_flags & M_PKTHDR) == 0) panic("if_simloop: no HDR"); m->m_pkthdr.rcvif = ifp; -#if NBPFILTER > 0 +#if NBPF > 0 /* BPF write needs to be handled specially */ if (dst->sa_family == AF_UNSPEC) { dst->sa_family = *(mtod(m, int *)); Index: src/sys/net/if_ppp.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_ppp.c,v retrieving revision 1.60 diff -u -r1.60 if_ppp.c --- if_ppp.c 1999/04/27 11:17:00 1.60 +++ if_ppp.c 1999/07/02 08:09:14 @@ -112,12 +112,12 @@ #include #endif -#include "bpfilter.h" -#if NBPFILTER > 0 +#include "bpf.h" +#if NBPF > 0 #include #endif -#if defined(PPP_FILTER) && NBPFILTER == 0 +#if defined(PPP_FILTER) && NBPF == 0 #error "PPP_FILTER requires bpf" #endif @@ -221,7 +221,7 @@ sc->sc_fastq.ifq_maxlen = IFQ_MAXLEN; sc->sc_rawq.ifq_maxlen = IFQ_MAXLEN; if_attach(&sc->sc_if); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(&sc->sc_if, DLT_PPP, PPP_HDRLEN); #endif } @@ -828,7 +828,7 @@ #endif /* PPP_FILTER */ } -#if NBPFILTER > 0 +#if NBPF > 0 /* * See if bpf wants to look at the packet. */ @@ -1463,7 +1463,7 @@ #endif /* PPP_FILTER */ } -#if NBPFILTER > 0 +#if NBPF > 0 /* See if bpf wants to look at the packet. */ if (sc->sc_if.if_bpf) bpf_mtap(&sc->sc_if, m); Index: src/sys/net/if_sl.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_sl.c,v retrieving revision 1.74 diff -u -r1.74 if_sl.c --- if_sl.c 1999/04/27 11:17:02 1.74 +++ if_sl.c 1999/07/02 08:09:14 @@ -68,7 +68,7 @@ #include "sl.h" #if NSL > 0 -#include "bpfilter.h" +#include "bpf.h" #include "opt_inet.h" #if !defined(ACTUALLY_LKM_NOT_KERNEL) && !defined(KLD_MODULE) #include "opt_slip.h" @@ -105,7 +105,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -150,7 +150,7 @@ * time. So, setting SLIP_HIWAT to ~100 guarantees that we'll lose * at most 1% while maintaining good interactive response. */ -#if NBPFILTER > 0 +#if NBPF > 0 #define BUFOFFSET (128+sizeof(struct ifnet **)+SLIP_HDRLEN) #else #define BUFOFFSET (128+sizeof(struct ifnet **)) @@ -232,7 +232,7 @@ sc->sc_if.if_linkmib = sc; sc->sc_if.if_linkmiblen = sizeof *sc; if_attach(&sc->sc_if); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(&sc->sc_if, DLT_SLIP, SLIP_HDRLEN); #endif } @@ -538,7 +538,7 @@ register struct ip *ip; int s; struct mbuf *m2; -#if NBPFILTER > 0 +#if NBPF > 0 u_char bpfbuf[SLTMAX + SLIP_HDRLEN]; register int len = 0; #endif @@ -583,7 +583,7 @@ * queueing, and the connection id compression will get * munged when this happens. */ -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->sc_if.if_bpf) { /* * We need to save the TCP/IP header before it's @@ -612,7 +612,7 @@ *mtod(m, u_char *) |= sl_compress_tcp(m, ip, &sc->sc_comp, 1); } -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->sc_if.if_bpf) { /* * Put the SLIP pseudo-"link header" in place. The @@ -775,7 +775,7 @@ register struct mbuf *m; register int len; int s; -#if NBPFILTER > 0 +#if NBPF > 0 u_char chdr[CHDR_LEN]; #endif @@ -844,7 +844,7 @@ /* less than min length packet - ignore */ goto newpack; -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->sc_if.if_bpf) { /* * Save the compressed header, so we @@ -885,7 +885,7 @@ } else goto error; } -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->sc_if.if_bpf) { /* * Put the SLIP pseudo-"link header" in place. Index: src/sys/net/if_tun.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_tun.c,v retrieving revision 1.59 diff -u -r1.59 if_tun.c --- if_tun.c 1999/06/19 18:42:28 1.59 +++ if_tun.c 1999/07/02 08:09:14 @@ -54,8 +54,8 @@ #include #endif -#include "bpfilter.h" -#if NBPFILTER > 0 +#include "bpf.h" +#if NBPF > 0 #include #endif @@ -144,7 +144,7 @@ ifp->if_flags = IFF_POINTOPOINT | IFF_MULTICAST; ifp->if_snd.ifq_maxlen = ifqmaxlen; if_attach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_NULL, sizeof(u_int)); #endif } @@ -340,7 +340,7 @@ return EHOSTDOWN; } -#if NBPFILTER > 0 +#if NBPF > 0 /* BPF write needs to be handled specially */ if (dst->sa_family == AF_UNSPEC) { dst->sa_family = *(mtod(m0, int *)); @@ -366,7 +366,7 @@ bpf_mtap(ifp, &m); } -#endif /* NBPFILTER > 0 */ +#endif /* NBPF > 0 */ /* prepend sockaddr? this may abort if the mbuf allocation fails */ if (tp->tun_flags & TUN_LMODE) { @@ -628,7 +628,7 @@ top->m_pkthdr.len = tlen; top->m_pkthdr.rcvif = ifp; -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) { /* * We need to prepend the address family as Index: src/sys/net/if_vlan.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_vlan.c,v retrieving revision 1.7 diff -u -r1.7 if_vlan.c --- if_vlan.c 1999/04/07 23:26:43 1.7 +++ if_vlan.c 1999/07/02 08:09:14 @@ -57,7 +57,7 @@ #include "vlan.h" #if NVLAN > 0 #include "opt_inet.h" -#include "bpfilter.h" +#include "bpf.h" #include #include @@ -69,7 +69,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif #include @@ -176,7 +176,7 @@ ifp->if_snd.ifq_maxlen = ifqmaxlen; if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif /* Now undo some of the damage... */ @@ -209,10 +209,10 @@ IF_DEQUEUE(&ifp->if_snd, m); if (m == 0) break; -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) bpf_mtap(ifp, m); -#endif /* NBPFILTER > 0 */ +#endif /* NBPF > 0 */ /* * If the LINK0 flag is set, it means the underlying interface @@ -304,7 +304,7 @@ */ m->m_pkthdr.rcvif = &ifv->ifv_if; -#if NBPFILTER > 0 +#if NBPF > 0 if (ifv->ifv_if.if_bpf) { /* * Do the usual BPF fakery. Note that we don't support @@ -356,7 +356,7 @@ m->m_len -= EVL_ENCAPLEN; m->m_pkthdr.len -= EVL_ENCAPLEN; -#if NBPFILTER > 0 +#if NBPF > 0 if (ifv->ifv_if.if_bpf) { /* * Do the usual BPF fakery. Note that we don't support Index: src/sys/pc98/conf/GENERIC98 =================================================================== RCS file: /home/ncvs/src/sys/pc98/conf/GENERIC98,v retrieving revision 1.77 diff -u -r1.77 GENERIC98 --- GENERIC98 1999/06/18 14:48:18 1.77 +++ GENERIC98 1999/07/02 08:09:14 @@ -262,8 +262,8 @@ options SYSVSEM -# The `bpfilter' pseudo-device enables the Berkeley Packet Filter. Be +# The `bpf' pseudo-device enables the Berkeley Packet Filter. Be # aware of the legal and administrative consequences of enabling this # option. The number of devices determines the maximum number of # simultaneous BPF clients programs runnable. -#pseudo-device bpfilter 4 #Berkeley packet filter +#pseudo-device bpf 4 #Berkeley packet filter Index: src/sys/pc98/pc98/if_ed.c =================================================================== RCS file: /home/ncvs/src/sys/pc98/pc98/if_ed.c,v retrieving revision 1.63 diff -u -r1.63 if_ed.c --- if_ed.c 1999/05/10 09:06:12 1.63 +++ if_ed.c 1999/07/02 08:09:14 @@ -60,7 +60,7 @@ */ #include "ed.h" -#include "bpfilter.h" +#include "bpf.h" #include "pnp.h" #ifndef EXTRA_ED @@ -87,7 +87,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif #include "opt_bdg.h" @@ -2463,7 +2463,7 @@ /* * If BPF is in the kernel, call the attach for it */ -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif return 1; @@ -2929,7 +2929,7 @@ /* * Tap off here if there is a bpf listener. */ -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) { bpf_mtap(ifp, m0); } @@ -3371,7 +3371,7 @@ } } -#if NBPFILTER > 0 +#if NBPF > 0 /* * Promiscuous flag may have changed, so reprogram the RCR. @@ -3502,7 +3502,7 @@ struct ifnet *ifp ; int need_more = 1 ; /* in case not bpf */ -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->arpcom.ac_if.if_bpf) { need_more = 0 ; ed_ring_copy(sc, buf, (char *)eh, len); @@ -3533,7 +3533,7 @@ */ ed_ring_copy(sc, buf, (char *)eh, len); -#if NBPFILTER > 0 +#if NBPF > 0 /* * Check if there's a BPF listener on this interface. If so, hand off Index: src/sys/pc98/pc98/olpt.c =================================================================== RCS file: /home/ncvs/src/sys/pc98/pc98/olpt.c,v retrieving revision 1.1 diff -u -r1.1 olpt.c --- olpt.c 1999/06/18 14:48:26 1.1 +++ olpt.c 1999/07/02 08:09:14 @@ -145,8 +145,8 @@ #include #include #include -#include "bpfilter.h" -#if NBPFILTER > 0 +#include "bpf.h" +#if NBPF > 0 #include #endif #endif /* INET */ @@ -958,7 +958,7 @@ if_attach(ifp); printf("lp%d: TCP/IP capable interface\n", unit); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_NULL, LPIPHDRLEN); #endif } @@ -1232,7 +1232,7 @@ IF_DROP(&ipintrq); goto done; } -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->sc_if.if_bpf) { bpf_tap(&sc->sc_if, sc->sc_ifbuf, len); } @@ -1424,7 +1424,7 @@ } else { ifp->if_opackets++; ifp->if_obytes += m->m_pkthdr.len; -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) { /* * We need to prepend the packet type as Index: src/sys/pci/if_al.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_al.c,v retrieving revision 1.4 diff -u -r1.4 if_al.c --- if_al.c 1999/05/26 22:56:22 1.4 +++ if_al.c 1999/07/02 08:09:16 @@ -49,7 +49,7 @@ * has physical address and multicast address registers. */ -#include "bpfilter.h" +#include "bpf.h" #include #include @@ -65,7 +65,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -1066,7 +1066,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif at_shutdown(al_shutdown, sc, SHUTDOWN_POST_SYNC); @@ -1300,7 +1300,7 @@ ifp->if_ipackets++; eh = mtod(m, struct ether_header *); -#if NBPFILTER > 0 +#if NBPF > 0 /* * Handle BPF listeners. Let the BPF user see the packet, but * don't pass it up to the ether_input() layer unless it's @@ -1625,7 +1625,7 @@ /* Pack the data into the descriptor. */ al_encap(sc, cur_tx, m_head); -#if NBPFILTER > 0 +#if NBPF > 0 /* * If there's a BPF listener, bounce a copy of this frame * to him. Index: src/sys/pci/if_ax.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_ax.c,v retrieving revision 1.9 diff -u -r1.9 if_ax.c --- if_ax.c 1999/05/09 17:06:48 1.9 +++ if_ax.c 1999/07/02 08:09:14 @@ -49,7 +49,7 @@ * the registers. */ -#include "bpfilter.h" +#include "bpf.h" #include #include @@ -65,7 +65,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -1308,7 +1308,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif at_shutdown(ax_shutdown, sc, SHUTDOWN_POST_SYNC); @@ -1542,7 +1542,7 @@ ifp->if_ipackets++; eh = mtod(m, struct ether_header *); -#if NBPFILTER > 0 +#if NBPF > 0 /* * Handle BPF listeners. Let the BPF user see the packet, but * don't pass it up to the ether_input() layer unless it's @@ -1866,7 +1866,7 @@ if (cur_tx != start_tx) AX_TXOWN(cur_tx) = AX_TXSTAT_OWN; -#if NBPFILTER > 0 +#if NBPF > 0 /* * If there's a BPF listener, bounce a copy of this frame * to him. Index: src/sys/pci/if_de.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_de.c,v retrieving revision 1.106 diff -u -r1.106 if_de.c --- if_de.c 1999/05/10 14:12:26 1.106 +++ if_de.c 1999/07/02 08:09:14 @@ -93,8 +93,8 @@ #include #endif -#include "bpfilter.h" -#if NBPFILTER > 0 +#include "bpf.h" +#if NBPF > 0 #include #endif @@ -3539,7 +3539,7 @@ #endif /* TULIP_BUS_DMA */ eh = *mtod(ms, struct ether_header *); -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->tulip_bpf != NULL) { if (me == ms) TULIP_BPF_TAP(sc, mtod(ms, caddr_t), total_len); @@ -3810,7 +3810,7 @@ TULIP_TXMAP_POSTSYNC(sc, map); sc->tulip_txmaps[sc->tulip_txmaps_free++] = map; #endif /* TULIP_BUS_DMA */ -#if NBPFILTER > 0 +#if NBPF > 0 if (sc->tulip_bpf != NULL) TULIP_BPF_MTAP(sc, m); #endif @@ -5115,7 +5115,7 @@ #endif #endif /* __bsdi__ */ -#if NBPFILTER > 0 +#if NBPF > 0 TULIP_BPF_ATTACH(sc); #endif Index: src/sys/pci/if_devar.h =================================================================== RCS file: /home/ncvs/src/sys/pci/if_devar.h,v retrieving revision 1.13 diff -u -r1.13 if_devar.h --- if_devar.h 1999/05/26 23:05:23 1.13 +++ if_devar.h 1999/07/02 08:08:55 @@ -961,7 +961,7 @@ #endif #if BSD >= 199506 #define TULIP_IFP_TO_SOFTC(ifp) ((tulip_softc_t *)((ifp)->if_softc)) -#if NBPFILTER > 0 +#if NBPF > 0 #define TULIP_BPF_MTAP(sc, m) bpf_mtap(&(sc)->tulip_if, m) #define TULIP_BPF_TAP(sc, p, l) bpf_tap(&(sc)->tulip_if, p, l) #define TULIP_BPF_ATTACH(sc) bpfattach(&(sc)->tulip_if, DLT_EN10MB, sizeof(struct ether_header)) @@ -1115,7 +1115,7 @@ * While I think FreeBSD's 2.2 change to the bpf is a nice simplification, * it does add yet more conditional code to this driver. Sigh. */ -#if !defined(TULIP_BPF_MTAP) && NBPFILTER > 0 +#if !defined(TULIP_BPF_MTAP) && NBPF > 0 #define TULIP_BPF_MTAP(sc, m) bpf_mtap((sc)->tulip_bpf, m) #define TULIP_BPF_TAP(sc, p, l) bpf_tap((sc)->tulip_bpf, p, l) #define TULIP_BPF_ATTACH(sc) bpfattach(&(sc)->tulip_bpf, &(sc)->tulip_if, DLT_EN10MB, sizeof(struct ether_header)) Index: src/sys/pci/if_fxp.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_fxp.c,v retrieving revision 1.69 diff -u -r1.69 if_fxp.c --- if_fxp.c 1999/05/09 10:45:54 1.69 +++ if_fxp.c 1999/07/02 08:09:15 @@ -34,7 +34,7 @@ * Intel EtherExpress Pro/100B PCI Fast Ethernet driver */ -#include "bpfilter.h" +#include "bpf.h" #include #include @@ -52,7 +52,7 @@ #include #endif -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -419,7 +419,7 @@ */ ifp->if_snd.ifq_maxlen = FXP_NTXCB - 1; ether_ifattach(ifp, enaddr); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(&sc->sc_ethercom.ec_if.if_bpf, ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -598,7 +598,7 @@ */ ifp->if_snd.ifq_maxlen = FXP_NTXCB - 1; ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -988,7 +988,7 @@ sc->tx_queued++; -#if NBPFILTER > 0 +#if NBPF > 0 /* * Pass packet to bpf if there is a listener. */ @@ -1097,12 +1097,12 @@ m->m_pkthdr.len = m->m_len = total_len ; eh = mtod(m, struct ether_header *); -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) bpf_tap(FXP_BPFTAP_ARG(ifp), mtod(m, caddr_t), total_len); -#endif /* NBPFILTER > 0 */ +#endif /* NBPF > 0 */ #ifdef BRIDGE if (do_bridge) { struct ifnet *bdg_ifp ; Index: src/sys/pci/if_mx.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_mx.c,v retrieving revision 1.19 diff -u -r1.19 if_mx.c --- if_mx.c 1999/06/16 16:27:30 1.19 +++ if_mx.c 1999/07/02 08:09:15 @@ -56,7 +56,7 @@ * the NWAY support. */ -#include "bpfilter.h" +#include "bpf.h" #include #include @@ -72,7 +72,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -1563,7 +1563,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif at_shutdown(mx_shutdown, sc, SHUTDOWN_POST_SYNC); @@ -1777,7 +1777,7 @@ eh = mtod(m, struct ether_header *); m->m_pkthdr.rcvif = ifp; -#if NBPFILTER > 0 +#if NBPF > 0 /* * Handle BPF listeners. Let the BPF user see the packet, but * don't pass it up to the ether_input() layer unless it's @@ -2118,7 +2118,7 @@ if (cur_tx != start_tx) MX_TXOWN(cur_tx) = MX_TXSTAT_OWN; -#if NBPFILTER > 0 +#if NBPF > 0 /* * If there's a BPF listener, bounce a copy of this frame * to him. Index: src/sys/pci/if_pn.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_pn.c,v retrieving revision 1.21 diff -u -r1.21 if_pn.c --- if_pn.c 1999/05/28 18:43:10 1.21 +++ if_pn.c 1999/07/02 08:09:15 @@ -57,7 +57,7 @@ * 100BaseTX PHY. */ -#include "bpfilter.h" +#include "bpf.h" #include #include @@ -73,7 +73,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -1211,7 +1211,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif at_shutdown(pn_shutdown, sc, SHUTDOWN_POST_SYNC); @@ -1569,7 +1569,7 @@ eh = mtod(m, struct ether_header *); m->m_pkthdr.rcvif = ifp; -#if NBPFILTER > 0 +#if NBPF > 0 /* * Handle BPF listeners. Let the BPF user see the packet, but * don't pass it up to the ether_input() layer unless it's @@ -1900,7 +1900,7 @@ if (cur_tx != start_tx) PN_TXOWN(cur_tx) = PN_TXSTAT_OWN; -#if NBPFILTER > 0 +#if NBPF > 0 /* * If there's a BPF listener, bounce a copy of this frame * to him. Index: src/sys/pci/if_rl.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_rl.c,v retrieving revision 1.17 diff -u -r1.17 if_rl.c --- if_rl.c 1999/06/19 20:17:37 1.17 +++ if_rl.c 1999/07/02 08:09:15 @@ -83,7 +83,7 @@ * to select which interface to use depending on the chip type. */ -#include "bpfilter.h" +#include "bpf.h" #include #include @@ -99,7 +99,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -1234,7 +1234,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif at_shutdown(rl_shutdown, sc, SHUTDOWN_POST_SYNC); @@ -1417,7 +1417,7 @@ eh = mtod(m, struct ether_header *); ifp->if_ipackets++; -#if NBPFILTER > 0 +#if NBPF > 0 /* * Handle BPF listeners. Let the BPF user see the packet, but * don't pass it up to the ether_input() layer unless it's @@ -1614,7 +1614,7 @@ rl_encap(sc, m_head); -#if NBPFILTER > 0 +#if NBPF > 0 /* * If there's a BPF listener, bounce a copy of this frame * to him. Index: src/sys/pci/if_ti.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_ti.c,v retrieving revision 1.7 diff -u -r1.7 if_ti.c --- if_ti.c 1999/06/19 00:36:53 1.7 +++ if_ti.c 1999/07/02 08:09:15 @@ -78,7 +78,7 @@ * - Andrew Gallatin for providing FreeBSD/Alpha support. */ -#include "bpfilter.h" +#include "bpf.h" #include "vlan.h" #include @@ -96,7 +96,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -1735,7 +1735,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -1830,7 +1830,7 @@ eh = mtod(m, struct ether_header *); m->m_pkthdr.rcvif = ifp; -#if NBPFILTER > 0 +#if NBPF > 0 /* * Handle BPF listeners. Let the BPF user see the packet, but * don't pass it up to the ether_input() layer unless it's @@ -2113,7 +2113,7 @@ * If there's a BPF listener, bounce a copy of this frame * to him. */ -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) bpf_mtap(ifp, m_head); #endif Index: src/sys/pci/if_tl.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_tl.c,v retrieving revision 1.32 diff -u -r1.32 if_tl.c --- if_tl.c 1999/05/09 17:07:01 1.32 +++ if_tl.c 1999/07/02 08:09:15 @@ -178,7 +178,7 @@ * itself thereby reducing the load on the host CPU. */ -#include "bpfilter.h" +#include "bpf.h" #include #include @@ -194,7 +194,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -1786,7 +1786,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -1966,7 +1966,7 @@ continue; } -#if NBPFILTER > 0 +#if NBPF > 0 /* * Handle BPF listeners. Let the BPF user see the packet, but * don't pass it up to the ether_input() layer unless it's @@ -2434,7 +2434,7 @@ * If there's a BPF listener, bounce a copy of this frame * to him. */ -#if NBPFILTER > 0 +#if NBPF > 0 if (ifp->if_bpf) bpf_mtap(ifp, cur_tx->tl_mbuf); #endif Index: src/sys/pci/if_tx.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_tx.c,v retrieving revision 1.27 diff -u -r1.27 if_tx.c --- if_tx.c 1999/05/10 00:20:46 1.27 +++ if_tx.c 1999/07/02 08:09:15 @@ -67,7 +67,7 @@ } \ } -#include "bpfilter.h" +#include "bpf.h" #include "pci.h" #include "opt_bdg.h" @@ -107,7 +107,7 @@ #include #endif -#if NBPFILTER > 0 +#if NBPF > 0 #include #include #endif @@ -357,7 +357,7 @@ /* Attach os interface and bpf */ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(&sc->sc_if.if_bpf, ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -554,7 +554,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp,DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -850,7 +850,7 @@ /* Set watchdog timer */ ifp->if_timer = 8; -#if NBPFILTER > 0 +#if NBPF > 0 if( ifp->if_bpf ) #if defined(__FreeBSD__) bpf_mtap( ifp, m0 ); @@ -920,15 +920,15 @@ m->m_pkthdr.rcvif = &(sc->sc_if); m->m_pkthdr.len = m->m_len = len; -#if NBPFILTER > 0 - /* Give mbuf to BPFILTER */ +#if NBPF > 0 + /* Give mbuf to BPF */ if( sc->sc_if.if_bpf ) #if defined(__FreeBSD__) bpf_mtap( &sc->sc_if, m ); #else /* __OpenBSD__ */ bpf_mtap( sc->sc_if.if_bpf, m ); #endif /* __FreeBSD__ */ -#endif /* NBPFILTER */ +#endif /* NBPF */ #ifdef BRIDGE if (do_bridge) { @@ -951,7 +951,7 @@ } #endif -#if NBPFILTER > 0 +#if NBPF > 0 #ifdef BRIDGE /* * This deserves explanation @@ -961,7 +961,7 @@ * address of one of the other interfaces. * * But if the bridge is off, then we have to drop - * stuff that came in just via bpfilter. + * stuff that came in just via bpf. */ if (!do_bridge) #endif Index: src/sys/pci/if_vr.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_vr.c,v retrieving revision 1.11 diff -u -r1.11 if_vr.c --- if_vr.c 1999/05/09 17:07:03 1.11 +++ if_vr.c 1999/07/02 08:09:15 @@ -59,7 +59,7 @@ * transmission. */ -#include "bpfilter.h" +#include "bpf.h" #include #include @@ -75,7 +75,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -1110,7 +1110,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -1316,7 +1316,7 @@ eh = mtod(m, struct ether_header *); m->m_pkthdr.rcvif = ifp; m->m_pkthdr.len = m->m_len = total_len; -#if NBPFILTER > 0 +#if NBPF > 0 /* * Handle BPF listeners. Let the BPF user see the packet, but * don't pass it up to the ether_input() layer unless it's @@ -1621,7 +1621,7 @@ if (cur_tx != start_tx) VR_TXOWN(cur_tx) = VR_TXSTAT_OWN; -#if NBPFILTER > 0 +#if NBPF > 0 /* * If there's a BPF listener, bounce a copy of this frame * to him. Index: src/sys/pci/if_wb.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_wb.c,v retrieving revision 1.10 diff -u -r1.10 if_wb.c --- if_wb.c 1999/05/13 20:36:00 1.10 +++ if_wb.c 1999/07/02 08:09:15 @@ -83,7 +83,7 @@ * three of my test boards seems fine. */ -#include "bpfilter.h" +#include "bpf.h" #include #include @@ -99,7 +99,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -1228,7 +1228,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif at_shutdown(wb_shutdown, sc, SHUTDOWN_POST_SYNC); @@ -1423,7 +1423,7 @@ ifp->if_ipackets++; eh = mtod(m, struct ether_header *); -#if NBPFILTER > 0 +#if NBPF > 0 /* * Handle BPF listeners. Let the BPF user see the packet, but * don't pass it up to the ether_input() layer unless it's @@ -1772,7 +1772,7 @@ if (cur_tx != start_tx) WB_TXOWN(cur_tx) = WB_TXSTAT_OWN; -#if NBPFILTER > 0 +#if NBPF > 0 /* * If there's a BPF listener, bounce a copy of this frame * to him. Index: src/sys/pci/if_xl.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_xl.c,v retrieving revision 1.40 diff -u -r1.40 if_xl.c --- if_xl.c 1999/06/01 19:04:23 1.40 +++ if_xl.c 1999/07/02 08:09:15 @@ -89,7 +89,7 @@ * PCI-based NICs. */ -#include "bpfilter.h" +#include "bpf.h" #include #include @@ -105,7 +105,7 @@ #include #include -#if NBPFILTER > 0 +#if NBPF > 0 #include #endif @@ -1791,7 +1791,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER > 0 +#if NBPF > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif at_shutdown(xl_shutdown, sc, SHUTDOWN_POST_SYNC); @@ -1967,7 +1967,7 @@ m->m_pkthdr.rcvif = ifp; m->m_pkthdr.len = m->m_len = total_len; -#if NBPFILTER > 0 +#if NBPF > 0 /* Handle BPF listeners. Let the BPF user see the packet. */ if (ifp->if_bpf) bpf_mtap(ifp, m); @@ -1987,7 +1987,7 @@ } #endif -#if NBPFILTER > 0 +#if NBPF > 0 /* * Don't pass packet up to the ether_input() layer unless it's * a broadcast packet, multicast packet, matches our ethernet @@ -2381,7 +2381,7 @@ } prev = cur_tx; -#if NBPFILTER > 0 +#if NBPF > 0 /* * If there's a BPF listener, bounce a copy of this frame * to him. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 3 2:56:48 1999 Delivered-To: freebsd-net@freebsd.org Received: from des.follo.net (des.follo.net [195.204.143.216]) by hub.freebsd.org (Postfix) with ESMTP id 763A51536F; Sat, 3 Jul 1999 02:56:41 -0700 (PDT) (envelope-from des@des.follo.net) Received: (from des@localhost) by des.follo.net (8.9.3/8.9.3) id LAA54563; Sat, 3 Jul 1999 11:56:30 +0200 (CEST) (envelope-from des) To: hackers@freebsd.org Subject: netstat(1) / sockstat(1) field width adjustments Organization: Yes Interactive Visit-Us-At: http://www.yes.no/ From: Dag-Erling Smorgrav Date: 03 Jul 1999 11:56:30 +0200 Message-ID: Lines: 20 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Bcc:ed to net, please follow up on hackers] Attached are patches which widen the local/foreign address fields in netstat(1) (so as not to truncate the port number) and the protocol field in sockstat(1) (to accomodate 'divert'). The netstat patch has the unfortunate side effect of pushing the state field so far to the right that most states (except LISTEN) spill over. I consider that the lesser of two evils. I chopped two characters off the process name field to avoid a similar problem in sockstat. As usual, I welcome comments and suggestions, and will commit the patches to -CURRENT in a few days if no-one objects. The patches are by Ruslan Ermilov, with a few adjustment by yours truly. DES -- Dag-Erling Smorgrav - des@yes.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message