Operating system name and version: CentOS 5.2
Version of smsd: 3.0.10
Smsd installed from: N/A
Name and model of a modem / phone: iTegno GSM Modem 3800
Interface: USB

Hi! We have been having constant problems with our GSM Modem for the past few weeks. The GSM Modem suddenly stops running properly and have shown a put_command error. Please see the log below for details:

2009-09-11 10:49:10,6, GSM1: Modem is registered to the network 2009-09-11 10:49:10,6, GSM1: Selecting PDU mode 2009-09-11 10:49:10,7, GSM1: -> AT+CMGF=0 2009-09-11 10:49:10,7, GSM1: Command is sent, waiting for the answer 2009-09-11 10:49:11,7, GSM1: <- OK 2009-09-11 10:49:11,7, GSM1: -> AT+CMGS=154 2009-09-11 10:49:11,7, GSM1: Command is sent, waiting for the answer 2009-09-11 10:49:11,7, GSM1: <- > 2009-09-11 10:49:11,7, GSM1: -> PDU 1 (moved to private) 2009-09-11 10:49:12,7, GSM1: Command is sent, waiting for the answer 2009-09-11 10:49:16,7, GSM1: <- +CMGS: 0 OK 2009-09-11 10:49:16,5, GSM1: SMS sent, Message_id: 0, To: 6391788998xx 2009-09-11 10:49:16,6, GSM1: Sending SMS from to 6391788998xx 2009-09-11 10:49:16,7, GSM1: -> AT+CMGS=136 2009-09-11 10:49:16,7, GSM1: Command is sent, waiting for the answer 2009-09-11 10:49:16,7, GSM1: <- > 2009-09-11 10:49:16,7, GSM1: -> PDU 2 2009-09-11 10:49:16,7, GSM1: Command is sent, waiting for the answer 2009-09-11 10:49:21,7, GSM1: <- +CMGS: 1 OK 2009-09-11 10:49:21,5, GSM1: SMS sent, Message_id: 1, To: 6391788998xx 2009-09-11 10:49:21,6, GSM1: Moved file /var/spool/sms/checked/send_ok4702 to /var/spool/sms/sent 2009-09-11 10:49:22,6, GSM1: Splitting this message into 4 parts of max 153 characters. 2009-09-11 10:49:22,6, GSM1: I have to send 4 short message for /var/spool/sms/checked/send_Yi4710 2009-09-11 10:49:22,6, GSM1: Sending SMS from to 091788992xx 2009-09-11 10:49:22,7, GSM1: -> AT+CMGS=154 2009-09-11 10:49:22,7, GSM1: Command is sent, waiting for the answer 2009-09-11 10:49:22,7, GSM1: <- > 2009-09-11 10:49:22,7, GSM1: -> PDU 3 2009-09-11 10:49:23,7, GSM1: Command is sent, waiting for the answer 2009-09-11 10:49:53,7, GSM1: put_command expected (OK)|(ERROR), timeout occurred. 2009-09-11 10:49:53,7, GSM1: <- 2009-09-11 10:49:53,3, GSM1: The modem said ERROR or did not answer. 2009-09-11 10:49:53,5, GSM1: Waiting 10 sec. before retrying 2009-09-11 10:50:03,6, GSM1: Checking if modem is ready 2009-09-11 10:50:03,7, GSM1: -> AT 2009-09-11 10:50:03,7, GSM1: Command is sent, waiting for the answer 2009-09-11 10:50:03,7, GSM1: <- OK

PDU's:

Hidden private text.

On "2009-11-2009-09-11 10:49:21,5,", an SMS was sent successfully but the next transaction on "2009-09-11 10:49:53" a put_command error popped up.

After this put_command error, GSM Modem fails to send or receive messages. We have to resort to unplug the GSM Modem and restart the SMS service for it to work again. We tried replicating the error in our development server but we cannot pinpoint what's the main cause of this.

For extra reference, this is the contents of our config file:
devices = GSM1 outgoing = /var/spool/sms/outgoing checked = /var/spool/sms/checked failed = /var/spool/sms/failed incoming = /var/spool/sms/incoming sent = /var/spool/sms/sent logfile = /var/log/smsd.log mypath = /usr/local/bin loglevel = 9 #alarmhandler = /opt/smstools/alarmevent alarmlevel = 4 delaytime = 3 errorsleeptime = 10 #blocktime = 300 blocktime = 60 eventhandler = /opt/smstools/smsevent #stats = /var/log/smsd_stats #stats_interval = 3600 #stats_no_zeroes = no #blacklist = /etc/smsd.black #whitelist = /etc/smsd.white checkhandler = /opt/smstools/smscheck receive_before_send = no # autosplit 0=no 1=yes 2=with text numbers 3=concatenated autosplit = 3 internal_combine = yes validity = 167 # regular_run = /opt/smstools/sql2sms #regular_run_interval = 7 [GSM1] init = AT+CPMS="SM","SM" #device = /dev/ttyUSB0 device = /dev/ttyUSB1 #device = /dev/ttyS0 #device = /dev/usb/ttyUSB0 incoming = yes mode = new baudrate = 115200 #baudrate = 9600 # hardware handshake #rtscts = yes rtscts = no cs_convert = yes report = no memory_start = 1

We think rtscts being disabled is causing error but have no proof that it is.

Anyone have any ideas what is causing this problem and why the modem is not recovering from this error message?

Have you had some troubles with communication as handshaking is disabled? Usually it should be used, at least with high baudrates.

The message which has failed was tried to send to a national number. I think that's the reason for the problem. With 3.0.10, international format must always be used. As you are already using a checkhandler, you could use it to check the number and change the format.

If there are still problems, even when using international format, you can check the communication with the following changes to the smsd.conf:
pre_init = no
init = ATE1;+CPMS="SM","SM"

If the sending fails, compare the PDU strings sent to the modem and echoed from the modem. They should be equal and any difference means that communication has an error.

Quote from a new post:

Quote

Hi,

I raised an issue regarding a put_command() error we have been encountering frequently. This is on this post.

Unfortunately the thread was locked so I have opted to make a new one instead.

Sir Keke has advised that we turn on handshaking(rtscts) and change our numbers to international format (63917xxxxxxx). We have done so but put_command() error still occurs.

Does anyone have any other suggestions regarding this issue? Is this a bug with version 3.0.10 of SMSTools3?

I will post the latest logs of the put_command() error by next week.

Thanks!

This topic was not locked, probably there is some issue with a browser...

"Post reply" buttons are located in the same direction on the screen where "Post topic" buttons are (when logged in). Can you re-check if those buttons can be found? If they are still missing, please contact me via "Contact admin" form and send to me the source code of a page.

The error with a national number format was clear, but as this problem remains with international numbers too, latest logs will be interesting.

9-09-25 12:19:24,5, GSM1: SMS sent, Message_id: 210, To: 63917xxxxxxx 2009-09-25 12:19:24,6, GSM1: Sending SMS from to 63917xxxxxxx 2009-09-25 12:19:24,7, GSM1: -> AT+CMGS=32^M 2009-09-25 12:19:24,7, GSM1: Command is sent, waiting for the answer 2009-09-25 12:19:25,7, GSM1: <- AT+CMGS=32 > 2009-09-25 12:19:25,7, GSM1: -> PDU 1 2009-09-25 12:19:25,7, GSM1: Command is sent, waiting for the answer 2009-09-25 12:19:27,7, GSM1: <- PDU 1 echoed, correct +CMGS: 211 OK 2009-09-25 12:19:27,5, GSM1: SMS sent, Message_id: 211, To: 63917xxxxxxx 2009-09-25 12:19:27,6, GSM1: Moved file /var/spool/sms/checked/send_x15478 to /var/spool/sms/sent 2009-09-25 12:19:28,6, GSM1: Splitting this message into 2 parts of max 153 characters. 2009-09-25 12:19:28,6, GSM1: I have to send 2 short message for /var/spool/sms/checked/send_z15486 2009-09-25 12:19:28,6, GSM1: Sending SMS from to 63917xxxxxxx 2009-09-25 12:19:28,7, GSM1: -> AT+CMGS=154^M 2009-09-25 12:19:28,7, GSM1: Command is sent, waiting for the answer 2009-09-25 12:19:28,7, GSM1: <- AT+CMGS=154 > 2009-09-25 12:19:28,7, GSM1: -> PDU 2 2009-09-25 12:19:29,7, GSM1: Command is sent, waiting for the answer 2009-09-25 12:19:59,7, GSM1: put_command expected (OK)|(ERROR), timeout occurred. 2009-09-25 12:19:59,7, GSM1: <- PDU 2 echoed, correct 2009-09-25 12:19:59,3, GSM1: The modem said ERROR or did not answer. 2009-09-25 12:19:59,5, GSM1: Waiting 10 sec. before retrying 2009-09-25 12:20:09,6, GSM1: Checking if modem is ready 2009-09-25 12:20:09,7, GSM1: -> AT^M 2009-09-25 12:20:09,7, GSM1: Command is sent, waiting for the answer 2009-09-25 12:20:10,7, GSM1: <- OK T OK 2009-09-25 12:20:10,6, GSM1: Pre-initializing modem 2009-09-25 12:20:10,7, GSM1: -> ATE0+CMEE=1^M 2009-09-25 12:20:10,7, GSM1: Command is sent, waiting for the answer 2009-09-25 12:20:10,7, GSM1: <- ATE0+CMEE=1 OK

PDU's:

Hidden private text.

2009-09-25 12:19:27,5 -> SMS was sent

2009-09-25 12:19:59,7 -> SMS failed

Another observation is that Modem fails on multipart messages but this does not happen all the time.

Hmmm...

Both PDU's were echoed back correctly. The first PDU was a second part of a message containing two parts. That message was sent successfully. The second PDU was a first part of a message which was containing two parts too. The sending has failed. Probably three retries did not help, this is not shown in the log?

After a PDU 2 was echoed back, there was no CMGS answer. It's not sure if this was lost because of communication error, or if it was never sent by the modem. After sending has failed, there was, at 2009-09-25 12:20:10, strange answer from the modem ("T\n").

Quote

Is this a bug with version 3.0.10 of SMSTools3?

There has not been that kind of bug, at least not known to me. I also checked this using 3.0.10 and 3.2beta0(unreleased):
- text from your PDU 2 (part 1)
- some characters more so it goes to multipart
- your setting for validity (167) and report (no)

--> with both versions of the smsd, the PDU created was the same than yours (of course with a different destination number and information of concatenation). Messages were delivered successfully with a modem iTegno 3000 (USB, device based on Wavecom chip).

Quote

We have to resort to unplug the GSM Modem and restart the SMS service for it to work again.

I think it starts to feel that your modem is somehow broken. Probably it has a bad firmware.

Can you move to some another device, or if it does not help, to some another network provider?

Quote

The sending has failed. Probably three retries did not help, this is not shown in the log?

Actually, we just cut the log as it was repeating itself. On our count, it did retry three times - all with the same put_command() error.

As for 2009-09-25 12:20:10, no CMGS was being returned for the message_id because we always thought that the message failed to send and as such no message_id was being returned. is this assumption correct?

Quote

I think it starts to feel that your modem is somehow broken. Probably it has a bad firmware.

Can you move to some another device, or if it does not help, to some another network provider?

As for broken firmware, I have to confirm from our supplier if they have any updates to our modem's firmware. But currently, we already have three iTegno 3800s on hand and all of them are experiencing put_command() errors on this server alone. From the other servers we have not experienced this problem yet.

Can you provide a list of compatible hardware with SMS Tools 3 that are USB based?

Thanks!

brutalpanda wrote

As for 2009-09-25 12:20:10, no CMGS was being returned for the message_id because we always thought that the message failed to send and as such no message_id was being returned. is this assumption correct?

In many cases, but not always, an error code is received when sending fails. In this case no any response was received within a timeout (30 sec).

Quote

Quote

I think it starts to feel that your modem is somehow broken. Probably it has a bad firmware.

Can you move to some another device, or if it does not help, to some another network provider?

As for broken firmware, I have to confirm from our supplier if they have any updates to our modem's firmware. But currently, we already have three iTegno 3800s on hand and all of them are experiencing put_command() errors on this server alone. From the other servers we have not experienced this problem yet.

And the other servers are running smstools too and they are sending similar messages using the same SIM cards? Probably the problem still is in the interface, for example a poor cable or connector can cause transmission errors.

Quote

Can you provide a list of compatible hardware with SMS Tools 3 that are USB based?

There is no such kind of list available.

Yes they are also running SMS Tools 3 with similar setups. The only difference is they use different simcards. Is this a possible simcard error?

brutalpanda wrote

Yes they are also running SMS Tools 3 with similar setups. The only difference is they use different simcards. Is this a possible simcard error?

Probably yes, but this can also be an operator (network) depended issue.

Oops...

I just noticed that there was a bug in the board code: for users not logged in, every topic was marked as "locked". It was not intended, of course, and is now fixed.

I apologize...