Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751009AbeAPFQl (ORCPT + 1 other); Tue, 16 Jan 2018 00:16:41 -0500 Received: from mail-qt0-f182.google.com ([209.85.216.182]:38662 "EHLO mail-qt0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750842AbeAPFQj (ORCPT ); Tue, 16 Jan 2018 00:16:39 -0500 X-Google-Smtp-Source: ACJfBou5/eRGAgbmKf9YFeSTALsxZvepZi4oJ9AxVLE2wq1MdgpfDxeYJkRLfpaNtPSRJEjGAlYLcA== MIME-Version: 1.0 In-Reply-To: References: <20180101140056.475827799@linuxfoundation.org> <20180101140100.858496151@linuxfoundation.org> <9edf97da-5492-b598-492e-c982591dddff@dd-wrt.com> From: Kevin Cernekee Date: Mon, 15 Jan 2018 21:16:17 -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 Mon, Jan 15, 2018 at 8:44 PM, Sebastian Gottschall wrote: > Am 16.01.2018 um 05:32 schrieb Kevin Cernekee: >> >> On Mon, Jan 15, 2018 at 8:26 PM, Sebastian Gottschall >> wrote: >>> >>> havent check the source addresses right now. i basicly discovered that >>> this >>> patch breaks the igmp routing and all traffic stops >>> this here is from a working system with the reverted patch. if you really >>> need that i break it again using the patch you need to wait a little bit >>> >>> 05:14:22.697962 IP 10.88.195.138 > 239.35.100.8: igmp v2 report >>> 239.35.100.8 >> >> The patch should only affect IGMPv3 behavior. I did not intend to >> change IGMPv2 behavior. If it does, that might be a bug. > > it does change the behaviour indeed. i dont know the reason. but i while > discovering the issue on 4.14 last week and newly on 4.9 this week while > testing > (my latest firmware i builded was from 30. december and worked) i got > tracked it down to this small patch and it immediatly worked after reverting > it >> >> Is it possible that the kernel is using a source IP of 0.0.0.0, but >> another host does not recognize it because it does not comply with RFC >> 3376? > > this is possible yes, but i cannot look into the "deutsche telekom" host >> >> >> Before/after packet traces would be the best way to see if the kernel >> change is causing it to violate the standard. > > let me just take a look into our patch > + for_ifa(in_dev) { > + if (inet_ifa_match(fl4->saddr, ifa)) > + return fl4->saddr; > + } endfor_ifa(in_dev); > this looks like you're checking if the source address matches to a local > interface, if not you return 0.0.0.0 instead of the source address > > (193.158.35.251, 239.35.20.4) Iif: ppp0 Oifs: briptv > > our first source address here 193.158.35.251 is from a remote network. so > your patch also will change the behaviour since the source address will get > ignored 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. 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?