iperf3 -u -c fails for server with opposite byte-order

[rokuyama]

Context

• Version of iperf3:
  iperf 3.15 (cJSON 1.7.15) as well as github master

• Hardware:
  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:

server% uname -p
x86_64
server% iperf3 -s

client-side:

client% uname -p
earmv7hfeb
client% iperf3 -u -c server
Connecting to host server, port 5201
iperf3: error - unable to read from stream socket:

• Possible Solution

This is because client and server exchange 4-byte magic numbers, UDP_CONNECT_MSG and UDP_CONNECT_REPLY in host byte-order (https://github.com/esnet/iperf/blob/master/src/iperf.h#L455C1-L458C97) :

/* 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

They should have been defined with ntohl(3):

#define UDP_CONNECT_MSG ntohl(0x36373839)
#define UDP_CONNECT_REPLY ntohl(0x39383736)

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.

[davidBar-On]

There are already at least PRs with suggested fix for the problem: #1415 (partial solution), #1468, #1564.

[bmah888]

Fixed by PR #1468.