[ovs-dev] Treat: d...@openvswitch.org

[Hiro KIYOKO]

Greetings,
I have decided to contact you privately via your email (d...@openvswitch.org) 
for an inheritance funds deposited with your matching surname.Respond for 
details. 
Dr. Hiro KIYOKO


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] pinctrl: Be more careful in parsing DHCPv6 and DNS.

[Greg Rose]

On Sat, 2017-05-20 at 16:57 -0700, Ben Pfaff wrote:
> pinctrl_handle_put_dhcpv6_opts() and pinctrl_handle_dns_lookup() were not
> checking that a full UDP header was present before reading its udp_len
> field.  This patch fixes the problem.
> 
> I don't think that the system as a whole, as normally installed, was
> exploitable.  This is because pinctrl processes a packet sent to it from
> ovs-vswitchd.  ovs-vswitchd only sends it UDPv6 DHCPv6 packets.  To
> determine that the packets are DHCPv6, ovs-vswitchd has to see its UDP port
> numbers are those for DHCPv6, and it's only going to see that if an entire
> UDP header is present.  Therefore, this part of pinctrl will only ever
> process a packet for which udp_len is there.
> 
> I believe that pinctrl_handle_dns_lookup() is similar.
> 
> Reported-by: Bhargava Shastry 
> Signed-off-by: Ben Pfaff 
> ---
>  ovn/controller/pinctrl.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
> index 9ad413376736..225f6a7563dc 100644
> --- a/ovn/controller/pinctrl.c
> +++ b/ovn/controller/pinctrl.c
> @@ -526,6 +526,11 @@ pinctrl_handle_put_dhcpv6_opts(
>  
>  struct udp_header *in_udp = dp_packet_l4(pkt_in);
>  const uint8_t *in_dhcpv6_data = dp_packet_get_udp_payload(pkt_in);
> +if (!in_udp || !in_dhcpv6_data) {
> +VLOG_WARN_RL(, "truncated dhcpv6 packet");
> +goto exit;
> +}
> +
>  uint8_t out_dhcpv6_msg_type;
>  switch(*in_dhcpv6_data) {
>  case DHCPV6_MSG_TYPE_SOLICIT:
> @@ -710,6 +715,10 @@ pinctrl_handle_dns_lookup(
>  
>  /* Extract the DNS header */
>  struct dns_header const *in_dns_header = 
> dp_packet_get_udp_payload(pkt_in);
> +if (!in_dns_header) {
> +VLOG_WARN_RL(, "truncated dns packet");
> +goto exit;
> +}
>  
>  /* Check if it is DNS request or not */
>  if (in_dns_header->lo_flag & 0x80) {

LGTM

Acked-by: Greg Rose 

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ofp-util: Fix buffer overrread in ofputil_pull_queue_get_config_reply10().

[Greg Rose]

On Sat, 2017-05-20 at 16:41 -0700, Ben Pfaff wrote:
> msg->size isn't the relevant measurement here because we're only supposed
> to read 'len' bytes.  Reading more than that causes 'len' to underflow to a
> large number at the end of the loop.
> 
> Reported-by: Bhargava Shastry 
> Signed-off-by: Ben Pfaff 
> ---
>  lib/ofp-util.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/ofp-util.c b/lib/ofp-util.c
> index bdf89b6c3017..f05ca398c13e 100644
> --- a/lib/ofp-util.c
> +++ b/lib/ofp-util.c
> @@ -2610,7 +2610,7 @@ ofputil_pull_queue_get_config_reply10(struct ofpbuf 
> *msg,
>  
>  hdr = ofpbuf_at_assert(msg, 0, sizeof *hdr);
>  prop_len = ntohs(hdr->len);
> -if (prop_len < sizeof *hdr || prop_len > msg->size || prop_len % 8) {
> +if (prop_len < sizeof *hdr || prop_len > len || prop_len % 8) {
>  return OFPERR_OFPBRC_BAD_LEN;
>  }
>  

Yikes.  Good catch.

Acked-by: Greg Rose 

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [patch_v1] flow.c: refactor ct_orig_tuple check in miniflow_extract.

[Greg Rose]

On Sat, 2017-05-20 at 11:09 -0700, Darrell Ball wrote:
> The checks to populate ct_orig_tuple in miniflow_extract
> includes recirc_id being non-zero.  This is changed here
> to populate the ct_orig_tuple fields based only on ct_state
> per the logic of the design.
> 
> Signed-off-by: Darrell Ball 
> ---
>  lib/flow.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/flow.c b/lib/flow.c
> index 7f98a46..5ef783a 100644
> --- a/lib/flow.c
> +++ b/lib/flow.c
> @@ -615,12 +615,15 @@ miniflow_extract(struct dp_packet *packet, struct 
> miniflow *dst)
>  }
>  miniflow_push_uint32(mf, dp_hash, md->dp_hash);
>  miniflow_push_uint32(mf, in_port, odp_to_u32(md->in_port.odp_port));
> -if (md->recirc_id || md->ct_state) {
> +if (md->ct_state) {
>  miniflow_push_uint32(mf, recirc_id, md->recirc_id);
>  miniflow_push_uint8(mf, ct_state, md->ct_state);
>  ct_nw_proto_p = miniflow_pointer(mf, ct_nw_proto);
>  miniflow_push_uint8(mf, ct_nw_proto, 0);
>  miniflow_push_uint16(mf, ct_zone, md->ct_zone);
> +} else if (md->recirc_id) {
> +miniflow_push_uint32(mf, recirc_id, md->recirc_id);
> +miniflow_pad_to_64(mf, recirc_id);
>  }
>  
>  if (md->ct_state) {

That looks right to me if the assertion in the commit statement is
correct.

Reviewed-by: Greg Rose 

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] pinctrl: Be more careful in parsing DHCPv6 and DNS.

[Ben Pfaff]

pinctrl_handle_put_dhcpv6_opts() and pinctrl_handle_dns_lookup() were not
checking that a full UDP header was present before reading its udp_len
field.  This patch fixes the problem.

I don't think that the system as a whole, as normally installed, was
exploitable.  This is because pinctrl processes a packet sent to it from
ovs-vswitchd.  ovs-vswitchd only sends it UDPv6 DHCPv6 packets.  To
determine that the packets are DHCPv6, ovs-vswitchd has to see its UDP port
numbers are those for DHCPv6, and it's only going to see that if an entire
UDP header is present.  Therefore, this part of pinctrl will only ever
process a packet for which udp_len is there.

I believe that pinctrl_handle_dns_lookup() is similar.

Reported-by: Bhargava Shastry 
Signed-off-by: Ben Pfaff 
---
 ovn/controller/pinctrl.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index 9ad413376736..225f6a7563dc 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -526,6 +526,11 @@ pinctrl_handle_put_dhcpv6_opts(
 
 struct udp_header *in_udp = dp_packet_l4(pkt_in);
 const uint8_t *in_dhcpv6_data = dp_packet_get_udp_payload(pkt_in);
+if (!in_udp || !in_dhcpv6_data) {
+VLOG_WARN_RL(, "truncated dhcpv6 packet");
+goto exit;
+}
+
 uint8_t out_dhcpv6_msg_type;
 switch(*in_dhcpv6_data) {
 case DHCPV6_MSG_TYPE_SOLICIT:
@@ -710,6 +715,10 @@ pinctrl_handle_dns_lookup(
 
 /* Extract the DNS header */
 struct dns_header const *in_dns_header = dp_packet_get_udp_payload(pkt_in);
+if (!in_dns_header) {
+VLOG_WARN_RL(, "truncated dns packet");
+goto exit;
+}
 
 /* Check if it is DNS request or not */
 if (in_dns_header->lo_flag & 0x80) {
-- 
2.10.2

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] ofp-util: Fix buffer overrread in ofputil_pull_queue_get_config_reply10().

[Ben Pfaff]

msg->size isn't the relevant measurement here because we're only supposed
to read 'len' bytes.  Reading more than that causes 'len' to underflow to a
large number at the end of the loop.

Reported-by: Bhargava Shastry 
Signed-off-by: Ben Pfaff 
---
 lib/ofp-util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/ofp-util.c b/lib/ofp-util.c
index bdf89b6c3017..f05ca398c13e 100644
--- a/lib/ofp-util.c
+++ b/lib/ofp-util.c
@@ -2610,7 +2610,7 @@ ofputil_pull_queue_get_config_reply10(struct ofpbuf *msg,
 
 hdr = ofpbuf_at_assert(msg, 0, sizeof *hdr);
 prop_len = ntohs(hdr->len);
-if (prop_len < sizeof *hdr || prop_len > msg->size || prop_len % 8) {
+if (prop_len < sizeof *hdr || prop_len > len || prop_len % 8) {
 return OFPERR_OFPBRC_BAD_LEN;
 }
 
-- 
2.10.2

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v5] netdev-dpdk: fix ifindex assignment for DPDK ports

[Ben Pfaff]

On Fri, May 19, 2017 at 10:19:10AM +0200, Przemyslaw Lal wrote:
> On 18/05/2017 22:41, Ben Pfaff wrote:
> 
> >On Thu, May 18, 2017 at 06:09:21PM +, Darrell Ball wrote:
> >>
> >>On 4/4/17, 5:47 PM, "Darrell Ball"  wrote:
> >>
> >> On 4/4/17, 3:09 AM, "Lal, PrzemyslawX"  
> >> wrote:
> >> On 04/04/2017 06:14, Darrell Ball wrote:
> >> >
> >> > On 4/3/17, 5:27 AM, "ovs-dev-boun...@openvswitch.org on behalf 
> >> of Przemyslaw Lal"  >> przemyslawx@intel.com> wrote:
> >> >
> >> >  In current implementation port_id is used as an ifindex for 
> >> all netdev-dpdk
> >> >  interfaces.
> >> >
> >> >  For physical DPDK interfaces using port_id as ifindex 
> >> causes that '0' is set as
> >> >  ifindex for 'dpdk0' interface, '1' for 'dpdk1' and so on. 
> >> For the DPDK vHost
> >> >  interfaces ifindexes are not even assigned (0 is used by 
> >> default) due to the
> >> >  fact that vHost ports don't use port_id field from the DPDK 
> >> library.
> >> >
> >> >  This causes multiple negative side-effects. First of all 0 
> >> is an invalid
> >> >  ifindex value. The other issue is possible overlapping of 
> >> 'dpdkX' interfaces
> >> >  ifindex values with the ifindexes of kernel space 
> >> interfaces which may cause
> >> >  problems in any external tools that use those values. 
> >> Neither 'dpdk0', nor any
> >> >  DPDK vHost interfaces are visible in sFlow collector tools, 
> >> as all interfaces
> >> >  with ifindexes smaller than 1 are ignored.
> >> >
> >> >  Proposed solution to these issues is to calculate a hash of 
> >> interface's name
> >> >  and use calculated value as an ifindex. This way interfaces 
> >> keep their
> >> >  ifindexes during OVS-DPDK restarts, ports re-initialization 
> >> events, etc., show
> >> >  up in sFlow collectors and meet RFC 2863 specification 
> >> regarding re-using
> >> >  ifindex values by the same virtual interfaces and maximum 
> >> ifindex value.
> >> >
> >> >  Signed-off-by: Przemyslaw Lal 
> >> >  ---
> >> >   lib/netdev-dpdk.c | 6 +-
> >> >   1 file changed, 5 insertions(+), 1 deletion(-)
> >> >
> >> >  diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> >> >  index ddc651b..687b0a5 100644
> >> >  --- a/lib/netdev-dpdk.c
> >> >  +++ b/lib/netdev-dpdk.c
> >> >  @@ -2215,7 +2215,11 @@ netdev_dpdk_get_ifindex(const struct 
> >> netdev *netdev)
> >> >   int ifindex;
> >> >
> >> >   ovs_mutex_lock(>mutex);
> >> >  -ifindex = dev->port_id;
> >> >  +/* Calculate hash from the netdev name. Ensure that 
> >> ifindex is a 24-bit
> >> >  + * postive integer to meet RFC 2863 recommendations.
> >> >  + */
> >> >  +uint32_t h = hash_string(netdev->name, 0);
> >> >  +ifindex = (int)(h % 0xfe + 1);
> >> >
> >> >
> >> > If user configuration was supported, enforcing uniqueness would 
> >> be the
> >> > responsibility of the user.
> >> This was already discussed on this mailing list and outcome was 
> >> that while hash is not perfect, it is the best solution for now.
> >> Also, please keep in mind that names of the physical DPDK devices 
> >> and dpdkvhostuser interfaces are configurable, so user can still enforce
> >> uniqueness.
> >> I know uniqueness could be enforced by trial and error of name 
> >> selection.
> >> I saw the comment
> >>  “At some point, with vhost-pmd we will have port_ids also for vhost 
> >> interfaces.
> >>Maybe we can revisit this approach when that becomes available.”
> >> If others are fine, then so am I.
> >>
> >>The uniqueness issue is understood and there is a workaround capability to
> >>address it.
> >>
> >>Let us just fold the patch in, since the patch has been out for long enough 
> >>to
> >>receive feedback.
> >>
> >>Acked by: Darrell Ball 
> >Thanks Przemyslaw and Darrell.  I applied this to master.  I simplified
> >the code since the cast to int was a no-op (it does the same thing as
> >the conversion implied by the assignment:
> >
> >--8<--cut here-->8--
> >
> >From: Przemyslaw Lal 
> >Date: Mon, 3 Apr 2017 13:27:47 +0100
> >Subject: [PATCH] netdev-dpdk: fix ifindex assignment for DPDK ports
> >
> >In current implementation port_id is used as an ifindex for all netdev-dpdk
> >interfaces.
> >
> >For physical DPDK interfaces using 

Re: [ovs-dev] [PATCH] netflow: Fix memory leak in netflow_unref.

[Ben Pfaff]

On Sat, May 20, 2017 at 06:33:03PM +0800, Yunjian Wang wrote:
> The memory leak was triggered each time on calling
> netflow_unref with containing netflow_flows.
> 
> Signed-off-by: Yunjian Wang 
> ---
>  ofproto/netflow.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/ofproto/netflow.c b/ofproto/netflow.c
> index 55f7814..6bcbfe5 100644
> --- a/ofproto/netflow.c
> +++ b/ofproto/netflow.c
> @@ -413,6 +413,7 @@ netflow_unref(struct netflow *nf)
>  atomic_count_dec(_count);
>  collectors_destroy(nf->collectors);
>  ofpbuf_uninit(>packet);
> +hmap_destroy(>flows);
>  free(nf);
>  }
>  }

Thank you for the bug fix, which appears correct.

However, going a bit further, I don't see a guarantee that 'flows' is
empty when the object is destroyed.  Should there also be a loop that
removes and destroys any remaining flows?

Thanks,

Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ofproto-dpif-ipfix: add support for per-flow TCP counters

[Ben Pfaff]

On Fri, May 19, 2017 at 10:57:17AM +, Szczerbik, PrzemyslawX wrote:
> 
> 
> > -Original Message-
> > From: Ben Pfaff [mailto:b...@ovn.org]
> > Sent: Friday, May 19, 2017 4:39 AM
> > To: Szczerbik, PrzemyslawX 
> > Cc: d...@openvswitch.org
> > Subject: Re: [ovs-dev] [PATCH] ofproto-dpif-ipfix: add support for per-flow 
> > TCP
> > counters
> > 
> > On Thu, May 11, 2017 at 11:13:27AM +0100, Przemyslaw Szczerbik wrote:
> > > This patch implements support for per-flow TCP IPFIX counters. It's based 
> > > on
> > RFC
> > > 5102, section 5.10.
> > >
> > > Signed-off-by: Przemyslaw Szczerbik 
> > 
> > Thanks for working on IPFIX!
> > 
> > I suggest folding in an update to NEWS to mention this new feature,
> 
> Sure thing, I can update NEWS file.
> > e.g.:
> > 
> > diff --git a/NEWS b/NEWS
> > index 7a2b185bbd84..ab2faec02e57 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -10,7 +10,9 @@ Post-v2.7.0
> > Log level can be changed in a usual OVS way using
> > 'ovs-appctl vlog' commands for 'dpdk' module. Lower bound
> > still can be configured via extra arguments for DPDK EAL.
> > -   - IPFIX now provides additional counters for totals since startup.
> > +   - IPFIX now provides additional counters:
> > + * Total counters since metering process startup.
> > + * Per-flow TCP flag counters.
> > - New support for multiple VLANs (802.1ad or "QinQ"), including a new
> >   "dot1q-tunnel" port VLAN mode.
> > - In ovn-vsctl and vtep-ctl, record UUIDs in commands may now be
> > 
> > However, I am worried about this feature.  I suspect that it does not
> > report correct statistics.  It infers that, if a flow's tcp_flags
> > contains a given flag, then that flag has been seen on every packet.
> > But this is incorrect: in fact, it only means that the flag has been
> > seen on at least one packet.
> 
> Flow represents exact content of the packet that is going to be sampled.
> If packet, is it in fact a TCP packet, then tcp_flags member will contain 
> appropriate values.
> I'm assuming that all matched packets had exactly the same flags set, which 
> really boils down to a single issue - IPFIX counters are based on probability.
> 
> Sampling probability is used to approximate number of matched packets, which 
> is then used as a baseline for majority of other counters.
> For instance, octet_delta_count counter implementation assumes that all 
> matched packets have the same length.
> 
> I run a few tests on my patch and it worked quite well.

OK, I understand the context now.  Thanks for the explanation.

I applied this to master.  Thank you!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC] packets: Do not initialize ct_orig_tuple.

[Darrell Ball]

On 5/19/17, 1:15 PM, "Joe Stringer"  wrote:

On 17 May 2017 at 17:54, Joe Stringer  wrote:
> On 17 May 2017 at 16:26, Darrell Ball  wrote:
>>
>>
>> On 5/17/17, 2:19 PM, "Joe Stringer"  wrote:
>>
>> On 16 May 2017 at 21:01, Darrell Ball  wrote:
>> >
>> >
>> > On 5/15/17, 6:00 AM, "ovs-dev-boun...@openvswitch.org on behalf of 
Bodireddy, Bhanuprakash"  wrote:
>> >
>> > >Commit daf4d3c18da4("odp: Support conntrack orig tuple key.") 
introduced
>> > >new fields in struct 'pkt_metadata'.  pkt_metadata_init() is 
called for every
>> > >packet in the userspace datapath.  When testing a simple 
single flow case with
>> > >DPDK, we observe a lower throughput after the above commit 
(it was 14.88
>> > >Mpps before, it is 13 Mpps after).
>> > >
>> > >This patch skips initializing ct_orig_tuple in 
pkt_metadata_init().
>> > >It should be enough to initialize ct_state, because nobody 
should look at
>> > >ct_orig_tuple unless ct_state is != 0.
>> > >
>> > >CC: Jarno Rajahalme 
>> > >Signed-off-by: Daniele Di Proietto 
>> > >---
>> > >I'm sending this as an RFC because I didn't check very 
carefully if we can really
>> > >avoid initializing ct_orig_tuple.
>> > >
>> > >Maybe there are better solutions to this problem.
>> > >---
>> > > lib/packets.h | 2 +-
>> > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > >diff --git a/lib/packets.h b/lib/packets.h index 
a5a483bc8..6f1791c7a 100644
>> > >--- a/lib/packets.h
>> > >+++ b/lib/packets.h
>> > >@@ -129,7 +129,7 @@ pkt_metadata_init(struct pkt_metadata *md,
>> > >odp_port_t port)
>> > > /* It can be expensive to zero out all of the tunnel 
metadata. However,
>> > >  * we can just zero out ip_dst and the rest of the data 
will never be
>> > >  * looked at. */
>> > >-memset(md, 0, offsetof(struct pkt_metadata, in_port));
>> > >+memset(md, 0, offsetof(struct pkt_metadata, 
ct_orig_tuple));
>> > > md->tunnel.ip_dst = 0;
>> > > md->tunnel.ipv6_dst = in6addr_any;
>> > >
>> >
>> > It's been a while this RFC patch has been submitted to fix 
performance drop on Master. This indeed fixes the OvS-DPDK performance drop 
that was introduced by the conntrack commit.
>> > Is there a better fix than what is suggested above?
>> >
>> >
>> > This affects both kernel and userspace.
>> > I tested this on both datapaths.
>> > LGTM
>>
>> How do we make sure that ct_orig_tuple isn't used uninitialized? Do 
we
>> need to zero out the ct_orig_tuple proto?
>>
>> There are a couple places where we explicitly set or reset the pkt 
metadata ct_orig_tuple;
>> one is in pkt_metadata_from_flow().
>>
>> I know there is a check for ct_orig_tuple proto in 
odp_key_from_pkt_metadata()
>> Can you find a case where can run this code without a set or reset of 
ct_orig_tuple pkt md
>> or you are not sure ?
>
> I wasn't sure, and I didn't see a response to the question that
> Daniele asked below the dashes in the original submission.
>
> Is miniflow_extract() safe wrt this? Seems like plausibly if the
> recirc_id is nonzero but there is no CT state (because, eg, bonds, or
> MPLS pop to IP, etc) it could end up populating the miniflow with
> garbage. In particular the path from emc_processing() seems suspect.

Perhaps this is actually OK, because the ct_state would be initialized
to zero in pkt_metadata_init(), and the classifier would never look at
ct_orig_tuple unless the ct_state is valid (according to the
ovs-fields(7) documentation). In which case, it shouldn't(?) matter
that garbage is written to the miniflow.

I am glad you agree.

The way I was reasoning about this is:
ct_orig_tuple should not be looked at unless the connection tracker
has seen the packet. It would be a bug, otherwise.

Alternatively if md_is_valid
(eg, because it was recirculated),

s/eg/i.e./ for this code path

 then it's up to the other callers
to ensure that md.ct_state was properly initialized. Effectively this
is done by the write_ct_md() function.

originates from conntrack in general.

I wonder though if actually the miniflow_extract() "ct_nw_proto_p"
initialization should only occur if the md->ct_state is valid. 
That could save a few 

[ovs-dev] [patch_v1] flow.c: refactor ct_orig_tuple check in miniflow_extract.

[Darrell Ball]

The checks to populate ct_orig_tuple in miniflow_extract
includes recirc_id being non-zero.  This is changed here
to populate the ct_orig_tuple fields based only on ct_state
per the logic of the design.

Signed-off-by: Darrell Ball 
---
 lib/flow.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/flow.c b/lib/flow.c
index 7f98a46..5ef783a 100644
--- a/lib/flow.c
+++ b/lib/flow.c
@@ -615,12 +615,15 @@ miniflow_extract(struct dp_packet *packet, struct 
miniflow *dst)
 }
 miniflow_push_uint32(mf, dp_hash, md->dp_hash);
 miniflow_push_uint32(mf, in_port, odp_to_u32(md->in_port.odp_port));
-if (md->recirc_id || md->ct_state) {
+if (md->ct_state) {
 miniflow_push_uint32(mf, recirc_id, md->recirc_id);
 miniflow_push_uint8(mf, ct_state, md->ct_state);
 ct_nw_proto_p = miniflow_pointer(mf, ct_nw_proto);
 miniflow_push_uint8(mf, ct_nw_proto, 0);
 miniflow_push_uint16(mf, ct_zone, md->ct_zone);
+} else if (md->recirc_id) {
+miniflow_push_uint32(mf, recirc_id, md->recirc_id);
+miniflow_pad_to_64(mf, recirc_id);
 }
 
 if (md->ct_state) {
-- 
1.9.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] hi

[Eamon Mangan]

Nice to meet you, hope all is well with you and how are you enjoying your day? 
I'm M  Jessica Umeir, I am a U.S. Army officer, from the United States of 
America, I am supportive and caring, i like swimming and cooking, i am gentle 
although i am a soldier but i am kind, looking for a good friend, I saw your 
email in the web directory, I would like to establish a mutual friendship with 
you, let us continue our conversation through my private email 
(ebuka221...@gmail.com)  am expecting to hear from you so that I will give you 
my pictures, and give you more details about myself.

Jessica



Encantado de conocerte, espero que todo esté bien contigo y cómo estás 
disfrutando tu día? Soy M Jessica Umeir, soy un oficial del ejército 
estadounidense, de los Estados Unidos de América, soy solidario y cariñoso, me 
gusta nadar y cocinarme, soy amable aunque soy un soldado pero soy amable, en 
busca de una buena Amigo, vi su correo electrónico en el directorio web, me 
gustaría establecer una amistad mutua con usted, vamos a continuar nuestra 
conversación a través de mi correo electrónico privado (ebuka221...@gmail.com) 
estoy esperando escuchar de usted para que yo le daré Mis fotos, y darle más 
detalles sobre mí.

Jessica

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] netflow: Fix memory leak in netflow_unref.

[Yunjian Wang]

The memory leak was triggered each time on calling
netflow_unref with containing netflow_flows.

Signed-off-by: Yunjian Wang 
---
 ofproto/netflow.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ofproto/netflow.c b/ofproto/netflow.c
index 55f7814..6bcbfe5 100644
--- a/ofproto/netflow.c
+++ b/ofproto/netflow.c
@@ -413,6 +413,7 @@ netflow_unref(struct netflow *nf)
 atomic_count_dec(_count);
 collectors_destroy(nf->collectors);
 ofpbuf_uninit(>packet);
+hmap_destroy(>flows);
 free(nf);
 }
 }
-- 
1.8.3.1


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev