I have 2 PCs which are linked by cables directly .PC1 address:10.10.10.1 , PC2 address:192.168.3.1 . Their firewalls have been shut down. PC1 is a stream server , sending multicast video to 239.1.1.1:1234 with VLC media player .PC2 could recieve and watch the video perfectly .
Now I have a router between PC1 and PC2 . The router is running LEDE 17.01.
Router's wan port is linked to PC1 ,lan port is linked to PC2.Router's lan IP is 192.168.1.1/24
And I changed the IP of PC2 to DHCP client mode.
According to this article : https://wiki.openwrt.org/doc/howto/udp_multicast
Install igmpproxy , /etc/config/igmpproxy:
config igmpproxy
option quickleave 1
config phyint
option network wan
option direction upstream
list altnet 0.0.0.0/0
config phyint
option network lan
option direction downstream
config rule
option src wan
option proto igmp
option target ACCEPT
config rule
option src wan
option proto udp
option dest lan
option dest_ip 224.0.0.0/4
option target ACCEPT
option family ipv4
Force IGMP version:
Add to "net.ipv4.conf.all.force_igmp_version=2" to /etc/sysctl.conf
After all these things done and igmproxy running, I cannot watch the stream video.At first I thought it was about IP address , then I changed IP of PC1 and Routers'wan to a same subnet , the issue still.
Using "ifconfig" to see RX/TX bytes count of eth0.2 (wan) ,it was confirmed that the stream was already recieved by the router. But don't know why the stream was not forwarded to lan?
I traced the multicasting packets from wan , and I found that they've just be dropped after through table NAT chain PREROUTING.Normally they should keep moving to table FILTER chain FORWARD, but they didn't.
I believed it was caused by the defect of Openwrt, nothing to do about how I configure.I think there are some way to figure it out ,for example , pimd should fix that .And also remaking Openwrt to add multicast forwarding feature could work it out.
> config rule
> option src wan
> option proto igmp
> option target ACCEPT
Can someone explain what this rule exactly does?
Hmm yeah igmp is used to join a multicast group.
So client tells the router, i want to join this group.
I use smcroute to route some ssdp traffic between 2 vlans and it does work with out this rule.
(one vlan is "isolated" only can reach some services on the router and no forward to the other vlan)
why?
What lleachii wrote, makes sense.
I guess a forward rule is only useful if you use a multicast routing daemon like pimd or smcroute.
if you only use that one multicast address and only2 pc, i guess that should also work?:
config rule
option src wan
option proto udp
option dest_ip 239.1.1.0/31
option target ACCEPT
option family ipv4
config igmpproxy
option quickleave 1
config phyint
option network wan
option direction upstream
list altnet 239.1.1.0/31
config phyint
option network lan
option direction downstream
list altnet 192.168.1.0/24
Im not sure if 0.0.0.0/0 is an valid option.
And i also dont know if 239.1.1.0/31 does work x)
Maybe use 224.0.0.0/4 instead.
and for the network option....
maybe you have to use br-lan instead.
and for your wan interface, maybe use the physical interface name. something eth0 or eth1.
you can check this with ifconfig or in the luci gui in the "physical settings" page of your interface under network --> interfaces
Setting igmp_snooping '1' on the bridge is only needed, if you have bridged multiple interfaces together and want that multicast traffic get passed through all bridged interfaces.
Something like your lan switch and wlan.
For exmaple with igmp_snooping 0 and multicast traffic on the lan switch,
the multicast traffic would not get passed through to your wlan clients and vice versa.
With igmp_snooping 1 the traffic gets also passed to the wlan clients and vice versa.
But im also not sure about this x)
Thank you for your advice!
I modified /etc/config/igmpproxy following your instruction , igmpproxy cannot start successfully and there was no any process of it when using 'ps' .
My WAN is a Multicast network, my LAN must receive those multicasts, I have the same igmpproxy conf file as you, and a RAW ACCEPT firewall rule (I'll show it, if it helps below).I made no syscrtl changes.
Make sure that you have enabled igmpproxy system process to run, if it is not already enabled.
No, such a rule isn't needed on WAN, you only need to ALLOW INPUT of the multicast traffic itself. The LAN interface does need to receive IGMP (but the firewall is set to ALLOW by default).
It is valid, especially if you don't know the source IP of the multicast traffic. You must specify the SRC_IP by CIDR notation allowed to send multicast traffic - if the traffic will come from a SRC not equal to the subnet configured on the WAN interface.
THIS IS INCORRECT!!! NO LEGITIMATE PACKET ON THE INTERNET HAS THIS RANGE AS A SRC ADDRESS!!! THIS IP RANGE ARE ONLY VALID AS DESTINATION IPs ONLY
config igmpproxy
option quickleave 1
config phyint
option network wan
option direction upstream
list altnet 0.0.0.0/0
config phyint lan
option network lan
option direction downstream
MAKE SURE YOU FIX YOUR LAN IGMPPROXY RULE!!!
iptables -t raw -A PREROUTING -i eth0.2 -d 224.0.0.0/4 -m ttl --ttl-lt <TTL_here> -j ACCEPT (NOTE: I only needed a RAW rule because I block some malicious traffic by TTL)
This is my previous rule:
config rule
option target 'ACCEPT'
option src 'wan'
option family 'ipv4'
option proto 'udp'
option dest 'lan'
option dest_ip '224.0.0.0/4'
option name 'Allow-UDP_Multicast_In'
0.0.0.0/0 is only valid because openwrt includes some patch for this.
THIS IS INCORRECT!!! NO LEGITIMATE PACKET ON THE INTERNET HAS THIS RANGE AS A SRC ADDRESS!!! THIS IP RANGE ARE ONLY VALID AS DESTINATION IPs ONLY
This is true indeed. No isp would route multicast from their end customers all over the internet.
But his wan interface is not connected to the internet.
And some ISP use this range to deliver their IPTV services. (through vlan tagging though)
I think they use:
239.0.0.0/8
232.0.0.0/8
So each IP on this net represents 1 tv channel.
I made they advise to use 224.0.0.0/4 cause this wil cover the entire multicast range and makes debugging easier.
I get your point that 0.0.0.0/0 should represent a wildcard to cover all networks.
Where in the doc it states that 0.0.0.0 is valid?
Also i think it is not an good idea to blindly accept all multicast traffic.
But in his case, where everything is local only, it should be okay.
Because the SSM model essentially makes the entire multicast address
space local to the host, no IANA assignment policy is required.
Note, however, that while no additional IANA assignment is required,
addresses in the Source-Specific Multicast Block are explicitly for
use by SSM and MUST NOT be used for other purposes.
I understand the OP has a server that isn't on the Internet, but the same model applies, as it's the same technology. YOUR IMMEDIATELY UPSTREAM ROUTER IS LOCAL, THAT'S WHY IT'S IN THE SAME SUBNET!
Defines alternate sources for multicasting and IGMP data. The
network address must be on the following format 'a.b.c.d/n'. By default the router will accept data from sources on the same network as configured on an interface. If the multicast source lies on a remote network, one must define from where traffic should be accepted.