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.fujitsu.com \
--cc=davem@davemloft.net \
--cc=lw@cn.fujitsu.com \
--cc=netdev@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.