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.

Introduction

Rappel

L’objectif est de faire fonctionner un décodeur TV en faisant passer les flux multicast sur un pont Wi-Fi. Dans la première partie, nous avons fait fonctionner ce décodeur en Ethernet et vérifier son comportement réseau. Désormais, rentrons dans le vif du sujet : on débranche le câble, et on essaie de passer en Wi-Fi.

Passer d’Ethernet à Wi-Fi

Naïvement, quand on débute en réseau, on pense qu’une trame qui passe sur un câble réseau ou dans un champ électromagnétique, c’est la même chose. Dans un cas on parle de Wi-Fi ou de 802.11, dans l’autre d’Ethernet ou parfois 802.3, mais seule la couche physique change, non ? Celle qui nous parait un peu mystique et dont on préfère confier la compréhension à des électronicien ou autres magiciens du bas niveau. On a tous mis en place un point d’accès Wi-Fi d’ailleurs, ça n’est si pas compliqué de passer de filaire à Wi-Fi. La réalité est un peu différente…

Tentative n°1 : répéteur Wi-Fi en mode bridge

Parti de ce principe, j’ai remis la main sur un vieux répéteur Wi-Fi Asus RP N12 qui propose un mode Wi-Fi vers Ethernet appelé Media Bridge. En avant, je configure la bestiole, voici d’ailleurs à quoi elle ressemble :

Le schéma est donc le suivant :

On a notre répéteur qui capte le réseau Wi-Fi IPTV du Mikrotik et qui le retransmet (commute) sur son port RJ45, lui-même branché au décodeur.

Chouette, la télé a internet ! Les métadonnées des chaines se chargent, je peux aller sur YouTube. Mais il y a un problème… aucune chaine ne fonctionne 🫠​. Cela dit, j’ai environ une image toutes les 20 secondes, et parfois le décodeur m’affiche une erreur réseau et m’invite à vérifier ma connexion ou contacter le support. Premier réflexe : la portée du Wi-Fi ne doit pas être bonne. Je déplace le répéteur à côté du Mikrotik, je tire un grand câble jusqu’au décodeur… même résultat. Je commence à flairer le problème de multicast, et ça ne m’arrange pas parce que je n’y connais pas grand chose.

Quelques recherches plus tard je comprends qu’il faudrait aller bricoler au niveau des commandes brctl et des fichiers du style sys/class/net/br0, c’est à dire ce qui contrôle les bridges, afin d’y ajuster des paramètres concernant le multicast tels que l’IGMP snooping. Ce répéteur ne fait pas grand chose d’autre qu’exploiter des fonctionnalités du noyau Linux et de proposer une interface web pour piloter tout ça. A ma surprise, un shell est accessible en Telnet, on peut donc s’y connecter facilement.

Bon, c’est une vieille version du noyau (2.6.36, sorti en 2010 !) avec juste un Busybox installé. Et les commandes que j’ai pu lire précedemment n’existent pas. Vieux noyau, fonctionnalités limitées, impossibilité d’installer des paquets… Je conclue qu’il gère mal le multicast et que je ne peux pas en faire grand-chose. Next !

Tentative n°2 : bridge avec un noyau récent

S’il suffit de mettre en place un bridge sous un Linux moderne, je vais m’en sortir. Je lance un live Ubuntu sur mon PC portable et je commence à regarder comment paramétrer un bridge.

Ben ça marche pas terrible… C’est pire qu’avec le répéteur en fait. Je suis sans doute nul en configuration de bridge sous Linux, mais je n’arrive même pas à fournir Internet à la télé cette fois-ci. En creusant je commence à comprendre : il existe plusieurs formats de trame en Wi-Fi, certaines contiennent 3 adresses MAC (🤨​) et d’autres 4 adresses MAC (🫨​). Ben, une trame, c’est pas 2 seulement ? Source et destination ? Et oui, le Wi-Fi n’est pas de l’Ethernet. Nous y reviendrons. En attendant, ça doit jouer un rôle dans nos problèmes, ce n’est pas si trivial que ça, de changer de média.

Je mets alors la main sur un programme prometteur : wlan_kabel. L’objectif est exactement celui recherché : faire un pont Wi-Fi depuis un PC portable. L’idée est d’utiliser la MAC de l’équipement que l’on veut relier au réseau (ici le décodeur) pour se connecter au point d’accès. C’est mieux mais c’est toujours pas ça : la télé ne reçoit pas les chaines. Encore une fois le multicast semble nous embêter.

Tentative n°3 : un pont Wi-Fi propre et qui marche bien

Je me dis que je vais devoir partir sur du matériel spécialisé, finalement. Les bridges Wi-Fi manuels avec du multicast ça fonctionne mal, pour une raison que je ne percute pas encore. Tant pis, confions cette tâche à un système fait pour cela : un vrai pont Wi-Fi Mirkotik. J’ai déjà un hAP lite ac, j’en commande un autre. Il y a plusieurs façons de gérer ça, je choisis le fonctionnement suivant :

• L’AP est en mode bridge : c’est une sorte de mode AP, mais qui n’accepte qu’un seul client. Parfait pour notre cas, on ne veut que connecter le second Mikrotik. Aussi le SSID est masqué : c’est propre.
• La station (le second Mikrotik) est en mode station bridge. Ce mode permet d’être client (station) d’un AP, et de pouvoir en même temps bridger les interfaces Ethernet.

Mais ne parlons pas trop vite : la télé reçoit Internet, mais ne reçoit pas les flux IPTV pour autant !

Dernière ligne droite

Là, j’ai passé pas mal de temps à fouiller les options de Mikrotik, essayer des trucs au pif et lire la doc. Il existe beaucoup d’options dont le nom n’est pas toujours très clair. Abrégeons : il faut activer le multicast-helper. Cette option, qui ne figure pas dans le GUI (en tout cas je ne l’ai pas trouvée) doit être passée en ligne de commande :

/interface/wireless/set wlan1 multicast-helper=full

Sitôt entrée, la télé fonctionne !

J’explique plus bas les effets de cette Sainte Commande. Juste pour le plaisir, voici d’autres options facultatives mais intéressantes :

• L’IGMP snooping, que j’ai déjà expliqué plus haut.
• Le multicast-router, qui permet d’indiquer derrière quelle interface du bridge se trouve le routeur multicast — utile pour optimiser.
• Le multicast-querier, dans le cas où l’on n’a pas de routeur multicast sur le LAN. Inutile dans notre cas.
• Le multicast-buffering, utile pour les appareils sur batterie pour l’économiser. Peut-être que ça change quelque chose dans notre cas…

La configuration finale est détaillée dans la conclusion.

On voit sur cette capture d’écran :

• l’IGMP snooping activé pour permettre le multicast-helper,
• le VLAN filtering activé pour permettre la prise en compte des VLAN,
• le PVID est à 100, ce qui correspond au VLAN ID de l’interface VLAN d’administration de l’équipement,
• dans la section IGMP snooping, le paramètre version n’a de sens que lorsque multicast querier est activé, ce qui est inutile dans notre cas.

Mais pourquoi c’est si compliqué ?

Il y a deux difficultés principales :

• faire un bridge Wi-Fi vers Ethernet,
• faire passer du multicast sur du Wi-Fi, notamment des flux conséquents.

Les bridge Wi-Fi/Ethernet

Il faut comprendre les différences entre Wi-Fi et Ethernet pour comprendre pourquoi il n’est pas évident de passer de l’un à l’autre, et quelles sont les limitations à le faire.

Wi-Fi vs. Ethernet

On l’a vu, outre les technologies physiques évidemment différentes, le format des trames Wi-Fi n’est pas celui des trames Ethernet classiques. De plus un AP (point d’accès) ne se comporte pas comme pas un simple commutateur (ou switch). Ce qu’il faut retenir, c’est que la notion d’association est centrale. Une station qui se connecte à un AP s’associe avec lui, et cet AP devient joue un rôle beaucoup plus important qu’un switch dans un réseau Ethernet. Un switch n’a aucun échange avec une station, si ce n’est la négotiation de vitesse et parfois quelques échanges d’infos (LLDP, …).

Un AP, lui, échange des clés de chiffrement, s’assure que les trames sont réceptionnées, veille à la qualité du lien, … Et notamment, c’est un interlocuteur intermédiaire à qui on va adresser nos trames. Ce concept n’existe pas en Ethernet : l’interloctueur à qui on adresse les trames est la vraie destination L2 (une autre station ou notre passerelle) ; on n’adresse jamais de trame à un switch (sauf quand on est nous-même un équipement réseau, ou que l’on veut administrer le switch). Rappelons qu’un switch n’a même pas besoin d’adresse MAC pour faire son boulot de commutation.

3 adresses ?

En 802.11, l’AP se positionne donc comme intermédiaire. C’est pour cela qu’il faut spécifier, en plus de l’adresse MAC destination, l’adresse MAC de l’AP. Et on se retrouve avec une trame à 3 adresses ! Le sens de chaque adresse dépend du cas, mais dans une communication Station → AP on retrouve :

• l’adresse MAC destination,
• l’adresse MAC de l’AP,
• l’adresse MAC source de la station.

Il y a une subtilité à bien comprendre, liée à la notion d’association : une trame provenant d’une station ne peut disposer comme adresse source que celle de la station. L’AP ne va pas accepter une trame dont la source ne correspond pas à l’adresse d’association.

Ce n’est pas la seule différence, il existe une quantité d’autres champs qui diffèrent des trames Ethernet. Wi-Fi et Ethernet sont donc deux ensembles de technologies L2 distinctes, mais interopérables notamment grâce à l’utilisation commune des adresses MAC et d’une logique de commutation compatible. C’est l’AP qui a la responsabilité de la transformation des trames Ethernet en trames 802.11.

Ce qui est un peu complexe finalement, c’est de faire cohabiter dans un même LAN les technos Wi-Fi et Ethernet. Quand on a du routage, on n’a pas tous ces problèmes : pas de commutation, pas d’adresse MAC qui passent d’une techno à l’autre, le L2 est transparent du point de vue du L3.

Donc comment on bridge ?

On l’a vu, passer de Wi-Fi à Ethernet ou l’inverse n’est pas qu’une histoire de medium physique. Un AP sait faire, mais peut-on le faire plus manuellement ? Sous Linux par exemple, la fonctionnalité de bridge entre 2 interfaces Ethernet ne date pas d’hier (de 1999 en fait, kernel 2.2). Mais quand on veut bridger de l’Ethernet et du Wi-Fi (eth0 et wlan0) on est dans un cas particulier. On ne peut pas faire de pont transparent comme en Ethernet à cause du changement de technologie L2. On peut l’émuler, avec quelques concessions.

Le problème est que wlan0 est connecté à l’AP en mode station (“client” Wi-Fi). L’AP considère donc que c’est un équipement terminal, pas intermédiaire. Or, on a 3 adresses MAC dans une trame Station-AP : la source, la vraie destination et l’AP. Si une trame arrive de eth0 et doit être commutée sur wlan0, pourrait-on mettre l’adresse MAC d’origine dans la trame Wi-Fi en adresse source, à la place de l’adresse de wlan0 ? Ben non, cf. plus haut. Il va falloir bricoler…

4 adresses ?

En fait, il existe d’autres formats de trame Wi-Fi. Et notamment le format 4addr pour 4 addresses :

• l’adresse MAC destination,
• l’adresse MAC de l’AP,
• l’adresse MAC source de la station,
• … et l’adresse MAC de l’équipement original.

Voici une capture d’écran d’une trame 802.11 issue du blog mrn-cciew. Elle montre bien 4 adresses MAC ainsi que les flags en question.

Les solutions

Finalement, on a plusieurs possibilité pour permettre à un LAN Ethernet de passer par une liaison Wi-Fi. Passons-en quelques une en revue maintenant que l’on a quelques éléments techniques.

Faire du 4addr

C’est la solution idéale : standard, propre, efficace. C’est ce qu’implémente Mikrotik en mode station-bridge : on est client d’un AP, mais on bridge vers un LAN Ethernet. Si on met juste en station, on ne pourra pas faire de bridge et on utilisera 3 adresses : on sera le seul client Wi-Fi comme prévu par la norme.

Pourquoi on ne fait pas ça tout le temps ? Il y a au moins deux raisons :

• Il faut que le driver le supporte. Ce n’est pas toujours (voire rarement) le cas sur du matériel grand public, et c’est normal, personne n’a besoin de faire ça sur son laptop. Et donc quand c’est implémenté, c’est pas forcément bien testé.
• En mode station l’AP peut très bien refuser les trames 4addr : quelle station aurait besoin de ce type de trame ? C’est louche, on drop.

Travailler sur IP

On n’en a pas parlé car l’idée était d’étendre le LAN sans complexifier l’architecture, mais il est tout à fait envisageable de mettre en place du routage pour cette problématique. Là, plus de problème d’adresse MAC non reconnue, on peut parfaitement faire cohabiter et discuter un réseau Wi-Fi d’un côté, et un réseau Ethernet de l’autre. Si on a des problèmes de box Internet qui refusent la création de route, on peut toujours faire du NAT. Cette solution n’est pas du bridging.

Rester en 3addr

La dernière solution est de rester en mode station avec 3 adresses, mais plutôt que d’essayer de remplacer l’adresse MAC de wlan0 par la vraie adresse MAC source, on peut faire l’inverse : utiliser l’adresse MAC de wlan0 à la place de la vraie. Ainsi l’AP accepte notre trame. Il faut pour cela maintenir une sorte de table d’association pour savoir comment traiter la réponse à cette trame. C’est une sorte de NAT de niveau 2 finalement. On peut appeler ça du MAC masquerade.

Non. Déjà parce que tout ce qui s’apparente au NAT est crado. Ensuite parce que c’est pas standard. Et enfin parce qu’à jouer à ça, on casse des trucs : et notamment… le multicast ! 😄​

Concrètement, on peut gérer ça avec ebtables ou parprouted. Je n’ai jamais pratiqué. On peut aussi optimiser un peu le truc avec un proxy ARP côté LAN Ethernet, pour éviter de balancer trop de broadcast sur le lien Wi-Fi.

Il faut tout de même retenir que le mode Station n’est pas fait pour ça, par design. Donner l’accès à un réseau à une autre machine lorsque l’on est client d’un AP ce n’est pas prévu par la norme, donc ce n’est pas propre et ça pose des problèmes quand on essaie de le faire.

Wi-Fi et multicast

Nous avons vu que Wi-Fi et Ethernet, c’est compatible mais pas si facile. Rajoutons-en une couche avec l’étude du multicast sur le Wi-Fi.

Fiabilité du lien radio

L’une des différences avec Ethernet est qu’en Wi-Fi la probabilité qu’une trame arrive intègre à destination est relativement faible. Là où un taux de perte d'1% en Ethernet est déjà très élevé, en Wi-Fi on a classiquement 5%, voire 10%. Rappelons que le Wi-Fi utilise des fréquences non soumise à licence donc utilisables par tout le monde (et particulièrement en 2,4 GHz : micro-ondes, Bluetooth, ZigBee, et d’autres choses). Cela implique qu’il n’y a aucune garantie que ça marche. Ethernet non plus d’ailleurs, c’est un protocole non fiable au niveau de la transmission, dans le sens où la livraison des trames à destination n’est pas garantie (contrairement à d’autres protocoles d’accès) ; mais son taux d’erreur, du moins en Ethernet commuté, est très faible en l’absence de problème matériel et respect des distances max. On peut optimiser et certains paramètres s’adaptent tout seul (choix des canaux notamment), mais ça reste moins fiable qu’Ethernet. Le risque d’interférence et collision est élevé, surtout en 2.4GHz. Rappelons que le Wi-Fi ne peut pas empêcher une collision, contrairement à l’Ethernet commuté (voir CSMA/CA).

Pour améliorer les performances sur un média si peu fiable, un mécanisme d’acquittement est mis en place. Je ne parle pas ici de l’acquittement des datagrammes TCP, mais bien d’un mécanisme au niveau de la transmission des trames. En Ethernet on sait détecter qu’une trame a été corrompue pour pouvoir l’ignorer (on confie en fait la responsabilité de la réemission aux couches supérieures, si besoin) ; en Wi-Fi on va toujours la réemettre.

Comportement standard du multicast

Ce qui vient d’être dit est valable pour les trames unicast. Le multicast reçoivent un traitement différent qui va nous embêter de deux manières :

• Il n’y a pas d’acquittement. Ce comportement est logique : une station qui acquitte est une station qui prend la trame en compte. Mais en multicast, on est en one-to-many : on ne sait pas quelles sont les stations intéressées, donc on ne peut pas savoir quels acquittements attendre. Rappelons en effet qu’une trame multicast n’est envoyée qu’une seule fois pour tout le monde.
  💡 Et l'IGMP snooping ?
  En effet l’IGMP snooping permet au switch (ou à l’AP) de connaitre les destinataires des trames multicast. Mais c’est un bonus, ce n’est pas une obligation de le mettre en place, et il y a des cas dans lesquels ce n’est pas suffisant pour savoir qui est destinataire.
• La vitesse de transmission est très lente. C’est le corrolaire du premier point : comme on ne peut pas savoir si la trame va être reçue, on la transmet lentement. Cela permet d’utiliser des modulations de signal moins sensibles au bruit et d’améliorer la portée. Lentement comment ? Très lentement : à la vitesse la plus basse supportée par tout le monde. On appelle cela le basic rate. Typiquement on va descendre à 6Mbps (ça dépend des normes, pour les anciennes on descend à 1Mbps). Avec l’IPTV on aime bien avoir 20Mbps. Hem, notre problème est peut-être là.

Rajoutons à cela que les implémentation du multicast diffèrent selon les AP, et il n’est pas rare de rencontrer des bugs, des limitations, voires des blocages. Et je n’ai même pas parlé de chiffrement : creusez les notions de group key, group cipher, etc.

Donc en fait le multicast en Wi-Fi ça marche pour les protocoles de contrôle (mDNS, etc.), mais pas pour les gros débits comme du flux vidéo. Pas de bol pour notre projet ! Il faut retenir que le multicast a été conçu pour Ethernet, avec un taux de perte < 1%. Il y a des solutions, que l’on verra plus bas.

Bridger du multicast sur du Wi-Fi

On a donc des problèmes pour passer de Wi-Fi à Ethernet, et des problèmes pour faire passer du multicast sur du Wi-Fi. Combinons les deux 🙂​.

Problématiques

Ce qui va nous embêter, c’est que certains AP ne vont pas simplement émettre des trames, mais dans le but de réduire le trafic et par souci de sécurité ils vont réfléchir : est-ce que cette station a légitimement besoin de cette trame ? Pour savoir cela, l’IGMP snooping va notamment être utilisé. Et quand on a un bridge en 3addr, la station associée n’est pas celle intéressée par les flux multicast, donc l’AP n’envoie pas la trame.

On n’a pas encore parlé de sécurité, mais en Wi-Fi les trames sont chiffrées avec une clé unique par client ; pour envoyer une trame à tout le monde ou à un groupe multicast, quelle clé utiliser ? Une autre clé, appelée Group Key, qui est partagée avec tous les clients. Cette clé doit être renouvellée régulièrement, et notamment lorsqu’un client quitte le réseau. Les clients sont sensés accuser réception de cette clé, mais si l’un des clients ne la reçoit pas, ou n’acquitte pas, il ne recevra plus les flux multicast. Cela n’est pas sensé arriver justement grâce au ACK car l’AP doit savoir si la clé a bien été reçue, mais certaines implémentations semble buggées. D’autres problématiques liées à de mauvaises implémentations remontent régulièrement sur les forums. Encore une fois, il faut donc privilégier du matériel professionnel ; celui destiné au grand public ne s’encombre pas de ce genre de fonctionnalités “avancées”.

On peut aussi citer les problématiques liées à la notion de client isolation : parfois les AP interdisent les communications de client à client, un peu à la manière du PVLAN. Dans certains cas, cela peut compromettre le bon fonctionnement du multicast.

Il y a d’autres problèmes liés au multicast sur du Wi-Fi mais qui sortent du contexte IPTV. La RFC 9119 décrit cela et propose des solutions.

Solutions

Il y a plusieurs angles d’approche pour faire fonctionner correctement du multicast sur un pont Wi-Fi. On l’a mentionné à plusieurs reprises, l’utilisation du mode 4addr est obligatoire si l’on veut respecter les standards et donc faire les choses proprement — un vrai réseau WDS est idéal. Mais encore faut-il disposer de matériel configurable et qui l’implémente bien.

Si l’on doit rester en 3addr, une solution qui fonctionne mais qui demande une architecture un peu plus compliquée est l’utilisation d’un tunnel : l’AP ne verra des trames qu’à destination d’une seule station, bien associée, et tout passera en unicast. Sans avoir testé je pense à GRE, Wireguard, un tunnel SSL ou même du VXLAN.

Enfin, une autre solution “toute bête”, qui fonctionne bien sans trop tordre les standards, est la conversion muticast → unicast. Il faut que l’AP le prenne en charge évidemment, mais cette solution nous permet de nous affranchir de tous les problèmes de débit faibles, non-acquittement, gestion des clés de groupe, etc. Attention toutefois à ne pas surcharger le réseau : si l’on a beaucoup de clients multicast qui écoutent des flux consommateurs comme de la vidéo et que l’on utilise de l’unicast pour tous, on va rapidement effondrer les performances. Les bridge sous Linux peuvent implémenter cette astuce, voir ici pour les zinzins qui voudraient en lire le code.

Cette dernière solution est celle que j’ai mise en place grâce à la fonctionnalité multicast-helper=full de Mikrotik, couplée à l’utilisation du mode 4addr.

Conclusion

Faire fonctionner un flux IPTV sur un pont Wi-Fi n’est pas une mince affaire. Il existe des solutions, notamment proposées par l’IETF dans la RFC 9119, mais leur implémentation dans les AP n’est pas systématique, et parfois buggée. Il faut donc utiliser du matériel sérieux et bien documenté — c’est le cas de Mikrotik, dans une gamme de prix abordable (un hAP ac lite coûte aujourd’hui une cinquantaine d’euros).

Le streaming (donc unicast) serait plus adapté à notre cas, d’ailleurs la lecture d’une vidéo YouTube depuis le décodeur fonctionne bien sans tous ces artifices. Mais je n’ai pas le choix, le décodeur reçoit la TV en multicast.

Résumé

La TV ne fonctionnait pas parce que :

• le MAC masquerade, utilisé par mon bridge Asus, casse le multicast,
• le mode 4addr, utilisé par mon bridge sous Linux, est mal implémenté ou refusé par l’AP,
• le multicast natif en Wi-Fi implique un débit très faible.

La solution proposée fonctionne parce que :

• le mode 4addr est bien implémenté sous Mikrotik et accepté par l’AP,
• Mikrotik propose la conversion multicast to unicast (RFC 9119).

Un schéma qui résume les configuration :

Limites

En vrai, la solution n’est pas idéale : j’ai régulièrement des artefacts audio et vidéo, plus rarement des freezes. Cela est principalement dû à une qualité de transmission pas géniale : murs très épais, vieux matériel.

Bref, pas évident de d’arriver à une bonne expérience télévisuelle à l’heure de la 4k en passant par un simple Wi-Fi en 2,4 GHz. J’ai noté des améliorations en activant le multicast-buffer sur le bridge, mais je ne sais pas si c’est du hasard car cette fonctionnalité est là pour économiser de l’énergie des stations sur batterie.

Axes d’amélioration

Du matériel plus récent et l’utilisation du 5 GHz me permettrait d’avoir un meilleur résultat. Le Wi-Fi reste dans tous les cas peu adapté à la diffusion d’un flux IPTV. La bonne solution est évidemment le réseau Ethernet filaire. Si on ne souhaite pas tirer des câbles on pourrait penser au CPL, mais cela reste peu adapté à l’IPTV :

• débits assez faibles et dépendant de l’installation électrique,
• fiabilité relative,
• ce n’est pas de l’Ethernet natif non plus : risque de nouveaux problèmes liés au multicast ? C’est à creuser.

Intégration dans une infrastructure existante

Cette section est un petit bonus. Elle vise à expliquer la configuration complète des deux Mikrotik. J’ai 3 réseaux : administration (VLAN 100), Wi-Fi guest (VLAN 101) et IPTV (VLAN 102). Le premier Mikrotik a besoin des 3 réseaux : son IP d’administration est dans le premier, et il diffuse les autre en Wi-Fi, chacun sur une antenne. Le second Mikrotik n’a besoin que de l’administration et de l’IPTV.

Ce schéma représente cela :

Côté routage c’est simple : le VyOS est la passerelle des 3 réseaux, et ceux-ci sont envoyés sur la fibre optique en mode trunk. En revanche la configuration des bridges sous Mikrotik n’est pas très instinctive, alors voici un résumé.

Chez Mikrotik, la fonction de commutation passe par l’utilisation de bridge. Un bridge est avant tout un groupement d’interfaces physiques. Ici c’est assez simple, les deux Mikrotik disposent d’un bridge : bridge1 d’un côté, bridge-wifi de l’autre (voir schéma plus haut). On retrouve sur le premier l’interface cuivre reliée à la fibre optique (côté VyOS et box) et les deux interfaces wlan. Sur l’autre Mikrotik, une interface wlan, connectée au réseau IPTV, et une interface cuivre qui va au décodeur.

Les bridges peuvent gérer les VLAN, il faut pour cela activer le VLAN filtering dans la configuration du bridge. Ici on a 3 VLAN ; pour les appliquer aux bons ports il faut aller dans le menu Bridge > VLANs. Ici on peut définir PVID, untagged VLAN et tagged VLAN sur chaque port. De plus, on va avoir une interface VLAN (SVI sous Cisco), qui est simplement une adresse IP positionnée sur le bridge dans un VLAN spécifique.

Ici on va avoir, sur le premier Mikrotik, la configuration suivante :

• Le VLAN 100 est taggé sur l’interface eth1 (uplink) et wlan1 : on en a besoin localement (interface d’administration) et également sur l’autre Mikrotik pour son interface d’administration.
• Le VLAN 101 est taggé sur l’interface eth1 et non taggé sur l’interface wlan2 : on se contente de le diffuser sur un SSID dédié.
• Le VLAN 102 est taggé sur l’interface eth1 et taggé sur l’interface wlan1 : on a besoin de le diffuser au 2nd Mikrotik, mais sur un lien trunk.

On retrouve cela sur Sur la capture d’écran ci-dessous, à l’exception du VLAN 101 qui n’était pas encore présent et d’un VLAN 100 accessible depuis wlan2 pour des tests.

Et sur le deuxième Mikrotik :

• Le VLAN 100 est taggée sur l’interface wlan1 qui sert d’uplink.
• Il est également déclaré au niveau du bridge-wifi car son IP d’administration est dessus.
• Le VLAN 102 (IPTV) est taggé sur l’uplink et non taggée sur ether1, sur laquelle est raccordé le décodeur.

Sources

• Extreme Networks — Broadcast and multicast traffic in a Wi-Fi Environnement
• Reddit — why multicast not easy for wireless
• RFC 9119 — Multicast Considerations over IEEE 802 Wireless Media
• Server Fault — Bridging wlan0 to eth0
• Super User — Why do some Wi-Fi routers block multicast packets going from wired to wireless
• Wyebot — Wi-Fi multicast benefits, problems and mitigation strategies
• Wiki Mikrotik - Multicast detailed example
• mrn-cciew — CWAP – MAC Header : Addresses