Monitoring Allnet 3418v2


There might still be time!

I don't like this device. Getting this configured and monitored has needed way too much effort.

If you're evaluating web thermometers, spend the extra money for a better one that works without hassle.

  • It doesn't come with SNMP support. Vendor thinks XML is the way to go.
  • The XML output is not XML. It's some beginner dev's attempt at XML...
  • Has no DTD.
  • Badly structured
  • Returns an empty(!) page when there is an issue with permissions or the sensors - instead of returning empty xml-structured data or an error message
  • We had it shelved for months - it pulled updates but still runs an old OpenSSL
  • The default temperature alarms trigger at around 140 deg Celsius. Pretty sure this is outside of allowed params for the device.

On the bright side...:

SSH tinkering

the root flash (jffs2) is writeable and persistent, adding a Check_MK agent is an interesting option


A good friend helped me with a Perl-based XML parser, that is tuned to ignore invalid XML data. Using that we have access to the data in a structured manner. I've just hooked it up on my local lan for writing the checks and made a tarball of the files needed to make it work.

With that done, here is a manual how to set it up!

The setup

Create a test site

root@egal:~# omd create thermo
Adding /opt/omd/sites/thermo/tmp to /etc/fstab.
Restarting Apache...OK
Creating temporary filesystem /omd/sites/thermo/tmp...OK
Created new site thermo with version
  The site can be started with omd start thermo.
  The default web UI is available at http://egal/thermo/
  The admin user for the web applications is omdadmin with password omd.
  Please do a su - thermo for administration of this site.
root@egal:~# omd start thermo
Starting Livestatus Proxy-Daemon...OK
Starting rrdcached...OK
Starting npcd...OK
Starting nagios...OK
Starting dedicated Apache for site thermo...OK
Initializing Crontab...OK



Getting the files:


Fetch the tarball attached here or get the files from bitbucket.

root@egal:~# su - thermo
OMD[thermo]:~$ wget -q && 
tar -tvf allnet.tar.gz
-rwx------ thermo/thermo   612 2014-06-27 02:38 local/bin/
-rw-rw-r-- thermo/thermo   134 2014-06-27 02:07 local/share/check_mk/web/plugins/perfometer/
lrwxrwxrwx thermo/thermo     0 2014-06-27 02:12 local/share/check_mk/pnp-templates/check_mk-allnet_sensors.temp.php ->
-rw-rw-r-- thermo/thermo  3535 2014-06-27 02:01 local/share/check_mk/checks/allnet_sensors
-rwx------ thermo/thermo   399 2014-06-15 07:51 local/lib/

The stuff on bitbucket will be more current over the years, so don't hesistate to look at and head for "source" there.


In summary, the following files are what you need to make it work on the server end:



Configuring Web access:

You need to enable the "remote control" and set up the user for it:

Tools to create a password could be "apg" or "pwgen"

doesn't hurt to use a "real" password, since you won't need to manually access the api interface!

Here you can see the OpenSSL version I found on the device (and it says there's no updates)

current version heartbleed vulnerable?
[root@all3418 /root]# openssl version
OpenSSL 1.0.0e 6 Sep 2011
[root@all3418 /root]# ls -l /usr/bin/openssl 
-rwxr-xr-x    1 root     root        511896 Nov  9  2012 /usr/bin/openssl*

Given the age and version, I am afraid this is affected by heartbleed.

Surprisingly, there are some so-called offline updates on their website at:

The site says those are only to be used if you don't have an internet connection. There's no release notes on that page, let me know if you tested those patches and know more about how they handle patches.

Checking once more I found I already run "3.20.1050" on the device, which is the most current version. So seems *not fixed*.

I finally did some testing and it seems they compiled without the heartbeat TLS extension:

dhcp100:~ floh$ ./ 192.168.xx.xx -p 443
Sending Client Hello...
Waiting for Server Hello...
Sending heartbeat request...
 ... received message: type = 21, ver = 0302, length = 2
Received alert:
  0000: 02 46                                            .F
Server returned error, likely not vulnerable

It's just weird, and I think they are horrible for still using this version.

Configure access on server:

Configure the same user in the wrapper script:

OMD[thermo]:~$ vi local/bin/
pass=Lyejcag9 # example password :)


If you configured SSL, also change the url to https:

xml_data=`wget -q -O- --user=$user --password=$pass "https://$sensor/xml/?mode=sensor&type=list"`

If you get a certificate error, you can install the certificate to /etc/openssl or, if you despair, tell wget to "--no-check-certificate".

I didn't configure SSL for the check writing.


Adding the Check_MK configuration

With this configured, the last piece is to create the config for Check_MK.

I'll show the text-mode example since this is so easy:

OMD[thermo]:~$ cat etc/check_mk/conf.d/ 
all_hosts += [ 
datasource_programs += [
    ( "$OMD_ROOT/local/bin/ <IP>", [ "allnet-ds" ], ALL_HOSTS )
ipaddresses["therm1"] = ""

you can also use <HOST> - I just didn't have DNS configured in this case.


Checking if it works...

The sensors in the GUI:


If the perf-o-meters don't show after a GUI refresh, you might need to reload the site apache:

OMD[thermo]:~$ omd reload apache



Check that the PNP Template is correctly found. It should look as below:


Now enjoy more useful history graphs than in the original UI :)


I've been tinkering a little with the sensors.

As you can see here, the display range matters a lot. The OK range should ideally cover a higher area at Temp1 and the 50% mark should be where the needle sits at normal conditions.


The end