All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Walter <linux@stwm.de>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>
Subject: Re: [PATCH net v3] ipv4: ipv6: better estimate tunnel header cut for correct ufo handling
Date: Fri, 07 Mar 2014 15:13:34 +0100	[thread overview]
Message-ID: <1706818.o0xKyWJ5le@h2o.as.studentenwerk.mhn.de> (raw)
In-Reply-To: <20140223234805.GE6598@order.stressinduktion.org>

Hello Hannes,

my reply is a little bit late. I use the patch with 3.13.5 and 3.13.6 and it 
works fine with ISATAP. Thanks a lot.

Am Montag, 24. Februar 2014, 00:48:05 schrieb Hannes Frederic Sowa:
> Currently the UFO fragmentation process does not correctly handle inner
> UDP frames.
> 
> (The following tcpdumps are captured on the parent interface with ufo
> disabled while tunnel has ufo enabled, 2000 bytes payload, mtu 1280,
> both sit device):
> 
> IPv6:
> 16:39:10.031613 IP (tos 0x0, ttl 64, id 3208, offset 0, flags [DF], proto
> IPv6 (41), length 1300) 192.168.122.151 > 1.1.1.1: IP6 (hlim 64,
> next-header Fragment (44) payload length: 1240) 2001::1 > 2001::8: frag
> (0x00000001:0|1232) 44883 > distinct: UDP, length 2000 16:39:10.031709 IP
> (tos 0x0, ttl 64, id 3209, offset 0, flags [DF], proto IPv6 (41), length
> 844) 192.168.122.151 > 1.1.1.1: IP6 (hlim 64, next-header Fragment (44)
> payload length: 784) 2001::1 > 2001::8: frag (0x00000001:0|776) 58979 >
> 46366: UDP, length 5471
> 
> We can see that fragmentation header offset is not correctly updated.
> (fragmentation id handling is corrected by 916e4cf46d0204 ("ipv6: reuse
> ip6_frag_id from ip6_ufo_append_data")).
> 
> IPv4:
> 16:39:57.737761 IP (tos 0x0, ttl 64, id 3209, offset 0, flags [DF], proto
> IPIP (4), length 1296) 192.168.122.151 > 1.1.1.1: IP (tos 0x0, ttl 64, id
> 57034, offset 0, flags [none], proto UDP (17), length 1276)
> 192.168.99.1.35961 > 192.168.99.2.distinct: UDP, length 2000
> 16:39:57.738028 IP (tos 0x0, ttl 64, id 3210, offset 0, flags [DF], proto
> IPIP (4), length 792) 192.168.122.151 > 1.1.1.1: IP (tos 0x0, ttl 64, id
> 57035, offset 0, flags [none], proto UDP (17), length 772)
> 192.168.99.1.13531 > 192.168.99.2.20653: UDP, length 51109
> 
> In this case fragmentation id is incremented and offset is not updated.
> 
> First, I aligned inet_gso_segment and ipv6_gso_segment:
> * align naming of flags
> * ipv6_gso_segment: setting skb->encapsulation is unnecessary, as we
>   always ensure that the state of this flag is left untouched when
>   returning from upper gso segmenation function
> * ipv6_gso_segment: move skb_reset_inner_headers below updating the
>   fragmentation header data, we don't care for updating fragmentation
>   header data
> * remove currently unneeded comment indicating skb->encapsulation might
>   get changed by upper gso_segment callback (gre and udp-tunnel reset
>   encapsulation after segmentation on each fragment)
> 
> If we encounter an IPIP or SIT gso skb we now check for the protocol ==
> IPPROTO_UDP and that we at least have already traversed another ip(6)
> protocol header.
> 
> The reason why we have to special case GSO_IPIP and GSO_SIT is that
> we reset skb->encapsulation to 0 while skb_mac_gso_segment the inner
> protocol of GSO_UDP_TUNNEL or GSO_GRE packets.
> 
> Reported-by: Wolfgang Walter <linux@stwm.de>
> Cc: Cong Wang <xiyou.wangcong@gmail.com>
> Cc: Tom Herbert <therbert@google.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
> Changelog v2:
> 
> * Instead of removing the comment "/* Note : following gso_segment() might
>   change skb->encapsulation */" I just moved it to the ip6_offload.c file by
> accident.
> 
> Changelog v3 (only esthetic surgery):
> 
> * Added skb->encapsulation test to the condition where we test for GRE or
>   UDP_TUNNEL gso packet, to be in line with udp_offload test for GSO_TUNNEL.
> Sorry for the noise, hopefully the last revision.
> 
>  net/ipv4/af_inet.c     |  7 +++++--
>  net/ipv6/ip6_offload.c | 20 ++++++++++++--------
>  2 files changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index ecd2c3f..19ab78a 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1296,8 +1296,11 @@ static struct sk_buff *inet_gso_segment(struct
> sk_buff *skb,
> 
>  	segs = ERR_PTR(-EPROTONOSUPPORT);
> 
> -	/* Note : following gso_segment() might change skb->encapsulation */
> -	udpfrag = !skb->encapsulation && proto == IPPROTO_UDP;
> +	if (skb->encapsulation &&
> +	    skb_shinfo(skb)->gso_type & (SKB_GSO_SIT|SKB_GSO_IPIP))
> +		udpfrag = proto == IPPROTO_UDP && encap;
> +	else
> +		udpfrag = proto == IPPROTO_UDP && !skb->encapsulation;
> 
>  	ops = rcu_dereference(inet_offloads[proto]);
>  	if (likely(ops && ops->callbacks.gso_segment))
> diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
> index 1e8683b..59f95af 100644
> --- a/net/ipv6/ip6_offload.c
> +++ b/net/ipv6/ip6_offload.c
> @@ -89,7 +89,7 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff
> *skb, unsigned int unfrag_ip6hlen;
>  	u8 *prevhdr;
>  	int offset = 0;
> -	bool tunnel;
> +	bool encap, udpfrag;
>  	int nhoff;
> 
>  	if (unlikely(skb_shinfo(skb)->gso_type &
> @@ -110,8 +110,8 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff
> *skb, if (unlikely(!pskb_may_pull(skb, sizeof(*ipv6h))))
>  		goto out;
> 
> -	tunnel = SKB_GSO_CB(skb)->encap_level > 0;
> -	if (tunnel)
> +	encap = SKB_GSO_CB(skb)->encap_level > 0;
> +	if (encap)
>  		features = skb->dev->hw_enc_features & netif_skb_features(skb);
>  	SKB_GSO_CB(skb)->encap_level += sizeof(*ipv6h);
> 
> @@ -121,6 +121,12 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff
> *skb,
> 
>  	proto = ipv6_gso_pull_exthdrs(skb, ipv6h->nexthdr);
> 
> +	if (skb->encapsulation &&
> +	    skb_shinfo(skb)->gso_type & (SKB_GSO_SIT|SKB_GSO_IPIP))
> +		udpfrag = proto == IPPROTO_UDP && encap;
> +	else
> +		udpfrag = proto == IPPROTO_UDP && !skb->encapsulation;
> +
>  	ops = rcu_dereference(inet6_offloads[proto]);
>  	if (likely(ops && ops->callbacks.gso_segment)) {
>  		skb_reset_transport_header(skb);
> @@ -133,13 +139,9 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff
> *skb, for (skb = segs; skb; skb = skb->next) {
>  		ipv6h = (struct ipv6hdr *)(skb_mac_header(skb) + nhoff);
>  		ipv6h->payload_len = htons(skb->len - nhoff - sizeof(*ipv6h));
> -		if (tunnel) {
> -			skb_reset_inner_headers(skb);
> -			skb->encapsulation = 1;
> -		}
>  		skb->network_header = (u8 *)ipv6h - skb->head;
> 
> -		if (!tunnel && proto == IPPROTO_UDP) {
> +		if (udpfrag) {
>  			unfrag_ip6hlen = ip6_find_1stfragopt(skb, &prevhdr);
>  			fptr = (struct frag_hdr *)((u8 *)ipv6h + unfrag_ip6hlen);
>  			fptr->frag_off = htons(offset);
> @@ -148,6 +150,8 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff
> *skb, offset += (ntohs(ipv6h->payload_len) -
>  				   sizeof(struct frag_hdr));
>  		}
> +		if (encap)
> +			skb_reset_inner_headers(skb);
>  	}
> 
>  out:

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

      parent reply	other threads:[~2014-03-07 14:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-07 17:47 linux 3.13: problems with isatap tunnel device and UFO Wolfgang Walter
2014-02-07 17:56 ` Hannes Frederic Sowa
2014-02-07 18:17   ` Wolfgang Walter
2014-02-07 22:22     ` Hannes Frederic Sowa
2014-02-08 23:17       ` Wolfgang Walter
2014-02-11  2:44         ` Hannes Frederic Sowa
2014-02-11 17:42           ` Wolfgang Walter
2014-02-17 16:09             ` Hannes Frederic Sowa
2014-02-20  2:44               ` Hannes Frederic Sowa
2014-02-20  2:54                 ` Hannes Frederic Sowa
2014-02-21  0:43                 ` Cong Wang
2014-02-21  1:19                   ` Hannes Frederic Sowa
2014-02-23 21:05                     ` [PATCH net] ipv4: ipv6: better estimate tunnel header cut for correct ufo handling Hannes Frederic Sowa
2014-02-23 21:24                       ` [PATCH net v2] " Hannes Frederic Sowa
2014-02-23 23:48                         ` [PATCH net v3] " Hannes Frederic Sowa
2014-02-25 23:27                           ` David Miller
2014-02-26 13:47                             ` Hannes Frederic Sowa
2014-02-26 18:45                               ` David Miller
2014-03-07 14:13                           ` Wolfgang Walter [this message]

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=1706818.o0xKyWJ5le@h2o.as.studentenwerk.mhn.de \
    --to=linux@stwm.de \
    --cc=hannes@stressinduktion.org \
    --cc=netdev@vger.kernel.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 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.