Why Won’t mt-daapd Work Unless It’s Open to the Internet?

@fizze wrote:

Your rules block out multicasts / unicasts. That’s why firefly’s share can’t be seen by any client then. 😉

What fizze said. You need to allow traffic to/from 224.0.0.0/4, that’s the multicast network.

Or you can slim it down to just 224.0.0.251, as thats the only multicast address mdns uses, but you’ll run into problem later with other multicast apps unless you unfirewall the whole class d range now.

— Ron

@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. 🙂

@Linux User wrote:

Thanks, Ron, for the clear, informative and detailed explanation. Very helpful, and reasurring.

I tried the two rules you suggested. Not sure why, but they didn’t work.

k. Here’s a tip to log your drops…

at the end of your iptables script, you likely have something like:

iptables -A INPUT -j DROP

or

iptables -A OUTPUT -j DROP

Either that, or you just set default policy to drop, then let it drop off the end of the table list.

You can do something like this at the end of script:

/sbin/iptables -N LOGDROP
/sbin/iptables -A LOGDROP -j LOG
/sbin/iptables -A LOGDROP -j DROP

/sbin/iptables -A INPUT -j LOGDROP
/sbin/iptables -A OUTPUT -j LOGDROP

Then, rather than dropping to the default “DROP” rule, any packets that *would* have been dropped instead get logged then dropped. Then you can check your syslog and see what’s being dropped. Then you can see what source addr, dest addr, etc are, and fix your rules.

If you don’t want the syslog traffic, you can keep those normally commented out, and just add them when you want/need the extra logging.

— Ron

I have the same problem on ubuntu feisty. At startup:

# iptables -L

Chain INPUT (policy ACCEPT)

target     prot opt source               destination



Chain FORWARD (policy ACCEPT)

target     prot opt source               destination



Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

I used:

# iptables -A INPUT -s 192.168.2.0/24 -d 224.0.0.0/4 -j ACCEPT

# iptables -A INPUT -s 192.168.2.0/24 -d 255.255.255.255 -j ACCEPT

# iptables -A OUTPUT -s 192.168.2.0/24 -d 224.0.0.0/4 -j ACCEPT

# iptables -A OUTPUT -s 192.168.2.0/24 -d 255.255.255.255 -j ACCEPT

Giving:

# iptables -L

Chain INPUT (policy ACCEPT)

target     prot opt source               destination

ACCEPT     0    --  192.168.2.0/24       BASE-ADDRESS.MCAST.NET/4

ACCEPT     0    --  192.168.2.0/24       255.255.255.255



Chain FORWARD (policy ACCEPT)

target     prot opt source               destination



Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

ACCEPT     0    --  192.168.2.0/24       BASE-ADDRESS.MCAST.NET/4

ACCEPT     0    --  192.168.2.0/24       255.255.255.255

But no joy. What am I missing? Or how do I parse the spew from the logging?