Open domdorn opened 1 year ago
I am not familiar with the routing implemented by the IP stack, especially not on MacBook, but it seems reasonable that the IP stack will realize that 10.0.0.216 is a local machine address, so will rout the data internally instead of sending the data out of the machine.
Did you try using two different MacBooks to make sure that iperf3 binding is working o.k.?
I had the same issue with Ubuntu 24.04 when trying to test a cable between two ethernet ports on the same compuer. Seems like Linux force-optimizes the network route even when explicitly binding to two different network interfaces. Windows 10 did no such thing, so I used Windows for all my tests.
Context
Version of iperf3: iperf 3.13 (cJSON 1.7.15)
Hardware: MacBook Pro Intel Late 2019 i9-9900, 64gb ram
Operating system (and distribution, if any): Darwin MacBook-Pro-5.home 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:08:47 PST 2022; root:xnu-8792.61.2~4/RELEASE_X86_64 x86_64
Optional features available: sendfile / zerocopy, support IPv4 don't fragment
Bug Report
Expected Behavior when using two network interfaces, and explicitely binding server and client to one of them, iperf3 sends data over the network, so is limited by the speed of the underlying switch (e.g. 1GBit).
Steps to Reproduce given two network interfaces, one bound to 10.0.0.170 and one to 10.0.0.216 1.) start the server
iperf3 -B 10.0.0.216 -s
2.) start the clientiperf3 -B 10.0.0.170 -c 10.0.0.216
Actual Behavior iperf3 does not send over the network but over the local bus (thunderbolt).