SMS Server Tools 3
This site is hosted by Kekekasvi.com
 Menu
Basic information:
Additional information:
Support:
Get SMS Server Tools 3:
Additional Options

 Sponsored links

 Search
Custom Search

 Visitor locations
 
 SMS Server Tools 3 Community
Welcome, Guest. Please login or register. Sat May 25, 2024 11:16
SMSTools3 Community » Help and support Bottom

[answered] CMGL Handling Error

  This topic is locked

Page:  1

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

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.

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

Member
Registered:
Mar 2010
Location: Helsinki, Finland
Topic owner
I'll do loglevel 7 when I'm sending "mass-sms" next time.

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?

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

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

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!

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

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?

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

  This topic is locked

Page:  1

SMSTools3 Community » Help and support Top

 
Time in this board is UTC.  

Privacy Policy   SMS Server Tools 3 Copyright © Keijo Kasvi.