From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-2?Q?Micha=B3_Miros=B3aw?= Subject: Re: [PATCH] xfrm: use gre key as flow upper protocol info Date: Wed, 3 Nov 2010 22:46:42 +0100 Message-ID: References: <1288795298-323-1-git-send-email-timo.teras@iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: =?ISO-8859-1?Q?Timo_Ter=E4s?= , netdev@vger.kernel.org, Herbert Xu To: Jesse Gross Return-path: Received: from mail-pv0-f174.google.com ([74.125.83.174]:50456 "EHLO mail-pv0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752325Ab0KCVqm convert rfc822-to-8bit (ORCPT ); Wed, 3 Nov 2010 17:46:42 -0400 Received: by pvb32 with SMTP id 32so424605pvb.19 for ; Wed, 03 Nov 2010 14:46:42 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: W dniu 3 listopada 2010 22:35 u=BFytkownik Jesse Gross napisa=B3: > 2010/11/3 Micha=B3 Miros=B3aw : >> 2010/11/3 Timo Ter=E4s : >>> The GRE Key field is intended to be used for identifying an individ= ual >>> 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. >> [...] >>> diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c >>> index 4464f3b..57af4bd 100644 >>> --- a/net/ipv4/xfrm4_policy.c >>> +++ b/net/ipv4/xfrm4_policy.c >>> @@ -158,6 +159,20 @@ _decode_session4(struct sk_buff *skb, struct f= lowi *fl, int reverse) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fl->= fl_ipsec_spi =3D htonl(ntohs(ipcomp_hdr[1])); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; >>> + >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 case IPPROTO_GRE: >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (pskb_may_pull(skb= , xprth + 12 - skb->data)) { >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __be1= 6 *greflags =3D (__be16 *)xprth; >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __be3= 2 *gre_hdr =3D (__be32 *)xprth; >>> + >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (g= reflags[0] & GRE_KEY) { >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 if (greflags[0] & GRE_CSUM) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 gre_hdr++; >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 fl->fl_gre_key =3D gre_hdr[1]; >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break; >>> + >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0default: >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fl->fl_ipsec_spi =3D= 0; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; >> I would expect that keyless tunnel would be separate from key 0 tunn= el. > No key and key 0 are generally treated the same. =A0Both will match t= he > same tunnel when doing the lookup in the GRE receive path. I read the code again, and indeed it is. I was sure that they were treated separately some time ago, but git knows nothing about it. Best Regards, Micha=B3 Miros=B3aw