I was wondering... is a single dropped packet supposed to cause a 35s
stall in a ftp transfer? Here's a tcpdump, from yerfable's POV, with
comments from me in [].

20:28:19.547910 yerfable.ftp-data > fluff-wl.1647: . 1163621:1165081(1460) ack 1 win 17520 [tos 0x8]
20:28:19.569397 fluff-wl.1647 > yerfable.ftp-data: . ack 1160701 win 8760 <nop,nop,timestamp 202126 541186> (DF)
20:28:19.569398 yerfable.ftp-data > fluff-wl.1647: . 1165081:1166541(1460) ack 1 win 17520 [tos 0x8]
20:28:19.569399 yerfable.ftp-data > fluff-wl.1647: . 1166541:1168001(1460) ack 1 win 17520 [tos 0x8]
 [ everything had been going fine as far as I could tell, up to this
   point, when the above TCP segment apparently didn't make it to the
   other side ]
20:28:19.575257 fluff-wl.1647 > yerfable.ftp-data: . ack 1162161 win 8760 <nop,nop,timestamp 202126 541186> (DF)
20:28:19.575258 yerfable.ftp-data > fluff-wl.1647: . 1168001:1169461(1460) ack 1 win 17520 [tos 0x8]
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)
20:28:19.629951 fluff-wl.1647 > yerfable.ftp-data: . ack 1166541 win 4380 <nop,nop,timestamp 202126 541186> (DF)
20:28:19.709062 fluff-wl.1647 > yerfable.ftp-data: . ack 1166541 win 8116 <nop,nop,timestamp 202127 541186> (DF)
 [ the other end keeps ack-ing the last segment it got ]
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)
20:28:19.735432 fluff-wl.1647 > yerfable.ftp-data: . ack 1166541 win 8116 <nop,nop,timestamp 202127 541186> (DF)
 [ ack ack ack ]
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 ]
20:28:54.124117 fluff-wl.1647 > yerfable.ftp-data: . ack 1173841 win 8760 <nop,nop,timestamp 202470 541186> (DF)
20:28:54.124118 yerfable.ftp-data > fluff-wl.1647: . 1173841:1175301(1460) ack 1 win 17520 [tos 0x8]
20:28:54.124119 yerfable.ftp-data > fluff-wl.1647: . 1175301:1176761(1460) ack 1 win 17520 [tos 0x8]
20:28:54.149510 fluff-wl.1647 > yerfable.ftp-data: . ack 1176761 win 8760 <nop,nop,timestamp 202470 541186> (DF)

Is this normal? 'cuz it sure is lame :) yerfable is NetBSD/alpha 1.4W
from March 24, 100BaseT ethernet. fluff-wl is Windows 2000,
Aviator2.4. They're connected through a NT 4.0 box acting as a router,
since NetBSD's ray driver isn't on speaking terms with the latest
Windows driver.
-- 
Name: Dave Huang     |   Mammal, mammal / their names are called /
INet: khym@bga.com   |   they raise a paw / the bat, the cat /
FurryMUCK: Dahan     |   dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 24 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++