Hi!
i have the following setup.
2 zones, lets call them green and red zone.
both zones consist of 1 vlan and 1 wlan bridged together.
the green zone can forward any traffic to the red zone.
the red zone can only forward traffic to the green zone i allowed.
Input to the router is also rejected by default.
In the green zone there is one device advertising an dlna server.
i setup smcroute to route the multicast group 239.255.255.250 between the networks.
i created two firewall rules.
one to allow igmp from the red zone to the router.
second to allow 239.255.255.250 to be forwaded from red to green.
This setup works fine. for the most part. clients in the red zone either from ethernet or wlan can discover the dlna server.
However (strangely) on the green zone only the ethernet clients can see the dlna server.
igmp snooping is enabled on both bridges. (but same behavior when disabled)
What can cause this behavior?
why? green zone can forward all traffic it wants to the red zone. why is it rejected?
When i create one more rule. allow input to the router dst 239.255.255.250, this message is gone.
But the behavior is still the same.
Okay i ended up with the following rules now:
Input Rules from redzone to router
allow igmp
allow multicast 224.0.0.0/4
Im not sure about that one. But i looked at the available addresses.
224.0.0.1 The All Hosts multicast group addresses all hosts on the same network segment.
224.0.0.2 The All Routers multicast group addresses all routers on the same network segment.
224.0.0.22 Internet Group Management Protocol (IGMP) version 3
239.255.255.250 SSDP is also covered.
(And some more but they are not needed i guess)
I dont know if the first "allow igmp" rule also already matches the 224.0.0.22 igmp3 rule.
Someone knows what exactly the iptables protocol igmp option matches for?
Only the join and leave messages?
The IGMP is a separate protocol, not something carried over IP, so the "allow igmp" just allows people to announce "I'd like to join this group" or "I'd like to leave this group" or the like.
allowing multicast 224..../4 allows IP packets with multicast destinations to be routed, so that's separate from IGMP.
Glad you got it working. In the future, the ipv6 system for multicast is really a lot better as far as I can tell.
Hmm still not working as it should.
I only have one wireless client to test this.
It is an android phone.
on the red zone it always works instantly.
on the green zone i have to reboot the phone to make it work.
But then it works reliable.
Okay let me see if i get this all correctly. Step by Step.
igmp i used to manage multicast groups.
clients can join and leave a group. (leaving since v2)
Now i have 2 networks.
Both consist of a brdige. 1 lan and 1 wlan bridged.
IGMP snooping is enabled on the bridge.
So only multicast traffic is transferred on those bridge ports which are member of a multicast group.
Is this even correct?
Now for the green zone no firewall rules are needed.
Because all input to the router is allowed.
And also all forwarding to the red zone is allowed.
So clients both from the lan and from the wireless can send their join/leave messages to the multicast port on the router.
For the red zone i create an input rule to the router to allow igmp.
Now all clients from all networks can send their join/leave messages to the router.
First question.
On the router....
The igmp group memberships are stored per interface ?
I guess yes otherwise it makes no sense?
Do i have to allow the forwading of igmp join/leave messagest from red to green?
Then i configure smcroute to setup my multicast routes and create the matching forward rule.
And it should work?
//edit
i tried the rules from the beginning again.
and works now again.
I dont know.
multicast is a bit of a mystery, the snooping part makes it not entirely deterministic. I mean, it should just work as you have described for the most part, but I am not surprised if it sometimes works and sometimes doesn't.
You can maybe make this better by enabling multicast querying on the linux bridges:
mutli cast querier is set to 1 by default.
ttl increase rule is also set.
i dont get this.
from the red zone it works everytime.
from the green zone it only works for the lan clients reliably.
I downloaded some simple multicast test app from playstore.
When my phone is on the green zone and i send a message to 239.255.255.250 1900 i get an answer from the dlna server. but my phone cant find the server.
So it sounds like discovery is the issue rather than communications. How does the DLNA server broadcast its existence? Those packets are probably not going where they need to go.
When i start listening on 239.255.255.250 1900 in the green zone.
I get an notify from a dlna test server from the red zone.
But not from the dlna server in the green zone.
When i do the same in the red zone, i get both notifies. e.g. server from green and server from red.
either its a bridge or wireless bug that somehow only effects the green zone?
Strange is that it works for the lan side on the green zone all the time. Only wireless is buggy.
Ok, so the notify from the red zone is routed through your smcroute daemon whereas the green-green packet is bridged only. This seems to indicate that multicast snooping / bridging between wired and wireless within the green zone is not working right.
Have you confirmed that multicast snooping and querying settings are the same on both green bridge and red bridge? Is there a difference in hardware between the two? Did you test both wired and wireless on the red zone?
239.255.255.250 is routed between both networks.
1 dlna server in the green zone.
1 test dlna server in the red zone.
green lan can see both servers all the time.
green wireless doesnt work. only for short time after i rebooted my client (android phone)
But after some time my android only finds the dlna server in the red zone but not the one in the green zone anymore.
Seems like somehow the notify from the green dlna server doesnt reach my phone anymore. Also the m search from phone to the green server is lost somwhere.
red zone works as expected.
both lan and wireless can see the servers from green and red.
multicast snooping and querying settings are both the same.
The hardware is also the same.
At first i would say okay could be an android bug. But why does it work on the red zone wireless all the time?
I did some wiresharking on the dlna server.
The server sends an m seach every 10sec? Is this expected behavior?
When i start a dlna app and start search on my phone,
i can see the m searchers arriving.
Then the server should response with an unicast.but it doesnt.
So used some more generic filter.
It seems like that the server (or more like the os )isnt able to send the unicast.
Because there is no entry in the arp table. I see some arp request but no one answers.
When i try to ping my phone. i get an response from router that the destination host is unreachable.
arp -a on the router shows that the router does have that info.
Internet works fine on the phone too.
You're saying the server in the green zone, which is a separate device from your router, doesn't have an ARP entry for the phone (also in green zone) and does not receive arp responses?
That sounds like the kind of garbage that Android probably gives me. Did you actually reboot the phone? Also do you have ipv6 addresses available? Perhaps android internet "works" because it's using ipv6?
Yes.
Rebooting either the server machine or the phone fixes it for some time.
The network is not ipv6 enabled.
Somehow the phones arp entry disappears after sometime from the arp cache on the server machine.
I also have a network camera on the same network. the arp entry for this device seems consisted.
In wireshark i can see the server machine is sending out the arp request.
Unless you've set up somehow proxy arp, it's the phone that should respond. The phone is probably NOT receiving the arp request because.... Android and excessive power-saving behavior on the wifi. I kinda hate android
