IPTV igmpproxy issues

Here is my setup.

192.168.1.0/24(VLC)---eth0.1---OpenWRT---eth0.1991---10.33.199.0/24(Provider)

Below is igmpproxy config

config igmpproxy
        option quickleave 1
        option verbose 3
#       option verbose [0-3](none, minimal[default], more, maximum)

config phyint
        option network IPTV
        option zone wan
        option direction upstream
        list altnet 0.0.0.0/0

config phyint
        option network LAN
        option zone lan
        option direction downstream

igmpproxy debug, trying to open stream 232.232.64.102

Fri Apr 10 21:25:14 2020 user.info igmpproxy[3146]: Updated route entry for 232.232.64.102 on VIF #1
Fri Apr 10 21:25:14 2020 user.debug igmpproxy[3146]: Vif bits : 0x00000002
Fri Apr 10 21:25:14 2020 user.debug igmpproxy[3146]: Setting TTL for Vif 1 to 1
Fri Apr 10 21:25:14 2020 user.notice igmpproxy[3146]: Adding MFC: 88.212.8.3 -> 232.232.64.102, InpVIf: 0
Fri Apr 10 21:25:14 2020 user.debug igmpproxy[3146]: Vif bits : 0x00000002
Fri Apr 10 21:25:14 2020 user.debug igmpproxy[3146]: Setting TTL for Vif 1 to 1
Fri Apr 10 21:25:14 2020 user.notice igmpproxy[3146]: Adding MFC: 10.33.199.1 -> 232.232.64.102, InpVIf: 0
Fri Apr 10 21:25:14 2020 user.debug igmpproxy[3146]: Joining group 232.232.64.102 upstream on IF address 10.33.199.101
Fri Apr 10 21:25:14 2020 user.notice igmpproxy[3146]: joinMcGroup: 232.232.64.102 on eth0.1991
Fri Apr 10 21:25:14 2020 user.debug igmpproxy[3146]:
Fri Apr 10 21:25:14 2020 user.debug igmpproxy[3146]: Current routing table (Insert Route):
Fri Apr 10 21:25:14 2020 user.debug igmpproxy[3146]: -----------------------------------------------------
Fri Apr 10 21:25:14 2020 user.debug igmpproxy[3146]: #0: Src0: 88.212.8.3, Src1: 10.33.199.1, Dst: 232.232.64.102, Age:2, St: A, OutVifs: 0x00000002
Fri Apr 10 21:25:14 2020 user.debug igmpproxy[3146]: -----------------------------------------------------
Fri Apr 10 21:25:14 2020 user.notice igmpproxy[3146]: RECV V2 member report   from 10.33.199.101   to 232.232.64.102
Fri Apr 10 21:25:14 2020 user.notice igmpproxy[3146]: The IGMP message was from myself. Ignoring.
Fri Apr 10 21:25:14 2020 user.notice igmpproxy[3146]: Route activation request from 10.33.199.101 for 232.232.64.102 is from myself. Ignoring.
Fri Apr 10 21:25:15 2020 user.notice igmpproxy[3146]: RECV V2 member report   from 10.33.199.101   to 232.232.64.102
Fri Apr 10 21:25:15 2020 user.notice igmpproxy[3146]: The IGMP message was from myself. Ignoring.
Fri Apr 10 21:25:18 2020 user.debug igmpproxy[3146]: About to call timeout 11 (#0)
Fri Apr 10 21:25:21 2020 user.debug igmpproxy[3146]: About to call timeout 9 (#0)
Fri Apr 10 21:25:21 2020 user.debug igmpproxy[3146]: SENT Membership query   from 192.168.1.1     to 224.0.0.1
Fri Apr 10 21:25:21 2020 user.debug igmpproxy[3146]: Sent membership query from 192.168.1.1 to 224.0.0.1. Delay: 10
Fri Apr 10 21:25:21 2020 user.debug igmpproxy[3146]: Created timeout 12 (#0) - delay 10 secs
Fri Apr 10 21:25:21 2020 user.debug igmpproxy[3146]: (Id:12, Time:10)
Fri Apr 10 21:25:21 2020 user.debug igmpproxy[3146]: Created timeout 13 (#1) - delay 115 secs
Fri Apr 10 21:25:21 2020 user.debug igmpproxy[3146]: (Id:12, Time:10)
Fri Apr 10 21:25:21 2020 user.debug igmpproxy[3146]: (Id:13, Time:115)

igmpproxy inserts following rules:

root@OpenWrt:~# iptables --list |grep igmpproxy
ACCEPT     igmp --  anywhere             anywhere             /* !fw3: ubus:igmpproxy[instance1] rule 3 */
zone_lan_dest_DROP  udp  --  anywhere             239.255.255.250      /* !fw3: ubus:igmpproxy[instance1] rule 1 */
zone_lan_dest_ACCEPT  udp  --  anywhere             base-address.mcast.net/4  /* !fw3: ubus:igmpproxy[instance1] rule 2 */
ACCEPT     igmp --  anywhere             anywhere             /* !fw3: ubus:igmpproxy[instance1] rule 0 */

tcpdump from iptv interface

21:40:25.854739 IP (tos 0x80, ttl 62, id 14925, offset 0, flags [DF], proto UDP (17), length 1356)
    88.212.8.3.49152 > 232.232.64.102.5004: [udp sum ok] UDP, length 1328
21:40:25.855476 IP (tos 0x80, ttl 62, id 14987, offset 0, flags [DF], proto UDP (17), length 1356)
    88.212.8.3.49152 > 232.232.64.102.5004: [udp sum ok] UDP, length 1328
21:40:25.856217 IP (tos 0x80, ttl 62, id 15050, offset 0, flags [DF], proto UDP (17), length 1356)
    88.212.8.3.49152 > 232.232.64.102.5004: [udp sum ok] UDP, length 1328
21:40:25.856961 IP (tos 0x80, ttl 62, id 15113, offset 0, flags [DF], proto UDP (17), length 1356)
    88.212.8.3.49152 > 232.232.64.102.5004: [udp sum ok] UDP, length 1328
21:40:25.857632 IP (tos 0xc0, ttl 1, id 2407, offset 0, flags [none], proto IGMP (2), length 32, options (RA))
    10.33.199.1 > 232.232.64.102: igmp query v2 [max resp time 10] [gaddr 232.232.64.102]
21:40:25.857711 IP (tos 0x80, ttl 62, id 15171, offset 0, flags [DF], proto UDP (17), length 1356)
    88.212.8.3.49152 > 232.232.64.102.5004: [udp sum ok] UDP, length 1328
21:40:25.858467 IP (tos 0x80, ttl 62, id 15238, offset 0, flags [DF], proto UDP (17), length 1356)
    88.212.8.3.49152 > 232.232.64.102.5004: [udp sum ok] UDP, length 1328
21:40:25.859205 IP (tos 0x80, ttl 62, id 15293, offset 0, flags [DF], proto UDP (17), length 1356)
    88.212.8.3.49152 > 232.232.64.102.5004: [udp sum ok] UDP, length 1328

Debug message from VLC
Screenshot 2020-04-10 at 23.54.37

Now the issue is screen tearing, intermittent sound, stream opens after 10-30s. I am suspecting that it's because timeout and delay in igmpproxy debug but don't know what's causing it.
Also I've noticed that IGMP has TTL 1 in tcpdump. Is that ok?

Thanks for your help guys.

Can you try option quickleave 0 ?

Thanks,

The option improved it, however still there. Did a quick test seems like both HD and SD streams are affected. It's watchable now but screen tears like every 30s. It's driving me crazy. Is there anything I can do to improve it?
like

  • prioritize RTP stream
  • check VLC settings
  • turn on igmp snooping (LAN is not bridge)

Thanks for your help

Ummmm...

What device do you have?

Yes; because the packet doesn't leave the ISP's LAN. A PIM server/router exists there to handle it...hence why you installed a proxy to put the LAN IGMPs on the ISP's interface. :slightly_smiling_face:

Depends.

Unrelated to OpenWrt.

What is is?

It's Mikrotik RB750Gr3

Here is the LAN interface
config interface 'LAN'
option proto 'static'
option ifname 'eth0.1'
option delegate '0'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option metric '1'

I got standalone AP, created a separate SVI for it. I guess I don't need to bridge then right?

Well it's running...but if you want to bridge instead, you would disable igmpproxy while testing it to see if the "rippy" video stops.

So you're suggesting to bridge eth0.1 and eth0.1991?

Not sure I can bridge it since Vlan 1991 is video dedicated. There is a different Vlan for data.

Before I had both Vlans trunked to my Win10 box where I created interfaces localy and few days ago I started to have those tearing issues not sure why. That's why I decided to try igmpproxy approach.

No, I'm not.

You said:

Bridge it to that (I mistook this to mean "Standalone SSID"). If that possibility doesn't exist, I'm not sure why you suggested bridging - I wasn't making such a suggestion and I wouldn't guess to bridge them.

Wait...

Before using OpenWrt???

I was gong to suggest simply setting up VLAN1991 on the Windows box to test; but it seems you've done that before.

Nope with OpenWrt. I had that vlan on the Windows box, working correctly. Without any config change I had those video issues few days ago. Seems like same thing with igmpproxy. So I am assuming that igmpproxy works fine and issue is somewhere else.

The thing is that I am not sure where to look, I am not that skilled with multicast.

Well, if your NIC in the Win 10 box can be set to a VLAN, see if you can play the stream directly without issue. If you still experience the problem, it's likely the ISP.

Good idea. I'll check it tomorrow.

Thanks for help

1 Like

Ok works now.

Here is what I did:

  • direct connection to STB (worked)
  • trunked video Vlan through OpenWRT and connected STB (worked)
  • set up Win box with video Vlan and connected (worked)
  • ok now back to igmpproxy config (worked without screen tearing!)

I've no idea what was the issue, here are options I can think of:

  • bad cable, maybe I fixed it when making direct connection with rj45 coupler (have to check cabling with tester)
  • I've noticed that I've disabled firewall flow offloading at some point
  • sync issue with ISP

lleachii thanks for your help, I'll mark your answer as solution since it improved the video smoothness

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.