|
|
SMS Server Tools 3 Community |
Welcome, Guest. The forum is currently read-only, but will open soon. |
Sat Oct 12, 2024 09:42 |
This topic is locked
Page: 1
Author |
Post |
|
#1 Wed Jun 24, 2009 21:24, 186 months ago.
|
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
|
|
#2 Thu Jun 25, 2009 09:31, 186 months ago.
|
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.
|
|
#3 Thu Jun 25, 2009 10:42, 186 months ago.
|
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).
|
|
#4 Thu Jun 25, 2009 15:05, 186 months ago.
|
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.
|
|
#5 Thu Jun 25, 2009 16:37, 186 months ago.
|
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
|
|
#6 Thu Jun 25, 2009 17:06, 186 months ago.
|
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?
|
|
#7 Thu Jun 25, 2009 18:24, 186 months ago.
|
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.
|
|
#8 Thu Jun 25, 2009 19:18, 186 months ago.
|
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.
|
|
#9 Sun Jun 28, 2009 19:00, 186 months ago.
|
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.
|
|
#10 Sun Jun 28, 2009 19:37, 186 months ago.
|
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.
|
|
#11 Mon Jun 29, 2009 17:54, 186 months ago.
|
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
Time in this board is UTC.
|
|
|
|
|
|
|