[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FC0BE83.8090607@cn.fujitsu.com>
Date: Sat, 26 May 2012 19:29:07 +0800
From: Gao feng <gaofeng@...fujitsu.com>
To: Steffen Klassert <steffen.klassert@...unet.com>
CC: netdev@...r.kernel.org, davem@...emloft.net, lw@...fujitsu.com
Subject: Re: [PATCH] ipv6: fix incorrect ipsec transport mode fragment
于 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 ;)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists