Greg Troxel writes:
 > I would expect those to reflect the hardware state.
 > 
 > It's odd, though, that kermit indicates that it is using rts/cts, and
 > shows CTS on.

I put a hardware monitor inline with the serial port to monitor the
state of the lines.  In all cases--that is when connecting via kermit,
tip, or pppd/chat--all four modem control lines are activated:  DTR,
DSR, RTS, and CTS; CD is the only one that is off, presumably because
the phone does not implement it.  As mentioned before, kermit reports
the correct status of these lines.  Tip works correctly, though I
don't know how to get it to report status on the lines without
modifying the code.

However, my modified chat code reports the following (~ indicating an
unset bit):

ioctl (0, TIOCMGET):    00000007
                        TIOCM_DTR TIOCM_RTS
                        ~TIOCM_DSR ~TIOCM_CTS ~TIOCM_CAR ~TIOCM_CD
ioctl (0, TIOCGFLAGS):  00000000
                        ~TIOCFLAG_SOFTCAR ~TIOCFLAG_CLOCAL
                        ~TIOCFLAG_CRTSCTS ~TIOCFLAG_MDMBUF ~TIOCFLAG_CDTRCTS
ioctl (0, TIOCGETA):  termios state
  c_iflag:              00000025
  c_oflag:              00000003
  c_cflag:              0000cb00
                        CLOCAL ~CRTSCTS
  c_lflag:              00000000
  c_ispeed:             4800
  c_ospeed:             4800

Chat clearly does not recognize via TIOCMGET that the DSR and CTS
lines are actually activated at this time, which is what the hardware
monitor indicates.

The problem, thus, seems to be that the kernel is reporting
information about the serial port that does not agree with the actual
state of the hardware.  This happens with both a 1.6.1 and a 1.6ZK
GENERIC.MP kernel; as soon as 2.0 comes out I'll verify it again with
that.

Any idea why the in-kernel state would disagree with the hardware
state, especially only with the particular combination of pppd/chat
and not with either kermit or tip?

Cheers,
Brook