Re: Http get commands return a bad results.

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I first had the problem with cups-1.1.22-source.tar.bz2 when updating
:the cups port.  I had corrupted files from several ftp sites and I
:remember that the file sizes were different each time.
:
:I just used 'fetch' to get the same file and it is corrupted once again,
:but the filesize is correct this time.  I'd be happy to send you the
:file but I have no ftp server available to me.  May I upload it? (8MB)
:
:...
:>     sysctl net.inet.tcp.sack=0
:
:I just tried this and, with a sample size of 1 try, it works fine.  I
:changed the value of sack while my newsreader was open to this group
:and it got very confused -- I had to close the newsreader and reopen
:it before I could post this.  Dunno if it's related to sack or not.

    Leave SACK turned off (set it to 0 in /etc/sysctl.conf) and run a bunch
    more tests and report back.

    If you consistently get zero corruption with SACK turned off then we 
    know it is SACK.  Considering the experimental nature of SACK I am not
    surprised, if that turns out to be what it is I will simply make the
    default be off instead of on until Jeff tracks the issue down.  It could
    be a bug in our SACK code or in the originating machine's SACK code.

    Since your NFS worked (UDP packets) and local FS copies worked, about the
    only thing it can be is TCP and the only major change we've made to 
    TCP recently was Jeff's SACK commit.

    Jeff and I both are probably kicking ourselves for not checking data 
    integrity issues :-).  My guess is that you were downloading from LINUX
    driven sites which were running SACK too.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>