You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
/* UDP "connect" message and reply (textual value for Wireshark, etc. readability - legacy was numeric) */
#define UDP_CONNECT_MSG 0x36373839 // "6789" - legacy value was 123456789
#define UDP_CONNECT_REPLY 0x39383736 // "9876" - legacy value was 987654321
#define LEGACY_UDP_CONNECT_REPLY 987654321 // Old servers may still reply with the legacy value
but it is too late. I don't think this can be fixed with full backward compatibility. Probably, we need to introduce new magic numbers defined in network byte-order, and eventually switch to them.
The text was updated successfully, but these errors were encountered:
Context
Version of iperf3:
iperf 3.15 (cJSON 1.7.15)
as well as github masterHardware:
x86 v.s. big-endian arm/aarch64
Operating system (and distribution, if any):
NetBSD 10.0_RC1
Other relevant information (for example, non-default compilers, libraries, cross-compiling, etc.):
N/A
Bug Report
Actual Behavior
iperf3 -u -c
fails for server with opposite byte-order.Steps to Reproduce
server-side:
client-side:
This is because client and server exchange 4-byte magic numbers,
UDP_CONNECT_MSG
andUDP_CONNECT_REPLY
in host byte-order (https://github.com/esnet/iperf/blob/master/src/iperf.h#L455C1-L458C97) :They should have been defined with
ntohl(3)
:but it is too late. I don't think this can be fixed with full backward compatibility. Probably, we need to introduce new magic numbers defined in network byte-order, and eventually switch to them.
The text was updated successfully, but these errors were encountered: