Linux, ISDN, HFC-S: Game Over

Nachdem das mit der Rufumleitung am Anlagenanschluß mit Fritz!OS nicht so richtig tat, ist quasi Asterisk mit einer ISDN-Karte die letzte Hoffnung …

Ich hatte Grund zur Hoffnung, daß es mit relativ aktueller (neuer als ca. 2012) libpri klappt, insofern installierte ich eine aus meinem Hardwarefundus gefischte HFC-S-ISDN-PCI-Karte in einem Futro, und probierte mein Glück mit Ubuntu 16.04, der aktuellen LTS-Version.

Satz mit X: in 1:2.10.2~dfsg-1ubuntu1 wurde zaphfc, notwendiger DAHDI-Treiber für die Cologne-Chip-Single-Port-Karten, entfernt:

* debian/dkms.conf.in
– Dropping ap400, opvxd115, wcopenpci, and zaphfc from build as
those got dropped from the Debian extra patch.

Nunja; die Installation soll noch rund ein halbes Jahr laufen, dann nehmen wir eben 14.04 LTS, denn da ist zaphfc noch drin.

Aber natürlich habe ich die Rechnung ohne die vielen Wirte gemacht: 14.04 gibt’s nur noch als 14.04.5-Image, mit einem 4er Kernel. dahdi-dkms allerdings bricht beim 4er Kernel ins Essen, wird offensichtlich nicht mehr gepflegt (was, gelinde gesagt, ziemlich scheiße ist, verließe man sich darauf, daß in einem LTS-Setup alles weiterfunktioniert).

Ist mir aber auch egal, Downgrade auf 3.19er Kernel dann eben. Und nach einem kleinen Ausflug in die Welt des Rescue-Boots – ohne das ›linux-image-extra‹-Package fehlt ein Modul, welches die Futro-Hardware benötigt, um die CF-Card als Laufwerk anzusprechen; ohne pata_atiixp kein Bootdevice und somit auch kein Root-FS – und dem dkms-Lauf gab es, endlich, endlich, einen Treiber für meine HFC-S-ISDN-Karte (»Cologne Chip«):

root@voip:~# dahdi_hardware -v
pci:0000:0e:07.0     zaphfc+      1397:2bd0 HFC-S ISDN BRI card

Allerdings … in Asterisk tut’s nicht:

root@voip:~# dahdi_scan
[1]
active=yes
alarms=OK
description=HFC-S PCI A ISDN card 0 [TE]
name=ZTHFC1
manufacturer=Cologne Chips
devicetype=HFC-S PCI-A ISDN
location=PCI Bus 14 Slot 08
basechan=1
totchans=3
irq=20
type=digital-TE
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=AMI
framing_opts=CCS
coding=AMI
framing=CCS
[2]
active=yes
alarms=UNCONFIGURED
description=DAHDI_DUMMY/1 (source: HRtimer) 1
name=DAHDI_DUMMY/1
manufacturer=
devicetype=DAHDI Dummy Timing
location=
basechan=4
totchans=0
irq=0

root@voip:~# dahdi_hardware
pci:0000:0e:07.0     zaphfc+      1397:2bd0 HFC-S ISDN BRI card

root@voip:~# lsdahdi
### Span  1: ZTHFC1 "HFC-S PCI A ISDN card 0 [TE] " AMI/CCS
  1 BRI        Clear       (EC: OSLEC - INACTIVE) 
  2 BRI        Clear       (EC: OSLEC - INACTIVE) 
  3 BRI        Hardware-assisted HDLC  
### Span  2: DAHDI_DUMMY/1 "DAHDI_DUMMY/1 (source: HRtimer) 1" (MASTER)

root@voip:~# asterisk -r
Privilege escalation protection disabled!
See https://wiki.asterisk.org/wiki/x/1gKfAQ for more details.
Asterisk 11.7.0~dfsg-1ubuntu1, Copyright (C) 1999 - 2013 Digium, Inc. and others.
Created by Mark Spencer 
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
Connected to Asterisk 11.7.0~dfsg-1ubuntu1 currently running on voip (pid = 879)
voip*CLI> dahdi show status
Description                              Alarms  IRQ    bpviol CRC    Fra Codi Options  LBO
HFC-S PCI A ISDN card 0 [TE]             OK      0      0      0      CCS AMI           0 db (CSU)/0-133 feet (DSX-1)
DAHDI_DUMMY/1 (source: HRtimer) 1        UNCONFI 0      0      0      CAS Unk           0 db (CSU)/0-133 feet (DSX-1)

voip*CLI> dahdi show channels
   Chan Extension  Context         Language   MOH Interpret        Blocked    State      Description                    

root@voip:~# more /etc/asterisk/dahdi-channels.conf
context=from-isdn
channel => 1-2
switchtype = euroisdn
signalling = bri_cpe_ptmp
group = 1

root@voip:~# more /etc/asterisk/chan_dahdi.conf
trunkgroups]
  
[channels]
language=de
switchtype=euroisdn

pridialplan=unknown
prilocaldialplan=unknown
internationalprefix = 00
nationalprefix = 0
localprefix = 09876
privateprefix = 09876123456
unknownprefix =
priindication = outofband

facilityenable=yes
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
immediate=no
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
callgroup=1
pickupgroup=1
mohinterpret=default
mohsuggest=default

group=1
signalling=bri_cpe_ptmp
   ; p2p TE mode  => bri_cpe
   ; p2mp TE mode => bri_cpe_ptmp
   ; p2p NT mode  => bri_net
   ; p2mp NT mode => bri_net_ptmp
context=isdn-dtag
channel => 1-2

root@voip:~# uname -a
Linux voip 3.19.0-79-generic #87~14.04.1-Ubuntu SMP Wed Dec 21 18:46:52 UTC 2016 i686 athlon i686 GNU/Linux

root@voip:~# dmesg | grep -B2 hfc
[   10.028151] dahdi: Telephony Interface Registered on major 196
[   10.028161] dahdi: Version: 2.5.0.1
[   10.150688] vzaphfc: HFC-S PCI A ISDN (V1.42) loading
[   10.151251] vzaphfc: card 0: registered ZTHFC1/0/1
[   10.151259] vzaphfc: card 0: registered ZTHFC1/0/2
[   10.151263] vzaphfc: card 0: registered ZTHFC1/0/3
[   10.214250] vzaphfc: card 0: resetting
[   10.236562] vzaphfc: card 0 configured for TE mode at mem 0xf8300000 (0xf843c000) IRQ 20
--
[   16.965985] dahdi_transcode: Loaded.
[   18.379171] dahdi_echocan_oslec: Registered echo canceler 'OSLEC'
[   18.380399] vzaphfc: card 0: chan B1: TX FIFO has become empty
[   18.380409] vzaphfc: card 0: chan B1 opened as ZTHFC1/0/1.
[   18.380432] vzaphfc: card 0: chan B1 closed as ZTHFC1/0/1.
[   18.380450] vzaphfc: card 0: chan B2: TX FIFO has become empty
[   18.380455] vzaphfc: card 0: chan B2 opened as ZTHFC1/0/2.
[   18.380474] vzaphfc: card 0: chan B2 closed as ZTHFC1/0/2.
[   18.380493] vzaphfc: card 0: chan D opened as ZTHFC1/0/3.
[   18.380499] vzaphfc: card 0: chan D closed as ZTHFC1/0/3.

root@voip:~# lsmod | egrep 'dah|hfc'
dahdi_echocan_oslec    16384  2
echo                   16384  1 dahdi_echocan_oslec
dahdi_transcode        16384  0
dahdi_dummy            16384  0
zaphfc                 24576  0
dahdi                 196608  4 dahdi_dummy,dahdi_transcode,dahdi_echocan_oslec,zaphfc
crc_ccitt              16384  1 dahdi

Hmm. Wie es aussehen sollte, steht in diesem G+-Beitrag.

Auch die vier Jahre alten Tipps halfen nur bedingt weiter. Eingesetzt wurde »dahdi-2.5.0.1+dfsg-1ubuntu4~14.04.4«; des Rätsels Lösung fand sich in einem Git-Commit:

dahdi: Fix failure to read / write on kernel 3.16+

Kernel version 3.16+, since upstream commit (7f7f25e82d54870d “replace checking for ->read/->aio_read presence with check in ->f_mode” )[1], does not like it when dahdi changes the set of allowed file operations on a file descriptor outside of the context of an open() system call.

DAHDI changes the available file operations when a channel is opened by first opening /dev/dahdi/channel and then calling the DAHDI_SPECIFY ioctl to bind it to a particular DAHDI channel. Until DAHDI_SPECIFY is called there weren’t any read()/write() callbacks implemented and therefore after the initial open, the kernel was setting not setting FMODE_CAN_{WRITE,READ} on the file descriptor indicating that those operations were not allowed.

Now define empty shell functions on the general dahdi_fops so the vfs layer will not mark a file descriptor as unwritteable or unreadable on open.

Wie auch immer, Kernel 3.13 klingt auch nach einem Plan — und tatsächlich, kaum in den antiquarischen Tiefen eines 3.13er Kernels angekommt, klappt’s auch mit der ISDN-Karte. Yay …

Jetzt muß ich die ISDN-Karte nur noch auf den Anlagenmodus konfigurieren, korrekt in Asterisk einbinden und nach nur zwei Tagen werde ich sehen, ob Transfer() am Anlagenanschluß Partial Rerouting ausführt …

Das ist wirklich alles eine ganz große Grütze, und ich bin ziemlich froh, schon vor ca. 8 Jahren das Handtuch geworfen und auf FritzBoxen als ISDN-Interface gesetzt zu haben. Gut, ganz so schnell ging’s dann auch wieder nicht, aber ich habe tatsächlich das Trauerspiel um Treiber verpaßt — bis ich in der 1. Woche 2017 unverhofft mich dem Thema wieder widmen durfte.

Screenshot

500 EUR für ‘ne IS­DN­-Kar­te? Okay, ak­tiv, a­ber … Ker­nel 2.6?!

Und wie traurig der Markt geworden ist, zeigen IMHO die Sirrix-Produkte; da bietet ein Händler in der Nachbarstadt (Halle/Westfalen) eine 4-Port-ISDN-Karte für 500,– EUR an — nur ist ein Linux-Kernel 2.6 Betriebsvoraussetzung.

chan_capi, die Asterisk-Unterstützung für Karten, die via CAPI ansprechbar sind, wird mühsam weitergepflegt, es gibt sogar Anpassungen für Asterisk 13. Allerdings habe ich auf die Schnelle nicht rausgefunden, ob und wie welche aktiven ISDN-Karten noch unterstützt werden in aktuellen Kerneln (also weit jenseits 3.13+), geschweige denn, welche davon unter Linux wie per CAPI ansprechbar wären. Ältere aktive ISDN-Karten bekommt man da für relativ kleines Geld; allerdings liest sich die Mailingliste auch eher wie ein Abgesang, zumindest werden mehr und mehr Features zugusten der Basisfunktion über Bord geworfen. Und was aktuelle Kernel angeht, irgendwo zwischen 3.2 und vor 3.19 ist ein inoffizielles Treiberpaket für die DIVA-Karten stehen geblieben — letztes Update vor 2 Jahren. Mithin auch keine Option im Jahre 2017 mehr.

Aber es gibt auch geile Lösungen: die PCI(e)-Karten der beroNet GmbH kommen für’s Hostsystem als Realtek-Ethernetkarte daher, welche z. B. Asterisk dann per SIP über die »zweite Netzwerkkarte« anspricht — und Zusatzmodule machen die Ports dann zu ISDN- und/oder Analog-Ports. Aktive Karten, die aber wirklich keine Treiber brauchen, solange der Realtek-Ethernet-Chipsatz noch vom OS unterstützt wird. Schade, in der Bucht war vor ein, zwei Wochen eine 4-Port-ISDN-Karte, aber Sofortkauf für 150,– war mir dann doch zuviel des Guten — schließlich habe ich zuhause erst im letzten Jahr die 144 kBit/sec des ISDN- durch 100 MBit/sec des VDSL-Vectoring-Anschlusses ersetzt.
Letztlich schade, war an sich ein Schnäppchen — aber ab 2018 wird es kaum noch möglich sein, echte ISDN-Anschlüsse zu bekommen, und, seien wir mal ehrlich, preislich wie technisch ist SIP ISDN mittlerweile Lichtjahre voraus. Für 5 EUR/Monat bekommt man 10 parallele Gespräche per SIP — das wären 5 ISDN-Anschlüsse, die alleine an Kupferdoppeladern mit 50 EUR zu Buche schlagen. Plus lustiger Technik, die diese 10 einzelnen B- und 5 D-Kanäle logisch bündelt, Anrufe drauf verteilt.
Bei SIP hingegen: 10 EUR/Monat drauf, und man hat 1000 Minuten ins Fest- und 100 Minuten in die Mobilfunknetze frei. Klar, einen leistungsfähigen Internet-Zugang braucht man obendrauf; aber auch die gibt’s ab 25 EUR/Monat. Und man ist dann prinzipiell frei in der Wahl seines ITSP (Internet-Telephony Service Provider); Kehrseite allerdings: ohne IP kein SIP, rafft’s den Internetzugang dahin, sei es lokal oder beim ISP, hat sich auch die Telefonie erledigt. Bin wirklich gespannt, wie sich das in den nächsten Jahrzehnten auswirken wird. Oder ob.

Anyway, das Fazit bleibt: ISDN ist schon länger tot, nur haben ›wir‹ es nicht wahrhaben wollen. Also ich in dem Maße jedenfalls nicht. Schon beim letzten ISDN-Asterisk-Abenteuer habe ich geflucht wie ein Rohrspatz; zum Teil ist es deutlich besser geworden, DAHDI mit zaphfc läuft wie ein Kätzchen — unter Ubuntu 14.04 LTS mit Kernel 3.13. Danach … fehlt jegliche Anpassung an Änderungen im Kernel, HFC-S-Karten sind mithin jenseits Kernel 3.13 nur noch Elektroschrott.
Treiber für die 4-Port-Karten hingegen (HFC-4S), werden noch weiter gepflegt (wie lange?!), also entweder eine solche holen (inkl. PC, in dem eine Full-Profile-PCI(!)-Karte noch Platz findet) oder auf Media-Gateways ausweichen, hat man noch ISDN-Geraffel zu bedienen.

IMHO ist dies auch der bislang deutlichste Beweis, daß auch Hardware ›gealtert wird‹; sie altert gar nicht zwingend von sich heraus, sondern wird passiv, durch Nicht­an­pass­ung an aktuelle Ent­wick­lungen, abgehängt. Leider auch in der Open-Source-Welt; warum es gerade die HFC-S-Karten betrifft, erschließt sich mir nicht: die Änderungen für HFC-S und HFC-4S dürften austauschbar sein, machbar wäre es wohl. Alternativ könnte man auch die HFC-S-Treiber in die HFC-4S-Treiber integrieren, denke ich — aber es nutzen wohl zu wenige … Anyway, vor zehn Jahren hätte ich noch Stein und Bein geschworen, daß derlei nur proprietären Software-Hardware-Kombinationen ›passiert‹.

FTR, der Asterisk-x86-Server mit HFC-S läuft mittlerweile; und anders als eine Fritz!Box, kann jener am ISDN-Anlagenanschluß auch ganz wunderprächtig »Call Deflection Partial Rerouting«, dank DAHDI.
Daß AVMs Support-Helden, die mich per Twitter zur Support-Case-Eröffnung baten, nach gut einer Woche die Frage, ob denn ein aktuelles Fritz!OS am Anlagenanschluß ›CDPR‹ können sollte, mit »daß muß die Telekom einstellen und außerdem ist der Betrieb am Anlagenanschluß nicht supportet« (Nein! Doch! Oh! — das war mir initial schon klar, aber scheinbar hat AVM weder bei Twitter noch im Ticket meine Frage gelesen :() beantworteten, spricht für mich Bände. Ernsthaft, liebe AVM, ich hatte das vorher gelesen und daher getwittert, statt den Support zu belästigen. Hrmpft.

Wrap up: Fritz!OS kann zwar in den Anlagenmodus geschaltet werden (ISDN PtP statt PtMP), Rufumleitungen tun dann aber nur »zu Fuß«, sprich mit der eigenen Anschlußnummer über den zweiten B-Kanal. Eine Fritz!Box kann aber nur einen S0 gleichzeitig extern bedienen, Rufumleitung unter Nutzug beider B-Kanäle ist ziemlich nervig.
Ein Asterisk 11 unter Ubuntu 14.04 LTS und Kernel 3.13 ist im Jahre 2017 die scheinbar einzige Möglichkeit, noch eine HFC-ISDN-Karte sinnvoll zu nutzen. Und SIP hat in den letzten ~10 Jahren deutliche Forschritte gemacht, was die Qualität angeht — anders als damals höre ich heute, ISDN-verwöhnt, auch bei Verbindungen ins Festnetz per SIP kaum einen Unterschied.

Ruhe also sanft, ›mein‹ Integrated Services Digital Network!