Author |
Post |
|
#1 Tue Mar 23, 2010 05:13, 171 months ago.
|
Member
Registered: Mar 2010
Location: Helsinki, Finland
|
Operating system name and version: Solaris 10 Version of smsd: 3.1.5 Smsd installed from: sources Name and model of a modem / phone: Siemens MC35i Interface: serial
I was sending 40 SMS's to different phone numbers, I got 3-4 of these messages into log:
CMGL handling error: Line end not found (PDU) Unexpected input: +CMGL: 16,0,,167 +CMGL: 17,0,,167 +CMGL: 22,0,,167
What does that actually mean? Didn't I terminate the textfile correctly while editing it in vi?
|
|
#2 Tue Mar 23, 2010 10:02, 171 months ago.
|
Administrator
Registered: May 2009
Location: Jyväskylä, Finland
|
I think that the format of an outgoing textfile is not a reason for this.
I assume that you have used check_memory_method 31 successfully, at least when there has not been continuous outgoing traffic. Is that correct?
The format of CMGL answer should be: +CMGL: <index>,<stat>,[<alpha>],<length> <pdu> [...] OK
Now there is at least the line end missing, but that "Unexpected input:" also looks strange. Was it printed by the smsd? If so, the modem did not give the whole list when it was asked. After a communication continued, remaining entries were received and that's an unexpected input.
Have you used the setting report = yes, or header Report: yes?
I'm not sure if I have understood this error correctly. The missing PDU is problematic, but probably there has also been a timeout when waiting for the CMGL list. Probably a piece of log with loglevel 7 will help to resolve this problem. If you think that you can show the log, you can use Private tags to protect it.
|
|
#3 Tue Mar 23, 2010 10:34, 171 months ago.
|
Member
Registered: Mar 2010
Location: Helsinki, Finland
Topic owner
|
Hidden private text. Yes, I used check_memory_method = 31 and report = yes options. « Last edit by Sallinen on Tue Mar 23, 2010 10:36, 171 months ago. »
|
|
#4 Tue Mar 23, 2010 10:40, 171 months ago.
|
Administrator
Registered: May 2009
Location: Jyväskylä, Finland
|
Thanks. Those PDU's are status reports, and probably routed which should be disabled. I'll check that soon.
You have not used loglevel = 7, so I cannot check the "line end missing" issue...
|
|
#5 Tue Mar 23, 2010 10:42, 171 months ago.
|
Member
Registered: Mar 2010
Location: Helsinki, Finland
Topic owner
|
I'll do loglevel 7 when I'm sending "mass-sms" next time.
|
|
#6 Tue Mar 23, 2010 11:02, 171 months ago.
|
Administrator
Registered: May 2009
Location: Jyväskylä, Finland
|
Ok, I'll look forward.
Can you check the current setting of new SMS message indications:
Stop the smsd if it's running. Start it in communication mode: smsd -C GSM1 Follow the instructions on screen. Type ATE1 (and Enter) to set echo on. Type AT+CNMI=? And then AT+CNMI?
What are the results?
|
|
#7 Tue Mar 23, 2010 11:05, 171 months ago.
|
Member
Registered: Mar 2010
Location: Helsinki, Finland
Topic owner
|
AT+CNMI=? +CNMI: (0-3),(0,1),(0,2,3),(0,2),(1)
OK AT+CNMI? +CNMI: 0,0,0,0,1
|
|
#8 Fri Apr 23, 2010 08:49, 170 months ago.
|
Administrator
Registered: May 2009
Location: Jyväskylä, Finland
|
The initialization for MC35i could be init = AT+CNMI=2,0,0,2,1. I have been waiting for a new log file with loglevel = 7. Is this problem still active, and do you have such kind of a log? Or is the problem resolved, or have you stopped using SMSTools3 and MC35i?
|
|
#9 Fri Apr 23, 2010 08:56, 170 months ago.
|
Member
Registered: Mar 2010
Location: Helsinki, Finland
Topic owner
|
Ah I had almost forgotten the issue :-D We will be having scheduled maintenance tomorrow and I will be informing our users by SMS, so I will try the new init-string and loglevel 7 when sending the mass SMS tomorrow - I'll post the log. And no, we won't be quittig on MC35i and SMSTools, best combo ever!
|
|
#10 Mon Jun 21, 2010 13:57, 168 months ago.
|
Member
Registered: Mar 2010
Location: Helsinki, Finland
Topic owner
|
Continued from my last topic, which has been now marked as inactive (We don't send mass sms's that often Here's an private link to Keke to our sms.log with log-level 7. Hidden private text. It seems that after sending out +30 2-part SMS's we are unable to receive SMS, ie. no status reports received or anything :O
|
|
#11 Mon Jun 21, 2010 17:08, 168 months ago.
|
Administrator
Registered: May 2009
Location: Jyväskylä, Finland
|
Okay, I re-opened last topic and moved your post here.
With a quick view, if you move back to the default of check_memory_method, handling of incoming messages will work, even when I told before that method 31 is better. With the current method, data from modem comes too slow and timeout is reached. Also, the size of receiving buffer looks too small, I probably must increase it, or change the handling of incoming data.
I will check your log more deeply tomorrow.
Can you show what kind of smsd.conf you are currently using, it might be useful when checking the log?
|
|
#12 Mon Jun 21, 2010 20:17, 168 months ago.
|
Member
Registered: Mar 2010
Location: Helsinki, Finland
Topic owner
|
yeah, here we go: devices = GSM1 outgoing = /var/spool/sms/outgoing checked = /var/spool/sms/checked failed = /var/spool/sms/failed sent = /var/spool/sms/sent incoming = /var/spool/sms/incoming logfile = /var/log/smsd.log loglevel = 5 checkhandler = /opt/gnu/share/smstools/scripts/checkhandler-multirecip [GSM1] device = /dev/cua/b incoming = yes check_memory_method = 31 # init = AT+CPMS="SM" init = AT+CPMS="MT","MT","MT" pin = 1234 hangup_incoming_call = yes report = yes ps. commented #check_memory_method, aka. moved to default one and all the status reports we're received properly! « Last edit by Sallinen on Mon Jun 21, 2010 20:19, 168 months ago. »
|
|
#13 Wed Jun 23, 2010 12:12, 168 months ago.
|
Administrator
Registered: May 2009
Location: Jyväskylä, Finland
|
Because you now have a working setup, I do not yet publish any changes to the smsd.
Even when using baudrate 115200, the data is received too slow. There is a setting available for the timeout, but it will not help you. Currently smsd wants to get all of the data in the given time. I have to change it slightly: after nothing is received in the given time, timeout is reached, and if something is received after waiting, the counting starts from zero.
Usually the check_memory_method 31 can handle about 100 messages. In your case the problem is caused by the modem as it sends reports with a large number of F's as padding. The report itself is below 100 characters, and the padding is almost 300 characters. Because of this, the buffer used for receiving is too small. I probably make it changeable, or dynamic, but as said, not right now.
|