Supported Hardware
Package Content
Server Install
Client Install
Gateway Install
Tech Info
PDU format
Bugs / Todo
Related Links

Jump to Vim Home Page

Project SMSLink - Known bugs and Todo list

Table of Contents

Please be aware that in the following lists, the order in which the items are presented doesn't represent any idea of relative severity (bugs) or priority (todo items). All those items are just listed, as they say, "in no particular order".

Known bugs

Server bugs

  • (01/09/98) When the parser experience a "parse error" (typing mistake, command not recognized by the grammar), an error message is generated all right, but the next command(s) to be issued, correct or not, won't be processed. You first have to press [return] a few times (as many times as there are words in the first, incorrect command line) to "purge the buffer" that's still holding this line.
    Specially for the "set" command, the input buffer size defined by default by lex doesn't seem to be quite enough. When a very long string is keyed in, a "parse error" will be generated, due to the fact that the closing quote won't be seen by the parser. You then have to press [return] quite a few times to purge the buffer (see previous bug).
    Some side effect here is the fact that if the original string contained a sequence of words meaningfull to the language, they might get executed.
    Solved in 0.56b.
  • (02/09/98) The interactive interface (command prompt) is not displayed correctly when accessed from a DOS/Windows machine. To display the strings correctly, I had to replace '\n' char. by "\r\n". This fix doesn't seem to affect the Unix clients (using standard telnet) in the least.
    But even then, a "parse error" is generated for each character that the DOS/ Windows client is sending (even though the yytext string seems to contain only that character).
    UPDATE: the telnet client have to implement "line mode", not "character mode". I was able to configure Reflection ver. 6 (32bit) to do so (see varia directory, a file called SMS.R1W). But neither the telnet applet that ships with Win95 or WinNT, nor older versions of Reflection seem able to support that. So it would be much better to handle this on the server side.
  • (17/05/01) The way it is implemented now, the "dedicated daemon" code does not follow the same strict policy for access to the shared memory segment we used in the other parts of the code (use of critical sections protected by semaphores).
    Due to the fact that the devices affected by the "dd" flag are reserved for use by that code anyway, we don't believe that this violation should lead to serious troubles (the only other place where that part of the shared memory segment might be accessed is through commands such as "dl" or "stats" in the interactive interface - and then only in R/O mode).
    Still, good coding practices would prompt us to improve this.
    (25/09/01) This might explain the error message relative to the shared memory segment when stopping a server running in "dd" mode.
  • (25/09/01) The server in "dd" mode, when sending, doesn't report the message ID the way the "regular" server does. This prevents the new reporting feature of the client (sendsms >= 0.18b) from working against a server in "dd" mode.
  • (30/07/03) When in "dd" mode, the server will only support the send command.

Client bugs

  • (12/11/98) There seems to be a problem with the client when installed on a 1.2.13 Linux box (old SlackWare install). The commands are delivered all right to the server, but the client exits (times out) before a positive acknowledgement could be received. It returns thus a message to the effect that the message could not be sent, although it was sent successfully.
    I didn't try to increase the timeout value, but since it represents a number of seconds, it should behave the same no matter what the kernel revision.
    (25/09/01) This problem might be solved by version 0.18b of the client, and the new way it implements the dialogue with the server. I haven't had the ability to test that yet.

Gateway bugs

(momentarily empty).

Todo list

Server Todo list

  • Clean code (add tests after each malloc() call if not the case yet).
  • Improve Makefiles. Integrate them in an automake/autoconf environment.
  • Might be needed to add "routing help" for specific routes (i.e., how can we build a solution that would allow us to deliver SMS straight to GSM networks that are not normally reachable from the regular provider). More on this after some testing.
  • Solve this "char" versus "line" mode problem in telnet.
  • Improve the procedure that will save the incoming messages to file. Currently, messages might get lost in the following scenario: if the mailbox file is locked (by another application) when the server tries to save the messages, an error is issued but the server doesn't retry, it just goes on and happily removes the messages from the SIM, meaning they're just lost.
  • Improve parsing (we should use a separate procedure to get the commands, then parse them one at a time)
  • Improve variable handling (and typing) in the parser.
  • Add "validity period" handling for the SMS messages. There should be a configurable application-wide default value, and a command supported by the parser for the user to override this default.
  • Add support for "Flash SMS" (those that appear on the handy display without you having to press any key to select them).
  • Add command line parameters handling in the server (listening port, interval between incoming messages checks, ...). Work in progress: this is partially implemented in 0.54b, and will be more thoroughly in upcoming 0.55b. Implemented in 0.55b.
  • Integrate MySQL patch. Work in progress: will be available in upcoming 0.55b. Implemented in 0.55b.
  • Add queuing mechanism in addition to immediate delivery. Provide possibility for immediate mode to either fail and return an error code or be queued instead. Work in progress: this will be partially implemented in upcoming 0.55b. Implemented in 0.55b.
  • Add a "load" command to send pre-formatted PDU strings.
  • Add support for logos and ringtones handling.
  • Add a "long" parameter to the "devicelist" command, that will display all the properties attached to each module, including a list of its option flags. Implemented in 0.55b.
  • Add the appropriate commands for the administrator to interactively add or remove an option flag from a module without having to stop and restart the server.
  • Integrate the mail2sms perl script provided by Stan. Devise an install procedure and document it.
  • Review code for security risks. Try to make server drop root priviledges when they're not needed anymore.
  • Add support for SNPP protocol in both client and server (while still keeping the "interactive" interface as it is now). We could have the server listening on 2 separate ports: one meant for client programs and parsing SNPP requests, and the other meant for administrators only, for maintenance or debugging. I could also build a separate snppd daemon, that would just accept and queue messages. sms_serv(1) would pick those messages up and send them. Might be the easiest route.
  • When increasing the capabilities of the "interactive" interface, it might become usefull to include some form of authentication, at least when accessing the more sensitive features of that interface.
  • Add a configuration file (global to both server modules) to ease the handling of more options to come.
  • Add an "enable" mode to sms_serv interactive interface ("enable" in the sense that Cisco IOS gives it), allowing for some data / actions to be restricted to the administrator.

Client Todo list

  • Clean code (add tests after each malloc() call if not the case yet).
  • Improve Makefiles.
  • Add parameter to override default port for service. Modify algorithm used to get it. If value provided as parameter, use that. Otherwise, try to get it through getservbyname(), and only when that fails use the compiled-in default value. Implemented in 0.18b.
  • Improve error reporting by providing some analysis of the error code returned by the module (the +CMS ERROR, for instance).
  • Try to improve performance (regarding this long timeout). Implement the same approach used for "fast modem response" in the server. Implemented in 0.18b. If desirable, control that behaviour through a command-line option. Not needed any more (notion of "fast" vs. "slow" mode dropped on the client side).
  • Build a GUI-based client for Linux.

Gateway Todo list

  • The gateway process currently supports only the inbox file as a message store. Since the server now also supports a back-end database, it would make sense to expand the gateway in order for it to be able to also retrieve incoming messages to process from the DB inbox table.
  • When processing the inbox file, the gateway process currently dies when it encounters some invalid inbox entry (any line it can't parse). It would be much more efficient to then remove the offending line and store it in a "rejects" file (in the same directory as the inbox file). This would allow for easier debug and analysis, or for "salvage" by the administrator.

Last Modified: September 29th, 2006.
philipa STRUDEL scarlet PUNKT be
SourceForge Logo