FreeBSD 3.2 + KAME STABLE 19990809

george+6bone@m5p.com george+6bone@m5p.com
Mon, 9 Aug 1999 22:31:18 -0700 (PDT)


>From shin@nd.net.fujitsu.co.jp  Mon Aug  9 18:43:09 1999
Return-Path: <shin@nd.net.fujitsu.co.jp>
Received: from fgwmail3.fujitsu.co.jp (fgwmail3.fujitsu.co.jp [192.51.44.33])
	by southstation.m5p.com (8.9.3/8.9.3) with ESMTP id SAA35364
	for <george+6bone@m5p.com>; Mon, 9 Aug 1999 18:43:08 -0700 (PDT)
Received: from fdmnews.fujitsu.co.jp by fgwmail3.fujitsu.co.jp (8.9.3/3.7W-MX9904-Fujitsu Gateway)
	id KAA11566; Tue, 10 Aug 1999 10:43:00 +0900 (JST)
Received: from chisato.nd.net.fujitsu.co.jp by fdmnews.fujitsu.co.jp (8.9.3/3.7W-9907-Fujitsu Domain Master)
	id KAA24276; Tue, 10 Aug 1999 10:42:58 +0900 (JST)
Received: from localhost (dhcp7186.nd.net.fujitsu.co.jp [10.18.7.186]) by chisato.nd.net.fujitsu.co.jp (8.6.12+2.4W/3.3W8chisato-970826) with ESMTP id KAA00138; Tue, 10 Aug 1999 10:42:58 +0900
To: george+6bone@m5p.com
Cc: 6bone@ISI.EDU
Subject: Re: FreeBSD 3.2 + KAME SNAP 02 August 1999
In-Reply-To: <199908100040.RAA21209@southstation.m5p.com>
References: <199908100040.RAA21209@southstation.m5p.com>
X-Mailer: Mew version 1.94b5 on XEmacs 20.4 (Emerald)
X-Prom-Mew: Prom-Mew 1.93 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19990810104246T.shin@nd.net.fujitsu.co.jp>
Date: Tue, 10 Aug 1999 10:42:46 +0900
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
X-Dispatcher: imput version 990212(IM106)
Lines: 38
Status: R

I wrote:

>> I'm running FreeBSD version 3.2, and I've installed the KAME SNAP
>> patches from 02 August 1999.

Yoshinobu Inoue wrote:

> KAME/FreeBSD32 for 02 August 1999 version has a bug in icmp6
> error message handling. Which may let system panic, or cause
> unpredictable problem.

> There are patches for that. Please apply it at first (or use 09
> August version), if not yet applied.

I got KAME stable release for FreeBSD 3.2 earlier this evening and
rebuilt.  There was no change in behavior.


Itojun wrote:

>	Could you give us the configuration diagram of your setup?
>	Notice that KAME does not have 6over4 code yet, so configuration
>	that throws 6over4 packet toward KAME box does not work.
>	(see kit/IMPLEMENTATION for supported/unsupported items)

kit/IMPLEMENTATION section 1.5 says:

1.5 Generic tunnel interface

GIF (Generic InterFace) is a pseudo interface for configured tunnel.
Details are described in gif(4) manpage.
Currently
	v6 in v6
	v6 in v4
	v4 in v6
	v4 in v4
are available.  Use "gifconfig" to assign physical (outer) source
and destination address to gif interfaces.

Here is my configuration:
Ethernet interface ed0 connects to local network running unencapsulated
IPv6.  It seems to work, to the limited extent that I've tested it.

Ethernet interface xl0 (3Com 3C905) connects only to Cisco 675 ADSL
router-bridge in bridge mode to DSL ISP, running IPv4 only.  I have
an IPv6-in-IPv4 tunnel to NWNET.

ifconfig xl0:

xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	inet6 fe80:1::210:5aff:fea9:3338 prefixlen 64 
	inet 209.162.215.52 netmask 0xffffff00 broadcast 209.162.215.255
	inet6 3ffe:a00:0:160:210:5aff:fea9:3338 prefixlen 64 
	inet6 3ffe:a00:0:160:: prefixlen 64 anycast 
	ether 00:10:5a:a9:33:38 
	media: 100baseTX <full-duplex>

gifconfig gif0:

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
	inet6 fe80:4::210:5aff:fea9:3338  prefixlen 64 
	inet6 3ffe:a00:2:2::1e --> 3ffe:a00:2:2::1d  prefixlen 126 
	physical address inet 209.162.215.52 --> 192.220.249.249

When I "ping6 3ffe:a00:2:2::1d", instead of getting replies, I get the
following messages from the kernel:

icmp6_input: unknown type 0
icmp6_input: unknown type 0
icmp6_input: unknown type 0
icmp6_input: unknown type 0
icmp6_input: unknown type 0
icmp6_input: unknown type 0
icmp6_input: unknown type 0
icmp6_input: unknown type 0
icmp6_input: unknown type 0
icmp6_input: unknown type 0
icmp6_input: unknown type 50
icmp6_input: unknown type 32

Meanwhile, tcpdump host 192.220.249.249 says:

tcpdump: listening on xl0
22:26:45.124259 southstation.m5p.com > lo0.nwnet-6bone-gw.nw.verio.net: 3ffe:a00:2:2::1e > 3ffe:a00:2:2::1d: icmp6: echo request (encap)
22:26:45.159733 lo0.nwnet-6bone-gw.nw.verio.net > southstation.m5p.com: 3ffe:a00:2:2::1d > 3ffe:a00:2:2::1e: icmp6: echo reply (encap)
22:26:46.124120 southstation.m5p.com > lo0.nwnet-6bone-gw.nw.verio.net: 3ffe:a00:2:2::1e > 3ffe:a00:2:2::1d: icmp6: echo request (encap)
22:26:46.158128 lo0.nwnet-6bone-gw.nw.verio.net > southstation.m5p.com: 3ffe:a00:2:2::1d > 3ffe:a00:2:2::1e: icmp6: echo reply (encap)
22:26:47.114115 southstation.m5p.com > lo0.nwnet-6bone-gw.nw.verio.net: 3ffe:a00:2:2::1e > 3ffe:a00:2:2::1d: icmp6: echo request (encap)
22:26:47.147930 lo0.nwnet-6bone-gw.nw.verio.net > southstation.m5p.com: 3ffe:a00:2:2::1d > 3ffe:a00:2:2::1e: icmp6: echo reply (encap)
22:26:48.114148 southstation.m5p.com > lo0.nwnet-6bone-gw.nw.verio.net: 3ffe:a00:2:2::1e > 3ffe:a00:2:2::1d: icmp6: echo request (encap)
22:26:48.150301 lo0.nwnet-6bone-gw.nw.verio.net > southstation.m5p.com: 3ffe:a00:2:2::1d > 3ffe:a00:2:2::1e: icmp6: echo reply (encap)
22:26:49.114149 southstation.m5p.com > lo0.nwnet-6bone-gw.nw.verio.net: 3ffe:a00:2:2::1e > 3ffe:a00:2:2::1d: icmp6: echo request (encap)
22:26:49.146042 lo0.nwnet-6bone-gw.nw.verio.net > southstation.m5p.com: 3ffe:a00:2:2::1d > 3ffe:a00:2:2::1e: icmp6: echo reply (encap)
22:26:50.114158 southstation.m5p.com > lo0.nwnet-6bone-gw.nw.verio.net: 3ffe:a00:2:2::1e > 3ffe:a00:2:2::1d: icmp6: echo request (encap)
22:26:50.148386 lo0.nwnet-6bone-gw.nw.verio.net > southstation.m5p.com: 3ffe:a00:2:2::1d > 3ffe:a00:2:2::1e: icmp6: echo reply (encap)
22:26:51.114172 southstation.m5p.com > lo0.nwnet-6bone-gw.nw.verio.net: 3ffe:a00:2:2::1e > 3ffe:a00:2:2::1d: icmp6: echo request (encap)
22:26:51.149426 lo0.nwnet-6bone-gw.nw.verio.net > southstation.m5p.com: 3ffe:a00:2:2::1d > 3ffe:a00:2:2::1e: icmp6: echo reply (encap)

What this says to me is that the tunnel is up, ping6 can send packets
through it to NWNET, NWNET is responding to the packets, the replies
are arriving at the xl0 interface, but then they're getting lost in
the stack.  Help!

-- George Mitchell (george+6bone@m5p.com)