Beronet bero*fos failover switch

Update 2009-04-27: There is a new firmware: good support from beronet
Update 2009-04-10: I’ve written a config-utility for the device, available in my rsclib on sourceforge (in python)

I’m now experimenting with the Beronet bero*fos failover switch. I need this for a project where two redundant asterisks should be switched by the bero*fos.
To get the following into proportion: I’m a customer of Beronet and usually like their products. But selling a device for around 700.- Euro we should expect working firmware and working configuration software. Especially since the device sits at a crucial point from a safety point of view: it’s used in scenarios where we want failover capabilities for telephone equipment.
The config-software is open source, so we can work around it’s shortcomings. But there is a firmware bug, setting some configuration variables via web interface has side-effects on other configuration variables. (we can work around that by writing our own config program). So I’d really like a more open design here: I’m voting for open firmware and a hardware documentation. But that might lead to others building the device for less money…
I would also prefer a documentation of the parameter interface in addition to (or instead of) a configuration program. Integrating the device into other infrastructures where we don’t want a binary configuration program requires reverse-engineering. I’ve done that in the following.
In the following I’m referring to berofos Firmware 1.3.3 which is the latest on Beronets webpage and in my device. The berofos tools for Linux on the webpage were apparently last updated in December 2007 and don’t have a version number.
The device has four groups of 4 ports each, A, B, C, D. These can be switched in two scenarios, a fallback scenario, which can connect A-B or A-D and a bypass scenario which can connect A-B and C-D or A-D. The first scenario is useful if there are redundant devices where one device can replace another (e.g. as in our scenario with two asterisk boxes), the second scenario is useful when you have an asterisk connected in between the telephone network and an old PBX. In case the asterisk fails, the PBX can be directly connected to the telephone network.
I won’t rehash the features and documentation of the device here, the berofos docs and tools page has a link to the manual (and to the command-line tool for both, Linux and Windows).
The device has a web-interface and a command-line interface written in C under the GPL version 2 license without a version-upgrade clause. The individual source files refer to a LICENSE file which isn’t included in the distribution.
The web interface has several bugs, some changes of config variables will change variables in other configuration pages. A notable example is the defaults page. In this page the default state of the relais can be set. When changing anything on that page, the device will also change the scenario to bypass.
Worse, when changing the mailserver page (the device is able to notify you via email if something bad happens) the dhcp setting is reset. This means on next powerup the device probably won’t try to get it’s ip via dhcp but use whatever happens to be the currently configured IP address. I didn’t try to reboot the device in this state because I noticed (and was looking for) this side-effect because I was already searching for a pattern in the failures.
Getting the config is easy, it’s under the url http://fos/config.txt where fos is the device. The following text file is retrieved:

bnfos_confmap_magic=0.1
1_sz=0
4_mode=0
1_rm=checked
5_p0=0
1_p0=
5_p1=0
1_p1=
3_dn=
3_ip=10.23.5.100
3_nm=255.255.255.0
3_gw=10.23.5.254
3_dns=10.23.5.254
3_dhcp=checked
3_port=80
3_pwd=
2_mhost=0.0.0.0
2_mfrom=
2_mto=
3_log=
3_loghost=0.0.0.0
6_wen=0
2_wen=
6_wstate=0
2_wintv=60
2_as=checked
2_men=
0_wretv=0

Apparently all configuration variables that influence other variables are in the same group: They have the same number in front.
The bugs of the web interface are not browser-specific. In fact the command-line tools also use the http-interface of the device to set and get options:

% bnfos/bnfos –get scenario -h 10.23.5.100
scenario = 0
zsh: exit 167   bnfos/bnfos –get scenario -h 10.23.5.100
% bnfos/bnfos –set modedef=0 -h 10.23.5.100
Setting modedef succeeded!
% bnfos/bnfos –get scenario -h 10.23.5.100
scenario = 1
zsh: exit 167   bnfos/bnfos –get scenario -h 10.23.5.100

Exit-code of the bnfos tool when querying a variable is always 167. It also doesn’t follow the UNIX mantra for command-line tools: Be silent on success, noisy on error. But we also see here that the bug appears with the command-line tool too: changing the default relais mode also changed the scenario.
When looking with wireshark we see that for setting the variable with the command-line tool it just retrieved the URL /?cmd=1&rm=0 with a HTTP Get-request.
When using the –show switch, output is on stderr so piping the result needs special shell commands ( |& is a zsh shortcut for piping both, stdout and stderr):

% bnfos/bnfos –show -h 10.23.5.100 |& grep dhcp
 dhcp      = 1
zsh: exit 167   bnfos/bnfos –show -h 10.23.5.100 2>&1 |

Setting the mail parameters smtpserv, smtpfrom and smtpto is impossible via the command-line interface. We always the the cryptic error message:

% bnfos/bnfos –set smtpto=’10.23.5.5′ -h 10.23.5.100
Setting smtpto failed: Could not parse!
zsh: exit 1     bnfos/bnfos –set smtpto=’10.23.5.5′ -h 10.23.5.100

Studying the code of the config-tool reveals that there are two configuration tables, one in src/beronet/confmap_fos.h named bnfos_confmap which includes all info about the low-level device parameters:

static const struct {
  char *key;
  char type;
  int cmd;
  char *parm;
  char *macro;
} bnfos_confmap[BNFOS_MAX_KEYS] = {
  { “sz”     , ‘b’, 1, “sz=%s”    , “szenario(0)”},
  { “mode”   , ‘b’, 4, “mode=%s”  , “mode(0)”},
  { “rm”     , ‘b’, 1, “rm=%s”    , “config(1,1)”},

  { “p0″     , ‘b’, 5, “p=0&s=%s” , “pwrport(0,0)”},
  { “p0″     , ‘b’, 1, “p0=%s”    , “config(2,1)”},
  { “p1″     , ‘b’, 5, “p=1&s=%s” , “pwrport(0,1)”},
  { “p1″     , ‘b’, 1, “p1=%s”    , “config(3,1)”},

  { “dn”     , ‘h’, 3, “dn=%s”    , “hostname(1)”},
  { “ip”     , ‘a’, 3, “ip=%s”    , “netconf(0)”},
  { “nm”     , ‘a’, 3, “nm=%s”    , “netconf(1)”},
  { “gw”     , ‘a’, 3, “gw=%s”    , “netconf(2)”},
  { “dns”    , ‘a’, 3, “dns=%s”   , “netconf(3)”},
  { “dhcp”   , ‘b’, 3, “dhcp=%s”  , “config(4,1)”},
  { “port”   , ‘p’, 3, “port=%s”  , “netconf(6)”},
  { “pwd”    , ‘b’, 3, “pwd=%s”   , “config(5,1)”},
  { “apwd”   , ‘d’, 3, “apwd=%s”  , NULL},

  { “mhost”  , ‘s’, 2, “mhost=%s” , “netconf(5)”},
  { “mfrom”  , ‘s’, 2, “mfrom=%s” , “netconf(7)”},
  { “mto”    , ‘s’, 2, “mto=%s”   , “netconf(8)”},
  { “XXXXX”  , ‘n’, 7, “”         , NULL},

  { “log”    , ‘b’, 3, “syslog=%s”, “config(10,1)”},
  { “loghost”, ‘a’, 3, “slgip=%s” , “netconf(9)”},
  { “logport”, ‘p’, 3, “slgpt=%s” , “netconf(10)”},

  { “wen”    , ‘b’, 6, “wen=%s”   , “wdog(0)”},
  { “wen”    , ‘b’, 2, “wen=%s”   , “config(6,1)”},
  { “wstate” ,   0, 6, “wstate=%s”, “wdog(0)”},
  { “wintv”  , ‘p’, 2, “wintv=%s” , “config(8,?)”},
  { “as”     , ‘b’, 2, “as=%s”    , “config(9,1)”},
  { “men”    , ‘b’, 2, “men=%s”   , “config(7,1)”},
  { “wretv”  ,   0, 0, NULL       , “wdog(2)”},
};

and one in bnfos/main.c that maps the high-level command-line paramters to the low-level http requests:

/* keyword description for –set / –get */
static struct {
  char *keyword;
  char *descr;
} keys[BNFOS_MAX_KEYS] = {
  {“scenario”, “scenario (0=fallback; 1=bypass)”},

  {“mode”, “relais mode (0=A–D; 1=A–B or A–B,C–D)”},
  {“modedef”, “default relais mode (0=A–D; 1=A–B or A–B,C–D)”},

  {“power1″, “state of powerport 1 (0=off; 1=on)”},
  {“power1def”, “default state of powerport 1 (0=off; 1=on)”},
  {“power2″, “state of powerport 2 (0=off; 1=on)”},
  {“power2def”, “default state of powerport 2 (0=off; 1=on)”},

  {“hostname”, “device hostname”},

  {“address”, “ip address”},
  {“netmask”, “netmask address”},
  {“gateway”, “gateway address”},
  {“dns”, “dns server address”},
  {“dhcp”, “query dhcp server (0=off; 1=on)”},
  {“port”, “http listen port”},
  {“pwd”, “http password protection (0=off; 1=on)”},
  {“apwd”, “admin password”},

  {“smtpserv”, “smtp server”},
  {“smtpfrom”, “smtp sender address”},
  {“smtpto”, “smtp destination address”},
  {“smtptest”, “trigger testmail”},

  {“syslog”, “syslog logging (0=off; 1=on)”},
  {“slgip”, “syslog server ip”},
  {“slgpt”, “syslog server port”},
  {“wdog”, “watchdog enable (0=off; 1=on)”},
  {“wdogdef”, “default watchdog enable (0=off; 1=on)”},
  {“wdogstate”, “watchdog state (0=off; 1=on; 2=failure)”},
  {“wdogitime”, “watchdog intervall time”},
  {“wdogaudio”, “watchdog audio alarm (0=off; 1=on)”},
  {“wdogmail”, “watchdog alarm mails (0=off; 1=on)”},
  {“wdogrtime”, “watchdog remaining time to failure”},
};

I haven’t found a mechanism that keeps these two tables in different source files in sync (they currently seem to be), looks like both tables need to have the matching options in the same place in both tables. The code for matching options to low-level commands just uses the same index to navigate in both tables.
The bnfos_confmap table has a s for the type of the smtp parameters. This type isn’t handled in the config-tool and leads to the cryptic error message above. Patching the table to specify the type h (there is a comment XXX check hostname for validy for that type this checking apparently isn’t done yet, so we can use the code there to parse normal strings) would work. After applying a patch to src/beronet/confmap_fos.h, the sources aren’t recompiled, seems that the Makefile is broken, too. So after a make clean ; make I’m finally able to set the smtp parameters via the command-line interface:

% bnfos/bnfos –set smtpserv=’10.23.5.5′ -h 10.23.5.100
Setting smtpserv succeeded!

Looking over this again, I prefer to do the following patch that adds support for the ‘s’ type:

— bntools/src/bnfos.c 2007-08-28 09:27:46.000000000 +0200
+++ bntools.hacked/src/bnfos.c  2009-04-09 12:10:46.000000000 +0200
@@ -379,6 +379,14 @@
     set->val = strdup(val);
     return BNFOS_RET_OK;

+  case ‘s’:
+    /* Allow empty strings */
+    if (!val) {
+        val = “”;
+    }
+    set->val = strdup(val);
+    return BNFOS_RET_OK;
+
   case ‘p’:
     {
       int v;

This is a cleaner way to make configuring the smtp parameters work. Turns out that setting the mail gw does not influence the dhcp setting. But in the web-interface, the mail gateway and the syslog server are combined in one page. so trying that:

% bnfos/bnfos –show -h 10.23.5.100 |& grep dhcp
 dhcp      = 1
zsh: exit 167   bnfos/bnfos –show -h 10.23.5.100 2>&1 |
zsh: done       grep dhcp
% bnfos/bnfos –set slgip=’10.23.5.5′ -h 10.23.5.100
Setting slgip succeeded!
% bnfos/bnfos –show -h 10.23.5.100 |& grep dhcp
 dhcp      = 0
zsh: exit 167   bnfos/bnfos –show -h 10.23.5.100 2>&1 |
zsh: done       grep dhcp

we see that changing the syslog server also changes the dhcp setting like in the web-interface. When looking more closely, we see that the dhcp and the syslog IP are in the same cmd group. Thats the number in column 3 of the bnfos_confmap and the number in from of each line in config.txt retrieved via the web interface.
So the workaround for the bug in the firmware is to write a config program that retrieves all variables in the same cmd group and, when setting one of the variables in that group, also send all the other current settings in the same get-request.
Fortunately the bnfos_confmap table has the command pattern for generating the get-request for each of the variables in column 4 (parm). So it shouldn’t be too hard to write a new config utility (and of course I won’t do that i C either) that works around the firmware bugs.
I already said that I would have preferred an open firmware to fix the bugs at the source, did I?