iperf3 - Windows Server (-s) mode not supporting multiple UDP streams? [3.17.1] [BUG?]

[jeffsponaugle]

SHORT: It appears that the windows complied version of iPerf3, running on a windows box in server mode, does not correctly work when trying to do multiple UDP streams. This appears to be unique to the windows version in server mode.

[NOTE - Per the FAQ, iperf3 on Windows is UNSUPPORTED, and some options do not work. It is possible this is one of those 'options that does not work']

Reproduction and Comparison:

On a linux or OSX platform:

execute in one terminal session: iperf3 -s
in a second terminal, execute: iperf3 -c localhost

output is as expected.
in a second terminal, execute: iperf3 -c localhost -P2
output is as expected. ( two TCP connections)

in a second terminal, execute: iperf3 -c localhost -u
output is as expected. ( single UDP connection, 1.0Mbit bandwidth)

in a second terminal, execute: iperf3 -c localhost -u -P2
output is as expected. ( two UDP connection, 2.0Mbit bandwidth total).

On a Windows platform (In my case A Windows 11 build, Windows 10 build, and a Server 2016 build)

execute in one command window: iperf3 -s
in a second command window, execute: iperf3 -c localhost
output is as expected.

in a second command window, execute: iperf3 -c localhost -P2
output is as expected. ( two TCP connections)

in a second command window, execute: iperf3 -c localhost -u
output is as expected. ( single UDP connection, 1.0Mbit bandwidth)

in a second command window, execute: iperf3 -c localhost -u -P2
output is a hang of the client with the eventual output:

C:\iperf>iperf3.exe -c localhost -u -P2
Connecting to host localhost, port 5201
[  5] local ::1 port 61786 connected to ::1 port 5201
iperf3: error - unable to read from stream socket: Resource temporarily unavailable

The issue appears to be in the server side windows version, because doing the same client commands from either linux or osx against the windows server version has the same result. It does not appear to be related to using localhost, as it occurs from remote clients against the windows binary in server mode. Running either the server or the client in an administrator command windows makes no difference.

On the Windows side, the firewall is disable on all three machines, and this artifact seems to occur with either local or remote connections. The OSX and Linux versions do not display this behavior in any of my testing, either local, remote, or to each other.

This issue seems to occur with 3.13->3.17, but I have not tested earlier builds. I do not remember seeing this in the past, so it is possible that there could be a Windows related issue, or of course a user (me) related issue. It feels like something blocking UDP, but when running local to local that should not happen.

[jeffsponaugle]

To add to this:

A packet capture from an OSX client to a Windows server. Client command line:

jbs@M1MaxJS linux % iperf3 -c 10.1.30.2 -u -P2
Connecting to host 10.1.30.2, port 5201
[  5] local 10.1.10.129 port 55194 connected to 10.1.30.2 port 5201
iperf3: error - unable to read from stream socket: Resource temporarily unavailable
jbs@M1MaxJS linux % 

Capture:

11:41:55.738906 IP 10.1.10.129.55828 > 10.1.30.2.targus-getdata1: Flags [S], seq 1320758591, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 2465918404 ecr 0,sackOK,eol], length 0
11:41:55.742008 IP 10.1.30.2.targus-getdata1 > 10.1.10.129.55828: Flags [S.], seq 3153855431, ack 1320758592, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 14133467 ecr 2465918404], length 0
11:41:55.742116 IP 10.1.10.129.55828 > 10.1.30.2.targus-getdata1: Flags [.], ack 1, win 2058, options [nop,nop,TS val 2465918408 ecr 14133467], length 0
11:41:55.742157 IP 10.1.10.129.55828 > 10.1.30.2.targus-getdata1: Flags [P.], seq 1:38, ack 1, win 2058, options [nop,nop,TS val 2465918408 ecr 14133467], length 37
11:41:55.747770 IP 10.1.30.2.targus-getdata1 > 10.1.10.129.55828: Flags [P.], seq 1:2, ack 38, win 260, options [nop,nop,TS val 14133472 ecr 2465918408], length 1
11:41:55.747839 IP 10.1.10.129.55828 > 10.1.30.2.targus-getdata1: Flags [.], ack 2, win 2058, options [nop,nop,TS val 2465918414 ecr 14133472], length 0
11:41:55.747986 IP 10.1.10.129.55828 > 10.1.30.2.targus-getdata1: Flags [P.], seq 38:42, ack 2, win 2058, options [nop,nop,TS val 2465918414 ecr 14133472], length 4
11:41:55.748007 IP 10.1.10.129.55828 > 10.1.30.2.targus-getdata1: Flags [P.], seq 42:186, ack 2, win 2058, options [nop,nop,TS val 2465918414 ecr 14133472], length 144
11:41:55.751927 IP 10.1.30.2.targus-getdata1 > 10.1.10.129.55828: Flags [.], ack 186, win 259, options [nop,nop,TS val 14133477 ecr 2465918414], length 0
11:41:55.751928 IP 10.1.30.2.targus-getdata1 > 10.1.10.129.55828: Flags [P.], seq 2:3, ack 186, win 259, options [nop,nop,TS val 14133477 ecr 2465918414], length 1
11:41:55.751977 IP 10.1.10.129.55828 > 10.1.30.2.targus-getdata1: Flags [.], ack 3, win 2058, options [nop,nop,TS val 2465918418 ecr 14133477], length 0
11:41:55.752131 IP 10.1.10.129.55194 > 10.1.30.2.targus-getdata1: UDP, length 4
11:41:55.759233 IP 10.1.30.2.targus-getdata1 > 10.1.10.129.55194: UDP, length 4
11:41:55.761101 IP 10.1.10.129.56359 > 10.1.30.2.targus-getdata1: UDP, length 4
11:42:25.762680 IP 10.1.10.129.55828 > 10.1.30.2.targus-getdata1: Flags [P.], seq 186:187, ack 3, win 2058, options [nop,nop,TS val 2465948428 ecr 14133477], length 1
11:42:25.763008 IP 10.1.10.129.55828 > 10.1.30.2.targus-getdata1: Flags [F.], seq 187, ack 3, win 2058, options [nop,nop,TS val 2465948428 ecr 14133477], length 0
11:42:25.767498 IP 10.1.30.2.targus-getdata1 > 10.1.10.129.55828: Flags [.], ack 188, win 259, options [nop,nop,TS val 14163493 ecr 2465948428], length 0
11:42:25.767500 IP 10.1.30.2.targus-getdata1 > 10.1.10.129.55828: Flags [F.], seq 3, ack 188, win 259, options [nop,nop,TS val 14163493 ecr 2465948428], length 0
11:42:25.767805 IP 10.1.10.129.55828 > 10.1.30.2.targus-getdata1: Flags [.], ack 4, win 2058, options [nop,nop,TS val 2465948433 ecr 14163493], length 0

[davidBar-On]

This is a known issue in iperf3 on Windows. See PR #1163 that is supposed to fix this issue and the issues it is referring to.

I don't know if and when PR #1163 will be merged into iperf3, but if needed you can use that PR's code. I have now rebased it to the latest master branch (3.17.1+).