Rocco Scappatura:
> > > > I think I have solved the mystery. But I can offer you only a
> > > > workaround, to turn off selective ACK support.
> > > >
> > > > Here is one event in a tcpdump file that I received a few hours
> > > > ago (full context is below the signature):
> > > >
> > > > 10:49:57.930285 80.74.176.142.25 > 217.11.85.59.2528: . ack
> > > > 1998901 win 32767 <nop,nop,sack sack 1 {1994821:1996181} > (DF)
> > > >
> > > > After this, things go bad very quickly.
> > > >
> > > > What happens is that the receiver (80.74.176.142) says:
> > > >
> > > > I have received all data up to offset 1998901
> > > >
> > > > But the receiver (80.74.176.142) also sends a selective ACK for
> > > > offset range 1994821:1996181, that is, for data that it has already
> > > > acknowledged.
> > >
> > > Is it awesome! '80.74.176.142' is the interface of my smtp server.
What is the OS type/version?
Of course the bigger problem is that the sender keeps retransmitting
the data offset range 1994821:1996181 over several minutes.
Either way, if you turn off SACK support (RFC 2018) on the receiver
it should stop triggering this bug on the sender side.
http://support.microsoft.com/kb/224829 has instructions on how to turn
off SACK support on Windows (look for "SackOpts").
Wietse
