> 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. And I
collected data with tcpdump exactly on that interface. So I infere that
something goes wrong on that machine! Why it behaves so? It is maybe a
bug in TCP implementation on the OS used by that machine and so an OS
bug, or some problem tight to hardware device?
> The sender (217.11.85.59) then goes crazy and keeps retransmitting
> the data in 1994821:1996181 until the connection times out.
>
> All this happens on a connection with an insane packet loss rate.
>
> Of course it is possible that there is a firewall in-between that
> is screwing things up. Otherwise, you may want to advise your
> vendor(s) of a problem in the receiver's tcp stack, and in the
> sender's handling of an incorrect receiver response.
Thank very much I'll never should be able to point out a such subtle
thing!
:-o
rocsca
