> >I tried ATQ1 and it it helped - my modem now answers.  Thanks.
> >
> >I do think this is more of a workaround than a solution, though.
> 
> No, this is a pretty comon problem, obscure but common, and I personally
> thought the correct modem command was "ATE0".

Indeed it is, but I *had* set ATE0 and it still did not work.  Only
when I set ATE0 *and* ATQ1 did the modem answer.

> Nope, this happens with any type of unix as far as I know. I had the same
> exact problem when I first started fooling around with a relatively new
> AT&T 3B2 ;-)

I believe you are talking about the common problem where the modem and
getty get into an infinite login dialog.  That's well-known, but this
is a different problem which occurs while getty is still blocked in
open() waiting for carrier - there is no way it could have issued a
login prompt yet.

I just spent some more time analyzing the problem with a NetBSD
system, a terminal, an RS232 tester, and an RS232 breakout box (for
manually controlling the state of the CD signal).

I found that while CD is low, getty is blocked in open() just like it
is supposed to.  The port speed is reset to the default of 9600 bps at
this time, regardless of the speed configured for getty in
/etc/inittab.  That's OK, too (although the fact that getty reports it
as "ispeed 0 baud; ospeed 9600 baud" is somewhat suspect).

Now for the buggy part.  I found that when I set the terminal to 9600
bps (only), the system will actually echo all terminal input back to
the terminal, even though CD is low and getty is still blocked in
open().  With the terminal set to other speeds close to 9600 bps, the
echo still occurs, but the echoed data is garbage because the system
always echoes at 9600.

This is clearly wrong - a tty is not supposed to echo anything when it
is strictly speaking not even open yet.

I suspect this can also explain some other problems I have been having
with ppp chat scripts failing with PCMCIA modems in dialout mode.

> Maybe something in the FAQ is in order, but not any OS "fix"

I beg to differ, and will send a PR.
-- 
Andreas Gustafsson, gson@araneus.fi