cvs commit: ports/biology/tinker Makefile

[Brian Somers]

On Thu, 24 May 2007 22:00:23 -0400
Kris Kennaway <kris at obsecurity.org> wrote:

> On Fri, May 25, 2007 at 11:42:09AM +1000, Edwin Groothuis wrote:
> > On Thu, May 24, 2007 at 09:31:18PM -0400, Kris Kennaway wrote:
> > > On Fri, May 25, 2007 at 11:27:57AM +1000, Edwin Groothuis wrote:
> > > > On Fri, May 25, 2007 at 01:00:15AM +0000, Kris Kennaway wrote:
> > > > > kris        2007-05-25 01:00:15 UTC
> > > > > 
> > > > >   FreeBSD ports repository
> > > > > 
> > > > >   Modified files:
> > > > >     biology/tinker       Makefile 
> > > > >   Log:
> > > > >   BROKEN: Unfetchable
> > > > 
> > > > Looks like a temporary network issue:
> > > > 
> > > > => Attempting to fetch from ftp://dasher.wustl.edu/pub/.
> > > > tinker.tar.gz                                 100% of 7985 kB  110 kBps 00m00s
> > > > => MD5 Checksum OK for tinker-4.2.20040908/tinker.tar.gz.
> > > > => SHA256 Checksum OK for tinker-4.2.20040908/tinker.tar.gz.
> > > 
> > > Nope, that FTP site has been timing out for me for months now.
> > 
> > Works fine from freefall:
> > 
> > [~] edwin at freefall>fetch -ApRr ftp://dasher.wustl.edu/pub/tinker.tar.gz
> > tinker.tar.gz                                 100% of 7985 kB  462 kBps 00m00s
> > 
> > But not from pointyhat, not even in passive/non-passive and the -U option...
> > 
> > I wouldn't be surprised if it was because of your constant downloading
> > from that site :-)
> 
> It's weird, it starts to download but then hangs.  It could be some
> kind of explicit filter though.
> 
> > I've swapped the entries in MASTER_SITES to overcome this issue.
> 
> Thanks.
> 
> Kris

[andre cc'd]

I suspect the issue here is this:

 andre       2007-02-01 17:39:19 UTC

  FreeBSD src repository

  Modified files:
    sys/netinet          tcp_syncache.c tcp_usrreq.c 
  Log:
  Change the way the advertized TCP window scaling is computed.  Instead of
  upper-bounding it to the size of the initial socket buffer lower-bound it
  to the smallest MSS we accept.  Ideally we'd use the actual MSS information
  here but it is not available yet.
  
  For socket buffer auto sizing to be effective we need room to grow the
  receive window.  The window scale shift is determined at connection setup
  and can't be changed afterwards.  The previous, original, method effectively
  just did a power of two roundup of the socket buffer size at connection
  setup severely limiting the headroom for larger socket buffers.
  
  Tested by:      many (as part of the socket buffer auto sizing patch)
  MFC after:      1 month
  
  Revision  Changes    Path
  1.104     +8 -2      src/sys/netinet/tcp_syncache.c
  1.143     +7 -2      src/sys/netinet/tcp_usrreq.c

The connection failure is probably because the target machine is
using OpenBSD & pf.  There's a bug in older versions of OpenBSD
where pf clocks the wscale value before it's negotiated and
subsequently just doesn't think the data arriving is within a
reasonable window of the last received data (and drops it on
the floor).

Forcing wscale to a value of 4 or less seems to make such
connections work here.

Andre, is it worth having a net.inet.tcp.maxwscale tunable
(or something similar) so that this issue can be handled
in the short term?  If it's ok by you I can prepare a patch.

Cheers.

-- 
Brian Somers                                       <brian at Awfulhak.org>
Don't _EVER_ lose your sense of humour !            <brian at FreeBSD.org>