Tobias Fiebig encontró la falla en una NIC virtual

Resumen

El caso de Tobias Fiebig en RIPE 93 empezó como una sospecha de limitación en la red de acceso. Abrir el firewall del servidor para recibir el aviso ICMP no aceleró la descarga; comparar dos máquinas virtuales reveló que tenían tarjetas distintas.
La ruta ya había aprendido un MTU de 1.420 bytes, pero el offload TCP de la RTL8139 virtual seguía usando 1.500. Una ruta más específica, fijada en 1.320, hizo que la transferencia volviera a funcionar.

Análisis

La primera explicación tenía nombre de proveedor: alguien debía estar frenando el tráfico. La captura de paquetes señaló algo mucho menos visible, una tarjeta de red que existía solo dentro de la máquina virtual y que trataba 1.500 bytes como una verdad permanente.

Fiebig contó el episodio en la sesión plenaria de cierre de RIPE 93. Una transferencia grande iba a paso de tortuga para clientes detrás de una ruta con MTU inferior a 1.500. Desde otra máquina virtual cercana, el servicio funcionaba. La diferencia entre redes parecía culpable. El equipo permitió en el firewall del servidor el mensaje ICMP “packet too big”, que informa cuando un paquete no cabe en el siguiente enlace. El síntoma persistió. El cambio había sido real; el diagnóstico seguía incompleto.

Una consulta de ruta en el cliente afectado devolvió un MTU de camino de 1.420 bytes. El host ya tenía una medida menor que la MTU de su interfaz local. Aun así, siguieron las retransmisiones TCP. Fiebig fijó una ruta más específica en 1.320 bytes y el flujo respondió. Ese 1.320 no era la medida del camino: era el valor conservador que funcionó como salida local. La consulta de ruta había dado 1.420.

La máquina de prueba también engañó al investigador. Tenía el mismo software y recibió el mismo paquete de prueba, pero no fallaba. El contraste útil apareció al mirar los dispositivos: el huésped problemático usaba una Realtek RTL8139 emulada; el otro tenía otro modelo virtual. Fiebig había copiado el entorno de software y había dejado fuera justo el componente que torcía el comportamiento de TCP.

La búsqueda terminó en net/hw/8139.c de QEMU: el offload TCP trabajaba con un MTU estático de 1.500 bytes. El incidente registrado en el proyecto QEMU describe el mismo patrón: poco caudal al conectar clientes detrás de enlaces con MTU menor, PMTUD ignorado y retransmisiones; bajar el MTU del sistema huésped sirve de mitigación. En la charla, Fiebig situó la línea de código en 2006 y recordó que en 2016 ya hubo una discusión y una propuesta de parche que no llegó a integrarse. Desactivar TCP offload era otra opción; en el caso descrito, sustituir la tarjeta por VirtIO eliminó el problema.

PMTUD permite que los extremos ajusten los paquetes al tramo más estrecho. La RFC 1191 describe el mecanismo IPv4 y la RFC 2923 registra los agujeros negros de TCP cuando falta o se procesa mal la señal ICMP. El firewall era una hipótesis razonable. Después del cambio sin resultado, la tarjeta virtual se convirtió en la siguiente pregunta.

La prueba que faltaba no era otro cambio general de firewall. Era mirar el cable lógico: capturar, leer el MTU aprendido, identificar el modelo virtual y comparar el offload. La versión exacta de QEMU y los ajustes del huésped afectado no aparecen en el registro público; esos datos delimitarían cuántas instalaciones usan la misma combinación.