TCP Dup ACK / ritrasmissione, configurazione errata?

Attualmente sto esaminando i problemi di rete di una LAN di amici ( ancora ). La connettività Internet è molto lenta e inaffidabile e talvolta i servizi semplicemente non funzionano.

Ho monitorato il traffico per un po 'di tempo usando Wireshark. Alla fine ho trovato un problema riproducibile, a git pull al di sopra di ssh quello non ha funzionato. Ecco quello che il registro Wireshark del git pull sembrava:

Le ritrasmissioni TCP iniziano sempre quando viene avviato lo scambio di chiavi. O il server non riceve il pacchetto dalla mia macchina o la mia macchina non sta ricevendo la sua risposta. Ho la sensazione che la causa di questo sia anche la causa di tutti gli altri problemi di rete della LAN.

Una cosa che mi è venuta in mente è la lunghezza del pacchetto di 1514, pur avendo il bit non frammentato bit, di tutti i pacchetti difettosi qui, ma il router LAN è configurato per un MTU di 1492. Non riesco a configurare il router per una MTU più grande di 1500. I pacchetti potrebbero essere troppo grandi per essere bloccati sul router?

Inoltre, le connessioni per la maggior parte sicure (https, ssh) sembrano essere interessate, ma queste potrebbero sempre richiedere anche pacchetti di dimensioni maggiori.

Vedi, non ho molta esperienza con il networking, quindi spero che alcuni di voi con più esperienza siano in grado di dare più senso a questo.

modificare : Proprio ora, il git pull sta funzionando di nuovo bene. La configurazione MTU non può essere la causa dei problemi ...

I grandi pacchetti con "non frammentare" sono normali. Ecco come il sistema operativo esegue il rilevamento MTU - invece di lasciare che la rete frammenti in modo silenzioso i pacchetti, si aspetta che venga restituito un errore ICMP "Fragmentation required" (che avrebbe il MTU corretto).

Se si vedono ritrasmettere i pacchetti di grandi dimensioni, significa che alcuni router nel mezzo non sono configurati correttamente e blocca i pacchetti di errore ICMP o non li invia quando necessario.

Penso che accada un duplicato solo quando il ricevitore vede una lacuna nei numeri di sequenza, il che significa che un pacchetto è stato rilasciato sulla strada per raggiungerlo; quindi il problema inizia nella direzione da 192.168.0.8 al server remoto. Il fatto che non ci siano acks (nemmeno duplicati ack) nonostante alcune ritrasmissioni probabilmente significa che qualcosa è totalmente fottuto in quella direzione. (Potrebbe significare che il lato remoto non può inviare ma che non è coerente con l'ack duplicato prima, né con il fin-ack più tardi. Significherebbe che ci sono 2 problemi invece di 1.)

Ecco alcune idee:

• se la connessione è al di sopra di una cattiva rete pubblica Wi-Fi o 3G, è possibile ottenere brevi periodi di caduta del pacchetto del 100%. Verifica utilizzando un altro servizio allo stesso tempo e controlla se è interessato anche dall'interruzione.
• ci sono firewall compatibili con il protocollo che potrebbero richiedere un po 'di tempo per capire cosa si sta facendo prima che decidano di eliminare pacchetti su una particolare connessione. Il tuo amico ha un firewall esotico che potrebbe essere spento? L'ISP ha alcune regole di utilizzo?
• prova ad aggiornare i driver o ad avviare da un CD live di Linux e vedere se succede la stessa cosa. Prova a cambiare altri aspetti della connessione, utilizzando altri servizi, per limitare ciò che è sbagliato.