Meraki MR 32.2.5.1 : le correctif des latences et pertes Wi-Fi 5 GHz

Un ordinateur affiche toujours quatre barres de Wi-Fi. Il reste associé à la borne, conserve son adresse IP et apparaît normalement dans le dashboard. Pourtant, un appel Teams se fige, les pages mettent plusieurs secondes à répondre et les paquets vers la passerelle se perdent. Le réseau semble connecté, mais il ne fonctionne plus correctement.

Nous avons rencontré ce tableau sur plusieurs réseaux Meraki exploités pour nos clients. La difficulté était sa nature intermittente : une borne pouvait fonctionner pendant des heures, se dégrader sans saturation radio évidente, puis retrouver provisoirement un comportement normal après un redémarrage ou un changement de canal.

La version Meraki MR 32.2.5.1, documentée le 5 novembre 2026, corrige deux défauts capables de produire ces symptômes : MR-99882 et MR-104909. Ils se ressemblent du point de vue de l'utilisateur, mais ne touchent ni exactement les mêmes bornes, ni les mêmes versions, ni les mêmes mécanismes radio. Les distinguer évite de transformer toute lenteur Wi-Fi en diagnostic automatique.

Ces incidents sont déroutants parce que les indicateurs habituels ne racontent pas immédiatement la panne. Le terminal ne se déconnecte pas forcément. Le SSID reste visible, l'authentification a réussi et le client apparaît dans le dashboard. Le support reçoit alors des descriptions vagues : « Teams coupe », « Internet est lent », « le Wi-Fi rame » ou « cela fonctionne après avoir coupé et rallumé la borne ».

Plusieurs causes ordinaires peuvent produire une expérience proche : signal faible, interférences, canal saturé, roaming tardif, problème DNS, accès Internet dégradé ou application distante indisponible. Une analyse des canaux Wi-Fi 5 GHz et du niveau de signal reste nécessaire. Mais dans les deux bugs corrigés, la panne peut apparaître sans forte utilisation du canal ni interférence évidente.

Il faut donc regarder plus loin que l'état « connected ». Les tests utiles sont simples : latence et pertes vers la borne ou la passerelle, débit dans les deux sens, comportement de plusieurs clients associés au même point d'accès, canal utilisé et version exacte du firmware. Un appel vidéo permet de constater l'impact, mais il ne suffit pas à identifier la cause.

MR-99882 est le problème au périmètre le plus large. Cisco Meraki confirme les modèles et versions suivants :

Les clients 5 GHz peuvent subir des pics de latence intermittents, des pertes de paquets et une baisse importante du débit tout en restant associés. Les applications en temps réel sont particulièrement sensibles : l'audio ou l'image d'une visioconférence peut s'arrêter, saccader ou devenir inutilisable. La navigation ordinaire peut également ralentir ou échouer.

Meraki a reproduit le problème sur une MR46 servant huit clients 5 GHz avec un trafic audio et vidéo bidirectionnel continu. Une borne sur un canal adjacent servait quinze autres clients chargés. Cette reproduction ne signifie toutefois pas qu'il faut 23 appareils ou une forte densité pour déclencher le bug. Cisco mentionne aussi des signalements avec peu de clients et sans occupation radio anormale.

L'analyse de l'éditeur relie la dégradation à des échecs de transmission pendant le single-user transmit beamforming. Ce mécanisme adapte la transmission radio vers un client. Dans certaines séquences, des chemins de récupération ne restauraient pas correctement l'état de la radio. Le trafic continuait alors à être traité dans un état dégradé.

Désactiver le beamforming descendant ou l'OFDMA n'a pas empêché le comportement rapporté. Un redémarrage ou un changement de canal pouvait rétablir temporairement le service, mais déconnectait les utilisateurs et ne supprimait pas la cause. Avant MR 32.2.5.1, aucun contournement limité à la configuration n'était confirmé ; le support Meraki pouvait recommander un retour vers une version MR30 ou MR31 compatible.

MR-104909 produit une expérience proche, mais son périmètre est plus précis :

Les clients peuvent connaître plusieurs secondes de latence et des pertes répétées, y compris lorsqu'ils contactent la borne ou la passerelle locale. Tous les appareils reliés à la même borne peuvent être touchés. Le défaut ne suppose pas qu'un radar ait été détecté ni qu'un administrateur ait changé manuellement le canal.

Sur un canal DFS, la radio doit respecter des règles de coexistence destinées à protéger les systèmes radar. Dans la situation décrite par Cisco, des balises voisines n'annoncent pas leur capacité à tolérer certaines réponses OFDMA étroites. La borne limite alors automatiquement la largeur disponible pour ces réponses. Le planificateur pouvait malgré tout conserver trop de clients dans un même groupe OFDMA, créant des allocations qui se chevauchaient et faisaient échouer les échanges.

Le redémarrage constitue ici un mauvais test de fermeture : la dégradation peut revenir quelques minutes plus tard. Désactiver le single-user transmit beamforming ne l'empêche pas non plus. Avant le correctif, Meraki recommandait d'utiliser un canal non-DFS, soit par une affectation manuelle, soit en retirant les canaux DFS du profil RF.

Ce contournement a un coût. Exclure les canaux DFS réduit le nombre de canaux 5 GHz disponibles et peut augmenter leur réutilisation entre bornes voisines. Meraki rappelle d'ailleurs dans sa documentation radio que leur désactivation générale n'est pas recommandée sans analyse du plan de fréquences. Un changement de canal doit être préparé, observé et réversible.

La note de version permet de construire une première grille de qualification. Elle ne remplace pas l'analyse du réseau, mais évite plusieurs fausses pistes.

Cette grille sert d'orientation, pas de preuve automatique. Par exemple, une MR46 sous MR 32.2.5 sur un canal DFS appartient aux deux périmètres. Il faut alors conserver les heures précises, les clients affectés, les tests vers la passerelle et les informations radio avant de redémarrer la borne. Ces éléments permettent au support de rapprocher les symptômes du bon défaut.

Le diagnostic doit également vérifier les causes plus classiques. Un signal faible ou un roaming mal réglé peut toujours dégrader les appels. Notre article sur le Minimum RSSI et le roaming Wi-Fi explique pourquoi une modification agressive de seuil peut elle-même provoquer des déconnexions. Corriger un firmware ne remplace pas une implantation radio cohérente.

Pour MR-99882, le nouveau logiciel radio corrige trois chemins de récupération. Il attend la transmission des paquets de beamforming encore en vol, restaure certains paramètres d'émission lorsqu'ils deviennent invalides et récupère l'état de la radio lorsque les pondérations de beamforming ne sont plus disponibles. L'objectif est d'éviter que le chemin d'émission reste bloqué dans l'état associé aux pertes durables.

Pour MR-104909, le correctif adapte le groupement des clients OFDMA aux ressources réellement disponibles après application des contraintes de coexistence. Si la largeur de réponse ne permet pas de servir tout le groupe, celui-ci est réduit au lieu de créer des allocations invalides qui se chevauchent.

Ces explications sont importantes : la version ne se contente pas de masquer une alerte ou de redémarrer automatiquement la radio. Elle modifie les chemins logiciels qui menaient à la dégradation. Cela justifie un test ciblé sur les sites touchés.

La prudence reste néanmoins nécessaire. La note MR 32.2.5.1 répertorie deux problèmes corrigés et seize problèmes connus. Certains concernent SNMPv3, RadSec, le roaming avec authentification MAC, le basculement LACP, les SSID Teleworker VPN, le multicast, la puissance 6 GHz ou des redémarrages inattendus. Tous ne touchent pas tous les modèles, mais ils imposent de lire la matrice correspondant au parc réel.

Une entreprise ayant rencontré les symptômes n'a pas intérêt à attendre passivement, mais elle ne doit pas non plus mettre à jour toutes ses bornes sans qualification. Nous recommandons un déploiement par étapes.

Le dashboard permet d'organiser ce travail, mais la validation doit rester liée aux usages. Une mise à jour terminée et une borne « online » ne prouvent pas que Teams, la téléphonie Wi-Fi, les terminaux métiers ou le roaming fonctionnent correctement. Cette distinction rejoint notre approche de Meraki Actions et du diagnostic réseau : une hypothèse ou une opération appliquée doit toujours être suivie d'un test du service réel.

La recette doit reprendre le symptôme initial avec des mesures comparables :

Il faut aussi conserver une période d'observation réaliste. Les deux bugs ne se reproduisaient pas de la même manière et MR-99882 pouvait apparaître tardivement. L'absence de pertes juste après le redémarrage est encourageante, mais elle ne constitue pas encore une validation durable.