15. 12. 2023
NetEye, Unified Monitoring
12. 12. 2022
Juergen Vigna
NetEye, Unified Monitoring
Using More Than One SMS Gateway on a Server and Handling SMS Queues
Sending an SMS requires time, between 5-7 seconds. This means that if you have to write a lot of SMS’s, you have to attach more than one SMS gateway to your server to be able to send them within a certain time frame. This is possible using the USB connection of the SMS gateway.
As this is non-standard, I will quickly explain how this is done and how the Gateways are then seen by the system.
Normally you attach one modem to the serial port (ttyS1) and other modems to the USB ports, while if needed also putting a USB hub on the server to add more modems. The serial-attached modem will typically be /dev/ttyS1, but the USB attached modem should be named with their serial/by-id device, e.g.: /dev/serial/by-id/usb-WAVECOM_WAVECOM_MODEM_BH1940141209302-if00.
Under NetEye 4, when there is only 1 modem attached, smsd will use this directory:
/neteye/local/smsd/data/spool/checked
When you want to use more modems you’ll have to use “queues”, and each queue will then use its own directory. Set them up in smsd.conf like this:
devices = GSM1,GSM2 logfile = /neteye/local/smsd/log/smstools.log loglevel = 6 #user = smstools # 3.1.5 introduced smart logging # once your configuration is OK, set log level lower (5 is good in most cases) smart_logging = yes infofile = /run/smsd/smsd.working pidfile = /run/smsd/smsd.pid # PLEASE DO NOT EDIT THESE PATHS failed = /neteye/local/smsd/data/spool/failed incoming = /neteye/local/smsd/data/spool/incoming checked = /neteye/local/smsd/data/spool/checked outgoing = /neteye/local/smsd/data/spool/outgoing [queues] GSM1 = /neteye/local/smsd/data/spool/GSM1 GSM2 = /neteye/local/smsd/data/spool/GSM2 [GSM1] # Windows: /dev/com1, Solaris: /dev/cua/a, Linux /dev/ttyS0 device = /dev/ttyS1 incoming = yes cs_convert = yes #pin = 1111 baudrate = 115200 mode = new regular_run_interval = 60 regular_run_cmd = AT+CREG?;+CSQ;+COPS? regular_run_statfile = /dev/shm/sms_stat queues = GSM1,GSM2 #eventhandler = /usr/share/neteye/eventhandler/bin/ehsmshandler.sh #alarmhandler = /usr/local/bin/smsalarm [GSM2] # Windows: /dev/com1, Solaris: /dev/cua/a, Linux /dev/ttyS0 device = /dev/serial/by-id/usb-WAVECOM_WAVECOM_MODEM_BH1940141209302-if00 incoming = yes cs_convert = yes #pin = 1111 baudrate = 115200 mode = new regular_run_interval = 60 regular_run_cmd = AT+CREG?;+CSQ;+COPS? regular_run_statfile = /dev/shm/sms_stat_gsm2 queues = GSM2,GSM1 #eventhandler = /usr/share/neteye/eventhandler/bin/ehsmshandler.sh #alarmhandler = /usr/local/bin/smsalarm
You can see we are using 2 modems here and therefore we use 2 queues, which we name like the device itself (GSM<number>). You see also in the “queues” section that we define the “checked” directories where smsd is putting the messages to send. Then each modem will work separately on the queues you give it.
We don’t just want both modems sending only their own messages, but also that if one modem is broken then the other will send its messages as well. We thus put all the queues into each modem configuration, and the modem will then read the messages from each queue, but in the order you give it. So as you see above we start with the GSM1 queue for the first modem and the GSM2 queue for the second, and then if you send 2 messages at the same time, GSM1 will immediately send from the GSM1 queue, while the second modem will send at the same time from the GSM2 queue.
The smsd daemon will always put the messages in the next queue, returning to the first queue once the last has been used. So smsd will put the first message to be sent into the GSM1 queue, the second into the GSM2 queue and the third on the GSM1 queue and so on.
Such a configuration gives you not just faster send times for the messages (as always, n messages are sent at the same time, where n is the number of modems attached), but also a sort of High Availability where when one modem doesn’t work anymore others can take over and send its messages as well.
A last hint: don’t forget to create the GSM<n> spool directories and give them the right permissions, since they don’t exist in a standard setup.
Juergen Vigna
NetEye Solution Architect at Würth Phoenix
I have over 20 years of experience in the IT branch. After first experiences in the field of software development for public transport companies, I finally decided to join the young and growing team of Würth Phoenix. Initially, I was responsible for the internal Linux/Unix infrastructure and the management of CVS software. Afterwards, my main challenge was to establish the meanwhile well-known IT System Management Solution WÜRTHPHOENIX NetEye. As a Product Manager I started building NetEye from scratch, analyzing existing open source models, extending and finally joining them into one single powerful solution. After that, my job turned into a passion: Constant developments, customer installations and support became a matter of personal. Today I use my knowledge as a NetEye Senior Consultant as well as NetEye Solution Architect at Würth Phoenix.
Author
Latest posts by Juergen Vigna
23. 02. 2024
Log-SIEM, NetEye, Unified Monitoring
Monitoring Logs in Elasticsearch: A Practical Example
30. 11. 2023
Log Management, Log-SIEM, NetEye, Unified Monitoring
Monitor Your Elasticsearch Agents Registered in the Elastic Fleet Server
28. 04. 2023
Icinga Web 2, NetEye, Unified Monitoring
Elasticsearch Snapshots and How to Monitor Them