Bouygues Telecom TV Without the Bbox: IPTV Multicast Behind a GPON SFP Stick

Replacing the Bouygues Telecom Bbox with your own router is well documented for internet: a GPON SFP stick with the ONT identity cloned, VLAN 100, DHCP. The TV decoder is a different story. You get the channel list, the program guide, the menus... and a black screen with an error on every live channel.

Live TV on Bouygues fibre is IPTV multicast. The decoder asks for a channel with an IGMP join, and the fibre network sends the stream only if that join arrives exactly the way it expects. Here is the configuration that works, and nothing else.

The setup

Fibre ── GPON SFP stick ── router (VLAN 100, internet)
                              │
                              ├── IGMP proxy (upstream: VLAN 100, downstream: TV VLAN)
                              │
                              └── TV VLAN ── Bbox TV decoder

• A GPON SFP stick in the router's SFP cage, registered on the line with the identity of the Bouygues ONT (serial number, PLOAM password). Internet runs on VLAN 100.
• The decoder sits on its own VLAN (VLAN 50 here), with its own subnet and DHCP.
• An IGMP proxy relays the decoder's joins from the TV VLAN to VLAN 100, and the streams back.

In my case the router is a MikroTik RB5009 and the IGMP proxy runs in a small Debian container on Proxmox, bridged at layer 2 onto VLAN 100. The rules below apply to any router.

The five things that must be right

1. An IGMP proxy between VLAN 100 and the TV VLAN

igmpproxy is enough. Upstream is VLAN 100, downstream is the decoder's VLAN, and altnet 0.0.0.0/0 accepts streams from the Bouygues public sources:

phyint eth0-up.100 upstream  ratelimit 0  threshold 1
        altnet 0.0.0.0/0
phyint eth1-down downstream  ratelimit 0  threshold 1

Disable reverse path filtering, or the kernel drops streams coming from public sources on an interface with a private address:

net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0

Why not the MikroTik's own IGMP proxy? I tried it: RouterOS /routing igmp-proxy with the same upstream and downstream, firewall rules and priority 5. It does not work. It sends its joins as IGMPv3, the Bouygues network ignores them (see the next point), and RouterOS offers no option to force version 2. That is why the proxy runs on a small Linux box next to the router, where the IGMP version can be forced.

2. IGMP version 2, forced

The Bouygues network answers IGMPv2 joins only. A Linux kernel sends IGMPv3 by default, and the OLT silently ignores it. Force version 2 on the upstream interface and on all, because the kernel uses the higher of the two values:

sysctl -w net.ipv4.conf.all.force_igmp_version=2
sysctl -w net.ipv4.conf.eth0-up.100.force_igmp_version=2

On a MikroTik, this is not possible: the RouterOS IGMP proxy has no setting to choose the IGMP version of the joins it sends upstream. (The bridge's igmp-version only applies to its snooping querier.) The proxy sends IGMPv3, which is why it cannot be used here.

3. 802.1p priority 5 on the IGMP joins

This is the one almost nobody gets right, and it is the one that makes the difference. Outgoing IGMP on VLAN 100 must carry 802.1p priority (PCP) 5.

The reason is inside the GPON stick. The OLT tells the stick to send each 802.1p priority on its own upstream GEM port, and it listens for IGMP only on the GEM port of priority 5. A join marked 0 or 3 leaves the stick on another GEM port and the OLT never sees it. Everything looks fine on your side, and still no stream comes back.

On a Linux VLAN interface, map every priority to 5:

ip link set eth0-up.100 type vlan egress-qos-map 0:5 1:5 2:5 3:5 4:5 5:5 6:5 7:5

On RouterOS, a mangle rule does the same:

/ip firewall mangle add chain=output protocol=igmp out-interface-list=WAN \
    action=set-priority new-priority=5 comment="IGMP PCP 5"

4. No bridge in the path may eat the IGMP

IGMP snooping on a bridge only forwards joins towards ports it considers to be multicast router ports. Get this wrong and joins die silently on the way. You will see the decoder's leaves (sent to 224.0.0.2, always flooded) but never its joins.

• RouterOS: set igmp-snooping=no on the bridge carrying VLAN 100. I also run the SFP port and the port towards the proxy with hardware offload off (hw=no).
• Linux / Proxmox bridge: snooping is on by default. Mark as permanent router ports both the uplink towards the fibre side and the proxy's downstream port:

bridge link set dev enp2s0 mcast_router 2       # uplink towards the router/fibre
bridge link set dev veth101i1 mcast_router 2    # proxy container, TV side

The second one is easy to miss. A port learned as a router port expires after a few minutes, and the picture cuts out about 4 minutes into a channel. The container's veth is recreated each time the container starts, so on Proxmox set it from a hookscript (pct set 101 --hookscript local:snippets/…) in the post-start phase.

5. The GPON stick: nothing special

Once the four points above are right, the stick needs no extra tuning. The line identity (serial number, PLOAM password) is enough: the OLT provisions the multicast objects itself when the stick registers. This setup is validated with two sticks: an FS.com GPON-ONU-34-20BI and a Huawei MA5671A, both with the stock firmware.

If a stick seems to drop the TV, check the four points above before blaming it. A join lost on the way looks exactly like a stick that cannot do multicast.

Checking that it works

Watch the upstream interface while the decoder tunes a channel:

tcpdump -ni eth0-up.100 'igmp or (udp and net 232.0.0.0/8)'

You want to see an IGMPv2 report for a 232.0.64.x group, followed within a second by a steady UDP stream (about 1,200 packets per second for an HD channel). Then check the proxy route:

ip mroute show
# (89.86.97.6,232.0.64.205)  Iif: eth0-up.100  Oifs: eth1-down  State: resolved

One last detail: after a reboot, the decoder waits about a minute before its first join. Don't conclude too fast.

In short