Dans le gite que j’ai rénové, attenant à ma maison, l’installation d’un téléviseur sur une liaison Wi-Fi a posé quelques challenges techniques assez rigolos. Ce que je pensais être une formalité m’a entrainé dans une sorte de rabbit hole qui m’a fait découvrir bien des subtilités. Dans cet article j’expliquerai l’architecture et les détails de configuration que j’ai dû mettre en place, et les notions que j’ai apprises.
Cet article traite de Wi-Fi et de multicast. Je suis bon ni en Wi-Fi, ni en multicast. Il ne s’agit que de partager ce que j’ai appris au cours de mon aventure pour faire fonctionner une télé sur un pont Wi-Fi. Il y a peut-être des erreurs et approximations que je serais ravi de corriger.
Introduction
Objectif
Je ne suis pas un amateur de TV, mais c’est toujours bien d’en proposer une dans un gite, surtout que les TV ou décodeurs modernes embarquent des applis comme YouTube ou Netflix, ou encore une Chromecast. Mais il faut tout de même proposer les chaines classiques. Cela peut sembler trivial, tout le monde ou presque a une TV, pas besoin d’être CCIE pour regarder TF1. Mais dans mon contexte technique, et à cause de mon obstination à faire les choses moi-même et de travers “juste pour voir”, cela n’a pas été si simple.
Commençons par rappeler le fonctionnement de la TV numérique, puis étudions pourquoi dans certains cas elle peut être capricieuse, et comment la convaincre de fonctionner.
Dans cette première partie, on va déjà essayer de faire marcher la TV en Ethernet, car il y a déjà quelques problématiques à résoudre avant de s’attaquer au sans-fil.
La TV sur IP
Aujourd’hui, on reçoit la plupart du temps la télévision depuis notre box Internet — c’est le cas avec Bouygues Telecom. On l’appelle l’IPTV car elle tire partie du protocole IP, qui lui permet de passer par Internet ; plus précisemment, l’IPTV utilise du multicast. Cela permet à un client de s’abonner à une source qui émet un flux réseau, dans notre cas un flux audio et vidéo, sans avoir à gérer une connexion entre la source et chaque client. La source émet le flux une seule fois, et tous les décodeurs TV peuvent s’y abonner sans que la source n’ait à établir une connexion individuelle avec chacun (contrairement au streaming). Cela permet une optimisation des flux réseau mais demande la mise en place de mécanismes relativement complexes au niveau du réseau.
Pour les malades qui veulent creuser, voir : IGMPv3 et PIM-SSM. Pour les autres je résumerai ce qu’il faut savoir.
- Une source, typiquement un serveur propriété de votre opérateur, qui met à disposition les flux.
- Le réseau interne de l’opérateur (backbone) qui a été schématisé par ces trois routeurs. Il est configuré pour prendre en charge le multicast (avec
PIM-SSMdans notre cas). - Au “bout du fil”, une box Internet, qui est à la frontière entre le réseau de l’opérateur et le réseau interne domestique. A cette box est raccordée le décodeur TV.
Notez que tout reste en interne opérateur, son décodeur propriétaire, dans votre salon, est programmé pour se connecter à son serveur IPTV.
Chaque opérateur diffuse la télé à sa façon. Chez Bouygues, mon opérateur, c’est de bout en bout. Chez d’autres, ça s’arrête plus haut dans le backbone, la partie terminale étant en l’unicast ; et parfois, tout est en unicast.
L’opérateur récupère généralement les flux source des chaînes via des accords de peering avec elles, permettant un échange direct de trafic, mais c’est un autre sujet.
Du coup où est le problème ? Contexte.
Pour l’instant pas de problème. Chez les personnes normales, le décodeur TV est donc branché en Ethernet à la box avec un câble réseau. Le décodeur réclame ses chaines avec des messages IGMP Membership Report, aussi appelé IGMP Join à la box et celle-ci sert de relai pour aller s’abonner à ce flux sur le réseau de l’opérateur grâce à PIM. Ainsi le réseau de l’opérateur se “configure” pour que les flux émis par la source en question arrive sur la box et soient relayés en direction du décodeur.
Dans mon cas c’est un peu plus compliqué. D’abord parce que la box n’est pas dans le même bâtiment que la télé. Vais-je payer un abonnement à une box juste pour avoir une télé, alors que j’en ai une chez moi à quelques mètres de là ? Ensuite parce que je ne peux pas tirer de câble réseau dans le coin télé (ou plutôt je n’ai pas envie de décorer les murs avec des goulottes). Il va donc falloir passer en Wi-Fi. Les décodeurs en Wi-Fi ça existe, mais dans certains cas une location de matériel supplémentaire est nécessaire : c’est le cas chez Bouygues Télécom (mon opérateur), il faut un bridge Wi-Fi → Ethernet propriétaire pour en fait brancher le décodeur en filaire dessus. Sans cet équipement spécifique on peut quand même connecter le décodeur en Wi-Fi, on a accès à Internet, mais pas aux chaine. Je n’ai aucune intention de louer quoique ce soit qui me semble faisable avec mon matos perso. Et si on bricolait ça nous-même ?
La TV sur IP sur Wi-Fi
Oui alors attention : les flux IPTV sont réputés peu compatibles avec le Wi-Fi, car celui-ci est relativement peu stable, sensible aux interférences, proposait jusqu’à il y a peu des bandes passantes limitées, et son principe de fonctionnement n’est pas vraiment adapté au multicast (nous y reviendrons). Les dernières normes Wi-Fi améliorent cela, mais encore faut-il disposer de matériel récent (donc coûteux) et bien configuré. Ce que je n’ai pas 🙄.
On fait comment ?
Il y a donc 2 problèmes à gérer : l’acheminement du réseau jusqu’au gite, et le transport de l’IPTV sur du Wi-Fi. Voyons voir où cela nous mène. Cette première partie est consacrée au premier problème, la seconde partie au second problème (🧠).
Amener le réseau
L’idée de fournir du réseau au gite est arrivée bien avant ces réflexions sur l’IPTV. J’en avais de toute façon besoin pour mon bureau de télétravail que j’y ai aménagé, et également pour l’accès Wi-Fi des locataires. Ce que je vais décrire ici a été fait sans notion d’IPTV en tête, mais a servi de base comme on le verra par la suite.
Fibre optique domestique
Je trouvais ça marrant de tirer une rocade optique entre les deux maisons. Mais où se raccorder ? Sur le PTO : Point de Terminaison Optique. C’est le petit “boitier fibre” sur lequel est branché la jarretière qui est reliée à votre ONT (ou directement votre box). Lorsque la fibre a été installée dans mon village, j’ai fait relier ma maison pincipale de façon normale, mais aussi le gite, sans abonnement : juste un PTO et une soudure au PBO de la rue. J’ai gentiment demandé aux techniciens de me détourner un petit bout de fibre (quelques mètres). Les trous dans les murs de 70cm d’épaisseur ayant déjà été percés, passer la fibre d’une maison à l’autre n’a pas été très compliqué. J’ai juste dû rajouter une prise de courant à proximité (et donc percer un mur de 70cm 🙃).
Avec l’aide d’un copain équipé, j’ai pu souder cette fibre entre mes deux PTO : j’ai maintenant une rocade optique qui relie mes deux maisons, sur un port dédié de leurs PTO respectifs.
Un PTO c’est ça. Ici on voit sur l’image de gauche les deux fibres, tout à gauche : l’une vient du PBO, l’autre du gite. Et même image sur la droite :
- Une jarretière blanche, c’est mon arrivée FTTH qui va sur mon ONT.
- Une jarretière jaune, c’est ma fibre inter-maison qui va sur mon serveur Proxmox VE.
Sur l’image de droite, les fibres opérateur et inter-maison arrivent dans le boitier, le trou est directement derrière. On voit la jarretière jaune qui fait partie de la même liaison que celle de la photo de gauche, mais de l’autre côté de la rocade. Pas de jarretière blanche car pas d’abonnement, mais le premier connecteur est bien relié au PBO.
On branche quoi de chaque côté ? N’étant pas équipé en commutateur fibre optique, je passe par un petit convertisseur de chez FS de ce genre là, et une paire de SFP BiDi.
Pourquoi ne pas avoir tiré du cuivre du coup ?
Les PTO sont conçus pour accueillir jusqu’à 4 connecteurs SC. Lors de l’installation de la FTTH dans le gite, un seul connecteur était livré avec. J’ai dû en ajouter un autre (récupéré sur un vieux tiroir optique inutilisé), car je voulais garder la liaison vers le PBO pour le jour où je souhaiterais commander un abonnement dédié dans cette maison. Fait intéressant, la fibre que l’on m’a donné comporte deux brins. Seul un est soudé, mais j’ai la possibilité de doubler cette liaison inter-maison.
Côté maison d’habitation, le câble est ensuite branché sur un port réseau dédié de mon serveur Proxmox VE, qui atteri sur une interface trunk de mon routeur virtuel sous VyOS. De l’autre côté, c’est un petit Mikrotik hAP ac qui sert de commutateur d’accès local. Il ne dispose que de ports 100Mbps ce qui ne va pas nous arranger pour avoir de bons débits, ainsi que de deux interfaces WLAN (802.11b/g/n pour la première et 802.11a/n/ac pour la seconde). Un petit schéma s’impose :
NB : chez moi, le PM et le NRO sont dans le même shelter, dans deux locaux différents.
Je peux donc amener dans le gite un ensemble de réseaux via cette rocade (peut-on parler de rocade quand on n’a qu’un brin ?). Le VyOS s’occupe de la partie routage, filtrage, DHCP, et NAT pour éviter les problèmes de route au niveau de la box : on ne peut pas modifier la table de routage d’une BBox, encore moins créer des sous-réseaux, d’où la nécessité de mettre en place un vrai routeur.
La configuration d’un routeur VyOS est d’une simplicité redoutable malgré le nombre hallucinant de fonctionnalités. Ici mon interface “WAN” sur le réseau de ma BBox, mes sous-interfaces LAN pour mes différents réseaux internes dont ceux du gite, et un exemple de NAT (nécessaire car sinon ma BBox ne sait pas router, il faut tout masquer derrière le VyOS) :
emile@vyos# show conf
[...]
ethernet eth0 {
address 192.168.1.253/24
}
ethernet eth1 {
vif 10 {
address fe80::1/64
address 192.168.10.1/24
description Serveurs
}
vif 101 {
address 192.168.101.1/24
description "Wi-Fi gite"
}
vif 102 {
address 192.168.102.254/24
description "IPTV gite"
}
}
[...]
nat {
source {
rule 10 {
outbound-interface {
name eth0
}
source {
address 192.168.10.0/24
}
translation {
address masquerade
}
}
[...]
}
}
Certains paramètres ont été modifiés pour anonymiser, d’autres dont été omis par souci de concision.
Le Mikrotit sert notamment à diffuser un réseau Wi-Fi dans le gite. Mais nous, on veut la télé ! Il n’y a plus qu’à créer un VLAN dédié IPTV, le raccorder d’une manière ou d’une autre aux flux que récupère la box, et le diffuser en Wi-Fi dans le gite… n’est-ce pas ? 😥
Faire arriver l’IPTV…
On a vu tout à l’heure que la box avait un rôle particulier dans la récupération des flux IPTV depuis la source. Mais là, je passe par un routage intermédiaire, ça va poser problème : rappelons qu’IGMP n’est pas conçu pour être routé, alors comment faire ? La réponse s’appelle l’IGMP proxy, et VyOS l’implémente. C’est très simple :
emile@vyos# show protocols igmp-proxy
igmp-proxy {
interface eth0 {
alt-subnet 0.0.0.0/0
role upstream
}
interface eth1.102 {
role downstream
}
}
Ici eth0 est la patte qui va sur la box, et eth1.102 est la subinterface correspondant à mon réseau dédié IPTV, donc le VLAN dans lequel je vais placer le décodeur in fine. La commande alt-subnet 0.0.0.0/0 me permet de recevoir du trafic de sources distantes (sans cette commande VyOS n’accepterait que les sources sur le réseau de ma box). J’aurais pu affiner. Le reste va de soi ; plus d’infos sur la doc officielle.
Pour les gens pas à l’aise avec la notion de subinterface, il s’agit simplement d’une interface IP dans un VLAN (appelé
SVI ou interface VLAN sous Cisco), attaché à un port trunk. On parle aussi de vif pour virtual interface : sur un routeur chaque port physique porte une IP, mais là on a plusieurs IP sur le même port, on virtualise donc des interfaces. Ici eth1 est une interace physique en mode trunk, qui virtualise plusieurs interfaces (une par VLAN) qui portent chacune une IP.
…et l’envoyer sur la télé
A partir de là, il suffit de configurer un port du Mikrotik en access sur le VLAN IPTV, et on devrait recevoir les chaines. Le décodeur acquiert une IP en DHCP (donc le Mikrotik commute bien ce VLAN), il fait ses requêtes IGMP, et reçoit le flux TV 🥳.
Analyse
On peut en profiter pour regarder quelques éléments techniques, notamment les adresses IP utilisées en faisant une capture réseau. On filtre sur l’IGMP d’abord, et les flux IPTV ensuite. Wireshark interprète parfois ça comme de l’APD (Aruba Discovery Protocol, rien à voir), mais peu importe. Pour bien comprendre, 192.168.102.1 est mon routeur VyOS qui sert de proxy IGMP, et 192.168.102.13 est le décodeur TV.
NB : la seconde capture a été prise au niveau du lien d’uplink, d’où la présence d’une trame 802.1Q.
On remarque que l’adresse IP de la source est toujours 89.86.97.6. Cette IP appartient à Bouygues Telecom, ce qui est parfaitement logique.
Les IP publiques sont attribuées par les RIR, tels que le RIPE NCC en Europe. Sans rentrer dans les détails, elles sont liées à un Système Autonome (AS) qui est la propriété d’un organisme. Ici on peut rechercher l’IP en question sur un outil comme celui-ci ou celui-là qui vont piocher dans les bases de données des RIR. On apprend donc que l’AS qui annonce cette IP est
Bouygues Telecom SA (ASN 5410), qu’elle fait partie d’un /12 acquis par Bouygues en 2006, etc.
On voit aussi que les flux IPTV sont adressés à 232.0.64.204, mais j’ai aussi vu passer 232.0.64.25, 232.0.64.216, et d’autres. Il semble y avoir une IP par chaine, dans le réseau 232.0.64.0/24. A qui appartient-il ce réseau ? Personne, c’est un réseau réservé au multicast, plus spécifiquement tout le 232.0.0.0/8 est attribué par l’IANA au source-specific multicast (SSM) en vertu de la RFC 5771. Donc tout le monde peut l’utiliser, mais en interne seulement, il n’est pas routable sur Internet.
Ces IP correspondent donc aux groupes multicast des différentes chaines TV : quand on zappe, on s’abonne à un groupe en en faisant la demande en
IGMP, puis la box en informe le réseau de l’opérateur pour qu’il nous envoie les flux correspondant à ce groupe. Les flux sont envoyés par la source à l’adresse du groupe, une seule fois, et le réseau se “débrouille” pour envoyer le flux où il faut (là où il y a des abonnés). Ce “débrouillage” est précisemment le rôle de PIM. A la fin, notre décodeur écoute les flux qui sont adressés à l’IP du groupe en question, et si tout est bien configuré, il ne reçoit de toute façon que ces flux là.
Notez le message leave du groupe 232.0.64.216 puis le join (membership report) du groupe 232.0.64.25. On vient de zapper !
Un petit schéma pour digérer tout ça :
Heu alors par contre y’a un petit problème. Les adresses en 232.0.0.0/8 on l’a dit c’est du PIM-SSM. Ce mode de multicast repose aussi sur l’IGMPv3. Mais là, on voit de l’IGMPv2 (et ce n’est pas une erreur d’interprétation de Wireshark). Pire encore, on voit des IGMP membership report de la part du décodeur pour le groupe 224.0.0.22. Cela n’a aucun sens :
- Ce groupe est normalement celui des routeurs
IGMPv3, aucun client n’est sensé le rejoindre. - Normalement les clients multicast
IGMPv3envoient leurs demandes d’adhésion de groupe à cette adresse (l’adresse du groupe en question étant contenue dans le message IGMP). Par exemple on veut rejoindre232.0.64.216, on envoie un messageIGMPv3contenant “je veux rejoindre232.0.64.216” à l’adresse224.0.0.22, qui est “écoutée” par le routeur multicast (la box). - En IGMPv2 c’est différent, on envoie les demandes d’adhésion à l’adresse IP du groupe lui-même.
- Là, le décodeur envoie en IGMPv2 une demande d’adhésion au groupe
224.0.0.22🤔.
L’utilisation d’IGMPv2 peut s’expliquer par le fait que la source des flux étant de toute façon connue par le décodeur et/ou la box (hardcodée), il n’est pas nécessaire de faire du source-specific, donc on peut simplement faire de l’IGMPv2 qui est moins complexe ; on saura faire du PIM-SSM côté WAN car on connait la source. Ce n’est malgré tout pas standard, et cette explication est à prendre avec des pincettes.
Pour les adhésions au groupe 224.0.0.22, je n’ai aucune explication à donner outre une implémentation foireuse. Si quelqu’un en a une…
Bon, à part cette bizarrerie la TV fonctionne, mais on veut maintenant que ça passe par du Wi-Fi. C’est si pénible ? Oui ! La suite au prochain épisode…