A RTL8139 virtual do QEMU derrubava a transferência

Resumo

A transferência parecia sofrer limitação da operadora: ficava lenta em caminhos abaixo de 1.500 bytes e funcionava em outra VM. Liberar ICMP no firewall não mudou o sintoma; a diferença decisiva estava na placa virtual.
O offload TCP da RTL8139 emulada continuava em 1.500 bytes, apesar de a rota ter encontrado MTU de 1.420. Uma rota mais específica, travada em 1.320, fez a transferência voltar a andar.

Análise

A operadora entrou na lista de suspeitos primeiro. A equipe liberou no firewall o ICMP “packet too big”; o download continuou rastejando. Só quando Fiebig comparou duas VMs apareceu a diferença que importava: uma tinha a RTL8139 emulada pelo QEMU; a outra, outro adaptador. O defeito estava no equipamento virtual que quase ficou fora da investigação.

Tobias Fiebig contou a história na plenária de encerramento de RIPE 93. Uma transferência grande se arrastava para clientes por caminhos com MTU menor que 1.500. De outra VM ali perto, o mesmo serviço funcionava. A diferença parecia estar na rede. A equipe permitiu no firewall do servidor a mensagem ICMP “packet too big”, que avisa quando o pacote não cabe no próximo enlace. A regra mudou; a velocidade não.

Fiebig consultou a rota no cliente afetado e encontrou MTU de caminho de 1.420 bytes. O sistema já sabia que o caminho era menor que sua interface local de 1.500. Mesmo assim, o TCP seguia retransmitindo. Uma rota mais específica, com MTU travado em 1.320, destravou o fluxo. A consulta da rota encontrou 1.420 bytes; fixar 1.320 foi o contorno que funcionou.

A primeira tentativa de reprodução também falhou. Fiebig montou uma VM com o mesmo software e enviou o mesmo pacote de teste. Nada. A diferença apareceu no hardware virtual: a VM afetada usava uma Realtek RTL8139 emulada; a de teste usava outro adaptador. Reproduzir o sistema sem reproduzir a interface era repetir quase tudo, menos a condição decisiva.

O código levou Fiebig a net/hw/8139.c, no QEMU, onde o offload TCP usava MTU fixo de 1.500 bytes. O registro oficial do projeto QEMU descreve o mesmo quadro: baixo desempenho para clientes atrás de enlaces abaixo de 1.500, PMTUD ignorado, retransmissões e mitigação ao reduzir o MTU do sistema convidado. Na palestra, Fiebig disse que a implementação remontava a 2006 e citou uma discussão e uma proposta de correção em 2016. Desativar o offload TCP também poderia resolver; no caso apresentado, trocar a placa antiga por VirtIO eliminou a falha.

Path MTU Discovery deveria fazer os extremos ajustarem o tamanho dos pacotes ao enlace mais estreito. A RFC 1191 descreve a descoberta para IPv4; a RFC 2923 registra problemas de TCP quando a sinalização ICMP some ou é mal tratada. O firewall era um suspeito coerente. Depois que a liberação não mudou o sintoma, era hora de olhar a fronteira entre o convidado e sua NIC virtual.

A ordem que economiza horas é simples: capturar os pacotes, conferir o MTU aprendido pela rota, identificar o modelo da placa e comparar o estado do offload. Falta no registro público a versão exata do QEMU e a configuração de offload da VM afetada; esses dados mostrariam até onde o caso se repete.