From owner-freebsd-net Sun Oct 21 14: 9:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id F415837B401 for ; Sun, 21 Oct 2001 14:09:10 -0700 (PDT) Received: from gont.gont.com.ar (ppp238-r5300-cap3.via-net-works.net.ar [200.16.145.31]) by ns1.via-net-works.net.ar (8.9.3/8.9.3) with ESMTP id SAA89208; Sun, 21 Oct 2001 18:09:29 -0300 (ART) Message-Id: <4.3.2.7.2.20011021061340.00d8bc80@mail.sitanium.com> X-Sender: ingroupcomar-fgont@mail.sitanium.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 21 Oct 2001 06:26:32 -0300 To: Mike Silbersack From: Fernando Gont Subject: Re: SYN flood and IP spoofing Cc: freebsd-net@freebsd.org In-Reply-To: <20011020140704.R63640-100000@achilles.silby.com> References: <4.3.2.7.2.20011020101858.00d984e0@mail.sitanium.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 14:17 20/10/2001 -0500, Mike Silbersack wrote: > > I've read some explanations about the SYN flood DoS attack. > > I understand that when the attacker fills the listening queue of the > > attacked host with incomplete connections, the attacked host will not > > reply to any SYN it receives after that. >That's an old explanation; basically any OS released in the last few years >will throw old/random connections out of the queue when it fills up. Anyway, I wonder how the old implementations behaved, and why they behaved like that. >What you actually describe here is more "spoofing" than a syn flood; a >syn flood just involves blasting large numbers of syn packets at someone, >with no intent of actually spoofing a connection. >When Mitnick / anyone else did spoofing, it was through weaknesses in the >algorithm used to generate initial sequence numbers, not through simple >brute force. The attack was a trust relationship exploit, that means, one host trusted the other by its IP address. For exploiting that trust relationship, Mitnick spoofed the trusted-host IP address. But he had to silence the trusted host in some way, and that's why he SYN-flooded it. My point is that he shouldn't have been able to silence the host in that way. I don't see any reason for the old TCP/IP stacks droping a SYN/ACK segment they received just because the listening queue was full. Under normal conditions (i.e., listening queue NOT full), they replied the SYN/ACK with an RST (as they had never sent a SYN). So why should this behavior change when the listening queue is full? >(I'm assuming that's how Mitnick did it; I'm not aware that >he has revealed exactly how he did anything, He didn't do it. It was the owner of the attacked host that revealed it, in a post to comp.security.misc. >and I doubt I'd trust him even if he did explain.) Why? > > However, I don't understand why it will not even reply with an RST > > when it receives a SYN-ACK from other machine. >In the general case of spoofing, you could ensure that a syn-ack does not >elicit a rst by spoofing the IP of a nonexistant host. But in the case I'm talking about, the host did exist. >I've also read that older tcp stacks could be caused to stop emitting >packets by filling their SYN queue; I'm not sure when that stopped applying. Well, that's the point of my question: is there any reason for the stacks to behave like that? Kind regards, Fernando Gont e-mail: fernando@gont.com.ar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 21 21:30: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 3E74C37B401 for ; Sun, 21 Oct 2001 21:30:03 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA92891; Sun, 21 Oct 2001 21:25:48 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.3/8.11.3) id f9M4PmY91280; Sun, 21 Oct 2001 21:25:48 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200110220425.f9M4PmY91280@arch20m.dellroad.org> Subject: Re: netgraph one2many question In-Reply-To: "from murthy kn at Oct 21, 2001 02:25:45 am" To: murthy kn Date: Sun, 21 Oct 2001 21:25:47 -0700 (PDT) Cc: net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org murthy kn writes: > 1.In the context of one2many, in the manpage example, I see that it puts the > interfaces into promiscuous mode. My question is, instead of turning on the > promiscuous mode, will it not work if we use the "ifconfig lladdr" to > temporarily change the MAC address (hardware > receive filter) of the cards to that of the master card (fxp0 in the manpage > example). Assuming "ifconfig lladdr" changes both the transmit and receive MAC addresses, that should work... > 2. Are the messages like "arp: something was on fxp0 got the reply from > fxp1...." kind of messages harmful - can I turn it off if in any way. > I get lot of such messages when I enable multiple cards connected on the > same segment on a FreeBSD machine. Try sysctl -w net.link.ether.inet.log_arp_wrong_iface=0 > 3. Is it possible to have multiple cards with the same IP address > on a FreeBSD machine. Not sure.. I don't think so... which one would FreeBSD use to send packets?? -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 22 2:45:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by hub.freebsd.org (Postfix) with ESMTP id 1253037B401 for ; Mon, 22 Oct 2001 02:45:15 -0700 (PDT) Received: from ukmail.uk.lucent.com (h135-86-160-50.lucent.com [135.86.160.50]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9M9jDX29207 for ; Mon, 22 Oct 2001 05:45:13 -0400 (EDT) Received: from yahoo.com (mlgw010.uk.lucent.com [135.86.193.189]) by ukmail.uk.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA07897; Mon, 22 Oct 2001 10:08:39 +0100 (BST) Message-ID: <3BD3E217.EE8E2BE9@yahoo.com> Date: Mon, 22 Oct 2001 10:08:39 +0100 From: Alexander Thorp Organization: Lucent Technologies X-Mailer: Mozilla 4.6C-CCK-MCD EMS-1.4 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: PPP problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > You could try enabling tcp/ip and physical logging to see if data is > being written as expected. > > I'd be surprised if this was a ppp problem - it doesn't look at the > frame payload unless you're using NAT, filtering, or some of the more > nasty log levels. Perhaps you've got some rogue firewall rules ? > > > I am unable to bring up PPP to my ISP. DNS works, but PING and all TCP-based > > protocols don't. I haven't tried any other UDP-based protocols. I have copied > > here ifconfig -a and netstat -rn output both before bringing the link up and > > while it is up. Lastly I have also copied the relevant lines from ppp.log. > > > > Does anybody have any idea what is going wrong and how I can fix it? > > > > Alex Thorp I've enabled TCP/IP logging, and this is what I get for an attempt at first FTP, then SMTP, then PING. The only packets that ever come IN are DNS replies; all the TCP and ICMP packets go OUT but I don't get any replies coming IN. I am using a vanilla FreeBSD 4.4 installation, with firewalling off; I have copied my rc.conf at the end of this email. $ cat /var/log/ipflog | grep tun0 21/10/2001 17:10:36.977452 tun0 @0:1 L 192.168.1.4,1024 -> 128.9.0.107,53 PR udp len 20 45 OUT 21/10/2001 17:10:44.976936 tun0 @0:1 L 192.168.1.4,1024 -> 192.5.5.241,53 PR udp len 20 45 OUT 21/10/2001 17:10:45.678917 tun0 @0:1 L 62.136.168.208,1028 -> 195.92.195.95,53 PR udp len 20 61 OUT 21/10/2001 17:10:46.042636 tun0 @0:1 L 195.92.195.95,53 -> 62.136.168.208,1028 PR udp len 20 173 IN 21/10/2001 17:10:46.046374 tun0 @0:1 L 62.136.168.208,1029 -> 195.92.195.95,53 PR udp len 20 61 OUT 21/10/2001 17:10:46.253630 tun0 @0:1 L 195.92.195.95,53 -> 62.136.168.208,1029 PR udp len 20 276 IN 21/10/2001 17:10:46.263951 tun0 @0:1 L 62.136.168.208,1024 -> 62.243.72.50,21 PR tcp len 20 60 -S OUT 21/10/2001 17:10:48.976662 tun0 @0:1 L 192.168.1.4,1024 -> 198.41.0.10,53 PR udp len 20 45 OUT 21/10/2001 17:10:49.260875 tun0 @0:1 L 62.136.168.208,1024 -> 62.243.72.50,21 PR tcp len 20 60 -S OUT 21/10/2001 17:10:52.260910 tun0 @0:1 L 62.136.168.208,1024 -> 62.243.72.50,21 PR tcp len 20 60 -S OUT 21/10/2001 17:10:52.976421 tun0 @0:1 L 192.168.1.4,1024 -> 192.33.4.12,53 PR udp len 20 45 OUT 21/10/2001 17:10:55.260954 tun0 @0:1 L 62.136.168.208,1024 -> 62.243.72.50,21 PR tcp len 20 44 -S OUT 21/10/2001 17:10:56.976256 tun0 @0:1 L 192.168.1.4,1024 -> 198.32.64.12,53 PR udp len 20 45 OUT 21/10/2001 17:10:58.261052 tun0 @0:1 L 62.136.168.208,1024 -> 62.243.72.50,21 PR tcp len 20 44 -S OUT 21/10/2001 17:11:00.975941 tun0 @0:1 L 192.168.1.4,1024 -> 128.63.2.53,53 PR udp len 20 45 OUT 21/10/2001 17:11:01.261102 tun0 @0:1 L 62.136.168.208,1024 -> 62.243.72.50,21 PR tcp len 20 44 -S OUT 21/10/2001 17:11:04.975779 tun0 @0:1 L 192.168.1.4,1024 -> 128.9.0.107,53 PR udp len 20 45 OUT 21/10/2001 17:11:07.261189 tun0 @0:1 L 62.136.168.208,1024 -> 62.243.72.50,21 PR tcp len 20 44 -S OUT 21/10/2001 17:11:08.975466 tun0 @0:1 L 192.168.1.4,1024 -> 192.112.36.4,53 PR udp len 20 45 OUT 21/10/2001 17:11:12.975225 tun0 @0:1 L 192.168.1.4,1024 -> 192.203.230.10,53 PR udp len 20 45 OUT 21/10/2001 17:11:16.975007 tun0 @0:1 L 192.168.1.4,1024 -> 202.12.27.33,53 PR udp len 20 45 OUT 21/10/2001 17:11:20.974750 tun0 @0:1 L 192.168.1.4,1024 -> 192.36.148.17,53 PR udp len 20 45 OUT 21/10/2001 17:11:23.588094 tun0 @0:1 L 62.136.168.208,1030 -> 195.92.195.95,53 PR udp len 20 64 OUT 21/10/2001 17:11:23.733214 tun0 @0:1 L 195.92.195.95,53 -> 62.136.168.208,1030 PR udp len 20 157 IN 21/10/2001 17:11:23.737438 tun0 @0:1 L 62.136.168.208,1031 -> 195.92.195.95,53 PR udp len 20 64 OUT 21/10/2001 17:11:23.893235 tun0 @0:1 L 195.92.195.95,53 -> 62.136.168.208,1031 PR udp len 20 244 IN 21/10/2001 17:11:23.904681 tun0 @0:1 L 62.136.168.208,1025 -> 195.92.195.153,25 PR tcp len 20 60 -S OUT 21/10/2001 17:11:24.974555 tun0 @0:1 L 192.168.1.4,1024 -> 198.41.0.4,53 PR udp len 20 45 OUT 21/10/2001 17:11:26.901431 tun0 @0:1 L 62.136.168.208,1025 -> 195.92.195.153,25 PR tcp len 20 60 -S OUT 21/10/2001 17:11:28.974324 tun0 @0:1 L 192.168.1.4,1024 -> 128.8.10.90,53 PR udp len 20 45 OUT 21/10/2001 17:11:29.901477 tun0 @0:1 L 62.136.168.208,1025 -> 195.92.195.153,25 PR tcp len 20 60 -S OUT 21/10/2001 17:11:32.901517 tun0 @0:1 L 62.136.168.208,1025 -> 195.92.195.153,25 PR tcp len 20 44 -S OUT 21/10/2001 17:11:32.974093 tun0 @0:1 L 192.168.1.4,1024 -> 193.0.14.129,53 PR udp len 20 45 OUT 21/10/2001 17:11:35.901635 tun0 @0:1 L 62.136.168.208,1025 -> 195.92.195.153,25 PR tcp len 20 44 -S OUT 21/10/2001 17:11:36.973927 tun0 @0:1 L 192.168.1.4,1024 -> 192.5.5.241,53 PR udp len 20 45 OUT 21/10/2001 17:11:38.901672 tun0 @0:1 L 62.136.168.208,1025 -> 195.92.195.153,25 PR tcp len 20 44 -S OUT 21/10/2001 17:11:44.973382 tun0 @0:1 L 192.168.1.4,1024 -> 198.41.0.10,53 PR udp len 20 45 OUT 21/10/2001 17:11:52.972852 tun0 @0:1 L 192.168.1.4,1024 -> 192.33.4.12,53 PR udp len 20 45 OUT 21/10/2001 17:11:55.323544 tun0 @0:1 L 62.136.168.208,1032 -> 195.92.195.95,53 PR udp len 20 61 OUT 21/10/2001 17:11:55.483629 tun0 @0:1 L 195.92.195.95,53 -> 62.136.168.208,1032 PR udp len 20 261 IN 21/10/2001 17:11:55.525212 tun0 @0:1 L 62.136.168.208 -> 62.243.72.50 PR icmp len 20 84 icmp echo/0 OUT 21/10/2001 17:11:56.532115 tun0 @0:1 L 62.136.168.208 -> 62.243.72.50 PR icmp len 20 84 icmp echo/0 OUT 21/10/2001 17:11:57.542204 tun0 @0:1 L 62.136.168.208 -> 62.243.72.50 PR icmp len 20 84 icmp echo/0 OUT 21/10/2001 17:11:58.552182 tun0 @0:1 L 62.136.168.208 -> 62.243.72.50 PR icmp len 20 84 icmp echo/0 OUT 21/10/2001 17:11:59.562180 tun0 @0:1 L 62.136.168.208 -> 62.243.72.50 PR icmp len 20 84 icmp echo/0 OUT 21/10/2001 17:12:00.572194 tun0 @0:1 L 62.136.168.208 -> 62.243.72.50 PR icmp len 20 84 icmp echo/0 OUT 21/10/2001 17:12:00.972369 tun0 @0:1 L 192.168.1.4,1024 -> 198.32.64.12,53 PR udp len 20 45 OUT 21/10/2001 17:12:01.582329 tun0 @0:1 L 62.136.168.208 -> 62.243.72.50 PR icmp len 20 84 icmp echo/0 OUT $ cat /etc/rc.conf gateway_enable="YES" hostname="MYMACHINE.MYDOMAIN.CO.UK" ifconfig_ep0="inet 192.168.1.1 netmask 255.255.255.0" kern_securelevel_enable="NO" moused_enable="NO" moused_type="NO" nfs_reserved_port_only="YES" sendmail_enable="YES" sshd_enable="YES" inetd_enable="YES" # @@AT 21/10/01 - trying to find out what is happening to TCP and ICMP ipfilter_enable="YES" ipmon_enable="YES" ipmon_flags="-D /var/log/ipflog" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 22 12:15:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 012B037B403 for ; Mon, 22 Oct 2001 12:15:51 -0700 (PDT) Received: (qmail 70205 invoked by uid 1000); 22 Oct 2001 19:15:49 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Oct 2001 19:15:49 -0000 Date: Mon, 22 Oct 2001 14:15:49 -0500 (CDT) From: Mike Silbersack To: Fernando Gont Cc: Subject: Re: SYN flood and IP spoofing In-Reply-To: <4.3.2.7.2.20011021061340.00d8bc80@mail.sitanium.com> Message-ID: <20011022141035.H70111-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 21 Oct 2001, Fernando Gont wrote: > >That's an old explanation; basically any OS released in the last few years > >will throw old/random connections out of the queue when it fills up. > > Anyway, I wonder how the old implementations behaved, and why they behaved > like that. I don't think it's worth worrying about how old implementations behaved at this point in time. They weren't designed for the hostile environment of today's internet, and have long since been replaced by newer stacks with better countermeasures. If you encounter an old system, it's probably better to start upgrading it to a newer version of whatever OS it runs than to analyze it. > >(I'm assuming that's how Mitnick did it; I'm not aware that > >he has revealed exactly how he did anything, > > He didn't do it. It was the owner of the attacked host that revealed it, in > a post to comp.security.misc. Maybe I'll look for it some day. In either case, it doesn't matter anymore. We're using strong sequence numbers, and ip-based authentication has many better replacements now. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 22 14:24:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.oskarmobil.cz (smtp1.oskarmobil.cz [217.77.161.133]) by hub.freebsd.org (Postfix) with ESMTP id 13A9237B401; Mon, 22 Oct 2001 14:24:41 -0700 (PDT) Received: from wh01ex01.ceskymobil.cz (wh01ex01.oskarmobil.cz [172.20.116.17]) by smtp1.oskarmobil.cz (8.11.2/8.11.1) with ESMTP id f9MLONl14988; Mon, 22 Oct 2001 23:24:24 +0200 (CEST) (envelope-from Milon.Papezik@oskarmobil.cz) Received: by wh01ex01.oskarmobil.cz with Internet Mail Service (5.5.2653.19) id <40HAVT5Q>; Mon, 22 Oct 2001 23:22:02 +0200 Message-ID: From: Milon Papezik To: "'Julian Elischer'" Cc: "'net@freebsd.org'" , Archie Cobbs , "'wpaul@freebsd.org'" Subject: RE: netgraph one2many question Date: Mon, 22 Oct 2001 23:21:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-2" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Julian, I am aware about Bill's ng_fec module and I tested it carefully, but it has several drawbacks: 1) there is a bug in published 4.x version, which can lead to panic. I reported this bug together with single line patch to Bill, but I never got a response. 2) there is also a problem with packet 'directing' after failed link/interface recovers. 3) ng_fec does not handle gracefully fidling with up/down state of underlying interfaces (probably related to problem 2). 4) ng_fec is "out of tree" - i.e. it may ended up not being maintained at all (if it can be considered as such now). 5) ng_fec is touching kernel/interface functions directly, which makes it quite difficult to followup the code. These were the reasons. However you are right that it might be easier to fix ng_fec first. Could ng_fec be then imported into tree ? Thanks i advance :-) Milon -- milon.papezik@ > -----Original Message----- > From: Julian Elischer [mailto:julian@elischer.org] > Subject: Re: netgraph one2many question > > Bill Paul has written a specific NETGRAPH FEC module... > > he has failover as well.. > > (it is only PART a netgraph module as it doesn;t use the > netgraph hooks to > talk to teh ethernet driver.. (strange)) > > I suggest you look for it in the archives or on > http://www.freebsd.org/~wpaul/ > > On Sat, 20 Oct 2001, Archie Cobbs wrote: > > > Milon Papezik writes: > > > I would like to extend ng_one2many module to include > > > automatic link failure datection, failover and FEC functionality. > > > > > > My question is: > > > Are interface nodes able to send upstream notification > > > that their state has changed or do I have to poll their > status periodically > > > as it is done in ng_fec module made kindly available by wpaul ? > > > > They don't now, but I think you could add this in a reasonably > > unoffensive way. > > > > What you would do is add a new function pointer to struct ifnet, > > say "void (*if_report)(struct ifnet *, int status)" or something. > > > > When a device driver detected link going up/down, it could call > > this function (if non-NULL). Then if_ethersubr() would set this > > function pointer to point to some function if_ether_report(). > > When if_ether_report() is called, if ng_ether was loaded, it > > would call into ng_ether() to generate a control message that > > would be passed to the node connected to the "lower" hook. > > > > Then, ng_one2many could be modified to understand this control > > message and do the right thing according to its configuration. > > > > Or, something like that. Polling might be a quicker and easier > > though less precise way to do it for starters. > > > > -Archie > > > > > ______________________________________________________________ > ____________ > > Archie Cobbs * Packet Design * http://www.packetdesign.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 Mon Oct 22 15:36: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 5A4B937B401; Mon, 22 Oct 2001 15:35:55 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA91019; Mon, 22 Oct 2001 16:47:44 -0700 (PDT) Date: Mon, 22 Oct 2001 16:47:43 -0700 (PDT) From: Julian Elischer To: Milon Papezik Cc: net@FreeBSD.ORG, Archie Cobbs , Bill Paul Subject: RE: netgraph one2many question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I see not reason to not import ng_fec.c except that it really doesn't use most of the netgraph interface. If you were to use the same protocol engine but rewrite the interface part of it to use the netgraph data interface it'd probably be a better fit. On Mon, 22 Oct 2001, Milon Papezik wrote: > Hi Julian, > > I am aware about Bill's ng_fec module and I tested it carefully, > but it has several drawbacks: > > 1) there is a bug in published 4.x version, which can lead to panic. > I reported this bug together with single line patch to Bill, > but I never got a response. > > 2) there is also a problem with packet 'directing' > after failed link/interface recovers. > > 3) ng_fec does not handle gracefully fidling with up/down state > of underlying interfaces (probably related to problem 2). > > 4) ng_fec is "out of tree" - i.e. it may ended up not being > maintained at all (if it can be considered as such now). > > 5) ng_fec is touching kernel/interface functions directly, > which makes it quite difficult to followup the code. > > These were the reasons. > However you are right that it might be easier to fix ng_fec first. > > Could ng_fec be then imported into tree ? > > Thanks i advance :-) > Milon > -- > milon.papezik@ > > > -----Original Message----- > > From: Julian Elischer [mailto:julian@elischer.org] > > Subject: Re: netgraph one2many question > > > > Bill Paul has written a specific NETGRAPH FEC module... > > > > he has failover as well.. > > > > (it is only PART a netgraph module as it doesn;t use the > > netgraph hooks to > > talk to teh ethernet driver.. (strange)) > > > > I suggest you look for it in the archives or on > > http://www.freebsd.org/~wpaul/ > > > > On Sat, 20 Oct 2001, Archie Cobbs wrote: > > > > > Milon Papezik writes: > > > > I would like to extend ng_one2many module to include > > > > automatic link failure datection, failover and FEC functionality. > > > > > > > > My question is: > > > > Are interface nodes able to send upstream notification > > > > that their state has changed or do I have to poll their > > status periodically > > > > as it is done in ng_fec module made kindly available by wpaul ? > > > > > > They don't now, but I think you could add this in a reasonably > > > unoffensive way. > > > > > > What you would do is add a new function pointer to struct ifnet, > > > say "void (*if_report)(struct ifnet *, int status)" or something. > > > > > > When a device driver detected link going up/down, it could call > > > this function (if non-NULL). Then if_ethersubr() would set this > > > function pointer to point to some function if_ether_report(). > > > When if_ether_report() is called, if ng_ether was loaded, it > > > would call into ng_ether() to generate a control message that > > > would be passed to the node connected to the "lower" hook. > > > > > > Then, ng_one2many could be modified to understand this control > > > message and do the right thing according to its configuration. > > > > > > Or, something like that. Polling might be a quicker and easier > > > though less precise way to do it for starters. > > > > > > -Archie > > > > > > > > ______________________________________________________________ > > ____________ > > > Archie Cobbs * Packet Design * > http://www.packetdesign.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 Mon Oct 22 21: 4:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from mine.kame.net (kame195.kame.net [203.178.141.195]) by hub.freebsd.org (Postfix) with ESMTP id 2082D37B401; Mon, 22 Oct 2001 21:04:53 -0700 (PDT) Received: from localhost ([3ffe:501:4819:1000:260:1dff:fe21:f766]) by mine.kame.net (8.11.1/3.7W) with ESMTP id f9N4GfH31742; Tue, 23 Oct 2001 13:16:41 +0900 (JST) To: tlambert2@mindspring.com Cc: hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: IPSEC sucking up memory In-Reply-To: Your message of "Sat, 06 Oct 2001 01:46:47 -0700" <3BBEC4F7.D15FF792@mindspring.com> References: <3BBEC4F7.D15FF792@mindspring.com> X-Mailer: Cue version 0.6 (010810-1737/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20011023130449I.sakane@kame.net> Date: Tue, 23 Oct 2001 13:04:49 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > While investigating a problem, I noticed that the IPSEC code > is initializing the sp -- even when no one is using IPSEC. > It turns out that this really, really bloats the per socket > memory requirements, with the only real result being a lot > of extra processing that could be replaced by a pointer is > not NULL check. > It seems to me that this could be handled in the TCP, UDP, > and IP userreq code by only initializing the thing in the > case that a policy has been set. Is there some reason why > this can't be done? IPsec specification requires to consult the SPD with all of packets in order to handling the packet. it defines RFC2401. if a pointer to the entry of the SPD is NULL, it means the security policy is not defined. so the kernel consults the system wide default. it never means nothing to do. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 4:11: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 1858C37B405 for ; Tue, 23 Oct 2001 04:10:57 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [fec0::1:12]) by Awfulhak.org (8.11.6/8.11.6) with ESMTP id f9NBArT36772; Tue, 23 Oct 2001 12:10:53 +0100 (BST) (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.6/8.11.6) with ESMTP id f9NBAxL46035; Tue, 23 Oct 2001 12:10:59 +0100 (BST) (envelope-from brian@freebsd-services.com) Message-Id: <200110231110.f9NBAxL46035@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: chuakk@lycos.com Cc: "Brian Somers" , users@ipv6.org, freebsd-net@freebsd.org, brian@hak.lan.Awfulhak.org Subject: Re: IPv6 /PPP using FreeBSD 4.4 In-Reply-To: Message from "kim chua" of "Tue, 23 Oct 2001 18:45:48 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Oct 2001 12:10:59 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Hi Brian, > > thanks for your help..i got the Ipv6 ppp working now with the latest version of ppp from your site > > But i encountered another problem, on freebsd 4.4-stable, you cannot > use ifconfig to point to a destination address like below > > ifconfig tun0 inet6 3ffe:1800:100:1::1 prefixlen 48 3ffe:1800:100:1::2 prefixlen 48 > > do you know why? Bearing in mind that when assigning a destination address, you must use a prefixlens of 128, you need to do this in ppp: iface add 3ffe:1800:100:1::1 3ffe:1800:100:1::2 add 3ffe:1800:100:1::2/48 3ffe:1800:100:1::1 > Another question... > > is there anyway of controlling ipv6 address and routes in ppp.conf when using auto mode demand dialing...?? > > thanks, Sure - with ``iface add'' to assign interface addresses and ``add'' to add routes - that's what I was hinting at in my original mail. > Kim chua > > > > > > > -- > > On Thu, 18 Oct 2001 10:29:28 > Brian Somers wrote: > >Try using the -current version of ppp. It supports IPv6 natively. > > > >You need to use ``iface add'' to assign non-link-level addresses. > >For example, I've got this in my laptop's config: > > > > iface add 2001:6f8:602:1::12 # global > > iface add fec0::1:12 fec0::1:1 # site-local > > > >> Hi, > >> > >> I've been testing IPv6 over IPv4 over User-PPP over ISDN on Freebsd 4.3-stable. > >> > >> I've managed to establish the PPP/ISDN connection between a machine acting as a server and the other as a client (using Xyzel TA). Both the machine can ping to one another. > >> > >> But the problem arises when I try to establish a tunnel(ipv6 o ipv4) using gif via the PPP/ISDN connection which uses tun interface. > >> > >> Here's what I did: > >> > >> Assuming the server has 10.0.0.1 and client has 10.0.0.2 address on their tun interfaces. > >> > >> ##server side## > >> > >> ifconfig gif0 up > >> ifconfig gif0 IPv6src-add IPv6dst-add > >> gifconfig gif0 10.0.0.1 10.0.0.2 > >> > >> ##client side## > >> > >> ifconfig gif0 up > >> ifconfig gif0 Ipv6src-add IPv6dst-add > >> gifconfig gif0 10.0.0.2 10.0.0.1 > >> > >> At this stage, I should be able to ping6 -I gif0 ff02::1 to verify that the gif tunnel is establish. However, it didn't on tun interface. > >> > >> As far as I know, it worked when i tried tunnelling on physical interfaces like xl0 or xl1 with valid IPv4 addresses. > >> > >> > >> Anyone got any ideas? > >> > >> btw, anyone knows about or tried PPPv6 ?? > >> > >> > >> thanks in advance, > >> > >> Kim Chua > >> Multimedia Super Corridor (MSC) > >> Cyberjaya > >> Malaysia -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 8:31:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 762F437B403 for ; Tue, 23 Oct 2001 08:31:06 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id f9NFUw892231 for ; Tue, 23 Oct 2001 08:30:58 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id f9NFUwm46770; Tue, 23 Oct 2001 08:30:58 -0700 (PDT) (envelope-from jdp) Date: Tue, 23 Oct 2001 08:30:58 -0700 (PDT) Message-Id: <200110231530.f9NFUwm46770@vashon.polstra.com> To: net@freebsd.org From: John Polstra Subject: Re: PXE boot vs. DHCP In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article , John Polstra wrote: > I've been setting up a 4.4-RELEASE system for net booting and diskless > operation with pxeboot, and I've run into a minor but annoying > problem. It seems that if you boot with PXE you can't use dhclient. > pxeboot configures the relevant network interface (let's call it > fxp0), NFS-mounts the root filesystem, boots the kernel, etc., and > begins to enter multi-user mode. The rc.network script then runs > dhclient, which tries to configure fxp0 (again). It apparently starts > out by unconfiguring fxp0's IP address, because NFS immediately hangs > with a "host unreachable" error. At that point I have to walk over > and press the reset button. The patch below for dhclient-script fixes the problem for me. If the script is about to change the IP address to 0.0.0.0 (in the PREINIT phase), the patched version first checks to see if the interface is already up. If it is up, there is no need to reset its IP address. We are just trying to get the interface into a state where it can send IP packets, and it is already in that state. Any objections? John Index: freebsd =================================================================== RCS file: /home/ncvs/src/contrib/isc-dhcp/client/scripts/freebsd,v retrieving revision 1.19 diff -U5 -r1.19 freebsd --- freebsd 2001/03/31 09:26:03 1.19 +++ freebsd 2001/10/23 15:24:41 @@ -62,12 +62,20 @@ if [ x$reason = xPREINIT ]; then if [ x$alias_ip_address != x ]; then ifconfig $interface inet -alias $alias_ip_address > /dev/null 2>&1 route delete $alias_ip_address 127.0.0.1 > /dev/null 2>&1 fi - ifconfig $interface inet 0.0.0.0 netmask 0.0.0.0 \ - broadcast 255.255.255.255 up + # The interface may have already been brought up by pxeboot. Don't + # disturb it in that case. + case `ifconfig $interface` in + *flags=*[\<,]UP[\>,]*) + ;; + *) + ifconfig $interface inet 0.0.0.0 netmask 0.0.0.0 \ + broadcast 255.255.255.255 up + ;; + esac exit_with_hooks 0 fi if [ x$reason = xARPCHECK ] || [ x$reason = xARPSEND ]; then exit_with_hooks 0; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 9:24:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from hermes.intergate.ca (hermes.intergate.ca [207.34.179.108]) by hub.freebsd.org (Postfix) with SMTP id 1B24937B401 for ; Tue, 23 Oct 2001 09:24:38 -0700 (PDT) Received: (qmail 63489 invoked by uid 1007); 23 Oct 2001 17:01:00 -0000 Received: from landons@uniserve.com by hermes.intergate.ca with qmail-scanner-0.93 (uvscan: v4.0.50/v4166. . Clean. Processed in 2.542945 secs); 23/10/2001 10:00:57 Received: from landons.vpp-office.uniserve.ca (HELO pirahna.uniserve.com) (216.113.198.10) by hermes.intergate.ca with SMTP; 23 Oct 2001 17:00:56 -0000 Message-Id: <5.1.0.14.0.20011023092127.02e561c8@pop.uniserve.com> X-Sender: landons@pop.uniserve.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Oct 2001 09:24:30 -0700 To: freebsd-net@freebsd.org From: Landon Stewart Subject: My ISP dislikes my dhclient Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm using dhclient to obtain an IP address from my ISP. They claim that I am "hard coding" an IP because my IP doesn't seem to change. I know that dhclient keeps a database of past leases and attempts to renew the same IP whenever possible. Is there anyway I can direct my ISP to some documentation that would make them stop getting angry with me? Is it correct to say that dhclient simply ASKS for the same IP again and if their dhcp server says "yes you may have that IP again" then and only then will it be allowed or does dhclient attempt to steal the IP back in any way? (I don't think it does). --- Landon Stewart landons@uniserve.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 9:34:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail7.bigmailbox.com (mail7.bigmailbox.com [209.132.220.38]) by hub.freebsd.org (Postfix) with ESMTP id EEE6E37B406 for ; Tue, 23 Oct 2001 09:34:43 -0700 (PDT) Received: (from www@localhost) by mail7.bigmailbox.com (8.10.0/8.10.0) id f9NGYga26427; Tue, 23 Oct 2001 09:34:42 -0700 Date: Tue, 23 Oct 2001 09:34:42 -0700 Message-Id: <200110231634.f9NGYga26427@mail7.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [200.229.133.210] From: "irado@nettaxi.com" To: landons@uniserve.com, freebsd-net@freebsd.org Subject: RE: My ISP dislikes my dhclient Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org as far as I can recall, the dhcp *server* mantains a /etc/lease files, where the latest ip-addr corresponding to a specifc MAC address are tied one to another. The situation is: a) if there are 500 available ip for 1,000 clients, is is supposed that it will change frequently b) if there are 1,000 ip-addr in the pool and 500 clients, think that it will never change, mainly if they reconnect before the expiration time. Maybe if your isp reduce the lease time, maybe if he shorten the available ip-addr pool.. >Is it correct to say that dhclient simply ASKS for the same IP again and if >their dhcp server says "yes you may have that IP again" then and only then >will it be allowed or does dhclient attempt to steal the IP back in any >way? (I don't think it does). saudações, irado furioso com tudo GNU/Linux user CASSADO deus é construído à imagem e semelhança do homem. Principalmente em seus defeitos. por favor, clique aqui: http://www.thehungersite.com e aqui também: http://cf6.uol.com.br/umminuto/ ------------------------------------------------------------ Nettaxi would like to ask for your help in donations to the RED CROSS today! http://www.nyredcross.org/donate/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 10:12:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from mercury.ccmr.cornell.edu (mercury.ccmr.cornell.edu [128.84.231.97]) by hub.freebsd.org (Postfix) with ESMTP id 3778837B405 for ; Tue, 23 Oct 2001 10:12:33 -0700 (PDT) Received: from ruby.ccmr.cornell.edu (IDENT:0@ruby.ccmr.cornell.edu [128.84.231.115]) by mercury.ccmr.cornell.edu (8.9.3/8.9.3) with ESMTP id NAA02578; Tue, 23 Oct 2001 13:13:09 -0400 Received: from localhost (mitch@localhost) by ruby.ccmr.cornell.edu (8.9.3/8.9.3) with ESMTP id NAA25810; Tue, 23 Oct 2001 13:12:24 -0400 X-Authentication-Warning: ruby.ccmr.cornell.edu: mitch owned process doing -bs Date: Tue, 23 Oct 2001 13:12:23 -0400 (EDT) From: Mitch Collinsworth To: Landon Stewart Cc: freebsd-net@FreeBSD.ORG Subject: Re: My ISP dislikes my dhclient In-Reply-To: <5.1.0.14.0.20011023092127.02e561c8@pop.uniserve.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 23 Oct 2001, Landon Stewart wrote: > I'm using dhclient to obtain an IP address from my ISP. They claim that I > am "hard coding" an IP because my IP doesn't seem to change. I know that > dhclient keeps a database of past leases and attempts to renew the same IP > whenever possible. > > Is there anyway I can direct my ISP to some documentation that would make > them stop getting angry with me? The documentation is in their DHCP server's logs. I.e. they can look there to see if you're sending DHCPDISCOVER's and DHCPREQUEST's. If you're not then you're guilty. > Is it correct to say that dhclient simply ASKS for the same IP again and if > their dhcp server says "yes you may have that IP again" then and only then > will it be allowed or does dhclient attempt to steal the IP back in any > way? (I don't think it does). All DHCP clients ask to renew their existing address. The server could theoretically refuse and make the client get a new address, if it's run by a moron who thinks this is an effective way to prevent users from running servers. (Hint: it's not.) If you're conforming to proper DHCP protocol you will take what the server offers you. You can't "steal" an address from the server but you could refuse to take the address it offers and just make up one of your own. If they know how to read their server logs they can tell what's happening. -Mitch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 10:35: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id F158837B40A for ; Tue, 23 Oct 2001 10:34:52 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9NHYnd49983 for net@freebsd.org; Tue, 23 Oct 2001 10:34:49 -0700 (PDT) (envelope-from obrien) Date: Tue, 23 Oct 2001 10:34:49 -0700 From: "David O'Brien" To: net@freebsd.org Subject: Re: PXE boot vs. DHCP (fwd) Message-ID: <20011023103449.A49909@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <200110231530.f9NFUwm46770@vashon.polstra.com> <200110231535.f9NFZAg46786@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110231535.f9NFZAg46786@vashon.polstra.com>; from jdp@polstra.com on Tue, Oct 23, 2001 at 08:35:10AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Oct 23, 2001 at 08:35:10AM -0700, jdp@polstra.com wrote: > The patch below for dhclient-script fixes the problem for me. Murray and I are very close to importing dhclient 3 (vs. the versoin 2 we have now). I would prefer to wait until then before changing isc-dhcp/client/scripts/freebsd. dhclient 3 has a lot of "modernizations" such as support for dynamic DNS, and I would not be surprised if PXE booting wasn't also better supported. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 11: 6:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 6903437B406; Tue, 23 Oct 2001 11:06:26 -0700 (PDT) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id f9NI37H34813; Tue, 23 Oct 2001 11:03:07 -0700 (PDT) (envelope-from rizzo) Date: Tue, 23 Oct 2001 11:03:07 -0700 From: Luigi Rizzo To: net@freebsd.org Subject: performance issues with M_PREPEND on clusters Message-ID: <20011023110307.A34494@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, don't know what is the right forum to discuss this, but this is certainly one. I have also Bcc-ed some people who might need to be involved. In the mbuf code, M_LEADINGSPACE always returns 0 when M_EXT is set, instead of calling the second part of M_WRITABLE to check whether there is a chance of writing into the cluster. This means that both M_PREPEND() and m_pullup() will have to allocate a second mbuf when they are invoked on a cluster, which these days is basically true for most of the incoming traffic (several network drivers pass up the full packet in a cluster). Why do we care ? Well, the additional work is not much (~2us per packet on a 750MHz box, say 10us on a slow box), but on boxes acting as routers this might in turn trigger further slowdown with various NICs which have performance or functional problems in doing scatter-gather I/O (the 21143 is one of those, and some of the NICs supported by the "dc" driver also require an additional copy when the packet being output is split across multiple buffers). A quick fix to this problem is to change M_LEADINGSPACE as shown in the attached patch (for -stable), so that M_PREPEND can write into the cluster if this is not shared. This change alone improved the peak forwarding rate (in packets per second) by 15-20% on a system we have here using the "dc" driver. Similar things could be done in m_pullup() to avoid the extra allocation. I have quickly discussed this with Bosko, and he suggests that M_LEADINGSPACE should not care if the buffer is writable or not, and only report how much room is available in front of the buffer, doing somewhere else the test for writability. While I agree with this view, it is also true that as it is now, M_LEADINGSPACE always returns 0 if the buffer is not writable, and some of the places where it is used (e.g. M_PREPEND) depend on this feature. So i would feel a bit uncomfortable in removing the writability test from M_LEADINGSPACE, whereas the change I suggest below seems to be reasonably safe. Any objections in importing this in -stable after adequate testing by some volunteers ? I do not think that testing in current would help for this change, because the mbuf handling code is slightly different there (as a matter of fact, the mbuf code in -stable is quite ugly, e.g. there is no locking when accessing the refcounts for mbufs). cheers luigi Index: sys/mbuf.h =================================================================== RCS file: /home/xorpc/u2/freebsd/src/sys/sys/mbuf.h,v retrieving revision 1.44.2.10 diff -u -r1.44.2.10 mbuf.h --- sys/mbuf.h 2001/07/03 11:02:01 1.44.2.10 +++ sys/mbuf.h 2001/10/20 21:18:04 @@ -473,8 +473,11 @@ /* * Check if we can write to an mbuf. */ +#define M_EXT_WRITABLE(m) \ + ((m)->m_ext.ext_free == NULL && mclrefcnt[mtocl((m)->m_ext.ext_buf)] == 1) + #define M_WRITABLE(m) (!((m)->m_flags & M_EXT) || \ - ((m)->m_ext.ext_free == NULL && mclrefcnt[mtocl((m)->m_ext.ext_buf)] == 1)) + M_EXT_WRITABLE(m) ) /* * Compute the amount of space available @@ -482,7 +485,7 @@ */ #define M_LEADINGSPACE(m) \ ((m)->m_flags & M_EXT ? \ - /* (m)->m_data - (m)->m_ext.ext_buf */ 0 : \ + (M_EXT_WRITABLE(m) ? (m)->m_data - (m)->m_ext.ext_buf : 0): \ (m)->m_flags & M_PKTHDR ? (m)->m_data - (m)->m_pktdat : \ (m)->m_data - (m)->m_dat) =================================================================== ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 11:28:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 4048637B403 for ; Tue, 23 Oct 2001 11:28:19 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 0014681D01; Tue, 23 Oct 2001 13:28:13 -0500 (CDT) Date: Tue, 23 Oct 2001 13:28:13 -0500 From: Alfred Perlstein To: Luigi Rizzo Cc: net@freebsd.org Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011023132813.I15052@elvis.mu.org> References: <20011023110307.A34494@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011023110307.A34494@iguana.aciri.org>; from rizzo@aciri.org on Tue, Oct 23, 2001 at 11:03:07AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Luigi Rizzo [011023 13:06] wrote: > > Hi, > don't know what is the right forum to discuss this, but this is > certainly one. I have also Bcc-ed some people who might need to be > involved. > > In the mbuf code, M_LEADINGSPACE always returns 0 when M_EXT is > set, instead of calling the second part of M_WRITABLE to check > whether there is a chance of writing into the cluster. This means > that both M_PREPEND() and m_pullup() will have to allocate a second > mbuf when they are invoked on a cluster, which these days is > basically true for most of the incoming traffic (several network > drivers pass up the full packet in a cluster). I've seen this brought up before, this is not what you want to do otherwise you risk corrupting EXT data. The right thing to do is have the people allocating writable EXT bufs mark them as such. Other EXT type buffers such as sendfile bufs can not be written to no matter what the sharecount is. I hope this helps. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 11:32: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 81BA637B403 for ; Tue, 23 Oct 2001 11:31:59 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 7167A81D01; Tue, 23 Oct 2001 13:31:59 -0500 (CDT) Date: Tue, 23 Oct 2001 13:31:59 -0500 From: Alfred Perlstein To: Luigi Rizzo Cc: net@freebsd.org Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011023133159.J15052@elvis.mu.org> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011023132813.I15052@elvis.mu.org>; from bright@mu.org on Tue, Oct 23, 2001 at 01:28:13PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Alfred Perlstein [011023 13:28] wrote: > * Luigi Rizzo [011023 13:06] wrote: > > > > Hi, > > don't know what is the right forum to discuss this, but this is > > certainly one. I have also Bcc-ed some people who might need to be > > involved. > > > > In the mbuf code, M_LEADINGSPACE always returns 0 when M_EXT is > > set, instead of calling the second part of M_WRITABLE to check > > whether there is a chance of writing into the cluster. This means > > that both M_PREPEND() and m_pullup() will have to allocate a second > > mbuf when they are invoked on a cluster, which these days is > > basically true for most of the incoming traffic (several network > > drivers pass up the full packet in a cluster). > > I've seen this brought up before, this is not what you want to > do otherwise you risk corrupting EXT data. The right thing to > do is have the people allocating writable EXT bufs mark them > as such. Other EXT type buffers such as sendfile bufs can not > be written to no matter what the sharecount is. > > I hope this helps. Oh yeah, using this method you could "fix" MCLGET in -stable to from this: #define MCLGET(m, how) do { \ struct mbuf *_mm = (m); \ \ MCLALLOC(_mm->m_ext.ext_buf, (how)); \ if (_mm->m_ext.ext_buf != NULL) { \ _mm->m_data = _mm->m_ext.ext_buf; \ _mm->m_flags |= M_EXT; \ _mm->m_ext.ext_free = NULL; \ _mm->m_ext.ext_ref = NULL; \ _mm->m_ext.ext_size = MCLBYTES; \ } \ } while (0) to: #define MCLGET(m, how) do { \ struct mbuf *_mm = (m); \ \ MCLALLOC(_mm->m_ext.ext_buf, (how)); \ if (_mm->m_ext.ext_buf != NULL) { \ _mm->m_data = _mm->m_ext.ext_buf; \ _mm->m_flags |= M_EXT | M_EXTWRITEABLE; \ _mm->m_ext.ext_free = NULL; \ _mm->m_ext.ext_ref = NULL; \ _mm->m_ext.ext_size = MCLBYTES; \ } \ } while (0) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 11:50:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id F1AD937B403 for ; Tue, 23 Oct 2001 11:50:10 -0700 (PDT) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id f9NIkpW35146; Tue, 23 Oct 2001 11:46:51 -0700 (PDT) (envelope-from rizzo) Date: Tue, 23 Oct 2001 11:46:50 -0700 From: Luigi Rizzo To: Alfred Perlstein Cc: net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011023114650.C34494@iguana.aciri.org> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011023132813.I15052@elvis.mu.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Oct 23, 2001 at 01:28:13PM -0500, Alfred Perlstein wrote: ... > > In the mbuf code, M_LEADINGSPACE always returns 0 when M_EXT is > > set, instead of calling the second part of M_WRITABLE to check > > whether there is a chance of writing into the cluster. This means ... > I've seen this brought up before, this is not what you want to > do otherwise you risk corrupting EXT data. The right thing to > do is have the people allocating writable EXT bufs mark them > as such. Other EXT type buffers such as sendfile bufs can not > be written to no matter what the sharecount is. Actually, the BSD code works the other way around: * standard EXT bufs as returned by MCLGET _are_ writable if m_ext.ext_free == NULL and their refcnt is 1 (they _must_ be, otherwise we would have errors when m_free() decides to dispose of a cluster, which is a form of writing), and * people allocating "other EXT type" implicitly mark the buffer as not-writable by setting m_ext.ext_free to the proper routine. This is certainly what the sendfile bufs that you mentioned do. M_WRITABLE (used in the patch i proposed) does exactly the checks that you do when you m_free() a cluster. If this is wrong, then m_free() is broken! Am i missing something else ? cheers luigi #define M_WRITABLE(m) (!((m)->m_flags & M_EXT) || \ ((m)->m_ext.ext_free == NULL && mclrefcnt[mtocl((m)->m_ext.ext_buf)] == 1)) ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 12: 0:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 3C9A737B403 for ; Tue, 23 Oct 2001 12:00:34 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 4511781D01; Tue, 23 Oct 2001 14:00:34 -0500 (CDT) Date: Tue, 23 Oct 2001 14:00:34 -0500 From: Alfred Perlstein To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011023140034.M15052@elvis.mu.org> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011023114650.C34494@iguana.aciri.org>; from rizzo@aciri.org on Tue, Oct 23, 2001 at 11:46:50AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Luigi Rizzo [011023 13:50] wrote: > On Tue, Oct 23, 2001 at 01:28:13PM -0500, Alfred Perlstein wrote: > ... > > > In the mbuf code, M_LEADINGSPACE always returns 0 when M_EXT is > > > set, instead of calling the second part of M_WRITABLE to check > > > whether there is a chance of writing into the cluster. This means > ... > > I've seen this brought up before, this is not what you want to > > do otherwise you risk corrupting EXT data. The right thing to > > do is have the people allocating writable EXT bufs mark them > > as such. Other EXT type buffers such as sendfile bufs can not > > be written to no matter what the sharecount is. > > Actually, the BSD code works the other way around: > > * standard EXT bufs as returned by MCLGET _are_ writable if > m_ext.ext_free == NULL and their refcnt is 1 (they _must_ be, > otherwise we would have errors when m_free() decides to > dispose of a cluster, which is a form of writing), > > and > > * people allocating "other EXT type" implicitly mark the buffer > as not-writable by setting m_ext.ext_free to the proper routine. > This is certainly what the sendfile bufs that you mentioned do. > > M_WRITABLE (used in the patch i proposed) does exactly the checks > that you do when you m_free() a cluster. If this is wrong, then > m_free() is broken! > > Am i missing something else ? Yes, you're right, I was mistaken in my paranioa, however you're missing the fact that one may want to allocate an EXT buf and still have it writeable. I like your patch, it's a good idea, go for it. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 12: 5: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail24.bigmailbox.com (mail24.bigmailbox.com [209.132.220.207]) by hub.freebsd.org (Postfix) with ESMTP id E897B37B406 for ; Tue, 23 Oct 2001 12:05:04 -0700 (PDT) Received: (from www@localhost) by mail24.bigmailbox.com (8.10.0/8.10.0) id f9NJ54F06625; Tue, 23 Oct 2001 12:05:04 -0700 Date: Tue, 23 Oct 2001 12:05:04 -0700 Message-Id: <200110231905.f9NJ54F06625@mail24.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [200.229.133.210] From: "irado@nettaxi.com" To: freebsd-net@FreeBSD.ORG Subject: multipoint vpn (ipsec) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org is there a way to build multipoint vpn's, using the FreeBSD's ipsec?? I am just guessing something like: a) starlike vpn, 1 server, many clients ?? b) many-to-many conections, where each and everyone are server and client?? the many examples I get everywhere just specify point-to-point tunneling, for just 2 points. I can try (later) the vtun solution, but preffer to try ipsec first. Any hint, url's where I can get white papers, howto's, hands-on and any kind of information will be of great value. saudações, irado furioso com tudo GNU/Linux user CASSADO deus é construído à imagem e semelhança do homem. Principalmente em seus defeitos. por favor, clique aqui: http://www.thehungersite.com e aqui também: http://cf6.uol.com.br/umminuto/ ------------------------------------------------------------ Nettaxi would like to ask for your help in donations to the RED CROSS today! http://www.nyredcross.org/donate/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 12:17:14 2001 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 2F9C137B40A for ; Tue, 23 Oct 2001 12:17:12 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9NJH4T32996; Tue, 23 Oct 2001 15:17:04 -0400 (EDT) (envelope-from wollman) Date: Tue, 23 Oct 2001 15:17:04 -0400 (EDT) From: Garrett Wollman Message-Id: <200110231917.f9NJH4T32996@khavrinen.lcs.mit.edu> To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: performance issues with M_PREPEND on clusters In-Reply-To: <20011023110307.A34494@iguana.aciri.org> References: <20011023110307.A34494@iguana.aciri.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Similar things could be done in m_pullup() to avoid the > extra allocation. Can't be done in m_pullup: the whole purpose of m_pullup is to *guarantee* that the data in question will never be shared. It might be worth having a new interface which doesn't provide such a guarantee. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 12:42:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id D148237B406 for ; Tue, 23 Oct 2001 12:42:46 -0700 (PDT) Received: from hbo (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with SMTP id f9NJdcO28964; Tue, 23 Oct 2001 12:39:38 -0700 (PDT) From: "Lars Eggert" To: , Subject: RE: multipoint vpn (ipsec) Date: Tue, 23 Oct 2001 12:39:36 -0800 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; boundary="----=_NextPart_000_000E_01C15BBF.C6370420"; protocol="application/x-pkcs7-signature"; micalg=SHA1 In-Reply-To: <200110231905.f9NJ54F06625@mail24.bigmailbox.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C15BBF.C6370420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > is there a way to build multipoint vpn's, using the FreeBSD's ipsec?? The X-Bone does that, a port is in /usr/ports/net/xbone. Also see its web site at http://www.isi.edu/xbone/. -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California ------=_NextPart_000_000E_01C15BBF.C6370420 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5jCCArUw ggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEPMA0GA1UEBBMGRWdnZXJ0 MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFy c2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0AvLBsD78nxcUHeHkaMgl3b4 qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD11uZDy4CNNJUu3gKxKSb+zRV70O+lkwwf tuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcUSF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEA AaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREE ETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQ A8zI7U2K1ZIAl11j0a1DKxnp3GtTvOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2 OhB+jeKEqY7IDAJE4/fI0e+d6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4 fdcOo1S34r4wggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5WjCB kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y 8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtU ihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN AQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONnt UPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2 lhglTWr0ncXDkS+plrgFPFL83eliA0gxggKqMIICpgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFp bCBSU0EgMjAwMC44LjMwAgMFgUcwCQYFKw4DAhoFAKCCAWUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDExMDIzMjAzOTM2WjAjBgkqhkiG9w0BCQQxFgQUcwzt2EEn h4aWCPOm+b4/hZg2POIwWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgasGCSsGAQQB gjcQBDGBnTCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZI hvcNAQEBBQAEgYA8ItJCLzu8PCFl3dH/ExI7gErvsXOWq/oFTv/jlulJCwwEJtk4YKH2T7CJvJwh //gYVXWAmNGtY65m92RUGf+J1ldXhdwcXu6Bxjekk8/hCh7MXlUXhgANMbK2S3p55xL0WnsBmWEH cLPafQH0sbe+3Bb/7Y9O2JdS0MBjFoCEQQAAAAAAAA== ------=_NextPart_000_000E_01C15BBF.C6370420-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 13:13:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp.noos.fr (zola.noos.net [212.198.2.76]) by hub.freebsd.org (Postfix) with ESMTP id 80EB737B403 for ; Tue, 23 Oct 2001 13:13:51 -0700 (PDT) Received: (qmail 8710899 invoked by uid 0); 23 Oct 2001 20:13:49 -0000 Received: from unknown (HELO gits.dyndns.org) ([212.198.229.145]) (envelope-sender ) by 212.198.2.76 (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 23 Oct 2001 20:13:49 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.6/8.11.6) id f9NKDmU27220; Tue, 23 Oct 2001 22:13:48 +0200 (CEST) (envelope-from root) Message-Id: <200110232013.f9NKDmU27220@gits.dyndns.org> Subject: Re: PXE boot vs. DHCP In-Reply-To: <200110231530.f9NFUwm46770@vashon.polstra.com> To: John Polstra Date: Tue, 23 Oct 2001 22:13:47 +0200 (CEST) Cc: net@freebsd.org Reply-To: clefevre@citeweb.net From: Cyrille Lefevre Organization: ACME X-Face: X-Mailer: ELM [version 2.4ME+ PL94c (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Polstra wrote: > In article , > John Polstra wrote: > > I've been setting up a 4.4-RELEASE system for net booting and diskless > > operation with pxeboot, and I've run into a minor but annoying > > problem. It seems that if you boot with PXE you can't use dhclient. > > pxeboot configures the relevant network interface (let's call it > > fxp0), NFS-mounts the root filesystem, boots the kernel, etc., and > > begins to enter multi-user mode. The rc.network script then runs > > dhclient, which tries to configure fxp0 (again). It apparently starts > > out by unconfiguring fxp0's IP address, because NFS immediately hangs > > with a "host unreachable" error. At that point I have to walk over > > and press the reset button. > > The patch below for dhclient-script fixes the problem for me. If the > script is about to change the IP address to 0.0.0.0 (in the PREINIT > phase), the patched version first checks to see if the interface is > already up. If it is up, there is no need to reset its IP address. > We are just trying to get the interface into a state where it > can send IP packets, and it is already in that state. Any > objections? IMHO, it would be better to provide a /etc/dhclient-enter-hooks while you are net installing the station, then remove it when finished. the dhclient-enter-hooks would be almost what you are doing : #!/bin/sh if [ x$reason = xPREINIT ]; then case `ifconfig $interface` in *flags=*[\<,]UP[\>,]*) exit 0 ;; esac fi Cyrille. -- Cyrille Lefevre mailto:clefevre@citeweb.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 13:17:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 6BB0037B407; Tue, 23 Oct 2001 13:17:44 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id f9NKHd893595; Tue, 23 Oct 2001 13:17:39 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id f9NKHdb03997; Tue, 23 Oct 2001 13:17:39 -0700 (PDT) (envelope-from jdp) Date: Tue, 23 Oct 2001 13:17:39 -0700 (PDT) Message-Id: <200110232017.f9NKHdb03997@vashon.polstra.com> To: net@freebsd.org From: John Polstra Subject: Re: PXE boot vs. DHCP (fwd) In-Reply-To: <20011023103449.A49909@dragon.nuxi.com> References: <200110231530.f9NFUwm46770@vashon.polstra.com> <200110231535.f9NFZAg46786@vashon.polstra.com> <20011023103449.A49909@dragon.nuxi.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <20011023103449.A49909@dragon.nuxi.com>, David O'Brien wrote: > On Tue, Oct 23, 2001 at 08:35:10AM -0700, jdp@polstra.com wrote: > > The patch below for dhclient-script fixes the problem for me. > > Murray and I are very close to importing dhclient 3 (vs. the versoin 2 we > have now). I would prefer to wait until then before changing > isc-dhcp/client/scripts/freebsd. dhclient 3 has a lot of > "modernizations" such as support for dynamic DNS, and I would not be > surprised if PXE booting wasn't also better supported. OK, it doesn't bother me to keep the fix in my local tree until then. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 13:20:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id DB11237B401 for ; Tue, 23 Oct 2001 13:20:09 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id f9NKJn893612; Tue, 23 Oct 2001 13:19:49 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id f9NKJnJ04011; Tue, 23 Oct 2001 13:19:49 -0700 (PDT) (envelope-from jdp) Date: Tue, 23 Oct 2001 13:19:49 -0700 (PDT) Message-Id: <200110232019.f9NKJnJ04011@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: clefevre@citeweb.net Subject: Re: PXE boot vs. DHCP In-Reply-To: <200110232013.f9NKDmU27220@gits.dyndns.org> References: <200110232013.f9NKDmU27220@gits.dyndns.org> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <200110232013.f9NKDmU27220@gits.dyndns.org>, Cyrille Lefevre wrote: > IMHO, it would be better to provide a /etc/dhclient-enter-hooks > while you are net installing the station, then remove it when > finished. > > the dhclient-enter-hooks would be almost what you are doing : > > #!/bin/sh > > if [ x$reason = xPREINIT ]; then > case `ifconfig $interface` in > *flags=*[\<,]UP[\>,]*) exit 0 ;; > esac > fi I know the problem could be solved that way, and if I were using a Microsoft operating system that's what I'd have to do. But this is FreeBSD, and we can fix things that are broken. What is the reason you think it would be better to put the solution into dhclient-enter-hooks? John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 14: 6:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 92B3C37B401 for ; Tue, 23 Oct 2001 14:06:39 -0700 (PDT) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id f9NL3JR36068; Tue, 23 Oct 2001 14:03:19 -0700 (PDT) (envelope-from rizzo) Date: Tue, 23 Oct 2001 14:03:19 -0700 From: Luigi Rizzo To: Garrett Wollman Cc: net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011023140318.A35869@iguana.aciri.org> References: <20011023110307.A34494@iguana.aciri.org> <200110231917.f9NJH4T32996@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110231917.f9NJH4T32996@khavrinen.lcs.mit.edu> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Oct 23, 2001 at 03:17:04PM -0400, Garrett Wollman wrote: > < said: > > > Similar things could be done in m_pullup() to avoid the > > extra allocation. > > Can't be done in m_pullup: the whole purpose of m_pullup is to > *guarantee* that the data in question will never be shared. It might > be worth having a new interface which doesn't provide such a > guarantee. You are right, we cannot change the semantics of m_pullup() without carefully analysing how it is used, and this definitely calls for one or two new interfaces (m_pullup_readonly(), m_pullup_writable()). Technically, it is correct that m_pullup guarantees that the data in question will never be shared, but it seems to me more an artifact of its implementation than a real goal. From what i see, m_pullup() is mostly used to make sure that a block is contiguous, and in some other cases to have a writable copy of the block. In both cases being able to write into the cluster would save a bit of work. Yes, there are situations (e.g. where you are replicating a packet and changing some things in the header for each replica -- see EXAMPLE 1) where the current semantics of m_pullup() _seems_ to save something, but this comes at the price of an m_copy() so there is really no saving compared to EXAMPLE 2. By having the new m_pullup_XXX() calls, you could rewrite the same code as in EXAMPLE 3, with the advantage that the first instance could turn into a no-op, and you replicate only if really necessary. cheers luigi ----------------------------------------------------------------- EXAMPLE 1: /* some pieces of the kernel are like this */ m = m_pullup(m, some_len); for (;;) { n = m_copy(m, 0, M_COPYALL); if (some_condition) break ; } m_free(m); EXAMPLE 2: /* they could be rewritten in this way */ canfree = 1; for (;;) { n = m_pullup(m, some_len); if (n == m) canfree=0; if (some_condition) break ; } if (canfree) m_free(m); EXAMPLE 3: /* or in this way with a new m_pullupXXX() interface */ for (;;) { n = m_pullup_writable(m, some_len); if (n == m) canfree=0; if (some_condition) break ; } if (canfree) m_free(m); ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 14: 9:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 57CE037B405 for ; Tue, 23 Oct 2001 14:09:49 -0700 (PDT) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id f9NL6S636110; Tue, 23 Oct 2001 14:06:28 -0700 (PDT) (envelope-from rizzo) Date: Tue, 23 Oct 2001 14:06:28 -0700 From: Luigi Rizzo To: Alfred Perlstein Cc: net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011023140628.A36095@iguana.aciri.org> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011023140034.M15052@elvis.mu.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Oct 23, 2001 at 02:00:34PM -0500, Alfred Perlstein wrote: > > Yes, you're right, I was mistaken in my paranioa, however you're > missing the fact that one may want to allocate an EXT buf and still > have it writeable. Yes, but this is the sort of things that are better sorted out in -current... > I like your patch, it's a good idea, go for it. good to hear that :) cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 15:41:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from c1717606-a.sprgfld1.mo.home.com (c1717606-a.sprgfld1.mo.home.com [65.6.246.57]) by hub.freebsd.org (Postfix) with ESMTP id 5B57037B403 for ; Tue, 23 Oct 2001 15:41:20 -0700 (PDT) Received: from pooh.int (mail@pooh.int [10.0.1.2]) by c1717606-a.sprgfld1.mo.home.com (8.11.6/8.11.5) with ESMTP id f9NMfIR14501 for ; Tue, 23 Oct 2001 17:41:18 -0500 (CDT) (envelope-from kirk@strauser.com) Received: from kirk by pooh.int with local (Exim 3.32 #1 (Debian)) id 15wAEY-0004fd-00 for ; Tue, 23 Oct 2001 17:41:18 -0500 To: freebsd-net@freebsd.org Subject: Silly problem has me stumped From: Kirk Strauser Date: 23 Oct 2001 17:41:18 -0500 Message-ID: <871yjunfn5.fsf@pooh.int> Lines: 37 X-Mailer: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org It's late in the day, my coffee's wearing off, and my brain is fried. My new ISP uses private addresses for all internal routing. Let's say that my new public address block is 1.2.3.0/24, and that the routing block between their network and mine is 10.0.0.0/30, and my default router is 10.0.0.1.My FreeBSD 4.4 (STABLE) machine, named gw1 and housing several Ethernet cards, will be a router and DNS server. Here is the basic network diagram: Internet +--- || | Their network 10.0.0.1 - their router +--- || || 10.0.0.2 - gw1 +--- || | 1.2.3.0/24 - gw1 | My network || | Public servers | on my LAN +--- Because gw1 needs to be world-accessible, I need both the private (10.0.0.2/30) and public (1.2.3.0/24) configured on the same NIC. While that's trivial enough, my problem is that all outgoing packets originating from gw1 have a source address in the private block, which means that I can't ping out or traceroute past the borders of my ISP's internal routing system. My guess is that the outbound packets get a source address in the private block because the default route is in that block. Is there a way to get FreeBSD to use a particular address out of several on an interface as the source address? Please forgive me if I sound like a crack junkie. I've been looking at the screen too long for one day's work. -- Kirk Strauser To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 15:59:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from technokratis.com (modemcable093.62-201-24.mtl.mc.videotron.ca [24.201.62.93]) by hub.freebsd.org (Postfix) with ESMTP id CC8D837B405 for ; Tue, 23 Oct 2001 15:59:28 -0700 (PDT) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id f9NMvxp00467; Tue, 23 Oct 2001 18:57:59 -0400 (EDT) (envelope-from bmilekic) Date: Tue, 23 Oct 2001 18:57:59 -0400 From: Bosko Milekic To: Luigi Rizzo Cc: Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011023185759.A328@technokratis.com> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011023140628.A36095@iguana.aciri.org>; from rizzo@aciri.org on Tue, Oct 23, 2001 at 02:06:28PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As I have stated to Luigi in private and as I have stated more than half a year ago now when this issue was first brought up by dwmalone, I believe that the correct way to deal with this issue is to have M_LEADINGSPACE and M_TRAILINGSPACE simply return the number of bytes that make up the leading space or trailing space, respectively, regardless of whether the underlying cluster/mbuf/ext_buf is marked writable or not. There is nothing in the name "M_LEADINGSPACE" and "M_TRAILINGSPACE" that implies anything having to do with the writability of the underlying buffer and therefore, these two should not be concerned with writability. The reason that the relevant code to do so in the first place was commented out in the code when it was imported is the result of a crude hack which was probably brought in when support for other external buffers (besides for just clusters) was implemented because while this was done, at the time, the support for marking said buffers "writable" did not exist, and so to minimize checking in code using the M_LEADINGSPACE and M_TRAILINGSPACE macros, they were merely made to return 0 in the event of an M_EXT marked mbuf. Instead, the correct approach would be, as stated above, to have M_LEADINGSPACE and M_TRAILINGSPACE return what their names imply and have the code that uses them in the kernel appropriately check for writability of the ext_buf before it's about to write to it, using the _already existing_ interface, i.e. M_WRITABLE(). Since this interface _exists_ and we have it implemented, there is no reason not to use it properly anymore. Yes, I'm willing to go around and do the work in -CURRENT, and I will do this, hopefully, by this weekend, as the [massive amount of] school work "stabilizes." I think the same approach should be taken in -STABLE. That said, I am not 100% opposed to Luigi's patch and I think that had not brought this up, it would have been left long forgotten. On Tue, Oct 23, 2001 at 02:06:28PM -0700, Luigi Rizzo wrote: > On Tue, Oct 23, 2001 at 02:00:34PM -0500, Alfred Perlstein wrote: > > > > Yes, you're right, I was mistaken in my paranioa, however you're > > missing the fact that one may want to allocate an EXT buf and still > > have it writeable. > > Yes, but this is the sort of things that are better sorted out > in -current... > > > I like your patch, it's a good idea, go for it. > > good to hear that :) > > cheers > luigi Cheers, -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 17: 5:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by hub.freebsd.org (Postfix) with ESMTP id 9DE3337B403 for ; Tue, 23 Oct 2001 17:05:23 -0700 (PDT) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id f9O03uS69967; Tue, 23 Oct 2001 20:03:56 -0400 (EDT) (envelope-from barney) Date: Tue, 23 Oct 2001 20:03:51 -0400 From: Barney Wolff To: Kirk Strauser Cc: freebsd-net@FreeBSD.ORG Subject: Re: Silly problem has me stumped Message-ID: <20011023200351.A69785@tp.databus.com> References: <871yjunfn5.fsf@pooh.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <871yjunfn5.fsf@pooh.int>; from kirk@strauser.com on Tue, Oct 23, 2001 at 05:41:18PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 1. You don't need the public address configured on the same nic as the private - packets to the public address will be accepted even if they come in via the outside nic. 2. Both ping and traceroute offer options to set the source addr. rtfm. On Tue, Oct 23, 2001 at 05:41:18PM -0500, Kirk Strauser wrote: > It's late in the day, my coffee's wearing off, and my brain is fried. > > My new ISP uses private addresses for all internal routing. Let's say that > my new public address block is 1.2.3.0/24, and that the routing block > between their network and mine is 10.0.0.0/30, and my default router is > 10.0.0.1.My FreeBSD 4.4 (STABLE) machine, named gw1 and housing several > Ethernet cards, will be a router and DNS server. Here is the basic network > diagram: > > Internet +--- > || | Their network > 10.0.0.1 - their router +--- > || > || > 10.0.0.2 - gw1 +--- > || | > 1.2.3.0/24 - gw1 | My network > || | > Public servers | > on my LAN +--- > > Because gw1 needs to be world-accessible, I need both the private > (10.0.0.2/30) and public (1.2.3.0/24) configured on the same NIC. While > that's trivial enough, my problem is that all outgoing packets originating > from gw1 have a source address in the private block, which means that I > can't ping out or traceroute past the borders of my ISP's internal routing > system. > > My guess is that the outbound packets get a source address in the private > block because the default route is in that block. Is there a way to get > FreeBSD to use a particular address out of several on an interface as the > source address? > > Please forgive me if I sound like a crack junkie. I've been looking at the > screen too long for one day's work. > -- > Kirk Strauser > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Barney Wolff "Nonetheless, ease and peace had left this people still curiously tough. They were, if it came to it, difficult to daunt or to kill; and they were, perhaps, so unwearyingly fond of good things not least because they could, when put to it, do without them, and could survive rough handling by grief, foe, or weather in a way that astonished those who did not know them well and looked no further than their bellies and their well-fed faces." J.R.R.T. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 17:36:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from c1717606-a.sprgfld1.mo.home.com (c1717606-a.sprgfld1.mo.home.com [65.6.246.57]) by hub.freebsd.org (Postfix) with ESMTP id 5A2C737B401 for ; Tue, 23 Oct 2001 17:36:56 -0700 (PDT) Received: from pooh.int (mail@pooh.int [10.0.1.2]) by c1717606-a.sprgfld1.mo.home.com (8.11.6/8.11.5) with ESMTP id f9O0atR14908 for ; Tue, 23 Oct 2001 19:36:55 -0500 (CDT) (envelope-from kirk@strauser.com) Received: from kirk by pooh.int with local (Exim 3.32 #1 (Debian)) id 15wC2R-0004gF-00 for ; Tue, 23 Oct 2001 19:36:55 -0500 To: freebsd-net@freebsd.org Subject: Re: Silly problem has me stumped References: <871yjunfn5.fsf@pooh.int> <20011023200351.A69785@tp.databus.com> From: Kirk Strauser Date: 23 Oct 2001 19:36:55 -0500 In-Reply-To: <20011023200351.A69785@tp.databus.com> Message-ID: <87vgh5naag.fsf@pooh.int> Lines: 17 X-Mailer: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 2001-10-24T00:03:51Z, Barney Wolff writes: > 1. You don't need the public address configured on the same nic as the > private - packets to the public address will be accepted even if they come > in via the outside nic. I will occasionally need to connect *out* from gw1 for SSH, whois, DNS, etc. In that event, the packets need a public source address. > 2. Both ping and traceroute offer options to set the source addr. rtfm. I already RTFM, and TFM doesn't say a thing about how to do what I want, except for command line options of specific clients, which doesn't solve my problem. -- Kirk Strauser To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 17:48:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from comp1.mastery.ca (ptr-207-54-105-70.ptr.terago.ca [207.54.105.70]) by hub.freebsd.org (Postfix) with ESMTP id 3346337B401; Tue, 23 Oct 2001 17:48:18 -0700 (PDT) Received: from 78kw954 (dyn216-8-128-150.ADSL.mnsi.net [216.8.128.150]) (authenticated (0 bits)) by comp1.mastery.ca (8.12.0/8.11.1) with ESMTP id f9O0mAfl027175; Tue, 23 Oct 2001 20:48:11 -0400 (EDT) (envelope-from rmasse@mastery.ca) Message-ID: <000c01c15c25$8f45dbb0$3200a8c0@mobile.stclairc.ca> From: "Ryan Masse" To: Cc: "FreeBSD-Questions" Subject: pptp via mpd Date: Tue, 23 Oct 2001 20:48:01 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Is it possible to authenticate users on /etc/master.passwd or by some other method possibly RADIUS or an SQL table? storing the usernames and passwords in the mpd.secret file is redundant and insecure IMHO. Ryan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 18:29: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from mx3.uninterruptible.net (cyclonis.catonic.net [63.160.99.136]) by hub.freebsd.org (Postfix) with ESMTP id A16F437B403 for ; Tue, 23 Oct 2001 18:28:56 -0700 (PDT) Received: from mail.uninterruptible.net (ns1.uninterruptible.net [216.7.46.11]) by mx3.uninterruptible.net (Postfix) with ESMTP id 3C2DA5503; Tue, 23 Oct 2001 20:25:22 -0500 (CDT) Received: from Spaz.Catonic.NET (tnt6-216-180-5-61.dialup.HiWAAY.net [216.180.5.61]) by mail.uninterruptible.net (Postfix) with ESMTP id C0D8B5005C; Wed, 24 Oct 2001 01:28:36 +0000 (GMT) Received: by Spaz.Catonic.NET (Postfix, from userid 1002) id EAF5A331B; Wed, 24 Oct 2001 01:30:35 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by Spaz.Catonic.NET (Postfix) with ESMTP id E01D44C18; Wed, 24 Oct 2001 01:30:35 +0000 (GMT) Date: Wed, 24 Oct 2001 01:30:35 +0000 (GMT) From: Kris Kirby To: Kirk Strauser Cc: Subject: Re: Silly problem has me stumped In-Reply-To: <87vgh5naag.fsf@pooh.int> Message-ID: X-Tech-Support-Email: bofh@catonic.net X-Frames: I hate frames. Organization: Non Illegitemus Carborundum MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 23 Oct 2001, Kirk Strauser wrote: > I already RTFM, and TFM doesn't say a thing about how to do what I want, > except for command line options of specific clients, which doesn't solve my > problem. Yeah. The issue here is that the machine is picking the IP address as the "closest" IP to the internet -- the RFC1918 address over the WAN link. My mind is also mud at the moment, but this much I can thing of: By forcing ssh, et al. to bind to a specific IP, you can avoid the non-traceable issue. And a tidbit just surfaced from the mud! Use ipfw + natd to nat anything that would directly come from / to the private address and use "natd -u -a 1.2.3.1" (assumes .1 is the gateway). Careful that you don't wind up looking at every single packet though. The other solution would be to accuse your ISP of being incompentent / cheap, etc. and complain until you get a public /30 for the WAN link. I'm a fascist; I wouldn't have taken a link without a public WAN ip. ----- Kris Kirby, KE4AHR | TGIFreeBSD... 'Nuff said. | ------------------------------------------------------- "Fate, it seems, is not without a sense of irony." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 18:36:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by hub.freebsd.org (Postfix) with ESMTP id 9A8B237B403 for ; Tue, 23 Oct 2001 18:36:28 -0700 (PDT) Received: from compaq (user-uiven9e.dsl.mindspring.com [165.247.93.46]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with SMTP id VAA07319 for ; Tue, 23 Oct 2001 21:36:28 -0400 (EDT) Message-ID: <001001c15c2c$2458cb80$2e5df7a5@compaq> From: "Raju" To: Subject: Making TCP/IP reentrant ? Date: Tue, 23 Oct 2001 21:35:13 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C15C0A.995075E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C15C0A.995075E0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All:=20 I tried to search the archive for following, but could not come up a = answer. Is there any work in FreeBSD networking community for a multi-instance TCP/IP stack. In other words a re-entrant TCP/IP stack. Anyone who knows the stack in detail, can you please throw a rough estimate based on the effort that might be required.=20 Thanks! Raju ------=_NextPart_000_000D_01C15C0A.995075E0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
All:
I tried to search the archive for following, but = could not=20 come up a answer.
 
Is there any work in FreeBSD networking community = for a=20 multi-instance
TCP/IP stack. In other words a re-entrant TCP/IP = stack. Anyone=20 who knows
the stack in detail, can you please throw a rough = estimate=20 based on the
effort that might be required.
 
Thanks!
Raju
 
------=_NextPart_000_000D_01C15C0A.995075E0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 18:40:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 377E537B407 for ; Tue, 23 Oct 2001 18:40:12 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 1F60181D08; Tue, 23 Oct 2001 20:40:12 -0500 (CDT) Date: Tue, 23 Oct 2001 20:40:12 -0500 From: Alfred Perlstein To: Raju Cc: freebsd-net@freebsd.org Subject: Re: Making TCP/IP reentrant ? Message-ID: <20011023204012.W15052@elvis.mu.org> References: <001001c15c2c$2458cb80$2e5df7a5@compaq> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001001c15c2c$2458cb80$2e5df7a5@compaq>; from nraju@mindspring.com on Tue, Oct 23, 2001 at 09:35:13PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Raju [011023 20:36] wrote: > All: > I tried to search the archive for following, but could not come up a answer. > > Is there any work in FreeBSD networking community for a multi-instance > TCP/IP stack. In other words a re-entrant TCP/IP stack. Anyone who knows > the stack in detail, can you please throw a rough estimate based on the > effort that might be required. It's not that bad, probably about one to two man-months of work. There's a couple of places that use global variables, and there's some shared structures that need locking, but it's not too difficult. But that would probably just be the stack itself, not including the socket and complete path from read/write syscall all the way through to the driver, just the TCP/IP stack itself. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 18:59:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from c1717606-a.sprgfld1.mo.home.com (c1717606-a.sprgfld1.mo.home.com [65.6.246.57]) by hub.freebsd.org (Postfix) with ESMTP id 1EC3137B401 for ; Tue, 23 Oct 2001 18:59:19 -0700 (PDT) Received: from pooh.int (mail@pooh.int [10.0.1.2]) by c1717606-a.sprgfld1.mo.home.com (8.11.6/8.11.5) with ESMTP id f9O1xIR15240 for ; Tue, 23 Oct 2001 20:59:18 -0500 (CDT) (envelope-from kirk@strauser.com) Received: from kirk by pooh.int with local (Exim 3.32 #1 (Debian)) id 15wDKA-0004hd-00 for ; Tue, 23 Oct 2001 20:59:18 -0500 To: freebsd-net@freebsd.org Subject: Re: Silly problem has me stumped References: From: Kirk Strauser Date: 23 Oct 2001 20:59:18 -0500 In-Reply-To: Message-ID: <87lmi1n6h5.fsf@pooh.int> Lines: 29 X-Mailer: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 2001-10-24T01:30:35Z, Kris Kirby writes: > And a tidbit just surfaced from the mud! Use ipfw + natd to nat anything > that would directly come from / to the private address and use "natd -u -a > 1.2.3.1" (assumes .1 is the gateway). Careful that you don't wind up > looking at every single packet though. Ahhh... That doesn't sound too bad. Lately I've somewhat taken to ipfilter so I'll wave the appropriate translation stick at the issue. > The other solution would be to accuse your ISP of being incompentent / > cheap, etc. and complain until you get a public /30 for the WAN link. Actually, they're far and away the most competent provider in the area. Our contact is a CCNA-working-on-CCIE and really seems to know his stuff. We're also now on a dual-homed network, connected by two counter-rotating fiber rings. The rationale I heard was that this was something they went out of their way to do in order to avoid wasting public IPs on router interfaces. Coming from anyone else, I'd agree with you. From these guys, I tend to believe them. > I'm a fascist; I wouldn't have taken a link without a public WAN ip. Well, we have a whole public /24. Only the routing block is private, which I'm sure will seem like a better idea once I coerce this $@#!() FreeBSD box to bend to my will. -- Kirk Strauser To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 19: 0:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from wren.cs.unc.edu (wren.cs.unc.edu [152.2.128.86]) by hub.freebsd.org (Postfix) with ESMTP id DF9F337B401 for ; Tue, 23 Oct 2001 19:00:06 -0700 (PDT) Received: from le-cs.cs.unc.edu (IDENT:le@le-cs.cs.unc.edu [152.2.131.150]) by wren.cs.unc.edu (8.9.3/8.9.3) with ESMTP id WAA18945 for ; Tue, 23 Oct 2001 22:00:03 -0400 (EDT) Date: Tue, 23 Oct 2001 22:00:03 -0400 (EDT) From: Nguyen-Tuong Long Le To: Subject: ECN implementation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, Now that ECN has become an IETF standard RFC, I just wonder what is the status of the ECN implementation in FreeBSD hosts. I know that it used to be part of the ALTQ patch but its implementation seem to be stopped in the recent ALTQ versions. Please kindly send your reply to me since I am not on the list. Thanks, Long To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 22:19:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by hub.freebsd.org (Postfix) with ESMTP id 944A537B401 for ; Tue, 23 Oct 2001 22:19:47 -0700 (PDT) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id f9O5JdD71449; Wed, 24 Oct 2001 01:19:39 -0400 (EDT) (envelope-from barney) Date: Wed, 24 Oct 2001 01:19:39 -0400 From: Barney Wolff To: Kirk Strauser Cc: freebsd-net@FreeBSD.ORG Subject: Re: Silly problem has me stumped Message-ID: <20011024011939.A71324@tp.databus.com> References: <87lmi1n6h5.fsf@pooh.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <87lmi1n6h5.fsf@pooh.int>; from kirk@strauser.com on Tue, Oct 23, 2001 at 08:59:18PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Oct 23, 2001 at 08:59:18PM -0500, Kirk Strauser wrote: > > Well, we have a whole public /24. Only the routing block is private, which > I'm sure will seem like a better idea once I coerce this $@#!() FreeBSD box > to bend to my will. If you have a whole /24, and you need to do stuff other than ping and traceroute as a client on your gateway machine (which your original message did NOT say), offer 1.2.3.0/30 to your ISP to use for the link instead of the 1918 addresses. I've seen lots of cases where the ISP side of the link got an address from the customer's block. Or, of course, you could just do what you need from one of your other 253 hosts. Who's your ISP, so we know who to avoid? Credentials or not, using 1918 space like this is dumb, and a violation of 1918 itself. Your customers are going to get odd results on traceroutes to you, if there's anybody filtering 1918 between you - are you prepared for the help desk load? -- Barney Wolff "Nonetheless, ease and peace had left this people still curiously tough. They were, if it came to it, difficult to daunt or to kill; and they were, perhaps, so unwearyingly fond of good things not least because they could, when put to it, do without them, and could survive rough handling by grief, foe, or weather in a way that astonished those who did not know them well and looked no further than their bellies and their well-fed faces." J.R.R.T. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 23 23:27:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 0823937B405; Tue, 23 Oct 2001 23:27:48 -0700 (PDT) Received: from mindspring.com (dialup-209.244.104.31.Dial1.SanJose1.Level3.net [209.244.104.31]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id XAA06367; Tue, 23 Oct 2001 23:27:41 -0700 (PDT) Message-ID: <3BD65F31.24768789@mindspring.com> Date: Tue, 23 Oct 2001 23:26:57 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shoichi Sakane Cc: hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: IPSEC sucking up memory References: <3BBEC4F7.D15FF792@mindspring.com> <20011023130449I.sakane@kame.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Shoichi Sakane wrote: > > While investigating a problem, I noticed that the IPSEC code > > is initializing the sp -- even when no one is using IPSEC. > > > It turns out that this really, really bloats the per socket > > memory requirements, with the only real result being a lot > > of extra processing that could be replaced by a pointer is > > not NULL check. > > > It seems to me that this could be handled in the TCP, UDP, > > and IP userreq code by only initializing the thing in the > > case that a policy has been set. Is there some reason why > > this can't be done? > > IPsec specification requires to consult the SPD with all of packets > in order to handling the packet. it defines RFC2401. > if a pointer to the entry of the SPD is NULL, it means the security > policy is not defined. so the kernel consults the system wide default. > it never means nothing to do. So you are saying that I could establish a global default, and make the sp pointer NULL, and have that mean "use the global default", instead of copying identical policies all over the place, right? I think this would be the best approach, and it would get me all of the redundant "deep copy" memory back in the default case. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 0: 5:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp.noos.fr (claudel.noos.net [212.198.2.83]) by hub.freebsd.org (Postfix) with ESMTP id BB41337B401 for ; Wed, 24 Oct 2001 00:05:18 -0700 (PDT) Received: (qmail 5710086 invoked by uid 0); 24 Oct 2001 07:05:17 -0000 Received: from unknown (HELO gits.dyndns.org) ([212.198.229.145]) (envelope-sender ) by 212.198.2.83 (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 24 Oct 2001 07:05:17 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.6/8.11.6) id f9O75Fo49531; Wed, 24 Oct 2001 09:05:15 +0200 (CEST) (envelope-from root) Message-Id: <200110240705.f9O75Fo49531@gits.dyndns.org> Subject: Re: PXE boot vs. DHCP In-Reply-To: <200110232019.f9NKJnJ04011@vashon.polstra.com> To: John Polstra Date: Wed, 24 Oct 2001 09:05:15 +0200 (CEST) Cc: net@freebsd.org Reply-To: clefevre@citeweb.net From: Cyrille Lefevre Organization: ACME X-Face: X-Mailer: ELM [version 2.4ME+ PL94c (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Polstra wrote: > In article <200110232013.f9NKDmU27220@gits.dyndns.org>, > Cyrille Lefevre wrote: > > IMHO, it would be better to provide a /etc/dhclient-enter-hooks > > while you are net installing the station, then remove it when > > finished. > > > > the dhclient-enter-hooks would be almost what you are doing : > > > > #!/bin/sh > > > > if [ x$reason = xPREINIT ]; then > > case `ifconfig $interface` in > > *flags=*[\<,]UP[\>,]*) exit 0 ;; > > esac > > fi > > I know the problem could be solved that way, and if I were using a > Microsoft operating system that's what I'd have to do. But this is > FreeBSD, and we can fix things that are broken. > > What is the reason you think it would be better to put the solution > into dhclient-enter-hooks? IMHO, for instance, because this hack is only needed at PXE level not after, I am right ? Cyrille. -- Cyrille Lefevre mailto:clefevre@citeweb.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 0:31:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from brisefer.cediti.be (brisefer.cediti.be [193.190.156.67]) by hub.freebsd.org (Postfix) with ESMTP id 8327437B405 for ; Wed, 24 Oct 2001 00:31:20 -0700 (PDT) Received: by brisefer.cediti.be with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Oct 2001 09:28:59 +0200 Message-ID: From: Olivier Cherrier To: 'Ryan Masse' , freebsd-net@freebsd.org Subject: RE: pptp via mpd Date: Wed, 24 Oct 2001 09:28:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Is it possible to authenticate users on /etc/master.passwd or >by some other >method possibly RADIUS or an SQL table? storing the usernames >and passwords >in the mpd.secret file is redundant and insecure IMHO. > >Ryan > PPTP is itself insecure against SSH or IPSEC... MPD is a great application. Using MPD is as secure as PPTP is! :) oc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 2: 9: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from mx1.dev.itouchnet.net (devco.net [196.15.188.2]) by hub.freebsd.org (Postfix) with ESMTP id 78AA837B405 for ; Wed, 24 Oct 2001 02:09:06 -0700 (PDT) Received: from nobody by mx1.dev.itouchnet.net with scanned_ok (Exim 3.33 #2) id 15wK24-000BUe-00 for freebsd-net@freebsd.org; Wed, 24 Oct 2001 11:09:04 +0200 Received: from shell.devco.net ([196.15.188.7]) by mx1.dev.itouchnet.net with esmtp (Exim 3.33 #2) id 15wK22-000BUJ-00; Wed, 24 Oct 2001 11:09:02 +0200 Received: from bvi by shell.devco.net with local (Exim 3.33 #4) id 15wK2A-000BAI-00; Wed, 24 Oct 2001 11:09:10 +0200 Date: Wed, 24 Oct 2001 11:09:10 +0200 From: Barry Irwin To: Olivier Cherrier Cc: 'Ryan Masse' , freebsd-net@freebsd.org Subject: Re: pptp via mpd Message-ID: <20011024110909.H24235@itouchlabs.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Olivier.Cherrier@cediti.be on Wed, Oct 24, 2001 at 09:28:58AM +0200 X-Checked: This message has been scanned for any virusses and unauthorized attachments. X-iScan-ID: 44180-1003914544-84972@mx1.dev.itouchnet.net version $Name: $ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed 2001-10-24 (09:28), Olivier Cherrier wrote: > > PPTP is itself insecure against SSH or IPSEC... > MPD is a great application. Using MPD is as secure as > PPTP is! :) > slightly off topic form the original question, but PPTP works rather well over IPSEc, infact iirc win2k will attempt to setup an IPSEC connection when you establish a VPN session. FreeBSD IPSEC +racoon work really nicely ( well other than the wierd issue I am having in 4.4 :<) Barry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 4:23:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 7A4C837B401 for ; Wed, 24 Oct 2001 04:23:25 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [fec0::1:12]) by Awfulhak.org (8.11.6/8.11.6) with ESMTP id f9OBNNT41843; Wed, 24 Oct 2001 12:23:23 +0100 (BST) (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.6/8.11.6) with ESMTP id f9OBNNL64453; Wed, 24 Oct 2001 12:23:23 +0100 (BST) (envelope-from brian@freebsd-services.com) Message-Id: <200110241123.f9OBNNL64453@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: chuakk@lycos.com Cc: "Brian Somers" , users@ipv6.org, freebsd-net@freebsd.org, brian@hak.lan.Awfulhak.org, brian@hak.lan.Awfulhak.org Subject: Re: IPv6 /PPP using FreeBSD 4.4 In-Reply-To: Message from "kim chua" of "Wed, 24 Oct 2001 19:13:58 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Oct 2001 12:23:23 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Hi Brian, > > thanks alot for your info.. I can assigned IPv6 address using ppp.conf like you showed me. > > However, when ppp was started using ppp -auto, tun0 appears and > you can see the assigned IPv6 address on tun0. But when the connection > is established with the peer, tun1 appears and tun1 is where the > actual connection established with the link local addresses. > > What i want to achieve is to have the connection established at > tun0 where the global IPv6 was already assigned... This is what should be happening. I would guess that something else on your machine is starting another ppp invocation (on tun1) - although this sounds bizarre. > Below is the ifconfig from my machine: > > > tun0: flags=8051 mtu 1500 > inet6 fe80::250:4ff:fec1:ba68%tun0 prefixlen 64 scopeid 0x8 > inet 10.0.0.2 --> 10.0.0.1 netmask 0xffffff00 > inet6 2001:200:703:1::1 --> 2001:200:703:1::2 prefixlen 128 > Opened by PID 2025 > tun1: flags=8051 mtu 1500 > inet6 fe80::250:4ff:fec1:ba68%tun1 prefixlen 64 scopeid 0x9 > inet 0.0.0.0 --> 192.168.100.2 netmask 0xffffff00 > inet6 fe80::86e4:81d4%tun1 --> fe80::3a48:d102%tun1 prefixlen 128 scopei > d 0x9 > Opened by PID 2007 > tun2: flags=8010 mtu 1500 > inet6 fe80::250:4ff:fec1:ba68%tun2 prefixlen 64 scopeid 0xa > > > any ideas how to prevent the above from occuring??? I guess that depends on what's starting the second ppp invocation. > thanks in advance, > > kim chua > -- [.....] -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 5: 8:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail8.bigmailbox.com (mail8.bigmailbox.com [209.132.220.39]) by hub.freebsd.org (Postfix) with ESMTP id A3A3F37B403 for ; Wed, 24 Oct 2001 05:08:25 -0700 (PDT) Received: (from www@localhost) by mail8.bigmailbox.com (8.10.0/8.10.0) id f9OC89f09963; Wed, 24 Oct 2001 05:08:09 -0700 Date: Wed, 24 Oct 2001 05:08:09 -0700 Message-Id: <200110241208.f9OC89f09963@mail8.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [200.229.133.210] From: "irado@nettaxi.com" To: freebsd-net@freebsd.org, kirk@strauser.com Subject: RE: Silly problem has me stumped Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org think that *if* your ISP is cooperative enough, he can create routing rules saying that your ip-public can be found behind their's own. Also he can make an aliases (YOUR public in THEIR's machine), and a ipfilter/ipw rule saying that 'any request shoud be redirected to YOUR private address' Anyway, it must assure that your ISP is cooperative, otherwise.. And also for the private ip-addr: must not be thru DHCP, otherwise.. >my new public address block is 1.2.3.0/24, and that the routing block >between their network and mine is 10.0.0.0/30, and my default router is saudações, irado furioso com tudo GNU/Linux user CASSADO deus é construído à imagem e semelhança do homem. Principalmente em seus defeitos. por favor, clique aqui: http://www.thehungersite.com e aqui também: http://cf6.uol.com.br/umminuto/ ------------------------------------------------------------ Nettaxi would like to ask for your help in donations to the RED CROSS today! http://www.nyredcross.org/donate/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 6:15:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.tcoip.com.br (cerberus.tcoip.com.br [200.220.254.3]) by hub.freebsd.org (Postfix) with ESMTP id A2E6637B403 for ; Wed, 24 Oct 2001 06:14:58 -0700 (PDT) Received: from tcoip.com.br (xq1ikskqyqxu7y66@[192.168.60.194]) by mail.tcoip.com.br (8.11.1/8.11.1) with ESMTP id f9ODEtN14012 for ; Wed, 24 Oct 2001 11:14:55 -0200 Message-ID: <3BD6BECE.1020308@tcoip.com.br> Date: Wed, 24 Oct 2001 11:14:54 -0200 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.5) Gecko/20011023 X-Accept-Language: en, pt-br, ja MIME-Version: 1.0 To: net@freebsd.org Subject: RTM_NEWADDR Content-Type: multipart/mixed; boundary="------------040304030409040508090003" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------040304030409040508090003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit After a long time looking into this, I have finally understood what's the problem. RTM_NEWADDR is generated sometimes yes, sometimes no. I have absolutely no idea what makes the difference, particularly because I have absolutely no idea where the relevant code portions is located. As for my environment, my test base is all vlan, and I run a routing daemon (zebra). Attached are two logs. The first is a list of commands running in background manipulating the interfaces. The second is the output of route -n monitor at the same time. If anyone can point me in the right direction to debug this problem, I would appreciate immensily. This problem is being a hell on us. -- Daniel C. Sobral (8-DCS) Daniel.Sobral@tcoip.com.br dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net Writing about music is like dancing about architecture. -- Frank Zappa --------------040304030409040508090003 Content-Type: text/plain; name="checa.output" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="checa.output" vlandown fxp2 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp2 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp2 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp2 vlanup fxp0 ifconfig vlan0 vlan 301 vlandev fxp0 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp0 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp0 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.21 (172.31.199.21): 56 data bytes --- 172.31.199.21 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp0 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp0 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp0 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp0 vlanup fxp2 ifconfig vlan0 vlan 301 vlandev fxp2 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp2 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp2 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.22 (172.31.199.22): 56 data bytes --- 172.31.199.22 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp2 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp2 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp2 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp2 vlanup fxp0 ifconfig vlan0 vlan 301 vlandev fxp0 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp0 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp0 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.21 (172.31.199.21): 56 data bytes --- 172.31.199.21 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp0 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp0 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp0 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp0 vlanup fxp2 ifconfig vlan0 vlan 301 vlandev fxp2 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp2 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp2 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.22 (172.31.199.22): 56 data bytes --- 172.31.199.22 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp2 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp2 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp2 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp2 vlanup fxp0 ifconfig vlan0 vlan 301 vlandev fxp0 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp0 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp0 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.21 (172.31.199.21): 56 data bytes --- 172.31.199.21 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp0 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp0 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp0 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp0 vlanup fxp2 ifconfig vlan0 vlan 301 vlandev fxp2 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp2 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp2 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.22 (172.31.199.22): 56 data bytes --- 172.31.199.22 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp2 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp2 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp2 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp2 vlanup fxp0 ifconfig vlan0 vlan 301 vlandev fxp0 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp0 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp0 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.21 (172.31.199.21): 56 data bytes --- 172.31.199.21 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp0 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp0 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp0 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp0 vlanup fxp2 ifconfig vlan0 vlan 301 vlandev fxp2 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp2 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp2 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.22 (172.31.199.22): 56 data bytes --- 172.31.199.22 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp2 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp2 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp2 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp2 vlanup fxp0 ifconfig vlan0 vlan 301 vlandev fxp0 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp0 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp0 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.21 (172.31.199.21): 56 data bytes --- 172.31.199.21 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp0 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp0 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp0 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp0 vlanup fxp2 ifconfig vlan0 vlan 301 vlandev fxp2 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp2 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp2 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.22 (172.31.199.22): 56 data bytes --- 172.31.199.22 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp2 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp2 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp2 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp2 vlanup fxp0 ifconfig vlan0 vlan 301 vlandev fxp0 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp0 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp0 mtu 1500 ifconfig vlan2 up sleep 1 ifconfig vlan0 172.31.199.20 netmask 255.255.255.240 ifconfig vlan1 200.220.255.228 netmask 255.255.255.240 ifconfig vlan2 10.9.33.4 netmask 255.255.255.128 PING 172.31.199.21 (172.31.199.21): 56 data bytes --- 172.31.199.21 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss vlandown fxp0 ifconfig vlan0 delete ifconfig vlan1 delete ifconfig vlan2 delete sleep 1 ifconfig vlan0 down ifconfig vlan0 -vlandev fxp0 ifconfig vlan1 down ifconfig vlan1 -vlandev fxp0 ifconfig vlan2 down ifconfig vlan2 -vlandev fxp0 vlanup fxp2 ifconfig vlan0 vlan 301 vlandev fxp2 mtu 1500 ifconfig vlan0 up ifconfig vlan1 vlan 303 vlandev fxp2 mtu 1500 ifconfig vlan1 up ifconfig vlan2 vlan 302 vlandev fxp2 mtu 1500 ifconfig vlan2 up sleep 1 --------------040304030409040508090003 Content-Type: text/plain; name="monitor.output" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="monitor.output" got message of size 96 on Wed Oct 24 09:38:39 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:38:39 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 128 on Wed Oct 24 09:38:39 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:38:39 2001 RTM_IFINFO: iface status change: len 96, if# 3, flags: got message of size 96 on Wed Oct 24 09:38:40 2001 RTM_IFINFO: iface status change: len 96, if# 1, flags: got message of size 128 on Wed Oct 24 09:38:40 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 128 on Wed Oct 24 09:38:40 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:38:40 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:38:40 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:38:40 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:38:40 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:38:40 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:38:40 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:38:40 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:38:50 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 128 on Wed Oct 24 09:38:50 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:38:50 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 96 on Wed Oct 24 09:38:50 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:38:50 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 128 on Wed Oct 24 09:38:50 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:38:50 2001 RTM_IFINFO: iface status change: len 96, if# 1, flags: got message of size 96 on Wed Oct 24 09:38:51 2001 RTM_IFINFO: iface status change: len 96, if# 3, flags: got message of size 128 on Wed Oct 24 09:38:51 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 128 on Wed Oct 24 09:38:51 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:38:51 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:38:51 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:38:51 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:38:51 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:38:51 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:38:51 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:38:51 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:39:00 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 128 on Wed Oct 24 09:39:00 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:39:00 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 96 on Wed Oct 24 09:39:00 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:00 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 128 on Wed Oct 24 09:39:00 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:39:00 2001 RTM_IFINFO: iface status change: len 96, if# 3, flags: got message of size 96 on Wed Oct 24 09:39:01 2001 RTM_IFINFO: iface status change: len 96, if# 1, flags: got message of size 128 on Wed Oct 24 09:39:01 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 128 on Wed Oct 24 09:39:01 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:39:01 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:39:01 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:39:01 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:39:01 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:01 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:01 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:39:01 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:39:11 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 128 on Wed Oct 24 09:39:11 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:39:11 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 96 on Wed Oct 24 09:39:11 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:11 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 128 on Wed Oct 24 09:39:11 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:39:11 2001 RTM_IFINFO: iface status change: len 96, if# 1, flags: got message of size 96 on Wed Oct 24 09:39:12 2001 RTM_IFINFO: iface status change: len 96, if# 3, flags: got message of size 128 on Wed Oct 24 09:39:12 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 128 on Wed Oct 24 09:39:12 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:39:12 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:39:12 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:39:12 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:39:12 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:12 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:12 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:39:12 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:39:21 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 128 on Wed Oct 24 09:39:21 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:39:21 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 96 on Wed Oct 24 09:39:21 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:21 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 128 on Wed Oct 24 09:39:21 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:39:21 2001 RTM_IFINFO: iface status change: len 96, if# 3, flags: got message of size 96 on Wed Oct 24 09:39:22 2001 RTM_IFINFO: iface status change: len 96, if# 1, flags: got message of size 128 on Wed Oct 24 09:39:22 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 128 on Wed Oct 24 09:39:22 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:39:22 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:39:22 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:39:22 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:39:22 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:22 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:22 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:39:22 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:39:31 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 128 on Wed Oct 24 09:39:32 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:39:32 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 96 on Wed Oct 24 09:39:32 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:32 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 128 on Wed Oct 24 09:39:32 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:39:32 2001 RTM_IFINFO: iface status change: len 96, if# 1, flags: got message of size 96 on Wed Oct 24 09:39:33 2001 RTM_IFINFO: iface status change: len 96, if# 3, flags: got message of size 128 on Wed Oct 24 09:39:33 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 128 on Wed Oct 24 09:39:33 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:39:33 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:39:33 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:39:33 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:39:33 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:33 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:33 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:39:33 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:39:42 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 128 on Wed Oct 24 09:39:42 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:39:42 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 96 on Wed Oct 24 09:39:42 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:42 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 128 on Wed Oct 24 09:39:42 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:39:42 2001 RTM_IFINFO: iface status change: len 96, if# 3, flags: got message of size 96 on Wed Oct 24 09:39:43 2001 RTM_IFINFO: iface status change: len 96, if# 1, flags: got message of size 128 on Wed Oct 24 09:39:43 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 128 on Wed Oct 24 09:39:43 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:39:43 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:39:43 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:39:43 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:39:43 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:43 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:43 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:39:43 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:39:52 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 128 on Wed Oct 24 09:39:52 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:39:52 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 96 on Wed Oct 24 09:39:53 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:53 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 128 on Wed Oct 24 09:39:53 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:39:53 2001 RTM_IFINFO: iface status change: len 96, if# 1, flags: got message of size 96 on Wed Oct 24 09:39:54 2001 RTM_IFINFO: iface status change: len 96, if# 3, flags: got message of size 128 on Wed Oct 24 09:39:54 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 128 on Wed Oct 24 09:39:54 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:39:54 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:39:54 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:39:54 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:39:54 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:54 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:39:54 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:39:54 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:40:03 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 128 on Wed Oct 24 09:40:03 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:40:03 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 96 on Wed Oct 24 09:40:03 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:40:03 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 128 on Wed Oct 24 09:40:03 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:40:03 2001 RTM_IFINFO: iface status change: len 96, if# 3, flags: got message of size 96 on Wed Oct 24 09:40:04 2001 RTM_IFINFO: iface status change: len 96, if# 1, flags: got message of size 128 on Wed Oct 24 09:40:04 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 128 on Wed Oct 24 09:40:04 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:40:04 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:40:04 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:40:04 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:40:04 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:40:04 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:40:04 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:40:04 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:40:13 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 128 on Wed Oct 24 09:40:13 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:40:13 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 96 on Wed Oct 24 09:40:13 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:40:14 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 128 on Wed Oct 24 09:40:14 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:40:14 2001 RTM_IFINFO: iface status change: len 96, if# 1, flags: got message of size 96 on Wed Oct 24 09:40:15 2001 RTM_IFINFO: iface status change: len 96, if# 3, flags: got message of size 128 on Wed Oct 24 09:40:15 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 128 on Wed Oct 24 09:40:15 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:40:15 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:40:15 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:40:15 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:40:15 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:40:15 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:40:15 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:40:15 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:40:24 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 128 on Wed Oct 24 09:40:24 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:40:24 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 96 on Wed Oct 24 09:40:24 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:40:24 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 128 on Wed Oct 24 09:40:24 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp2:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:40:24 2001 RTM_IFINFO: iface status change: len 96, if# 3, flags: got message of size 96 on Wed Oct 24 09:40:25 2001 RTM_IFINFO: iface status change: len 96, if# 1, flags: got message of size 128 on Wed Oct 24 09:40:25 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 128 on Wed Oct 24 09:40:25 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:40:25 2001 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.1 got message of size 96 on Wed Oct 24 09:40:25 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:40:25 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 96 on Wed Oct 24 09:40:25 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:40:25 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:40:25 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:40:25 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 96 on Wed Oct 24 09:40:34 2001 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 128 on Wed Oct 24 09:40:34 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.5 got message of size 128 on Wed Oct 24 09:40:34 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.6 got message of size 96 on Wed Oct 24 09:40:34 2001 RTM_IFINFO: iface status change: len 96, if# 7, flags: got message of size 96 on Wed Oct 24 09:40:35 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 128 on Wed Oct 24 09:40:35 2001 RTM_DELMADDR: multicast group membership removed from iface: len 128, sockaddrs: fxp0:0.3.47.71.83.88 1.0.5e.0.0.1 --------------040304030409040508090003-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 8:14:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 94DB037B406 for ; Wed, 24 Oct 2001 08:14:34 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id f9OFE7898480; Wed, 24 Oct 2001 08:14:08 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id f9OFDq006831; Wed, 24 Oct 2001 08:13:52 -0700 (PDT) (envelope-from jdp) Date: Wed, 24 Oct 2001 08:13:52 -0700 (PDT) Message-Id: <200110241513.f9OFDq006831@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: clefevre@citeweb.net Subject: Re: PXE boot vs. DHCP In-Reply-To: <200110240705.f9O75Fo49531@gits.dyndns.org> References: <200110240705.f9O75Fo49531@gits.dyndns.org> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <200110240705.f9O75Fo49531@gits.dyndns.org>, Cyrille Lefevre wrote: > John Polstra wrote: > > > > What is the reason you think it would be better to put the solution > > into dhclient-enter-hooks? > > IMHO, for instance, because this hack is only needed at PXE level > not after, I am right ? Not quite. It's not the "PXE level," it's the normal operating state of the system. The only difference is that it was booted with PXE instead of by some other means. PXE booting is being used more and more at large installations. My change addresses a common situation which is becoming more common all the time. Shouldn't the standard dhclient installation function properly, regardless of how the system was booted? I think it should. Also, I don't feel that my patch is a hack. The entire purpose of dhclient's PREINIT phase is to put the network interface into an enabled state so that IP packets can be sent. If the interface is already up, then it is already in that state. By failing to check the interface first, the current dhclient-script needlessly destroys its configuration and hangs the system. That is a bug, and my patch fixes it. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 8:55:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from hermes.intergate.ca (hermes.intergate.ca [207.34.179.108]) by hub.freebsd.org (Postfix) with SMTP id 460B337B401 for ; Wed, 24 Oct 2001 08:55:09 -0700 (PDT) Received: (qmail 35923 invoked by uid 1007); 24 Oct 2001 16:31:32 -0000 Received: from landons@uniserve.com by hermes.intergate.ca with qmail-scanner-0.93 (uvscan: v4.0.50/v4166. . Clean. Processed in 0.934436 secs); 24/10/2001 09:31:31 Received: from landons.vpp-office.uniserve.ca (HELO pirahna.uniserve.com) (216.113.198.10) by hermes.intergate.ca with SMTP; 24 Oct 2001 16:31:30 -0000 Message-Id: <5.1.0.14.0.20011024084343.031b7770@pop.uniserve.com> X-Sender: landons@pop.uniserve.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 24 Oct 2001 08:54:41 -0700 To: freebsd-net@FreeBSD.ORG From: Landon Stewart Subject: ADSL with two interfaces in one machine using "dhclient" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I can obtain two seperate IP addresses and everything routes OK for both interfaces. Its just these ARP messages that are annoying me (filling up my logs with repeated messages). I'm having a problem with ARP's from my gateway. Both interfaces use the same gateway, but I get an error message in the log stating that: (GW = Gateway, IP1 = IP of first interface etc...) /kernel: arp: is on xl0 but got reply from on ed0 last message repeated 35 times last message repeated 136 times last message repeated 149 times last message repeated 112 times /kernel: arp: is on ed0 but got reply from on xl0 last message repeated 94 times last message repeated 111 times etc. etc... Failing this how can I stop the kernel from even logging this? (what to turn off?) I also get errors saying that my interface MAC addresses have changed (this is due to one interface thinking that the other interfaces MAC address is the MAC of my DSL router, and then it finds the REAL MAC address for the other interface and so forth). I have set a metric (scopeid) to one on my primary interface and to two on my secondary interface. External connections. A switch rather than a hub could fix this problem and I'll probably buy one anyway, but I'd like to know how to stop this. Can I have two interfaces with the same gateway without getting MAC address notices? --- Landon Stewart landons@uniserve.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 9:11:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id D9F9437B407 for ; Wed, 24 Oct 2001 09:11:25 -0700 (PDT) Received: by tao.org.uk (Postfix, from userid 100) id 9AF0A40F; Wed, 24 Oct 2001 17:11:07 +0100 (BST) Date: Wed, 24 Oct 2001 17:11:07 +0100 From: Josef Karthauser To: John Polstra Cc: net@freebsd.org, clefevre@citeweb.net Subject: Re: PXE boot vs. DHCP Message-ID: <20011024171107.R46678@tao.org.uk> References: <200110240705.f9O75Fo49531@gits.dyndns.org> <200110241513.f9OFDq006831@vashon.polstra.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="KqBSqvdnnccM6+Kg" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110241513.f9OFDq006831@vashon.polstra.com>; from jdp@polstra.com on Wed, Oct 24, 2001 at 08:13:52AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --KqBSqvdnnccM6+Kg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 24, 2001 at 08:13:52AM -0700, John Polstra wrote: =20 > Not quite. It's not the "PXE level," it's the normal operating state > of the system. The only difference is that it was booted with PXE > instead of by some other means. PXE booting is being used more and > more at large installations. My change addresses a common situation > which is becoming more common all the time. >=20 > Shouldn't the standard dhclient installation function properly, > regardless of how the system was booted? I think it should. >=20 > Also, I don't feel that my patch is a hack. The entire purpose of > dhclient's PREINIT phase is to put the network interface into an > enabled state so that IP packets can be sent. If the interface is > already up, then it is already in that state. By failing to check the > interface first, the current dhclient-script needlessly destroys its > configuration and hangs the system. That is a bug, and my patch fixes > it. Hear hear. Joe --KqBSqvdnnccM6+Kg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjvW6BsACgkQXVIcjOaxUBaKJACeMZzu29Df6S+ZSTwn0c1EGiFk hi8An38Izgq+UyL+5ea++I/IuMpAkGgc =3gsr -----END PGP SIGNATURE----- --KqBSqvdnnccM6+Kg-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 10:17:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from alf.uib.no (alf.uib.no [129.177.30.3]) by hub.freebsd.org (Postfix) with ESMTP id 7839137B401 for ; Wed, 24 Oct 2001 10:17:27 -0700 (PDT) Received: from hyll.ii.uib.no (ii.uib.no) [129.177.16.27] by alf.uib.no for freebsd-net@freebsd.org with esmtp (Exim 3.16) id 15wReF-0000jm-00; Wed, 24 Oct 2001 19:16:59 +0200 Message-ID: <3BD6FA2F.6070509@ii.uib.no> Date: Wed, 24 Oct 2001 19:28:15 +0200 From: Trond Davidsen Organization: Institutt for Informatikk, UiB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Mpd with a large number, 200+ , of bundles Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, some info about the machine: vpn-gw2# uname -a FreeBSD vpn-gw2 4.4-STABLE FreeBSD 4.4-STABLE #2: Tue Oct 16 16:42:27 CEST 2001 root@vpn-gw2:/usr/obj/usr/src/sys/VPN-GW2 i386 vpn-gw2# The machine is a dual 700MHz PIII with 512MB ram and 3 3c905B nics. /etc/sysctl.conf looks like this: vpn-gw2# cat /etc/sysctl.conf kern.ipc.shm_use_phys=1 vfs.vmiodirenable=1 net.inet.tcp.sendspace=65535 net.inet.tcp.recvspace=65535 net.inet.tcp.always_keepalive=1 kern.ipc.somaxconn=1024 net.inet.ip.rtexpire=10 I'm trying to set up mpd as a replacement for poptop + ppp. But I run into a problem when I try to configure more than 100 bundles. When I configure 30 bundles, everything works nicely. When I configure 100 bundles, things seems to work nicely, but when I run ngctl, I get the following error when typing 'list' at the ngctl prompt: [lines for ng100 - ng24 removed] Name: ng23 Type: iface ID: 00000849 Num hooks: 1 Name: Type: socket ID: 00000848 Num hooks: 2 Name: Type: vjc ID: 00000847 Num hooks: 4 Name: Type: bpf ID: 00000846 Num hooks: 3 Name: mpd37379-pptp12 Type: ppp ID: 00000845 Num hooks: 6 Name: ng22 Type: iface ID: 00000844 Num hooks: 1 Name: Type: socket ID: 00000843 Num hooks: 2 Name: Type: vjc ID: 00000842 Num hooks: 4 Name: Type: bpf ID: 00000841 Num hooks: 3 Name: xl0 Type: ether ID: 00000001 Num hooks: 0 ngctl: send msg: No such file or directory + quit it seems to be missing ng0 - ng21, but ifconfig shows all the interfaces. Earlier ngctl would not list any interfaces but print something like the following: + list ngctl: send msg: No buffer space available + quit which buffer is this, and how do I make it larger? On a PIII 1.3GHz with 1GB ram, trying to run with 110 bundles: vpn-gw3# uname -a FreeBSD vpn-gw3 4.4-STABLE FreeBSD 4.4-STABLE #0: Thu Oct 18 18:37:21 CEST 2001 root@vpn-gw3:/usr/obj/usr/src/sys/VPN-GW3 i386 vpn-gw3# [cut out 97 bundle configs] [pptp98] ppp node is "mpd18285-pptp98" [pptp98] using interface ng108 Radius: radius_Init [pptp99] ppp node is "mpd18285-pptp99" [pptp99] using interface ng109 Radius: radius_Init [pptp100] can't name ppp node: Address already in use [pptp100] netgraph initialization failed [pptp101] can't name ppp node: Address already in use [pptp101] netgraph initialization failed [pptp102] can't name ppp node: Address already in use [pptp102] netgraph initialization failed [pptp103] can't name ppp node: Address already in use [pptp103] netgraph initialization failed [pptp104] can't name ppp node: Address already in use [pptp104] netgraph initialization failed [pptp105] can't name ppp node: Address already in use [pptp105] netgraph initialization failed [pptp106] can't name ppp node: Address already in use [pptp106] netgraph initialization failed [pptp107] can't name ppp node: Address already in use [pptp107] netgraph initialization failed [pptp108] can't name ppp node: Address already in use [pptp108] netgraph initialization failed [pptp109] can't name ppp node: Address already in use [pptp109] netgraph initialization failed [pptp110] can't name ppp node: Address already in use [pptp110] netgraph initialization failed [pptp99:pptp99] vpn-gw3# ngctl + list ngctl: send msg: No buffer space available + This is with standard sendspace/recvspace. Trond To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 10:40:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 7458C37B405 for ; Wed, 24 Oct 2001 10:40:13 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id f9OHdng06092; Wed, 24 Oct 2001 20:39:49 +0300 (EEST) (envelope-from ru) Date: Wed, 24 Oct 2001 20:39:49 +0300 From: Ruslan Ermilov To: "Daniel C. Sobral" Cc: net@FreeBSD.ORG Subject: Re: RTM_NEWADDR Message-ID: <20011024203949.C4437@sunbay.com> References: <3BD6BECE.1020308@tcoip.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BD6BECE.1020308@tcoip.com.br>; from daniel.sobral@tcoip.com.br on Wed, Oct 24, 2001 at 11:14:54AM -0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Oct 24, 2001 at 11:14:54AM -0200, Daniel C. Sobral wrote: > After a long time looking into this, I have finally understood what's > the problem. RTM_NEWADDR is generated sometimes yes, sometimes no. I > have absolutely no idea what makes the difference, particularly because > I have absolutely no idea where the relevant code portions is located. > > As for my environment, my test base is all vlan, and I run a routing > daemon (zebra). Attached are two logs. The first is a list of commands > running in background manipulating the interfaces. The second is the > output of route -n monitor at the same time. > > If anyone can point me in the right direction to debug this problem, I > would appreciate immensily. This problem is being a hell on us. > I don't see RTM_NEWADDR's in the logs, only RTM_NEWMADDR's. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 11: 4:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from skill.myway.com.br (skill.myway.com.br [200.173.75.10]) by hub.freebsd.org (Postfix) with ESMTP id 9314837B405; Wed, 24 Oct 2001 11:04:52 -0700 (PDT) Received: from myway.com.br (sup_03.myway.com.br [10.0.0.15]) by skill.myway.com.br (8.11.1/8.11.1) with ESMTP id f9OIK4h01241; Wed, 24 Oct 2001 16:20:05 -0200 (BRST) (envelope-from leal@myway.com.br) Message-ID: <3BD6F720.8DBFA15@myway.com.br> Date: Wed, 24 Oct 2001 15:15:12 -0200 From: Marcelo Leal Organization: webcom X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: pt-BR, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: [Fwd: colisions!] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org i have the follow problem: i use etinc in one FreeBSD box (4.2). it works fine. this freebsd make bridge (one interface in switch), and another cross over to router. in the conection to router, there are one colision led, that are almost always up! i did put one rule for bridge only ip in rl0 (switch interface). why there are colisions betwen etinc and router??? the etinc interface are 10Mbps (half-duplex) and router too. the cross over is: etinc 1 2 orange/white 3 6 blue/white router 1 2 blue/white 3 6 orange/white thanks ___________  The ISP-WIRELESS Discussion List  ___________ To Join: mailto:join-isp-wireless@isp-wireless.com To Remove: mailto:remove-isp-wireless@isp-wireless.com Archives: http://isp-lists.isp-planet.com/isp-wireless/archives/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 11:19:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.tcoip.com.br (cerberus.tcoip.com.br [200.220.254.3]) by hub.freebsd.org (Postfix) with ESMTP id D294237B406 for ; Wed, 24 Oct 2001 11:19:09 -0700 (PDT) Received: from tcoip.com.br (y55usirld0u1knip@[192.168.60.194]) by mail.tcoip.com.br (8.11.1/8.11.1) with ESMTP id f9OIJ6j17316; Wed, 24 Oct 2001 16:19:06 -0200 Message-ID: <3BD70618.7080104@tcoip.com.br> Date: Wed, 24 Oct 2001 16:19:04 -0200 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.5) Gecko/20011023 X-Accept-Language: en, pt-br, ja MIME-Version: 1.0 To: Alan Cc: net@FreeBSD.ORG Subject: Re: Fw: documentacao do sistema de gerencia References: <3BD6BECE.1020308@tcoip.com.br> <20011024203949.C4437@sunbay.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Alan wrote: > On Wed, Oct 24, 2001 at 11:14:54AM -0200, Daniel C. Sobral wrote: > >>After a long time looking into this, I have finally understood what's >>the problem. RTM_NEWADDR is generated sometimes yes, sometimes no. I >>have absolutely no idea what makes the difference, particularly because >>I have absolutely no idea where the relevant code portions is located. >> >>As for my environment, my test base is all vlan, and I run a routing >>daemon (zebra). Attached are two logs. The first is a list of commands >>running in background manipulating the interfaces. The second is the >>output of route -n monitor at the same time. >> >>If anyone can point me in the right direction to debug this problem, I >>would appreciate immensily. This problem is being a hell on us. >> >> > I don't see RTM_NEWADDR's in the logs, only RTM_NEWMADDR's. Well, that's the whole point. It should. -- Daniel C. Sobral (8-DCS) Daniel.Sobral@tcoip.com.br dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net There is nothing more silly than a silly laugh. -- Gaius Valerius Catullus To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 13:27:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.conforama.fr (mail.conforama.fr [195.46.202.42]) by hub.freebsd.org (Postfix) with ESMTP id 52FDB37B403 for ; Wed, 24 Oct 2001 13:27:22 -0700 (PDT) Received: by mail.conforama.fr; id VAA23901; Wed, 24 Oct 2001 21:21:18 +0200 (CEST) Received: from nt-antivirus(192.168.23.111) by mail.conforama.fr via smap (4.0) id xma023806; Wed, 24 Oct 2001 21:20:52 +0200 Received: from s60170 ([172.25.4.17]) by snlogn01.conforama.fr (Lotus Domino Release 5.0.5) with SMTP id 2001102418313362:78 ; Wed, 24 Oct 2001 18:31:33 +0200 Message-ID: <002601c15cb4$064fb440$aa3c0007@home.conforama.fr> Reply-To: "Cyrille Lefevre" From: "Cyrille Lefevre" To: , "John Polstra" References: <200110240705.f9O75Fo49531@gits.dyndns.org> <200110241513.f9OFDq006831@vashon.polstra.com> Subject: Re: PXE boot vs. DHCP Date: Wed, 24 Oct 2001 18:48:01 +0100 Organization: SEEVIA MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MIMETrack: Itemize by SMTP Server on SNLOGN01/CONFORAMA(Release 5.0.5 |September 22, 2000) at 24/10/2001 18:31:33, Serialize by Router on SNLOGN01/CONFORAMA(Release 5.0.5 |September 22, 2000) at 24/10/2001 22:15:32, Serialize complete at 24/10/2001 22:15:32 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "John Polstra" wrote: > In article <200110240705.f9O75Fo49531@gits.dyndns.org>, > Cyrille Lefevre wrote: > > John Polstra wrote: > > > > > > What is the reason you think it would be better to put the solution > > > into dhclient-enter-hooks? > > > > IMHO, for instance, because this hack is only needed at PXE level > > not after, I am right ? > > Not quite. It's not the "PXE level," it's the normal operating state > of the system. The only difference is that it was booted with PXE > instead of by some other means. PXE booting is being used more and > more at large installations. My change addresses a common situation > which is becoming more common all the time. > > Shouldn't the standard dhclient installation function properly, > regardless of how the system was booted? I think it should. > > Also, I don't feel that my patch is a hack. The entire purpose of > dhclient's PREINIT phase is to put the network interface into an > enabled state so that IP packets can be sent. If the interface is > already up, then it is already in that state. By failing to check the > interface first, the current dhclient-script needlessly destroys its > configuration and hangs the system. That is a bug, and my patch fixes > it. ok, did you ask the dhcp mailing list about that ? since, as a general rule, dhclient should be fixed for all platforms and not only for FreeBSD... Cyrille. -- mailto:clefevre@citeweb.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 13:55:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by hub.freebsd.org (Postfix) with ESMTP id 425BE37B401; Wed, 24 Oct 2001 13:55:46 -0700 (PDT) Received: from tel.fer.hr (zg04-088.dialin.iskon.hr [213.191.137.89]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id f9OKtVH24614; Wed, 24 Oct 2001 22:55:36 +0200 (MEST) Message-ID: <3BD72A77.712CF51C@tel.fer.hr> Date: Wed, 24 Oct 2001 22:54:15 +0200 From: Marko Zec X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: net@freebsd.org, hackers@freebsd.org Cc: jlemon@freebsd.org Subject: fxp patch - bundling receive interrupts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org An updated fxp driver patch for bundling receive interrupts, thus saving a noticeable amount of CPU overhead for interrupt processing, can be found at http://www.tel.fer.hr/zec/BSD/fxp/. New features include: - control of microcode parameters through sysctl variables - activation/deactivation of microcode without bringing the interface down - independent control of microcode parameters/activity for each fxp interface instance - new parameter hw.fxp.size_mask - hw.fxp.int_delay is now defined in microseconds, instead of microcode time-counter units The microcode should work on many revisions - if not all - of Intel 8255* chipset, but the BSD driver is currently tested only on 82558-B0, so I would really appreciate any feedback on driver functionality/stability on other chipset revisions. Have fun! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 14:23: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by hub.freebsd.org (Postfix) with ESMTP id E90B437B403; Wed, 24 Oct 2001 14:22:52 -0700 (PDT) Received: from tel.fer.hr (zg04-088.dialin.iskon.hr [213.191.137.89]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id f9OLMZH05464; Wed, 24 Oct 2001 23:22:36 +0200 (MEST) Message-ID: <3BD7312F.470044F@tel.fer.hr> Date: Wed, 24 Oct 2001 23:22:55 +0200 From: Marko Zec X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dennis Wong Cc: net@freebsd.org, hackers@freebsd.org Subject: Re: fxp patch - bundling receive interrupts References: <04311C809F7CD411B97D00D0B78EC6B902298195@nvapollo.nvidia.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I am not an official FreeBSD commiter, so I can't tell really... Therefore jlemon was in cc: (he is the fxp driver maintainer), so it is his call. Nevertheless, I think this patch needs a little bit more testing - there are many 8255* chipset revisions out there, and as the code is *very* chipset dependent, we should wait for gathering some feedback first from the people testing the driver. Dennis Wong wrote: > Marko, > > Is this going to be rolled into -stable anytime soon? > > Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 15: 0:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id BB16037B406 for ; Wed, 24 Oct 2001 15:00:34 -0700 (PDT) Received: (qmail 79076 invoked by uid 1000); 24 Oct 2001 22:00:32 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 24 Oct 2001 22:00:32 -0000 Date: Wed, 24 Oct 2001 17:00:32 -0500 (CDT) From: Mike Silbersack To: Marko Zec Cc: , , Subject: Re: fxp patch - bundling receive interrupts In-Reply-To: <3BD72A77.712CF51C@tel.fer.hr> Message-ID: <20011024165611.F78388-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 24 Oct 2001, Marko Zec wrote: > An updated fxp driver patch for bundling receive interrupts, thus saving > a noticeable amount of CPU overhead for interrupt processing, can be > found at http://www.tel.fer.hr/zec/BSD/fxp/. New features include: I haven't reviewed the code and don't have a fxp near, but your patch sounds impressive. I'm sure we'd all be proud of its inclusion in -stable once enough testing has been performed. That being said, I thought I should check on one thing: In your original post, you mentioned that these techniques came from the linux drive for these cards. In the process of writing this patch, did you copy any section of code from the Linux driver? If possible, it would be best to avoid any GPL entanglements. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 15:25:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by hub.freebsd.org (Postfix) with ESMTP id DF3AF37B405; Wed, 24 Oct 2001 15:25:32 -0700 (PDT) Received: from tel.fer.hr (zg03-085.dialin.iskon.hr [213.191.135.86]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id f9OMPKH27376; Thu, 25 Oct 2001 00:25:20 +0200 (MEST) Message-ID: <3BD73FE2.20A464A2@tel.fer.hr> Date: Thu, 25 Oct 2001 00:25:38 +0200 From: Marko Zec X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: net@freebsd.org, hackers@freebsd.org, jlemon@freebsd.org Subject: Re: fxp patch - bundling receive interrupts References: <20011024165611.F78388-100000@achilles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Silbersack wrote: > That being said, I thought I should check on one thing: In your original > post, you mentioned that these techniques came from the linux drive for > these cards. In the process of writing this patch, did you copy any > section of code from the Linux driver? If possible, it would be best to > avoid any GPL entanglements. I used the microcode from Intel's proprietary Linux driver, which is definetely not GPL'ed. I'm not nearly a copyright expert, but it seems to me that Intel put a BSD-like copyrihght on mentioned sources. Intel's copyright is included in rcvbundle.h, so I hope some of BSD "legals" can check on that, and if in any doubt the simplest thing to do would be asking Intel for their position before including the code in a official distributon. Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 16:25: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 5E93337B401; Wed, 24 Oct 2001 16:25:01 -0700 (PDT) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id SAA97812; Wed, 24 Oct 2001 18:24:54 -0500 (CDT) (envelope-from cdillon@wolves.k12.mo.us) Date: Wed, 24 Oct 2001 18:24:54 -0500 (CDT) From: Chris Dillon To: Marko Zec Cc: , Subject: Re: fxp patch - bundling receive interrupts In-Reply-To: <3BD72A77.712CF51C@tel.fer.hr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 24 Oct 2001, Marko Zec wrote: > The microcode should work on many revisions - if not all - of > Intel 8255* chipset, but the BSD driver is currently tested only > on 82558-B0, so I would really appreciate any feedback on driver > functionality/stability on other chipset revisions. Chalk up another 82558B that it works on. I started using it shortly after you mentioned this patch a couple of days ago and haven't experienced any problems. While doing a large file transfer between two FreeBSD boxes, performance definately did not suffer. I got 11MB/sec over FTP. When communicating with a Windows NT server over SMB, though, performance was bad (max 1.2MB/sec). I haven't yet checked to see if this is because of the interrupt coalescing or if it is just because Windows sucks. I did notice a 33% decrease in interrupts (if about 900 packets came in, about 600 interrupts were generated), so it definately worked. If I get real brave I might try it on my router which has mostly 82558B's but also an 82559 or two. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 18:35:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id D70FC37B405 for ; Wed, 24 Oct 2001 18:35:50 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f9P1YJt18085; Wed, 24 Oct 2001 20:34:19 -0500 (CDT) (envelope-from jlemon) Date: Wed, 24 Oct 2001 20:34:19 -0500 (CDT) From: Jonathan Lemon Message-Id: <200110250134.f9P1YJt18085@prism.flugsvamp.com> To: rizzo@aciri.org, net@freebsd.org Subject: Re: struct ifnet changes X-Newsgroups: local.mail.freebsd-stable In-Reply-To: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article you write: >Hi, >in order to add polling support to network interfaces >i need to add one more flag to network interface descriptors, >but the relevant field in struct ifnet (if_flags) is only 16 bit >wide and already fully used. > >I would like to extend it to 32 bit, which is not a problem in >CURRENT, but doing this in STABLE will break binary compatibility >with older drivers (presumably up to FreeBSD 4.2, as between 4.1 >and 4.2 there were other changes that probably prevent the use of >old binary drivers). > >Are there strong objections to this change ? > >I can avoid breaking binary compatibility by using some other unused >field (e.g. if_ipending, which is currently unused), but i'd rather >not have to, because we risk to carry this dirty hack forever. > >If I am allowed to make changes to the structure, I would do the following: > > + change if_flags to an u_int32_t to accommodate more flags, > and move it to the beginning of the structure -- this is > accessed very very frequently, and this change makes the > kernel 200 bytes smaller, and possibly a bit faster; > > + remove if_ipending -- noone is using it; > > + change if_index to u_int32_t (mostly to preserve alignment > of the remaining fields); > > + maybe change if_unit and if_timer to 32 bit, for better alignment > and code efficiency > > + redefine some of the (currently unused) fields for polling > support. This does not compromise binary compatibility > because the field size and position will remain the same, > only the type will change. > >Comments ? Hmm, I think you would be better off sending this to -net, not -stable. :-) A few things: - I've been kicking around the idea of splitting if_flags into two fields, to better handle locking issues. Some of the fields are accessed by the driver frequently (OACTIVE), while others are more static. However, I haven't figured out whether this is needed or not. - I also have a few changes for polling support of my own, I use the poll_xmit/poll_recv slots in the dispatch table - You mention moving if_flags to the first element, is there any code that assumes that if_softc is the first element in the ifnet? Putting at the start of the second cache line might be another option. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 24 19:14:11 2001 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 AF8D637B403 for ; Wed, 24 Oct 2001 19:14:09 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9P2E4m50377; Wed, 24 Oct 2001 22:14:04 -0400 (EDT) (envelope-from wollman) Date: Wed, 24 Oct 2001 22:14:04 -0400 (EDT) From: Garrett Wollman Message-Id: <200110250214.f9P2E4m50377@khavrinen.lcs.mit.edu> To: Jonathan Lemon Cc: rizzo@aciri.org, net@FreeBSD.ORG Subject: Re: struct ifnet changes In-Reply-To: <200110250134.f9P1YJt18085@prism.flugsvamp.com> References: <200110250134.f9P1YJt18085@prism.flugsvamp.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > - You mention moving if_flags to the first element, is there any code > that assumes that if_softc is the first element in the ifnet? Putting > at the start of the second cache line might be another option. There shouldn't be; if_softc is a recent invention, and should by rights be unnecessary. Put more precisely: assert(ifp->if_softc == ifp); The people who wanted if_softc are the same ones who were arguing against this softc layout restriction, so it's quite unlikely that there would be anyone depending on &ifp->if_softc == (void **)ifp. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 25 2: 4:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by hub.freebsd.org (Postfix) with ESMTP id 0E0B237B405 for ; Thu, 25 Oct 2001 02:04:32 -0700 (PDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Oct 2001 11:04:34 +0200 Message-ID: <31A473DBB655D21180850008C71E251A031AB02A@mail.kebne.se> From: Gunnar Olsson To: "Freebsd Net (E-mail)" Subject: netperf?! Date: Thu, 25 Oct 2001 11:04:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I am confused... Is it not possible to decide message size to netperf? Now a default value of 16384 bytes is configured. Can I change that? Best regards Gunnar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Gunnar Olsson Phone: +46 8 5062 5762 Xelerated Packet Devices AB Fax: +46 8 5455 3211 Regeringsgatan 67 Mobile: +46 73 3279765 SE-10386 Stockholm Web: http://www.xelerated.com Email: mailto:gunnar.olsson@xelerated.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 25 2: 9:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50]) by hub.freebsd.org (Postfix) with ESMTP id 1F67737B406 for ; Thu, 25 Oct 2001 02:09:28 -0700 (PDT) Received: from dialup-209.247.142.37.dial1.sanjose1.level3.net ([209.247.142.37] helo=blossom.cjclark.org) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15wgVy-0002c6-00; Thu, 25 Oct 2001 02:09:27 -0700 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id f9P991Q11417; Thu, 25 Oct 2001 02:09:01 -0700 (PDT) (envelope-from cjc) Date: Thu, 25 Oct 2001 02:09:01 -0700 From: "Crist J. Clark" To: Landon Stewart Cc: freebsd-net@FreeBSD.ORG Subject: Re: ADSL with two interfaces in one machine using "dhclient" Message-ID: <20011025020901.E8495@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <5.1.0.14.0.20011024084343.031b7770@pop.uniserve.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20011024084343.031b7770@pop.uniserve.com>; from landons@uniserve.com on Wed, Oct 24, 2001 at 08:54:41AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Oct 24, 2001 at 08:54:41AM -0700, Landon Stewart wrote: [snip] > Can I have two interfaces with the same gateway without getting MAC address > notices? The easiest and best thing to do is unplug one of the NICs from the hub, since having two NICs from one machine on a collision domain is generally a Bad Thing. However, there are some reasons why some people may still need to do this(most don't). Use the net.link.ether.inet.log_arp_wrong_iface sysctl(8) knob. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 25 3:43:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail17.bigmailbox.com (mail17.bigmailbox.com [209.132.220.48]) by hub.freebsd.org (Postfix) with ESMTP id A534537B405; Thu, 25 Oct 2001 03:43:07 -0700 (PDT) Received: (from www@localhost) by mail17.bigmailbox.com (8.10.0/8.10.0) id f9PAh7m02791; Thu, 25 Oct 2001 03:43:07 -0700 Date: Thu, 25 Oct 2001 03:43:07 -0700 Message-Id: <200110251043.f9PAh7m02791@mail17.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [200.229.133.210] From: "irado@nettaxi.com" To: freebsd-hackers@freebsd.org, leal@myway.com.br, freebsd-net@freebsd.org Subject: RE: [Fwd: colisions!] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org somewhat strange your cross.. I am accoustumed to use the 568A/568B normalized cross, which is: 1-white-green 2-green 3-white-orange 4-blue 5-white-blue 6-orange 7-white-maroon 8-maroon the other side: 1-white-orange 2-orange 3-white-green 4-blue 5-white-blue 6-green 7-white-maroon 8-maroon as you can see, the green/orange pairs are the switched ones. Also, you *must* use the corresponding white of each pair - no mix/max whites please (Alcatel cables have no coloured strips), otherwise the crosstalking can produce a lot of collisions.. change the cable accordingly and try again. >Date: Wed, 24 Oct 2001 15:15:12 -0200 > Marcelo Leal freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG [Fwd: colisions!] > >i have the follow problem: >i use etinc in one FreeBSD box (4.2). it works fine. >this freebsd make bridge (one interface in switch), and another cross >over to router. in the conection to router, there are one colision led, >that are almost always up! i did put one rule for bridge only ip in rl0 >(switch interface). why there are colisions betwen etinc and router??? >the etinc interface are 10Mbps (half-duplex) and router too. >the cross over is: >etinc >1 2 >orange/white >3 6 >blue/white > >router >1 2 >blue/white >3 6 >orange/white > >thanks > >___________ The ISP-WIRELESS Discussion List ___________ >To Join: mailto:join-isp-wireless@isp-wireless.com >To Remove: mailto:remove-isp-wireless@isp-wireless.com >Archives: http://isp-lists.isp-planet.com/isp-wireless/archives/ > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message saudações, irado furioso com tudo GNU/Linux user CASSADO deus é construído à imagem e semelhança do homem. Principalmente em seus defeitos. por favor, clique aqui: http://www.thehungersite.com e aqui também: http://cf6.uol.com.br/umminuto/ ------------------------------------------------------------ Nettaxi would like to ask for your help in donations to the RED CROSS today! http://www.nyredcross.org/donate/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 25 4: 3:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.nsu.ru (b.ns.ssc.nsu.ru [193.124.215.221]) by hub.freebsd.org (Postfix) with ESMTP id 7CA0837B401; Thu, 25 Oct 2001 04:03:16 -0700 (PDT) Received: from uni.land3.nsu.ru ([193.124.213.230] helo=land3.nsu.ru) by mail.nsu.ru with esmtp (Exim 3.20 #1) id 15wiHK-000837-00; Thu, 25 Oct 2001 18:02:26 +0700 Received: from localhost (lucky@localhost) by land3.nsu.ru (8.11.4/8.11.4) with ESMTP id f9PB24U30580; Thu, 25 Oct 2001 18:02:04 +0700 (NOVST) (envelope-from lucky@land3.nsu.ru) Date: Thu, 25 Oct 2001 18:02:04 +0700 (NOVST) From: Alexey Privalov To: "irado@nettaxi.com" Cc: freebsd-hackers@freebsd.org, leal@myway.com.br, freebsd-net@freebsd.org Subject: RE: [Fwd: colisions!] In-Reply-To: <200110251043.f9PAh7m02791@mail17.bigmailbox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org to irado: read some information at www.ots.utexas.edu/ethernet to leal: try to test with different NIC`s and cabels. On Thu, 25 Oct 2001, irado@nettaxi.com wrote: > > somewhat strange your cross.. I am accoustumed to use the 568A/568B normalized cross, which is: > > 1-white-green > 2-green > 3-white-orange > 4-blue > 5-white-blue > 6-orange > 7-white-maroon > 8-maroon > > the other side: > 1-white-orange > 2-orange > 3-white-green > 4-blue > 5-white-blue > 6-green > 7-white-maroon > 8-maroon > > as you can see, the green/orange pairs are the switched ones. Also, you *must* use the corresponding white of each pair - no mix/max whites please (Alcatel cables have no coloured strips), otherwise the crosstalking can produce a lot of collisions.. > > change the cable accordingly and try again. > > >Date: Wed, 24 Oct 2001 15:15:12 -0200 > > Marcelo Leal freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG [Fwd: colisions!] > > > >i have the follow problem: > >i use etinc in one FreeBSD box (4.2). it works fine. > >this freebsd make bridge (one interface in switch), and another cross > >over to router. in the conection to router, there are one colision led, > >that are almost always up! i did put one rule for bridge only ip in rl0 > >(switch interface). why there are colisions betwen etinc and router??? > >the etinc interface are 10Mbps (half-duplex) and router too. > >the cross over is: > >etinc > >1 2 > >orange/white > >3 6 > >blue/white > > > >router > >1 2 > >blue/white > >3 6 > >orange/white > > > >thanks > > > >___________ The ISP-WIRELESS Discussion List ___________ > >To Join: mailto:join-isp-wireless@isp-wireless.com > >To Remove: mailto:remove-isp-wireless@isp-wireless.com > >Archives: http://isp-lists.isp-planet.com/isp-wireless/archives/ > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-net" in the body of the message > > > > saudações, > irado furioso com tudo > GNU/Linux user CASSADO > deus é construído à imagem e semelhança do homem. Principalmente em seus defeitos. > > por favor, clique aqui: http://www.thehungersite.com > e aqui também: http://cf6.uol.com.br/umminuto/ > > ------------------------------------------------------------ > Nettaxi would like to ask for your help in donations to the RED CROSS today! > http://www.nyredcross.org/donate/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" 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 Oct 25 11:17:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from hecky.it.northwestern.edu (hecky.acns.nwu.edu [129.105.16.51]) by hub.freebsd.org (Postfix) with ESMTP id D210537B405; Thu, 25 Oct 2001 11:17:03 -0700 (PDT) Received: (from mailnull@localhost) by hecky.it.northwestern.edu (8.8.7/8.8.7) id NAA25891; Thu, 25 Oct 2001 13:17:01 -0500 (CDT) Received: from confusion.net (dhcp089069.res-hall.nwu.edu [199.74.89.69]) by hecky.acns.nwu.edu via smap (V2.0) id xma025660; Thu, 25 Oct 01 13:16:41 -0500 Message-ID: <3BD856FB.2E52F12F@confusion.net> Date: Thu, 25 Oct 2001 13:16:27 -0500 From: Laurence Berland X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Marcelo Leal Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: [Fwd: colisions!] References: <3BD6F720.8DBFA15@myway.com.br> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org You're wired fine. You're seeing collisions because it's half duplex. To avoid collisions you need a full duplex segment, otherwise the router and etinc talking at the same time will lead to a collision. This is normal and is not cause for concern. Marcelo Leal wrote: > > i have the follow problem: > i use etinc in one FreeBSD box (4.2). it works fine. > this freebsd make bridge (one interface in switch), and another cross > over to router. in the conection to router, there are one colision led, > that are almost always up! i did put one rule for bridge only ip in rl0 > (switch interface). why there are colisions betwen etinc and router??? > the etinc interface are 10Mbps (half-duplex) and router too. > the cross over is: > etinc > 1 2 > orange/white > 3 6 > blue/white > > router > 1 2 > blue/white > 3 6 > orange/white > > thanks > > ___________  The ISP-WIRELESS Discussion List  ___________ > To Join: mailto:join-isp-wireless@isp-wireless.com > To Remove: mailto:remove-isp-wireless@isp-wireless.com > Archives: http://isp-lists.isp-planet.com/isp-wireless/archives/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Laurence Berland Northwestern '04 stuyman@confusion.net http://www.isp.northwestern.edu/~laurence "The world has turned and left me here" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 25 12:13:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from blade.elitsat.net (blade.elitsat.net [209.239.78.129]) by hub.freebsd.org (Postfix) with ESMTP id 91CC137B401 for ; Thu, 25 Oct 2001 12:13:32 -0700 (PDT) Received: from localhost (amour@localhost) by blade.elitsat.net (8.11.6/8.11.3) with ESMTP id f9PJDPS33168 for ; Thu, 25 Oct 2001 22:13:27 +0300 (EEST) (envelope-from amour@blade.elitsat.net) Date: Thu, 25 Oct 2001 22:13:20 +0300 (EEST) From: Alexander To: Subject: PXE-BOOT HOWTO Message-ID: <20011025221133.V33166-100000@blade.elitsat.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Can someone tell me where I can read about PXE BOOTing and diskless setup. Like how can I boot from floppy just like the Novell boot ? thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 25 13:46:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail4.home.nl (mail4.home.nl [213.51.129.228]) by hub.freebsd.org (Postfix) with ESMTP id 58BE437B61D for ; Thu, 25 Oct 2001 13:46:12 -0700 (PDT) Received: from testuser ([213.51.195.75]) by mail4.home.nl (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20011025204623.KORB3410.mail4.home.nl@testuser> for ; Thu, 25 Oct 2001 22:46:23 +0200 Message-ID: <001001c15d96$134ac7b0$0200a8c0@testuser> From: "Marcel Dijk" To: References: <20011025221133.V33166-100000@blade.elitsat.net> Subject: XP pro Date: Thu, 25 Oct 2001 22:46:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello fellow FreeBSD users! Is WinXP compatible with FreeBSD / samba? I mean, with Win2000 pro I always could connect to my FreeBSD shares. But if I try to make a connection from my XP box I get the message: The account is not allowd to connect from this station. How does one solve this? Greets, Marcel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 25 14: 8:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id 551D937B401 for ; Thu, 25 Oct 2001 14:08:32 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 919D74CE63; Thu, 25 Oct 2001 17:08:31 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA03918; Thu, 25 Oct 2001 17:08:30 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA26017; Thu, 25 Oct 2001 14:08:30 -0700 (PDT) Message-Id: <200110252108.OAA26017@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rizzo@aciri.org Subject: Re: performance issues with M_PREPEND on clusters Cc: wollman@khavrinen.lcs.mit.edu, net@freebsd.org References: <20011023110307.A34494@iguana.aciri.org> <200110231917.f9NJH4T32996@khavrinen.lcs.mit.edu> <20011023140318.A35869@iguana.aciri.org> Date: Thu, 25 Oct 2001 14:08:30 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo said: >On Tue, Oct 23, 2001 at 03:17:04PM -0400, Garrett Wollman wrote: >> ... the whole purpose of m_pullup is to >> *guarantee* that the data in question will never be shared. > >Technically, it is correct that m_pullup guarantees that the data >in question will never be shared, but it seems to me more an artifact >of its implementation than a real goal. It was not a design goal (in fact, the 4.4 daemon book actually claims "If the dtom() macro is eventually removed, m_pullup() will no longer be forced to move data from mbuf clusters." However, the "ensure that the data is not shared" side effect is heavily in at least the multicast code; the bridge code seem to also rely on it. I wouldn't be surprised if there were more. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 25 14:10: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id AAFAC37B406 for ; Thu, 25 Oct 2001 14:10:05 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 5A57381D06; Thu, 25 Oct 2001 16:10:00 -0500 (CDT) Date: Thu, 25 Oct 2001 16:10:00 -0500 From: Alfred Perlstein To: Alexander Cc: net@freebsd.org Subject: Re: PXE-BOOT HOWTO Message-ID: <20011025161000.M15052@elvis.mu.org> References: <20011025221133.V33166-100000@blade.elitsat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011025221133.V33166-100000@blade.elitsat.net>; from amour@blade.elitsat.net on Thu, Oct 25, 2001 at 10:13:20PM +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Alexander [011025 14:13] wrote: > Can someone tell me where I can read about PXE BOOTing and diskless setup. > Like how can I boot from floppy just like the Novell boot ? > thanks. http://people.freebsd.org/~alfred/pxe -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 25 16: 2:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f41.law3.hotmail.com [209.185.241.41]) by hub.freebsd.org (Postfix) with ESMTP id 5D5A637B401 for ; Thu, 25 Oct 2001 16:02:33 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 25 Oct 2001 16:02:33 -0700 Received: from 193.217.213.239 by lw3fd.law3.hotmail.msn.com with HTTP; Thu, 25 Oct 2001 23:02:33 GMT X-Originating-IP: [193.217.213.239] From: "Thor Legvold" To: freebsd-net@freebsd.org Subject: Problems with Orinoco WaveLan (long) Date: Thu, 25 Oct 2001 23:02:33 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Oct 2001 23:02:33.0324 (UTC) FILETIME=[21563AC0:01C15DA9] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As far as I'm able to see, the card is identified, configured and seems to exist fine (ifconfig -a shows it as up, reports the details, etc before the card is given any IP or netmask). wicontrol shows the stats, the IBSS name is correct (of the local access point I connect to), everything seems ok. I do the following: # dhclient wi0 and get the following: wi0: watchdog timeout After several repeated messages I get my prompt back, and ifconfig -a tells me that wi0 is: IP 0.0.0.0 mask 0xFF000000 broadcast 255.255.255.255. netstat -rn gives: dest gw flags netif 0 link#5 UC wi0 plus my other routes. The watchdog comments continue popping up on the console, of course. My ISP is currently running the AccessPoint as a NAT/DHCP server on a class A network (10.0.0.0). Luckily I have a laptop, lucky or not it has WinXP on it. I've configured it to use DHCP and put the Orinoco card in it, it works perfectly. I installed 4.0-RELEASE, CVSup'ed to 4.4-STABLE and have built and installed both world and kernel. I intend the machine to be a gateway/firewall (ipfw) and do NAT translation for my local home network, allowing all machines to access the broadband wireless connection. The hardware is a Fujitsu Siemens ScenicPro, Pentium 200MMX, both ISA and PCI slots. The Orinoco is in a PC-Card carrier in PCI slot 4, a Matrox MGA Millenium is in PCI slot 0. A CNet Pro-200 (dc0) is in slot 3. Nothing else is installed in the machine. The entire disk is dedicated to FreeBSD, I boot from a CD-R until the spinning baton, then give a boot message for the hard disk and kernel image (because for some strage reason the hard disk refuses to boot, although every test I've run on it say's it fine and I've tried every jumper setting available. When it's up and running everything works great. This is the same for FBSD, Windows and DOS, so I think it might be a faulty control card on the hard disk itself.). Checking my kernel configuration file and the dmesg, I see that there are no IRQ conflicts - the Orinoco is on IRQ 10, the dc0 on 11, etc. I have only a very few warning messages in my dmesg, relevant lines are as follows: boot ad(0,a)/kernel Warning: loader(8) metadata is missing! #this because I boot from the CD-R of 4.0-RELEASE, I expect. I wonder how I would go about making a boot floppy or CD-R dedicated to the machine's and kernel's configuration that would pass the boot (and root dev) to the hdd...? then I get this very shortly after the CPU type/setup is done: pci0: (vendor=0x11a, dev=0x0005) at 3.0 pci0: (vendor=0x11a, dev=0x0005) at 3.1 I'm guessing it's something built onto the mainboard, like a soundchip or the flashcard reader or something. I got the machine for free from someone who didn't want it after buying a new one. further down we have this: pci_cfgintr: can't route an interrupt to 0:18 INTA pcic0: at device 18.0 on pci0 pcic0: PCI Memory allocated: 0x44000000 pci_cfgintr: can't route an interrupt to 0:18 INTA pcic0: no PCI interrupt routed, trying ISA pcic0: Polling mode pcic0: TI12XX PCI Config Reg: [pwr save][CSC parallel isa irq] pccard0: ... then this: pccard: card inserted, slot 0 wi0: at port 0x240-0x27f irq 10 slot 0 on pccard0 wi0: ethernet address: 00:02:2d:0b:c2:39 I've checked sysctl, it says: hw.pcic.ignore_function_1: 0 and won't let me change it to "YES" or "1" (variable read only - even as root), so I'm not sure how else I would go about trying it (from what I've read on Deja about similar problems). Hoping someone can point me in the right direction (or proper mailing list, in case *-mobile would be more appropriate because of Warners presence...) Regards, Thor _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 25 20: 9:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 2F47737B405 for ; Thu, 25 Oct 2001 20:09:49 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id f9Q39h809125; Thu, 25 Oct 2001 20:09:43 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id f9Q39cQ20772; Thu, 25 Oct 2001 20:09:38 -0700 (PDT) (envelope-from jdp) Date: Thu, 25 Oct 2001 20:09:38 -0700 (PDT) Message-Id: <200110260309.f9Q39cQ20772@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: clefevre@citeweb.net Subject: Re: PXE boot vs. DHCP In-Reply-To: <002601c15cb4$064fb440$aa3c0007@home.conforama.fr> References: <200110240705.f9O75Fo49531@gits.dyndns.org> <200110241513.f9OFDq006831@vashon.polstra.com> <002601c15cb4$064fb440$aa3c0007@home.conforama.fr> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <002601c15cb4$064fb440$aa3c0007@home.conforama.fr>, Cyrille Lefevre wrote: > "John Polstra" wrote: > > > > Also, I don't feel that my patch is a hack. The entire purpose of > > dhclient's PREINIT phase is to put the network interface into an > > enabled state so that IP packets can be sent. If the interface is > > already up, then it is already in that state. By failing to check the > > interface first, the current dhclient-script needlessly destroys its > > configuration and hangs the system. That is a bug, and my patch fixes > > it. > > ok, did you ask the dhcp mailing list about that ? since, as a general rule, > dhclient should be fixed for all platforms and not only for FreeBSD... No, I did not ask the DHCP mailing list about it. You are welcome to do so if you wish. However, please note that (a) pxeboot is FreeBSD-specific, and (b) dhclient-script is OS-specific by design. I have to say, I'm baffled as to why you are looking so hard for ways to obstruct this simple bugfix. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 25 21:52:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from dms-lcc-vck-m1.dms.usace.army.mil (dms-lcc-vck-m1.dms.usace.army.mil [155.76.29.50]) by hub.freebsd.org (Postfix) with ESMTP id 4728537B406 for ; Thu, 25 Oct 2001 21:52:18 -0700 (PDT) Received: by dms-lcc-vck-m1.dms.usace.army.mil with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Oct 2001 23:51:58 -0500 Message-ID: <06F2D681CAF4774DBDD5852190A0CC213EF968@POJMAIL02.poj.usace.army.mil> From: "Mishler, Barry A POJ" To: freebsd-net@FreeBSD.ORG Subject: Timeout on dns resolver functions Date: Thu, 25 Oct 2001 23:22:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15DD5.C23E8920" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15DD5.C23E8920 Content-Type: text/plain; charset="iso-8859-1" I'm sure this has been discussed before but I've been unable to find a proper solution... Is there a nice portable way to establish a timeout on the resolver routines? I let trafshow run for several hours when it caused a flood of 'File Table Full' syslog messages. It turns out that the trafshow code sets an alarm() before it calls gethostbyaddr and then it wraps the whole thing inside a setjmp block. When the reverse lookup takes too long, the gethostbyaddr is terminated ungracefully leaving a file descriptor open. After a while, this file descriptor leakage fills up the table. I've found that trafshow's addrtoname.c was lifted pretty much straight out of the tcpdump collection. The biggest difference is that tcpdump waits 20 seconds whereas trafshow defaults to a 2-second wait in order to keep things moving. So I can only assume that tcpdump would similarly fill up the FD table if given the chance. I don't know if this is relevant, but trafshow never leaked descriptors until I upgraded from some version of 4.0-STABLE to 4.1-RELEASE. I confirmed this on two machines. I never got around to tracking it down until recently. Sorry. So what's a portable program to do? How can this FD leakage be avoided? Thanks in advance, Barry -- Barry Mishler System/Network Manager Japan Engineer District U.S. Army Corps of Engineers ------_=_NextPart_001_01C15DD5.C23E8920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Timeout on dns resolver functions

I'm sure this has been discussed before but I've been = unable to find a proper solution...

Is there a nice portable way to establish a timeout = on the resolver routines?

I let trafshow run for several hours when it caused a = flood of 'File Table Full' syslog messages.  It turns out that the = trafshow code sets an alarm() before it calls gethostbyaddr and then it = wraps the whole thing inside a setjmp block.  When the reverse = lookup takes too long, the gethostbyaddr is terminated ungracefully = leaving a file descriptor open.  After a while, this file = descriptor leakage fills up the table.

I've found that trafshow's addrtoname.c was lifted = pretty much straight out of the tcpdump collection.  The biggest = difference is that tcpdump waits 20 seconds whereas trafshow defaults = to a 2-second wait in order to keep things moving.  So I can only = assume that tcpdump would similarly fill up the FD table if given the = chance.

I don't know if this is relevant, but trafshow never = leaked descriptors until I upgraded from some version of 4.0-STABLE to = 4.1-RELEASE.  I confirmed this on two machines.  I never got = around to tracking it down until recently.  Sorry.

So what's a portable program to do?  How can = this FD leakage be avoided?

Thanks in advance,
Barry

--
Barry Mishler
System/Network Manager
Japan Engineer District
U.S. Army Corps of Engineers

------_=_NextPart_001_01C15DD5.C23E8920-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 0:46:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from pc0.sm.ukrtel.net (pc0.sm.ukrtel.net [195.5.1.116]) by hub.freebsd.org (Postfix) with ESMTP id A66DD37B406 for ; Fri, 26 Oct 2001 00:46:44 -0700 (PDT) Received: from cron.sm.ukrtel.net (cron.sm.ukrtel.net [10.16.250.40]) by pc0.sm.ukrtel.net (8.9.3/8.9.3) with ESMTP id KAA98084 for ; Fri, 26 Oct 2001 10:46:41 +0300 (EEST) (envelope-from mhl@cron.sm.ukrtel.net) Received: (from mhl@localhost) by cron.sm.ukrtel.net (8.11.6/8.11.3) id f9Q7keP03798 for freebsd-net@freebsd.org; Fri, 26 Oct 2001 10:46:40 +0300 (EEST) (envelope-from mhl) Date: Fri, 26 Oct 2001 10:46:40 +0300 From: Yegorov Mikhail To: freebsd-net@freebsd.org Subject: mdp and ng_iface Message-ID: <20011026104640.A3717@cron.sm.ukrtel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Mpd-netgraph remove ngX interface at exit but I need fixed interfaces. Is it possible to create option with which mpd will not send NGM_SHUTDOWN message to ng_iface node. -- Mikhail Yegorov e-mail: mhl@sm.ukrtel.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 1: 0:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp.noos.fr (claudel.noos.net [212.198.2.83]) by hub.freebsd.org (Postfix) with ESMTP id 0143537B40A for ; Fri, 26 Oct 2001 01:00:38 -0700 (PDT) Received: (qmail 7600809 invoked by uid 0); 26 Oct 2001 07:35:54 -0000 Received: from unknown (HELO gits.dyndns.org) ([212.198.229.145]) (envelope-sender ) by 212.198.2.83 (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Oct 2001 07:35:54 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.6/8.11.6) id f9Q7Zke65186; Fri, 26 Oct 2001 09:35:46 +0200 (CEST) (envelope-from root) Message-Id: <200110260735.f9Q7Zke65186@gits.dyndns.org> Subject: Re: PXE boot vs. DHCP In-Reply-To: <200110260309.f9Q39cQ20772@vashon.polstra.com> To: John Polstra Date: Fri, 26 Oct 2001 09:35:46 +0200 (CEST) Cc: net@freebsd.org Reply-To: clefevre@citeweb.net From: Cyrille Lefevre Organization: ACME X-Face: X-Mailer: ELM [version 2.4ME+ PL94c (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Polstra wrote: > In article <002601c15cb4$064fb440$aa3c0007@home.conforama.fr>, > Cyrille Lefevre wrote: > > "John Polstra" wrote: > > > > > > Also, I don't feel that my patch is a hack. The entire purpose of > > > dhclient's PREINIT phase is to put the network interface into an > > > enabled state so that IP packets can be sent. If the interface is > > > already up, then it is already in that state. By failing to check the > > > interface first, the current dhclient-script needlessly destroys its > > > configuration and hangs the system. That is a bug, and my patch fixes > > > it. > > > > ok, did you ask the dhcp mailing list about that ? since, as a general rule, > > dhclient should be fixed for all platforms and not only for FreeBSD... > > No, I did not ask the DHCP mailing list about it. You are welcome > to do so if you wish. However, please note that (a) pxeboot is > FreeBSD-specific, and (b) dhclient-script is OS-specific by design. > > I have to say, I'm baffled as to why you are looking so hard for ways > to obstruct this simple bugfix. because I'm not sure this fix didn't cause any problem outside PXE. imagine you have a "normal" machine on which dhclient die for any reason. what's happen when you restart dhclient using your fix ? is everything always work all right ? did you try this case ? Cyrille. -- Cyrille Lefevre mailto:clefevre@citeweb.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 2:53:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 911B737B405 for ; Fri, 26 Oct 2001 02:53:38 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 26 Oct 2001 10:53:37 +0100 (BST) Date: Fri, 26 Oct 2001 10:53:34 +0100 From: David Malone To: Alfred Perlstein Cc: Luigi Rizzo , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011026105334.A14635@walton.maths.tcd.ie> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011023140034.M15052@elvis.mu.org>; from bright@mu.org on Tue, Oct 23, 2001 at 02:00:34PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Oct 23, 2001 at 02:00:34PM -0500, Alfred Perlstein wrote: > Yes, you're right, I was mistaken in my paranioa, however you're > missing the fact that one may want to allocate an EXT buf and still > have it writeable. This is the function of M_RDONLY and M_WRITABLE framework which we put in place in -current about a year ago. I think we set things up so that sendfilebufs are not writable and so that custom external storage for jumbo ethernet frames are writeable. The changes were a bit big to port back to -stable. They involved moving external storage reference counts into the generic mbuf system. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 3: 6:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id ED87637B405 for ; Fri, 26 Oct 2001 03:06:39 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 26 Oct 2001 11:06:39 +0100 (BST) Date: Fri, 26 Oct 2001 11:06:35 +0100 From: David Malone To: Bosko Milekic Cc: Luigi Rizzo , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011026110635.B14635@walton.maths.tcd.ie> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> <20011023185759.A328@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011023185759.A328@technokratis.com>; from bmilekic@technokratis.com on Tue, Oct 23, 2001 at 06:57:59PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Oct 23, 2001 at 06:57:59PM -0400, Bosko Milekic wrote: > I believe that the correct way to deal with this issue is to have > M_LEADINGSPACE and M_TRAILINGSPACE simply return the number of bytes > that make up the leading space or trailing space, respectively, > regardless of whether the underlying cluster/mbuf/ext_buf is marked > writable or not. The only problem I can see with this tack is that we might end up with M_LEADINGSPACE macro which does something different to the same macro in {Net,Open}BSD. I guess we should check what their macros do at the moment. When I looked at this question last year I think I found that there were few enough places in the kernel which used M_LEADINGSPACE, so it should be fairly easy to check them. However, I think several of the uses were in KAME code. (I did have some notes on this work, but unfortunately the hard drive with them on whet south recently...) David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 4:48:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from neogw.osaka.iij.ad.jp (neogw.osaka.iij.ad.jp [202.232.14.130]) by hub.freebsd.org (Postfix) with ESMTP id 2828B37B405 for ; Fri, 26 Oct 2001 04:48:16 -0700 (PDT) Received: by neogw.osaka.iij.ad.jp; id UAA18160; Fri, 26 Oct 2001 20:48:10 +0900 (JST) Received: from keiichi01.osaka.iij.ad.jp(192.168.65.66) by neogw.osaka.iij.ad.jp via smap (V4.2) id xma018150; Fri, 26 Oct 01 20:47:45 +0900 Received: from keiichi01.osaka.iij.ad.jp (localhost.osaka.iij.ad.jp [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.6/8.11.6) with ESMTP id f9QBlR427830; Fri, 26 Oct 2001 20:47:32 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Fri, 26 Oct 2001 20:47:27 +0900 Message-ID: <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= To: Bosko Milekic , David Malone , Luigi Rizzo , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters In-Reply-To: <20011026110635.B14635@walton.maths.tcd.ie> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> <20011023185759.A328@technokratis.com> <20011026110635.B14635@walton.maths.tcd.ie> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I am one of the KAME members. > The only problem I can see with this tack is that we might end up > with M_LEADINGSPACE macro which does something different to the > same macro in {Net,Open}BSD. I guess we should check what their > macros do at the moment. Right. And we will have a problem if someone changes the semantics of M_LEADINGSPACE. The M_LEADINGSPACE macro of Net/OpenBSD does the same as the current FreeBSD does, that is, returns 0 if M_EXT is set. > When I looked at this question last year I think I found that there > were few enough places in the kernel which used M_LEADINGSPACE, so > it should be fairly easy to check them. However, I think several > of the uses were in KAME code. The patch posted first by Luigi is safe because the patch doesn't change any semantics of M_LEADINGSPACE. I think it (and the patch) reasonbale that M_LEADINGSPACE returns 0 when the mbuf (cluster) is not writable and the real space when the mbuf (cluster) is writable. But, I disagree the later proposal from Bosko that changes the meaning of M_LEADINGSPACE. This leads more ifdefs in the shared code (ex. KAME, maybe other cross-platform projects) and the code complexity. --- Keiichi SHIMA IIJ Research Laboratory KAME Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 5:10:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id A48B737B405 for ; Fri, 26 Oct 2001 05:10:35 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 26 Oct 2001 13:10:34 +0100 (BST) To: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= Cc: Bosko Milekic , Luigi Rizzo , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters In-reply-to: Your message of "Fri, 26 Oct 2001 20:47:27 +0900." <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> X-Request-Do: Date: Fri, 26 Oct 2001 13:10:34 +0100 From: David Malone Message-ID: <200110261310.aa66738@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > When I looked at this question last year I think I found that there > > were few enough places in the kernel which used M_LEADINGSPACE, so > > it should be fairly easy to check them. However, I think several > > of the uses were in KAME code. > The patch posted first by Luigi is safe because the patch doesn't > change any semantics of M_LEADINGSPACE. I think it (and the patch) > reasonbale that M_LEADINGSPACE returns 0 when the mbuf (cluster) is > not writable and the real space when the mbuf (cluster) is writable. So the M_LEADINGSPACE macro should probaly read: #define M_LEADINGSPACE(m) \ (!M_WRITABLE(m) ? 0 : \ (m)->m_flags & M_EXT ? (m)->m_data - (m)->m_ext.ext_buf : \ (m)->m_flags & M_PKTHDR ? (m)->m_data - (m)->m_pktdat : \ (m)->m_data - (m)->m_dat) and the comments for M_LEADINGSPACE and M_TRAILINGSPACE should note the inconsistancy where M_LEADINGSPACE returns the number of writable bytes and M_TRAILINGSPACE returns the number bytes, but doesn't indicate if they are writable or not. Maybe we should also provide M_{LEAD,TRAIL}INGSPACE_{R,W} macros with consistant behaviour. The _R macros would be cheaper 'cos they wouldn't have to check writability. These could be used in the case where you already know the storage is writable. (Here _R would mean "regardless" 'cos it's hard to imagine a situation where you want to know how many readable bytes are outside the valid data region in an mbuf ;-) Bosko - what do you think of modifying M_LEADINGSPACE as shown above and then providing these new macros? It would mean that we can leave shared code alone, but where we want to optimise M_LEADINGSPACE and M_TRAILINGSPACE we have the macros to do so. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 5:28:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 81E1D37B405 for ; Fri, 26 Oct 2001 05:28:30 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 26 Oct 2001 13:28:29 +0100 (BST) To: David Malone Cc: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= , Bosko Milekic , Luigi Rizzo , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters In-Reply-To: Your message of "Fri, 26 Oct 2001 13:10:34 BST." <200110261310.aa66738@salmon.maths.tcd.ie> Date: Fri, 26 Oct 2001 13:28:29 +0100 From: Ian Dowse Message-ID: <200110261328.aa71753@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <200110261310.aa66738@salmon.maths.tcd.ie>, David Malone writes: > >So the M_LEADINGSPACE macro should probaly read: > >#define M_LEADINGSPACE(m) > \ > (!M_WRITABLE(m) ? 0 : \ > (m)->m_flags & M_EXT ? (m)->m_data - (m)->m_ext.ext_buf : \ > (m)->m_flags & M_PKTHDR ? (m)->m_data - (m)->m_pktdat : \ > (m)->m_data - (m)->m_dat) Yes, I think this is cleaner than the version that was just committed to -stable, and it could have been committed to -current and MFC'd in the normal way without changes. I really doubt that it is worth splitting up M_WRITABLE just to marginally optimise M_LEADINGSPACE. >Maybe we should also provide M_{LEAD,TRAIL}INGSPACE_{R,W} macros >with consistant behaviour. The _R macros would be cheaper 'cos >they wouldn't have to check writability. These could be used in >the case where you already know the storage is writable. This optimisation seems the only reason why it might make sense to change the current semantics of M_LEADINGSPACE to ignore writeability, and I'm not sure that even this is worthwhile. While the word 'space' does not necessarily imply 'writable space', why would anything ask for the leading or trailing space if writing to it was not being considered? Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 7:53:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 9900537B403 for ; Fri, 26 Oct 2001 07:53:37 -0700 (PDT) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id f9QEo1Z64860; Fri, 26 Oct 2001 07:50:01 -0700 (PDT) (envelope-from rizzo) Date: Fri, 26 Oct 2001 07:50:01 -0700 From: Luigi Rizzo To: Keiichi SHIMA / ????????? Cc: Bosko Milekic , David Malone , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011026075001.C64631@iguana.aciri.org> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> <20011023185759.A328@technokratis.com> <20011026110635.B14635@walton.maths.tcd.ie> <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Keiichi, On Fri, Oct 26, 2001 at 08:47:27PM +0900, Keiichi SHIMA / ????????? wrote: > Hi, I am one of the KAME members. so i have a question for you -- the next step on this kind of optimizations is to avoid that m_pullup() allocates an mbuf when data is already contiguous and in a writable (non-shared) cluster. Garret was suggesting a new interface for this, at the beginning i thought the same, but now i am a bit uncertain on whether it is really necessary to use a different interface, or whether this would cause compatibility problems with other BSD's. Maybe you have already thought about this issue while developing the KAME code, and can say something on the topic ? cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 8:18: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 8449437B406 for ; Fri, 26 Oct 2001 08:17:57 -0700 (PDT) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id f9QFESr65017; Fri, 26 Oct 2001 08:14:28 -0700 (PDT) (envelope-from rizzo) Date: Fri, 26 Oct 2001 08:14:28 -0700 From: Luigi Rizzo To: Ian Dowse Cc: David Malone , Keiichi SHIMA / ????????? , Bosko Milekic , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011026081428.D64631@iguana.aciri.org> References: <200110261310.aa66738@salmon.maths.tcd.ie> <200110261328.aa71753@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110261328.aa71753@salmon.maths.tcd.ie> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Oct 26, 2001 at 01:28:29PM +0100, Ian Dowse wrote: > In message <200110261310.aa66738@salmon.maths.tcd.ie>, David Malone writes: > > > >So the M_LEADINGSPACE macro should probaly read: > > > >#define M_LEADINGSPACE(m) > > \ > > (!M_WRITABLE(m) ? 0 : \ > > (m)->m_flags & M_EXT ? (m)->m_data - (m)->m_ext.ext_buf : \ > > (m)->m_flags & M_PKTHDR ? (m)->m_data - (m)->m_pktdat : \ > > (m)->m_data - (m)->m_dat) > > Yes, I think this is cleaner than the version that was just committed > to -stable, and it could have been committed to -current and MFC'd > in the normal way without changes. I really doubt that it is worth > splitting up M_WRITABLE just to marginally optimise M_LEADINGSPACE. gcc -O seems to agree with you :) This form produces a kernel which is 32 bytes shorter than the form that I committed (out of 1Meg, so not really a big deal). cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 9:17:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from technokratis.com (modemcable093.62-201-24.mtl.mc.videotron.ca [24.201.62.93]) by hub.freebsd.org (Postfix) with ESMTP id E36A437B403 for ; Fri, 26 Oct 2001 09:17:42 -0700 (PDT) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id f9QGHSZ21540; Fri, 26 Oct 2001 12:17:28 -0400 (EDT) (envelope-from bmilekic) Date: Fri, 26 Oct 2001 12:17:24 -0400 From: Bosko Milekic To: "Keiichi SHIMA / ?$BEg7D0l?(B" Cc: David Malone , Luigi Rizzo , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011026121724.A21512@technokratis.com> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> <20011023185759.A328@technokratis.com> <20011026110635.B14635@walton.maths.tcd.ie> <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp>; from keiichi@iij.ad.jp on Fri, Oct 26, 2001 at 08:47:27PM +0900 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Oct 26, 2001 at 08:47:27PM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > Right. And we will have a problem if someone changes the semantics of > M_LEADINGSPACE. The M_LEADINGSPACE macro of Net/OpenBSD does the same > as the current FreeBSD does, that is, returns 0 if M_EXT is set. > > > When I looked at this question last year I think I found that there > > were few enough places in the kernel which used M_LEADINGSPACE, so > > it should be fairly easy to check them. However, I think several > > of the uses were in KAME code. > > The patch posted first by Luigi is safe because the patch doesn't > change any semantics of M_LEADINGSPACE. I think it (and the patch) > reasonbale that M_LEADINGSPACE returns 0 when the mbuf (cluster) is > not writable and the real space when the mbuf (cluster) is writable. > > But, I disagree the later proposal from Bosko that changes the meaning > of M_LEADINGSPACE. This leads more ifdefs in the shared code > (ex. KAME, maybe other cross-platform projects) and the code > complexity. Just because M_LEADINGSPACE may be broken in the other systems does not mean that it should be broken in our system as well. I am against sacrificying good code in order to deal with the left-over stupidities (pardon the seemingly harsh vocabulary) in the other systems, when it comes to porting. You should understand that M_LEADINGSPACE was meant to return the number of leading bytes in the underlying data buffer and that it was only broken when someone decided to half-implement ext bufs. This brokeness happened to live on in present-day systems and unbreaking it should not be put on hold for the sake of pseudo-compatibility, IMHO. > --- > Keiichi SHIMA > IIJ Research Laboratory > KAME Project > -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 9:19: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from technokratis.com (modemcable093.62-201-24.mtl.mc.videotron.ca [24.201.62.93]) by hub.freebsd.org (Postfix) with ESMTP id 10F0437B405 for ; Fri, 26 Oct 2001 09:18:58 -0700 (PDT) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id f9QGJDT21550; Fri, 26 Oct 2001 12:19:13 -0400 (EDT) (envelope-from bmilekic) Date: Fri, 26 Oct 2001 12:19:13 -0400 From: Bosko Milekic To: David Malone Cc: "Keiichi SHIMA / ?$BEg7D0l?(B" , Luigi Rizzo , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011026121913.B21512@technokratis.com> References: <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> <200110261310.aa66738@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110261310.aa66738@salmon.maths.tcd.ie>; from dwmalone@maths.tcd.ie on Fri, Oct 26, 2001 at 01:10:34PM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Oct 26, 2001 at 01:10:34PM +0100, David Malone wrote: > So the M_LEADINGSPACE macro should probaly read: > > #define M_LEADINGSPACE(m) \ > (!M_WRITABLE(m) ? 0 : \ > (m)->m_flags & M_EXT ? (m)->m_data - (m)->m_ext.ext_buf : \ > (m)->m_flags & M_PKTHDR ? (m)->m_data - (m)->m_pktdat : \ > (m)->m_data - (m)->m_dat) > > and the comments for M_LEADINGSPACE and M_TRAILINGSPACE should note > the inconsistancy where M_LEADINGSPACE returns the number of writable > bytes and M_TRAILINGSPACE returns the number bytes, but doesn't indicate > if they are writable or not. > > Maybe we should also provide M_{LEAD,TRAIL}INGSPACE_{R,W} macros > with consistant behaviour. The _R macros would be cheaper 'cos > they wouldn't have to check writability. These could be used in > the case where you already know the storage is writable. > > (Here _R would mean "regardless" 'cos it's hard to imagine a > situation where you want to know how many readable bytes are outside > the valid data region in an mbuf ;-) > > Bosko - what do you think of modifying M_LEADINGSPACE as shown > above and then providing these new macros? It would mean that we > can leave shared code alone, but where we want to optimise > M_LEADINGSPACE and M_TRAILINGSPACE we have the macros to do so. I already stated what I thought about it: it's wrong for reasons mentionned in previous Emails. It means that we will be adding support for a broken macro, not to mention enlarging the macro, which is bad especially for code that is actually using it properly. > David. -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 9:32:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 1754C37B401 for ; Fri, 26 Oct 2001 09:32:09 -0700 (PDT) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id f9QGSeW67054; Fri, 26 Oct 2001 09:28:40 -0700 (PDT) (envelope-from rizzo) Date: Fri, 26 Oct 2001 09:28:40 -0700 From: Luigi Rizzo To: Bosko Milekic Cc: "Keiichi SHIMA / ?$BEg7D0l?(B" , David Malone , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011026092840.F64631@iguana.aciri.org> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> <20011023185759.A328@technokratis.com> <20011026110635.B14635@walton.maths.tcd.ie> <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> <20011026121724.A21512@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011026121724.A21512@technokratis.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bosko, Keiichi has a valid point. The semantics of an interface are described by the documentation associated with it, not by its name or the Oxford Dictionary. As much as it might be misleading that M_LEADINGSPACE checks for writability, it has probably been like this for a long time, we have plenty of code that depends on this, and people looking for documentation will likely see this behaviour documented. Changing it might introduce insidious bugs in the code -- because in reality, clusters are almost never shared except for those on the TCP send queue and for multicast packets (but who uses multicast, anyways), so there is a chance that we will have buggy code that goes unnoticed for a long time. cheers luigi On Fri, Oct 26, 2001 at 12:17:24PM -0400, Bosko Milekic wrote: > On Fri, Oct 26, 2001 at 08:47:27PM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > > Right. And we will have a problem if someone changes the semantics of > > M_LEADINGSPACE. The M_LEADINGSPACE macro of Net/OpenBSD does the same ... > > But, I disagree the later proposal from Bosko that changes the meaning > > of M_LEADINGSPACE. This leads more ifdefs in the shared code > > (ex. KAME, maybe other cross-platform projects) and the code > > complexity. > > Just because M_LEADINGSPACE may be broken in the other systems does > not mean that it should be broken in our system as well. I am against > sacrificying good code in order to deal with the left-over stupidities > (pardon the seemingly harsh vocabulary) in the other systems, when it > comes to porting. > You should understand that M_LEADINGSPACE was meant to return the > number of leading bytes in the underlying data buffer and that it was > only broken when someone decided to half-implement ext bufs. This > brokeness happened to live on in present-day systems and unbreaking it > should not be put on hold for the sake of pseudo-compatibility, IMHO. > > > --- > > Keiichi SHIMA > > IIJ Research Laboratory > > KAME Project > > > > -- > Bosko Milekic > bmilekic@technokratis.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 Fri Oct 26 10:38:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from technokratis.com (modemcable093.62-201-24.mtl.mc.videotron.ca [24.201.62.93]) by hub.freebsd.org (Postfix) with ESMTP id F097537B403 for ; Fri, 26 Oct 2001 10:38:11 -0700 (PDT) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id f9QHcRq22167; Fri, 26 Oct 2001 13:38:27 -0400 (EDT) (envelope-from bmilekic) Date: Fri, 26 Oct 2001 13:38:27 -0400 From: Bosko Milekic To: Luigi Rizzo Cc: "Keiichi SHIMA / ?$BEg7D0l?(B" , David Malone , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011026133827.A22096@technokratis.com> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> <20011023185759.A328@technokratis.com> <20011026110635.B14635@walton.maths.tcd.ie> <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> <20011026121724.A21512@technokratis.com> <20011026092840.F64631@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011026092840.F64631@iguana.aciri.org>; from rizzo@aciri.org on Fri, Oct 26, 2001 at 09:28:40AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Oct 26, 2001 at 09:28:40AM -0700, Luigi Rizzo wrote: > Bosko, Keiichi has a valid point. The semantics of an interface > are described by the documentation associated with it, not by its > name or the Oxford Dictionary. And what documentation would that be? Are you referring to the [incomplete] mbuf(9) man page which does not cover M_LEADINGSPACE, or are you referring to "The Implementation of 4.4BSD" (McKusick et al.) which, to my knowledge, doesn't specify anything regarding the writability of the underlying data (I don't know if it specifies anything regarding M_LEADINGSPACE to begin with)? The M_LEADINGSPACE macro always had the line of code that would return the leading space even for ext_bufs commented out, suggesting that the code did exist in the original implementation or was intended to. You yourself noticed that the behavior of M_LEADINGSPACE was incorrect in that it returned 0 for all ext_bufs. Therefore, the issue is not whether or not M_LEADINGSPACE should be changed because, clearly, it should and you yourself are lobbying to change it. The issue is how to change it properly, and I have already presented my opinion on how it should be done. Arguing that OpenBSD and/or NetBSD don't have this behavior is totally ridiculous, seeing as how they don't have the same "writability" macros (the last time I checked) that we do anyway. > As much as it might be misleading that M_LEADINGSPACE checks for > writability, it has probably been like this for a long time, we > have plenty of code that depends on this, and people looking for > documentation will likely see this behaviour documented. Changing No. It has never been like this. > it might introduce insidious bugs in the code -- because in reality, > clusters are almost never shared except for those on the TCP send > queue and for multicast packets (but who uses multicast, anyways), > so there is a chance that we will have buggy code that goes unnoticed > for a long time. > > cheers > luigi > > On Fri, Oct 26, 2001 at 12:17:24PM -0400, Bosko Milekic wrote: > > On Fri, Oct 26, 2001 at 08:47:27PM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > > > Right. And we will have a problem if someone changes the semantics of > > > M_LEADINGSPACE. The M_LEADINGSPACE macro of Net/OpenBSD does the same > ... > > > But, I disagree the later proposal from Bosko that changes the meaning > > > of M_LEADINGSPACE. This leads more ifdefs in the shared code > > > (ex. KAME, maybe other cross-platform projects) and the code > > > complexity. > > > > Just because M_LEADINGSPACE may be broken in the other systems does > > not mean that it should be broken in our system as well. I am against > > sacrificying good code in order to deal with the left-over stupidities > > (pardon the seemingly harsh vocabulary) in the other systems, when it > > comes to porting. > > You should understand that M_LEADINGSPACE was meant to return the > > number of leading bytes in the underlying data buffer and that it was > > only broken when someone decided to half-implement ext bufs. This > > brokeness happened to live on in present-day systems and unbreaking it > > should not be put on hold for the sake of pseudo-compatibility, IMHO. > > > > > --- > > > Keiichi SHIMA > > > IIJ Research Laboratory > > > KAME Project > > > > > > > -- > > Bosko Milekic > > bmilekic@technokratis.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 > -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 10:51:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 72F5237B401 for ; Fri, 26 Oct 2001 10:51:05 -0700 (PDT) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id f9QHlYH67761; Fri, 26 Oct 2001 10:47:34 -0700 (PDT) (envelope-from rizzo) Date: Fri, 26 Oct 2001 10:47:34 -0700 From: Luigi Rizzo To: Bosko Milekic Cc: "Keiichi SHIMA / ?$BEg7D0l?(B" , David Malone , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011026104734.J64631@iguana.aciri.org> References: <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> <20011023185759.A328@technokratis.com> <20011026110635.B14635@walton.maths.tcd.ie> <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> <20011026121724.A21512@technokratis.com> <20011026092840.F64631@iguana.aciri.org> <20011026133827.A22096@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011026133827.A22096@technokratis.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Oct 26, 2001 at 01:38:27PM -0400, Bosko Milekic wrote: > On Fri, Oct 26, 2001 at 09:28:40AM -0700, Luigi Rizzo wrote: > > Bosko, Keiichi has a valid point. The semantics of an interface > > are described by the documentation associated with it, not by its > > name or the Oxford Dictionary. > > And what documentation would that be? Are you referring to the Probably Stevens vol.2 comments that in depth. But mostly, we have legacy code (which is a form of documentation), and the other BSDs. Point is, i could make the one-line commit in mbuf.h and go to bed without being worried of breaking the kernel, whereas the change you have in mind would require you a scrutiny of the whole code to make sure that noone is depending on the writability check. Don't misunderstand me, in principle you are right, but in practice having the same interface with two different semantics in different OS is a recipe for trouble. Microsoft has done something similar with their socket API (at least for multicast, anyways), where primitives have a slightly different semantics and/or parameters in Windows than in Unix, and I, and am sure others, have wasted hours and hours tracking portability bugs of this kind. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- > [incomplete] mbuf(9) man page which does not cover M_LEADINGSPACE, or > are you referring to "The Implementation of 4.4BSD" (McKusick et al.) > which, to my knowledge, doesn't specify anything regarding the > writability of the underlying data (I don't know if it specifies > anything regarding M_LEADINGSPACE to begin with)? > The M_LEADINGSPACE macro always had the line of code that would return > the leading space even for ext_bufs commented out, suggesting that the > code did exist in the original implementation or was intended to. You > yourself noticed that the behavior of M_LEADINGSPACE was incorrect in > that it returned 0 for all ext_bufs. Therefore, the issue is not whether > or not M_LEADINGSPACE should be changed because, clearly, it should and > you yourself are lobbying to change it. The issue is how to change it > properly, and I have already presented my opinion on how it should be > done. Arguing that OpenBSD and/or NetBSD don't have this behavior is > totally ridiculous, seeing as how they don't have the same "writability" > macros (the last time I checked) that we do anyway. > > > As much as it might be misleading that M_LEADINGSPACE checks for > > writability, it has probably been like this for a long time, we > > have plenty of code that depends on this, and people looking for > > documentation will likely see this behaviour documented. Changing > > No. It has never been like this. > > > it might introduce insidious bugs in the code -- because in reality, > > clusters are almost never shared except for those on the TCP send > > queue and for multicast packets (but who uses multicast, anyways), > > so there is a chance that we will have buggy code that goes unnoticed > > for a long time. > > > > cheers > > luigi > > > > On Fri, Oct 26, 2001 at 12:17:24PM -0400, Bosko Milekic wrote: > > > On Fri, Oct 26, 2001 at 08:47:27PM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > > > > Right. And we will have a problem if someone changes the semantics of > > > > M_LEADINGSPACE. The M_LEADINGSPACE macro of Net/OpenBSD does the same > > ... > > > > But, I disagree the later proposal from Bosko that changes the meaning > > > > of M_LEADINGSPACE. This leads more ifdefs in the shared code > > > > (ex. KAME, maybe other cross-platform projects) and the code > > > > complexity. > > > > > > Just because M_LEADINGSPACE may be broken in the other systems does > > > not mean that it should be broken in our system as well. I am against > > > sacrificying good code in order to deal with the left-over stupidities > > > (pardon the seemingly harsh vocabulary) in the other systems, when it > > > comes to porting. > > > You should understand that M_LEADINGSPACE was meant to return the > > > number of leading bytes in the underlying data buffer and that it was > > > only broken when someone decided to half-implement ext bufs. This > > > brokeness happened to live on in present-day systems and unbreaking it > > > should not be put on hold for the sake of pseudo-compatibility, IMHO. > > > > > > > --- > > > > Keiichi SHIMA > > > > IIJ Research Laboratory > > > > KAME Project > > > > > > > > > > -- > > > Bosko Milekic > > > bmilekic@technokratis.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 > > > > -- > Bosko Milekic > bmilekic@technokratis.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 Fri Oct 26 11:32:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from keiichi01.osaka.iij.ad.jp (g034172.ap.plala.or.jp [210.136.34.172]) by hub.freebsd.org (Postfix) with ESMTP id 2B56437B407 for ; Fri, 26 Oct 2001 11:32:35 -0700 (PDT) Received: from keiichi01.osaka.iij.ad.jp (localhost.osaka.iij.ad.jp [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.6/8.11.6) with ESMTP id f9QIVmK01135; Sat, 27 Oct 2001 03:31:58 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Sat, 27 Oct 2001 03:31:48 +0900 Message-ID: <867ktiw8vf.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= To: Bosko Milekic Cc: David Malone , Luigi Rizzo , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters In-Reply-To: <20011026121724.A21512@technokratis.com> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> <20011023185759.A328@technokratis.com> <20011026110635.B14635@walton.maths.tcd.ie> <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> <20011026121724.A21512@technokratis.com> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Bosko. Bosko Milekic wrote: > > Just because M_LEADINGSPACE may be broken in the other systems does > not mean that it should be broken in our system as well. I am against > sacrificying good code in order to deal with the left-over stupidities > (pardon the seemingly harsh vocabulary) in the other systems, when it > comes to porting. I agree with you at the point that the good code should be accepted. With Luigi's patch, we will get more performance than before. It makes us possible to use the leading space (they were unusable before the patch) to prepend some lower-layer packet headers with no changes of existing code. > You should understand that M_LEADINGSPACE was meant to return the > number of leading bytes in the underlying data buffer and that it was > only broken when someone decided to half-implement ext bufs. This > brokeness happened to live on in present-day systems and unbreaking it > should not be put on hold for the sake of pseudo-compatibility, IMHO. M_LEADINGSPACE might be meant to return as you were saying. But because of some reasons (maybe a lack of time to implement the complete code), it behaves as we see now. For a long time, in many systems, M_LEADINGSPACE had been returning writable space only. As a result, some codes (including KAME) rely on the behavior. So, I would suggest that we should not change M_LEADINGSPACE behavior, and write some documents (or comment in the source may be enough) about that. Because one of the reasons of the confusion of M_LEADINGSPACE is there were no documentation about that, we had only the code and the code said that it returns a writable length. (if necessary) we should create a new API to get the real(?) space as David have proposed. Best regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 11:51: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from technokratis.com (modemcable093.62-201-24.mtl.mc.videotron.ca [24.201.62.93]) by hub.freebsd.org (Postfix) with ESMTP id 369C937B412 for ; Fri, 26 Oct 2001 11:50:43 -0700 (PDT) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id f9QIp1p22744; Fri, 26 Oct 2001 14:51:01 -0400 (EDT) (envelope-from bmilekic) Date: Fri, 26 Oct 2001 14:51:01 -0400 From: Bosko Milekic To: "Keiichi SHIMA / ?$BEg7D0l?(B" Cc: David Malone , Luigi Rizzo , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011026145101.A22681@technokratis.com> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> <20011023185759.A328@technokratis.com> <20011026110635.B14635@walton.maths.tcd.ie> <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> <20011026121724.A21512@technokratis.com> <867ktiw8vf.wl@keiichi01.osaka.iij.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <867ktiw8vf.wl@keiichi01.osaka.iij.ad.jp>; from keiichi@iij.ad.jp on Sat, Oct 27, 2001 at 03:31:48AM +0900 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Oct 27, 2001 at 03:31:48AM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > M_LEADINGSPACE might be meant to return as you were saying. But > because of some reasons (maybe a lack of time to implement the > complete code), it behaves as we see now. For a long time, in many > systems, M_LEADINGSPACE had been returning writable space only. As a > result, some codes (including KAME) rely on the behavior. This is not true. M_LEADINGSPACE has not been returning writable space only for a long time; it has been returning space in non-M_EXT mbufs for a long time. So, doing what you want to do *is* changing its behavior, whether you like it or not. I don't know how many times I have to repeat this until someone starts to get it. The issue is not whether or not you're changing the behavior of M_LEADINGSPACE because Luigi's suggestion obviously does. The issue is how to do it properly and the way it's being proposed right now is not the proper way. As it turns out, I'm really not up for extending this debate any longer. I'm not going to kill myself because something like this is being done wrongly, seeing as how I'm the only one arguing this side (according to the response hits, it appears I'm alone with this opinion), although I will maintain that I believe it is wrong, and for good reason, but I may end up eventually beating myself up if I have to repeat the same thing over and over again in the same thread. > So, I would suggest that we should not change M_LEADINGSPACE behavior, > and write some documents (or comment in the source may be enough) > about that. Because one of the reasons of the confusion of > M_LEADINGSPACE is there were no documentation about that, we had only > the code and the code said that it returns a writable length. > > (if necessary) we should create a new API to get the real(?) space as > David have proposed. > > Best regards, > > --- > Keiichi SHIMA > IIJ Research Laboratory > KAME Project -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 12: 9:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from keiichi01.osaka.iij.ad.jp (g034172.ap.plala.or.jp [210.136.34.172]) by hub.freebsd.org (Postfix) with ESMTP id 2803D37B401 for ; Fri, 26 Oct 2001 12:09:52 -0700 (PDT) Received: from keiichi01.osaka.iij.ad.jp (localhost.osaka.iij.ad.jp [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.6/8.11.6) with ESMTP id f9QJ9ZK01332; Sat, 27 Oct 2001 04:09:36 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Sat, 27 Oct 2001 04:09:12 +0900 Message-ID: <86lmhykylj.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= To: Bosko Milekic Cc: David Malone , Luigi Rizzo , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters In-Reply-To: <20011026145101.A22681@technokratis.com> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> <20011023185759.A328@technokratis.com> <20011026110635.B14635@walton.maths.tcd.ie> <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> <20011026121724.A21512@technokratis.com> <867ktiw8vf.wl@keiichi01.osaka.iij.ad.jp> <20011026145101.A22681@technokratis.com> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Bosko, Bosko Milekic wrote: > > > M_LEADINGSPACE might be meant to return as you were saying. But > > because of some reasons (maybe a lack of time to implement the > > complete code), it behaves as we see now. For a long time, in many > > systems, M_LEADINGSPACE had been returning writable space only. As a > > result, some codes (including KAME) rely on the behavior. > > This is not true. M_LEADINGSPACE has not been returning writable space > only for a long time; it has been returning space in non-M_EXT mbufs for > a long time. Ah, I'm sorry, I was wrong. As you said, M_LEADINGSPACE returns 0 even if there are writable space before the data part of the mbuf cluster. Please note that I'm not saying you are wrong (maybe you are correct in theory). But there is a code (not only our code but others maybe..) relys on the current behaviour. Changing M_LEADINGSPACE return the writable space will not introduce any compatibility issues, while changing M_LEA... return the exact (writable or readonly) space will cause compatibility issue. I'm worring about that... > So, doing what you want to do *is* changing its behavior, > whether you like it or not. I don't know how many times I have to repeat > this until someone starts to get it. The issue is not whether or not > you're changing the behavior of M_LEADINGSPACE because Luigi's > suggestion obviously does. The issue is how to do it properly and the > way it's being proposed right now is not the proper way. > As it turns out, I'm really not up for extending this debate any > longer. I'm not going to kill myself because something like this is > being done wrongly, seeing as how I'm the only one arguing this side > (according to the response hits, it appears I'm alone with this > opinion), although I will maintain that I believe it is wrong, and for > good reason, but I may end up eventually beating myself up if I have to > repeat the same thing over and over again in the same thread. --- Keiichi SHIMA IIJ Research Laboratory KAME Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 13:11:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail3.home.nl (mail3.home.nl [213.51.129.227]) by hub.freebsd.org (Postfix) with ESMTP id BA5CB37B401 for ; Fri, 26 Oct 2001 13:11:26 -0700 (PDT) Received: from testuser ([213.51.195.75]) by mail3.home.nl (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20011026201103.SEXJ10918.mail3.home.nl@testuser> for ; Fri, 26 Oct 2001 22:11:03 +0200 Message-ID: <006201c15e5a$ad34f0c0$0200a8c0@testuser> From: "Marcel Dijk" To: Subject: Windows XP pro Date: Fri, 26 Oct 2001 22:13:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello fellow FreeBSD users! Is WinXP compatible with FreeBSD / samba? I mean, with Windows 2000 pro I always could connect to my FreeBSD shares. But if I try to make a connection from my Windows XP box I get the message: The account is not allowd to connect from this station. How does one solve this? In Samba I have turned encrypted passwords ON, because it was compatible with Windows 2000. Has anyone else made successful drive mapping between Windows XP and FreeBSD/Samba?? Greets, Marcel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 13:28:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id 0DE4337B53A for ; Fri, 26 Oct 2001 13:28:49 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id B540B1E011; Fri, 26 Oct 2001 16:28:47 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA23537; Fri, 26 Oct 2001 16:28:38 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id NAA12437; Fri, 26 Oct 2001 13:28:38 -0700 (PDT) Message-Id: <200110262028.NAA12437@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bmilekic@technokratis.com Subject: Re: performance issues with M_PREPEND on clusters Cc: rizzo@aciri.org, keiichi@iij.ad.jp, dwmalone@maths.tcd.ie, bright@mu.org, net@freebsd.org References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> <20011023185759.A328@technokratis.com> <20011026110635.B14635@walton.maths.tcd.ie> <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> <20011026121724.A21512@technokratis.com> <20011026092840.F64631@iguana.aciri.org> <20011026133827.A22096@technokratis.com> Date: Fri, 26 Oct 2001 13:28:37 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > The M_LEADINGSPACE macro always had the line of code that would return >the leading space even for ext_bufs commented out, suggesting that the >code did exist in the original implementation or was intended to. The M_LEADINGSPACE macro was introduced in rev 7.11 of mbuf.h, in August 1988, at the same time as the "new" mbufs, i.e. when external sotrage was introduced, m_act renamed to m_nextpkt, etc. Perhaps the commented code is there to remind what the right thing to do is once you can tell whether or not external storage is writable. I don't think it's reasonable to say that the presence of the comment makes it completely obvious what the intentions of this code were in 1988. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 16:15: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from lurza.secnetix.de (lurza.secnetix.de [212.66.1.130]) by hub.freebsd.org (Postfix) with ESMTP id CEDC437B401 for ; Fri, 26 Oct 2001 16:15:05 -0700 (PDT) Received: (from olli@localhost) by lurza.secnetix.de (8.11.6/8.11.6) id f9QNF4x91658; Sat, 27 Oct 2001 01:15:04 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Date: Sat, 27 Oct 2001 01:15:04 +0200 (CEST) Message-Id: <200110262315.f9QNF4x91658@lurza.secnetix.de> From: Oliver Fromme To: freebsd-net@FreeBSD.ORG Reply-To: freebsd-net@FreeBSD.ORG Subject: Port-based routing? X-Newsgroups: list.freebsd-net User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.4-RELEASE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Is there a way in FreeBSD to route packets based on the destination port number? (I'm asking this on behalf of a friend, not for myself.) This is the setup: There are two uplinks, the first is via a ADSL connection (ppp running on tun0, using PPPoE), the second is via a normal ethernet interface (dc0, which has a slower SDSL router connected). They have different IP addresses, of course. Now he would like to direct web traffic (i.e. port 80) to tun0, and everything else to dc0. Is this possible with FreeBSD at all? Thanks in advance for any hint and advice! Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 26 21:48:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7008D37B401 for ; Fri, 26 Oct 2001 21:48:37 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id f9R4mAB02893; Sat, 27 Oct 2001 00:48:10 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 27 Oct 2001 00:48:09 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Luigi Rizzo Cc: Bosko Milekic , "Keiichi SHIMA / ?$BEg7D0l?(B" , David Malone , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters In-Reply-To: <20011026092840.F64631@iguana.aciri.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 26 Oct 2001, Luigi Rizzo wrote: ... > documentation will likely see this behaviour documented. Changing it > might introduce insidious bugs in the code -- because in reality, > clusters are almost never shared except for those on the TCP send queue > and for multicast packets (but who uses multicast, anyways), so there is > a chance that we will have buggy code that goes unnoticed for a long > time. ... I use multicast on my workstation pretty much every day. While my own box isn't a multicast router, we have several FreeBSD boxes deployed as multicast routers at NAI Labs that are also used daily. Sure is a lot cheaper than the commercial video-conferencing services, and as long as you use telephone conferencing for the audio, it even sounds good too :-). No comment on the technical work going on here intended, just wanted to observe that people actually do use multicast :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 27 1: 2:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 2B97437B408; Sat, 27 Oct 2001 01:02:30 -0700 (PDT) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id f9R7x5973174; Sat, 27 Oct 2001 00:59:05 -0700 (PDT) (envelope-from rizzo) Date: Sat, 27 Oct 2001 00:59:05 -0700 From: Luigi Rizzo To: net@freebsd.org Subject: NEW CODE: polling support for device drivers. Message-ID: <20011027005905.A72758@iguana.aciri.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Maybe this can be of some interest to some of you using BSD boxes as routers, and who are concerned with performance and robustness to attacks. I would be grateful if some of you could have a look at this and possibly provide feedback. The patches attached here (for 4.4, i386 non-SMP) implement polling-mode operation for (a couple at the moment) network device drivers. This mode of operation gives huge performance and stability benefits under heavy load, at the price of a very modest (in many cases not noticeable) increase in latency. On our test box (Pentium 750 MHz, 21143 with "dc" driver), a stock FreeBSD 4.4 was barely able to forward a single stream of 130kpps through a 100Mbit interfac (well ok, that is not too bad!), but the system was very unresponsive, and livelock as soon as you start a second stream on a second interface. With polling enabled, the same box could forward 180Kpps and be completely responsive even when bombed with 4 full speed 100Mbit stream (about 590Kpps). Your mileage might vary, depending on the number of PCI buses, card type, etc. Note, this is really a minimal set of diffs, providing the basic mechanism for polling in the kernel, and very basic patches for a couple of device driver ("dc" and "fxp"). Next in the works is a system that limits to a programmable value the fraction of CPU time spent in a driver context -- right now the tuning is semi-manual. Instruction follow. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- INSTALLATION AND USE + make sure you have a device supported by the "dc" or "fxp" driver (the latter is not tested 100%, but should work) + (cd /sys ; patch < polling.patches ) + add the following two lines to the kernel config: options HZ=1000 options XORP_ETHER_POLLING + build and install the kernel + at runtime use the following sysctl variables to control polling: sysctl net.xorp.polling=1 # 1 to enable polling, 0 to disable sysctl net.xorp.poll_burst_min=10 # controls cpu allocation CPU permitting, the system will forward a minimum of ( poll_burst_min*HZ ) packets per second per interface, and more if there are any CPU cycles available. This parameter is only important if you expect to have CPU intensive tasks running on the router box -- otherwise, you can leave it set to a low value (5...20), and the system will use all the spare CPU cycles for forwarding. If you expect the system to be loaded, check the max forwarding speed setting the parameter to a low value when the system is unloaded, and then set the parameter to a suitable value to "reserve" the desired amount of CPU to forwarding. The additional latency introduced by polling can be as large as 1/HZ seconds, which is why i suggest using HZ=1000 (corresponding to 1ms additional latency in the worst case). Just for reference, the files touched by this diff are: sys/conf/options.i386 option definition sys/i386/include/asnames.h sys/net/if.h sys/net/netisr.h sys/sys/systm.h constants, variable and prototypes (mostly one-line changes) sys/i386/i386/swtch.s sys/i386/i386/trap.c calls to ether_poll from the idle loop and traps sys/kern/kern_clock.c main polling routines sys/dev/fxp/if_fxp.c sys/pci/if_dc.c sys/pci/if_dcreg.h device driver changes Supporting polling for other devices should be reasonably simple, following the example of the other two drivers. --------------------------------------------------------------------- --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="stable.xorp.diff.011026c" Index: conf/options.i386 =================================================================== RCS file: /home/xorpc/u2/freebsd/src/sys/conf/options.i386,v retrieving revision 1.132.2.8 diff -u -r1.132.2.8 options.i386 --- conf/options.i386 2001/10/03 07:15:37 1.132.2.8 +++ conf/options.i386 2001/10/27 00:23:01 @@ -208,5 +208,10 @@ SMBFS # ------------------------------- +# Xorp stuff +# ------------------------------- +XORP_ETHER_POLLING opt_global.h + +# ------------------------------- # EOF # ------------------------------- Index: dev/fxp/if_fxp.c =================================================================== RCS file: /home/xorpc/u2/freebsd/src/sys/dev/fxp/if_fxp.c,v retrieving revision 1.110.2.7 diff -u -r1.110.2.7 if_fxp.c --- dev/fxp/if_fxp.c 2001/08/31 02:17:02 1.110.2.7 +++ dev/fxp/if_fxp.c 2001/10/27 00:31:29 @@ -1123,6 +1123,39 @@ } } +static void fxp_intr_body(struct fxp_softc *sc, u_int8_t statack, int count); + +#ifdef XORP_ETHER_POLLING +static poll_handler_t fxp_poll; + +static void +fxp_poll(void *xsc, int cmd, int count) +{ + struct fxp_softc *sc = xsc; + u_int8_t statack ; + + statack = FXP_SCB_STATACK_CXTNO | FXP_SCB_STATACK_CNA | + FXP_SCB_STATACK_FR ; + if (cmd == 1) { + u_int8_t tmp ; + tmp = CSR_READ_1(sc, FXP_CSR_SCB_STATACK); + if (tmp == 0xff || tmp == 0) + return ; /* nothing to do */ + tmp &= ~statack ; + /* ack what we can */ + if (tmp != 0) + CSR_WRITE_1(sc, FXP_CSR_SCB_STATACK, tmp); + statack |= tmp ; + } + fxp_intr_body(sc, statack, count); + if (cmd == 2) { + sc->sc_if.if_ipending &= ~IFF_POLLING ; + /* enable interrupt */ + CSR_WRITE_1(sc, FXP_CSR_SCB_INTRCNTL, 0); + } +} +#endif /* XORP_ETHER_POLLING */ + /* * Process interface interrupts. */ @@ -1137,6 +1170,18 @@ return; } +#ifdef XORP_ETHER_POLLING + if (ifp->if_ipending & IFF_POLLING) + return ; + if (ether_poll_register(fxp_poll, xsc)) { + ifp->if_ipending |= IFF_POLLING ; + /* disable interrupts */ + CSR_WRITE_1(sc, FXP_CSR_SCB_INTRCNTL, FXP_SCB_INTR_DISABLE); + fxp_poll(xsc, 0, poll_burst); + return ; + } +#endif + while ((statack = CSR_READ_1(sc, FXP_CSR_SCB_STATACK)) != 0) { /* * It should not be possible to have all bits set; the @@ -1151,6 +1196,14 @@ * First ACK all the interrupts in this pass. */ CSR_WRITE_1(sc, FXP_CSR_SCB_STATACK, statack); + fxp_intr_body(sc, statack, -1); + } +} + +static void +fxp_intr_body(struct fxp_softc *sc, u_int8_t statack, int count) +{ + struct ifnet *ifp = &sc->sc_if; /* * Free any finished transmit mbuf chains. @@ -1201,7 +1254,9 @@ m = sc->rfa_headm; rfa = (struct fxp_rfa *)(m->m_ext.ext_buf + RFA_ALIGNMENT_FUDGE); - +#ifdef XORP_ETHER_POLLING /* loop at most count times if count >=0 */ + if (count < 0 || count-- > 0) +#endif if (rfa->rfa_status & FXP_RFA_STATUS_C) { /* * Remove first packet from the chain. @@ -1258,7 +1313,6 @@ fxp_scb_cmd(sc, FXP_SCB_COMMAND_RU_START); } } - } } /* Index: i386/i386/swtch.s =================================================================== RCS file: /home/xorpc/u2/freebsd/src/sys/i386/i386/swtch.s,v retrieving revision 1.89.2.4 diff -u -r1.89.2.4 swtch.s --- i386/i386/swtch.s 2001/07/26 02:29:10 1.89.2.4 +++ i386/i386/swtch.s 2001/10/26 21:54:19 @@ -246,6 +246,17 @@ call _procrunnable testl %eax,%eax CROSSJUMP(jnz, sw1a, jz) +#ifdef XORP_ETHER_POLLING + incl _idle_done + pushl _poll_burst + call _ether_poll + addl $4,%esp + sti + nop + cli + testl %eax, %eax + jnz idle_loop +#endif call _vm_page_zero_idle testl %eax, %eax jnz idle_loop Index: i386/i386/trap.c =================================================================== RCS file: /home/xorpc/u2/freebsd/src/sys/i386/i386/trap.c,v retrieving revision 1.147.2.5 diff -u -r1.147.2.5 trap.c --- i386/i386/trap.c 2001/08/15 01:23:50 1.147.2.5 +++ i386/i386/trap.c 2001/10/26 21:47:16 @@ -266,6 +266,11 @@ enable_intr(); } +#ifdef XORP_ETHER_POLLING + if (poll_in_trap) + ether_poll(poll_in_trap); +#endif /* XORP_ETHER_POLLING */ + #if defined(I586_CPU) && !defined(NO_F00F_HACK) restart: #endif Index: i386/include/asnames.h =================================================================== RCS file: /home/xorpc/u2/freebsd/src/sys/i386/include/Attic/asnames.h,v retrieving revision 1.44.2.3 diff -u -r1.44.2.3 asnames.h --- i386/include/asnames.h 2001/09/20 09:29:23 1.44.2.3 +++ i386/include/asnames.h 2001/10/27 00:32:28 @@ -210,6 +210,7 @@ #define _eintrnames eintrnames #define _end end #define _etext etext +#define _ether_poll ether_poll #define _exception exception #define _fast_intr_lock fast_intr_lock #define _fastmove fastmove @@ -225,6 +226,7 @@ #define _get_mplock get_mplock #define _get_syscall_lock get_syscall_lock #define _idle idle +#define _idle_done idle_done #define _ihandlers ihandlers #define _imen imen #define _imen_lock imen_lock @@ -266,6 +268,7 @@ #define _ovbcopy_vector ovbcopy_vector #define _panic panic #define _pc98_system_parameter pc98_system_parameter +#define _poll_burst poll_burst #define _poly_div16 poly_div16 #define _poly_div2 poly_div2 #define _poly_div4 poly_div4 Index: kern/kern_clock.c =================================================================== RCS file: /home/xorpc/u2/freebsd/src/sys/kern/kern_clock.c,v retrieving revision 1.105.2.4 diff -u -r1.105.2.4 kern_clock.c --- kern/kern_clock.c 2001/02/18 15:29:14 1.105.2.4 +++ kern/kern_clock.c 2001/10/27 00:45:42 @@ -67,6 +67,9 @@ #include #endif +#ifdef XORP_ETHER_POLLING +#include /* for NETISR_POLL */ +#endif /* * Number of timecounters used to implement stable storage @@ -188,6 +191,10 @@ psdiv = pscnt = 1; cpu_initclocks(); +#ifdef XORP_ETHER_POLLING + register_netisr(NETISR_POLL, ether_poll1); +#endif + /* * Compute profhz/stathz, and fix profhz if needed. */ @@ -236,6 +243,11 @@ tco_forward(0); ticks++; +#ifdef XORP_ETHER_POLLING + if (poll_handlers > 0) + schednetisr(NETISR_POLL); +#endif + /* * Process callouts at a very low cpu priority, so we don't keep the * relatively high clock interrupt priority any longer than necessary. @@ -999,3 +1011,202 @@ } #endif } + +#ifdef XORP_ETHER_POLLING +#ifdef SMP + error -- POLLING and SMP are not compatible yet +#endif +/* + * Polling support for device drivers. + */ + +SYSCTL_NODE(_net, OID_AUTO, xorp, CTLFLAG_RW, 0, "Xorp parameters"); + +u_int32_t idle_done; +SYSCTL_ULONG(_net_xorp, OID_AUTO, idle_done, CTLFLAG_RD, + &idle_done, 0, "Have gone in idle_loop"); + +u_int32_t poll_burst = 5; +SYSCTL_ULONG(_net_xorp, OID_AUTO, poll_burst, CTLFLAG_RW, + &poll_burst, 0, "Current Polling burst size"); + +u_int32_t poll_burst_min = 5; +SYSCTL_ULONG(_net_xorp, OID_AUTO, poll_burst_min, CTLFLAG_RW, + &poll_burst_min, 0, "Min Polling burst size"); + +u_int32_t poll_burst_max = 100; +SYSCTL_ULONG(_net_xorp, OID_AUTO, poll_burst_max, CTLFLAG_RW, + &poll_burst_max, 0, "Max Polling burst size"); + +u_int32_t poll_in_trap; +SYSCTL_ULONG(_net_xorp, OID_AUTO, poll_in_trap, CTLFLAG_RW, + &poll_in_trap, 0, "Poll size while getting a trap ?"); + +/* + * Devices that want to do polling must register for it, + * typically from the interrupt service routine, by calling + * ether_poll_register(handler, arg). + * + * The handler is called with 3 arguments: the "arg" passed at register + * time (typically a softc pointer), a command (see below) and a count limit. + * The command can be one of the following: + * 0: quick move of "count" packets from input/output queues. + * 1: as above, plus check status registers for errors etc. + * 2: unregister and return to interrupt mode. + * + * The count limit specifies how much work the handler can do during the + * call -- typically this is the number of packets to be received, or + * transmitted, etc. (drivers are free to interpret this number, as long + * as the max time spent in the function grows roughly linearly with the + * count). + */ +#define POLL_LIST_LEN 128 +struct pollrec { + poll_handler_t *handler ; + void *arg; +}; + +static struct pollrec pr[POLL_LIST_LEN]; +u_int32_t poll_handlers; /* next free entry in pr[]. */ +SYSCTL_ULONG(_net_xorp, OID_AUTO, poll_handlers, CTLFLAG_RD, + &poll_handlers, 0, "next entry in poll register array"); + +/* + * this sysctl variable globally controls polling + */ +static int polling = 0 ; +SYSCTL_ULONG(_net_xorp, OID_AUTO, polling, CTLFLAG_RW, + &polling, 0, "Polling enabled"); + + +/* + * ether_poll is called from the idle loop. + */ +int +ether_poll(int count) +{ + static int i; + int s = splimp(); + + if (count > poll_burst) + count = poll_burst ; + if (i >= poll_handlers) + i = 0 ; + if (pr[i].handler) + (*pr[i].handler)(pr[i].arg, 0, count); /* quick check */ + i++ ; + splx(s); + return 1; /* more polling */ +} + +/* + * A simple control loop to adapt the burst size to the CPU load, within + * predefined limit. In practice, only the minimum size counts, and should + * be small enough not to cause livelock. The actual value depends on + * CPU speed, number and type of interfaces, etc. The max size only + * serves to reserve some CPU to the polling routines at the beginning + * of heavy CPU load, but it rapidly decays to the min value under load. + * + * A better but more complex controller (to come) will account time spent + * in the interrupt/polling routines and tries to match it with a + * user-programmable threshold. + */ +static void update_poll_burst(void); + +static void +update_poll_burst(void) +{ + static u_int32_t ready = 0 ; /* act when ready==0 */ + + if (ready-- > 0) + return ; + ready = hz/20 ; + if (poll_burst_min >= poll_burst_max) + poll_burst_min = poll_burst_max/2 ; + if (poll_burst_min > 50) + poll_burst_min = 50 ; + else if (poll_burst_min < 1) + poll_burst_min = 1 ; + if (idle_done > 0) { + if (poll_burst < poll_burst_max) + poll_burst++ ; + else + poll_burst = poll_burst_max; + } else { /* decreasing */ + if (poll_burst <= poll_burst_min) + poll_burst = poll_burst_min ; + else if (poll_burst < 4 * poll_burst_min ) + poll_burst -- ; + else + poll_burst >>= 1 ; + } + + idle_done = 0 ; +} + +/* + * ether_poll1 is called by schednetisr when appropriate, typically once + * per tick. It is called at splnet() so first thing to do is to upgrade to + * splimp(), then recompute the burst size, and call all registered handlers. + */ +void +ether_poll1(void) +{ + int i; + int s=splimp(); + int arg = polling ? 1 /* poll */ : 2 /* unregister */ ; + + update_poll_burst(); + + for (i = 0 ; i < poll_handlers ; i++) { + if (pr[i].handler) { + (*pr[i].handler)(pr[i].arg, arg, poll_burst); + if (arg == 2) + pr[i].handler=NULL; + } + } + if (arg == 2) + poll_handlers = 0; + splx(s); +} + +/* + * Try to register routine for polling. Returns 1 if successful + * (and polling should be enabled), 0 otherwise. + * A device is not supposed to register itself multiple times. + */ +int +ether_poll_register(poll_handler_t *h, void *arg) +{ + int s; + + if (polling == 0) /* polling disabled, cannot register */ + return 0; + if (h == NULL || arg == NULL) /* bad arguments */ + return 0 ; + + s = splhigh(); + if (poll_handlers >= POLL_LIST_LEN) { /* list full */ + /* + * This should never happen; if it does, it is probably a broken + * driver trying to register multiple times. But checking this at + * runtime is expensive, and won't solve problems anyways, so just + * report the problem a few times and then give up. + */ + static int verbose = 10 ; + splx(s); + if (verbose >0) { + printf("poll handlers list full -- maybe a broken driver ?\n"); + verbose-- ; + } + return 0; /* no polling for you */ + } + + pr[poll_handlers].handler = h ; + pr[poll_handlers].arg = arg ; + poll_handlers++ ; + splx(s); + return 1 ; /* polling enabled in next call */ +} + +#endif /* XORP_ETHER_POLLING */ Index: net/if.h =================================================================== RCS file: /home/xorpc/u2/freebsd/src/sys/net/if.h,v retrieving revision 1.58.2.2 diff -u -r1.58.2.2 if.h --- net/if.h 2001/07/24 19:10:18 1.58.2.2 +++ net/if.h 2001/10/27 00:46:45 @@ -131,6 +131,15 @@ #define IFF_ALTPHYS IFF_LINK2 /* use alternate physical connection */ #define IFF_MULTICAST 0x8000 /* supports multicast */ +/* + * The following flag(s) ought to go in if_flags, but we cannot change + * struct ifnet because of binary compatibility, so we store them in + * if_ipending, which is not used so far. + * If possible, make sure the value is not conflicting with other + * IFF flags, so we have an easier time when we want to merge them. + */ +#define IFF_POLLING 0x10000 /* Interface is in polling mode. */ + /* flags set internally only: */ #define IFF_CANTCHANGE \ (IFF_BROADCAST|IFF_POINTOPOINT|IFF_RUNNING|IFF_OACTIVE|\ Index: net/netisr.h =================================================================== RCS file: /home/xorpc/u2/freebsd/src/sys/net/netisr.h,v retrieving revision 1.21.2.2 diff -u -r1.21.2.2 netisr.h --- net/netisr.h 2001/03/06 00:55:07 1.21.2.2 +++ net/netisr.h 2001/10/25 23:23:58 @@ -52,6 +52,7 @@ * interrupt used for scheduling the network code to calls * on the lowest level routine of each protocol. */ +#define NETISR_POLL 1 /* polling callback */ #define NETISR_IP 2 /* same as AF_INET */ #define NETISR_NS 6 /* same as AF_NS */ #define NETISR_ATALK 16 /* same as AF_APPLETALK */ Index: pci/if_dc.c =================================================================== RCS file: /home/xorpc/u2/freebsd/src/sys/pci/if_dc.c,v retrieving revision 1.9.2.22 diff -u -r1.9.2.22 if_dc.c --- pci/if_dc.c 2001/07/20 02:01:26 1.9.2.22 +++ pci/if_dc.c 2001/10/27 00:51:11 @@ -2318,6 +2318,13 @@ while(!(sc->dc_ldata->dc_rx_list[i].dc_status & DC_RXSTAT_OWN)) { struct mbuf *m0 = NULL; +#ifdef XORP_ETHER_POLLING + if (ifp->if_ipending & IFF_POLLING) { + if (sc->rxcycles <= 0) + break ; + sc->rxcycles -- ; + } +#endif /* XORP_ETHER_POLLING */ cur_rx = &sc->dc_ldata->dc_rx_list[i]; rxstat = cur_rx->dc_status; m = sc->dc_cdata.dc_rx_chain[i]; @@ -2606,6 +2613,61 @@ return; } +#ifdef XORP_ETHER_POLLING +static poll_handler_t dc_poll; + +static void +dc_poll(void *arg, int cmd, int count) +{ + struct dc_softc *sc = arg ; + struct ifnet *ifp = &sc->arpcom.ac_if; + + sc->rxcycles = count ; + dc_rxeof(sc); + dc_txeof(sc); + if (ifp->if_snd.ifq_head != NULL && !(ifp->if_flags & IFF_OACTIVE)) + dc_start(ifp); + + if (cmd == 1) { /* also check status register */ + u_int32_t status; + + status = CSR_READ_4(sc, DC_ISR); + status &= (DC_ISR_RX_WATDOGTIMEO|DC_ISR_RX_NOBUF| + DC_ISR_TX_NOBUF|DC_ISR_TX_IDLE|DC_ISR_TX_UNDERRUN| + DC_ISR_BUS_ERR); + if (!status) + return ; + /* ack what we have */ + CSR_WRITE_4(sc, DC_ISR, status); + + if (status & (DC_ISR_RX_WATDOGTIMEO|DC_ISR_RX_NOBUF) ) { + u_int32_t r = CSR_READ_4(sc, DC_FRAMESDISCARDED); + ifp->if_ierrors += (r & 0xffff) + + ( (r >> 17) & 0x7ff ) ; + + if (dc_rx_resync(sc)) + dc_rxeof(sc); + } + /* restart transmit unit if necessary */ + if (status & DC_ISR_TX_IDLE && sc->dc_cdata.dc_tx_cnt) + CSR_WRITE_4(sc, DC_TXSTART, 0xFFFFFFFF); + + if (status & DC_ISR_TX_UNDERRUN) + dc_tx_underrun(sc); + + if (status & DC_ISR_BUS_ERR) { + printf("dc_poll: dc%d bus error\n", sc->dc_unit); + dc_reset(sc); + dc_init(sc); + } + } else if (cmd == 2) { /* final call, enable interrupts */ + ifp->if_ipending &= ~IFF_POLLING ; + /* Re-enable interrupts. */ + CSR_WRITE_4(sc, DC_IMR, DC_INTRS); + } +} +#endif /* XORP_ETHER_POLLING */ + static void dc_intr(arg) void *arg; { @@ -2614,11 +2676,24 @@ u_int32_t status; sc = arg; + ifp = &sc->arpcom.ac_if; + +#ifdef XORP_ETHER_POLLING + if (ifp->if_ipending & IFF_POLLING) + return ; + if (ether_poll_register(dc_poll, arg)) { + ifp->if_ipending |= IFF_POLLING ; + /* disable interrupts */ + CSR_WRITE_4(sc, DC_IMR, 0x00000000); + dc_poll(sc, 0, poll_burst); + return ; + } +#endif + if ( (CSR_READ_4(sc, DC_ISR) & DC_INTRS) == 0) return ; - ifp = &sc->arpcom.ac_if; /* Suppress unwanted interrupts */ if (!(ifp->if_flags & IFF_UP)) { @@ -2875,6 +2950,11 @@ CSR_WRITE_4(sc, DC_BUSCTL, 0); else CSR_WRITE_4(sc, DC_BUSCTL, DC_BUSCTL_MRME|DC_BUSCTL_MRLE); + /* + * Evenly share the bus between receive and transmit process. + */ + if (DC_IS_INTEL(sc)) + DC_SETBIT(sc, DC_BUSCTL, DC_BUSCTL_ARBITRATION); if (DC_IS_DAVICOM(sc) || DC_IS_INTEL(sc)) { DC_SETBIT(sc, DC_BUSCTL, DC_BURSTLEN_USECA); } else { Index: pci/if_dcreg.h =================================================================== RCS file: /home/xorpc/u2/freebsd/src/sys/pci/if_dcreg.h,v retrieving revision 1.4.2.11 diff -u -r1.4.2.11 if_dcreg.h --- pci/if_dcreg.h 2001/10/25 18:50:18 1.4.2.11 +++ pci/if_dcreg.h 2001/10/26 07:22:36 @@ -429,7 +429,7 @@ #define DC_FILTER_HASHONLY 0x10400000 #define DC_MAXFRAGS 16 -#define DC_RX_LIST_CNT 64 +#define DC_RX_LIST_CNT 192 /* was 64 */ #define DC_TX_LIST_CNT 256 #define DC_MIN_FRAMELEN 60 #define DC_RXLEN 1536 @@ -659,6 +659,7 @@ bus_space_handle_t dc_bhandle; /* bus space handle */ bus_space_tag_t dc_btag; /* bus space tag */ void *dc_intrhand; + int rxcycles; /* ... when polling */ struct resource *dc_irq; struct resource *dc_res; struct dc_type *dc_info; /* adapter info */ Index: sys/systm.h =================================================================== RCS file: /home/xorpc/u2/freebsd/src/sys/sys/systm.h,v retrieving revision 1.111.2.8 diff -u -r1.111.2.8 systm.h --- sys/systm.h 2001/07/30 23:28:01 1.111.2.8 +++ sys/systm.h 2001/10/26 21:39:52 @@ -89,6 +89,17 @@ #define CONDSPLASSERT(cond, level, msg) #endif +#ifdef XORP_ETHER_POLLING +extern u_int32_t poll_handlers; /* how many handlers registered for polling */ +extern u_int32_t poll_in_trap; /* do we poll devices in a trap ? */ +extern u_int32_t poll_burst; /* how many pkts per poll cycle */ + +typedef void poll_handler_t __P((void *sc, int cmd, int count)); +int ether_poll __P((int count)); +void ether_poll1 __P((void)); +int ether_poll_register __P((poll_handler_t *h, void *sc)); +#endif /* XORP_ETHER_POLLING */ + /* * General function declarations. */ --9jxsPFA5p3P2qPhR-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 27 1:43:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from server.soekris.com (soekris.com [216.15.61.44]) by hub.freebsd.org (Postfix) with ESMTP id 79DE037B403 for ; Sat, 27 Oct 2001 01:43:53 -0700 (PDT) Received: from soekris.com (1.4.soekris.com [192.168.1.4] (may be forged)) by server.soekris.com (8.9.2/8.9.2) with ESMTP id BAA27034; Sat, 27 Oct 2001 01:43:58 -0700 (PDT) (envelope-from soren@soekris.com) Message-ID: <3BDA73C0.73DBCAE9@soekris.com> Date: Sat, 27 Oct 2001 01:43:44 -0700 From: Soren Kristensen Organization: Soekris Engineering X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: NEW CODE: polling support for device drivers. References: <20011027005905.A72758@iguana.aciri.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi and all, That looks very interesting to me.... I would like to follow up with a question, just because of my interest in getting maximum packet forwarding performance out of FreeBSD.... As I see it, the advantage of the polling code is to avoid interrupts and context switches. Is it possible to implement all the basic packet forwarding to run to completion at interrupt, ie, when a packet comes in, the interrupt code would run until the packet has been sent out on another interface, and then loop back to see if there's more incomming packets, in a polling fashion. That would give the advantage of the polling, but without the latency. I'm mostly a hardware guy, so bear over with me if it's not possible at all.... Regards, Soren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 27 1:52:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id CFE3437B401 for ; Sat, 27 Oct 2001 01:52:40 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id D52A681D05; Sat, 27 Oct 2001 03:52:40 -0500 (CDT) Date: Sat, 27 Oct 2001 03:52:40 -0500 From: Alfred Perlstein To: Soren Kristensen Cc: Luigi Rizzo , net@FreeBSD.ORG, Terry Lambert Subject: Re: NEW CODE: polling support for device drivers. Message-ID: <20011027035240.Q15052@elvis.mu.org> References: <20011027005905.A72758@iguana.aciri.org> <3BDA73C0.73DBCAE9@soekris.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BDA73C0.73DBCAE9@soekris.com>; from soren@soekris.com on Sat, Oct 27, 2001 at 01:43:44AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Soren Kristensen [011027 03:43] wrote: > Luigi and all, > > That looks very interesting to me.... I would like to follow up with a > question, just because of my interest in getting maximum packet > forwarding performance out of FreeBSD.... > > As I see it, the advantage of the polling code is to avoid interrupts > and context switches. > > Is it possible to implement all the basic packet forwarding to run to > completion at interrupt, ie, when a packet comes in, the interrupt code > would run until the packet has been sent out on another interface, and > then loop back to see if there's more incomming packets, in a polling > fashion. > > That would give the advantage of the polling, but without the latency. > > I'm mostly a hardware guy, so bear over with me if it's not possible at > all.... Actually your idea is sort of what Terry Lambert posted about a couple of weeks ago. I have no idea what happened in the end, the flameage went on and on and I lost interest. Can anyone summarize for the benefit of the list? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 27 2:52:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id E937237B401 for ; Sat, 27 Oct 2001 02:52:55 -0700 (PDT) Received: (qmail 92360 invoked by uid 1000); 27 Oct 2001 09:52:54 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Oct 2001 09:52:54 -0000 Date: Sat, 27 Oct 2001 04:52:54 -0500 (CDT) From: Mike Silbersack To: Alfred Perlstein Cc: Soren Kristensen , Luigi Rizzo , , Terry Lambert Subject: Re: NEW CODE: polling support for device drivers. In-Reply-To: <20011027035240.Q15052@elvis.mu.org> Message-ID: <20011027044854.X88536-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 27 Oct 2001, Alfred Perlstein wrote: > > Is it possible to implement all the basic packet forwarding to run to > > completion at interrupt, ie, when a packet comes in, the interrupt code > > would run until the packet has been sent out on another interface, and > > then loop back to see if there's more incomming packets, in a polling > > fashion. > > > > That would give the advantage of the polling, but without the latency. > > > > I'm mostly a hardware guy, so bear over with me if it's not possible at > > all.... > > Actually your idea is sort of what Terry Lambert posted about a couple > of weeks ago. I have no idea what happened in the end, the flameage > went on and on and I lost interest. > > Can anyone summarize for the benefit of the list? > > -- > -Alfred Perlstein [alfred@freebsd.org] Summary: The patch Terry posted was to loop a few more times in the interrupt handler. I was going to commit it this weekend for the dc driver, but it looks like Luigi's work overshadows that. The idea proposed above is (similar to) LRP, which Terry implemented for clickarray. It is not in his patchset. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 27 7: 9:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hub.freebsd.org (Postfix) with ESMTP id D561637B405; Sat, 27 Oct 2001 07:09:30 -0700 (PDT) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id SAA05296; (8.9.3/vak/2.1) Sat, 27 Oct 2001 18:12:11 +0400 (MSD) Message-ID: <3BDABF7B.4060808@cronyx.ru> Date: Sat, 27 Oct 2001 18:06:51 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Cc: Serge Vakulenko , mike@FreeBSD.org, freebsd-bugs@FreeBSD.org, julian@FreeBSD.org, archie@FreeBSD.org, joerg@FreeBSD.org, rik@cronyx.ru Subject: kern/11238, kern/14848, kern/21771, sppp patch's patch_id #1 References: <000901c1134b$827a69a0$48b5ce90@crox> Content-Type: multipart/mixed; boundary="------------090906090208020507000109" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------090906090208020507000109 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Hi, This is the first patch of set of patches that I plan to make. These patches ware send several times as a big patch and last one wasn't even discussed. So I will try to send them by small pieces and will try to comment them. Last one big patch was kern/21771. Last our version of sppp and adapter drivers could be found at http://www.cronyx.ru/software/ First portion contains following changes: 1) Just a header changes. 2) Changes like that: case STATE_CLOSING: - sppp_cp_change_state(cp, sp, STATE_CLOSED); (cp->tlf)(sp); + sppp_cp_change_state(cp, sp, STATE_CLOSED); break; Comment: If you change state at first and then call tlf you will get wrong final state cause tlf will lead to "Close" event and you will get (for this example) final state "Initial". In some cases this isn't so fatal but in other this will put out of action a link. All this changes was made according to RFC1661. Best regards, Roman Kurakin, Software Engineer, Cronyx Engineering >>Synopsis: Frame Relay support, corrected >> >>State-Changed-From-To: open->suspended >>State-Changed-By: mike >>State-Changed-When: Fri Jul 20 19:54:47 PDT 2001 >>State-Changed-Why: >> >>With a little bit of work, this could probably be committed. >>Awaiting committer. >> >>http://www.FreeBSD.org/cgi/query-pr.cgi?pr=14848 >> > --------------090906090208020507000109 Content-Type: text/plain; name="sppp1.pch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sppp1.pch" --- if_spppsubr.c.orig Sat Oct 27 16:37:21 2001 +++ if_spppsubr.c Sat Oct 27 16:56:32 2001 @@ -1,13 +1,21 @@ /* - * Synchronous PPP/Cisco link level subroutines. + * Synchronous PPP/Cisco/Frame Relay link level subroutines. * Keepalive protocol implemented in both Cisco and PPP modes. + * ANSI T1.617-compaible link management signaling + * implemented for Frame Relay mode. + * Cisco-type Frame Relay framing added, thanks Alex Tutubalin. + * Only one DLCI per channel for now. * - * Copyright (C) 1994-1996 Cronyx Engineering Ltd. + * Copyright (C) 1994-2001 Cronyx Engineering Ltd. * Author: Serge Vakulenko, * * Heavily revamped to conform to RFC 1661. * Copyright (C) 1997, Joerg Wunsch. * + * Slightly revamped to conform to real life. + * Copyright (C) 1999-2001 Cronyx Engineering Ltd. + * Author: Kurakin Roman, + * * This software is distributed with NO WARRANTIES, not even the implied * warranties for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * @@ -222,7 +230,7 @@ u_short time0; u_short time1; }; -#define CISCO_PACKET_LEN 18 +#define CISCO_PACKET_LEN 14 /* * We follow the spelling and capitalization of RFC 1661 here, to make @@ -1532,12 +1540,12 @@ case STATE_ACK_SENT: break; case STATE_CLOSING: - sppp_cp_change_state(cp, sp, STATE_CLOSED); (cp->tlf)(sp); + sppp_cp_change_state(cp, sp, STATE_CLOSED); break; case STATE_STOPPING: - sppp_cp_change_state(cp, sp, STATE_STOPPED); (cp->tlf)(sp); + sppp_cp_change_state(cp, sp, STATE_STOPPED); break; case STATE_ACK_RCVD: sppp_cp_change_state(cp, sp, STATE_REQ_SENT); @@ -1850,8 +1858,8 @@ case STATE_CLOSING: break; case STATE_STARTING: - sppp_cp_change_state(cp, sp, STATE_INITIAL); (cp->tlf)(sp); + sppp_cp_change_state(cp, sp, STATE_INITIAL); break; case STATE_STOPPED: sppp_cp_change_state(cp, sp, STATE_CLOSED); @@ -1890,18 +1898,18 @@ /* TO- event */ switch (sp->state[cp->protoidx]) { case STATE_CLOSING: - sppp_cp_change_state(cp, sp, STATE_CLOSED); (cp->tlf)(sp); + sppp_cp_change_state(cp, sp, STATE_CLOSED); break; case STATE_STOPPING: - sppp_cp_change_state(cp, sp, STATE_STOPPED); (cp->tlf)(sp); + sppp_cp_change_state(cp, sp, STATE_STOPPED); break; case STATE_REQ_SENT: case STATE_ACK_RCVD: case STATE_ACK_SENT: - sppp_cp_change_state(cp, sp, STATE_STOPPED); (cp->tlf)(sp); + sppp_cp_change_state(cp, sp, STATE_STOPPED); break; } else --------------090906090208020507000109-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 27 7:49: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from leviathan.umiacs.umd.edu (leviathan.umiacs.umd.edu [128.8.120.189]) by hub.freebsd.org (Postfix) with ESMTP id 6DB8937B401 for ; Sat, 27 Oct 2001 07:49:02 -0700 (PDT) Received: from leviathan.umiacs.umd.edu (localhost [127.0.0.1]) by leviathan.umiacs.umd.edu (8.9.3/8.9.1) with ESMTP id KAA11184 for ; Sat, 27 Oct 2001 10:49:01 -0400 (EDT) Message-Id: <200110271449.KAA11184@leviathan.umiacs.umd.edu> To: freebsd-net@FreeBSD.ORG Subject: Reply Hazy (Encrypted VPN across FBSD, W2k, RHL, etc...) Date: Sat, 27 Oct 2001 10:49:01 -0400 From: Gary Jackson Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm looking for the best way to get an encrypted VPN set up that's compatible with FreeBSD (on the permanent end), and clients running Win 2k and RedHat Linux. I'd like to do this without having to buy software from someone. I have a suspicion that the limiting factor here is going to be the Microsoft product. It appears as if it will do encrypted VPNs two ways: 1. PPTP with proprietary MPPE encryption/compression 2. IPSec/l2tp proprietary hybrid I looked in to option (1). It seems to be the easiest, with the exception that apparently I need some proprietary code (as per the following quote from the ng_mppc(4) manual page: The MPPC protocol requires proprietary compression code available from Hi/Fn (formerly STAC). These files must be obtained elsewhere and added to the kernel sources before this node type will compile with the NETGRAPH_MPPC_COMPRESSION option. I haven't been able to find said code freely, for sale, or otherwise. Option (2) looks even less likely. I've only been able to find one implementation of l2tp, and it looks like it's still a pretty flaky piece of software that hasn't been integrated with IPSec. I'd appreciate any help I can get with this. -- Gary Jackson bargle@umiacs.umd.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 27 7:52:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id C1A1C37B401 for ; Sat, 27 Oct 2001 07:52:11 -0700 (PDT) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id f9REmjT78232; Sat, 27 Oct 2001 07:48:45 -0700 (PDT) (envelope-from rizzo) Date: Sat, 27 Oct 2001 07:48:45 -0700 From: Luigi Rizzo To: Soren Kristensen Cc: net@FreeBSD.ORG Subject: Re: NEW CODE: polling support for device drivers. Message-ID: <20011027074845.D77729@iguana.aciri.org> References: <20011027005905.A72758@iguana.aciri.org> <3BDA73C0.73DBCAE9@soekris.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BDA73C0.73DBCAE9@soekris.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Oct 27, 2001 at 01:43:44AM -0700, Soren Kristensen wrote: > Luigi and all, > > That looks very interesting to me.... I would like to follow up with a > question, just because of my interest in getting maximum packet > forwarding performance out of FreeBSD.... > > As I see it, the advantage of the polling code is to avoid interrupts > and context switches. There is in fat more than that. I will post later another (longish) message to explain things in more detail. > Is it possible to implement all the basic packet forwarding to run to > completion at interrupt, ie, when a packet comes in, the interrupt code > would run until the packet has been sent out on another interface, and > then loop back to see if there's more incomming packets, in a polling > fashion. This seems to be a common question :) If you have fastforwarding enabled (sysctl net.inet.ip.fastforwarding=1) this is actually how network drivers already work now -- they loop around the interrupt status register, and each incoming packet is processed up to the call to XX_start() on the output interface. Without fastforwarding, processing stops much earlier, i.e. when the packet is queued into the ipintrq, and then a software interrupt is scheduled to process ip_input(). cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 27 8: 8:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 0753937B405 for ; Sat, 27 Oct 2001 08:08:20 -0700 (PDT) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id f9RF4md78357; Sat, 27 Oct 2001 08:04:48 -0700 (PDT) (envelope-from rizzo) Date: Sat, 27 Oct 2001 08:04:48 -0700 From: Luigi Rizzo To: Mike Silbersack Cc: Alfred Perlstein , Soren Kristensen , net@FreeBSD.ORG, Terry Lambert Subject: Re: NEW CODE: polling support for device drivers. Message-ID: <20011027080448.F77729@iguana.aciri.org> References: <20011027035240.Q15052@elvis.mu.org> <20011027044854.X88536-100000@achilles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011027044854.X88536-100000@achilles.silby.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Oct 27, 2001 at 04:52:54AM -0500, Mike Silbersack wrote: ... > Summary: The patch Terry posted was to loop a few more times in the > interrupt handler. I was going to commit it this weekend for the dc > driver, but it looks like Luigi's work overshadows that. Terry was kind enough to send me a copy of his patch. I havent looked at it in much details, but from what i remember it matches the description given above by Mike, and is totally different from what I have done (which also explain why i did not look more closely at Terry's code). Note, the use of polling is not novel and i do not claim any paternity on the ideas i have implemented -- polling has been largely described in the literature and implemented by some (I know of Mogul's 1997 paper on preventing interrupt livelock and of MIT's Click http://www.pdos.lcs.mit.edu/Click/ ). I am just quite proud of how simple and compact (and possibly elegant) this code came out (admittedly, this is the third rewrite!) cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 27 11:55:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id C110937B403 for ; Sat, 27 Oct 2001 11:55:11 -0700 (PDT) Received: from dialup-209.247.143.45.dial1.sanjose1.level3.net ([209.247.143.45] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15xYbo-0003vh-00; Sat, 27 Oct 2001 11:55:05 -0700 Message-ID: <3BDB033C.98ED2BDF@mindspring.com> Date: Sat, 27 Oct 2001 11:55:56 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: Alfred Perlstein , Soren Kristensen , Luigi Rizzo , net@FreeBSD.ORG Subject: Re: NEW CODE: polling support for device drivers. References: <20011027044854.X88536-100000@achilles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Silbersack wrote: > > > Is it possible to implement all the basic packet forwarding to run to > > > completion at interrupt, ie, when a packet comes in, the interrupt code > > > would run until the packet has been sent out on another interface, and > > > then loop back to see if there's more incomming packets, in a polling > > > fashion. > > > > > > That would give the advantage of the polling, but without the latency. > > > > > > I'm mostly a hardware guy, so bear over with me if it's not possible at > > > all.... > > > > Actually your idea is sort of what Terry Lambert posted about a couple > > of weeks ago. I have no idea what happened in the end, the flameage > > went on and on and I lost interest. > > > > Can anyone summarize for the benefit of the list? > > Summary: The patch Terry posted was to loop a few more times in the > interrupt handler. I was going to commit it this weekend for the dc > driver, but it looks like Luigi's work overshadows that. > > The idea proposed above is (similar to) LRP, which Terry implemented for > clickarray. It is not in his patchset. Luigi's stuff is rather complementary, IMO, and would require the same thing, in order to not lose an inordinate amount of packets to other high latency processing. On you backhand comment on the unavailability of the LRP code... Rice University has made an LRP implementation available for integration into FreBSD on no less that two occasions. Realize that the LRP I implemented for ClickArray is based on the 2.x FreeBSD work they did for LRP. I _strongly_ disagree with their resource container design, which they have built for FreeBSD 4.x, and which is an easy ported to the RELENG_4 branch. There are two problems with the resource container implementation: 1) It ignores some fundamental issues of SMP, kernel preemption, stack reentrancy, and container contention. 2) It has a very bad license, which requires you to get permission -- and pay -- for commercial use of the code. Both the resource container and the earlier implementations are research toys, as they are distributed. By this, I mean that they are not commercial quality code; the way they implemented their integration was to define an alternate protocol type, and in so doing, they have created a method whereby they can run the LRP stack in parallel with the BSD stack. The reason this makes them toys is that they do not handle most of the required processing for a huge number of boundary conditions, and rely on the fact that they will only get a subset of the trafic on the LRP stack that they would otherwise get on the wire. They also disable support for a number of RFC mandated TCP options and actual TCP implemnetation details; my lab testing with these reenabled shows no reason for this, other than they were difficult to reenable. ClickArray has a number of similar "toys" in their research projects, as well. My implementation (which I indicated before I would like to get freed up and donated back to FreeBSD -- if I can't, I will rewrite it from scratch, on my own time and equipment) does not have these problems, in that I have integrated into the real BSD stack. It can peacefully coeexist with other networking stacks, and it can handle all of TCP, not just the expected traffic, without breaking on, for example, new socket allocation for a kqueue based batch accept. You will get it when I can give it to you, and not before; meanwhile, I'll give you what I can when I can. PS: Luigi had copies of some of my code well before I was able to give copies of the coelescing code to FreeBSD; he had previously signed a non-disclosure agreement which allowed me to hand him a lot of code that I still have not handed to others. It's no wonder that there is some overlap. PPS: The polling support for device drivers was something I had discussed with Bill Paul previously. He did not like the idea of externalizing the entry points for the tx_eof and rx_eof routines, as it changed the interface, and not all cards were capable of supporting it, anyway. PPPS: A more correct implementation of polling would probably be implemented using opportunistic timers; due to an office move which will not really be complete before Tuesday, I am unfortunately unable to cite paper references on opportunistic timers today. PPPPS: The techniques we are describing are nothing new; the people at Rice University who have pioneered a number of them are actually the founders of iMimic, which, if you were into such things, you would know is the company that kicks everyone's butt on the commercial benchmarks. Regards, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 27 12: 1:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 2662837B403 for ; Sat, 27 Oct 2001 12:01:16 -0700 (PDT) Received: from dialup-209.247.143.45.dial1.sanjose1.level3.net ([209.247.143.45] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15xYhj-0000h8-00; Sat, 27 Oct 2001 12:01:12 -0700 Message-ID: <3BDB04AC.1D100774@mindspring.com> Date: Sat, 27 Oct 2001 12:02:04 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: Mike Silbersack , Alfred Perlstein , Soren Kristensen , net@FreeBSD.ORG Subject: Re: NEW CODE: polling support for device drivers. References: <20011027035240.Q15052@elvis.mu.org> <20011027044854.X88536-100000@achilles.silby.com> <20011027080448.F77729@iguana.aciri.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo wrote: > > On Sat, Oct 27, 2001 at 04:52:54AM -0500, Mike Silbersack wrote: > ... > > Summary: The patch Terry posted was to loop a few more times in the > > interrupt handler. I was going to commit it this weekend for the dc > > driver, but it looks like Luigi's work overshadows that. > > Terry was kind enough to send me a copy of his patch. I havent > looked at it in much details, but from what i remember it > matches the description given above by Mike, and is totally > different from what I have done (which also explain why i did not > look more closely at Terry's code). Yes. The code is totally complementary. > Note, the use of polling is not novel and i do not claim any > paternity on the ideas i have implemented -- polling has been > largely described in the literature and implemented by some (I know > of Mogul's 1997 paper on preventing interrupt livelock and of MIT's > Click http://www.pdos.lcs.mit.edu/Click/ ). Yes, the Click router project (no relation to ClickArray) is a nifty piece of work. It has too much overengineering for modularity, for my taste, in that the latency is taken at run time, instead of module assembly time. I've been pointing at the 1991 Mogul paper, myself, on the coelescing defense front. The guy is incredibly prolific! 8-). > I am just quite proud of how simple and compact (and possibly > elegant) this code came out (admittedly, this is the third > rewrite!) Yes, it's very nice code. I like it. Note to FreeBSD people: you would do well to incorporate code from Luigi whenever possible. You would have had a SACK and TSACK implementation for FreeBSD Circa 1996 or so, about half a decade before any commercial OS had it. The TSACK, in particular, did not rely on Microsoft implementing SACK in their clients, which is what everyone else held off their implementations over. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 27 12:11:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id DEA1437B403 for ; Sat, 27 Oct 2001 12:11:35 -0700 (PDT) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id f9RJ85581300; Sat, 27 Oct 2001 12:08:05 -0700 (PDT) (envelope-from rizzo) Date: Sat, 27 Oct 2001 12:08:05 -0700 From: Luigi Rizzo To: Terry Lambert Cc: Mike Silbersack , Alfred Perlstein , Soren Kristensen , net@FreeBSD.ORG Subject: Re: NEW CODE: polling support for device drivers. Message-ID: <20011027120805.B80606@iguana.aciri.org> References: <20011027044854.X88536-100000@achilles.silby.com> <3BDB033C.98ED2BDF@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BDB033C.98ED2BDF@mindspring.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Oct 27, 2001 at 11:55:56AM -0700, Terry Lambert wrote: ... only one small note: you are probably confusing me with someone else here, all i had from you was (early this september) a short snippet of code for some device driver after you or somene else mentioned it on the lists. > PS: Luigi had copies of some of my code well before I was > able to give copies of the coelescing code to FreeBSD; he > had previously signed a non-disclosure agreement which allowed > me to hand him a lot of code that I still have not handed to > others. It's no wonder that there is some overlap. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 27 12:40:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id DA66037B401 for ; Sat, 27 Oct 2001 12:40:29 -0700 (PDT) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id f9RJb0g81483; Sat, 27 Oct 2001 12:37:00 -0700 (PDT) (envelope-from rizzo) Date: Sat, 27 Oct 2001 12:37:00 -0700 From: Luigi Rizzo To: Terry Lambert Cc: Mike Silbersack , Alfred Perlstein , Soren Kristensen , net@FreeBSD.ORG Subject: Re: NEW CODE: polling support for device drivers. Message-ID: <20011027123700.C80606@iguana.aciri.org> References: <20011027044854.X88536-100000@achilles.silby.com> <3BDB033C.98ED2BDF@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BDB033C.98ED2BDF@mindspring.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org And a few more comments on the technical side: On Sat, Oct 27, 2001 at 11:55:56AM -0700, Terry Lambert wrote: ... > PPS: The polling support for device drivers was something I > had discussed with Bill Paul previously. He did not like > the idea of externalizing the entry points for the tx_eof > and rx_eof routines, as it changed the interface, and not > all cards were capable of supporting it, anyway. If you look at the code i posted, what i did to make the architecture sufficiently general was to make polling-aware driver register a single callback, XX_poll(), at the first useful invocation of XX_intr() (this can be made slightly more efficient by using a macro instead of a function for the registering -- but you get the idea). XX_poll() is then invoked with a "count" argument, which is proportional to the amount of resources (typically packet served, or CPU cycles) that the driver is supposed to spend before returning. The beauty of this approach is that the binary interface for the driver does not change, and you can adapt XX_poll() to what the card is actually able to do. It is responsibility of the programmer to code XX_poll() in a sensible way. Typically, the thing you do is to fetch at most "count" packets from the receive ring (because those mean more work for the router), and process most or all pending tx_eof() events and possibly move a larger chunk of packets from ifq_snd to the transmit ring (because this means finalising work already done and freeing resources). The diffs for if_fxp.c and if_dc.c to implement fxp_poll and dc_poll are quite small indeed, and turned out to be rather mechanical. I guess this comes from well designed drivers. > PPPS: A more correct implementation of polling would probably > be implemented using opportunistic timers; due to an office it might be Mohit Aaron's work at RICE ? Anyways, i am not totally sure that opportunistic timers are really necessary, because you probably want some kind of guarantee on your forwarding rate, and this can only be achieved by a fixed timer rate. And it does not make much sense not to poll whenever you have a chance to, because you either have nothing to do (in which case polling costs little more than a function call and a bunch of memory accesses), or you have packets to forward and then you don't want to delay them further. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 27 12:54:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 69D1E37B401 for ; Sat, 27 Oct 2001 12:54:27 -0700 (PDT) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id f9RJp2j81585; Sat, 27 Oct 2001 12:51:02 -0700 (PDT) (envelope-from rizzo) Date: Sat, 27 Oct 2001 12:51:02 -0700 From: Luigi Rizzo To: net@FreeBSD.ORG Subject: Polling vs Interrupts (was Re: NEW CODE: polling support...) Message-ID: <20011027125102.E80606@iguana.aciri.org> References: <20011027005905.A72758@iguana.aciri.org> <3BDA73C0.73DBCAE9@soekris.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BDA73C0.73DBCAE9@soekris.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As the topic came out, i thought it would be useful to pass around a short discussion on the performance implications of interrupts and polling. In addition to the code that i already posted and which implements polling as discussed in Sec.4 below, I have another set of patches to implement device-independent interrupt mitigation as discussed near the end of Sec.3, and am finishing up some other code that lets you say "i want to reserve XX percent of the CPU to device drivers" and dynamically adapt the polling "counts" to match the requirements. cheers luigi [DISCLAIMER: what follows reflects my view of the world, and it is mostly well known stuff, documented for a long time in the literature. I am sure others have already implemented some or all or more of this, I am not claiming paternity on any of these ideas.] === Polling versus Interrupts in (network) device drivers === 1. BASIC OPERATION OF INTERRUPT Typical network device drivers use interrupts to let the network controller (NIC) communicate with the operating system: when some interesting event occurs, the NIC generates an interrupt request which is dispatched to the processor through the interrupt controller. This in turn causes the execution of a short piece of code (typically written in assembler) which in the end invokes the interrupt service routines (ISR's) for all the devices sharnig the same interrupt line. The ISR, which is typically a C function part of the device driver, say XX_intr(), normally does the following: for (;;) { if (no interrupts pending) break; } The cost of getting and servicing an interrupt is made of the following components: + hardware and software context switch + software overhead to access the interrupt controller and dispatch the request to the appropriate ISR + time spent in each of the XX_intr() associated to the physical interrupt line. The first two components can take anywhere from 1 to 20us depending on your system. These times are relatively constant, irrespective of the system load. The cost of the last component is largely variable and unpredictable, as we will see below. At low load levels (incoming packet rates), a good fraction of the interrupt cost is actually the overhead for context switch and dispatch, but this is not something to worry about, because there is enough CPU to serve all the interrupts you get. Even at 10000 packets per second, a state-of-the art CPU may spend some 5-10% of its time in overhead. 2. THE CPU BOTTLENECK As the load level increases, your interrupt rate also grows, and so does the work that you perform in each call to XX_intr(). The increase in interrupt rate is dangerous because it can make you waste a large fraction of your CPU cycles just in overhead and context switches, leading to a steep drop of the forwarding rate as the offered load increases. The growth in interrupt rate is typically sublinear in the incoming packet rate, because as the latter increases, it becomes more and more likely that you get to process a second packet before you can complete the interrupt service routine. This might seem a good thing; but unfortunately, there migth be a third packet, and a fourth, and a fifth... and so you might remain within your interrupt service routine for a very large amount of time (potentially unbounded). This is what makes the system unresponsive under load, and prevents a fair sharing of resources among devices. This regime, where you spend all of your time servicing interrupts, and not having time to do work outside the interrupt context, is often referred to as livelock. Depending on how processing is done, you might end up with some work done even in this situation, but the situation is far from being ideal. It would seem that a way to make the system more responsive (or at least, achieve better sharing of CPU time among devices) is to limit the amount of time you spend in each invocation of the interrupt service routine. Unfortunately, in an interrupt-based system, before you return from the handler you are forced to acknowledge the interrupt (typically write into the status register) and process all events that might have triggered it -- if you stop early, there might not be another interrupt that wakes you up to continue the leftover work, so you have to set a timeout by independent means, or resort to polling. (There are workarounds, but they involve not acknowledging interrupts in the ISR, which translates in new requests being generated immediately after the ISR returns. So, these can solve the fairness problem but not the responsiveness problem). So, to summarise, interrupt-based systems can be subject, under load, to high overhead; low responsiveness; and unfairness. 3. INTERRUPT MITIGATION A technique that can be used to reduce the overhead (but not to improve responsiveness or fairness) is to implement some form of "interrupt coalescing" or "interrupt mitigation": generate an interrupt only after a sufficient delay from the previous one, and/or after a minimum number of packets have arrived. The tty drivers in unix have done this for a long time. Some NICs can do interrupt mitigation by themselves -- e.g. the 21143 has a register where you can program timeout and count; the i82558 apparently can download microcode to do the same, and from my experiments, some Tulip-clones also appear to have a minimum delay between interrupts which is larger than the minimum packet interarrival time. In general, interrupt mitigation is almost a must for high speed devices. If the NIC cannot do interrupt mitigation, it is possible to simulate it in software as follows: the low level interrupt service routines (those who ultimately invoke XX_intr()) keep track of how many times a given interrupt has been generated in the last tick. When the number is above a threshold, that interrupt line is kept masked on the interrupt controller until the next clock tick. This does not require any support in the hardware or in the driver, but as a drawback, it might add some additional latency (up to 1 tick) in the response to the interrupt, for all the device sharing the same line. 4. THE BUS BOTTLENECK As the incomnig packet rate increases even further, you are likely to hit another bottleneck, which may even kick in before the CPU bottleneck: this is the bus bandwidth. The raw bandwidth of a PCI bus (33MHz, 32bit) is slightly above 1Gbit/s, and 4Gbit/s for a fast PCI bus (66MHz, 64bit). However this is only the raw bandwidth -- each transaction on the bus consumes a minimum of 4 (or is it 3?) cycles, plus an additional cycle per word. A typical network controller acting as a bus master, has to perform the following operatios on each received packet: + read the descriptor for the memory buffer + write the packet to memory + write the descriptor to memory (this might be a read-modify-write cycle); For short packets (64 bytes) the overhead can easily reduce the useful bandwidth to half of the theoretical maximum, or even less. On top of this you have to consider that forwarding a packet from one interface to another requires the payload to cross the bus twice. In order to offload some work from the CPU, some controllers autonomously poll descriptors in memory to check if there are more packets to transmit, or new receive descriptors are available for incoming packet. This helps the CPU, but generates even more traffic on the bus, further reducing its capacity to transfer data. Once the PCI bus becomes congested, it behaves exactly the same as a congested network link: those units (CPU, NICs or other devices on the bus) willing to access the bus might experience long delays waiting for it to be available. The actual wait times depend on the load of the bus, on the number of devices conflicting for access, and on the arbitration algorithm used to grant access to the bus itself. As an example, for a simple I/O read from a register on a PCI card, I have often measured times as high as 10,000 clock cycles (for our 750MHz host, this is over 10us) during which the CPU cannot do anything. Unfortunately, this time is totally unpredictable, and the CPU has no way to abort the transaction once started. To understand the impact of this, consider that an interrupt service routine typically needs to access the status register on the NIC at least 3 times (first one to fetch the status, second one to clear it, third one to make sure that there are no other pending interrupts), so you can easily see how bad this can become. 4. POLLING Polling works by disabling interrupts in the card, and in their place letting the operating system poll the status of the card when it finds it convenient. This can happen e.g. once per timer tick, in the idle loop, and when the kernel gets control because of a software interrupt. This helps because of two reasons. First of all, the amount of work that can be performed in the poll call can be easily controlled. There is no need to process all events to completion, because further events can be processed in the next poll call. This also means that, when resources are scarce, the system can postpone processing, and possibly let the hardware drop excessive incoming traffic (that would be dropped anyways by the software) with no overhead. Secondly, the poll routine does not always need to check status registers for all events. Some information (e.g. packet received or transmitted) is already available in main memory, within the buffer descriptor, so the polling does not cause further contention on the PCI bus and has a more predictable cost. Of course, every now and then you have to access the status registers to test for events that are only reported there (e.g. running out of buffers, or error conditions, etc.) but that can be done sufficiently rarely not to cause a significant additional overhead and/or contention. The drawbacks of polling are quite obvious: because you do not have an instantaneous notification of the events you are interested in, there might be some delay before you get a chance to process the events. This delay is normally limited to one clock tick (so it can be easily as low as 1ms or less), and in practice can be even more limited when your system is not heavily loaded and you poll the devices more frequently than once per tick. On the plus side, by using polling you can easily control how much time you want to dedicate to the processing of I/O events, both globally and on an individual basis. This translates in more predictable, responsive and fair system behaviour. [THE END] ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message