The speed test failed because the address used in the ESt UDP connection was inconsistent.

[Mozartor2]

[root@localhost ~]# iperf3 -v
iperf 3.5 (cJSON 1.5.2)
Linux localhost.localdomain 4.18.0-553.89.1.el8_10.x86_64 #1 SMP Fri Dec 12 10:42:53 UTC 2025 x86_64
Optional features available: CPU affinity setting, IPv6 flow label, SCTP, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing, authentication

[root@localhost ~]# uname -a
Linux localhost.localdomain 4.18.0-553.89.1.el8_10.x86_64 #1 SMP Fri Dec 12 10:42:53 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux


[root@localhost ~]# cat /etc/os-release 
NAME="Rocky Linux"
VERSION="8.6 (Green Obsidian)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.6"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Rocky Linux 8.6 (Green Obsidian)"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:rocky:rocky:8:GA"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
ROCKY_SUPPORT_PRODUCT="Rocky Linux"
ROCKY_SUPPORT_PRODUCT_VERSION="8"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8"

My Host IP Address List：

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:f3:f6:00 brd ff:ff:ff:ff:ff:ff
    altname enp11s0
    inet 10.88.110.10/24 brd 10.88.110.255 scope global noprefixroute ens192
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fef3:f600/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:f3:f6:ec brd ff:ff:ff:ff:ff:ff
    altname enp19s0
    inet 10.98.1.10/24 brd 10.98.1.255 scope global noprefixroute ens224
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fef3:f6ec/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: ens256: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:f3:f6:f6 brd ff:ff:ff:ff:ff:ff
    altname enp27s0
    inet 192.168.122.27/24 brd 192.168.122.255 scope global noprefixroute ens256
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fef3:f6f6/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.155.1.10/24 scope global wg0
       valid_lft forever preferred_lft forever
6: vxlan100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1370 qdisc noqueue master br0 state UNKNOWN group default qlen 1000
    link/ether 6e:f2:be:0d:0e:5e brd ff:ff:ff:ff:ff:ff
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1370 qdisc noqueue state UP group default qlen 1000
    link/ether 6e:f2:be:0d:0e:5e brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.10/24 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::6b0:56da:7f53:2c62/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
8: GsnTun: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 100.0.0.1/16 scope global GsnTun
       valid_lft forever preferred_lft forever
    inet 110.100.0.1/16 scope global GsnTun
       valid_lft forever preferred_lft forever
    inet6 2001:cafe::1/32 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::ebe5:1590:ab5a:dece/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

I started iperf3

iperf3 -s -i 1

Client:
`iperf3 -u -c 10.98.1.10 -i 1 -t 30

aa.zip

-b 30M`

[root@localhost ~]# iperf3 -s -i 1
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

The client initiated a speed test, but the server remained silent as described above.

What we actually observed was that the downlink UDP was using a different network interface card (NIC) on the local machine for transmission, instead of the address specified by the client's -c option.

The problem was resolved after specifying the server address using -B.

The desired outcome was that the -s option would use the address specified by the client's -c option for downlink transmission.

[davidBar-On]

The desired outcome was that the -s option would use the address specified by the client's -c option for downlink transmission.

What do you mean by "-s option would use the address specified by the client's -c option"? The -s is set on the server side while the -c is set on the client side.

Also, can you send the command used with the -B option? (And note that iperf3 version 3.5 is very old version.)

[Mozartor2]

On the server side, the following command is used:
iperf3 -s -i 1
On the client side, the following command is used:
iperf3 -u -c 10.98.1.10 -i 1 -t 30
The server has multiple IP addresses. One of them is a virtual TUN interface named GsnTun, which is used to handle special encapsulation and includes an address pool of 100.0.0.1/24.

On the server side, iperf3 -s -i 1 does not specify which local address to bind to. In theory, this is equivalent to binding to 0.0.0.0:5201.

The client (IP address 100.0.0.2) initiates the throughput test by connecting to 10.98.1.10. After the control negotiation is completed and the test enters the UDP transmission phase, the server does not send downstream UDP traffic using 10.98.1.10:5201 as the source address. Instead, it uses 100.0.0.1:5201 as the source address.

However, when the server side explicitly forces the bind address using the -B option to bind to 10.98.1.10, the issue does not occur.

[davidBar-On]

Thanks for the explanation. It seems that there was already an attempt to fix this issue by PR #1452 (note that the PR is quite old and still open, with no comments about whether it is considered to be merged.)

[Mozartor2]

Thank you very much!