Receiving and processing SMS messages on a Linux machine

In one of our recent projects, the development team was tasked with collecting the most realistic contact information about users of our site. A heated discussion of the correct and incorrect forms of registration, one- and two-step, addition of information as you use the site ... It seemed that the flow of ideas would not stop. However, none of them guaranteed that as a result we would not get a bunch of worthless data. Validate? You can, but do you foresee everything? Activating an account through a mailbox to validate it? But a bunch of services like 10 Minute Mailnullify the effect. In addition, the specifics of the project did not allow to stretch the registration process too much. It was decided that the user should go in, do his own thing, and then activate his account or not. In the end, the phrase “And let's activate by SMS!” Sounded . Searching for providers, studying price lists and abandoning the idea of ​​putting SMS processing on a third-party office ... It became clear that they would have to accept and process them themselves.

There was a modest experience with VOIP / Asterisk and the selection of equipment for a VOIP gateway. I used the old links to my Chinese brothers to look for SMS-gateway. But firstly, time was running out, and secondly, on the experience of working with them, the first time rarely something came out, so it became interesting whether a regular USB GSM modem can handle it. And, looking ahead, I will say that this decision was correct. At least at this stage.

Server Tuning


So, the Huawei E1750 modem (HSPA USB Stick) with a contract came into my hands. The first thing a person who faces a similar task will face is that all the latest GSM-modem models, to please Windows users, are first recognized in the system as a storage device (SCSI CD-ROM). Autorun is launched from it, which installs the drivers and switches the modem to modem mode (oh how!). As soon as I found out, I decided to “come”. However, another half hour, and the usb_modeswitch utility was found , which performs modem mode switching. Only after that the modem will work for its intended purpose. It starts and configures simply, there is nothing special to write here.

Well, with god! Information at this point was already dug not to say that much, but enough to dig in the right direction. Existing solutions were filtered on the basis of “works like a daemon”, as a result, there was only one candidate - SMS Server Tools. It should be noted that the original package is no longer being developed, but its continuation SMS Server Tools 3 is not only developing, but it is also perfectly supported by its creator Mr. Keijo "Keke" Kasvi.

Unfortunately, in my beloved Gentoo there was no ebuild for the latest version, the latest version is 2.2.20. But, not googling for long, I found a ready-made ebuild for the 3rd version, which I compiled after editing it a bit. At the moment, version 3.1.14 is installed and stable for me.

As it turned out, configuring smstools is so simple that you can already start receiving messages with almost the initial config. No, of course, if your SIM card is locked with a PIN code, you will have to add it to the configuration, but this is done very simply.

The structure of the configuration file is also understandable to disgrace (viva unix-way!). At the beginning of the file, we specify the global settings of the daemon, and then in the sections we describe the settings of our devices:
# Глобальные настройки демона
...
...

# Наш модем и его настройки
[Huawei E1750 ]
...

# И еще одно устройство, если оно у нас есть, со своими настройками
[AnotherModem]
...


Global settings

The most important parameter is which devices the daemon will poll for new messages. If you have only one device, like mine, just write down devices = HuaweiE1750, if you have several, list them here with a comma.

Two other important parameters are user = smsdand group = sms. People familiar with Linux do not need to explain their meaning, but I will confine myself to a reminder of the correct rights to all resources to which the daemon should have access. So I mention about these instructions, like pidfile = /var/run/smsd/smsd.pid, logfile = /var/log/smsd/smsd.logthe value of which must also be clear. By the way, at the time of debugging, I recommend that you also insert instructions in the configuration loglevel = 7, this will allow you to track what is happening inside the daemon. In the future, I set loglevel = 5.

Modem settings

In principle, here, too, as promised, everything is simple. However, I encountered some problems, because of which I actually decided to share information with you.

One problem was the burning desire of the modem all the time to jump to a new device. Once it was defined as /dev/ttyUSB0, another time under a different number. This state of affairs did not suit me. Therefore, I began to look for how to write udev rules for devices. However, when I was ready to make my changes, it turned out that ebuild usb_modeswitch had already done this for me by adding a file to the system /lib64/udev/rules.d/40-usb_modeswitch.rulesaccording to which a symlink to the device at the address appeared in the system /dev/gsmmodem. We will write it in the configuration.

The second problem was the modem freezing from time to time. Unfortunately, there was no longer time to read the materiel, and Google gave so many options that it all made no sense to try them all. Therefore, not really counting on help, I crawled to the smstools3 forum. What were my surprise and joy when keke answered my post after a miserable 2-3 hours. No, he did not give the exact solution, however, two lines that he recommended adding to the config once and for all saved me from freezes. It still remains a mystery to me where to get the values ​​for them; I did not find the technical documentation for the modem: Well, the third problem that caused the whole fuss was started was writing an SMS handler. To do this, an instruction was added to the config
check_memory_method = 1
memory_start = 0


eventhandler = /usr/local/scripts/activatewithin which the request for account activation was sent to the project server. The script receives two parameters - the type of event and the message file. He pulls out the data we need from it, and sends it to the server.

Total, we got here such a short config:
devices = Huawei
loglevel = 5

user = smsd
group = sms
logfile = /var/log/smsd/smsd.log
infofile = /var/run/smsd/smsd.running
pidfile = /var/run/smsd/smsd.pid

alarmlevel = 7
alarmhandler = /usr/local/scripts/activate/smsd-alarm

[Huawei]
device = /dev/gsmmodem
baudrate = 115200
pin = 1111
incoming = high
cmgl_value = 0
check_memory_method = 1
memory_start = 0
eventhandler = /usr/local/scripts/activate


Unexpected profit


Initially, the registration form contained the Mobile Phone field - this was in the requirements of the project. The incoming SMS should have been sent from the specified phone, and the account with this phone was activated. However, as it turned out, users get stuck when they don’t need to write anything in the message. First, after registration, the instruction “Send a message with the text“ F ”to number 12345678 appeared. Then another, brilliant idea, as it seems now, was born: the Mobile phone field was removed from the form, after a short registration (Name, Surname, E-mail / login, Password), the user is given a code that he must send to the specified number. The account is located by this code, and the phone from which the SMS came is entered in the user profile. Voila, we have a user, we have a real phone number, we can add a bunch of phones to our profile, and change the phone number in the profile if the old one is lost, send another SMS and delete the old number.

Summary


  • Almost got a free SMS processing system
  • Speed ​​up the process of registering users on the site
  • Received real data about the user (it remains to come up with how to send us passport scans)
  • We gained experience that I would like to use for sending out notifications about some events on the servers (sending was not considered in the considered case, but I think there will be no problems)
  • We implemented everything in a very short time (ehhh, if not for the problem with the modem freezes)

Also popular now: