Chatscript meets low expectations - PPP

This is a discussion on Chatscript meets low expectations - PPP ; 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' ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Chatscript meets low expectations

  1. Chatscript meets low expectations

    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


  2. Re: Chatscript meets low expectations

    juliansomers@googlemail.com writes:
    > '' AT
    > 'OK-+++\c-OK' "AT+WS45=4"

    [...]
    > 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. 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.

    > 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.

    > Here are the ppp options in effect:


    Not relevant. PPP isn't running at this point.

    > 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.

    > 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
    +++" 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.'

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  3. Re: Chatscript meets low expectations

    Thank-you for your very helpful reply.

    > juliansom...@googlemail.com writes:
    > > '' AT
    > > 'OK-+++\c-OK' "AT+WS45=4"

    > [...]
    > > 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. 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.

    >
    > 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.

    >
    > If it _does_ work, then more investigation is needed. A debug log
    > (using "-v" on the chat command line) would be interesting to see.
    >
    > > 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.
    >
    > > Here are the ppp options in effect:

    >
    > Not relevant. PPP isn't running at this point.


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

    >
    > > 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.
    >
    >> 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
    > +++" 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


  4. Re: Chatscript meets low expectations

    juliansomers@googlemail.com writes:
    > > same problem with the modem?
    > >
    > > Do exactly what the chat script does. Type AT. 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.)

    > 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.

    > 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.)

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  5. Re: Chatscript meets low expectations

    On 24 May 2006, in the Usenet newsgroup comp.protocols.ppp, in article
    <1148479036.406672.143220@j55g2000cwa.googlegroups. com>,
    juliansomers@googlemail.com wrote:

    >>> '' 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.

    >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

  6. Re: Chatscript meets low expectations

    juliansomers@googlemail.com writes:

    >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 '+++'.


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



    >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.


    ?? 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?



    >pppd version 2.4.3
    >kernel 2.6.11.12 on a VIA EPIA-M


    >Many thanks for your time,


    >Julian



  7. Re: Chatscript meets low expectations

    James Carlson writes:

    >juliansomers@googlemail.com writes:
    >> > same problem with the modem?
    >> >
    >> > Do exactly what the chat script does. Type AT. 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.)


    >> 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.


    >> 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.



  8. Re: Chatscript meets low expectations

    Unruh writes:
    > >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.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  9. Re: Chatscript meets low expectations

    On 28 May 2006, in the Usenet newsgroup comp.protocols.ppp, in article
    , James Carlson wrote:

    Happy Holiday!

    >Unruh writes:


    [James Carlson wrote]

    >>> 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.

    >>> (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.


    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.

    > - 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

+ Reply to Thread