I am having a little trouble dialing out with my GSM modem with pppd, and I cannot understand why. The script I am passing to chat goes as follows:

I am having it expect DIALING because I will then immediately step in an send AT#CONNECTIONSTOP manually (this is just for test purposes: once I have it working, I will have it expect CONNECTED, and will pick a more useful number for AT#DIALN1). If I use these AT commands manually (through minicom) everything works as expected, but when I use pppd (and check /var/log/messages), it steps through each of these lines as expected, but chat quits after the final line, AT#CONNECTIONSTART, returns an error code (which translates to `the product is not registered on the network'). I get the same error code if I do not set AT+CPIN, however, if I add the line `AT+CPIN? READY' before `AT#CONNECTIONSTART DIALING', then it continues onto attemting to connect (suggesting the PIN has been accepted).

Because this all works perfectly fine when I do it manually, I cannot understand what would be different now. I thought maybe it would be that they are entered too quickly here, but I added a line of `\p\p\p\p\p\p\p\p\p\p ""' between each AT command, so as to give them a good pause, but it did not seem to have any effect (and it would not make sense that they would return OK before they were done).

I am pretty stumped on this one, so any suggestions would be greatfully received.

PS If AT+CPIN has already been set, then I do not need to set it again (indeed, attempting to will return ERROR rather than OK). Is there any way with chat scripts to make a conditional (eg if 'AT+CPIN? SIM PIN' then 'AT+CPIN=xxxx')?

By adding \d to the front of each AT command, I was able to get it to successfully dial, but I still have that issue with requiring a conditional. I read about subscripts in chat scripts, but did not really understand it. The situatin I have is like this:

`AT+CPIN?' will return either `SIM PIN' or `READY'. If it returns READY, I just want to continue with the rest of the script, but if it returns SIM PIN then I want to send 'AT+CPIN=xxxx', and I expect to see an `OK' return from this. Could someone show me how to write this, as I have not been able to follow the description of subscripts (and have not seen any useful examples).

They say it's better late than never, so here's a quick (& somewhat dirty) suggestion for the "conditional" sending of the PIN to the modem.

'chat' is very limited in control flow, by reading the man page the best solution i could figure was to ALWAYS send the PIN and use the "subexpect-subsend" option. This is how it goes:

### chatscript

""
ATZ OK
#send pin
AT+CPIN=1234 TIMEOUT 5 ERROR-AT-OK
AT+CGDCONT=1,"IP","kolbi3g","0.0.0.0",0,0 OK
ATDT*99#
### end chatscript


With my modem, a Huawei 1556 (internally a E620 according to lsusb) if the sim is not locked, then the command to send the pin, "AT+CPIN=1234" will unlock it and return "OK", meanwhile if it was already unlocked by some previous use, the "AT+CPIN=1234" would return "ERROR".

Thus the logic is as follows: the script always sends the command, expecting "ERROR" (assuming the modem was previously unlocked).

If the modem was unlocked, it will respond with "ERROR" and everything will be fine, the -AT-OK part will be ignored and execution will continue with the AT+CGDCONT...

If the modem was locked, then it will respond with "OK" (which is wrong from chat's point of view, since it expected "ERROR", but this will unlock the modem anyway!). Since chat got a bad response it will tend to terminate with an error, but having the optional "-AT-OK" keeps it from dying and allows it to continue. A "send AT expect OK" should be harmless anyway

The TIMEOUT 5 is in order to accelerate the time before the optional part (AT-OK) is executed, otherwise the default is 45 seconds which is kind of too much. Since whenever the sim is really unlocked by the command, execution is stopped by 5 seconds, it has the (accidental) added benefit of giving the device enough time to hook onto the 3G network.

(this solution reminds me of badly written programs who abuse function side effects to carry out their logic in an unclear way...but hey)

When i have some time i will check the "expect" program which apparently allows "complex" (in terms of logic) scripts.