evristzam / ndt

Automatically exported from code.google.com/p/ndt
Other
0 stars 0 forks source link

Multiple clients mode (-m) not working anymore on 3.6.1 #42

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
When upgrading from 3.5.14 to 3.6.1 we noticed that the "-m" mode for allowing 
multiple 
parallel clients stopped working.
With that option enabled, the inbound test fails as follows:

TCP/Web100 Network Diagnostic Tool v3.6.1
click START to begin

** Starting test 1 of 1 **
Connecting to 'lsmp2' [lsmp2/130.59.35.42] to run test
Connected to: lsmp2  --  Using IPv4 address
Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
checking for firewalls . . . . . . . . . . . . . . . . . . .  Done
running 10s outbound test (client-to-server [C2S]) . . . . . 91.97Mb/s
running 10s inbound test (server-to-client [S2C]) . . . . . . Protocol error!  
Expected test data, got: 

ndt-3.6.1-debug-output.txt

TCP/Web100 Network Diagnostic Tool v3.6.1
click START to begin

** Starting test 1 of 1 **
Connecting to 'lsmp2' [lsmp2/130.59.35.42] to run test
Connected to: lsmp2  --  Using IPv4 address
Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
checking for firewalls . . . . . . . . . . . . . . . . . . .  Done
running 10s outbound test (client-to-server [C2S]) . . . . . 91.97Mb/s
running 10s inbound test (server-to-client [S2C]) . . . . . . Protocol error!  
Expected test data, got:    
instead
S2C throughput test FAILED!
Protocol error!  Expected test results, got:    instead

click START to re-test

The debug log on the server:

: 1root@lsmp2[welti]; /usr/local/sbin/web100srv -d -a -m --ipv4
ANL/Internet2 NDT ver 3.6.1
    Variables file = /usr/local/ndt/web100_variables
    log file = /usr/local/ndt/web100srv.log
    Admin file = /usr/local/ndt/admin.html
    Debug level set to 1
server ready on port 3001
web100_init() read 69 variables from file
Initial counter Values Totalcnt = 0, Total Mismatch = 0, Total Bad Cables = 0
Updated counter values Totalcnt = 1, Total Mismatch = 0, Total Bad Cables = 0
...
Initial counter Values Totalcnt = 594, Total Mismatch = 0, Total Bad Cables = 0
Updated counter values Totalcnt = 595, Total Mismatch = 0, Total Bad Cables = 0
Individual counts = [33, 2, 4, 421, 30, 18, 41, 42, 4, 0, 0, 0, 0, 0, 0, 0]
Signal 17 received by process 9888
successfully locked '/tmp/view.string' for updating
sending '988488,0,989562,0,595,0,0,33,2,4,421,30,18,41,42,4,0,0,0,0,0,0,0,Mar  
9 
13:46:21,Jan 26 10:44:53' to tmp file
Starting test suite:
 > Middlebox test
 > Simple firewall test
 > C2S throughput test
 > S2C throughput test
 <-- Middlebox test -->
WARNING: ephemeral port number was bound
  -- port: 54794
Sending 1444 Byte packets over the network
Signal 17 received by process 9891
 <-------------------->
 <-- Simple firewall test -->
  -- port: 43250
  -- time: 1
  -- oport: 53549
Unable to create connect socket.
 <-------------------------->
 <-- C2S throughput test -->
WARNING: ephemeral port number was bound
  -- port: 46533
listening for Inet connection on testOptions->c2ssockfd, fd=3
Sending 'GO' signal, to tell client to head for the next test
Opening network interface 'eth0' for packet-pair timing
installing pkt filter for 'host maccw.switch.ch and port 53554'
Initial pkt src data = 806d804
New IPv4 packet trace started -- initializing counters
 91973 kbps outbound
Signal USR1(10) sent to child [9897]
Signal 10 received by process 9897
03:19:30.019186   57 bytes read '  1 1 0 39 205 78854 278 2 127 11 83 2 266.12 
0 0 0 1 0 7' 
from C2S monitor pipe
03:19:30.019186   65 bytes read '  0 0 1 9 118 38235 112 0 1 58 3372 0 100.05 
99 67 41740 0 
3372 7' from C2S monitor pipe
 <------------------------->
 <-- S2C throughput test -->
Signal 17 received by process 9891
WARNING: ephemeral port number was bound
  -- port: 50564
waiting for data on testOptions->s2csockfd
Opening network interface 'eth0' for packet-pair timing
installing pkt filter for 'host maccw.switch.ch and port 53569'
Initial pkt src data = 806d804
Signal 17 received by process 9891
New IPv4 packet trace started -- initializing counters
Signal 15 received by process 9891
Signal 17 received by process 9888
Signal 14 received by process 9899

Original issue reported on code.google.com by jwzuraw...@gmail.com on 12 Mar 2010 at 1:27

GoogleCodeExporter commented 9 years ago
Re-verified with Version 3.6.3 and found this bug is fixed!

Original comment by Garimell...@gmail.com on 10 Jun 2010 at 10:22

GoogleCodeExporter commented 9 years ago

Original comment by Garimell...@gmail.com on 11 Jun 2010 at 12:33