ndt-users list created

[Richard Carlson <>]

Hi Simon;

At 11:40 AM 8/30/2006, Simon Leinen wrote:
> Jeremian  writes:
> > I forgot that the patch in the mentioned mail wasn't complete. Here
> > comes the missing part:
>
> >  /-----------------------------------------------------------------\
> > @@ -703,7 +703,7 @@
>
> >      cp = agent->info.local.connection_head;
> >      while (cp) {
> > -        if (memcmp(&cp->spec_v6, spec_v6, sizeof (spec_v6)) != 0)
> > +        if (memcmp(&cp->spec_v6, spec_v6, sizeof (spec_v6)) == 0)
> >              break;
> >          cp = cp->info.local.next;
> >      }
> >  \-----------------------------------------------------------------/
>
> Thanks.  With that patch, the server logs this for an IPv6 transfer:
>
>     Sending 1408 Byte packets over the network
>     libweb100: warning: accessing depricated variable AckPktsIn
>     libweb100: warning: accessing depricated variable AckPktsOut
>
> Looks better.  But the client still says:
>
>     : 
> leinen@soekris[leinen];
>  ./web100clt -n ndt.switch.ch
>     Testing network path for configuration and performance 
> problems  --  Using IPv6 address
>     [...]
>     Information: Network Middlebox is modifying MSS variable (changed to 
> 1420)
>
> ...which I find confusing, because there is no middlebox.  1420 bytes
> is simply the MSS that the client naturally advertises, because its
> default route points to a tunnel interface with a 1480 byte IPv6 MTU.

Two things.

You can select the IP protocol (v4 or v6) with the -4 and -6 option.  These 
also work on the server (web100srv process).  I think we are still thinking 
about the best way to make the applet work this way too.

The MSS test is the same as it always was.  Ideally the server should set a 
value and the client should report what it actually got.  Unfortunately I 
have been unable to get the data out of the applet.  So what happens now is 
that the server tries to set a specific - non-standard - MSS and then it 
checks to see if that is what was negotiated.  If not, then it reports a 
middlebox in the path.  As you note, the tunnel interface confuses this 
test.  We'll fix this in a future release.

Rich

> --
> Simon.

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



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