|
|
| SMS Server Tools 3 Community |
| Welcome, Guest. The forum is currently read-only, but will open soon. |
Tue Jul 01, 2025 10:25 |
Page: 1
| Keywords: Mode: All keywords (AND) |
|
Sun Sep 29, 2013 17:33
|
polarlight: hi MareAlta,
Below you can find my smsd.conf. The init-string parts seem to be:
init = ATE0+CPMS="ME"
init2 = AT+CNMI=3,1,0,0,0
--------------------------------- /etc/smsd.conf
#
# /etc/smsd.conf
#
# Description: Main configuration file for the smsd
#
devices = GSM1
outgoing = /var/spool/sms/outgoing
checked = /var/spool/sms/checked
incoming = /var/spool/sms/incoming
logfile = /var/log/smstools/smsd.log
infofile = /var/run/smstools/smsd.working
pidfile = /var/run/smstools/smsd.pid
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
stats = /var/log/smstools/smsd_stats
#loglevel = 7
#delaytime = 10
#errorsleeptime = 10
#blocktime = 3600
#stats = /var/log/smsd_stats
#stats_interval = 3600
#stats_no_zeroes = no
#checkhandler = /usr/local/bin/smscheck
receive_before_send = no
# autosplit 0=no 1=yes 2=with text numbers 3=concatenated
autosplit = 3
# store_received_pdu 0=no, 1=unsupported, 2=unsupported and 8bit, 3=all
#store_received_pdu = 1
#validity = 255
#decode_unicode_text = no
#internal_combine = no
# You can specify here an external program that is started whenever an alarm occurs.
# alarmhandler = /path/to/an/alarmhandler/script
# Specifies what levels start an alarmhandler. You can use value between 2 and 5.
# alarmlevel = 4
# eventhandler = @EVENTHANDLER@
#blacklist = /etc/smstools/blacklist
#whitelist = /etc/smstools/whitelist
#[queues]
# Commented lines are examples for germany
# D1 = /var/spool/sms/D1
# D2 = /var/spool/sms/D2
# O2 = /var/spool/sms/O2
# EPLUS = /var/spool/sms/EPLUS
# QUAM = /var/sppol/sms/QUAM
# MOBILCOM = /var/spool/sms/MOBILCOM
#OTHER = /var/spool/sms/OTHER
#[provider]
# Commented lines are examples for germany
# D1 = 49160, 49170, 49171, 49175, 49151
# D2 = 491520, 49162, 49172, 49173, 49174
# O2 = 49176, 49179, 49159
# EPLUS = 49163, 49177, 49178, 49157
# QUAM = 49150
# MOBILCOM = 49156
#OTHER = 0,1,2,3,4,5,6,7,8,9
[GSM1]
#init = ATE0+CPMS="SM"+CNMI=2,0,0,2,1 2,0,0,1,0 3,2
# by default ZTE636+ has AT+CNMI 3,1,0,0,0 which gives indcation like: +CMTI: "ME",3
init = ATE0+CPMS="ME"
init2 = AT+CNMI=3,1,0,0,0
# # Windows: /dev/com1, Solaris: /dev/cua/a, Linux /dev/ttyS0
device = /dev/ttyUSB2
incoming = yes
# queues = OTHER
# You don't need a PIN for mobile phones
# pin = ***
# mode = new
# smsc = ********
smsc = 358405202000
baudrate = 19200
check_memory_method = 2
# rtscts = yes
cs_convert = yes
# report = no
# memory_start = 1
# primary_memory = memory name
# secondary_memory = memory name
# secondary_memory_max = number
# pdu_from_file = /var/spool/sms/GSM1-PDU
sending_disabled = no
# decode_unicode_text = no
# internal_combine = no
#
#[GSM2]
#init = ATE0
# Windows: /dev/com2, Solaris: /dev/cua/b, Linux /dev/ttyS1
#device = /dev/ttyS1
#incoming = yes
#queues = OTHER
#You don't need a PIN for mobile phones
#pin = ****
#mode = new
#smsc = 491710760000
#baudrate = 19200
#rtscts = yes
#cs_convert = yes
#report = no
#memory_start = 1
#primary_memory = memory name
#secondary_memory = memory name
#secondary_memory_max = number
#pdu_from_file = /var/spool/sms/GSM2-PDU
#sending_disabled = no
#decode_unicode_text = no
#internal_combine = no
#[GSM1]
#init =
#device = /dev/ttyUSB2
#incoming = yes
#pin =
#baudrate = 19200
|
|
Sat Dec 15, 2012 14:01
|
polarlight: hi,
As a quite generic thing, we developers often forget to remain consistent - me included. It is just a part of human nature to do the same thing differently each time. If this does not get fixed along time with Smstools then I hope at least the world becomes a little more better (logical at least!) if at least some readers and we all developers note this.
I think naming conventions are much more important than most of people think. To maintain consistent naming makes both development time and runtime usage much more straightforward.
These different names below instead of just "smstools" everywhere are an example showcase what should be avoided in my opinion. When saying this, I perfectly understand that these have probably just accumulated over time and it is certainly not current main developer's fault that it is the way like it is now.
Software home page: SMS Server tools 3
Package name: smstools
service management name: sms3
service binary executable name: smsd
runtime configuration file: /etc/sms.conf
log-folder name: /var/log/smstools
data (spool) folder name: /var/spool/sms
Alternative, and I would say very consistend naming situation could be for example:
Software home page: SMS Tools 3
Package name: smstools
service management name: smstools
service binary executable name: smstoolsd
runtime configuration file: /etc/smstools.conf
log-folder name: /var/log/smstools
data (spool) folder name: /var/spool/smstools
With "service management name" I mean the name you
use in service management commands like "service sms3 start".
This is just a positive suggestion/idea. Feel free to use/improve or leave like it is as probably too many other software has dependencies to current naming convention -- which is also the argument why naming should be well thought before there are popular releases.
|
|
Sun Nov 25, 2012 13:18
|
polarlight: It looks like this got fixed in 3.1.15 as at least now I got sending working with the exactly same /etc/smsd.conf that it was not working with 3.1.14.
So download the newest one and build it from source unless it is already available as a binary package. See one other Help-forum post about sending problems for more detailed explanation.
|
|
Sun Nov 25, 2012 13:14
|
polarlight: I confirm that for my part this problem seems to been solved in 3.1.15. I did not yet test receiving, but at least sending worked with the same smsd.conf I have had earlier.
I downloaded the 3.1.15 tar.gz-package and built it manually in just a couple of weeks ago shipped Raspberry Pi (Debian Wheezy).
However, it was not enough to have only these install steps:
make
make install
Additionally I had to manually create these directories
/var/spool/sms/failed
/var/spool/sms/sent
/var/log/smstools/smsd_stats
and of course modify the /etc/smsd.conf to match my system.
The service could be started in Debian wheezy manually after those mods like this:
/etc/init.d/sms3 start
Check also that your service is installed so that it automatically starts after boot.
Additional info about my setup:
---------------------------------
I have ZTE-MF636+ USB stick modem and it requires the use of usb-modeswitch package
with this config added into /etc/usb_modeswitch.conf after the last line of default content:
########################################################
# ZTE MF622 (aka "Onda MDC502HS")
# ZTE MF626
# ZTE MF628+ (tested version from Telia / Sweden)
# ZTE MF633
# ZTE MF636 (aka "Telstra / BigPond 7.2 Mobile Card")
# ZTE MF637
# and probably others not listed here
#
# Contributor: Joakim Wennergren and others
DefaultVendor= 0x19d2
DefaultProduct= 0x2000
TargetVendor= 0x19d2
TargetProduct= 0x0031
MessageContent="5553424312345678000000000000061e000000000000000000000000000000"
MessageContent2="5553424312345679000000000000061b000000020000000000000000000000"
NeedResponse=1
|
|
Sat Sep 22, 2012 12:25
|
polarlight: Just additional information: the "check_memory_method = 2" is probably in a wrong value here but currently I don't know what is the correct value as I just noticed this issue.
|
|
Sat Sep 22, 2012 12:23
|
polarlight: Ok, the case was solved for you, but the problem still exists and the cause is not explained.
I just wrote a new post with similar observations from 3.1.14.
The setup with 3.1.11 I had earlier is not working anymore in a similar machine with 3.1.14 with the same modem even though the two-way serial communication with the modem works and reception of SMS-messages work too.
If anybody has an explanation, please let the rest of the world know.
|
|
Sat Sep 22, 2012 12:11
|
polarlight: Based on the log above I noticed that my "check_memory_method=2" ( http://smstools3.kekekasvi.com/index.php?p=configure#m_check_memory_method ) is probably wrong and should be set to some other value but I think it is not playing a role here as that was wrong with the previous setup as well.
Clarification: when I mentioned "sending a test message" which was received ok, I was referring to sending a test message from my phone to this USB modem. That was received OK by the USB modem and smstools.
Unless there is somewhere already a good diagnostic log or other status info available about the smstools sending status and about beginning sending attempts (such as "New outgoing msg noticed. Selected processing: rejected|starting sending"), including that sending is disabled by a user setting, I would wish you'd add such a logging/indication feature. If only reporting failure after the sending attempt, you miss the chance to find your configuration/setup error quickly. In this case I assume I just have some critical setting wrong.
|
|
Sat Sep 22, 2012 11:35
|
polarlight: Operating system name and version: RaspberryPi2 / Debian Wheezy Raspian
Version of smsd: Smsd v3.1.14
Smsd installed from: package repository of RaspberryPi2
Name and model of a modem / phone: (USB-stick) ZTE MF636+
Interface: USB
I had previously a completely working SMSTOOLS setup in Debian Squeeze running in TuxRail SBC with Smsd v3.1.11. I am now migrating this system now into RaspberryPi 2 SBC (single board computer) and the Smsd version from RaspberryPi repo is 3.1.14. Both are basicly headless embedded ARM-based computers so I access them via ssh commandline interface only.
This ZTE MF636+ requires the usb-modeswitch package to be used to unload the default mass memory profile and turn on the serial port modem-mode and I have that installed in the new rig too. After using modeswitch, the serial ports of ZTE MF636+ /dev/ttyUSB0.../dev/ttyUSB2 appear in the system. It was the /dev/ttyUSB2 that had to be configured for smsd.
Now I am somewhat confused as I copied the /etc/smsd.conf from the old computer to the new one and also the settings of the /etc/usb-modeswitch.conf.
The /var/log/smstools/smsd.log shows that the smsd is actually communicating with the modem, but despite that I have created valid sms messages to /var/spool/sms/outgoing/.. in the right format, I cannot see any log line mentioning anything about "new outgoing message detected" or in any way about any attempt to to send that message. In the smstools conf file I certainly have sending enabled, like in the previous rig.
Here is part of the smsd.log
2012-09-22 14:23:54,6, GSM1: Checking device for incoming SMS
2012-09-22 14:23:54,6, GSM1: Checking if modem is ready
2012-09-22 14:23:54,7, GSM1: -> AT
2012-09-22 14:23:54,7, GSM1: Command is sent, waiting for the answer
2012-09-22 14:23:55,7, GSM1: <- OK
2012-09-22 14:23:55,6, GSM1: Pre-initializing modem
2012-09-22 14:23:55,7, GSM1: -> ATE0+CMEE=1;+CREG=2
2012-09-22 14:23:55,7, GSM1: Command is sent, waiting for the answer
2012-09-22 14:23:55,7, GSM1: <- OK
2012-09-22 14:23:55,6, GSM1: Initializing modem
2012-09-22 14:23:55,7, GSM1: -> ATE0+CPMS="ME"
2012-09-22 14:23:55,7, GSM1: Command is sent, waiting for the answer
2012-09-22 14:23:56,7, GSM1: <- +CPMS: 0,100,0,30,0,100 OK
2012-09-22 14:23:56,7, GSM1: -> AT+CNMI=3,1,0,0,0
2012-09-22 14:23:56,7, GSM1: Command is sent, waiting for the answer
2012-09-22 14:23:56,7, GSM1: <- OK
2012-09-22 14:23:56,7, GSM1: -> AT+CSQ
2012-09-22 14:23:56,7, GSM1: Command is sent, waiting for the answer
2012-09-22 14:23:57,7, GSM1: <- +CSQ: 15,99 OK
2012-09-22 14:23:57,6, GSM1: Signal Strength Indicator: (15,99) -83 dBm (Good), Bit Error Rate: not known or not detectable
2012-09-22 14:23:57,6, GSM1: Checking if Modem is registered to the network
2012-09-22 14:23:57,7, GSM1: -> AT+CREG?
2012-09-22 14:23:57,7, GSM1: Command is sent, waiting for the answer
2012-09-22 14:23:57,7, GSM1: <- +CREG: 2,1, CA, 14DFA5 OK
2012-09-22 14:23:57,6, GSM1: Modem is registered to the network
2012-09-22 14:23:57,6, GSM1: Selecting PDU mode
2012-09-22 14:23:57,7, GSM1: -> AT+CMGF=0
2012-09-22 14:23:57,7, GSM1: Command is sent, waiting for the answer
2012-09-22 14:23:58,3, GSM1: Unexpected input: OK
2012-09-22 14:23:58,7, GSM1: <- OK
2012-09-22 14:23:58,6, GSM1: Changing SMSC
2012-09-22 14:23:58,7, GSM1: -> AT+CSCA="+358447983500"
2012-09-22 14:23:58,7, GSM1: Command is sent, waiting for the answer
2012-09-22 14:23:59,7, GSM1: <- OK
2012-09-22 14:23:59,6, GSM1: Checking memory size
2012-09-22 14:23:59,7, GSM1: -> AT+CMGD=?
2012-09-22 14:23:59,7, GSM1: Command is sent, waiting for the answer
2012-09-22 14:24:04,7, GSM1: put_command expected (\+CMGD:.*OK)|(ERROR), timeout occurred. 1.
2012-09-22 14:24:04,7, GSM1: <- OK
2012-09-22 14:24:04,6, GSM1: Used memory is 0
2012-09-22 14:24:04,6, GSM1: No SMS received
This just goes on and looks like only checking if modem is ok and if there are any new messages received. Despite of some timeout errors the receiving side seems to work. I sent a test message and it was received into /var/spool/sms/incoming/GSM1.EZsfeU correctly.
So, the two way serial type communication works with the modem, but SMSses are not sent and no records of even trying. The message I have put under ../outgoing does not even appear into ../failed directory, which was the case in the previous rig setup. Looks just like sending would be disabled, but how?
Any idea what could be the matter? I have installed the smstools in both rigs as binary packages from repositories.
|
|
Fri Mar 30, 2012 22:19
|
polarlight: The below was the configuration in Debian Squeeze running in TuxRail SBC for operator DNA prepaid SIM in Finland. I confirm that I have tested both sending text-format SMS (from outgoing folder) and receiving text-format SMSses (into incoming folder). Test period: so far just 3-4 hours from the first communication. Sending started working easily first. Receiving is always more difficult than sending and took longer time to find the correct settings. The last problem preventing message reading was very likely (not confirmed 100%) AT+CPMS="SM" related. When I changed it to the AT+CPMS="ME" the reception seemed to start right away.
1. You probably have to install usb-modeswitch package to prevent storage device overtaking the interface and to allow access to serial ports (/dev/ttyUSB0,/dev/ttyUSB1,/dev/ttyUSB2 ).
Note: The /dev/ttyUSB2 is the one, unless you have other USB-attached serial ports in your system. In addition you may need to use terminal connection to issue AT+ZCDRUN=8 which instructs the modem to boot without storage device (to return to norma you would use AT0ZCDRUN=9), but this may be unnecessary if usb-modeswitch is used.
I have these added to the end of default /etc/usb_modeswitch.conf
########################################################
# ZTE MF622 (aka "Onda MDC502HS")
# ZTE MF626
# ZTE MF628+ (tested version from Telia / Sweden)
# ZTE MF633
# ZTE MF636 (aka "Telstra / BigPond 7.2 Mobile Card")
# ZTE MF637
# and probably others not listed here
#
# Contributor: Joakim Wennergren and others
DefaultVendor= 0x19d2
DefaultProduct= 0x2000
TargetVendor= 0x19d2
TargetProduct= 0x0031
MessageContent="5553424312345678000000000000061e000000000000000000000000000000"
MessageContent2="5553424312345679000000000000061b000000020000000000000000000000"
NeedResponse=1
2. Not tested for sure if needed, but I also have this defined in /etc/modules:
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.
#Driver for Huawei ZTE MF627 3G Modem (added 2012-02-18)
usbserial vendor=0x19d2 product=0x0031
3. get smstools package and modify /etc/smsd.conf to have this kind of modem-specific section
(You would modify smsc by your operator of course)
[GSM1]
#init = ATE0+CPMS="SM"+CNMI=2,0,0,2,1 2,0,0,1,0 3,2
# by default ZTE636+ has AT+CNMI 3,1,0,0,0 which gives indcation like: +CMTI: "ME",3
init = ATE0+CPMS="ME"
init2 = AT+CNMI=3,1,0,0,0
# # Windows: /dev/com1, Solaris: /dev/cua/a, Linux /dev/ttyS0
device = /dev/ttyUSB2
incoming = yes
# queues = OTHER
# You don't need a PIN for mobile phones ( often not needed by default for NET sticks either)
# pin = ****
# mode = new
# smsc = 491722270000 or DNA/.FI: 358447983500
smsc = 358447983500
baudrate = 19200
check_memory_method = 2
# rtscts = yes
cs_convert = yes
# report = no
# memory_start = 1
# primary_memory = memory name
# secondary_memory = memory name
# secondary_memory_max = number
# pdu_from_file = /var/spool/sms/GSM1-PDU
sending_disabled = no
# decode_unicode_text = no
# internal_combine = no
|
Page: 1
Time in this board is UTC.
|
|
|
 |
|
|
 |
|
