IPTV troubles with OpenWRT: cannot get live streams to work

I’ve got some trouble getting IPTV to work with OpenWRT. I’ve read quite a few posts on here, tweakers and the openwrt forum, but I’m still missing something.

I’ve got the following simple setup:

20241126_mini_setup

  • OpenWRT (23.05.5) on an Asus RT-AX53U (2 cores, 256 Mb RAM).
  • Modem is a Draytek 167, latest firmware, on Freedom VDSL. Bridged to the router.
  • I have a wan interface for PPPoE (br-wan.6) and an iptv interface (br-wan.4). Local interface for the STB is lan_tv (br-lan2).
  • The WAN VLAN 4 IP Address is 100.68.x.y/23 (so not the range starting with 10. that I see others have).
  • The route output shows the expected pppoe-wan route (185.93…), and two for br-wan.4 (100.64.0.0, 100.68.210.0).
  • igmpproxy is running (details below).

My issue:

The STB doesn’t show live streams pretty much at all. Sometimes, it briefly shows channel 20, it never shows any live stream for NPO1, 2, etc. When on a live stream channel, the router graphs shows that the traffic is going to the STB’s port (and not to other ports or wifi).

When any stream higher than SD is active, internet access fails. Some pings go through, but really lagged. Local connections are still fine though – it’s only WAN.

I’ve tested the streams with VLC:
Watching the SD stream for NPO1 (rtp://@224.0.251.1:8002) works well enough (stutters occasionally). HD and HD+ streams (rtp://@224.0.252.126:7252, rtp://@224.0.251.124:8248) don’t work. HD sometimes starts for a few seconds, then freezes. HD+ never starts displaying.

I’ve verified:

  • It all works with the standard Fritzbox – internet and TV work just fine (on the same STB).
  • Watching a stream on demand works fine, stream comes in over br-wan.6, displays fine.
  • The router load should be ok. It has 2 cores and only goes up to max 0.75 spikes for HD+ streams. (Load seems similar for working VOD stream.)
  • IGMP group membership works. Memberships look ok, no errors in the logs. Leaving works, and stop the stream.
  • IGMP snooping works. Graphs show that traffic is only going to the correct LAN port.
  • Firewall is not blocking any relevant traffic (logging is on for all zones).

I’ve tried:

  • IGMP snooping and multicast settings changed for devices.
  • sendopts 121 and vendor class “IPTV_RG” included for the iptv interface (though that is outdated configuration, right?).
  • Added a DNAT rule to forward streams directly to the STB (or attempted to, may have messed that up, config below)
  • Enabled SQM QoS (cake) for the bridge devices (lan and wan), did not make any difference.

Any help is appreciated. Even examples of debug output for healthy setups would be great.
I’m not a networking pro, but willing to learn (and I know my way around the basics, linux well enough).

(Not using the STB is not an option for me. If I can’t get it to work with OpenWRT, I’ll have to go back to using the FB or try OpnSense.)

Debugging:

When a live stream is open for the STB, this is what tcpdump shows. What’s weird, to me, is the traffic on wan.6. I would have expected the IPTV streams to come only from wan.4. (And when watching the SD NPO1 stream with VLC, traffic does only go over wan.4).

tcpdump -nai br-lan2:

13:28:22.053315 IP 217.166.225.124.49152 > 224.0.251.124.8248: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2185616
13:28:22.054903 IP 217.166.225.124.49152 > 224.0.251.124.8248: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2185617
13:28:22.056910 IP 217.166.225.124.49152 > 224.0.251.124.8248: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2185618
13:28:22.059018 IP 217.166.225.124.49152 > 224.0.251.124.8248: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2185619

tcpdump -nai br-wan.6:

13:25:33.697741 PPPoE  [ses 0x390] IP <MyPublicWanIp>.44494 > 185.24.175.211.10001: UDP, length 16
13:25:33.702921 PPPoE  [ses 0x390] IP <MyPublicWanIp>.44494 > 185.24.175.211.10001: UDP, length 16
13:25:33.706882 PPPoE  [ses 0x390] IP 185.24.175.211.10001 > <MyPublicWanIp>.44494: UDP, length 1330
13:25:33.708062 PPPoE  [ses 0x390] IP <MyPublicWanIp>.44494 > 185.24.175.211.10001: UDP, length 16
13:25:33.713291 PPPoE  [ses 0x390] IP <MyPublicWanIp>.44494 > 185.24.175.211.10001: UDP, length 16
13:25:33.716897 PPPoE  [ses 0x390] IP 185.24.175.211.10001 > <MyPublicWanIp>.44494: UDP, length 1330
13:25:33.723655 PPPoE  [ses 0x390] IP <MyPublicWanIp>.44494 > 185.24.175.211.10001: UDP, length 16
13:25:33.725886 PPPoE  [ses 0x390] IP 185.24.175.211.10001 > <MyPublicWanIp>.44494: UDP, length 1330

Configuration

Installed packages:

igmpproxy
kmod-ipt-nathelper-~rtsp~
luci-app-sqm

network:

config device
    option name 'br-lan'
    option type 'bridge'
    option acceptlocal '1'
    list ports 'lan1'
    option igmp_snooping '1'
    option multicast '0'
    option multicast_querier '0'

config interface 'lan'
    option device 'br-lan'
    option proto 'static'
    option ipaddr '192.168.3.1'
    option netmask '255.255.255.0'
    option ip6assign '60'
    list dns '185.93.175.43'

config device
    option type 'bridge'
    option name 'br-wan'
    list ports 'wan'
    option multicast '0'
    option igmp_snooping '1'
    option multicast_querier '0'

config bridge-vlan
    option device 'br-wan'
    option vlan '2'
    list ports 'wan:t'

config bridge-vlan
    option device 'br-wan'
    option vlan '4'
    list ports 'wan:t'

config bridge-vlan
    option device 'br-wan'
    option vlan '6'
    list ports 'wan:t'

config device
    option type 'bridge'
    option name 'br-lan2'
    option multicast '0'
    option igmp_snooping '1'
    list ports 'lan2'
    list ports 'lan3'

config interface 'wan'
    option proto 'pppoe'
    option device 'br-wan.6'
    option username 'fake@freedom.nl'
    option password '1234'
    option ipv6 'auto'

config interface 'wan_tv'
    option proto 'dhcp'
    option device 'br-wan.4'
    option type 'bridge'
    option peerdns '0'
    option defaultroute '0'
#   option sendopts '121'

config interface 'lan_tv'
    option proto 'static'
    option ipaddr '192.168.4.1'
    option netmask '255.255.255.0'
    list dns '185.93.175.43'
    option device 'br-lan2'

firewall

config rule
    option name 'IPTV-Allow-Multicast'
    list proto 'udp'
    option src 'iptv'
    option dest 'lan_tv'
    list dest_ip '224.0.0.0/4'
    option target 'ACCEPT'

config rule
    option name 'IPTV-Allow-IGMP'
    list proto 'igmp'
    option src 'iptv'
    option dest 'lan_tv'
    option target 'ACCEPT'

config rule
    option name 'Allow-IGMP'
    option src 'wan'
    option proto 'igmp'
    option family 'ipv4'
    option target 'ACCEPT'

config zone
    option name 'lan_tv'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    option masq_allow_invalid '1'
    option auto_helper '0'
    list helper 'rtsp'
    list network 'lan_tv'

config zone
    option name 'wan'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option mtu_fix '1'
    option masq '1'
    list network 'wan'

config zone
    option name 'iptv'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq_allow_invalid '1'
    option masq '1'
    option mtu_fix '1'
    list network 'wan_tv'

config forwarding
    option src 'lan_tv'
    option dest 'iptv'

config forwarding
    option src 'lan_tv'
    option dest 'wan'

config rule
    option name 'LanTV-Allow-Internet'
    list proto 'all'
    option src 'lan_tv'
    option dest 'wan'
    option target 'ACCEPT'

igmpproxy config: [edited with actual up to date config]

config igmpproxy
    option quickleave 1
    option verbose 3

config phyint
    option network wan_tv
    option zone iptv
    option direction upstream
#   list altnet 0.0.0.0/0
#   list altnet 185.24.172.0/24 <- tried with and without these
#   list altnet 185.24.175.0/24 <- tried with and without these
#   list altnet 185.41.48.0/24 <- tried with and without these
    list altnet 217.166.0.0/16

config phyint
    option network lan_tv
    option zone lan_tv
    option direction downstream
#    list altnet 192.168.4.1/24

Extra DNAT rules to forward traffic to STB (just to try):

config redirect
    option dest 'lan_tv'
    option target 'DNAT'
    option name 'Stream Test'
    option src 'wan'
    option src_ip '185.24.0.0/16'
    option src_dport '10000'
    option dest_ip '192.168.4.4'

config redirect
    option dest 'lan_tv'
    option target 'DNAT'
    option name 'IPTV TV test 2'
    option src 'wan'
    option src_ip '185.41.48.0/24'
    option src_dport '10000'
    option dest_ip '192.168.4.4'

Edit: updated igmpproxy config.

phyint refers to media_tv network, but I don’t see such network declared?

Oops, my bad! Posted an old config. This is the current one:

config igmpproxy
    option quickleave 1
    option verbose 3

config phyint
    option network wan_tv
    option zone iptv
    option direction upstream
#   list altnet 0.0.0.0/0
#   list altnet 185.24.172.0/24 <- tried with and without these
#   list altnet 185.24.175.0/24 <- tried with and without these
#   list altnet 185.41.48.0/24 <- tried with and without these
    list altnet 217.166.0.0/16

config phyint
    option network lan_tv
    option zone lan_tv
    option direction downstream
#    list altnet 192.168.4.1/24

Small update: I installed OpenWRT on a PC with an extra NIC, just to see if it may be a hardware/performance thing. Started from a fresh config. Same behaviour: no video on the STB and the WAN connection becomes unusable.

what do you mean exactly by “the WAN connection becomes unusable”?

As soon as the UDP stream starts up (over the iptv interface), any traffic over the wan interface times out. Pinging any internet address (like the freedom DNS server’s IP) times out, whether it is from the router itself or any other LAN device. When you go to the CD home page (and leave the stream), it only loads the menu after the IGMP group is left and the UDP stream stops – as soon as the stream stops, all wan traffic works as normal again.

(And if I just leave the STB on the channel, it eventually gives an S815 error – not sure if that’s directly related.)

And also from the router itself under that condition you cannot ping freedom DNS servers’ IPs?

igmpproxy adds a route IIRC when it goes into action so perhaps it’s interesting to compare the output of ip route show before and during the multicast delivery

It sounds to me like your routing is messed up and traffic goes over VLAN4 which obviously doesn’t work.

ip route show without any igmp action – it stays the same when igmp routes are active.

default via 185.93.175.233 dev pppoe-wan
100.64.0.0/10 via 100.68.210.1 dev br-wan.4  src 100.68.210.y
100.68.210.0/23 dev br-wan.4 scope link  src 100.68.210.y
185.93.175.233 dev pppoe-wan scope link  src 45.x.y.z
192.168.4.0/24 dev br-lan2 scope link  src 192.168.4.1

Pinging from the router while the UDP stream is going does work (poorly):

root@Wrt1:~# ping freedom.nl
ping: bad address 'freedom.nl'

root@Wrt1:~# ping 185.93.175.43
PING 185.93.175.43 (185.93.175.43): 56 data bytes
64 bytes from 185.93.175.43: seq=0 ttl=62 time=111.370 ms
64 bytes from 185.93.175.43: seq=1 ttl=62 time=204.011 ms
64 bytes from 185.93.175.43: seq=2 ttl=62 time=28.748 ms
64 bytes from 185.93.175.43: seq=3 ttl=62 time=114.942 ms
64 bytes from 185.93.175.43: seq=4 ttl=62 time=211.759 ms
64 bytes from 185.93.175.43: seq=5 ttl=62 time=35.137 ms
64 bytes from 185.93.175.43: seq=6 ttl=62 time=127.273 ms
64 bytes from 185.93.175.43: seq=7 ttl=62 time=219.025 ms
64 bytes from 185.93.175.43: seq=8 ttl=62 time=34.323 ms
64 bytes from 185.93.175.43: seq=9 ttl=62 time=126.091 ms
64 bytes from 185.93.175.43: seq=10 ttl=62 time=227.106 ms
64 bytes from 185.93.175.43: seq=11 ttl=62 time=44.034 ms
64 bytes from 185.93.175.43: seq=12 ttl=62 time=139.460 ms
64 bytes from 185.93.175.43: seq=13 ttl=62 time=223.175 ms
64 bytes from 185.93.175.43: seq=14 ttl=62 time=6.487 ms
64 bytes from 185.93.175.43: seq=15 ttl=62 time=6.403 ms
64 bytes from 185.93.175.43: seq=16 ttl=62 time=6.359 ms
64 bytes from 185.93.175.43: seq=17 ttl=62 time=6.544 ms
64 bytes from 185.93.175.43: seq=18 ttl=62 time=6.553 ms

So I can ping from the router, just with serious lag and DNS does not work. When the streams stops, it shoots back to ~6 ms (and pinging to friendly names works again).

So it does look more like congestion, I guess?

Here’s some traffic graphs that show what happens when I’m on a live channel:

lan3 (to the STB)


all other lan ports are quiet.

br-wan.4

br-wan.6

load during a stream:

What’s weird to me is that ~4Mbit/s are coming over VLAN 4 and ~1Mbit/s over VLAN 6 at the same time.

It’s not just this behaviour that causes the latency/timeouts though, since I get the same issues when running a HD stream on a Pi with VLC, but without the extra VLAN 6 traffic. Being able to run a lower bandwidth SD stream in VLC, but not an HD stream, is also an indication there is basic connectivity.

IGMP snippet:

 RECV V2 member report   from 192.168.4.4     to 224.0.251.124
 Should insert group 224.0.251.124 (from: 192.168.4.4) to route table. Vif Ix : 0
 No existing route for 224.0.251.124. Create new.
 Found existing routes. Find insert location.
 Inserting after route 225.0.71.1
 Inserted route table entry for 224.0.251.124 on VIF #0
 Joining group 224.0.251.124 upstream on IF address 100.68.210.y
 Joining group 224.0.251.124 on interface br-wan.4

 Current routing table (Insert Route):
 -----------------------------------------------------
 #0: Dst: 225.0.71.1, Age:2, St: I, OutVifs: 0x00000001, dHosts: not tracked
 #1: Dst: 224.0.251.124, Age:2, St: I, OutVifs: 0x00000001, dHosts: not tracked
 -----------------------------------------------------
 Route activate request from 217.166.225.124 to 224.0.251.124 on VIF[1]
 Vif bits : 0x00000001
 Setting TTL for Vif 0 to 1
 Adding MFC: 217.166.225.124 -> 224.0.251.124, InpVIf: 1

 Current routing table (Activate Route):
 -----------------------------------------------------
 #0: Dst: 225.0.71.1, Age:2, St: I, OutVifs: 0x00000001, dHosts: not tracked
 #1: Src0: 217.166.225.124, Dst: 224.0.251.124, Age:2, St: A, OutVifs: 0x00000001, dHosts: not tracked
 -----------------------------------------------------

---- 9 seconds later ----

 About to call timeout 6 (#0)

two things

  • have you looked at the packet counters, your dns resolves no longer working, and your pings would suggest you swamp the interface?
  • have you done a (brief) tcpdump -envi any to see what traffic is going over what interfaces?

Oh by the way, I don’t know if this really is a problem or not (some ramips architectures I know of for sure have issues with this) are you really using a bridge for your wan interface? If you can, use a plain lan/eth port and define a VLAN (802.1q) over them, to get e.g. a lan0.6 and lan0.4. Exclude lan0 from the br-lan bridge.

[edit]

I just looked again, and you are using a bridge wrapper over wan, try dropping that bridge and just define the vlans so you get wan.4 and wan.6. I’m sure you don’t need the bridge, but it might also cause issues for you here.

1 like

Check ook of de CPU/Hardware overbelast is, hetzij een hoge CPU load of percentage >0 IO-WAIT.

Thanks for the reponses so far.

I do not know, I’ll figure out how I can look at those :sweat_smile: .

I’ll do this and report back.

I couldn’t see another way to do this. The only VLANs I currently have are the ones defined for/by the WAN. I’ll see if I can change this.

However, I did try this on an old, but powerful tower PC with an extra NIC. There, the eth1.4 and eth1.6 were present without a bridge, and I had the exact same problem there.

I don’t think it’s a load problem, since a way more powerful PC has the same issue. The load is at max always below 1 (and the router has 2 cores). I’ll check with top though, only looked at the graphs so far.

I’ve removed all the bridge devices. Now PPPoE is just over wan.6, IPTV on wan.4, and I just have the STB’s interface directly connected to lan3. No difference yet.

During live stream, htop shows only luci-bwc 9 taking up some CPU, % between 3 and 16. Memory use is 30% at most. No io activity (at all, it seems).

Traffic on lan3 shows:

Many packets like:

ethertype IPv4 (0x0800), length 1370: (tos 0x0, ttl 61, id 824, offset 0, flags [DF], proto UDP (17), length 1356)
    217.166.225.124.49152 > 224.0.251.124.8248:
    BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2176913
     (invalid)

A bunch of these:

ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 20884, offset 0, flags [DF], proto UDP (17), length 44)
    192.168.4.4.54493 > 185.24.175.211.10001: UDP, length 16

and finally a bunch (but fewer):

ethertype IPv4 (0x0800), length 1372: (tos 0x90, ttl 123, id 2345, offset 0, flags [none], proto UDP (17), length 1358)
    185.24.175.211.10001 > 192.168.4.4.54493: UDP, length 1330

The packets from 217.166... show identically on wan.4 (just with ttl + 1, which makes sense).
The packets from and to 185.24.... show identically on wan.6:

ethertype PPPoE S (0x8864), length 66: PPPoE  [ses 0x5f6] IP (0x0021), length 46: (tos 0x0, ttl 63, id 18525, offset 0, flags [DF], proto UDP (17), length 44)
    45.137.x.y.54493 > 185.24.175.211.10001: UDP, length 16

ethertype PPPoE S (0x8864), length 1380: PPPoE  [ses 0x5f6] IP (0x0021), length 1360: (tos 0x90, ttl 124, id 61940, offset 0, flags [none], proto UDP (17), length 1358)
    185.24.175.211.10001 > 45.137.x.y.54493: UDP, length 1330

I haven’t figured out how detect an issue ‘packet counters’. I can see that the li-id of the 217.166... packets always skips 3 (2177004, 2177007, etc.), not sure if that means that it keeps dropping 2 packets every time, it is very consistent. The li-id’s are also the same on wan.4 as on lan3, so if packets get dropped, that doesn’t seem to happen after they’re proxied.


I temporarily set up OpenWRT to function as just a switch in my normal FB network. The STB works fully then. I can’t get as much details about the data, but I can see that the li-id’s are consecutive in that case.
In that case, all of the traffic goes over 217.166..., there’s no extra traffic going to/from 185.24.., so that’s a pretty big difference.

The UDP port 10001 packets are repair traffic. It means that your STB experiences packet loss indeed. I don’t think that VLC requests repair traffic, as it does’t have an idea from whom to ask that.

Don’t take any value in that li-id (Logical Interface ID) field. It is decoded wrongly as tcpdump is not aware that this is RTP-traffic. The RTP-counter is 16 bits, hence that would not count further than 65535 and then wraps to 0 again.

– Ariën

Right, thanks! So too many packets are dropped for the stream to work, and then repair traffic starts up. That explains the behaviour and the difference with VLC.

Then the mystery to me is why the packets are lost. If I can’t use the li-id to detect what’s lost, it may be tricky to test and debug that, too.

I’ve also set up OpnSense (on a FW4C) just to try a different approach. Exactly the same issue/behaviour!

So either the Fritzbox is doing something special that neither OpenWRT nor OpnSense are able to do (at least not by default or without special configuration); or the Draytek modem is the problem – since it is the only consistent piece of hardware in the failed setups.

Would it be worth getting a different modem to compare? Maybe try and get an old Fritzbox that still supports bridging.

I have no experience with openwrt or a Draytek dsl modem. What I do notice is that in all cases that it does not work the Draytek is present, you could set the FB so that all ports to your Asus are open (exposed host in FB, unfortunately you do have double NAT) to exclude the Draytek. In addition, you could compare the dsl info of the Draytek and the FB, there may be an incompatibility that is in the way. These are some suggestions to try.

Honestly, since your draytek bridges, you access vlans 4 and 6 from your router only, so you can pretty much exclude it as cause for this problem IMO, because it doesn’t even know what it’s forwarding.

I’ve heard about this issue before with OpenWRT from someone else. That person reported it worked fine with 22.x releases, but since 23.x stopped working. I wonder whether trying a 22.x release would work for you too. In that case Freedom’s/canal’s multicast iptv stuff requires something that KPN’s iptv stuff doesn’t need. From personal experience I know it works with 23.x on KPN connections.

Willing to try anything at this point, so I’ll try an older OpenWRT just in case, thanks.

However, I doubt that the potential issue in there is also what’s going wrong with OpnSense.

I’ll also try alternatives to igmpproxy, since that looks to be one thing that OpenWRT and OpnSense have in common. I kinda doubt that the proxy is the problem though. The UDP packets coming in over wan.4 go out fine to the STB.

My DSL speed isn’t anything to write home about (80-90 Mbit down, 28 up, at best, and https://www.waveform.com/tools/bufferbloat gives me horrendous results, even with the FB), so I’m not convinced yet that a poor(er) modem can’t be part of the problem.

Yeah, but your latency is around 10ms or so? 80Mbps is really more than enough. IPTV is not like anywhere near quality or something, so you have enough bandwidth with 10Mbps. Its not like 20 or 40Mbps you can get for an UHD stream on other providers. More like 4 or 5 Mbps IMO. In any case, you have plenty of bandwidth.

You can, however, enable SQM to see if capping it on the router makes things better under load.

One thing I wonder, when you have the FB trained in, does it also have 80/25 or, does it report much higher speeds? Draytek runs in 35b profile I presume?

Yeah, latency is 10 ms, and bandwidth-wise it should be plenty. I’m just guessing at packet-loss, but I’m not seeing errors in the Draytek, so probably just chasing ghosts.

FB: ~ 10300 kbit/s down, 30000 up, so that’s better down, worse up on paper, but not by a huge amount either way.

Draytek:

Edit: forgot to mention: Draytek is also in 17a pofile.

I’ve checked during IPTV streaming, and the Draytek doesn’t report any errors (HEC, LOS, LOF, didn’t bother to find out what all the abbreviations mean, since all the error counts stay 0). During streaming the “Bitswap” stays “ON” for downstream, but flips to “OFF” for upstream.

Running a speedtest gives better results for the FB, but only a 5-10 Mbit difference – biggest difference is on the upstream, nothing major.

The Fritz shows regular reports telling me “Impaired quality of the signal on DSL line 1 was detected due to incorrect cabling. The incorrect branch is 10 meters long. This costs around [~5500] kbit/s.” – but then, no issues with IPTV with the FB, so it shouldn’t be relevant.


I’ve tried SQM on OpenWRT (cake). I couldn’t choose any QoS settings for VDSL (only available for ADSL) on the Draytek. I will try some traffic shaping settings on OpnSense, but will have to read up on that some more first.