nick black

I've added a '-Q' '--quantum' option to iperf2 in our deployments, enforcing a time limit on client connections, after which they will be terminated by the server. This was necessary to keep our singly-threaded iperf from being tied up by an unresponsive client. I doubt that this patch will be accepted into iperf2, but you're welcome to take it. If merged, please credit Nick Black of Luma, Inc. diff -ur iperf-2.0.9/include/Settings.hpp dankperf-2.0.9/include/Settings.hpp --- iperf-2.0.9/include/Settings.hpp...

The cause of the nmap -sV memory pressure is the following in Settings_GenerateClientSettings: (client)->mThreads = ntohl(hdr->numThreads); which is then used to allocate client->mThreads items a bit later. With iperf2 2.0.9 and nmap 7.60, this results in a mThreads value of 1929256211 and a rapid OOM. Note that this happens even if --disable-threads is used with configure. On our builds, I've added the following: --- iperf-2.0.9-orig/src/Settings.cpp 2017-08-31 15:33:53.583021939 -0400 +++ iperf-2.0.9/src/Settings.cpp...

In at least version 2.0.9 of iperf2 (taken from current git), there's a mismatched new[]/delete. The delete also needs to be a delete[]. This shows up immediately in valgrind when run with memcheck. The fix is pretty simple: @@ -586,7 +589,7 @@ mExtSettings->mBindPort = atoi(results); } } - delete parsedopts; + delete[] parsedopts; if (mExtSettings->mLocalhost == NULL) { mExtSettings->mLocalhost = new char[ strlen( optarg ) + 1 ]; strcpy( mExtSettings->mLocalhost, optarg ); If this patch is included,...