Linux et Hélix fin 2025 pas plus lojng qu'en 2020
📖 Mémoire de combat contre l’incompétence de Vidéotron et l’incompatibilité Linux de Helix 1. Préambule : le cri d’un citoyen numérique Depuis trop longtemps, les utilisateurs Linux sont ignorés par Vidéotron. Nous payons pour un service incomplet, nous subissons des limitations absurdes, et nous recevons en retour des réponses vagues, des promesses creuses et une absence totale de calendrier. Ce document est un témoignage, une analyse et un ultimatum : il est temps que Vidéotron respecte ses clients et adopte les standards universels du web. 2. Le contexte : une bataille de plusieurs années Je suis Josué, citoyen numérique de Saint‑Jean‑sur‑Richelieu. J’ai mené le combat sur le forum Vidéotron, dénonçant l’incompatibilité de Helix avec Linux. J’ai investi dans du matériel moderne : carte réseau 2.5G intégrée à ma MSI MAG B550M Mortar Max WiFi, câbles Cat6a, SSD NVMe, routeur optimisé. J’ai préparé mon installation pour la fibre 2,5 GIGA. Pourtant, malgré tout cela, Helix TV ne fonctionne pas sur Linux. 3. La fracture technologique • Forfait 1 Gbit/s (coaxial) : upload limité à ~50 Mb/s, instable, incompatible avec les usages modernes. • Forfait 2,5 Gbit/s (fibre) : symétrie parfaite, vitesse idéale, mais Helix TV reste incompatible sur Linux. • DRM propriétaire : Vidéotron utilise une couche de sécurité qui ne respecte pas les standards (Widevine), ce qui bloque Firefox/Linux. 4. Témoignage d’un utilisateur engagé Pendant des années, j’ai porté ce combat sur le forum Vidéotron. J’ai dénoncé l’injustice, j’ai proposé des solutions, j’ai demandé un calendrier. En retour, j’ai reçu des réponses vagues : “1 mois, 6 mois, 2 ans…”. Aucune transparence, aucune volonté réelle de corriger le problème. 5. Comparaison avec les géants • Netflix : fonctionne sur Linux via Firefox grâce à HTML5 + Widevine DRM. • Prime Video : idem, compatibilité universelle. • Crave : idem, aucune restriction. • Helix TV : incompatible, malgré un abonnement payant. 👉 Conclusion : Vidéotron est en retard technologique par rapport aux standards mondiaux. 6. Conséquences pour les clients • Exclusion numérique : les utilisateurs Linux sont privés d’un service qu’ils paient. • Perte de confiance : Vidéotron refuse de donner un calendrier de correction. • Injustice commerciale : on paie pour un service incomplet. • Frustration accumulée : des années de combat sur le forum, sans résultat. 7. Solutions techniques 1. Adopter Widevine DRM comme les autres plateformes. 2. Support officiel Firefox/Linux dans Helix TV. 3. Mode bridge sur la borne Helix pour permettre l’usage de routeurs Linux‑friendly. 4. Documentation claire pour les utilisateurs avancés. 8. Appel à la transparence Vidéotron doit publier un calendrier clair : quand Helix sera compatible Linux. Les réponses vagues (“1 mois, 6 mois, 2 ans…”) sont inacceptables. Les clients méritent de savoir. 9. Le rôle du citoyen numérique Nous, utilisateurs, ne sommes pas des consommateurs passifs. Nous sommes des citoyens numériques qui exigent des standards ouverts, une compatibilité universelle et un respect de nos choix technologiques. 10. Message direct à Vidéotron Votre incompétence est flagrante. Vous avez reconnu sur votre forum que Helix n’est pas compatible Linux. Vous avez refusé de donner une solution. Pendant ce temps, vos concurrents mondiaux offrent une compatibilité universelle. Vous devez corriger cette erreur immédiatement. 11. Conclusion : la solution en pleine face La solution est simple : respecter les standards du web. Adoptez Widevine DRM, ouvrez Helix à Firefox/Linux, et cessez d’exclure vos clients. Nous ne demandons pas un luxe, mais un droit : utiliser les services que nous payons sur la plateforme de notre choix. 12. Annexes : calculs et comparatifs • Upload 1 Gbit/s coaxial : 50 Mb/s → 10 Go = ~30 minutes. • Upload 2,5 GIGA fibre : 2,5 Gbit/s → 10 Go = ~35 secondes. • Compatibilité : Netflix, Prime, Crave = OK sur Linux. Helix = KO.
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!
Internet et vol en même temps
Bonjour problèmes d'internet, moi je veut bien payé mon internet mais la, il a des LIMITES Là, vous envoyer des gens faire du porte à porte, et il font de promesses de carte cadeau de 100$ d'épicerie et après tu reçois quoi que dalle, moi tannée payer pour de la scrapp, sois je fait une plainte au CRTC, juste pour qu'on sois sur votre compagnie de cellulaire et internet, et vous êtes mieux de remettre l'Internet sinon je ferais ma plainte!!, pour fausse carte cadeau promise par un de vos employés qui est venu chez moi!!! Et en plus m'a fait choisir à moi et mon mari la carte cadeau de 100$ pour le IGA en mai 2025 !!! Alors arrangée vous que l'Internet sois la en fin de journée merci !!!!
Problème peering vers serveurs Microsoft Azure (pathping joint)
Bonjour la communauté Vidéotron, Je constate l'Impossibilité de jouer à Microsoft Flight Simulator 2024 (MSFS) via Helix à cause d'erreurs "bandwidth too low". Le problème existe en Ethernet ET via wifi (routeur gaming 800-850mb/s en moyenne) et survient 9 fois sur 10 sessions. Le test pathping fait état de congestion peering Vidéotron vers Azure/Yotta à tout moment de la journée. Avez-vous déjà vu ce problème ? Vidéotron peut-il vérifier le peering vers azure? J'en suis au point ou j'envisage de basculer vers Rogers qui semble avoir des connexions plus directes et fiables avec les services azure microsoft. Merci pour vos retours !