From: "Timo Teräs" <timo.teras@iki.fi>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, herbert@gondor.apana.org.au
Subject: Re: [PATCH] xfrm: use gre key as flow upper protocol info
Date: Tue, 23 Nov 2010 16:03:45 +0200 [thread overview]
Message-ID: <4CEBC9C1.8080101@iki.fi> (raw)
In-Reply-To: <20101115.104322.212675424.davem@davemloft.net>
On 11/15/2010 08:43 PM, David Miller wrote:
> From: Timo Teräs <timo.teras@iki.fi>
> Date: Wed, 3 Nov 2010 16:41:38 +0200
>
>> The GRE Key field is intended to be used for identifying an individual
>> traffic flow within a tunnel. It is useful to be able to have XFRM
>> policy selector matches to have different policies for different
>> GRE tunnels.
>>
>> Signed-off-by: Timo Teräs <timo.teras@iki.fi>
>
> I'll apply this to net-next-2.6, thanks.
Hmm.. I tested this with using the "ip xfrm" sport and dport manually
(without doing the actual userland support for this), and checking it in
kernel with printk's in various places that the stuff matches. In these
tests I checked the sport/dport by hand and apparently messed up the
byte order.
Now that I'm writing the GRE support for "ip xfrm" I think that missed
two htons() calls.
I was confused if xfrm_flowi_{s|d}port was supposed to return host or
net byte order for non-TCP/UDP packets.
I was under the assumption that host byte order since case IPPROTO_ICMP
swaps the byte order. But it would appear that the fl->fl_icmp_* is
actually host order and it's turned to network order; this is also
implied by using htons instead of ntohs. Since I decided to keep
fl_gre_key in network order, the return value would now be inconsistent,
and make userland abi endianess dependent.
I'll follow up with iproute2 patch soon.
So we probably would need to do:
xfrm: fix gre key endianess
fl->fl_gre_key is network byte order contrary to fl->fl_icmp_*.
Make xfrm_flowi_{s|d}port return network byte order values for gre
key too.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 1a57ff9..916ac47 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -806,7 +806,7 @@ __be16 xfrm_flowi_sport(struct flowi *fl)
port = htons(fl->fl_mh_type);
break;
case IPPROTO_GRE:
- port = htonl(fl->fl_gre_key) >> 16;
+ port = htons(ntohl(fl->fl_gre_key) >> 16);
break;
default:
port = 0; /*XXX*/
@@ -830,7 +830,7 @@ __be16 xfrm_flowi_dport(struct flowi *fl)
port = htons(fl->fl_icmp_code);
break;
case IPPROTO_GRE:
- port = htonl(fl->fl_gre_key) & 0xffff;
+ port = htons(ntohl(fl->fl_gre_key) & 0xffff);
break;
default:
port = 0; /*XXX*/
next prev parent reply other threads:[~2010-11-23 14:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-03 14:41 [PATCH] xfrm: use gre key as flow upper protocol info Timo Teräs
2010-11-03 20:16 ` Michał Mirosław
2010-11-03 21:35 ` Jesse Gross
2010-11-03 21:46 ` Michał Mirosław
2010-11-15 18:43 ` David Miller
2010-11-23 14:03 ` Timo Teräs [this message]
2010-11-28 19:22 ` 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=4CEBC9C1.8080101@iki.fi \
--to=timo.teras@iki.fi \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--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.