From: Gao feng <gaofeng@cn•fujitsu.com>
To: Steffen Klassert <steffen.klassert@secunet•com>
Cc: netdev@vger•kernel.org, davem@davemloft•net, lw@cn•fujitsu.com
Subject: Re: [PATCH] ipv6: fix incorrect ipsec transport mode fragment
Date: Sat, 26 May 2012 19:29:07 +0800 [thread overview]
Message-ID: <4FC0BE83.8090607@cn.fujitsu.com> (raw)
In-Reply-To: <4FC09B9A.6090806@cn.fujitsu.com>
于 2012年05月26日 17:00, Gao feng 写道:
> Hi Steffen
>
> 于 2012年05月14日 21:05, Steffen Klassert 写道:
>> On Mon, May 14, 2012 at 11:21:00AM +0800, Gao feng wrote:
>>> Since commit 299b0767(ipv6: Fix IPsec slowpath fragmentation problem)
>>> the fragment of ipsec transport mode packets is incorrect.
>>> because tunnel mode needs IPsec headers and trailer for all fragments,
>>> while on transport mode it is sufficient to add the headers to the
>>> first fragment and the trailer to the last.
>>
>> I mentioned this in an other thread some time ago,
>> this is due to commit ad0081e43a
>> "ipv6: Fragment locally generated tunnel-mode IPSec6 packets as needed"
>> changed tunnel mode to do fragmentation before the transformation
>> while transport mode still does fragmentation after transformation.
>> Now, tunnel mode needs IPsec headers and trailer for all fragments,
>> while on transport mode it is sufficient to add the headers to the
>> first fragment and the trailer to the last.
>>
>>>
>>> so modify mtu and maxfraglen base on ipsec mode and if fragment is first
>>> or last.
>>
>> There might be other opinions, but I don't like to see this IPsec mode
>> dependent stuff hacked into the generic ipv6 output path.
>>
>> Basically we have two cases. One where we have to add rt->dst.header_len
>> to the first fragment and rt->dst.trailer_len to the last fragment,
>> and the other where we have to add both to all fragments. So perhaps we
>> could isolate this code and create two functions, one for each case.
>>
>>
>
> I thought this problem carefully,I think the important and troubled thing is
> how to deal with transport mode.
>
> we have to use different mtu and maxfraglen for checking if the prev_skb has
> extra data or has free room. so mtu_prev and maxfraglen_prev have to be used.
>
I found we can delete the mtu_prev and maxfraglen prev ;)
next prev parent reply other threads:[~2012-05-26 11:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-13 8:10 Question with commit 299b0767(ipv6: Fix IPsec slowpath fragmentation problem) Li Wei
2012-02-14 11:04 ` Steffen Klassert
2012-02-15 7:00 ` Li Wei
2012-02-15 10:40 ` Steffen Klassert
2012-05-14 3:21 ` [PATCH] ipv6: fix incorrect ipsec transport mode fragment Gao feng
2012-05-14 13:05 ` Steffen Klassert
2012-05-14 22:41 ` David Miller
2012-05-17 7:42 ` Gao feng
2012-05-17 8:48 ` David Miller
2012-05-15 3:44 ` Gao feng
2012-05-15 11:48 ` Steffen Klassert
2012-05-16 2:59 ` Gao feng
2012-05-26 9:00 ` Gao feng
2012-05-26 11:29 ` Gao feng [this message]
2012-05-26 11:30 ` [PATCH v2] ipv6: fix incorrect ipsec fragment Gao feng
2012-05-27 5:12 ` 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=4FC0BE83.8090607@cn.fujitsu.com \
--to=gaofeng@cn$(echo .)fujitsu.com \
--cc=davem@davemloft$(echo .)net \
--cc=lw@cn$(echo .)fujitsu.com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=steffen.klassert@secunet$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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