Chatscript meets low expectations

[j***@googlemail.com]

Hi,

I have a modem here (it's a satellite phone (Nera Fleet 77)) that does
not work if I "expect" anything back from the modem in the chatscript.

If I use this chat:

TIMEOUT 8
ABORT 'BUSY'
ABORT 'NO ANSWER'
ABORT 'NO CARRIER'
ABORT 'NO DIALTONE'
ABORT 'NO DIAL TONE'
ABORT 'VOICE'
ABORT 'ERROR'
ABORT 'SERVICE AVAILABLE: NO'
'' AT
'OK-+++\c-OK' "AT+WS45=4"
TIMEOUT 40
OK ATDT12345
CONNECT ''

It never dials, as it does not reply 'OK' to my 'AT', or 'OK' to the
subsequent '+++'.

But If I take out the expect strings, it works:

TIMEOUT 8
ABORT 'BUSY'
ABORT 'NO ANSWER'
ABORT 'NO CARRIER'
ABORT 'NO DIALTONE'
ABORT 'NO DIAL TONE'
ABORT 'VOICE'
ABORT 'ERROR'
ABORT 'SERVICE AVAILABLE: NO'
'' AT
'' "AT+WS45=4"
TIMEOUT 40
OK ATDT12345
CONNECT ''

If I use minicom and just say 'AT', I get no response.

If I say 'AT+WS45=4' in minicom, I do get an 'OK'. (This AT command
initialises the modem for Inmarsat MPDS.)

After the 'AT+WS45=4', if I then say 'AT' again, I /do/ get an 'OK'.

I never get any response from '+++'.

Here are the ppp options in effect:

/dev/ttyS0
debug
ipparam dialup
115200
crtscts
receive-all
ipcp-accept-local
ipcp-accept-remote
asyncmap 0xa0000
noccp
novj
novjccomp
nodetach
noipdefault
defaultroute
usepeerdns
idle 0
user username
connect '/etc/wiredocean/chat_connect.sh'
disconnect '/etc/wiredocean/chat_disconnect.sh'

This is a generic chatscript that I use for several different devices,
including GPRS. (The init string and phone number only are changed for
each device). So I don't want to just get rid of the "OK-+++\c-OK"
expect string.

I've tried changing flow control parameters, to no avail.

I'd be most grateful if anyone has any ideas where to go from here. I
can't beleive the modem is this broken: I must be doing something
wrong. Of course, as the Nera support people are quick to assure me, it
Works With Windows.

pppd version 2.4.3
kernel 2.6.11.12 on a VIA EPIA-M

Many thanks for your time,

Julian

[James Carlson]

Post by j***@googlemail.com
'' AT
'OK-+++\c-OK' "AT+WS45=4"

[...]

Post by j***@googlemail.com
It never dials, as it does not reply 'OK' to my 'AT', or 'OK' to the
subsequent '+++'.

If you use miniterm (or some other terminal program), can you see the
same problem with the modem?

Do exactly what the chat script does. Type AT<Enter>. Then wait a
couple of seconds and type "+++". Does that produce an "OK" response?

If that procedure doesn't work with that modem, and it sounds like it
doesn't, then why would you expect it to work when a different program
(chat) does exactly the same thing? It sounds like the modem firmware
just has bugs. That's not terribly uncommon, and not something for
which chat itself can be held responsible.

If it _does_ work, then more investigation is needed. A debug log
(using "-v" on the chat command line) would be interesting to see.

Post by j***@googlemail.com
I never get any response from '+++'.

Sounds like a modem bug. How can 'chat' be blamed for problems in the
modem? I'm sort of confused about what sort of answer you're hoping
to get here.
Not relevant. PPP isn't running at this point.

Post by j***@googlemail.com
This is a generic chatscript that I use for several different devices,
including GPRS. (The init string and phone number only are changed for
each device). So I don't want to just get rid of the "OK-+++\c-OK"
expect string.

It sounds like you have to.

Frankly, I'm not sure that your chat script makes sense. It doesn't
look very robust on a number of fronts.

Here are a few suggestions:

- Try using "+++\d\dAT&F" as the initial string. You should *NOT*
have to send "+++" at all -- that's what DTR is for -- but if you
do (is the serial interface broken?), then following it up with a
valid AT command makes sense.

- Try using "AT&F" instead of just "AT". Setting the modem to some
known state is almost always better than just using whatever
random state the modem happens to be in.

- If you must do "OK-+++", consider adding an 'AT' command to that
middle (timeout-send) string to prompt the modem to say something.

Post by j***@googlemail.com
I'd be most grateful if anyone has any ideas where to go from here. I
can't beleive the modem is this broken: I must be doing something
wrong. Of course, as the Nera support people are quick to assure me, it
Works With Windows.

... which of course means nothing unless you're mimicking Windows
behavior _exactly_ with your chat script. Does Windows do the "AT
<wait> +++" dance with this modem that your chat script does? If not,
then "works with Windows" doesn't mean much here. You're doing
something different, and if the manufacturer's test criteria consists
of "must work with Windows," then 'different' is by their definition
'wrong.'

[j***@googlemail.com]

Thank-you for your very helpful reply.

Post by James Carlson

Post by j***@googlemail.com
'' AT
'OK-+++\c-OK' "AT+WS45=4"

[...]

Post by j***@googlemail.com
It never dials, as it does not reply 'OK' to my 'AT', or 'OK' to the
subsequent '+++'.

If you use miniterm (or some other terminal program), can you see the
same problem with the modem?
Do exactly what the chat script does. Type AT<Enter>. Then wait a
couple of seconds and type "+++". Does that produce an "OK" response?

No, I never get a response from anything until I have typed
'AT+WS45=4'. After this I get responses from common AT commands. I
never get any response from '+++' at any time.

Post by James Carlson
If that procedure doesn't work with that modem, and it sounds like it
doesn't, then why would you expect it to work when a different program
(chat) does exactly the same thing? It sounds like the modem firmware
just has bugs. That's not terribly uncommon, and not something for
which chat itself can be held responsible.

I certainly don't hold chat responsible! I hope that the subject line
'Chatscript meets low expectations' did not come across as 'I have low
expectations of chat'! I meant that it works without expect strings.
Sorry, very lame joke indeed.

Post by James Carlson
If it _does_ work, then more investigation is needed. A debug log
(using "-v" on the chat command line) would be interesting to see.

Post by j***@googlemail.com
I never get any response from '+++'.

Sounds like a modem bug. How can 'chat' be blamed for problems in the
modem? I'm sort of confused about what sort of answer you're hoping
to get here.
Not relevant. PPP isn't running at this point.

Ah. Very helpful point -- explains why changes to flow control settings
had no effect.

Post by James Carlson

Post by j***@googlemail.com
This is a generic chatscript that I use for several different devices,
including GPRS. (The init string and phone number only are changed for
each device). So I don't want to just get rid of the "OK-+++\c-OK"
expect string.

It sounds like you have to.
Frankly, I'm not sure that your chat script makes sense. It doesn't
look very robust on a number of fronts.
- Try using "+++\d\dAT&F" as the initial string. You should *NOT*
have to send "+++" at all -- that's what DTR is for -- but if you
do (is the serial interface broken?), then following it up with a
valid AT command makes sense.
- Try using "AT&F" instead of just "AT". Setting the modem to some
known state is almost always better than just using whatever
random state the modem happens to be in.
- If you must do "OK-+++", consider adding an 'AT' command to that
middle (timeout-send) string to prompt the modem to say something.

Post by j***@googlemail.com
I'd be most grateful if anyone has any ideas where to go from here. I
can't beleive the modem is this broken: I must be doing something
wrong. Of course, as the Nera support people are quick to assure me, it
Works With Windows.

... which of course means nothing unless you're mimicking Windows
behavior _exactly_ with your chat script. Does Windows do the "AT
<wait> +++" dance with this modem that your chat script does? If not,
then "works with Windows" doesn't mean much here. You're doing
something different, and if the manufacturer's test criteria consists
of "must work with Windows," then 'different' is by their definition
'wrong.'

I put +++ in the chatscript for GPRS. If a previous GPRS session is not
properly terminated (for instance, if the phone was simply unplugged),
then this resets it. I thought it wouldn't hurt to include it for all
devices. I guess this satphone just does not respond to +++ with an OK.

I've make the changes you've suggested, and will let you know after
testing with the various phones.

Many thanks,

Julian

[James Carlson]

Post by j***@googlemail.com

Post by James Carlson
same problem with the modem?
Do exactly what the chat script does. Type AT<Enter>. Then wait a
couple of seconds and type "+++". Does that produce an "OK" response?

No, I never get a response from anything until I have typed
'AT+WS45=4'. After this I get responses from common AT commands. I
never get any response from '+++' at any time.

It sounds like either a bug (or merely "quirk") in the modem firmware,
or something that's misconfigured with this modem.

Unfortunately, modems are cantankerous beasts. They're often very
low-cost high-integration affairs, and thus many have ad-hoc designs,
and the "standards" that apply for the various interfaces are
substantially less than air-tight. Seeing slightly (or even grossly)
different behaviors among brands, models, or even firmware revisions
is just par for the course.

This is why Windows has piles of special "INI" files to deal with
modems, and why almost all modems come with special "driver" disks
that the user must install. Modems aren't all the same, and hoping
for a single chat script to rule them all likely won't get you very
far. (To the extent that you've been able to make it work up until
now, you've just been lucky.)

Post by j***@googlemail.com
I put +++ in the chatscript for GPRS. If a previous GPRS session is not
properly terminated (for instance, if the phone was simply unplugged),
then this resets it. I thought it wouldn't hurt to include it for all
devices. I guess this satphone just does not respond to +++ with an OK.

"+++" (the old Hayes in-band break command) makes some sense only if
there's no DTR line hooked up to this modem, or the modem cannot be
convinced to do AT&D2 (go on-hook [hang up] on DTR deassertion).
Otherwise, it doesn't.

Note that having in-band signals active when you're trying to send
binary data over the modem is at best hazardous. Normally, PPP users
disable that sequence (by setting ATS2=255 or ATS2=128). If you can't
avoid it, well, then expect trouble. That attention sequence was
designed in the days of glass ttys and text dial-ins.

Decently designed modems just don't have this sort of problem. Using
something other than decently-designed equipment is sort of hard to
recommend, but I can understand that it's sometimes unavoidable.

Post by j***@googlemail.com
I've make the changes you've suggested, and will let you know after
testing with the various phones.

OK; good luck.

Getting some of those Windows initialization files and examining them
for clues (I think they're just plain text) might be helpful. (Of
course, they're copyrighted, I'm not a lawyer, this isn't legal
advice, and so on.)

[Unruh]

Post by James Carlson

Post by j***@googlemail.com

Post by James Carlson
same problem with the modem?
Do exactly what the chat script does. Type AT<Enter>. Then wait a
couple of seconds and type "+++". Does that produce an "OK" response?

No, I never get a response from anything until I have typed
'AT+WS45=4'. After this I get responses from common AT commands. I
never get any response from '+++' at any time.

It sounds like either a bug (or merely "quirk") in the modem firmware,
or something that's misconfigured with this modem.
Unfortunately, modems are cantankerous beasts. They're often very
low-cost high-integration affairs, and thus many have ad-hoc designs,
and the "standards" that apply for the various interfaces are
substantially less than air-tight. Seeing slightly (or even grossly)
different behaviors among brands, models, or even firmware revisions
is just par for the course.
This is why Windows has piles of special "INI" files to deal with
modems, and why almost all modems come with special "driver" disks
that the user must install. Modems aren't all the same, and hoping
for a single chat script to rule them all likely won't get you very
far. (To the extent that you've been able to make it work up until
now, you've just been lucky.)

Post by j***@googlemail.com
I put +++ in the chatscript for GPRS. If a previous GPRS session is not
properly terminated (for instance, if the phone was simply unplugged),
then this resets it. I thought it wouldn't hurt to include it for all
devices. I guess this satphone just does not respond to +++ with an OK.

"+++" (the old Hayes in-band break command) makes some sense only if
there's no DTR line hooked up to this modem, or the modem cannot be
convinced to do AT&D2 (go on-hook [hang up] on DTR deassertion).
Otherwise, it doesn't.
Note that having in-band signals active when you're trying to send
binary data over the modem is at best hazardous. Normally, PPP users
disable that sequence (by setting ATS2=255 or ATS2=128). If you can't
avoid it, well, then expect trouble. That attention sequence was
designed in the days of glass ttys and text dial-ins.
Decently designed modems just don't have this sort of problem. Using
something other than decently-designed equipment is sort of hard to
recommend, but I can understand that it's sometimes unavoidable.

Post by j***@googlemail.com
I've make the changes you've suggested, and will let you know after
testing with the various phones.

OK; good luck.
Getting some of those Windows initialization files and examining them
for clues (I think they're just plain text) might be helpful. (Of
course, they're copyrighted, I'm not a lawyer, this isn't legal
advice, and so on.)

If there is only one way of accomplishing a task or expressing an idea,
then copyright does not apply.

[James Carlson]

Post by Unruh

Post by James Carlson
Getting some of those Windows initialization files and examining them
for clues (I think they're just plain text) might be helpful. (Of
course, they're copyrighted, I'm not a lawyer, this isn't legal
advice, and so on.)

If there is only one way of accomplishing a task or expressing an idea,
then copyright does not apply.

A couple of comments:

- The poster might not be in Canada, so what works there may not
work where he lives. I'd suggest being careful in giving out
legal advice, even if this is only usenet.

- I can think of _lots_ of ways to express a modem init string to
get at a particular goal. The information in the Windows INI
files is just one example.

In any event, I was just trying to warn the reader that he's skating
off onto the ice. It's up to him to gauge the thickness.

[Moe Trin]

On 28 May 2006, in the Usenet newsgroup comp.protocols.ppp, in article
<***@sun.com>, James Carlson wrote:

Happy Holiday!
[James Carlson wrote]

Post by James Carlson

Post by Unruh

Post by James Carlson
Getting some of those Windows initialization files and examining them
for clues (I think they're just plain text) might be helpful.

The windoze equivalent of 'chat -v' is to create a modem log. The website
I mentioned (http://www.modemsite.com/56k/modemlog2k.asp) tells how to do
this by finding the right pull-down menu item. Briefly, it is something
like "Go to Control Panel/Modems/Properties/Connection/Advanced. Check
Record a log file." Only problem is that windoze is _EXTREMELY_ wordy,
and the resulting log filename is not consistent. There is also a means of
creating a ppp log (vaguely along the idea of -debug) but in line with the
microsoft "Baffle 'em with Bullsh!t" mode, the log is not translated from
the raw hex. I usually hope that Patrick Klos is reading the group when
one of those logs comes along.

Post by James Carlson

Post by Unruh

Post by James Carlson
(Of course, they're copyrighted, I'm not a lawyer, this isn't legal
advice, and so on.)

If there is only one way of accomplishing a task or expressing an idea,
then copyright does not apply.

- The poster might not be in Canada, so what works there may not
work where he lives. I'd suggest being careful in giving out
legal advice, even if this is only usenet.

NNTP-Posting-Host: 193.252.16.47

193.252.0.0 - 193.252.63.255 France Telecom
193.252.16.0 - 193.252.17.31 GlobeCast Nothern Europe (GB) globecast.com

I dunno - France, or the UK. No PTR record on the address.

Post by James Carlson
- I can think of _lots_ of ways to express a modem init string to
get at a particular goal. The information in the Windows INI
files is just one example.

Again - the classic windoze snow-job. The init strings often consist of
setting the factory default (AT&F?) and then another 80 characters restating
the defaults, such as 'B0E0F1M1L2Q0V1&C1&D0' and so on. For non-POTS modems
which follow the Hayes standard much as a codfish follows migrating caribou,
this is often the only way to find out WTF it takes to get the thing to work.

Old guy

[Moe Trin]

On 24 May 2006, in the Usenet newsgroup comp.protocols.ppp, in article

Post by j***@googlemail.com

Post by j***@googlemail.com
'' AT
'OK-+++\c-OK' "AT+WS45=4"

No, I never get a response from anything until I have typed
'AT+WS45=4'. After this I get responses from common AT commands. I
never get any response from '+++' at any time.

That extremely ancient script (check the file date in the distribution
package - Oct 16 12:25 1995) is pretty useless by current standards.
The original sequence says "wait for nothing" then send "AT" which is
the Hayes command prefix - no command, just the prefix. Many modems
will reply to an empty command with 'OK' _if_ they are initialized.
The "OK-+++\c-OK" sequence says to expect an OK, but if you don't
get one in the alloted timeout, send +++ which is the default Hayes
modem 'escape to command mode' string (the \c prevents sending a
carriage-return character which is not part of the command). This
is great if your modem obeys the Hayes standard commands, but even
Hayes did not follow that standard.

Post by j***@googlemail.com
I put +++ in the chatscript for GPRS. If a previous GPRS session is not
properly terminated (for instance, if the phone was simply unplugged),
then this resets it. I thought it wouldn't hurt to include it for all
devices. I guess this satphone just does not respond to +++ with an OK.

Normally, you are told to "Read The Fine Manual" for the modem, and see
what commands it uses, but a lot of the manuals are more interested in
telling you to not use the telephone while riding your bicycle under water
(or similar obvious suggestions). If you actually have windoze on a
computer, see http://www.modemsite.com/56k/modemlog2k.asp

I don't like the "OK-+++\c-OK" concept. If the modem is keeping the
line up or the telephone off the hook, I'd rather learn about this
problem now than wait until the end of the month when I am billed for
a 730 hour long call I didn't make.

Old guy

[Unruh]

Post by j***@googlemail.com
Hi,
I have a modem here (it's a satellite phone (Nera Fleet 77)) that does
not work if I "expect" anything back from the modem in the chatscript.
TIMEOUT 8
ABORT 'BUSY'
ABORT 'NO ANSWER'
ABORT 'NO CARRIER'
ABORT 'NO DIALTONE'
ABORT 'NO DIAL TONE'
ABORT 'VOICE'
ABORT 'ERROR'
ABORT 'SERVICE AVAILABLE: NO'
'' AT
'OK-+++\c-OK' "AT+WS45=4"
TIMEOUT 40
OK ATDT12345
CONNECT ''
It never dials, as it does not reply 'OK' to my 'AT', or 'OK' to the
subsequent '+++'.
TIMEOUT 8
ABORT 'BUSY'
ABORT 'NO ANSWER'
ABORT 'NO CARRIER'
ABORT 'NO DIALTONE'
ABORT 'NO DIAL TONE'
ABORT 'VOICE'
ABORT 'ERROR'
ABORT 'SERVICE AVAILABLE: NO'
'' AT
'' "AT+WS45=4"
TIMEOUT 40
OK ATDT12345
CONNECT ''
If I use minicom and just say 'AT', I get no response.
If I say 'AT+WS45=4' in minicom, I do get an 'OK'. (This AT command
initialises the modem for Inmarsat MPDS.)
After the 'AT+WS45=4', if I then say 'AT' again, I /do/ get an 'OK'.
I never get any response from '+++'.

The faces of incompetence are many and varied. This surprises you?

Post by j***@googlemail.com
/dev/ttyS0
debug
ipparam dialup
115200
crtscts
receive-all
ipcp-accept-local
ipcp-accept-remote
asyncmap 0xa0000
noccp
novj
novjccomp
nodetach
noipdefault
defaultroute
usepeerdns
idle 0
user username
connect '/etc/wiredocean/chat_connect.sh'
disconnect '/etc/wiredocean/chat_disconnect.sh'
This is a generic chatscript that I use for several different devices,
including GPRS. (The init string and phone number only are changed for
each device). So I don't want to just get rid of the "OK-+++\c-OK"
expect string.
I've tried changing flow control parameters, to no avail.
I'd be most grateful if anyone has any ideas where to go from here. I
can't beleive the modem is this broken: I must be doing something
wrong. Of course, as the Nera support people are quick to assure me, it
Works With Windows.

?? It is broken. You know how to get around that.
So do.
I suspect if you sent it any command ATH say instead of AT it would
respond. So send it an command.

Why would you want to spend immense amounts of time battling incompetence?

Post by j***@googlemail.com
pppd version 2.4.3
kernel 2.6.11.12 on a VIA EPIA-M
Many thanks for your time,
Julian