#22 'iperf -s' exits when client connects with -d flag

[Anonymous]

iperf version 2.0.4 running in server mode exits when a
client connects using the -d (duplex) flag.

To reproduce:

on machine foo, run server:

[somlo@foo]$ iperf -s

on machine bar, run client in duplex mode:

[somlo@bar]$ iperf -c foo -d

What happens:

at the end of the test, the iperf process on machine
foo exits.

What *should* happen:

at the end of the test, the iperf process on machine
should keep running, listening for new connections.

[Jason Frisvold]

Logged In: YES
user_id=1201957
Originator: NO

I can duplicate this as well. Additionally, the -r (tradeoff) flag causes the same behavior.

[Benjamin Low]

Logged In: YES
user_id=120613
Originator: NO

Also occurs with iperf 2.0.3, on OS X 10.5.3 and Linux 2.6.22 and 2.6.21. I tested 2.0.3 and 2.0.4 as the server with client versions 1.7.0, 2.0.2 and 2.0.4 - the server exited with "Waiting for server threads to complete. Interrupt again to force quit." in each case (example run below). iperf 2.0.2 as the server does not exhibit this behaviour (same list of clients). i.e. it seems platform independent (sample of two), confined to the 'server' mode and was introduced after 2.0.2.

Example undesirable run (client is also 2.0.4 on OS X 10.5.3):
$ uname -a
Linux gw 2.6.22-3-686 #1 SMP Mon Nov 12 08:32:57 UTC 2007 i686 GNU/Linux
$ iperf --version
iperf version 2.0.4 (7 Apr 2008) pthreads
$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 10.10.151.251 port 5001 connected with 10.10.151.2 port 49958
------------------------------------------------------------
Client connecting to 10.10.151.2, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 6] local 10.10.151.251 port 52163 connected with 10.10.151.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 101 MBytes 85.1 Mbits/sec
Waiting for server threads to complete. Interrupt again to force quit.
[ 6] 0.0-10.0 sec 105 MBytes 88.2 Mbits/sec
$

This time with 2.0.2:
$ ./src/iperf --version
iperf version 2.0.2 (03 May 2005) pthreads
$ ./src/iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 10.10.151.251 port 5001 connected with 10.10.151.2 port 49959
------------------------------------------------------------
Client connecting to 10.10.151.2, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 6] local 10.10.151.251 port 54551 connected with 10.10.151.2 port 5001
[ 4] 0.0-10.0 sec 53.4 MBytes 44.6 Mbits/sec
[ 6] 0.0-10.0 sec 111 MBytes 93.3 Mbits/sec

(and the server keeps running)

[Nobody/Anonymous]

Following patch fixes the problem:

--- iperf-2.0.4.orig/src/Client.cpp 2008-04-07 22:37:54.000000000 -0400
+++ iperf-2.0.4/src/Client.cpp 2009-01-21 14:10:33.000000000 -0500
@@ -205,14 +205,14 @@
int adjust = 0;

char* readAt = mBuf;

#if HAVE_THREAD
- if ( !isUDP( mSettings ) ) {
- RunTCP();
- return;
- }
+// if ( !isUDP( mSettings ) ) {
+// RunTCP();
+// return;
+// }
#endif

// Indicates if the stream is readable
bool canRead = true, mMode_Time = isModeTime( mSettings );

Not exactly sure why RunTCP() is only considered necessary if threads are available. The
rest of the code inside the Run() method seems perfectly capapble of handling a tcp test,
whether in a threaded environment or not... More on this if I get enough brain cycles to
take a detailed look at RunTCP()

[Joe Chiarelli]

How does one apply this patch?

[Anonymous]

Is the patch suitable for inclusion in the main code tree?

[yasmin kattab]

okay i don't get it how do i solve this bug??..i need to it to run as it should :(