BT TV (Multicast IPTV) problems with Adaptive QoS

[Vexira]

I think i might know what's going on. (But I am not an IT person or network engineer so this is just a wild guess)

Take a look at netstat -anr

If says that if any destination IP leaving your router matches your current WAN address, it will be routed through the eth0 interface.

It then says if any destination IP matches your LAN address range, it will be routed through br0 interface.

The issue here with multicast streams and these rules is that their destination IP is 224.0.0.0 through 239.255.255.255 (not your actual device like regular internet traffic)

With that different approach to the destination IP it does not match either of two the interface routing rules mentioned before.

I also believe that the rules are executed from top to bottom. With that said I believe the last rule listed as 0.0.0.0 with a gen mask 0.0.0.0 is a catch all for all IP's not matched by all of the multiple beginning rules. Aka it takes all IP's not yet caught (0.0.0.0 - 255.255.255.255) and chooses route them through the eth0 interface.

As you know that is the defined upload interface for the QOS engine when the traffic finally has to pass through there.

If my thinking is correct, I wounder if we can change the last routing rule to default to br0 (makes more sense QOS purposes), or if we could include the multicast IP range and send only that through br0.

Note this is not my field and I am clueless as to the feasibility my statements. Maybe it has to be eth0 for some technical reason or another.

What I do know is you can create a QOS rule so that multicast traffic will not be throttled against your QOS upload limit at all. (While it is impossible to have it properly count as your download QOS limit since it's on the eth0 interface the best we can do is 0 rate it and pretend it doesn't exist.)


Maybe someone will chime and see if they could fix what interface the kernel is routine through to allow QOS to properly pick it up.

Good luck.

I think you should ask Merlin, he might have a better idea of it.

 

[HeadBanger]

You need to private message him.

I did as well as raising a support case directly with ASUS. I have not heard anything back yet.

HB


Sent from my iPhone using Tapatalk

 

[Vexira]

He's quite busy.

 

[FreshJR]

To take it outside of QOS, just run this command in putty.

realtc filter add dev eth0 protocol all prio 1 u32 match ip dst 224.0.0.0/4 flowid 1:2

if it doesn't work, try running this one aswell

realtc filter add dev eth0 protocol all prio 1 u32 match ip src 224.0.0.0/4 flowid 1:2

If the command starts working, you can put it into my QOS script so it automatically get applied.
If either command does not work, you can restart QOS to clear it from the config. Finding a packet using wireshark could then help since we have to see if multicast content is within 224.0.0.0 - 239.255.255.255


Sorry it took so long for two simple commands. I was a little preoccupied.

Note, this traffic will not be "metered", so QOS will not be accurate while watching multicast content, but at least its a workaround so it is not limited to the upload limit.

I think the real issue/fix is within the routing table, but I do not know how to modify it without research.

 

[brummygit]

Thank you @FreshJR but for some reason on the latest RMerlin betas the multicast traffic is no longer showing in QoS (but does show in Merlin's normal traffic stats) so it seems Asus have made a change. The reason my reply took a few days was to allow me to fully test this as I've been waiting more than a year for Asus to fix the problem.

I'll keep an eye on things and use your rule if I have any further problems.

Thanks again, much appreciated.

 

[FreshJR]

Not even sure it works.

But it's great that you don't need it.