Nenhuma resposta para alguns pacotes SYN quando os timestamps estão ativados

Question

Eu tenho um servidor TCP escutando em uma máquina ("o servidor") rodando o Ubuntu 12.04.3 (kernel 3.8.0-31-generic). Ele recebe conexões de duas máquinas clientes diferentes. A máquina A está executando o Ubuntu 12.04.4 (3.11.0-17-generic) e a máquina B está executando o Ubuntu 11.10 (3.0.0-32-server).

Se os carimbos de data / hora TCP estiverem habilitados no servidor (sysctl net.ipv4.tcp_timestamps = 1), às vezes os pacotes SYN da máquina A serão "ignorados". Usando o tcpdump no servidor (no modo não promíscuo) eu posso ver os SYNs chegando OK e com checksums corretos - simplesmente não há resposta - sem SYN / ACK e nenhum RST. A máquina A retransmite o SYN um certo número de vezes antes de desistir. O software cliente em execução na máquina A (nesse caso, wget) tenta novamente imediatamente com uma nova conexão e obtém um SYN / ACK instantâneo.

A Máquina B não tem problemas com o mesmo servidor e seu tráfego parece normal - está usando as mesmas opções de TCP da máquina A (pelo que vejo nos arquivos de captura). Desativar os timestamps TCP no servidor faz com que tudo funcione como deveria.

Os timestamps nos pacotes SYN ignorados parecem ser válidos para mim, por isso não sei por que eles estão causando problemas ou se eles são a causa subjacente.

Eu coloquei um pcap anonimizado aqui link . Ela foi tirada no servidor (10.76.0.74) mostrando a máquina A (10.4.0.76) executando com êxito um HTTP GET (pacotes de 1 a 10) e depois 1 segundo depois tentando buscar a mesma URL novamente (pacotes 11 a 17), mas tem seus SYNs ignorados. Os pacotes de 18 a 27 são outro sucesso.

Suspeito que seja um problema semelhante ao descrito em " Por que um servidor não envia um pacote SYN / ACK em resposta a um pacote SYN " e enquanto desabilitar timestamps é uma solução alternativa eu gostaria de entender o que está acontecendo. Isso é apenas um bug?

Não há firewall local em execução. O servidor lida com algumas conexões TCP (aproximadamente 32K a qualquer momento), mas tem bastante memória / CPU livre. No momento do teste mostrado no pcap não havia outras conexões TCP entre a máquina A e o servidor. Não há sinal de que a fila de aceitação do aplicativo do servidor esteja subitamente preenchida (além disso, isso deve afetar os dois clientes que eu presumo). Como os pacotes parecem OK em um pcap tirado no servidor, não parece que um dispositivo de rede intermediário esteja quebrando as coisas.

Eu originalmente postei isso nos fóruns do Ubuntu, mas em retrospectiva este pode ser um local mais apropriado. Esperando pelo empréstimo de uma pista.

    

Answer 1

No meu caso, o seguinte comando corrigiu o problema com a falta de respostas SYN / ACK do servidor Linux:

sysctl -w net.ipv4.tcp_tw_recycle=0

Eu acho que é mais correto do que desabilitar timestamps TCP, pois os timestamps TCP são úteis afinal (PAWS, dimensionamento de janelas, etc).

A documentação do tcp_tw_recycle declara explicitamente que não é recomendável habilitá-lo, já que muitos roteadores NAT preservam os timestamps e, portanto, PAWS entra em ação, pois os timestamps do mesmo IP não são consistentes.

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this
          option is not recommended for devices communicating with the
          general Internet or using NAT (Network Address Translation).
          Since some NAT gateways pass through IP timestamp values, one
          IP can appear to have non-increasing timestamps.  See RFC 1323
          (PAWS), RFC 6191.