netdev - Re: [PATCH net-next v2 2/5] vxlan: support fdb and learning in COLLECT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <589E995B.9090405@cumulusnetworks.com>
Date:   Fri, 10 Feb 2017 20:55:55 -0800
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Joe Stringer <joe@....org>
CC:     netdev <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        stephen@...workplumber.org, nikolay@...ulusnetworks.com,
        Thomas Graf <tgraf@...g.ch>,
        Hannes Frederic Sowa <hannes@...essinduktion.org>,
        Jiri Benc <jbenc@...hat.com>, pravin shelar <pshelar@....org>,
        David Ahern <dsa@...ulusnetworks.com>, hadi@...atatu.com,
        Jarno Rajahalme <jarno@....org>
Subject: Re: [PATCH net-next v2 2/5] vxlan: support fdb and learning in COLLECT_METADATA
 mode

On 2/10/17, 8:05 PM, Joe Stringer wrote:
> On 31 January 2017 at 22:59, Roopa Prabhu <roopa@...ulusnetworks.com> wrote:
>> @@ -1289,7 +1331,12 @@ static int vxlan_rcv(struct sock *sk, struct sk_buff *skb)
>>         if (!vs)
>>                 goto drop;
>>
>> -       vxlan = vxlan_vs_find_vni(vs, vxlan_vni(vxlan_hdr(skb)->vx_vni));
>> +       vni = vxlan_vni(vxlan_hdr(skb)->vx_vni);
>> +
>> +       if ((vs->flags & VXLAN_F_COLLECT_METADATA) && !vni)
>> +               goto drop;
>> +
>> +       vxlan = vxlan_vs_find_vni(vs, vni);
>>         if (!vxlan)
>>                 goto drop;
> Hi Roopa,
>
> We've noticed a failure in OVS system-traffic kmod test cases and
> bisected it down to this commit. It seems that it's related to this
> new drop condition here. Can you explain what's meant to be special
> about VNI 0? I can't see anything mentioned about it in RFC7348, so I
> don't see why it should be dropped.
>
> In the OVS testsuite, we configure OVS in the root namespace with an
> OVS vxlan device (which has VXLAN_F_COLLECT_METADATA set), with vni 0.
> Then, we configure a veth pair into another namespace where we have
> the other end of the tunnel configured using a regular native linux
> vxlan device on vni 0. Prior to this commit, the test worked; after
> this test it failed. If we manually change to use a nonzero VNI, it
> works. The test is here:
To be honest, I thought vni 0 was only used for the collect metadata device for lookup
of the device until a real vni was derived. and since i moved the line that got the vni from the packet
up, I ended up adding that check. Did not realize vni 0 could be valid vni in the packet.
>
> https://github.com/openvswitch/ovs/blob/branch-2.7/tests/system-traffic.at#L218
>
> Jarno also tried setting up two namespaces with regular vxlan devices
> and VNI 0, and this worked too. Presumably this is because this would
> not use VXLAN_F_COLLECT_METADATA.
yeah, that should be it.

I will send a patch in a few hours. Thanks for reporting. I am glad you ran these tests.. as I was not able to
completely verify all cases for ovs.