> 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?
SUSE Linux Enterprise Server 10 (i586)
VERSION = 10
Linux av5 2.6.16.21-0.8-smp #1 SMP Mon Jul 3 18:25:39 UTC 2006 i686 i686
i386 GNU/Linux
> 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.
It could impact heavily on performance of SMTP service?
rocsca
