我们有一个惠普procurvenetworking和大约20个标准的借记/信贷pinpadterminal，每个人都习惯在几乎每一家商店看到这些天。 它们直接连接到局域网，只能通过SSL / 443与支付站点通信。 没有软件或服务器在中间。
问题是设备在第一次尝试使用时通常会导致TCP连接失败。 然后，他们会正常工作一个小时。 但是，如果允许闲置10-15分钟（约），他们会抛出最初的错误一次。
最初，他们都来自一家公司，我们认为这与他们的设置或制造/模型有关。 但是最近，我们已经从一个完全不同的供应商那里安装了一些新的设备，使用不同types的pinpads …并且它们有相同的错误。
我们已经尝试了静态与DHCP IP寻址。 我们已经将外部付款网站添加到特殊的防火墙规则，允许他们没有正常的威胁检查退出。 我们已经尝试过各种Vlans。 我们已经尝试将它们转化为各种types的区域切换。 甚至已经尝试了一个预定的batch file，他们每隔3分钟将它们（自制的）保留下来。 没有什么区别。 在networking问题方面，这些设备都与其附近的现金电脑/打印机完全相同，并且没有任何问题。 现金系统运行完整的客户端/服务器/数据库应用程序，如果因为该地区的networking不好而出现同样令人不安的问题，我们会很快听到。
我将要解决的最新理论与arpcaching超时有关，但我刚刚开始。
将不胜感激一些援助…疯狂的想法也欢迎。
W.
过去我也遇到类似的问题。 我的问题是关于我的设备通过NAT设备build立连接，然后连接保持闲置太久（没有发送，没有收到）。 连接的两端都不知道，但是中间的NAT设备由于不活动而决定closures连接。 然后，当stream量试图穿越NAT时，由于NAT规则不再存在，数据包被丢弃。
您的设备可能正在做类似的事情。 我的解决scheme是在两个设备之间使用保持活动的数据包。 它会每60秒发送一个数据包，这就解决了我的问题（系统已经运行好几年了，现在不需要被触摸）。 只需ping同一个局域网中的任何一台设备，都不足以将NAT规则保留在原地。 设备必须定期对话。
但是，如果不了解更多关于您的特定系统的信息，就很难说这是否适用于您。
希望这可以帮助。
问题是设备通常在第一次尝试使用时发生TCP连接失败。 然后，他们会正常工作一个小时。 但是，如果允许闲置10-15分钟（约），他们会抛出最初的错误一次。
我build议的第一件事就是查看手册的副本或与供应商交谈，以获得有关设备产生错误的准确解释。 当错误实际上意味着别的东西的时候，我浪费了时间寻找Layer-3/4的问题。 并非所有供应商都正确或一致地使用术语。
这听起来像设备没有发送处理或保持正常运行。 如果没有数据遍历你的TCP连接，它将被最终closures。 为了防止这一个端点（或两者）可以发送保持活动分组以防止连接被终止。 我知道这可以用TCP（Layer-4）完成，大概也可以用SSL / TLS（Layer-7）完成。
在这些设备之一和你的基础设施之间放置一个select的数据包嗅探器，并logging从它工作的时间到它没有的时间的所有stream量。 然后查看它并查找连接到的设备或服务器在何处开始终止序列 ，然后查看紧接着的内容。 还要看看设备抛出“TCP连接失败”错误的时间点。 它是否尝试使用它认为已build立的连接，但服务器认为已终止？ 这里也发生了一些奇怪的事情 – 如果连接没有build立，而不是抛出一个错误，你的信用卡设备应该尝试创build一个新的（显然第二次成功发生）。
最后，如果您使用的是NAT，请考虑给这些设备之一提供一个直接的非NAT连接用于testing目的（再次捕获数据包）。 对于依赖于端到端原则的应用程序或协议，NAT可以做很奇怪的事情，不要将NAT或其他有状态的设备广泛使用，而将干涉连接考虑在内。
如果您使用的是代理服务器，请确保它不涉及或正确configuration以处理这些设备。 我们有很多设备或进程足够聪明，可以使用其主机操作系统的WPAD设置，但不会提交正在运行它们的用户帐户的活动目录凭据，而且它们的HTTP / HTTPS请求和代理需要所有连接进行身份validation所以这个过程将悄然失败，客户端。