Mikrotik Dude (http://www.mikrotik.com/thedude) is a great network monitoring tool. This small and free software came with good set of suitable probes for network monitoring. There is no limit in the number of a services or device types. We can check Mikrotik routerboard routers, network switches, Linux or Windows servers and every other device on the network.
In same time, this is a open framework. That means that we can develop our own probes and tests. With that new probes we can expand possibilities of this small, yet powerful software.
It’s very easy to monitor standard TCP based services, as many of them have well defined client-server communication. In many cases, a client and the server will exchange text based commands. Problem arise when we want to monitor UDP based services.
As you probably know, UDP based services are based on unreliable communication. The server will send a datagram (a network packet) and a client will or will not accept it. There will be no error checking or packet retransmitting. Also, many communications are binary based. That means that we need to simulate a client side of communication.
We need to check TFTP server
About a year ago, I have a need to check for the TFTP server, as some IP telephones depends on it. This sounds simple, but actually, it’s tricky.
A TFTP server uses port 69 UDP for connections. On top of that, we have just two commands PUT and GET. But we can’t send them as plain text, like we can do with a FTP server.
We need to learn much more about this protocol and best source is a RFC (Request For Comment) document. TFTP protocol is described in the RFC 1350 (https://www.ietf.org/rfc/rfc1350.txt). On the page 5 of this RFC, you can find that client sending a WRQ or RRQ message to the server. On the bottom of the page, we can see that we need to send an opcode or a binary interpretation of the command.
For our probe, we can simulate a client that read some file. It doesn’t matter if file exists. If a TFTP server running, it will return error in case that file does not exits. Now we have a frame for our new probe. We need to capture at least one communication sequence between a client and the server.
The Test environment
We need a clean environment for test. That means that we should have least possible amount of a network traffic between a client and the server. We can use two virtual machines and connect them over a virtual network. For this test, I will make a mix of the physical and a virtual machine.
I will use my laptop and one virtual machine. Virtual machine is cloned for this test, as I described in this article Using linked clone OF Virtual machines. I will connect them using a VirtualBox Host-Only network. That will isolate a network traffic and make things easier.
It doesn’t matter which side is a server and which one is the client. Also, we can capture a traffic on any side. In this case, laptop is a TFTP server. I used the TFTPd application (http://tftpd32.jounin.net) as TFTP server. Client application is a Microsoft built-in command-line TFTP client in Windows 2003 Server R2, which will act as a client.
TFTPd application is easy to setup. We just need to select an appropriate service and to select the root directory for TFTP service.
We will restart a TFTPd application and our server is ready.
Now we’re checking our client. We will open a command prompt and type tftp, then press Enter. We should see help for this command:
As we can see, our command should be:
TFTP hostname GET filename
where hostname is an IP address or the hostname of our server, and a filename is a arbitrary file name. We will use test.txt as our file name. Now, when we have all parameters, we begun with the tests. Before we launch a test, we should prepare some tool that can capture an interesting network traffic.
Our server is on the IP address 192.168.101.1 and the client have an IP address 192.168.101.10. We will use those IP addresses during the test.
Wireshark is your best friend
When it comes to monitoring raw network traffic, best tool for such job is WireShark (https://www.wireshark.org/). We can catch the network packets and analyze them later. We can also filter traffic to the specific service or a host (network server or computer).
We will use it to check a network traffic between our client and a server. When we run Wireshark, we will check appropriate network interface (in case that there are more then one). Then we will enter tftp as filter and we’re ready for the test.
Now, we will execute command on the client in command prompt:
C:\>tftp 192.168.101.1 get test.txt
Error on server : File not found
Connect request failed
We will receive an error, as a file test.txt doesn’t exists. That’s OK. TFTP server answered and we know that it’s alive. Now, I will shutdown TFTP server and try a test again:
C:\>tftp 192.168.101.1 get test.txt
Connect request failed
As we can see, if there is no TFTP server on the specified IP address, we will have an error that timeout occurred and there will be no response. This is a crucial part of our test.
As we can see on this screenshot from Wireshark, if the TFTP server is alive, we will have one TFTP packet. Response is almost immediate. When we retrieving a real file, we can do that for a couple of seconds.
However, when there is no TFTP server, we will have series of request, ending with error. That means that our probe will fail. We will have timeout, indicating that a TFTP server is unreachable. This error indicates packet from 300 to 308.
We can also request a files in a binary mode, like in the packet 64. This requires –i command line parameter. In our command string we will replace a command netascii with octet.
Don’t forget that all strings must be null-terminated. Therefore, we have binary zero (a byte with the value 0 or 00 in a hex code) on the end of every text part.
Building our probe
According to all we already saw here, a key is in this string \00\01dude.txt\00octet\00. We should open a communication with the server on the port 69 UDP and send this string as a parameter.
I will use dude.txt instead test.txt for my real probe. In short, we must provide following:
- Command begun with 2 bytes OpCode, like 00 01 for read request. That’s represented as \00\01 in Dude.
- We will ask for some file, like dude.txt. This string must be null terminated, so we have \00 after the file name.
- The transfer mode must be specified. I chose binary mode or octet, ending will a binary zero or \00.
- If anything returned (even something like a Access denied to dude.txt), the TFTP server/service works. Therefore, just put ^.* as a received string.
And here is the code for the Dude version 4.0 beta 3:
<?xml version="1.0" ?>
We will try this probe in the Dude on the real site. We have a Mikrotik Routerboard RB750GL (http://routerboard.com/RB750GL) router without a TFTP server. We will add this new probe in list of services and wait for execution.
As expected, timeout occurred and a probe failed. As we can see, our probe works. Now we can try it on some server with the TFTP service.
Our probe works and we can use it to monitor our TFTP servers.
Using same principles we can build probes for all services we need to monitor.