Posted: Mon Nov 13, 2006 9:16 Post subject: Multicast debugging
I am currently stuck with multicast on the WRT54G with latest DD-WRT firmware.
The configuration is as follows:
- Internet connection provided by Alcatel Speedtouch modem. The modem does PPPOE.
- Behind the modem, a WRT54G router is installed.
- I am starting a multicast on one of the LAN ports of the WRT54G.
- I want to receive the multicast on another LAN port of the WRT54G.
See network diagram attached
I am broadcasting from the server on 239.255.12.12
I try to receive the multicast on the client... without success.
From Ethereal, I can see:
- The UDP strem leaves the video server. TTL is set to 3.
- The IGMP V2 traffic seems absolutely correct from the WRT54G and from the client.
- Still, when joining the group, the UDP packets are not forwarded by the Linksys router to the client.
Any idea what the issue could be?
I notice on the WRT54G that a process is running: igmprt -f -i vlan1
Is it normal that is runs on vlan1? Is there something I have to change to make it to work? How?
Anyone having some information on igmprt? How can I see the IGMP memberships on the WRT54G?
I noticed this problem as well a couple of weeks ago. For our project we want to implement an igmp proxy as well so I made a set up with a WRT54G with DD-WRT and our router behind it. Multicast does not pass the DD-WRT, however with tomato (which is using the same igmp proxy) it is no problem. I tried to compile the igmprt sources for our box and could not get it to work either , which made me decide to look for another solution. On sourceforge I found a piece of software called igmpproxy which compiles and works as a real igmpproxy, however the problem with this program is that you have to specify the remote multicast address in the igmpprxy.conf file, which IMHO is silly, since you have to change the file everytime you want to access another multicast server. Therefore I removed this feature and made the program connect to any remote multicast server without specifying it. Attached you can find the adapted sources, be aware that the binary inside this archive is compiled for our MIPS based viper II, so you have to recompile it yourself.
Thank you both for the responses. Very informative, and I don't feel so lonely anymore.
Eko, do you have an idea of the release date for SP3? I would like to assess if I'd better wait for that new version, or switch, in the mean time, to another firmware.
Is there any temporary fix you can give on SP2 to solve the issue (commands, etc)? What was the issue?
Actually, the process you mention was already running under SP2 (igpmrt -f -i vlan1).
What about the VLAN1 parameter? Is it appropriate to broadcast from a LAN port to another LAN port? Or is there anything I should add related to VLANs in the config?
Any tip you could give to debug it? How can I know the IGMP members? Where can I configure the parameters for igmprt to start (to tweak the parameters)? Where can I find the config file for igmprt?
Frustrating... I could swap to another firmware, but I'd rather stay on dd-wrt if possible.
I finally found where the igmp membership is stored by igmprt.
This is in /proc/net/igmp
The information in there indicate that my video client igmp request is indeed logged, as indicated in the screenshot. (0C0CFFEF is 239.255.12.12)
It also indicates that the interface vlan1 is OK as well.
So, what's wrong? Why aren't my udp packets relayed from LAN port 1 to the other LAN ports?
When I setup the stream server to multicast the router just floods this out all LAN switch ports. I also notice high router CPU utilization from the softIRQ daemon process.
I use VLC for the stream server and it uses IGMPv3. Is there any DD-WRT build that supports IGMPv3?
I did somemore digging and discovered that a switch must support igmp snooping in order to prevent multicast packets from being flooded on all ports in that VLAN.
I guess the 4-port switch built in to the Linksys WRT54G does not support IGMP snooping??
Can anyone confirm this?
craig0 wrote:
When I setup the stream server to multicast the router just floods this out all LAN switch ports. I also notice high router CPU utilization from the softIRQ daemon process.
I use VLC for the stream server and it uses IGMPv3. Is there any DD-WRT build that supports IGMPv3?
Actually, the process you mention was already running under SP2 (igpmrt -f -i vlan1).
I have exactly the same problem, I've been fighting with this all day. There are two main reasons for me to get DD-WRT working, the other one is IPv6 which works quite well out-of-the-box but I just can't make multicast forwarding to work.
Update: I don't have exactly the same problem because I want multicast to go from wan to lan... But the result is pretty much the same.
igmp goes through just fine and multicast data comes all the way to my WRT54G router but then it stops there. When I do iptables -v -n -L INPUT I see that all the multicast packets are dropped. When I check the FORWARD chain and its multicast rule I see that the packets never get that far. If I add a rule into INPUT that will accept the multicast data packets it still doesn't seem to work.
What do I need to do to make it work, please give a tip...
debackel wrote:
What about the VLAN1 parameter? Is it appropriate to broadcast from a LAN port to another LAN port? Or is there anything I should add related to VLANs in the config?
Any tip you could give to debug it? How can I know the IGMP members? Where can I configure the parameters for igmprt to start (to tweak the parameters)? Where can I find the config file for igmprt?
Frustrating... I could swap to another firmware, but I'd rather stay on dd-wrt if possible.
Me too. Did you ever find out any answers to these questions? I would be really happy to know...
As you can see here the origin is always 00000000 which is not right. The source code of igmp-proxy reveals the line:
mfcctrl.mfcc_origin.s_addr = 0;
This is clearly the reason that it's always 0, the comment says "Since the implementation in the kernel has been changed to no longer care for the SOURCE of Multicast packets we can safely pass a 0 as the ORIGIN of multicast packets." However reading the kernel source it clearly cares about this and also tested with newer kernels the situation is the same. It does the comparison:
if (c->mfc_origin==origin && c->mfc_mcastgrp==mcastgrp)
In the official linksys release this c->mfc_origin==origin check is removed from the if in question in ipmr_cache_find and it has also replaced the line:
This is done in both ipmr_mfc_delete and ipmr_mfc_add. After these three small changes the multicast routing should start to work just fine. But compiling DD-WRT is a bit pain in the ass so if someone could compile me v23SP2 with these changes I would be very happy. I don't like v23SP3 since I haven't found any IPv6 setting there and it is totally necessary for me. Is it hidden somewhere?
I'll post this information in both bugtracker and the forum posts.
