8 votos

De débito / crédito pinpad terminales de desconexión de red después de 15 minutos. Reconexión tras una error

Tenemos una red HP procurve y a unos 20 de la norma de débito/crédito pinpad terminales de todo el mundo está acostumbrado a ver en casi todas las tiendas en estos días. Se conectan directamente a la red LAN y que sólo se comunica a un sitio de pago en SSL/443. Ningún software de servidor o en el medio.

El problema es que los dispositivos suelen dar una conexión TCP error en el primer intento de uso. Luego vamos a trabajar muy bien durante una hora en línea recta. Pero, si se le permite quedarse en reposo durante 10 - 15 minutos (aprox), que va a tirar el error inicial una vez.

Inicialmente, todos ellos eran de una sola empresa y nos dimos cuenta de que tenía algo que ver con su configuración, o la marca y modelo. Pero recientemente, hemos instalado algunos de los nuevos dispositivos de una forma completamente diferente proveedor, utilizando diferentes tipos de pinpads ... y ellos tienen el mismo error.

Hemos tratado de estática vs DHCP direccionamiento IP. Hemos añadido el fuera de sitio de pago para un especial de la regla de firewall que les permite salir sin el normal amenaza de cheques. Hemos intentado, en varias Vlan. Hemos tratado de conencting a diversos tipos de áreas de interruptores. Incluso han intentado previsto un archivo por lotes que los pings ellos (hecho en casa stay alive), cada 3 minutos. Nada hace ninguna diferencia. En términos de problemas de red, los dispositivos son todos conencted exactamente en la misma vlan y de las áreas de interruptores como sus cercanos efectivo ordenadores/impresoras - y no tenemos problemas con cualquier otra cosa. El dinero en efectivo de los sistemas de ejecución completa de servidor/cliente de la base de datos de las aplicaciones, y si la misma disconenct tema estuvo presente en los mismos debido a que el trabajo en red en el área fue malo, nos gustaría escuchar acerca de ella rápido.

Última teoría que voy a abordar es la relativa a la caché de arp tiempos de espera, pero estoy empezando.

Agradecería alguna ayuda ... ideas locas también la bienvenida.

W.

5voto

Dave Lucre Puntos 176

He visto un problema similar en el pasado. Mi problema estaba relacionado con mi dispositivo de establecer una conexión a través de un dispositivo NAT, y luego de que la conexión se quedó inactivo durante demasiado tiempo (enviado nada, nada de lo recibido). Ambos extremos de la conexión no tenía ni idea, pero el dispositivo NAT en el medio decidió cerrar la conexión debido a la inactividad. A continuación, cuando el tráfico estaba tratando de atravesar el NAT, los paquetes estaban siendo abandonados a causa de la regla de NAT ya no existía.

Los dispositivos podrían estar haciendo algo similar. Mi solución fue usar un paquete keep-alive entre los dos dispositivos. Iba a enviar un paquete a cada 60 segundos, y en esta solucionado mi problema (el sistema ha estado funcionando durante varios años sin necesidad de ser tocado). Simplemente hacer ping a cualquiera de los dispositivos de la misma red LAN no fue suficiente para mantener la regla de NAT en el lugar. Los dispositivos DEBEN hablar entre sí con regularidad.

Sin embargo, sin saber más acerca de su particular sistemas, es difícil decir si esto se aplica a usted.

Espero que esto ayude.

2voto

kce Puntos 9227

El problema es que los dispositivos suelen dar una conexión TCP error en el primer intento de uso. Luego vamos a trabajar muy bien durante una hora en línea recta. Pero, si se le permite quedarse en reposo durante 10 - 15 minutos (aprox), que va a tirar el error inicial una vez.

La primera cosa que yo recomiendo es localizar una copia del manual o de hablar con el proveedor para obtener una explicación de exactamente lo que el error de los dispositivos de generar medios. He perdido el tiempo buscando Capa-3/4 problemas cuando el error en realidad significaba algo más. No todos los proveedores de utilizar correctamente la terminología o de forma coherente.

Suena como los dispositivos que no son el envío de manejo o haciendo keep-alive correctamente. Si no hay datos de atravesar más de su conexión TCP, se cerrará con el tiempo. Para evitar este extremo (o ambos) puede enviar paquetes keep-alive para evitar la conexión se termina. Sé que esto se puede hacer con TCP (Capa 4) y, presumiblemente, también se podría hacer con SSL/TLS (Capa 7).

Poner un sniffer de paquetes de elegir entre uno de estos dispositivos y de su infraestructura y registro de todos los de su tráfico desde el momento en que las obras hasta el momento no. Luego de mirar a través de ella y saber que el dispositivo o en el servidor que se conecta a partir de la secuencia de terminación, y luego ver lo que inmediatamente precede. También tomamos una mirada en el punto en el tiempo donde el dispositivo lanza la "conexión TCP de error" error. Está tratando de utilizar una conexión que se piensa, sino que el servidor piensa que es despedido? Algo extraño está pasando aquí - si la conexión no está establecida, en lugar de tirar un error, su tarjeta de crédito dispositivo debería intentar crear uno nuevo (que al parecer sucede con éxito el segundo tiempo).

Y por último, si usted está usando NAT, considere la posibilidad de que uno de estos dispositivos de una manera directa, la no-conexión de NAT para propósitos de prueba (una vez más, tomar una captura de paquetes). NAT puede hacer cosas muy extrañas a las aplicaciones o protocolos que dependen de la extremo-a-Extremo Princple y no tome la generalización del uso de NAT u otro estado de los dispositivos de interferir con la conexión en cuenta.

Si usted está usando un proxy, asegúrese de que no está involucrado o que está correctamente configurado para manejar estos dispositivos. Tenemos un montón de dispositivos o procesos que son lo suficientemente inteligentes como para utilizar su sistema operativo host del WPAD configuración pero no presentar las credenciales de active directory de la cuenta de usuario que ejecuta con sus solicitudes de HTTP/HTTPS y el proxy espera que todas las conexiones estén autenticadas por lo que el proceso silencio va a fallar el lado del cliente.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: