#400 iperf2 2.2.2: UDP parallel streams (-P > 1) repeatedly create server connections with packet sizes below 40 bytes

[Vladyslav Korchuk]

Environment

• iperf2 version: 2.2.2, built from source
• OS: Ubuntu 20.04.6 LTS on both client and server
• Both endpoints are Linux virtual machines
• Protocol: UDP
• Test configuration: multiple parallel streams with small UDP payload sizes

Problem description

After upgrading from iperf2 2.1.9 to 2.2.2, I encountered an issue when running UDP throughput tests with multiple parallel streams (-P) and small packet sizes (-l).

When the UDP payload size is less than 40 bytes and -P 2 or higher is used, the server continuously reports new connections. The stream IDs keep increasing, even though the client is using the same UDP source ports.

The problem is reproducible at low traffic rates.

Steps to reproduce

Server:

iperf -s -u -i 1

Client:

iperf -c 192.168.0.232 -u -i 1 -t 30 -b 1m -l 39 -P 2

Actual result

The server repeatedly prints connection messages with increasing stream IDs, often referencing the same client source ports:

[1719] local 192.168.0.232 port 5001 connected with 192.168.0.231 port 42896
[1720] local 192.168.0.232 port 5001 connected with 192.168.0.231 port 51244
...
[1731] local 192.168.0.232 port 5001 connected with 192.168.0.231 port 42896
[1732] local 192.168.0.232 port 5001 connected with 192.168.0.231 port 51244

The number of reported streams increases far beyond the configured number of parallel streams.

Expected result

The server should recognize the two UDP streams and process their packets without repeatedly creating new logical connections.

Additional tests

Configuration	Result
-l 16 -P 1	Works
-l 18 -P 1	Works
-l 32 -P 1	Works
-l 39 -P 1	Works
-l 32 -P 2	Fails
-l 36 -P 2	Fails
-l 38 -P 2	Fails
-l 39 -P 2	Fails
-l 40 -P 8	Works
-l 39 -P 8	Fails

Workaround

Adding -C (--compatibility) on the client only resolves the issue. The server does not require -C.

For example:

iperf -s -u -i 1

iperf -c 192.168.0.232 -u -i 1 -t 30 -b 10m -l 18 -P 8 -C

This test runs without the repeated connection messages.

Previous version

Our existing UDP throughput tests using -l 18 -P 8 worked with iperf2 2.1.9 without requiring -C.

Possible cause

The exact 40-byte threshold and the fact that client-side -C resolves the problem suggest that it may be related to the initial UDP control/header exchange when multiple parallel streams are used.

However, I have not confirmed the root cause.

Thank you!