Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Dec 1999 19:53:41 +0100
From:      Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>
To:        Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
Cc:        freebsd-arch@freebsd.org, cvs-committers@freebsd.org
Subject:   Re: [Solicite review for KAME 3rd patch]
Message-ID:  <19991206195341.B11220@daemon.ninth-circle.org>
In-Reply-To: <19991206210212K.shin@nd.net.fujitsu.co.jp>; from shin@nd.net.fujitsu.co.jp on Mon, Dec 06, 1999 at 09:02:12PM %2B0900
References:  <19991203050711F.shin@nd.net.fujitsu.co.jp> <19991204154807.G711@daemon.ninth-circle.org> <19991206210212K.shin@nd.net.fujitsu.co.jp>

next in thread | previous in thread | raw e-mail | index | archive | help
-On [19991206 16:00], Yoshinobu Inoue (shin@nd.net.fujitsu.co.jp) wrote:
>Thanks for your detailed comments.

You are quite welcome.  It is in my own interest to do so.

>> All patches succeeded on a fresh CURRENT source tree except for:
>> 
>> - sbin/ifconfig/Makefile
>> - sbin/route/Makefile
>> - usr.bin/netstat/Makefile
>> 
>> no .rej file was made curiously enough.  Patched by hand.
>
>Was your fix uncommenting
>
>#CFLAGS+=-DINET6

No, as Peter Wemm was kind enough to explain to me, I forgot to use -p
and -I flags.

>Then, I intentionally commented them out by default, because
>INET6 kernel config option is also not enabled by default.

Well, a make world shouldn't be dying from lack of specifying INET6.  I
wonder how to best tackle this problem.  I mean, we want IPv6 support to
be there when we want it, and not there when we don't.  Ideas of how to
solve this small kludge are welcome.

>> sys/conf/files:
>> 
>> I like the rearranging of the netinet options, it certainly clarifies
>> things.
>
>Thanks, though I'm a little bit uncertain where is the best
>place ipfilter related files should be put in.

Please ask Guido van Rooij <guido@freebsd.org> about this.

>> COMPATIBILITY OPTIONS seems to be a whitespace fix.  Not needed IMHO.
>(and all comments about whitespaces)
>
>I exec'ed some script which do removing whitespaces and tabs at the end
>of each line and etc for all files I touched, in case I mistakenly put
>them.

Heh, don't do that. =)

>But, 
>
>> My suggestion: checkout a new source tree and only modify that what you want to
>> change and ignore tab line-ups and concentrate on the functionality.  White
>> space corrections are best done in cosmestic commits.
>
>I agree, I'll take care of whitespaces later.

Thanks.

>> The `faith` pseudo-device catches those packets which sent to it, and
>> forwards then to IPv4 and IPv6 translating daemon.
>> 
>> Should this be:
>> 
>> The `faith' pseudo-device captures packets sent to it and forwards them
>> to the IPv4/IPv6 translation daemon.
>
>Thanks, I use it.

Only if what I said is what it really does of course.  Looking through
the sources I think my description matches or at least comes close.
(Which is of course based on your description.)

>> Although I wonder if forwards could be changed to divert.
>
>Is the word "divert" more natural?
>Then I change the description.

Well, that's what I am wondering about.  Divert is something which is
also used a lot in NAT related set-ups in which all specified traffic
gets send to a specific port or host.  In this case to a daemon.  So I
think divert might be better use to remain consistent with the rest of
the terminology.  But of course I am open to suggestions from long term
veterans such as Mr Wollman.

>> Does faith replace loop?  If so, what is against adding the IPv6
>> functionality to loop?
>
>Its if_type IFT_FAITH is also important.

Aha, so we have loop and faith, which both provide the same
functionality.  Is the functionality _EXACT_ the same and does it differ
only in terms of IPv6 support or does it differ even more aside from
that.  That wasn't too clear to me.

>Packets catched by faith is put into ip6 input queue and
>processed by ip6_input() again.
>But this 2nd time input, it matches this check, and treated as
>'ours'.

Aha, so the true difference is the reprocessing of previously matched
packets?

>But just one point,
>I think this patch should be left, shouldn't it?
>
>-#if defined(INET) || defined(NS) || defined(DECNET) || defined(IPX) || defined(NETATALK)
>+#if defined(INET) || defined(INET6) || defined(NS) || defined(DECNET) || defined(IPX) || defined(NETATALK)

Oh sorry.  A mistake on my part. =)
Aye, that was meant to stay there.  Too much dd'ing of whitespace
changes.

>> Hope this helps,
>
>Thanks very much again.

You are welcome.

>When I cvs updated my environments I'll soon prepare new diff.
>(But freefall seems to be heavy now.)

It was having severe disk problems.  I think Peter Wemm solved them all
this afternoon.
(If anyone has disks to spare, feel free to let the project know =) )

Inoue-san, feel free to mail me when your new patches are done as I am
very eager to help getting KAME intergrated as fast as possible without
too many hick-ups.

Kind regards,

-- 
Jeroen Ruigrok van der Werven/Asmodai           asmodai@[wxs.nl|bart.nl]
Documentation nutter.          *BSD: Technical excellence at its best...  
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>;
Atone me to my throes curtail...




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991206195341.B11220>