Yes, you should be able to use the specific multicast address in place of 224.0.0.0 without a problem if you've got a hard-coded multicast address to use. We do it for our multicast setups without a hassle. As far as "what else should I open?", that depends on what you're using -- if you've got some unicast traffic that manages the multicast streams, for example, then you need to allow that traffic to get to where it's going, too. Obviously without knowing what it is that you're doing, I can't give you any advice on that.
In our instance, our problem was solved by sysctl parameters, one different from Maciej.
Please note that I do not speak for the OP (buecking), I came on this post due to the problem being related by the basic detail (no multicast traffic in userland).
We have an application that reads data sent to four multicast addresses, and a unique port per multicast address, from an appliance that is (usually) connected directly to an interface on the receiving server.
We were attempting to deploy this software on a customer site when it mysteriously failed with no known reason. Attempts at debugging this software resulted in inspecting every system call, ultimately they all told us the same thing:
Our software asks for data, and the OS never provides any.
The multicast packet counter incremented, tcpdump showed the traffic reaching the box/specific interface, yet we couldn't do anything with it. SELinux was disabled, iptables was running but had no rules in any of the tables.
Stumped, we were.
In randomly poking around, we started thinking about the kernel parameters that sysctl handles, but none of the documented features was either particularly relevant, or if they had to do with multicast traffic, they were enabled. Oh, and ifconfig did list "MULTICAST" in the feature line (up, broadcast, running, multicast). Out of curiosity we looked at /etc/sysctl.conf. 'lo and behold, this customer's base image had a couple of extra lines added to it at the bottom.
In our case, the customer had set net.ipv4.all.rp_filter = 1. rp_filter is the Route Path filter, which (as I understand it) rejects all traffic that could not have possibly reached this box. Network subnet hopping, the thought being that the source IP is being spoofed.
Well, this server was on a 192.168.1/24 subnet and the appliance's source IP address for the multicast traffic was somewhere in the 10.* network. Thus, the filter was preventing the server from doing anything meaningful with the traffic.
A couple of tweaks approved by the customer; net.ipv4.eth0.rp_filter = 1 and net.ipv4.eth1.rp_filter = 0 and we were running happily.
Best Answer
I'd say the most common cause that you'll need to be on the lookout for is routed networks, where the entire set of systems that need to participate in the multicast group (the clients and the server) are not on the same broadcast domain.
That's the first thing to ask the client's network administrators. As far as resolving it if that is the case, it depends on their networking equipment; they'll need to set up PIM and IGMP snooping on their routing equipment.
Their equipment having support for it may be hit or miss; this may be a major barrier for some of your clients. You may need to look into alternative solutions that don't require their network equipment to play nice with multicast. A couple ideas: