FreeBSD: iperf3 -s only accepts IPv6 connections

[GoogleCodeExporter]

This is a placeholder for observed behavior running the iperf server on FreeBSD 
(observed on 10.0-RC2).  It only accepts connections via IPv6, not via IPv4.

I have a pretty good idea what the problem is.  Writing this as a placeholder 
so we can discuss this in an ongoing project discussion.  I'll write more 
details in a bit.

Original issue reported on code.google.com by bmah@es.net on 18 Dec 2013 at 9:56

[GoogleCodeExporter]

Original comment by bltier...@es.net on 18 Dec 2013 at 9:59

• Added labels: Milestone-3.0-Release

[GoogleCodeExporter]

OK.  So what's happening is that on FreeBSD (10.0-RC2) is we run "iperf3 -s" 
and clients can only connect to it via IPv6.  To get IPv4 connections, we need 
"iperf3 -s -4" (which of course disables IPv6 connections).  On Linux (CentOS 
6.5) and MacOS (10.8.5) we get the expected behavior, which is that "iperf3 -s" 
allows both IPv4 and IPv6 connections.

The differing behavior seems to be that FreeBSD by default doesn't allow IPv4 
mapped addresses on IPv6 sockets, whereas (by experimentation) Linux and OS X 
both do.  There is a setsockopt(IPV6_V6ONLY) call in netannounce() that is 
supposed to allow the use of mapped addresses, however the call appears to fail 
because the level argument to setsockopt() is SOL_SOCKET (incorrect) instead of 
IPPROTO_IPV6 (correct).  The failure is silent because we never check the 
return value from setsockopt().

Fixing the level argument appears to make "iperf3 -s" DTRT on FreeBSD.

Original comment by bmah@es.net on 18 Dec 2013 at 10:34

[GoogleCodeExporter]

Fixed in d7e0c1445c0a.

Lightly tested on FreeBSD, this seems to fix the problem.  No regressions 
observed on Linux or MacOS X (same platforms as reported above).

Original comment by bmah@es.net on 18 Dec 2013 at 11:29

• Changed state: Fixed