From: Kazunori MIYAZAWA <kazunori@miyazawa.org>
To: David Miller <davem@davemloft.net>
Cc: miika@iki.fi, Diego.Beltrami@hiit.fi,
herbert@gondor.apana.org.au, netdev@vger.kernel.org,
usagi-core@linux-ipv6.org
Subject: Re: [PATCH][IPSEC][6/7] inter address family ipsec tunnel
Date: Fri, 01 Dec 2006 14:07:04 +0900 [thread overview]
Message-ID: <456FB878.4080109@miyazawa.org> (raw)
In-Reply-To: <20061130.170503.35356518.davem@davemloft.net>
David Miller wrote:
> From: Kazunori MIYAZAWA <kazunori@miyazawa.org>
> Date: Fri, 24 Nov 2006 14:39:01 +0900
>
>> This patch fixes mtu calculation of IPv4
>>
>> ip_append_data should refer the mtu of "dst" not "path".
>> if "dst" is stacked, "path" is the actual dst_entry in
>> the routing table.
>> therefore the mtu of "path" equals link mtu which is
>> depends on the device so that it ignores the header length
>> and the trailer length
>> "dst" has mtu for creating packet.
>>
>> Signed-off-by: Miika Komu <miika@iki.fi>
>> Signed-off-by: Diego Beltrami <Diego.Beltrami@hiit.fi>
>> Signed-off-by: Kazunori Miyazawa <miyazawa@linux-ipv6.org>
>
> I'm not sure about this change.
>
> If you look at the code in this function, "mtu" is always used with
> adjustments via 'exthdrlen' (which is set to rt->u.dst.header_len).
> So it seems the encapsulation is taken into account.
>
Oh, sorry. I misread the code.
I tested with IPv4 over IPv4 IPsec tunnel. The original code works.
Sorry this patch was wrong. Please throw away [6/7] and [7/7].
> Perhaps any problem you are seeing is some artifact of the ipv6 in
> ipv4 tunnel implementation. Otherwise we'd have other reports of this
> problem, wouldn't we?
The easy test is that you create IPv6 over IPv6 IPsec tunnel between 2
hosts, the tunnel is terminated by themselves, and send icmp echo
packets which are longer than the mtu such as 2000. Then it seems
that the kernel returns too big messages to ping6.
I guess mtu calculation and/or building packets of IPv6 has some problem
If you use another host (SGW) to encapsulate the packets,
I think it succeeds because SGW returns a too big message and the
packet sending host learns and fragments properly.
I had same situation like IPv6 over IPv6 IPsec self tunneling
under IPv6 over IPv4 IPsec tunneling test.
I'm going to trace the problem.
Thank you.
--
Kazunori Miyazawa
next prev parent reply other threads:[~2006-12-01 5:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-24 5:39 [PATCH][IPSEC][6/7] inter address family ipsec tunnel Kazunori MIYAZAWA
2006-12-01 1:05 ` David Miller
2006-12-01 5:07 ` Kazunori MIYAZAWA [this message]
2006-12-04 1:58 ` David Miller
2006-12-04 2:28 ` David Miller
2006-12-04 2:50 ` Kazunori MIYAZAWA
2006-12-04 3:12 ` David Miller
2006-12-04 3:30 ` Herbert Xu
2006-12-04 4:26 ` (usagi-core 31727) " Kazunori MIYAZAWA
2006-12-04 6:33 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=456FB878.4080109@miyazawa.org \
--to=kazunori@miyazawa.org \
--cc=Diego.Beltrami@hiit.fi \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=miika@iki.fi \
--cc=netdev@vger.kernel.org \
--cc=usagi-core@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).