-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
iperf3: error - unable to receive parameters from client: Bad file descriptor #1808
Comments
To better understand this issue, I created a branch in my private iperf3 fork which print a debug message when this problem happens. The message starts with "*** TEMP DEBUG - Parameters JSON: ..." and shows the expected Parameters JSON length and the actual length received. Can you rebuild iperf3 for the server from this branch, run it and send the debug message output? |
@davidBar-On Here is the log
|
@davidBar-On Additional information: I'm on the corporate network. Are there any chances that the corporate network could prevent the client from sending packets to the server? |
I don't know. Usually different UDP/TCP ports are blocked, but in this case some messages were already exchanged between the client and server before the error happened. If there is a content filter (which I am not sure there is), then maybe the JSON contents were filtered.
Receiving 0 bytes can happen either because of timeout or because the the session was closed (by the corporate network)? To better understand what happens, I added few additional debug messages (same branch on my repository). Can you build the server from the new code and send the results? Please add the |
@davidBar-On Here is the log Server
Client
|
Somehow the JSON parameters message does not arrive to the server, so the read times out (note the 10 seconds difference between the client send time 50:49 and the server error at 50:59). It is probably because of some filtering in the corporate network. I don't know what this filtering is, but one guess is that it filters text/JSON. To check that I have changed the sent JSON to zeros. If JSON is filtered, then the message will arrive to the server (but it will fail since this is not JSON). Can you rebuild and run with the new version in the branch to check? |
@davidBar-On Here is the update Server
Client
|
@coinhu1995, sorry, I somehow didn't push the last debug changes to github. I did it now. Can you rebuild and run again? |
Server
Client
|
@coinhu1995, thanks for re-running. It is almost clear now that this is a corporate network issue. Either it filters JSON, filters text messages or something else. This is because in the last test there was no timeout and all the full 124 bytes message was received by the server. There is still small probability that this is an iperf3 issue, although I cannot guess what that might be. I suggest to ask corporate network administrators about this. If you want to evaluate this further, you can try sending different messages instead of the parameters string, to see if they are received by the server. This can be done with my branch code, in the
If you get any interesting results, either from the tests or about the corporate network, please share. |
@davidBar-On thank you. I will check with network admin. |
Context
Got error when measuring bandwidth between macos (local) and ubuntu (AWS EC2 with public IP)
Version of iperf3:
Client and server are the same: iperf 3.17.1+
Hardware:
Bug Report
Server log
Client log
N/A
The text was updated successfully, but these errors were encountered: