> On Sat, 28 Jun 1997, Bob Nestor wrote:
> 
> > Recall that most (not all) hardware 
> > handshake modem cables sold nowdays have RTS tied to DTR.  If all this is 
> > still true then it might be that your problem is you're only getting flow 
> > control in one direction.

The above's why the mac68k driver doesn't support in-bound flow control.

> Well, this was with MacPPP, set explicitly to use RTS and CTS, so unless
> there's something wrong with the serial chip....
> 
> Another interesting point to note, when using x/y/zmodem, transmissions
> from the laptop to the linux box worked fine with zmodem, but to go the
> other way, I had to switch to xmodem, because zmodem kept getting errors
> until it gave up.  Using the PowerMac in MacOS running Zterm, I didn't
> have this problem.  Thus, the big question is why I got so many errors
> even at slow speeds (e.g. 1200 baud).  It is obviously a driver problem.
> Maybe when they fix handshaking on PCI macs so they don't crash during
> data transfers, the code changes might help this NuBus mac's handshaking
> at the same time....

I doubt it's a flow control problem. Though our driver's not perfect, it
will tell you when you loose data (ring or fifo overflow). You said
you're not seeing that. Also, the 1200 baud case doesnt jibe w/ data
loss errors from bad handshaking.

I'd bet the problem is:

cable (but you said it's fine, so this one looses)

ppp settings (as Ken suggested)

Linux ppp problem (since MacOS and NetBSD both have problems)

Linux driver problem. It could have an obscure off-by-one
error which corrupts the data stream. ??

Good luck!

Take care,

Bill