From owner-freebsd-net Sun Mar 31 16:28:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from web21110.mail.yahoo.com (web21110.mail.yahoo.com [216.136.227.112]) by hub.freebsd.org (Postfix) with SMTP id 8884337B41A for ; Sun, 31 Mar 2002 16:28:39 -0800 (PST) Message-ID: <20020401002839.54646.qmail@web21110.mail.yahoo.com> Received: from [152.15.26.29] by web21110.mail.yahoo.com via HTTP; Sun, 31 Mar 2002 16:28:39 PST Date: Sun, 31 Mar 2002 16:28:39 -0800 (PST) From: Vinod Subject: help needed with configuring a gateway To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi there. i was trying to create a gateway having one ethernet card(10.0.0.2) and a wireless nic(10.0.1.1). I wanted this gateway to act between a laptop(10.0.1.5) and another pc acting as a firewall/gateway(10.0.0.1). 10.0.0.1-wired----10.0.0.2 gateway 10.0.1.1---wireless---10.0.1.5 Somehow i cant ping from the laptop to the 10.0.0.1 host.i can ping from laptop to the gateway and from gateway to 10.0.0.1.i have done gateway_enable="YES" in /etc/rc.conf. Here's how my routing table looks at the gateway. ------------------------------------------------------ Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.1 UGSc 1 422 fxp0 10/24 link#1 UC 2 0 fxp0 10.0.0.1 0:e0:29:24:4d:d4 UHLW 4 7 fxp0 1047 10.0.0.255 ff:ff:ff:ff:ff:ff UHLWb 1 264 fxp0 10.0.1/24 link#7 UC 0 0 wi0 localhost localhost UH 1 2 lo0 ------------------------------------------------------ i tried to observe if my ping from the laptop is reaching the 10.0.0.1 machine at all by running tcp dump there. i got: testbed1-pc.1028>10.0.0.255.3661 : udp 80 testbed1-pc.1028>10.0.0.255.3661 : udp 80 ......... [Here testbed1-pc is the name of the gateway] Does this tell anything?i am new to all this so have no clue. when i run tcpdump at my gateway and ping the laptop from 10.0.0.1 i see on the screen: arp who-has 10.0.1.5 tell 10.0.0.1 .......... 10.0.0.2.1028>10.0.0.255.3661> udp 80 .................... Would appreciate any help a lot. Thanks in advance, Vinod __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 31 17: 5:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from newmail.skyrunner.net (newmail.skyrunner.net [208.133.44.6]) by hub.freebsd.org (Postfix) with ESMTP id A2B8C37B417 for ; Sun, 31 Mar 2002 17:05:34 -0800 (PST) Received: from micron (athena.skyrunner.net [208.150.25.130]) by newmail.skyrunner.net (8.11.2/8.11.0/SuSE Linux 8.11.0-0.4) with SMTP id g3115SG16895 for ; Sun, 31 Mar 2002 20:05:28 -0500 From: "Peter Brezny" To: Subject: NATD theoretical max and tuning question Date: Sun, 31 Mar 2002 20:06:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've got a system acting as a router for about 1000 users behind various private networks who are currently all routed through a pII 400 with 512M ram. Currently all of these private networks are translated through one public IP. Frequently the natd process will use more than 50% of the cpu. Is a system of this class adequate for what I am trying to do? Would I be better off assinging a separate public IP for each of the private networks routed behind it? TIA Peter Brezny Skyrunner.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 31 18:12:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from nanguo.chalmers.com.au (nanguo.chalmers.com.au [203.1.96.5]) by hub.freebsd.org (Postfix) with ESMTP id 6199F37B41B for ; Sun, 31 Mar 2002 18:11:42 -0800 (PST) Received: from carbon (carbon.chalmers.com.au [203.1.96.26]) by nanguo.chalmers.com.au (8.11.6/8.11.6) with SMTP id g312ERs12435 for ; Mon, 1 Apr 2002 12:14:27 +1000 (EST) (envelope-from robert@quantum-radio.net.au) Message-ID: <018c01c1d922$df055a70$1a6001cb@chalmers.com.au> Reply-To: "Merlin" From: "Merlin" To: "freebsd-net" Subject: Trying to get the IPv6 stf0 interface syntax right Date: Mon, 1 Apr 2002 12:13:45 +1000 Organization: Quantum Radio MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm trying to get the options in rc.conf right for the stf0 interface for IPv6/6to4 stuff I'm hoping that someone out there is somewhat more expert in this than I. It all works I might say. ping6 and all that - but I'm sure it's not set up right? I have two servers with one connected to the internet on a permanent modem/ppp dialup. [ruby.chalmers.com.au] ------ [ nanguo.chalmers.com.au]------[ppp internet] FreeBSd-5.0 FreeBSD-4.5 ............................................................................ .............................................. ( the relevant bits for ruby rc.conf) ifconfig_ed0="inet 203.1.96.6 netmask 255.255.255.0" ifconfig_stf0="inet6 2002:cb01:6006:1:0040:05ff:fe4e:a982 prefixlen 16 alias" # tested options ?? #ifconfig_stf0="inet6 2002:cb01:6006:0001::1 prefixlen 16 alias" #ifconfig_stf0="inet6 2002:cb01:6006::1 prefixlen 16 alias" #ifconfig_stf0="inet6 2002:cb01:6006:0:240:5ff:fe4e:a982 prefixlen 16 alias" hostname="ruby.chalmers.com.au" named_enable="YES" ### IPv6 options: ### ipv6_enable="YES" # Set to YES to set up for IPv6. ipv6_network_interfaces="auto" # List of network interfaces (or "auto"). ipv6_gateway_enable="NO" # Set to YES if this host will be a gateway. #ipv6_prefix_ed0="2002:cb01:6006:0" ipv6_static_routes="default" ipv6_route_default="default 2002:c058:6301::" stf_interface_ipv4addr="203.1.96.6" #stf_interface_ipv6_ifid="0:0:0:1" #================================================= #stf_interface_ipv4addr="" # Local IPv4 addr for 6to4 IPv6 over IPv4 # tunneling interface. Specify this entry # to enable 6to4 interface. #stf_interface_ipv4plen="0" # Prefix length for 6to4 IPv4 addr, # to limit peer addr range. Effective value # is 0-31. stf_interface_ipv6_ifid="0:0:0:1" # IPv6 interface id for stf0. # If you like, you can set "AUTO" for this. #stf_interface_ipv6_slaid="0000" # IPv6 Site Level Aggregator for stf0 #ipv6_faith_prefix="NO" # Set faith prefix to enable a FAITH # IPv6-to-IPv4 TCP translator. You also need # faithd(8) setup. ======================================================= However, the ifconfig for the first server, nangou, is this ifconfig_stf0="inet6 2002:cb01:6005::1 prefixlen 16 alias" and it works fine. Thanks for any ideas anyone may have, Regards Robert --- Quantum Radio: World Music with a difference. http://quantum-radio.net/ Now Playing: Leningrad Symphony Orchestra - Prelude Khoantchina To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 1 1: 4:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from bps.jodocus.org (c115139.upc-c.chello.nl [212.187.115.139]) by hub.freebsd.org (Postfix) with ESMTP id B240937B417 for ; Mon, 1 Apr 2002 01:04:52 -0800 (PST) Received: (from joost@localhost) by bps.jodocus.org (8.11.6/8.11.6) id g31950F83113; Mon, 1 Apr 2002 11:05:00 +0200 (CEST) (envelope-from joost) Date: Mon, 1 Apr 2002 11:04:59 +0200 From: Joost Bekkers To: Peter Brezny Cc: freebsd-net@FreeBSD.ORG Subject: Re: NATD theoretical max and tuning question Message-ID: <20020401110459.A83056@bps.jodocus.org> Mail-Followup-To: Joost Bekkers , Peter Brezny , freebsd-net@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from peter@skyrunner.net on Sun, Mar 31, 2002 at 08:06:16PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Mar 31, 2002 at 08:06:16PM -0500, Peter Brezny wrote: > I've got a system acting as a router for about 1000 users behind various > private networks who are currently all routed through a pII 400 with 512M > ram. > > Currently all of these private networks are translated through one public > IP. > > Frequently the natd process will use more than 50% of the cpu. > This is due to a bug in natd which was fixed in 4.5-STABLE http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2878659+0+archive/2002/freebsd-questions/20020324.freebsd-questions I personally noticed the same thing, but it stopped after I upgraded natd Greetz Joost joost@jodocus.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 1 1:29:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 14AFE37B41D for ; Mon, 1 Apr 2002 01:29:22 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g319TCh69936; Mon, 1 Apr 2002 01:29:12 -0800 (PST) (envelope-from rizzo) Date: Mon, 1 Apr 2002 01:29:12 -0800 From: Luigi Rizzo To: Joost Bekkers Cc: Peter Brezny , freebsd-net@FreeBSD.ORG Subject: Re: NATD theoretical max and tuning question Message-ID: <20020401012912.B69717@iguana.icir.org> References: <20020401110459.A83056@bps.jodocus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020401110459.A83056@bps.jodocus.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Actually, following other reports on natd performance trashing under load and with time, I am under the impression that the library used by natd (libalias ?) might use some heavyweight data structure (such as linear lists, or hash tables which saturate too early) to lookup sessions. The bug mentioned below is only partly related -- yes it prevents natd from doing busy-waiting on an interface, but that is only part of the story. cheers luigi On Mon, Apr 01, 2002 at 11:04:59AM +0200, Joost Bekkers wrote: > On Sun, Mar 31, 2002 at 08:06:16PM -0500, Peter Brezny wrote: > > I've got a system acting as a router for about 1000 users behind various > > private networks who are currently all routed through a pII 400 with 512M > > ram. > > > > Currently all of these private networks are translated through one public > > IP. > > > > Frequently the natd process will use more than 50% of the cpu. > > > > This is due to a bug in natd which was fixed in 4.5-STABLE > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2878659+0+archive/2002/freebsd-questions/20020324.freebsd-questions > > I personally noticed the same thing, but it stopped after I > upgraded natd > > Greetz Joost > joost@jodocus.org > > 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 Apr 1 7:59:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from rack.purplecat.net (rack.purplecat.net [208.133.44.46]) by hub.freebsd.org (Postfix) with ESMTP id A24E237B417 for ; Mon, 1 Apr 2002 07:59:42 -0800 (PST) Received: (qmail 16522 invoked from network); 1 Apr 2002 15:59:42 -0000 Received: from unknown (HELO micron) (208.150.25.130) by mx1.skyrunner.net with SMTP; 1 Apr 2002 15:59:42 -0000 Reply-To: From: "Peter Brezny" To: "Luigi Rizzo" , "Joost Bekkers" Cc: Subject: RE: NATD theoretical max and tuning question Date: Mon, 1 Apr 2002 11:00:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: <20020401012912.B69717@iguana.icir.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thank everyone for the background. So as far as load on natd is concerned, which is better: All private networks translated through one public ip address (about 5 class c networks total) or A separate public ip for each private network to be translated through. Thanks again for your help. Peter Brezny Skyrunner.net -----Original Message----- From: Luigi Rizzo [mailto:rizzo@icir.org] Sent: Monday, April 01, 2002 4:29 AM To: Joost Bekkers Cc: Peter Brezny; freebsd-net@FreeBSD.ORG Subject: Re: NATD theoretical max and tuning question Actually, following other reports on natd performance trashing under load and with time, I am under the impression that the library used by natd (libalias ?) might use some heavyweight data structure (such as linear lists, or hash tables which saturate too early) to lookup sessions. The bug mentioned below is only partly related -- yes it prevents natd from doing busy-waiting on an interface, but that is only part of the story. cheers luigi On Mon, Apr 01, 2002 at 11:04:59AM +0200, Joost Bekkers wrote: > On Sun, Mar 31, 2002 at 08:06:16PM -0500, Peter Brezny wrote: > > I've got a system acting as a router for about 1000 users behind various > > private networks who are currently all routed through a pII 400 with 512M > > ram. > > > > Currently all of these private networks are translated through one public > > IP. > > > > Frequently the natd process will use more than 50% of the cpu. > > > > This is due to a bug in natd which was fixed in 4.5-STABLE > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2878659+0+archive/2002/freebsd- questions/20020324.freebsd-questions > > I personally noticed the same thing, but it stopped after I > upgraded natd > > Greetz Joost > joost@jodocus.org > > 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 Apr 1 8:52:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from web21107.mail.yahoo.com (web21107.mail.yahoo.com [216.136.227.109]) by hub.freebsd.org (Postfix) with SMTP id 7E01D37B41A for ; Mon, 1 Apr 2002 08:52:21 -0800 (PST) Message-ID: <20020401165221.4936.qmail@web21107.mail.yahoo.com> Received: from [152.15.26.29] by web21107.mail.yahoo.com via HTTP; Mon, 01 Apr 2002 08:52:21 PST Date: Mon, 1 Apr 2002 08:52:21 -0800 (PST) From: Vinod Subject: Re: help needed with configuring a gateway To: Vladimir Terziev Cc: freebsd-net@freebsd.org In-Reply-To: <20020401130700.67849982.vlady@rila.bg> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org no i don't. Vinod --- Vladimir Terziev wrote: > Do you have active firewall on your gateway? > > > On Sun, 31 Mar 2002 16:28:39 -0800 (PST) > Vinod wrote: > > > Hi there. i was trying to create a gateway having > one > > ethernet card(10.0.0.2) and a wireless > nic(10.0.1.1). > > I wanted this gateway to act between a > > laptop(10.0.1.5) and another pc acting as a > > firewall/gateway(10.0.0.1). > > > > 10.0.0.1-wired----10.0.0.2 > > gateway > > 10.0.1.1---wireless---10.0.1.5 > > > > > > > Somehow i cant ping from the laptop to the > 10.0.0.1 > > host.i can ping from laptop to the gateway and > from > > gateway to 10.0.0.1.i have done > gateway_enable="YES" > > in /etc/rc.conf. > > Here's how my routing table looks at the gateway. > > > ------------------------------------------------------ > > Routing tables > > > > Internet: > > Destination Gateway Flags Refs Use Netif Expire > > default 10.0.0.1 UGSc 1 422 fxp0 > > 10/24 link#1 UC 2 0 fxp0 > > 10.0.0.1 0:e0:29:24:4d:d4 UHLW 4 7 fxp0 1047 > > 10.0.0.255 ff:ff:ff:ff:ff:ff UHLWb 1 264 fxp0 > > 10.0.1/24 link#7 UC 0 0 wi0 > > localhost localhost UH 1 2 lo0 > > > ------------------------------------------------------ > > > > i tried to observe if my ping from the laptop is > > reaching the 10.0.0.1 machine at all by running > tcp > > dump there. > > i got: > > testbed1-pc.1028>10.0.0.255.3661 : udp 80 > > testbed1-pc.1028>10.0.0.255.3661 : udp 80 > > ......... > > [Here testbed1-pc is the name of the gateway] > > Does this tell anything?i am new to all this so > have > > no clue. > > when i run tcpdump at my gateway and ping the > laptop > > from 10.0.0.1 i see on the screen: > > > > arp who-has 10.0.1.5 tell 10.0.0.1 > > .......... > > 10.0.0.2.1028>10.0.0.255.3661> udp 80 > > .................... > > > > > > Would appreciate any help a lot. > > Thanks in advance, > > Vinod > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Greetings - send holiday greetings for > Easter, Passover > > http://greetings.yahoo.com/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 1 10:46:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from web21108.mail.yahoo.com (web21108.mail.yahoo.com [216.136.227.110]) by hub.freebsd.org (Postfix) with SMTP id B7B9B37B400 for ; Mon, 1 Apr 2002 10:46:34 -0800 (PST) Message-ID: <20020401184634.75370.qmail@web21108.mail.yahoo.com> Received: from [152.15.24.197] by web21108.mail.yahoo.com via HTTP; Mon, 01 Apr 2002 10:46:34 PST Date: Mon, 1 Apr 2002 10:46:34 -0800 (PST) From: Vinod Subject: help needed with configuring a gateway To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi there.this is a repost of an earlier message.didnt get replies to that one.maybe probably i posted on a sunday:-).trying my luck again. i was trying to create a gateway having one ethernet card(10.0.0.2) and a wireless nic(10.0.1.1). I wanted this gateway to act between a laptop(10.0.1.5) and another pc acting as a firewall/gateway(10.0.0.1). 10.0.0.1-wired----10.0.0.2 gateway 10.0.1.1---wireless---10.0.1.5 Somehow i cant ping from the laptop to the 10.0.0.1 host.i can ping from laptop to the gateway and from gateway to 10.0.0.1.i have done gateway_enable="YES" in /etc/rc.conf. Here's how my routing table looks at the gateway. ------------------------------------------------------ Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.1 UGSc 1 422 fxp0 10/24 link#1 UC 2 0 fxp0 10.0.0.1 0:e0:29:24:4d:d4 UHLW 4 7 fxp0 1047 10.0.0.255 ff:ff:ff:ff:ff:ff UHLWb 1 264 fxp0 10.0.1/24 link#7 UC 0 0 wi0 localhost localhost UH 1 2 lo0 ------------------------------------------------------ i tried to observe if my ping from the laptop is reaching the 10.0.0.1 machine at all by running tcp dump there. i got: testbed1-pc.1028>10.0.0.255.3661 : udp 80 testbed1-pc.1028>10.0.0.255.3661 : udp 80 ......... [Here testbed1-pc is the name of the gateway] Does this tell anything?i am new to all this so have no clue. when i run tcpdump at my gateway and ping the laptop from 10.0.0.1 i see on the screen: arp who-has 10.0.1.5 tell 10.0.0.1 .......... 10.0.0.2.1028>10.0.0.255.3661> udp 80 .................... Am i making a mistake somewhere? Would appreciate any help a lot. Thanks in advance, Vinod __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 1 12:19:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 6AE0637B41A for ; Mon, 1 Apr 2002 12:19:21 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g31KJGS76280; Mon, 1 Apr 2002 12:19:16 -0800 (PST) (envelope-from rizzo) Date: Mon, 1 Apr 2002 12:19:16 -0800 From: Luigi Rizzo To: Peter Brezny Cc: Joost Bekkers , freebsd-net@FreeBSD.ORG Subject: Re: NATD theoretical max and tuning question Message-ID: <20020401121916.B76235@iguana.icir.org> References: <20020401012912.B69717@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Apr 01, 2002 at 11:00:20AM -0500, Peter Brezny wrote: > > Thank everyone for the background. > > So as far as load on natd is concerned, which is better: no idea. As long as you keep the public ip of the NAT host itself distinct from the public IP of the natted hosts, there should be any diffefence (the former distinction is to avoid passing to natd traffic that has no need to be handled by the daemon). cheers luigi > All private networks translated through one public ip address (about 5 class > c networks total) > > or > > A separate public ip for each private network to be translated through. > > Thanks again for your help. > > Peter Brezny > Skyrunner.net > > > > -----Original Message----- > From: Luigi Rizzo [mailto:rizzo@icir.org] > Sent: Monday, April 01, 2002 4:29 AM > To: Joost Bekkers > Cc: Peter Brezny; freebsd-net@FreeBSD.ORG > Subject: Re: NATD theoretical max and tuning question > > > Actually, following other reports on natd performance trashing under > load and with time, I am under the impression that the library used > by natd (libalias ?) might use some heavyweight data structure > (such as linear lists, or hash tables which saturate too early) > to lookup sessions. > > The bug mentioned below is only partly related -- yes it prevents > natd from doing busy-waiting on an interface, but that is only > part of the story. > > cheers > luigi > > On Mon, Apr 01, 2002 at 11:04:59AM +0200, Joost Bekkers wrote: > > On Sun, Mar 31, 2002 at 08:06:16PM -0500, Peter Brezny wrote: > > > I've got a system acting as a router for about 1000 users behind various > > > private networks who are currently all routed through a pII 400 with > 512M > > > ram. > > > > > > Currently all of these private networks are translated through one > public > > > IP. > > > > > > Frequently the natd process will use more than 50% of the cpu. > > > > > > > This is due to a bug in natd which was fixed in 4.5-STABLE > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2878659+0+archive/2002/freebsd- > questions/20020324.freebsd-questions > > > > I personally noticed the same thing, but it stopped after I > > upgraded natd > > > > Greetz Joost > > joost@jodocus.org > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 1 13:39:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns1.hexanet.fr (smtp-out.hexanet.fr [81.23.32.141]) by hub.freebsd.org (Postfix) with ESMTP id 4B2B937B416 for ; Mon, 1 Apr 2002 13:39:43 -0800 (PST) Received: from speedfreak.rural (speedfreak.hexanet.fr [194.98.140.14]) by ns1.hexanet.fr (8.9.3/8.9.3) with ESMTP id XAA99883 for ; Mon, 1 Apr 2002 23:39:41 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Received: from freak (locahost.rural [127.0.0.1]) by freak.rural (8.11.6/8.11.6) with SMTP id g31LZJ901574 for ; Mon, 1 Apr 2002 23:35:19 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Mon, 1 Apr 2002 23:35:18 +0200 From: Christophe Prevotaux To: freebsd-net@freebsd.org Subject: HUT Project Message-Id: <20020401233518.5c47153e.c.prevotaux@hexanet.fr> Organization: HEXANET X-Mailer: Sylpheed version 0.7.1 (GTK+ 1.2.8; i386--freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I was wondering why the FreeBSD core team would think of including the vrrp daemon and loadd to the distribution or let the author of this commit his source for peer reviewing I think the author has asked for this to several people of the FreeBSD team already. This kind of work is much needed IMHO. There is also a neat thing called ethfw that is also part of the HUT project. http://www.bsdshell.net/hut_project.html Maybe it need to be integrated into current and then backported to stable (has it is already stable so it would be forwardported ? to current and backported to stable ??:)) -- -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 1 14:10:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id AC1CA37B419 for ; Mon, 1 Apr 2002 14:10:35 -0800 (PST) Received: from isi.edu (j7oz85wcrz27w6zc@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g31MATT27358; Mon, 1 Apr 2002 14:10:29 -0800 (PST) Message-ID: <3CA8DAD5.2090409@isi.edu> Date: Mon, 01 Apr 2002 14:10:29 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020329 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Christophe Prevotaux Cc: freebsd-net@freebsd.org Subject: Re: HUT Project References: <20020401233518.5c47153e.c.prevotaux@hexanet.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090203000104010207060502" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms090203000104010207060502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Christophe Prevotaux wrote: > I was wondering why the FreeBSD core team would think > of including the vrrp daemon and loadd to the distribution or let > the author of this commit his source for peer reviewing ... > Maybe it need to be integrated into current and then backported > to stable (has it is already stable so it would be forwardported ? > to current and backported to stable ??:)) Disclaimer: I'm not part of the core team (or even a comitter). I briefly looked at the package, and nothing in there seems to depend on kernel mods. Having it be a port should be fine. Aside from that, the thing would benefit from some documentation... :-) Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms090203000104010207060502 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDQwMTIyMTAyOVowIwYJKoZIhvcNAQkEMRYEFGgKDPlaOjyGYeXViF5oGYRgOtQhMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYAQJ53yiVpDEpOIBn7bLAyj5N+fI27yMW6C36rbsB9P+AwH6HD0iS6nX38i+gUhms8J 1SE8g3G4eQaXdSFpSX9Jt1bqXoIXRTmXVyBpHBneXWk2OWq93SCUUje7n2CNPwUb5G8Ifp15 sFVLHSD0wnv6XoZrb4QWuyl+QOj8Pnm4qAAAAAAAAA== --------------ms090203000104010207060502-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 1 14:23:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns1.hexanet.fr (smtp-out.hexanet.fr [81.23.32.141]) by hub.freebsd.org (Postfix) with ESMTP id 284C437B405 for ; Mon, 1 Apr 2002 14:23:13 -0800 (PST) Received: from speedfreak.rural (speedfreak.hexanet.fr [194.98.140.14]) by ns1.hexanet.fr (8.9.3/8.9.3) with ESMTP id AAA00367 for ; Tue, 2 Apr 2002 00:23:12 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Received: from freak (locahost.rural [127.0.0.1]) by speedfreak.rural (8.11.6/8.11.6) with SMTP id g31MMKU02675; Tue, 2 Apr 2002 00:22:22 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Tue, 2 Apr 2002 00:22:19 +0200 From: Christophe Prevotaux To: Lars Eggert Cc: freebsd-net@freebsd.org Subject: Re: HUT Project Message-Id: <20020402002219.058b2860.c.prevotaux@hexanet.fr> In-Reply-To: <3CA8DAD5.2090409@isi.edu> References: <20020401233518.5c47153e.c.prevotaux@hexanet.fr> <3CA8DAD5.2090409@isi.edu> Organization: HEXANET X-Mailer: Sylpheed version 0.7.1 (GTK+ 1.2.8; i386--freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Having this as part of the system would ensure that the integration and future update of the vrppd or loadd would be supported and also that its usage would become more common , self-inducing a greater amount of support for users and better documentation etc.... etc... On Mon, 01 Apr 2002 14:10:29 -0800 Lars Eggert wrote: > Christophe Prevotaux wrote: > > I was wondering why the FreeBSD core team would think > > of including the vrrp daemon and loadd to the distribution or let > > the author of this commit his source for peer reviewing > ... > > Maybe it need to be integrated into current and then backported > > to stable (has it is already stable so it would be forwardported ? > > to current and backported to stable ??:)) > > Disclaimer: I'm not part of the core team (or even a comitter). > > I briefly looked at the package, and nothing in there seems to depend on > kernel mods. Having it be a port should be fine. Aside from that, the > thing would benefit from some documentation... :-) > > Lars > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California > -- -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 1 14:29:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 6318C37B41E for ; Mon, 1 Apr 2002 14:29:05 -0800 (PST) Received: from isi.edu (dd4zz5yewzo8uoa0@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g31MT3T10189; Mon, 1 Apr 2002 14:29:03 -0800 (PST) Message-ID: <3CA8DF2E.8070401@isi.edu> Date: Mon, 01 Apr 2002 14:29:02 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020329 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Christophe Prevotaux Cc: freebsd-net@freebsd.org Subject: Re: HUT Project References: <20020401233518.5c47153e.c.prevotaux@hexanet.fr> <3CA8DAD5.2090409@isi.edu> <20020402002219.058b2860.c.prevotaux@hexanet.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090409060708050009040906" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms090409060708050009040906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Christophe Prevotaux wrote: > Having this as part of the system would ensure that > the integration and future update of the vrppd or loadd > would be supported and also that its usage would become > more common , self-inducing a greater amount of support > for users and better documentation etc.... etc... Ports are "part of the system" in some sense. Do you mean part of the default installation? I'm not sure load-balancing would be useful for the majority of users. (Although it can be very useful for a minority.) Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms090409060708050009040906 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDQwMTIyMjkwMlowIwYJKoZIhvcNAQkEMRYEFBwktTyoyHVjsA85uETeylEFsZIWMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYARQye4EJi5llfgNXA7A8jMQnGBT0HqwHHJBIqYhFwhRkIZ5f3pgOS/niNAQvEUVUEH prACQFlcU4osyl7FK4Rp69EPhNAJIWgUMPOVyYPpc0f/bJKnz1phc0NJnnFtrqpnhYFGeuVJ lig5bV5SgN+d3akB5cYPKsyskvUpV2nFDAAAAAAAAA== --------------ms090409060708050009040906-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 1 15:20:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns1.hexanet.fr (smtp-out.hexanet.fr [81.23.32.141]) by hub.freebsd.org (Postfix) with ESMTP id A714D37B419 for ; Mon, 1 Apr 2002 15:20:12 -0800 (PST) Received: from speedfreak.rural (speedfreak.hexanet.fr [194.98.140.14]) by ns1.hexanet.fr (8.9.3/8.9.3) with ESMTP id BAA00745; Tue, 2 Apr 2002 01:20:11 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Received: from freak (locahost.rural [127.0.0.1]) by speedfreak.rural (8.11.6/8.11.6) with SMTP id g31NKAb02864; Tue, 2 Apr 2002 01:20:10 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Tue, 2 Apr 2002 01:20:10 +0200 From: Christophe Prevotaux To: Lars Eggert Cc: freebsd-net@freebsd.org Subject: Re: HUT Project Message-Id: <20020402012010.6bed9346.c.prevotaux@hexanet.fr> In-Reply-To: <3CA8DF2E.8070401@isi.edu> References: <20020401233518.5c47153e.c.prevotaux@hexanet.fr> <3CA8DAD5.2090409@isi.edu> <20020402002219.058b2860.c.prevotaux@hexanet.fr> <3CA8DF2E.8070401@isi.edu> Organization: HEXANET X-Mailer: Sylpheed version 0.7.1 (GTK+ 1.2.8; i386--freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 01 Apr 2002 14:29:02 -0800 Lars Eggert wrote: > Christophe Prevotaux wrote: > > Having this as part of the system would ensure that > > the integration and future update of the vrppd or loadd > > would be supported and also that its usage would become > > more common , self-inducing a greater amount of support > > for users and better documentation etc.... etc... > > Ports are "part of the system" in some sense. Do you mean part of the > default installation? I'm not sure load-balancing would be useful for > the majority of users. (Although it can be very useful for a minority.) Well maybe not for a majority, but it is surely useful to have it as a part of the system, for the reasons cited above. IMHO > > Lars > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California > -- -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 1 16:56:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from nori.vegan.net (nori.vegan.net [198.143.3.16]) by hub.freebsd.org (Postfix) with ESMTP id 1D10737B41A for ; Mon, 1 Apr 2002 16:56:05 -0800 (PST) Received: from localhost (tony@localhost) by nori.vegan.net (8.11.0/8.11.0) with ESMTP id g2UJJNZ16786 for ; Sat, 30 Mar 2002 14:19:23 -0500 Date: Sat, 30 Mar 2002 14:19:23 -0500 (EST) From: tony bourke To: Subject: tcpCurrEstab in 4.2 Kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I'm doing research into performance metrics, and I've found that SNMP (net-snmp 4.2.3 and net-snmp 5.0pre2) isn't reporting tcpCurrEstab on FreeBSD 4.2, it always resports zero no matter how many connections are actually in ESTABLISHED. tcp.tcpCurrEstab.0 = Gauge32: 0 From the two versions of net-snmp I've used, it looks like that the FreeBSD 4.2 kernel (4.2-RELEASE) just isn't keeping track of tcpCurrEstab, although I couldn't say for sure. Netstat -s doesn't show this metric, and the only place I can got to find out is doing a netstat -n and grep-ing for ESTABLISHED. I don't know where else in FreeBSD to go to see what the Kernel knows about EST connections. Anyone have any insight? Is this an issue with other releases of FreeBSD? Tony To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 1 17:36: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 23F6C37B416 for ; Mon, 1 Apr 2002 17:36:01 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020402013600.PBEE1147.rwcrmhc52.attbi.com@blossom.cjclark.org>; Tue, 2 Apr 2002 01:36:00 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g321ZuH50550; Mon, 1 Apr 2002 17:35:56 -0800 (PST) (envelope-from cjc) Date: Mon, 1 Apr 2002 17:35:56 -0800 From: "Crist J. Clark" To: Lars Eggert Cc: Christophe Prevotaux , freebsd-net@FreeBSD.ORG Subject: Re: HUT Project Message-ID: <20020401173556.D99214@blossom.cjclark.org> References: <20020401233518.5c47153e.c.prevotaux@hexanet.fr> <3CA8DAD5.2090409@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CA8DAD5.2090409@isi.edu>; from larse@ISI.EDU on Mon, Apr 01, 2002 at 02:10:29PM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Apr 01, 2002 at 02:10:29PM -0800, Lars Eggert wrote: > Christophe Prevotaux wrote: > > I was wondering why the FreeBSD core team would think > > of including the vrrp daemon and loadd to the distribution or let > > the author of this commit his source for peer reviewing > ... > > Maybe it need to be integrated into current and then backported > > to stable (has it is already stable so it would be forwardported ? > > to current and backported to stable ??:)) > > Disclaimer: I'm not part of the core team (or even a comitter). > > I briefly looked at the package, and nothing in there seems to depend on > kernel mods. Having it be a port should be fine. Aside from that, the > thing would benefit from some documentation... :-) You've touched on my problem with it, that it _doesn't_ rely on kernel modifciations. It does some very hackish things with BPF devices and clobbering MAC addresses. If someone wants to do this The Right Way, some of it definately needs to live in the kernel. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 1 18:40:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 3252F37B419; Mon, 1 Apr 2002 18:40:28 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020402024027.SRPO7801.rwcrmhc51.attbi.com@InterJet.elischer.org>; Tue, 2 Apr 2002 02:40:27 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA17620; Mon, 1 Apr 2002 18:24:33 -0800 (PST) Date: Mon, 1 Apr 2002 18:24:32 -0800 (PST) From: Julian Elischer To: "Crist J. Clark" Cc: Lars Eggert , Christophe Prevotaux , freebsd-net@FreeBSD.ORG Subject: Re: HUT Project In-Reply-To: <20020401173556.D99214@blossom.cjclark.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 1 Apr 2002, Crist J. Clark wrote: > On Mon, Apr 01, 2002 at 02:10:29PM -0800, Lars Eggert wrote: > > Christophe Prevotaux wrote: > > > I was wondering why the FreeBSD core team would think > > > of including the vrrp daemon and loadd to the distribution or let > > > the author of this commit his source for peer reviewing > > ... > > > Maybe it need to be integrated into current and then backported > > > to stable (has it is already stable so it would be forwardported ? > > > to current and backported to stable ??:)) > > > > Disclaimer: I'm not part of the core team (or even a comitter). > > > > I briefly looked at the package, and nothing in there seems to depend on > > kernel mods. Having it be a port should be fine. Aside from that, the > > thing would benefit from some documentation... :-) > > You've touched on my problem with it, that it _doesn't_ rely on kernel > modifciations. It does some very hackish things with BPF devices and > clobbering MAC addresses. If someone wants to do this The Right Way, > some of it definately needs to live in the kernel. The things using bpf nterfaces could be done by hooking in a netgraph module.. in fact the ethernet packet filter could be completely implemented as such.. > -- > Crist J. Clark | cjclark@alum.mit.edu > | cjclark@jhu.edu > http://people.freebsd.org/~cjc/ | cjc@freebsd.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 2 0: 4:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [194.98.140.18]) by hub.freebsd.org (Postfix) with ESMTP id DB44937B41D; Tue, 2 Apr 2002 00:04:14 -0800 (PST) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.11.6/8.11.6) with SMTP id g32847d00865; Tue, 2 Apr 2002 10:04:08 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Tue, 2 Apr 2002 10:04:07 +0200 From: Christophe =?ISO-8859-1?B?UHLpdm90YXV4?= To: "Crist J. Clark" , freebsd-net@FreeBSD.ORG Cc: spe@selectbourse.net, julian@elischer.org Subject: Re: HUT Project Message-Id: <20020402100407.506b5cca.c.prevotaux@hexanet.fr> In-Reply-To: <20020401173556.D99214@blossom.cjclark.org> References: <20020401233518.5c47153e.c.prevotaux@hexanet.fr> <3CA8DAD5.2090409@isi.edu> <20020401173556.D99214@blossom.cjclark.org> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 1 Apr 2002 17:35:56 -0800 "Crist J. Clark" wrote: > On Mon, Apr 01, 2002 at 02:10:29PM -0800, Lars Eggert wrote: > > Christophe Prevotaux wrote: > > > I was wondering why the FreeBSD core team would think > > > of including the vrrp daemon and loadd to the distribution or let > > > the author of this commit his source for peer reviewing > > ... > > > Maybe it need to be integrated into current and then backported > > > to stable (has it is already stable so it would be forwardported ? > > > to current and backported to stable ??:)) > > > > Disclaimer: I'm not part of the core team (or even a comitter). > > > > I briefly looked at the package, and nothing in there seems to depend on > > kernel mods. Having it be a port should be fine. Aside from that, the > > thing would benefit from some documentation... :-) > > You've touched on my problem with it, that it _doesn't_ rely on kernel > modifciations. It does some very hackish things with BPF devices and > clobbering MAC addresses. If someone wants to do this The Right Way, > some of it definately needs to live in the kernel. I agree with this, so maybe it is a good way for him (the author) to start redoing things the proper way , but I am sure he will need guidance from you (FreeBSD people), I'll aks him if he is ok with this -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 2 8:41:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by hub.freebsd.org (Postfix) with ESMTP id 8A58037B419 for ; Tue, 2 Apr 2002 08:41:47 -0800 (PST) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.6) id g32Gfkp64998 for freebsd-net@freebsd.org; Tue, 2 Apr 2002 11:41:46 -0500 (EST) (envelope-from barney) Date: Tue, 2 Apr 2002 11:41:46 -0500 From: Barney Wolff To: freebsd-net@freebsd.org Subject: Re: HUT Project Message-ID: <20020402114146.A64910@tp.databus.com> References: <20020401233518.5c47153e.c.prevotaux@hexanet.fr> <3CA8DAD5.2090409@isi.edu> <20020401173556.D99214@blossom.cjclark.org> <20020402100407.506b5cca.c.prevotaux@hexanet.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020402100407.506b5cca.c.prevotaux@hexanet.fr>; from c.prevotaux@hexanet.fr on Tue, Apr 02, 2002 at 10:04:07AM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Does anyone have any insight on how this compares to the existing net/freevrrpd port? Without digging at all, it appears that freevrrpd tries to update everybody's ARP tables rather than taking over the MAC address. I wonder how well that would work. -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 2 9: 1:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from exchange.corp.cre8.com (ns.cre8.com [216.135.81.2]) by hub.freebsd.org (Postfix) with ESMTP id 1D39F37B427 for ; Tue, 2 Apr 2002 09:00:18 -0800 (PST) Received: by exchange.corp.cre8.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 12:00:30 -0500 Message-ID: <2F6DCE1EFAB3BC418B5C324F13934C96016C950B@exchange.corp.cre8.com> From: Scott Ullrich To: 'Barney Wolff' , freebsd-net@freebsd.org Subject: RE: HUT Project Date: Tue, 2 Apr 2002 12:00:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA67.E4F124A0" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DA67.E4F124A0 Content-Type: text/plain; charset="iso-8859-1" The HUT Project includes FreeVRRPD. Since Sebastien hasn't rung in here, I will try to clear the air. Sebastien and I are currently rewriting FreeVRRPD to take care of the remaining RFC issues and to cleanup the ARP code. The new version will be completely RFC compliant and will feature a few extra bells and whistles of its own. My development version currently does not update arp cache tables but takes over the Mac. In addition, the master and backup arp address are settable for each VRID. It seems to be running very well if anyone is interested in taking a look at my hacks (no pun intended). Hopefully in the next couple of weeks we will have a new development version posted. Peace, Scott > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com] > Sent: Tuesday, April 02, 2002 11:42 AM > To: freebsd-net@freebsd.org > Subject: Re: HUT Project > > > Does anyone have any insight on how this compares to the existing > net/freevrrpd port? Without digging at all, it appears that freevrrpd > tries to update everybody's ARP tables rather than taking over the > MAC address. I wonder how well that would work. > -- > Barney Wolff > I never met a computer I didn't like. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > ------_=_NextPart_001_01C1DA67.E4F124A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: HUT Project

The HUT Project includes FreeVRRPD.  Since = Sebastien hasn't rung in here, I will try to clear the air.  =

Sebastien and I are currently rewriting FreeVRRPD to = take care of the remaining RFC issues and to cleanup the ARP = code.  The new version will be completely RFC compliant and will = feature a few extra bells and whistles of its own. 

My development version currently does not update arp = cache tables but takes over the Mac.  In addition, the master and = backup arp address are settable for each VRID.  It seems to be = running very well if anyone is interested in taking a look at my hacks = (no pun intended).

Hopefully in the next couple of weeks we will have a = new development version posted.

Peace,

Scott

> -----Original Message-----
> From: Barney Wolff [mailto:barney@databus.com]=
> Sent: Tuesday, April 02, 2002 11:42 AM
> To: freebsd-net@freebsd.org
> Subject: Re: HUT Project
>
>
> Does anyone have any insight on how this = compares to the existing
> net/freevrrpd port?  Without digging at = all, it appears that freevrrpd
> tries to update everybody's ARP tables rather = than taking over the
> MAC address.  I wonder how well that would = work.
> --
> Barney Wolff
> I never met a computer I didn't like.
>
> To Unsubscribe: send mail to = majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the = body of the message
>

------_=_NextPart_001_01C1DA67.E4F124A0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 2 14:23:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from exchmx2.lsuhsc.edu (exchmx2.lsuhsc.edu [155.58.212.90]) by hub.freebsd.org (Postfix) with ESMTP id 3793837B400 for ; Tue, 2 Apr 2002 14:23:19 -0800 (PST) Received: by exchmx2.lsuhsc.edu with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 16:22:09 -0600 Message-ID: From: "Mire, John" To: "'freebsd-net@freebsd.org'" Subject: subscribe Date: Tue, 2 Apr 2002 16:20:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 2 15:36:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id D614837B421 for ; Tue, 2 Apr 2002 15:36:28 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020402233628.OIUT22231.rwcrmhc52.attbi.com@blossom.cjclark.org>; Tue, 2 Apr 2002 23:36:28 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g32NaRD54014; Tue, 2 Apr 2002 15:36:27 -0800 (PST) (envelope-from cjc) Date: Tue, 2 Apr 2002 15:36:27 -0800 From: "Crist J. Clark" To: Scott Ullrich Cc: "'Barney Wolff'" , freebsd-net@FreeBSD.ORG Subject: Re: HUT Project Message-ID: <20020402153627.E52193@blossom.cjclark.org> References: <2F6DCE1EFAB3BC418B5C324F13934C96016C950B@exchange.corp.cre8.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2F6DCE1EFAB3BC418B5C324F13934C96016C950B@exchange.corp.cre8.com>; from sullrich@CRE8.COM on Tue, Apr 02, 2002 at 12:00:30PM -0500 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Apr 02, 2002 at 12:00:30PM -0500, Scott Ullrich wrote: > The HUT Project includes FreeVRRPD. Since Sebastien hasn't rung in here, I > will try to clear the air. > > Sebastien and I are currently rewriting FreeVRRPD to take care of the > remaining RFC issues and to cleanup the ARP code. The new version will be > completely RFC compliant and will feature a few extra bells and whistles of > its own. > > My development version currently does not update arp cache tables but takes > over the Mac. In addition, the master and backup arp address are settable > for each VRID. IIRC, the exact MAC address of the virtual router as a function of VRID is specified in the RFC? -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 2 15:52:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from exchange.corp.cre8.com (ns.cre8.com [216.135.81.2]) by hub.freebsd.org (Postfix) with ESMTP id BBEB237B416; Tue, 2 Apr 2002 15:52:13 -0800 (PST) Received: by exchange.corp.cre8.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 18:52:26 -0500 Message-ID: <2F6DCE1EFAB3BC418B5C324F13934C96016C9521@exchange.corp.cre8.com> From: Scott Ullrich To: "'Crist J. Clark'" , Scott Ullrich Cc: 'Barney Wolff' , freebsd-net@FreeBSD.ORG Subject: RE: HUT Project Date: Tue, 2 Apr 2002 18:52:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DAA1.70DA9E90" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DAA1.70DA9E90 Content-Type: text/plain; charset="iso-8859-1" Correct. The master and backup settings and/will override the RFC. Can anyone suggest a few ways that this could all be improved at the kernel level? -Scott > -----Original Message----- > From: Crist J. Clark [mailto:cjc@FreeBSD.ORG] > Sent: Tuesday, April 02, 2002 6:36 PM > To: Scott Ullrich > Cc: 'Barney Wolff'; freebsd-net@FreeBSD.ORG > Subject: Re: HUT Project > > > On Tue, Apr 02, 2002 at 12:00:30PM -0500, Scott Ullrich wrote: > > The HUT Project includes FreeVRRPD. Since Sebastien hasn't > rung in here, I > > will try to clear the air. > > > > Sebastien and I are currently rewriting FreeVRRPD to take > care of the > > remaining RFC issues and to cleanup the ARP code. The new > version will be > > completely RFC compliant and will feature a few extra bells > and whistles of > > its own. > > > > My development version currently does not update arp cache > tables but takes > > over the Mac. In addition, the master and backup arp > address are settable > > for each VRID. > > IIRC, the exact MAC address of the virtual router as a function of > VRID is specified in the RFC? > -- > Crist J. Clark | cjclark@alum.mit.edu > | cjclark@jhu.edu > http://people.freebsd.org/~cjc/ | cjc@freebsd.org > ------_=_NextPart_001_01C1DAA1.70DA9E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: HUT Project

Correct.  The master and backup settings = and/will override the RFC.  Can anyone suggest a few ways that = this could all be improved at the kernel level?

-Scott


> -----Original Message-----
> From: Crist J. Clark [mailto:cjc@FreeBSD.ORG]
> Sent: Tuesday, April 02, 2002 6:36 PM
> To: Scott Ullrich
> Cc: 'Barney Wolff'; = freebsd-net@FreeBSD.ORG
> Subject: Re: HUT Project
>
>
> On Tue, Apr 02, 2002 at 12:00:30PM -0500, Scott = Ullrich wrote:
> > The HUT Project includes FreeVRRPD.  = Since Sebastien hasn't
> rung in here, I
> > will try to clear the air. 
> >
> > Sebastien and I are currently rewriting = FreeVRRPD to take
> care of the
> > remaining RFC issues and to cleanup the = ARP code.  The new
> version will be
> > completely RFC compliant and will feature = a few extra bells
> and whistles of
> > its own. 
> >
> > My development version currently does not = update arp cache
> tables but takes
> > over the Mac.  In addition, the = master and backup arp
> address are settable
> > for each VRID.
>
> IIRC, the exact MAC address of the virtual = router as a function of
> VRID is specified in the RFC?
> --
> Crist J. = Clark           &= nbsp;         = |     cjclark@alum.mit.edu
>          = ;            = ;            = ;  |     cjclark@jhu.edu
> http://people.freebsd.org/~cjc/    = |     cjc@freebsd.org
>

------_=_NextPart_001_01C1DAA1.70DA9E90-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 2 17: 9:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id A3F5737B419 for ; Tue, 2 Apr 2002 17:09:26 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020403010926.TIEZ21252.rwcrmhc53.attbi.com@blossom.cjclark.org>; Wed, 3 Apr 2002 01:09:26 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g3319Md54301; Tue, 2 Apr 2002 17:09:22 -0800 (PST) (envelope-from cjc) Date: Tue, 2 Apr 2002 17:09:22 -0800 From: "Crist J. Clark" To: Scott Ullrich Cc: "'Barney Wolff'" , freebsd-net@FreeBSD.ORG Subject: Re: HUT Project Message-ID: <20020402170922.G52193@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <2F6DCE1EFAB3BC418B5C324F13934C96016C9521@exchange.corp.cre8.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2F6DCE1EFAB3BC418B5C324F13934C96016C9521@exchange.corp.cre8.com>; from sullrich@CRE8.COM on Tue, Apr 02, 2002 at 06:52:26PM -0500 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Apr 02, 2002 at 06:52:26PM -0500, Scott Ullrich wrote: > Correct. The master and backup settings and/will override the RFC. Can > anyone suggest a few ways that this could all be improved at the kernel > level? I think it was Julian who mentioned netgraph(5)? That probably would be a really good way to try to implement it. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 2 21: 2:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.uninterruptible.net (ns1.uninterruptible.net [216.7.46.11]) by hub.freebsd.org (Postfix) with ESMTP id BA40C37B41C for ; Tue, 2 Apr 2002 21:02:55 -0800 (PST) Received: from Spaz.Catonic.NET (tnt6-216-180-4-189.dialup.HiWAAY.net [216.180.4.189]) by mail.uninterruptible.net (Postfix) with ESMTP id 9918550284 for ; Wed, 3 Apr 2002 05:02:49 +0000 (GMT) Received: by Spaz.Catonic.NET (Postfix, from userid 1002) id A16193332; Wed, 3 Apr 2002 05:02:47 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by Spaz.Catonic.NET (Postfix) with ESMTP id 627044C4B for ; Wed, 3 Apr 2002 05:02:47 +0000 (GMT) Date: Wed, 3 Apr 2002 05:02:47 +0000 (GMT) From: Kris Kirby To: Subject: VPN / VLAN? Message-ID: X-Tech-Support-Email: bofh@catonic.net Organization: Non Illegitemus Carborundum Inc. X-Disclaimer: My opinions are not those of my employer(s). X-Driving-The-Information-Superhighway-Joke: Asleep at the wheel. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Let say I have a machine I want to attach to internet subnet 216.6.6.129/25. But the machine is at my house, NAT'd from the world. So to network the machine, I'd have to "bridge" across something like a VLAN over an IPSEC tunnel. Is this right? Can it be done that way? Is the IPSEC tunnel even necessary (if I don't care about security)? Finally, can FreeBSD bridge a subnet attached to a public interface on the big bad old internet to the other side of the world? -- Kris Kirby, KE4AHR | TGIFreeBSD... 'Nuff said. | IM: KrisBSD | HSV, AL. ------------------------------------------------------- "Fate, it seems, is not without a sense of irony." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 2 23: 7: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from melchior.cuivre.fr.eu.org (melchior.enst.fr [137.194.161.6]) by hub.freebsd.org (Postfix) with ESMTP id ED26437B417 for ; Tue, 2 Apr 2002 23:07:01 -0800 (PST) Received: from melusine.cuivre.fr.eu.org (melusine.enst.fr [137.194.160.34]) by melchior.cuivre.fr.eu.org (Postfix) with ESMTP id D1FF2762D for ; Wed, 3 Apr 2002 09:06:59 +0200 (CEST) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id C9C4D2C3D1; Wed, 3 Apr 2002 09:06:58 +0200 (CEST) Date: Wed, 3 Apr 2002 09:06:58 +0200 From: Thomas Quinot To: freebsd-net@freebsd.org Subject: Userland ppp hung in Ack-Rcvd Message-ID: <20020403090658.A65499@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I observed a peculiar situation today on an ADSL link using pptpclient and the userland ppp daemon: the LCP negociation hunk in state Ack-Rcvd for almost 3 hours (until I killed it) without any progress, but without timing out, either. Here is an excerpt from the log: Apr 3 05:25:02 melusine ppp[53064]: tun0: LCP: deflink: State change Initial --> Closed Apr 3 05:25:02 melusine ppp[53064]: tun0: LCP: deflink: State change Closed --> Stopped Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: deflink: LayerStart Apr 3 05:25:03 melusine ppp[53064]: tun0: Warning: deflink: Reducing configured MRU from 1500 to 1480 Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: ACFCOMP[2] Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: PROTOCOMP[2] Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: ACCMAP[6] 0x00000000 Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: MRU[4] 1480 Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: MAGICNUM[6] 0x91e371fe Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: deflink: State change Stopped --> Req-Sent Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: ACFCOMP[2] Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: PROTOCOMP[2] Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: ACCMAP[6] 0x00000000 Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: MRU[4] 1480 Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: MAGICNUM[6] 0x91e371fe Apr 3 05:25:09 melusine ppp[53064]: tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: ACFCOMP[2] Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: PROTOCOMP[2] Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: ACCMAP[6] 0x00000000 Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: MRU[4] 1480 Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: MAGICNUM[6] 0x91e371fe Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: deflink: RecvConfigAck(1) state = Req-Sent Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: deflink: State change Req-Sent --> Ack-Rcvd Apr 3 08:11:27 melusine ppp[53064]: tun0: Phase: Signal 15, terminate. In other sessions that I have a trace of, I never enter Ack-Recvd, but instead: Apr 3 08:12:07 melusine ppp[61776]: tun0: LCP: deflink: RecvConfigReq(224) state = Req-Sent This box is running 4.5-STABLE kernel and world cvsuppsed 10 days or so ago. Any idea why it did not time out? Thomas. -- Thomas.Quinot@Cuivre.FR.EU.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 2: 3: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from sbserv0.intra.selectbourse.net (APuteaux-107-2-1-3.abo.wanadoo.fr [217.128.228.3]) by hub.freebsd.org (Postfix) with ESMTP id 75EB437B417 for ; Wed, 3 Apr 2002 02:03:00 -0800 (PST) Received: from there (artik.intra.selectbourse.net [172.16.2.3]) by sbserv0.intra.selectbourse.net (Postfix) with SMTP id E148FBADD; Wed, 3 Apr 2002 12:01:44 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Sebastien Petit To: cjclark@alum.mit.edu, "Crist J. Clark" , Scott Ullrich Subject: Re: HUT Project Date: Wed, 3 Apr 2002 12:06:20 +0200 X-Mailer: KMail [version 1.3.2] Cc: "'Barney Wolff'" , freebsd-net@FreeBSD.ORG References: <2F6DCE1EFAB3BC418B5C324F13934C96016C9521@exchange.corp.cre8.com> <20020402170922.G52193@blossom.cjclark.org> In-Reply-To: <20020402170922.G52193@blossom.cjclark.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020403100144.E148FBADD@sbserv0.intra.selectbourse.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wednesday 03 April 2002 03:09, Crist J. Clark wrote: > On Tue, Apr 02, 2002 at 06:52:26PM -0500, Scott Ullrich wrote: > > Correct. The master and backup settings and/will override the RFC. Can > > anyone suggest a few ways that this could all be improved at the kernel > > level? > > I think it was Julian who mentioned netgraph(5)? That probably would > be a really good way to try to implement it. Hi, freevrrpd actually use RFC MAC addresses (00:00:5E:00:01:VRID) as ethernet source address when it send to the multicast address (as described in the RFC). Actually, FreeBSD doesn't support multiple ethernet address on one physical interface (as I know). Then I must use BPF for sending VRRP packets with the normalized RFC2338 ethernet address. Is there a way to do real aliases (one ethernet address and one IP address) on a specified physical interface ? Design of freevrrpd cause a problem actually because when a MASTER server leave LAN (cable problem), SLAVE take his place and send gratuitous ARP for update ARP cache of all hosts on the same LAN. Normally, I don't need that if I can set one ethernet address and one VIP on one alias. This method cause a problem when MASTER is living again because it don't send any Gratuitous ARP for reupdating all ARP caches of all hosts on the same LAN with his ethernet address. So, my question is simple, is there a mechanism like netgraph or TAP that permits me to do that: xl0: flags=8843 mtu 1500 options=3 /* Real address of the server on the first LAN 1 */ inet 172.16.1.1 netmask 0xffff0000 broadcast 172.16.255.255 ether 00:b0:d0:5e:3a:04 xl1: flags=8843 mtu 1500 options=3 /* Real address of the server on the LAN 2 */ inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255 ether 00:b0:d0:5e:3a:10 /* Alias on xl0 with ethernet address 00:00:5E:00:01:01 because this is the VRID 1 */ xl0:0: flags=8843 mtu 1500 options=3 inet 172.16.2.1 netmask 0xffff0000 broadcast 172.16.255.255 ether 00:00:5E:00:01:01 /* Alias on xl1 with ethernet address 00:00:5E:00:01:01 becasue this is the VRID 1 on the LAN 2 (not the same as LAN1) */ xl1:0: flags=8843 mtu 1500 options=3 inet 10.0.1.1 netmask 0xff000000 broadcast 10.255.255.255 ether 00:00:5E:00:01:01 I think that TAP interface cannot permit me to do that because I can't attach one tap interface on one physical interface. I can have multiple 00:00:5E:00:01:01 MAC addresses on multiple LAN connected on multiple physical interfaces of the same host. My wish is to implement VRRP as clean as I can but there is some limitations... Any idea to implement that correctly under FreeBSD ? Sebastien. -- spe@selectbourse.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 2:30:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from serio.al.rim.or.jp (serio.al.rim.or.jp [202.247.191.123]) by hub.freebsd.org (Postfix) with ESMTP id 74B8A37B416; Wed, 3 Apr 2002 02:30:11 -0800 (PST) Received: from mail2.rim.or.jp by serio.al.rim.or.jp (3.7W/HMX-13) id TAA01787; Wed, 3 Apr 2002 19:30:10 +0900 (JST) Received: from bougainvillea.FromTo.Cc (shell.al.rim.or.jp [202.247.191.81]) by mail2.rim.or.jp (8.9.3/3.7W) id TAA15543; Wed, 3 Apr 2002 19:30:07 +0900 (JST) Date: Wed, 03 Apr 2002 19:31:16 +0900 Message-ID: <86zo0lqdjf.wl@bougainvillea.FromTo.Cc> From: Tatsumi Hosokawa To: freebsd-net@freebsd.org Cc: hosokawa@freebsd.org Subject: Please review: ppp(8) and RADIUS address allocation User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, all. I'm testing to use FreeBSD box as PPPoE server and found that ppp(8) uses 255.255.255.254 (special address to get IP address from NAS pool defined in RADIUS protocol) as p2p address when "set radius" is used in ppp.conf. I found the same trouble at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=299723+0+archive/2001/freebsd-net/20010812.freebsd-net Following patch can fix this problem. Please review it. Thanks. diff -ur /var/tmp/src/usr.sbin/ppp/auth.c ppp/auth.c --- /var/tmp/src/usr.sbin/ppp/auth.c Thu Jun 14 06:56:33 2001 +++ ppp/auth.c Wed Apr 3 19:05:58 2002 @@ -156,7 +156,8 @@ } #ifndef NORADIUS - if (bundle->radius.valid && bundle->radius.ip.s_addr != INADDR_NONE) { + if (bundle->radius.valid && bundle->radius.ip.s_addr != INADDR_NONE && + bundle->radius.ip.s_addr != RADIUS_INADDR_POOL) { /* We've got a radius IP - it overrides everything */ if (!ipcp_UseHisIPaddr(bundle, bundle->radius.ip)) return 0; diff -ur /var/tmp/src/usr.sbin/ppp/radius.h ppp/radius.h --- /var/tmp/src/usr.sbin/ppp/radius.h Fri May 18 04:11:48 2001 +++ ppp/radius.h Wed Apr 3 19:06:11 2002 @@ -76,3 +76,6 @@ #define RAD_START 1 #define RAD_STOP 2 #endif + +/* Get address from NAS pool */ +#define RADIUS_INADDR_POOL 0xfeffffff /* 255.255.255.254 */ -- Tatsumi Hosokawa http://FromTo.Cc/hosokawa/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 9:31: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 5A28937B41E; Wed, 3 Apr 2002 09:30:02 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id JAA51733; Wed, 3 Apr 2002 09:23:57 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g33HNDa75761; Wed, 3 Apr 2002 09:23:13 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200204031723.g33HNDa75761@arch20m.dellroad.org> Subject: Re: Please review: ppp(8) and RADIUS address allocation In-Reply-To: <86zo0lqdjf.wl@bougainvillea.FromTo.Cc> "from Tatsumi Hosokawa at Apr 3, 2002 07:31:16 pm" To: Tatsumi Hosokawa Date: Wed, 3 Apr 2002 09:23:13 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Tatsumi Hosokawa writes: > Following patch can fix this problem. Please review it. > > - if (bundle->radius.valid && bundle->radius.ip.s_addr != INADDR_NONE) { > + if (bundle->radius.valid && bundle->radius.ip.s_addr != INADDR_NONE && > + bundle->radius.ip.s_addr != RADIUS_INADDR_POOL) { > /* We've got a radius IP - it overrides everything */ > if (!ipcp_UseHisIPaddr(bundle, bundle->radius.ip)) > return 0; > diff -ur /var/tmp/src/usr.sbin/ppp/radius.h ppp/radius.h > --- /var/tmp/src/usr.sbin/ppp/radius.h Fri May 18 04:11:48 2001 > +++ ppp/radius.h Wed Apr 3 19:06:11 2002 > @@ -76,3 +76,6 @@ > #define RAD_START 1 > #define RAD_STOP 2 > #endif > + > +/* Get address from NAS pool */ > +#define RADIUS_INADDR_POOL 0xfeffffff /* 255.255.255.254 */ This patch will only work for little-endian machines. Suggest you put some htonl() and ntohl() in there. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 10:14:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by hub.freebsd.org (Postfix) with ESMTP id C86EF37B4C9 for ; Wed, 3 Apr 2002 10:13:16 -0800 (PST) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.1/8.12.1) with ESMTP id g33IDFpt033980 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 3 Apr 2002 10:13:16 -0800 (PST)?g (envelope-from sam@errno.com)œ Message-ID: <2c1d01c1db3b$460c7720$52557f42@errno.com> From: "Sam Leffler" To: Subject: kame ipsec vs. openbsd ipsec Date: Wed, 3 Apr 2002 10:13:35 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm slogging through the KAME IPsec code looking at adding support for crypto hardware (and NICs that do onboard IPSEC processing). The OpenBSD IPsec implementation already has this and doing something similar to what OpenBSD has done requires restructuring large parts of the KAME code in a similar way. (It's also likely to have repercussions throughout the rest of the inet code.) So it seems I can either muck with the KAME code or integrate the OpenBSD code instead. Both options are a lot of work so I thought I'd solicit some feedback first. 1. Has anyone else seriously looked at doing this? 2. Has anyone compared the OpenBSD and KAME implementations and understand their relative strengths? (e.g. is there some reason to work with KAME other than it's already in the system) I found an old port of the OpenBSD code to FreeBSD but that was abandoned. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 10:40:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id D828537B417 for ; Wed, 3 Apr 2002 10:40:12 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020403184012.PYMO15826.rwcrmhc54.attbi.com@InterJet.elischer.org>; Wed, 3 Apr 2002 18:40:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA26573; Wed, 3 Apr 2002 10:37:22 -0800 (PST) Date: Wed, 3 Apr 2002 10:37:22 -0800 (PST) From: Julian Elischer To: Sam Leffler Cc: freebsd-net@freebsd.org Subject: Re: kame ipsec vs. openbsd ipsec In-Reply-To: <2c1d01c1db3b$460c7720$52557f42@errno.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org have you asked the KAME people if they have plans to do such suppport themselves? On Wed, 3 Apr 2002, Sam Leffler wrote: > I'm slogging through the KAME IPsec code looking at adding support for > crypto hardware (and NICs that do onboard IPSEC processing). The OpenBSD > IPsec implementation already has this and doing something similar to what > OpenBSD has done requires restructuring large parts of the KAME code in a > similar way. (It's also likely to have repercussions throughout the rest of > the inet code.) So it seems I can either muck with the KAME code or > integrate the OpenBSD code instead. Both options are a lot of work so I > thought I'd solicit some feedback first. > > 1. Has anyone else seriously looked at doing this? > 2. Has anyone compared the OpenBSD and KAME implementations and understand > their relative strengths? (e.g. is there some reason to work with KAME other > than it's already in the system) > > I found an old port of the OpenBSD code to FreeBSD but that was abandoned. > > Sam > > > 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 Wed Apr 3 10:41: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 732DB37B420 for ; Wed, 3 Apr 2002 10:40:25 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020403184022.PYQL15826.rwcrmhc54.attbi.com@InterJet.elischer.org>; Wed, 3 Apr 2002 18:40:22 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA26531; Wed, 3 Apr 2002 10:24:54 -0800 (PST) Date: Wed, 3 Apr 2002 10:24:53 -0800 (PST) From: Julian Elischer To: Sebastien Petit Cc: cjclark@alum.mit.edu, "Crist J. Clark" , Scott Ullrich , "'Barney Wolff'" , freebsd-net@FreeBSD.ORG Subject: Re: HUT Project In-Reply-To: <20020403100144.E148FBADD@sbserv0.intra.selectbourse.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 3 Apr 2002, Sebastien Petit wrote: > > freevrrpd actually use RFC MAC addresses (00:00:5E:00:01:VRID) as ethernet > source address when it send to the multicast address (as described in the > RFC). Actually, FreeBSD doesn't support multiple ethernet address on one > physical interface (as I know). Then I must use BPF for sending VRRP packets > with the normalized RFC2338 ethernet address. The closest you are going to find is the netgraph ethernet interface.. it allows you yo have complete control of the interface. > Is there a way to do real aliases (one ethernet address and one IP address) > on a specified physical interface ? yes.. netgraph can do that with the bpf node and the eiface node however you may be able to do better by writing your own node to do specifically what you want. > Design of freevrrpd cause a problem actually because when a MASTER server > leave LAN (cable problem), SLAVE take his place and send gratuitous ARP for > update ARP cache of all hosts on the same LAN. Normally, I don't need that if > I can set one ethernet address and one VIP on one alias. This method cause a > problem when MASTER is living again because it don't send any Gratuitous ARP > for reupdating all ARP caches of all hosts on the same LAN with his ethernet > address. > So, my question is simple, is there a mechanism like netgraph or TAP that > permits me to do that: > > xl0: flags=8843 mtu 1500 > options=3 > /* Real address of the server on the first LAN 1 */ > inet 172.16.1.1 netmask 0xffff0000 broadcast 172.16.255.255 > ether 00:b0:d0:5e:3a:04 > > xl1: flags=8843 mtu 1500 > options=3 > /* Real address of the server on the LAN 2 */ > inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255 > ether 00:b0:d0:5e:3a:10 > > /* Alias on xl0 with ethernet address 00:00:5E:00:01:01 because this is the > VRID 1 */ > xl0:0: flags=8843 mtu 1500 > options=3 > inet 172.16.2.1 netmask 0xffff0000 broadcast 172.16.255.255 > ether 00:00:5E:00:01:01 > > /* Alias on xl1 with ethernet address 00:00:5E:00:01:01 becasue this is the > VRID 1 on the LAN 2 (not the same as LAN1) */ > xl1:0: flags=8843 mtu 1500 > options=3 > inet 10.0.1.1 netmask 0xff000000 broadcast 10.255.255.255 > ether 00:00:5E:00:01:01 > > I think that TAP interface cannot permit me to do that because I can't attach > one tap interface on one physical interface. I can have multiple > 00:00:5E:00:01:01 MAC addresses on multiple LAN connected on multiple > physical interfaces of the same host. > My wish is to implement VRRP as clean as I can but there is some > limitations... > Any idea to implement that correctly under FreeBSD ? > > Sebastien. > -- > spe@selectbourse.net > > 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 Wed Apr 3 10:41:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id C731237B405 for ; Wed, 3 Apr 2002 10:41:30 -0800 (PST) Received: from isi.edu (6wehvo33wq5vfpz5@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g33IfLT06627; Wed, 3 Apr 2002 10:41:21 -0800 (PST) Message-ID: <3CAB4CD0.9040508@isi.edu> Date: Wed, 03 Apr 2002 10:41:20 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020329 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Kris Kirby Cc: freebsd-net@freebsd.org Subject: Re: VPN / VLAN? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040304090005000704070801" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms040304090005000704070801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kris Kirby wrote: > Let say I have a machine I want to attach to internet subnet > 216.6.6.129/25. But the machine is at my house, NAT'd from the world. So > to network the machine, I'd have to "bridge" across something like a VLAN > over an IPSEC tunnel. Is this right? Can it be done that way? Is the IPSEC > tunnel even necessary (if I don't care about security)? We have a vtun setup (tethered.net) that does just that (relay the real Internet to the inside of a NAT box) to support DARPA PI meetings. We're currently documenting the thing and will put up a website with descriptions and the config scripts. Ping me again in a few days if you haven't heard from me :-) What is required to make this work though is that you can get a few static IPs inside the 216.6.6.129/25 net (in your example) to relay. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms040304090005000704070801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDQwMzE4NDEyMFowIwYJKoZIhvcNAQkEMRYEFEpaK6g68AFrBEzXsnuuIfdcaBJMMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYCi3wmzEjAGDesRgmd8M/aN04nybnCeztY2Lco1Fw93kRpRSrFRkwyGCFnfLnbbnxlr SdMUoto4c2ZR556WJJS1ag0WoHQib5aOJCxiJVnS7OcsiZFJI7p9otW//iIf6yLvWNNuorSD sRwWIO/xoJMOwOAduG779h6W4rJ5AjQTyQAAAAAAAA== --------------ms040304090005000704070801-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 10:46:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by hub.freebsd.org (Postfix) with ESMTP id 70C0937B416 for ; Wed, 3 Apr 2002 10:46:29 -0800 (PST) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.1/8.12.1) with ESMTP id g33IkPpt034121 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 3 Apr 2002 10:46:26 -0800 (PST)?g (envelope-from sam@errno.com)œ Message-ID: <2c7701c1db3f$e8393390$52557f42@errno.com> From: "Sam Leffler" To: "Julian Elischer" Cc: References: Subject: Re: kame ipsec vs. openbsd ipsec Date: Wed, 3 Apr 2002 10:46:46 -0800 Organization: Errno Consulting 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Yes and no. I was told they wanted to add hardware support but I've been unable to reach the "right people" to start a dialogue, which is why I sent my note. Sam ----- Original Message ----- From: "Julian Elischer" To: "Sam Leffler" Cc: Sent: Wednesday, April 03, 2002 10:37 AM Subject: Re: kame ipsec vs. openbsd ipsec > have you asked the KAME people if they have plans to > do such suppport themselves? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 10:51:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id 56D7A37B419 for ; Wed, 3 Apr 2002 10:51:18 -0800 (PST) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.11.6/8.11.6) with SMTP id g32I8kd09452 for ; Tue, 2 Apr 2002 20:08:47 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Tue, 2 Apr 2002 20:08:46 +0200 From: Christophe =?ISO-8859-1?B?UHLpdm90YXV4?= To: freebsd-net@freebsd.org Subject: Firewall rules renumbering or rule number step Message-Id: <20020402200846.6c8793bf.c.prevotaux@hexanet.fr> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi I have reached the 655 firewalling rules limit (with discrete values) in ipfw and I was wondering why ipfw will not let the user select the incremental step value in rules numbering ? also it should be possible to renumber these rules on the fly (though, i agree this is not this useful) -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 10:51:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id BECB137B417 for ; Wed, 3 Apr 2002 10:51:20 -0800 (PST) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.11.6/8.11.6) with SMTP id g32IQEd09535; Tue, 2 Apr 2002 20:26:14 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Tue, 2 Apr 2002 20:26:14 +0200 From: Christophe =?ISO-8859-1?B?UHLpdm90YXV4?= To: Scott Ullrich Cc: freebsd-net@freebsd.org Subject: Re: HUT Project Message-Id: <20020402202614.2cb6b471.c.prevotaux@hexanet.fr> In-Reply-To: <2F6DCE1EFAB3BC418B5C324F13934C96016C950B@exchange.corp.cre8.com> References: <2F6DCE1EFAB3BC418B5C324F13934C96016C950B@exchange.corp.cre8.com> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 2 Apr 2002 12:00:30 -0500 Scott Ullrich wrote: > The HUT Project includes FreeVRRPD. Since Sebastien hasn't rung in here, I > will try to clear the air. > > Sebastien and I are currently rewriting FreeVRRPD to take care of the > remaining RFC issues and to cleanup the ARP code. The new version will be > completely RFC compliant and will feature a few extra bells and whistles of > its own. Yes but it has been said that this should better belong in the kernel and that seems to be the reason why it has not gained wider acceptance among freebsd commiter. (just my 2 cents :)) ----------------------- I quote ------------------------------------------ You've touched on my problem with it, that it _doesn't_ rely on kernel modifciations. It does some very hackish things with BPF devices and clobbering MAC addresses. If someone wants to do this The Right Way, some of it definately needs to live in the kernel. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org --------------------------------------------------------------------------- > > My development version currently does not update arp cache tables but takes > over the Mac. In addition, the master and backup arp address are settable > for each VRID. It seems to be running very well if anyone is interested in > taking a look at my hacks (no pun intended). > > Hopefully in the next couple of weeks we will have a new development version > posted. > > Peace, > > Scott > > > -----Original Message----- > > From: Barney Wolff [mailto:barney@databus.com] > > Sent: Tuesday, April 02, 2002 11:42 AM > > To: freebsd-net@freebsd.org > > Subject: Re: HUT Project > > > > > > Does anyone have any insight on how this compares to the existing > > net/freevrrpd port? Without digging at all, it appears that freevrrpd > > tries to update everybody's ARP tables rather than taking over the > > MAC address. I wonder how well that would work. > > -- > > Barney Wolff > > I never met a computer I didn't like. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 10:54: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id B358737B417 for ; Wed, 3 Apr 2002 10:53:52 -0800 (PST) Received: from isi.edu (9fdijyx36emy0wbk@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g33IrnT14994; Wed, 3 Apr 2002 10:53:49 -0800 (PST) Message-ID: <3CAB4FBC.7060904@isi.edu> Date: Wed, 03 Apr 2002 10:53:48 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020329 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Sam Leffler Cc: Julian Elischer , freebsd-net@freebsd.org Subject: Re: kame ipsec vs. openbsd ipsec References: <2c7701c1db3f$e8393390$52557f42@errno.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060506070601000704010803" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms060506070601000704010803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sam Leffler wrote: > Yes and no. I was told they wanted to add hardware support but I've been > unable to reach the "right people" to start a dialogue, which is why I sent > my note. Try snap-users@kame.net; you'll have a response in a few hours (when daylight hits Japan :-) Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms060506070601000704010803 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDQwMzE4NTM0OFowIwYJKoZIhvcNAQkEMRYEFNlK6GWMN+fEDW24btJuhKY8xXNLMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYClmGldH7hJGS1XJ5ES9wY/SSFelKhtoC3+45mPy3Nl3qS6gTm4nt80fsecPz0j662E eqwIx3a2oWVR2FYYSzyxAhfB62YQe7PA8utkABlbQR3iFUxqFe8E3ZJrJV/CoJBi9Lvsxd+K w5qFEwk42KKEGOZXj7GnoHzcqKTNEd2YtAAAAAAAAA== --------------ms060506070601000704010803-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 10:59:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id 0E2A637B41E for ; Wed, 3 Apr 2002 10:59:25 -0800 (PST) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.11.6/8.11.6) with SMTP id g33IxOD05335 for ; Wed, 3 Apr 2002 20:59:24 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Wed, 3 Apr 2002 20:59:23 +0200 From: Christophe =?ISO-8859-1?B?UHLpdm90YXV4?= To: freebsd-net@freebsd.org Subject: IPFW Max Rule Discrete Number Limit Message-Id: <20020403205923.27d35e11.c.prevotaux@hexanet.fr> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi I have reached the 655 firewalling rules limit (with discrete values) in ipfw and I was wondering why ipfw will not let the user select the incremental step value in rules numbering ? also it should be possible to renumber these rules on the fly (though, i agree this is not this useful) -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 11:15:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id A498337B41D for ; Wed, 3 Apr 2002 11:15:52 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g33JFjA98251; Wed, 3 Apr 2002 11:15:45 -0800 (PST) (envelope-from rizzo) Date: Wed, 3 Apr 2002 11:15:45 -0800 From: Luigi Rizzo To: Christophe =?iso-8859-1?Q?Pr=E9votaux?= Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPFW Max Rule Discrete Number Limit Message-ID: <20020403111545.A98202@iguana.icir.org> References: <20020403205923.27d35e11.c.prevotaux@hexanet.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20020403205923.27d35e11.c.prevotaux@hexanet.fr> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Apr 03, 2002 at 08:59:23PM +0200, Christophe Prévotaux wrote: > Hi > > I have reached the 655 firewalling rules limit (with discrete values) > in ipfw and I was wondering why ipfw will not let the user select > the incremental step value in rules numbering ? also it should be > possible to renumber these rules on the fly > (though, i agree this is not this useful) you know you can assign explicit numbers to rules ? There is alot of magic you can do in userland rather than relying on the kernel to cope with all sorts of different user requirements... cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 11:40:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 94ACC37B405 for ; Wed, 3 Apr 2002 11:40:19 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020403194019.TPMG22231.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 3 Apr 2002 19:40:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA26808; Wed, 3 Apr 2002 11:21:41 -0800 (PST) Date: Wed, 3 Apr 2002 11:21:40 -0800 (PST) From: Julian Elischer To: Christophe =?ISO-8859-1?B?UHLpdm90YXV4?= Cc: freebsd-net@freebsd.org Subject: Re: Firewall rules renumbering or rule number step In-Reply-To: <20020402200846.6c8793bf.c.prevotaux@hexanet.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 2 Apr 2002, Christophe [ISO-8859-1] Pr=E9votaux wrote: > Hi >=20 > I have reached the 655 firewalling rules limit (with discrete values) > in ipfw and I was wondering why ipfw will not let the user select > the incremental step value in rules numbering ? also it should be > possible to renumber these rules on the fly=20 > (though, i agree this is not this useful) If you do yuor own numberring you an certainly do more than that.. a 'renumber' wouldn't be that hard I think.. patches accepted :-) basicaly..=20 pass 1: ensure the 'skipto' caches are all filled out... pass 2: renumber... pass3: change the numbers on skipto commands to the new number pointed to by the cached pointer. >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Christophe Prevotaux Email: c.prevotaux@hexanet.fr > HEXANET SARL URL: http://www.hexanet.fr/ > Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05=20 > 3 All=E9e Thierry Sabine Direct: +33 (0)3 26 79 08 02=20 > BP202 Fax: +33 (0)3 26 79 30 06 > 51686 Reims Cedex 2 =09=09 =20 > FRANCE HEXANET Network Operation Center =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 12: 2:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by hub.freebsd.org (Postfix) with ESMTP id 3E8B237B405; Wed, 3 Apr 2002 12:02:39 -0800 (PST) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.6) id g33K2cd77015; Wed, 3 Apr 2002 15:02:38 -0500 (EST) (envelope-from barney) Date: Wed, 3 Apr 2002 15:02:38 -0500 From: Barney Wolff To: Tatsumi Hosokawa Cc: freebsd-net@FreeBSD.ORG Subject: Re: Please review: ppp(8) and RADIUS address allocation Message-ID: <20020403150238.C76772@tp.databus.com> References: <86zo0lqdjf.wl@bougainvillea.FromTo.Cc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <86zo0lqdjf.wl@bougainvillea.FromTo.Cc>; from hosokawa@FreeBSD.ORG on Wed, Apr 03, 2002 at 07:31:16PM +0900 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org And what would this code do on a Sparc? Don't assume little-endian hardware. As this is hardly time-critical code, memcmp or equivalent is fine. On Wed, Apr 03, 2002 at 07:31:16PM +0900, Tatsumi Hosokawa wrote: > Hi, all. > > I'm testing to use FreeBSD box as PPPoE server and found that ppp(8) > uses 255.255.255.254 (special address to get IP address from NAS pool > defined in RADIUS protocol) as p2p address when "set radius" is used > in ppp.conf. I found the same trouble at > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=299723+0+archive/2001/freebsd-net/20010812.freebsd-net > > Following patch can fix this problem. Please review it. > > Thanks. > > diff -ur /var/tmp/src/usr.sbin/ppp/auth.c ppp/auth.c > --- /var/tmp/src/usr.sbin/ppp/auth.c Thu Jun 14 06:56:33 2001 > +++ ppp/auth.c Wed Apr 3 19:05:58 2002 > @@ -156,7 +156,8 @@ > } > > #ifndef NORADIUS > - if (bundle->radius.valid && bundle->radius.ip.s_addr != INADDR_NONE) { > + if (bundle->radius.valid && bundle->radius.ip.s_addr != INADDR_NONE && > + bundle->radius.ip.s_addr != RADIUS_INADDR_POOL) { > /* We've got a radius IP - it overrides everything */ > if (!ipcp_UseHisIPaddr(bundle, bundle->radius.ip)) > return 0; > diff -ur /var/tmp/src/usr.sbin/ppp/radius.h ppp/radius.h > --- /var/tmp/src/usr.sbin/ppp/radius.h Fri May 18 04:11:48 2001 > +++ ppp/radius.h Wed Apr 3 19:06:11 2002 > @@ -76,3 +76,6 @@ > #define RAD_START 1 > #define RAD_STOP 2 > #endif > + > +/* Get address from NAS pool */ > +#define RADIUS_INADDR_POOL 0xfeffffff /* 255.255.255.254 */ > > -- > Tatsumi Hosokawa > > http://FromTo.Cc/hosokawa/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 15:50:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from serio.al.rim.or.jp (serio.al.rim.or.jp [202.247.191.123]) by hub.freebsd.org (Postfix) with ESMTP id A47F137B419; Wed, 3 Apr 2002 15:50:13 -0800 (PST) Received: from mail2.rim.or.jp by serio.al.rim.or.jp (3.7W/HMX-13) id IAA00684; Thu, 4 Apr 2002 08:50:12 +0900 (JST) Received: from bougainvillea.FromTo.Cc (shell.al.rim.or.jp [202.247.191.81]) by mail2.rim.or.jp (8.9.3/3.7W) id IAA06942; Thu, 4 Apr 2002 08:50:11 +0900 (JST) Date: Thu, 04 Apr 2002 08:51:23 +0900 Message-ID: <86hems5ojo.wl@bougainvillea.FromTo.Cc> From: Tatsumi Hosokawa To: Barney Wolff Cc: Tatsumi Hosokawa , freebsd-net@FreeBSD.ORG Subject: Re: Please review: ppp(8) and RADIUS address allocation In-Reply-To: <20020403150238.C76772@tp.databus.com> References: <86zo0lqdjf.wl@bougainvillea.FromTo.Cc> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At Wed, 3 Apr 2002 15:02:38 -0500, Barney Wolff wrote: > > And what would this code do on a Sparc? Don't assume little-endian > hardware. As this is hardly time-critical code, memcmp or equivalent > is fine. Oops, sorry. I'll use htonl(0xfffffffe) instead. I don't think it isn't time critical code because it executed only once per auth session of ppp. -- Tatsumi Hosokawa http://FromTo.Cc/hosokawa/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 15:52:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from serio.al.rim.or.jp (serio.al.rim.or.jp [202.247.191.123]) by hub.freebsd.org (Postfix) with ESMTP id E298D37B41E; Wed, 3 Apr 2002 15:52:02 -0800 (PST) Received: from mail2.rim.or.jp by serio.al.rim.or.jp (3.7W/HMX-13) id IAA00787; Thu, 4 Apr 2002 08:52:02 +0900 (JST) Received: from bougainvillea.FromTo.Cc (shell.al.rim.or.jp [202.247.191.81]) by mail2.rim.or.jp (8.9.3/3.7W) id IAA07184; Thu, 4 Apr 2002 08:52:01 +0900 (JST) Date: Thu, 04 Apr 2002 08:53:13 +0900 Message-ID: <86g02c5ogm.wl@bougainvillea.FromTo.Cc> From: Tatsumi Hosokawa To: Tatsumi Hosokawa Cc: Barney Wolff , Tatsumi Hosokawa , freebsd-net@FreeBSD.ORG Subject: Re: Please review: ppp(8) and RADIUS address allocation In-Reply-To: <86hems5ojo.wl@bougainvillea.FromTo.Cc> References: <86zo0lqdjf.wl@bougainvillea.FromTo.Cc> <20020403150238.C76772@tp.databus.com> <86hems5ojo.wl@bougainvillea.FromTo.Cc> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Typo. At Thu, 04 Apr 2002 08:51:23 +0900, Tatsumi Hosokawa wrote: > > Oops, sorry. I'll use htonl(0xfffffffe) instead. I don't think it > isn't time critical code because it executed only once per auth ~~~~~ is :-) > session of ppp. -- Tatsumi Hosokawa http://FromTo.Cc/hosokawa/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 18:39:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from serio.al.rim.or.jp (serio.al.rim.or.jp [202.247.191.123]) by hub.freebsd.org (Postfix) with ESMTP id 27EA437B41F; Wed, 3 Apr 2002 18:38:50 -0800 (PST) Received: from mail2.rim.or.jp by serio.al.rim.or.jp (3.7W/HMX-13) id LAA16077; Thu, 4 Apr 2002 11:38:48 +0900 (JST) Received: from bougainvillea.FromTo.Cc (shell.al.rim.or.jp [202.247.191.81]) by mail2.rim.or.jp (8.9.3/3.7W) id LAA04048; Thu, 4 Apr 2002 11:38:48 +0900 (JST) Date: Thu, 04 Apr 2002 11:39:59 +0900 Message-ID: <86zo0kchkw.wl@bougainvillea.FromTo.Cc> From: Tatsumi Hosokawa To: freebsd-net@freebsd.org Cc: hosokawa@freebsd.org Subject: Re: Please review: ppp(8) and RADIUS address allocation In-Reply-To: <86zo0lqdjf.wl@bougainvillea.FromTo.Cc> References: <86zo0lqdjf.wl@bougainvillea.FromTo.Cc> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At Wed, 03 Apr 2002 19:31:16 +0900, Tatsumi Hosokawa wrote: > > I'm testing to use FreeBSD box as PPPoE server and found that ppp(8) > uses 255.255.255.254 (special address to get IP address from NAS pool > defined in RADIUS protocol) as p2p address when "set radius" is used > in ppp.conf. I found the same trouble at > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=299723+0+archive/2001/freebsd-net/20010812.freebsd-net Updated patch against -current. Endian problem was fixed. Index: auth.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/ppp/auth.c,v retrieving revision 1.53 diff -u -r1.53 auth.c --- auth.c 8 Jan 2002 11:24:39 -0000 1.53 +++ auth.c 4 Apr 2002 01:08:13 -0000 @@ -170,7 +170,8 @@ } #ifndef NORADIUS - if (bundle->radius.valid && bundle->radius.ip.s_addr != INADDR_NONE) { + if (bundle->radius.valid && bundle->radius.ip.s_addr != INADDR_NONE && + bundle->radius.ip.s_addr != RADIUS_INADDR_POOL) { /* We've got a radius IP - it overrides everything */ if (!ipcp_UseHisIPaddr(bundle, bundle->radius.ip)) return 0; Index: radius.h =================================================================== RCS file: /home/ncvs/src/usr.sbin/ppp/radius.h,v retrieving revision 1.7 diff -u -r1.7 radius.h --- radius.h 1 Apr 2001 22:39:17 -0000 1.7 +++ radius.h 4 Apr 2002 01:08:13 -0000 @@ -76,3 +76,6 @@ #define RAD_START 1 #define RAD_STOP 2 #endif + +/* Get address from NAS pool */ +#define RADIUS_INADDR_POOL htonl(0xfffffffe) /* 255.255.255.254 */ -- Tatsumi Hosokawa http://FromTo.Cc/hosokawa/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 21:45:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 1657D37B41B for ; Wed, 3 Apr 2002 21:45:40 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020404054539.OGVI15826.rwcrmhc54.attbi.com@blossom.cjclark.org>; Thu, 4 Apr 2002 05:45:39 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g345jUM57709; Wed, 3 Apr 2002 21:45:30 -0800 (PST) (envelope-from cjc) Date: Wed, 3 Apr 2002 21:45:30 -0800 From: "Crist J. Clark" To: Sebastien Petit Cc: Scott Ullrich , "'Barney Wolff'" , freebsd-net@FreeBSD.ORG Subject: Re: HUT Project Message-ID: <20020403214530.A57543@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <2F6DCE1EFAB3BC418B5C324F13934C96016C9521@exchange.corp.cre8.com> <20020402170922.G52193@blossom.cjclark.org> <20020403100144.E148FBADD@sbserv0.intra.selectbourse.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020403100144.E148FBADD@sbserv0.intra.selectbourse.net>; from spe@selectbourse.net on Wed, Apr 03, 2002 at 12:06:20PM +0200 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Apr 03, 2002 at 12:06:20PM +0200, Sebastien Petit wrote: [snip] > Design of freevrrpd cause a problem actually because when a MASTER server > leave LAN (cable problem), SLAVE take his place and send gratuitous ARP for > update ARP cache of all hosts on the same LAN. That's not really accurate. The reason a backup router who becomes master is required to send a gratuitous ARP is so that the learning bridges (a.k.a. switches) can learn which port the MAC address is on. Since the MAC-to-IP relationship never actually changes, there isn't really any need to update the ARP cache of hosts (that's kinda the whole idea). > Normally, I don't need that if > I can set one ethernet address and one VIP on one alias. This method cause a > problem when MASTER is living again because it don't send any Gratuitous ARP > for reupdating all ARP caches of all hosts on the same LAN with his ethernet > address. Huh? > So, my question is simple, is there a mechanism like netgraph or TAP that > permits me to do that: > > xl0: flags=8843 mtu 1500 > options=3 > /* Real address of the server on the first LAN 1 */ > inet 172.16.1.1 netmask 0xffff0000 broadcast 172.16.255.255 > ether 00:b0:d0:5e:3a:04 > > xl1: flags=8843 mtu 1500 > options=3 > /* Real address of the server on the LAN 2 */ > inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255 > ether 00:b0:d0:5e:3a:10 > > /* Alias on xl0 with ethernet address 00:00:5E:00:01:01 because this is the > VRID 1 */ > xl0:0: flags=8843 mtu 1500 > options=3 > inet 172.16.2.1 netmask 0xffff0000 broadcast 172.16.255.255 > ether 00:00:5E:00:01:01 > > /* Alias on xl1 with ethernet address 00:00:5E:00:01:01 becasue this is the > VRID 1 on the LAN 2 (not the same as LAN1) */ > xl1:0: flags=8843 mtu 1500 > options=3 > inet 10.0.1.1 netmask 0xff000000 broadcast 10.255.255.255 > ether 00:00:5E:00:01:01 > > I think that TAP interface cannot permit me to do that because I can't attach > one tap interface on one physical interface. I can have multiple > 00:00:5E:00:01:01 MAC addresses on multiple LAN connected on multiple > physical interfaces of the same host. > My wish is to implement VRRP as clean as I can but there is some > limitations... > Any idea to implement that correctly under FreeBSD ? One point. I don't see any reason to maintain the separate xl[01] interfaces with other MAC addresses in this example. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 23:13:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mel-rto6.wanadoo.fr (smtp-out-6.wanadoo.fr [193.252.19.25]) by hub.freebsd.org (Postfix) with ESMTP id 8A8AE37B41A for ; Wed, 3 Apr 2002 23:12:38 -0800 (PST) Received: from mel-rta5.wanadoo.fr (193.252.19.122) by mel-rto6.wanadoo.fr; 4 Apr 2002 09:12:23 +0200 Received: from SPE (80.13.173.107) by mel-rta5.wanadoo.fr; 4 Apr 2002 09:12:18 +0200 Message-ID: <000d01c1dba8$1c0c6e90$020110ac@SPE> From: "Sebastien Petit" To: Cc: "Scott Ullrich" , References: <2F6DCE1EFAB3BC418B5C324F13934C96016C9521@exchange.corp.cre8.com> <20020402170922.G52193@blossom.cjclark.org> <20020403100144.E148FBADD@sbserv0.intra.selectbourse.net> <20020403214530.A57543@blossom.cjclark.org> Subject: Re: HUT Project Date: Thu, 4 Apr 2002 09:12:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Disposition-Notification-To: "Sebastien Petit" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ----- Original Message ----- From: "Crist J. Clark" To: "Sebastien Petit" Cc: "Scott Ullrich" ; "'Barney Wolff'" ; Sent: Thursday, April 04, 2002 7:45 AM Subject: Re: HUT Project > On Wed, Apr 03, 2002 at 12:06:20PM +0200, Sebastien Petit wrote: > [snip] > > > Design of freevrrpd cause a problem actually because when a MASTER server > > leave LAN (cable problem), SLAVE take his place and send gratuitous ARP for > > update ARP cache of all hosts on the same LAN. > > That's not really accurate. The reason a backup router who becomes > master is required to send a gratuitous ARP is so that the learning > bridges (a.k.a. switches) can learn which port the MAC address is > on. Since the MAC-to-IP relationship never actually changes, there > isn't really any need to update the ARP cache of hosts (that's kinda > the whole idea). > > > Normally, I don't need that if > > I can set one ethernet address and one VIP on one alias. This method cause a > > problem when MASTER is living again because it don't send any Gratuitous ARP > > for reupdating all ARP caches of all hosts on the same LAN with his ethernet > > address. > > Huh? > > > So, my question is simple, is there a mechanism like netgraph or TAP that > > permits me to do that: > > > > xl0: flags=8843 mtu 1500 > > options=3 > > /* Real address of the server on the first LAN 1 */ > > inet 172.16.1.1 netmask 0xffff0000 broadcast 172.16.255.255 > > ether 00:b0:d0:5e:3a:04 > > > > xl1: flags=8843 mtu 1500 > > options=3 > > /* Real address of the server on the LAN 2 */ > > inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255 > > ether 00:b0:d0:5e:3a:10 > > > > /* Alias on xl0 with ethernet address 00:00:5E:00:01:01 because this is the > > VRID 1 */ > > xl0:0: flags=8843 mtu 1500 > > options=3 > > inet 172.16.2.1 netmask 0xffff0000 broadcast 172.16.255.255 > > ether 00:00:5E:00:01:01 > > > > /* Alias on xl1 with ethernet address 00:00:5E:00:01:01 becasue this is the > > VRID 1 on the LAN 2 (not the same as LAN1) */ > > xl1:0: flags=8843 mtu 1500 > > options=3 > > inet 10.0.1.1 netmask 0xff000000 broadcast 10.255.255.255 > > ether 00:00:5E:00:01:01 > > > > I think that TAP interface cannot permit me to do that because I can't attach > > one tap interface on one physical interface. I can have multiple > > 00:00:5E:00:01:01 MAC addresses on multiple LAN connected on multiple > > physical interfaces of the same host. > > My wish is to implement VRRP as clean as I can but there is some > > limitations... > > Any idea to implement that correctly under FreeBSD ? > > One point. I don't see any reason to maintain the separate xl[01] > interfaces with other MAC addresses in this example. with the RFC2338, FreeBSD must respond to ARP query on 10.0.1.1 and 172.16.2.1 with 00:00:5E:01:01 MAC address and not with the real MAC addresses of physical interfaces. Then when a switching between SLAVE and MASTER occures ARP cache doesn't need to be updated anyware. The switch learn effectivly the MAC address on his port but it updates his ARP table automaticly when another host become a MASTER because the new MASTER send VRRP packets every seconds. so if you don't use real aliases with RFC2338 MAC addresses, ARP cache of hosts on the same LAN need to be updated (because SLAVE doesn't have the same MAC address as the MASTER). This problem is describe in the RFC2338. Then, I need to write a new node called ng_alias for example and use it for doing this staff. But perhaps I'm wrong with that or with RFC2338. If this is the case, can you correct me ? Any comments ? Sebastien. -- spe@selectbourse.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 3 23:53:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id F2A6C37B400 for ; Wed, 3 Apr 2002 23:53:40 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020404075340.QYBH22231.rwcrmhc52.attbi.com@blossom.cjclark.org>; Thu, 4 Apr 2002 07:53:40 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g347rdj58147; Wed, 3 Apr 2002 23:53:39 -0800 (PST) (envelope-from cjc) Date: Wed, 3 Apr 2002 23:53:39 -0800 From: "Crist J. Clark" To: Sebastien Petit Cc: Scott Ullrich , freebsd-net@freebsd.org Subject: Re: HUT Project Message-ID: <20020403235339.D57543@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <2F6DCE1EFAB3BC418B5C324F13934C96016C9521@exchange.corp.cre8.com> <20020402170922.G52193@blossom.cjclark.org> <20020403100144.E148FBADD@sbserv0.intra.selectbourse.net> <20020403214530.A57543@blossom.cjclark.org> <000d01c1dba8$1c0c6e90$020110ac@SPE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000d01c1dba8$1c0c6e90$020110ac@SPE>; from spe@selectbourse.net on Thu, Apr 04, 2002 at 09:12:40AM +0200 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Apr 04, 2002 at 09:12:40AM +0200, Sebastien Petit wrote: [snip] > with the RFC2338, FreeBSD must respond to ARP query on 10.0.1.1 and > 172.16.2.1 with 00:00:5E:01:01 MAC address and not with the real MAC > addresses of physical interfaces. Then when a switching between SLAVE and > MASTER occures ARP cache doesn't need to be updated anyware. The switch > learn effectivly the MAC address on his port but it updates his ARP table > automaticly when another host become a MASTER because the new MASTER send > VRRP packets every seconds. All looks good so far. > so if you don't use real aliases with RFC2338 MAC addresses, ARP cache of > hosts on the same LAN need to be updated (because SLAVE doesn't have the > same MAC address as the MASTER). This problem is describe in the RFC2338. I still don't understand what you are saying here. I think it is a language and terminology barrier. What is a "real alias?" > Then, I need to write a new node called ng_alias for example and use it for > doing this staff. > > But perhaps I'm wrong with that or with RFC2338. If this is the case, can > you correct me ? > Any comments ? > Sebastien. > -- > spe@selectbourse.net -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 0:21:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from hardy.inty.net (hardy.inty.net [195.224.93.245]) by hub.freebsd.org (Postfix) with ESMTP id 781AD37B41C for ; Thu, 4 Apr 2002 00:21:43 -0800 (PST) Received: from inty.hq.inty.net (inty.hq.inty.net [213.38.150.150]) by hardy.inty.net (8.11.3/8.11.3) with ESMTP id g348LbF15085; Thu, 4 Apr 2002 09:21:37 +0100 (BST) Received: from tariq ([10.0.1.156]) by inty.hq.inty.net (8.12.1/8.12.1) with SMTP id g348LacG064064; Thu, 4 Apr 2002 09:21:36 +0100 (BST) From: "Tariq Rashid" To: "Sam Leffler" , Subject: RE: kame ipsec vs. openbsd ipsec / netgraph ipsec node? Date: Thu, 4 Apr 2002 09:24:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <2c1d01c1db3b$460c7720$52557f42@errno.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Sender-IP: 10.0.1.156 X-INT-DeliveryDone: g348LacG064064 X-suppress-rcpt-virus-notify: yes X-Skip-Virus-Check: yes X-Virus-Checked: 11584 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On a slightly side note, I'd much prefer to see FreeBSD with IPSEC pseudo-interfaces a la OpenBSD/linux. I'd much prefer to work with say, enc0, or ipsec1, than mess around with guf half-tunnels.... makes complex routing much easier.... Just a thought - perhaps a netgraph ipsec node is the way forward? Tariq intY (www.inty.com) has automatically scanned this email using Sophos Anti-Virus To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 0:37:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from sbserv0.intra.selectbourse.net (APuteaux-107-2-1-3.abo.wanadoo.fr [217.128.228.3]) by hub.freebsd.org (Postfix) with ESMTP id 494CB37B41B for ; Thu, 4 Apr 2002 00:37:09 -0800 (PST) Received: from there (artik.intra.selectbourse.net [172.16.2.3]) by sbserv0.intra.selectbourse.net (Postfix) with SMTP id 89A9DBB03; Thu, 4 Apr 2002 10:35:46 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Sebastien Petit To: cjclark@alum.mit.edu, "Crist J. Clark" Subject: Re: HUT Project Date: Thu, 4 Apr 2002 10:40:21 +0200 X-Mailer: KMail [version 1.3.2] Cc: Scott Ullrich , freebsd-net@freebsd.org References: <2F6DCE1EFAB3BC418B5C324F13934C96016C9521@exchange.corp.cre8.com> <000d01c1dba8$1c0c6e90$020110ac@SPE> <20020403235339.D57543@blossom.cjclark.org> In-Reply-To: <20020403235339.D57543@blossom.cjclark.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020404083546.89A9DBB03@sbserv0.intra.selectbourse.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thursday 04 April 2002 09:53, Crist J. Clark wrote: > On Thu, Apr 04, 2002 at 09:12:40AM +0200, Sebastien Petit wrote: > [snip] > > > with the RFC2338, FreeBSD must respond to ARP query on 10.0.1.1 and > > 172.16.2.1 with 00:00:5E:01:01 MAC address and not with the real MAC > > addresses of physical interfaces. Then when a switching between SLAVE and > > MASTER occures ARP cache doesn't need to be updated anyware. The switch > > learn effectivly the MAC address on his port but it updates his ARP table > > automaticly when another host become a MASTER because the new MASTER send > > VRRP packets every seconds. > > All looks good so far. > > > so if you don't use real aliases with RFC2338 MAC addresses, ARP cache of > > hosts on the same LAN need to be updated (because SLAVE doesn't have the > > same MAC address as the MASTER). This problem is describe in the RFC2338. > > I still don't understand what you are saying here. I think it is a > language and terminology barrier. What is a "real alias?" Yes perhaps it's a language problem :) I mean real alias when I can create an "interface" with a specified MAC address and a specified IP address attached to a physical device. Actually I can create IP alias (with ifconfig alias for example) but I can't create a MAC address alias associed with this IP alias. Am I wrong ? Sebastien -- spe@selectbourse.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 1:31:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from core.radioactivedata.org (146-115-123-197.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [146.115.123.197]) by hub.freebsd.org (Postfix) with ESMTP id 03FB637B41B for ; Thu, 4 Apr 2002 01:31:54 -0800 (PST) Received: from radioactivedata.org (localhost [127.0.0.1]) by core.radioactivedata.org (8.12.2/8.9.3) with ESMTP id g349SNBa013785 for ; Thu, 4 Apr 2002 04:28:23 -0500 (EST) (envelope-from mbertsch@radioactivedata.org) Message-ID: <3CAC1CB7.6090003@radioactivedata.org> Date: Thu, 04 Apr 2002 04:28:23 -0500 From: Mike DeGraw-Bertsch User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020317 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Question regarding pseudo-device ether Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Howdy, Please forgive what is hopefully not too naive of a question. According to arp(4), the pseudo-device ether is used to map between 10Mb/s Ethernet addresses and IP addresses. PR docs/35604 was opened questioning whether this is true, or if it also supports 100Mb/s, and possibly also gigabit Ethernet. I've searched Google and the mailing list archives, and haven't come upon an answer. If the ether device doesn't support the 100/1000 addresses mapping, what does? If it does support 100/1000, would it be accurate to change arp(4) to read: The Address Resolution Protocol (ARP) is a protocol used to dynamically map between Internet host addresses and 10/100/1000Mb/s Ethernet addresses. It is used by all the 10/100/1000Mb/s Ethernet interface drivers. It is not specific to Internet protocols or to 10/100/1000Mb/s Ethernet, but this implementation currently supports only that combination. Thanks much, -Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 5:47:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from web.cs.ndsu.nodak.edu (web.cs.ndsu.NoDak.edu [134.129.125.7]) by hub.freebsd.org (Postfix) with ESMTP id AD2B437B420 for ; Thu, 4 Apr 2002 05:47:33 -0800 (PST) Received: (from tinguely@localhost) by web.cs.ndsu.nodak.edu (8.11.4/8.11.4) id g34DlT400606; Thu, 4 Apr 2002 07:47:29 -0600 (CST) (envelope-from tinguely) Date: Thu, 4 Apr 2002 07:47:29 -0600 (CST) From: mark tinguely Message-Id: <200204041347.g34DlT400606@web.cs.ndsu.nodak.edu> To: freebsd-net@FreeBSD.ORG, mbertsch@radioactivedata.org Subject: Re: Question regarding pseudo-device ether In-Reply-To: <3CAC1CB7.6090003@radioactivedata.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > According to arp(4), the pseudo-device ether is used to map between > 10Mb/s Ethernet addresses and IP addresses. PR docs/35604 was opened > questioning whether this is true, or if it also supports 100Mb/s, and > possibly also gigabit Ethernet. I've searched Google and the mailing > list archives, and haven't come upon an answer. yes, ARP resolves all speeds of Ethernet to IP. -current and 4.5-stable as of this week, also support other size MACs like Arcnet too. --mark tinguely To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 7:44:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by hub.freebsd.org (Postfix) with ESMTP id 7243E37B41C for ; Thu, 4 Apr 2002 07:44:19 -0800 (PST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 63C3A43128 for ; Thu, 4 Apr 2002 17:44:18 +0200 (CEST) Received: from itserv2.lab.it.uc3m.es (itserv2.lab.it.uc3m.es [163.117.144.121]) by smtp02.uc3m.es (Postfix) with ESMTP id E0B2099E34 for ; Thu, 4 Apr 2002 17:44:17 +0200 (CEST) Received: from lm002.lab.it.uc3m.es (root@lm002.lab.it.uc3m.es [163.117.144.131]) by itserv2.lab.it.uc3m.es (8.9.3/8.9.3) with ESMTP id RAA16632 for ; Thu, 4 Apr 2002 17:44:17 +0200 Received: from localhost (jrh@localhost) by lm002.lab.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id RAA02982 for ; Thu, 4 Apr 2002 17:44:16 +0200 Date: Thu, 4 Apr 2002 17:44:16 +0200 (CEST) From: Juan Francisco Rodriguez Hervella To: freebsd-net@freebsd.org Subject: Problems trying to debugging a kernel with remote GDB Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello: I'm following all the steps of the Handbook to make a remote kernel debugging using GDB. My problem is that when I write "target remote /dev/cuaa0", I can not see the source files because I received the following message: "Cannot find the bounds of currect function" I run gdb with xemacs with "-k kernel", in the directory /sys/compile/MY-KERNEL What is wrong ? Thank you very much. ***** JFRH ***** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 7:55:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from ice-nine.org (iorek.ice-nine.org [206.168.0.33]) by hub.freebsd.org (Postfix) with ESMTP id 3C18F37B41F for ; Thu, 4 Apr 2002 07:55:13 -0800 (PST) Received: from matt (helo=localhost) by ice-nine.org with local-esmtp (Exim 3.33 #1) id 16t9Zn-0001xO-00; Thu, 04 Apr 2002 08:55:03 -0700 Date: Thu, 4 Apr 2002 08:55:03 -0700 (MST) From: matthew weaver To: Sam Leffler Cc: freebsd-net@FreeBSD.ORG Subject: Re: kame ipsec vs. openbsd ipsec In-Reply-To: <2c1d01c1db3b$460c7720$52557f42@errno.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org in Apr, Sam Leffler probably wrote : |1. Has anyone else seriously looked at doing this? |2. Has anyone compared the OpenBSD and KAME implementations and understand |their relative strengths? (e.g. is there some reason to work with KAME other |than it's already in the system) I realize you're most interested in a developer's perspective on this, and I'm not comfortable providing anything like that. On a side note, however, I'll mention some things from a administrative/user perspective. I like these features of the OpenBSD implementation, one of which was mentioned by Tariq Rashid : 1. The enc interface. Makes it extremely simple to have packet filtering rules for IPSEC tunneled networks, and routing is easier to think about, imho. 2. IPSEC flows appear in netstat -r output, very handy. 3. kernfs has information about each SA, including statistics for them (bytes, packets, etc). I'm less familiar with the KAME implementation, so I'm unable to highlight its strengths compared to the OpenBSD code -- perhaps someone will jump in here and point them out for me. matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 8:46:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail49.fg.online.no (mail49-s.fg.online.no [148.122.161.49]) by hub.freebsd.org (Postfix) with ESMTP id 39A5537B41F for ; Thu, 4 Apr 2002 08:46:47 -0800 (PST) Received: from epostleser.online.no (epostleser12.frisurf.no [148.122.3.20]) by mail49.fg.online.no (8.9.3/8.9.3) with ESMTP id SAA27456 for ; Thu, 4 Apr 2002 18:46:45 +0200 (MET DST) X-WebMail-UserID: glaerumk@online.no Date: Thu, 4 Apr 2002 18:46:45 +0200 From: glaerumk To: freebsd-net@freebsd.org X-EXP32-SerialNo: 50000140 Subject: natd and online games Message-ID: <3CAFB036@epostleser.online.no> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: InterChange (Hydra) SMTP v3.62 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org if I run natd to share a isdn connection, is there a way I can get counterstrike and other online-games to work through the freebsd box running natd? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 8:55:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id D8A2937B405 for ; Thu, 4 Apr 2002 08:55:16 -0800 (PST) Received: from isi.edu (2difk6cathejfoib@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g34GqHT05214; Thu, 4 Apr 2002 08:52:17 -0800 (PST) Message-ID: <3CAC84C0.3000702@isi.edu> Date: Thu, 04 Apr 2002 08:52:16 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020329 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Tariq Rashid Cc: Sam Leffler , freebsd-net@freebsd.org, Joe Touch Subject: Re: kame ipsec vs. openbsd ipsec / netgraph ipsec node? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060102070009020102050209" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms060102070009020102050209 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Tariq Rashid wrote: > On a slightly side note, I'd much prefer to see FreeBSD with IPSEC > pseudo-interfaces a la OpenBSD/linux. > > I'd much prefer to work with say, enc0, or ipsec1, than mess around > with guf half-tunnels.... makes complex routing much easier.... Have you looked at draft-touch-ipsec-vpn (ftp://ftp.isi.edu/internet-drafts/draft-touch-ipsec-vpn-03.txt)? We address just this issue with a combination of IPsec transport mode and IPIP tunnels. We are currently revising it and it will move to Informational RFC soon. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms060102070009020102050209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDQwNDE2NTIxNlowIwYJKoZIhvcNAQkEMRYEFIDKx4PMz9/MlMhf0+f9GOea97+oMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYAlmt52X8P/G9s/7YvgAPA0K5tN0djRy8zwoYdYIWbqKTw8jlSEmxMrrM/eS+2o8yAF p6fZKgzwa9420RRxaUMPKw7pjS145T+V5qR+3CjPfwkZLlPweG+da5pgfOzdXSsHf/+29rU7 3eNR2fj0FRXqnhH6SAOxnUTdR/UWXdlZ9QAAAAAAAA== --------------ms060102070009020102050209-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 8:55:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by hub.freebsd.org (Postfix) with ESMTP id CDF5037B42F for ; Thu, 4 Apr 2002 08:55:43 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id EB71B43155; Thu, 4 Apr 2002 18:23:56 +0200 (CEST) Received: from itserv2.lab.it.uc3m.es (itserv2.lab.it.uc3m.es [163.117.144.121]) by smtp01.uc3m.es (Postfix) with ESMTP id A6AE499E03; Thu, 4 Apr 2002 18:23:56 +0200 (CEST) Received: from lm008.lab.it.uc3m.es (root@lm008.lab.it.uc3m.es [163.117.144.137]) by itserv2.lab.it.uc3m.es (8.9.3/8.9.3) with ESMTP id SAA24528; Thu, 4 Apr 2002 18:23:56 +0200 Received: from localhost (jrh@localhost) by lm008.lab.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id SAA04452; Thu, 4 Apr 2002 18:23:56 +0200 Date: Thu, 4 Apr 2002 18:23:56 +0200 (CEST) From: Juan Francisco Rodriguez Hervella To: Peter Lei Cc: freebsd-net@freebsd.org Subject: Re: Problems trying to debugging a kernel with remote GDB Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I continue with the same problem :( > Hello: > > I'm following all the steps of the Handbook to make a > remote kernel debugging using GDB. > > My problem is that when I write "target remote /dev/cuaa0", > I can not see the source files because I received the > following message: > > "Cannot find the bounds of currect function" > > I run gdb with xemacs with "-k kernel", in the > directory /sys/compile/MY-KERNEL > > What is wrong ? > > Thank you very much. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 9:18:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id ADDC537B41D; Thu, 4 Apr 2002 09:18:06 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [fec0::1:12]) by Awfulhak.org (8.11.6/8.11.6) with ESMTP id g34HHp906928; Thu, 4 Apr 2002 18:17:51 +0100 (BST) (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.12.2/8.12.2) with ESMTP id g34HHkq7037326; Thu, 4 Apr 2002 18:17:46 +0100 (BST) (envelope-from brian@freebsd-services.com) Message-Id: <200204041717.g34HHkq7037326@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Doug Ambrisko Cc: "M. Warner Losh" , j@uriah.heep.sax.de, alan@clegg.com, luigi@FreeBSD.org, nsayer@FreeBSD.org, ryand-bsd@zenspider.com, Brian Somers , freebsd-arch@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: Your change to in.c to limit duplicate networks is causing trouble In-Reply-To: Message from Doug Ambrisko of "Mon, 25 Mar 2002 11:34:50 PST." <200203251934.g2PJYoY68469@ambrisko.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Apr 2002 18:17:46 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've crossposted to -net and -arch as this could probably do with a review from a larger audience.... > Brian Somers writes: > | > In message: <20020325172024.B60771@uriah.heep.sax.de> > | > Joerg Wunsch writes: > | > : As Alan Clegg wrote: > | > : > | > : > Is there any motion to pull this back? > | > : > | > : There was only consensus to special-case the BOOTP case. > | > : > | > : As i understand it, the change itself was more than desirable for > | > : PPP connections (so no surprise it was Brian who committed it). > | > > | > dhclient is still broken, however. The 0.0.0.0 should be the special > | > case, not bootp. > | > | Yes, I agree. > | > | The question is.... should interface address assignments with > | destinations of 0.0.0.0 have host routes created in the first place ? > | > | I'd tend to think not. > | > | Doing this will make things consistent, but maybe at the expense of > | breaking something else - under ``usual'' circumstances. I'm > | thinking along the lines of some program that may configure a > | destination address of 0.0.0.0 and then expect to be able to do stuff > | with the routing table - such as adding a route via 0.0.0.0 or calling > | sendto() or connect() with 0.0.0.0 as the destination. > | > | I'm guessing that dhclient will continue to work without a host route > | as it writes raw IP packets, and I haven't heard of any problems with > | running multiple dhclients using the old in.c code where second and > | subsequent SIOCAIADDRs with a 0.0.0.0 destination had no host route. > | I haven't tested it yet though. > | > | If nobody objects, I'll tweak things so that destinations of 0.0.0.0 > | don't add host routes and see if it breaks anything I know of. I'll > | post patches to -arch and cc -net when I get something working. > > Sounds reasonable. I can test it when you have something since I'm hitting > this on a few machines around here. > > Doug A. The attached patches seem to make things work for BOOTP with multiple interfaces and for ppp expecting failures for duplicate destination address assignments. The code now avoids adding a host route if the interface address is 0.0.0.0, and always treats a failure to add a host route as fatal (previously, it masked EEXIST for some reason - I guessed because it was trying to handle address re-assignment, but that works ok with this patch). If people could get some time to review it, it'd be appreciated. Cheers. -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! Index: netinet/in.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in.c,v retrieving revision 1.63 diff -u -r1.63 in.c --- netinet/in.c 1 Apr 2002 21:31:06 -0000 1.63 +++ netinet/in.c 4 Apr 2002 16:52:59 -0000 @@ -661,7 +661,7 @@ { register u_long i = ntohl(sin->sin_addr.s_addr); struct sockaddr_in oldaddr; - int s = splimp(), flags = RTF_UP, error; + int s = splimp(), flags = RTF_UP, error = 0; oldaddr = ia->ia_addr; ia->ia_addr = *sin; @@ -723,17 +723,21 @@ return (0); flags |= RTF_HOST; } - if ((error = rtinit(&(ia->ia_ifa), (int)RTM_ADD, flags)) == 0) - ia->ia_flags |= IFA_ROUTE; - if (error != 0 && ia->ia_dstaddr.sin_family == AF_INET) { - ia->ia_addr = oldaddr; - return (error); + /* + * Don't add routing table entries for interface address entries + * of 0.0.0.0. This makes it possible to assign several such address + * pairs with consistent results (no host route) and is required by + * BOOTP. + */ + if (ia->ia_addr.sin_addr.s_addr != INADDR_ANY) { + if ((error = rtinit(&ia->ia_ifa, (int)RTM_ADD, flags)) != 0) { + ia->ia_addr = oldaddr; + return (error); + } + ia->ia_flags |= IFA_ROUTE; } - /* XXX check if the subnet route points to the same interface */ - if (error == EEXIST) - error = 0; /* * If the interface supports multicast, join the "all hosts" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 11:18: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 54B6E37B41F for ; Thu, 4 Apr 2002 11:17:56 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.2/8.11.6) with ESMTP id g34JHlCu001183; Thu, 4 Apr 2002 20:17:47 +0100 (BST) (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.12.2/8.12.2) with ESMTP id g34JHjq7038873; Thu, 4 Apr 2002 20:17:45 +0100 (BST) (envelope-from brian@freebsd-services.com) Message-Id: <200204041917.g34JHjq7038873@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Thomas Quinot Cc: freebsd-net@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: Userland ppp hung in Ack-Rcvd In-Reply-To: Message from Thomas Quinot of "Wed, 03 Apr 2002 09:06:58 +0200." <20020403090658.A65499@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Apr 2002 20:17:45 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I observed a peculiar situation today on an ADSL link using pptpclient > and the userland ppp daemon: the LCP negociation hunk in state > Ack-Rcvd for almost 3 hours (until I killed it) without any progress, > but without timing out, either. > > Here is an excerpt from the log: > > Apr 3 05:25:02 melusine ppp[53064]: tun0: LCP: deflink: State change Initial --> Closed > Apr 3 05:25:02 melusine ppp[53064]: tun0: LCP: deflink: State change Closed --> Stopped > Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: deflink: LayerStart > Apr 3 05:25:03 melusine ppp[53064]: tun0: Warning: deflink: Reducing configured MRU from 1500 to 1480 > Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped > Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: ACFCOMP[2] > Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: PROTOCOMP[2] > Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: ACCMAP[6] 0x00000000 > Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: MRU[4] 1480 > Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: MAGICNUM[6] 0x91e371fe > Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: deflink: State change > Stopped --> Req-Sent > Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent > Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: ACFCOMP[2] > Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: PROTOCOMP[2] > Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: ACCMAP[6] 0x00000000 > Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: MRU[4] 1480 > Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: MAGICNUM[6] 0x91e371fe > Apr 3 05:25:09 melusine ppp[53064]: tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent > Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: ACFCOMP[2] > Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: PROTOCOMP[2] > Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: ACCMAP[6] 0x00000000 > Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: MRU[4] 1480 > Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: MAGICNUM[6] 0x91e371fe > Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: deflink: RecvConfigAck(1) state = Req-Sent > Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: deflink: State change Req-Sent --> Ack-Rcvd > Apr 3 08:11:27 melusine ppp[53064]: tun0: Phase: Signal 15, terminate. > > In other sessions that I have a trace of, I never enter Ack-Recvd, > but instead: > > Apr 3 08:12:07 melusine ppp[61776]: tun0: LCP: deflink: RecvConfigReq(224) state = Req-Sent > > This box is running 4.5-STABLE kernel and world cvsuppsed 10 days or so > ago. Any idea why it did not time out? > > Thomas. It looks like the peer responded to our req, but never sent a req of it's own. In this scenario, ppp should enter Ack-Rcvd from Req-Sent due to the RCA event and initialise it's restart counter. Examining the code implies that it's doing this (FsmRecvConfigAck() in fsm.c). Therefore something else must have jammed things up. If you have a diagnostic socket configured, it's worth using pppctl to connect to it and see if that wakes up ppp - or at least if ``show timer'' indicates that the timers are running (run ``show timer'' a few times and note the timeouts decrementing). If it doesn't wake things up or you can't connect, killing ppp with a -11 and examining the core dump is the only option.... but you'll need symbols in the binary. I add CFLAGS=-g and STRIP= to the Makefile to achieve this. > -- > Thomas.Quinot@Cuivre.FR.EU.ORG -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 11:39: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.uninterruptible.net (ns1.uninterruptible.net [216.7.46.11]) by hub.freebsd.org (Postfix) with ESMTP id 1EF9537B405 for ; Thu, 4 Apr 2002 11:39:01 -0800 (PST) Received: from Spaz.Catonic.NET (tnt6-216-180-4-159.dialup.HiWAAY.net [216.180.4.159]) by mail.uninterruptible.net (Postfix) with ESMTP id 1A747502E9; Thu, 4 Apr 2002 19:38:55 +0000 (GMT) Received: by Spaz.Catonic.NET (Postfix, from userid 1002) id BEEDA3332; Thu, 4 Apr 2002 19:38:52 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by Spaz.Catonic.NET (Postfix) with ESMTP id BA1EC4C4C; Thu, 4 Apr 2002 19:38:52 +0000 (GMT) Date: Thu, 4 Apr 2002 19:38:52 +0000 (GMT) From: Kris Kirby To: Lars Eggert Cc: Subject: Re: VPN / VLAN? In-Reply-To: <3CAB4CD0.9040508@isi.edu> Message-ID: X-Tech-Support-Email: bofh@catonic.net Organization: Non Illegitemus Carborundum Inc. X-Disclaimer: My opinions are not those of my employer(s). X-Driving-The-Information-Superhighway-Joke: Asleep at the wheel. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 3 Apr 2002, Lars Eggert wrote: > We have a vtun setup (tethered.net) that does just that (relay the real > Internet to the inside of a NAT box) to support DARPA PI meetings. We're > currently documenting the thing and will put up a website with > descriptions and the config scripts. Ping me again in a few days if you > haven't heard from me :-) Lars, I'd be most interested to see that documentation, when you're done with it. Perhaps and article for Daemon News? > What is required to make this work though is that you can get a few > static IPs inside the 216.6.6.129/25 net (in your example) to relay. I'm a little confused by this. -- Kris Kirby, KE4AHR | TGIFreeBSD... 'Nuff said. | IM: KrisBSD | HSV, AL. ------------------------------------------------------- "Fate, it seems, is not without a sense of irony." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 12: 1: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 04C4737B41C; Thu, 4 Apr 2002 12:00:28 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id WAA22498; Thu, 4 Apr 2002 22:00:04 +0200 (CEST) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id g34Jwin83318; Thu, 4 Apr 2002 21:58:44 +0200 (MET DST) (envelope-from j) Date: Thu, 4 Apr 2002 21:58:44 +0200 From: Joerg Wunsch To: Brian Somers Cc: Doug Ambrisko , "M. Warner Losh" , alan@clegg.com, luigi@FreeBSD.org, nsayer@FreeBSD.org, ryand-bsd@zenspider.com, freebsd-arch@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: Your change to in.c to limit duplicate networks is causing trouble Message-ID: <20020404215844.A83154@uriah.heep.sax.de> Reply-To: Joerg Wunsch References: <200204041717.g34HHkq7037326@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200204041717.g34HHkq7037326@hak.lan.Awfulhak.org>; from brian@freebsd-services.com on Thu, Apr 04, 2002 at 06:17:46PM +0100 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As Brian Somers wrote: > The code now avoids adding a host route if the interface address is > 0.0.0.0, and always treats a failure to add a host route as fatal > (previously, it masked EEXIST for some reason - I guessed because it > was trying to handle address re-assignment, but that works ok with > this patch). I think that will be fatal for the sppp case with dynamic IP address negotiation. We use 0.0.0.0 as the local IP address for the unnegotiated PPP link then, with the idea that it's still possible to route through the interface anyway. For dial-on-demand PPP links (like on ISDN), the routed packets will then trigger the dialout event. In the course of the PPP negotiations, an actual local IP address will be negotiated and assigned, but we first need some packets to pass through the PPP layer in order to trigger this. Perhaps it would still be possible to use per-interface routes even after your change (-iface isp0 etc.), but currently, a number of documents describe that it's possible to use local address 0.0.0.0 and still get normal routing behaviour for those links. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 12: 1:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 5067337B419 for ; Thu, 4 Apr 2002 12:01:04 -0800 (PST) Received: from isi.edu (1q6maca4197nlrnr@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g34K13T00733; Thu, 4 Apr 2002 12:01:03 -0800 (PST) Message-ID: <3CACB0FE.5060500@isi.edu> Date: Thu, 04 Apr 2002 12:01:02 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020329 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Kris Kirby Cc: freebsd-net@freebsd.org Subject: Re: VPN / VLAN? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040302050807080100070801" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms040302050807080100070801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kris Kirby wrote: >>What is required to make this work though is that you can get a few >>static IPs inside the 216.6.6.129/25 net (in your example) to relay. > > I'm a little confused by this. It's simple, really. At ISI, for example, we have the 128.9/16 subnet. We use a class C inside that block, and relay it over the tunnel to the remote site. Thus, at the remote site, everything looks like your are at the main site: you get an 128.9/16 IP address, etc. The NAT box is invisible. The down side for a normal home user is that you need someone that has a globally routable block (like 128.9/16) that is willing to hand you a sublock, and let you run one end of the relay on their system. It can't magically make your NAT'ed machines globally routable. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms040302050807080100070801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDQwNDIwMDEwMlowIwYJKoZIhvcNAQkEMRYEFLP8K3yTNQ3U1FWHFmRkP1hMHNutMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYAJZOTtDnYOYje8+duZFEiIY4Dkj/IT+aFDspedDDA/W/65h6ljcBHtwEyenCUf3LO9 RJFChKr1tOD955IcXvc3hrC3AQxHV0P5y+E836+17mcsqtbQud7ENV5B7efLF9Ak3R+0SJn7 FpKYAovesfLGlK/2sVDRf1iDbMAFrQjJXQAAAAAAAA== --------------ms040302050807080100070801-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 12:26:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id 5D43537B416 for ; Thu, 4 Apr 2002 12:26:02 -0800 (PST) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.11.6/8.11.6) with SMTP id g34KPu003795; Thu, 4 Apr 2002 22:25:57 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Thu, 4 Apr 2002 22:25:56 +0200 From: Christophe Prevotaux To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPFW Max Rule Discrete Number Limit Message-Id: <20020404222556.5ddeb117.c.prevotaux@hexanet.fr> In-Reply-To: <20020403111545.A98202@iguana.icir.org> References: <20020403205923.27d35e11.c.prevotaux@hexanet.fr> <20020403111545.A98202@iguana.icir.org> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 3 Apr 2002 11:15:45 -0800 Luigi Rizzo wrote: > On Wed, Apr 03, 2002 at 08:59:23PM +0200, Christophe Prévotaux wrote: > > Hi > > > > I have reached the 655 firewalling rules limit (with discrete values) > > in ipfw and I was wondering why ipfw will not let the user select > > the incremental step value in rules numbering ? also it should be > > possible to renumber these rules on the fly > > (though, i agree this is not this useful) > > you know you can assign explicit numbers to rules ? yes I know , do you seriously think I will do this ? What happens when I insert new rules ? I have to write a script to renumber them ? can't this be included in the ipfw itself for example by specifying a incremental step number for exemple ipfw -q flush -i [step] ipfw -q flush -i 10 in this manner no big changes to the rc.firewall or firewall rules files would be needed and everyone would be happy. > There is alot of magic you can do in userland rather than > relying on the kernel to cope with all sorts of different > user requirements... > > cheers > luigi > -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 13:11: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hub.freebsd.org (Postfix) with ESMTP id B67A837B41E; Thu, 4 Apr 2002 13:10:59 -0800 (PST) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id NAA05062; Thu, 4 Apr 2002 13:10:44 -0800 (envelope-from stephenm@shell4.bayarea.net) Message-Id: <200204042110.NAA05062@shell4.bayarea.net> To: Doug Ambrisko Cc: "M. Warner Losh" , j@uriah.heep.sax.de, alan@clegg.com, luigi@FreeBSD.ORG, nsayer@FreeBSD.ORG, ryand-bsd@zenspider.com, Brian Somers , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Your change to in.c to limit duplicate networks is causing trouble Date: Thu, 04 Apr 2002 13:10:44 -0800 From: stephen macmanus Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > The code now avoids adding a host route if the interface address is > 0.0.0.0, and always treats a failure to add a host route as fatal > (previously, it masked EEXIST for some reason - I guessed because it > was trying to handle address re-assignment, but that works ok with > this patch). One effect of the masked EEXIST is to suppress the spurious error which occurs when adding an alias IP address (SIOCAIFADDR) on the same logical subnet as an existing IP address. Users have no way of knowing that it's actually safe to simply ignore the error in that situation, so the masking should probably be preserved. Stephen ------------------ Stephen Macmanus #include stephenm@bayarea.net - - - if ((error = rtinit(&(ia->ia_ifa), (int)RTM_ADD, flags)) == 0) - - - ia->ia_flags |= IFA_ROUTE; - - - if (error != 0 && ia->ia_dstaddr.sin_family == AF_INET) { - - - ia->ia_addr = oldaddr; - - - return (error); + /* + * Don't add routing table entries for interface address entries + * of 0.0.0.0. This makes it possible to assign several such address + * pairs with consistent results (no host route) and is required by + * BOOTP. + */ + if (ia->ia_addr.sin_addr.s_addr != INADDR_ANY) { + if ((error = rtinit(&ia->ia_ifa, (int)RTM_ADD, flags)) != 0) { + ia->ia_addr = oldaddr; + return (error); + } + ia->ia_flags |= IFA_ROUTE; } - - - /* XXX check if the subnet route points to the same interface */ - - - if (error == EEXIST) - - - error = 0; /* * If the interface supports multicast, join the "all hosts" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 13:46:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id D67B637B41D for ; Thu, 4 Apr 2002 13:46:20 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id NAA61048; Thu, 4 Apr 2002 13:42:04 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g34LfIo80888; Thu, 4 Apr 2002 13:41:18 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200204042141.g34LfIo80888@arch20m.dellroad.org> Subject: Re: Problems trying to debugging a kernel with remote GDB In-Reply-To: "from Juan Francisco Rodriguez Hervella at Apr 4, 2002 06:23:56 pm" To: Juan Francisco Rodriguez Hervella Date: Thu, 4 Apr 2002 13:41:17 -0800 (PST) Cc: Peter Lei , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Juan Francisco Rodriguez Hervella writes: > > I run gdb with xemacs with "-k kernel", in the > > directory /sys/compile/MY-KERNEL You mean "gdb -k kernel.debug" right? -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 14:10:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from skippy.eecs.umich.edu (skippy.eecs.umich.edu [141.213.8.138]) by hub.freebsd.org (Postfix) with ESMTP id C74CE37B417 for ; Thu, 4 Apr 2002 14:10:10 -0800 (PST) Received: from skippy.eecs.umich.edu (localhost [127.0.0.1]) by skippy.eecs.umich.edu (8.11.6/8.11.6) with ESMTP id g34MAAR42207 for ; Thu, 4 Apr 2002 17:10:10 -0500 (EST) (envelope-from dwatson@skippy.eecs.umich.edu) Message-Id: <200204042210.g34MAAR42207@skippy.eecs.umich.edu> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: freebsd-net@freebsd.org Subject: Failure to set promiscuous correctly Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Apr 2002 17:10:10 -0500 From: David Watson Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm experience a really weird condition with the bridging code. It looks like there is some race condition that causes an interface to look like it's in promiscuous mode when it really isn't. My setup has two Intel Gigabit cards with the Intel em driver. (The gx driver causes auto-negotiation to fail with the switch I'm using.) I'm running 4.5-RELEASE, with some custom modifications to the kernel. I have been able to verify the condition with a 4.5 GENERIC kernel which uses the wx drivers. Immediately after booting the first card (em0) is up and assigned an ip address (10.5.5.2), the second card is unmodified (no ip address assigned) and has the flags: em1: flags=0xffff8802 I then issue the following commands (from a file): sysctl -w net.link.ether.bridge=1 sysctl -w net.link.ether.bridge_ipfw=1 sysctl -w net.link.ether.bridge_cfg=em0:1,em1:1 and get the following output from my my instrumented ifpromisc(): em0: promiscuous mode enabled (dw) em0: ioctl succeeded! >> now em0 promisc ON if_flags 0xffff8943 bdg_flags 0x5 em1: promiscuous mode enabled (dw) em1: ioctl succeeded! em1: promiscuous counter = 2, promiscuous mode is already enabled >> now em1 promisc ON if_flags 0xffff8943 bdg_flags 0x5 >> now em1 promisc ON if_flags 0xffff8943 bdg_flags 0x5 em0: promiscuous mode disabled em0: ioctl succeeded! em0: promiscuous mode enabled (dw) em0: ioctl succeeded! >> now em0 promisc ON if_flags 0xffff8943 bdg_flags 0x5 em1: promiscuous counter = 2, promiscuous mode is already enabled >> now em1 promisc ON if_flags 0xffff8943 bdg_flags 0x5 em1 now has the flags: em1: flags=0xffff8943 but is _not_ really in promisc mode (i.e. bridging doesn't work, packets that I can verify are hitting the card never hit the interface statistics...). I can manually take the card out of promisc and back in using ioctl and things work just fine. It looks like one attempt to turn off promisc mode manages to turn it off on the card, but not in the flags and the promisc counter. Note that this doesn't always happen. Sometimes the interface truly ends up in promisc and bridging works just fine. Enabling the DEB macro in bridge.c seems to ensure that it works correctly. I thought I would fix the problem while I had the code torn apart but I can't think of the next place to look. dmesg and my instrumentation follows. David Watson dmesg: Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-RELEASE #26: Thu Apr 4 11:30:33 EST 2002 dwatson@skippy.eecs.umich.edu:/usr/home/dwatson/work/scrubber/new_scrub/fbsd_4.5/sys/compile/SCRUB Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 731023035 Hz CPU: Pentium III/Pentium III Xeon/Celeron (731.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383fbff real memory = 1744814080 (1703920K bytes) Kernel map size: 2145390592, (2046 M) sio0: gdb debugging port avail memory = 382730240 (373760K bytes) Preloaded elf kernel "kernel" at 0x802ff000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pci0: at 1.0 pci0: (vendor=0x1022, dev=0x2000) at 2.0 irq 11 pci0: (vendor=0x8086, dev=0x1229) at 9.0 irq 15 isab0: at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x840-0x84f at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 15.2 irq 9 pcib1: on motherboard pci1: on pcib1 ahc0: port 0x4b00-0x4bff mem 0xeffff000-0xefffffff irq 10 at device 3.0 on pci1 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: port 0x4c00-0x4cff mem 0xefffe000-0xefffefff irq 10 at device 3.1 on pci1 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/255 SCBs em0: mem 0xeffc0000-0xeffdffff irq 11 at device 5.0 on pci1 em0: Speed:1000 Mbps Duplex:Full em1: mem 0xeffa0000-0xeffbffff irq 15 at device 6.0 on pci1 em1: Speed:1000 Mbps Duplex:Full orm0:
 
 
Little bit confused here.
 
Hope the formatting in the email isn't = screwed up -=20 these things usually are. sorry
 
 
rl0 is the ethernet interface on the = machine -and=20 I'm setting up IPv6 over IPv4 (6to4), using the stf0 interface. The box = is=20 connected by PPP to the internet over tun0.
 
But I'm haveing trouble actually = working out which=20 is the host for the DNS, and which is the interface, global and local = addresses=20 and so on.?
 
Internet6:
Destination      &nb= sp;           &nbs= p;   =20 Gateway           =            =20 Flags      Netif=20 Expire
::/96         &nbs= p;            = ;      =20 ::1           &nbs= p;            = ;  =20 UGRSc       lo0=20 =3D>
default         &= nbsp;           &n= bsp;    =20 2002:c058:6301::         &nb= sp;   =20 UGSc      =20 stf0
::1          &n= bsp;           &nb= sp;       =20 ::1           &nbs= p;            = ;  =20 UH         =20 lo0
::ffff:0.0.0.0/96        &= nbsp;       =20 ::1           &nbs= p;            = ;  =20 UGRSc      =20 lo0
2002::/24         &nb= sp;           &nbs= p;  =20 ::1           &nbs= p;            = ;  =20 UGRSc       lo0=20 =3D>
2002::/16         = ;            =    =20 2002:cb01:6005:1::1         =  =20 Uc        =20 stf0
2002:7f00::/24        &nb= sp;          =20 ::1           &nbs= p;            = ;  =20 UGRSc      =20 lo0
2002:cb01:6005::1        &= nbsp;       =20 link#4           &= nbsp;           =20 UHL        =20 lo0
2002:cb01:6005:1::1        = ;      =20 link#4           &= nbsp;           =20 UHL        =20 lo0
2002:e000::/20        &nbs= p;          =20 ::1           &nbs= p;            = ;  =20 UGRSc      =20 lo0
2002:ff00::/24        &nbs= p;          =20 ::1           &nbs= p;            = ;  =20 UGRSc      =20 lo0
fe80::/10         &nb= sp;           &nbs= p;  =20 ::1           &nbs= p;            = ;  =20 UGRSc      =20 lo0
fe80::%rl0/64         = ;           =20 link#1           &= nbsp;           =20 UC         =20 rl0
fe80::210:b5ff:fee4:4386%rl0     =20 0:10:b5:e4:43:86         &nb= sp;   =20 UHL        =20 lo0
fe80::%lo0/64         = ;           =20 fe80::1%lo0          &n= bsp;       =20 Uc         =20 lo0
fe80::1%lo0         &= nbsp;           &n= bsp;=20 link#2           &= nbsp;           =20 UHL        =20 lo0
fe80::%faith0/64        &n= bsp;        =20 fe80::210:b5ff:fee4:4386%faith0 Uc      =20 faith0
fe80::210:b5ff:fee4:4386%faith0  =20 link#3           &= nbsp;           =20 UHL        =20 lo0
fe80::%tun0/64        &nbs= p;          =20 fe80::210:b5ff:fee4:4386%tun0 = Uc        =20 tun0
fe80::210:b5ff:fee4:4386%tun0    =20 link#5           &= nbsp;           =20 UHL        =20 lo0
ff01::/32         &nb= sp;           &nbs= p;  =20 ::1           &nbs= p;            = ;  =20 U          =20 lo0
ff02::/16         &nb= sp;           &nbs= p;  =20 ::1           &nbs= p;            = ;  =20 UGRS       =20 lo0
ff02::%rl0/32         = ;           =20 link#1           &= nbsp;           =20 UC         =20 rl0
ff02::%lo0/32         = ;           =20 ::1           &nbs= p;            = ;  =20 UC         =20 lo0
ff02::%faith0/32        &n= bsp;        =20 fe80::210:b5ff:fee4:4386%faith0 UC      =20 faith0
ff02::%tun0/32        &= nbsp;          =20 fe80::210:b5ff:fee4:4386%tun0 = UC        =20 tun0
 
 
Thanks if you can=20 point me = in the right=20 direction.
 
Robert
 
---
Quantum Radio: World Music with = a=20 difference.
http://quantum-radio.net/
Now=20 Playing: Various - Aarti06
 
 
------=_NextPart_000_017F_01C1DCBC.3CCD89B0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 22:11:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 1285C37B41E for ; Thu, 4 Apr 2002 22:11:52 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g356Bdo13679; Fri, 5 Apr 2002 15:11:40 +0900 (JST) Date: Fri, 05 Apr 2002 15:11:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Merlin" Cc: "freebsd-net" Subject: Re: IPv6 question - Whaich one is the host and which is the interface ? In-Reply-To: <018201c1dc68$76e25b20$1a6001cb@chalmers.com.au> References: <018201c1dc68$76e25b20$1a6001cb@chalmers.com.au> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 16 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Fri, 5 Apr 2002 16:09:17 +1000, >>>>> "Merlin" said: > rl0 is the ethernet interface on the machine -and I'm setting up IPv6 over IPv4 (6to4), using the stf0 interface. The box is connected by PPP to the internet over tun0. > But I'm haveing trouble actually working out which is the host for the DNS, and which is the interface, global and local addresses and so on.? I don't understand the question...what is "the DNS"? What is "the interface"? What do you mean by "global and local addresses"? Please be more specific. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 22:42:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from nanguo.chalmers.com.au (nanguo.chalmers.com.au [203.1.96.5]) by hub.freebsd.org (Postfix) with ESMTP id ED6BC37B41C for ; Thu, 4 Apr 2002 22:42:03 -0800 (PST) Received: from carbon (carbon.chalmers.com.au [203.1.96.26]) by nanguo.chalmers.com.au (8.11.6/8.11.6) with SMTP id g356ifq01353 for ; Fri, 5 Apr 2002 16:44:41 +1000 (EST) (envelope-from robert@quantum-radio.net.au) Message-ID: <01fe01c1dc6d$55248fd0$1a6001cb@chalmers.com.au> Reply-To: "Merlin" From: "Merlin" To: "freebsd-net" Subject: to JINMEI, Tatuya. Rephrased last question Date: Fri, 5 Apr 2002 16:44:20 +1000 Organization: Quantum Radio MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ----- Original Message ----- > I don't understand the question...what is "the DNS"? What is "the > interface"? What do you mean by "global and local addresses"? > > Please be more specific. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > My apologies, I'll rephrase that. (ps - can't get to your email address?) My host name is nanguo.chalmers.com.au, on IPv4 203.1.96.5 netstat -rn shows: 203.1.96.5 0:10:b5:e4:43:86 UHLW 2 675 lo0 Which one of these IPv6 addresses is it's equivelant. 2002:cb01:6005::1 link#4 UHL lo0 2002:cb01:6005:1::1 link#4 UHL lo0 ...... because they both respond to ping6 $ ping6 2002:cb01:6005::1 PING6(56=40+8+8 bytes) 2002:cb01:6005::1 --> 2002:cb01:6005::1 16 bytes from 2002:cb01:6005::1, icmp_seq=0 hlim=64 time=0.155 ms 16 bytes from 2002:cb01:6005::1, icmp_seq=1 hlim=64 time=0.142 ms --- 2002:cb01:6005::1 ping6 statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/std-dev = 0.142/0.148/0.155/0.007 ms $ ping6 2002:cb01:6005:1::1 PING6(56=40+8+8 bytes) 2002:cb01:6005:1::1 --> 2002:cb01:6005:1::1 16 bytes from 2002:cb01:6005:1::1, icmp_seq=0 hlim=64 time=0.154 ms 16 bytes from 2002:cb01:6005:1::1, icmp_seq=1 hlim=64 time=0.1 ms 16 bytes from 2002:cb01:6005:1::1, icmp_seq=2 hlim=64 time=0.127 ms --- 2002:cb01:6005:1::1 ping6 statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/std-dev = 0.100/0.127/0.154/0.022 ms Thank you Robert To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 4 23:48: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id DB0DA37B417 for ; Thu, 4 Apr 2002 23:47:59 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g357l8o14282; Fri, 5 Apr 2002 16:47:08 +0900 (JST) Date: Fri, 05 Apr 2002 16:47:06 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Merlin" Cc: "freebsd-net" Subject: Re: to JINMEI, Tatuya. Rephrased last question In-Reply-To: <01fe01c1dc6d$55248fd0$1a6001cb@chalmers.com.au> References: <01fe01c1dc6d$55248fd0$1a6001cb@chalmers.com.au> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 28 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Fri, 5 Apr 2002 16:44:20 +1000, >>>>> "Merlin" said: > (ps - can't get to your email address?) (This was perhaps due to the mime-encoded full name in the from field. You can ignore this problem because I'm on the list. Please just reply to the list.) > My host name is nanguo.chalmers.com.au, on IPv4 203.1.96.5 > netstat -rn shows: > 203.1.96.5 0:10:b5:e4:43:86 UHLW 2 675 lo0 > Which one of these IPv6 addresses is it's equivelant. > 2002:cb01:6005::1 link#4 UHL lo0 > 2002:cb01:6005:1::1 link#4 UHL lo0 That depends on your local configuration. Please show us the result of % ifconfig -a and the contents of /etc/rc.conf (if you don't mind). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 0: 9: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from nanguo.chalmers.com.au (nanguo.chalmers.com.au [203.1.96.5]) by hub.freebsd.org (Postfix) with ESMTP id 010A537B404 for ; Fri, 5 Apr 2002 00:08:51 -0800 (PST) Received: from carbon (carbon.chalmers.com.au [203.1.96.26]) by nanguo.chalmers.com.au (8.11.6/8.11.6) with SMTP id g358Bhq01763 for ; Fri, 5 Apr 2002 18:11:43 +1000 (EST) (envelope-from robert@quantum-radio.net.au) Message-ID: <021301c1dc79$7d236630$1a6001cb@chalmers.com.au> Reply-To: "Merlin" From: "Merlin" To: "freebsd-net" References: <01fe01c1dc6d$55248fd0$1a6001cb@chalmers.com.au> Subject: Re: to JINMEI, Tatuya. Rephrased last question Date: Fri, 5 Apr 2002 18:11:28 +1000 Organization: Quantum Radio MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > My host name is nanguo.chalmers.com.au, on IPv4 203.1.96.5 > > netstat -rn shows: > > > 203.1.96.5 0:10:b5:e4:43:86 UHLW 2 675 lo0 > > > > Which one of these IPv6 addresses is it's equivelant. > > 2002:cb01:6005::1 link#4 UHL lo0 > > 2002:cb01:6005:1::1 link#4 UHL lo0 > > That depends on your local configuration. Please show us the result > of > % ifconfig -a > and the contents of /etc/rc.conf (if you don't mind). My pleasure. I'd like to get this working if I can. (properly) ifconfig -a: $ ifconfig -a rl0: flags=8943 mtu 1500 inet 203.1.96.5 netmask 0xffffff00 broadcast 203.1.96.255 inet6 fe80::210:b5ff:fee4:4386%rl0 prefixlen 64 scopeid 0x1 inet 203.1.96.155 netmask 0xffffffff broadcast 203.1.96.155 inet 203.1.96.200 netmask 0xffffffff broadcast 203.1.96.200 ether 00:10:b5:e4:43:86 media: Ethernet 10baseT/UTP status: active lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 faith0: flags=8043 mtu 1500 inet6 fe80::210:b5ff:fee4:4386%faith0 prefixlen 64 scopeid 0x3 stf0: flags=1 mtu 1280 inet6 2002:cb01:6005:1::1 prefixlen 16 inet6 2002:cb01:6005::1 prefixlen 16 tun0: flags=8051 mtu 1500 inet6 fe80::210:b5ff:fee4:4386%tun0 prefixlen 64 scopeid 0x5 inet 203.1.96.5 --> 139.130.78.1 netmask 0xffffff00 Opened by PID 56 ======================================== rc.conf (relative bits) gateway_enable="YES" hostname="nanguo.chalmers.com.au" ifconfig_rl0="inet 203.1.96.5 netmask 255.255.255.0 media 10baseT/UTP" ifconfig_stf0="inet6 2002:cb01:6005:0001::1 prefixlen 16 alias" inetd_enable="YES" # NO if using xinetd named_enable="YES" ipv6_enable="YES" ipv6_network_interfaces="auto" ipv6_gateway_enable="YES" ipv6_static_routes="default" ipv6_route_default="default 2002:c058:6301::" stf_interface_ipv4addr="203.1.96.5" rtadvd_enable="YES" rtadvd_interfaces="auto" ======================================== netstat -rn ( this needs copying to something like textpad to be readable) Internet: Destination Gateway Flags Refs Use Netif Expire default 139.130.78.1 UGSc 41 4455 tun0 127.0.0.1 127.0.0.1 UH 1 8236 lo0 139.130.78.1 203.1.96.5 UH 41 0 tun0 203.1.96.0 ff:ff:ff:ff:ff:ff UHLWb 0 3 rl0 => 203.1.96 link#1 UC 6 0 rl0 203.1.96.1 link#1 UHLW 1 2 rl0 203.1.96.5 0:10:b5:e4:43:86 UHLW 1 2937 lo0 203.1.96.6 0:40:5:4e:a9:82 UHLW 0 2895 rl0 423 203.1.96.26 52:54:5:e3:57:30 UHLW 9 278713 rl0 1124 203.1.96.155/32 link#1 UC 0 0 rl0 203.1.96.200/32 link#1 UC 0 0 rl0 203.1.96.255 ff:ff:ff:ff:ff:ff UHLWb 0 1 rl0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRSc lo0 => default 2002:c058:6301:: UGSc stf0 ::1 ::1 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRSc lo0 2002::/24 ::1 UGRSc lo0 => 2002::/16 2002:cb01:6005:1::1 Uc stf0 2002:7f00::/24 ::1 UGRSc lo0 2002:cb01:6005::1 link#4 UHL lo0 2002:cb01:6005:1::1 link#4 UHL lo0 2002:e000::/20 ::1 UGRSc lo0 2002:ff00::/24 ::1 UGRSc lo0 fe80::/10 ::1 UGRSc lo0 fe80::%rl0/64 link#1 UC rl0 fe80::210:b5ff:fee4:4386%rl0 0:10:b5:e4:43:86 UHL lo0 fe80::%lo0/64 fe80::1%lo0 Uc lo0 fe80::1%lo0 link#2 UHL lo0 fe80::%faith0/64 fe80::210:b5ff:fee4:4386%faith0 Uc faith0 fe80::210:b5ff:fee4:4386%faith0 link#3 UHL lo0 fe80::%tun0/64 fe80::210:b5ff:fee4:4386%tun0 Uc tun0 fe80::210:b5ff:fee4:4386%tun0 link#5 UHL lo0 ff01::/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%rl0/32 link#1 UC rl0 ff02::%lo0/32 ::1 UC lo0 ff02::%faith0/32 fe80::210:b5ff:fee4:4386%faith0 UC faith0 ff02::%tun0/32 fe80::210:b5ff:fee4:4386%tun0 UC tun0 $ I'm sorry if this is obvious to experts on this list, but IPv6 is new to me... and still a mystery. Thanks Robert > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 0:25:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by hub.freebsd.org (Postfix) with ESMTP id F36BB37B404 for ; Fri, 5 Apr 2002 00:25:26 -0800 (PST) Received: from localhost ([2001:240:10a:1000:260:1dff:fe21:f766]) by papa.tanu.org (8.11.6/8.11.6) with ESMTP id g358MYv41096; Fri, 5 Apr 2002 17:22:35 +0900 (JST) (envelope-from sakane@kame.net) To: sam@errno.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: kame ipsec vs. openbsd ipsec In-Reply-To: Your message of "Wed, 3 Apr 2002 10:13:35 -0800" <2c1d01c1db3b$460c7720$52557f42@errno.com> References: <2c1d01c1db3b$460c7720$52557f42@errno.com> X-Mailer: Cue version 0.6 (011026-1440/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20020405172620N.sakane@kame.net> Date: Fri, 05 Apr 2002 17:26:20 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 59 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > 1. Has anyone else seriously looked at doing this? > 2. Has anyone compared the OpenBSD and KAME implementations and understand > their relative strengths? (e.g. is there some reason to work with KAME other > than it's already in the system) i have summarized what some people argued to merge OpenBSD IPsec implementation into FreeBSD. some people say that OpenBSD has advantage because: 1. it supports the crypto hardware acceleration. 2. because SA is shown as a pseudo interface, 2-a. we can see how packets are flowed through the interface by netstat(8). 2-b. it can configure packet rules easily. 2-c. routing information can be flowed into the interface. 3. we can see parameters and the statistics of the SA. 4. SPD is implemented into the routing table. i can say about KAME implementation against above points. 1. doesn't support it. 2-a. we can see them. 2-b. we can define it. 2-c. cannot do it. 3. we can see them. 4. SPD is implemented by a filtering base. about 1, OpenBSD gives up to support the multiple mixed SA both ESP and AH in order to support hardware acceleration. it means the kernel cannot construct a packet like IP|ESP|AH|ESP|ULP. but KAME can do that because RFC2401, which is the specification of IPsec architecture, doesn't prohibit to generate the packet. itojun@kame.net says that why we haven't supported the feature, with fine-grain kernel threads present, i hope to see no restructuring of ip_input/output path. (openbsd splitted the function into two) about 2-a, KAME records how packets are transmitted, when the SA is used, when the SA is created and so on. we can see them of each SA by using setkey(8). about 2-b, i'm not sure how easy to configure the packet filter rule in OpenBSD. KAME can do that similarly by using setkey(8), ipf(8) or ipfw(8). about 2-c, is it possible on OpenBSD surely ? KAME cannot do it when we use IPsec tunnel mode. larse@isi.edu tell us how the feature can be implemented. about 3, KAME can show them by using setkey(8) because SA has them. about 4, we don't like to create a pseudo interface of each SA, in particular, when we use IPsec transport mode. each userland process can use individual SA in KAME. this function is specified by RFC2401. when we would choice to implement SA by a interface base, how many interface we would need. also we want to avoid infinity loop due to mistaken the configuration of IPsec tunnel mode. basically we have many tunnel protocols on several layer. there are many methods in the internet for implementing a single purpose. please, correct me if i'm misunderstanding. _IMHO_, if IETF would employ the draft-touch-ipsec-vpn approach, we could get rid of the redundant protocol. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 0:36:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by hub.freebsd.org (Postfix) with ESMTP id 98CA637B41A for ; Fri, 5 Apr 2002 00:36:34 -0800 (PST) Received: from localhost ([2001:240:10a:1000:260:1dff:fe21:f766]) by papa.tanu.org (8.11.6/8.11.6) with ESMTP id g358Xkv41144; Fri, 5 Apr 2002 17:33:46 +0900 (JST) (envelope-from sakane@kame.net) To: sam@errno.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: kame ipsec vs. openbsd ipsec In-Reply-To: Your message of "Fri, 05 Apr 2002 17:26:20 +0900" <20020405172620N.sakane@kame.net> References: <20020405172620N.sakane@kame.net> X-Mailer: Cue version 0.6 (011026-1440/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20020405173731D.sakane@kame.net> Date: Fri, 05 Apr 2002 17:37:31 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 13 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > some people say that OpenBSD has advantage because: > 2. because SA is shown as a pseudo interface, > about 4, we don't like to create a pseudo interface of each SA, > in particular, when we use IPsec transport mode. each userland > process can use individual SA in KAME. this function is specified by > RFC2401. when we would choice to implement SA by a interface base, > how many interface we would need. i have heard that openbsd have a single interface, enc0 for only ESP flow. all of ESP packets are threw to this interface. is that right ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 0:44:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from starfruit.itojun.org (dhcp108.iijlab.net [202.232.15.108]) by hub.freebsd.org (Postfix) with ESMTP id EE42037B404 for ; Fri, 5 Apr 2002 00:44:50 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E731A7B9; Fri, 5 Apr 2002 17:44:36 +0900 (JST) To: freebsd-net@FreeBSD.ORG Subject: Re: kame ipsec vs. openbsd ipsec References: <20020405172620N.sakane@kame.net> 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 From: Jun-ichiro itojun Hagino Date: Fri, 05 Apr 2002 17:44:36 +0900 Message-Id: <20020405084437.E731A7B9@starfruit.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >> 1. Has anyone else seriously looked at doing this? >> 2. Has anyone compared the OpenBSD and KAME implementations and understand >> their relative strengths? (e.g. is there some reason to work with KAME other >> than it's already in the system) > >i have summarized what some people argued to merge OpenBSD IPsec >implementation into FreeBSD. > >some people say that OpenBSD has advantage because: > 1. it supports the crypto hardware acceleration. > 2. because SA is shown as a pseudo interface, > 2-a. we can see how packets are flowed through the interface > by netstat(8). > 2-b. it can configure packet rules easily. > 2-c. routing information can be flowed into the interface. > 3. we can see parameters and the statistics of the SA. > 4. SPD is implemented into the routing table. observation 2-[abc] are incorrect. openbsd uses enc0 interface which enables people to run tcpdump against packets after ESP decapsulation (or before encapsulation). the interface is a pseudo interface, and you cannot run routing protocol over it. enc0 interface won't be instantiated per-SA (one interface is shared for all SAs). KAME does not have enc0 interface or alike as doing so breaks IPv6 scoping architecture (in short, you can never play with m->m_pkthdr.rcvif, as addresses must be evaluated under certain interface's context). 4 is also incorrect. SPD is implemented as a radix tree, separate from IPv4 (or IPv6) routing table. therefore, it has nothing to do with normal routing table. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 7:28:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail2.it.kth.se (mail2.it.kth.se [130.237.212.132]) by hub.freebsd.org (Postfix) with ESMTP id 61DF637BB8D for ; Fri, 5 Apr 2002 07:26:35 -0800 (PST) Received: from kurt (iw01-194.it.kth.se [130.237.213.194]) by mail2.it.kth.se (8.9.3/8.9.3) with SMTP id RAA08706 for ; Fri, 5 Apr 2002 17:15:25 +0200 (MET DST) Message-ID: <000a01c1dcb4$b63bc940$c2d5ed82@kurt> From: "Ke Chen" To: Subject: about gif interface! Date: Fri, 5 Apr 2002 17:15:24 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C1DCC5.7982D550" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C1DCC5.7982D550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, I have some problems about gif interface. Could gif interface be bridged together with Ethernet interface? I have one machines with 2 Ethernet card, one is fxp0, the other is = fxp1=20 I create a gif interface by using ifconfig gif0 create then I add this configuration to /etc/sysctl.conf net.link.ether.bridge=3D1 net.link.ether.bridge_cfg=3Dfxp0:0,gif0:0,fxp1:1 I want to use this configuration to bind fxp0 and gif0 together. The = data frames could flow from fxp0 to gif0 but not to fxp1. I am not sure it is the right mailing list I should post the messge. = If i am wrong, would you be kind to forward it to the right mailing = list? thank you very much. best regards, kurt ------=_NextPart_000_0007_01C1DCC5.7982D550 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi,
   I have some problems about = gif =20 interface.
   Could gif interface be = bridged=20 together with Ethernet interface?
 
   I have one machines with 2 = Ethernet=20 card, one is fxp0, the other is fxp1 
  I create a gif interface by = using=20 ifconfig gif0 create
   then I add this = configuration to=20 /etc/sysctl.conf
  = net.link.ether.bridge=3D1
 =20 net.link.ether.bridge_cfg=3Dfxp0:0,gif0:0,fxp1:1
 
  I want to use this = configuration to=20 bind fxp0 and gif0 together. The data frames could flow from fxp0 to = gif0 but=20 not to fxp1.
 
  I am not sure it is the right = mailing list I=20 should post the messge. If i am wrong, would you be kind to forward it = to the=20 right mailing list?
  thank you very = much.
 
best regards,
kurt
------=_NextPart_000_0007_01C1DCC5.7982D550-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 8: 5:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 96CE437B41A for ; Fri, 5 Apr 2002 08:05:12 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g35G3Io17140; Sat, 6 Apr 2002 01:03:18 +0900 (JST) Date: Sat, 06 Apr 2002 01:03:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Merlin" Cc: "freebsd-net" Subject: Re: to JINMEI, Tatuya. Rephrased last question In-Reply-To: <021301c1dc79$7d236630$1a6001cb@chalmers.com.au> References: <01fe01c1dc6d$55248fd0$1a6001cb@chalmers.com.au> <021301c1dc79$7d236630$1a6001cb@chalmers.com.au> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 37 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Fri, 5 Apr 2002 18:11:28 +1000, >>>>> "Merlin" said: >> > Which one of these IPv6 addresses is it's equivelant. >> > 2002:cb01:6005::1 link#4 UHL lo0 >> > 2002:cb01:6005:1::1 link#4 UHL lo0 >> >> That depends on your local configuration. Please show us the result >> of >> % ifconfig -a >> and the contents of /etc/rc.conf (if you don't mind). > My pleasure. I'd like to get this working if I can. (properly) > ifconfig -a: > $ ifconfig -a > stf0: flags=1 mtu 1280 > inet6 2002:cb01:6005:1::1 prefixlen 16 > inet6 2002:cb01:6005::1 prefixlen 16 Then, both of the 2002 addresses are "equivalent". Actually, > ifconfig_stf0="inet6 2002:cb01:6005:0001::1 prefixlen 16 alias" you should be able to omit this. Then you'll only see 2002:cb01:6005::1 or, if you prefer 2002:cb01:6005:1::1, add the following line to /etc/rc.conf: stf_interface_ipv6_slaid="0001" as well as removing the line "ifconfig_stf0...". JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 8:31:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by hub.freebsd.org (Postfix) with ESMTP id 9EC9A37B405 for ; Fri, 5 Apr 2002 08:31:11 -0800 (PST) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.1/8.12.1) with ESMTP id g35GV9pt040501 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 5 Apr 2002 08:31:10 -0800 (PST)?g (envelope-from sam@errno.com)œ Message-ID: <354301c1dcbf$5a6d95c0$52557f42@errno.com> From: "Sam Leffler" To: "Shoichi Sakane" Cc: References: <2c1d01c1db3b$460c7720$52557f42@errno.com> <20020405172620N.sakane@kame.net> Subject: Re: kame ipsec vs. openbsd ipsec Date: Fri, 5 Apr 2002 08:31:34 -0800 Organization: Errno Consulting 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ----- Original Message ----- From: "Shoichi Sakane" To: Cc: Sent: Friday, April 05, 2002 12:26 AM Subject: Re: kame ipsec vs. openbsd ipsec > > 1. Has anyone else seriously looked at doing this? > > 2. Has anyone compared the OpenBSD and KAME implementations and understand > > their relative strengths? (e.g. is there some reason to work with KAME other > > than it's already in the system) > > i have summarized what some people argued to merge OpenBSD IPsec > implementation into FreeBSD. > > some people say that OpenBSD has advantage because: > 1. it supports the crypto hardware acceleration. The advantage is that openbsd has it working now. I started this thread because it appeared that adding the same functionality to the KAME implementation would cause the KAME code to look a lot like the openbsd implementation. > 2. because SA is shown as a pseudo interface, > 2-a. we can see how packets are flowed through the interface > by netstat(8). > 2-b. it can configure packet rules easily. > 2-c. routing information can be flowed into the interface. > 3. we can see parameters and the statistics of the SA. > 4. SPD is implemented into the routing table. > > i can say about KAME implementation against above points. > 1. doesn't support it. > 2-a. we can see them. > 2-b. we can define it. > 2-c. cannot do it. > 3. we can see them. > 4. SPD is implemented by a filtering base. > > about 1, OpenBSD gives up to support the multiple mixed SA > both ESP and AH in order to support hardware acceleration. > it means the kernel cannot construct a packet like IP|ESP|AH|ESP|ULP. > but KAME can do that because RFC2401, which is the specification of > IPsec architecture, doesn't prohibit to generate the packet. > itojun@kame.net says that why we haven't supported the feature, > openbsd supports mixed SA, but only with a single ESP and AH. itojun explained privately, however that openbsd does not support multiple ESP/AH headers as required by an iterated VPN cloud (VPN cloud within VPN cloud). This issue is, however, separate from the hardware acceleration of the crypto operations. > with fine-grain kernel threads present, i hope to see no restructuring > of ip_input/output path. (openbsd splitted the function into two) > I've exchanged several notes with itojun about this. The key requirement that I see is that the input processing thread be able to block when a crypto operation is dispatched to the hardware. itojun (and it sounds like you too) suggest forking from the softnet context to wait for the crypto operation to complete. This would require obtaining a new context in which one can sleep and possibly also require changing the existing software interrupt thread to a different context (e.g. a process) in which one can block. This seems expensive--I don't see how to do this cheaply in FreeBSD. openbsd dealt with this problem by not blocking, but instead using continuations (crypto ops are queud to a crypto processing thread/process and when they complete a callback is made to continue the packet/protocol processing). The other concern I have with your approach is that each crypto operation must be dispatched and waited for separately. This means, for example, if a packet requires both AH+ESP crypto operations then there would be two "fork+wait" exchanges. openbsd batches these operations and continues packet processing only after both have completed. Again, this could be done for KAME whether one blocks directly or uses a continuation-style approach. Perhaps I've misunderstood your intention. Can you explain in more detail how you expected to do things as you suggest? Remember also that I need a solution that works in both -stable and -current. > about 2-a, KAME records how packets are transmitted, when the SA is used, > when the SA is created and so on. we can see them of each SA by using > setkey(8). > about 2-b, i'm not sure how easy to configure the packet filter > rule in OpenBSD. KAME can do that similarly by using setkey(8), ipf(8) > or ipfw(8). > about 2-c, is it possible on OpenBSD surely ? > KAME cannot do it when we use IPsec tunnel mode. larse@isi.edu tell us > how the feature can be implemented. > about 3, KAME can show them by using setkey(8) because SA has them. > about 4, we don't like to create a pseudo interface of each SA, > in particular, when we use IPsec transport mode. each userland > process can use individual SA in KAME. this function is specified by > RFC2401. when we would choice to implement SA by a interface base, > how many interface we would need. also we want to avoid infinity > loop due to mistaken the configuration of IPsec tunnel mode. > basically we have many tunnel protocols on several layer. there are > many methods in the internet for implementing a single purpose. > > please, correct me if i'm misunderstanding. > > _IMHO_, if IETF would employ the draft-touch-ipsec-vpn approach, > we could get rid of the redundant protocol. > Yes, I read the draft-touch document yesterday and agree. The above items, while different, do not look so difficult to reconcile (e.g. add to openbsd). I'd prefer to work with the KAME implementation for many reasons, not the least of which is adding hardware support would benefit the most people. I started this discussion because I was concerned that adding hardware crypto support would lead me down the same path as openbsd and result in more work than starting from the openbsd implementation. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 8:52: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 5903837B41B for ; Fri, 5 Apr 2002 08:51:58 -0800 (PST) Received: from isi.edu (mzqi4d84aax0niuy@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g35FoST10215; Fri, 5 Apr 2002 07:50:28 -0800 (PST) Message-ID: <3CADC7C4.6030609@isi.edu> Date: Fri, 05 Apr 2002 07:50:28 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020329 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Ke Chen Cc: freebsd-net@FreeBSD.org Subject: Re: about gif interface! References: <000a01c1dcb4$b63bc940$c2d5ed82@kurt> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090007020502070803020704" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms090007020502070803020704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ke Chen wrote: > hi, > > I have some problems about gif interface. > > Could gif interface be bridged together with Ethernet interface? Sorry, I can't help you with Ethernet bridging (never set one up), but I can tell you that you will not need a gif interface for it (that's for IP tunnels). Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms090007020502070803020704 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDQwNTE1NTAyOFowIwYJKoZIhvcNAQkEMRYEFMZI/1OI5tSJ5AWX7HHhL2+QpCDYMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYAi/EqYj2hscuo5UDvx53XtpP7T6JVRBJwtTCL42TjylFOfhtXBJy6a6JaEsi0VjELR ZSGWYtSCkuLIxXLdvDFMIzCgihV115imAX57hK64M9UV/BOq+qBqgI/DHlEqdABRdLgqvtRL CdvV1QLQB6QDVkwCrjenmSWVEdyZyugEFwAAAAAAAA== --------------ms090007020502070803020704-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 9:35:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from hub.islandnet.com (hub.islandnet.com [199.175.106.11]) by hub.freebsd.org (Postfix) with ESMTP id 9A14837B404 for ; Fri, 5 Apr 2002 09:35:17 -0800 (PST) Received: (from root@localhost) by hub.islandnet.com (8.11.6/8.11.6) id g35HZH359012 for freebsd-net@FreeBSD.ORG; Fri, 5 Apr 2002 09:35:17 -0800 (PST) (envelope-from wsmuir@islandnet.com) X-Mailer: inMAIL [http://www.islandnet.com/inmail.html] Message-ID: <020405093517@islandnet.com> Date: Fri, 05 Apr 2002 09:35:17 -0800 From: wsmuir@islandnet.com To: freebsd-net@FreeBSD.ORG Subject: one machine, 2 external nics Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all... I'd really appreciate a hint or two on this. I'm having problems deciding on the 'best way' for this one... I have a freebsd 4.2 firewall machine built and have it plugged into both a dsl modem with static ips and a cable modem with static ips... what I am trying to do is have the machine respond to the outside like it was 2 separate machines. for instance i want to be able to connect to sshd on either external ip and have it respond. my understanding is that it won't do this because the 2nd nic doesn't know how to route beyond its own subnet. this is to solve a bigger problem for which there are other solutions, but I would like to know how to do this one specifically... thank you Scott. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 10:32:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id D806837B405 for ; Fri, 5 Apr 2002 10:32:20 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g35IWBq04771; Fri, 5 Apr 2002 10:32:11 -0800 Date: Fri, 5 Apr 2002 10:32:11 -0800 From: Brooks Davis To: Ke Chen Cc: freebsd-net@FreeBSD.ORG Subject: Re: about gif interface! Message-ID: <20020405103211.B29398@Odin.AC.HMC.Edu> References: <000a01c1dcb4$b63bc940$c2d5ed82@kurt> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Bn2rw/3z4jIqBvZU" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000a01c1dcb4$b63bc940$c2d5ed82@kurt>; from iw01_cke@it.kth.se on Fri, Apr 05, 2002 at 05:15:24PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 05, 2002 at 05:15:24PM +0200, Ke Chen wrote: >=20 > hi, > =20 > I have some problems about gif interface. > =20 > Could gif interface be bridged together with Ethernet interface? No. Bridging works between interfaces with the same framing. Generally this means you can brige Ethernet to Ethernet and some time (though I don't think we can support it) Ethernet to Token Ring or FDDI. The gif interface is not an Ethernet interface or anything like one. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --Bn2rw/3z4jIqBvZU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8re2qXY6L6fI4GtQRAoAYAKDLJ6W5p6B3JRqzBOSpFiBzeslcrwCfa2ju UHRlGC6B/0tExVksiV+E34g= =joj+ -----END PGP SIGNATURE----- --Bn2rw/3z4jIqBvZU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 11:40:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 3640E37B41B for ; Fri, 5 Apr 2002 11:40:18 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020405194017.FEEY3676.rwcrmhc52.attbi.com@InterJet.elischer.org>; Fri, 5 Apr 2002 19:40:17 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA37237; Fri, 5 Apr 2002 11:27:59 -0800 (PST) Date: Fri, 5 Apr 2002 11:27:59 -0800 (PST) From: Julian Elischer To: Lars Eggert Cc: Ke Chen , freebsd-net@FreeBSD.org Subject: Re: about gif interface! In-Reply-To: <3CADC7C4.6030609@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org .se? anyhow you may be able to do what you want to do bu you need to tell us a bit more.. what is at the other end of the gif tunnel? are you trying o bridge two networks or just add a single machine to your network? On Fri, 5 Apr 2002, Lars Eggert wrote: > Ke Chen wrote: > > hi, > > > > I have some problems about gif interface. > > > > Could gif interface be bridged together with Ethernet interface? > > Sorry, I can't help you with Ethernet bridging (never set one up), but I > can tell you that you will not need a gif interface for it (that's for > IP tunnels). > > Lars > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 12: 9:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail2.it.kth.se (mail2.it.kth.se [130.237.212.132]) by hub.freebsd.org (Postfix) with ESMTP id C652C37B41B for ; Fri, 5 Apr 2002 12:09:24 -0800 (PST) Received: from kurt (iw01-194.it.kth.se [130.237.213.194]) by mail2.it.kth.se (8.9.3/8.9.3) with SMTP id WAA12851; Fri, 5 Apr 2002 22:09:10 +0200 (MET DST) Message-ID: <002a01c1dcdd$bfd36570$c2d5ed82@kurt> From: "Ke Chen" To: "Julian Elischer" , "Lars Eggert" , "Brooks Davis" Cc: References: Subject: Re: about gif interface! Date: Fri, 5 Apr 2002 22:09:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi, thank all of you for such quick reply. I am sorry for not addressing matters clearly. In face, I want to do tests on Ethernet over IP. That means one end of tunnel could encapsulate the whole Ethernet frame into the IP packet. when the datagrams reach on the other side, the Ethernet frame could be freed out. I read from the following article about a easy way to implement it with OpenBSD. So i think it is reasonable to use it with freeBSD. http://www.csh.rit.edu/~jon/papers/tunneling/ Another way to implement Ethernet over IP is to use vtun, a specially desgined software. http://vtun.sourceforge.net I really appreciated someone could offer some experience on it. thank you again. best regards, kurt ----- Original Message ----- From: "Julian Elischer" To: "Lars Eggert" Cc: "Ke Chen" ; Sent: Friday, April 05, 2002 9:27 PM Subject: Re: about gif interface! > > .se? > > anyhow you may be able to do what you want to do bu you need to > tell us a bit more.. > > what is at the other end of the gif tunnel? > are you trying o bridge two networks or just add a single > machine to your network? > > > On Fri, 5 Apr 2002, Lars Eggert wrote: > > > Ke Chen wrote: > > > hi, > > > > > > I have some problems about gif interface. > > > > > > Could gif interface be bridged together with Ethernet interface? > > > > Sorry, I can't help you with Ethernet bridging (never set one up), but I > > can tell you that you will not need a gif interface for it (that's for > > IP tunnels). > > > > Lars > > -- > > Lars Eggert Information Sciences Institute > > http://www.isi.edu/larse/ University of Southern California > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 12:40:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id D8F6337B419 for ; Fri, 5 Apr 2002 12:40:07 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020405204007.ELPG18078.rwcrmhc51.attbi.com@InterJet.elischer.org>; Fri, 5 Apr 2002 20:40:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA37588; Fri, 5 Apr 2002 12:26:43 -0800 (PST) Date: Fri, 5 Apr 2002 12:26:43 -0800 (PST) From: Julian Elischer To: Ke Chen Cc: Lars Eggert , Brooks Davis , freebsd-net@FreeBSD.org Subject: Re: about gif interface! In-Reply-To: <002a01c1dcdd$bfd36570$c2d5ed82@kurt> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org you can do this with no code using the eiface netgraph node and the ksocket netgraph node. (I don't think I have the eiface node in 4.x yet... I'll need to check.) julian On Fri, 5 Apr 2002, Ke Chen wrote: > hi, > thank all of you for such quick reply. > I am sorry for not addressing matters clearly. > In face, I want to do tests on Ethernet over IP. That means one end of > tunnel could encapsulate the whole Ethernet frame into the IP packet. when > the datagrams reach on the other side, the Ethernet frame could be freed > out. > I read from the following article about a easy way to implement it with > OpenBSD. So i think it is reasonable to use it with freeBSD. > http://www.csh.rit.edu/~jon/papers/tunneling/ > > Another way to implement Ethernet over IP is to use vtun, a specially > desgined software. > http://vtun.sourceforge.net > I really appreciated someone could offer some experience on it. > > thank you again. > > best regards, > kurt > > ----- Original Message ----- > From: "Julian Elischer" > To: "Lars Eggert" > Cc: "Ke Chen" ; > Sent: Friday, April 05, 2002 9:27 PM > Subject: Re: about gif interface! > > > > > > .se? > > > > anyhow you may be able to do what you want to do bu you need to > > tell us a bit more.. > > > > what is at the other end of the gif tunnel? > > are you trying o bridge two networks or just add a single > > machine to your network? > > > > > > On Fri, 5 Apr 2002, Lars Eggert wrote: > > > > > Ke Chen wrote: > > > > hi, > > > > > > > > I have some problems about gif interface. > > > > > > > > Could gif interface be bridged together with Ethernet interface? > > > > > > Sorry, I can't help you with Ethernet bridging (never set one up), but I > > > can tell you that you will not need a gif interface for it (that's for > > > IP tunnels). > > > > > > Lars > > > -- > > > Lars Eggert Information Sciences Institute > > > http://www.isi.edu/larse/ University of Southern California > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 13:20:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id D19C037B419; Fri, 5 Apr 2002 13:20:33 -0800 (PST) Received: from bmah.dyndns.org ([12.233.149.189]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020405212033.GBLD18078.rwcrmhc51.attbi.com@bmah.dyndns.org>; Fri, 5 Apr 2002 21:20:33 +0000 Received: from intruder.bmah.org (localhost [IPv6:::1]) by bmah.dyndns.org (8.12.2/8.12.2) with ESMTP id g35LKXt2034175; Fri, 5 Apr 2002 13:20:33 -0800 (PST) (envelope-from bmah@intruder.bmah.org) Received: (from bmah@localhost) by intruder.bmah.org (8.12.2/8.12.2/Submit) id g35LKW00034174; Fri, 5 Apr 2002 13:20:32 -0800 (PST) Message-Id: <200204052120.g35LKW00034174@intruder.bmah.org> X-Mailer: exmh version 2.5+ 20020404 with nmh-1.0.4 To: Andrew Gallatin Cc: Terry Lambert , bmah@FreeBSD.ORG, net@FreeBSD.ORG Subject: IP fragmentation (was Re: Fatal trap 12: page fault while in kernel mode) In-reply-to: <15533.57961.725030.692387@grasshopper.cs.duke.edu> References: <20020403181854.I42720-100000@angui.sh> <15532.29114.310072.957330@grasshopper.cs.duke.edu> <200204050504.g355493C001200@intruder.bmah.org> <15533.46222.49598.958821@grasshopper.cs.duke.edu> <3CADE0E7.ED472650@mindspring.com> <15533.57961.725030.692387@grasshopper.cs.duke.edu> Comments: In-reply-to Andrew Gallatin message dated "Fri, 05 Apr 2002 12:44:09 -0500." From: bmah@FreeBSD.ORG (Bruce A. Mah) Reply-To: bmah@FreeBSD.ORG X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Apr 2002 13:20:32 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [Moving to -net] If memory serves me right, Andrew Gallatin wrote: > > Alternately, it would be a good idea to have a "ip_maxpacketfrags" > > instead of an "ip_maxfragpackets", to put a hard limit on the > > number of mbufs that can be consumed by the fragment reassembly > > process. > > I think this is the best solution. Just for the heck of it, I started reading through ip_input.c to see how hard this would be to do. Haven't got there yet, I saw something odd: the variables ip_nfragpackets and nipq look *awfully* similar. It looks like they both track the number of reassembly queues, because they're initialized to zero, and incremented and decremented at the same time. Their limits (ip_maxfragpackets and maxnipq respectively) are even initialized on consecutive lines. The only difference I can see is that in ip_input(), if nipq > maxnipq, all of the fragments for some other packet in the current hash bucket get dropped (with the wonderfully descriptive comment "gak"). The check for ip_nfragpackets comes in ip_reass(), where if ip_nfragpackets >= ip_maxfragpackets, then we drop the current fragment. (Is it possible that the second check masks the effects of the first?) I couldn't find any obvious explanation in the CVS log for ip_input.c. Am I missing something, or are these two variables basically doing the same thing? Thanks, Bruce. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 15:10:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id 7E24C37B405; Fri, 5 Apr 2002 15:10:03 -0800 (PST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id E423F1E03D; Fri, 5 Apr 2002 18:10:02 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA22215; Fri, 5 Apr 2002 18:10:02 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id PAA21604; Fri, 5 Apr 2002 15:10:02 -0800 (PST) Message-Id: <200204052310.PAA21604@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bmah@FreeBSD.ORG Subject: Re: IP fragmentation (was Re: Fatal trap 12: page fault while in kernel mode) Cc: gallatin@cs.duke.edu, tlambert2@mindspring.com, net@FreeBSD.ORG References: <20020403181854.I42720-100000@angui.sh> <15532.29114.310072.957330@grasshopper.cs.duke.edu> <200204050504.g355493C001200@intruder.bmah.org> <15533.46222.49598.958821@grasshopper.cs.duke.edu> <3CADE0E7.ED472650@mindspring.com> <15533.57961.725030.692387@grasshopper.cs.duke.edu> <200204052120.g35LKW00034174@intruder.bmah.org> Date: Fri, 5 Apr 2002 15:10:02 -0800 Versions: dmail (solaris) 2.4/makemail 2.9b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Just for the heck of it, I started reading through ip_input.c to see how >hard this would be to do. Haven't got there yet, I saw something odd: >the variables ip_nfragpackets and nipq look *awfully* similar. So do the commit logs for the revisions in which each was introduced. Revision 1.65 - Mon Sep 15 23:07:01 1997 UTC (4 years, 6 months ago) by ache Prevent overflow with fragmented packets vs. Revision 1.169 - Sun Jun 3 23:33:23 2001 UTC (10 months ago) by jesper Prevent denial of service using bogus fragmented IPv4 packets. so I think you're right, that they're both meant to do the same thing but neither is doing what they intended. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 15:28:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 4F61837B416 for ; Fri, 5 Apr 2002 15:28:42 -0800 (PST) Received: (from rousskov@localhost) by measurement-factory.com (8.11.6/8.11.6) id g35NSbb67425; Fri, 5 Apr 2002 16:28:37 -0700 (MST) (envelope-from rousskov) Date: Fri, 5 Apr 2002 16:28:37 -0700 (MST) From: Alex Rousskov To: freebsd-net@FreeBSD.ORG Subject: Forcing packets to the wire Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi there, I have two Ethernet NICs inside a PC. I want TCP/IP packets to leave one NIC, go on the wire, and eventually arrive at the other NIC. I do not want the kernel to be smart and shortcut the path. I want the outside world to see the packets and to think that my two NICs are two PCs talking to each other. Could any networking guru answer the following questions: - Is it possible without kernel modifications? How? - If kernel modifications are required, how extensive would they be (e.g., how many hours would it take a guru to implement the required functionality)? I am flexible as far as IP addressing scheme is concerned, though I would prefer to be able to put both NIC IP addresses on one and on separate subnets (from the outside world point of view). Again, I want the outside world think that these NICs are inside two PCs. If you want to know a "use case" for this strange requirement, here it is: I am building an appliance to test HTTP proxies. I want an appliance to have one NIC for the "client side" and one NIC for the "server side". I want to be able to run no-proxy test through the networking gear (a baseline experiment testing hubs/switches for bottlenecks), and I want to test "transparent proxies" (clients think they send requests directly to servers). Thank you, Alex. P.S. So far, all attempts to make this work have failed. Even jail environment does not go far enough and lets the "jailed" packet to traverse the kernel instead of using the wires... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 15:45:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id D1C2737B41A; Fri, 5 Apr 2002 15:45:24 -0800 (PST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 3349A4CE17; Fri, 5 Apr 2002 18:45:24 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA22711; Fri, 5 Apr 2002 18:45:23 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id PAA21989; Fri, 5 Apr 2002 15:45:23 -0800 (PST) Message-Id: <200204052345.PAA21989@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bmah@FreeBSD.ORG Subject: Re: IP fragmentation (was Re: Fatal trap 12: page fault while in kernel mode) Cc: net@FreeBSD.ORG References: <20020403181854.I42720-100000@angui.sh> <15532.29114.310072.957330@grasshopper.cs.duke.edu> <200204050504.g355493C001200@intruder.bmah.org> <15533.46222.49598.958821@grasshopper.cs.duke.edu> <3CADE0E7.ED472650@mindspring.com> <15533.57961.725030.692387@grasshopper.cs.duke.edu> <200204052120.g35LKW00034174@intruder.bmah.org> Date: Fri, 5 Apr 2002 15:45:22 -0800 Versions: dmail (solaris) 2.4/makemail 2.9b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >The only difference I can see is that in ip_input(), if nipq > maxnipq, >all of the fragments for some other packet in the current hash bucket >get dropped (with the wonderfully descriptive comment "gak"). The best thing to do is to drop the oldest frag queue; that's obviously non-trivial with the current data structures. The problem with the ip_nfragments code is that if space becomes available in the middle of reception of an entire packet, a queue will be created to reassemble a packet that will never completely arrive (since we dropped some of the beginning of it due to no space). I guess the nipq code has a similar problem: it will gladly free a queue that contains fragments that go with the next fragment that arrives. In fact, if datagrams that hash to the same bucket arrive with interleaved fragments, the nipq code could thrash between the two packets, creating and deleting a frag queue for each fragment arrival, dropping both datagrams. To address this kind of problem, it might be worth creating a "drop" frag queue entry, which is a way to remember that we dropped fragments from a given datagram so we should drop all the other fragments too. (I'd also go for modifying the data structures to make it easy to drop the oldest frag queue.) Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 16:12:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 7A2BE37B419; Fri, 5 Apr 2002 16:12:13 -0800 (PST) Received: from bmah.dyndns.org ([12.233.149.189]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020406001213.MZBE18078.rwcrmhc51.attbi.com@bmah.dyndns.org>; Sat, 6 Apr 2002 00:12:13 +0000 Received: from intruder.bmah.org (localhost [IPv6:::1]) by bmah.dyndns.org (8.12.2/8.12.2) with ESMTP id g360CCt2056168; Fri, 5 Apr 2002 16:12:12 -0800 (PST) (envelope-from bmah@intruder.bmah.org) Received: (from bmah@localhost) by intruder.bmah.org (8.12.2/8.12.2/Submit) id g360CC99056167; Fri, 5 Apr 2002 16:12:12 -0800 (PST) Message-Id: <200204060012.g360CC99056167@intruder.bmah.org> X-Mailer: exmh version 2.5+ 20020404 with nmh-1.0.4 To: Bill Fenner Cc: bmah@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: IP fragmentation (was Re: Fatal trap 12: page fault while in kernel mode) In-reply-to: <200204052345.PAA21989@windsor.research.att.com> References: <20020403181854.I42720-100000@angui.sh> <15532.29114.310072.957330@grasshopper.cs.duke.edu> <200204050504.g355493C001200@intruder.bmah.org> <15533.46222.49598.958821@grasshopper.cs.duke.edu> <3CADE0E7.ED472650@mindspring.com> <15533.57961.725030.692387@grasshopper.cs.duke.edu> <200204052120.g35LKW00034174@intruder.bmah.org> <200204052345.PAA21989@windsor.research.att.com> Comments: In-reply-to Bill Fenner message dated "Fri, 05 Apr 2002 15:45:22 -0800." From: bmah@FreeBSD.ORG (Bruce A. Mah) Reply-To: bmah@FreeBSD.ORG X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Apr 2002 16:12:12 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org If memory serves me right, Bill Fenner wrote: > The problem with the ip_nfragments code is that if space becomes > available in the middle of reception of an entire packet, a queue > will be created to reassemble a packet that will never completely > arrive (since we dropped some of the beginning of it due to no space). > I guess the nipq code has a similar problem: it will gladly free > a queue that contains fragments that go with the next fragment that > arrives. ...but of course the "obvious" solution of only creating the queue when we see a fragment with offset 0 doesn't work, because of the potential of out-of-order delivery. Sigh. > In fact, if datagrams that hash to the same bucket arrive with > interleaved fragments, the nipq code could thrash between the two > packets, creating and deleting a frag queue for each fragment arrival, > dropping both datagrams. Bleah. This is an acid flashback to grad school, when I was measuring TCP performance over ATM switches with too-small drop-tail cell buffers. :-( > To address this kind of problem, it might be worth creating a "drop" > frag queue entry, which is a way to remember that we dropped fragments > from a given datagram so we should drop all the other fragments too. Sounds reasonable, I think. > (I'd also go for modifying the data structures to make it easy to drop > the oldest frag queue.) That's a *lot* harder. We're at least dumping the oldest queue in the hash bucket now (64 buckets, fragment queues in the hundreds). Bruce. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 16:31:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 5C8E537B404; Fri, 5 Apr 2002 16:31:23 -0800 (PST) Received: from pool0399.cvx21-bradley.dialup.earthlink.net ([209.179.193.144] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16te6x-0002If-00; Fri, 05 Apr 2002 16:31:19 -0800 Message-ID: <3CAE41BE.8AD65DC6@mindspring.com> Date: Fri, 05 Apr 2002 16:30:54 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner Cc: bmah@FreeBSD.ORG, gallatin@cs.duke.edu, net@FreeBSD.ORG Subject: Re: IP fragmentation (was Re: Fatal trap 12: page fault while in kernel mode) References: <20020403181854.I42720-100000@angui.sh> <15532.29114.310072.957330@grasshopper.cs.duke.edu> <200204050504.g355493C001200@intruder.bmah.org> <15533.46222.49598.958821@grasshopper.cs.duke.edu> <3CADE0E7.ED472650@mindspring.com> <15533.57961.725030.692387@grasshopper.cs.duke.edu> <200204052120.g35LKW00034174@intruder.bmah.org> <200204052310.PAA21604@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bill Fenner wrote: > >Just for the heck of it, I started reading through ip_input.c to see how > >hard this would be to do. Haven't got there yet, I saw something odd: > >the variables ip_nfragpackets and nipq look *awfully* similar. > > So do the commit logs for the revisions in which each was introduced. > > Revision 1.65 - Mon Sep 15 23:07:01 1997 UTC (4 years, 6 months ago) by ache > > Prevent overflow with fragmented packets > > vs. > > Revision 1.169 - Sun Jun 3 23:33:23 2001 UTC (10 months ago) by jesper > > Prevent denial of service using bogus fragmented IPv4 packets. > > so I think you're right, that they're both meant to do the same thing > but neither is doing what they intended. I thought about this for a while, after Bruce said he was looking into it. There are some implicit problems that I don't know if it's really possible to resolve satisfactorily. If you drop fragments for whatever reason, in order to prevent overflow, just random dropping leads to "almost full" reassembly queues... and you don't want that. If you do it preferentially, based on what's already in there, then you end up assembling things in such a way that an attack can intentionally stick N-1 out of N packets into the queue for the full timeout period... and you don't want that. It seems to me that you need to disallow packets whose agregate size would be "too big" -- over some configurable limit. UDP datagrams larger than the max MTU strike me as "too big", but I'm sure someone will tell me why DNS switches to TCP, instead of using really big UDP datagrams? Preferential dropping gives you a similar deadlock, since the algorithm must permit you to not drop the Kth frag in a set of N, as K -> N. So you can't simply red-queue. If you LRU the frag sets, then that means that you will be penalizing the high latency links. In my experience, it is the humans on the other end of high latency links that have the patience of Job: they will try forever, until they get through. So dropping these means that you will up your overall pool retention time for packets from these people. If you don't LRU the frag sets, then that means that you will open youself to attack by intentional pacing, where frags are sent slowly enough to keep the drop timer reset in time to prevent dropping (TTL of a frag in the reassembly queue). This looks like a lively area for real research. My gut tells me that there should be two tiers: after you hit the second tier, then you need to drop any fragments for new frag sets, and at the top, you need to LRU out the total frag set. This implies two timers: an overall reassembly lifetime, which can not be exceeded (a frag set TTL), and a idle time wherein no mor fargs were received (a no new frags TTL). The second already exists. Really, you have to treat the fragment reassembly buffers as if they were external. You allocate the resources to them, and then forget the resources. What you really want is to act, logically, as if you have a traffic normalizer between you and the source of the traffic. I don't know how you would account for differential paths, should they result in further fragmentation. 8-(. But an approximation would be to precommit based on the number of frags expected in a frag chain. So getting frag 1 of 10 means that you have a committed quota usage of 10, even if you only have 1 frag in there right now. This is where I think the current algorithm is falling down. As I said, a nice area for research. Anyone looking for a Masters Thesis topic? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 16:41:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id 3A52737B41C for ; Fri, 5 Apr 2002 16:41:19 -0800 (PST) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id g360m9903575; Fri, 5 Apr 2002 18:48:13 -0600 (CST) (envelope-from nick@rogness.net) Date: Fri, 5 Apr 2002 18:48:09 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Alex Rousskov Cc: freebsd-net@FreeBSD.ORG Subject: Re: Forcing packets to the wire In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 5 Apr 2002, Alex Rousskov wrote: > Hi there, > > I have two Ethernet NICs inside a PC. I want TCP/IP packets to > leave one NIC, go on the wire, and eventually arrive at the other NIC. > I do not want the kernel to be smart and shortcut the path. I want the > outside world to see the packets and to think that my two NICs are two > PCs talking to each other. > > Could any networking guru answer the following questions: > > - Is it possible without kernel modifications? How? AFAIK, No. Your only 2 possiblities that I could think of would be to use policy routing or natd. Both will fail in this case. > > - If kernel modifications are required, how extensive > would they be (e.g., how many hours would it take a guru > to implement the required functionality)? > I'm not sure, but I would assume it would be painful. > I am flexible as far as IP addressing scheme is concerned, > though I would prefer to be able to put both NIC IP addresses on one > and on separate subnets (from the outside world point of view). Again, > I want the outside world think that these NICs are inside two PCs. > This is violating basic routing principles so it doesn't matter which IP subnets you use. > If you want to know a "use case" for this strange requirement, > here it is: I am building an appliance to test HTTP proxies. I want an > appliance to have one NIC for the "client side" and one NIC for the > "server side". I want to be able to run no-proxy test through the > networking gear (a baseline experiment testing hubs/switches for > bottlenecks), and I want to test "transparent proxies" (clients think > they send requests directly to servers). > > There is probably a better solution than trying to hack the kernel to do this. From the above paragraph, it sounds like you could bridge across the 2 interfaces and do some tricks with IPFW to direct traffic for your transparent proxy stuff. I would need more details to be sure. Nick Rogness - Don't mind me...I'm just sniffing your packets To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 20:26: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from draco.over-yonder.net (draco.over-yonder.net [198.78.58.61]) by hub.freebsd.org (Postfix) with ESMTP id 9508037B416 for ; Fri, 5 Apr 2002 20:25:55 -0800 (PST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 30D4AFC2; Fri, 5 Apr 2002 22:25:55 -0600 (CST) Date: Fri, 5 Apr 2002 22:25:55 -0600 From: "Matthew D. Fuller" To: Nick Rogness Cc: Alex Rousskov , freebsd-net@FreeBSD.ORG Subject: Re: Forcing packets to the wire Message-ID: <20020405222555.C65380@over-yonder.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5-fullermd.1i In-Reply-To: ; from nick@rogness.net on Fri, Apr 05, 2002 at 06:48:09PM -0600 X-Editor: vi X-OS: FreeBSD Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Apr 05, 2002 at 06:48:09PM -0600 I heard the voice of Nick Rogness, and lo! it spake thus: > On Fri, 5 Apr 2002, Alex Rousskov wrote: > > > > - Is it possible without kernel modifications? How? > > AFAIK, No. Your only 2 possiblities that I could think of would > be to use policy routing or natd. Both will fail in this case. You MIGHT be able to use ipfw divert/pipe rules to somehow shove the packets into a program on their way out, and write a program that would use raw sockets to hand-assemble the IP datagram on the way out; I'm not sure if the kernel would try to outsmart you on that. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 5 23: 7:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 3621B37B416 for ; Fri, 5 Apr 2002 23:07:20 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g3677Js14386 for net@freebsd.org; Fri, 5 Apr 2002 23:07:19 -0800 Date: Fri, 5 Apr 2002 23:07:19 -0800 From: Brooks Davis To: net@freebsd.org Subject: review request: minor cloning API change Message-ID: <20020405230719.A13516@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The following patch reverts a previous API change which change the return value of a clonable interfaces' destory function from void to int to allow the interface to refuse to delete a unit. Since we now manage unit creation in the generic cloning code and the only use mux or I could thing of for refusing to delete a unit was forcing a certain number of units to exist, I've added a new member to the cloner struct, ifc_minifs which specifies the minimum number of units of this device allowed. This changes the initilizer macro, but we already differ from NetBSD in that area and we get to revert to function signatures that match those from NetBSD in exchange. This diff also includes code to convert the disc interface to be clonable and unloadable. This will be commited seperatly. -- Brooks Index: if.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/net/if.c,v retrieving revision 1.137 diff -u -p -r1.137 if.c --- if.c 4 Apr 2002 21:03:28 -0000 1.137 +++ if.c 6 Apr 2002 06:38:02 -0000 @@ -656,12 +656,15 @@ if_clone_destroy(name) struct if_clone *ifc; struct ifnet *ifp; int bytoff, bitoff; - int err, unit; + int unit; =20 ifc =3D if_clone_lookup(name, &unit); if (ifc =3D=3D NULL) return (EINVAL); =20 + if (unit < ifc->ifc_minifs) + return (EINVAL); + ifp =3D ifunit(name); if (ifp =3D=3D NULL) return (ENXIO); @@ -669,9 +672,7 @@ if_clone_destroy(name) if (ifc->ifc_destroy =3D=3D NULL) return (EOPNOTSUPP); =20 - err =3D (*ifc->ifc_destroy)(ifp); - if (err !=3D 0) - return (err); + (*ifc->ifc_destroy)(ifp); =20 /* * Compute offset in the bitmap and deallocate the unit. @@ -734,8 +735,15 @@ void if_clone_attach(ifc) struct if_clone *ifc; { + int bytoff, bitoff; + int err; int len, maxclone; + int unit; =20 + KASSERT(ifc->ifc_minifs - 1 <=3D ifc->ifc_maxunit, + ("%s: %s requested more units then allowed (%d > %d)", + __func__, ifc->ifc_name, ifc->ifc_minifs, + ifc->ifc_maxunit + 1)); /* * Compute bitmap size and allocate it. */ @@ -745,8 +753,21 @@ if_clone_attach(ifc) len++; ifc->ifc_units =3D malloc(len, M_CLONE, M_WAITOK | M_ZERO); ifc->ifc_bmlen =3D len; + LIST_INSERT_HEAD(&if_cloners, ifc, ifc_list); if_cloners_count++; + + for (unit =3D 0; unit < ifc->ifc_minifs; unit++) { + err =3D (*ifc->ifc_create)(ifc, unit); + KASSERT(err =3D=3D 0, + ("%s: failed to create required interface %s%d", + __func__, ifc->ifc_name, unit)); + + /* Allocate the unit in the bitmap. */ + bytoff =3D unit >> 3; + bitoff =3D unit - (bytoff << 3); + ifc->ifc_units[bytoff] |=3D (1 << bitoff); + } } =20 /* Index: if.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/net/if.h,v retrieving revision 1.71 diff -u -p -r1.71 if.h --- if.h 19 Mar 2002 21:54:16 -0000 1.71 +++ if.h 6 Apr 2002 05:41:12 -0000 @@ -64,16 +64,17 @@ struct if_clone { LIST_ENTRY(if_clone) ifc_list; /* on list of cloners */ const char *ifc_name; /* name of device, e.g. `gif' */ size_t ifc_namelen; /* length of name */ + int ifc_minifs; /* minimum number of interfaces */ int ifc_maxunit; /* maximum unit number */ unsigned char *ifc_units; /* bitmap to handle units */ int ifc_bmlen; /* bitmap length */ =20 int (*ifc_create)(struct if_clone *, int); - int (*ifc_destroy)(struct ifnet *); + void (*ifc_destroy)(struct ifnet *); }; =20 -#define IF_CLONE_INITIALIZER(name, create, destroy, maxunit) \ - { { 0 }, name, sizeof(name) - 1, maxunit, NULL, 0, create, destroy } +#define IF_CLONE_INITIALIZER(name, create, destroy, minifs, maxunit) \ + { { 0 }, name, sizeof(name) - 1, minifs, maxunit, NULL, 0, create, des= troy } =20 /* * Structure used to query names of interface cloners. Index: if_disc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/net/if_disc.c,v retrieving revision 1.30 diff -u -p -r1.30 if_disc.c --- if_disc.c 14 Dec 2001 19:27:33 -0000 1.30 +++ if_disc.c 6 Apr 2002 06:51:56 -0000 @@ -42,6 +42,7 @@ #include #include #include +#include #include #include #include @@ -61,20 +62,39 @@ #define DSMTU 65532 #endif =20 -static void discattach(void); +#define DISCNAME "disc" =20 -static struct ifnet discif; -static int discoutput(struct ifnet *, struct mbuf *, - struct sockaddr *, struct rtentry *); -static void discrtrequest(int, struct rtentry *, struct rt_addrinfo *); -static int discioctl(struct ifnet *, u_long, caddr_t); +struct disc_softc { + struct ifnet sc_if; /* must be first */ + LIST_ENTRY(disc_softc) sc_list; +}; + +static int discoutput(struct ifnet *, struct mbuf *, + struct sockaddr *, struct rtentry *); +static void discrtrequest(int, struct rtentry *, struct rt_addrinfo *); +static int discioctl(struct ifnet *, u_long, caddr_t); +static int disc_clone_create(struct if_clone *, int); +static void disc_clone_destroy(struct ifnet *); + +static MALLOC_DEFINE(M_DISC, DISCNAME, "Discard interface"); +static LIST_HEAD(, disc_softc) disc_softc_list; +static struct if_clone disc_cloner =3D IF_CLONE_INITIALIZER(DISCNAME, + disc_clone_create, disc_clone_destroy, 0, IF_MAXUNIT); =20 -static void -discattach(void) +static int +disc_clone_create(struct if_clone *ifc, int unit) { - struct ifnet *ifp =3D &discif; + struct ifnet *ifp; + struct disc_softc *sc; + + sc =3D malloc(sizeof(struct disc_softc), M_DISC, M_WAITOK); + bzero(sc, sizeof(struct disc_softc)); + + ifp =3D &sc->sc_if; =20 - ifp->if_name =3D "ds"; + ifp->if_softc =3D sc; + ifp->if_name =3D DISCNAME; + ifp->if_unit =3D unit; ifp->if_mtu =3D DSMTU; ifp->if_flags =3D IFF_LOOPBACK | IFF_MULTICAST; ifp->if_ioctl =3D discioctl; @@ -85,6 +105,23 @@ discattach(void) ifp->if_snd.ifq_maxlen =3D 20; if_attach(ifp); bpfattach(ifp, DLT_NULL, sizeof(u_int)); + LIST_INSERT_HEAD(&disc_softc_list, sc, sc_list); + + return (0); +} + +static void +disc_clone_destroy(struct ifnet *ifp) +{ + struct disc_softc *sc; + + sc =3D ifp->if_softc; + + LIST_REMOVE(sc, sc_list); + bpfdetach(ifp); + if_detach(ifp); + + free(sc, M_DISC); } =20 static int @@ -92,11 +129,16 @@ disc_modevent(module_t mod, int type, vo {=20 switch (type) {=20 case MOD_LOAD:=20 - discattach(); + LIST_INIT(&disc_softc_list); + if_clone_attach(&disc_cloner); break;=20 case MOD_UNLOAD:=20 - printf("if_disc module unload - not possible for this module type\n");= =20 - return EINVAL;=20 + if_clone_detach(&disc_cloner); + + while (!LIST_EMPTY(&disc_softc_list)) + disc_clone_destroy( + &LIST_FIRST(&disc_softc_list)->sc_if); + break; }=20 return 0;=20 }=20 @@ -123,7 +165,7 @@ discoutput(struct ifnet *ifp, struct mbu m->m_data +=3D sizeof(int); } =20 - if (discif.if_bpf) { + if (ifp->if_bpf) { /* * We need to prepend the address family as * a four byte field. Cons up a dummy header @@ -138,7 +180,7 @@ discoutput(struct ifnet *ifp, struct mbu m0.m_len =3D 4; m0.m_data =3D (char *)⁡ =20 - bpf_mtap(&discif, &m0); + bpf_mtap(ifp, &m0); } m->m_pkthdr.rcvif =3D ifp; =20 Index: if_faith.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/net/if_faith.c,v retrieving revision 1.14 diff -u -p -r1.14 if_faith.c --- if_faith.c 19 Mar 2002 21:54:16 -0000 1.14 +++ if_faith.c 6 Apr 2002 05:41:12 -0000 @@ -103,10 +103,10 @@ static MALLOC_DEFINE(M_FAITH, FAITHNAME, static LIST_HEAD(, faith_softc) faith_softc_list; =20 int faith_clone_create(struct if_clone *, int); -int faith_clone_destroy(struct ifnet *); +void faith_clone_destroy(struct ifnet *); =20 struct if_clone faith_cloner =3D IF_CLONE_INITIALIZER(FAITHNAME, - faith_clone_create, faith_clone_destroy, IF_MAXUNIT); + faith_clone_create, faith_clone_destroy, 0, IF_MAXUNIT); =20 #define FAITHMTU 1500 =20 @@ -181,7 +181,7 @@ faith_clone_create(ifc, unit) return (0); } =20 -int +void faith_clone_destroy(ifp) struct ifnet *ifp; { @@ -192,7 +192,6 @@ faith_clone_destroy(ifp) if_detach(ifp); =20 free(sc, M_FAITH); - return (0); } =20 int Index: if_gif.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/net/if_gif.c,v retrieving revision 1.22 diff -u -p -r1.22 if_gif.c --- if_gif.c 19 Mar 2002 21:54:18 -0000 1.22 +++ if_gif.c 6 Apr 2002 05:41:12 -0000 @@ -90,10 +90,10 @@ void (*ng_gif_attach_p)(struct ifnet *if void (*ng_gif_detach_p)(struct ifnet *ifp); =20 int gif_clone_create(struct if_clone *, int); -int gif_clone_destroy(struct ifnet *); +void gif_clone_destroy(struct ifnet *); =20 struct if_clone gif_cloner =3D IF_CLONE_INITIALIZER("gif", - gif_clone_create, gif_clone_destroy, IF_MAXUNIT); + gif_clone_create, gif_clone_destroy, 0, IF_MAXUNIT); =20 static int gifmodevent(module_t, int, void *); void gif_delete_tunnel(struct gif_softc *); @@ -207,7 +207,7 @@ gif_clone_create(ifc, unit) return (0); } =20 -int +void gif_clone_destroy(ifp) struct ifnet *ifp; { @@ -231,7 +231,6 @@ gif_clone_destroy(ifp) if_detach(ifp); =20 free(sc, M_GIF); - return (0); } =20 static int Index: if_loop.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/net/if_loop.c,v retrieving revision 1.70 diff -u -p -r1.70 if_loop.c --- if_loop.c 4 Apr 2002 06:03:17 -0000 1.70 +++ if_loop.c 6 Apr 2002 05:54:06 -0000 @@ -110,7 +110,7 @@ static void lortrequest(int, struct rten int looutput(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, struct rtentry *rt); int lo_clone_create(struct if_clone *, int); -int lo_clone_destroy(struct ifnet *); +void lo_clone_destroy(struct ifnet *); =20 struct ifnet *loif =3D NULL; /* Used externally */ =20 @@ -118,10 +118,10 @@ static MALLOC_DEFINE(M_LO, LONAME, "Loop =20 static LIST_HEAD(lo_list, lo_softc) lo_list; =20 -struct if_clone lo_cloner =3D - IF_CLONE_INITIALIZER(LONAME, lo_clone_create, lo_clone_destroy, IF_MAX= UNIT); +struct if_clone lo_cloner =3D IF_CLONE_INITIALIZER(LONAME, + lo_clone_create, lo_clone_destroy, 1, IF_MAXUNIT); =20 -int +void lo_clone_destroy(ifp) struct ifnet *ifp; { @@ -129,17 +129,13 @@ lo_clone_destroy(ifp) =09 sc =3D ifp->if_softc; =20 - /* - * Prevent lo0 from being destroyed. - */ - if (loif =3D=3D ifp) - return (EINVAL); + /* XXX: destroying lo0 will lead to panics. */ + KASSERT(loif !=3D ifp, ("%s: destroying lo0", __func__)); =20 bpfdetach(ifp); if_detach(ifp); LIST_REMOVE(sc, sc_next); free(sc, M_LO); - return (0); } =20 int @@ -172,16 +168,10 @@ lo_clone_create(ifc, unit) static int loop_modevent(module_t mod, int type, void *data)=20 {=20 - int err; - switch (type) {=20 case MOD_LOAD:=20 LIST_INIT(&lo_list); if_clone_attach(&lo_cloner); - - /* Create lo0 */ - err =3D if_clone_create("lo0", sizeof ("lo0")); - KASSERT(err =3D=3D 0, ("%s: can't create lo0", __func__)); break;=20 case MOD_UNLOAD:=20 printf("loop module unload - not possible for this module type\n");=20 Index: if_stf.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/net/if_stf.c,v retrieving revision 1.20 diff -u -p -r1.20 if_stf.c --- if_stf.c 19 Mar 2002 21:54:18 -0000 1.20 +++ if_stf.c 6 Apr 2002 05:41:13 -0000 @@ -158,11 +158,11 @@ static void stf_rtrequest(int, struct rt static int stf_ioctl(struct ifnet *, u_long, caddr_t); =20 int stf_clone_create(struct if_clone *, int); -int stf_clone_destroy(struct ifnet *); +void stf_clone_destroy(struct ifnet *); =20 /* only one clone is currently allowed */ struct if_clone stf_cloner =3D - IF_CLONE_INITIALIZER(STFNAME, stf_clone_create, stf_clone_destroy, 0); + IF_CLONE_INITIALIZER(STFNAME, stf_clone_create, stf_clone_destroy, 0, = 0); =20 int stf_clone_create(ifc, unit) @@ -194,7 +194,7 @@ stf_clone_create(ifc, unit) return (0); } =20 -int +void stf_clone_destroy(ifp) struct ifnet *ifp; { @@ -208,7 +208,6 @@ stf_clone_destroy(ifp) if_detach(ifp); =20 free(sc, M_STF); - return (0); } =20 static int Index: if_vlan.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/net/if_vlan.c,v retrieving revision 1.40 diff -u -p -r1.40 if_vlan.c --- if_vlan.c 4 Apr 2002 05:42:09 -0000 1.40 +++ if_vlan.c 6 Apr 2002 05:41:13 -0000 @@ -90,7 +90,7 @@ static MALLOC_DEFINE(M_VLAN, "vlan", "80 static LIST_HEAD(, ifvlan) ifv_list; =20 static int vlan_clone_create(struct if_clone *, int); -static int vlan_clone_destroy(struct ifnet *); +static void vlan_clone_destroy(struct ifnet *); static void vlan_start(struct ifnet *ifp); static void vlan_ifinit(void *foo); static int vlan_input(struct ether_header *eh, struct mbuf *m); @@ -102,7 +102,7 @@ static int vlan_unconfig(struct ifnet *i static int vlan_config(struct ifvlan *ifv, struct ifnet *p); =20 struct if_clone vlan_cloner =3D IF_CLONE_INITIALIZER("vlan", - vlan_clone_create, vlan_clone_destroy, IF_MAXUNIT); + vlan_clone_create, vlan_clone_destroy, 0, IF_MAXUNIT); =20 /* * Program our multicast filter. What we're actually doing is @@ -236,7 +236,7 @@ vlan_clone_create(struct if_clone *ifc,=20 return (0); } =20 -static int +static void vlan_clone_destroy(struct ifnet *ifp) { struct ifvlan *ifv =3D ifp->if_softc; @@ -250,7 +250,6 @@ vlan_clone_destroy(struct ifnet *ifp) ether_ifdetach(ifp, ETHER_BPF_SUPPORTED); =20 free(ifv, M_VLAN); - return (0); } =20 static void --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8rp6mXY6L6fI4GtQRAs6sAJ4q1R7chQy6vsX0PMSPqyVh2p64ggCdH8N7 +mK5M/iYtMhspJY0nOsrCrE= =0aZn -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 0: 4:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.dev.itouchnet.net (devco.net [196.15.188.2]) by hub.freebsd.org (Postfix) with ESMTP id 08D3D37B404 for ; Sat, 6 Apr 2002 00:04:34 -0800 (PST) Received: from nobody by mx1.dev.itouchnet.net with scanned_ok (Exim 3.33 #2) id 16tlFl-000KP8-00 for freebsd-net@freebsd.org; Sat, 06 Apr 2002 10:08:53 +0200 Received: from shell.devco.net ([196.15.188.7]) by mx1.dev.itouchnet.net with esmtp (Exim 3.33 #2) id 16tlFh-000KP1-00 for freebsd-net@freebsd.org; Sat, 06 Apr 2002 10:08:49 +0200 Received: from bvi by shell.devco.net with local (Exim 3.33 #4) id 16tlFt-000JoX-00 for freebsd-net@freebsd.org; Sat, 06 Apr 2002 10:09:01 +0200 Date: Sat, 6 Apr 2002 10:09:01 +0200 From: Barry Irwin To: freebsd-net@freebsd.org Subject: Packets lost when forwarding disabled Message-ID: <20020406100901.C62987@itouchlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Checked: This message has been scanned for any virusses and unauthorized attachments. X-iScan-ID: 78434-1018080531-02178@mx1.dev.itouchnet.net version $Name: REL_2_0_2 $ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi All After mucking around on a firewall problem on the other side of the world yesterday, the problem was that net.inet.ip.forwarding was set to off * the gateway_enable had been mangled in rc.conf). Packets were being received by the firewall kernel, and happily passed through the firewall ruleset as expected, they then dissapeared. I thought it would be useful to have a sysctl knob which would allow one to cause these packets to be logged. From a security pov it would be interesting to know if people are trying to use you as a gateway? Now for the real question, does somethign like this already exist, and am I going to be re-inventing the whell if I add it to the kernel. I s the another way of doing this? Thanks Barry -- Barry Irwin bvi@itouchlabs.com +27214875177 Systems Administrator: Networks And Security Itouch Labs http://www.itouchlabs.com South Africa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 0:45:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 8869B37B419 for ; Sat, 6 Apr 2002 00:45:06 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g368iun24617; Sat, 6 Apr 2002 00:44:56 -0800 (PST) (envelope-from rizzo) Date: Sat, 6 Apr 2002 00:44:56 -0800 From: Luigi Rizzo To: Barry Irwin Cc: freebsd-net@FreeBSD.ORG Subject: Re: Packets lost when forwarding disabled Message-ID: <20020406004456.A24597@iguana.icir.org> References: <20020406100901.C62987@itouchlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020406100901.C62987@itouchlabs.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Apr 06, 2002 at 10:09:01AM +0200, Barry Irwin wrote: > Hi All > > After mucking around on a firewall problem on the other side of the world > yesterday, the problem was that net.inet.ip.forwarding was set to off * the > gateway_enable had been mangled in rc.conf). Packets were being received by ... > I thought it would be useful to have a sysctl knob which would allow one to > cause these packets to be logged. From a security pov it would be > interesting to know if people are trying to use you as a gateway? > > Now for the real question, does somethign like this already exist, and am I netstat -s -p ip tells you that. cheers luigi > going to be re-inventing the whell if I add it to the kernel. I s the > another way of doing this? > > Thanks > Barry > > -- > Barry Irwin bvi@itouchlabs.com +27214875177 > Systems Administrator: Networks And Security > Itouch Labs http://www.itouchlabs.com South Africa > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 0:52:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (oe84.pav0.hotmail.com [64.4.33.226]) by hub.freebsd.org (Postfix) with ESMTP id AEA8437B41C for ; Sat, 6 Apr 2002 00:52:16 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 6 Apr 2002 00:52:16 -0800 X-Originating-IP: [67.41.74.62] Reply-To: "Seth Hieronymus" From: "Seth Hieronymus" To: Cc: Subject: Fw: IP fragmentation (was Re: Fatal trap 12: page fault while in kernel mode) Date: Sat, 6 Apr 2002 01:52:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 06 Apr 2002 08:52:16.0492 (UTC) FILETIME=[5A44B2C0:01C1DD48] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Terry Lambert wrote: > I thought about this for a while, after Bruce said he was > looking into it. > > There are some implicit problems that I don't know if it's > really possible to resolve satisfactorily. > > If you drop fragments for whatever reason, in order to prevent > overflow, just random dropping leads to "almost full" reassembly > queues... and you don't want that. [snip] > As I said, a nice area for research. Anyone looking for a > Masters Thesis topic? > > -- Terry Sorry for jumping into the middle of a conversation. Please tell me if I don't know what I am talking about. How about taking a pseudo genetic algorithm path, and look at the packet groups as the organisms, with their fitnesses determined by some combination of percentage fragments received (ie 1/10) and the time since first fragment reception. Then, periodically cull the low-fitness fragment groups, which could be either almost complete groups that have a large timeout, or groups with a smaller timeout but that have not received many fragments. I don't know... it's late and I can't sleep. Anyway, just was thinking about it. > As I said, a nice area for research. Anyone looking for a > Masters Thesis topic? No, I'm ok, thanks. Seth Hieronymus To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 4:51:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 4279537B404 for ; Sat, 6 Apr 2002 04:51:31 -0800 (PST) Received: (from uucp@localhost) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) id g36CpPf26041; Sat, 6 Apr 2002 14:51:25 +0200 (MET DST) >Received: from titan.klemm.gtn.com (localhost [127.0.0.1]) by klemm.gtn.com (8.12.2/8.11.6) with ESMTP id g32GdHsQ004412; Tue, 2 Apr 2002 18:39:17 +0200 (CEST) (envelope-from andreas@titan.klemm.gtn.com) Received: (from andreas@localhost) by titan.klemm.gtn.com (8.12.2/8.12.2/Submit) id g32GdCde004411; Tue, 2 Apr 2002 18:39:12 +0200 (CEST) Date: Tue, 2 Apr 2002 18:39:12 +0200 From: Andreas Klemm To: freebsd-net@freebsd.org Cc: Luigi Rizzo Subject: better DSL bandwidth usage by priorizing ACKs in outgoing packets over others Message-ID: <20020402163912.GD4307@titan.klemm.gtn.com> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.3.27i X-Operating-System: FreeBSD 4.5-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 List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi ! A collegue of mine has an Apple (Mac OS X) and told me about a cool software, that priorizes outgoing ACKs over other traffic. On Tue, Apr 02, 2002 at 04:53:08PM +0200, andreas.klemm.ak@bayer-ag.de wrote: > http://www.intrarts.com/quest/throttle.html Using DSL you have usually 768K in and 128K out. Figure a szenario, where you ftp like hell from a ftp server. You get very good throughput, since the outgoing ACKs of the incoming ftp data stream are not throttled by 128K outgoing bandwidth. But if you start another application like cvsup at the same time you'll notice an immediate throttle of incoming packets, because cvsup monopolizes the outgoing 128K bandwidth. And if the ACKs don't get out in a timely manner, you can't get that much incoming FTP traffic. The above mentioned software manages exactly this by using a daemon program. With divert sockets and ipfw you send outgoing traffic to this daemon which gives outgoing ACKs over the 128K higher preference and buffers the rest of the traffic (I think). Would something like this be possible anyhow with our current Firewall implementation, or would somebody have time and fun to implement this ?? Andreas /// -- Andreas Klemm /\/\/\/\/\/\/\/\/\/\/\ http://www.64bits.de < Powered by FreeBSD > http://www.apsfilter.org/ \ www.FreeBSD.org / http://people.FreeBSD.ORG/~andreas \/\/\/\/\/\/\/\/\/\/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 4:51:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id A9C0C37B405 for ; Sat, 6 Apr 2002 04:51:37 -0800 (PST) Received: (from uucp@localhost) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) id g36Cpae26158 for freebsd-net@freebsd.org; Sat, 6 Apr 2002 14:51:36 +0200 (MET DST) >Received: from titan.klemm.gtn.com (localhost [127.0.0.1]) by klemm.gtn.com (8.12.2/8.11.6) with ESMTP id g337phuE006229 for ; Wed, 3 Apr 2002 09:51:43 +0200 (CEST) (envelope-from andreas@titan.klemm.gtn.com) Received: (from andreas@localhost) by titan.klemm.gtn.com (8.12.2/8.12.2/Submit) id g337pd3S006228 for freebsd-net@freebsd.org; Wed, 3 Apr 2002 09:51:39 +0200 (CEST) Date: Wed, 3 Apr 2002 09:51:39 +0200 From: Andreas Klemm To: freebsd-net@freebsd.org Subject: better DSL bandwidth usage by priorizing ACKs in outgoing packets over others Message-ID: <20020403075139.GA6210@titan.klemm.gtn.com> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.3.27i X-Operating-System: FreeBSD 4.5-STABLE 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 List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi ! A collegue of mine has an Apple (Mac OS X) and told me about a cool software, that priorizes outgoing ACKs over other traffic. Apple MacOS X application, see: http://www.intrarts.com/quest/throttle.html Using DSL you have usually 768K in and 128K out. Figure a szenario, where you ftp like hell from a ftp server. You get very good throughput, since the outgoing ACKs of the incoming ftp data stream are not throttled by 128K outgoing bandwidth. But if you start another application like cvsup at the same time you'll notice an immediate throttle of incoming packets, because cvsup monopolizes the outgoing 128K bandwidth. And if the ACKs don't get out in a timely manner, you can't get that much incoming FTP traffic. The above mentioned software manages exactly this by using a daemon program. With divert sockets and ipfw you send outgoing traffic to this daemon which gives outgoing ACKs over the 128K higher preference and buffers the rest of the traffic (I think). Would something like this be possible anyhow with our current Firewall implementation, or would somebody have time and fun to implement this ?? Andreas /// -- Andreas Klemm /\/\/\/\/\/\/\/\/\/\/\ http://www.64bits.de < Powered by FreeBSD > http://www.apsfilter.org/ \ www.FreeBSD.org / http://people.FreeBSD.ORG/~andreas \/\/\/\/\/\/\/\/\/\/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 6:57:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 36C6637B404 for ; Sat, 6 Apr 2002 06:57:40 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g36EvaR29466; Sat, 6 Apr 2002 06:57:36 -0800 (PST) (envelope-from rizzo) Date: Sat, 6 Apr 2002 06:57:36 -0800 From: Luigi Rizzo To: Andreas Klemm Cc: freebsd-net@freebsd.org Subject: Re: better DSL bandwidth usage by priorizing ACKs in outgoing packets over others Message-ID: <20020406065735.A29144@iguana.icir.org> References: <20020402163912.GD4307@titan.klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020402163912.GD4307@titan.klemm.gtn.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Apr 02, 2002 at 06:39:12PM +0200, Andreas Klemm wrote: we would need a minor tweak to the ipfw code so that it can match packets whose size is less than X bytes (so the mechanism is general enough to be used for other things). This could be done in a matter of 1hour or less, most of the time would be wasted in figuring out a way to implement it that does not break binary compatibility. Once we have done this, we can define a dummynet pipe with a bandwidth <= the bottleneck (128kbit/s), and use"queue" rules to privilege the acks wrt other traffic. Something like ipfw pipe 10 config bw 100kbit/s ipfw queue 1 config weight 1 pipe 10 ipfw queue 100 config weight 100 pipe 10 ipfw add queue 100 tcp from any to ${outside} shorter-than 80 ipfw add queue 1 ip from any to ${outside} This said, i have never seen terribly bad effects when cvsupping and doing other things. If there is something which goes to its knees, this is the disk. Oh, and "usually" in italy, the cheap DSL contracts give you 256kbit/s in! cheers luigi > Hi ! > > A collegue of mine has an Apple (Mac OS X) and told me about > a cool software, that priorizes outgoing ACKs over other traffic. > > On Tue, Apr 02, 2002 at 04:53:08PM +0200, andreas.klemm.ak@bayer-ag.de wrote: > > http://www.intrarts.com/quest/throttle.html > > Using DSL you have usually 768K in and 128K out. > Figure a szenario, where you ftp like hell from a ftp > server. You get very good throughput, since the outgoing > ACKs of the incoming ftp data stream are not throttled by > 128K outgoing bandwidth. > > But if you start another application like cvsup at the > same time you'll notice an immediate throttle of incoming > packets, because cvsup monopolizes the outgoing 128K bandwidth. > And if the ACKs don't get out in a timely manner, you can't get > that much incoming FTP traffic. > > The above mentioned software manages exactly this by using > a daemon program. With divert sockets and ipfw you send outgoing > traffic to this daemon which gives outgoing ACKs over the > 128K higher preference and buffers the rest of the traffic > (I think). > > Would something like this be possible anyhow with our current > Firewall implementation, or would somebody have time and fun > to implement this ?? > > Andreas /// > > -- > Andreas Klemm /\/\/\/\/\/\/\/\/\/\/\ > http://www.64bits.de < Powered by FreeBSD > > http://www.apsfilter.org/ \ www.FreeBSD.org / > http://people.FreeBSD.ORG/~andreas \/\/\/\/\/\/\/\/\/\/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 11:51: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id 5736837B405 for ; Sat, 6 Apr 2002 11:50:54 -0800 (PST) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id g36Jvi912545; Sat, 6 Apr 2002 13:57:44 -0600 (CST) (envelope-from nick@rogness.net) Date: Sat, 6 Apr 2002 13:57:44 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: "Matthew D. Fuller" Cc: Alex Rousskov , freebsd-net@FreeBSD.ORG Subject: Re: Forcing packets to the wire In-Reply-To: <20020405222555.C65380@over-yonder.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 5 Apr 2002, Matthew D. Fuller wrote: > On Fri, Apr 05, 2002 at 06:48:09PM -0600 I heard the voice of > Nick Rogness, and lo! it spake thus: > > On Fri, 5 Apr 2002, Alex Rousskov wrote: > > > > > > - Is it possible without kernel modifications? How? > > > > AFAIK, No. Your only 2 possiblities that I could think of would > > be to use policy routing or natd. Both will fail in this case. > > You MIGHT be able to use ipfw divert/pipe rules to somehow shove the > packets into a program on their way out, and write a program that > would use raw sockets to hand-assemble the IP datagram on the way out; > I'm not sure if the kernel would try to outsmart you on that. Yeh, I thought of that. The problem is packets never leave anywhere since the route for the other NIC is not "OUT" any interface...it is the machine itself. I had a brief thought of using an upstream device that could route the appropriate nat'd addresses to each interface. This would be tricky to do but a maybe something like: =================== | Upstream device | =================== | | | | xl0 xl1 =================== | BSD Machine | =================== On the BSD machine: ipfw divert natd ip from any to 2.3.4.5 out via xl0 ipfw divert natd ip from 2.3.4.5 to any in via xl0 ipfw divert natd2 ip from any to 2.3.4.5 in via xl1 ipfw divert natd2 ip from any to 192.168.0.1 out via xl1 ipfw allow ip from any to any # route add -host 192.168.0.1 -iface xl1 # route add -host 2.3.4.5 -iface xl0 # natd -alias_address 192.168.0.1 # natd2 -redirect_address $IP_OF_xl1 2.3.4.5 -n xl1 # route add default $IP_OF_UPSTREAM_DEVICE Then on the Upstream device: # route add -host 2.3.4.5 $IP_OF_xl1 # route add -host 192.168.0.1 $IP_OF_xl0 That should get the basic functionality but there is still a tad bit of tweaking to do to get everything working. The basic concept is there though. Of course, your IP's on the outside will be different than what they really are which is not what the original author wanted. So I said it is not a viable solution. PS. I just randomly chose 192.168.0.1 & 2.3.4.5...you could use anything that is not part of either IP subnet assigned to xl0 & xl1. Nick Rogness - Don't mind me...I'm just sniffing your packets To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 12:44:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by hub.freebsd.org (Postfix) with ESMTP id F1F5B37B41A for ; Sat, 6 Apr 2002 12:44:16 -0800 (PST) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.6) id g36Ki3q09382; Sat, 6 Apr 2002 15:44:03 -0500 (EST) (envelope-from barney) Date: Sat, 6 Apr 2002 15:44:03 -0500 From: Barney Wolff To: Nick Rogness Cc: "Matthew D. Fuller" , Alex Rousskov , freebsd-net@FreeBSD.ORG Subject: Re: Forcing packets to the wire Message-ID: <20020406154403.A9364@tp.databus.com> References: <20020405222555.C65380@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from nick@rogness.net on Sat, Apr 06, 2002 at 01:57:44PM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Think about using vmware? -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 15:53:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from herbelot.dyndns.org (d013.dhcp212-198-27.noos.fr [212.198.27.13]) by hub.freebsd.org (Postfix) with ESMTP id 7762937B404 for ; Sat, 6 Apr 2002 15:53:18 -0800 (PST) Received: from herbelot.com (tulipe.herbelot.nom [192.168.1.5]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id BAA02655; Sun, 7 Apr 2002 01:52:22 +0200 (CEST) (envelope-from thierry@herbelot.com) Message-ID: <3CAF8A36.5E7DF008@herbelot.com> Date: Sun, 07 Apr 2002 01:52:22 +0200 From: Thierry Herbelot X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Barney Wolff Cc: Nick Rogness , "Matthew D. Fuller" , Alex Rousskov , freebsd-net@FreeBSD.ORG Subject: Re: Forcing packets to the wire References: <20020405222555.C65380@over-yonder.net> <20020406154403.A9364@tp.databus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Barney Wolff wrote: > > Think about using vmware? along the same line, but without any outside software : from my experience, I'm sure you can do it with jail(8) with the creation of two jails, one NIC per jail and one sender/emitter in each jail. (there are lots of papers on how to setup a jail, beginning with the man page) TfH [SNIP] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 16:40:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id A0D5E37B41D for ; Sat, 6 Apr 2002 16:40:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020407004010.NVKU3676.rwcrmhc52.attbi.com@InterJet.elischer.org>; Sun, 7 Apr 2002 00:40:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA43395; Sat, 6 Apr 2002 16:23:42 -0800 (PST) Date: Sat, 6 Apr 2002 16:23:41 -0800 (PST) From: Julian Elischer To: Nick Rogness Cc: "Matthew D. Fuller" , Alex Rousskov , freebsd-net@FreeBSD.ORG Subject: Re: Forcing packets to the wire In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 6 Apr 2002, Nick Rogness wrote: > On Fri, 5 Apr 2002, Matthew D. Fuller wrote: > > > On Fri, Apr 05, 2002 at 06:48:09PM -0600 I heard the voice of > > Nick Rogness, and lo! it spake thus: [missing stuff] I missed the original mailling.. what was the requirement? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 17: 0:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 7D80237B405 for ; Sat, 6 Apr 2002 17:00:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020407010009.ENUD15826.rwcrmhc54.attbi.com@InterJet.elischer.org>; Sun, 7 Apr 2002 01:00:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA43452; Sat, 6 Apr 2002 16:44:33 -0800 (PST) Date: Sat, 6 Apr 2002 16:44:32 -0800 (PST) From: Julian Elischer To: Brooks Davis Cc: net@freebsd.org Subject: Re: review request: minor cloning API change In-Reply-To: <20020405230719.A13516@Odin.AC.HMC.Edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Please excuse the comment if I'm way off the mark.. With a VERY BRIEF look I see that you are returning a void from the destroy function and it is callled from the module unload code where some destroy functions used to return ints. this ia I think a BAD MOVE.. a driver must be able to veto it's own unloading. If it is in use fro example. You leave no way for the driver to say "Nope, I can't be unloaded now, I'm busy." On Fri, 5 Apr 2002, Brooks Davis wrote: > The following patch reverts a previous API change which change the > return value of a clonable interfaces' destory function from void to > int to allow the interface to refuse to delete a unit. Since we now > manage unit creation in the generic cloning code and the only use mux or > I could thing of for refusing to delete a unit was forcing a certain > number of units to exist, I've added a new member to the cloner struct, > ifc_minifs which specifies the minimum number of units of this device > allowed. This changes the initilizer macro, but we already differ from > NetBSD in that area and we get to revert to function signatures that > match those from NetBSD in exchange. > > This diff also includes code to convert the disc interface to be > clonable and unloadable. This will be commited seperatly. > > -- Brooks > > > Index: if.c > =================================================================== > RCS file: /usr/cvs/src/sys/net/if.c,v > retrieving revision 1.137 > diff -u -p -r1.137 if.c > --- if.c 4 Apr 2002 21:03:28 -0000 1.137 > +++ if.c 6 Apr 2002 06:38:02 -0000 > @@ -656,12 +656,15 @@ if_clone_destroy(name) > struct if_clone *ifc; > struct ifnet *ifp; > int bytoff, bitoff; > - int err, unit; > + int unit; > > ifc = if_clone_lookup(name, &unit); > if (ifc == NULL) > return (EINVAL); > > + if (unit < ifc->ifc_minifs) > + return (EINVAL); > + > ifp = ifunit(name); > if (ifp == NULL) > return (ENXIO); > @@ -669,9 +672,7 @@ if_clone_destroy(name) > if (ifc->ifc_destroy == NULL) > return (EOPNOTSUPP); > > - err = (*ifc->ifc_destroy)(ifp); > - if (err != 0) > - return (err); > + (*ifc->ifc_destroy)(ifp); > > /* > * Compute offset in the bitmap and deallocate the unit. > @@ -734,8 +735,15 @@ void > if_clone_attach(ifc) > struct if_clone *ifc; > { > + int bytoff, bitoff; > + int err; > int len, maxclone; > + int unit; > > + KASSERT(ifc->ifc_minifs - 1 <= ifc->ifc_maxunit, > + ("%s: %s requested more units then allowed (%d > %d)", > + __func__, ifc->ifc_name, ifc->ifc_minifs, > + ifc->ifc_maxunit + 1)); > /* > * Compute bitmap size and allocate it. > */ > @@ -745,8 +753,21 @@ if_clone_attach(ifc) > len++; > ifc->ifc_units = malloc(len, M_CLONE, M_WAITOK | M_ZERO); > ifc->ifc_bmlen = len; > + > LIST_INSERT_HEAD(&if_cloners, ifc, ifc_list); > if_cloners_count++; > + > + for (unit = 0; unit < ifc->ifc_minifs; unit++) { > + err = (*ifc->ifc_create)(ifc, unit); > + KASSERT(err == 0, > + ("%s: failed to create required interface %s%d", > + __func__, ifc->ifc_name, unit)); > + > + /* Allocate the unit in the bitmap. */ > + bytoff = unit >> 3; > + bitoff = unit - (bytoff << 3); > + ifc->ifc_units[bytoff] |= (1 << bitoff); > + } > } > > /* > Index: if.h > =================================================================== > RCS file: /usr/cvs/src/sys/net/if.h,v > retrieving revision 1.71 > diff -u -p -r1.71 if.h > --- if.h 19 Mar 2002 21:54:16 -0000 1.71 > +++ if.h 6 Apr 2002 05:41:12 -0000 > @@ -64,16 +64,17 @@ struct if_clone { > LIST_ENTRY(if_clone) ifc_list; /* on list of cloners */ > const char *ifc_name; /* name of device, e.g. `gif' */ > size_t ifc_namelen; /* length of name */ > + int ifc_minifs; /* minimum number of interfaces */ > int ifc_maxunit; /* maximum unit number */ > unsigned char *ifc_units; /* bitmap to handle units */ > int ifc_bmlen; /* bitmap length */ > > int (*ifc_create)(struct if_clone *, int); > - int (*ifc_destroy)(struct ifnet *); > + void (*ifc_destroy)(struct ifnet *); > }; > > -#define IF_CLONE_INITIALIZER(name, create, destroy, maxunit) \ > - { { 0 }, name, sizeof(name) - 1, maxunit, NULL, 0, create, destroy } > +#define IF_CLONE_INITIALIZER(name, create, destroy, minifs, maxunit) \ > + { { 0 }, name, sizeof(name) - 1, minifs, maxunit, NULL, 0, create, destroy } > > /* > * Structure used to query names of interface cloners. > Index: if_disc.c > =================================================================== > RCS file: /usr/cvs/src/sys/net/if_disc.c,v > retrieving revision 1.30 > diff -u -p -r1.30 if_disc.c > --- if_disc.c 14 Dec 2001 19:27:33 -0000 1.30 > +++ if_disc.c 6 Apr 2002 06:51:56 -0000 > @@ -42,6 +42,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -61,20 +62,39 @@ > #define DSMTU 65532 > #endif > > -static void discattach(void); > +#define DISCNAME "disc" > > -static struct ifnet discif; > -static int discoutput(struct ifnet *, struct mbuf *, > - struct sockaddr *, struct rtentry *); > -static void discrtrequest(int, struct rtentry *, struct rt_addrinfo *); > -static int discioctl(struct ifnet *, u_long, caddr_t); > +struct disc_softc { > + struct ifnet sc_if; /* must be first */ > + LIST_ENTRY(disc_softc) sc_list; > +}; > + > +static int discoutput(struct ifnet *, struct mbuf *, > + struct sockaddr *, struct rtentry *); > +static void discrtrequest(int, struct rtentry *, struct rt_addrinfo *); > +static int discioctl(struct ifnet *, u_long, caddr_t); > +static int disc_clone_create(struct if_clone *, int); > +static void disc_clone_destroy(struct ifnet *); > + > +static MALLOC_DEFINE(M_DISC, DISCNAME, "Discard interface"); > +static LIST_HEAD(, disc_softc) disc_softc_list; > +static struct if_clone disc_cloner = IF_CLONE_INITIALIZER(DISCNAME, > + disc_clone_create, disc_clone_destroy, 0, IF_MAXUNIT); > > -static void > -discattach(void) > +static int > +disc_clone_create(struct if_clone *ifc, int unit) > { > - struct ifnet *ifp = &discif; > + struct ifnet *ifp; > + struct disc_softc *sc; > + > + sc = malloc(sizeof(struct disc_softc), M_DISC, M_WAITOK); > + bzero(sc, sizeof(struct disc_softc)); > + > + ifp = &sc->sc_if; > > - ifp->if_name = "ds"; > + ifp->if_softc = sc; > + ifp->if_name = DISCNAME; > + ifp->if_unit = unit; > ifp->if_mtu = DSMTU; > ifp->if_flags = IFF_LOOPBACK | IFF_MULTICAST; > ifp->if_ioctl = discioctl; > @@ -85,6 +105,23 @@ discattach(void) > ifp->if_snd.ifq_maxlen = 20; > if_attach(ifp); > bpfattach(ifp, DLT_NULL, sizeof(u_int)); > + LIST_INSERT_HEAD(&disc_softc_list, sc, sc_list); > + > + return (0); > +} > + > +static void > +disc_clone_destroy(struct ifnet *ifp) > +{ > + struct disc_softc *sc; > + > + sc = ifp->if_softc; > + > + LIST_REMOVE(sc, sc_list); > + bpfdetach(ifp); > + if_detach(ifp); > + > + free(sc, M_DISC); > } > > static int > @@ -92,11 +129,16 @@ disc_modevent(module_t mod, int type, vo > { > switch (type) { > case MOD_LOAD: > - discattach(); > + LIST_INIT(&disc_softc_list); > + if_clone_attach(&disc_cloner); > break; > case MOD_UNLOAD: > - printf("if_disc module unload - not possible for this module type\n"); > - return EINVAL; > + if_clone_detach(&disc_cloner); > + > + while (!LIST_EMPTY(&disc_softc_list)) > + disc_clone_destroy( > + &LIST_FIRST(&disc_softc_list)->sc_if); > + break; > } > return 0; > } > @@ -123,7 +165,7 @@ discoutput(struct ifnet *ifp, struct mbu > m->m_data += sizeof(int); > } > > - if (discif.if_bpf) { > + if (ifp->if_bpf) { > /* > * We need to prepend the address family as > * a four byte field. Cons up a dummy header > @@ -138,7 +180,7 @@ discoutput(struct ifnet *ifp, struct mbu > m0.m_len = 4; > m0.m_data = (char *)⁡ > > - bpf_mtap(&discif, &m0); > + bpf_mtap(ifp, &m0); > } > m->m_pkthdr.rcvif = ifp; > > Index: if_faith.c > =================================================================== > RCS file: /usr/cvs/src/sys/net/if_faith.c,v > retrieving revision 1.14 > diff -u -p -r1.14 if_faith.c > --- if_faith.c 19 Mar 2002 21:54:16 -0000 1.14 > +++ if_faith.c 6 Apr 2002 05:41:12 -0000 > @@ -103,10 +103,10 @@ static MALLOC_DEFINE(M_FAITH, FAITHNAME, > static LIST_HEAD(, faith_softc) faith_softc_list; > > int faith_clone_create(struct if_clone *, int); > -int faith_clone_destroy(struct ifnet *); > +void faith_clone_destroy(struct ifnet *); > > struct if_clone faith_cloner = IF_CLONE_INITIALIZER(FAITHNAME, > - faith_clone_create, faith_clone_destroy, IF_MAXUNIT); > + faith_clone_create, faith_clone_destroy, 0, IF_MAXUNIT); > > #define FAITHMTU 1500 > > @@ -181,7 +181,7 @@ faith_clone_create(ifc, unit) > return (0); > } > > -int > +void > faith_clone_destroy(ifp) > struct ifnet *ifp; > { > @@ -192,7 +192,6 @@ faith_clone_destroy(ifp) > if_detach(ifp); > > free(sc, M_FAITH); > - return (0); > } > > int > Index: if_gif.c > =================================================================== > RCS file: /usr/cvs/src/sys/net/if_gif.c,v > retrieving revision 1.22 > diff -u -p -r1.22 if_gif.c > --- if_gif.c 19 Mar 2002 21:54:18 -0000 1.22 > +++ if_gif.c 6 Apr 2002 05:41:12 -0000 > @@ -90,10 +90,10 @@ void (*ng_gif_attach_p)(struct ifnet *if > void (*ng_gif_detach_p)(struct ifnet *ifp); > > int gif_clone_create(struct if_clone *, int); > -int gif_clone_destroy(struct ifnet *); > +void gif_clone_destroy(struct ifnet *); > > struct if_clone gif_cloner = IF_CLONE_INITIALIZER("gif", > - gif_clone_create, gif_clone_destroy, IF_MAXUNIT); > + gif_clone_create, gif_clone_destroy, 0, IF_MAXUNIT); > > static int gifmodevent(module_t, int, void *); > void gif_delete_tunnel(struct gif_softc *); > @@ -207,7 +207,7 @@ gif_clone_create(ifc, unit) > return (0); > } > > -int > +void > gif_clone_destroy(ifp) > struct ifnet *ifp; > { > @@ -231,7 +231,6 @@ gif_clone_destroy(ifp) > if_detach(ifp); > > free(sc, M_GIF); > - return (0); > } > > static int > Index: if_loop.c > =================================================================== > RCS file: /usr/cvs/src/sys/net/if_loop.c,v > retrieving revision 1.70 > diff -u -p -r1.70 if_loop.c > --- if_loop.c 4 Apr 2002 06:03:17 -0000 1.70 > +++ if_loop.c 6 Apr 2002 05:54:06 -0000 > @@ -110,7 +110,7 @@ static void lortrequest(int, struct rten > int looutput(struct ifnet *ifp, struct mbuf *m, > struct sockaddr *dst, struct rtentry *rt); > int lo_clone_create(struct if_clone *, int); > -int lo_clone_destroy(struct ifnet *); > +void lo_clone_destroy(struct ifnet *); > > struct ifnet *loif = NULL; /* Used externally */ > > @@ -118,10 +118,10 @@ static MALLOC_DEFINE(M_LO, LONAME, "Loop > > static LIST_HEAD(lo_list, lo_softc) lo_list; > > -struct if_clone lo_cloner = > - IF_CLONE_INITIALIZER(LONAME, lo_clone_create, lo_clone_destroy, IF_MAXUNIT); > +struct if_clone lo_cloner = IF_CLONE_INITIALIZER(LONAME, > + lo_clone_create, lo_clone_destroy, 1, IF_MAXUNIT); > > -int > +void > lo_clone_destroy(ifp) > struct ifnet *ifp; > { > @@ -129,17 +129,13 @@ lo_clone_destroy(ifp) > > sc = ifp->if_softc; > > - /* > - * Prevent lo0 from being destroyed. > - */ > - if (loif == ifp) > - return (EINVAL); > + /* XXX: destroying lo0 will lead to panics. */ > + KASSERT(loif != ifp, ("%s: destroying lo0", __func__)); > > bpfdetach(ifp); > if_detach(ifp); > LIST_REMOVE(sc, sc_next); > free(sc, M_LO); > - return (0); > } > > int > @@ -172,16 +168,10 @@ lo_clone_create(ifc, unit) > static int > loop_modevent(module_t mod, int type, void *data) > { > - int err; > - > switch (type) { > case MOD_LOAD: > LIST_INIT(&lo_list); > if_clone_attach(&lo_cloner); > - > - /* Create lo0 */ > - err = if_clone_create("lo0", sizeof ("lo0")); > - KASSERT(err == 0, ("%s: can't create lo0", __func__)); > break; > case MOD_UNLOAD: > printf("loop module unload - not possible for this module type\n"); > Index: if_stf.c > =================================================================== > RCS file: /usr/cvs/src/sys/net/if_stf.c,v > retrieving revision 1.20 > diff -u -p -r1.20 if_stf.c > --- if_stf.c 19 Mar 2002 21:54:18 -0000 1.20 > +++ if_stf.c 6 Apr 2002 05:41:13 -0000 > @@ -158,11 +158,11 @@ static void stf_rtrequest(int, struct rt > static int stf_ioctl(struct ifnet *, u_long, caddr_t); > > int stf_clone_create(struct if_clone *, int); > -int stf_clone_destroy(struct ifnet *); > +void stf_clone_destroy(struct ifnet *); > > /* only one clone is currently allowed */ > struct if_clone stf_cloner = > - IF_CLONE_INITIALIZER(STFNAME, stf_clone_create, stf_clone_destroy, 0); > + IF_CLONE_INITIALIZER(STFNAME, stf_clone_create, stf_clone_destroy, 0, 0); > > int > stf_clone_create(ifc, unit) > @@ -194,7 +194,7 @@ stf_clone_create(ifc, unit) > return (0); > } > > -int > +void > stf_clone_destroy(ifp) > struct ifnet *ifp; > { > @@ -208,7 +208,6 @@ stf_clone_destroy(ifp) > if_detach(ifp); > > free(sc, M_STF); > - return (0); > } > > static int > Index: if_vlan.c > =================================================================== > RCS file: /usr/cvs/src/sys/net/if_vlan.c,v > retrieving revision 1.40 > diff -u -p -r1.40 if_vlan.c > --- if_vlan.c 4 Apr 2002 05:42:09 -0000 1.40 > +++ if_vlan.c 6 Apr 2002 05:41:13 -0000 > @@ -90,7 +90,7 @@ static MALLOC_DEFINE(M_VLAN, "vlan", "80 > static LIST_HEAD(, ifvlan) ifv_list; > > static int vlan_clone_create(struct if_clone *, int); > -static int vlan_clone_destroy(struct ifnet *); > +static void vlan_clone_destroy(struct ifnet *); > static void vlan_start(struct ifnet *ifp); > static void vlan_ifinit(void *foo); > static int vlan_input(struct ether_header *eh, struct mbuf *m); > @@ -102,7 +102,7 @@ static int vlan_unconfig(struct ifnet *i > static int vlan_config(struct ifvlan *ifv, struct ifnet *p); > > struct if_clone vlan_cloner = IF_CLONE_INITIALIZER("vlan", > - vlan_clone_create, vlan_clone_destroy, IF_MAXUNIT); > + vlan_clone_create, vlan_clone_destroy, 0, IF_MAXUNIT); > > /* > * Program our multicast filter. What we're actually doing is > @@ -236,7 +236,7 @@ vlan_clone_create(struct if_clone *ifc, > return (0); > } > > -static int > +static void > vlan_clone_destroy(struct ifnet *ifp) > { > struct ifvlan *ifv = ifp->if_softc; > @@ -250,7 +250,6 @@ vlan_clone_destroy(struct ifnet *ifp) > ether_ifdetach(ifp, ETHER_BPF_SUPPORTED); > > free(ifv, M_VLAN); > - return (0); > } > > static void > > -- > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 17: 6:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 2BEF937B400 for ; Sat, 6 Apr 2002 17:06:28 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g3716Mj08473; Sat, 6 Apr 2002 17:06:22 -0800 Date: Sat, 6 Apr 2002 17:06:22 -0800 From: Brooks Davis To: Julian Elischer Cc: Brooks Davis , net@FreeBSD.ORG Subject: Re: review request: minor cloning API change Message-ID: <20020406170622.B6096@Odin.AC.HMC.Edu> References: <20020405230719.A13516@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="cmJC7u66zC7hs+87" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Sat, Apr 06, 2002 at 04:44:32PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --cmJC7u66zC7hs+87 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 06, 2002 at 04:44:32PM -0800, Julian Elischer wrote: > Please excuse the comment if I'm way off the mark.. >=20 > With a VERY BRIEF look I see that you are returning a void > from the destroy function and it is callled from the module unload code > where some destroy functions used to return ints. >=20 > this ia I think a BAD MOVE.. >=20 > a driver must be able to veto it's own unloading. > If it is in use fro example. You leave no way for the driver to say > "Nope, I can't be unloaded now, I'm busy." NetBSD does it this way and we did so too until a few weeks ago. I'm just returing to the old behavior. The unload of the loopback interface still fails as is required by the system. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --cmJC7u66zC7hs+87 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8r5uNXY6L6fI4GtQRAsVGAKCusHLJ6YyUmSQn1M673jHdeqOQsACeM8BM TuEM192xapvCTxcGWwjYIuM= =5CML -----END PGP SIGNATURE----- --cmJC7u66zC7hs+87-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 18:27:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 605FA37B404 for ; Sat, 6 Apr 2002 18:27:26 -0800 (PST) Received: (from rousskov@localhost) by measurement-factory.com (8.11.6/8.11.6) id g372RFP09208; Sat, 6 Apr 2002 19:27:15 -0700 (MST) (envelope-from rousskov) Date: Sat, 6 Apr 2002 19:27:15 -0700 (MST) From: Alex Rousskov To: Nick Rogness Cc: freebsd-net@FreeBSD.ORG Subject: Re: Forcing packets to the wire In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 6 Apr 2002, Nick Rogness wrote: > I had a brief thought of using an upstream device that could route > the appropriate nat'd addresses to each interface. This is not an option, unfortunately. The required functionality has to be implemented inside one PC (appliance). No external devices. I want to ship that PC to a customer with one NIC labeled "client side", the other NIC labeled "server side". The customer should be able to plug in the wires and test their "explicit" proxies (works now because client packets are addressed to the proxy), their transparent (aka TCP hijacking) proxies (does not work because client packets are addressed to servers and do not leave the appliance), and their networking gear (does not work for the same reason). Thank you, Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 18:45:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 07D5A37B405 for ; Sat, 6 Apr 2002 18:45:28 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020407024527.GOVO15826.rwcrmhc54.attbi.com@blossom.cjclark.org>; Sun, 7 Apr 2002 02:45:27 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g372jQE71070; Sat, 6 Apr 2002 18:45:26 -0800 (PST) (envelope-from cjc) Date: Sat, 6 Apr 2002 18:45:26 -0800 From: "Crist J. Clark" To: Luigi Rizzo Cc: Andreas Klemm , freebsd-net@FreeBSD.ORG Subject: Re: better DSL bandwidth usage by priorizing ACKs in outgoing packets over others Message-ID: <20020406184526.E70207@blossom.cjclark.org> References: <20020402163912.GD4307@titan.klemm.gtn.com> <20020406065735.A29144@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020406065735.A29144@iguana.icir.org>; from luigi@iet.unipi.it on Sat, Apr 06, 2002 at 06:57:36AM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Apr 06, 2002 at 06:57:36AM -0800, Luigi Rizzo wrote: > On Tue, Apr 02, 2002 at 06:39:12PM +0200, Andreas Klemm wrote: > > we would need a minor tweak to the ipfw code so that it can match > packets whose size is less than X bytes (so the mechanism is general > enough to be used for other things). This could be done in a matter > of 1hour or less, most of the time would be wasted in figuring out > a way to implement it that does not break binary compatibility. Actually, could just match ACK-only packets, no PSH? ...I'm getting some severe deja vu with this topic. But I can't recall what the exact subject was previously. > Once we have done this, we can define a dummynet pipe with > a bandwidth <= the bottleneck (128kbit/s), and use"queue" rules > to privilege the acks wrt other traffic. > > Something like > > > ipfw pipe 10 config bw 100kbit/s > ipfw queue 1 config weight 1 pipe 10 > ipfw queue 100 config weight 100 pipe 10 > ipfw add queue 100 tcp from any to ${outside} shorter-than 80 > ipfw add queue 1 ip from any to ${outside} > > This said, i have never seen terribly bad effects when cvsupping > and doing other things. If there is something which goes to its > knees, this is the disk. On a previous Internet provider, I had silent PMTU issues somewhere downstream. Ploss went through the roof when you got above 1000 bytes-per-packet upstream. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 21:13:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 218CA37B400 for ; Sat, 6 Apr 2002 21:13:30 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020407051326.STTO3676.rwcrmhc52.attbi.com@blossom.cjclark.org>; Sun, 7 Apr 2002 05:13:26 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g375DQu71303; Sat, 6 Apr 2002 21:13:26 -0800 (PST) (envelope-from cjc) Date: Sat, 6 Apr 2002 21:13:25 -0800 From: "Crist J. Clark" To: wsmuir@islandnet.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: one machine, 2 external nics Message-ID: <20020406211325.F70207@blossom.cjclark.org> References: <020405093517@islandnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <020405093517@islandnet.com>; from wsmuir@islandnet.com on Fri, Apr 05, 2002 at 09:35:17AM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Apr 05, 2002 at 09:35:17AM -0800, wsmuir@islandnet.com wrote: > Hi all... > > I'd really appreciate a hint or two on this. > > I'm having problems deciding on the 'best way' for this one... > > I have a freebsd 4.2 firewall machine built and have it plugged into > both a dsl modem with static ips and a cable modem with static ips... > > what I am trying to do is have the machine respond to the outside > like it was 2 separate machines. > > for instance i want to be able to connect to sshd on either external > ip and have it respond. > my understanding is that it won't do this because the 2nd nic doesn't > know how to route beyond its own subnet. > > this is to solve a bigger problem for which there are other > solutions, but I would like to know how to do this one > specifically... thank you Are you doing natd(8)? If so, it is pretty easy to do. natd(8) will end up tracking which interface the packet came in for you. You can use the information in natd(8), when it translates the source address on outgoing packets, to "route" packets to a next-hop (one gateway or another) using a 'fwd' rule. There still are some tricks to doing this, but it's quite doable. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 6 21:28:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id DC15537B400 for ; Sat, 6 Apr 2002 21:28:24 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020407052824.YQMW18078.rwcrmhc51.attbi.com@blossom.cjclark.org>; Sun, 7 Apr 2002 05:28:24 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g375SNe71336; Sat, 6 Apr 2002 21:28:23 -0800 (PST) (envelope-from cjc) Date: Sat, 6 Apr 2002 21:28:22 -0800 From: "Crist J. Clark" To: Nick Rogness Cc: "Matthew D. Fuller" , Alex Rousskov , freebsd-net@FreeBSD.ORG Subject: Re: Forcing packets to the wire Message-ID: <20020406212822.G70207@blossom.cjclark.org> References: <20020405222555.C65380@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nick@rogness.net on Sat, Apr 06, 2002 at 01:57:44PM -0600 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Apr 06, 2002 at 01:57:44PM -0600, Nick Rogness wrote: > On Fri, 5 Apr 2002, Matthew D. Fuller wrote: > > > On Fri, Apr 05, 2002 at 06:48:09PM -0600 I heard the voice of > > Nick Rogness, and lo! it spake thus: > > > On Fri, 5 Apr 2002, Alex Rousskov wrote: > > > > > > > > - Is it possible without kernel modifications? How? > > > > > > AFAIK, No. Your only 2 possiblities that I could think of would > > > be to use policy routing or natd. Both will fail in this case. > > > > You MIGHT be able to use ipfw divert/pipe rules to somehow shove the > > packets into a program on their way out, and write a program that > > would use raw sockets to hand-assemble the IP datagram on the way out; > > I'm not sure if the kernel would try to outsmart you on that. > > Yeh, I thought of that. The problem is packets never leave > anywhere since the route for the other NIC is not "OUT" any > interface...it is the machine itself. Then never go over a _physical_ inteface, but they _do_ cross an interface, lo0, the internal loopback. ipfw fwd ip from to in via lo0 -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message