> Eep.  This looks as though our stack doesn't do fast
> retransmit...is that true?  Does it have to be turned on or
> something?

The stack does fast retransmit.  I can't tell if that is the problem
here or not because it looks like the trace has been snipped.
But....

> 20:28:19.586001 fluff-wl.1647 > yerfable.ftp-data: . ack 1165081 win 5840 <nop,nop,timestamp 202126 541186> (DF)
> 20:28:19.586002 yerfable.ftp-data > fluff-wl.1647: . 1169461:1170921(1460) ack 1 win 17520 [tos 0x8]
> 20:28:19.626044 fluff-wl.1647 > yerfable.ftp-data: . ack 1166541 win 4380 <nop,nop,timestamp 202126 541186> (DF)

[[ The above is a new ACK. ]]

> 20:28:19.629951 fluff-wl.1647 > yerfable.ftp-data: . ack 1166541 win 4380 <nop,nop,timestamp 202126 541186> (DF)

[[ Above is the first duplicate ACK. ]]

> 20:28:19.709062 fluff-wl.1647 > yerfable.ftp-data: . ack 1166541 win 8116 <nop,nop,timestamp 202127 541186> (DF)

[[ The sequence number in the above identical to the previous two
   ACKs, but the advertised window is not.  And, window updates are
   not "duplicate ACKs" (Accoring to the code; whether this is Right
   or not has been questioned.  None of the TCP RFCs define
   precisley what a "duplicate ACK" is.).  So, this is a new ACK and
   the dupack counter starts over. ]]

> 20:28:19.709063 yerfable.ftp-data > fluff-wl.1647: . 1170921:1172381(1460) ack 1 win 17520 [tos 0x8]
> 20:28:19.709064 yerfable.ftp-data > fluff-wl.1647: . 1172381:1173841(1460) ack 1 win 17520 [tos 0x8]
> 20:28:19.732502 fluff-wl.1647 > yerfable.ftp-data: . ack 1166541 win 8116 <nop,nop,timestamp 202127 541186> (DF)

[[ First duplicate ACK. ]]

> 20:28:19.735432 fluff-wl.1647 > yerfable.ftp-data: . ack 1166541 win 8116 <nop,nop,timestamp 202127 541186> (DF)

[[ Second duplicate ACK. ]]

>  [ ack ack ack ]

[[ I am not sure what the snipped ACKs look like.  If they have an
   updated advertised window they are probably reseting the dupack
   counter. ]]

> 20:28:54.106537 yerfable.ftp-data > fluff-wl.1647: . 1166541:1168001(1460) ack 1 win 17520 [tos 0x8]
>  [ and finally, yerfable decides maybe it should retransmit ]

It would be interesting to see the entire trace (the binary version
would be especially nice).  What concerns me about this is the
apparent long delay between receiving the last ACK and
retransmitting the missing segment.  (I say "apparent" because there
is stuff missing from the trace file).  I don't see any reason why
the RTO should be that high.  (Usually it would only get that high
after successive exponential backoffs).  But, from the trace
provided fast retransmit is working as expected.

allman