There is one entry per line, and each line has the format:
dev:pin:puk:addr:defsca:defmode:pinpause:model:provider[:flags]
Lines beginning with '#' are treated as comments and ignored. Empty lines are allowed and ignored. Invalid entries are silently ignored (and the server will report the number of valid entries loaded at startup).
The field descriptions are:
- dev
- the Unix device name for the module (without the /dev/ part). Usually a serial port (/dev/cuax) or a more meaningfull softlink to it (/dev/gsm).
- pin
- the PIN code for the SIM card installed in that module (4 digits).
- puk
- the PUK code for the SIM card installed in that module (up to 16 digits).
- addr
- the Caller ID (i.e. phone number) allocated to the SIM card installed in that module.
- defsca
- default Service Center Address (or SMSC) - usually that of the provider network (check with them). The value set here only defines the default SCA for the device. Users can override it through the set smsc command.
- defmode
- default SMS sending mode. Supported values are 0 and 1 (0 = PDU mode (aka binary mode), 1 = text mode (aka ascii mode)). The value set here only defines the default behaviour for the device. Users can override it through set mode command. Please keep in mind that not all devices support all modes.
- PINpause
- the amount of time (in seconds) the server should sleep(3) after having provided the PIN code to the device. The required amount will vary wildly from one setup to the next (I feel it is linked more to the provider or the GSM network than to the hardware). Typical values here can range from 20 secs. to 120 secs. Setting too low a value will result in a "+CMS ERROR: 515" when issuing the next AT+ command.
- model
- short model name, as defined in /etc/gsmcaps file. The short model name will be translated by the server program to a flags-based capacity matrix for the module, that will be used as a primitive form of driver to control the way the server program will interact with the GSM module. Should you wish to tinker with the translated values, please read /etc/gsmcaps file.
- provider
- GSM network provider name (comment only).
- flags
- Optional field. A comma separated list of flags defining the way the server program will handle that device. The supported flags are:
* dd: attaches a dedicated daemon to the device - processes incoming messages more efficiently. Specify only one of dd, init or poll per device.
* init: assumes exclusive access to the GSM modem and will initialize it at server startup. This allows for a faster sending / mailbox check procedure, as only the variable settings are checked at that time (mode, SCA, registration, etc.). Be aware, though, that when using this mode, the GSM modems can't be power-cycled while the server process is up. Specify only one of dd, init or poll per device.
* poll: uses the regular polling mechanism. Doesn't make any assumption as to the current status of the GSM modem. Specify only one of dd, init or poll per device.
* inbox: stores the incoming messages in an inbox-like file. You can specify any combination of inbox, db and prog for the same device.
* db: stores the incoming messages in a back-end MySQL database table. You can specify any combination of inbox, db and prog for the same device.
* prog: feeds the incoming messages to an external program. You can specify any combination of inbox, db and prog for the same device.
* skip: skips (ignores) the device during inbox runs. Use this flag in a multi-device setup when you want one (or more) device(s) never to be polled for incoming messages. The skip flag conflicts with and overrides any of inbox, db and prog for the same device.
* fast: enables the use of the "fast modem response" method. This will leave the modem listening loop as soon as a catch phrase is received, and makes the waiting time a lot shorter.
* r4: instructs the mailbox checker daemon (if enabled) to always read all incoming messages from the SIM memory (instead of the default behaviour, which would read only the "UNREAD" ones). Pro: it prevents stale messages from clogging the SIM memory positions (a situation which would render it unable to receive more messages). Con: it opens the possibility that a given message might be processed more than once downstream of sms_serv (by any application processing the inbox, for instance).
Part of the code is (c) Riccardo Facchetti.
The code also includes contributions from Philipp Klaus <pklaus@access.ch>, Andrew Worsley <epaanwo@asac.ericsson.se>, and numerous others. All contributors are acknowledged in the CHANGELOG document, and in the comment headers of the source files they modified.
SMSLink has been released to the public under the GNU GPL.
Home page: <http://smslink.sourceforge.net/ >