Tobias Fiebig remonte une panne TCP jusqu’à la carte virtuelle

Résumé

La panne racontée par Tobias Fiebig à RIPE 93 ressemblait à un bridage de l’accès. Autoriser le signal ICMP sur le pare-feu du serveur n’a rien changé; la capture et la comparaison de deux machines virtuelles ont révélé des cartes différentes.
L’offload TCP de la RTL8139 émulée restait fixé à 1 500 octets. La route avait pourtant appris un MTU de 1 420; une route plus précise, verrouillée à 1 320, a rétabli le transfert.

Analyse

Le débit accusait le réseau d’accès. Les paquets, eux, désignaient un témoin plus discret : une carte réseau que le système émulait depuis longtemps et dont l’offload continuait à croire que 1 500 octets passeraient partout.

À RIPE 93, Tobias Fiebig a raconté le cas d’un téléchargement massif qui avançait au ralenti pour des clients derrière un chemin au MTU réduit. Depuis une autre machine virtuelle proche, le service fonctionnait. L’hypothèse d’un filtrage côté accès ou pare-feu paraissait raisonnable. Le pare-feu du serveur a été modifié pour laisser passer le message ICMP « packet too big ». Le débit n’a pas bougé. La règle avait changé; le problème, non.

Fiebig a interrogé la route depuis le client en difficulté. Le système avait déjà appris un MTU de chemin de 1 420 octets. Cette information aurait dû amener l’émetteur à réduire ses paquets. Les retransmissions TCP continuaient pourtant. Une route plus spécifique, avec un MTU verrouillé à 1 320 octets, a fait repartir le téléchargement. Les deux chiffres n’ont pas le même rôle : 1 420 est la valeur trouvée par la route; 1 320 est le contournement qui a fonctionné.

La reproduction a apporté le déclic. Fiebig a créé une autre machine virtuelle avec le même logiciel et le même test de paquet. La panne ne s’y produisait pas. Les deux environnements différaient dans leur matériel virtuel : la machine touchée utilisait une Realtek RTL8139 émulée, l’autre une autre interface. Copier le logiciel sans copier la carte revenait à tester un autre cas.

Fiebig a suivi la piste jusqu’à net/hw/8139.c dans QEMU et à un MTU fixe de 1 500 octets pour l’offload TCP. Le ticket officiel du projet QEMU décrit la même combinaison : faible débit depuis des chemins sous 1 500, PMTUD ignorée, retransmissions, MTU plus bas comme atténuation. Dans son intervention, Fiebig fait remonter l’hypothèse au code de 2006 et rappelle une discussion et une proposition de correctif en 2016. Il cite aussi deux options : désactiver l’offload TCP ou remplacer la vieille carte virtuelle par VirtIO. Dans le cas présenté, VirtIO a supprimé la panne.

La découverte du MTU de chemin doit permettre aux extrémités d’adapter leurs paquets au maillon le plus étroit. La RFC 1191 décrit le mécanisme IPv4; la RFC 2923 documente le trou noir TCP créé par un retour ICMP absent ou mal traité. Le pare-feu était donc un suspect crédible. Une fois la règle modifiée sans effet, il fallait regarder à la frontière entre l’invité et sa carte virtuelle.

La séquence utile tient en quatre gestes : capturer les paquets, lire le MTU appris par la route, comparer le modèle de carte et tester un contournement ciblé. Le dossier public ne donne pas la version exacte de QEMU ni les paramètres d’offload de l’invité touché; ces éléments permettraient d’évaluer l’extension du cas.