Weird Sources in Routing Table

[Mushoz]

I am trying to debug the occasional stutter I am experiencing when watching IPTV via igmpproxy running on my router on Lede, and enabling the verbose 2 option has shown a weird routing table:

Sat Mar 24 20:27:31 2018 user.debug igmpproxy[19162]: Current routing table (Insert Route):
Sat Mar 24 20:27:31 2018 user.debug igmpproxy[19162]: -----------------------------------------------------
Sat Mar 24 20:27:31 2018 user.debug igmpproxy[19162]: #0: Src: 213.75.167.58, Dst: 224.3.2.6, Age:2, St: A, OutVifs: 0x00000002
Sat Mar 24 20:27:31 2018 user.debug igmpproxy[19162]: #1: Src: 0.0.0.0, Dst: 239.255.3.22, Age:2, St: I, OutVifs: 0x00000002
Sat Mar 24 20:27:31 2018 user.debug igmpproxy[19162]: #2: Src: 213.75.167.6, Dst: 224.0.251.124, Age:2, St: A, OutVifs: 0x00000002
Sat Mar 24 20:27:31 2018 user.debug igmpproxy[19162]: #3: Src: 0.0.0.0, Dst: 239.255.255.250, Age:2, St: I, OutVifs: 0x00000002
Sat Mar 24 20:27:31 2018 user.debug igmpproxy[19162]: -----------------------------------------------------

What is up with the routes with a 0.0.0.0 source? Are these normal or is there something wrong somewhere? The igmpproxy configuration I am using is as follows:

config igmpproxy
    option quickleave 1
    option verbose 2

config phyint
    option network iptv
    option direction upstream
    list altnet 213.75.0.0/16

config phyint
    option network lan
    option direction downstream

[Mushoz]

Some additional information:

root@LEDE:~# ip mroute
(213.75.167.58, 224.3.2.6)       Iif: eth0.4     Oifs: br-lan 
(192.168.1.187, 239.255.255.250) Iif: unresolved 

As we can see in the multicast routes, we also notice unresolved routes here.

Edit: As far as I can understand (please correct me if I am wrong), some of my downstream devices (on 192.168.1.0/24) are sending multicast traffic themselves. Since lan is defined as my downstream direction (as it should), the routes aren't properly being added to the routing table. According to Wikipedia, the 239.0.0.0/8 range is "Administratively scoped" and hence sounds important to me.

My questions: 1) IPTV is working fine, except the occasional stutter every now and then, especially on higher bitrate channels. Is this something that could possibly be fixed by fixing this routing issue? 2) If this should be fixed, how should I tackle this issue?

[Mushoz]

Progress! For anyone looking for the solution to the same problem, changing my igmpproxy config file fixed the issue. I simply had to add the internal IP range to my altnet list as well :)

config igmpproxy
    option quickleave 1
    option verbose 2

config phyint
    option network iptv
    option direction upstream
    list altnet 192.168.1.0/24
    list altnet 213.75.0.0/16

config phyint
    option network lan
    option direction downstream

However, it doesn't seem like we are completely done just yet. Now my logs are filling up with the following messages:

root@LEDE:~# logread | grep -i "changed from"
Sun Mar 25 17:46:29 2018 user.warn igmpproxy[3463]: The origin for route 239.255.255.250 changed from 192.168.1.187 to 192.168.1.1
Sun Mar 25 17:46:32 2018 user.warn igmpproxy[3463]: The origin for route 239.255.255.250 changed from 192.168.1.1 to 192.168.1.232
Sun Mar 25 17:46:34 2018 user.warn igmpproxy[3463]: The origin for route 239.255.255.250 changed from 192.168.1.232 to 192.168.1.203
Sun Mar 25 17:46:39 2018 user.warn igmpproxy[3463]: The origin for route 239.255.255.250 changed from 192.168.1.203 to 192.168.1.210
Sun Mar 25 17:46:42 2018 user.warn igmpproxy[3463]: The origin for route 239.255.255.250 changed from 192.168.1.210 to 192.168.1.187

Does anyone happen to know: 1) What this means and what is causing this? 2) Are these messages harmless, or should something be fixed? 3) If so, how? :)

It seems like igmpproxy is simply overwriting earlier routes with the same destination but different source. Shouldn't these be inserted instead? The following command does show the proper routes:

root@LEDE:~# ip mroute
(213.75.167.58, 224.3.2.6)       Iif: eth0.4     Oifs: br-lan 
(213.75.167.6, 224.0.251.124)    Iif: eth0.4     Oifs: br-lan 
(192.168.1.187, 239.255.255.250) Iif: eth0.4     Oifs: br-lan 
(192.168.1.210, 239.255.255.250) Iif: eth0.4     Oifs: br-lan 
(192.168.1.203, 239.255.255.250) Iif: eth0.4     Oifs: br-lan 
(192.168.1.232, 239.255.255.250) Iif: eth0.4     Oifs: br-lan 
(192.168.1.1, 239.255.255.250)   Iif: eth0.4     Oifs: br-lan 

[Mushoz]

Did some more digging and found the following commit: https://github.com/pali/igmpproxy/commit/d37dd49665d82a4b3b79a9b6fa985238b04989e4

Seems like Lede is still using an ancient version from sourceforge rather than this new github and is missing this commit. Time to file a bug report for Lede then to update the package :)

Why is MAX_ORIGINS set to 4 in said commit, though? Isn't that extremely low still? In my small home network the logs above already show 5 different origins, which means overwriting of active routes would still take place. What I find baffling is that only 192.168.1.187 is an iptv device. How come all the other devices (phones, laptops, computers, etc) are also sending out multicast traffic? Is that normal nowadays?

[Mushoz]

root@LEDE:~# ip mroute
(213.75.167.58, 224.3.2.6)       Iif: eth0.4     Oifs: br-lan 
(213.75.167.6, 224.0.251.124)    Iif: eth0.4     Oifs: br-lan 
(192.168.1.187, 239.255.255.250) Iif: eth0.4     Oifs: br-lan 
(192.168.1.210, 239.255.255.250) Iif: eth0.4     Oifs: br-lan 
(192.168.1.203, 239.255.255.250) Iif: eth0.4     Oifs: br-lan 
(192.168.1.232, 239.255.255.250) Iif: eth0.4     Oifs: br-lan 
(192.168.1.1, 239.255.255.250)   Iif: eth0.4     Oifs: br-lan 

To come back to this log, this does not seem correct on second thought. Iif and Oifs should be reversed for all the LAN -> IPTV routes, right?

Edit: tcpdump shows that the routes for LAN -> upstream IPTV are indeed useless. I can see packets with 239.255.0.0/16 destination on my br-lan interface (my lan bridge), but they are not visible on eth0.4 (tagged VLAN from ISP carrying IPTV multicast streams), because there are no valid routes for this communication.

How should igmpproxy handle this scenario? Or is this outside the scope of igmpproxy? Should this issue even be fixed? Why would non-IPTV devices (phones, computers, laptops, etc) even be wanting to send multicast traffic upstream?

[Mushoz]

Yet another update after some more digging. Please correct me if anything that I have found/concluded is wrong. But it looks like this multicast traffic from my internal LAN to 239.255.255.250 is SSDP traffic for uPNP and should not be proxied by IGMPProxy. And hence the option:

list altnet 192.168.1.0/24

Should be removed. However, this does result in IGMPProxy still adding the unresolved routes to the multicast routing table. Is there a way to prevent IGMPProxy from listening to this SSDP traffic on the downstream devices, and if so, how?

I'm also seeing the following message in the log, I'm not sure whether they are related:

edit: Enabling quickleave removes these error messages. Somehow, when IGMPProxy wants to delete an old route, it is already gone and hence the error message. Quickleave makes IGMPProxy immediately delete these routes, and hence there are no error messages. So is my assumption that these errors are harmless correct? Should this be patched somehow to not confuse users? What is even deleting those routes before IGMPProxy can in the first place?

Tue Mar 27 15:44:54 2018 user.warn igmpproxy[14980]: MRT_DEL_MFC; Errno(2): No such file or directory
Tue Mar 27 15:44:54 2018 user.warn igmpproxy[14980]: MRT_DEL_MFC; Errno(2): No such file or directory
Tue Mar 27 15:44:54 2018 user.warn igmpproxy[14980]: MRT_DEL_MFC; Errno(2): No such file or directory
Tue Mar 27 15:44:54 2018 user.warn igmpproxy[14980]: MRT_DEL_MFC; Errno(2): No such file or directory
Tue Mar 27 15:44:54 2018 user.warn igmpproxy[14980]: MRT_DEL_MFC; Errno(2): No such file or directory
Tue Mar 27 15:44:54 2018 user.warn igmpproxy[14980]: MRT_DEL_MFC; Errno(2): No such file or directory

Also, there's a big discussion going on regarding IGMPProxy on the Lede forum. And I was wondering if anybody here happens to know the answer. The OpenWRT / Lede wiki states that a FORWARD rule should be used from the zone with the upstream IPTV interface to the zone(s) with the downstream interface(s). However, one user claims the UDP multicast traffic should be handled by an INPUT rule to the router itself, and that IGMPProxy proxies the UDP traffic. From my understanding, IGMPProxy only proxies the IGMP messages and not the multicast streams themselves. What is the correct answer here?