From owner-freebsd-net  Tue May  1  9:27: 1 2001
Delivered-To: freebsd-net@freebsd.org
Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97])
	by hub.freebsd.org (Postfix) with ESMTP id D5EF537B422
	for <freebsd-net@freebsd.org>; Tue,  1 May 2001 09:26:57 -0700 (PDT)
	(envelope-from itojun@itojun.org)
Received: from itojun.org (localhost [127.0.0.1])
	by coconut.itojun.org (Postfix) with ESMTP
	id 47C304B0B; Wed,  2 May 2001 01:26:54 +0900 (JST)
To: Gunther Schadow <gunther@aurora.regenstrief.org>
Cc: snap-users@kame.net, Shoichi Sakane <sakane@ydc.co.jp>,
	freebsd-net@freebsd.org
In-reply-to: gunther's message of Tue, 01 May 2001 16:13:01 GMT.
      <3AEEE08D.DBF7BD5C@aurora.regenstrief.org> 
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: (KAME-snap 4571) Re: KAME SPD bug, please try and confirm ... 
From: itojun@iijlab.net
Date: Wed, 02 May 2001 01:26:54 +0900
Message-ID: <1482.988734414@itojun.org>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

>>         my guess is that you have some issue with routing setup.
>>         last time, you had some wacky static routes to help source address
>>         selection (i do not really recommend that).  do you still have them?
>>         if so, please show them to us (to mailing list) with in the script.
>No, I don't think so. My routing tables are just fine, I see 
>with tcpdump how packets are exchanged as they should and I 
>see them come in the receiving interface and I see them being 
>dropped an counted under "unknown/unsupported protocol." So, 
>how can you conclude that it's my routing tables? How should
>my routing tables be different?

	sorry if you felt offended.  i really think it is issue in routing
	table, as multiple SPD configuration works just fine here.

	the "unknown/unsupported protocol" error can be increased by multiple
	reasons, including decryption resulted into garbage.  so it can mean
	almost nothing.  it can be because of different key setups in SAD,
	or whatever.

	even if you don't think related, we need your exact configuration
	to repeat, or emulate your setup.  i have tested a configuration
	that should emulate your setup, but it worked.  so i guess we need
	to emulate whatever you have configured, put some debugging printfs,
	to chase what is going on in the kernel.  of course we need to
	get some equipments to do that, and it takes time.
	i understand your frustration, really feeling sorry about it.

	ipset setup is really a f*cking complex beast, because of the
	specification itself, and because of the interaction of
	multiple other network components.  we need to know everything
	about your setup to repeat the symptom.  also, there are a lot of
	wacky interaction in FreeBSD IPv4 code path, which makes it really hard
	to track the problem down.  if you have any other setups including NAT,
	divert socket, packet filtering (ipf/ipfilter), routing, ifconfig,
	special servers, bridging, whatever, please show them to us.
	otherwise we can never repeat that setup.

	even if you know that "additional SPD entry tickles some problem"
	in your environment, that may not be the real reason.
	i believe this is not the real reason, as multiple SPD entry works
	fine here (and other places).  so i'm trying to understand what
	differentiates your setup and my setup.

	so, please send us every configuration you have.  preferably
	not the meta-script like "${ipaddr-c}".  we need what you have
	configured exactly.

itojun

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