Problem with IPTV on wlan

Hi guys,
i'm facing a strange problem with iptv broadcast and can't figure out what's going on.
i'm using mercusys mr90x router with OpenWrt 23.05.2, all the clients are connected via wi-fi, including the iptv box.
I've installed igmpproxy, configured it and the firewall, and iptv is working, but if i choose any channel and leave it streaming then it will freeze after 255 seconds.
If i click on any other channel then it will again work for 255 seconds and freeze.

I've tried to make a separate interface and wlan exclusively for iptv box, playing with igmp snooping, multicast querier - got same result.

Any suggestions?
Thanks!

UPD:
here's the sample from system log with igmpproxy config verbose 2.
Can it be that the problem is that the server don't receive igmp replies and kicks my receiver out of the group?

Mon Jan  8 14:03:23 2024 user.notice igmpproxy[7366]: RECV V2 member report   from 192.168.2.172   to 239.255.255.250
Mon Jan  8 14:03:23 2024 user.info igmpproxy[7366]: Updated route entry for 239.255.255.250 on VIF #1
Mon Jan  8 14:03:26 2024 user.notice igmpproxy[7366]: RECV Membership query   from 192.168.2.1     to 224.0.0.1
Mon Jan  8 14:03:27 2024 user.notice igmpproxy[7366]: RECV V2 member report   from 192.168.2.172   to 239.255.5.171
Mon Jan  8 14:03:27 2024 user.info igmpproxy[7366]: Updated route entry for 239.255.5.171 on VIF #1
Mon Jan  8 14:03:27 2024 user.notice igmpproxy[7366]: Adding MFC: 172.16.255.154 -> 239.255.5.171, InpVIf: 0
Mon Jan  8 14:03:30 2024 user.notice igmpproxy[7366]: RECV V2 member report   from 192.168.2.1     to 224.0.0.2
Mon Jan  8 14:03:30 2024 user.notice igmpproxy[7366]: The IGMP message was from myself. Ignoring.
Mon Jan  8 14:03:33 2024 user.notice igmpproxy[7366]: RECV Membership query   from 192.168.2.1     to 224.0.0.1
Mon Jan  8 14:03:34 2024 user.notice igmpproxy[7366]: RECV V2 member report   from 192.168.2.172   to 225.0.71.1
Mon Jan  8 14:03:34 2024 user.info igmpproxy[7366]: Updated route entry for 225.0.71.1 on VIF #1
Mon Jan  8 14:03:34 2024 user.notice igmpproxy[7366]: RECV V2 member report   from 192.168.2.1     to 224.0.0.22
Mon Jan  8 14:03:34 2024 user.notice igmpproxy[7366]: The IGMP message was from myself. Ignoring.
Mon Jan  8 14:03:35 2024 user.notice igmpproxy[7366]: RECV V2 member report   from 192.168.2.172   to 239.255.255.250
Mon Jan  8 14:03:35 2024 user.info igmpproxy[7366]: Updated route entry for 239.255.255.250 on VIF #1
Mon Jan  8 14:03:41 2024 user.notice igmpproxy[7366]: RECV Membership query   from 192.168.2.1     to 224.0.0.1
Mon Jan  8 14:03:41 2024 user.notice igmpproxy[7366]: RECV V2 member report   from 192.168.2.1     to 224.0.0.2
Mon Jan  8 14:03:41 2024 user.notice igmpproxy[7366]: The IGMP message was from myself. Ignoring.
Mon Jan  8 14:03:42 2024 user.notice igmpproxy[7366]: RECV V2 member report   from 192.168.2.172   to 239.255.5.171
Mon Jan  8 14:03:42 2024 user.info igmpproxy[7366]: Updated route entry for 239.255.5.171 on VIF #1
Mon Jan  8 14:03:42 2024 user.notice igmpproxy[7366]: Adding MFC: 172.16.255.154 -> 239.255.5.171, InpVIf: 0
Mon Jan  8 14:03:45 2024 user.notice igmpproxy[7366]: RECV V2 member report   from 192.168.2.1     to 224.0.0.22
Mon Jan  8 14:03:45 2024 user.notice igmpproxy[7366]: The IGMP message was from myself. Ignoring.
Mon Jan  8 14:03:47 2024 user.notice igmpproxy[7366]: RECV V2 member report   from 192.168.2.172   to 225.0.71.1
Mon Jan  8 14:03:47 2024 user.info igmpproxy[7366]: Updated route entry for 225.0.71.1 on VIF #1

What is the igmpproxy quickleave setting?

1 Like

it's option quickleave 1 , i've tried to change it to 0, same thing

Can you try enabling multicast to unicast?

it was enabled by default, now i disabled it, (both in the device config and in the wlan config) and restarted the router. TV streaming became extremely laggy, like a slideshow.
Still after 255 seconds it freezes

It should stay enabled as otherwise multicast packets are going to be transmitted at 6Mbps signaling - 3.5Mbps actual rate.

It's a long shot, but worth a try.

255 seconds is the default query-timeout on some devices and usually messages sent by those devices have a TTL value set to 1.

Try increasing the TTL value for multicast traffic entering the wan interface (as suggested in the wiki).

dev=$(ifstatus wan | grep \"device | awk '{ print $2 }' | sed 's/[",]//g')
nft insert rule inet fw4 mangle_prerouting iifname "$dev" ip daddr 224.0.0.0/4 ip ttl set 2 counter

If it still doesn't work, stop the service, start it manually in debug mode and look for something useful.

service igmpproxy stop
nft insert rule inet fw4 forward meta l4proto udp ip daddr 224.0.0.0/4 counter accept
igmpproxy -n -d -vv /var/etc/igmpproxy.conf
2 Likes

thanks for the suggestion! I just managed to get it work by enabling "Accept packets with local source addresses" on eth1 device (Ethernet port). It was disabled by default.
Now everything works fine. Still i don't get how that helps since...there's shouldn't be any packets with local source adresses?

Sorry, neither do I.

The net.ipv4.conf.<interface>.accept_local variable is used to make the IP stack accept packets that leave the host from one physical interface and come back to another "over the wire". Additionally, it either works or it doesn't and there is no explanation for the 255 second interval (except due to packets blocking some timeout expires).

I think that's some firmware bug, because before installing stable version i was trying snapshot and no "accept local" was needed, everything was working fine (well, at least for the multicast part).
Anyway, thanks for your help!