From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Description of problem: In current 2.4.21 kernels, IGMPv3 is used by default. There is no option to select IGMPv2. This is a problem when using multicast in networks that do not yet support IGMPv3. In newer kernels (2.4.25 and up), there is a way to force IGMPv2 via sysctl. It looks like this: /sbin/sysctl -w net.ipv4.conf.eth0.force_igmp_version=2 The problem currently exists in kernel 2.4.21-15.EL. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Implement in a network that uses IGMPv2. 2. Subscribe to multicast groups other than 224.0.0.1 3. Use "tcpdump" to monitor incoming traffic. 4. You will see no multicast traffic. Additional info:
This bug report doesn't indicate that a problem actually occurs. The way it works is that IGMPv3 is tried _first_ but if no response is received to that IGMPv2 is used next. The sysctl to force IGMPv2 is only need for some broken middleware boxes, and that is pretty rare and thus I do not think the reporter is seeing that.
Upon doing some more research, I think the problem may be related to the fact that we are running IGMP snooping, which doesn't work with IGMPv3 clients (at least not in the software running on our routers/switches). In a situation like this, having the option to force IGMPv2 on the client is essential.
It works with IGMPv3 clients, just some vendors don't implement it properly. Anyways, this is the critical piece of information I needed thanks.
Actually, we cannot add this feature into the RHEL3 product because the change requires changing a publicly visible kernel ABI which we cannot change, namely the layout of the inetdevice structure needs to change in order to accomodate this feature. Sorry.
Are you sure the IGMP version fallback is working like you described in comment #1? I am having problems with ganglia, which uses multicast. I have a few computers running RHEL-3 (igmp v3) and one computer running RedHat-7.3 (igmp v2). They are on the same subnet and configured to use the same multicast address, but they are not receiving eachother's multicast packets. Our network equipment does not support igmp v3, but I still see the RHEL computers using igmp v3 (checked with tcpdump). Since our network hardware doesn't support igmp v3 and there is another computer, on the same subnet and using the same multicast address and using igmp v2, shouldn't they fallback to use igmp v2 also?
Created attachment 103866 [details] backport of 2.6 force igmp functionality I've had a few customers mention that it would be nice to be able to force igmp version in order to interoperate properly with their other network equipment. I thought that this would be a good time to re-open this bug, as we're talking about changing the ABI for RHEL3 U4 anyway. I've taken the liberty of backporting the 2.6 functionality and attached it here
Feel free to put this in Neil, looks fine to me.
Have you looked into the version fallback behavior which doesn't appear to be working? Someone of the ganglia mailing list recently reported similar igmp problems and found that the kernel doesn't appear to be advertising its igmp version correctly: sgilbert-at-nvidia wrote: We just looked at the RedHat kernel source...sure enough...it checks to see if it's v1, and it not, it just blindly puts "v2" in /proc/net/igmp, even though it's really talking v3. Could this be contributing to the problem? Are there any other igmp versioning bugs in the kernel?
I'll post this to rhkernel-list then. Thanks dave! Jason, in regards to your other question, If its the problem I believe that it is, I've fixed this as well in the patch that I previously attached. The problem is in the chunk that starts at line 2106. I've included the 2.6 functionality there that properly reports V1,2 or 3. Please let me know if thats not the problem you are referring to and I'll be happy to investigate further.
A patch to facilitate forcing the igmp protocol version has just been committed to the RHEL3 U4 patch pool (in kernel version 2.4.21-20.9.EL).
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-550.html