[lkml]   [2018]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports
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 > igmp v2 report
>> 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, 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 instead of the source address
> (, Iif: ppp0 Oifs: briptv
> our first source address here 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 = That is what I
see in my testing.

However, your packet trace says 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 in your configuration?

 \ /
  Last update: 2018-01-16 06:17    [W:0.210 / U:0.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site