Weird Sources in Routing Table #26
Comments
|
Some additional information: 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:
|
|
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 :) However, it doesn't seem like we are completely done just yet. Now my logs are filling up with the following messages: Does anyone happen to know:
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: |
|
Did some more digging and found the following commit: d37dd49 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? |
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? |
|
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: 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? 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? |
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:
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:
The text was updated successfully, but these errors were encountered: