From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751436AbeAPEo1 (ORCPT + 1 other); Mon, 15 Jan 2018 23:44:27 -0500 Received: from smtps.newmedia-net.de ([185.84.6.167]:44971 "EHLO webmail.newmedia-net.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751319AbeAPEoZ (ORCPT ); Mon, 15 Jan 2018 23:44:25 -0500 Subject: Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports To: Kevin Cernekee Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, stable , Andrew Lunn , "David S. Miller" References: <20180101140056.475827799@linuxfoundation.org> <20180101140100.858496151@linuxfoundation.org> <9edf97da-5492-b598-492e-c982591dddff@dd-wrt.com> From: Sebastian Gottschall Message-ID: Date: Tue, 16 Jan 2018 05:44:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: 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 > -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottschall@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565