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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPWQB7GGEvpjdnU6O6XM6r8MPQGZG1CV6wYdOkX33T6Ja5jtNw@mail.gmail.com>
Date:   Fri, 10 Feb 2017 20:05:34 -0800
From:   Joe Stringer <joe@....org>
To:     Roopa Prabhu <roopa@...ulusnetworks.com>
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 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:

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.