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. Fri Mar 14, 2025 11:14
SMSTools3 Community » Search Bottom

Page:  1

Keywords:
Mode: All keywords (AND)
unterwulf: If you use the same modem for receiving and sending its handler may be blocked until the script completion and because of that the handler doesn't check outgoing queue. (Just a guess. I haven't taken a look at the source code.) After the script completion the modem handler finds both two messages in outgoing queue and sends them immediately. If it is the case one probable solution can be to spawn a background job from your script, like the following: if [ "$1" = "RECEIVED" ]; then script_that_does_long_job.sh & fi
unterwulf: Just for the record, there has already been a topic about this bug. Here is the link http://smstools3.kekekasvi.com/topic.php?id=831.
unterwulf: You found a bug. The process_id is a modem index in modem processes and [always hardcoded ;-)] -1 in the main smsd process. Because DEVICE is actually devices[process_id], DEVICE must never be used unconditionally in shared code. Here is a quick patch. diff -pruN smstools3.orig/src/locking.c smstools3/src/locking.c --- smstools3.orig/src/locking.c 2010-08-18 15:34:57.000000000 +0400 +++ smstools3/src/locking.c 2012-03-19 19:35:28.000000000 +0400 @@ -42,7 +42,8 @@ int lockfile( char* filename) lockfile=open(lockfilename,O_CREAT|O_EXCL|O_WRONLY,0644); if (lockfile>=0) { - snprintf(pid, sizeof(pid), "%i %s\n", (int)getpid(), DEVICE.name); + snprintf(pid, sizeof(pid), "%i %s\n", (int)getpid(), + (process_id == -1) ? "MAINPROCESS" : DEVICE.name); write(lockfile, pid, strlen(pid)); close(lockfile); sync();
unterwulf: At first, as root: 1) echo /tmp/core.%p > /proc/sys/kernel/core_pattern This is required because smsd changes its working directory to / on start and it won't be able to create core files unless it is run from the user root. The command above asks Linux kernel to create core files in the directory /tmp instead of the current working directory. Note that this parameter is global and will immediately affect all sessions. Next, as a regular user: 2) Make sure that the maximum size of core files isn't zero using the command ulimit -c. If it is zero, set it to some reasonable value or unlimited with the command ulimit -c unlimited. Note that this parameter is local for current session. So... 3) Run smsd in the same session. 4) Reproduce segmentation fault. 5) Make sure that a core file has been created in /tmp. 6) Run gdb -c <core_file> <smsd_binary> 7) In GDB session, issue the command bt. After that you should see a stack trace where the topmost function is the one where the segmentation fault happened.
unterwulf: smsd cannot use UDP. But it doesn't matter, because it wouldn't help you anyway. Several servers cannot use the same modem with serial interface simultaneously even if it is available via network, just because the modem is designed to use the only connection. Irrespective of protocol you would need to synchonize the servers to use the modem exclusively. And it doesn't look like a wise setup. BTW, what is the reason not to use just the only server?
unterwulf: As far as I know smsd has no such functionality available via command line. There is an option -D to decode 7-bit GSM strings, but it not the same as decoding PDU. However, you can have decoded PDU as a side effect of pdu_from_file option. See http://smstools3.kekekasvi.com/index.php?p=configure#m_pdu_from_file for details. Please note, that to make use of this option without real modem you will need to use modem_disabled option as well. p.s. Just to save your time, smsd unable to decode the PDU from your post. Here is what it tells: Error: Cannot decode PDU, see text part for details. From: Received: 12-03-06 13:01:52 Subject: GSM1 Modem: GSM1 IMSI: Report: no Alphabet: ISO Length: 497 PDU: 02910021320c9144776211850210003c7f319 Pos: ....^^~here(5) First tried with PDU mode new (with CSA): The PDU data (21) says that this is a sent message. Can only decode received messages. Next tried with PDU mode old (without CSA): PDU ERROR: Position 5,2: Invalid recipient address length: "00" No success. This PDU cannot be decoded. There is something wrong. If you are unsure, confused or angry, please view the GSM 03.40 (ETSI TS 100 901) and related documents for details of correct PDU format. You can also get some help via the Support Website.
unterwulf: "decode_unicode_text = yes" turns on internal decoding of incoming messages and it works. Is any option for outgoing messages ? The Alphabet header is a kind of alternative to that for outgoing messages. I took a quick look at the source code and it seems that UTF-8 is a supported yet not documented value. So try to add the following header to your messages: Alphabet: UTF-8
unterwulf: Hi sasso, Could be it due to the hardware? May be I'm using an unsupported GSM modem or is it only a software depending? At this point it is not a hardware problem for sure. This message is a result of failed memory allocation. As far as I can see the FreeBSD port builds smsd with statistics support enabled by default. It this case smsd uses libmm memory allocation function that I don't know too much about and have no idea why it can fail. So as a first step I would suggest to build smsd without statistics support. In this case smsd will use plain old malloc().
unterwulf: Hi kewes! Take a look at http://smstools3.kekekasvi.com/index.php?p=localizing. In short, obviously language file can be used to drop unwanted headers from the incoming messages. For example the following language file will drop From_TOA and From_SMSC headers. incoming = yes From_TOA: = - From_SMSC: = -
unterwulf: Current smstools build system has no convenient cross-compiling/staging support, so I would suggest to create a patch for Makefile like this: diff -pruN smstools3.orig/src/Makefile smstools3/src/Makefile --- smstools3.orig/src/Makefile 2010-09-21 15:29:14.000000000 +0400 +++ smstools3/src/Makefile 2012-02-15 12:12:10.000000000 +0400 @@ -1,7 +1,10 @@ # In case of windows, use os_cygwin=yes setting in the configuration file (smsd.conf). # Select your setup size: -CFLAGS = -D NUMBER_OF_MODEMS=64 +CFLAGS = -D NUMBER_OF_MODEMS=1 + +CFLAGS += $(USER_CFLAGS) +LFLAGS += $(USER_LDFLAGS) # Uncomment for Solaris # CFLAGS += -D SOLARIS @@ -12,10 +15,10 @@ CFLAGS = -D NUMBER_OF_MODEMS=64 CFLAGS += -D NOSTATS # Comment this out if iconv is not available on the system -#CFLAGS += -D USE_ICONV +CFLAGS += -D USE_ICONV # Uncomment this is iconv is used and it's not included in libc: -#LFLAGS += -liconv +LFLAGS += -liconv # Uncomment this to force smsd to run in terminal mode #CFLAGS += -D TERMINAL And use the following in the package Makefile: define Package/smstools3 [...] DEPENDS:=+libiconv-full endef [...] define Build/Compile $(MAKE) -C $(PKG_BUILD_DIR) \ CC=$(TARGET_CC) \ USER_CFLAGS='$(TARGET_CFLAGS) $(EXTRA_CFLAGS) $(TARGET_CPPFLAGS) $(EXTRA_CPPFLAGS) -I$(STAGING_DIR)/usr/lib/libiconv-full/include' \ USER_LDFLAGS='$(TARGET_LDFLAGS) $(EXTRA_LDFLAGS) -L$(STAGING_DIR)/usr/lib/libiconv-full/lib' endef
unterwulf: It decodes in something unreadable and I do not know type of encoding after this internal decoding. I tried this optoion in the past (and just now) - that is whi this option was commented out in my config Looks like the internal decoder makes use of wctomb() that in turn depends on current locale (and on libc locale support). As an alternative option you can link smsd against libiconv. In this case resulting encoding will be UTF-8 for sure (as long as libiconv supports UCS-2BE and UTF-8). In order to link against libiconv uncomment the following lines in the src/Makefile: # Comment this out if iconv is not available on the system CFLAGS += -D USE_ICONV # Uncomment this is iconv is used and it's not included in libc: LFLAGS += -liconv
unterwulf: Seems because I get Alphabet: UCS2 sms and this option has no effect - it should affect on ISO or GSM alphabet only like documentation tells. I just tried this option and there was no effect. Received message has been saved in UNICODEBIG (aka UCS-2BE in iconv). My bad. Try decode_unicode_text instead. http://smstools3.kekekasvi.com/index.php?p=configure#g_decode_unicode_text
unterwulf: I need received sms in UTF-8 if Alphabet is UCS2. To encode sms on PC I use "sms2unicode $2 | iconv -c -f UTF-16 -t UTF-8 >> $2.txt" in smsevent. ... Pleace help me to encode SMS in UCS2 to UTF-8. Why don't you use the incoming_utf8 option instead of this? http://smstools3.kekekasvi.com/index.php?p=configure#g_incoming_utf8
unterwulf: B.t.w. Why smsd uses so mutch memory ? It is a biggest process on my router by memory usage. pppd eats less RAM. pppd is more feature rech program. I almost have no RAM margin after starting smsd. Try to reduce NUMBER_OF_MODEMS in src/Makefile. # Select your setup size: CFLAGS = -D NUMBER_OF_MODEMS=1
unterwulf: For those who still interested in using smsd with PORTech modems here is a patch that adds a new functionality required for that. It introduces a number of new smsd.conf options, namely: * telnet_crlf * telnet_cmd * telnet_cmd_prompt Their meaning is quite straightforward. Here is a config that is known to work with at least PORTech MV-372: [GSM1] device = @<your_modem_IP>:23 telnet_crlf = yes telnet_login = <your_login> telnet_password = <your_password> telnet_login_prompt = username: telnet_password_prompt = password: telnet_cmd_prompt = module1, module2, state1, state2, info. telnet_cmd = module1 init = ATV1 Note, the init = ATV1. It is required to switch the device into verbose result code format mode, so it answers OK and ERROR instead of 0 and 4. It is required as smsd doesn't understand numeric codes. As an option you can store settings in the user profile via telnet like ATV1 AT&W and the use init = ATZ to restore these settings. diff -pruN smstools3.orig/src/modeminit.c smstools3/src/modeminit.c --- smstools3.orig/src/modeminit.c 2010-09-20 13:31:43.000000000 +0400 +++ smstools3/src/modeminit.c 2012-02-04 01:44:14.000000000 +0400 @@ -487,6 +487,7 @@ void negotiate_with_telnet(char *answer, char command; int got_option; char option; + const char *eol = DEVICE.telnet_crlf ? "\r\n" : "\n"; idx = 0; while (idx < *len) @@ -543,14 +544,20 @@ void negotiate_with_telnet(char *answer, if (DEVICE.telnet_login_prompt[0] && strstr(answer, DEVICE.telnet_login_prompt) && DEVICE.telnet_login[0]) { if (DEVICE.telnet_login_prompt_ignore[0] == 0 || !strstr(answer, DEVICE.telnet_login_prompt_ignore)) - snprintf(response, sizeof(response), "%s\n", DEVICE.telnet_login); + snprintf(response, sizeof(response), "%s%s", DEVICE.telnet_login, eol); } else if (DEVICE.telnet_password_prompt[0] && strstr(answer, DEVICE.telnet_password_prompt) && DEVICE.telnet_password[0]) - snprintf(response, sizeof(response), "%s\n", DEVICE.telnet_password); + snprintf(response, sizeof(response), "%s%s", DEVICE.telnet_password, eol); + else if (DEVICE.telnet_cmd_prompt[0] && strstr(answer, DEVICE.telnet_cmd_prompt) && DEVICE.telnet_cmd[0]) + snprintf(response, sizeof(response), "%s%s", DEVICE.telnet_cmd, eol); if (*response) + { + *answer = 0; + *len = 0; if ((size_t)write(modem_handle, response, strlen(response)) != strlen(response)) writelogfile(LOG_ERR, 1, "%s: Failed to send response (login/password).", title); + } #undef IAC #undef DONT @@ -1259,7 +1266,8 @@ int initmodem(char *new_smsc, int receiv retries++; put_command("AT\r", answer, sizeof(answer), 1, EXPECT_OK_ERROR); - if (!strstr(answer, "OK") && !strstr(answer, "ERROR")) + if (!strstr(answer, "OK") && !strchr(answer, '0') && + !strstr(answer, "ERROR") && !strchr(answer, '4')) { if (terminate) return 7; @@ -1272,7 +1280,7 @@ int initmodem(char *new_smsc, int receiv } // 3.1.7: If it looks like modem does not respond, try to close and open the port: - if (retries >= 5 && !strstr(answer, "OK")) + if (retries >= 5 && !strstr(answer, "OK") && !strchr(answer, '0')) { try_closemodem(1); t_sleep(1); @@ -1282,8 +1290,8 @@ int initmodem(char *new_smsc, int receiv break; } } - while (retries <= 10 && !strstr(answer,"OK")); - if (!strstr(answer,"OK")) + while (retries <= 10 && !strstr(answer, "OK") && !strchr(answer, '0')); + if (!strstr(answer,"OK") && !strchr(answer, '0')) { // 3.1: more detailed error message: p = get_gsm_error(answer); @@ -1308,7 +1316,7 @@ int initmodem(char *new_smsc, int receiv put_command(command, answer, sizeof(answer), 2, EXPECT_OK_ERROR); - if (!strstr(answer,"OK")) + if (!strstr(answer,"OK") && !strchr(answer, '0')) writelogfile(LOG_ERR, 1, "Modem did not accept the pre-init string"); } diff -pruN smstools3.orig/src/smsd_cfg.c smstools3/src/smsd_cfg.c --- smstools3.orig/src/smsd_cfg.c 2010-09-21 13:15:07.000000000 +0400 +++ smstools3/src/smsd_cfg.c 2012-02-05 01:16:20.000000000 +0400 @@ -335,11 +335,14 @@ void initcfg() devices.keep_messages = 0; devices.trust_spool = 1; devices.smsc_pdu = 0; + devices.telnet_crlf = 0; devices.telnet_login[0] = 0; snprintf(devices.telnet_login_prompt, sizeof(devices.telnet_login_prompt), "%s", TELNET_LOGIN_PROMPT_DEFAULT); snprintf(devices.telnet_login_prompt_ignore, sizeof(devices.telnet_login_prompt_ignore), "%s", TELNET_LOGIN_PROMPT_IGNORE_DEFAULT); devices.telnet_password[0] = 0; snprintf(devices.telnet_password_prompt, sizeof(devices.telnet_password_prompt), "%s", TELNET_PASSWORD_PROMPT_DEFAULT); + devices.telnet_cmd[0] = 0; + devices.telnet_cmd_prompt[0] = 0; devices.signal_quality_ber_ignore = 0; devices.verify_pdu = 0; devices.loglevel_lac_ci = 6; @@ -1647,6 +1650,12 @@ int readcfg() startuperror(yesno_error, name, value); } else + if (strcasecmp(name,"telnet_crlf")==0) + { + if ((NEWDEVICE.telnet_crlf = yesno_check(ask_value(NEWDEVICE.name, name, value))) == -1) + startuperror(yesno_error, name, value); + } + else if (strcasecmp(name,"telnet_login")==0) strcpy2(NEWDEVICE.telnet_login, ask_value(NEWDEVICE.name, name, value)); else @@ -1662,6 +1671,12 @@ int readcfg() if (strcasecmp(name,"telnet_password_prompt")==0) strcpy2(NEWDEVICE.telnet_password_prompt, ask_value(NEWDEVICE.name, name, value)); else + if (strcasecmp(name,"telnet_cmd")==0) + strcpy2(NEWDEVICE.telnet_cmd, ask_value(NEWDEVICE.name, name, value)); + else + if (strcasecmp(name,"telnet_cmd_prompt")==0) + strcpy2(NEWDEVICE.telnet_cmd_prompt, ask_value(NEWDEVICE.name, name, value)); + else if (strcasecmp(name,"signal_quality_ber_ignore")==0) { if ((NEWDEVICE.signal_quality_ber_ignore = yesno_check(ask_value(NEWDEVICE.name, name, value))) == -1) @@ -2367,14 +2382,17 @@ int startup_check(int result) if (!value_in(devices[x].check_network, 3, 0, 1, 2)) wrlogfile(&result, "Device %s has invalid value for check_network (%i).", devices[x].name, devices[x].check_network); - // 3.1.7: Devices cannot have the same port. - for (y = 0; y < NUMBER_OF_MODEMS; y++) + if (!DEVICE_X_IS_SOCKET) { - if (y == x) - continue; - if (devices[y].name[0] && devices[y].device[0]) - if (strcmp(devices[y].device, devices[x].device) == 0) - wrlogfile(&result, "Devices %s and %s has the same port ( device = %s ).", devices[x].name, devices[y].name, devices[x].device); + // 3.1.7: Devices cannot have the same port. + for (y = 0; y < NUMBER_OF_MODEMS; y++) + { + if (y == x) + continue; + if (devices[y].name[0] && devices[y].device[0]) + if (strcmp(devices[y].device, devices[x].device) == 0) + wrlogfile(&result, "Devices %s and %s has the same port ( device = %s ).", devices[x].name, devices[y].name, devices[x].device); + } } #ifndef USE_ICONV diff -pruN smstools3.orig/src/smsd_cfg.h smstools3/src/smsd_cfg.h --- smstools3.orig/src/smsd_cfg.h 2010-09-20 15:11:26.000000000 +0400 +++ smstools3/src/smsd_cfg.h 2012-02-04 00:50:23.000000000 +0400 @@ -221,11 +221,14 @@ typedef struct char stopstring[100]; // 3.1.7: Command(s) to send to the modem when a devicespooler is stopping. int trust_spool; // 3.1.9 int smsc_pdu; // 3.1.12: 1 if smsc is included in the PDU. + int telnet_crlf; char telnet_login[64]; // 3.1.12: Settings for telnet. char telnet_login_prompt[64]; char telnet_login_prompt_ignore[64]; char telnet_password[64]; char telnet_password_prompt[64]; + char telnet_cmd[64]; + char telnet_cmd_prompt[100]; int signal_quality_ber_ignore; // 3.1.14. int verify_pdu; // 3.1.14. int loglevel_lac_ci; // 3.1.14.
unterwulf: As per your log it looks like the device echoing data characters it receives. (The seaquake is a login, isn't it?) If so, it is strange that it has not negotiated this feature (if it has there would be something like "Telnet: Got WILL for 1 (0x01), answering DONT." in the log). Nevertheless, smsd doesn't care about any telnet options, so I see the two options here: 1) Somehow force the device not to use telnet echoing (probably some settings via GUI) 2) Implement echoing support in smsd :-) Not sure if I can help here, but who knows. At least I am interested in identifying the root cause of the issue, so drop me a gmail (the same login as on this forum) if you can provide access to the device.
unterwulf: Take a look at the patch from another similar topic http://smstools3.kekekasvi.com/topic.php?post=4011#post4011.
unterwulf: I have no such a modem, but I took a look at smsd behaviour during telnet negotiation using netcat as a telnet server and I see that smsd continuously sends telnet_login if there is no enough delay between login and password prompt. So the session looks like: smsd> AT telnet> login: smsd> <telnet_login> telnet> Password: smsd> <telnet_login> telnet> anything else smsd> <telnet_login> This patch seems to fix this, but probably break something else ;-) --- a/src/modeminit.c +++ b/src/modeminit.c @@ -545,8 +545,12 @@ void negotiate_with_telnet(char *answer, int *len) snprintf(response, sizeof(response), "%s\n", DEVICE.telnet_password); if (*response) + { + *answer = 0; + *len = 0; if ((size_t)write(modem_handle, response, strlen(response)) != strlen(response)) writelogfile(LOG_ERR, 1, "%s: Failed to send response (login/password).", title); + } #undef IAC #undef DONT And, of course, per the user manual you referenced to you need a configuration like the following: telnet_login_prompt = username: telnet_password_prompt = password: init = module1
unterwulf: BTW, support of Solaris seems to be broken in 3.1.12, so I had to fix it somehow to test the building process. What was that bug? The issue was that Solaris' headers do not define the NAME_MAX macro. # gmake cd src && gmake - gmake[1]: Entering directory `/home/vs/src/smstools3/src' cc -D NUMBER_OF_MODEMS=64 -D NOSTATS -W -Wall -D_FILE_OFFSET_BITS=64 -c -o extras.o extras.c extras.c: In function `getfile': extras.c:522: error: `NAME_MAX' undeclared (first use in this function) extras.c:522: error: (Each undeclared identifier is reported only once extras.c:522: error: for each function it appears in.) gmake[1]: *** [extras.o] Error 1 gmake[1]: Leaving directory `/home/vs/src/smstools3/src/smstools3/src' gmake: *** [compile] Error 2 The definition of NAME_MAX is commented out in the Solaris' limits.h with the following note: /* * POSIX 1003.1a, section 2.9.5, table 2-5 contains [NAME_MAX] and the * related text states: * * A definition of one of the values from Table 2-5 shall be omitted from the * <limits.h> on specific implementations where the corresponding value is * equal to or greater than the stated minimum, but where the value can vary * depending on the file to which it is applied. The actual value supported for * a specific pathname shall be provided by the pathconf() (5.7.1) function. * * This is clear that any machine supporting multiple file system types * and/or a network can not include this define, regardless of protection * by the _POSIX_SOURCE and _POSIX_C_SOURCE flags. * * #define NAME_MAX 14 */ I verified this on the following systems ('uname -a' output): * SunOS hostname 5.10 Generic_142900-06 sun4u sparc SUNW,Sun-Fire-V890 * SunOS hostname 5.8 Generic_117000-05 sun4u sparc SUNW,Sun-Fire-480R I could not build the original 3.1.14 under MinGW, so I didn't care of MinGW build at all. Do you really support this platform? Yes, it really is supported, just like most other Unix-style platforms. As far as I can see MinGW does not even support the fork() call [1], so I wonder how can smsd be built under MinGW. Have you really been able to compile it under MinGW? [1] http://www.mingw.org/node/21
unterwulf: Hi Keke, The patchset is ready. Please find it at [1]. An autotools generated distribution is also available at [2]. It probably worth to be looked at firstly, as it doesn't require any additional tools to be installed. Brief description of the new features: - staging area installation support - iconv/libiconv autodetection (can be explicitly enabled/disabled) - inet socket availability autodetection (inet socket will be automatically disabled if the system doesn't support it) - Cygwin autodetection (instead of the os_cygwin parameter) - distribution autogeneration (make dist) - more accurate handling of the installation prefix - no need to edit Makefile, all parameters are configurable via the ./configure options. Using this distribution I was able to build the software on Linux, Cygwin, SunOS 5.8, SunOS 5.9, OpenBSD and FreeBSD. I didn't tested any functionality of the software, only the building process itself (+compilation options etc). BTW, support of Solaris seems to be broken in 3.1.12, so I had to fix it somehow to test the building process. I could not build the original 3.1.14 under MinGW, so I didn't care of MinGW build at all. Do you really support this platform? [1] https://github.com/unterwulf/smstools3-uw/commits/ [2] https://github.com/downloads/unterwulf/smstools3-uw/smstools3-3.1.14-uw.tar.gz
unterwulf: In some cases ICONV is not used, even when it's available, meaning that option is required for this. The same applies to INET_SOCKET. A definition USE_LINUX_PS_TRICK is removed in the next version, so it does not require any option. These cases will be covered by ./configure --without-iconv --disable-inet-socket. Previously os_cygwin was in the Makefile, but it was moved to the configuration. The same settings applies to MinGW too. This still doesn't mean that it needs to be configurable in runtime. I can imagine only two situations when this parameter might need to be configurable in runtime: 1. It may need to be disabled when running under Cygwin. 2. The same binary can be used on several platforms that require different behavior. Does any of two make sense in real life? I am not familiar with MinGW, but my guess is that it still require that binary should be built for it as a target platform, and autoconf seems to be able to recognize mingw as well as cygwin. Simple migration, like described for example at http://markuskimius.wikidot.com/programming:tut:autotools, was not enough. If you can prepare the patch, I'm of course interested to see it. OK. Do you mean that Makefile should be compatible with both GNU make and OpenBSD's make? Actually, no ;-) I mean that, despite the user had gmake, the building process didn't advice him to use it and he had to spent time to find it out himself. OMG! I've just realized that I forgot to mention the main reason that forced me to modify smstools3 build process :-) Current implementation has no means to install the software into a staging area (see Staged-Installs for details), although this feature is very helpful for building packages.
unterwulf: One more portability issue: [solved] Compile on OpenBSD 4.5
unterwulf: Currently I do now know about any portability issues, which could be automatically solved by Autotools (other than "-D SOLARIS"). Actually there are two more: - Automake can detect whether iconv() is available and included in libc/installed as a separate library. - The configuration parameter os_cygwin doesn't need to be configurable in runtime, it should be determined at compilation time. In the past I quickly checked Autotools, but it seemed like a too big job to implement it. It is a false impression :-) Migration to autotools is not a big deal. I can prepare the patch if you are interested in it.
unterwulf: Hi, I just want to know why smstools3 do not use some building system like autotools etc? I would be much easier for users to just perform a couple of well-known steps to have a best build for their system. p.s. I have not found a forum for developers, so asking here. Let me know if there is some better place for such questions. Vitaly

Page:  1

SMSTools3 Community » Search Top

 
Time in this board is UTC.  

Privacy Policy   SMS Server Tools 3 Copyright © Keijo Kasvi.