-B option is not processed correctly

[kyanite]

-B, --bind bind to a specific interface or multicast address
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-B option is the client only option from the help information, but still can pass by server mode.

$>/opt/iperf3/bin/iperf3 -s -B 192.168.1.3
iperf3: error - unable to start listener for connections:

---

Server listening on 5201

[bmah888]

Initial findings: There seem to be several problems here. First, in my own testing, it looks like the -B parameter isn't taking effect; I get the same error message originally reported as well as seeing the process bind to the wildcard address (this is on MacOS, I wonder if there is any platform specific behavior at work also).

Second, the -B option is I believe applicable to both the client and server sides. If this is true, the help text is wrong.

Finally, there is no multicast support at all in iperf3, so the mention of multicast addresses is incorrect (if there were multicast support, it would be implemented significantly differently than how iperf3 binds to TCP or UDP ports).

Just for completeness, on what platform was this seen?

[bmah888]

I've looked into this a little bit more. This bug has something to do with iperf3 trying to be smart about auto-detecting the correct address family (i.e. AF_INET vs. AF_INET6). It appears to happen if the argument to the "-B" option resolves to (only) an IPv4 address, for example an IPv4 literal or an FQDN that has only an A record in DNS. It works fine in these cases if you provide a "-4" flag, so I'd say for now use that as a workaround if you need it.

Another facet of this bug is that if you give an argument to -B that has no relation to any interface address on the host at all, iperf3 fails in the same way and binds to the wildcard address, where it really should just die.

Still trying to figure out what the real problem is.

Reports of people trying this on different platforms would be appreciated. I've seen identical behavior on MacOS and FreeBSD.

[kyanite]

I do this on Ubuntu Linux and MacOS. Following is what i think.

1. -B option should applicable to both the client and server sides.
2. $>/opt/iperf3/bin/iperf3 -s -B 192.168.1.3 is still can work but bind to wildcard address.
   The code in main.c as below, it will call iperf_reset_test, so the first time output error, and second time it start iperf correctly but bind to wildcard address.
   main.c
   112 for (;;) {
   113 if (iperf_run_server(test) < 0) {
   114 iperf_err(test, "error - %s", iperf_strerror(i_errno));
   115 fprintf(stderr, "\n");
   116 ++consecutive_errors;
   117 if (consecutive_errors >= 5) {
   118 fprintf(stderr, "too many errors, exiting\n");
   119 break;
   120 }
   121 } else {
   122 consecutive_errors = 0;
   123 }
   124 iperf_reset_test(test);
   125 }
3. In net.c
   109 hints.ai_flags = AI_PASSIVE;
   110 if (getaddrinfo(local, portstr, &hints, &res) != 0)
   111 return -1;

Return socket address structures suitable for a passive open (i.e., a listening
socket). In this case, host should be NULL, and the IP address component
of the socket address structure(s) returned by result will contain a wildcard
IP address (i.e., INADDR_ANY or IN6ADDR_ANY_INIT). (From the linux programming interface)

[bmah888]

So the reason there's an error is that in netannounce(), we convert AF_UNSPEC to AF_INET6. This means that in any case we don't specify an address family, the code would assume that a -B argument was to be treated as an IPv6 address. This broke for the case of specifying an IPv4 literal or an FQDN that only resolved to an IPv4 address.

The previous comment explained why iperf3 would "recover" and bind to the wildcard address...it was calling iperf_reset_test(), which zapped out test->bind_address. It shouldn't do that; a common use case for binding a server to a particular address is because you don't want it to be reachable on all interfaces. That code was updated in revision c7ddeba to fix some memory leaks, but iperf_reset_test() probably shouldn't be trying to clear strings that were originally set via command-line arguments.

I'm not sure why we transmorgify AF_UNSPEC to AF_INET6 in the first place. If I make it not do that, as well as a couple of other minor tweaks, it behaves as I'd expect to see, at least on the server side. I think it works on the client side too but I'm not 100% sure.

The following excerpt from RFC 6724 is probably applicable in some way here:

   Well-behaved applications SHOULD NOT simply use the first address
   returned from an API such as getaddrinfo() and then give up if it
   fails.  For many applications, it is appropriate to iterate through
   the list of addresses returned from getaddrinfo() until a working
   address is found.  For other applications, it might be appropriate to
   try multiple addresses in parallel (e.g., with some small delay in
   between) and use the first one to succeed.

Also Issue #177 is probably related in some way as this is also related to address family selection.

[bmah888]

Something's still not quite right. Now, if the user doesn't give -B and doesn't specify an address family we bind to the IPv4 wildcard address (we shouldn't force IPv4 in this case). I'm trying to sort this out, but if I haven't solved this by the end of today I'm going to temporarily revert the above change.

[bmah888]

This appears to be working correctly now. Closing this issue.

[bmah888]

@i2aaron and @arlake228 have reported some problems with a combination of -B and -w (because setting the window size causes the listening socket used for the control connection to be recreated, and I missed fixing the socket-binding stuff for this case). We're working this out over email; both @i2aaron and I have patches in hand for this.

[bmah888]

Close this for now. I hope we fixed this for good this time.