SMS Server Tools 3
This site is hosted by
Basic information:
Additional information:
Get SMS Server Tools 3:
Additional Options

 Sponsored links

Custom Search

 Visitor locations
 SMS Server Tools 3 Community
Welcome, Guest. Please login or register. Tue Jun 25, 2024 15:56
SMSTools3 Community » Help and support Bottom

newline after SMS when sent with "Alphabet: UTF8"

Login and Post Reply

Page:  1

Author Post
Jun 2021
Location: Saarbrücken, Germany
Operating system name and version: Linux Debian 10
Version of smsd: 3.1.21
Smsd installed from: sources
Name and model of a modem / phone: SIMCOM SIM7600G
Interface: USB

Hi there,
I noticed that as soon as I send a message with Alphabet: UTF8, the SMS will have an additional newline at the end when received on the other side.

This file (------ indicates the boundary) shows the problem:

To: 00491709xxxxxx
Alphabet: UTF8
Flash: no
To_TOA: International


As soon as I remove the "Alphabet: UTF8" line, the SMS is received as expected. My goal is to make UTF work (for non-ASCII language support), and at the same time have a correct transmission for such cases.

Any help appreciated!



devices = GSM0
outgoing = /var/spool/sms/outgoing
checked = /var/spool/sms/checked
incoming = /var/spool/sms/incoming
infofile = /var/run/smstools/smsd.working
pidfile = /var/run/smstools/
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
stats_interval = 0
stats_no_zeroes = yes
status_include_counters = no
ignore_outgoing_priority = yes
loglevel = 6
receive_before_send = no
autosplit = 3
validity = 255
decode_unicode_text = no
hangup_incoming_call = yes
date_filename = 2
ignore_exec_output = yes
eventhandler = /opt/braintower/sms-gateway/scripts/
blockafter = 3
blocktime = 3600
notifier = yes
delaytime = 0

device = /dev/gsm0
device = /dev/gsm0
signal_quality_ber_ignore = yes
init = AT+CPMS="ME","ME","ME"
init2 = AT+CNMI=2,0,0,2,1
cmgl_value = 4
check_memory_method = 1
keep_open = yes
report = disabled
report_device_details = yes
check_network = yes
memory_start = 0
mode = new
incoming = yes
baudrate = 115200
regular_run_post_run = /opt/braintower/sms-gateway/scripts/
regular_run_cmdfile = /var/spool/sms/regular_run.cmdfile
regular_run_interval = 60
regular_run_statfile = /var/log/smstools/smsd_stats/statfile
pin = ignore

Jun 2021
Location: Saarbrücken, Germany
Topic owner
Update: the problem appears to be in the spot where SMSTools computes the PDU representation of the message. As soon as Alphabet: UTF8 ist present, there is the excess linefeed in the PDU string, as I can check with

(Not posting the messages here as I have tested with true phone numbers that cannot be obfuscated in the PDU but this should now be easy to reproduce.)

May 2009
Location: Jyväskylä, Finland
As you have the sent files stored, could you use the hexdump -C < sent/filename command to check if there is a linefeed at the end of the file? ​Perhaps the editor you are using is placing it to the file.

Jun 2021
Location: Saarbrücken, Germany
Topic owner
Hi Keke,

got me, thank you! I was looking at the file in vi only, it didn't occur to me to do a hex dump, and the different behavior with the Alphabet apparently was a red herring in my analysis. I can confirm that there was a trailing 0a which didn't play a role with the 8 bit charset but apparently does with UTF type messages. When I remove the trailing 0a with sed it's working as expected, so please consider this report done. I appreciate your reply and assistance!


Login and Post Reply

Page:  1

SMSTools3 Community » Help and support Top

Time in this board is UTC.  

Privacy Policy   SMS Server Tools 3 Copyright © Keijo Kasvi.