> > > 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?
>
> That would be a bug in the TCP implementation. Sending SACK for
> segments already acknowledged makes no sense.
First of all I will tell to the client to disable SACK on its side,
while I will look for a patch for the OS that I'm using.. :-)
> However....
>
> > > The sender (217.11.85.59) then goes crazy and keeps retransmitting
> > > the data in 1994821:1996181 until the connection times out.
>
> That is also a bug.
>
> > > 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!
>
> Once I had a tcpdump recording, it took only a few minutes.
> And as I wrote earlier, this did not need any information
> abuot the content of the SMTP session.
>
I will try to imit you next time I'll face a similar issue..
;-)
Tnx
rocsca
