Un número de secuencia de datos ya reconocido vuelve a aparecer como byte nulo repetidamente

Hay un server de procesamiento de transactions (TP-Server) al que se conecta mi aplicación (Cliente). Estamos viendo una extraña secuencia de packages en la que TP-Server está enviando un package PUSH con un nulo (0) byte de datos, pero el número de secuencia de este package es incorrecto; el número de secuencia es el del último byte recibido.

Por favor, mire los datos de volcado TCP aquí
http://pastebin.com/5UBXWazy

172.250.10.10.13824 es el server TP.

172.11.105.5.49524 es el Cliente.

"TP-Server" no está en mi control, no estoy seguro de qué sistema operativo se está ejecutando. "Cliente" es mi aplicación de pago que se ejecuta en Debian Squeeze.

Puede ver que los datos de bytes nulos son enviados por TP-Server en el package siguiente.

20:52:34.472819 IP (tos 0x0, ttl 59, id 51820, offset 0, flags [DF], proto TCP (6), length 53) 172.250.10.10.13824 > 172.11.105.5.49524: Flags [P.], cksum 0xe36f (correct), seq 1457045850:1457045851, ack 3097912286, win 17680, options [nop,nop,TS val 646012206 ecr 73190886], length 1 0x0000: 4500 0035 ca6c 4000 3b06 a941 acfa 0a0a E..5.l@.;..A.... 0x0010: ac0b 6905 3600 c174 56d8 c15a b8a6 63de ..i.6..tV..Z..c. 0x0020: 8018 4510 e36f 0000 0101 080a 2681 5d2e ..E..o......&.]. 0x0030: 045c cde6 00 .\... 

El número de secuencia de los datos de byte nulo anteriores se marca como 1457045850. Pero el mismo se recibió mucho antes en el time como se muestra a continuación.

 20:50:22.506267 IP (tos 0x0, ttl 59, id 51817, offset 0, flags [DF], proto TCP (6), length 607) 172.250.10.10.13824 > 172.11.105.5.49524: Flags [P.], cksum 0x6460 (correct), seq 1457045296:1457045851, ack 3097912253, win 17680, options [nop,nop,TS val 645999009 ecr 73187775], length 555 

Para el número de secuencia incorrecto, Cliente responde de nuevo con una bandera de saco que indica el número de secuencia incorrecto.

 20:52:34.472864 IP (tos 0x0, ttl 64, id 1172, offset 0, flags [DF], proto TCP (6), length 64) 172.11.105.5.49524 > 172.250.10.10.13824: Flags [.], cksum 0x4501 (correct), seq 3097912286, ack 1457045851, win 2003, options [nop,nop,TS val 73220891 ecr 646012206,nop,nop,sack 1 {1457045850:1457045851}], length 0 

Los mismos datos de byte nulo se envían repetidamente por TP-Server durante 7 veces más con el mismo número de secuencia incorrecto. Y el cliente responde con delicadeza de nuevo con el saco.

 20:58:29.024492 IP (tos 0x0, ttl 59, id 51827, offset 0, flags [DF], proto TCP (6), length 53) 172.250.10.10.13824 > 172.11.105.5.49524: Flags [P.], cksum 0x04bf (correct), seq 1457045850:1457045851, ack 3097912308, win 17680, options [nop,nop,TS val 646047661 ecr 73277952], length 1 0x0000: 4500 0035 ca73 4000 3b06 a93a acfa 0a0a E..5.s@.;..:.... 0x0010: ac0b 6905 3600 c174 56d8 c15a b8a6 63f4 ..i.6..tV..Z..c. 0x0020: 8018 4510 04bf 0000 0101 080a 2681 e7ad ..E.........&... 0x0030: 045e 2200 00 .^".. 20:58:29.024553 IP (tos 0x0, ttl 64, id 1179, offset 0, flags [DF], proto TCP (6), length 64) 172.11.105.5.49524 > 172.250.10.10.13824: Flags [.], cksum 0x602c (correct), seq 3097912308, ack 1457045851, win 2003, options [nop,nop,TS val 73309529 ecr 646047661,nop,nop,sack 1 {1457045850:1457045851}], length 0 

Sin embargo, la octava vez sucede lo mismo, el cliente deja de dar ack. TP-Server continúa enviando datos de byte nulo por otras 5 veces más, para ninguno de los cuales el cliente responde con ack. Este comportamiento está ocurriendo en el nivel de stack de networking y mi pobre aplicación de cliente no recibe errores de socket y sólo a time "21:18:59", recibió un error getsocketopt: 110 (que creo que es ETIMED_OUT). Por lo tanto, mi aplicación cliente, esperó un poco más de time y trató de volver a conectar a las 21:21:38 (se puede ver los packages SYN). Sin embargo, el TP-Server no estaba respondiendo después de eso. Después de reiniciar el PC "Cliente" después de unos minutos, el TP-Server aceptó nuevas conexiones. Sin embargo, los mismos packages de bytes nulos comienzan a reaparecer nuevamente. A veces, sucedió que el Cliente tenía algunos packages de datos periódicos para ser enviados al TP-Server en intervalos de aproximadamente 10 segundos y esto mantuvo la connection viva, independientemente de los bytes nulos que siguen ocurriendo y el cliente responde con los sacos.

Mis preguntas:

  1. ¿Cuál es la razón detrás de estos bytes de datos nulos enviados con el número de secuencia incorrecto?

  2. ¿Debo hacer algo acerca de la stack de networking debian para manejar este escenario para mantener la connection viva?

  • ¿Cuál es el tiempo de espera de conexión TCP predeterminado en Windows?
  • Cómo extender el range de IP desde 192.168.1.1 a 192.168.2.254
  • Práctico Anycast
  • TCP Dump, no puede entender estas 4 líneas?
  • ¿Cómo puedo agregar más de 255 máquinas a una única networking de Clase C?
  • Varias direcciones IP por NIC
  • La ruta UNC falla por IP "ningún proveedor de red aceptó la ruta de red dada", pero funciona usando el nombre de host
  • Dispositivo de networking para cambiar la dirección IP dentro de los packages
  • ¿Por qué se corrompe la stack TCP / IP W2k3?
  • ¿Cómo puedo persistir una ruta en Ubuntu 9.04?
  • Bloqueo de NetDiag + TCP?
  • ¿Cómo puedo averiguar mi dirección IP en un cuadro unix-like?
  • Configuración de networking ESXi para máquinas virtuales internas aisladas
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.