Atualmente estou investigando problemas de rede de uma LAN de amigos ( novamente ). A conectividade com a Internet é muito lenta e não confiável e, às vezes, os serviços simplesmente não funcionam.
Eu monitorei o tráfego por algum tempo usando o Wireshark. Eu finalmente encontrei um problema reproduzível, um git pull over ssh que não funcionou. Aqui está como o log do Wireshark do git pull se parecia:
As retransmissões TCP sempre começam quando a troca de chaves é iniciada. O servidor não está recebendo o pacote da minha máquina ou a minha máquina não está recebendo sua resposta. Tenho a sensação de que a causa disso também é a causa de todos os outros problemas de rede da LAN.
Uma coisa que eu criei foi o comprimento do pacote de 1514 , enquanto o conjunto de bits não é fragmentado, de todos os pacotes ruins aqui, mas o roteador LANs está configurado para um MTU de 1492 . Não consigo configurar o roteador para uma MTU maior que 1500 . Os pacotes poderiam ser muito grandes para que eles fiquem presos no roteador?
Além disso, a maioria das conexões seguras (https, ssh) parece ser afetada, mas elas sempre podem exigir tamanhos maiores de pacotes também.
Você vê, eu não tenho muita experiência com networking, então espero que alguns de vocês com mais experiência possam fazer mais sentido disso.
Editar : Agora, o git pull está funcionando bem novamente. A configuração da MTU não pode ser a causa dos problemas ...
Grandes pacotes com "não fragmentar" são normais. É assim que o SO executa a descoberta de MTU - em vez de deixar a rede fragmentar silenciosamente os pacotes, espera que seja retornado um erro "Fragmentation required" do ICMP (que teria o MTU correto).
Se você ver os pacotes grandes sendo retransmitidos, isso significa que algum roteador no meio está configurado incorretamente e bloqueia os pacotes de erro do ICMP ou não os envia quando necessário.
Eu acho que um ack duplicado acontece somente quando o receptor vê uma lacuna nos números de sequência, significando que um pacote foi descartado no caminho para ele; então o problema começa na direção de 192.168.0.8 para o servidor remoto. O fato de não haver acks (nem mesmo duplicados) apesar de várias retransmissões provavelmente significa que algo está totalmente errado nessa direção. (Isso pode significar que o lado remoto não pode ser enviado, mas isso não é consistente com o duplicado ack anterior, nem com o fin-ack mais tarde. Isso significaria que existem dois problemas em vez de 1.)
Aqui estão algumas ideias:
Tags networking wireshark tcp