> Sounds like reassembly failure on mircosquishy's (I like that! ;-)
> end.   

Heh.  My SO's brother works for Microsoft.  We call it Nanosquishy. :)

> Packet's get only fragment once, and nobody reassembles them until
> they reach their final destination.  Now, it could also be that one
> of your frags gets lots all the time.

It probably is not immediately relevant, but I did once see a problem
that turned out to be something very much like this.

I was NFS-mounting stuff.  The NFS server was a Sun-3 running whatever
the then-latest was, SunOS 3.something I think; the client was a
MicroVAX running a somewhat locally-hacked mtXinu 4.3+NFS.  The uVAX
ran an FTP daemon, part of whose anonymous FTP tree consisted of
(read-only) NFS mounts from the Sun.  I started noticing FTP daemons
getting stuck in D wait states.  On investigation, it seemed that there
were a few files such that fetching them reliably threw the ftpd
involved into this state.

It eventually turned out that the problem was that the DEQNA on the
MicroVAX simply couldn't receive packets less than about 64 bytes.  But
the minimum Ethernet packet size is 60 bytes (both numbers from memory,
may be wrong, but are approximately right).  Normally, this was not a
problem, because with NFS and RPC and UDP headers, everything was well
over 64 bytes.  But if a large read reply got fragmented, the last frag
of the reply could be a minimum-size packet, and would reliably be
dropped.  Reassembly would timeout and the request would be retried,
only to fail in exactly the same way.

The cure we used was to mount the filesystem rsize=1024, so that
replies would never be large enough to be fragmented.  Of course, the
_correct_ fix would have been to use non-broken Ethernet hardware; the
next best fix would have been to make sure the Sun padded packets to 64
bytes if necessary...but neither of those was feasible.

I suppose the point of this is just that you shouldn't write off the
possibility that something is dropping a fragment reliably, so that
retransmissions lose exactly the same way as the original.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B