Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751381AbeAPPcR (ORCPT + 1 other); Tue, 16 Jan 2018 10:32:17 -0500 Received: from mail-qt0-f175.google.com ([209.85.216.175]:45942 "EHLO mail-qt0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750964AbeAPPcP (ORCPT ); Tue, 16 Jan 2018 10:32:15 -0500 X-Google-Smtp-Source: ACJfBotSvZXnqlxkzGj56NUYTwPv8EMAsH6Fyw01uAgjTgoDitXtRr068dwQNfBF/fr1yqWO+uj9rA== MIME-Version: 1.0 In-Reply-To: <76522cb7-8a6e-8379-6850-33c8f6943f99@dd-wrt.com> References: <20180101140056.475827799@linuxfoundation.org> <20180101140100.858496151@linuxfoundation.org> <9edf97da-5492-b598-492e-c982591dddff@dd-wrt.com> <76522cb7-8a6e-8379-6850-33c8f6943f99@dd-wrt.com> From: Kevin Cernekee Date: Tue, 16 Jan 2018 07:31:51 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports To: Sebastian Gottschall Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, stable , Andrew Lunn , "David S. Miller" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Tue, Jan 16, 2018 at 1:18 AM, Sebastian Gottschall wrote: > >> According to my understanding of igmpv3_newpack(), the destination >> address should always be IGMPV3_ALL_MCR = 224.0.0.22. That is what I >> see in my testing. >> >> However, your packet trace says 239.35.100.8. I don't know how the >> code that we touched would be generating an IGMPv2 packet with that >> destination address. > > easy answer from wikipedia. 224.0.x.x is not the only multicast block AFAICT the code that was changed by this patch should not have anything to do with other multicast blocks. It generates an IGMPv3 report with destination address 224.0.0.22. So it would be useful to get more information on how exactly it is causing a failure, so we can find the root cause. >> Would it be possible to get a stack trace for the case where the >> source address is being cleared to 0.0.0.0 in your configuration? > > you mean something like dumpstack and watching the flood comes over me? I would just add something like this into my local tree for testing: WARN_ON_ONCE(pip->saddr == htonl(INADDR_ANY));