目前，我正在遇到正好每10分钟发生一次连接问题（需要花几秒钟）。
我有一个带有DD-WRT v24-sp2 std的Lynksys WRT150N。 我已经证实，这不是一个ISP问题，因为它发生在内部局域网，并把个人路由器的混合一切工作正常。
这个问题是一个相对较小的连接问题，因为几乎在所有的应用程序中， 当我参加一个在线的SANS课程时，我才发现这个问题，并且类stream应用程序每10分钟就会连接一次。
我决定进行一个pingtesting，我基本上只是在不断地攻击Google。 （ping / t www.google.com）。 我发现每10分钟我会得到一个“请求超时”。 或“来自192.168.1.1的回复：目标networking不可达”。 错误（没有明显的模式，哪一个会发生在另一个之上）。 这只会发生在10分钟的一个ICMP数据包，然后恢复正常。
我已经尝试更新固件（升级到v24-sp2，之前有一个旧版本）。 升级前后我一定要做30/30/30硬重启。 我已经试图在所有我能想到的地方寻找答案。 我发现最接近的东西是这个职位：
什么导致TCP / IP重置（RST）标志被发送？
当然，这只涉及到RST标志每隔10分钟就会发生一次（尽pipe我很好奇它们的问题实际上是TCP问题还是我所面临的问题不仅仅是TCP层，也有一个WRT路由器）。
在这一点上，我正在考虑只是得到一个新的路由器，但我觉得很难相信这是一个硬件问题，导致连接在这样一个固定的时间间隔下降。
任何帮助，您可以提供非常感谢。 对于我的错误概念或缺乏信息，我深表歉意。
“十分钟”就是这里的赠品 – 这是一些周期性的操作，由人的方向来完成。 那600秒，所以我很想去寻找某种stream量计量。
鉴于此，我做了一些Googlesearch，发现这一点：
http://www.handcoding.com/archives/2006/03/20/preventing-aim-disconnects-with-dd-wrt/
Google是你的朋友。
我知道如果从networkingpath中删除路由器，但您是否已经validation过其他客户端存在此问题，则无法重现该问题？ 我将确保在继续假设路由器是潜在的问题（尽pipe可能是）之前，您可以在多个客户端上重现此问题（尝试在另一台计算机上执行pingtesting）。
DD-WRT从来没有让我印象深刻，因为它是一个非常稳定的平台。 很难说这是否是由于它运行的硬件的COTS性质，DD-WRT本身还是两者的结合造成的。 无论一个快速的谷歌和漫步在论坛上发现很多“连接丢失”的问题。 由于没有足够的内存来保持客户端build立的所有TCP连接的状态，数据包通常被丢弃。 这是COTS“路由器”的常见问题，无论固件如何（DD-WRT都有一个关于相关问题的wiki）。
尝试通过ssh（或telnet）访问您的路由器，并通过/var/log/messages查看ip_conntrack（用于跟踪连接状态的内核模块）的任何内容。 你可能会发现这样的： ip_conntrack: table full, dropping packet 。
我看你已经调整了ip_conntrack_max设置为最大4096，但是尝试使用命令行（ cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max ）来validation。 如果你的WRT150N有一个相当数量的内存（例如，32MB或更大），你可以手动设置ip_conntrack_max到一个数字大于4096（见这里 ）。
WRT150N有多less客户？ 你使用的是P2P协议吗？ 不幸的是，我的经验是，Linksys的硬件和DD-WRTtypes的吸盘特别是在存在任何真实types的networkingstream量的情况下。 现在是时候去研究更强大的解决scheme了。