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 <freebsd-net@freebsd.org>; 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 <geekvinod@yahoo.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Sun, 31 Mar 2002 20:05:28 -0500
From: "Peter Brezny" <peter@skyrunner.net>
To: <freebsd-net@freebsd.org>
Subject: NATD theoretical max and tuning question
Date: Sun, 31 Mar 2002 20:06:16 -0500
Message-ID: <NEBBIGLHNDFEJMMIEGOOIEDPEPAA.peter@skyrunner.net>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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" <robert@quantum-radio.net.au>
From: "Merlin" <robert@quantum-radio.net.au>
To: "freebsd-net" <freebsd-net@freebsd.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <joost@bps.jodocus.org>
To: Peter Brezny <peter@skyrunner.net>
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 <joost@FreeBSD.ORG>,
Peter Brezny <peter@skyrunner.net>, freebsd-net@FreeBSD.ORG
References: <NEBBIGLHNDFEJMMIEGOOIEDPEPAA.peter@skyrunner.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: <NEBBIGLHNDFEJMMIEGOOIEDPEPAA.peter@skyrunner.net>; from peter@skyrunner.net on Sun, Mar 31, 2002 at 08:06:16PM -0500
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <rizzo@icir.org>
To: Joost Bekkers <joost@bps.jodocus.org>
Cc: Peter Brezny <peter@skyrunner.net>, freebsd-net@FreeBSD.ORG
Subject: Re: NATD theoretical max and tuning question
Message-ID: <20020401012912.B69717@iguana.icir.org>
References: <NEBBIGLHNDFEJMMIEGOOIEDPEPAA.peter@skyrunner.net> <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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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: <peter@skyrunner.net>
From: "Peter Brezny" <peter@skyrunner.net>
To: "Luigi Rizzo" <rizzo@icir.org>,
"Joost Bekkers" <joost@bps.jodocus.org>
Cc: <freebsd-net@FreeBSD.ORG>
Subject: RE: NATD theoretical max and tuning question
Date: Mon, 1 Apr 2002 11:00:20 -0500
Message-ID: <NEBBIGLHNDFEJMMIEGOOAEEHEPAA.peter@skyrunner.net>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <geekvinod@yahoo.com>
Subject: Re: help needed with configuring a gateway
To: Vladimir Terziev <vlady@rila.bg>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
no i don't.
Vinod
--- Vladimir Terziev <vlady@rila.bg> wrote:
> Do you have active firewall on your gateway?
>
>
> On Sun, 31 Mar 2002 16:28:39 -0800 (PST)
> Vinod <geekvinod@yahoo.com> 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 <freebsd-net@freebsd.org>; 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 <geekvinod@yahoo.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <rizzo@icir.org>
To: Peter Brezny <peter@skyrunner.net>
Cc: Joost Bekkers <joost@bps.jodocus.org>, 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> <NEBBIGLHNDFEJMMIEGOOAEEHEPAA.peter@skyrunner.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <NEBBIGLHNDFEJMMIEGOOAEEHEPAA.peter@skyrunner.net>
User-Agent: Mutt/1.3.23i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <c.prevotaux@hexanet.fr>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <larse@ISI.EDU>
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 <c.prevotaux@hexanet.fr>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <larse@isi.edu> 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <c.prevotaux@hexanet.fr>
To: Lars Eggert <larse@ISI.EDU>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <larse@ISI.EDU> 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 <larse@isi.edu> 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 <freebsd-net@freebsd.org>; 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 <larse@ISI.EDU>
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 <c.prevotaux@hexanet.fr>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <larse@isi.edu> 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 <freebsd-net@freebsd.org>; 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 <c.prevotaux@hexanet.fr>
To: Lars Eggert <larse@ISI.EDU>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Mon, 01 Apr 2002 14:29:02 -0800
Lars Eggert <larse@ISI.EDU> 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 <larse@isi.edu> 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 <freebsd-net@FreeBSD.ORG>; 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 <freebsd-net@FreeBSD.ORG>; Sat, 30 Mar 2002 14:19:23 -0500
Date: Sat, 30 Mar 2002 14:19:23 -0500 (EST)
From: tony bourke <tony@vegan.net>
To: <freebsd-net@FreeBSD.ORG>
Subject: tcpCurrEstab in 4.2 Kernel
Message-ID: <Pine.LNX.4.33.0203301400040.1243-100000@nori.vegan.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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" <cjc@FreeBSD.ORG>
To: Lars Eggert <larse@ISI.EDU>
Cc: Christophe Prevotaux <c.prevotaux@hexanet.fr>,
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <julian@elischer.org>
To: "Crist J. Clark" <cjc@FreeBSD.ORG>
Cc: Lars Eggert <larse@ISI.EDU>,
Christophe Prevotaux <c.prevotaux@hexanet.fr>,
freebsd-net@FreeBSD.ORG
Subject: Re: HUT Project
In-Reply-To: <20020401173556.D99214@blossom.cjclark.org>
Message-ID: <Pine.BSF.4.21.0204011823180.16786-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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?= <c.prevotaux@hexanet.fr>
To: "Crist J. Clark" <cjc@FreeBSD.ORG>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Mon, 1 Apr 2002 17:35:56 -0800
"Crist J. Clark" <cjc@FreeBSD.ORG> 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 <freebsd-net@freebsd.org>; 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 <barney@databus.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; Tue, 2 Apr 2002 09:00:18 -0800 (PST)
Received: by exchange.corp.cre8.com with Internet Mail Service (5.5.2653.19)
id <HTN53HRT>; Tue, 2 Apr 2002 12:00:30 -0500
Message-ID: <2F6DCE1EFAB3BC418B5C324F13934C96016C950B@exchange.corp.cre8.com>
From: Scott Ullrich <sullrich@CRE8.COM>
To: 'Barney Wolff' <barney@databus.com>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: HUT Project</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>The HUT Project includes FreeVRRPD. Since =
Sebastien hasn't rung in here, I will try to clear the air. =
</FONT>
</P>
<P><FONT SIZE=3D2>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. </FONT></P>
<P><FONT SIZE=3D2>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).</FONT></P>
<P><FONT SIZE=3D2>Hopefully in the next couple of weeks we will have a =
new development version posted.</FONT>
</P>
<P><FONT SIZE=3D2>Peace,</FONT>
</P>
<P><FONT SIZE=3D2>Scott</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Barney Wolff [<A =
HREF=3D"mailto:barney@databus.com">mailto:barney@databus.com</A>]</FONT>=
<BR><FONT SIZE=3D2>> Sent: Tuesday, April 02, 2002 11:42 AM</FONT>
<BR><FONT SIZE=3D2>> To: freebsd-net@freebsd.org</FONT>
<BR><FONT SIZE=3D2>> Subject: Re: HUT Project</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Does anyone have any insight on how this =
compares to the existing</FONT>
<BR><FONT SIZE=3D2>> net/freevrrpd port? Without digging at =
all, it appears that freevrrpd</FONT>
<BR><FONT SIZE=3D2>> tries to update everybody's ARP tables rather =
than taking over the</FONT>
<BR><FONT SIZE=3D2>> MAC address. I wonder how well that would =
work.</FONT>
<BR><FONT SIZE=3D2>> -- </FONT>
<BR><FONT SIZE=3D2>> Barney Wolff</FONT>
<BR><FONT SIZE=3D2>> I never met a computer I didn't like.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> To Unsubscribe: send mail to =
majordomo@FreeBSD.org</FONT>
<BR><FONT SIZE=3D2>> with "unsubscribe freebsd-net" in the =
body of the message</FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_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 <freebsd-net@freebsd.org>; Tue, 2 Apr 2002 14:23:19 -0800 (PST)
Received: by exchmx2.lsuhsc.edu with Internet Mail Service (5.5.2653.19)
id <G9JWSGHP>; Tue, 2 Apr 2002 16:22:09 -0600
Message-ID: <DAC809EAC7E4594AA0696EF512F6ABF10AA73879@sh-exch>
From: "Mire, John" <jmire@lsuhsc.edu>
To: "'freebsd-net@freebsd.org'" <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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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" <cjc@FreeBSD.ORG>
To: Scott Ullrich <sullrich@CRE8.COM>
Cc: "'Barney Wolff'" <barney@databus.com>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <HTN532Z7>; Tue, 2 Apr 2002 18:52:26 -0500
Message-ID: <2F6DCE1EFAB3BC418B5C324F13934C96016C9521@exchange.corp.cre8.com>
From: Scott Ullrich <sullrich@CRE8.COM>
To: "'Crist J. Clark'" <cjc@FreeBSD.ORG>,
Scott Ullrich <sullrich@CRE8.COM>
Cc: 'Barney Wolff' <barney@databus.com>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: HUT Project</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>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? </FONT></P>
<P><FONT SIZE=3D2>-Scott</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Crist J. Clark [<A =
HREF=3D"mailto:cjc@FreeBSD.ORG">mailto:cjc@FreeBSD.ORG</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: Tuesday, April 02, 2002 6:36 PM</FONT>
<BR><FONT SIZE=3D2>> To: Scott Ullrich</FONT>
<BR><FONT SIZE=3D2>> Cc: 'Barney Wolff'; =
freebsd-net@FreeBSD.ORG</FONT>
<BR><FONT SIZE=3D2>> Subject: Re: HUT Project</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> On Tue, Apr 02, 2002 at 12:00:30PM -0500, Scott =
Ullrich wrote:</FONT>
<BR><FONT SIZE=3D2>> > The HUT Project includes FreeVRRPD. =
Since Sebastien hasn't </FONT>
<BR><FONT SIZE=3D2>> rung in here, I</FONT>
<BR><FONT SIZE=3D2>> > will try to clear the air. </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > Sebastien and I are currently rewriting =
FreeVRRPD to take </FONT>
<BR><FONT SIZE=3D2>> care of the</FONT>
<BR><FONT SIZE=3D2>> > remaining RFC issues and to cleanup the =
ARP code. The new </FONT>
<BR><FONT SIZE=3D2>> version will be</FONT>
<BR><FONT SIZE=3D2>> > completely RFC compliant and will feature =
a few extra bells </FONT>
<BR><FONT SIZE=3D2>> and whistles of</FONT>
<BR><FONT SIZE=3D2>> > its own. </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > My development version currently does not =
update arp cache </FONT>
<BR><FONT SIZE=3D2>> tables but takes</FONT>
<BR><FONT SIZE=3D2>> > over the Mac. In addition, the =
master and backup arp </FONT>
<BR><FONT SIZE=3D2>> address are settable</FONT>
<BR><FONT SIZE=3D2>> > for each VRID.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> IIRC, the exact MAC address of the virtual =
router as a function of</FONT>
<BR><FONT SIZE=3D2>> VRID is specified in the RFC?</FONT>
<BR><FONT SIZE=3D2>> -- </FONT>
<BR><FONT SIZE=3D2>> Crist J. =
Clark &=
nbsp; =
| cjclark@alum.mit.edu</FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
;  =
; | cjclark@jhu.edu</FONT>
<BR><FONT SIZE=3D2>> <A HREF=3D"http://people.freebsd.org/~cjc/" =
TARGET=3D"_blank">http://people.freebsd.org/~cjc/</A> =
| cjc@freebsd.org</FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_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 <freebsd-net@FreeBSD.ORG>; 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" <crist.clark@attbi.com>
To: Scott Ullrich <sullrich@CRE8.COM>
Cc: "'Barney Wolff'" <barney@databus.com>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Wed, 3 Apr 2002 05:02:47 +0000 (GMT)
Date: Wed, 3 Apr 2002 05:02:47 +0000 (GMT)
From: Kris Kirby <kris@catonic.net>
To: <freebsd-net@freebsd.org>
Subject: VPN / VLAN?
Message-ID: <Pine.BSF.4.33.0204030458480.12164-100000@spaz.catonic.net>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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.
<kris@nospam.catonic.net> | 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <thomas@cuivre.fr.eu.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <spe@selectbourse.net>
To: cjclark@alum.mit.edu, "Crist J. Clark" <crist.clark@attbi.com>,
Scott Ullrich <sullrich@CRE8.COM>
Subject: Re: HUT Project
Date: Wed, 3 Apr 2002 12:06:20 +0200
X-Mailer: KMail [version 1.3.2]
Cc: "'Barney Wolff'" <barney@databus.com>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=3<rxcsum,txcsum>
/* 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=3<rxcsum,txcsum>
/* 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=3<rxcsum,txcsum>
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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=3<rxcsum,txcsum>
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 <hosokawa@FreeBSD.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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
<hosokawa@FreeBSD.org>
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 <archie@dellroad.org>
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 <hosokawa@FreeBSD.ORG>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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" <sam@errno.com>
To: <freebsd-net@freebsd.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <julian@elischer.org>
To: Sam Leffler <sam@errno.com>
Cc: freebsd-net@freebsd.org
Subject: Re: kame ipsec vs. openbsd ipsec
In-Reply-To: <2c1d01c1db3b$460c7720$52557f42@errno.com>
Message-ID: <Pine.BSF.4.21.0204031036550.26496-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <julian@elischer.org>
To: Sebastien Petit <spe@selectbourse.net>
Cc: cjclark@alum.mit.edu, "Crist J. Clark" <crist.clark@attbi.com>,
Scott Ullrich <sullrich@CRE8.COM>,
"'Barney Wolff'" <barney@databus.com>, freebsd-net@FreeBSD.ORG
Subject: Re: HUT Project
In-Reply-To: <20020403100144.E148FBADD@sbserv0.intra.selectbourse.net>
Message-ID: <Pine.BSF.4.21.0204031021400.26496-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> options=3<rxcsum,txcsum>
> /* 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> options=3<rxcsum,txcsum>
> /* 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> options=3<rxcsum,txcsum>
> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> options=3<rxcsum,txcsum>
> 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 <freebsd-net@freebsd.org>; 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 <larse@ISI.EDU>
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 <kris@catonic.net>
Cc: freebsd-net@freebsd.org
Subject: Re: VPN / VLAN?
References: <Pine.BSF.4.33.0204030458480.12164-100000@spaz.catonic.net>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040304090005000704070801"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <larse@isi.edu> 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 <freebsd-net@freebsd.org>; 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" <sam@errno.com>
To: "Julian Elischer" <julian@elischer.org>
Cc: <freebsd-net@freebsd.org>
References: <Pine.BSF.4.21.0204031036550.26496-100000@InterJet.elischer.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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" <julian@elischer.org>
To: "Sam Leffler" <sam@errno.com>
Cc: <freebsd-net@freebsd.org>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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?= <c.prevotaux@hexanet.fr>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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?= <c.prevotaux@hexanet.fr>
To: Scott Ullrich <sullrich@CRE8.COM>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Tue, 2 Apr 2002 12:00:30 -0500
Scott Ullrich <sullrich@CRE8.COM> 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 <freebsd-net@freebsd.org>; 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 <larse@ISI.EDU>
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 <sam@errno.com>
Cc: Julian Elischer <julian@elischer.org>, freebsd-net@freebsd.org
Subject: Re: kame ipsec vs. openbsd ipsec
References: <Pine.BSF.4.21.0204031036550.26496-100000@InterJet.elischer.org> <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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <larse@isi.edu> 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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?= <c.prevotaux@hexanet.fr>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <rizzo@icir.org>
To: Christophe =?iso-8859-1?Q?Pr=E9votaux?= <c.prevotaux@hexanet.fr>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <julian@elischer.org>
To: Christophe =?ISO-8859-1?B?UHLpdm90YXV4?= <c.prevotaux@hexanet.fr>
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: <Pine.BSF.4.21.0204031118260.21569-100000@InterJet.elischer.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <barney@databus.com>
To: Tatsumi Hosokawa <hosokawa@FreeBSD.ORG>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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
> <hosokawa@FreeBSD.org>
> 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 <hosokawa@FreeBSD.org>
To: Barney Wolff <barney@databus.com>
Cc: Tatsumi Hosokawa <hosokawa@FreeBSD.ORG>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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
<hosokawa@FreeBSD.org>
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 <hosokawa@FreeBSD.org>
To: Tatsumi Hosokawa <hosokawa@FreeBSD.org>
Cc: Barney Wolff <barney@databus.com>,
Tatsumi Hosokawa <hosokawa@FreeBSD.ORG>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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
<hosokawa@FreeBSD.org>
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 <hosokawa@FreeBSD.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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
<hosokawa@FreeBSD.org>
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 <freebsd-net@FreeBSD.ORG>; 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" <crist.clark@attbi.com>
To: Sebastien Petit <spe@selectbourse.net>
Cc: Scott Ullrich <sullrich@CRE8.COM>,
"'Barney Wolff'" <barney@databus.com>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> options=3<rxcsum,txcsum>
> /* 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> options=3<rxcsum,txcsum>
> /* 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> options=3<rxcsum,txcsum>
> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> options=3<rxcsum,txcsum>
> 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 <freebsd-net@freebsd.org>; 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" <spe@selectbourse.net>
To: <cjclark@alum.mit.edu>
Cc: "Scott Ullrich" <sullrich@CRE8.COM>, <freebsd-net@freebsd.org>
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" <spe@selectbourse.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
----- Original Message -----
From: "Crist J. Clark" <crist.clark@attbi.com>
To: "Sebastien Petit" <spe@selectbourse.net>
Cc: "Scott Ullrich" <sullrich@CRE8.COM>; "'Barney Wolff'"
<barney@databus.com>; <freebsd-net@FreeBSD.ORG>
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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > options=3<rxcsum,txcsum>
> > /* 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > options=3<rxcsum,txcsum>
> > /* 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > options=3<rxcsum,txcsum>
> > 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > options=3<rxcsum,txcsum>
> > 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 <freebsd-net@freebsd.org>; 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" <crist.clark@attbi.com>
To: Sebastien Petit <spe@selectbourse.net>
Cc: Scott Ullrich <sullrich@CRE8.COM>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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" <tariq@inty.net>
To: "Sam Leffler" <sam@errno.com>, <freebsd-net@freebsd.org>
Subject: RE: kame ipsec vs. openbsd ipsec / netgraph ipsec node?
Date: Thu, 4 Apr 2002 09:24:11 +0100
Message-ID: <MPENKFCCIIDAJKJJOLBHMEAJCNAA.tariq@inty.net>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <spe@selectbourse.net>
To: cjclark@alum.mit.edu, "Crist J. Clark" <crist.clark@attbi.com>
Subject: Re: HUT Project
Date: Thu, 4 Apr 2002 10:40:21 +0200
X-Mailer: KMail [version 1.3.2]
Cc: Scott Ullrich <sullrich@CRE8.COM>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <mbertsch@radioactivedata.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <tinguely@web.cs.ndsu.nodak.edu>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Thu, 4 Apr 2002 17:44:16 +0200
Date: Thu, 4 Apr 2002 17:44:16 +0200 (CEST)
From: Juan Francisco Rodriguez Hervella <jrh@lab.it.uc3m.es>
To: freebsd-net@freebsd.org
Subject: Problems trying to debugging a kernel with remote GDB
Message-ID: <Pine.LNX.3.96.1020404174230.2952A-100000@lm002.lab.it.uc3m.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <matt@ice-nine.org>
To: Sam Leffler <sam@errno.com>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: kame ipsec vs. openbsd ipsec
In-Reply-To: <2c1d01c1db3b$460c7720$52557f42@errno.com>
Message-ID: <Pine.BSO.4.44.0204040846240.28381-100000@iorek.ice-nine.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <tariq@inty.net>:
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <glaerumk@online.no>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <larse@ISI.EDU>
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 <tariq@inty.net>
Cc: Sam Leffler <sam@errno.com>, freebsd-net@freebsd.org,
Joe Touch <touch@ISI.EDU>
Subject: Re: kame ipsec vs. openbsd ipsec / netgraph ipsec node?
References: <MPENKFCCIIDAJKJJOLBHMEAJCNAA.tariq@inty.net>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060102070009020102050209"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <larse@isi.edu> 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 <freebsd-net@freebsd.org>; 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 <jrh@lab.it.uc3m.es>
To: Peter Lei <peter.lei@ieee.org>
Cc: freebsd-net@freebsd.org
Subject: Re: Problems trying to debugging a kernel with remote GDB
Message-ID: <Pine.LNX.3.96.1020404182256.4442A-100000@lm008.lab.it.uc3m.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <ambrisko@ambrisko.com>
Cc: "M. Warner Losh" <imp@village.org>, j@uriah.heep.sax.de,
alan@clegg.com, luigi@FreeBSD.org, nsayer@FreeBSD.org,
ryand-bsd@zenspider.com, Brian Somers <brian@freebsd-services.com>,
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 <ambrisko@ambrisko.com>
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 <brian@freebsd-services.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <j@uriah.heep.sax.de> 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 <brian@freebsd-services.com> <brian@Awfulhak.org>
http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org>
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 <freebsd-net@FreeBSD.ORG>; 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 <thomas@cuivre.fr.eu.org>
Cc: freebsd-net@FreeBSD.ORG, brian@freebsd-services.com
Subject: Re: Userland ppp hung in Ack-Rcvd
In-Reply-To: Message from Thomas Quinot <thomas@cuivre.fr.eu.org>
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 <brian@freebsd-services.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <brian@freebsd-services.com> <brian@Awfulhak.org>
http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.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 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 <freebsd-net@freebsd.org>; 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 <kris@catonic.net>
To: Lars Eggert <larse@ISI.EDU>
Cc: <freebsd-net@freebsd.org>
Subject: Re: VPN / VLAN?
In-Reply-To: <3CAB4CD0.9040508@isi.edu>
Message-ID: <Pine.BSF.4.33.0204041937170.27304-100000@spaz.catonic.net>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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.
<kris@nospam.catonic.net> | 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 <j@uriah.heep.sax.de>
To: Brian Somers <brian@freebsd-services.com>
Cc: Doug Ambrisko <ambrisko@ambrisko.com>,
"M. Warner Losh" <imp@village.org>, 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 <joerg_wunsch@uriah.heep.sax.de>
References: <ambrisko@ambrisko.com> <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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <larse@ISI.EDU>
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 <kris@catonic.net>
Cc: freebsd-net@freebsd.org
Subject: Re: VPN / VLAN?
References: <Pine.BSF.4.33.0204041937170.27304-100000@spaz.catonic.net>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040302050807080100070801"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <larse@isi.edu> 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 <freebsd-net@FreeBSD.ORG>; 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 <c.prevotaux@hexanet.fr>
To: Luigi Rizzo <rizzo@icir.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Wed, 3 Apr 2002 11:15:45 -0800
Luigi Rizzo <rizzo@icir.org> 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 <ambrisko@ambrisko.com>
Cc: "M. Warner Losh" <imp@village.org>, j@uriah.heep.sax.de,
alan@clegg.com, luigi@FreeBSD.ORG, nsayer@FreeBSD.ORG,
ryand-bsd@zenspider.com, Brian Somers <brian@freebsd-services.com>,
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 <stephenm@bayarea.net>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <std_disclaimer.h>
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 <freebsd-net@FreeBSD.ORG>; 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 <archie@dellroad.org>
Message-Id: <200204042141.g34LfIo80888@arch20m.dellroad.org>
Subject: Re: Problems trying to debugging a kernel with remote GDB
In-Reply-To: <Pine.LNX.3.96.1020404182256.4442A-100000@lm008.lab.it.uc3m.es>
"from Juan Francisco Rodriguez Hervella at Apr 4, 2002 06:23:56 pm"
To: Juan Francisco Rodriguez Hervella <jrh@lab.it.uc3m.es>
Date: Thu, 4 Apr 2002 13:41:17 -0800 (PST)
Cc: Peter Lei <peter.lei@ieee.org>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <dwatson@eecs.umich.edu>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <BROADCAST,SIMPLEX,MULTICAST>
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 <UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
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: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <ServerWorks NB6635 3.0LE host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
pci0: <S3 Savage 4 graphics accelerator> at 1.0
pci0: <unknown card> (vendor=0x1022, dev=0x2000) at 2.0 irq 11
pci0: <unknown card> (vendor=0x8086, dev=0x1229) at 9.0 irq 15
isab0: <ServerWorks IB6566 PCI to ISA bridge> at device 15.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <ServerWorks ROSB4 ATA33 controller> port 0x840-0x84f at device 15.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: <OHCI USB controller> at 15.2 irq 9
pcib1: <ServerWorks NB6635 3.0LE host to PCI bridge> on motherboard
pci1: <PCI bus> on pcib1
ahc0: <Adaptec aic7899 Ultra160 SCSI adapter> 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: <Adaptec aic7899 Ultra160 SCSI adapter> 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: <Intel(R) PRO/1000 Network Connection, Version - 1.0.9> mem 0xeffc0000-0xeffdffff irq 11 at device 5.0 on pci1
em0: Speed:1000 Mbps Duplex:Full
em1: <Intel(R) PRO/1000 Network Connection, Version - 1.0.9> mem 0xeffa0000-0xeffbffff irq 15 at device 6.0 on pci1
em1: Speed:1000 Mbps Duplex:Full
orm0: <Option ROM> at iomem 0xc0000-0xc9fff on isa0
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x80 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
plip0: <PLIP network interface> on ppbus0
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
IP packet filtering initialized, divert disabled, rule-based forwarding disabled, default to accept, logging disabled
BRIDGE 011031, have 5 interfaces
-- index 1 type 6 phy 0 addrl 6 addr 00.d0.b7.45.85.cf
-- index 2 type 6 phy 0 addrl 6 addr 00.d0.b7.45.85.2e
acd0: CDROM <CRN-8241B> at ata0-master using PIO4
Waiting 10 seconds for SCSI devices to settle
pass1 at ahc1 bus 0 target 8 lun 0
pass1: <IBM YGLv3 S2 0> Fixed Processor SCSI-2 device
pass1: 3.300MB/s transfers
da0 at ahc1 bus 0 target 0 lun 0
da0: <IBM-PSG DDYS-T09170M F S96E> Fixed Direct Access SCSI-3 device
da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled
da0: 8678MB (17774160 512 byte sectors: 255H 63S/T 1106C)
Mounting root from ufs:/dev/da0s1a
ifpromisc from if.c:
ifpromisc(ifp, pswitch)
struct ifnet *ifp;
int pswitch;
{
struct ifreq ifr;
int error;
int oldflags;
oldflags = ifp->if_flags;
if (pswitch) {
/*
* If the device is not configured up, we cannot put it in
* promiscuous mode.
*/
if ((ifp->if_flags & IFF_UP) == 0) {
log(LOG_INFO,
"%s%d: not up, promiscuous mode NOT enabled\n",
ifp->if_name, ifp->if_unit);
return (ENETDOWN);
}
if (ifp->if_pcount++ != 0) {
log(LOG_INFO,
"%s%d: promiscuous counter = %d, promiscuous "
"mode is already enabled\n",
ifp->if_name, ifp->if_unit, ifp->if_pcount);
return (0);
}
ifp->if_flags |= IFF_PROMISC;
log(LOG_INFO, "%s%d: promiscuous mode enabled (dw)\n",
ifp->if_name, ifp->if_unit);
} else {
if (--ifp->if_pcount > 0)
return (0);
ifp->if_flags &= ~IFF_PROMISC;
log(LOG_INFO, "%s%d: promiscuous mode disabled\n",
ifp->if_name, ifp->if_unit);
}
ifr.ifr_flags = ifp->if_flags;
error = (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t)&ifr);
if (error == 0) {
log(LOG_INFO, "%s%d: ioctl succeeded!\n",
ifp->if_name, ifp->if_unit);
rt_ifmsg(ifp);
} else {
log(LOG_INFO, "%s%d: ioctl failed (%d)!\n",
ifp->if_name, ifp->if_unit, error);
ifp->if_flags = oldflags;
}
return error;
}
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 15:20:36 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 2FA4E37B405; Thu, 4 Apr 2002 15:20:21 -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 g34NK9Cu001874;
Fri, 5 Apr 2002 00:20:09 +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 g34NK6q7041410;
Fri, 5 Apr 2002 00:20:06 +0100 (BST)
(envelope-from brian@freebsd-services.com)
Message-Id: <200204042320.g34NK6q7041410@hak.lan.Awfulhak.org>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
Cc: Brian Somers <brian@freebsd-services.com>,
Doug Ambrisko <ambrisko@ambrisko.com>,
"M. Warner Losh" <imp@village.org>, 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
In-Reply-To: Message from Joerg Wunsch <j@uriah.heep.sax.de>
of "Thu, 04 Apr 2002 21:58:44 +0200." <20020404215844.A83154@uriah.heep.sax.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 05 Apr 2002 00:20:06 +0100
From: Brian Somers <brian@freebsd-services.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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.
Hmm, valid point :(
So the code will have to become something like the attached ? This
is quite grotty, but I can't think of any clean way other than
somehow telling SIOCAIFADDR and SIOCSIFADDR not to add the host route
in the first place.
> --
> cheers, J"org .-.-. --... ...-- -.. . DL8DTL
>
> http://www.sax.de/~joerg/ NIC: JW11-RIPE
> Never trust an operating system you don't have sources for. ;-)
--
Brian <brian@freebsd-services.com> <brian@Awfulhak.org>
http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org>
Index: in.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/in.c,v
retrieving revision 1.63
diff -u -r1.63 in.c
--- in.c 1 Apr 2002 21:31:06 -0000 1.63
+++ in.c 4 Apr 2002 23:18:36 -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,25 @@
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 host routes for interface addresses of
+ * 0.0.0.0 --> 0.255.255.255 netmask 255.0.0.0. This makes it
+ * possible to assign several such address pairs with consistent
+ * results (no host route) and is required by BOOTP.
+ *
+ * XXX: This is ugly ! There should be a way for the caller to
+ * say that they don't want a host route.
+ */
+ if (ia->ia_addr.sin_addr.s_addr != INADDR_ANY ||
+ ia->ia_netmask != IN_CLASSA_NET ||
+ ia->ia_dstaddr.sin_addr.s_addr != htonl(IN_CLASSA_HOST)) {
+ 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 16:20:41 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 D1AFD37B43F; Thu, 4 Apr 2002 16:19:38 -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 g350JSCu002060;
Fri, 5 Apr 2002 01:19:28 +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 g350JPq7042133;
Fri, 5 Apr 2002 01:19:25 +0100 (BST)
(envelope-from brian@freebsd-services.com)
Message-Id: <200204050019.g350JPq7042133@hak.lan.Awfulhak.org>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: stephen macmanus <stephenm@bayarea.net>
Cc: Doug Ambrisko <ambrisko@ambrisko.com>,
"M. Warner Losh" <imp@village.org>, j@uriah.heep.sax.de,
alan@clegg.com, luigi@FreeBSD.ORG, nsayer@FreeBSD.ORG,
ryand-bsd@zenspider.com, Brian Somers <brian@freebsd-services.com>,
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 stephen macmanus <stephenm@bayarea.net>
of "Thu, 04 Apr 2002 13:10:44 -0800." <200204042110.NAA05062@shell4.bayarea.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 05 Apr 2002 01:19:25 +0100
From: Brian Somers <brian@freebsd-services.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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.
Hmm, thanks for the pointer.
I think this now works - where it didn't before (although see
the new patch posted in response to Joergs mention of the sppp
problem).
The lack of the EEXIST hack in my patch means that this will work as
before:
ifconfig dc0 inet 172.16.0.5 netmask 0xffffff00
ifconfig dc0 inet 172.16.0.11 netmask 0xfffffff8
Where connections to 172.16.0.1-172.16.0.7 and 172.16.0.16-172.16.0.255
come from 172.16.0.5 and connections to 172.16.0.8-172.16.0.15 come from
172.16.0.11.
After the above however,
ifconfig dc0 inet 172.16.0.14 netmask 0xfffffff8
will (correctly) fail in the patched code. It fails because the
gateway/netmask combination produces a duplicate key in the routing
table, returning an error from rtinit(). Previously, this failure
was masked by the EEXIST hack, allowing the interface address update
without a corresponding host route.
I believe the old behaviour becomes obviously wrong when someone then
deletes the 172.16.0.11 interface address, blowing away the
associated host route and leaving no routing table entry to talk to
the 172.16.0.14 address.
So I don't think the old was was really safe after all :-/
> Stephen
> ------------------
> Stephen Macmanus #include <std_disclaimer.h>
> 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"
--
Brian <brian@freebsd-services.com> <brian@Awfulhak.org>
http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.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 16:51:21 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 E52AE37B405
for <freebsd-net@FreeBSD.ORG>; Thu, 4 Apr 2002 16:51:17 -0800 (PST)
Received: from localhost (nick@localhost)
by cody.jharris.com (8.11.1/8.9.3) with ESMTP id g350vpT86505;
Thu, 4 Apr 2002 18:57:51 -0600 (CST)
(envelope-from nick@rogness.net)
Date: Thu, 4 Apr 2002 18:57:51 -0600 (CST)
From: Nick Rogness <nick@rogness.net>
X-Sender: nick@cody.jharris.com
To: glaerumk <glaerumk@online.no>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: natd and online games
In-Reply-To: <3CAFB036@epostleser.online.no>
Message-ID: <Pine.BSF.4.21.0204041853480.86383-100000@cody.jharris.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Thu, 4 Apr 2002, glaerumk wrote:
> 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?
Yes... and this question belongs on the freebsd-questions mailing
list not freebsd-net.
Nick Rogness <nick@rogness.net>
- 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 Thu Apr 4 17:37:28 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 C491337B41C; Thu, 4 Apr 2002 17:36:58 -0800 (PST)
Received: (from stephenm@localhost)
by shell4.bayarea.net (8.9.3/8.9.3) id RAA02010;
Thu, 4 Apr 2002 17:36:51 -0800
(envelope-from stephenm)
Date: Thu, 4 Apr 2002 17:36:51 -0800
From: stephen macmanus <stephenm@bayarea.net>
Message-Id: <200204050136.RAA02010@shell4.bayarea.net>
To: brian@freebsd-services.com, stephenm@bayarea.net
Subject: Re: Your change to in.c to limit duplicate networks is causing trouble
Cc: alan@clegg.com, ambrisko@ambrisko.com, freebsd-arch@FreeBSD.ORG,
freebsd-net@FreeBSD.ORG, imp@village.org, j@uriah.heep.sax.de,
luigi@FreeBSD.ORG, nsayer@FreeBSD.ORG, ryand-bsd@zenspider.com
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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.
>
> Hmm, thanks for the pointer.
>
> I think this now works - where it didn't before (although see
> the new patch posted in response to Joergs mention of the sppp
> problem).
>
> The lack of the EEXIST hack in my patch means that this will work as
> before:
>
> ifconfig dc0 inet 172.16.0.5 netmask 0xffffff00
> ifconfig dc0 inet 172.16.0.11 netmask 0xfffffff8
>
> Where connections to 172.16.0.1-172.16.0.7 and 172.16.0.16-172.16.0.255
> come from 172.16.0.5 and connections to 172.16.0.8-172.16.0.15 come from
> 172.16.0.11.
>
> After the above however,
>
> ifconfig dc0 inet 172.16.0.14 netmask 0xfffffff8
>
> will (correctly) fail in the patched code. It fails because the
> gateway/netmask combination produces a duplicate key in the routing
> table, returning an error from rtinit(). Previously, this failure
> was masked by the EEXIST hack, allowing the interface address update
> without a corresponding host route.
All true. However, this change just redefines the desired behavior
in this situation. The current EEXIST hack prevents a "meaningless"
error message (in the sense that it is still possible to use the
172.16.0.14 address due to the existence of the earlier route).
This patch just restores the original behavior from earlier BSD
versions which reported an error for the reasons you mention.
I guess it's just a judgement call as to which one is more desirable.
> I believe the old behaviour becomes obviously wrong when someone then
> deletes the 172.16.0.11 interface address, blowing away the
> associated host route and leaving no routing table entry to talk to
> the 172.16.0.14 address.
>
> So I don't think the old was was really safe after all :-/
Definitely true. An ideal solution would involve some type of
reference count for the route entry to maintain connectivity
without attempting to add a duplicate route which would always
cause an error.
It would be even easier if users didn't setup redundant addresses
like this one which serve no purpose! ;-) The people who do it,
however, are also the most likely to think the resulting error
indicates an actual problem with the new address assignment.
Stephen
------------------
Stephen Macmanus #include <std_disclaimer.h>
stephenm@bayarea.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 17:43:31 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 1EE3737B41D
for <freebsd-net@FreeBSD.ORG>; Thu, 4 Apr 2002 17:43:20 -0800 (PST)
Received: (from rizzo@localhost)
by iguana.icir.org (8.11.6/8.11.3) id g351hGS11713;
Thu, 4 Apr 2002 17:43:17 -0800 (PST)
(envelope-from rizzo)
Date: Thu, 4 Apr 2002 17:43:16 -0800
From: Luigi Rizzo <rizzo@icir.org>
To: Christophe Prevotaux <c.prevotaux@hexanet.fr>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: IPFW Max Rule Discrete Number Limit
Message-ID: <20020404174316.A11314@iguana.icir.org>
References: <20020403205923.27d35e11.c.prevotaux@hexanet.fr> <20020403111545.A98202@iguana.icir.org> <20020404222556.5ddeb117.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: <20020404222556.5ddeb117.c.prevotaux@hexanet.fr>
User-Agent: Mutt/1.3.23i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Thu, Apr 04, 2002 at 10:25:56PM +0200, Christophe Prevotaux wrote:
> Luigi Rizzo <rizzo@icir.org> wrote:
> > On Wed, Apr 03, 2002 at 08:59:23PM +0200, Christophe Prévotaux wrote:
> > > ...
> > > I have reached the 655 firewalling rules limit (with discrete values)
> > ...
> > you know you can assign explicit numbers to rules ?
> ...
> yes I know , do you seriously think I will do this ?
any serious ipfw usage (especially with the hundreds of rules you
mention) involves skipto rules so you can make
your search paths shorter than having to scan all rules sequentially.
In such a context autonumbering is useless because you need to know
where to jump, and so you want to assign number yourself.
Additionally, you can have multiple rules with the same number,
which is useful e.g. when you have a block of rules which you
want to scan sequentially.
A typical large configuration could be something like this:
# bunch of demux rules
ipfw add 1000 skipto 5000 udp from any to any
ipfw add 1000 skipto 5500 tcp from any to any
ipfw add 1000 skipto 6000 icmp from any to any
# all other traffic
ipfw add 1000 skipto 6500 ip from any to any
# udp specific rules
ipfw add 5000 allow udp from any to any 53,137,138
ipfw add 5000 allow udp from any 53,137,138 to any
ipfw add 5000 deny ip from any to any
# tcp specific rules
ipfw add 5500 deny tcp from any to ${my-net} 23
ipfw add 5500 allow tcp from ${my-proxy} to any
ipfw add 5500 allow tcp from any to ${my-proxy}
ipfw add 5500 deny tcp from any to any 80
...
ipfw add 5500 deny ip from any to any
# icmp rules
ipfw add 6000 pipe 10 icmp from any to any
ipfw add 1000 skipto 11000 ip from ${net2} to any
ipfw add 1000 skipto 11500 ip from any to ${net2}
# ... you get the idea
> What happens when I insert new rules ?
of course you number them manually it if is just single rules, and
if it is dozens of them you insert them in the script that loads
your configuration, and rerun the script.
cheers
luigi
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 19: 9:25 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 5EC9B37B41D; Thu, 4 Apr 2002 19:09:11 -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 g3538xCu002757;
Fri, 5 Apr 2002 04:08:59 +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 g3538sq7044360;
Fri, 5 Apr 2002 04:08:54 +0100 (BST)
(envelope-from brian@freebsd-services.com)
Message-Id: <200204050308.g3538sq7044360@hak.lan.Awfulhak.org>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: stephen macmanus <stephenm@bayarea.net>
Cc: brian@freebsd-services.com, alan@clegg.com,
ambrisko@ambrisko.com, freebsd-arch@FreeBSD.ORG,
freebsd-net@FreeBSD.ORG, imp@village.org, j@uriah.heep.sax.de,
luigi@FreeBSD.ORG, nsayer@FreeBSD.ORG, ryand-bsd@zenspider.com,
brian@freebsd-services.com
Subject: Re: Your change to in.c to limit duplicate networks is causing trouble
In-Reply-To: Message from stephen macmanus <stephenm@bayarea.net>
of "Thu, 04 Apr 2002 17:36:51 -0800." <200204050136.RAA02010@shell4.bayarea.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 05 Apr 2002 04:08:54 +0100
From: Brian Somers <brian@freebsd-services.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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.
> >
> > Hmm, thanks for the pointer.
> >
> > I think this now works - where it didn't before (although see
> > the new patch posted in response to Joergs mention of the sppp
> > problem).
> >
> > The lack of the EEXIST hack in my patch means that this will work as
> > before:
> >
> > ifconfig dc0 inet 172.16.0.5 netmask 0xffffff00
> > ifconfig dc0 inet 172.16.0.11 netmask 0xfffffff8
> >
> > Where connections to 172.16.0.1-172.16.0.7 and 172.16.0.16-172.16.0.255
> > come from 172.16.0.5 and connections to 172.16.0.8-172.16.0.15 come from
> > 172.16.0.11.
> >
> > After the above however,
> >
> > ifconfig dc0 inet 172.16.0.14 netmask 0xfffffff8
> >
> > will (correctly) fail in the patched code. It fails because the
> > gateway/netmask combination produces a duplicate key in the routing
> > table, returning an error from rtinit(). Previously, this failure
> > was masked by the EEXIST hack, allowing the interface address update
> > without a corresponding host route.
>
> All true. However, this change just redefines the desired behavior
> in this situation. The current EEXIST hack prevents a "meaningless"
> error message (in the sense that it is still possible to use the
> 172.16.0.14 address due to the existence of the earlier route).
>
> This patch just restores the original behavior from earlier BSD
> versions which reported an error for the reasons you mention.
>
> I guess it's just a judgement call as to which one is more desirable.
>
> > I believe the old behaviour becomes obviously wrong when someone then
> > deletes the 172.16.0.11 interface address, blowing away the
> > associated host route and leaving no routing table entry to talk to
> > the 172.16.0.14 address.
> >
> > So I don't think the old was was really safe after all :-/
>
> Definitely true. An ideal solution would involve some type of
> reference count for the route entry to maintain connectivity
> without attempting to add a duplicate route which would always
> cause an error.
>
> It would be even easier if users didn't setup redundant addresses
> like this one which serve no purpose! ;-) The people who do it,
> however, are also the most likely to think the resulting error
> indicates an actual problem with the new address assignment.
Well, it does serve a purpose - it allows the machine to accept
tcp connections on the .14 address (although udp requests get nicely
confused) and to bind to the .14 address before connect().
The resulting error *does* indicate that there's a problem with the
new address assignment; adding that .14 address with a conflicting
netmask should be considered wrong (and is treated as an error when
the EEXIST hack is removed). If they want to add another address to
the 172.16/28 subnet, they must use a netmask of 0xffffffff to get
the desired result.
The EEXIST hack is just permitting people to confuse themselves.
> Stephen
>
>
> ------------------
> Stephen Macmanus #include <std_disclaimer.h>
> stephenm@bayarea.net
--
Brian <brian@freebsd-services.com> <brian@Awfulhak.org>
http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.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 22: 7:29 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 86ADD37B420
for <freebsd-net@freebsd.org>; Thu, 4 Apr 2002 22:07:05 -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 g3569mq01067
for <freebsd-net@freebsd.org>; Fri, 5 Apr 2002 16:09:50 +1000 (EST)
(envelope-from robert@quantum-radio.net.au)
Message-ID: <018201c1dc68$76e25b20$1a6001cb@chalmers.com.au>
Reply-To: "Merlin" <robert@quantum-radio.net.au>
From: "Merlin" <robert@quantum-radio.net.au>
To: "freebsd-net" <freebsd-net@freebsd.org>
Subject: IPv6 question - Whaich one is the host and which is the interface ?
Date: Fri, 5 Apr 2002 16:09:17 +1000
Organization: Quantum Radio
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_017F_01C1DCBC.3CCD89B0"
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
This is a multi-part message in MIME format.
------=_NextPart_000_017F_01C1DCBC.3CCD89B0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Little bit confused here.
Hope the formatting in the email isn't screwed up - these things usually =
are. sorry
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.?
Internet6:
Destination Gateway Flags =
Netif Expire
::/96 ::1 UGRSc =
lo0 =3D>
default 2002:c058:6301:: UGSc =
stf0
::1 ::1 UH =
lo0
::ffff:0.0.0.0/96 ::1 UGRSc =
lo0
2002::/24 ::1 UGRSc =
lo0 =3D>
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
Thanks if you can point me in the right direction.
Robert
---
Quantum Radio: World Music with a difference.
http://quantum-radio.net/
Now Playing: Various - Aarti06
------=_NextPart_000_017F_01C1DCBC.3CCD89B0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2715.400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Little bit confused here.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Hope the formatting in the email isn't =
screwed up -=20
these things usually are. sorry</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>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.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>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.?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DCourier=20
size=3D2>Internet6:<BR>Destination &nb=
sp; &nbs=
p; =20
Gateway =
=20
Flags Netif=20
Expire<BR>::/96 &nbs=
p;  =
; =20
::1 &nbs=
p;  =
; =20
UGRSc lo0=20
=3D><BR>default &=
nbsp; &n=
bsp; =20
2002:c058:6301:: &nb=
sp; =20
UGSc =20
stf0<BR>::1 &n=
bsp; &nb=
sp; =20
::1 &nbs=
p;  =
; =20
UH =20
lo0<BR>::ffff:0.0.0.0/96 &=
nbsp; =20
::1 &nbs=
p;  =
; =20
UGRSc =20
lo0<BR>2002::/24 &nb=
sp; &nbs=
p; =20
::1 &nbs=
p;  =
; =20
UGRSc lo0=20
=3D><BR>2002::/16  =
; =
=20
2002:cb01:6005:1::1 =
=20
Uc =20
stf0<BR>2002:7f00::/24 &nb=
sp; =20
::1 &nbs=
p;  =
; =20
UGRSc =20
lo0<BR>2002:cb01:6005::1 &=
nbsp; =20
link#4 &=
nbsp; =20
UHL =20
lo0<BR>2002:cb01:6005:1::1  =
; =20
link#4 &=
nbsp; =20
UHL =20
lo0<BR>2002:e000::/20 &nbs=
p; =20
::1 &nbs=
p;  =
; =20
UGRSc =20
lo0<BR>2002:ff00::/24 &nbs=
p; =20
::1 &nbs=
p;  =
; =20
UGRSc =20
lo0<BR>fe80::/10 &nb=
sp; &nbs=
p; =20
::1 &nbs=
p;  =
; =20
UGRSc =20
lo0<BR>fe80::%rl0/64  =
; =20
link#1 &=
nbsp; =20
UC =20
rl0<BR>fe80::210:b5ff:fee4:4386%rl0 =20
0:10:b5:e4:43:86 &nb=
sp; =20
UHL =20
lo0<BR>fe80::%lo0/64  =
; =20
fe80::1%lo0 &n=
bsp; =20
Uc =20
lo0<BR>fe80::1%lo0 &=
nbsp; &n=
bsp;=20
link#2 &=
nbsp; =20
UHL =20
lo0<BR>fe80::%faith0/64 &n=
bsp; =20
fe80::210:b5ff:fee4:4386%faith0 Uc =20
faith0<BR>fe80::210:b5ff:fee4:4386%faith0 =20
link#3 &=
nbsp; =20
UHL =20
lo0<BR>fe80::%tun0/64 &nbs=
p; =20
fe80::210:b5ff:fee4:4386%tun0 =
Uc =20
tun0<BR>fe80::210:b5ff:fee4:4386%tun0 =20
link#5 &=
nbsp; =20
UHL =20
lo0<BR>ff01::/32 &nb=
sp; &nbs=
p; =20
::1 &nbs=
p;  =
; =20
U =20
lo0<BR>ff02::/16 &nb=
sp; &nbs=
p; =20
::1 &nbs=
p;  =
; =20
UGRS =20
lo0<BR>ff02::%rl0/32  =
; =20
link#1 &=
nbsp; =20
UC =20
rl0<BR>ff02::%lo0/32  =
; =20
::1 &nbs=
p;  =
; =20
UC =20
lo0<BR>ff02::%faith0/32 &n=
bsp; =20
fe80::210:b5ff:fee4:4386%faith0 UC =20
faith0<BR>ff02::%tun0/32 &=
nbsp; =20
fe80::210:b5ff:fee4:4386%tun0 =
UC =20
tun0<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT> </DIV>
<DIV><FONT face=3DCourier size=3D2><FONT =
face=3DArial></FONT></FONT> </DIV>
<DIV><FONT face=3DCourier size=3D2><FONT face=3DArial>Thanks if you can=20
po</FONT></FONT><FONT face=3DCourier size=3D2><FONT face=3DArial>int me =
in the right=20
direction.</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Robert</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2><FONT =
face=3DArial></FONT> </DIV></FONT>
<DIV><FONT face=3DArial size=3D2>---<BR>Quantum Radio: World Music with =
a=20
difference.<BR></FONT><A href=3D"http://quantum-radio.net/"><FONT =
face=3DArial=20
size=3D2>http://quantum-radio.net/</FONT></A><BR><FONT face=3DArial =
size=3D2>Now=20
Playing: Various - Aarti06</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV></BODY></HTML>
------=_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 <freebsd-net@FreeBSD.ORG>; 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: <y7vk7rmptd3.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
To: "Merlin" <robert@quantum-radio.net.au>
Cc: "freebsd-net" <freebsd-net@FreeBSD.ORG>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
>>>>> On Fri, 5 Apr 2002 16:09:17 +1000,
>>>>> "Merlin" <robert@quantum-radio.net.au> 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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" <robert@quantum-radio.net.au>
From: "Merlin" <robert@quantum-radio.net.au>
To: "freebsd-net" <freebsd-net@freebsd.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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: <y7vhemqpoxx.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
To: "Merlin" <robert@quantum-radio.net.au>
Cc: "freebsd-net" <freebsd-net@FreeBSD.ORG>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
>>>>> On Fri, 5 Apr 2002 16:44:20 +1000,
>>>>> "Merlin" <robert@quantum-radio.net.au> 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 <freebsd-net@FreeBSD.ORG>; 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 <freebsd-net@FreeBSD.ORG>; 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" <robert@quantum-radio.net.au>
From: "Merlin" <robert@quantum-radio.net.au>
To: "freebsd-net" <freebsd-net@FreeBSD.ORG>
References: <01fe01c1dc6d$55248fd0$1a6001cb@chalmers.com.au> <y7vhemqpoxx.wl@ocean.jinmei.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> 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<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff000000
faith0: flags=8043<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::210:b5ff:fee4:4386%faith0 prefixlen 64 scopeid 0x3
stf0: flags=1<UP> mtu 1280
inet6 2002:cb01:6005:1::1 prefixlen 16
inet6 2002:cb01:6005::1 prefixlen 16
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> 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 <freebsd-net@FreeBSD.ORG>; 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 <sakane@kame.net>
X-Dispatcher: imput version 20000228(IM140)
Lines: 59
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <sakane@kame.net>
X-Dispatcher: imput version 20000228(IM140)
Lines: 13
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <itojun@iijlab.net>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.org>; 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 <freebsd-net@FreeBSD.org>;
Fri, 5 Apr 2002 17:15:25 +0200 (MET DST)
Message-ID: <000a01c1dcb4$b63bc940$c2d5ed82@kurt>
From: "Ke Chen" <iw01_cke@it.kth.se>
To: <freebsd-net@FreeBSD.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> I have some problems about =
gif =20
interface.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> Could gif interface be =
bridged=20
together with Ethernet interface?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2> I have one machines with 2 =
Ethernet=20
card, one is fxp0, the other is fxp1</FONT><FONT face=3DArial=20
size=3D2> </FONT></DIV>
<DIV><FONT face=3DArial size=3D2> I create a gif interface by =
using=20
ifconfig gif0 create</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> then I add this =
configuration to=20
/etc/sysctl.conf</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
net.link.ether.bridge=3D1</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =20
net.link.ether.bridge_cfg=3Dfxp0:0,gif0:0,fxp1:1</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2> 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.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2> 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?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> thank you very =
much.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>best regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>kurt</FONT></DIV></BODY></HTML>
------=_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 <freebsd-net@FreeBSD.ORG>; 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: <y7velhup1z0.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
To: "Merlin" <robert@quantum-radio.net.au>
Cc: "freebsd-net" <freebsd-net@FreeBSD.ORG>
Subject: Re: to JINMEI, Tatuya. Rephrased last question
In-Reply-To: <021301c1dc79$7d236630$1a6001cb@chalmers.com.au>
References: <01fe01c1dc6d$55248fd0$1a6001cb@chalmers.com.au>
<y7vhemqpoxx.wl@ocean.jinmei.org>
<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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
>>>>> On Fri, 5 Apr 2002 18:11:28 +1000,
>>>>> "Merlin" <robert@quantum-radio.net.au> 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<UP> 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 <freebsd-net@FreeBSD.ORG>; 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" <sam@errno.com>
To: "Shoichi Sakane" <sakane@kame.net>
Cc: <freebsd-net@FreeBSD.ORG>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
----- Original Message -----
From: "Shoichi Sakane" <sakane@kame.net>
To: <sam@errno.com>
Cc: <freebsd-net@FreeBSD.ORG>
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 <freebsd-net@FreeBSD.org>; 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 <larse@ISI.EDU>
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 <iw01_cke@it.kth.se>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <larse@isi.edu> 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 <freebsd-net@FreeBSD.ORG>; 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <brooks@one-eyed-alien.net>
To: Ke Chen <iw01_cke@it.kth.se>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.org>; 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 <julian@elischer.org>
To: Lars Eggert <larse@ISI.EDU>
Cc: Ke Chen <iw01_cke@it.kth.se>, freebsd-net@FreeBSD.org
Subject: Re: about gif interface!
In-Reply-To: <3CADC7C4.6030609@isi.edu>
Message-ID: <Pine.BSF.4.21.0204051126230.37186-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <larse@isi.edu> 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 <freebsd-net@FreeBSD.org>; 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" <iw01_cke@it.kth.se>
To: "Julian Elischer" <julian@elischer.org>,
"Lars Eggert" <larse@ISI.EDU>,
"Brooks Davis" <brooks@one-eyed-alien.net>
Cc: <freebsd-net@FreeBSD.org>
References: <Pine.BSF.4.21.0204051126230.37186-100000@InterJet.elischer.org>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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" <julian@elischer.org>
To: "Lars Eggert" <larse@ISI.EDU>
Cc: "Ke Chen" <iw01_cke@it.kth.se>; <freebsd-net@FreeBSD.org>
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 <larse@isi.edu> 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 <freebsd-net@FreeBSD.org>; 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 <julian@elischer.org>
To: Ke Chen <iw01_cke@it.kth.se>
Cc: Lars Eggert <larse@ISI.EDU>,
Brooks Davis <brooks@one-eyed-alien.net>, freebsd-net@FreeBSD.org
Subject: Re: about gif interface!
In-Reply-To: <002a01c1dcdd$bfd36570$c2d5ed82@kurt>
Message-ID: <Pine.BSF.4.21.0204051225120.37543-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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" <julian@elischer.org>
> To: "Lars Eggert" <larse@ISI.EDU>
> Cc: "Ke Chen" <iw01_cke@it.kth.se>; <freebsd-net@FreeBSD.org>
> 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 <larse@isi.edu> 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 <gallatin@cs.duke.edu>
Cc: Terry Lambert <tlambert2@mindspring.com>, 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 <gallatin@cs.duke.edu>
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^@n5<Pi&akO)o^8;[r
%l(8ZHlbF`dD>v4: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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <fenner@research.att.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <rousskov@measurement-factory.com>
To: freebsd-net@FreeBSD.ORG
Subject: Forcing packets to the wire
Message-ID: <Pine.BSF.4.10.10204051543440.54230-100000@measurement-factory.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <fenner@research.att.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <fenner@research.att.com>
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 <fenner@research.att.com>
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^@n5<Pi&akO)o^8;[r
%l(8ZHlbF`dD>v4: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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bill Fenner <fenner@research.att.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <nick@rogness.net>
X-Sender: nick@cody.jharris.com
To: Alex Rousskov <rousskov@measurement-factory.com>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: Forcing packets to the wire
In-Reply-To: <Pine.BSF.4.10.10204051543440.54230-100000@measurement-factory.com>
Message-ID: <Pine.BSF.4.21.0204051826180.95757-100000@cody.jharris.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <nick@rogness.net>
- 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 <freebsd-net@FreeBSD.ORG>; 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" <fullermd@over-yonder.net>
To: Nick Rogness <nick@rogness.net>
Cc: Alex Rousskov <rousskov@measurement-factory.com>,
freebsd-net@FreeBSD.ORG
Subject: Re: Forcing packets to the wire
Message-ID: <20020405222555.C65380@over-yonder.net>
References: <Pine.BSF.4.10.10204051543440.54230-100000@measurement-factory.com> <Pine.BSF.4.21.0204051826180.95757-100000@cody.jharris.com>
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: <Pine.BSF.4.21.0204051826180.95757-100000@cody.jharris.com>; from nick@rogness.net on Fri, Apr 05, 2002 at 06:48:09PM -0600
X-Editor: vi
X-OS: FreeBSD <http://www.freebsd.org>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <net@freebsd.org>; 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 <brooks@one-eyed-alien.net>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <sys/param.h>
#include <sys/systm.h>
#include <sys/kernel.h>
+#include <sys/malloc.h>
#include <sys/module.h>
#include <sys/mbuf.h>
#include <sys/socket.h>
@@ -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 <freebsd-net@freebsd.org>; 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 <bvi@itouchlabs.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <rizzo@icir.org>
To: Barry Irwin <bvi@itouchlabs.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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" <sethh@principia.edu>
From: "Seth Hieronymus" <sethh@principia.edu>
To: <freebsd-net@freebsd.org>
Cc: <tlambert2@mindspring.com>
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: <OE84ixqDCZx4FR0rmTI00007405@hotmail.com>
X-OriginalArrivalTime: 06 Apr 2002 08:52:16.0492 (UTC) FILETIME=[5A44B2C0:01C1DD48]
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <andreas@klemm.gtn.com>
To: freebsd-net@freebsd.org
Cc: Luigi Rizzo <luigi@iet.unipi.it>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <andreas@klemm.gtn.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@freebsd.org>; 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 <luigi@iet.unipi.it>
To: Andreas Klemm <andreas@klemm.gtn.com>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <nick@rogness.net>
X-Sender: nick@cody.jharris.com
To: "Matthew D. Fuller" <fullermd@over-yonder.net>
Cc: Alex Rousskov <rousskov@measurement-factory.com>,
freebsd-net@FreeBSD.ORG
Subject: Re: Forcing packets to the wire
In-Reply-To: <20020405222555.C65380@over-yonder.net>
Message-ID: <Pine.BSF.4.21.0204061322160.12246-100000@cody.jharris.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <nick@rogness.net>
- 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 <freebsd-net@FreeBSD.ORG>; 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 <barney@databus.com>
To: Nick Rogness <nick@rogness.net>
Cc: "Matthew D. Fuller" <fullermd@over-yonder.net>,
Alex Rousskov <rousskov@measurement-factory.com>,
freebsd-net@FreeBSD.ORG
Subject: Re: Forcing packets to the wire
Message-ID: <20020406154403.A9364@tp.databus.com>
References: <20020405222555.C65380@over-yonder.net> <Pine.BSF.4.21.0204061322160.12246-100000@cody.jharris.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.BSF.4.21.0204061322160.12246-100000@cody.jharris.com>; from nick@rogness.net on Sat, Apr 06, 2002 at 01:57:44PM -0600
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <thierry@herbelot.com>
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Barney Wolff <barney@databus.com>
Cc: Nick Rogness <nick@rogness.net>,
"Matthew D. Fuller" <fullermd@over-yonder.net>,
Alex Rousskov <rousskov@measurement-factory.com>,
freebsd-net@FreeBSD.ORG
Subject: Re: Forcing packets to the wire
References: <20020405222555.C65380@over-yonder.net> <Pine.BSF.4.21.0204061322160.12246-100000@cody.jharris.com> <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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <julian@elischer.org>
To: Nick Rogness <nick@rogness.net>
Cc: "Matthew D. Fuller" <fullermd@over-yonder.net>,
Alex Rousskov <rousskov@measurement-factory.com>,
freebsd-net@FreeBSD.ORG
Subject: Re: Forcing packets to the wire
In-Reply-To: <Pine.BSF.4.21.0204061322160.12246-100000@cody.jharris.com>
Message-ID: <Pine.BSF.4.21.0204061623001.43363-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <net@freebsd.org>; 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 <julian@elischer.org>
To: Brooks Davis <brooks@one-eyed-alien.net>
Cc: net@freebsd.org
Subject: Re: review request: minor cloning API change
In-Reply-To: <20020405230719.A13516@Odin.AC.HMC.Edu>
Message-ID: <Pine.BSF.4.21.0204061639400.43363-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <sys/param.h>
> #include <sys/systm.h>
> #include <sys/kernel.h>
> +#include <sys/malloc.h>
> #include <sys/module.h>
> #include <sys/mbuf.h>
> #include <sys/socket.h>
> @@ -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 <net@FreeBSD.ORG>; 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 <brooks@one-eyed-alien.net>
To: Julian Elischer <julian@elischer.org>
Cc: Brooks Davis <brooks@one-eyed-alien.net>, 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> <Pine.BSF.4.21.0204061639400.43363-100000@InterJet.elischer.org>
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: <Pine.BSF.4.21.0204061639400.43363-100000@InterJet.elischer.org>; from julian@elischer.org on Sat, Apr 06, 2002 at 04:44:32PM -0800
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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 <rousskov@measurement-factory.com>
To: Nick Rogness <nick@rogness.net>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: Forcing packets to the wire
In-Reply-To: <Pine.BSF.4.21.0204061322160.12246-100000@cody.jharris.com>
Message-ID: <Pine.BSF.4.10.10204061919440.91712-100000@measurement-factory.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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" <cjc@FreeBSD.ORG>
To: Luigi Rizzo <luigi@iet.unipi.it>
Cc: Andreas Klemm <andreas@klemm.gtn.com>, 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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" <cjc@FreeBSD.ORG>
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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <freebsd-net@FreeBSD.ORG>; 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" <cjc@FreeBSD.ORG>
To: Nick Rogness <nick@rogness.net>
Cc: "Matthew D. Fuller" <fullermd@over-yonder.net>,
Alex Rousskov <rousskov@measurement-factory.com>,
freebsd-net@FreeBSD.ORG
Subject: Re: Forcing packets to the wire
Message-ID: <20020406212822.G70207@blossom.cjclark.org>
References: <20020405222555.C65380@over-yonder.net> <Pine.BSF.4.21.0204061322160.12246-100000@cody.jharris.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.BSF.4.21.0204061322160.12246-100000@cody.jharris.com>; 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: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
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 <external gateway> ip from <ip_if0> to <ip_if1> 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