|
|
SMS Server Tools 3 Community |
Welcome, Guest. The forum is currently read-only, but will open soon. |
Wed Nov 06, 2024 02:10 |
This topic is locked
Page: 1
Author |
Post |
|
#1 Sun Dec 12, 2010 09:28, 169 months ago.
|
Member
Registered: Oct 2009
Location: Latvia
|
Operating system name and version: Debian on PPC Version of smsd: 3.1.14. Smsd installed from: sources Name and model of a modem / phone: Huawei E1752 Interface: USB It looks like modem runs well, but I tested it just by sending few SMSes. There are some minor errors are they significant? conf: # Example smsd.conf. Read the manual for a description
devices = GSM1 logfile = /var/log/smsd.log failed = /var/spool/sms/failed report = /var/spool/sms/report loglevel = 5 smart_logging = yes incoming_utf8 = yes
eventhandler = /usr/local/bin/smsd_eventhandler.sh checkhandler = /usr/local/bin/smsd_checkhandler.sh
incoming_utf8 = yes
date_filename = 2
#END GLOBAL DIRECTIVES
[GSM1] device = /dev/ttyUSB0 incoming = yes pin = XXXX
init = AT^CURC=0
#END GSM1 DIRECTIVES 'smsdconf' Syntax Highlight powered by GeSHi smd.log trouble.log
|
|
#2 Sun Dec 12, 2010 12:42, 169 months ago.
|
Administrator
Registered: May 2009
Location: Jyväskylä, Finland
|
Janeks wrote
If you enable statistics (install libmm, edit src/Makefile and recompile), you can get rid of this message. Janeks wrote
Right after smsd was started, the modem said "OK" even when it was not asked. Perhaps there was something remaining in the buffer when smsd was stopped, or some another process sent "AT" to the modem. Next day when smsd was restarted, there was no unexpected input, so this seems not to be a major problem. I think that you should do nothing for it. If this kind or any unexpected input is repeated, the reason should be found out. There is also a modem setting unexpected_input_is_trouble = no available, if you want to keep trouble log clean. However, this setting is meant to use if modem sends lot of unexpected input and it's known that it's not a problem. Janeks wrote
After the checkhandler was executed, you had a message file which had destination defined, but the message body was empty. If you are sure that the original file had a message body, you have some problem in checkhandler. Another reason could be that the process which creates outgoing files, creates them directly to the outgoing directory and works too slow. Therefore smsd handled file before it was complete. Files should be created to another directory in the same partition, and moved to the outgoing directory. It is also possible to create files with .LOCK extension or starting with LOCKED. In this case smsd will not handle files and they can be renamed after the writing is complete.
|
|
#3 Sun Dec 12, 2010 14:14, 169 months ago.
|
Member
Registered: Oct 2009
Location: Latvia
Topic owner
|
It seems from my tests that the last problem (smsd: The file /var/spool/sms/outgoing/send_xJ3059 has no text or data) caused by using accentuated characters in message body, by using sendsms? I did such tests from command line and when the first character was accentuated, than I got this message.
|
|
#4 Sun Dec 12, 2010 15:19, 169 months ago.
|
Administrator
Registered: May 2009
Location: Jyväskylä, Finland
|
I was assuming that accentuated characters were working in your system 5 weeks ago...
If you believe that sendsms does not work properly in your system, please do the following:
- Stop the smsd. - Create a message using sendsms. Show what you typed. - Show the outgoing message: hexdump -C < /var/spool/sms/outgoing/send_<random>
Assuming that message body is not empty, - Start the smsd. - Check how message is sent or failed to send.
If it's failed, show your current /usr/local/bin/smsd_checkhandler.sh.
|
|
#5 Sun Dec 12, 2010 17:19, 169 months ago.
|
Member
Registered: Oct 2009
Location: Latvia
Topic owner
|
The accentuated character conversion is working also now. The problem in sendsms or how my ssh client is translating accentuated characters: and the result file in outgoing folder is with empty text body.
|
|
#6 Sun Dec 12, 2010 18:03, 169 months ago.
|
Administrator
Registered: May 2009
Location: Jyväskylä, Finland
|
In ssh client you should use the same encoding as in the server, because in sendsms script "from" encoding is not defined and it defaults to servers encoding. With different encodings you will have another problems with other files too, when the encoding does not match.
If you cannot change the encoding in ssh client, you could create a copy of sendsms script and in this script define correct encoding for iconv using -f argument.
|
|
#7 Sun Dec 12, 2010 20:05, 169 months ago.
|
Member
Registered: Oct 2009
Location: Latvia
Topic owner
|
It looks like I successfully moved from old (damaged) Nokia N30 to Huawei E1752. For that I needed to install usb_modeswitch tool and also I used custom init string (see previous post).
Let's see what will happen in next week when it will have more SMSes to process.
|
|
#8 Mon Feb 07, 2011 09:05, 167 months ago.
|
Member
Registered: Oct 2009
Location: Latvia
Topic owner
|
Problems again, but I am not sure that it is smstools problem, because I had some problems with usb_modeswitch. But last time when I stopped sms3, than I could still access the modem, by Minicom. Here is the last lines of logs: smsd_trouble.log smsd.log « Last edit by Janeks on Mon Feb 07, 2011 09:08, 167 months ago. »
|
|
#9 Mon Feb 07, 2011 11:42, 167 months ago.
|
Administrator
Registered: May 2009
Location: Jyväskylä, Finland
|
It seems that the problem is caused by the PC, or usb driver, not by the modem. The modem answers, but the answer is not delivered to smsd. Therefore there are timeouts, and some time later the answer is received. Because the answer is late, it's shown as unexpected input.
Was your system working well for 8 weeks, or has those kind of errors happened all the time?
|
|
#10 Mon Feb 07, 2011 12:04, 167 months ago.
|
Member
Registered: Oct 2009
Location: Latvia
Topic owner
|
It worked for about 2-4 weeks, then hanged around once per week, than later - every couple of days. I can solve it temporary, by unpluging the USB stick, then back.
|
|
#11 Mon Feb 07, 2011 12:33, 167 months ago.
|
Administrator
Registered: May 2009
Location: Jyväskylä, Finland
|
Perhaps a log with loglevel = 7 might tell something interesting when this problem starts to happen. However, it seems that you have to fix the usb driver, but I do not know how to fix it in your case. If you want to, I could try to publish a simple circuit diagram of "unplugging" hardware, which can be used for automated unplugging.
|
This topic is locked
Page: 1
Time in this board is UTC.
|
|
|
|
|
|
|