-
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 server udp mode showing 0.0 for everthing #905
Comments
@mojtaba-eshghie You are using a really old version of iperf3. The latest version is 3.7. Can upgrade to the latest version and try again. |
This is also tested using the following version of iperf3, still the exact same situtation: |
So your client is sending data to the server, but it looks like none of the packets are getting through. The control connection seemed to have worked however. I wonder if you have some sort of firewall or packet filter blocking UDP traffic between yoru hosts. What if you try a TCP test, does that work as expected? |
I have the same issue. Tried multiple OS servers with latest version of iperf3 with same result from multiple clients using Windows or Linux. There is no local firewall at either end filtering UDP traffic. The TCP test works as expected. Is this a known issue with iperf3?
|
There are no well-known issues with UDP tests, at least of this level of breakage, in any version of iperf3. I just ran this test with a MacOS client, FreeBSD server:
For those of you having this problem, do you know how to use tcpdump to examine the packets arriving on the server? That would at least help narrow down where the problem is, or isn't. I really don't think this is an iperf3 bug, since I can't recreate this problem and if we had such a critical flaw. I'd have received a flood of bug reports by now. |
I am using an older version of iperf3 (iperf 3.1.3), and I can reproduce the issue for when there is IP fragmentation between Client / Server. In Iperf version 3.1.3, it seems the default UDP datagram size is set to 8192 bytes, which causes IP packet to fragment in my env. For those seeing the behaviour could you tweak the UDP datagram length, on the client, to a smaller value ( with the --length option, with whatever value suits your env) for verification - My results below: Repro (with default length):Setup:
Result:
Using tcpdump have verified that the server does see the UDP datagrams even when iperf reports 0.0Bytes (Although the IP packets are fragmented, they do reach the server). Repro (with length set to 1200 bytes)Setup:
Result:
|
@nnaukwal You're quite right about fragmentation and the default IP send size in older versions of iperf3. That's why we changed the default starting in iperf-3.1.5, although as you correctly pointed out the UDP payload size can be changed with the I'm starting to think there isn't much more we can do with this issue. I suppose if this were my setup I'd do packet captures on the server side (as I recommended earlier) and try varying the |
@GF-Huang : That's not the official iperf3 site. The official iperf3 Web site is https://software.es.net/iperf and we have never made binaries available any platform, only source code. A question such as this probably be asked in the Discussions...this is a issue that's been closed for two years. |
I am trying to measure the maximum throughput with iperf3. In UDP mode, the server shows this:
However the client shows this:
The command that I issued on the server is:
iperf3 -B db03::2 -s -6
And the command that I issued on the client is:
iperf3 -c db03::2 -6 -u
This is the result of iperf3 --version:
The text was updated successfully, but these errors were encountered: