bgrayson@ece.utexas.edu (Brian C. Grayson) writes:

>   Ever since I started tracking 1.2-current, PPP has been
> misbehaving.  I can sup and ftp files from other machines fine,
> but when I try to 'put' a file, the first several packets get
> shipped, and then things just sort of hang.  Occasionally, the
> file will eventually get through, at a rate of around 200
> bytes/sec (this is with a 14.4 modem, and receives flow around
> 1.4K/sec).  Sometimes I get a 'connection reset by peer'
> message, instead.  CVS also no longer works over the net (too
> many timeouts, IIRC).

I had this precise problem when I started using PPP with
NetBSD-current around May. Data is being dropped out of large packets
when leaving your system, which is why telnet works fine (except
things like pasting from the X clipboard), but bulk file and mail
transfers off the machine fail. To see if this is what is happening,
try ping -s with various sizes up to the interface MTU. I found that
packet loss rates increased with the size of the packet until almost
none got through for large packets. I calculated something like one
byte was being dropped from every 512 bytes sent on average or
something; probabalistically causing high loss rates for large
packets. You can watch the netstat -s stats to see if packets are
being lost entering or leaving your machine.

I don't believe this problem is related to the well known serial
interrupts problem in NetBSD, which the patches already mentioned
address -- that causes data dropped on packets coming *in* to your
machine, as I understand it. I think the problem was actually a flow
control problem on my ISP's side; I switched ISPs and my problems went
away, while different computer/OS/modem combinations exhibited the
same symptoms. So when reviewing your configuration I would suggest
you see if flow control is working locally and remotely. If you can't
track the loss down, a workaround is to select a very small MTU in
/etc/ppp/options, on the order of 300 or whatever size you can get
through with ping -s and acceptable packet loss.

Another suggestion I have heard for similar problems is to increase
the size of certain buffers in the tty subsystem; I think this perhaps
alleviated a problem with NetBSD sometimes losing data when modem flow
control was asserted and the tty code not informed quickly
enough. This was discussed on this mailing list some months ago, but I
no longer have the exact patch. Anyone remember this?

-- 
..nathaniel daw..........................................daw@panix.com..
 .ok soda may be the preferred drink of other people, such as yourself.