TL;DR
My ISP and IPTV provider at home provided me with two IPTV STBs which use multicast as a part of subscription. I'd like to lend the second STB to my parents in an apartment which has different ISP. I already have OpenWRT routers on both locations and L3 wireguard tunnel between them and access to LAN services works fine between locations (files sharing from NAS, Home Assistant, etc...).
More details:
STBs use multicast to deliver IPTV. I did some Wireshark analysis on what they do. They obviously use IGMP to subscribe to the current channel being watched. TV streams use UDP for transport and streams are sent to multicast IPs, different multicast IP for different channel being watched. UDP packets are less than 1300 bytes in length, so I thought there wont be any problems with fragmentation if I set up L2 tunnel (I tried gre4t for tunneling) between locations...
...however, upon closer inspection, the IPTV uses unicast https connections for loading TV UI and for other "control" connections like loading TV channel list etc. These are obviously TCP connections, but are more than 1400 bytes in length and therefore cannot pass through gre4t tunnel. These packet also have DNF bit set, so they do not get fragmented. From there, I see two options:
- either manipulate DNF bit for these HTTPS connections, or
- because I only have fragmentation issues with TCP connections, I could also adjust MSS on these connections, so TCP stacks on both sides should limit the segment size
As far as I understand, for both actions I would need these packets to pass through iptables, which they currently don't because they are caught by L2 tunnel. I also understood that I could set the net.bridge.bridge-nf-call-iptables but than all traffic passing through router, including that in different VLANs and LAN traffic between bridged WiFi and wired clients, would also go through iptables which I don't want and, besides that, would probably cause performance issues. Can I limit this command only to one bridge and leave br-lan as is? Any other solutions?
P.S. Gre4t tunnel over the abovementioned wireguard tunnel seems to work fine. I can see the broadcast traffic (ARPs, DHCP discoveries...) and my STB successfully gets IP address via DHCP on the remote location. Even the unicast TCP connection succeeds, TLS handshake completes, but fails when large HTTPS payload is dropped due to limited MTU in my L2 tunnel...