ndt-users list created

[Richard Carlson <>]

Hi Claudio;

Are you running the web100srv process as root?  The link type detection 
mechanism requires access to the raw network interface, and this is usually 
restricted to root.  Send us the output from the "ps axuw | egrep 
"fakewww|web100srv" | grep -v egrep" command.

Where are you writing the web100srv.log file?  I think there is a bug in 
the code that causes the "protocol error" message if the write to the 
web100srv.log file fails.  I have an unreleased patch for this, and I'll 
try and get it out shortly.  In the mean time, check the file system and 
make sure the log file exists and there is room in the file system.

The other thing you can do is run the web100srv process with some debugging 
options.

Simply run "sudo /usr/local/sbin/web100srv -d" and the debugging output 
will appear in your terminal window.  Adding more '-d' flags (-ddd) will 
get you more details (3 levels with a -ddd).  Start with 1 level and add 
more if nothing shows up.

Regards;
Rich Carlson
At 08:53 AM 3/8/2007, 

 wrote:
> Hi,
>
> I have some problems with NDT, but the main one reffer checking 
> middleboxes. NDT work fine but sometimes during checking middleboxes 
> web100clt (and also the java applet) return a "Protocol error!". Test was 
> perform on localhost and also connecting by another pc and results it's 
> the same. If I use web100clt with the '--disablemid' option, all (quite 
> all...) works perfectly. NDT version is 3.3.19 on a Scientific Linux CERN 
> 4.4 with a kernel 2.6.10 web100 patched. The userland library is 1.6 with 
> the patch for IPv4 addresses mapped on IPv6. Follow up test results with 
> '--disablemid' enabled:
>
>  Testing network path for configuration and performance 
> problems  --  Using IPv4 address
> checking for firewalls . . . . . . . . . . . . . . . . . . .  Done
> running 10s outbound test (client to server) . . . . .  982.12 Mb/s
> running 10s inbound test (server to client) . . . . . . 424.24 Mb/s
> Server unable to determine bottleneck link type.
> Server 'xxxxxxxxxxxxxxx' is not behind a firewall. [Connection to the 
> ephemeral port was successful]
> Client is not behind a firewall. [Connection to the ephemeral port was 
> successful]
>
>         ------  Web100 Detailed Analysis  ------
>
> Web100 reports the Round trip time = 0.29 msec;the Packet size = 16384 
> Bytes; and
> No packet loss - but packets arrived out-of-order 0.02% of the time.
> This connection is receiver limited 99.68% of the time.
>
>     Web100 reports TCP negotiated the optional Performance Settings to:
> RFC 2018 Selective Acknowledgment: ON
> RFC 896 Nagle Algorithm: ON
> RFC 3168 Explicit Congestion Notification: OFF
> RFC 1323 Time Stamping: ON
> RFC 1323 Window Scaling: ON; Scaling Factors - Server=2, Client=2
> The theoretical network limit is 430403.47 Mbps
> The NDT server has a 216 KByte buffer which limits the throughput to 
> 5818.97 Mbps
> Your PC/Workstation has a 67 KByte buffer which limits the throughput to 
> 1792.41 Mbps
> The network based flow control limits the throughput to 2155.17 Mbps
>
> Client Data reports link is ' -1', Client Acks report link is ' -1'
> Server Data reports link is ' -1', Server Acks report link is ' -1'
> CurMSS: 16384
> X_Rcvbuf: 221184
> X_Sndbuf: 221184
> AckPktsIn: 32393
> AckPktsOut: 0
> BytesRetrans: 0
> CongAvoid: 0
> CongestionOverCount: 0
> CongestionSignals: 0
> CountRTT: 32387
> CurCwnd: 32768
> CurRTO: 201
> CurRwinRcvd: 17780
> CurRwinSent: 32768
> CurSsthresh: 2147483647
> DSACKDups: 0
> DataBytesIn: 0
> DataBytesOut: 532361884
> DataPktsIn: 0
> DataPktsOut: 32392
> DupAcksIn: 7
> ECNEnabled: 0
> FastRetran: 0
> MaxCwnd: 81920
> MaxMSS: 16384
> MaxRTO: 211
> MaxRTT: 40
> MaxRwinRcvd: 68132
> MaxRwinSent: 32768
> MaxSsthresh: 0
> MinMSS: 16364
> MinRTO: 201
> MinRTT: 0
> MinRwinRcvd: 1072
> MinRwinSent: 32768
> NagleEnabled: 1
> OtherReductions: 2
> PktsIn: 32393
> PktsOut: 32392
> PktsRetrans: 0
> RcvWinScale: 2
> SACKEnabled: 3
> SACKsRcvd: 0
> SendStall: 0
> SlowStart: 3
> SampleRTT: 0
> SmoothedRTT: 1
> SndWinScale: 2
> SndLimTimeRwin: 9996291
> SndLimTimeCwnd: 561
> SndLimTimeSender: 31951
> SndLimTransRwin: 2
> SndLimTransCwnd: 1
> SndLimTransSender: 1
> SndLimBytesRwin: 532230552
> SndLimBytesCwnd: 82180
> SndLimBytesSender: 49152
> SubsequentTimeouts: 0
> SumRTT: 9406
> Timeouts: 0
> TimestampsEnabled: 1
> WinScaleRcvd: 2
> WinScaleSent: 2
> DupAcksOut: 0
> StartTimeUsec: 789820
> Duration: 10030003
> c2sData: -1
> c2sAck: -1
> s2cData: -1
> s2cAck: -1
> half_duplex: 0
> link: 100
> congestion: 0
> bad_cable: 0
> mismatch: 0
> spd: 424.67
> bw: 430403.47
> loss: 0.000001000
> avgrtt: 0.29
> waitsec: 0.00
> timesec: 10.00
> order: 0.0002
> rwintime: 0.9968
> sendtime: 0.0032
> cwndtime: 0.0001
> rwin: 0.5198
> swin: 1.6875
> cwin: 0.6250
> rttsec: 0.000290
> Sndbuf: 221184
> aspd: 0.00000
> CWND-Limited: 0.00
>
> And now the second problem...
> "Server unable to determine bottleneck link type." Searching in some 
> previous articles in mailing list i found something about it (eth0 is the 
> only network device and enter properly in promiscuous mode) but not work. 
> Any idea?
>
> Regards,
>
> Claudio.
> (i'm sorry for my english...)

------------------------------------



Richard A. Carlson                              e-mail: 

Network Engineer                                phone:  (734) 352-7043
Internet2                                       fax:    (734) 913-4255
1000 Oakbrook Dr; Suite 300
Ann Arbor,  MI  48104