ndt-users list created

[Richard Carlson <>]

Hi Nathaniel;

Hum, I'll need to look into this.  The server isn't suppose to know 
which client was used.  I'll post a new message when I've resolved this bug.

Rich

On 1/15/2010 10:23 AM, Nathaniel Gephart wrote:
> Hi all,
>
> I updated to 3.5.14 from 3.5.6 (I was having the "Invalid S2C
> throughput received" error that was addressed by this update). Now,
> however, the Java applet seems to hang at the link detection phase. It
> says "Receiving results..." at the top and reports the slowest link.
> Here's what I see on the client side (IPs and hostnames removed).
>
> TCP/Web100 Network Diagnostic Tool v3.5.14
> click START to begin
>
> ** Starting test 1 of 1 **
> Connecting to '<blocked>' [<blocked>] to run test
> Connected to:<blocked>   --  Using IPv4 address
> Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
> checking for firewalls . . . . . . . . . . . . . . . . . . .  Done
> running 10s outbound test (client-to-server [C2S]) . . . . . 94.04Mb/s
> running 10s inbound test (server-to-client [S2C]) . . . . . . 93.73Mb/s
> The slowest link in the end-to-end path is a a 622 Mbps OC-12 subnet
>
> On the server side, I've been running the web100srv process at the
> terminal with full debugging (-ddd) turned on. I've been using a
> command line client for comparison because the problem doesn't seem to
> occur with those tests. Everything looks fine in the web app test
> except the four lines related to link detection:
>
> Client -->  Server data detects link = OC-12
> Client<-- Server Ack's detect link = Dial-up
> Server -->  Client data detects link = OC-12
> Server<-- Client Ack's detect link = System Fault
>
> My hunch is there's something wrong with the Java app that's fine in
> the command line app. I'm using the latest versions of everything. Any
> idea what the issue might be?
>
> Thanks,
>
> Nate Gephart