SMS Server Tools 3
 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. The forum is currently read-only, but will open soon. Sat Oct 12, 2024 09:42
SMSTools3 Community » Help and support Bottom

[changed in 3.1.7] communicate with developers

  This topic is locked

Page:  1

Author Post
Member
Registered:
Jun 2009
Location: Moscow, Russian Federation
I'm make some patches to sms3 (e.g. remove compilation warnings in 64bit build, 'localize' datime format in log, etc), but...
When I can sent this patches to it? I can't find any e-mail on site (and in package :), and Your forum's does not support 'attach file'.

Regards

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Text data can be included in the post using Code block. If you publish a patch here, other users can see it without delays and probably implement it if they want.

E-mails are hidden (even inside a package) because of spamming robots. You can run smsd -V to see the e-mail address. However, this forum is the preferred way to communicate.

Member
Registered:
Jun 2009
Location: Moscow, Russian Federation
Topic owner
As You wish :).
First patch remove compiler warnings when build in 64bit system (x64). Build with -W -Wall and possible -O2



The second patch (apply after first) 'cenralize' all datetime formats used for logging as #defines in header. Also define default config file pathname to header and correct help out.
When this defines placed in header it may be trivial changed before compilation (needed for pseudo-localized output - e.g. in russian environment datetimestamp in all log is d-m-Y).


The third patch (apply after second) make very readable process names (for 'ps') and permitts to simplify sms3 script :). Also source is slightly shorter :)


I want to now which patches are accepted (or not) to decide to make other patches (e.g. correct ucsc2 conversation in non 8859-15 environment :) and more extension).

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Thank's for the information, I do not currently have x64 system available and have not seen these typecast warnings.

Almost all of your changes will be included in the future releases. Some argument usage will be changed and logging timestamp formats will be possible to define in the configuration file too. This is for those who do not compile this from sources.

I'm not sure about the last path. The array (argv) cannot be used to store longer string than there initially was, because it's not known if there is a space available in the buffer. I made some simple test and with "./test" I got Segmentation fault because the size of argv[0] was only 7 characters. Because of this I have used underscores to allow "MAINPROCESS" to be replaced with a longer modem name. Please correct if I'm wrong.

Member
Registered:
Jun 2009
Location: Moscow, Russian Federation
Topic owner
Big thanks (detail below).

For argv/argc - this is 'standard trick' :) for linux used in many (old) programs.
1. Argv's pointed to single memory buffer (e.g argv[n+1] == argv[n] + strlen(argv[n]).
2. Than go to /usr/src/linux/fs open file exec.c and find procedure copy_strings (it copies arguments from parent process to current). You can see that allocation have 'page' granularity (e.g. minimum allocation size for x86 is 4kB :).

-----
Next (apply after previoused) trivial patch change log levels for 4 messages - it described as information (in comment's), but outed as notice :) and 'expand' logfile to unneeded details:


------
That go to complex problem :).
Your realization of ucs2 conversion ( to/from utf8 ) is not correct (if messages contain symbols not in Latin-5).
1. You use wctomb without setlocale. In this case wctomb use default ('C') locale. And locale 'C'... is analogue of Latin1 :).
2. You use 'internal' tables for conversion (e.g. not support others languages).

The simplest (but not fully correct) workaround is insert at begin of main() setlocale(LC_CTYPE, "en_US.UTF-8"); (or setlocale(LC_CTYPE, ""); if user environment is utf8 :).
With this change 'decode_unicode_text=yes' work correctly for inputed mesages, but... only if 'incoming_utf8=yes' is NOT set.
I think that 'ut8-conversion' would be unneeded, but this must be tested in environment for which it developed.

But this method doesn't resolve problem of conversion output messages from utf8 to ucs2.

The second (not so trivial) variant is add 'UTF8' alphabet and convert it (with iconv() call) to ucs2 on output if SMS-file set it.
Also can use iconv instead of wctomb (and not change locale).
But in this case 'Alphabet: UTF8' must be set it in inputed UCS2 messages when it converted and... for ISO-converted messages (if this needed) - for unification.
But in this variant I also don't known must your utf8-conversion procedures removed or not. And if this procedures must remain we have situation with potentially conflicting configuration parameters.

Please, tell me Your suggestions of this problem :) and I try to make patch (check it in my - russian - environment) and sent it to You.
-----
Sorry, but my english is very poor :(

Member
Registered:
Jun 2009
Location: Moscow, Russian Federation
Topic owner
Before go to problem with non-english messages :) last one small patch. This patch is very 'special' - for communicate with SIM-applications. It permit send SMS as SS,- it not show, not stored in ME and always stored (sended to) SIM.
I'm not add new parameters - use one of Your's :) - SMS-file header for this behavior is:

System_message: toSIM



Currently this message always sended as binary,- I'm can't yet test others case :).

Do You intend to include this patch included in Your package, or I'm must make it in separate branch and merge after new versions?

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Quote
For argv/argc - this is 'standard trick' :) for linux used in many (old) programs.

Linux source (2.6.16) looks like you told. However, this program should compile and run on any Unix and variants, and on Windows with Cygwin, and on some other systems which names I do not right now even remember, and on embedded devices like routers and so on... ;) Trusting on some kernel trick does not sound like a good idea... :( But you are right, arguments are "concatenated", it can be seen if they are not cleared while using this "trick". I did not check 4KB allocation, but test shows that problems occur if total length of original arguments is exceeded. Not every time, but often. Simply, the following code may show the issue: first #define TEST1 and compile it to test1. Then #define TEST2 and compile it to a.out. Run test1. It crashes but not every time. Then try with shorter *test string (123), it does not crash.



Anyways, I do not see much difference between "/usr/local/bin/smsd -n MAINPROCESS -p/var/run..." and "smsd: MAINPROCESS" ps listing. Perhaps you have something more to tell, e.g. what changes you been thinking on sms3 script? How about backward compatibility with watchdog systems, and probably for systems running more than one daemon...

Quote
That go to complex problem :).
Your realization of ucs2 conversion . . .

I have to check this issue later. Generally taken, it has been problematic to test some cyrillic environments, because I do not understand the language :(. But if you can help this project with your knowledge, I and many users too would appreciate it very much.

Quote
Next (apply after previoused) trivial patch change log levels for 4 messages . . .

Those messages were using LOG_INFO in previous versions, but now (with smart_logging) LOG_NOTICE is a good level for logging and those messages was changed because they were needed in some kind of systems. Because those are startup messages only, not much additional lines are produced.

Quote
This patch is very 'special' - . . .

You will get your feature as a new header, I just have to check how this works and if there is any side effects. :)

Member
Registered:
Jun 2009
Location: Moscow, Russian Federation
Topic owner
keke wrote
Perhaps you have something more to tell, e.g. what changes you been thinking on sms3 script? How about backward compatibility with watchdog systems, and probably for systems running more than one daemon...

No problem. I'm can place this in #ifdef USE_SHORT_PS_NAMES (defined on make) or (if You will) move this patch to addition branch (when my environment in headers present).
What variant is perfectly to You? (I'm replace patch after Your answer).

Quote
I have to check this issue later.

Ok, I'm wait :)

Quote
Generally taken, it has been problematic to test some cyrillic environments, because I do not understand the language :(. But if you can help this project with your knowledge, I and many users too would appreciate it very much.

This problem present not only in cyrillic environment (e.g. in chinese, japanese, tai... :)), but I'm can check only in cyrillic. I'm will make variant for english/russian combianation in any case, but... I can't test European languages (diasterics, etc).

After You answer we can start 'iterated' process - e.g. I'm make build that correct work for cyrillic SMS (without checking of 'invalid-configuration-combination'), send it to You, You check this build in european environment, and that we can resolve check's of configuration. Ok? :)
If yes - maybe I (or You) create (temporary) svn-repository for this process? Message-board is not optimal place for it.

Quote
Those messages were using LOG_INFO in previous versions, but now (with smart_logging) LOG_NOTICE is a good level for logging and those messages was changed because they were needed in some kind of systems. Because those are startup messages only, not much additional lines are produced.

First three - yes (Ok, I'm remove patch), and 4?
"Moved file %s to %s"
not needed for send/receive log-analizers, and present of any outed message :(


Quote
You will get your feature as a new header, I just have to check how this works and if there is any side effects. :)

Not good idea. If make new header (e.g. SStoSIM) need check that this header not present in combination with System_message. And in this situation (conflict) we have many variants - drop message, select one of options, etc.

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
yjh wrote
keke wrote
Perhaps you have something more to tell, e.g. what changes you been thinking on sms3 script? How about backward compatibility with watchdog systems, and probably for systems running more than one daemon...

No problem. I'm can place this in #ifdef USE_SHORT_PS_NAMES (defined on make) or (if You will) move this patch to addition branch (when my environment in headers present).
What variant is perfectly to You? (I'm replace patch after Your answer).

Have you double-checked that there surely is enough space available while running on GNU/Linux? My test code said that it's not sure. Your changes can be included in the code, but it should be users choice to use it or not. And by default the ps list will remain as it is currently. Some configuration setting can also be included for this, because lot of users do not compile this software from sources.

yjh wrote
Quote
Generally taken, it has been problematic to test some cyrillic environments, because I do not understand the language :(. But if you can help this project with your knowledge, I and many users too would appreciate it very much.

This problem present not only in cyrillic environment (e.g. in chinese, japanese, tai... :)), but I'm can check only in cyrillic. I'm will make variant for english/russian combianation in any case, but... I can't test European languages (diasterics, etc).

After You answer we can start 'iterated' process - e.g. I'm make build that correct work for cyrillic SMS (without checking of 'invalid-configuration-combination'), send it to You, You check this build in european environment, and that we can resolve check's of configuration. Ok? :)
If yes - maybe I (or You) create (temporary) svn-repository for this process? Message-board is not optimal place for it.

Because of some activities I'm little bit busy currently, but after a while this repository can be created. Code of an upcoming version should be used as a base, not 3.1.5. New code is already reformatted and reorganized and there are also changes to allow SQL database based spooling.

There has been users who run this software on chinese environment, but (as far as I know) they used Unicode as a locale too. It will be very useful to get this software working well on russian environments too, with your help.

yjh wrote
Quote
Those messages were using LOG_INFO in previous versions, but now (with smart_logging) LOG_NOTICE is a good level for logging and those messages was changed because they were needed in some kind of systems. Because those are startup messages only, not much additional lines are produced.

First three - yes (Ok, I'm remove patch), and 4?
"Moved file %s to %s"
not needed for send/receive log-analizers, and present of any outed message :(

Sorry, I forgot to tell about the fourth message :(. You are right, it does not present sent message. However, it presents work of mainprocess, how messages are spooled. If this message has lower level, we cannot see from the log how mainprocess is working. In many environments it has been useful to see (and track) this information. And even if you are running smsd on it's maximum capacity (which means very heavy load), log file still does not grow too much.

yjh wrote
Quote
You will get your feature as a new header, I just have to check how this works and if there is any side effects. :)

Not good idea. If make new header (e.g. SStoSIM) need check that this header not present in combination with System_message. And in this situation (conflict) we have many variants - drop message, select one of options, etc.

A new header can override System_message header. I do not change System_message header usage because of backward compatibility.

Member
Registered:
Jun 2009
Location: Moscow, Russian Federation
Topic owner
Quote
Have you double-checked that there surely is enough space available while running on GNU/Linux?

Many time in many programs :). But only on x86/x64.

Quote
Your changes can be included in the code, but it should be users choice to use it or not.

Thanks. I'm post new version of patch tomorrow (or today later)

Quote
Because of some activities I'm little bit busy currently, but after a while this repository can be created. Code of an upcoming version should be used as a base, not 3.1.5. New code is already reformatted and reorganized and there are also changes to allow SQL database based spooling.

My patch is practically done - I'm will post it tomorrow. But this patch based on 3.1.5. If You will receive patch to other version (checked it in my environment), please send my e-mail with 'base-source'.

Quote
A new header can override System_message header. I do not change System_message header usage because of backward compatibility.

I think that backward compatibility present in my variant also (yes/no/0/1/etc values interpret in old manner), but if You will change header - make header part as You need right and get functionality from patch.

Member
Registered:
Jun 2009
Location: Moscow, Russian Federation
Topic owner
That was promised :).

There are changed patch for 'ps': the your old code is working if USE_LINUX_PS_TRICK is not defined in makefile.



-----------------------------
Next is ucs2<=>utf8 converter. All changes are under #ifdef USE_ICONV (i.e. if is is not defined in makefile all work in old manner).

If USE_ICONV is defined than "logical changes" are:

1. If define Alphabet: UTF-8 in output file, than:
1.1. If message contains only ASCII symbols that math GSM
coding, that only change is Alphabet replacing to GSM (this
is needed for "automating" of scripts and E-mail
redirector).
1.2. If 1.1 is not true, the message is recoding from
UTF8 to UCS2 and Alphabet is changed to UCS2.

2. If decode_unicode_text=yes is defined in configuration, than:
2.1. The message is recoding from UCS2 to UTF8
(and ISO=>UTF recoding is automatically disabled).
2.2. The Alphabet:UTF-8 is placed in output file.

3. NOTE (unexpected addonce :)).
If the USSD command is defined in regular_run_cmd
and if this command receive replay in HEX-UCS2,
this string is automatically converted to UTF8.
This is necessary for receiving "balance" (payment
information). There are many GSM-modems that permit
the USSD request only in format '1,"....",15'
(i.e. with "default" language). The many GSM-providers
in this case are send replay in "local" language.
And if language is not LatinX, the replays are some
sort of: OK +CUSD 2,"045b04230023.....",72
which is... not readable for user :).



ATT: If build after this patch in cyrwin/mingw environment makefile must add '-liconv' option (in linux all included in libc).

NOTE: Yet NOT tested: Errors (i.e. replay with errors :));
code auto-detection (I don't know how to reach this situation); and finally, all tested only with Russian providers (but for different languages, including European :).
-----------------------------

Next small patch (must use after "converter") needed, for example, for "balance" requests.
If regular_run_cmd is defined for modem (and use USSD command), and the MODEM eventhandler are defined, after executing regular_run_cmd modem eventhandler is called with arguments:

<modem_handler> USSD <modem_name> "answer_string"

And the quotes(") in answer_string are processed correctly (escaped for shell).



NOTE: I'm not make separate options for enable this call - I'm think that it will be only more complicate. If you think that 'enable option' is needed - I have't any questions :)

  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.