At 13:46 -0500 11/2/05, Gorman Tom wrote:
Hi Debbie,
Thank you for getting back to me. The version is 1.7.0.
It seemed to be the most recent available on the website for Windows.
I'm doing all my testing on the same VLAN.
One more thing I did not mention: the server does not stop cleanly. It is
always necessary to kill the process. Ctrl/C has no effect in the cmd
window.
It would also be useful to be able to configure the server so it does not
reply, since generally that is the nature of multicast. That would let the
server simply accept the multicasts from our patient monitors, and other
devices as well.
I've included some information that may be of interest to anyone who might
shed some light on the Windows implementation.
Thank you again.
Best regards,
Tom
DRAEGER MEDICAL
Draeger Medical Systems, Inc.
16 Electronics Avenue
Danvers, MA 01923
Tel: +1 978-907-7711
Fax: +1 978-907-6489
>E-mail: Tom.Gorman --at-- draeger.com
###########################################################################
#
#######
The following are snippits of the operations.
Note the absence of the word multicast in the header on the server.
C:\tools>iperf -c 224.127.2.254 -u
------------------------------------------------------------
Client connecting to 224.127.2.254, UDP port 5001
Sending 1470 byte datagrams
Setting multicast TTL to 1
UDP buffer size: 8.00 KByte (default)
------------------------------------------------------------
[884] local 191.1.10.18 port 1049 connected with 224.127.2.254 port 5001
[ ID] Interval Transfer Bandwidth
[884] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec
[884] Sent 893 datagrams
C:\tools>iperf -s -u -B 224.127.2.254
------------------------------------------------------------
Server listening on UDP port 5001
Binding to local address 191.1.10.19
Receiving 1470 byte datagrams
UDP buffer size: 8.00 KByte (default)
------------------------------------------------------------
[900] local 191.1.10.19 port 5001 connected with 191.1.10.18 port 1049
[ ID] Interval Transfer Bandwidth Jitter Lost/Total
Datagrams
[900] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 3.838 ms 0/ 893 (0%)
read failed: Connection reset by peer
read failed: Connection reset by peer
read failed: Connection reset by peer
read failed: Connection reset by peer
read failed: Connection reset by peer
read failed: Connection reset by peer
read failed: Connection reset by peer
read failed: Connection reset by peer
read failed: Connection reset by peer
read failed: Connection reset by peer
[900] WARNING: ack of last datagram failed after 10 tries.
A dump of the ICMP packets shows that the problem is the destination port
on the server 191.1.10.19 where its complaint is that the destination is
>unreachable.
191.1.10.19 is the server receiving the packets
191.1.10.18 is the transmitting client
extract From Ethereal capture:
909 13.818549 191.1.10.19 191.1.10.18 UDP
Source port: 5001 Destination port: 1049
910 13.820132 191.1.10.18 191.1.10.19 ICMP
Destination unreachable
911 13.826596 191.1.10.19 191.1.10.18 UDP
Source port: 5001 Destination port: 1049
912 13.828154 191.1.10.18 191.1.10.19 ICMP
Destination unreachable
913 13.836027 191.1.10.19 191.1.10.18 UDP
Source port: 5001 Destination port: 1049
914 13.837592 191.1.10.18 191.1.10.19 ICMP
Destination unreachable
915 13.843924 191.1.10.19 191.1.10.18 UDP
Source port: 5001 Destination port: 1049
916 13.845495 191.1.10.18 191.1.10.19 ICMP
>Destination unreachable
917 13.851715 191.1.10.19 191.1.10.18 UDP
Source port: 5001 Destination port: 1049
918 13.853273 191.1.10.18 191.1.10.19 ICMP
Destination unreachable
###########################################################################
#
#############
-----Original Message-----
From: debbie fligor [mailto:fligor --at-- uiuc.edu]
Sent: Wednesday, November 02, 2005 9:57 AM
To: Tom.Gorman --at-- draeger.com
Cc: Iperf Users
Subject: Re: DAST: Iperf - multicast with iperf - Tom.Gorman --at--
draeger.com
Tom,
You didn't say what version of iPerf you were using 2.0.1 had a known
multicast bug that no matter what the TTL setting was specified, it
was always "1", so it wouldn't work through even one router (it
should have worked if your two test stations were on the same LAN
though).
I've not tested 2.0.2, but I know 1.7.0 works well with multicast,
I've personally used it for testing, and we've also used it in the I2
multicast workshop labs.
when doing multicast testing across routers, be sure you set -T
(multicast TTL) to something larger than the number of routers in
your network -T32 or -T64 generally is plenty.
Unfortunately I don't use iPerf on windows, so if you are using 1.7.0
or 2.0.2 I can't really help you debug your problem, but perhaps
someone else can.
At 16:50 -0600 11/1/05, Mitch Kutzko wrote:
>Date: Tue, 1 Nov 2005 16:37:44 -0600
>To: Tom.Gorman --at-- draeger.com
Subject: DAST: Iperf - multicast with iperf - Tom.Gorman --at--
draeger.com
Contacting DAST re: Request for information about Iperf
From: Tom Gorman <Tom.Gorman --at-- draeger.com>
Subject: multicast with iperf
Question/Comment:
We at Draeger Medical make patient monitoring systems which use multicast
for more than 90% of our traffic. The iperf tool seems suited to help
with
testing, but at least on Windows 2000 the display does not correspond to
the documentation. We never see "Joining multicast group" and a transfer
is always followed by ICMP message "destination unreachable". A dump of
the packet shows the destination port is the issue. The -i and -b
switches
function as advertised. We'd love to know if we are doing something
wrong.
Ethereal traces confirm the transfers.
How significant are the values following the -l switch? If the server
receives packets of a size different from what it expects, does it ignore
the packet? Our monitors can transmit packets of various sizes.
Thank you very much.
--
Mitch Kutzko | mitch --at-- dast.nlanr.net | mitch --at-- ncsa.uiuc.edu | 217-333-1199
Project: http://dast.nlanr.net | Personal: http://hobbes.ncsa.uiuc.edu
--
-debbie
Debbie Fligor, n9dn Network Engineer, CITES, Univ. of Il
email: fligor --at-- uiuc.edu <http://www.uiuc.edu/ph/www/fligor>
"Every keystroke can be monitored. And the computers never forget."
Important Note: This email and any attachment hereto are confidential and
may contain trade secrets or may be otherwise protected from disclosure. If
you have received it in error you are in notice of this fact. Please notify
>us immediately by reply email and then delete this email and any attachment
from your system. Please understand that you are not allowed to copy this
email or any attachment hereto or disclose its contents to any other
person.
Thank you.
--
-debbie
Debbie Fligor, n9dn Network Engineer, CITES, Univ. of Il
email: fligor --at-- uiuc.edu <http://www.uiuc.edu/ph/www/fligor>
"Every keystroke can be monitored. And the computers never forget."
Important Note: This email and any attachment hereto are confidential and
may contain trade secrets or may be otherwise protected from disclosure. If
you have received it in error you are in notice of this fact. Please notify
us immediately by reply email and then delete this email and any attachment
from your system. Please understand that you are not allowed to copy this
email or any attachment hereto or disclose its contents to any other person.
Thank you.