@mickey84 , please decide if you wish to:
- configure the PIM properly, or
- if you want assistance with mangling packets
We can't decide that for you...but others are more available to configure mangling on OpenWrt than a PIM.
I really want to do it properly with PIM. But I will need step by step instructions if thats ok for you guys.
I thought that's what igmpproxy does? PIM seems to handle more the upstream routers, like with this topology:
TV Source -------- ISP Router 1 ----- ISP Router 2 -------- OpenWrt Router ----- LAN
PIM would talk ISP Router 1 to ISP Router 2 so that ISP Router 1 starts sending the tv source, and then isp router 2 can forward it... and the packets hit OpenWrt Router which only needs igmpproxy because once the multicast packets are hitting OpenWrt it can just pass them from WAN to LAN
EDIT: my understanding is that for the moment the topology is just:
TV Source --- OpenWrt Router with igmpproxy ---- LAN client
and we have the multicast video hitting OpenWrt already, so igmpproxy should be able to forward them along to LAN if that's what it does I'm still not entirely clear on what the full features of igmpproxy are.
You posted the results of tcpdump -i eth0 igmp but it wasn't clear whether you had a listener on LAN requesting at that time, and also whether igmpproxy was even running at that point. Can you please try this one again and just tell us whether any igmp is showing up on WAN once your LAN client is started?
Yes I will try again. Be right back
@dlakelan, you are correct. Though, you are not considering @mickey84's case. There's no PIM-enabled device to tell igmpproxy it's subscribed (this is the "upstream router" you refer to). It's never told by any daemon, that the stream is available.
igmpproxy = only a PROXY for the IGMP packets (and the subsequent UDP stream - this is why others in threads are confused when TCP gets in the mix, replies can have a unicast address data too).
AHA! I get it. So igmpproxy is sitting there waiting for someone to say "hey go ahead and grab those packets we're sending you" so it doesn't know to start forwarding? Is that the main issue?
In this case @mickey84 you will need a second GL-inet router to get the full simulation:
TV Source ---- additional router running PIMd simulating ISP ----- Your existing router --- LAN client
If you don't have extra devices, you can maybe put the "additional router running PIMd" in a virtual machine on the same device as TV Source 
1 Like
Yes!
But, in the [true] ISP's case, there are no packets [on the upstream broadcast domain] until the IGMP subscription is sent upstream (unless a neighboring node was already receiving it, of course) - this is when and were snooping comes into play (which would reduce bandwidth consumed on the broadcast domain).
as soon as i started to open the stream i got igmp messages:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:29:21.822552 IP 10.0.0.100 > 224.0.0.22: igmp v3 report, 1 group record(s)
02:29:22.762512 IP 10.0.0.100 > 224.0.0.22: igmp v3 report, 1 group record(s)
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
root@OpenWrt:~#
with rtp://@230.1.1.1:5004
1 Like
* You addressed the processor
* See if that's on LAN (br-lan) or WAN (eth0.2)
* See if you get a response from anywhere on WAN
Hummm....can you SEE the stream?
Misread the tcpdump, I see that a request being sent to his WAN.
@lleachii, in his device I think WAN is a separate ethernet port with a separate interface, so there's no VLAN tag just eth0.
Great, so with @lleachii's help, I think we've identified the issue.
On LAN, Listener sends "membership report" requesting a certain stream.
OpenWrt router running igmpproxy hears membership report and proxies it onto the WAN.
On the WAN, no-one is listening to these reports and sending queries.
On the WAN we are getting the packets already.
igmpproxy is waiting for an igmp query for that address, which basically tells it "hey someone wants to know who wants the thing we just requested"
until it gets that query it's not likely to start proxying the UDP itself (I think).
@mickey84, do you have a smart switch available?
1 Like
no I can't
I have a netgear switch with igmp snooping activated. but right now i'm connected directly to the WAN without the switch in between
If your netgear switch is a managed switch with igmp snooping, please turn on the igmp snooping function, and set up the following topology:
TV Source ----> Netgear Switch with igmp snooping ----> OpenWrt Router ----> LAN device
make sure you enable igmp querying along with snooping in the netgear switch.
1 Like
I see your idea...but I'm still slightly lost at who's gonna be telling the "snooper" on the broadcast domain facing the server port of the switch - that the stream is available there.
And since it's just a switch...who's routing the packets?
The switch is one big broadcast domain, but igmp snooping lets it decide not to broadcast packets on some ports if it "knows" no-one on those ports wants the packets.
It finds out who wants packets by sending out igmp queries, to which listeners are supposed to respond. Listeners also can just spontaneously send responses, which it should notice as well.
As soon as it "knows" that the OpenWrt router wants the TV packets, it should start forwarding them to the OpenWrt router, and it will start sending igmp queries "hey who wants this stream?" which igmpproxy should proxy back to the LAN and the listener should respond to... and proxy back to WAN etc.
that's why we need querier function on the switch turned on.
MY setup is now: PC(10.0.0.50)---Switch(10.0.0.100)---WAN(10.0.0.120)---LAN(192.168.133)
I activated IGMP snooping on the switch.
Theres a IGMP querier functioni enabled and it says address 0.0.0.0 and query interval 60 and igmp version 2
Ok, hopefully you can now turn on the sender and the listener, and tcpdump on your WAN for igmp packets and see both responses and queries for the given stream.
EDIT: and maybe even see your TV stream? 
tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:58:44.299531 IP 10.0.0.50.58401 > 230.1.1.1.5004: UDP, length 1328
02:58:44.304299 IP 10.0.0.50.58401 > 230.1.1.1.5004: UDP, length 1328
02:58:44.309294 IP 10.0.0.50.58401 > 230.1.1.1.5004: UDP, length 1328
02:58:44.314278 IP 10.0.0.50.58401 > 230.1.1.1.5004: UDP, length 1328
02:58:44.319288 IP 10.0.0.50.58401 > 230.1.1.1.5004: UDP, length 1328
02:58:44.324267 IP 10.0.0.50.58401 > 230.1.1.1.5004: UDP, length 1328
02:58:44.329278 IP 10.0.0.50.58401 > 230.1.1.1.5004: UDP, length 1328
02:58:49.307288 IP 10.0.0.50.58401 > 230.1.1.1.5004: UDP, length 1328
02:58:49.312257 IP 10.0.0.50.58401 > 230.1.1.1.5004: UDP, length 1328
tcpdump -i eth0 igmp nothing happens
Ok, so WAN side is receiving the TV stream... have it dump just the igmp packets and look for whether a complete conversation is going on there (both queries and responses)
Do you have igmpproxy running and also your LAN viewer running?