From owner-freebsd-net Sun Oct 1 20:59: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from ns1.meltzer.org (ns1.meltzer.org [205.136.35.36]) by hub.freebsd.org (Postfix) with SMTP id D89BB37B502 for ; Sun, 1 Oct 2000 20:59:04 -0700 (PDT) Received: (qmail 28401 invoked by uid 0); 2 Oct 2000 03:54:50 -0000 Received: from ns1.meltzer.org (meltzer@205.136.35.36) by ns1.meltzer.org with SMTP; 2 Oct 2000 03:54:50 -0000 Date: Sun, 1 Oct 2000 23:54:50 -0400 (EDT) From: Jeffrey Meltzer X-Sender: meltzer@ns1.meltzer.org To: freebsd-net@freebsd.org Subject: GRE Tunnels Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I'm attempting to get a GRE Tunnel going between a Cisco 7206 and a FreeBSD 4.1 box. It seems to come up for about 15 seconds, but then I see... ping: sendto: No buffer space available I've raised the maxusers to 64 and the MSGBUF_SIZE to 81920 Anybody have any other ideas as to what I could try? Thanks! Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 1:33:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by hub.freebsd.org (Postfix) with ESMTP id 6F83F37B66D; Mon, 2 Oct 2000 01:33:40 -0700 (PDT) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JUUX5JOVJS000LV1@research.kpn.com>; Mon, 2 Oct 2000 10:33:34 +0200 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Mon, 02 Oct 2000 10:33:33 +0100 Content-return: allowed Date: Mon, 02 Oct 2000 10:33:32 +0100 From: "Steehouder, R.J." Subject: IPv6 Firewall problem (with solution) To: "'freebsd-net@freebsd.org'" , "'freebsd-ipfw@freebsd.org'" Message-id: <59063B5B4D98D311BC0D0001FA7E45220369D2CB@l04.research.kpn.com> 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 X-Loop: FreeBSD.org Sorry if this is sightly off topic, but there is no FreeBSD-IPv6 mailing list that I know of. I have stumbled upon the following: The IPv6 firewall and IPv6 neighbor discovery don't work well together. In the system depicted below, Tembo acts as a firewall and gateway for Kima. Target is to only let traffic between Twiga and Kima through. +--+ +--+ +--+ | |-----+---| |---------| | +--+ | +--+ +--+ Twiga | Tembo Kima | +--+ Simba | |----(Internet / 6Bone / etc.) +--+ Twiga: FreeBSD 4.1-RELEASE Kima: Windows 2000 Tembo: FreeBSD 4.x-STABLE Simba: SISCO Router All network connections are IPv6. Simba is default router in the left network, Tembo in the right one. Firewall rules on Tembo: # link-local addresses add allow all from fe80::/64 to fe80::/64 # link-local multicast addresses add allow all from any to ff00::/12 # Twiga <-> Kima add allow all from Kima to Twiga add allow all from Twiga to Kima Problem: Some time after installing these rules, communication between Kima and Twiga stops. Why? Because neighbor discovery tells Tembo that Kima is no longer there (due to firewall restrictions Tembo cannot communicate with Kima using global addresses). Kima is therefore removed from the routing table and traffic stops. Solution Allow communications between Kima and Tembo: allow all from Kima to Tembo allow all from Tembo to Kima Using a static routes instead should work as well, but then what's the point of using autoconfiguration in IPv6. Between Tembo and Twiga this does not pose a problem, because there is a route via Simba (using Simba's link-local address). Simba is known, because of its router sollicitation messages on ff02:: multicast addresses. Twiga should also lose contact with Tembo (neighbor discovery fails), but since Simba has a static route to Tembo, it doesn't mind. Opening up the firewall/gateway to the networks poses a security risk. Maybe this situation should be documented somewhere in the firewall documentation? (If only to show people how to solve this problem when they get to it.) If anyone knows a better solution (one that doesn't expose the firewall), please tell me. Rogier Steehouder Stagiair KPN Research mailto:r.j.steehouder@kpn.com (If it bounces, try mailto:r.j.steehouder@student.utwente.nl) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 6:49: 0 2000 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 0BE3437B66C for ; Mon, 2 Oct 2000 06:48:58 -0700 (PDT) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id GAA36775 for ; Mon, 2 Oct 2000 06:48:54 -0700 (PDT) Date: Mon, 2 Oct 2000 06:48:53 -0700 (PDT) From: Julian Elischer To: net@freebsd.org Subject: SACK in FreeBSD TCP. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is anyone working on a SACK (Selective acknowlegement) implementation for FreeBSD? (rfc 2018) It would make a huge difference to performance out here at the edge of the univertse (Perth, Western Australia) julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 6:53:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id A8AF537B502 for ; Mon, 2 Oct 2000 06:53:16 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id PAA47114; Mon, 2 Oct 2000 15:53:30 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200010021353.PAA47114@info.iet.unipi.it> Subject: Re: SACK in FreeBSD TCP. In-Reply-To: from Julian Elischer at "Oct 2, 2000 06:48:53 am" To: Julian Elischer Date: Mon, 2 Oct 2000 15:53:30 +0200 (CEST) Cc: net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Is anyone working on a SACK (Selective acknowlegement) implementation > for FreeBSD? > > (rfc 2018) > > It would make a huge difference to performance out here at the edge of the > univertse (Perth, Western Australia) I wonder if the "huge difference" is for real or just a myth. When i did some work on sack back in 1996 (including a FreeBSD implementation, see http://www.iet.unipi.it/~luigi/sack.html I did not find that SACK to be such a panacea. Basically, most connections under high loss still had a tendency to stall because the window would never open enough to have 3dupacks which would trigger a retransmission... cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 6:58:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id A3CBD37B502 for ; Mon, 2 Oct 2000 06:58:47 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id e92DwbA14157; Mon, 2 Oct 2000 08:58:37 -0500 (CDT) (envelope-from jlemon) Date: Mon, 2 Oct 2000 08:58:37 -0500 (CDT) From: Jonathan Lemon Message-Id: <200010021358.e92DwbA14157@prism.flugsvamp.com> To: julian@elischer.org, net@freebsd.org Subject: Re: SACK in FreeBSD TCP. X-Newsgroups: local.mail.freebsd-net In-Reply-To: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: >Is anyone working on a SACK (Selective acknowlegement) implementation >for FreeBSD? I believe that Jayanth was working on it at one time, you could ask him. >It would make a huge difference to performance out here at the edge of the >univertse (Perth, Western Australia) That's what all the Australians I know claim. But is there any hard data to back that up as well? (E.g.: does Linux perform better out there?) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 7: 8:59 2000 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 2F21637B503 for ; Mon, 2 Oct 2000 07:08:56 -0700 (PDT) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id HAA36865; Mon, 2 Oct 2000 07:08:54 -0700 (PDT) Date: Mon, 2 Oct 2000 07:08:53 -0700 (PDT) From: Julian Elischer To: Jonathan Lemon Cc: net@freebsd.org Subject: Re: SACK in FreeBSD TCP. In-Reply-To: <200010021358.e92DwbA14157@prism.flugsvamp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well I just look at the data flowing... we lose bursts of packets out of a single window, and of course then we get teh entire window retransmitted... because of the long RT delay, the entire retransmitted window arrives before the ack we send to say "hey we got it all now" gets to the server in the US.. (I have both ends of this transmittion so I can see that it is happenning....) (tcpdump is your friend). Of course this etra stuff queues up on the far end of my modem link and forces packets from teh NEXT window to get dropped..... Once the error rate drops below 1 packet lost for 20 or so transmitted, I start to get some data through but below that ( most of the time) I get about 500 bytes/sec throughput.. (FBSD<-> FBSD) Julian On Mon, 2 Oct 2000, Jonathan Lemon wrote: > In article you write: > >Is anyone working on a SACK (Selective acknowlegement) implementation > >for FreeBSD? > > I believe that Jayanth was working on it at one time, you could ask him. > > > >It would make a huge difference to performance out here at the edge of the > >univertse (Perth, Western Australia) > > That's what all the Australians I know claim. But is there any hard > data to back that up as well? (E.g.: does Linux perform better out > there?) > -- > Jonathan > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 7:33:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by hub.freebsd.org (Postfix) with ESMTP id DB20D37B502 for ; Mon, 2 Oct 2000 07:33:14 -0700 (PDT) Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.10.1/8.10.1) with ESMTP id e92EX6r15583; Mon, 2 Oct 2000 07:33:06 -0700 (PDT) Message-Id: <200010021433.e92EX6r15583@ptavv.es.net> To: Jonathan Lemon Cc: julian@elischer.org, net@FreeBSD.ORG Subject: Re: SACK in FreeBSD TCP. In-reply-to: Your message of "Mon, 02 Oct 2000 08:58:37 CDT." <200010021358.e92DwbA14157@prism.flugsvamp.com> Date: Mon, 02 Oct 2000 07:33:06 -0700 From: "Kevin Oberman" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I can't comment on what the symptoms are in Oz, but testing on very large streams done last year by ESnet, Lawrence Berkeley National Laboratory, and Argonne National Laboratory made it painfully obvious that trying to run a single TCP stream of over 200 Mbps between Chicago and California was impossible without SACK. It does require many other things, like very large windows and fast recovery, but without SACK it's hopeless. In our testing we used Solaris and Tru64 UNIX, but FreeBSD was not an option because of the lack of SACK. As a strong proponent of FreeBSD and the FreeBSD network stack in particular, this was a bit painful to me. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 7:38: 4 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id CAB0A37B502 for ; Mon, 2 Oct 2000 07:37:59 -0700 (PDT) Received: from popserver-02.iinet.net.au (popserver-02.iinet.net.au [203.59.24.148]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id WAA18152; Mon, 2 Oct 2000 22:37:52 +0800 Received: from elischer.org (reggae-39-206.nv.iinet.net.au [203.59.173.206]) by popserver-02.iinet.net.au (8.9.3/8.9.3) with ESMTP id WAA22491; Mon, 2 Oct 2000 22:37:42 +0800 Message-ID: <39D89D9D.5BB9508C@elischer.org> Date: Mon, 02 Oct 2000 07:37:17 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: SACK in FreeBSD TCP. References: <200010021353.PAA47114@info.iet.unipi.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo wrote: > > > Is anyone working on a SACK (Selective acknowlegement) implementation > > for FreeBSD? > > > > (rfc 2018) > > > > It would make a huge difference to performance out here at the edge of the > > univertse (Perth, Western Australia) > > I wonder if the "huge difference" is for real or just a myth. > > When i did some work on sack back in 1996 (including a FreeBSD > implementation, see http://www.iet.unipi.it/~luigi/sack.html great.. I'll look at that.. Julian > I did not find that SACK to be such a panacea. Basically, > most connections under high loss still had a tendency to > stall because the window would never open enough to have 3dupacks > which would trigger a retransmission... > > cheers > luigi > -----------------------------------+------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > Mobile +39-347-0373137 > -----------------------------------+------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 7:39:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 36F0D37B502 for ; Mon, 2 Oct 2000 07:39:14 -0700 (PDT) Received: from popserver-02.iinet.net.au (popserver-02.iinet.net.au [203.59.24.148]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id WAA18320; Mon, 2 Oct 2000 22:39:10 +0800 Received: from elischer.org (reggae-39-206.nv.iinet.net.au [203.59.173.206]) by popserver-02.iinet.net.au (8.9.3/8.9.3) with ESMTP id WAA22584; Mon, 2 Oct 2000 22:38:59 +0800 Message-ID: <39D89DEB.956C1E21@elischer.org> Date: Mon, 02 Oct 2000 07:38:35 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lemon Cc: net@freebsd.org Subject: Re: SACK in FreeBSD TCP. References: <200010021358.e92DwbA14157@prism.flugsvamp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jonathan Lemon wrote: > > In article you write: > >Is anyone working on a SACK (Selective acknowlegement) implementation > >for FreeBSD? > > I believe that Jayanth was working on it at one time, you could ask him. > > >It would make a huge difference to performance out here at the edge of the > >univertse (Perth, Western Australia) > > That's what all the Australians I know claim. But is there any hard > data to back that up as well? (E.g.: does Linux perform better out So the Linux types say, but of course that's not actual proof af anything.. > there?) > -- > Jonathan > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 9: 6:20 2000 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id D7B1337B503 for ; Mon, 2 Oct 2000 09:06:17 -0700 (PDT) Received: (qmail 29832 invoked by uid 1000); 2 Oct 2000 16:07:27 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Oct 2000 16:07:27 -0000 Date: Mon, 2 Oct 2000 11:07:27 -0500 (CDT) From: Mike Silbersack To: Julian Elischer Cc: net@freebsd.org Subject: Re: SACK in FreeBSD TCP. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 2 Oct 2000, Julian Elischer wrote: > Is anyone working on a SACK (Selective acknowlegement) implementation > for FreeBSD? > > (rfc 2018) > > It would make a huge difference to performance out here at the edge of the > univertse (Perth, Western Australia) > > > julian Out of curiosity, if you're using 5.x on both ends, how much does newreno help? 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 2 11: 4:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from virtual.sysadmin-inc.com (lists.sysadmin-inc.com [209.16.228.140]) by hub.freebsd.org (Postfix) with ESMTP id 5F6D037B503 for ; Mon, 2 Oct 2000 11:04:54 -0700 (PDT) Received: from 98sas ([10.10.1.71]) by virtual.sysadmin-inc.com (8.9.1/8.9.1) with SMTP id OAA21806 for ; Mon, 2 Oct 2000 14:07:27 -0400 Reply-To: From: "Peter Brezny" To: Subject: IP sec and lan to lan vpn over internet vs mpd-netgraph and lan to lan vpn over internet Date: Mon, 2 Oct 2000 14:05:25 -0400 Message-ID: <000801c02c9b$57bb0040$47010a0a@fire.sysadmininc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is it possible to use ipsec to create a lan to lan vpn over the internet similar to the way the mpd-netgraph port can? if so, what are the advantages of ipsec or mpd-netgraph? Thanks, Peter Brezny SysAdmin Services, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 16:36:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 624B837B502 for ; Mon, 2 Oct 2000 16:36:40 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.0/8.11.0) with ESMTP id e92NUda76955; Tue, 3 Oct 2000 00:30:39 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.1/8.11.0) with ESMTP id e92NT9n37409; Tue, 3 Oct 2000 00:29:09 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200010022329.e92NT9n37409@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Julian Elischer Cc: Patrick Bihan-Faou , freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: natd and userland ppp In-Reply-To: Message from Julian Elischer of "Wed, 27 Sep 2000 10:26:16 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Oct 2000 00:29:09 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > It seems also that some features (such as automatic holes in the firewall > > and dynamic rules) are a bit tricky to get working properly with aliasing in > > ppp. Now I probably missed some tricks on that side, so don't flame me > > because of that last comment, educate me! > > > I'm not an expert on PPP's filtering rules.. I'll let Brian answer that.. The firewall punching stuff is done internally in libalias, so there's no code duplication there. I think there's probably room for some sort of ascii interface to libalias though, including (at least) the natd configuration file parser. That way ppp could allow ``nat config /etc/natd.conf'' and could have a generally more compatible (with natd) interface. > > Well actually, with the "dynamic" option in natd, synchronizing to ppp is > > really painless (or at least it looks like it is working properly). Thanks > > to the magic of the routing socket. So this is hardly an argument. > > > well, yes it works.. > I'm not totally sure though if you can do everything quite the same. One of the more impressive things it can't do is the ``iface-alias'' stuff. This is where ppp keeps the old IP number as an interface alias, natting already-bound local sockets. This makes the first-connection problem go away (see the FAQ). > > > Mpd can use netgraph to do all ppp processing in the kernel to reduce > > > latency even further, but it doesn't have NAT. You could however combine > > > it with ipfilter's in-kernel NAT to get an all-kernel solution. > > > (we need to make a netgraph NAT module but we haven't done it yet.) > > > > A netgraph nat module seems to be the way to go... As soon as I have some > > spare time (wishfull thinking :) I'll look into that. > > > yes I actually was considering using the NAT code from ipfilter > to do the job.. > the difficulty is deciding exactly wherre and how to slot a NAT module > in.. > > if it were attached to an interface, then it would have to know about > both IP and the MAC levels which would break layering. If it's attached to > the IP stack (where ipfw presently gets packets for NAT from) then > it loses some of the niceness of attaching it to an interface. > > Maybe it's not really a job for netgraph but a job for an IPFW > keyword/Module. (then in that case we should look at ipfilter > again as it isn't going away..) > Personally I'd like a way of attaching a netgraph node between IP and the > various interfaces. (I think this could be achieved by > using the netgraph interface node as a frontend to the actual interfaces > and not assigning IP addresses to the real interfaces you wanted to > do NAT on, but instead assign those addresses to teh ng interfaces.. > > (hmmmm maybe..) ppp does the libalias stuff at the top of it's stack. From physical.c: void physical_SetupStack(struct physical *p, const char *who, int how) { link_EmptyStack(&p->link); if (how == PHYSICAL_FORCE_SYNC || how == PHYSICAL_FORCE_SYNCNOACF || (how == PHYSICAL_NOFORCE && physical_IsSync(p))) link_Stack(&p->link, &synclayer); else { link_Stack(&p->link, &asynclayer); link_Stack(&p->link, &hdlclayer); } if (how != PHYSICAL_FORCE_SYNCNOACF) link_Stack(&p->link, &acflayer); link_Stack(&p->link, &protolayer); link_Stack(&p->link, &lqrlayer); link_Stack(&p->link, &ccplayer); link_Stack(&p->link, &vjlayer); #ifndef NONAT link_Stack(&p->link, &natlayer); #endif ....... The NAT has to happen there because of all the compression and other mucking about. Eventually (I say after having done nothing about this in the last year), I would like to convert each of the above layers into a module that will compile either as a lump of userland code or as some sort of netgraph kld plugin.... the idea being that ppp can decide at run time whether it'll use kernel or userland functionality, getting the same results either way. The approach would be that if the user doesn't specify what they want, they probably want everything in the kernel. If everything can't be implemented in the kernel, then as much as possible should be implemented outside of the kernel. Some day, I'll get some time to do this stuff.... -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 16:39:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail9.bigmailbox.com (mail9.bigmailbox.com [209.132.220.40]) by hub.freebsd.org (Postfix) with ESMTP id CB7E137B503 for ; Mon, 2 Oct 2000 16:39:25 -0700 (PDT) Received: œby mail9.bigmailbox.com (8.8.7/8.8.7) id QAA07185; Mon, 2 Oct 2000 16:44:28 -0700 Date: Mon, 2 Oct 2000 16:44:28 -0700 Message-Id: <200010022344.QAA07185@mail9.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: [63.28.163.128] From: "gummibear@nettaxi.com" To: net@freebsd.org Subject: xl0 error message help needed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm not sure what this means, perhaps someone can explain it to me. Oct 2 14:30:16 ns /kernel: xl0: transmission error: 90 Oct 2 14:30:16 ns /kernel: xl0: tx underrun, increasing tx start threshold to 120 bytes Thanks!! Joey ------------------------------------------------------------ Nettaxi MP3 Player, Burner, Ripper - NEW Version 2.0!!! DOWNLOAD IT FREE! (5MBs) MP3 DOWNLOAD: http://www.nettaxi.com/mp3/version_2/ntxy_MP3_setup.exe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 17: 5: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from xena.gsicomp.on.ca (cr677933-a.ktchnr1.on.wave.home.com [24.42.130.87]) by hub.freebsd.org (Postfix) with ESMTP id CF65C37B502 for ; Mon, 2 Oct 2000 17:04:54 -0700 (PDT) Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.10.1/8.9.2) with SMTP id e93046s97854; Mon, 2 Oct 2000 20:04:07 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <001101c02ccd$c1e96470$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Julian Elischer" , "Brian Somers" Cc: "Patrick Bihan-Faou" , , References: <200010022329.e92NT9n37409@hak.lan.Awfulhak.org> Subject: Re: natd and userland ppp Date: Mon, 2 Oct 2000 20:05:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > It seems also that some features (such as automatic holes in the firewall > > > and dynamic rules) are a bit tricky to get working properly with aliasing in > > > ppp. Now I probably missed some tricks on that side, so don't flame me > > > because of that last comment, educate me! > > > > > > I'm not an expert on PPP's filtering rules.. I'll let Brian answer that.. > > The firewall punching stuff is done internally in libalias, so > there's no code duplication there. > > I think there's probably room for some sort of ascii interface to > libalias though, including (at least) the natd configuration file > parser. That way ppp could allow ``nat config /etc/natd.conf'' and > could have a generally more compatible (with natd) interface. And just in case anyone was wondering, I am currently working on a ``nat config '' feature for ppp. I'm just taking lots of time determining the best way to do it, since there is a considerable amount of code from natd that needs to be added to ppp (in other words, the config file parser is around 25% of natd's total code.) -- Matthew Emmerton GSI Computer Services +1 (800) 217 5409 (Canada) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 20:53:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable140.61-201-24.mtl.mc.videotron.ca [24.201.61.140]) by hub.freebsd.org (Postfix) with SMTP id 6FF9537B503 for ; Mon, 2 Oct 2000 20:53:46 -0700 (PDT) Received: (qmail 31529 invoked from network); 3 Oct 2000 03:53:45 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 3 Oct 2000 03:53:45 -0000 Message-ID: <038501c02ced$99936960$040aa8c0@local.mindstep.com> From: "Patrick Bihan-Faou" To: References: <200010022329.e92NT9n37409@hak.lan.Awfulhak.org> <001101c02ccd$c1e96470$1200a8c0@gsicomp.on.ca> Subject: Re: natd and userland ppp Date: Mon, 2 Oct 2000 23:54:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > > I think there's probably room for some sort of ascii interface to > > libalias though, including (at least) the natd configuration file > > parser. That way ppp could allow ``nat config /etc/natd.conf'' and > > could have a generally more compatible (with natd) interface. > > And just in case anyone was wondering, I am currently working on a ``nat > config '' feature for ppp. I'm just taking lots of time > determining the best way to do it, since there is a considerable amount of > code from natd that needs to be added to ppp (in other words, the config > file parser is around 25% of natd's total code.) Ouch, that hurts... 25% code porting calls for drastic measures... It would definitely be nice to have the same code for these two tools. Maybe extending the library or creating a new one, I don't know. But if the code is not the same, there will be some divergence at some point and that will be painfull... There must be a better way (although I don't have the answer). Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 22: 5: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from xena.gsicomp.on.ca (cr677933-a.ktchnr1.on.wave.home.com [24.42.130.87]) by hub.freebsd.org (Postfix) with ESMTP id 4050737B503 for ; Mon, 2 Oct 2000 22:05:02 -0700 (PDT) Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.10.1/8.9.2) with SMTP id e9354xs98404; Tue, 3 Oct 2000 01:04:59 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <000a01c02cf7$c0cb0a10$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Patrick Bihan-Faou" , References: <200010022329.e92NT9n37409@hak.lan.Awfulhak.org> <001101c02ccd$c1e96470$1200a8c0@gsicomp.on.ca> <038501c02ced$99936960$040aa8c0@local.mindstep.com> Subject: Re: natd and userland ppp Date: Tue, 3 Oct 2000 01:06:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > I think there's probably room for some sort of ascii interface to > > > libalias though, including (at least) the natd configuration file > > > parser. That way ppp could allow ``nat config /etc/natd.conf'' and > > > could have a generally more compatible (with natd) interface. > > > > And just in case anyone was wondering, I am currently working on a ``nat > > config '' feature for ppp. I'm just taking lots of time > > determining the best way to do it, since there is a considerable amount of > > code from natd that needs to be added to ppp (in other words, the config > > file parser is around 25% of natd's total code.) > > Ouch, that hurts... > > 25% code porting calls for drastic measures... It would definitely be nice > to have the same code for these two tools. Maybe extending the library or > creating a new one, I don't know. But if the code is not the same, there > will be some divergence at some point and that will be painfull... There > must be a better way (although I don't have the answer). It's actually closer to 30% (gasp!). This is simply the code to parse configuration files (and command line arguments, which are essentially aliases for config file directives) and the data structures to support the parsing. The rest is just daemonizing code and wrappers around the functions in libalias. Due to the nature of this "common" code, I don't think it belongs in libalias, but since I don't forsee anything other than ppp requiring embedded nat capabilities (hmm, perhaps netgraph), I don't see the need for libnat on the horizon either. My current idea is to split out enough of the natd code into separate files so that the ppp code can just refer to a few source files from natd. This method comes with two main drawbacks -- the introduction of a source dependency across the usr.sbin and sbin source trees, as well as the need to make ppp and natd do option processing in similar fashions (which they don't really do right now.) Since I like the way natd's option processing is done now, I think that I'm going to be patching ppp to work with "the natd way" (subject to Brian's review, of course.) The only other option is to use netgraph. I'm thinking that a ng_nat module would eliminate some situations -- however the majority would be would be those requiring natd as a daemon (such as plain Ethernet or PPPoE) and not the nat-enabled user-ppp. -- Matthew Emmerton GSI Computer Services +1 (800) 217 5409 (Canada) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 22:35:10 2000 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 5800E37B502 for ; Mon, 2 Oct 2000 22:35:08 -0700 (PDT) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA40051; Mon, 2 Oct 2000 22:34:58 -0700 (PDT) Date: Mon, 2 Oct 2000 22:34:57 -0700 (PDT) From: Julian Elischer To: Brian Somers Cc: Patrick Bihan-Faou , freebsd-net@FreeBSD.ORG Subject: Re: natd and userland ppp In-Reply-To: <200010022329.e92NT9n37409@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 3 Oct 2000, Brian Somers wrote: > > The NAT has to happen there because of all the compression and other > mucking about. > > Eventually (I say after having done nothing about this in the last > year), I would like to convert each of the above layers into a module > that will compile either as a lump of userland code or as some sort of > netgraph kld plugin.... the idea being that ppp can decide at run > time whether it'll use kernel or userland functionality, getting the > same results either way. > > The approach would be that if the user doesn't specify what > they want, they probably want everything in the kernel. If > everything can't be implemented in the kernel, then as much as > possible should be implemented outside of the kernel. Some day, I'll > get some time to do this stuff.... > As discussed with you a year ago, teh netgraph code can now support 'stub' nodes, where the packet is passed to the node, which will examine it, maybe alter it, and pass it BACK.. (as opposed to forward.) (I believe this was on your 'wish list' Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 2 23: 2:35 2000 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 8487D37B66C for ; Mon, 2 Oct 2000 23:02:33 -0700 (PDT) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA40168; Mon, 2 Oct 2000 23:02:24 -0700 (PDT) Date: Mon, 2 Oct 2000 23:02:24 -0700 (PDT) From: Julian Elischer To: Matthew Emmerton Cc: Patrick Bihan-Faou , freebsd-net@FreeBSD.ORG Subject: Re: natd and userland ppp In-Reply-To: <000a01c02cf7$c0cb0a10$1200a8c0@gsicomp.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 3 Oct 2000, Matthew Emmerton wrote: > The only other option is to use netgraph. I'm thinking that a ng_nat module > would eliminate some situations -- however the majority would be would be > those requiring natd as a daemon (such as plain Ethernet or PPPoE) and not > the nat-enabled user-ppp. mpd uses all netgraph kernellevel processing for it's PPP (though is can do it itself if it needed to) It wouldn't take much to add a NAT module at the head of the chain.. for configuration We'd use the Netgraph ascii parser. I'd like to make an IPFW (or IPF) node as well but the difficult bit is working out exactly where to slot it in.. Basically it requires the ability to slot oneself just below the top interface of ANY network interface, (including lo, tun, ng, etc.) it might be a job more for ALTQ.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 3 7:38:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from lunatic.oneinsane.net (lunatic.oneinsane.net [207.113.133.231]) by hub.freebsd.org (Postfix) with ESMTP id E804E37B66D for ; Tue, 3 Oct 2000 07:38:49 -0700 (PDT) Received: by lunatic.oneinsane.net (Postfix, from userid 1000) id 5EB4215551; Tue, 3 Oct 2000 07:38:49 -0700 (PDT) Date: Tue, 3 Oct 2000 07:38:49 -0700 From: Ron 'The InSaNe One' Rosson To: freebsd-net@freebsd.org Subject: mpd and NAT Message-ID: <20001003073849.A42825@lunatic.oneinsane.net> Reply-To: Ron Rosson Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD lunatic.oneinsane.net 4.1-STABLE X-Moon: The Moon is Waxing Crescent (33% of Full) X-Opinion: What you read here is my IMHO X-WWW: http://www.oneinsane.net X-GPG-FINGERPRINT: 3F11 DB43 F080 C037 96F0 F8D3 5BD2 652B 171C 86DB X-Uptime: 7:24AM up 5 days, 8:46, 1 user, load averages: 0.08, 0.05, 0.01 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am working on a machine running FreeBSD 4.1-Release. It mission in life is to act as a gateway for a home network. The machine has 2 USR Couriers and a NIC card. I downloaded mpd-2.0b2 to handle the chores of getting the 2 USR's to dial and bond to the ISP. For starters I am just working with mpd and getting it configured to dial into the ISP. With the example in the sample (single modem) modified to dial into my ISP I get connected but am unable to ping my IP address or the IP address of the machine on the other end. Once I get this accomplished the final is to get both modems to dial using bandwidth allocation and dial-on-demand with the Ring back feature enabled. From what I have read it also looks that mpd has not NAT capabilities. I am assuming that I will have to accomplish this from NATD or IPFilters ipnat. Archie you did a hell of a job on mpd. TIA -- ------------------------------------------------------------------------------ Ron Rosson ... and a UNIX user said ... The InSaNe One rm -rf * insane@oneinsane.net and all was /dev/null and *void() ------------------------------------------------------------------------------ Loose bits sink chips. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 3 7:58:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 73FC837B502 for ; Tue, 3 Oct 2000 07:57:49 -0700 (PDT) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id WAA08247; Tue, 3 Oct 2000 22:57:32 +0800 Received: from elischer.org (reggae-34-48.nv.iinet.net.au [203.59.167.48]) by muzak.iinet.net.au (8.8.5/8.8.5) with ESMTP id WAA10531; Tue, 3 Oct 2000 22:57:11 +0800 Message-ID: <39D9F3AC.1C9A1F14@elischer.org> Date: Tue, 03 Oct 2000 07:56:44 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: net@freebsd.org Subject: Re: SACK in FreeBSD TCP. References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Silbersack wrote: > > On Mon, 2 Oct 2000, Julian Elischer wrote: > > > Is anyone working on a SACK (Selective acknowlegement) implementation > > for FreeBSD? > > > > (rfc 2018) > > > > It would make a huge difference to performance out here at the edge of the > > univertse (Perth, Western Australia) > > > > > > julian > > Out of curiosity, if you're using 5.x on both ends, how much does newreno > help? Unfortunatly I've got 3.2 on the other end and I can't change it a the moment. My guess is that it would solve about 70% of the problems I'm seeing. but SACK will nearly always do better than new-Reno.. it just needs more support as well. What I think would be really cool would be a Vegas/new-reno/SACK implementation! BTW looks like we have 2 FreeBSD-2.1 SACK implementations, and a netBSD VEGAS implementation. We already have new-reno of course. > > Mike "Silby" Silbersack > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 3 8:19:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from oden.exmandato.se (oden.exmandato.se [192.71.33.1]) by hub.freebsd.org (Postfix) with ESMTP id 7369C37B66C for ; Tue, 3 Oct 2000 08:19:43 -0700 (PDT) Received: from servicefactory.se (root@oden.exmandato.se [192.71.33.1]) by oden.exmandato.se (8.8.8/8.8.5) with ESMTP id RAA17029 for ; Tue, 3 Oct 2000 17:19:35 +0200 (MET DST) Message-ID: <39D9F906.E35FEE57@servicefactory.se> Date: Tue, 03 Oct 2000 17:19:34 +0200 From: Jonas Bulow X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.1.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: arp behaviour... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! I have an interface configured with two IP networks, let's say 10.1.0.0 and 10.2.0.0, like: exp1: flags=8963 link type ether 0:50:8b:df:bf:e2 mtu 1500 speed 100Mbps media 100baseTX full_duplex status active inet 10.1.0.1 netmask 255.255.0.0 broadcast 10.1.255.255 inet 10.2.0.1 netmask 255.255.0.0 broadcast 10.2.255.255 If I get an arp-request like: ARP: Who has 10.1.0.1? Tell 10.2.0.x i.e an arp-request crossing network boundary. How should a proper arp behave? Should the request be ignored? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 3 8:20:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 53D5A37B66C for ; Tue, 3 Oct 2000 08:20:34 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA40493; Tue, 3 Oct 2000 11:20:27 -0400 (EDT) (envelope-from wollman) Date: Tue, 3 Oct 2000 11:20:27 -0400 (EDT) From: Garrett Wollman Message-Id: <200010031520.LAA40493@khavrinen.lcs.mit.edu> To: Julian Elischer Cc: net@FreeBSD.ORG Subject: Re: SACK in FreeBSD TCP. In-Reply-To: <39D9F3AC.1C9A1F14@elischer.org> References: <39D9F3AC.1C9A1F14@elischer.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > What I think would be really cool would be a Vegas/new-reno/SACK > implementation! I'm not aware of anyone other than Larry Peterson who thinks that Vegas was correct, never mind a good idea to implement. -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 3 8:35:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 115E437B503 for ; Tue, 3 Oct 2000 08:35:32 -0700 (PDT) Received: (qmail 33433 invoked by uid 1000); 3 Oct 2000 15:36:42 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 3 Oct 2000 15:36:42 -0000 Date: Tue, 3 Oct 2000 10:36:42 -0500 (CDT) From: Mike Silbersack To: Julian Elischer Cc: net@freebsd.org Subject: Re: SACK in FreeBSD TCP. In-Reply-To: <39D9F3AC.1C9A1F14@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 3 Oct 2000, Julian Elischer wrote: > BTW looks like we have 2 FreeBSD-2.1 SACK implementations, and a netBSD > VEGAS implementation. We already have new-reno of course. OpenBSD has SACK implemented as well. It looks like it's on the third generation of fixes already, so I'm not sure if that means that it's stable code, or suspect code. Probably worth looking at as well, in any case. 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 Tue Oct 3 9: 8:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 1F04A37B66C for ; Tue, 3 Oct 2000 09:08:21 -0700 (PDT) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id AAA15711; Wed, 4 Oct 2000 00:08:03 +0800 Received: from elischer.org (reggae-34-48.nv.iinet.net.au [203.59.167.48]) by muzak.iinet.net.au (8.8.5/8.8.5) with ESMTP id AAA14328; Wed, 4 Oct 2000 00:08:01 +0800 Message-ID: <39DA0446.CDBB9B56@elischer.org> Date: Tue, 03 Oct 2000 09:07:34 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: net@FreeBSD.ORG Subject: Re: SACK in FreeBSD TCP. References: <39D9F3AC.1C9A1F14@elischer.org> <200010031520.LAA40493@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman wrote: > > < said: > > > What I think would be really cool would be a Vegas/new-reno/SACK > > implementation! > > I'm not aware of anyone other than Larry Peterson who thinks that > Vegas was correct, never mind a good idea to implement. In the past I had something to do with some systems that used "vegas-like" logic to try reduce losses. They worked quite well in low to medium loads and were neutral (as compared to dumber systems) in heavy congestion (where packet loss is unavaoidable). Certainly reno/tahoe are "criminally negligent" when it comes to losing packets that didn't need to be lost. New-reno, from looking at it might be a little better. Unfortunatly the logic used for Vegas is susceptible to network topology and load flucuations, but I found in practice that they work 'enough' to make them useful. The systems we used would reset themselves back to default "dumb" behaviour if it looked as if the network was too unstable to try use vegas-like "prediction". In particular when competing with many streams of beligerent stacks (e.g. tahoe/reno) the ability to measure the aproach of an impending packet loss was less sure, and the loss of a packet might not be avoided by backing off anyway as the load is probably coming from somewhere else. We found however that even in this case it rarely performed WORSE than the dumb stack. I think that addition of SACK would aid greatly in cases of heavy load/loss and Vegas would assist in light to medium loads. In each case the change doesn't negatively (in our experience) the behaviour in the case where it is not useful. > > -GAWollman -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 3 9:17:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 820E437B502 for ; Tue, 3 Oct 2000 09:17:32 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id MAA41267; Tue, 3 Oct 2000 12:17:28 -0400 (EDT) (envelope-from wollman) Date: Tue, 3 Oct 2000 12:17:28 -0400 (EDT) From: Garrett Wollman Message-Id: <200010031617.MAA41267@khavrinen.lcs.mit.edu> To: Julian Elischer Cc: net@FreeBSD.ORG Subject: Re: SACK in FreeBSD TCP. In-Reply-To: <39DA0446.CDBB9B56@elischer.org> References: <39D9F3AC.1C9A1F14@elischer.org> <200010031520.LAA40493@khavrinen.lcs.mit.edu> <39DA0446.CDBB9B56@elischer.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > In the past I had something to do with some systems that used > "vegas-like" The bug in Vegas was that it broke congestion control. -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 3 10:27:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from server.osny.com.br (osny.com.br [200.215.110.57]) by hub.freebsd.org (Postfix) with ESMTP id 7272A37B66D for ; Tue, 3 Oct 2000 10:27:30 -0700 (PDT) Received: from osny.com.br ([172.20.185.22]) by server.osny.com.br (8.10.1/8.10.1) with ESMTP id e93HSuZ00229 for ; Tue, 3 Oct 2000 15:29:03 -0200 (EDT) Message-ID: <39D9EE22.70EE4684@osny.com.br> Date: Tue, 03 Oct 2000 14:33:06 +0000 From: Michelangelo Pisa Organization: Agencia Maritima Osny X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: free inglish Subject: Procmail Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hello!! I'm trying to use the Procmail-3.13.1 in the FreeBSD 2.2.7 to filter e-mails with virus, but when I use the following configuration in my sendmail.cf: Mprocmail, P=/usr/bin/procmail, F=DFMmShu, S=11/31, R=21/31, T=DNS/RFC822/X-Unix, A=procmail -m MAIL_FROM="$_" MAIL_TO="$u" $h In the initialization of the system shown me errors how: invalide rewrite line (tab expected) Everybody with relation the sintaxe up... Somebody know is it? thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 3 10:53:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id CCB0237B502 for ; Tue, 3 Oct 2000 10:53:53 -0700 (PDT) Received: from elischer.org (reggae-34-48.nv.iinet.net.au [203.59.167.48]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id BAA22863; Wed, 4 Oct 2000 01:53:13 +0800 Message-ID: <39DA1CEE.ADCEA934@elischer.org> Date: Tue, 03 Oct 2000 10:52:46 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman , net@freebsd.org Subject: ETH =?iso-8859-15?Q?Z=FCrich=2FComputer=20Science=2FJ=FCrg?= Bolliger Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman wrote: > > < said: > > > In the past I had something to do with some systems that used > > "vegas-like" > > The bug in Vegas was that it broke congestion control. > > -GAWollman check out the first article on this page .. http://www.cs.inf.ethz.ch/~bolliger/ for an interesting analysis.... Unfortunatly New-reno was not in the comparison, but your suggestion that Vegas broke congestion control is not 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 3 11:30:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 7F54537B502 for ; Tue, 3 Oct 2000 11:29:58 -0700 (PDT) Received: from elischer.org (reggae-34-48.nv.iinet.net.au [203.59.167.48]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id CAA25185; Wed, 4 Oct 2000 02:29:28 +0800 Message-ID: <39DA256D.8077E698@elischer.org> Date: Tue, 03 Oct 2000 11:29:01 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman , net@freebsd.org Subject: Re: SACK in FreeBSD TCP. References: <39DA1CEE.ADCEA934@elischer.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman wrote: > > < said: > > > In the past I had something to do with some systems that used > > "vegas-like" > > The bug in Vegas was that it broke congestion control. > > -GAWollman check out the first article on this page .. http://www.cs.inf.ethz.ch/~bolliger/ for an interesting analysis.... Unfortunatly New-reno was not in the comparison, but your suggestion that Vegas broke congestion control is not supported. Another more relevant reference is the LINUX Vegas page: http://www.cs.washington.edu/homes/cardwell/linux-vegas/ They have quite a few results there... Most interesting is the comment that SACK can also produce the same gain, and that SACK+Vegas gives littel extra gain. However for Non-SACK clients, Vegas can give good results without relying on the client to upgrade.. Also they point out that Vegas is a better net-citizen in that it tends to use up less buffers in routers in the cloud. Anyway It looks like there are definitly lots of improvements we can still make.. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 3 23:30:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from picalon.gun.de (picalon.gun.de [192.109.159.1]) by hub.freebsd.org (Postfix) with ESMTP id CF7C437B502 for ; Tue, 3 Oct 2000 23:30:52 -0700 (PDT) Received: (from uucp@localhost) by picalon.gun.de (8.9.3/8.9.3) id IAA01290; Wed, 4 Oct 2000 08:30:18 +0200 (MET DST) >Received: (from andreas@localhost) by klemm.gtn.com (8.11.0/8.11.0) id e946Jl706633; Wed, 4 Oct 2000 08:19:47 +0200 (CEST) (envelope-from andreas) Date: Wed, 4 Oct 2000 08:19:47 +0200 From: Andreas Klemm To: Michelangelo Pisa Cc: net@FreeBSD.ORG Subject: Re: Procmail Message-ID: <20001004081946.A6539@titan.klemm.gtn.com> References: <39D9EE22.70EE4684@osny.com.br> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <39D9EE22.70EE4684@osny.com.br>; from michelangelo@osny.com.br on Tue, Oct 03, 2000 at 02:33:06PM +0000 X-Operating-System: FreeBSD 4.1.1-STABLE SMP X-Disclaimer: A free society is one where it is safe to be unpopular Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Oct 03, 2000 at 02:33:06PM +0000, Michelangelo Pisa wrote: > hello!! > > I'm trying to use the Procmail-3.13.1 in the FreeBSD 2.2.7 to > filter e-mails with virus, but > when I use the following configuration in my sendmail.cf: > Mprocmail, P=/usr/bin/procmail, F=DFMmShu, S=11/31, R=21/31, > T=DNS/RFC822/X-Unix, > A=procmail -m MAIL_FROM="$_" MAIL_TO="$u" > $h > > In the initialization of the system shown me errors how: > invalide rewrite line > (tab expected) You need to use tabulator instead of spaces to indent lines... Another thing would be to upgrade sendmail and to build a sendmail.cf file by using a .mc file defining define(`PROCMAIL_MAILER_PATH', `/usr/local/bin/procmail')dnl and FEATURE(local_procmail) Here is my .mc file (I run UUCP over TCP/IP and send and receive mail via UUCP): divert(-1) include(`../m4/cf.m4') VERSIONID(`@(#)klemm.mc 1.1 (AKL) 20/03/96') define(`_USE_ETC_MAIL_', True)dnl OSTYPE(bsd4.4)dnl DOMAIN(generic)dnl FEATURE(nocanonify) Dmklemm.gtn.com define(`confDOMAIN_NAME', `$m')dnl MASQUERADE_AS(klemm.gtn.com)dnl define(`PROCMAIL_MAILER_PATH', `/usr/local/bin/procmail')dnl define(`confCON_EXPENSIVE', True)dnl define(`SMTP_MAILER_FLAGS', e)dnl define(`confBIND_OPTS', `-DNSRCH -DEFNAMES')dnl define(`confDIAL_DELAY', `5s')dnl define(`UUCP_MAX_SIZE', 2000000)dnl define(`SMART_HOST', `uucp-dom:easix')dnl define(`UUCP_RELAY', `uucp-dom:easix')dnl FEATURE(access_db) FEATURE(accept_unresolvable_domains) FEATURE(always_add_domain) FEATURE(masquerade_envelope) FEATURE(local_procmail) FEATURE(relay_entire_domain) MAILER(local)dnl MAILER(smtp)dnl MAILER(uucp)dnl -- Andreas Klemm Powered by FreeBSD SMP Songs from our band >>64Bits<<............http://www.apsfilter.org/64bits.html My homepage................................ http://people.FreeBSD.ORG/~andreas Please note: Apsfilter got a NEW HOME................http://www.apsfilter.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 4 10:16: 1 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id BA21637B66C for ; Wed, 4 Oct 2000 10:15:56 -0700 (PDT) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id BAA12482 for ; Thu, 5 Oct 2000 01:15:51 +0800 Received: from elischer.org (reggae-12-204.nv.iinet.net.au [203.59.92.204]) by muzak.iinet.net.au (8.8.5/8.8.5) with ESMTP id BAA29339 for ; Thu, 5 Oct 2000 01:15:48 +0800 Message-ID: <39DB65A7.2FB8B884@elischer.org> Date: Wed, 04 Oct 2000 10:15:19 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: net@freebsd.org Subject: new mbuf stuff (dwmalone commit) Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The new reference code could cause a lot of grief in the future for One company I know of. This is because the new reference counting code doesn't take into account the reason that the old reference counting code for external storage was added in the first place. The old code had two methods. One to Add a reference and one to decrement a reference, however the new code only leaves the code to decrement the reference. This means that code that supplies it's own external memory types has no way to notify it's own memory manager that there are multiple references to an object. My guess is that it was assumed that the underlying memory manager has no reason to know ho many references are held on an object, and that there is now just a single reference from "the mbuf system" which is removed when the last mbuf internal reference is removed.. One system I know however had many objects, sorted in order of "number of references" in order to have the heavily used items near the head fo a list. Items with only one reference were "incomplete" and unlikely to be searched for. This system can no longer work. (Luckily it may never get ported to FreeBSD-5) (It was on 2.x) At this time I don't see a need to change it back, but it's just a 'heads up' that this sort of behaviour should be considered.. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 4 14: 4:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id B544D37B66C for ; Wed, 4 Oct 2000 14:04:39 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e94L4Z111586; Wed, 4 Oct 2000 14:04:35 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma011580; Wed, 4 Oct 2000 14:04:12 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.11.0/8.11.0) id e94L4BP44690; Wed, 4 Oct 2000 14:04:11 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200010042104.e94L4BP44690@bubba.whistle.com> Subject: Re: IP sec and lan to lan vpn over internet vs mpd-netgraph and lan to lan vpn over internet In-Reply-To: <000801c02c9b$57bb0040$47010a0a@fire.sysadmininc.com> "from Peter Brezny at Oct 2, 2000 02:05:25 pm" To: peter@sysadmin-inc.com Date: Wed, 4 Oct 2000 14:04:06 -0700 (PDT) Cc: freebsd-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 X-Loop: FreeBSD.org Peter Brezny writes: > Is it possible to use ipsec to create a lan to lan vpn over the internet > similar to the way the mpd-netgraph port can? > > if so, what are the advantages of ipsec or mpd-netgraph? Yes.. IPSec is more industry standard and "mainstream" than PPTP. But.. it may also be harder to configure. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 4 18: 3:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from bastuba.partitur.se (bastuba.partitur.se [212.209.169.194]) by hub.freebsd.org (Postfix) with ESMTP id D1C1737B502; Wed, 4 Oct 2000 18:03:18 -0700 (PDT) Received: from palle.girgensohn.se (c193.150.250.87.cm-upc.chello.se [193.150.250.87]) by bastuba.partitur.se (8.9.3/8.9.3) with ESMTP id DAA74398; Thu, 5 Oct 2000 03:03:17 +0200 (CEST) (envelope-from girgen@partitur.se) Received: (from girgen@localhost) by palle.girgensohn.se (8.11.0/8.11.0) id e9513G256238; Thu, 5 Oct 2000 03:03:16 +0200 (CEST) (envelope-from girgen@partitur.se) X-Authentication-Warning: palle.girgensohn.se: girgen set sender to girgen@partitur.se using -f To: freebsd-net@freebsd.org Cc: freebsd-emulation@freebsd.org Subject: bridged vmnet make NIS go berzerk killing servers with icmp msgs From: Palle Girgensohn Date: 05 Oct 2000 03:03:15 +0200 Message-ID: <87aeck14mk.fsf@palle.girgensohn.se> Lines: 60 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! Sorry for crossposting, but I'm not certain wheather this is -net or -emulation; probably both... We use NIS/YP for passwords, group, netgroup and amd lists, and have about ten workstations and three servers. One of the three is the master NIS server, the other two slaves tied to themselves. Nothing strange, it has worked splendid for years. Hubbed ethernet 100TX network. All systems involved are FreeBSD, all workstations are 4.1.1-release, the servers 3.5-release, 4.0-stable (july 2), 4.1-stable [the master] (september 13). The master server also acts as NFS server for the workstations, serving /usr/local, /usr/X11R6 and /home. Hence, workstations are more or useless without this server... I have set up vmware (from fresh port) to use bridged networking on some of the workstations, and it works just fine, dhcp and everything - for a while. After some time, maybe caused by something, I don't yet know what, all workstations using a vmnet and having a bridge between the NIC and the vmnet interface starts sending enormous amounts of ICMP "Host unreachable" (about the other servers, I think, and for every port) to all NIS servers, actually *killing* them if I don't pull the ethernet cord from the workstations within minutes. At least once, I've had a server reboot this way (the 3.5 system), giving up under the pressure from the ICMP flood. On all NIS servers, the portmap goes to top, eating all CPU cycles it can find, and more, and within seconds all [pt]ty's are locked, and all I can do on the console is switch tty (ctrl-alt-FN), the console is quite locked apart from that and does not react to any other keys. After resting for a while when the flood icmp is stopped (due to my pulling the cord), all is back to normal. I can usually ping the server interface during the hang, but that is about it... When it comes back, the server complains about "/kernel: icmp-response bandwidth limit 243/200 pps". no surprise... :-) I've tried finddling with the max setting, but there's really no difference. The workstations sending all icmp messages are also hung, and will also come back when pulling the cord, albiet in a rather useless condition due to all missing NIS and NFS services. They also get the icmp-response bandwith stuff. I've tried using netgraph instead of old-fashion bridge, by replacing the BRIDGE kernel option with NETGRAPH, according to the posting here (-net) by Nick Sayer around September 16th. I does not help. Same thing happens again after a few hours of uptime... What gives? /Palle PS. If you need, I will try to retrieve more specific log files and tcpdumps, but I'm not at the office right now, so I can't force any more info. DS. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 4 18:35:50 2000 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 851) id B1A9437B503; Wed, 4 Oct 2000 18:35:46 -0700 (PDT) To: net@freebsd.org Message-Id: <20001005013546.B1A9437B503@hub.freebsd.org> Date: Wed, 4 Oct 2000 18:35:46 -0700 (PDT) From: bmilekic@FreeBSD.ORG (Bosko Milekic) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Note: below is a (hopefully OK formatted) copy of a reply I tried to post to net@ earlier this evening. Unfortunately, due to technical difficulties on what presently seems to be my provider's side, I don't believe it will be arriving there any time soon. For those interested, I'm forwarding it from hub, knowing that it will certainly arrive at its intended destination. Appologies to Julian if he's receiving this twice or three times now, depending if my original send succeeded. Replies can be made to the list, by the way, as it seems I can receive mail without any problems...] On Wed, 4 Oct 2000, Julian Elischer wrote: > The old code had two methods. > One to Add a reference and one to decrement a reference, > however the new code only leaves the code to decrement the reference. I'm not sure what you mean by this. It's still possible to add and remove references, it's just that now this is all done in the mbuf system code, and is much faster. If that is what you meant, then in that case, the "new code" doesn't leave "non-mbuf-system code" to decrement counters either; all it does is call the "non-mbuf-system code's" designated free routine when the counter [theoretically] reaches 0. > This means that code that supplies it's own external memory types > has no way to notify it's own memory manager that there are > multiple references to an object. That's correct. This behavior was discussed quite a bit on the lists before it was implemented. It was agreed on this way because, strictly speaking, the memory management code should not be concerned with the mbuf system's reference counters (under normal circumstances). > My guess is that it was assumed that the underlying memory manager > has no reason to know ho many references are held on an object, and that > there is now just a single reference from "the mbuf system" which is > removed > when the last mbuf internal reference is removed.. Right. > One system I know however had many objects, sorted in order of "number > of references" > in order to have the heavily used items near the head fo a list. Items > with only > one reference were "incomplete" and unlikely to be searched for. A system so closely tied to the mbuf system can theoretically still be modified to do this. All that is really required is that a pointer is held to the corresponding counter. The pointer can sit at the top of the buffer, for example (and m_data would have to be modified to point to top_of_buffer + sizeof (pointer)). If this is not desired, then you can always allocate/manage a separate data structure to hold this, and possibly other information about your buffer (note that you can easily have that structure passed to your free routine with the use of the extra pointer in the declaration of the free routine). Notice that with this suggestion, even though it may not seem so at a first glance, you'll still likely to have slightly better performance than before, because you don't have to deal with the relatively important overhead of calling an external function to do the job for you. The other advantage is that, if you have other places where you want this sort of behavior, you can re-use a large portion of the code that you'll write the first time, because it will always be dealing with the same identical type of counter data structure (in this case, a union). [...] > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000 > ---> X_.---._/ presently in: Perth > v Regards, 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 Thu Oct 5 6:28:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from quack.kfu.com (quack.kfu.com [205.178.90.194]) by hub.freebsd.org (Postfix) with ESMTP id 4EC7837B66C; Thu, 5 Oct 2000 06:28:12 -0700 (PDT) Received: from medusa.kfu.com (medusa.kfu.com [205.178.90.222]) by quack.kfu.com (8.11.0/8.9.3) with ESMTP id e95DS2e94722; Thu, 5 Oct 2000 06:28:02 -0700 (PDT) (envelope-from nsayer@quack.kfu.com) Received: from icarus.kfu.com (ssmail@localhost) by medusa.kfu.com (8.11.0/8.11.0) with ESMTP id e95DS2404453; Thu, 5 Oct 2000 06:28:02 -0700 (PDT) (envelope-from nsayer@quack.kfu.com) Received: from quack.kfu.com by icarus.kfu.com with ESMTP (8.11.0//ident-1.0) id e95DS1m72464; Thu, 5 Oct 2000 06:28:01 -0700 (PDT) Message-ID: <39DC81E1.2C0F7315@quack.kfu.com> Date: Thu, 05 Oct 2000 06:28:01 -0700 From: Nick Sayer X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Palle Girgensohn Cc: freebsd-net@FreeBSD.ORG, freebsd-emulation@FreeBSD.ORG Subject: Re: bridged vmnet make NIS go berzerk killing servers with icmp msgs References: <87aeck14mk.fsf@palle.girgensohn.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Palle Girgensohn wrote: > > Hi! > > Sorry for crossposting, but I'm not certain wheather this is -net or > -emulation; probably both... I see a similar failure every once in a while on FreeBSD machines that are NIS clients that are not running vmware, though it sounds to me like you are seeing it a lot more frequently. I can sometimes precipitate this by disconnecting an NIS client from the net briefly, using NIS, then reconnecting it. It ends up in the icmp supression state and the only way out is the history eraser button. Our master is a Solaris 2.x x86 machine, though. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 5 6:45:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id A581937B502 for ; Thu, 5 Oct 2000 06:45:25 -0700 (PDT) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G1X00K38EXIQT@field.videotron.net> for net@FreeBSD.ORG; Wed, 4 Oct 2000 18:10:30 -0400 (EDT) Date: Wed, 04 Oct 2000 18:14:25 -0400 (EDT) From: Bosko Milekic Subject: Re: new mbuf stuff (dwmalone commit) In-reply-to: <39DB65A7.2FB8B884@elischer.org> X-Sender: bmilekic@jehovah.technokratis.com To: Julian Elischer Cc: net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 4 Oct 2000, Julian Elischer wrote: > The old code had two methods. > One to Add a reference and one to decrement a reference, > however the new code only leaves the code to decrement the reference. I'm not sure what you mean by this. It's still possible to add and remove references, it's just that now this is all done in the mbuf system code, and is much faster. If that is what you meant, then in that case, the "new code" doesn't leave "non-mbuf-system code" to decrement counters either; all it does is call the "non-mbuf-system code's" designated free routine when the counter [theoretically] reaches 0. > This means that code that supplies it's own external memory types > has no way to notify it's own memory manager that there are > multiple references to an object. That's correct. This behavior was discussed quite a bit on the lists before it was implemented. It was agreed on this way because, strictly speaking, the memory management code should not be concerned with the mbuf system's reference counters (under normal circumstances). > My guess is that it was assumed that the underlying memory manager > has no reason to know ho many references are held on an object, and that > there is now just a single reference from "the mbuf system" which is > removed > when the last mbuf internal reference is removed.. Right. > One system I know however had many objects, sorted in order of "number > of references" > in order to have the heavily used items near the head fo a list. Items > with only > one reference were "incomplete" and unlikely to be searched for. A system so closely tied to the mbuf system can theoretically still be modified to do this. All that is really required is that a pointer is held to the corresponding counter. The pointer can sit at the top of the buffer, for example (and m_data would have to be modified to point to top_of_buffer + sizeof (pointer)). If this is not desired, then you can always allocate/manage a separate data structure to hold this, and possibly other information about your buffer (note that you can easily have that structure passed to your free routine with the use of the extra pointer in the declaration of the free routine). Notice that with this suggestion, even though it may not seem so at a first glance, you'll still likely to have slightly better performance than before, because you don't have to deal with the relatively important overhead of calling an external function to do the job for you. The other advantage is that, if you have other places where you want this sort of behavior, you can re-use a large portion of the code that you'll write the first time, because it will always be dealing with the same identical type of counter data structure (in this case, a union). [...] > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000 > ---> X_.---._/ presently in: Perth > v Regards, 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 Thu Oct 5 7: 2:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from bastuba.partitur.se (bastuba.partitur.se [212.209.169.194]) by hub.freebsd.org (Postfix) with ESMTP id 1989837B502; Thu, 5 Oct 2000 07:02:19 -0700 (PDT) Received: from elbas.partitur.se (elbas.partitur.se [212.209.169.222]) by bastuba.partitur.se (8.9.3/8.9.3) with ESMTP id QAA81896; Thu, 5 Oct 2000 16:02:17 +0200 (CEST) (envelope-from girgen@partitur.se) Received: from partitur.se (localhost.partitur.se [127.0.0.1]) by elbas.partitur.se (8.11.0/8.11.0) with ESMTP id e95E2HH02567; Thu, 5 Oct 2000 16:02:17 +0200 (CEST) (envelope-from girgen@partitur.se) Message-ID: <39DC89E9.6569F@partitur.se> Date: Thu, 05 Oct 2000 16:02:17 +0200 From: Palle Girgensohn Organization: Partitur X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.1.1-RELEASE i386) X-Accept-Language: sv, en MIME-Version: 1.0 To: Nick Sayer Cc: freebsd-net@FreeBSD.ORG, freebsd-emulation@FreeBSD.ORG Subject: Re: bridged vmnet make NIS go berzerk killing servers with icmp msgs References: <87aeck14mk.fsf@palle.girgensohn.se> <39DC81E1.2C0F7315@quack.kfu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nick Sayer wrote: > > Palle Girgensohn wrote: > > > > Hi! > > > > Sorry for crossposting, but I'm not certain wheather this is -net or > > -emulation; probably both... > > I see a similar failure every once in a while on FreeBSD machines that > are NIS clients that are not running vmware, though it sounds to me like > you are seeing it a lot more frequently. Actually, the clients are not necessarily using vmware, just the vmnet interface and a bridge to fxp0 or xl0. I suspect there is a problem with nis and bridges... > I can sometimes precipitate this by disconnecting an NIS client from the > net briefly, using NIS, then reconnecting it. It ends up in the icmp > supression state and the only way out is the history eraser button. you mean that after disconnecting the client, you do some NIS operations? > Our master is a Solaris 2.x x86 machine, though. ok... Does that matter? Isn't it the client failing? How can I debug this? I really need to get it fixed. running natd and private nets for vmware on every system isn't really an option (well, I can cope, but I'd rather not...) /Palle -- Partitur Informationsteknik AB Wenner-Gren Center +46 8 566 280 02 113 46 Stockholm +46 70 785 86 02 Sweden girgen@partitur.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 5 15:56: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from service.sh.cvut.cz (service.sh.cvut.cz [147.32.127.214]) by hub.freebsd.org (Postfix) with ESMTP id 6EDFA37B502 for ; Thu, 5 Oct 2000 15:56:04 -0700 (PDT) Received: from logout.sh.cvut.cz (logout.sh.cvut.cz [147.32.127.203]) by service.sh.cvut.cz (8.9.3/8.8.8/Silicon Hill/Antispam/8.12.1999) with ESMTP id AAA25210 for ; Fri, 6 Oct 2000 00:56:03 +0200 Received: from sh.cvut.cz (fulda.sh.cvut.cz [147.32.123.45]) by logout.sh.cvut.cz (8.9.3/8.9.2) with ESMTP id AAA34695 for ; Fri, 6 Oct 2000 00:56:03 +0200 (CEST) (envelope-from Jindrich.Fucik@sh.cvut.cz) Message-ID: <39DD074B.7714399C@sh.cvut.cz> Date: Fri, 06 Oct 2000 00:57:15 +0200 From: Jindra Fucik X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: cs,en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: EtherExpress PRO/100 - EISA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! I have problem with Intel EtherExpress PRO/100 - EISA (not PRO/100+, not PRO/100B) I can not find driver. Is this card supported? Thanx Jindrich Fucik To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 5 16: 8:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from mario.zyan.com (mario.zyan.com [209.250.96.140]) by hub.freebsd.org (Postfix) with ESMTP id DE58937B502 for ; Thu, 5 Oct 2000 16:08:25 -0700 (PDT) Received: from dopey.weyrich.com (orville@node-64-249-12-250.dslspeed.zyan.com [64.249.12.250]) by mario.zyan.com (8.9.3/8.9.3) with ESMTP id QAA11918 for ; Thu, 5 Oct 2000 16:08:19 -0700 (PDT) (envelope-from orville@weyrich.com) Received: from localhost (orville@localhost) by dopey.weyrich.com (8.9.3/8.6.9) with ESMTP id QAA11323; Thu, 5 Oct 2000 16:02:03 -0700 Date: Thu, 5 Oct 2000 16:02:03 -0700 (MST) From: "Orville R. Weyrich.Jr" To: Jindra Fucik Cc: freebsd-net@FreeBSD.ORG Subject: Re: EtherExpress PRO/100 - EISA In-Reply-To: <39DD074B.7714399C@sh.cvut.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I don't know anything about this card. EISA is one of those good ideas that did not catch on before it was displaced by a better one (PCI). In general, there is little support for EISA -- but you may be able to use an ISA driver. I know that Adaptec's 1740 EISA SCSI card could emulate a 1540 ISA SCSI card, so this might be the case for EtherExpress PRO/100 - EISA also. Of course, this defeats the whole idea of using an EISA card. On Fri, 6 Oct 2000, Jindra Fucik wrote: > Hi! > > I have problem with Intel EtherExpress PRO/100 - EISA > (not PRO/100+, not PRO/100B) > I can not find driver. > > Is this card supported? > > Thanx > Jindrich Fucik > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > =================================================================== IF YOU WANT REFORM, VOTE REFORM ------- VOTE BUCHANAN/FOSTER VOTE! ------------------------------------------------------------------- Orville R. Weyrich, Jr. Weyrich Computer Consulting mailto:orville@weyrich.com KD7HJV http://www.weyrich.com ------------------------------------------------------------------- Visit our online collection of book reviews: http://www.weyrich.com/book_reviews/ Ask about our world wide web services! ------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 5 18:42:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id AB92C37B502 for ; Thu, 5 Oct 2000 18:42:34 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id VAA02266; Thu, 5 Oct 2000 21:42:31 -0400 (EDT) Date: Thu, 5 Oct 2000 21:42:30 -0400 (EDT) From: "Matthew N. Dodd" To: Jindra Fucik Cc: freebsd-net@FreeBSD.ORG Subject: Re: EtherExpress PRO/100 - EISA In-Reply-To: <39DD074B.7714399C@sh.cvut.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 6 Oct 2000, Jindra Fucik wrote: > I have problem with Intel EtherExpress PRO/100 - EISA > (not PRO/100+, not PRO/100B) > I can not find driver. > > Is this card supported? Nope, and neither is its close cousin the PRO/100A PCI. I've got examples of both. :/ -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 5 18:44:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id BC79A37B502 for ; Thu, 5 Oct 2000 18:44:40 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id VAA02314; Thu, 5 Oct 2000 21:44:35 -0400 (EDT) Date: Thu, 5 Oct 2000 21:44:34 -0400 (EDT) From: "Matthew N. Dodd" To: "Orville R. Weyrich.Jr" Cc: Jindra Fucik , freebsd-net@FreeBSD.ORG Subject: Re: EtherExpress PRO/100 - EISA In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 5 Oct 2000, Orville R. Weyrich.Jr wrote: > In general, there is little support for EISA On the whole I'd say FreeBSD has very good support for EISA. There are quite a few devices that nobody has fixed drivers to work with but one might attribute that to lack of developers or me having far to much to do to carry everything myself. :) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 5 23:25:30 2000 Delivered-To: freebsd-net@freebsd.org Received: from tepid.osl.fast.no (tepid.osl.fast.no [213.188.9.130]) by hub.freebsd.org (Postfix) with ESMTP id BAFC737B502 for ; Thu, 5 Oct 2000 23:25:26 -0700 (PDT) Received: from raw.grenland.fast.no (fw-oslo.fast.no [213.188.9.129]) by tepid.osl.fast.no (8.9.3/8.9.1) with ESMTP id GAA92720; Fri, 6 Oct 2000 06:29:55 GMT (envelope-from raw@fast.no) Received: (from raw@localhost) by raw.grenland.fast.no (8.11.0/8.11.0) id e966PZ973737; Fri, 6 Oct 2000 08:25:35 +0200 (CEST) (envelope-from raw) From: Raymond Wiker MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14813.28763.410367.378304@raw.grenland.fast.no> Date: Fri, 6 Oct 2000 08:25:31 +0200 (CEST) To: freebsd-net@FreeBSD.ORG Subject: Re: bridged vmnet make NIS go berzerk killing servers with icmp msgs In-Reply-To: <39DC81E1.2C0F7315@quack.kfu.com> References: <87aeck14mk.fsf@palle.girgensohn.se> <39DC81E1.2C0F7315@quack.kfu.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nick Sayer writes: > Palle Girgensohn wrote: > > > > Hi! > > > > Sorry for crossposting, but I'm not certain wheather this is -net or > > -emulation; probably both... > > I see a similar failure every once in a while on FreeBSD machines that > are NIS clients that are not running vmware, though it sounds to me like > you are seeing it a lot more frequently. > > I can sometimes precipitate this by disconnecting an NIS client from the > net briefly, using NIS, then reconnecting it. It ends up in the icmp > supression state and the only way out is the history eraser button. You can achieve the same effect by putting wildly inappropriate values in /var/yp/securenets... //Raymond. -- Raymond Wiker Raymond.Wiker@fast.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 6 12:22:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from hetnet.nl (net015s.hetnet.nl [194.151.104.155]) by hub.freebsd.org (Postfix) with ESMTP id 98AB737B503 for ; Fri, 6 Oct 2000 12:22:24 -0700 (PDT) Received: from hetnet.nl ([192.150.187.12]) by hetnet.nl with Microsoft SMTPSVC(5.5.1877.537.53); Fri, 6 Oct 2000 21:22:21 +0200 Message-ID: <39DE266B.E9975E2F@hetnet.nl> Date: Fri, 06 Oct 2000 12:22:19 -0700 From: Wilbert de Graaf Reply-To: wilbertdg@hetnet.nl X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: how to lock, but not using spl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have been working on some FreeBSD networking code, that used spl() to protect a linked list. I want to change this using ? so that it would run on SMP systems too. I monitored the SMP list and had a look in the 4.4BSD book but I haven't been able to find how to do it on BSD. Is there any sample or can anybopdy give me a pointer ? - Wilbert Some more info about what I would like to do: SLIST_HEAD slh; // gets called from the ioctl (the api) void my_ioctl(int n) { struct my_entry e = malloc(sizeof(struct my_entry), ...); e->id = n; // s = splnet(); ... ? ... SLIST_INSERT_HEAD(slh, e, e->link); // splx(s); ... ? ... } // gets called from a timer void my_timer(void) { struct my_entry e; FOREACH(e, slh) { if (e->done) { // s = splnet(); ... ? ... SLIST_REMOVE(slh, e, struct my_entry, e->link); // splx(s); ... ? ... } } } I have the impression simple_lock() can do this but I'm not sure if any of these processes can block on the other. Like what if the net timer mechanism has to block on a smiple api call. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 6 13:12:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 07B1437B502 for ; Fri, 6 Oct 2000 13:12:58 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e96KCuo03846; Fri, 6 Oct 2000 13:12:56 -0700 (PDT) Date: Fri, 6 Oct 2000 13:12:56 -0700 From: Alfred Perlstein To: Wilbert de Graaf Cc: freebsd-net@FreeBSD.ORG Subject: Re: how to lock, but not using spl Message-ID: <20001006131256.D266@fw.wintelcom.net> References: <39DE266B.E9975E2F@hetnet.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <39DE266B.E9975E2F@hetnet.nl>; from wilbertdg@hetnet.nl on Fri, Oct 06, 2000 at 12:22:19PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Wilbert de Graaf [001006 12:22] wrote: > > > I have been working on some FreeBSD networking code, that used spl() to > protect a linked list. I want to change this using ? so that it would > run on SMP systems too. I monitored the SMP list and had a look in the > 4.4BSD book but I haven't been able to find how to do it on BSD. Is > there any sample or can anybopdy give me a pointer ? See the mutex.9 manpage in recent -current. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 7 11:25:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id D79AB37B502; Sat, 7 Oct 2000 11:25:53 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e97IPrt01259; Sat, 7 Oct 2000 11:25:53 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma001257; Sat, 7 Oct 2000 11:25:38 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.11.0/8.11.0) id e97IPcE01449; Sat, 7 Oct 2000 11:25:38 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200010071825.e97IPcE01449@bubba.whistle.com> Subject: header bogosity in To: freebsd-net@freebsd.org, developers@freebsd.org Date: Sat, 7 Oct 2000 11:25:38 -0700 (PDT) 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 X-Loop: FreeBSD.org In the following appears: #ifndef _KERNEL #define Bcmp(a, b, n) bcmp(((char *)(a)), ((char *)(b)), (n)) #define Bcopy(a, b, n) bcopy(((char *)(a)), ((char *)(b)), (unsigned)(n)) #define Bzero(p, n) bzero((char *)(p), (int)(n)); #define R_Malloc(p, t, n) (p = (t) malloc((unsigned int)(n))) #define Free(p) free((char *)p); #else #define Bcmp(a, b, n) bcmp(((caddr_t)(a)), ((caddr_t)(b)), (unsigned)(n)) #define Bcopy(a, b, n) bcopy(((caddr_t)(a)), ((caddr_t)(b)), (unsigned)(n)) #define Bzero(p, n) bzero((caddr_t)(p), (unsigned)(n)); #define R_Malloc(p, t, n) (p = (t) malloc((unsigned long)(n), M_RTABLE, M_DONTWAIT)) #define Free(p) free((caddr_t)p, M_RTABLE); #endif /* _KERNEL */ Isn't this bogus? For example, it conflicts with any program that #defines Free() for itself. Apparenly some of these C files (sys/net/radix.c, sys/net/route.c, sys/net/rtsock.c) are used in both kernel and userland compilation. What is the correct way to do this? Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 7 17: 9:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 0E3D137B681; Sat, 7 Oct 2000 17:05:55 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id JAA06053; Sun, 8 Oct 2000 09:05:49 +0900 (JST) To: Archie Cobbs Cc: freebsd-net@freebsd.org, developers@freebsd.org In-reply-to: archie's message of Sat, 07 Oct 2000 11:25:38 MST. <200010071825.e97IPcE01449@bubba.whistle.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: header bogosity in From: itojun@iijlab.net Date: Sun, 08 Oct 2000 09:05:49 +0900 Message-ID: <6051.970963549@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >In the following appears: > > #ifndef _KERNEL > #define Bcmp(a, b, n) bcmp(((char *)(a)), ((char *)(b)), (n)) > #define Bcopy(a, b, n) bcopy(((char *)(a)), ((char *)(b)), (unsigned)(n)) > #define Bzero(p, n) bzero((char *)(p), (int)(n)); > #define R_Malloc(p, t, n) (p = (t) malloc((unsigned int)(n))) > #define Free(p) free((char *)p); > #else > #define Bcmp(a, b, n) bcmp(((caddr_t)(a)), ((caddr_t)(b)), (unsigned)(n)) > #define Bcopy(a, b, n) bcopy(((caddr_t)(a)), ((caddr_t)(b)), (unsigned)(n)) > #define Bzero(p, n) bzero((caddr_t)(p), (unsigned)(n)); > #define R_Malloc(p, t, n) (p = (t) malloc((unsigned long)(n), M_RTABLE, M_DONTWAIT)) > #define Free(p) free((caddr_t)p, M_RTABLE); > #endif /* _KERNEL */ > >Isn't this bogus? For example, it conflicts with any program that >#defines Free() for itself. Apparenly some of these C files >(sys/net/radix.c, sys/net/route.c, sys/net/rtsock.c) are used in >both kernel and userland compilation. > >What is the correct way to do this? I had the same problem with compiling with openssl headers, on netbsd. if i were you, i'd remove "!_KERNEL" case, and define those in kernel compilation only. itoj To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 7 17: 9:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id A3DA237B68D; Sat, 7 Oct 2000 17:07:23 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id JAA06079; Sun, 8 Oct 2000 09:07:20 +0900 (JST) To: Archie Cobbs , freebsd-net@freebsd.org, developers@freebsd.org In-reply-to: itojun's message of Sun, 08 Oct 2000 09:05:49 JST. <6051.970963549@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: header bogosity in From: itojun@iijlab.net Date: Sun, 08 Oct 2000 09:07:20 +0900 Message-ID: <6077.970963640@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>Isn't this bogus? For example, it conflicts with any program that >>#defines Free() for itself. Apparenly some of these C files >>(sys/net/radix.c, sys/net/route.c, sys/net/rtsock.c) are used in >>both kernel and userland compilation. >> >>What is the correct way to do this? > > I had the same problem with compiling with openssl headers, on netbsd. > > if i were you, i'd remove "!_KERNEL" case, and define those in kernel > compilation only. i believe this was here so that we can share radix.[ch] among sys/net, and sbin/routed. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 7 18: 4:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 45D4637B503; Sat, 7 Oct 2000 18:04:37 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id VAA99968; Sat, 7 Oct 2000 21:04:32 -0400 (EDT) (envelope-from wollman) Date: Sat, 7 Oct 2000 21:04:32 -0400 (EDT) From: Garrett Wollman Message-Id: <200010080104.VAA99968@khavrinen.lcs.mit.edu> To: itojun@iijlab.net Cc: freebsd-net@FreeBSD.org, developers@FreeBSD.org Subject: Re: header bogosity in In-Reply-To: <6077.970963640@coconut.itojun.org> References: <6051.970963549@coconut.itojun.org> <6077.970963640@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < i believe this was here so that we can share radix.[ch] among > sys/net, and sbin/routed. And, potentially, other routing processes. However, last time I tried this, support had rotted sufficiently elsewhere as to require manual edits elsewhere, so I don't see much value in keeping the non-kernel alternative. (I would not, however, delete the actual macros themselves -- just be more careful about the context in which they are defined.) Why should OpenSSL be including anyway? -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 7 18: 9: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 05B1637B502; Sat, 7 Oct 2000 18:09:02 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id KAA06803; Sun, 8 Oct 2000 10:08:45 +0900 (JST) To: Garrett Wollman Cc: freebsd-net@FreeBSD.org, developers@FreeBSD.org In-reply-to: wollman's message of Sat, 07 Oct 2000 21:04:32 -0400. <200010080104.VAA99968@khavrinen.lcs.mit.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: header bogosity in From: itojun@iijlab.net Date: Sun, 08 Oct 2000 10:08:45 +0900 Message-ID: <6801.970967325@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> i believe this was here so that we can share radix.[ch] among >> sys/net, and sbin/routed. >And, potentially, other routing processes. However, last time I tried >this, support had rotted sufficiently elsewhere as to require manual >edits elsewhere, so I don't see much value in keeping the non-kernel >alternative. (I would not, however, delete the actual macros >themselves -- just be more careful about the context in which they are >defined.) >Why should OpenSSL be including anyway? sorry i was unclear. i was building sendmail with STARTTLS enabled (so it pulls in openssl). sendmail tries to look at IP options, so it pulls in sys/netinet/ip_var.h. ip_var.h pulls in sys/net/route.h, and then sys/net/radix.h. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message