Found that iperf does not set the client socket correctly, which is due
to the order of statements in filling in the socket structure. A patch
has been uploaded to
http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/iperf/patches/04_Iperf_IPv6-Support.diff
which is already integrated into the tarball at
http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/iperf/zip/iperf-2.0.2_DCCP-patched-CBR-continuous.tar.bz2
Test run for DCCPv6 server:
iperf -Vsd
Test run for DCCPv6 client (to dst address `beef::2')
iperf -V -d -c beef::2
In IPv6 the layer-3 header reduces the MPS by an additional 20 bytes. For IPv4,
iperf uses a `magic number' of 1424
bytes which corresponds to the old way of computing MPS. With the new way
(dynamically, after feature negotiation),
the MPS in DCCPv4 can be up to 1440 bytes.
This means that in DCCPv6 the MPS can be maximally 1420 bytes, so that the
`magic number' of 1424 bytes is still too
much unless using jumbo frames. Hence the `-l argument' becomes necessary, i.e.
for a client on a normal Ethernet link:
iperf -V -d -l 1420 -c beef::2
--
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
