> 
> Adam, sounds like a kernel problem. I had that problem when I had compiled
> a -current kernel whose serial code had been messed with...

Being the person who's been mucking with the serial ports, I probably
should chime in.

I've also had problems with cu. Bluntly, I've never gotten it to work
with my computer. Every time I'd type anything, it would quit because
of an IO error. I've had this responce both with my modified serial
code, and with the origonal serial code back when I'd first installed
the binaries.

My problem is that, for some reason, cu is getting an error which
basically says try again later (basically a your write will block; try
later message). It freaks at this. Since I've seen this with both old
and new kernels on my machine, I suspect there is something wrong
in the tty setup.

For reference, the new serial code is basically a port of the sun's serial
code. From the point of view of the tty's, it should be identical. Most
of the changes have been to get hardware flow control working, and to
adapt for the differences between how the mac & sun ports deal with
the serial ports.

So what have we gained? Well, we've lost serial console for the moment.
But we do have serial echo, and we also have hardware flow control
and fairly solid operation at up to 57600 baud. ppp connections seem
to be much more stable with the new driver. Also, I can print to my
DeskWriter successfully!

I think the origonal problem was that nothing got sent to the modem.
Maybe a "stty -f /dev/tty00 clocal -crtscts" might help. -clocal means
make sure DCD is asserted before proceeding, and crtscts means wait
for CTS (if DCD is asserted) before sending. I've rigged it so that
if DCD is not asserted, CTS is ignored.

Take care,

Bill