Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 4.19 01/24] bridge: do not add port to router list when
 receives query with source 0.0.0.0
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        Ying Xu <yinxu@redhat.com>, Hangbin Liu <liuhangbin@gmail.com>,
        Nikolay Aleksandrov <nikolay@cumulusnetworks.com>,
        Roopa Prabhu <roopa@cumulusnetworks.com>,
        "David S. Miller" <davem@davemloft.net>
References: <20181102182839.725385066@linuxfoundation.org>
 <20181102182839.913422845@linuxfoundation.org>
 <07d315a2-d735-3d8b-686c-9c52acf91bf1@newmedia-net.de>
 <20190217164809.GA24091@kroah.com>
From:   Sebastian Gottschall <s.gottschall@newmedia-net.de>
Message-ID: <7978727a-eacc-779c-771f-f4c3013237f3@newmedia-net.de>
Date:   Mon, 18 Feb 2019 11:18:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <20190217164809.GA24091@kroah.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


Am 17.02.2019 um 17:48 schrieb Greg Kroah-Hartman:
> On Sun, Feb 17, 2019 at 03:29:22PM +0100, Sebastian Gottschall wrote:
>> according to user reports this patch will cause a serious regression. 
>> igmp
>> snooping is not working anymore with this patch
>>
>> Am 02.11.2018 um 19:34 schrieb Greg Kroah-Hartman:
>>> 4.19-stable review patch.  If anyone has any objections, please let 
>>> me know.
>>>
>>> ------------------
>>>
>>> From: Hangbin Liu <liuhangbin@gmail.com>
>>>
>>> [ Upstream commit 5a2de63fd1a59c30c02526d427bc014b98adf508 ]
>>>
>>> Based on RFC 4541, 2.1.1.  IGMP Forwarding Rules
>>>
>>>     The switch supporting IGMP snooping must maintain a list of
>>>     multicast routers and the ports on which they are attached.  This
>>>     list can be constructed in any combination of the following ways:
>>>
>>>     a) This list should be built by the snooping switch sending
>>>        Multicast Router Solicitation messages as described in IGMP
>>>        Multicast Router Discovery [MRDISC].  It may also snoop
>>>        Multicast Router Advertisement messages sent by and to other
>>>        nodes.
>>>
>>>     b) The arrival port for IGMP Queries (sent by multicast routers)
>>>        where the source address is not 0.0.0.0.
>>>
>>> We should not add the port to router list when receives query with 
>>> source
>>> 0.0.0.0.
>>>
>>> Reported-by: Ying Xu <yinxu@redhat.com>
>>> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
>>> Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>>> Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> ---
>>>    net/bridge/br_multicast.c |   10 +++++++++-
>>>    1 file changed, 9 insertions(+), 1 deletion(-)
>>>
>>> --- a/net/bridge/br_multicast.c
>>> +++ b/net/bridge/br_multicast.c
>>> @@ -1420,7 +1420,15 @@ static void br_multicast_query_received(
>>>            return;
>>>        br_multicast_update_query_timer(br, query, max_delay);
>>> -    br_multicast_mark_router(br, port);
>>> +
>>> +    /* Based on RFC4541, section 2.1.1 IGMP Forwarding Rules,
>>> +     * the arrival port for IGMP Queries where the source address
>>> +     * is 0.0.0.0 should not be added to router port list.
>>> +     */
>>> +    if ((saddr->proto == htons(ETH_P_IP) && saddr->u.ip4) ||
>>> +        (saddr->proto == htons(ETH_P_IPV6) &&
>>> +         !ipv6_addr_any(&saddr->u.ip6)))
>>> +        br_multicast_mark_router(br, port);
>>>    }
>>>    static void br_ip4_multicast_query(struct net_bridge *br,
> Is this also a problem in 4.20?  This patch went into 4.20-rc1, so it
> has been around for a while with no reported issues that I can find.
> Any pointers to the reports?

i need to check this. i found this patch in 4.9, 4.14 and 4.4
the rest was picked up from the mailinglist. according to the git 
sources of 4.20 and 5.0 the same code is in there as well

i just got the report from users today and was able to reproduce it with 
iptv streams. just by disabling the code it was working again.

Sebastian
>
> thanks,
>
> greg k-h
>