On Mon, Jan 15, 2018 at 8:44 PM, Sebastian Gottschall s.gottschall@dd-wrt.com wrote:
Am 16.01.2018 um 05:32 schrieb Kevin Cernekee:
On Mon, Jan 15, 2018 at 8:26 PM, Sebastian Gottschall s.gottschall@dd-wrt.com 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?