After some googling I came across a blog entry (look for September 5, 2011) that describes a bug in bash: Bash, when calling “read” with a timeout, will install a signal handler for SIGALRM and longjump out of the signal handler, leaving SIGALRM blocked forever.

The boot-script runs as init (with pid 1) and therefore will leave SIGALRM blocked for all children. My immediate workaround is to read the filesystem to boot in a sub-shell…seems the bug is fixed with newer versions of bash.

“In Niederösterreich stehen Förderungsmittel in der Höhe von EUR 4.750.000 zur Verfügung, mit diesen Mitteln können 426 Projekte gefördert werden. Ihr Ansuchen ist an 746. Stelle gereiht und kann daher derzeit aus dem verfügbaren Budget leider nicht gefördert werden”

Mich würde ja doch interessieren, wie anfechtbar eine Reihung nach Web-Formular-Ausfüllen ist — nach meiner Erfahrung muss es sich da um Sekunden gehandelt haben, in der Zeit haben offensichtlich über 700 Niederösterreicher vor mir eingereicht. Woher weiss ich, dass die Webserver-Ausfallzeit nicht benutzt wurde, um eigene “VIPs” mal zuerst in die Datenbank einzutragen?

Ich habs ja schonmal geschrieben: Eine Ziehung unter notarieller Aufsicht wäre fairer und transparenter.

Aug  4 11:29:34 debian3264m postfix/smtpd[18583]: NOQUEUE: reject:
       RCPT from k969.ims-firmen.de[213.174.47.182]: 450 4.7.1
       <ralf@zoo.priv.at>: Recipient address rejected: Greylisted, see

http://isg.ee.ethz.ch/tools/postgrey/help/zoo.priv.at.html;

       from=<pv.service@kommunalkredit.at> to=<ralf@zoo.priv.at>
       proto=ESMTP helo=<bruce.connex.cc>

10 Minuten später kam dann auch die Email durch:

Aug  4 11:39:13 debian3264m postfix/smtpd[19080]: 3D5AE814E:
       client=k969.ims-firmen.de[213.174.47.182]
Aug  4 11:39:13 debian3264m postfix/cleanup[19086]: 3D5AE814E:
       message-id=<1144469538.1283.1249378174385.JavaMail.tomcatkk@bruce.connex.cc>
Aug  4 11:39:13 debian3264m postfix/smtpd[19080]: disconnect from
       k969.ims-firmen.de[213.174.47.182]
Aug  4 11:39:13 debian3264m postfix/qmgr[29847]: 3D5AE814E:
       from=<pv.service@kommunalkredit.at>, size=5844, nrcpt=1 (queue active)
Aug  4 11:39:13 debian3264m postfix/local[19087]: 3D5AE814E:
       to=<web11_ralf@static.88-198-162-230.clients.your-server.de>,
       orig_to=<ralf@zoo.priv.at>, relay=local, delay=0.28,
       delays=0.25/0/0/0.03, dsn=2.0.0, status=sent (delivered to command:
       /usr/bin/procmail -f-)
Aug  4 11:39:13 debian3264m postfix/qmgr[29847]: 3D5AE814E: removed

Hoffen wir mal, dass sich der Aufwand von 1.5 Stunden gelohnt hat. Die Gewährung von Förderungen von der Reihenfolge der Antragstellung bei einem kaputten Server abhängig zu machen lässt natürlich viele Vermutungen über Ungerechtigkeiten zu: Woher weiss ich, dass andere nicht früher durchgekommen sind? Vielleicht haben andere Bewerber noch einige Zeit lang ein Meldung wegen Überlastung bekommen, während andere schon munter ihren Antrag ausgefüllt haben? Wäre man schneller gewesen, wenn man einen Robot programmiert hätte? Vielleicht waren Robots an der Überlastung schuld?
Mir wäre da eine Frist und eine Ziehung unter notarieller Aufsicht deutlich lieber, damit würde klar zugegeben dass es ein Glücksspiel ist …

Diese Verhalten eines der wichtigsten Services im Internet — der Namensauflösung — verletzt klar die Netzneutralität wie auch schon im Jahr 2007 von Ed Felten in seinem Blog im Falle Verizon festgestellt wurde. Verizon hat wohl seither auf diese Praxis — nach vielen Protesten — wieder verzichtet. Berechtigterweise wurde UPC für diese Praxis für den Big Brother Award nominiert — die gesammelten Daten gehen offensichtlich an einen ausländischen Werbeunternehmer. Zumindest in einem Fall kommt es bei diesem Verhalten zu Probleme bei Telefonie im Internet wie einem Forum Posting zu entnehmen ist.

Schlimmer noch: UPC liefert falschen Information auch für Domains die ganz klar von jemand anderem reserviert sind. Wenn ich also nonexistent.source-forge.org ansurfe komme ich auch auf die Werbeseite von UPC — obwohl source-forge.org (ja mit Bindestrich) von dem grossen Open Source Projekthoster sourceforge reserviert ist. Hoffentlich lässt es da mal jemand auf ein Gerichtsverfahren wegen unlauterem Wettbewerb ankommen. Wäre vermutlich recht lukrativ, jedenfalls bei anderen Firmen als Sourceforge.

Mir war das bisher nicht aufgefallen, aber offensichtlich wurden ehemalige Inode-Kunden erst vor kurzem umgestellt, UPC-Telekabel Kunden offensichtlich schon früher.

Heute habe ich mich bei der UPC-Hotline beschwert. Man werde an dem Fall arbeiten und “den Fehler” beheben. Leider könne man mir keine Ticket-Nummer geben unter welcher ich meine Beschwerde nochmal urgieren kann — aber ich könne ja “in einigen Tagen” wieder anrufen. Ein Rückruf wurde mir versprochen, mal sehen ob da was kommt. Ich habe den Hotline-Bearbeiter freundlich darauf hingewiesen, dass es sich ja nicht um einen unbekannten Fehler handeln kann, wenn UPC dafür bereits für den Big Brother Award nominiert wurde.

Inzwischen habe ich einen Workaround gefunden: UPC hat die alten, funktionierenden Nameserver nicht abgeschaltet, in obigem Link des ip-phone-forums findet man funktionierende DNS-Server: 195.34.133.25 und 195.34.133.26 die man fix einstellen kann. Weitere Tips finden sich als Antwort auf mein Posting an die LUGA-Mailingliste. Die alternative ist, gleich einen eigenen Nameserver zu betreiben (unter Linux sehr einfach möglich) oder auf alternative Namenshierarchien umzusatteln wie z.B. opennicproject — auch wenn man bei Verwendung von Alternativen von einer deutschen Ministerin gleich als pädophil eingestuft wird. Es ist kaum zu glauben, was manche Politiker für einen Schwachsinn von sich geben.

Die Firma Skype hat früher Peer-to-Peer Filesharing-Software hergestellt (mit dem Namen "KaZaA"), Filesharing-Programme dienen zum Tauschen von Musik und anderen elektronischen Inhalten. Diese Software hat nachgewiesenermassen sogenannte “Spyware” enthalten (vgl. auch diverse Tips, wie man diese ausschalten können soll). Unter Spyware verstehen wir Programme, die unbemerkt vom Eigentümer eines Rechners diesen Rechner ausspioniert und die ausspionierten Daten via Internet an den Programmierer der Spyware schickt. Zu den ausspionierten Daten zählen Statistiken über das Besuchen von Websites bis zu Passwörtern. Was genau die von der KaZaA Spyware ausspionierten Daten sind entzieht sich meiner Kenntnis. Ich vertraue solchen Leuten meine Telefongespräche nicht an.

Es gibt eine unabhängige Analysen von Skype 2005 und 2006, nach der in der analysierten Skype-Version keine Hinweise auf Spyware gefunden wurden. Das kannn sich inzwischen geändert haben und diese Analyse sagt nichts über die Sicherheit von Skype aus:

Skype (und vorher schon KaZaA) enthalten Mechanismen, um automatisch neue Software-Versionen (teilweise ohne Wissen oder sogar Zustimmung des Benutzers) zu installieren. In einer solchen neuen Version könnte Spyware enthalten sein — oder auch nur eine Software-Fehler der vorher nicht enthalten war. Damit ist man den Herstellern der Software ausgeliefert, da es unter der Kontrolle von Skype ist, was in neuen Versionen enthalten sein wird. Man könnte auch sagen: Nach Installation von Skype gehört Dir Dein Computer nicht mehr.

Dann wird immer wieder behauptet, die Kommunikation mit Skype sei verschlüsselt. Das mag ja stimmen. Der Grund ist aber wohl nicht die Privatsphäre des Nutzers, sondern die Absicht, zu verhindern, dass andere Software schreiben, die das Skype-Protokoll spricht. Denn was nützt mir die Verschlüsselung wenn ich nicht weiss, wer den Schlüssel besitzt? Der Benutzer von Skype besitzt den Schlüssel jedenfalls nicht.

Zum Abhören hat Kurt Sauer, Leiter der Sicherheitsabteilung von Skype, auf die durch ZDNet gestellte Frage, ob Skype die Gespräche abhören könne, ausweichend geantwortet: "Wir stellen eine sichere Kommunikationsmöglichkeit zur Verfügung. Ich werde Ihnen nicht sagen, ob wir dabei zuhören können oder nicht." (vgl. den Artikel in der deutschen Wikipedia dazu bzw. direkt das ZDNET-Interview.

Hinzu kommt, dass sich Skype an keinerlei etablierte Standards im Bereich der Sprachkommunikation über Internet-Protokolle hält, ja wie Skype genau funktioniert ist nicht offengelegt, es kann also keine andere Firma derzeit Programme bauen, die mit Skype-Software zusammen funktioniert. Solche "Closed Source" Programme fördern Monopolstellungen und sind — ähnlich wie z.B. Monopolstellungen im Bereich von Nahrungsmitteln wie Genmais von Monsanto — mit erhöhter Wachsamkeit zur Kenntnis zu nehmen. Die etablierten Standards im Bereich der Sprachkommunikation stehen Punkto Sprachqualität u.a. Skype in nichts nach.

Skype hat — aus seiner Peer-to-Peer Vergangenheit — Mechanismen um durch Firewalls zu "tunneln". Diese Techniken, auch als "Firewall Piercing" bekannt, sind für die Sicherheit einer Firma gefährlich, oder wie humorvoll von einem Kollegen formuliert: "Firewall Piercings können sich entzünden und eitern".

Es gibt etablierte Standards zur Sprachkommunikation wie z.B. SIP (Session Initiation Protocol) für den Verbindungsaufbau. Es gibt Open Source Implementierungen für "Softphones", das sind — ähnlich wie Skype — Programme mit welchen über einen Computer telefoniert werden kann. Ein Beispiel ist Qutecom (früher "Wengo Phone"), eine Suche nach "Softphone" in Google sollte noch einige andere zutage fördern. Es gibt natürlich auch kommerzielle Anbieter solcher Programme (teilweise als Closed Source), der Knackpunkt liegt in einem gemeinsamen Protokoll bei dem alle mitmachen können. Es gibt inzwischen auch "Hard" phones, also ein Ding was wie ein Telefon aussieht, aber hinten einen Ethernet-Anschluss hat und SIP spricht. Sehr preiswert ist das Budgetone von Grandstream, ein weiterer Anbieter ist z.B. Snom und Cisco hat einige kleinere Anbieter wie Sipura gekauft.

Ich habe selbst keine grosse Erfahrungen mit solchen Softphones auf Windows oder MAC Plattformen. Für Erfahrungsberichte bin ich dankbar.

Dann gibt es Anbieter, die Vermittlungstätigkeiten für solche Softphones anbieten. Ein Beispiel ist sipgate, andere finden sich auf voip-info.org. Man meldet sich dort an, kann gratis mit anderen Softphones über das Internet telefonieren, bekommt bei einigen Anbietern sogar kostenlos eine Telefonnummer über die man vom Festnetz aus angerufen werden kann. Das "Businessmodell" dieser Anbieter sind Anrufe vom Internet ins Festnetz. Die kosten dann etwas, sind aber immer noch deutlich günstiger als z.B. die Telekom in Deutschland oder Österreich.

Ein weiterer SIP-Dienst ist ekiga.net vom Team des gleichnamigen Open Source Soft-Phones Ekiga, ich bin dort z.B. als rsc@ekiga.net erreichbar.

Ausserdem ist ein öffentlicher Verzeichnisdienst ENUM im Aufbau, wo man seine eigene Telefonnummer weiterverwenden kann. Damit wird es in Zukunft möglich sein, einfach eine Telefonnummer einzugeben und über das Internet den gewünschten Teilnehmer zu erreichen.

Inzwischen gibt es auch eine Open Source Telefonanlage, Asterisk. Asterisk kann sowohl ans Festnetz (ISDN aber auch eine analoge Leitung) angeschlossen werden, als auch an Internet-Telefonie mit verschiedenen Standards (SIP, IAX, H323) teilnehmen. Die Telefon-Software läuft auf einem ganz normalen handelsüblichen PC — Modelle mit niedrigem Stromverbrauch sind zu empfehlen, da ja eine Telefonanlage Tag und Nacht in Betrieb sein soll. Asterisk "spricht" bereits heute ENUM. Ausserdem kann man über Einsteckkarten ganz normale "analoge" Telefonapparate anschliessen. Dann kann man verschiedene SIP-Anbieter gleichzeitig und einen Festnetzanschluss an der selben Telefonanlage betreiben und mit einem ganz normalen Analogtelefon, oder auch mit einem Komfort-ISDN-Telefon, einem Hard-Phone (z.B. Snom), oder einfach mit einem Softphone — telefonieren. Man kann die Telefonanlage suchen lassen, ob ein bestimmter Teilnehmer über das Internet erreichbar ist oder nur über das Festnetz. Der Anrufende muss nicht mal merken ob über Festnetz oder Internet telefoniert wird.

Das geniale an Asterisk (und das Erfolgsrezept von vielen anderen Open Source Projekten) ist sein modularer Aufbau: Für verschiedene anzuschliessende Geräte oder Protokolle kann man einen "Channel Treiber" schreiben und Asterisk kann danach mit einem neuen Gerät kommunizieren. So kann ein Spezialist für ein bestimmtes Gerät oder Protokoll einen neuen Gerätetreiber beitragen.

Man kann Asterisk-Telefonanlagen miteinander vernetzen — auch über eine verschlüsselte Verbindung über das Internet, ein sogenanntes "Virtual Private Network" (VPN). Dann kann man telefonieren ohne dass Dritte die Verbindung abhören können — eine solche Installation setzt allerdings Absprachen zwischen den Betreibern der zu vernetzenden Telefonanlagen voraus.

Neuere Techniken erlauben, vorhandene SIP-Infrastruktur zu benutzen und trotzdem ohne vorherige Absprache verschlüsselt zu telefonieren. Der Schlüssel wird dabei direkt zwischen den beiden Teilnehmern ausgehandelt. Philip Zimmermann, der Autor von PGP, hat dafür den Standard ZRTP vorgeschlagen, der inzwischen bei der Internet Engineering Task-Force (dem Gremium das Internet-Standards macht) zur Standardisierung eingereicht ist.

Ich selbst verwende Asterisk seit einigen Jahren statt meiner alten ISDN-Telefonanlage.

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?

Unpacking of 'iscan-firmware-2.8.0.1-48.1.noarch.rpm' failed at /usr/share/perl5/Alien/Package/Rpm.pm line 155.

After some more searching I found debian bugs 518348 and 509444 of which the latter contains a workaround: Seems that the rpm format changed to a compressed format that can be unpacked with lzma. Now unpacking was possible — after all I was only interested in the firmware file — and now my scanner is working again… For the record, unpacking was done as follows:

mkdir iscan-firmware-2.8.0.1
rpm2cpio iscan-firmware-2.8.0.1-48.1.noarch.rpm \
| lzma -d | (cd iscan-firmware-2.8.0.1; \
cpio --extract --make-directories \
--no-absolute-filenames --preserve-modification-time)

Letzten Freitag bekomm’ ich ein SMS, dass meine Telering-Rechung da ist — es gibt ja fast nix wichtigeres auf der Welt als eine Telering-Rechung, daher ist es unerlässlich, den Kunden auf allen verfügbaren Kanälen darauf aufmerksam zu machen, dass die Rechnung da ist (fehlt eigentlich nur, dass ich einen Anruf bekomme :

tele.ring Rechnungs-Info!
Ihre aktuelle Rechnung ist online. Abrufbar unter my.telering.at > Rechnung. LG Ihr tele.ring Team

Ich ärgere mich also über die Störung und versuche die Absendernummer 1554020000001 des SMS anzurufen — und — am anderen Ende ist eine Österreichische Wettervorhersage.

Also habe ich bei der Hotline die Rechnung wieder auf Papier zurückgestellt (online-Rechung heisst offensichtlich Email und SMS) — möglicherweise kommt sie ja jetzt wieder — nach einmal hin und her Umstellen auf Online und zurück.