Bring the PPP connection up again.  Retry whatever-it-is that's
failing. 

PPP includes a link-level checksum.  Watch the packet counts in the
netstat -I ppp? output over time. Check carefully Check carefully to
see whether the PPP driver is recording input errors (frames whose CRC
failed.)  Frames with bad checksums are counted in Ierr field.  A
non-zero count indicates _something_, possibly overruns, is in fact
garbling your PPP traffic.  If the packets are being discarded due to
errors at the PPP level, they'll never even get as far as IP.


Also, use netstat (or an SNMP daemon and monitor, if you prefer)
to watch the rate of change of bad packets at the IP and TCP level.
I run "netstat -p ip" "netstat -p tcp".  One has to manually compute
the rate of change; netstat's -i option means something different
to, say, vmstat's.   (Adding  periodic  sampling and rate-of-change
to netstat would be a Cool Project.)

At the IP level, the relevant statistcs are
        0 bad header checksums
        0 with size smaller than minimum
        0 with data size < data length
        0 with header length < data size
        0 with data length < header length
        0 with bad options
        0 with incorrect version number
	[...]
        0 output packets dropped due to no bufs, etc.
 


at the TCP level,  look for, e.g.,

                0 discarded for bad checksums
                0 discarded for bad header offset fields
                0 discarded because packet too short

Any of these being non-zero would support the hypothesis of a bug
in the PPP implementation.  Unlikely, but one never knows.


It could be that a TCP ack got munged or dropped by your PPP link;
or possibly somewhere else in the Internet.  That's not abnormal
on busy links.

What OS is your FTP peer (ghostwheel) running?  Is it a pre-2.0.0
Linux? If so, have you tried turning off rfc1323 on your NetBSD
machine??

(Is there an FAQ or HOWTO for this stuff, for *bsd, __somewhere__??)