📜 ⬆️ ⬇️

Receiving and processing SMS messages on a Linux machine

In one of our recent projects, the development team was tasked to collect the most realistic contact information about the users of our site. Hot discussion of the correct and irregular registration forms, one- and two-step, the addition of information as far as using 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 useless data. Validate? It is possible, but does everything provide? Account activation via mailbox for its validation? But a bunch of services like 10 Minute Mail negate the effect. In addition, the specifics of the project did not allow too stretching the registration process. It was decided that the user should log in, do his own thing, and then activate his account or not. In the end, the phrase "And let's activate by SMS!" . The search for providers, the study of price lists and the refusal of the idea to charge SMS processing to 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 equipment selection for the VOIP gateway. Climbed on the old links to the Chinese brothers to search for SMS-gateway. But firstly, time was running out, secondly, because of the experience of working with them, something rarely comes out from the first time, so it became interesting if a normal USB GSM modem can handle it. And, looking ahead, I will say that this decision was the right one. At least at this stage.

Server Tuning


So, the Huawei E1750 modem (HSPA USB Stick) with my contract fell into my hands. The first thing that a person who will undertake a similar task will face is that all new models of GSM modems, for the sake of Windows users, are recognized in the system as a storage device (SCSI CD-ROM) first. It runs autorun, which installs the driver and switches the modem to modem mode (oh, how!). As soon as I learned this, I decided to "come." However, another half an 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 is launched and configured simply, there is nothing special to write here.

Well, with god! Information at this point has already been dug not to say so much, but enough to dig in the right direction. The existing solutions were filtered by the feature “works like a demon”, and as a result there was only one candidate left - 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 is also well supported by its creator Mr. Keijo "Keke" Kasvi.
')
Unfortunately, my favorite Gentoo did not have an ebuild for the latest version, the latest version available is 2.2.20. But, not long googling, I found an already ready ebuild for the 3rd version, which I compiled after a small edit. At the moment I have installed and stable version 3.1.14.

As it turned out, setting up smstools is so simple that almost with the initial config you can already begin to receive messages. No, well, 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 ugliness (viva unix-way!). At the beginning of the file we set 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 list devices = HuaweiE1750 , if you have several, list them here separated by commas.

Two more important parameters are user = smsd and group = sms . People familiar with Linux, to explain their value is not necessary, I restrict myself to just a reminder of the correct rights to all the resources to which the demon must have access. Well, I will mention about such instructions as pidfile = /var/run/smsd/smsd.pid , logfile = /var/log/smsd/smsd.log , the meaning of which should also be clear. By the way, at the time of debugging, I recommend inserting the loglevel = 7 instruction into the configuration, this will allow you to keep track of what happens inside the daemon. Later I set loglevel = 5 .

Modem settings

In principle, here too, as promised, everything is simple. However, I ran into 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 off on 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 the /lib64/udev/rules.d/40-usb_modeswitch.rules file to the system, according to which the system appeared a symlink to the device at /dev/gsmmodem . We will write it in the configuration.

The second problem was the hang of the modem from time to time. Unfortunately, there was no time to read the materiel, and Google gave so many options that it did not make sense to try them all. Therefore, not counting on help, I crawled to the smstools3 forum. What were my surprise and joy when keke responded to my post after a miserable 2-3 hours. No, he did not give an exact solution, but two lines that he recommended adding to the config once and for all saved me from freezing. For me, it still remains a mystery where to take values ​​for them, I did not find technical documentation on the modem:
check_memory_method = 1
memory_start = 0


Well, the third problem, because of which all the fuss was started, was the writing of an SMS handler. To do this, the eventhandler = /usr/local/scripts/activate instruction was added to the config, inside which a request to activate the account was sent to the project server. The script receives two parameters - the type of event and the message file. Pulls out the data we need, and sends it to the server.

So, we got 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 project requirements. 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 are at a standstill when they do not need to write anything in the message. At first, after registration, the instruction appeared “Send a message with the text“ F ”to number 12345678”. Then another, ingenious idea seemed to be born: the Mobile phone field was removed from the form, after a short registration (First Name, Last Name, E-mail / login, Password), the user is given a code that he should send to the specified number. This code is an account, and the phone from which the SMS came from is recorded in the user profile. Voila, we have a user, there is his real phone, there is an opportunity to add a bunch of phones to your profile, and change the phone number in the profile in case of loss of the old one, by sending another SMS and deleting the old number.

Results


Source: https://habr.com/ru/post/111305/


All Articles