
[images/mobile.gif] [images/smslink.gif]

-------------------------------------------------------------------------------


General                 Project SMSLink - FAQ
Introduction
Platforms
Supported_Hardware      Table of Contents
Package_Content

                        * The_server_doesn't_seem_to_process_incoming_messages
Installation            * Using_a_multi-serial_board_/_more_than_2_serial_ports
Download                * Will_SMSLink_support_Nokia_phones_+_DataSuite_cable_?
Server_Install          * Run-time_error_after_upgrading_to_2.2.x_kernel
Client_Install          * Server_hanging_in_the_beginning_of_the_sending
Gateway_Install           process
                        * Server_hanging_in_the_beginning_of_the_sending
                          process_(bis)
Tech Info               * Yet_another_"blopen_mdm_line()_failed"_cause.
Changelog               * Hardware_or_software_flow_control.
FAQ                     * The_server_is_running,_but_I_can't_connect.
Drivers                 * Enabling_debugging_in_the_program_modules.
Related_Links
                        -------------------------------------------------------

[Jump_to_Vim_Home_Page] The server doesn't seem to process incoming messages

                        One thing to remember concerning processing of incoming
                        SMS messages is that it will be handled by polling each
                        configured device's SIM card for messages. To do that,
                        the server will spawn a child process that will attempt
                        to get a lock on each device in turn and poll them for
                        stored messages (the device will store incoming
                        messages in the SIM automatically).
                        This polling of the devices occurs only at specified
                        interval (by default, once an hour). This interval can
                        of course be customized to the administrator's desire.
                        To do so, in the project source tree, edit the file
                        server/sms_serv.h and change the line reading
                        #define MBCHKINTERVAL 3600 /* mailbox check interv.
                        (sec)*/
                        to define the appropriate number of seconds. It is not
                        recommended to set it lower than 120 (once every 2
                        min.). Please remember than the more often you poll
                        your devices for incoming messages, the more you reduce
                        the window for sending outgoing messages. As an
                        administrator, you have to find the right balance
                        between both tasks according to the application needs.
                        To disable this polling altogether, set MBCHKINTERVAL
                        to 0 (zero).
                        The server module will report the value of this
                        parameter through syslog when loading, with messages
                        like the following:
                        Nov 6 15:09:55 vger sms_serv[1192]: mailbox check
                        function enabled, first check in 3600 secs.
                        At the present, this parameter can only be choosen at
                        compile-time, but future versions of the server should
                        allow the administrator to specify this interval on the
                        command-line.
                        -------------------------------------------------------

                        Using a multi-serial board / more than 2 serial ports

                        By default, the server ships with a source tree
                        configured to handle at most 2 (two) GSM modules. This
                        is not due to any internal limitation of the software,
                        but to acknowledge the fact that most PC hardware only
                        have 2 physical serial ports. Defining more than 2
                        devices in your configuration files wouldn't make sense
                        in this case.
                        But of course, some situations might require the use of
                        specific hardware allowing one to drive a lot more than
                        2 serial devices (such as through the use of multi-
                        serial boards). SMSLink is perfectly equiped to handle
                        that. The only think you'll have to do is make sure,
                        before you compile the server, to edit server/
                        sms_serv.h and alter the value of MAXMODEMS to reflect
                        the (projected maximum) number of serial devices you
                        will want to connect to the server.
                        To repeat myself, this maximum number of devices
                        doesn't have to be reached from the start. The only use
                        of this value is to provide some form of sanity check
                        for the devices configuration file (by default, /etc/
                        gsmdevices), to avoid an unreasonable amount of devices
                        being defined by mistake. It should basically reflect
                        the maximum amount of (external) serial devices your
                        hardware is able to support.
                        -------------------------------------------------------

                        Will SMSLink support Nokia phones + DataSuite cable ?

                        The problem with the Nokia phones is being able to
                        reach their AT command interface at all ! Nokia phones
                        require a driver to access that AT command interface
                        (implemented in the software part of the DataSuite
                        product -- proprietary, closed-source and Win32-only if
                        you hadn't guessed). Their proprietary protocol has
                        already been reverse-engineered, though (check the
                        Gnokii_project), but Gnokii doesn't provided a fully
                        functionnal AT command set yet -- so that's not usable
                        yet with SMSLink.
                        Maybe later.
                        Folding the Gnokii-developped Nokia protocol into
                        SMSLink source tree is not on my TODO list right now.
                        -------------------------------------------------------

                        Run-time error after upgrading to 2.2.x kernel

                        After upgrading an existing server install to version
                        2.2.x of the Linux kernel, you might encounter the
                        following error:
                        ----------cut-----------
                        got </dev/gsm>, now sending...
                        tty_io.c: process 160 (sms_serv) used obsolete /dev/
                        cua0 - update software
                        to use /dev/ttyS0
                        ----------cut-----------
                        To solve this error, go to /dev, remove your gsm
                        softlink to cuax and create a new one (with the same
                        name) to ttySx (where x is also the same, obviously).
                        As long as you kept the same name for the gsm softlink,
                        there's nothing to change in the configuration files.
                        -------------------------------------------------------

                        Server hanging in the beginning of the sending process

                        After installing the server software, you want to test
                        it through the interactive interface (telnet localhost
                        sms), you supply a username, a destination GSM number
                        and a message, and you then type "send". The server
                        answers:
                        ----------cut-----------
                        got </dev/gsm>, now sending...
                        ----------cut-----------
                        ...and then hangs.
                        What is most likely happening is that the directory
                        where the "libmodem" library would like to store its
                        lock file doesn't exist. By default, libmodem expects a
                        directory called /usr/spool/uucp. It should be owned
                        uucp:uucp (or root:root if the uucp user doesn't exist
                        on your system), and mode drwxrwxrwt (watch for the 't'
                        bit). It is indeed not created by default on all
                        distributions and / or configurations. Just create it
                        with the aforementionned rights and ownership if not
                        present. You can also edit dial/modems.h.in in the
                        libmodem source tree and alter the LOCKDIR define (not
                        the recommended solution).
                        -------------------------------------------------------

                        Server hanging in the beginning of the sending process
                        (bis)

                        The symptoms here are similar to the previous case.
                        When you type "send", the server answers:
                        ----------cut-----------
                        got </dev/gsm>, now sending...
                        ----------cut-----------
                        ...and then hangs.
                        In the syslog log file, you'll find an entry saying
                        something like:
                        ----------cut-----------
                        ...sms_serv[1147]: call to blopen_mdm_line() failed.
                        ----------cut-----------
                        What could be happening is that the flow control to the
                        GSM module is no set correctly. Please check the last
                        field of the relevant line in /etc/modems. A value of 0
                        (zero) means hardware flow control. This seems to work
                        fine with Falcom A1 and Wavecom WMO1. If you have
                        problems with a Falcom A2, you might want to try with a
                        value of 1 (one). This will use software flow control
                        (XON-XOFF).
                        Thanks to Piero_Baudino for pointing that out.
                        -------------------------------------------------------

                        Yet another "blopen_mdm_line() failed" cause.

                        Should you notice the dreaded
                        ----------cut-----------
                        ...sms_serv[1147]: call to blopen_mdm_line() failed.
                        ----------cut-----------
                        appear in your logs, and after ruling out the other
                        possible causes (see above 2 entries), you might want
                        to check your /etc/gsmdevices for duplicate entries.
                        That error can occur when you mistakenly defined
                        multiple entries in /etc/gsmdevices for the same device
                        (identical first field in /etc/gsmdevices). The
                        sms_serv(1) daemon will then consider it has 2 modules
                        attached and try to use the one it has twice at the
                        same time (when multiple clients are sending
                        simultaneously), resulting (for the second client) in a
                        failure to lock it.
                        Thanks to Stanley_Hopcroft for reporting this.
                        -------------------------------------------------------

                        Hardware or software flow control.

                        On FreeBSD:
                        It looks like that FreeBSD works better with software
                        flow control (XON-XOFF) than with hardware. In
                        Stanley's own words:
                        --------------------------------------------------
                        The last note is that the message loss with hardware
                        flowcontrol set
                        in /etc/modems is worse than XON/XOFF. Message loss
                        begins when the
                        message rate exeeds 12/min (ie 5 seec between messages)
                        rather than
                        about 30 messages/min with XON/XOFF.

                        I think this suggests that FreeBSD does not have a
                        termios or whatever
                        that supports hardware flow control (from man termios

                        The CCTS_OFLOW (CRTSCTS) flag is currently unused

                        )
                        --------------------------------------------------
                        Hence, make sure that CTSRTS support is in the kernel,
                        and that you enabled it on the "sio" serial driver.
                        -------------------------------------------------------

                        The server is running, but I can't connect.

                        You can see through the process list and the messages
                        logged in the system log that the server seems to be
                        running fine, but when trying to connect to it from
                        another machine over the network, you get the message:
                        bernward:~$ telnet vger sms
                        Trying 192.168.100.254...
                        Connected to vger.ste.scitex.com.
                        Escape character is '^]'.
                        Connection closed by foreign host.
                        bernward:~$
                        This is most likely due to an error in implementing the
                        access control mechanism. Either you forgot to allow
                        connection from that specific host / network, or the
                        line which should allow access was dropped by the
                        server due to some format error.
                        Also take into account that each entry in /etc/
                        gsmaccess should contain a subnet mask. Make sure the
                        host from which you're trying to open the connection is
                        indeed part of the subnet you defined in the access
                        file (to allow a single machine, use a subnet string of
                        "/32").
                        Please also remember that the entries in the access
                        file are scanned top-down and matched on a "first-fit"
                        basis. This means that the order of the lines in the
                        file is relevant, and that denying access to network X
                        and then allowing access to host Y, member of network
                        X, won't work. Put it the other way around.
                        A way of debugging this is first to look at the
                        messages logged in the system log of the server. The
                        number of valid ACL entries is mentionned, or the fact
                        that access control is disabled in case no access file
                        was found. Example:
                        Nov 15 16:17:04 vger sms_serv[1289]: successfully
                        loaded 12 ACL entries.
                        Also, in case a connection is rejected based on the
                        current set of ACL's, a message similar to the
                        following is logged:
                        Nov 15 16:20:21 vger sms_serv[1289]: illegal connect
                        from [192.168.100.10]
                        A good way to check the exact set of ACL's currently
                        used by the server is to connect to it from an allowed
                        machine (obviously), and to issue the "acl" command at
                        the "SMS>" prompt.
                        -------------------------------------------------------

                        Enabling debugging in the program modules.

                        When faced with a tricky issue to debug (or when
                        attempting to add support for a new brand of GSM
                        module), you might need to turn debugging on in any of
                        the program modules. I might also ask you to do this if
                        you mail me for help: that way, you can simply forward
                        me the collected debugging info.
                        Here are the steps involved in enabling the debugging
                        (and capturing its output in a file). In the example
                        below, I'll focus on the server module (sms_serv(1)),
                        but the procedure is exactly the same for any other
                        module.
                        Basically, you'll need to recompile the module with
                        debugging enabled. So go to the source tree, and begin
                        by issuing a make clean command.
                        Then edit the Makefile and uncomment the line which
                        reads:
                        #DEBUG = -DINCL_DEBUG_CODE
                        (just remove the "#" sign in front). You can now
                        recompile the module (make sms_serv). When finished,
                        just copy the new executable in place or consider to
                        launch it from the source tree (a version with
                        debugging enabled is not meant for production use
                        anyway).
                        You now want to start the server, but also make sure
                        that any debug info it will output will be kept in a
                        file for further analysis. The way to go is to use the
                        script(1) utility (should be installed by default on
                        most distros).
                        So, first start the script:
                        # script /tmp/smslink-debug.txt
                        Script started, file is /tmp/smslink-debug.txt
                        Then, "inside" the script, start the server:
                        # ./sms_serv
                         (lots of debugging info output on the screen and
                        dumped in the file -- the server is running now).
                        You can now connect to the server (either from inside
                        the script or from outside, depending on what it is
                        that you need to debug) and test what you need to test.
                        # telnet localhost sms
                        Or you might just want to wait for the server to
                        automatically initiate a mailbox check (if that's the
                        part giving you troubles).
                        When you saw that you captured the bit of info you
                        needed, you can stop the server and exit the script
                        (will commit any unsaved debug info to the file).
                        # killall sms_serv
                        # exit
                        exit
                        Script done, file is /tmp/smslink-debug.txt
                        That's it. You can now browse through the debug trace,
                        and correlate it with regular messages dumped to your
                        syslog files (/var/log/messages and/or /var/log/syslog
                        -- see /etc/syslog.conf to check which).

-------------------------------------------------------------------------------

Last Modified: December 30th, 2000. [SourceForge_Logo]
     philipa@tiscalinet.be

