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. 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.
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.
Wietse
