Atualmente estou investigando problemas de rede de uma LAN de amigos (de novo). A conectividade com a Internet é muito lenta e pouco confiável e às vezes os serviços simplesmente não funcionam.
Monitorei o tráfego há algum tempo usando o Wireshark. Finalmente descobri um problema reproduzível, um git pullover sshque não funcionou. Aqui está a git pullaparência do log do Wireshark :
As retransmissões TCP sempre iniciam quando a troca de chaves é iniciada. O servidor não está recebendo o pacote da minha máquina ou minha máquina não está recebendo a 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 descobri é o comprimento do pacote 1514, embora tenha o bit não fragmentado definido, de todos os pacotes ruins aqui, mas o roteador LANs está configurado para um MTU de 1492. Não consigo configurar o roteador para um MTU maior que 1500. Os pacotes poderiam ser muito grandes e ficar presos no roteador?
Além disso, a maioria das conexões seguras (https, ssh) parecem ser afetadas, mas também podem exigir tamanhos de pacotes maiores.
Veja, não tenho muita experiência com networking, então espero que alguns de vocês com mais experiência consigam entender melhor isso.
Editar: Agora mesmo, o git pullestá funcionando bem novamente. A configuração do MTU não pode ser a causa dos problemas...
Responder1
Pacotes grandes com "não fragmentar" são normais. É assim que o sistema operacional realiza a descoberta de MTU – em vez de permitir que a rede fragmente silenciosamente os pacotes, ele espera que um erro ICMP "Fragmentação necessária" seja retornado (que teria o MTU correto).
Se você vir pacotes grandes sendo retransmitidos, significa que algum roteador intermediário está configurado incorretamente e bloqueia os pacotes de erro ICMP ou não os envia quando necessário.
Responder2
Acho que acontece uma confirmação duplicadaapenasquando o receptor vê uma lacuna nos números de sequência, significando que um pacote foi descartado no caminho até 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 acks duplicados) de volta, 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 enviar, mas isso não é consistente com a confirmação duplicada anterior, nem com a confirmação posterior. Isso significaria que há 2 problemas em vez de 1.)
Aqui estão algumas ideias:
- se a conexão for através de um wifi público ou 3G ruim, você poderá obter breves períodos de queda de 100% dos pacotes. Verifique usando outro serviço ao mesmo tempo e veja se ele também foi afetado pela interrupção.
- existem firewalls com reconhecimento de protocolo que podem demorar um pouco para descobrir o que você está fazendo antes de decidirem descartar pacotes em uma conexão específica. Seu amigo está executando um firewall exótico que pode ser desativado? O ISP tem algumas regras de uso?
- tente atualizar os drivers ou inicializar a partir de um live CD do Linux e veja se a mesma coisa acontece. Tente alterar outros aspectos da conexão, usando outros serviços, para identificar o que há de errado.