This might be it then (bare with me) --- given that Lucent claims that
my aging USR33.6 modem has a compression bug that they are now
compensating for on their end, it is possible that sometimes the
kernel has been sending back its ACK at a point in time when the two
modems compression tables are in a bad state and the packet is (was)
either getting lost in the modems or is mangled enough that the packet
is dropped the next time someone does a checksum on it. Perhaps the
kernel is ever so slightly faster (or slower) turning around when it
is ACKing an earlier packet because of the missing one and this could
be a timing reason for why it is catching the modems at an inopportune
moment. Running the traceroute would then act to modify the
compression tables and the next ACK can get through.
This same problem happened to me several times during the
"1.3.almost-ready" kernels. At that time my ISP was entirely an
USR33.6 shop, so Lucents claims might have a touch of weight (it is
always somewhat hard to swallow finger pointing when a change on the
other side seems to fix things :-) I have fallen off the list several
times since then, so I do not really know whether Linux successfully
addressed this problem since then or whether it kept disappearing
mysteriously as it used to do during 1.3.* days.
(I will shut up now and finish reading Stevens)
[snip]
>
> Alan
>
>