Discussion de forum
ae_oub87
30-06-2026Initiate
Débit Wi-Fi très lent sous Linux (Helix XB7)
Bonjour,
Je cherche à documenter un problème de débit Wi-Fi avec une borne Helix XB7 de Vidéotron, qui semble toucher spécifiquement les appareils sous Linux.
Contexte :
Borne : Helix XB7, technologie Comcast/Xfinity
Forfait Internet : 500/50 Mbit/s
Réseau Wi-Fi : [SSID masqué]
Bande utilisée : 5 GHz
Canal observé : 157 / fréquence 5785 MHz
Signal côté Linux : environ -50 à -52 dBm, donc signal bon
Appareils testés :
Ordinateur fixe avec carte Intel Wi-Fi 6 AX200, Lenovo ThinkPad X390, Dell Latitude 3520
Systèmes testés :
Fedora 44, Ubuntu 26.04, Windows
Le problème observé est le suivant : sous Linux, en Wi-Fi, le débit réel descend généralement autour de 20 Mbit/s, alors que le forfait est de 500/50 Mbit/s.
Le même portable, au même endroit et sur le même réseau Wi-Fi, atteint environ 438,91 Mbit/s en téléchargement et 46,09 Mbit/s en téléversement sous Windows, avec une latence normale.
Exemple sous Windows (Dell Latitude 3520), même portable, même emplacement, en Wi-Fi :
Download : 438,91 Mbit/s Upload : 46,09 Mbit/s Ping : 21 / 56 / 28 ms
Un test en Ethernet sous Linux avec le Dell Latitude 3520 donne aussi les vitesses attendues du forfait. Le problème ne semble donc pas venir de la connexion Internet Vidéotron, du provisionnement, du coaxial, ni de Linux en général, mais plutôt de l’interaction entre le Wi-Fi sous Linux et la borne Helix XB7.
Exemples de résultats sous Linux en Wi-Fi :
Speedtest : 20,46 / 19,75 Mbit/s
Les téléchargements réels sont aussi touchés. Par exemple :
curl depuis OVH : environ 2,58 MiB/s, soit environ 20,6 Mbit/s aria2c avec 8 connexions parallèles : environ 2,4 MiB/s, soit environ 19,2 Mbit/s
Le problème n’est donc pas seulement lié à speedtest ou à un serveur de test précis.
Côté Linux, la connexion Wi-Fi semble pourtant parfois négocier correctement. Par exemple :
Connected to [BSSID masqué] (on wlp4s0) SSID: [SSID masqué] freq: 5785.0 signal: -52 dBm rx bitrate: 780.0 MBit/s VHT-MCS 8 80MHz short GI VHT-NSS 2 tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2
Le power save Wi-Fi est désactivé :
Power save: off
J’ai aussi testé le ping vers la borne locale, 10.0.0.1. Par moments, il est très stable :
rtt min/avg/max/mdev = 1.528/2.618/5.288/0.887 ms 0% packet loss
Mais à d’autres moments, il y a eu des pics de latence importants vers la borne elle-même, par exemple plus de 100 à 200 ms, et auparavant autour de 300 à 400 ms. Cela suggère un problème local entre Linux et la borne, plutôt qu’un problème avec Internet en général.
Un élément important : sous charge, la connexion Linux semble parfois retomber en mode legacy à 54 Mbit/s. Après un gros transfert avec aria2c, la commande iw dev wlp4s0 station dump donnait :
tx packets: 373850 tx retries: 55125 tx failed: 0 signal: -51 dBm tx bitrate: 54.0 MBit/s rx bitrate: 54.0 MBit/s
Au départ, sous Fedora, j’avais aussi observé le message suivant dans dmesg :
required MCSes not supported, disabling HT
Ce problème ressemble à un bogue connu avec certaines bornes Comcast/Xfinity qui annoncent des ensembles MCS incorrects. J’ai testé un noyau Fedora plus récent, 7.0.13-200.fc44, qui semble corriger partiellement ce problème initial, car la connexion peut maintenant s’établir en VHT 80 MHz. J’ai aussi testé temporairement un patch mac80211 externe lié à ce problème MCS, mais il n’a pas réglé le débit réel sous charge.
Tests et contournements déjà essayés :
-mise à jour complète de Fedora 44 ;
-noyau Fedora 7.0.13-200.fc44 ;
-test avec le module mac80211 standard de Fedora ;
-test temporaire avec un patch mac80211 lié aux MCS ;
-désactivation du Wi-Fi 6 / 802.11ax côté Linux avec disable_11ax=Y ;
-connexion forcée en Wi-Fi 5 / VHT au lieu de HE/Wi-Fi 6 ;
-désactivation du power save Wi-Fi ;
-utilisation de l’adresse MAC permanente au lieu de la MAC aléatoire ;
-test avec IPv6 désactivé ;
-test avec MTU 1400 au lieu de 1500 ;
-test avec 11n_disable=8 ;
-tests avec speedtest-cli, navigateur, curl et aria2c ;
-comparaison avec Windows sur le même portable et au même endroit ;
-test Ethernet sous Linux avec le Dell Latitude 3520, qui donne les vitesses attendues ;
-tests avec plusieurs machines Linux : Dell Latitude 3520, Lenovo X390 et ordinateur fixe avec Intel AX200 ;
-désactiver le 2,4ghz sur la borne.
À ce stade, le problème semble très spécifique à l’interaction entre Linux, probablement iwlwifi/mac80211 avec cartes Intel, et la borne Helix XB7. Le réseau, l’abonnement et l’emplacement semblent corrects, puisque Windows atteint environ 439/46 Mbit/s en Wi-Fi dans les mêmes conditions, et puisque Linux atteint les vitesses attendues en Ethernet.
Ma question : est-ce que d’autres utilisateurs Linux ont observé ce genre de comportement avec les bornes Helix XB7, surtout avec des cartes Intel AX200/AX201 ou des portables Lenovo/Dell? Est-ce que Vidéotron peut pousser une mise à jour de firmware, modifier le profil Wi-Fi de la borne, ou proposer un remplacement de borne lorsque le Wi-Fi fonctionne correctement sous Windows et en Ethernet, mais très mal en Wi-Fi sous Linux?
Merci!
2 Réponses
- ae_oub87Initiate
En cherchant sur Internet, j'ai vu que d'autres utilisateurs ont le même problème chez d'autres FAI utilisant la technologie Xfinity :
https://www.reddit.com/r/Rogers/comments/1sk29zj/very_very_slow_wifi_on_xb7_router_after_factory/
https://www.linuxquestions.org/questions/linux-networking-3/very-slow-wi-fi-speeds-with-some-aps-after-they-firmware-updated-4175763630-print/?__cf_chl_f_tk=D8zRmOSHF_lBGcYkbDE4emvgQvid67cGRInZbGzWS8w-1782843526-1.0.1.1-23erVDp3IQZrRfAC.PA7.pBlzfiHvkczEiMaO9vMtIE
Je suis actuellement en visite chez mon père à Montréal qui a migré de FH400/Illico à Helix il y a 2 mois environ et j'ai été désagréablement surpris de constater que la technologie utilisée est extrêmement hostile à GNU/Linux. Négocier des vitesses internet 20x plus faibles en WiFi parce que la borne a un problème de firmware non-résolu depuis avril 2026 est complètement inacceptable. J'utilise un ordinateur fixe chez lui comme petit serveur Linux privé auquel j'accède de chez moi à Québec.
Je tiens aussi à dire que je suis abonné à Québec avec illico pour la télévision, ebox-ftth pour internet. Comme client Vidéotron, ce genre d'expérience m'encourage à ne pas migrer sur Helix aussi longtemps qu'illico sera en service. Vous chargez un prix premium pour une technologie qui fonctionne moins bien que celle utilisée par des marques low-cost, ou vous obligez vos clients à racheter un routeur et faire fonctionner la borne en «bridge». J'espère que vous ferez passer le mot à qui de droit pour qu'une mise à jour du firmware sur la borne XB7/HFi2 règle le problème dans les prochaines semaines. - ae_oub87Initiate
Je complète avec quelques informations logicielles trouvées dans l’interface de la borne :
System Software Version
eMTA & DOCSIS Software Version : Prod_24.2_PD & Prod_24.2_PD
Software Image Name : CGM4331COM_8.3p12s1_PROD_sey
Advanced Services : CGM4331COM
Packet Cable : 1.5La ligne la plus pertinente semble être « CGM4331COM_8.3p12s1_PROD_sey », qui paraît correspondre à l’image logicielle/firmware principale de la borne. Si le problème est lié au firmware ou au profil Wi-Fi de la XB7/HFi2, cette information pourrait aider à comparer avec d’autres cas similaires.
Je précise toutefois que, comme client, je n’ai pas accès aux réglages avancés de la borne. C’est justement pourquoi je demande une escalade technique : si le problème vient du firmware ou du profil Wi-Fi appliqué à la borne, je ne peux pas le diagnostiquer ni le corriger moi-même à partir de l’interface Helix disponible au client.
Le mode bridge avec un routeur tiers peut être un contournement, mais il ne corrige pas la fonction Wi-Fi intégrée de la borne fournie avec le service. Il transfère aussi le coût du contournement au client qui utilise des appareils sous Linux, alors que Helix est présenté comme une solution intégrée et clé en main incluant la borne Wi-Fi.
Pour cette raison, je crois qu’une vérification côté Vidéotron est nécessaire, plutôt qu’une simple recommandation d’utiliser un routeur personnel en mode bridge.