Nessuna risposta ad alcuni pacchetti SYN quando i timestamp sono abilitati

Ho un server TCP in ascolto su una macchina ("il server") con Ubuntu 12.04.3 (kernel 3.8.0-31-generico). Riceve connessioni da 2 macchine client diverse. La macchina A esegue Ubuntu 12.04.4 (3.11.0-17-generico) e la macchina B esegue Ubuntu 11.10 (3.0.0-32-server).

Se i timestamp TCP sono abilitati sul server (sysctl net.ipv4.tcp_timestamps = 1), a volte i pacchetti SYN dalla macchina A vengono "ignorati". Usando tcpdump sul server (in modalità non promiscua) vedo che i SYN arrivano OK e con checksum corretti - non c'è risposta - nessun SYN / ACK e nessun RST. La macchina A ritrasmette il SYN diverse volte prima di arrendersi. Il software client in esecuzione sulla macchina A (in questo caso wget) riprova immediatamente con una nuova connessione e ha esito positivo, ottenendo un SYN / ACK istantaneo.

La macchina B non ha problemi con lo stesso server e il suo traffico sembra normale - utilizza anche le stesse opzioni TCP della macchina A (da quello che vedo dai file di acquisizione). La disabilitazione dei timestamp TCP sul server fa funzionare tutto come dovrebbe.

I timestamp nei pacchetti SYN ignorati sembrano essere validi per me, quindi non sono sicuro del motivo per cui stanno causando problemi o se sono la causa sottostante.

Ho messo un pcap anonimizzato qui https://www.dropbox.com/s/onimdkbyx9lim70/server-machineA.pcap . È stato acquisito sul server (10.76.0.74) che mostrava la macchina A (10.4.0.76) che eseguiva correttamente un HTTP GET (pacchetti da 1 a 10) e quindi 1 secondo dopo, tentando di recuperare nuovamente lo stesso URL (pacchetti da 11 a 17) ma invece ha i suoi SYN ignorati. I pacchetti da 18 a 27 sono un altro successo.

Ho il sospetto che questo sia un problema simile a quello descritto in " Perché un server non dovrebbe inviare un pacchetto SYN / ACK in risposta a un pacchetto SYN " e mentre disabilitare i timestamp è una soluzione alternativa, vorrei capire cosa sta succedendo. Questo è solo un bug?

Non è in esecuzione un firewall locale. Il server gestisce alcune connessioni TCP (circa 32 KB alla volta) ma ha molta memoria / CPU libere. Al momento del test mostrato nel pcap non c'erano altre connessioni TCP tra la macchina A e il server. Non vi è alcun segno che la coda di accettazione dell'applicazione server si stia riempiendo improvvisamente (oltre a ciò dovrebbe interessare entrambi i client, presumo). Dato che i pacchetti sembrano OK in un pcap preso sul server, non sembra che un dispositivo di rete che sta intervenendo stia rompendo le cose.

Inizialmente l'ho pubblicato nei forum di Ubuntu, ma a ben vedere questo potrebbe essere un posto più appropriato. Sperando in un prestito di un indizio.

Nel mio caso il seguente comando ha risolto il problema con risposte SYN / ACK mancanti dal server Linux:

sysctl -w net.ipv4.tcp_tw_recycle=0

Penso che sia più corretto che disabilitare i timestamp TCP, poiché i timestamp TCP sono utili dopo tutto (PAWS, ridimensionamento delle finestre, ecc.).

La documentazione sull'affermazione tcp_tw_recycleesplicita che non è consigliabile abilitarlo, poiché molti router NAT conservano i timestamp e quindi si avvia PAWS , poiché i timestamp dello stesso IP non sono coerenti.

   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.