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: Tue, 15 May 2012 11:44:26 +0800 [thread overview]
Message-ID: <4FB1D11A.4040206@cn.fujitsu.com> (raw)
In-Reply-To: <20120514130528.GA24733@secunet.com>
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.
>
how about add a function pointer append_data to the struct rt6_info?
so we can just call rt->append_data in ip6_append_data without conside
witch mode it is.
of course, we will set rt->append_data appropriatly in xfrm_lookup.
But the only problem is this will bloats up rt6_info,I don't konw if
it's worth doing it in this way.
>
>>
>> with my test,it work well and does not trigger slow fragment path.
>>
>> Signed-off-by: Gao feng <gaofeng@cn•fujitsu.com>
>> ---
>> net/ipv6/ip6_output.c | 80 +++++++++++++++++++++++++++++++++++++-----------
>> 1 files changed, 61 insertions(+), 19 deletions(-)
>>
>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>> index b7ca461..9416887 100644
>> --- a/net/ipv6/ip6_output.c
>> +++ b/net/ipv6/ip6_output.c
>> @@ -1191,19 +1191,23 @@ int ip6_append_data(struct sock *sk, int getfrag(void *from, char *to,
>> struct ipv6_pinfo *np = inet6_sk(sk);
>> struct inet_cork *cork;
>> struct sk_buff *skb;
>> - unsigned int maxfraglen, fragheaderlen;
>> + unsigned int maxfraglen, maxfraglen_prev, fragheaderlen;
>> int exthdrlen;
>> int dst_exthdrlen;
>> int hh_len;
>> - int mtu;
>> + int mtu, mtu_prev;
>> int copy;
>> int err;
>> int offset = 0;
>> int csummode = CHECKSUM_NONE;
>> __u8 tx_flags = 0;
>> -
>> + bool transport_mode = false;
>> + struct xfrm_state *x = rt->dst.xfrm;
>> if (flags&MSG_PROBE)
>> return 0;
>> + if (x && x->props.mode == XFRM_MODE_TRANSPORT)
>> + transport_mode = true;
>> +
>
> Btw. beet mode should behave like transport mode here, just tunnel
> mode was changed to do fragmentation before the transformation.
>
thanks steffen,I miss it and CONFIG_XFRM...
next prev parent reply other threads:[~2012-05-15 3:44 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 [this message]
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
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=4FB1D11A.4040206@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