Subject: chat bugs

From: Randy Gobbel <[email-masked]>
Date: Thu, 8 Aug 1996 12:29:55 -0700

I installed Debian Linux 1.1 on my new Pentium Pro a couple of weeks ago.  so
far everything mostly works great, but I've noticed that the chat program
seems to have a number of problems:

- If I put ABORT "NO CARRIER" in my script, it sometimes erroneously aborts
  when it sees a "CARRIER 28800" message (but works most of the time).

- If I put "quiet" flags (\q) on both my username and password strings, it
  only recognizes the first one, i.e., it puts my password into the log file!

- I tried to put a second "TIMEOUT" string into the script, to make it shorter
  after the initial prompt was detected, but instead of taking it as a timeout
  directive, it just looks for the string "TIMEOUT" coming over the
  connection.

Has anyone else noticed similar problems?  I'm going to take a look at the
source, and will fix the bug if I find it.

-Randy
-- 
http://cogsci.ucsd.edu/~gobbel/

---

From: Rob Browning <[email-masked]>
Date: 08 Aug 1996 20:42:06 -0500

> seems to have a number of problems:

Just a personal experience: I had all kinds of trouble with the modem
that came with my Gateway 2000 (the Telepath internal -- almost a
Sportster, made by USR for Gateway).  I had dropped connections, chat
problems with recognizing REPORT and ABORT strings, etc.  When I
recently replaced it with an external Courier, *all* the problems
vanished.

Anyone want a cheap internal modem :>
--
Rob

---

From: Yves Arrouye <[email-masked]>
Date: Fri, 9 Aug 1996 12:41:02 +0200

>   only recognizes the first one, i.e., it puts my password into the log file!

I have only one \q for my passwd, and it's in the log file too :-(.
Yves.

---

From: Yves Arrouye <[email-masked]>
Date: Fri, 9 Aug 1996 12:41:02 +0200

---

From: Randy Gobbel <[email-masked]>
Date: Fri, 9 Aug 1996 07:44:19 -0700

>>>>> On Fri, 9 Aug 1996 12:41:02 +0200, Yves Arrouye <[email-masked]> said:

> I have only one \q for my passwd, and it's in the log file too :-(.

I'm still scratching my head over the other oddities, but I've solved the "\q"
problem: first, it turns out that the switch is a toggle!  So, if you put two
"\q"'s in your script, the first one turns on quiet mode, the second one turns
it off!  This is basically a bug in the documentation, which makes it sound as
if you should put a "\q" at the start of each string you don't want logged.  I
put a \q at the start of my username only, and now both it and my password
show in the logs as "??????".  Second, you need to put the whole string in
single quotes, or the '\' character will be snarfed by the shell, and the
wrong string will be sent to the host.

-Randy

---

From: Guy Maor <[email-masked]>
Date: Fri, 9 Aug 1996 11:24:38 -0500 (CDT)

> I have only one \q for my passwd, and it's in the log file too :-(.

The \q option is a toggle switch, so the second \q turns logging back
on.  Move the second \q after the password.

btw, I had to read the chat source to discover this, so it's probably
reasonable to call it a bug in the man page.

Guy

---

From: Guy Maor <[email-masked]>
Date: Fri, 9 Aug 1996 11:24:38 -0500 (CDT)

Guy

---

From: Jean Orloff <[email-masked]>
Date: Mon, 12 Aug 1996 19:40:00 +0200

I'm still unsuccessfully fighting my chat problems reported over 2 weeks
ago. For memory:

# pppd connect 'chat -v ....'

fires ppp OK,
starts chat OK,
dials the correct number,
waits for '00',
find it in the 'CONNECT 28800' response from the modem

Then the chatscript sends a character over the line, and hopelessly waits for
the reply (a login prompt): just as if the line beyond the modem was cut.

I call this a chat problem because I can successfully do all this using
minicom, suspending minicom without reset, and start pppd without connect
option.

People suggested this could be a problem with my serial line configuration, but
no: I get the same problems if I just use minicom to setup the line, suspend
and fire pppd/chat.

With all the recent discussions about diald, I'll check there isn't an
interference coming from diald, but I am pessimistic. 

If I had courage, I would rewrite a chat clone in Perl...  But this problem has
cost me about 15h playing around during the last weeks, and my faith in myself
and debian is declining...

Amities,

		Jean Orloff
+++++++++	+	+	+	+	+	+	+	++++++
+ Tel:(33)50.09.16.75  Fax:(33)50.09.94.95  http://lapphp0.in2p3.fr/~orloff/ +
+++++++++	+	+	+	+	+	+	+	++++++
In a Rhodes tailor shop:
       Order your summers suit.  Because is big rush we will execute 
       customers in strict rotation.
+++++++++	+	+	+	+	+	+	+	+

---

From: Randy Gobbel <[email-masked]>
Date: Mon, 12 Aug 1996 11:29:50 -0700

>>>>> On Mon, 12 Aug 1996 19:40:00 +0200, Jean Orloff <[email-masked]>
>>>>> said:

> ago. [snip]

> the reply (a login prompt): just as if the line beyond the modem was cut.

Some ISPs require you to type a couple of carriage returns before they'll give
you a prompt.  To do this, put "\d\r\d\r\d\r" as the first send string.  A
single character may not be enough.

> If I had courage, I would rewrite a chat clone in Perl...  But this problem
> has cost me about 15h playing around during the last weeks, and my faith in
> myself and debian is declining...

Don't blame Debian for this, chat is simply flaky, and always has been, as far
as I can tell.  I used to use chat with MachTen, a Unix for the Mac, and had
very similar problems.  I can pretty much guarantee that chat won't work any
better with any other system.

I was having lots of trouble with chat, and am still meaning to fix it when I
have time.  Meanwhile, I looked at the source, and noticed a couple of buffers
that seemed awfully small.  I increased their size from 50 to 5000 characters,
and I haven't had any trouble with chat for a few days now.  So maybe that
worked, though I haven't looked at the code carefully enough to even know what
these buffers are for.

-Randy

NOTICE: I DO NOT ACCEPT UNSOLICITED COMMERCIAL EMAIL MESSAGES OF ANY KIND.  I
CONSIDER SUCH MESSAGES PERSONAL HARRASSMENT AND A GROSS INVASION OF MY
PRIVACY.  By sending unsolicited commercial advertising/solicitations (or
otherwise on or as part of a mailing list) to me via e-mail you will be
indicating your consent to paying John R. (Randy) Gobbel $1,000.00 U.S.D./hour
for a minimum of 1 hour for my time spent dealing with it. Payment due in 30
days upon receipt of an invoice (e-mail or regular mail) from me or my
authorized representative.

---

From: Jean Orloff <[email-masked]>
Date: Wed, 14 Aug 1996 12:40:33 +0200

>> After CONNECT, chat sends a character over the line, and hopelessly waits
 >> for the reply (a login prompt): just as if the line beyond the modem was
 >> cut.

>>>>> On Mon, 12 Aug 1996 11:29:50 -0700, Randy Gobbel <[email-masked]> answered:

 Randy> Some ISPs require you to type a couple of carriage returns before
 Randy> they'll give you a prompt.  To do this, put "\d\r\d\r\d\r" as the first
 Randy> send string.  A single character may not be enough.

Tilt, bingo, WAOOOW! "\d" was the solution!!!! Randy, I love you!!!

I had earlier tried sending muliple characters (eg "\r\r\r") to no avail. The
problem was then apparently that a delay is needed between the moment the modem
issues "CONNECT 28800" and the moment the ISP is ready to respond. Anything
sent in the meantime apparently fell in some bit bucket on the way... Of
course, this delay was easily satisfied when manually connecting with minicom:
human brain is sooo sssllloooowwww!

To summarize, the chat string example given in eg PPP-HOWTO:

       chat -v -l LCK..$DEVICE ABORT "NO CARRIER" ABORT BUSY "" ATZ OK\
          ATDT$PHONE CONNECT "" ogin: $USER ssword: \\q$PASSWORD

wouldn't work for me. But what would work contains a \d:

       chat -v -l LCK..$DEVICE ABORT "NO CARRIER" ABORT BUSY "" ATZ OK\
          ATDT$PHONE CONNECT '\d' ogin: $USER ssword: \\q$PASSWORD

The simple chat string example of the chat manpage

       '' ATZ OK ATDT5551212 CONNECT '' ogin: ppp ssword: hello2u2

would not work, whereas the more refined

       '' ATZ  OK ATDT5551212 CONNECT '' ogin:--ogin: ppp assowrd: hello2u2

would always fail on the first "ogin:" expect, but would probably work on the
second, provided the timeout is larger than my "minimum delay" (quite probable)

Finally, this is not a bug in chat: chat cannot see a difference between what
is generated by the local and remote modems. If anything, it might be a bug in
my modem that generates a CONNECT string before being really ready to transmit,
or to be nasty, in the docs that never mention this may happen.

It certainly was a bug in my mind: thanks for the debugging, Randy!

Amities,

		Jean Orloff
+++++++++	+	+	+	+	+	+	+	++++++
+Tel:(33)50.09.16.75   Fax:(33)50.09.94.95   http://lapphp0.in2p3.fr/~orloff/+
+++++++++	+	+	+	+	+	+	+	++++++
In a Norwegian cocktail lounge:
       Ladies are requested not to have children in the bar.
+++++++++	+	+	+	+	+	+	+	+