From [email protected] on December 04, 2011 19:49:46

Now, I have a Macintosh with OS X 10.5. I downloaded the source file iperf-3.0b4.tar.gz . I attempted to compile it with the GCC 4.0.1. The compile process failed. What steps will reproduce the problem? 1. Extract iperf-3.0b4.tar.gz to a directory on Mac OS X Darwin.
2. As the README says, do ./configure and make.
3. Output from the configure and make is posted below for your information. What is the expected output? What do you see instead? I expected that the source was compiled into a binary executable. But I couldn't see any binary executable. Some error message from the compiling process appeared. It is posted below. What version of the product are you using? On what operating system? I downloaded the iperf-3.0b4.tar.gz file. I compiled it on Mac OS X 10.5 using GCC 4.0.1. Please provide any additional information below. Output from ./configure:
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... config/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking build system type... i386-apple-darwin9.8.0
checking host system type... i386-apple-darwin9.8.0
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for ranlib... ranlib
checking whether ln -s works... yes
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld
checking if the linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -p
checking the name lister (/usr/bin/nm -p) interface... BSD nm
checking the maximum length of command line arguments... 196608
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload object files... -r
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... (cached) ranlib
checking command to parse /usr/bin/nm -p output from gcc object... ok
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin9.8.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for ANSI C header files... (cached) yes
checking for uuid_create... no
checking for uuid_generate... yes
checking uuid.h usability... no
checking uuid.h presence... no
checking for uuid.h... no
checking uuid/uuid.h usability... yes
checking uuid/uuid.h presence... yes
checking for uuid/uuid.h... yes
checking for an ANSI C-conforming const... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating src/config.h
config.status: executing depfiles commands
config.status: executing libtool commands

Output from make:
Making all in src
make all-am
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT iperf_api.o -MD -MP -MF .deps/iperf_api.Tpo -c -o iperf_api.o iperf_api.c
mv -f .deps/iperf_api.Tpo .deps/iperf_api.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT iperf_error.o -MD -MP -MF .deps/iperf_error.Tpo -c -o iperf_error.o iperf_error.c
mv -f .deps/iperf_error.Tpo .deps/iperf_error.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT iperf_client_api.o -MD -MP -MF .deps/iperf_client_api.Tpo -c -o iperf_client_api.o iperf_client_api.c
mv -f .deps/iperf_client_api.Tpo .deps/iperf_client_api.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT iperf_server_api.o -MD -MP -MF .deps/iperf_server_api.Tpo -c -o iperf_server_api.o iperf_server_api.c
mv -f .deps/iperf_server_api.Tpo .deps/iperf_server_api.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT iperf_tcp.o -MD -MP -MF .deps/iperf_tcp.Tpo -c -o iperf_tcp.o iperf_tcp.c
mv -f .deps/iperf_tcp.Tpo .deps/iperf_tcp.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT iperf_udp.o -MD -MP -MF .deps/iperf_udp.Tpo -c -o iperf_udp.o iperf_udp.c
mv -f .deps/iperf_udp.Tpo .deps/iperf_udp.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT iperf_util.o -MD -MP -MF .deps/iperf_util.Tpo -c -o iperf_util.o iperf_util.c
mv -f .deps/iperf_util.Tpo .deps/iperf_util.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT locale.o -MD -MP -MF .deps/locale.Tpo -c -o locale.o locale.c
mv -f .deps/locale.Tpo .deps/locale.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT net.o -MD -MP -MF .deps/net.Tpo -c -o net.o net.c
mv -f .deps/net.Tpo .deps/net.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT tcp_info.o -MD -MP -MF .deps/tcp_info.Tpo -c -o tcp_info.o tcp_info.c
mv -f .deps/tcp_info.Tpo .deps/tcp_info.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT tcp_window_size.o -MD -MP -MF .deps/tcp_window_size.Tpo -c -o tcp_window_size.o tcp_window_size.c
mv -f .deps/tcp_window_size.Tpo .deps/tcp_window_size.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT timer.o -MD -MP -MF .deps/timer.Tpo -c -o timer.o timer.c
mv -f .deps/timer.Tpo .deps/timer.Po
gcc -DHAVE_CONFIG_H -I. -...

Original issue: http://code.google.com/p/iperf/issues/detail?id=43

From richih.mailinglist on August 06, 2010 14:06:33

Explaination of new feature If --uuid is specified, every time a client connects to a server, client and server send a UUID to each other:

• If --uuid-string is specified and valid, this string is used
• If /etc/hostuuid exists and the content is valid (a single UUID with newlines and whitespaces after the UUID ignored), this string is used
• If none of the above applies, a UUID version 1 or 4 is generated. Default is version 1. Can be overridden by --uuid-version

Version 1 is not cryptographically secure, but it would help a lot in determining which connection came from where; see [1].

Both client and server display their own and the partner's UUID and save it to the log file in [2].

For every transmission, a UUID is generated by the client and sent to the server. Both client and server display this UUID. Justification of new feature Cross-referencing of log files. Long-term storage of results, etc.

Richard

PS: I can supply a perl script to handle /etc/hostuuid and I still hope to get this into Debian proper. We use it internally and it saves a lot of work to have hostuuids.

[1] http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Definition [2] http://code.google.com/p/iperf/issues/detail?id=24

Original issue: http://code.google.com/p/iperf/issues/detail?id=25

From eduade.2001 on May 22, 2011 22:43:49

What steps will reproduce the problem? 1.server execute command - iperf3 -u -s -i 1
2.client execute command - iperf3 -c ip_address -u
3.re-running command - iperf3 -c ip_address -u after previous execution on client causes error "Unable to read from stream socket : Connection refused What is the expected output? What do you see instead? should provide output for latency and loss on UDP tests What version of the product are you using? On what operating system? Ubuntu server version 11 64bit Please provide any additional information below.

Attachment: error.png

Original issue: http://code.google.com/p/iperf/issues/detail?id=41

From jdugan.esnet on December 10, 2009 16:43:22

Explaination of new feature make sure all test related i/o uses select Justification of new feature cleaner, less error prone

Original issue: http://code.google.com/p/iperf/issues/detail?id=18

From pcrotwell on August 31, 2010 13:27:01

What steps will reproduce the problem? 1. iperf3 -s -u 2. 3. What is the expected output? What do you see instead? crotwell$ bin/iperf3 -s -u
parameter error: Some option you are trying to set is client only What version of the product are you using? On what operating system? 3.0b4
linux Please provide any additional information below. Same problem with variations on --server and --udp

Docs seem to indicate that -u can be used with -s

Original issue: http://code.google.com/p/iperf/issues/detail?id=31

From robkih on March 25, 2011 07:05:56

Explaination of new feature:
Is there any way to implement a feature where iperf loops a
pattern given in a file rather than just sending the file content once, as in Iperf2 with the "-F" option. Justification of new feature I'm working with systems that are able to compress packets and I believe this could be a useful feature of Iperf.

Original issue: http://code.google.com/p/iperf/issues/detail?id=39

From jdugan.esnet on July 20, 2010 10:03:17

Richard Hartmann [email protected] suggested:

One follow-up: It would be nice if the iperf server could set
DSCP/TOS bits, as well. If ACKs are shaped away, things start
to suck.

I would envision two modes:

1. -S for servers: Set default DSCP value for all outgoing packets

which is overridded by

2. If you receive a packet with DSCP bit vector foo, set the same
   for replies to that packet/client.

I'd like to verify that #2 is good netiquette before implementing it. However, #1 should definitely be implemented and be part of the client-server parameter exchange.

Original issue: http://code.google.com/p/iperf/issues/detail?id=22

From edvinas.stunzenas on September 05, 2012 08:11:18

By default ARM processors typically use unsigned char for char type. That why signed char use must be forced.
I used arm-linux-gcc-4.2.1 compiler.

Submitting patch for this problem to solve:

diff -r dafbddb0e039 src/Makefile.in
--- a/src/Makefile.in Mon Aug 20 14:35:58 2012 -0700
+++ b/src/Makefile.in Wed Sep 05 18:08:55 2012 +0300
@@ -266,7 +266,7 @@

Specify the sources and various flags for the iperf binary

iperf3_SOURCES = main.c
-iperf3_CFLAGS = -g -Wall
+iperf3_CFLAGS = -g -Wall -funsigned-char
iperf3_LDADD = libiperf.a
iperf3_LDFLAGS =

Tested with:
arm-linux-gcc-4.2.1
mipsel-linux-gcc-4.1.2

Original issue: http://code.google.com/p/iperf/issues/detail?id=49

From bltierney on July 16, 2009 10:38:15

The 'burst mode' in the new version of nuttcp sounds useful.

Here is the description from Chris Tracy:

"nuttcp has a new option that allows you
to specify that traffic is sent in bursts, instead of a nice smooth
transfer. This is extremely useful in determining if a switch has
enough buffering to handle a 10GigE -> GigE translation (e.g. in
general, most cheaper 1U switches cannot handle this, while bigger
modular switches do have the buffering to handle it). I recently ran
into this issue when sending from a host with a 10GigE NIC using a
bursty application (UltraGrid) and I ended up with 250Mbps (averaged
but extremely bursty) going into a 10GigE port on a 1U switch and only
80Mbps coming out of the GigE port. iperf/nuttcp in standard rate
limit mode set to 250Mbps did not trigger the problem, but nuttcp's
new burst testing mode will reproduce the buffering issue."

See the code at: ftp://ftp.lcp.nrl.navy.mil/u/bill/private/nuttcp-6.3.1-beta2.c to see how
this is implemented.

Original issue: http://code.google.com/p/iperf/issues/detail?id=3

From rightright2 on February 28, 2011 09:28:40

Explaination of new feature want to use iperf3.0 in win7 OS. Justification of new feature use two clients, one is WIN7 os, one is linux(ubuntu)
connect to the same home router and do performance test.

Original issue: http://code.google.com/p/iperf/issues/detail?id=38

From bltierney on August 21, 2010 09:02:23

When I try to build on FreeBSD (www-eng9.es.net), I get this error:

(doing ./configure; make)

/usr/bin/ld: cannot find -lgcc_eh_p

Original issue: http://code.google.com/p/iperf/issues/detail?id=29

From chris.t.tracy on August 24, 2010 11:21:35

It can often be helpful to know the average CPU utilization for both the sending and receiving hosts during an iperf, to determine if one side is CPU-bound.

As an example, nuttcp reports CPU utilization on the summary line at the end of a transfer, e.g. "%TX" and "%RX" in the output below:

70908.4355 MB / 60.06 sec = 9903.3007 Mbps 19 %TX 43 %RX 0 retrans 0.10
msRTT

(Of course, when you run nuttcp in UDP mode, it is expected that the TX side will go to 100%...)

Original issue: http://code.google.com/p/iperf/issues/detail?id=30

From jdugan.esnet on December 09, 2009 22:59:13

Explaination of new feature use netlogger like messages to report the results from server to client. Justification of new feature makes things easier to parse locally without messing with fixed length packet formats

Original issue: http://code.google.com/p/iperf/issues/detail?id=15

From andre.gomes.pt on April 15, 2011 13:48:22

Explaination of new feature An option to set the Flow Label field in the IPv6 header for an outgoing stream on the client side. Justification of new feature To permit the testing of IPv6 QoS implementations based on the Flow Label field.

Original issue: http://code.google.com/p/iperf/issues/detail?id=40

From kennethwebber on August 11, 2010 14:45:48

Explaination of new feature Support for Multicast testing. Justification of new feature A lot of video is multicast and has QOS implication that would desire testing.

Original issue: http://code.google.com/p/iperf/issues/detail?id=27

From jdugan.esnet on December 09, 2009 22:57:33

Explaination of new feature simplify the API by defining a single callback for periodic use. This can be used for intermediate
results calculation, reporting, etc.. Justification of new feature

Original issue: http://code.google.com/p/iperf/issues/detail?id=14

From bltierney on September 06, 2012 14:54:16

For testing in firewalled environments, it would be useful to be able to run iperf over a single port (including port 80)

Original issue: http://code.google.com/p/iperf/issues/detail?id=50

From castrogomez83 on February 23, 2012 03:29:23

What steps will reproduce the problem? 1.iperf -s -u -f k -w 122.0K -l 1.0K
2.iperf -u -c x.x.x.x -f k -w 122.0K -l 1.0K -b 50.0K -t 30 3. What is the expected output? What do you see instead? a correctly UDP test. the transmissionis interrupted during 8-10 sec What version of the product are you using? On what operating system? iperf 2.0.4. Debian GNU/Linux 5.0 Please provide any additional information below. i have tested with differents values of -w, -l, -b...but the transmission is always interrupted...

Attachment: jperf_image.bmp

Original issue: http://code.google.com/p/iperf/issues/detail?id=44

From jcm293 on July 16, 2009 06:53:00

There is an existing parameter to set the qos bits on ipv4
packets. This should be supported in ipv6 as well.

Original issue: http://code.google.com/p/iperf/issues/detail?id=2

From sethdelliott on July 28, 2010 08:59:58

Aaron Brown [email protected] suggested:

Currently the code defaults to the AF_INET domain (IPv4). The default should be AF_UNSPEC.

Things to change:
1.) Set the default to AF_UNSPEC
2.) Change support code to reflect this change
3.) Add an IPv4 flag (-4) for specifying an IPv4 iperf test

Original issue: http://code.google.com/p/iperf/issues/detail?id=23

From marko06 on September 04, 2012 08:24:06

What steps will reproduce the problem? 1. Raspberry PI & Debian wheezy installed on it.
2. Download iperf3 and compile it.
3. Fix: https://groups.google.com/forum/?fromgroups=#!topic/iperf-dev/MzL9zMzZ1Co 4. Run "./iperf3 -s" on one tty and "./iperf3 -c localhost -t 2" on the other. What is the expected output? What do you see instead? System call accept does not accept connection and stays blocked:

root@rpitc:~/iperf-3.0b4# ./src/iperf3 -s

Server listening on 5201

Staring iperf_accept
Before accept call.
^CAfter accept call. What version of the product are you using? On what operating system? Raspberry PI:
root@rpitc:~# uname -a
Linux rpitc 3.2.27-rpitc+ #3 PREEMPT Thu Aug 30 10:19:18 CEST 2012 armv6l GNU/Linux

root@rpitc:~# cat /etc/issue.net
Debian GNU/Linux wheezy/sid Please provide any additional information below. Tcpdump output in raspberry_pi txt file.

Attachment: raspberry_pi

Original issue: http://code.google.com/p/iperf/issues/detail?id=48

From geekboy on April 13, 2010 10:03:38

Explaination of new feature It would be helpful to be able to send a known number of packets at a known rate, so that the
packets can be counted at the far end. The idea is to be able to measure the ability of the
network to handle bursty behavior without requiring that the network devices be able to count
packets reliably (Juniper routers can, most others cannot).

This is similar to the burst mode enhancement request.

It might be desirable to have a flag to prime the flow cache of the routers along the path (routers
with a punt-first architecture typically rely on the TCP handshake to get the hardware forwarding
primed, so a big burst out of the blue might experience loss that a non-synthetic TCP stream
might not experience). The counting mechanism would have to take these "priming packets" into
consideration.

Original issue: http://code.google.com/p/iperf/issues/detail?id=19

From [email protected] on April 03, 2012 13:37:50

A link on the following pages back to this project would be useful: http://iperf.sourceforge.net/ http://sourceforge.net/projects/iperf/

Original issue: http://code.google.com/p/iperf/issues/detail?id=46

From cfxchenfangxian on August 09, 2012 21:02:45

What steps will reproduce the problem? 1.server execute below command:
iperf -s -u
2.client execute below command:
iperf -u -c 10.10.21.188 -i 1 -l 5K -b 1000M -t 10000000 -P 10 -d 3. What is the expected output? What do you see instead? when start testing, network card load remaining 96%, but when the tests to seven or eight hours after，the network card load down to 0%。I don't know why happen it。 What version of the product are you using? On what operating system? iperf version 2.0.5 (08 Jul 2010) pthreads.
CentOS release 5.2 (Final) Please provide any additional information below. the network card information as belows:
class: NETWORK
bus: PCI
detached: 0
device: eth0
driver: e1000e
desc: "Intel Corporation 82573E Gigabit Ethernet Controller (Copper)"
network.hwaddr: 00:15:17:21:87:e4
vendorId: 8086
deviceId: 108c
subVendorId: 8086
subDeviceId: 348f
pciType: 1
pcidom: 0
pcibus: 3
pcidev: 0

pcifn: 0

[root@hh iperf-2.0.5]# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbag
Wake-on: g
Current message level: 0x00000001 (1)
Link detected: yes

Any help is appreciated, thanks. :)

Best regards,

chenfangxian

Original issue: http://code.google.com/p/iperf/issues/detail?id=47

From jdugan.esnet on December 09, 2009 22:44:25

Explaination of new feature to allow maximum flexibility implement a callback per state change
this will allow much cleaner separation of library from the tool

Original issue: http://code.google.com/p/iperf/issues/detail?id=8

From richih.mailinglist on August 06, 2010 13:49:48

Explaination of new feature -L or --log-file will save all data to a log file.
iperf will quit with an error if the target file exists unless -A or --append is specified.
Both a client & server option. Justification of new feature I need to keep logs, sometimes.

Original issue: http://code.google.com/p/iperf/issues/detail?id=24

From jdugan.esnet on December 09, 2009 22:46:57

Explaination of new feature use the primitives in queue.h rather than homegrown Justification of new feature more standard, clearer, less bug prone

Original issue: http://code.google.com/p/iperf/issues/detail?id=10

From jdugan.esnet on July 21, 2009 13:07:34

Create random payload.

This makes the data more like real traffic. In particular repetitive patterns might be compressed by
some devices thus skewing results.

Original issue: http://code.google.com/p/iperf/issues/detail?id=4

From raghubec on February 07, 2011 04:40:26

What steps will reproduce the problem? 1. Install RHEL6.0 x86_64 bit OS. Gunzip,untar iperf files
2. Do ./configure, you get library files not found or ./congure throws "newly created files is older than distrubited files" Check your system clock
3. Unable to proceed further. What is the expected output? What do you see instead? Installation should go through fine as with previous version of iperf2xx What version of the product are you using? On what operating system? Iperf-3.0b4.tar Please provide any additional information below. Package should come with all the required lib files and should synchronise properly.

Original issue: http://code.google.com/p/iperf/issues/detail?id=37

From jdugan.esnet on December 09, 2009 23:00:17

Explaination of new feature stop a running test. Justification of new feature it's useful!

Original issue: http://code.google.com/p/iperf/issues/detail?id=16

From ryousei on May 20, 2010 19:46:46

With gethostbyname(3), you should use herror(3) for error reporting.

Please find an attached patch file.

Attachment: iperf3.herror.diff

Original issue: http://code.google.com/p/iperf/issues/detail?id=20

From jdugan.esnet on November 30, 2010 18:26:51

Explaination of new feature add things like the version number of iperf and possibly uname(1) type info. Justification of new feature Many/most Iperf bug reports include Iperf output but frequently omit the version number and/or OS.

Original issue: http://code.google.com/p/iperf/issues/detail?id=35

From joe.vijay on June 14, 2010 07:58:52

I am trying to make this compile in Solaris 1o for SPARC using the Sun Studio compiler ver. 12 and i get the following error for 'errno'

------------------------< cut here> ------------------------------
$ gmake
cc -g -c -o main.o main.c
"main.c", line 272: warning: statement not reached
cc -g -c -o iperf_api.o iperf_api.c
"iperf_api.c", line 805: warning: statement not reached
cc -g -c -o iperf_server_api.o iperf_server_api.c
"iperf_server_api.c", line 179: warning: improper pointer/integer combination: o
"iperf_server_api.c", line 195: warning: improper pointer/integer combination: o
cc -g -c -o iperf_tcp.o iperf_tcp.c
cc -g -c -o iperf_udp.o iperf_udp.c
cc -g -c -o timer.o timer.c
"timer.c", line 120: undefined symbol: errno
cc: acomp failed for timer.c
gmake: *** [timer.o] Error 1

$ CC -V
CC: Sun C++ 5.10 SunOS_sparc 128228-08 2010/04/21
Usage: CC [ options ] files. Use 'CC -flags' for details
---------------------------< cut here >-----------------------------

Original issue: http://code.google.com/p/iperf/issues/detail?id=21

From jdugan.esnet on December 09, 2009 22:46:03

Explaination of new feature allow a library user to pass in a fd rather than having the stream functions allocate it.

Original issue: http://code.google.com/p/iperf/issues/detail?id=9

From jdugan.esnet on July 27, 2009 15:52:21

the TCP_INFO getsockopt provides information about the current state of a TCP session. This
information can give significant insight into TCP performance issues.

Original issue: http://code.google.com/p/iperf/issues/detail?id=5

From kennethwebber on August 11, 2010 14:42:19

What steps will reproduce the problem? 1. On Server A /opt/iperf3 --client 10.10.205.13 --port 55525 --udp --debug
2. On Server B /opt/iperf3 --format k --port 55525 --udp --server -V 3. What is the expected output? What do you see instead? ON A:
Connecting to host 10.10.205.13, port 55525

ON B:
Accepted connection from 10.10.24.14, port 37180
Cookie: e47a1dcd-70b4-44b5-9411-e59ade43f579 What version of the product are you using? On what operating system? [root@horoscope opt]# /opt/iperf3 -v
iperf version 3.0-BETA4 (2 Aug 2010) Please provide any additional information below. When I remove --udp it works just fine.

Original issue: http://code.google.com/p/iperf/issues/detail?id=26

From jdugan.esnet on December 09, 2009 22:51:47

Explaination of new feature when a signal is received in a send or recv it will cause a partial send/recieve.
add an element to iperf_stream to allow a signal handler to decide how streams should handle the
interrupted call -- continue reading or exit. Justification of new feature

Original issue: http://code.google.com/p/iperf/issues/detail?id=11

From jdugan.esnet on June 16, 2009 15:05:45

Presently we set the window size to DEFAULT_TCP_BUFSIZE.

This has two issues:

1. it overrides the system default implicitly
2. it may prevent the system's auto tuning from working

Instead we should set socket_snd_bufsize and socket_rcv_bufsize to zero by default (probably in
iperf_defaults()). Then when it comes time to set the socket_snd_bufsize and socket_rcv_bufsize
only set it if it isn't zero.

for the present iperf the tool should use -w to set both socket_snd_bufsize and
socket_rcv_bufsize, but in the long term we probably want options to set the individually.

Original issue: http://code.google.com/p/iperf/issues/detail?id=1

From jdugan.esnet on December 09, 2009 22:55:09

Explaination of new feature Add IPv6 support Justification of new feature The end is near!

Original issue: http://code.google.com/p/iperf/issues/detail?id=12

From thirumalai.android on October 07, 2010 23:08:45

What steps will reproduce the problem? 1. iperf -S [this will not work on windows XP] 2. 3. What is the expected output? What do you see instead? Should send prioritized output but i didn't see this on my sniffer trace. What version of the product are you using? On what operating system? 2.0.5 compiled using cygwin. windows XP OS Please provide any additional information below.

Original issue: http://code.google.com/p/iperf/issues/detail?id=34

From tru64.freak on December 09, 2010 08:04:11

What steps will reproduce the problem? 1. iperf3 -s
2. iperf3 -c server -u 3. What is the expected output? What do you see instead? no idea what to expect. What I get is:
client:
Connecting to host server, port 5201
error: Unable to read from stream socket: Connection refused

server:

Server listening on 5201

Accepted connection from 10.1.1.2, port 1840
Teh client has unexpectedly close the connection.
--------------- What version of the product are you using? On what operating system? iperf verion 3.0-BETA4 (2 Aug 2010)
OS: Tru64 v5.1 Please provide any additional information below. it is very disappointing that UDP does not work. As UDP is unreliable, and there is no compensation for packet loss/corruption as compared to TCP, it can be extremely useful in diagnosing connections that have problems.
It's a shame you haven't fixed this bug already.

Original issue: http://code.google.com/p/iperf/issues/detail?id=36

From jdugan.esnet on December 09, 2009 22:43:15

Explaination of new feature currently the library code exits rather than signalling an error condition Justification of new feature the library shouldn't exit arbitrarily

Implementation Plan

add an error member to the iperf_stream struct to hold per stream errors
define error codes for each distinct error condition
similar to perror in spirit

Original issue: http://code.google.com/p/iperf/issues/detail?id=7

From richih.mailinglist on March 27, 2012 08:49:06

-d evaluates if -c is set before all option parsing is done.

This means that

iperf -dc host

will not start a dual test while

iperf -c host -d

does; obviously this behavior is undesirable.

host1:~% iperf -dc host2

WARNING: option -d is not valid for server mode

Client connecting to host2, TCP port 5001

TCP window size: 16.0 KByte (default)

[ 3] local host1 port 42220 connected with host2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 376 MBytes 315 Mbits/sec

host1:~% iperf -c host2 -d

Server listening on TCP port 5001

TCP window size: 85.3 KByte (default)

Client connecting to host2, TCP port 5001

TCP window size: 63.1 KByte (default)

[ 5] local host1 port 42221 connected with host2 port 5001
[ 4] local host1 port 5001 connected with host2 port 57550
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-10.0 sec 98.7 MBytes 82.8 Mbits/sec
[ 4] 0.0-10.0 sec 978 MBytes 817 Mbits/sec
host1:~%

Original issue: http://code.google.com/p/iperf/issues/detail?id=45

From jdugan.esnet on December 09, 2009 23:52:24

What steps will reproduce the problem? 1. it's in the code

this is very confusing and potentially evil behavior for a library, needs to be handled at the tool
level.

Original issue: http://code.google.com/p/iperf/issues/detail?id=17

From jdugan.esnet on November 18, 2009 12:47:37

What steps will reproduce the problem? 1. iperf -s -T
2. iperf -c 3. What is the expected output? What do you see instead? Expected TCPINFO results got a segfault Please use labels and text to provide additional information.

Original issue: http://code.google.com/p/iperf/issues/detail?id=6

From jdugan.esnet on December 09, 2009 22:55:50

Explaination of new feature Add windows support Justification of new feature Should be done, but I don't want to do it.

Original issue: http://code.google.com/p/iperf/issues/detail?id=13

From novickivan on September 08, 2010 11:22:05

make[2]: Entering directory `/home/build/inovick/iperf-3.0b4/src'
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT iperf_api.o -MD -MP -MF .deps/iperf_api.Tpo -c -o iperf_api.o iperf_api.c
iperf_api.c:17:23: error: sys/queue.h: No such file or directory
In file included from iperf_api.c:32:

Original issue: http://code.google.com/p/iperf/issues/detail?id=33

From busylee on July 26, 2011 04:11:09

What steps will reproduce the problem? 1. A measurement for download bandwidth is inaccurate.
2. Which difference between with "-R" and without "-R"? What is the expected output? What do you see instead? 1. According to the line configuration, I expected the result for Up and Download bandwidth is each 1Mbps, 0.5Mbps, But the result was follow as,

(Log is captured on the Server, but client is almost same)

Server listening on 5201

Accepted connection from 10.64.180.254, port 56738
[ 5] local 10.64.84.227 port 5201 connected to 10.64.180.254 port 56739
[ ID] Interval Transfer Bandwidth
Sent
[ 5] 0.00-31.05 sec 3.75 MBytes 1.01 Mbits/sec
Received
[ 5] 0.00-31.05 sec 3.50 MBytes 946 Kbits/sec

1. Speaking of the output result both on client and server,
   I cannot recognize the difference between with -R and without -R.
   The result is same.
   I think the results for "Received" had better be removed if without "-R" option. What version of the product are you using? On what operating system? iperf-3.04b, CentOS release 5.6 Please provide any additional information below. Actually I make test-environment asymmetric for up/down link using emulation tool like a 'TC' of linux.

Client -- [TC and NAT enabled LinuxBox] --- Server
Up:1Mbps, Down:0.5Mbps

Original issue: http://code.google.com/p/iperf/issues/detail?id=42

From abisain on September 07, 2010 17:40:20

Explaination of new feature Provide API to remotely control the sender to change traffic pattern. This will allow a user to run at 10mbps UDP for some time and then change to 60mbps on the same udp port. Justification of new feature This allows for showing affect of varying traffic on a system.

Original issue: http://code.google.com/p/iperf/issues/detail?id=32

From kennethwebber on August 11, 2010 14:50:11

Explaination of new feature An option to set the DSCP field in the IP header for an out-going stream on the client side.

On the server side a message if there is any DSCP value. Justification of new feature This will allow for a Network admin to make certain that devices between to points are not removing the QOS.

Original issue: http://code.google.com/p/iperf/issues/detail?id=28