@Linux User wrote:
Thanks Ron and fizze.
I tried adding the following rules (separately, in the pairs shown), but none of them worked:
iptables -A INPUT -s 224.0.0.0/4 -d 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -s 127.0.0.1 -d 224.0.0.0/4 -j ACCEPT
iptables -A INPUT -s 224.0.0.0/4 -d 192.168.1.0/24 -j ACCEPT
iptables -A OUTPUT -s 192.168.1.0/24 -d 224.0.0.0/4 -j ACCEPT
iptables -A INPUT -s 224.0.0.0/4 -d 224.0.0.0/4 -j ACCEPT
iptables -A OUTPUT -s 224.0.0.0/4 -d 224.0.0.0/4 -j ACCEPT
True. The rules should probably be:
iptables -A INPUT -s 224.0.0.0/4 -j ACCEPT
iptables -A OUTPUT -d 224.0.0.0/4 -j ACCEPT
When it sends multicast, it uses the addressable interface, not the loopback. Probably a 192.168 address.
So there is clearly some misconception about multicast. Here’s the 30 second multicast primer. Imagine the case where you are streaming live video. You can have everyone connect to your server, and each download the data on individual connections. But that sucks, because you are using tons of bandwidth to stream video, when all of it is the same content. A better solution would be to send out one copy of the data to everyone that was interested in seeing it. It would be a hard problem, because you’d have to send it to every connected router that had someone who was interested in watching the video behind it. And so on, through every router connected between you and all the users who wanted to see it.
But that’s what multicast does. To make it work, they took all the class “d” addresses and made them multicast addresses. These addresses are really collections of computers that have “joined” that address (or multicast group). So for example, I could have my video running on a specific multicast address, spewing out video constantly. When someone wanted to see it, they could join that multicast address, and suddenly the traffic that I was sending to that multicast address would appear at the end station.
Course, it’s more complex than that… all the routers in between have to notify each other about multicast subscriptions and stuff, but essentially that’s it. Multicast is really kind of a “channel” that interested computers can “join” and receive data. Kind of a network inside the network, connected by multicast enabled routers.
I’m not doing this justice, but the point is that multicast groups look like ip addresses in the 224 range, but are really nothing more than quieter broadcast than broadcast. If that makes sense.
iptables -A INPUT -m pkttype --pkt-type multicast -j ACCEPT
iptables -A OUTPUT -m pkttype --pkt-type multicast -j ACCEPT
iptables -A INPUT -m pkttype --pkt-type unicast -j ACCEPT
iptables -A OUTPUT -m pkttype --pkt-type unicast -j ACCEPT
Now THAT worked. But it allows sending and receiving multi/unicasts to the public internet doesn’t it? Am I advertising my music library to the public internet? ‘Cause I don’t want to be doing that.
You don’t want that. First, you won’t be advertising. No routers enable multicast by default, so the multicast packets are getting dropped at your gateway router to the net.
Secondly, you don’t want to allow unicast. Unicast is all traffic that isn’t multicast or broadcast, which is pretty much all traffic you want to block — web traffic, mail traffic, pretty much everything tcp. You don’t want that.
Why does firefly have to be able to multi/unicasts without limit on source or destination?
That’s the nature of multicast, and that’s what it uses to locate servers on the network. It’s a better way than broadcast, as it doesn’t spam packets to machines that aren’t interested.
is there some kind of spyware in there, is it reporting back to HQ?
Spyware? that’s why it’s source available. 😉
What it is about firefly and/or multi/unicasting that I don’t get?
Multicast is kinda wierd. these guys probably explain it better. 🙂