Corruption Wi-Fi : le cas du TP-Link EAP770
Un TP-Link EAP770 corrompait les téléchargements sans alerte réseau. Découvrez comment isoler la panne, comprendre le bug DMA et contourner le problème.
Un point d'accès Wi-Fi corrompait mes fichiers : enquête sur le TP-Link EAP770
Un téléchargement qui échoue, ça fait vite penser à une connexion instable, à un serveur capricieux... ou à un client SSH mal réglé. J'ai vécu avec cette hypothèse pendant des années. En réalité, mon point d'accès Wi-Fi TP-Link EAP770 modifiait certains paquets en transit, tout en laissant une somme de contrôle TCP valide. Le réseau avait donc l'air « propre ». Le vrai problème se trouvait au-dessus de TCP : les couches de chiffrement, elles, finissaient par détecter la casse.
Le diagnostic m'a obligé à remonter progressivement : séparer les symptômes, comparer plusieurs chemins réseau, et suivre les paquets jusqu'au matériel. La correction, elle, se jouait sur deux paramètres système. Le hic : le terminal limité du point d'accès ne permettait pas de les modifier. Faute de mise à jour disponible, il a fallu trouver un moyen de reprendre la main - sans redémarrer, ni rendre l'appareil inutilisable.
Cette enquête raconte pourquoi les vérifications « habituelles » ne suffisent pas toujours, comment un souci de cohérence de cache peut finir en corruption de données, et ce qu'il faut vérifier avant d'accuser un client (ou un serveur).
Des transferts qui échouent sans signe évident
J'ai acheté le TP-Link EAP770, un point d'accès Wi-Fi 7, en août 2023. La connexion n'était pas parfaite : parfois, une vidéo se mettait en mémoire tampon. Comme mon poste de travail était relié en Ethernet, je n'ai pas pris ça au sérieux tout de suite. Le problème est devenu beaucoup plus clair quand j'ai commencé à transférer des fichiers volumineux vers mon ordinateur portable, en Wi-Fi.
Les fichiers de plusieurs gigaoctets échouaient. SSH remontait des erreurs MAC : l'intégrité des données reçues ne correspondait pas à ce qui était attendu. J'ai d'abord cherché du côté de SSH et de rsync : options de transfert, reprises après échec, diagnostic des connexions. Certaines modifications rendaient le problème moins fréquent, d'autres l'aggravaient.
Et pourtant, les indicateurs « de base » ne montraient rien d'anormal. Wireshark ne donnait ni mauvaise somme de contrôle, ni retransmission suspecte. Un flux UDP de données aléatoires arrivait intact. J'ai donc eu tendance à faire confiance à TCP - après tout, sa mission consiste à détecter les pertes et à retransmettre. J'ai écrit un script qui relançait rsync en cas d'échec, puis j'ai continué.
Plus tard, sur le même LAN, le fait d'utiliser Tailscale a rendu ces transferts beaucoup plus fiables. Le tunnel WireGuard écarte les paquets dont l'authentification échoue ; ensuite, TCP, encapsulé dans le tunnel, voit une perte et peut retransmettre. En clair : j'avais un indice solide... mais ça ne m'expliquait pas la cause. Le tunnel masquait le symptôme.
Quand le symptôme revient par un autre chemin
En 2026, après être passé à NixOS, j'ai vu le problème se manifester autrement. Un fichier de 128 Mio provenant d'un cache binaire échouait en HTTP/2, mais se téléchargeait correctement en HTTP/1.1. Des clones Git échouaient aussi, avec des erreurs du type bad record MAC sur des connexions HTTPS. Et en mars, le téléchargement d'une image ISO de NixOS s'est interrompu avec une erreur TLS après plusieurs gigaoctets.
J'ai forcé HTTP/1.1 et j'ai encore contourné. Mais je n'ai pas vraiment compris pourquoi le protocole changeait la donne : un contournement qui marche n'est pas un diagnostic.
Il y avait en plus un détail qui m'a fait perdre un peu de temps au début : j'avais aussi des déconnexions Wi-Fi du portable autour de 11 heures, juste avant une réunion quotidienne. L'enquête a montré que ces coupures étaient un problème séparé, lié au micrologiciel de la carte Wi-Fi Qualcomm du portable. Elles n'avaient rien à voir avec la corruption de données dont je parle ici.
Un équipement déjà en fin de vie
L'EAP770 concerné est un modèle européen, version matérielle 1.0, avec un Qualcomm IPQ9574 et Linux 5.4.164. Il tournait avec le micrologiciel 1.0.0 Build 20230605 Rel. 71641, celui d'origine. Je l'avais acheté avant la finalisation de la norme Wi-Fi 7 (septembre 2024) et avant sa certification par la Wi-Fi Alliance. Avec le recul, j'aurais dû éviter un produit basé sur une norme encore en cours de stabilisation.
En 2025, j'ai vérifié : le modèle ne recevait toujours aucune mise à jour. TP-Link ne proposait des micrologiciels que pour la version 2. Le support m'a confirmé que la version 1 était en fin de vie et ne serait plus mise à jour. Le matériel, lui, continuait à tourner chez moi. Le fabricant, non.
Remonter la chaîne réseau jusqu'au point d'accès
Pour localiser une corruption, il faut comparer les chemins, regarder les directions, et surtout s'intéresser aux couches. Dire simplement « le Wi-Fi est mauvais » n'aide pas : ça ne dit pas si le problème vient de l'application, du système du client, de l'interface radio, du point d'accès, ou du réseau filaire.
J'ai commencé par capturer un transfert HTTPS avec tcpdump. Un segment TCP de 1 440 octets contenait 64 octets faux, mais sa somme de contrôle TCP restait valide. Le compteur TcpInCsumErrors restait à zéro. Bref : TCP acceptait le segment et le passait à TLS, qui rejetait ensuite l'enregistrement avec une erreur d'authentification.
Ce détail change tout. Une somme de contrôle valide sur du contenu corrompu suggère qu'un équipement intermédiaire a recalculé la somme après avoir modifié les données. Et les captures ne pouvaient pas reconstruire le contenu attendu : TLS ne déchiffre pas un enregistrement invalide. J'ai donc remplacé mon test HTTPS par un transfert TCP brut entre deux machines, avec des données connues, comparables octet par octet.
Réduire le problème par comparaison
Les tests ont mis en évidence trois blocs de 64 octets incorrects sur 8 192 Mio de données. Et surtout : ça ne se produisait que lorsque plusieurs flux TCP tournaient en même temps, dans le sens réseau filaire vers client Wi-Fi. Les transferts inverses étaient propres. Les clients filaires ne montraient pas non plus de corruption.
Ensuite, j'ai remplacé la carte MediaTek du portable par une carte Qualcomm et j'ai modifié des paramètres côté client (comme GRO, l'agrégation côté noyau). Ça améliorait parfois la situation, mais sans faire disparaître les erreurs. Autrement dit : un changement qui « a l'air » d'aider ne prouve pas que le composant modifié est coupable.
Les trames Wi-Fi qui transportaient les données altérées gardaient une authentification CCMP intacte. Ça pointait plutôt vers la corruption qui survient après la transmission radio, pas pendant. Le câble ne semblait pas en cause : les clients filaires restaient propres, la panne persistait avec deux cartes Wi-Fi différentes, et le seul point commun solide restait le point d'accès, sur le trajet entre Ethernet et Wi-Fi.
La taille des blocs, elle aussi, donne un indice. Sur le processeur IPQ9574, 64 octets correspondent à une ligne de cache. Ce n'était pas une preuve, mais ça rendait plausible un problème lié au cache ou à des transferts DMA. Et parmi les composants sur ce chemin, l'accélération Qualcomm SFE/PPE semble gérer le trafic ponté et recalcule les sommes de contrôle. C'est là que ça s'est mis à ressembler à un « vrai » coupable.
Un défaut DMA derrière des blocs de 64 octets
DMA, ou Direct Memory Access, permet à un périphérique de transférer des données directement en mémoire sans demander au processeur de copier octet par octet. C'est efficace, mais ça demande de la discipline : DMA et cache doivent rester cohérents. Si les deux ne voient pas la même version d'une zone mémoire, le système peut lire des données incohérentes ou écraser au mauvais moment.
Sur l'EAP770, la piste mène au pilote Qualcomm qca-nss-dp et à la réutilisation de tampons réseau. Après certains envois accélérés, un tampon peut être remis dans une liste de recyclage puis réutilisé pour recevoir un paquet. Le chemin de réception traite alors ce tampon comme s'il avait été correctement synchronisé avec le cache. Sauf qu'ici, la maintenance du cache effectuée lors de l'envoi précédent ne couvre pas forcément toute la zone mémoire réellement utilisée à la prochaine réception.
Comment des données anciennes peuvent remplacer un paquet récent
Sur ce matériel, le périphérique DMA écrit en mémoire vive sans forcer automatiquement la cohérence avec le cache CPU. Si une ligne de cache modifiée reste en attente, elle peut être réécrite en mémoire après que la carte réseau y a déposé un nouveau paquet. Résultat : une portion du nouveau paquet est remplacée par des données plus anciennes.
Ces remplacements se produisent par lignes de cache - et c'est exactement ce que j'observais : des blocs de 64 octets.
La somme de contrôle TCP, elle, reste valide parce que le chemin d'accélération recalcule après coup. Le client reçoit donc des données incorrectes, mais « cohérentes » selon la somme du paquet modifié. TCP n'a aucune raison de rejeter. Ce sont TLS, SSH et d'autres mécanismes d'authentification bout en bout qui finissent par détecter que le contenu reçu ne correspond pas à ce qui a été envoyé.
Autre détail important : la direction du trafic. Les téléchargements vers un client Wi-Fi passent par le chemin de réception Ethernet du point d'accès. Les envois dans l'autre sens empruntent un parcours différent. Et les transferts entre deux appareils filaires évitent ce chemin précis.
Cette analyse colle avec les observations et le comportement attendu du pilote. Mais certains détails internes du PPE sont propriétaires. Impossible donc de décrire entièrement la séquence matérielle uniquement à partir du code public. Le point pratique, lui, est vérifiable : désactiver l'accélération fait disparaître les erreurs.
Pourquoi une machine x86 peut ne pas montrer le même défaut
Sur x86, la cohérence entre cache et accès DMA est en général mieux prise en charge matériellement. Une omission du genre peut donc ne pas produire le même symptôme sur un PC x86. Sur ARM, le logiciel doit être plus explicite sur la synchronisation attendue.
En fouillant les sources du noyau, j'ai trouvé des cas similaires de maintenance DMA dans d'autres pilotes. Mais ça ne prouve pas qu'ils causent exactement les mêmes corruptions en production : l'objectif reste de reproduire le scénario sur le matériel concerné et d'identifier le bon canal de signalement. C'est la limite classique du diagnostic « à partir du code ».
Deux paramètres, un exploit et un compromis de performance
Le pilote pointait vers deux paramètres sysfs à désactiver : /sys/sfe/l2_feature et /sys/sfe/ppe_rfs_feature. Ils contrôlent des fonctions d'accélération SFE/PPE. Sauf qu'ils ne sont modifiables que par root. Et le shell SSH fourni par TP-Link tourne avec un utilisateur restreint, sans les capacités nécessaires. Il n'y a pas non plus d'équivalent dans l'interface graphique.
J'ai donc cherché une autre voie. Pas d'image de micrologiciel pour la version 1 à patcher : la version 2 correspondait à un matériel différent. Une image d'un produit voisin a été rejetée par l'appareil. Flasher directement la puce demandait en plus du matériel de type « programmateur » et comportait un vrai risque de rendre l'accès inutilisable. Je ne voulais pas acheter un autre appareil juste parce que le fabricant ne proposait plus de correctif.
Le point d'accès, en fait, était plus verrouillé que je ne l'imaginais. Je n'ai pas trouvé de faille exploitable directement dans les binaires du fabricant. Ils utilisent notamment des listes d'autorisation et ne chargent que certains modules. Donc, pas de « simple commande privilégiée ».
Une élévation de privilèges, sans redémarrer l'appareil
La seule option restante, c'était une faille du noyau Linux. Avec l'aide d'un assistant de programmation, j'ai adapté une chaîne basée sur CVE-2022-0185 : une vulnérabilité d'entier dans le traitement de certains paramètres de systèmes de fichiers, combinée à des manipulations de tampons de tubes. Les analyses et preuves de concept publiques existaient déjà ; le travail a surtout consisté à adapter la chaîne au noyau et à la mémoire de cet appareil.
Je ne détaille pas ici une procédure exploitable « pas à pas ». Le point décisif, c'était opérationnel : obtenir les privilèges nécessaires sans redémarrer l'EAP770. Redémarrer réactivait l'accélération défectueuse, et une tentative ratée pouvait finir en plantage du noyau. Il fallait donc tester, dans un environnement QEMU aussi proche que possible, puis valider sur le matériel avec prudence.
Le noyau n'utilisait pas KASLR, mais les symboles utiles n'étaient pas directement accessibles et les adresses divergeaient entre la simulation et l'appareil réel. J'ai dû retrouver les bonnes références à partir du micrologiciel, puis corriger les hypothèses. Au total, ça a pris environ dix-sept heures : comprendre les protections, analyser les binaires, puis stabiliser l'exploitation.
Une fois root obtenu, j'ai désactivé les deux fonctions d'accélération. Les téléchargements sont redevenus fiables. Par contre, ce n'était pas durable : au redémarrage, les paramètres revenaient à leur valeur initiale. J'ai donc mis un processus sur mon NAS qui surveille l'état du point d'accès et relance la procédure après un démarrage, avec un nombre maximal de tentatives avant de redémarrer l'accès réseau via l'interface de gestion.
Le prix mesuré du contournement
J'ai comparé des transferts TCP bruts entre les mêmes machines, avec et sans accélération :
| Accélération SFE/PPE | Sens | Volume testé | Débit | Blocs corrompus |
|---|---|---|---|---|
| Activée | Réseau filaire vers Wi-Fi | 8 192 Mio | 103,4 Mio/s | 3 |
| Désactivée | Réseau filaire vers Wi-Fi | Test nocturne | 95,4 Mio/s | 0 |
Sur ce test, désactiver l'accélération fait baisser le débit d'environ 8 %. C'est un compromis mesurable : je perds un peu de performance pour récupérer l'intégrité des fichiers. Avec l'accélération active, les gros transferts en un seul flux échouaient régulièrement. Une fois désactivée, un test nocturne n'a montré aucun bloc incorrect, et les transferts volumineux sont devenus fiables.
Je ne prétends pas que « l'accélération réseau doit être désactivée par défaut ». Ce résultat dépend d'un modèle précis et d'un micrologiciel précis. La leçon, elle, tient en une phrase : quand les sommes de contrôle semblent correctes mais que les couches applicatives détectent quand même des données altérées, il faut regarder les composants d'accélération et les chemins DMA - surtout si le problème dépend du sens du trafic.
Conclusion
Ce n'était ni un défaut de rsync, ni un simple problème radio, ni une erreur visible dans les compteurs TCP. La cause venait d'un chemin d'accélération côté point d'accès : une mauvaise gestion de la cohérence du cache DMA pouvait remplacer des blocs de données après leur réception. Et comme les sommes de contrôle étaient recalculées sur le contenu altéré, TLS et SSH ne faisaient que constater les dégâts en dernier.
Le contournement a fonctionné, avec environ 8 % de débit en moins dans mon test, mais il ne remplace pas une mise à jour du pilote ou du micrologiciel. Et le plus gênant, c'est ça : quand un équipement réseau n'est plus maintenu, corriger le défaut peut demander du temps, des compétences, et une prise de risque disproportionnée.
Si vous êtes face à un problème comparable, commencez par comparer directions et chemins, puis cherchez où les données changent vraiment. Et avant d'acheter un routeur/point d'accès cher, vérifiez la certification, la version matérielle exacte, et la politique de mises à jour du fabricant. Pour le détail technique de l'enquête : l'article source.