Debian FreeTDS packages

• freetds-common – configuration files for FreeTDS SQL client libraries: NEEDED
• freetds-dev – MS SQL and Sybase client library (static libs and headers)
• gda2-sybase – FreeTDS backend plugin for GNOME Data Access library for GNOME2
• libct4 – libraries for connecting to MS SQL and Sybase SQL servers, needed only for sqsh for testing, gets automatically installed with sqsh.
• libdbd-freetds – Freetds database server driver for libdbi
• libsybdb5 – libraries for connecting to MS SQL and Sybase SQL servers
• sqlrelay-freetds – SQL Relay FreeTDS (Sybase and MS SQL Server) connection daemon
• sqsh – commandline SQL client for MS SQL and Sybase servers depends on libct4: Good for testing
• tdsodbc – ODBC driver for connecting to MS SQL and Sybase SQL servers “This package includes the ODBC driver for FreeTDS, for use with UnixODBC or iODBC.”: NEEDED

FreeTDS Needs either unixodbc or iodbc, both are ODBC implementations for Linux/Unix. Asterisk is built against unixodbc.
iodbc packages:

• iodbc – GTK+ config frontend for the iODBC Driver Manager
• libiodbc2 – iODBC Driver Manager
• libiodbc2-dev – iODBC Driver Manager (development files)

unixodbc packages:

• unixodbc – ODBC tools libraries depends on odbcinst1debian1: NEEDED
• unixodbc-bin – Graphical tools for ODBC management and browsing
• unixodbc-dev – ODBC libraries for UNIX (development files)

common packages for debian:

• odbcinst1debian1 – Support library and helper program for accessing odbc ini files: NEEDED

Asterisk depends on unixodbc which should be already installed, so we install the following packages (ignoring any warnings about already-installed packages):

apt-get install unixodbc sqsh tdsodbc

Other Software using ODBC

• Python seems to have its own access module for MS-SQL:
  python-pymssql – Python database access for MS SQL server and Sybase

Configuraton for Asterisk Logging

• /etc/freetds/freetds.conf

  
  [global]
          # TDS protocol version
  ;       tds version = 4.2
  
          # Whether to write a TDSDUMP file for diagnostic purposes
          # (setting this to /tmp is insecure on a multi-user system)
  ;       dump file = /tmp/freetds.log
  ;       debug flags = 0xffff
  
          # Command and connection timeouts
  ;       timeout = 10
  ;       connect timeout = 10
  
          # If you get out-of-memory errors, it may mean that your client
          # is trying to allocate a huge buffer for a TEXT field.
          # Try setting 'text size' to a more reasonable limit
          text size = 64512
  
  [logserver]
          host = 172.23.23.4
          port = 1433
          tds version = 8.0
  

• /etc/odbcinst.ini

  
  [FreeTDS]
  Description = FreeTDS ODBC driver for MSSQL
  Driver = /usr/lib/odbc/libtdsodbc.so
  Setup = /usr/lib/odbc/libtdsS.so
  

• /etc/odbc.ini

  
  [ODBC Data Sources]
  logserver = MSSQL Log-Server for Asterisk
  
  [logserver]
  description = MSSQL Log-Server for Asterisk
  driver      = /usr/lib/odbc/libtdsodbc.so
  servername  = logserver
  language = us_english
  trace = no
  tracefile = /root/mssql.trace
  

• /etc/asterisk/cdr_odbc.conf

  
  [global]
  dsn=logserver
  username=asterisk
  password=VERYSECRET
  loguniqueid=yes
  dispositionstring=yes
  table=cdr              ;"cdr" is default table name
  usegmtime=no             ; set to "yes" to log in GMT
  

• Test using isql

  # isql logserver asterisk "VERYSECRET" -v
  +---------------------------------------+
  | Connected!                            |
  |                                       |
  | sql-statement                         |
  | help [tablename]                      |
  | quit                                  |
  |                                       |
  +---------------------------------------+
  SQL> select * from cdr;
  [output of current cdr table]
  

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?

This is a short howto how I built the debian patches and how you can — as a user — install everything needed for mISDN version 2 and Linux Call Router (LCR) with asterisk chan_lcr running on debian lenny.

I’m providing debian packages for Kernel (v 2.6.28.5), an updated zaptel (debian lenny zaptel doesn’t compile with newer kernels and zaptel wctdm uses some settings for analogue phones that don’t work with german and austrian phone like the “R”-key or optional pulse dialling), finally I’m providing a slightly patched asterisk for larger buffer sizes when playing long tones, LCR and misdnv2user packages originally built by Joerg Dorchain. My misdnv2user is the same as Joergs. The lcr package contains my bug-fix for DTMF digits A-F (also in Joergs packages now) which don’t work in upstream LCR version 1.3 and an updated /etc/init.d/lcr for querying the status of lcr.

I’m also providing source packages, except for the kernel — the kernel is stock kernel.org 2.6.28.5 configured for use of mISDN. The kernel was built using debians make-kpkg from the kernel-package debian package. And the config used for building the kernel is in the binary package.

I hope I can contribute something in order to get mISDN V2 and LCR into debian… in the meantime others may want to uses these on debian stable.

Installation

apt-get install vim less ssh ntp
apt-get install python-dev openbsd-inetd postfix madplay

Add following lines to /etc/apt/sources.list:

deb http://project.runtux.com/asterisk/debian/ lenny main
deb-src http://project.runtux.com/asterisk/debian/ lenny main

If you want to avoid warnings about an untrusted archive key from apt, you should import the following archive key. Save the key to a file and then issue the command
apt-key add file

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.9 (GNU/Linux)

mQENBEnREAIBCADM8+KpoC/HJUCEsx8KZhGgsX/G3ouR4/xkgIuIPgz+t6JoTisj
9QmymDZKUXSy04WmbLjU/088xD5A9ukOEYxoFCGqwWf1tPOKqN1oKpVCkjJb8Dht
vvebqOCzJSV0nfqmIfkpbX+6dUssx+9u0BiFK3aj/GilkEloZl2g+vIT6fveJtKE
qmxz19vL516TDhsbsv3/AKfNKc7QRpsgvPmnNE2IL0CTgQYs26WtnJASlu1MQpwo
Qfb1PrO7ufq9eO58HjEBdfbSNjalQjVj7vLvE4GQglHULO500H9UlfOm2zpO0Vzs
5lGGbwLJdTpAS3HIRhQAW0pueRsQ8zagMn5lABEBAAG0OFJhbGYgU2NobGF0dGVy
YmVjayAoRGViaWFuLVBhY2thZ2UtS2V5KSA8cnNjQHJ1bnR1eC5jb20+iQE2BBMB
AgAgBQJJ0RACAhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQ5CizCR9G97ah
pAf/eLRYtPVs1apI3+AVi//8y1/r6uL+IxI/Tlt53jCtX/dy3Q3FeAEJt/7fbvcW
TBDnP5K8vWaYUlHHaz+6lbcQyV/KAH4LKJEKkyoINc9ytG1qEG6z8NPfDmKiEluy
HksgLpAqUBrdZy46iWQhcg7f3fpcUIsHHcXrOd2Ip5G9DL2q4/UoRrhBhHC3GNX7
ERaeAKZTF1JRaVN6KSWPC2+yaNmuGn1yoSChG0Q/bBTgzv2fm9Jzvok546f9LE0q
k2q5PvjlUSMGHHojTzzR6tGhnbw5mOfyMUDDs5LuAN1aWbDatepJgiC+dYasprQ5
pZygpoCASqIhWjjCZd3XI5mAEIhGBBARAgAGBQJJ0nZlAAoJEIO0FkDz/lcw0xYA
njBSGef/4KhZpuspIh6WnLM7ORKNAKCw28et9bUoaGu4ESRpIwtwj4asQoicBBAB
AgAGBQJJ0ncuAAoJEJWCQpSoBzk1hpcD/2KXiuvE2Nm0oOi0jBVEjT/Tu/GGkG5m
lf97/I6TMcJxlMpeBlv9SiJD+/BBQo0MGMxmkCwU4t+eBCBsCVcr/bJnrlrKa4Ab
9SR9WQ8PGrSQ+AwMePCDKngqFd5EERz8bxz4sZKGCxn9JVRQOGp03eKSGDG/Yh0v
FY3v7nV0BUaE
=mPtt
-----END PGP PUBLIC KEY BLOCK-----

Then install:

apt-get update
apt-get install linux-headers-2.6.28.5-i686 linux-image-2.6.28.5-i686 \
    asterisk zaptel lcr zaptel-modules-2.6.28.5-i686

If you’re on the amd64 architecture, you should replace i686 in the packages above with amd64.

and optionally (for misdn_info):

apt-get install misdnv2user

Edit /etc/default/asterisk and set RUNASTERISK=yes. Then make several directories (should be done by a future version of the lcr package):

mkdir /var/run/lcr
chown asterisk.asterisk /var/run/lcr
mkdir /var/log/lcr
chown asterisk.asterisk /var/log/lcr

I’ve also made a start-script for lcr (for use as /etc/init.d/lcr) ,
downloadable at http://project.runtux.com/asterisk/init.d:lcr
this probably should also be part of the lcr package.

Config file examples used for lcr — these pass
everything to asterisk. File /etc/lcr/interface.conf:

[Ext1]
portnum 0
ptp
nodtmf

[Ext2]
portnum 1
ptp
nodtmf

[Int1]
portnum 2
nt
ptp
nodtmf

[Int2]
portnum 3
nt
ptp
nodtmf

I’m using a Beronet 4 port ISDN card, your config will probably differ: This system only expects incoming calls and needs to check on which line a call comes in. So I distinguish all external interfaces as separate interfaces of LCR. I also need to check an interface by calling out via that interface, you probably would want to make all external ports a trunk by grouping them into one LCR interface.

And the routing config needs to match your interface definition. This config will pass all calls — if asterisk is running — to asterisk. If asterisk isn’t running, I’m calling a test application (untested). The context in asterisk will be the interface name. Again, if you’re using a trunk here, be sure to match the routing config with your interface config. /etc/lcr/routing.conf:

[main]
remote=asterisk interface=Ext1 : remote application=asterisk
remote=asterisk interface=Ext2 : remote application=asterisk
remote=asterisk interface=Int1 : remote application=asterisk
remote=asterisk interface=Int2 : remote application=asterisk
default                        : efi

Update /etc/modules to include the following lines (the command appends the lines between cat and EOF):

cat >> /etc/modules << EOF
mISDN_core debug=0x0
mISDN_dsp debug=0x0 options=0x0
hfcmulti debug=0x0
EOF

Linux udev must be configured to correctly set the user for the isdn device(s):

cat > /etc/udev/rules.d/91-isdn.rules << EOF
ACTION!="add|change", GOTO="permissions_end"

KERNEL=="mISDN*",       GROUP="dialout"

LABEL="permissions_end"
EOF

After a reboot asterisk and lcr should be running.

Building

Getting kernel:

wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.28.tar.bz2
wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.28.tar.bz2.sign
wget http://kernel.org/pub/linux/kernel/v2.6/patch-2.6.28.5.gz
wget http://kernel.org/pub/linux/kernel/v2.6/patch-2.6.28.5.gz.sign

For compilation (zlib isn’t checked by make-kpkg!):

apt-get install kernel-package bzip2 libncurses5-dev zaptel-source \
    zlib1g-dev fakeroot

Compile Kernel:

tar xvf linux-2.6.28.tar.bz2
cd linux-2.6.28
zcat ../patch-2.6.28.5.gz | patch -N -p1 | less 2>&1
cp /boot/config-2.6.28.5-i686 .config
make oldconfig
make menuconfig # just to be sure

For amd64:

make-kpkg --append-to-version -amd64 --revision 2.6.28.5.1.rsc --us \
    --uc --initrd --rootcmd fakeroot binary > m.out 2> m.err

For i686:

make-kpkg --append-to-version -i686 --revision 2.6.28.5.1.rsc --us \
    --uc --initrd --rootcmd fakeroot binary > m.out 2> m.err

The following doesn’t seem to work although zaptel is installed:
probably need to unpack /usr/src/zaptel.tar.bz2 into
/usr/src/modules/zaptel (tar file contains modules directory!)
this would save us from the m-a a-i step below. amd64:

make-kpkg --append-to-version -amd64 --revision 2.6.28.5.1.rsc --us \
    --uc --initrd --rootcmd fakeroot modules > mo.out 2> mo.err
cd ..

For i686:

make-kpkg --append-to-version -i686 --revision 2.6.28.5.1.rsc --us \
    --uc --initrd --rootcmd fakeroot modules > mo.out 2> mo.err
cd ..

Make a debianized zaptel for new kernel:

apt-get install devscripts libnewt-dev quilt libusb-dev asciidoc
svn checkout http://svn.digium.com/svn/zaptel/branches/1.4 zaptel
apt-get source zaptel-source
cp zaptel/kernel/ztdummy.* zaptel-1.4.11~dfsg/kernel
cd zaptel-1.4.11~dfsg
# Add "Fix compilation for newer kernels"
dch -i
dpkg-buildpackage
cd ..
dpkg -i zaptel-source_1.4.11~dfsg-3.1_all.deb
m-a a-i zaptel

The following installs my patched asterisk, I’m modifying some buffer sizes because I want to play long tones (I’m generating a faked modem guard-tone that is needed in a project). You probably won’t need the patches asterisk, but it won’t hurt to install it. The create-patches script is available from
http://project.runtux.com/asterisk/create-patches

apt-get install libreadline5-dev libgsm1-dev libssl-dev libtonezone-dev \
    libvpb-dev autotools-dev libsqlite-dev libspeex-dev libspeexdsp-dev \
    graphviz libcurl4-openssl-dev doxygen libpopt-dev libopenh323-dev   \
    libiksemel-dev libradiusclient-ng-dev freetds-dev libvorbis-dev     \
    libsnmp-dev libc-client2007b-dev libcap2-dev libpq-dev unixodbc-dev \
    libpri-dev
apt-get source asterisk
scp ralf@bee:checkout/own/config/asterisk/create-patches .
cd asterisk-1.4.21.2~dfsg/
sh ../create-patches
# Hunk #1 succeeded at 25 (offset 3 lines).
# Add "runtux.com local buffer-size patches"
# and new version-number 1:1.4.21.2.1~dfsg-3
dch -i # add comment
dpkg-buildpackage -rfakeroot
cd ..

For mISDNuser and chan_lcr I’m using Joerg Dorchains packages with my added patches for DTMF codes A-F.