Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v3.5 error - control socket has closed unexpectedly #751

Closed
bcronje opened this issue Jun 8, 2018 · 1 comment
Closed

v3.5 error - control socket has closed unexpectedly #751

bcronje opened this issue Jun 8, 2018 · 1 comment

Comments

@bcronje
Copy link

bcronje commented Jun 8, 2018

Context

I use iperf3 as part of an automated test environment using ansible. We run various tests over different network conditions.

  • Version of iperf3: iperf 3.5 (cJSON 1.5.2)

  • Hardware: lxd containers

  • Operating system (and distribution, if any): Ubuntu 16.04.3

  • Other relevant information (for example, non-default compilers,
    libraries, cross-compiling, etc.):

Bug Report

Randomly I get the following error in the json report:
"error": "error - control socket has closed unexpectedly"
When it happens, it seems to always occur after the second last interval, e.g. using -t 60 the json report will contain the interval report for interval 58 - 59, and then ends with the error. So the 60th interval is never reported on.

The server is run with iperf3 -s -D
The client is run with iperf3 -c 1.1.1.1 -t 60 -P 8 -J

Unfortunately I do not have access to the output of the server.

Note - I never experienced this when I was still using iper3 version that ships with Ubuntu, think it was v3.1.x ?? This might only be coincidence or a regression.

  • Expected Behavior
    Expects to complete the test without any errors.

  • Actual Behavior
    Test ends with "error": "error - control socket has closed unexpectedly"

  • Steps to Reproduce
    It occurs randomly, so not easy to reproduce.

@acooks acooks mentioned this issue Apr 19, 2019
@bmah888
Copy link
Contributor

bmah888 commented Jun 14, 2019

Increased the timeout on the control channel as per the first commit in PR #859, which hopefully will solve this issue.

A further enhancement could be to allow setting this as a command-line parameter, although note that the timer that is affected by this has no effect for the --bytes or --blockcount cases.

Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants