I was a little too quick with the analysis; same conclusion, slightly
different details.

Five packets in a row were received on the ftp data channel with bad
checksums; each of these had the correct checksum for the next packet.
The fifth expected TCP packet was not received!  (There is one PPP input
error according to netstat, but that probably happened a couple of minutes
ago, not while I was doing the test).  In its place in the log there is
a message from the ftp server on the ftp control channel ("220 Transfer
complete", arriving 83221 bytes into a 138K transfer).  After that are
6 more data packets with *correct* checksums (the last two checksums are,
by "coincidence", equal to the checksums of the most recent two acknowledges.
(Considering the predictability of TCP packets and the lack of sensitivity
to positional exchange of the TCP checksum, it's not quite just a coincidence.)

Eventually the transfer restarts as described before (though interestingly
enough, the pause appears to have cut down the window so instead of 12 TCP
segments trying to send 1460 bytes, I get 10 1460 byte segments and a 547
byte segment.


Now that's interesting.

I am receiving 1460 byte segments.  tcpdump says I'm receiving 1504 byte PPP
packets.  I have PPP configured for 576 byte mru and mtu.  HUH?  (I guess
they must have MRU negotiation turned off.)


Anyway, it's still a router bug, it's just not the router bug I thought it
was.