你运行的是什么版本的iperf？ 需要什么命令行参数来实现这一点？

你好，

我们注意到了同样的问题。 在我们的例子中，我们使用 iperf3 进行 WiFi 网络的吞吐量调查。 这通常在具有大量漫游和连接中断的不可靠网络上完成。

我进一步分析了这个问题。 我认为问题在于，当客户端网络连接突然断开时，TCP 连接可能会在服务器端处于 ESTABLISHED 状态。 这些连接永远不会被操作系统关闭（或者至少在很长一段时间内都不会）。 这就是 iperf3 的服务器端 TCP 控制通道连接发生的情况。 这会导致测试无限期地继续进行，这反过来意味着服务器拒绝任何进一步的连接，直到它重新启动。

我能想到的最简单的解决方法是在服务器端设置一个超时，关闭任何运行时间超过客户端请求的“持续时间”的测试。 我有一个 iperf_server_api.c 修订版 8d3ed69f8e86281ac0a491df3268b70a53007b1d 的补丁，它通过关闭持续时间超过“持续时间”+ 5 秒的测试为我解决了这个问题。 如果你喜欢，我可以发给你。 我要把它寄到哪里？

对于未来，也许更健壮的方法是在检查连接状态的控制信道上有一个周期性的保持活动消息。 不过，这可能会非常轻微地影响测试结果。

如果您需要更多信息，请告诉我。

最好的问候，迈克尔

你好，我们又见面了，

我分叉了源代码并将更改放在这里：
https://github.com/mkall/iperf/commit/aaeeaf6c9cdbc466d762ccd3fdcf0b790319cfee

我忘了发布重现问题的步骤。 只需运行任何 UDP 测试，并在测试进行时突然断开客户端的网络。 对我来说，100% 的时间服务器将永远运行测试并且必须重新启动。

我们希望此修复程序（或解决此问题的其他修复程序）可以尽快包含在 master 分支中。 在此之前，我们将不得不使用从该源构建的自定义二进制文件。

最好的问候，迈克尔

迈克尔，
这与我让它挂起的使用场景完全相同。
非常感谢你的补丁，我会把它应用到我们的测试中
服务器，看看我是否也可以为您确认修复。
我真的很感谢你在这方面的帮助。 我会把我的电子邮件地址发给你
当我到办公室时！

大卫

周一，2015年1月12日，mkall [email protected]写道：

你好，我们又见面了，

我分叉了源代码并将更改放在这里：
mkall@aaeeaf6
https://github.com/mkall/iperf/commit/aaeeaf6c9cdbc466d762ccd3fdcf0b790319cfee

我忘了发布重现问题的步骤。 只需运行任何 UDP 测试，然后
当测试正在进行时，突然断开客户端的网络。 为了我
100% 的时间服务器将永远运行测试并且必须
重新启动。

我们希望此修复程序（或解决该问题的其他修复程序）可以
尽快包含在主分支中。 在此之前，我们将不得不使用自定义
从此源构建的二进制文件。

最好的问候，迈克尔

—
直接回复此邮件或在 GitHub 上查看
https://github.com/esnet/iperf/issues/225#issuecomment -69556212。

嗨，大卫。

你有没有机会试用我的补丁？ 我很想知道您的问题是否已解决。 特别是因为这可能会增加最终修复主分支的机会。

• 米凯尔

迈克尔，
我昨天在 TCP 和 UDP 上对此进行了测试。 变化似乎有
彻底解决了问题！ 我确实注意到一件奇怪的事情：补丁
导致进程以“错误的文件描述符”错误终止，我不
知道是否有办法将其详细程度更改为“测试超时”
或类似的东西，但在功能上它非常有效！！

大卫

上周日，2015年1月18日，mkall [email protected]写道：

嗨，大卫。

你有没有机会试用我的补丁？ 我很想知道你是否
问题已解决。 特别是因为这可能会增加
最终得到对主分支的修复。

• 米凯尔

—
直接回复此邮件或在 GitHub 上查看
https://github.com/esnet/iperf/issues/225#issuecomment -70451590。

好的，谢谢！ 但是，“导致进程终止”是什么意思？ 整个 iperf 服务器进程是否真的终止了？ 我猜你不是那个意思，否则你可能不会对修复很满意。 :) 它应该只是终止正在进行的测试。

布鲁斯，我不确定你是否在关注这个讨论。 如果我要稍微清理一下修复程序，您会考虑将其合并到主分支吗？ 或者你更喜欢其他类型的修复？ 通过清理代码，我的意思是添加注释，添加更好的错误消息，并可能设置超时 #DEFINE 值的秒数。

• 米凯尔

布鲁斯，
你是对的，整个 iperf 进程不会终止，只有
目前正在运行测试！ 我实际上对修复很满意，很高兴
你的参与！ 感谢你们每个人都参与其中
让 Linux 很棒！

大卫

周二，2015年1月20日，mkall [email protected]写道：

好的，谢谢！ 但是，您所说的“导致进程
终止”？整个 iperf 服务器进程是否真的终止了？我是
猜你不是那个意思，否则你可能不会很开心
与修复。 :) 它应该只是终止正在进行的测试。

布鲁斯，我不确定你是否在关注这个讨论。 如果我要
稍微清理一下修复你会考虑将它合并到主分支吗？
或者你更喜欢其他类型的修复？ 通过清理代码我的意思是添加
评论，添加更好的错误信息，并可能使数量
#DEFINE 值超时的秒数。

• 米凯尔

—
直接回复此邮件或在 GitHub 上查看
https://github.com/esnet/iperf/issues/225#issuecomment -70623900。

@mkall ：我一直在关注这个……我正在做几个几乎完全不相关的项目。 我希望尽快找时间看看你的补丁。

@haukened ：Linux 不是唯一的开源项目，或者实际上是唯一的开源操作系统。 来自 FreeBSD 的前发行工程师。 :-)

你好，我不得不承认这个问题也困扰着我的服务器实例。 （从最新的 git 构建。）
布鲁斯，你能看看这个吗？

我在 CentOS 6.5 下使用 TCP 运行 iperf 3.0.11，我看到了一些问题。

如果我从客户端断开以太网电缆，服务器将保持忙碌，直到我终止并重新启动 iperf3 服务器进程。

我还看到 iperf3 根本不响应客户端的情况。 服务器表明它正在侦听，但客户端连接挂起，然后返回“iperf3：错误 - 无法接收控制消息：对等方重置连接”。 这是在这种情况下使用的 iperf3 服务器端口的 lsof 输出（我知道它说它正在侦听）：

lsof | 格雷普 55503
iperf3 28785 根 3u IPv6 2703599 0t0 TCP *:55503（听）
iperf3 28785 根 4u IPv6 2705589 0t0 TCP xxxx:55503->xxxx:48790（已建立）
iperf3 28785 根 5u IPv6 2707433 0t0 TCP xxxx:55503->xxxx:48795 (CLOSE_WAIT)
iperf3 28785 根 7u IPv6 2755607 0t0 TCP xxxx:55503-> xxxx:48962 （已建立）

我有多个 10G 服务器出现此问题。 我很乐意协助解决此问题。

我也注意到流套接字也可以挂起，所以我在 mkall 的这个很好的补丁中添加了代码来做到这一点并提交了拉取请求。

https://github.com/dmdailey/iperf/pull/1/commits/f7fd67d4a2848aca754cfdb4d76ffeb1df1442fd

这已通过拉取请求 #446 解决。 保持这个问题开放以注意需要合并代码更改。

446 合并到 3.1-STABLE。 关闭。

我在客户端和服务器机器上都安装了 3.7 版，但问题仍然存在，无论是 TCP 还是 UDP 连接。 当客户端断开连接时，服务器不会停止和/或重新启动......我在测试持续时间结束之前断开连接并且我使用的是 Alpine 机器（客户端）和 OpenWrt 机器（服务器）。 我在 iperf 文档中没有找到有关可能的服务器超时的任何信息。 是我遗漏了什么，还是其他人有同样的问题？