netdev - Re: bridge is not forwaring ICMP6 neighbor solicitation to KVM guest

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]

Date:	Mon, 03 Mar 2014 16:40:40 -0500
From:	Vlad Yasevich <vyasevich@...il.com>
To:	Linus Lüssing <linus.luessing@....de>,
	Jan Stancek <jstancek@...hat.com>
CC:	netdev@...r.kernel.org, Florian Westphal <fwestpha@...hat.com>,
	bridge@...ts.linux-foundation.org
Subject: Re: bridge is not forwaring ICMP6 neighbor solicitation to KVM guest

On 03/03/2014 04:27 PM, Linus Lüssing wrote:
> Hi Jan,
> 
> On Mon, Mar 03, 2014 at 02:47:15PM -0500, Jan Stancek wrote:
>> I'm seeing an issue where bridge (sometimes) stops forwarding ICMP6
>> neighbor solicitation packets to KVM guest and as result KVM guest doesn't
>> respond with neighbor advertisement.
> 
> Hm, okay, that's not supposed to happen.
> 
>> The reason I think this packet is related is because when I send same exact
>> packet I'm often hitting same issue - bridge stops forwarding ICMP6 neigh.
>> solicitation packets to KVM guest.
> 
> Yes, the MLD query is kicking the multicast snooping into gear. If
> there's never a query, then snooping is basically disabled
> (compare: "bridge: disable snooping if there is no querier").
> 
>>
>> My current way to reproduce this is:
>> 0. host B IP / MAC is: 2620:52:0:1040:221:5aff:fe47:931c / 00:21:5a:47:93:1c
>>    guest IP / MAC is: 2620:52:0:1040:5056:ff:fe00:29 / 52:56:00:00:00:29
>> 1. host B is sending neigh solicit packets every 5 seconds with KVM guest IP
>>    using ns6 from ipv6toolkit: http://www.si6networks.com/tools/ipv6toolkit/
>>    with parameters:
>>    --src-address=2620:52:0:1040:221:5aff:fe47:931c --dst-address=ff02::1:ff00:0029
>>    -t 2620:52:0:1040:5056:ff:fe00:29 --link-src-address=00:21:5a:47:93:1c
>>    --source-lla-opt=00:21:5a:47:93:1c --link-dst-address=33:33:ff:00:00:29
>>    tcpdump running on guest can see both solicit and advertisement packets
>> 2. wait ~5 minutes
>> 3. host B sends Multicast Listener Query packet described above
>> 4. tcpdump running on guest is no longer seeing any neigh solicit packets
> 
> Just to clarify, host B is behind eno1 and vnet0 is directly
> connected to the interface of the guest, no additional bridge or
> anything else on top of that, right?
> 
> Would it be possible for you to upload the tcpdumps from host B
> (or if you can't tcpdump on host B, then capturing on eno1)
> and the guest somewhere and saying at which time/packet in the dumps
> it stops working (probably ~10 seconds after the query). Filtering
> for ICMPv6 should be sufficient. 
> 
> What I'm curious about is, whether the guest receives
> the MLD query and responds with an MLD report. I suspect that
> either the bridge doesn't get an MLD report and therefore is
> shutting down the according port or there's a bug in parsing the
> MLD report in the bridge code.
> 

I did notice a minor issue in the bridge code.  The following
code:
       /* Prevent flooding this packet if there is no listener present */
        if (!ipv6_addr_is_ll_all_nodes(&ip6h->daddr))
                BR_INPUT_SKB_CB(skb)->mrouters_only = 1;

        if (ip6h->nexthdr != IPPROTO_HOPOPTS ||
            ip6h->payload_len == 0)
                return 0;

will mark most multicast traffic is mrouters_only.  The two
statement should be probably be reversed.  However, that's shouldn't
cause the reported problem.

-vlad

> 
> Thanks for the detailed report so far!
> 
> Cheers, Linus
> 

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