Re: [ovs-dev] [RFC PATCH 1/5] netfilter: Remove IP_CT_NEW_REPLY definition.

Re: [ovs-dev] [RFC PATCH 1/5] netfilter: Remove IP_CT_NEW_REPLY definition.

[Thomas Graf]

[Copying netfilter-devel]

On 10/20/15 at 03:20pm, Jarno Rajahalme wrote:
> Remove the definition of IP_CT_NEW_REPLY as it does not make sense.
> This allows the definition of IP_CT_NUMBER to be simplified as well.
> 
> Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
> ---
>  include/uapi/linux/netfilter/nf_conntrack_common.h | 7 ++++---
>  net/openvswitch/conntrack.c                        | 2 --
>  2 files changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/include/uapi/linux/netfilter/nf_conntrack_common.h b/include/uapi/linux/netfilter/nf_conntrack_common.h
> index 319f471..e0aebc8 100644
> --- a/include/uapi/linux/netfilter/nf_conntrack_common.h
> +++ b/include/uapi/linux/netfilter/nf_conntrack_common.h
> @@ -20,9 +20,10 @@ enum ip_conntrack_info {
>  
>  	IP_CT_ESTABLISHED_REPLY = IP_CT_ESTABLISHED + IP_CT_IS_REPLY,
>  	IP_CT_RELATED_REPLY = IP_CT_RELATED + IP_CT_IS_REPLY,
> -	IP_CT_NEW_REPLY = IP_CT_NEW + IP_CT_IS_REPLY,	
> -	/* Number of distinct IP_CT types (no NEW in reply dirn). */
> -	IP_CT_NUMBER = IP_CT_IS_REPLY * 2 - 1
> +	/* No IP_CT_NEW_REPLY */
> +
> +	/* Number of distinct IP_CT types. */
> +	IP_CT_NUMBER
>  };

I understand what you are doing here but this is part of the published
UAPI and removing this might break compilation of a user application
even if the definition is not used right now. It's probably safer to
leave the definition and obsolete it with a comment.

Re: [RFC PATCH 1/5] netfilter: Remove IP_CT_NEW_REPLY definition.

[Jarno Rajahalme]

> On Oct 21, 2015, at 1:33 AM, Thomas Graf <tgraf@suug.ch> wrote:
> 
> [Copying netfilter-devel]
> 
> On 10/20/15 at 03:20pm, Jarno Rajahalme wrote:
>> Remove the definition of IP_CT_NEW_REPLY as it does not make sense.
>> This allows the definition of IP_CT_NUMBER to be simplified as well.
>> 
>> Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
>> ---
>> include/uapi/linux/netfilter/nf_conntrack_common.h | 7 ++++---
>> net/openvswitch/conntrack.c                        | 2 --
>> 2 files changed, 4 insertions(+), 5 deletions(-)
>> 
>> diff --git a/include/uapi/linux/netfilter/nf_conntrack_common.h b/include/uapi/linux/netfilter/nf_conntrack_common.h
>> index 319f471..e0aebc8 100644
>> --- a/include/uapi/linux/netfilter/nf_conntrack_common.h
>> +++ b/include/uapi/linux/netfilter/nf_conntrack_common.h
>> @@ -20,9 +20,10 @@ enum ip_conntrack_info {
>> 
>> 	IP_CT_ESTABLISHED_REPLY = IP_CT_ESTABLISHED + IP_CT_IS_REPLY,
>> 	IP_CT_RELATED_REPLY = IP_CT_RELATED + IP_CT_IS_REPLY,
>> -	IP_CT_NEW_REPLY = IP_CT_NEW + IP_CT_IS_REPLY,	
>> -	/* Number of distinct IP_CT types (no NEW in reply dirn). */
>> -	IP_CT_NUMBER = IP_CT_IS_REPLY * 2 - 1
>> +	/* No IP_CT_NEW_REPLY */
>> +
>> +	/* Number of distinct IP_CT types. */
>> +	IP_CT_NUMBER
>> };
> 
> I understand what you are doing here but this is part of the published
> UAPI and removing this might break compilation of a user application
> even if the definition is not used right now. It's probably safer to
> leave the definition and obsolete it with a comment.

OK. I should probably separate the netlink and openvswitch changes to separate patches as well?

  Jarno

_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [RFC PATCH 1/5] netfilter: Remove IP_CT_NEW_REPLY definition.

[Thomas Graf]

On 10/21/15 at 01:15pm, Jarno Rajahalme wrote:
> 
> > On Oct 21, 2015, at 1:33 AM, Thomas Graf <tgraf@suug.ch> wrote:
> > I understand what you are doing here but this is part of the published
> > UAPI and removing this might break compilation of a user application
> > even if the definition is not used right now. It's probably safer to
> > leave the definition and obsolete it with a comment.
> 
> OK. I should probably separate the netlink and openvswitch changes to separate patches as well?

Given that at that point the changes become unrelated, I'd split
it into separate patches, yes.

Re: [RFC PATCH 4/5] openvswitch: conntrack netlink API updates.

[Pablo Neira Ayuso]

On Tue, Oct 20, 2015 at 03:20:28PM -0700, Jarno Rajahalme wrote:
> diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
> index 77850f1..1e6c2ac 100644
> --- a/net/openvswitch/flow_netlink.c
> +++ b/net/openvswitch/flow_netlink.c
> @@ -291,7 +291,7 @@ size_t ovs_key_attr_size(void)
>  		+ nla_total_size(4)   /* OVS_KEY_ATTR_SKB_MARK */
>  		+ nla_total_size(4)   /* OVS_KEY_ATTR_DP_HASH */
>  		+ nla_total_size(4)   /* OVS_KEY_ATTR_RECIRC_ID */
> -		+ nla_total_size(1)   /* OVS_KEY_ATTR_CT_STATE */
> +		+ nla_total_size(4)   /* OVS_KEY_ATTR_CT_STATE */
>  		+ nla_total_size(2)   /* OVS_KEY_ATTR_CT_ZONE */
>  		+ nla_total_size(4)   /* OVS_KEY_ATTR_CT_MARK */
>  		+ nla_total_size(16)  /* OVS_KEY_ATTR_CT_LABEL */

This is very strange.

You're changing the size of the netlink attribute, this will break
existing userspace applications.

Re: [RFC PATCH 4/5] openvswitch: conntrack netlink API updates.

[Thomas Graf]

On 10/21/15 at 12:41pm, Pablo Neira Ayuso wrote:
> On Tue, Oct 20, 2015 at 03:20:28PM -0700, Jarno Rajahalme wrote:
> > diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
> > index 77850f1..1e6c2ac 100644
> > --- a/net/openvswitch/flow_netlink.c
> > +++ b/net/openvswitch/flow_netlink.c
> > @@ -291,7 +291,7 @@ size_t ovs_key_attr_size(void)
> >  		+ nla_total_size(4)   /* OVS_KEY_ATTR_SKB_MARK */
> >  		+ nla_total_size(4)   /* OVS_KEY_ATTR_DP_HASH */
> >  		+ nla_total_size(4)   /* OVS_KEY_ATTR_RECIRC_ID */
> > -		+ nla_total_size(1)   /* OVS_KEY_ATTR_CT_STATE */
> > +		+ nla_total_size(4)   /* OVS_KEY_ATTR_CT_STATE */
> >  		+ nla_total_size(2)   /* OVS_KEY_ATTR_CT_ZONE */
> >  		+ nla_total_size(4)   /* OVS_KEY_ATTR_CT_MARK */
> >  		+ nla_total_size(16)  /* OVS_KEY_ATTR_CT_LABEL */
> 
> This is very strange.
> 
> You're changing the size of the netlink attribute, this will break
> existing userspace applications.

This seems to be a temporary forward port of the following commit. The
change is backwards compatible.

commit fbccce5965a58d56aaed9e9acd1bec75d8a66e87
Author: Joe Stringer <joestringer@nicira.com>
Date:   Tue Oct 6 11:00:00 2015 -0700

    openvswitch: Extend ct_state match field to 32 bits

    The ct_state field was initially added as an 8-bit field, however six of
    the bits are already being used and use cases are already starting to
    appear that may push the limits of this field. This patch extends the
    field to 32 bits while retaining the internal representation of 8 bits.
    This should cover forward compatibility of the ABI for the foreseeable
    future.

    This patch also reorders the OVS_CS_F_* bits to be sequential.

    Suggested-by: Jarno Rajahalme <jrajahalme@nicira.com>
    Signed-off-by: Joe Stringer <joestringer@nicira.com>
    Acked-by: Pravin B Shelar <pshelar@nicira.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Re: [RFC PATCH 3/5] netfilter: Allow calling into nat helper without skb_dst.

[Pablo Neira Ayuso]

On Tue, Oct 20, 2015 at 03:20:27PM -0700, Jarno Rajahalme wrote:
> NAT checksum recalculation code assumed existence of skb_dst, which
> becomes a problem for a later patch in the series.  Simplify this by
> removing the checks, as the checksum will be dealt with later in the
> stack.

Please, resubmit netfilter patches to netfilter-devel@vger.kernel.org
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [RFC PATCH 3/5] netfilter: Allow calling into nat helper without skb_dst.

[Jarno Rajahalme]

> On Oct 21, 2015, at 3:44 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> 
> On Tue, Oct 20, 2015 at 03:20:27PM -0700, Jarno Rajahalme wrote:
>> NAT checksum recalculation code assumed existence of skb_dst, which
>> becomes a problem for a later patch in the series.  Simplify this by
>> removing the checks, as the checksum will be dealt with later in the
>> stack.
> 
> Please, resubmit netfilter patches to netfilter-devel@vger.kernel.org

Will do.

  Jarno

Re: [RFC PATCH 2/5] netfilter: Factor out nf_ct_get_info().

[Thomas Graf]

On 10/20/15 at 03:20pm, Jarno Rajahalme wrote:
> Define a new inline function to map conntrack status to enum
> ip_conntrack_info.  This removes the need to otherwise duplicate this
> code in a later patch.
> 
> Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>

LGTM

> ---
>  include/net/netfilter/nf_conntrack.h | 15 +++++++++++++++
>  net/netfilter/nf_conntrack_core.c    | 22 +++-------------------
>  2 files changed, 18 insertions(+), 19 deletions(-)
> 
> diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
> index fde4068..b3de10e 100644
> --- a/include/net/netfilter/nf_conntrack.h
> +++ b/include/net/netfilter/nf_conntrack.h
> @@ -125,6 +125,21 @@ nf_ct_tuplehash_to_ctrack(const struct nf_conntrack_tuple_hash *hash)
>  			    tuplehash[hash->tuple.dst.dir]);
>  }
>  
> +static inline enum ip_conntrack_info
> +nf_ct_get_info(const struct nf_conntrack_tuple_hash *h)
> +{
> +	const struct nf_conn *ct = nf_ct_tuplehash_to_ctrack(h);
> +
> +	if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
> +		return IP_CT_ESTABLISHED_REPLY;
> +	/* Once we've had two way comms, always ESTABLISHED. */
> +	if (test_bit(IPS_SEEN_REPLY_BIT, &ct->status))
> +		return IP_CT_ESTABLISHED;
> +	if (test_bit(IPS_EXPECTED_BIT, &ct->status))
> +		return IP_CT_RELATED;
> +	return IP_CT_NEW;
> +}
> +
>  static inline u_int16_t nf_ct_l3num(const struct nf_conn *ct)
>  {
>  	return ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.l3num;
> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
> index 3cb3cb8..70ddbd8 100644
> --- a/net/netfilter/nf_conntrack_core.c
> +++ b/net/netfilter/nf_conntrack_core.c
> @@ -1056,25 +1056,9 @@ resolve_normal_ct(struct net *net, struct nf_conn *tmpl,
>  	ct = nf_ct_tuplehash_to_ctrack(h);
>  
>  	/* It exists; we have (non-exclusive) reference. */
> -	if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY) {
> -		*ctinfo = IP_CT_ESTABLISHED_REPLY;
> -		/* Please set reply bit if this packet OK */
> -		*set_reply = 1;
> -	} else {
> -		/* Once we've had two way comms, always ESTABLISHED. */
> -		if (test_bit(IPS_SEEN_REPLY_BIT, &ct->status)) {
> -			pr_debug("nf_conntrack_in: normal packet for %p\n", ct);
> -			*ctinfo = IP_CT_ESTABLISHED;
> -		} else if (test_bit(IPS_EXPECTED_BIT, &ct->status)) {
> -			pr_debug("nf_conntrack_in: related packet for %p\n",
> -				 ct);
> -			*ctinfo = IP_CT_RELATED;
> -		} else {
> -			pr_debug("nf_conntrack_in: new packet for %p\n", ct);
> -			*ctinfo = IP_CT_NEW;
> -		}
> -		*set_reply = 0;
> -	}
> +	*ctinfo = nf_ct_get_info(h);
> +	*set_reply = NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY;
> +
>  	skb->nfct = &ct->ct_general;
>  	skb->nfctinfo = *ctinfo;
>  	return ct;
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [RFC PATCH 2/5] netfilter: Factor out nf_ct_get_info().

[Pablo Neira Ayuso]

On Tue, Oct 20, 2015 at 03:20:26PM -0700, Jarno Rajahalme wrote:
> Define a new inline function to map conntrack status to enum
> ip_conntrack_info.  This removes the need to otherwise duplicate this
> code in a later patch.

Where is that later patch that justifies this update?

> Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
> ---
>  include/net/netfilter/nf_conntrack.h | 15 +++++++++++++++
>  net/netfilter/nf_conntrack_core.c    | 22 +++-------------------
>  2 files changed, 18 insertions(+), 19 deletions(-)
> 
> diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
> index fde4068..b3de10e 100644
> --- a/include/net/netfilter/nf_conntrack.h
> +++ b/include/net/netfilter/nf_conntrack.h
> @@ -125,6 +125,21 @@ nf_ct_tuplehash_to_ctrack(const struct nf_conntrack_tuple_hash *hash)
>  			    tuplehash[hash->tuple.dst.dir]);
>  }
>  
> +static inline enum ip_conntrack_info
> +nf_ct_get_info(const struct nf_conntrack_tuple_hash *h)
> +{
> +	const struct nf_conn *ct = nf_ct_tuplehash_to_ctrack(h);
> +
> +	if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
> +		return IP_CT_ESTABLISHED_REPLY;
> +	/* Once we've had two way comms, always ESTABLISHED. */
> +	if (test_bit(IPS_SEEN_REPLY_BIT, &ct->status))
> +		return IP_CT_ESTABLISHED;
> +	if (test_bit(IPS_EXPECTED_BIT, &ct->status))
> +		return IP_CT_RELATED;
> +	return IP_CT_NEW;
> +}

I would really like to see how you want to use this.

Re: [RFC PATCH 2/5] netfilter: Factor out nf_ct_get_info().

[Jarno Rajahalme]

> On Oct 21, 2015, at 3:45 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> 
> On Tue, Oct 20, 2015 at 03:20:26PM -0700, Jarno Rajahalme wrote:
>> Define a new inline function to map conntrack status to enum
>> ip_conntrack_info.  This removes the need to otherwise duplicate this
>> code in a later patch.
> 
> Where is that later patch that justifies this update?
> 

It is in patch 5/5, ovs_ct_find_existing(). The intent it to locate an existing conntrack entry without modifying it, if such an entry exists. This is needed in a case where we first go through the conntrack (calling nf_conntrack_in), then recirculate (to match on the state bits), but do not find a matching flow entry in the flow table. In this case we issue an upcall and let the OVS userspace compute a new flow entry. When the packet gets back to kernel we have lost the skb (as we do not buffer it in the kernel after issuing the upcall). ovs_ct_find_existing() can then be used to populate the nfct and nfctinfo fields of the new skb, as if this skb had gone through the nf_conntrack_in() call. This allows us to pass the packet through NAT after such an upcall without passing the packet through nf_conntrack_in() twice.

ovs_ct_find_existing() is intended to be used only when we have evidence in the OVS flow key that the packet actually went through nf_conntrack_in() prior to the upcall. In the current version of the patches I do not have a test case for this, and I intend to separate out this change into a separate patch before the NAT patch for the next (non-RFC) version.

I could implement ovs_ct_find_existing() using exported conntrack APIs apart from this mapping from conntrack status to enum ip_conntrack_info. ovs_ct_find_existing() is in no way OVS specific, though, so it could be added to the conntrack proper as well, if so desired.

  Jarno

>> Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
>> ---
>> include/net/netfilter/nf_conntrack.h | 15 +++++++++++++++
>> net/netfilter/nf_conntrack_core.c    | 22 +++-------------------
>> 2 files changed, 18 insertions(+), 19 deletions(-)
>> 
>> diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
>> index fde4068..b3de10e 100644
>> --- a/include/net/netfilter/nf_conntrack.h
>> +++ b/include/net/netfilter/nf_conntrack.h
>> @@ -125,6 +125,21 @@ nf_ct_tuplehash_to_ctrack(const struct nf_conntrack_tuple_hash *hash)
>> 			    tuplehash[hash->tuple.dst.dir]);
>> }
>> 
>> +static inline enum ip_conntrack_info
>> +nf_ct_get_info(const struct nf_conntrack_tuple_hash *h)
>> +{
>> +	const struct nf_conn *ct = nf_ct_tuplehash_to_ctrack(h);
>> +
>> +	if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
>> +		return IP_CT_ESTABLISHED_REPLY;
>> +	/* Once we've had two way comms, always ESTABLISHED. */
>> +	if (test_bit(IPS_SEEN_REPLY_BIT, &ct->status))
>> +		return IP_CT_ESTABLISHED;
>> +	if (test_bit(IPS_EXPECTED_BIT, &ct->status))
>> +		return IP_CT_RELATED;
>> +	return IP_CT_NEW;
>> +}
> 
> I would really like to see how you want to use this.

_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [RFC PATCH 2/5] netfilter: Factor out nf_ct_get_info().

[Jarno Rajahalme]

> On Oct 21, 2015, at 3:45 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> 
> On Tue, Oct 20, 2015 at 03:20:26PM -0700, Jarno Rajahalme wrote:
>> Define a new inline function to map conntrack status to enum
>> ip_conntrack_info.  This removes the need to otherwise duplicate this
>> code in a later patch.
> 
> Where is that later patch that justifies this update?
> 

It is in patch 5/5, ovs_ct_find_existing(). The intent it to locate an existing conntrack entry without modifying it, if such an entry exists. This is needed in a case where we first go through the conntrack (calling nf_conntrack_in), then recirculate (to match on the state bits), but do not find a matching flow entry in the flow table. In this case we issue an upcall and let the OVS userspace compute a new flow entry. When the packet gets back to kernel we have lost the skb (as we do not buffer it in the kernel after issuing the upcall). ovs_ct_find_existing() can then be used to populate the nfct and nfctinfo fields of the new skb, as if this skb had gone through the nf_conntrack_in() call. This allows us to pass the packet through NAT after such an upcall without passing the packet thro
 ugh nf_conntrack_in() twice.

ovs_ct_find_existing() is intended to be used only when we have evidence in the OVS flow key that the packet actually went through nf_conntrack_in() prior to the upcall. In the current version of the patches I do not have a test case for this, and I intend to separate out this change into a separate patch before the NAT patch for the next (non-RFC) version.

I could implement ovs_ct_find_existing() using exported conntrack APIs apart from this mapping from conntrack status to enum ip_conntrack_info. ovs_ct_find_existing() is in no way OVS specific, though, so it could be added to the conntrack proper as well, if so desired.

  Jarno

>> Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
>> ---
>> include/net/netfilter/nf_conntrack.h | 15 +++++++++++++++
>> net/netfilter/nf_conntrack_core.c    | 22 +++-------------------
>> 2 files changed, 18 insertions(+), 19 deletions(-)
>> 
>> diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
>> index fde4068..b3de10e 100644
>> --- a/include/net/netfilter/nf_conntrack.h
>> +++ b/include/net/netfilter/nf_conntrack.h
>> @@ -125,6 +125,21 @@ nf_ct_tuplehash_to_ctrack(const struct nf_conntrack_tuple_hash *hash)
>> 			    tuplehash[hash->tuple.dst.dir]);
>> }
>> 
>> +static inline enum ip_conntrack_info
>> +nf_ct_get_info(const struct nf_conntrack_tuple_hash *h)
>> +{
>> +	const struct nf_conn *ct = nf_ct_tuplehash_to_ctrack(h);
>> +
>> +	if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
>> +		return IP_CT_ESTABLISHED_REPLY;
>> +	/* Once we've had two way comms, always ESTABLISHED. */
>> +	if (test_bit(IPS_SEEN_REPLY_BIT, &ct->status))
>> +		return IP_CT_ESTABLISHED;
>> +	if (test_bit(IPS_EXPECTED_BIT, &ct->status))
>> +		return IP_CT_RELATED;
>> +	return IP_CT_NEW;
>> +}
> 
> I would really like to see how you want to use this.

Re: [RFC PATCH 5/5] openvswitch: Interface with NAT.

[Thomas Graf]

On 10/20/15 at 03:20pm, Jarno Rajahalme wrote:
> Extend OVS conntrack interface to cover NAT.  New nested
> OVS_CT_ATTR_NAT may be used to include NAT with a CT action.  A bare
> OVS_CT_ATTR_NAT only mangles existing connections.  If
> OVS_NAT_ATTR_SRC or OVS_NAT_ATTR_DST is included within the nested
> attributes, new (non-committed/non-confirmed) connections are mangled
> according to the rest of the nested attributes.
> 
> This work extends on a branch by Thomas Graf at
> https://github.com/tgraf/ovs/tree/nat.
> 
> Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>

Awesome work. This is a great start.

There are some, probably unintended, unrelated style changes. More
comments below.

> +enum ovs_nat_attr {
> +	OVS_NAT_ATTR_UNSPEC,
> +	OVS_NAT_ATTR_SRC,
> +	OVS_NAT_ATTR_DST,
> +	OVS_NAT_ATTR_IP_MIN,
> +	OVS_NAT_ATTR_IP_MAX,
> +	OVS_NAT_ATTR_PROTO_MIN,
> +	OVS_NAT_ATTR_PROTO_MAX,
> +	OVS_NAT_ATTR_PERSISTENT,
> +	OVS_NAT_ATTR_PROTO_HASH,
> +	OVS_NAT_ATTR_PROTO_RANDOM,

Simplify this with an OVS_NAT_ATTR_FLAGS?

> @@ -137,11 +159,17 @@ static void __ovs_ct_update_key(struct sw_flow_key *key, u8 state,
>  	ovs_ct_get_label(ct, &key->ct.label);
>  }
>  
> -/* Update 'key' based on skb->nfct. If 'post_ct' is true, then OVS has
> - * previously sent the packet to conntrack via the ct action.
> +/* Update 'key' based on skb->nfct.  If 'post_ct' is true, then OVS has
> + * previously sent the packet to conntrack via the ct action.  If
> + * 'keep_nat_flags' is true, the existing NAT flags retained, else they are
> + * initialized from the connection status.
>   */
>  static void ovs_ct_update_key(const struct sk_buff *skb,
> -			      struct sw_flow_key *key, bool post_ct)
> +			      struct sw_flow_key *key, bool post_ct
> +#ifdef CONFIG_NF_NAT_NEEDED
> +			      , bool keep_nat_flags
> +#endif
> +			      )

I suggest keeping the argument even for !CONFIG_NF_NAT_NEEDED. This
unclutters the call sites of this function. An ifdef inside the
keep_nat_flags branch should be enough. The compiler will optimize
the code away and it's much prettier to read.

>  {
>  	const struct nf_conntrack_zone *zone = &nf_ct_zone_dflt;
>  	enum ip_conntrack_info ctinfo;
> @@ -151,8 +179,20 @@ static void ovs_ct_update_key(const struct sk_buff *skb,
>  	ct = nf_ct_get(skb, &ctinfo);
>  	if (ct) {
>  		state = ovs_ct_get_state(ctinfo);
> +		/* OVS persists the related flag for the duration of the
> +		 * connection. */
>  		if (ct->master)
>  			state |= OVS_CS_F_RELATED;
> +#ifdef CONFIG_NF_NAT_NEEDED
> +		if (keep_nat_flags)
> +			state |= key->ct.state & OVS_CS_F_NAT_MASK;
> +		else {
> +			if (ct->status & IPS_SRC_NAT)
> +				state |= OVS_CS_F_SRC_NAT;
> +			if (ct->status & IPS_DST_NAT)
> +				state |= OVS_CS_F_DST_NAT;
> +		}
> +#endif
>  		zone = nf_ct_zone(ct);
>  	} else if (post_ct) {
>  		state = OVS_CS_F_TRACKED | OVS_CS_F_INVALID;
> @@ -291,7 +337,16 @@ static int ovs_ct_helper(struct sk_buff *skb, u16 proto)
>  		return NF_DROP;
>  	}
>  
> -	return helper->help(skb, protoff, ct, ctinfo);
> +	if (helper->help(skb, protoff, ct, ctinfo) != NF_ACCEPT)
> +		return NF_DROP;

Return the returned value here instead of hardcoding NF_DROP?

> +#ifdef CONFIG_NF_NAT_NEEDED
> +	/* Adjust seqs after helper. */

A comment on why this is needed would be helpful.

> +	if (test_bit(IPS_SEQ_ADJUST_BIT, &ct->status)
> +	    && !nf_ct_seq_adjust(skb, ct, ctinfo, protoff))
> +		return NF_DROP;
> +#endif
> +	return NF_ACCEPT;

> @@ -377,7 +432,211 @@ static bool skb_nfct_cached(const struct net *net, const struct sk_buff *skb,
>  	return true;
>  }
>  
> -static int __ovs_ct_lookup(struct net *net, const struct sw_flow_key *key,
> +#ifdef CONFIG_NF_NAT_NEEDED
> +/* Modeled after nf_nat_ipv[46]_fn().
> + * range is only used for new, uninitialized NAT state.
> + * Returns either NF_ACCEPT or NF_DROP. */
> +static int ovs_ct_nat_execute(struct sk_buff *skb, struct nf_conn *ct,
> +			      enum ip_conntrack_info ctinfo,
> +			      const struct nf_nat_range *range,
> +			      enum nf_nat_manip_type maniptype)
> +{
> +	int hooknum, nh_off, err = NF_ACCEPT;
> +
> +	nh_off = skb_network_offset(skb);
> +	skb_pull(skb, nh_off);
> +
> +	/* See HOOK2MANIP(). */
> +	if (maniptype == NF_NAT_MANIP_SRC)
> +		hooknum = NF_INET_LOCAL_IN; /* Source NAT */
> +	else
> +		hooknum = NF_INET_LOCAL_OUT; /* Destination NAT */
> +
> +	switch (ctinfo) {
> +	case IP_CT_RELATED:
> +	case IP_CT_RELATED_REPLY:
> +		if (skb->protocol == htons(ETH_P_IP)
> +		    && ip_hdr(skb)->protocol == IPPROTO_ICMP) {
> +			if (!nf_nat_icmp_reply_translation(skb, ct, ctinfo,
> +							   hooknum))
> +				err = NF_DROP;
> +			goto push;
> +		} else if (skb->protocol == htons(ETH_P_IPV6)) {
> +			__be16 frag_off;
> +			u8 nexthdr = ipv6_hdr(skb)->nexthdr;
> +			int hdrlen = ipv6_skip_exthdr(skb,
> +						      sizeof(struct ipv6hdr),
> +						      &nexthdr, &frag_off);
> +
> +			if (hdrlen >= 0 && nexthdr == IPPROTO_ICMPV6) {
> +				if (!nf_nat_icmpv6_reply_translation(skb, ct,
> +								     ctinfo,
> +								     hooknum,
> +								     hdrlen))
> +					err = NF_DROP;
> +				goto push;
> +			}
> +		}
> +		/* Non-ICMP, fall thru to initialize if needed. */
> +	case IP_CT_NEW:
> +		/* Seen it before?  This can happen for loopback, retrans,
> +		 * or local packets.
> +		 */
> +		if (!nf_nat_initialized(ct, maniptype)) {

Explicit unlikely()?

> +			/* Initialize according to the NAT action. */
> +			err = (range && range->flags & NF_NAT_RANGE_MAP_IPS)
> +				/* Action is set up to establish a new
> +				 * mapping */
> +				? nf_nat_setup_info(ct, range, maniptype)
> +				: nf_nat_alloc_null_binding(ct, hooknum);
> +		}
> +		break;
> +
> +	case IP_CT_ESTABLISHED:
> +	case IP_CT_ESTABLISHED_REPLY:
> +		break;
> +
> +	default:
> +		err = NF_DROP;
> +		goto push;
> +	}
> +
> +	if (err == NF_ACCEPT)
> +		err = nf_nat_packet(ct, ctinfo, hooknum, skb);

If you goto push on init failure (IP_CT_NEW branch), then this
conditional is no longer needed and a more straight forward exception
handling is seen.

> +push:
> +	skb_push(skb, nh_off);
> +
> +	return err;
> +}

> +/* Returns NF_DROP if the packet should be dropped, NF_ACCEPT otherwise.
> + * This action can be used to both NAT and reverse NAT, however, reverse NAT
> + * can also be done with the conntrack action. */
> +static int ovs_ct_nat(struct net *net, struct sw_flow_key *key,
> +		      const struct ovs_conntrack_info *info,
> +		      struct sk_buff *skb)
> +{
> +	enum nf_nat_manip_type maniptype;
> +	enum ip_conntrack_info ctinfo;
> +	struct nf_conn *ct;
> +	int err;
> +
> +	/* No NAT action or already NATed? */
> +	if (!(info->flags & OVS_CT_F_NAT_MASK)
> +	    || key->ct.state & OVS_CS_F_NAT_MASK)
> +		return NF_ACCEPT;
> +
> +	ct = nf_ct_get(skb, &ctinfo);
> +	/* Check if an existing conntrack entry may be found for this skb.
> +	 * This happens when we lose the ct entry pointer due to an upcall.
> +	 * Don't lookup invalid connections. */
> +	if (!ct && key->ct.state & OVS_CS_F_TRACKED
> +	    && !(key->ct.state & OVS_CS_F_INVALID))
> +		ct = ovs_ct_find_existing(net, &info->zone, info->family, skb,
> +					  &ctinfo);
> +	if (!ct || nf_ct_is_untracked(ct))
> +		/* A NAT action may only be performed on tracked packets. */
> +		return NF_ACCEPT;

Braces

> +	/* Add NAT extension if not commited yet. */
> +	if (!nf_ct_is_confirmed(ct)) {
> +		if (!nf_ct_nat_ext_add(ct))
> +			return NF_ACCEPT;   /* Can't NAT. */
> +	}

&&

> +	/* Determine NAT type.
> +	 * Check if the NAT type can be deduced from the tracked connection.
> +	 * Make sure expected traffic is NATted only when commiting. */
> +	if (info->flags & OVS_CT_F_NAT && ctinfo != IP_CT_NEW
> +	    && ct->status & IPS_NAT_MASK
> +	    && (!(ct->status & IPS_EXPECTED_BIT)
> +		|| info->flags & OVS_CT_F_COMMIT)) {
> +		/* NAT an established or related connection like before. */
> +		if (CTINFO2DIR(ctinfo) == IP_CT_DIR_REPLY)
> +			/* This is the REPLY direction for a connection
> +			 * for which NAT was applied in the forward
> +			 * direction.  Do the reverse NAT. */
> +			maniptype = ct->status & IPS_SRC_NAT
> +				? NF_NAT_MANIP_DST : NF_NAT_MANIP_SRC;
> +		else
> +			maniptype = ct->status & IPS_SRC_NAT
> +				? NF_NAT_MANIP_SRC : NF_NAT_MANIP_DST;
> +	}
> +	else if (info->flags & OVS_CT_F_SRC_NAT)
> +		maniptype = NF_NAT_MANIP_SRC;
> +	else if (info->flags & OVS_CT_F_DST_NAT)
> +		maniptype = NF_NAT_MANIP_DST;
> +	else
> +		return NF_ACCEPT; /* Connection is not NATed. */
> +
> +	err = ovs_ct_nat_execute(skb, ct, ctinfo, &info->range, maniptype);
> +
> +	/* Mark NAT done if successful. */
> +	if (err == NF_ACCEPT)
> +		key->ct.state |= (maniptype == NF_NAT_MANIP_SRC)
> +			? OVS_CS_F_SRC_NAT : OVS_CS_F_DST_NAT;
> +	return err;
> +}
> +#endif
> +
> +static int __ovs_ct_lookup(struct net *net, struct sw_flow_key *key,
>  			   const struct ovs_conntrack_info *info,
>  			   struct sk_buff *skb)
>  {


> @@ -538,6 +819,131 @@ static int ovs_ct_add_helper(struct ovs_conntrack_info *info, const char *name,
>  	return 0;
>  }
>  
> +#ifdef CONFIG_NF_NAT_NEEDED
> +static int parse_nat(const struct nlattr *attr,
> +		     struct ovs_conntrack_info *info, bool log)
> +{
> +	struct nlattr *a;
> +	int rem;
> +	bool have_ip_max = false;
> +	bool have_proto_max = false;
> +	bool ip_vers = (info->family == NFPROTO_IPV6);
> +
> +	nla_for_each_nested(a, attr, rem) {
> +		static const u16 ovs_nat_attr_lens[OVS_NAT_ATTR_MAX + 1][2] = {
> +			[OVS_NAT_ATTR_SRC] = {0, 0},
> +			[OVS_NAT_ATTR_DST] = {0, 0},
> +			[OVS_NAT_ATTR_IP_MIN] = {sizeof(struct in_addr),
> +						 sizeof(struct in6_addr)},
> +			[OVS_NAT_ATTR_IP_MAX] = {sizeof(struct in_addr),
> +						 sizeof(struct in6_addr)},
> +			[OVS_NAT_ATTR_PROTO_MIN] = {sizeof(u16),sizeof(u16)},
> +			[OVS_NAT_ATTR_PROTO_MAX] = {sizeof(u16),sizeof(u16)},
> +			[OVS_NAT_ATTR_PERSISTENT] = {0, 0},
> +			[OVS_NAT_ATTR_PROTO_HASH] = {0, 0},
> +			[OVS_NAT_ATTR_PROTO_RANDOM] = {0, 0},
> +		};
> +		int type = nla_type(a);
> +
> +		if (type > OVS_NAT_ATTR_MAX) {
> +			OVS_NLERR(log, "Unknown nat attribute (type=%d, max=%d).\n",
> +			type, OVS_NAT_ATTR_MAX);

Formatting

> +			return -EINVAL;
> +		}
> +
> +		case OVS_NAT_ATTR_IP_MIN:
> +			nla_memcpy(&info->range.min_addr, a, nla_len(a));

The length attribute should be sizeof of min_addr like for max_addr
below.

> +			info->range.flags |= NF_NAT_RANGE_MAP_IPS;
> +			break;
> +
> +		case OVS_NAT_ATTR_IP_MAX:
> +			have_ip_max = true;
> +			nla_memcpy(&info->range.max_addr, a,
> +				   sizeof(info->range.max_addr));
> +			info->range.flags |= NF_NAT_RANGE_MAP_IPS;
> +			break;
> +
> +	}

>  static const struct ovs_ct_len_tbl ovs_ct_attr_lens[OVS_CT_ATTR_MAX + 1] = {
>  	[OVS_CT_ATTR_COMMIT]	= { .minlen = 0,
>  				    .maxlen = 0 },
> @@ -548,7 +954,11 @@ static const struct ovs_ct_len_tbl ovs_ct_attr_lens[OVS_CT_ATTR_MAX + 1] = {
>  	[OVS_CT_ATTR_LABEL]	= { .minlen = sizeof(struct md_label),
>  				    .maxlen = sizeof(struct md_label) },
>  	[OVS_CT_ATTR_HELPER]	= { .minlen = 1,
> -				    .maxlen = NF_CT_HELPER_NAME_LEN }
> +				    .maxlen = NF_CT_HELPER_NAME_LEN },
> +#ifdef CONFIG_NF_NAT_NEEDED
> +	[OVS_CT_ATTR_NAT]	= { .minlen = 0,
> +				    .maxlen = 96 }
> +#endif

Is the 96 a temporary hack here?

> @@ -607,6 +1017,14 @@ static int parse_ct(const struct nlattr *attr, struct ovs_conntrack_info *info,
>  				return -EINVAL;
>  			}
>  			break;
> +#ifdef CONFIG_NF_NAT_NEEDED
> +		case OVS_CT_ATTR_NAT: {
> +			int err = parse_nat(a, info, log);
> +			if (err)
> +				return err;
> +			break;
> +		}
> +#endif

We should probably bark if user space provides a OVS_CT_ATTR_NAT but the
kernel is compiled without support for it.

> +#ifdef CONFIG_NF_NAT_NEEDED
> +static bool ovs_ct_nat_to_attr(const struct ovs_conntrack_info *info,
> +			       struct sk_buff *skb)
> +{
> +	struct nlattr *start;
> +
> +	start = nla_nest_start(skb, OVS_CT_ATTR_NAT);
> +	if (!start)
> +		return false;
> +
> +	if (info->flags & OVS_CT_F_SRC_NAT) {
> +		if (nla_put_flag(skb, OVS_NAT_ATTR_SRC))
> +			return false;
> +	} else if (info->flags & OVS_CT_F_DST_NAT) {
> +		if (nla_put_flag(skb, OVS_NAT_ATTR_DST))
> +			return false;
> +	} else {
> +		goto out;

Is the empty nested attribute intended here?

Re: [RFC PATCH 5/5] openvswitch: Interface with NAT.

[Jarno Rajahalme]

> On Oct 21, 2015, at 3:59 AM, Thomas Graf <tgraf@suug.ch> wrote:
> 
> On 10/20/15 at 03:20pm, Jarno Rajahalme wrote:
>> Extend OVS conntrack interface to cover NAT.  New nested
>> OVS_CT_ATTR_NAT may be used to include NAT with a CT action.  A bare
>> OVS_CT_ATTR_NAT only mangles existing connections.  If
>> OVS_NAT_ATTR_SRC or OVS_NAT_ATTR_DST is included within the nested
>> attributes, new (non-committed/non-confirmed) connections are mangled
>> according to the rest of the nested attributes.
>> 
>> This work extends on a branch by Thomas Graf at
>> https://github.com/tgraf/ovs/tree/nat.
>> 
>> Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
> 
> Awesome work. This is a great start.
> 
> There are some, probably unintended, unrelated style changes. More
> comments below.
> 

Thanks for the review!

>> +enum ovs_nat_attr {
>> +	OVS_NAT_ATTR_UNSPEC,
>> +	OVS_NAT_ATTR_SRC,
>> +	OVS_NAT_ATTR_DST,
>> +	OVS_NAT_ATTR_IP_MIN,
>> +	OVS_NAT_ATTR_IP_MAX,
>> +	OVS_NAT_ATTR_PROTO_MIN,
>> +	OVS_NAT_ATTR_PROTO_MAX,
>> +	OVS_NAT_ATTR_PERSISTENT,
>> +	OVS_NAT_ATTR_PROTO_HASH,
>> +	OVS_NAT_ATTR_PROTO_RANDOM,
> 
> Simplify this with an OVS_NAT_ATTR_FLAGS?

The use of separate flag attributes was actually intentional, as it makes the interface easier to understand, and code also easier to read.

> 
>> @@ -137,11 +159,17 @@ static void __ovs_ct_update_key(struct sw_flow_key *key, u8 state,
>> 	ovs_ct_get_label(ct, &key->ct.label);
>> }
>> 
>> -/* Update 'key' based on skb->nfct. If 'post_ct' is true, then OVS has
>> - * previously sent the packet to conntrack via the ct action.
>> +/* Update 'key' based on skb->nfct.  If 'post_ct' is true, then OVS has
>> + * previously sent the packet to conntrack via the ct action.  If
>> + * 'keep_nat_flags' is true, the existing NAT flags retained, else they are
>> + * initialized from the connection status.
>>  */
>> static void ovs_ct_update_key(const struct sk_buff *skb,
>> -			      struct sw_flow_key *key, bool post_ct)
>> +			      struct sw_flow_key *key, bool post_ct
>> +#ifdef CONFIG_NF_NAT_NEEDED
>> +			      , bool keep_nat_flags
>> +#endif
>> +			      )
> 
> I suggest keeping the argument even for !CONFIG_NF_NAT_NEEDED. This
> unclutters the call sites of this function. An ifdef inside the
> keep_nat_flags branch should be enough. The compiler will optimize
> the code away and it's much prettier to read.
> 

OK.

>> {
>> 	const struct nf_conntrack_zone *zone = &nf_ct_zone_dflt;
>> 	enum ip_conntrack_info ctinfo;
>> @@ -151,8 +179,20 @@ static void ovs_ct_update_key(const struct sk_buff *skb,
>> 	ct = nf_ct_get(skb, &ctinfo);
>> 	if (ct) {
>> 		state = ovs_ct_get_state(ctinfo);
>> +		/* OVS persists the related flag for the duration of the
>> +		 * connection. */
>> 		if (ct->master)
>> 			state |= OVS_CS_F_RELATED;
>> +#ifdef CONFIG_NF_NAT_NEEDED
>> +		if (keep_nat_flags)
>> +			state |= key->ct.state & OVS_CS_F_NAT_MASK;
>> +		else {
>> +			if (ct->status & IPS_SRC_NAT)
>> +				state |= OVS_CS_F_SRC_NAT;
>> +			if (ct->status & IPS_DST_NAT)
>> +				state |= OVS_CS_F_DST_NAT;
>> +		}
>> +#endif
>> 		zone = nf_ct_zone(ct);
>> 	} else if (post_ct) {
>> 		state = OVS_CS_F_TRACKED | OVS_CS_F_INVALID;
>> @@ -291,7 +337,16 @@ static int ovs_ct_helper(struct sk_buff *skb, u16 proto)
>> 		return NF_DROP;
>> 	}
>> 
>> -	return helper->help(skb, protoff, ct, ctinfo);
>> +	if (helper->help(skb, protoff, ct, ctinfo) != NF_ACCEPT)
>> +		return NF_DROP;
> 
> Return the returned value here instead of hardcoding NF_DROP?
> 

OK

>> +#ifdef CONFIG_NF_NAT_NEEDED
>> +	/* Adjust seqs after helper. */
> 
> A comment on why this is needed would be helpful.
> 

Will add a comment like: /* Needed when a helper adjusts payload size (e.g., FTP PORT command). */

>> +	if (test_bit(IPS_SEQ_ADJUST_BIT, &ct->status)
>> +	    && !nf_ct_seq_adjust(skb, ct, ctinfo, protoff))
>> +		return NF_DROP;
>> +#endif
>> +	return NF_ACCEPT;
> 
>> @@ -377,7 +432,211 @@ static bool skb_nfct_cached(const struct net *net, const struct sk_buff *skb,
>> 	return true;
>> }
>> 
>> -static int __ovs_ct_lookup(struct net *net, const struct sw_flow_key *key,
>> +#ifdef CONFIG_NF_NAT_NEEDED
>> +/* Modeled after nf_nat_ipv[46]_fn().
>> + * range is only used for new, uninitialized NAT state.
>> + * Returns either NF_ACCEPT or NF_DROP. */
>> +static int ovs_ct_nat_execute(struct sk_buff *skb, struct nf_conn *ct,
>> +			      enum ip_conntrack_info ctinfo,
>> +			      const struct nf_nat_range *range,
>> +			      enum nf_nat_manip_type maniptype)
>> +{
>> +	int hooknum, nh_off, err = NF_ACCEPT;
>> +
>> +	nh_off = skb_network_offset(skb);
>> +	skb_pull(skb, nh_off);
>> +
>> +	/* See HOOK2MANIP(). */
>> +	if (maniptype == NF_NAT_MANIP_SRC)
>> +		hooknum = NF_INET_LOCAL_IN; /* Source NAT */
>> +	else
>> +		hooknum = NF_INET_LOCAL_OUT; /* Destination NAT */
>> +
>> +	switch (ctinfo) {
>> +	case IP_CT_RELATED:
>> +	case IP_CT_RELATED_REPLY:
>> +		if (skb->protocol == htons(ETH_P_IP)
>> +		    && ip_hdr(skb)->protocol == IPPROTO_ICMP) {
>> +			if (!nf_nat_icmp_reply_translation(skb, ct, ctinfo,
>> +							   hooknum))
>> +				err = NF_DROP;
>> +			goto push;
>> +		} else if (skb->protocol == htons(ETH_P_IPV6)) {
>> +			__be16 frag_off;
>> +			u8 nexthdr = ipv6_hdr(skb)->nexthdr;
>> +			int hdrlen = ipv6_skip_exthdr(skb,
>> +						      sizeof(struct ipv6hdr),
>> +						      &nexthdr, &frag_off);
>> +
>> +			if (hdrlen >= 0 && nexthdr == IPPROTO_ICMPV6) {
>> +				if (!nf_nat_icmpv6_reply_translation(skb, ct,
>> +								     ctinfo,
>> +								     hooknum,
>> +								     hdrlen))
>> +					err = NF_DROP;
>> +				goto push;
>> +			}
>> +		}
>> +		/* Non-ICMP, fall thru to initialize if needed. */
>> +	case IP_CT_NEW:
>> +		/* Seen it before?  This can happen for loopback, retrans,
>> +		 * or local packets.
>> +		 */
>> +		if (!nf_nat_initialized(ct, maniptype)) {
> 
> Explicit unlikely()?
> 

Normally initialization is needed, but for IP_CT_RELATED the expectation handling may have already initialized NAT. As such, I do not see a strong case for if (likely(!nf_nat_initialized(ct, maniptype)). I’ll see if I can improve the comment, though, as the current one is copied from nf_nat_ipv[46]_fn().

>> +			/* Initialize according to the NAT action. */
>> +			err = (range && range->flags & NF_NAT_RANGE_MAP_IPS)
>> +				/* Action is set up to establish a new
>> +				 * mapping */
>> +				? nf_nat_setup_info(ct, range, maniptype)
>> +				: nf_nat_alloc_null_binding(ct, hooknum);
>> +		}
>> +		break;
>> +
>> +	case IP_CT_ESTABLISHED:
>> +	case IP_CT_ESTABLISHED_REPLY:
>> +		break;
>> +
>> +	default:
>> +		err = NF_DROP;
>> +		goto push;
>> +	}
>> +
>> +	if (err == NF_ACCEPT)
>> +		err = nf_nat_packet(ct, ctinfo, hooknum, skb);
> 
> If you goto push on init failure (IP_CT_NEW branch), then this
> conditional is no longer needed and a more straight forward exception
> handling is seen.
> 

OK.

>> +push:
>> +	skb_push(skb, nh_off);
>> +
>> +	return err;
>> +}
> 
>> +/* Returns NF_DROP if the packet should be dropped, NF_ACCEPT otherwise.
>> + * This action can be used to both NAT and reverse NAT, however, reverse NAT
>> + * can also be done with the conntrack action. */
>> +static int ovs_ct_nat(struct net *net, struct sw_flow_key *key,
>> +		      const struct ovs_conntrack_info *info,
>> +		      struct sk_buff *skb)
>> +{
>> +	enum nf_nat_manip_type maniptype;
>> +	enum ip_conntrack_info ctinfo;
>> +	struct nf_conn *ct;
>> +	int err;
>> +
>> +	/* No NAT action or already NATed? */
>> +	if (!(info->flags & OVS_CT_F_NAT_MASK)
>> +	    || key->ct.state & OVS_CS_F_NAT_MASK)
>> +		return NF_ACCEPT;
>> +
>> +	ct = nf_ct_get(skb, &ctinfo);
>> +	/* Check if an existing conntrack entry may be found for this skb.
>> +	 * This happens when we lose the ct entry pointer due to an upcall.
>> +	 * Don't lookup invalid connections. */
>> +	if (!ct && key->ct.state & OVS_CS_F_TRACKED
>> +	    && !(key->ct.state & OVS_CS_F_INVALID))
>> +		ct = ovs_ct_find_existing(net, &info->zone, info->family, skb,
>> +					  &ctinfo);
>> +	if (!ct || nf_ct_is_untracked(ct))
>> +		/* A NAT action may only be performed on tracked packets. */
>> +		return NF_ACCEPT;
> 
> Braces
> 

Needed due to the comment?

>> +	/* Add NAT extension if not commited yet. */
>> +	if (!nf_ct_is_confirmed(ct)) {
>> +		if (!nf_ct_nat_ext_add(ct))
>> +			return NF_ACCEPT;   /* Can't NAT. */
>> +	}
> 
> &&
> 

Sure.

>> +	/* Determine NAT type.
>> +	 * Check if the NAT type can be deduced from the tracked connection.
>> +	 * Make sure expected traffic is NATted only when commiting. */
>> +	if (info->flags & OVS_CT_F_NAT && ctinfo != IP_CT_NEW
>> +	    && ct->status & IPS_NAT_MASK
>> +	    && (!(ct->status & IPS_EXPECTED_BIT)
>> +		|| info->flags & OVS_CT_F_COMMIT)) {
>> +		/* NAT an established or related connection like before. */
>> +		if (CTINFO2DIR(ctinfo) == IP_CT_DIR_REPLY)
>> +			/* This is the REPLY direction for a connection
>> +			 * for which NAT was applied in the forward
>> +			 * direction.  Do the reverse NAT. */
>> +			maniptype = ct->status & IPS_SRC_NAT
>> +				? NF_NAT_MANIP_DST : NF_NAT_MANIP_SRC;
>> +		else
>> +			maniptype = ct->status & IPS_SRC_NAT
>> +				? NF_NAT_MANIP_SRC : NF_NAT_MANIP_DST;
>> +	}
>> +	else if (info->flags & OVS_CT_F_SRC_NAT)
>> +		maniptype = NF_NAT_MANIP_SRC;
>> +	else if (info->flags & OVS_CT_F_DST_NAT)
>> +		maniptype = NF_NAT_MANIP_DST;
>> +	else
>> +		return NF_ACCEPT; /* Connection is not NATed. */
>> +
>> +	err = ovs_ct_nat_execute(skb, ct, ctinfo, &info->range, maniptype);
>> +
>> +	/* Mark NAT done if successful. */
>> +	if (err == NF_ACCEPT)
>> +		key->ct.state |= (maniptype == NF_NAT_MANIP_SRC)
>> +			? OVS_CS_F_SRC_NAT : OVS_CS_F_DST_NAT;
>> +	return err;
>> +}
>> +#endif
>> +
>> +static int __ovs_ct_lookup(struct net *net, struct sw_flow_key *key,
>> 			   const struct ovs_conntrack_info *info,
>> 			   struct sk_buff *skb)
>> {
> 
> 
>> @@ -538,6 +819,131 @@ static int ovs_ct_add_helper(struct ovs_conntrack_info *info, const char *name,
>> 	return 0;
>> }
>> 
>> +#ifdef CONFIG_NF_NAT_NEEDED
>> +static int parse_nat(const struct nlattr *attr,
>> +		     struct ovs_conntrack_info *info, bool log)
>> +{
>> +	struct nlattr *a;
>> +	int rem;
>> +	bool have_ip_max = false;
>> +	bool have_proto_max = false;
>> +	bool ip_vers = (info->family == NFPROTO_IPV6);
>> +
>> +	nla_for_each_nested(a, attr, rem) {
>> +		static const u16 ovs_nat_attr_lens[OVS_NAT_ATTR_MAX + 1][2] = {
>> +			[OVS_NAT_ATTR_SRC] = {0, 0},
>> +			[OVS_NAT_ATTR_DST] = {0, 0},
>> +			[OVS_NAT_ATTR_IP_MIN] = {sizeof(struct in_addr),
>> +						 sizeof(struct in6_addr)},
>> +			[OVS_NAT_ATTR_IP_MAX] = {sizeof(struct in_addr),
>> +						 sizeof(struct in6_addr)},
>> +			[OVS_NAT_ATTR_PROTO_MIN] = {sizeof(u16),sizeof(u16)},
>> +			[OVS_NAT_ATTR_PROTO_MAX] = {sizeof(u16),sizeof(u16)},
>> +			[OVS_NAT_ATTR_PERSISTENT] = {0, 0},
>> +			[OVS_NAT_ATTR_PROTO_HASH] = {0, 0},
>> +			[OVS_NAT_ATTR_PROTO_RANDOM] = {0, 0},
>> +		};
>> +		int type = nla_type(a);
>> +
>> +		if (type > OVS_NAT_ATTR_MAX) {
>> +			OVS_NLERR(log, "Unknown nat attribute (type=%d, max=%d).\n",
>> +			type, OVS_NAT_ATTR_MAX);
> 
> Formatting

Not readily apparent what you mean here, care to elaborate?

> 
>> +			return -EINVAL;
>> +		}
>> +
>> +		case OVS_NAT_ATTR_IP_MIN:
>> +			nla_memcpy(&info->range.min_addr, a, nla_len(a));
> 
> The length attribute should be sizeof of min_addr like for max_addr
> below.
> 

Right.

>> +			info->range.flags |= NF_NAT_RANGE_MAP_IPS;
>> +			break;
>> +
>> +		case OVS_NAT_ATTR_IP_MAX:
>> +			have_ip_max = true;
>> +			nla_memcpy(&info->range.max_addr, a,
>> +				   sizeof(info->range.max_addr));
>> +			info->range.flags |= NF_NAT_RANGE_MAP_IPS;
>> +			break;
>> +
>> +	}
> 
>> static const struct ovs_ct_len_tbl ovs_ct_attr_lens[OVS_CT_ATTR_MAX + 1] = {
>> 	[OVS_CT_ATTR_COMMIT]	= { .minlen = 0,
>> 				    .maxlen = 0 },
>> @@ -548,7 +954,11 @@ static const struct ovs_ct_len_tbl ovs_ct_attr_lens[OVS_CT_ATTR_MAX + 1] = {
>> 	[OVS_CT_ATTR_LABEL]	= { .minlen = sizeof(struct md_label),
>> 				    .maxlen = sizeof(struct md_label) },
>> 	[OVS_CT_ATTR_HELPER]	= { .minlen = 1,
>> -				    .maxlen = NF_CT_HELPER_NAME_LEN }
>> +				    .maxlen = NF_CT_HELPER_NAME_LEN },
>> +#ifdef CONFIG_NF_NAT_NEEDED
>> +	[OVS_CT_ATTR_NAT]	= { .minlen = 0,
>> +				    .maxlen = 96 }
>> +#endif
> 
> Is the 96 a temporary hack here?
> 

It is not an exact value. It is much better than my temporary hack of 512 was. As trailing garbage is checked for, I’m not sure if this should be very accurately calculated? Maybe it would be better to disable the length checks for this altogether?

>> @@ -607,6 +1017,14 @@ static int parse_ct(const struct nlattr *attr, struct ovs_conntrack_info *info,
>> 				return -EINVAL;
>> 			}
>> 			break;
>> +#ifdef CONFIG_NF_NAT_NEEDED
>> +		case OVS_CT_ATTR_NAT: {
>> +			int err = parse_nat(a, info, log);
>> +			if (err)
>> +				return err;
>> +			break;
>> +		}
>> +#endif
> 
> We should probably bark if user space provides a OVS_CT_ATTR_NAT but the
> kernel is compiled without support for it.
> 

We do issue -EINVAL and log “Unknown conntrack attr” in that case.

>> +#ifdef CONFIG_NF_NAT_NEEDED
>> +static bool ovs_ct_nat_to_attr(const struct ovs_conntrack_info *info,
>> +			       struct sk_buff *skb)
>> +{
>> +	struct nlattr *start;
>> +
>> +	start = nla_nest_start(skb, OVS_CT_ATTR_NAT);
>> +	if (!start)
>> +		return false;
>> +
>> +	if (info->flags & OVS_CT_F_SRC_NAT) {
>> +		if (nla_put_flag(skb, OVS_NAT_ATTR_SRC))
>> +			return false;
>> +	} else if (info->flags & OVS_CT_F_DST_NAT) {
>> +		if (nla_put_flag(skb, OVS_NAT_ATTR_DST))
>> +			return false;
>> +	} else {
>> +		goto out;
> 
> Is the empty nested attribute intended here?

Yes. On netlink interface empty nested attribute (NAT without any arguments) signifies to NAT packets of previously NATted connections (only).

  Jarno


--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 5/5] openvswitch: Interface with NAT.

[Thomas Graf]

On 10/21/15 at 02:04pm, Jarno Rajahalme wrote:
> 
> > On Oct 21, 2015, at 3:59 AM, Thomas Graf <tgraf@suug.ch> wrote:
> > Simplify this with an OVS_NAT_ATTR_FLAGS?
> 
> The use of separate flag attributes was actually intentional, as it makes the interface easier to understand, and code also easier to read.

OK, either is fine with me.

> >> +					  &ctinfo);
> >> +	if (!ct || nf_ct_is_untracked(ct))
> >> +		/* A NAT action may only be performed on tracked packets. */
> >> +		return NF_ACCEPT;
> > 
> > Braces
> > 
> 
> Needed due to the comment?

The compiler would be fine but most other places like this seem to
put braces on for this single comment + single statement case.

> >> +		if (type > OVS_NAT_ATTR_MAX) {
> >> +			OVS_NLERR(log, "Unknown nat attribute (type=%d, max=%d).\n",
> >> +			type, OVS_NAT_ATTR_MAX);
> > 
> > Formatting
> 
> Not readily apparent what you mean here, care to elaborate?

The argument list should be indented up to the (.

> >> +#ifdef CONFIG_NF_NAT_NEEDED
> >> +	[OVS_CT_ATTR_NAT]	= { .minlen = 0,
> >> +				    .maxlen = 96 }
> >> +#endif
> > 
> > Is the 96 a temporary hack here?
> > 
> 
> It is not an exact value. It is much better than my temporary hack of 512 was. As trailing garbage is checked for, I???m not sure if this should be very accurately calculated? Maybe it would be better to disable the length checks for this altogether?

I would just drop the maxlen then. The nested content should be
verified separately anyway later on.

> > We should probably bark if user space provides a OVS_CT_ATTR_NAT but the
> > kernel is compiled without support for it.
> > 
> 
> We do issue -EINVAL and log ???Unknown conntrack attr??? in that case.

Misread then, sorry.