Thanks you again. I will take a detailed look at this setup.
In the Movistar setup, the querier is the igmp-proxy.
Yes, I remember that I tested the Asus as AP and had the same issues. But if I use the Asus as my main and only router , the TV doesn’t have any cuts or pixelation issues.
Tested again disabling ax2 wifi and installing the Asus as AP, and same cuts. There’s a problem in the ROS code for sure with igmp proxy.
First try it with an ethernet cable instead of WiFi to isolate that issue with multicast over WiFi.
Backup your AX config and throw the minimal i sent on there. See if it works in passthrough.
With the TV Box through ethernet, there are no cuts, only fast pixelations sometimes. But with the Asus router, TV Box through wifi works 100%
But my ISP TV require some special things like RIP, a special DNS for the TV Box, an option for the TV OPCH, and an option matcher in the DNS server.. This is the ISP setup I use:
:local iptv XX.XX.XX.XX/X
####################################################
/interface/bridge
set 0 igmp-snooping=yes
/interface/vlan
add interface=ether1 name=vlan2-iptv vlan-id=2
add interface=ether1 name=vlan3-telefono vlan-id=3
add interface=ether1 name=vlan6-internet vlan-id=6
/interface/pppoe-client
add add-default-route=yes disabled=no interface=vlan6-internet \
name=internet use-peer-dns=yes user=adslppp@telefonicanetpa \
password=adslppp
/interface/list
add comment=vlans-iptv-voip name=VLANs2&3
/interface/list/member
set [find where interface=ether1 and list=WAN] interface=internet
add interface=vlan2-iptv list=VLANs2&3
add interface=vlan3-telefono list=VLANs2&3
/ip/dhcp-server/option
add code=240 name=opch-imagenio value="':::::239.0.2.29:22222'"
/ip/pool
set [find name=default-dhcp] ranges=192.168.88.10-192.168.88.239
add name=iptv-dhcp ranges=192.168.88.241-192.168.88.254
/ip/dhcp-server/matcher
add address-pool=iptv-dhcp code=60 name=descos server=defconf \
value="[IAL]" matching-type=exact
/ip/dhcp-server/network
add address=192.168.88.240/28 comment=iptv-network \
dhcp-option=opch-imagenio dns-server=172.26.23.3 \
gateway=192.168.88.1 netmask=24
/ip/dhcp-client
add interface=vlan3-telefono add-default-route=no \
use-peer-ntp=no use-peer-dns=no
/ip/address
add address=$iptv interface=vlan2-iptv
/ip/firewall/filter
add action=accept chain=input comment="vlans: accept voip and iptv vlans" \
in-interface-list=VLANs2&3 place-before=\
[find where comment="defconf: drop all not coming from LAN"]
/ip/firewall/nat
add action=masquerade chain=srcnat comment="VLANs2&3: masquerade" \
out-interface-list=VLANs2&3
/ip/firewall/service-port
set [find name=rtsp] disabled=no
/routing/igmp-proxy
set query-interval=30s quick-leave=yes
/routing/igmp-proxy/interface
add alternative-subnets=0.0.0.0/0 interface=vlan2-iptv upstream=yes
add interface=bridge
/routing/rip/instance
add afi=ipv4 disabled=no name=rip
/routing rip interface-template
add instance=rip interfaces=vlan2-iptv,vlan3-telefono mode=passive
All options that have no issue traversing an L2 bridge.
I sent to support a pcap file capturing vlan2-iptv traffic (except UDP) and a support, just capturing when IPTV had a cut. Thay said that when the cut occurred, the bridge sent a general query and the client responses didn’t come back, so the group subscriptions are kicked. Those responses had to be loose somewhere. It is really strange, and had to be a Mikrotik issue, due that putting the Asus router itself results in no issues with TV, but putting the Asus as an AP through the ax2, results in same cuts.
Should be something related to MT and probably using wifi.
Actually it is not correct to stop a multicast stream immediately when there is no response to a query.
I don’t know if MikroTik use a well established IGMP implementation or have doctored their own (probably the latter) but the way it should work is: when a query is sent and a response received, the multicast group remains active again for some time X, and a new query is already sent at maybe X/2 or X/3 time, so when a single response is missed the stream is not immediately cut.
Similar to how a DHCP lease is extended not at the moment when it expires, but halfway through the lease time.
Probably a difference between your Asus router and the MikroTik router is that it handles this situation in a more sturdy way.
(this of course notwithstanding the issue with MikroTik WiFi not treating multicast optimally)
Probably you’re right! I really hope that the team can fix this, but I think they’re running out of ideas now. I will try to install an ethernet cable from first floor to connect the tv box wired, but I would like this bug to be fixed. I really want to use Mikrotik instead of Asus.
It’s also potentially the latter causes the former too, IDK. But if your at Wi-Fi basic rate, and stream does not fit, stuff is going to get dropped. And that dropped stuff might be IGMP.
Yes, there really should be multicast enhancement in the WiFi driver (multicast to unicast), but as he wrote it also happens with the Asus as an AP (and it undoubtedly has that) and is triggered by having the MikroTik router, it may be that the IGMP querier being buggy is the main cause.
Of course IGMP, being a datagram protocol, does not rely on the correct arrival of all queries and responses.
I think the time between queries should always be much shorter than the group timeout. A receiver that no longer wants the stream (e.g. when switching channels) should send a LEAVE message anyway.
Reading trough all of this, I think there are several issues at hand:
The ROS IGMP proxy querier encodes the max response time field wrong: First, the value is modulo 25.5 (255 = 0xFF), hence for 30s it is 4.4 = 30 - 25.5. Second, the max response time field is not just a 8bit binary value in 0.1s increments. Values above 12.8s (128 = 0x80) must be encoded as 8-bit floating point value. See RFC3376 Section 4.1.1. It seems to be another example of sloppy implementation of RFCs by MTs home-grown modules and lack of testing for RFC conformity.
As I understand it, the TV-box works well if connected with wired Ethernet to the Mikrotik router. Beside the problem above, the ROS IGMP proxy querier seems to work.
As the problem arises if connecting the TV-box with MT WiFi and M2U (multicast-to unicast conversion), the problem is probably there: To be able the send multicast packages individually as unicast to each STA interested, it needs to keep track of IGMP subscribers among WiFi STAs. For this, the WiFi AP internally also does kind of IGMP snooping and special handling of IGMP messages. My suspicion is there is something wrong with this, causing the observed delay for transporting multicast IGMP Query responses from the TV-box over WiFi.
You are right, the issue still exists when using the Asus as an AP connected to the ax2.
You are right, the issue still exists when using the Asus as an AP connected to the ax2.
Dou you also see the delay of TV-box IGMP Group query response if connected with the ASUS WiFi to the ax2?
As you have a MacBook, did you use monitor mode of the integrated WiFi to capture all packets on your SSID’s WiFi channel, not only Unicast/Multicast/Broadcast going to your MacBook? This would allow to check what’s really going on on the Air and also to see multicast packets going to the TV-box MAC instead of multicast MAC because converted from multicast to unicast. And also to exactly see what the AUSUS does differently when used for WiFi and routing.
Thanks for your detailed responses.
When TV Box is wired to an ethernet port of the ax2, there are NO cuts, only fast pixelations here and there. In a spanish Mikrotik forum, there are more users that report these pixelation when wired.
I have a theory. When a pixelation happens while wired, it would translate into a cut if wireless. I think it could be the same issue, but maybe I’m wrong. But no, there are no cuts when wired.
I’ll try to capture a cut using monitor mode of my MacBook and compare with a capture using the Asus.
I managed to capture in monitor mode while a cut occurred.
Here you can see the packets from ax2 to tv box (Commscope), and suddenly, some strange packets, seems that the conversation stops. I do not have too much more knowledge to see what is happening here. I will send the capture file to support in case they want to continue the investigation.
Whatever happens in your captures, it is some strange stuff. Something for MT to investigate.
I sent the file to support. Hope they can get some useful info.
Yeah just tested it myself and multicast-enhance doesnt seem to be working rip.
I’ll open a ticket about this 
Thanks! Hope the team can fix these issues.
I bought a second hand ac2 to test and make sure if it’s an issue that only affects ax devices. Will comment back when I get it.