gmane.network.openvswitch.devel

Re: [ovs-discuss] kernel crash - openvswitch_mod

Jesse Gross — 2012-05-25T20:31:28

I don't think that looking at assembler dumps is the best way to go
about this.  The original poster also mentioned that he saw this with
the Linux bridge so if you're looking at the same thing then OVS code
is probably not the issue.

Re: [ovs-discuss] kernel crash - openvswitch_mod

Luiz Ozaki — 2012-05-25T18:59:04

Hmmm... Yea, Im trying to do some debug on this.

I did the objdump, I think I found the line but I got stuck.

<0>EIP: [<f1f0cd29>] queue_userspace_packet+0x19/0x310 [openvswitch_mod] 
SS:ESP 0069:ef935af4

00001d10 <queue_userspace_packet>:
     1d10:   55                      push   %ebp
     1d11:   89 e5                   mov    %esp,%ebp
     1d13:   57                      push   %edi
     1d14:   56                      push   %esi
     1d15:   53                      push   %ebx
     1d16:   83 ec 30                sub    $0x30,%esp
     1d19:   89 45 d4                mov    %eax,0xffffffd4(%ebp)
     1d1c:   89 55 d0                mov    %edx,0xffffffd0(%ebp)
     1d1f:   89 4d cc                mov    %ecx,0xffffffcc(%ebp)
     1d22:   c7 45 d8 00 00 00 00    movl   $0x0,0xffffffd8(%ebp)
     1d29:   66 83 ba 8c 00 00 00    cmpw   $0x0,0x8c(%edx) <========= 
This line
     1d30:   00
     1d31:   0f 85 e7 01 00 00       jne    1f1e 
<queue_userspace_packet+0x20e>
     1d37:   8b 75 d0                mov    0xffffffd0(%ebp),%esi
     1d3a:   bb e5 ff ff ff          mov    $0xffffffe5,%ebx
     1d3f:   8b 46 50                mov    0x50(%esi),%eax
     1d42:   83 c0 04                add    $0x4,%eax
     1d45:   3d ff ff 00 00          cmp    $0xffff,%eax
     1d4a:   0f 8f b5 01 00 00       jg     1f05 
<queue_userspace_packet+0x1f5>

OVS 1.4.0

I tried to compile the *.s files to put the asm() but it's not creating 
those files.

Any help on the next steps ?

Re: [PATCH 05/21] vswitchd: Add add_tunnel_ports()

Ben Pfaff — 2012-05-25T17:18:47

This seems reasonable at a glance.  There are bits I might quibble
with as this gets closer, but the structure seems reasonable.

Re: MPLS and VLAN QinQ patch

2012-05-25T16:42:19

-----Original Message-----
From: Ben Pfaff [mailto:blp-l0M0P4e3n4LQT0dZR+AlfA< at >public.gmane.org] 
Sent: Friday, May 25, 2012 9:32 AM
To: Kerur, Ravi
Cc: dev-yBygre7rU0TnMu66kgdUjQ< at >public.gmane.org
Subject: Re: [ovs-dev] MPLS and VLAN QinQ patch

On Fri, May 25, 2012 at 01:24:00AM +0200, Ravi.Kerur-+tb+GG71Y8BBDgjK7y7TUQ< at >public.gmane.org wrote:

Yes, that's what I had in mind.

<rk> That's the approach I have taken for kernel code. For userspace, I just thought of using packet->l3 which is readily available(one can argue the same for kernel as well with skb's). Anyways I will modify the code.

Thanks,
Ravi

Thanks,

Ben.

Re: MPLS and VLAN QinQ patch

Ben Pfaff — 2012-05-25T16:31:56

Yes, that's what I had in mind.

Thanks,

Ben.

Re: MPLS and VLAN QinQ patch

Ben Pfaff — 2012-05-25T16:30:26

OK, thanks.

It's entirely possible that we should fine-tune how rate-limiting
works for invalid_ttl (both IP and MPLS).

Re: MPLS and VLAN QinQ patch

2012-05-25T16:27:11

Sorry for the confusion, I was not questioning your comments they are valid and I have addressed them. While making changes it occurred to me how invalid_ttl is handled in the controller, will it suffer from similar ttl expiry attack and should rate-limit sending invalid_ttl to controller? Since OVS can rate-limit and invalid_ttl for ip doesn't rate-limit, will leave the code for mpls as it is.

-----Original Message-----
From: Ben Pfaff [mailto:blp-l0M0P4e3n4LQT0dZR+AlfA< at >public.gmane.org] 
Sent: Friday, May 25, 2012 9:14 AM
To: Kerur, Ravi
Cc: dev-yBygre7rU0TnMu66kgdUjQ< at >public.gmane.org
Subject: Re: [ovs-dev] MPLS and VLAN QinQ patch

On Fri, May 25, 2012 at 05:49:30PM +0200, Ravi.Kerur-+tb+GG71Y8BBDgjK7y7TUQ< at >public.gmane.org wrote:

I don't see how your comment is related to mine.  Mine is about properly handling double-decrement to zero.  Yours is about handling decrement to zero in general.

The main rationale is that OpenFlow says to do that.  I wasn't behind that decision.  You could ask the people who were, if you join the Open Network Foundation "extensibility" mailing list.

There are other dubious OpenFlow choices regarding MPLS, also.

Open vSwitch can limit the rate at which "packet-in"s are sent to the controller.  This can mitigate the amount of work the controller has to do.

Re: MPLS and VLAN QinQ patch

Ben Pfaff — 2012-05-25T16:13:35

I don't see how your comment is related to mine.  Mine is about
properly handling double-decrement to zero.  Yours is about handling
decrement to zero in general.

The main rationale is that OpenFlow says to do that.  I wasn't behind
that decision.  You could ask the people who were, if you join the
Open Network Foundation "extensibility" mailing list.

There are other dubious OpenFlow choices regarding MPLS, also.

Open vSwitch can limit the rate at which "packet-in"s are sent to the
controller.  This can mitigate the amount of work the controller has
to do.

Re: MPLS and VLAN QinQ patch

2012-05-25T15:49:30

I would like to revisit this topic...

ofproto-dpif.c
--------------

I think that say, two, dec_mpls_ttl actions in a single flow, starting from a TTL of, say, 2, will fail to detect reaching TTL 0.  Also, the existing implementation of dec ttl for IP stop translating actions after reaching TTL 0.  Presumably the MPLS implementation should do the same.

<rk> In traditional  network for invalid TTLs(0 and 1) ICMP error msg has to be sent and a TTL expiry handling attack can be easily envisioned with this. Routers usually mitigate this attack via access-list to drop packets with TTL 0/1 (assumption is that network applications usually send with larger TTL value and it's highly unlikely that a packet will ever arrive with TTL 0/1) or rate-limit sending ICMP error message and can be evidenced via traceroute. In OVS, I see every invalid TTL(both IP and MPLS) packet is sent to the controller and I assume controller does rate control on sending ICMP error message  or drop the packet  or do additional processing?  It's quite unclear to me what's the rationale to send every invalid TTL packet to controller with knowing what it does, can you please
  clarify?

Thanks,
Ravi

Re: [ovs-discuss] kernel crash - openvswitch_mod

Jesse Gross — 2012-05-25T14:05:11

No, the caller will perform that check.  rpl_skb_gso_segment() is a
compatibility replacement for skb_gso_segment() on older kernels.  It
needs to return a pointer, not an error code.
_______________________________________________
dev mailing list
dev< at >openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-discuss] kernel crash - openvswitch_mod

Luiz Ozaki — 2012-05-25T10:58:56

Changed to Dev Mailing...

We might have found the problem in the kernel function 
"skb_gso_segment"... Doing some test to check.

Anyways, looking at the OVS code I see this skb_gso_segment called in 
other places and handled in different ways:
./datapath/vport-netdev.c
./datapath/tunnel.c
./datapath/datapath.c

./datapath/linux/compat/netdevice.c

Doesn't rpl_skb_gso_segment need to check IS_ERR and return the PTR_ERR 
if it's true ?

Does it make sense ?

Something like this:

diff --git a/datapath/linux/compat/netdevice.c 
b/datapath/linux/compat/netdevice.c
index 9e92eeb..7974e8c 100644
--- a/datapath/linux/compat/netdevice.c
+++ b/datapath/linux/compat/netdevice.c
< at >< at > -95,6 +95,9 < at >< at > struct sk_buff *rpl_skb_gso_segment(struct sk_buff 
*skb, u32 features)

         skb_gso = skb_gso_segment(skb, features);
         skb->protocol = skb_proto;
+       if (IS_ERR(skb))
+               return PTR_ERR(skb);
+
         return skb_gso;
  }
  #endif /* kernel version < 2.6.38 */

87% Off TESOL Teaching Certification Course

TeacherBuys — 2012-05-25T10:56:06

$79 for a 150-Hour Specialist TESOL/TEFL Course from Global Leadership  
College ($599 Value)
Please go to http://www.teacherbuys.com/nationwide/ 
for more details.

Certificate awarded upon completion of course

-150 hours of training from the comfort of your own home or office
-Information including TESOL/TEFL theory and practice
-100% comprehensive
-Easy to follow classes
-Get your certificate in as little as 8 weeks
-Learn and study at your own pace
-A solid base for a career
-Makes a great gift!

Expand your mind, and your future, with today's TeacherBuy!
If you prefer not to receive future Daily Deal emails, you can always  
send email to unsubscribe-7fvPQkbVUmAOZTnbMYOWKg< at >public.gmane.org to unsubscribe.

Hello my dear,

Mercy Joseph — 2012-05-25T09:54:39


Hello my dear,

With great respect and honour i am writing to you this mail.Please pardon me if i interfere into your privacy,My name is Miss Mercy Joseph Young, 23 years of age, i am the only daughter of Late Dr Joseph Young from Ivory Coast, my father was the owner of Joseph Cocoa Industries Limited and he was a personal adviser to our former Head of State (late General Robert Guei). My purpose of contacting you is first, i want to know more about you so that i will know the areas you will be of assistance to my needs. I have some reasonable amount of moneys which my parents left for me before their untimely death, i want to plan for my future by investing this money in a good and profitable business but I don’t know where to start and that is why I got interested in contacting you hoping that you will be kind a sincere to me by leading me through the right process to see that this money is not wasted because it is my only hope of planning for my future .Please,
 don’t be surprise or scared because all my words are very sincere and I will prove it as we communicate along.



From your contact i observed you are an important personality before i made up my mind to contact you.Though i don't know you in person but your assurance can motivate me to tell you everything about the money i want to invest and to go into this investment with by my side . i have no experience i terms of any foreign investment but I wish you could be honest to me because i am afraid of choosing the wrong business or loose this money . As soon as i receive your respond we will decide on the next line of action, remember you caught my attention when I saw your contact and that was why i have the courage to write you in the first place. You will know me more as we communicate along and I will also send my pictures as soon as i hear from you so that you will see who you are communicating with.



Thanks for your understanding, hoping to hear from you soon.

Yours sincerely

Miss.Mercy

Re: MSS Clamp in User-Space

Jesse Gross — 2012-05-25T02:34:39

Hi Simon,

Sorry I haven't responded to your patches yet.  I'm not ignoring them
- I've just been very busy lately.  Your high level descriptions all
sounds good so far though.  I'm hoping to have a chance to look at
them this weekend.

On Wed, May 23, 2012 at 5:26 PM, Simon Horman <horms< at >verge.net.au> wrote:

I think it probably needs to be configurable per output port but
doesn't need to be optimized for the case where there are different
configurations or MTUs.  We could potentially just send multiple
copies of the packet to the kernel, for example.


There's some code already in lib/route-table.c that can lookup the
device and from there you could get the MTU.  That said, it doesn't
really take into account any path MTU information that the kernel
might have or multipathing.


Do you have an idea of what this would look like?  I'm not sure how it
would fit in with using the in-tree tunneling code, since that would
presumably do the route lookup.

The flexibility of doing it in userspace is certainly nice but it may
not work or we may be able to get it anyways in the kernel.
_______________________________________________
dev mailing list
dev< at >openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: MPLS and VLAN QinQ patch

2012-05-25T00:02:31

I was wrong on handling v4/v6 tos. I will re-check man pages for -Q option, maybe it's using old TOS format? I will assume it's going be DSCP for IPv4 and TClass for IPv6 and copy lower 3 bits into MPLS EXP bits.

Thanks,
Ravi

-----Original Message-----
From: dev-bounces-yBygre7rU0TnMu66kgdUjQ< at >public.gmane.org [mailto:dev-bounces-yBygre7rU0TnMu66kgdUjQ< at >public.gmane.org] On Behalf Of Ben Pfaff
Sent: Thursday, May 24, 2012 4:02 PM
To: Kerur, Ravi
Cc: dev-yBygre7rU0TnMu66kgdUjQ< at >public.gmane.org
Subject: Re: [ovs-dev] MPLS and VLAN QinQ patch

On Thu, May 24, 2012 at 11:58:53PM +0200, Ravi.Kerur-+tb+GG71Y8BBDgjK7y7TUQ< at >public.gmane.org wrote:

But that only comes up in one situation: copying the TTL inward or outward when there is exactly one MPLS label.  In other situations (pushing an MPLS label or popping one) we know the correct inner Ethertype either because it's in the packet or because it's an argument to the action.  When we know it, we should use it.

Please do check again.  We have
    #define IP_ECN_MASK 0x03
    #define IP_DSCP_MASK 0xfc
in packets.h and I'm sure that's correct.

Please check again.  We have
    #define IP_VER(ip_ihl_ver) ((ip_ihl_ver) >> 4) and
    #define IP6_VER(ip6_vfc) ((ip6_vfc) >> 4) in packets.h and I'm sure that's correct.

By omitting the check we could incur a segfault.  Please check the length.

Hmm, I must have been looked elsewhere.  Sorry.

push_mpls() calls push_mpls_lse() in this case.  push_mpls_lse() starts out this:
    /* neither ipv4 or ipv6 return; */
which implies that it does nothing to non-IP.  Please remove the comment.

Thanks,

Ben.
_______________________________________________
dev mailing list
dev-yBygre7rU0TnMu66kgdUjQ< at >public.gmane.org
http://openvswitch.org/mailman/listinfo/dev

Re: [PATCH 03/21] odp-util: Add tun_key to parse_odp_key_attr()

Simon Horman — 2012-05-25T00:01:19

Strange. I asked git send-mail to CC him explicitly.


Sorry, perhaps this is not the latest revision, somehow.
I did have it compiling, and I'll update the patch accordingly.

Re: MPLS and VLAN QinQ patch

2012-05-24T23:24:00

Thanks Ben for your thorough review. Comments inline <rk>

-----Original Message-----
From: dev-bounces-yBygre7rU0TnMu66kgdUjQ< at >public.gmane.org [mailto:dev-bounces-yBygre7rU0TnMu66kgdUjQ< at >public.gmane.org] On Behalf Of Ben Pfaff
Sent: Thursday, May 24, 2012 4:02 PM
To: Kerur, Ravi
Cc: dev-yBygre7rU0TnMu66kgdUjQ< at >public.gmane.org
Subject: Re: [ovs-dev] MPLS and VLAN QinQ patch

On Thu, May 24, 2012 at 11:58:53PM +0200, Ravi.Kerur-+tb+GG71Y8BBDgjK7y7TUQ< at >public.gmane.org wrote:

But that only comes up in one situation: copying the TTL inward or outward when there is exactly one MPLS label.  In other situations (pushing an MPLS label or popping one) we know the correct inner Ethertype either because it's in the packet or because it's an argument to the action.  When we know it, we should use it. 

<rk> Cases for multiple MPLS headers currently happen only at Provider core routers and yes in that case we don't have to worry, I was thinking more in terms of Provider-Edge or MPLS termination point.  For those multiple MPLS label case it is already handled and I use existing mpls header to copy.  I will closely look at it one more time probably I am missing your point. I think you are probably saying extract ethtype from packet and use it to derive ttl and tos?

Please do check again.  We have
    #define IP_ECN_MASK 0x03
    #define IP_DSCP_MASK 0xfc
in packets.h and I'm sure that's correct.

<rk>  I had tested with "ping -Q <1-7> <dst-ip>" and I had seen correct TOS bits copied into MPLS headers. I will fix it as needed.

Please check again.  We have
    #define IP_VER(ip_ihl_ver) ((ip_ihl_ver) >> 4) and
    #define IP6_VER(ip6_vfc) ((ip6_vfc) >> 4) in packets.h and I'm sure that's correct.

<rk> Will double check.

By omitting the check we could incur a segfault.  Please check the length.

<rk> I have added the check. I got confused with checking the payload itself and was questioning why?

Hmm, I must have been looked elsewhere.  Sorry.

push_mpls() calls push_mpls_lse() in this case.  push_mpls_lse() starts out this:
    /* neither ipv4 or ipv6 return; */
which implies that it does nothing to non-IP.  Please remove the comment.

<rk> I  have fixed all the comments and its format as well.

Thanks,
Ravi

Thanks,

Ben.
_______________________________________________
dev mailing list
dev-yBygre7rU0TnMu66kgdUjQ< at >public.gmane.org
http://openvswitch.org/mailman/listinfo/dev

Re: MPLS and VLAN QinQ patch

Ben Pfaff — 2012-05-24T23:02:18

But that only comes up in one situation: copying the TTL inward or
outward when there is exactly one MPLS label.  In other situations
(pushing an MPLS label or popping one) we know the correct inner
Ethertype either because it's in the packet or because it's an
argument to the action.  When we know it, we should use it.


Please do check again.  We have
    #define IP_ECN_MASK 0x03
    #define IP_DSCP_MASK 0xfc
in packets.h and I'm sure that's correct.


Please check again.  We have
    #define IP_VER(ip_ihl_ver) ((ip_ihl_ver) >> 4)
and
    #define IP6_VER(ip6_vfc) ((ip6_vfc) >> 4)
in packets.h and I'm sure that's correct.


By omitting the check we could incur a segfault.  Please check the
length.


Hmm, I must have been looked elsewhere.  Sorry.


push_mpls() calls push_mpls_lse() in this case.  push_mpls_lse()
starts out this:
    /* neither ipv4 or ipv6 return; */
which implies that it does nothing to non-IP.  Please remove the
comment.

Thanks,

Ben.

Re: MPLS and VLAN QinQ patch

2012-05-24T21:58:53

Replies Inline <rk>

-----Original Message-----
From: Ben Pfaff [mailto:blp-l0M0P4e3n4LQT0dZR+AlfA< at >public.gmane.org] 
Sent: Thursday, May 24, 2012 1:45 PM
To: Kerur, Ravi
Cc: dev-yBygre7rU0TnMu66kgdUjQ< at >public.gmane.org
Subject: Re: [ovs-dev] MPLS and VLAN QinQ patch

On Tue, May 22, 2012 at 07:36:32PM +0200, Ravi.Kerur-+tb+GG71Y8BBDgjK7y7TUQ< at >public.gmane.org wrote:

Here's my second and final round of comments for this version of the patch.

Thanks, Ravi!  This is getting much closer.

High-level comments
-------------------

OF1.1 says that, on MPLS push, the MPLS traffic class of the new MPLS tag is only derived from an existing inner MPLS tag, never from an IP TOS, and that if there is no inner MPLS tag it must be set to 0.  I think your code tries to derive it from inner IP headers.

<rk> Generally IP TOS(older version) or IP DSCP values are copied to MPLS EXP bits, 6 bits of DSCP are mapped to 3 EXP bits in MPLS as there can be no more than 5 types of classification it can be easily done. I thought this would make more practical sense since its already deployed than the OF 1.1. Sorry for the confusion here, in my initial patch I had followed OF 1.1 spec and never used TOS from IP, changed it in this version of code as I found it more practical.  

lib/ofp-util.c
--------------

In validate_actions(), the following "if" can never trigger because mpls_ttl is an 8-bit quantity:
+            if (mpls_ttl & ~0xff) {
+                error = OFPERR_OFPBAC_BAD_ARGUMENT;
+            }

<rk> My mistake, will fix it.

get_l3_ttl_and_tos()
--------------------

Why does get_l3_ttl_and_tos() consider an unknown IP version as success, with a default?  This seems odd.

<rk> To handle non-IP traffic i.e push/pop MPLS over non-IP traffic e.g. ARP(practical?), VPLS. I had also mentioned in previous discussion that MPLS ttl actions will not work for these type of traffic but other actions lke push_mpls,pop_mpls, set_mpls_label/set_mpls_tc would be. In this function I keep them to default for non-IP traffic.

In get_l3_ttl_and_tos(), it's unnecessary to check both 'ih' and 'ih6'
for NULL, since they point to the same location.

<rk> agreed, will keep just one.

In get_l3_ttl_and_tos(), I'm pretty sure that "ih->tos & 0x07" is wrong.  By my reading, it extracts the two ECN bits and the lowest-order DSCP bit.  Is that really what you want?

<rk> I will check again. I thought IP DSCP bits are 0 - 5 and 6,7 for ECN. Here the goal is to copy lower 3 bits of DSCP/TOS or copy from mapping table(based on Service Level Agreement) or configuration from the controller. Copying from SLA mapping table can be added later, but configuration can override EXP bits now using "set_mpls_tc" action.

In get_l3_ttl_and_tos(), I wonder about "ih6->ip6_vfc >> 4", too.  By my reading, this will always equal 6, since we know that this is IPv6.
I don't think the "6" in IPv6 means that it always has to have a TOS of 6.

<rk> IPV6 tos bits are 8 bits long(starting from bit 21), I just take lower 3 bits from there. Same argument as above.

In the push_mpls() case, at least, it would be better to check the Ethertype, since we have it, than the first byte of the payload.

<rk> will fix it.

In get_l3_ttl_and_tos(), I don't see any check that the payload is long enough to hold the entire IPv4 or IPV6 header.

<rk> I don't see the need, but will fix it if needed. 

lib/packets.c
-------------

I see many uses of __be<N> in this file.  Those are kernel types.  In userspace, use ovs_be<N>.

<rk> I double checked I don't see any __be*

Most of the functions in this file have a "void" return type and end in an explicit "return;".  You can remove the "return;" since it serves no purpose.

<rk> Old coding style habit. Will remove them.

set_new_mpls_lse() is a little puzzling.  It only sets the fields that are nonzero in 'label'.  What if a caller wants to set a zero value?
(Are zero values reserved in MPLS?)

Why is it still not allowed to push an MPLS header onto non-IP data?
I think that it should be.

<rk> It does push MPLS onto non-IP data. I have tested it on ARP traffic.

In push_mpls(), I don't think either of the checks in the first "if"
is necessary.  If they are, then you can drop the "eh == NULL" check because the packet->size check is sufficient to ensure eh != NULL.
You can definitely drop the "packet->size >= sizeof(struct eth_header)" check in the second "if" in the function, because it duplicates that check from four lines earlier\.

<rk> will fix it.

The cases in push_mpls() are a bit confusing.  What if you separate it into steps:

        1. Determine correct TC, TTL, and BOS based on what's already
           in the packet.  This is the part that changes based on
           what's already in the packet.

        2. Push MPLS header based on information from previous step.
           I'm pretty sure that a single procedure works here,
           regardless of the initial state of the packet.

<rk> I will see if I can simplify further. Code flow is as follows

1. CASE IPv4/IPv4: get_l3_ttl_and_tos(Get layer-3 tos and ttl), push_mpls_lse(def_label, tc, ttl and bos), adjust ofpbuf.
2. CASE MPLS: get_inner_tag_values(copy inner tag values, set stack=0), push_mpls and adjust ofpbuf.
3. CASE VLAN: get_l3_ttl_and_tos, push_mpls and adjust ofpbuf.

I will further simplify this.

In pop_mpls(), I think that the initial test should be for size that is at least the size of an ethernet header followed by an MPLS header.

In pop_mpls(), one should write:
        if (mh->mpls_lse & ntohl(MPLS_STACK_MASK)) { instead of:
        if (ntohl(mh->mpls_lse) & MPLS_STACK_MASK) { for performance.

In pop_mpls(), one may write:
            eh->eth_type = ethtype;
instead of:
            char *t_ethtype = (char *)packet->l2_5 - 2;
            ovs_be16 *n_ethtype = (ovs_be16*) t_ethtype;
            *n_ethtype = ethtype;

<rk> will fix it.

ofproto-dpif.c
--------------

I think that say, two, dec_mpls_ttl actions in a single flow, starting from a TTL of, say, 2, will fail to detect reaching TTL 0.  Also, the existing implementation of dec ttl for IP stop translating actions after reaching TTL 0.  Presumably the MPLS implementation should do the same.

ovs-dpctl.c
-----------

In do_normalize_actions(), I'd start using a switch statement.

<rk> will fix it.

Thanks,
Ravi

Re: [PATCH] ovs-ofctl: Support all OFPPC_* flags in "mod-port" command.

Ben Pfaff — 2012-05-24T21:00:24

Thanks, fixed.


Good idea, I added this to the existing unit test:

diff --git a/tests/ofproto.at b/tests/ofproto.at
index 3113577..98942e5 100644
--- a/tests/ofproto.at
+++ b/tests/ofproto.at
< at >< at > -68,7 +68,14 < at >< at > for command_config_state in \
     'up 0 0' \
     'noflood NO_FLOOD 0' \
     'down PORT_DOWN,NO_FLOOD LINK_DOWN' \
-    'flood PORT_DOWN LINK_DOWN'
+    'flood PORT_DOWN LINK_DOWN' \
+    'no-receive PORT_DOWN,NO_RECV LINK_DOWN' \
+    'no-forward PORT_DOWN,NO_RECV,NO_FWD LINK_DOWN' \
+    'no-packet-in PORT_DOWN,NO_RECV,NO_FWD,NO_PACKET_IN LINK_DOWN' \
+    'forward PORT_DOWN,NO_RECV,NO_PACKET_IN LINK_DOWN' \
+    'packet-in PORT_DOWN,NO_RECV LINK_DOWN' \
+    'up NO_RECV 0' \
+    'receive 0 0'
 do
     set $command_config_state
     command=$[1] config=`echo $[2] | sed 's/,/ /g'` state=$[3]

I'll push this soon.

Re: [PATCH] memory: Memory leak when generating reports.

Ethan Jackson — 2012-05-24T20:51:34

Thanks, merged to master.

Ethan

On Thu, May 24, 2012 at 1:47 PM, Ben Pfaff <blp-l0M0P4e3n4LQT0dZR+AlfA< at >public.gmane.org> wrote: