Aucune réponse à certains paquets SYN lorsque les horodatages sont activés

J'ai un serveur TCP qui écoute sur une machine ("le serveur") exécutant Ubuntu 12.04.3 (noyau 3.8.0-31-générique). Il reçoit les connexions de 2 machines client différentes. La machine A exécute Ubuntu 12.04.4 (3.11.0-17-générique) et la machine B exécute Ubuntu 11.10 (3.0.0-32-server).

Si les horodatages TCP sont activés sur le serveur (sysctl net.ipv4.tcp_timestamps = 1), les paquets SYN de la machine A sont parfois "ignorés". En utilisant tcpdump sur le serveur (en mode non promiscuous), je peux voir les SYN arriver correctement et avec des sommes de contrôle correctes - il n'y a tout simplement pas de réponse - pas de SYN / ACK et pas de RST. La machine A retransmet le SYN plusieurs fois avant d'abandonner. Le logiciel client exécuté sur la machine A (wget dans ce cas) réessaye immédiatement avec une nouvelle connexion et réussit, obtenant un SYN / ACK instantané.

La machine B n'a aucun problème avec le même serveur et son trafic semble normal - elle utilise également les mêmes options TCP que la machine A (d'après ce que je vois dans les fichiers de capture). La désactivation des horodatages TCP sur le serveur fait que tout fonctionne comme il se doit.

Les horodatages dans les paquets SYN ignorés semblent cependant être valides pour moi, donc je ne sais pas pourquoi ils causent des problèmes ou s'ils sont la cause sous-jacente.

J'ai mis un pcap anonyimisé ici https://www.dropbox.com/s/onimdkbyx9lim70/server-machineA.pcap . Elle a été prise sur le serveur (10.76.0.74) montrant que la machine A (10.4.0.76) a réussi à exécuter un HTTP GET (paquets 1 à 10), puis 1 seconde plus tard en essayant de récupérer à nouveau la même URL (paquets 11 à 17) mais à la place a ses SYNs ignorés. Les paquets 18 à 27 sont un autre succès.

Je soupçonne que c'est un problème similaire à celui décrit dans " Pourquoi un serveur n'enverrait-il pas un paquet SYN / ACK en réponse à un paquet SYN " et tout en désactivant les horodatages est une solution de contournement, je voudrais comprendre ce qui se passe. Est-ce juste un bug?

Aucun pare-feu local n'est en cours d'exécution. Le serveur gère pas mal de connexions TCP (environ 32 Ko à la fois) mais dispose de beaucoup de mémoire / CPU libre. Au moment du test indiqué dans le pcap, il n'y avait aucune autre connexion TCP entre la machine A et le serveur. Il n'y a aucun signe que la file d'attente d'acceptation de l'application serveur se remplit soudainement (en plus cela devrait affecter les deux clients, je suppose). Comme les paquets semblent OK dans un pcap pris sur le serveur, il ne semble pas qu'un périphérique réseau intervenant soit en train de casser les choses.

J'ai initialement posté cela sur les forums ubuntu mais avec le recul, cela peut être un endroit plus approprié. En espérant le prêt d'un indice.

Dans mon cas, la commande suivante a résolu le problème avec les réponses SYN / ACK manquantes du serveur Linux:

sysctl -w net.ipv4.tcp_tw_recycle=0

Je pense que c'est plus correct que de désactiver les horodatages TCP, car les horodatages TCP sont utiles après tout (PAWS, mise à l'échelle des fenêtres, etc.).

La documentation sur le tcp_tw_recycleexplicit indique qu'il n'est pas recommandé de l'activer, car de nombreux routeurs NAT conservent les horodatages et donc PAWS entre en action, car les horodatages de la même IP ne sont pas cohérents.

   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.