This is the concluding part of the article; here is the beginning
Last time, I wrote about how I implemented device monitoring; now we'll discuss management. In discussions with the 'techies' from the Client's side, I often encounter a limited perception of the capabilities of such small devices (with low memory resources and performance); many believe that 'the most we will need is to send a reboot, for something more serious — we'll send a crew.'
But practice shows that this is not quite true. Here is a small list of common typical tasks:
- Network diagnostics and troubleshooting. Behind the Ethernet port of your router, another device usually 'lives,' which has its own internal IP address. Sometimes, it can (or needs to) be 'pinged.' Or tunnel management — if on a router working through a 3G modem, the tunnel fails to establish, but we can see the router itself.
- System maintenance. Firmware updates, upgrades of service scripts.
- Equilibristics. This could be called 'twisted practices,' but the term 'equilibristics,' as I quote, ‘the ability of a circus artist to maintain balance in an unstable body position’ — fits better. Such situations arise due to the client's budget constraints. Below, I've provided a couple of examples, but since they are not directly related to the topic of discussion, I have placed them in the notes.
Wi-Fi monitoringThe fashionable topic of the last five years has mainly been among federal retail networks. You leisurely stroll through the shopping halls, while your mobile phone, with Wi-Fi turned on, attempts to 'attach' to some network by regularly sending out Probe Request packets that can be analyzed to count you: how often you visit this store, what trajectories you walk through, and so on. Further, the data is collected, analyzed, heat maps are drawn, and managers use such images to 'extract' money from management or investors. But for now... 'there's no money, but hang in there...' and the result (the real one) must already be shown. The old reliable song comes into play: 'Yes, yes, of course, later we will install all the necessary components and everything you need, but right now we need to show the Client the results! By the way, we forgot to mention, the Client allowed us to connect our equipment to their hotspot via Wi-Fi, but on common terms, just as if we were guest clients.' So we have to create router acrobats — raising several WiFi subinterfaces, one of which connects to the hotspot, while the other monitors the environment, urgently unloading the tcpdump results into itself, then packing the file contents into an archive, and risking 'overloading' tries to spit the contents out to the FTP server. It’s not surprising that the router acrobat often 'drops out' and has to be remotely 'revived'.
RadiusHere, the situation can be described simply with the customer's statement: "We want a decentralized network of hotspots that would operate on equipment whose model is not known in advance, through channels, but we don't know what those will be yet. Oh, we forgot to mention, we not only want to display ads to customers, but also analyze everything around the site of the hotspot installation. No, we don't know why yet, but we'll come up with something, don't worry, we managed to come up with this idea after all."
And we must not forget that due to many uncertain circumstances, management must operate under non-standard conditions, when we cannot connect to the router directly via IP: port and are forced to simply wait for it to show activity. If we abstract a bit, the dialogue between the server and the router can be imagined like this:
- Router: hello. I am the router, are there any tasks for me?
- Server: Router such-and-such, I have registered you, that you are alive. Here’s the task: show me the result of the ifconfig command?
- Router: Hello. I am router such-and-such, last time you asked to show the result of ifconfig, here it is. Do I have any tasks?
- Server: Router such-and-such, I have registered you, that you are alive. There are no tasks for you.
The most interesting question: how can a remote router send a certain amount of information? In the previous part, I described that on the router, due to resource limitations, only a 'trimmed' version of wget is available, which only works through GET and nothing more; there is neither an FTP client nor curl. More precisely, we need a universal way, regardless of the peculiarities of the image build. I settled on using wget. Actually, how I 'settled'—I simply had no choice 🙂
A disclaimer right awayMy management solution works, is not heavily limited, and I'm sure—it's crooked, even if it satisfies most of my clients. How it could ideally be done—write a small utility that sends binary data via POST through port 80. Include this utility in the router's firmware and then call it using bash. But the reality is that: a) it needs to be fast b) maybe it has to work on the existing 'zoo' of routers c) 'do no harm!'—if the router is working and performing other tasks, try to make changes that do not affect the existing functionality.
Let's move on to implementation. Suppose your client wants to easily and effortlessly reboot the router from zabbix, with a 'click of a mouse'. Today we will start the description of the implementation with zabbix.
In the 'Administration' menu -> 'Scripts', we add a new script. We name it 'Reboot', and as the command we write 'php /usr/share/zabbix/reboot.php {HOST.HOST}'
Next: Menu 'Monitoring' -> 'Latest Data' -> 'Right-click on the desired network node'. This is how the menu will look after adding the script.
Accordingly, we place the reboot.php script in the directory /usr/share/zabbix (yours may differ, I use the root directory of zabbix).
Disclaimer for securityTo illustrate the explanation in the script, I am using only the router ID, but not using the password. This is not recommended in the working version! The reason I did this is that there's a big question — where to store passwords for routers? In Zabbix in the "inventory data"? A controversial practice. One option is to restrict external access to the reboot.php file itself.
reboot.php file
set_charset("utf8");
// "Send" the reboot command by modifying the task field in the users table. Any command can be sent in the task field.
$sql_users=$conn->prepare("UPDATE users SET task='reboot' WHERE id=? AND status='active';");
$sql_users->bind_param('s', $user);
$sql_users->execute();
$sql_users->close();
?>That's it. The question remains open about "how to get the result of the command execution from the device side." Let's consider the task using the ifconfig command as an example. Here's a command that can be sent to the device:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, where:
message=`ifconfig` — we assign the result of the ifconfig command output to the $message variable
wget " — our a.php script, which registers routers and receives messages from them
u=user&p=password!&m=$message — the credentials and assigns the content of the $message variable to the request variable m
-O /tmp/out.txt — output to the file /tmp/out.txt is not needed in this case, but if this parameter is not specified, wget does not execute
Why does this work poorlyBecause it is a potential security hole. The most harmless error that can happen is if your command output contains a symbol like "&". Therefore, it is necessary to filter everything that is sent from the routers and everything that comes to the server. Yes, I am ashamed, really. In my defense, I can only say that the whole article is dedicated to managing routers with an undefined firmware in advance, using uncertain communication channels.
I have also made provisions for the future: I haven't figured out yet how to display results (like the output of a command) that arrive on the server using Zabbix's standard tools.
As a reminder, all source files can be retrieved from the Git repository at:
Source: habr.com
