HFC-Karte mit Dahdi und Asterisk 1.6

[robber437]

Hallo,

hat irgendjemand schon seine HFC-Karte in Asterisk 1.6 mit Dahdi zum laufen bekommen? Dahdi soll doch schon von Hause aus BRI Unterstützung bieten, warum gibt es kein Modul für den HFC-Chipsatz. Es kursieren zwar diverse Patches aber nichts will so richtig funktionieren...

Gruß
robber

 

[robber437]

Uups ich hab vergessen zu erwähnen dass ich den HFC-S Chip auf den BilligISDN-Karten, die mit dem zaphfc Modul laufen meine.

 

[speedy1980]

... Es kursieren zwar diverse Patches aber nichts will so richtig funktionieren...

Gruß
robber

Kannst Du Quellen nennen? Letzlich braucht man ja "nur" einen angepassten Treiber, soll ja alles in Asterisk 1.6 für BRI drinnen sein.

 

[robber437]

Hier z.B:

http://svn.debian.org/wsvn/pkg-voip/dahdi-linux/trunk/drivers/dahdi/?rev=6097&sc=0

 

[speedy1980]

Also ich sehe dort keine Anpassungen für Dahdi. Das zaphfc Modul finde ich in dem Verzeichnis nicht und zumindest der qozap Treiber ist für Zaptel und nicht Dahdi. Demnach kann das mit Asterisk 1.6 nicht funktionieren.
Aber ich guck mal auf die Bristuff-Mailingliste.

Edit: zaphfc Modul gefunden. Aber auch dort sind noch die Zap-Aufrufe drin. Anpassungen für DAHDI in Asterisk 1.6 fehlen.

 

[wildzero]

hallo, unter
http://svn.debian.org/viewsvn/pkg-voip/dahdi-linux/trunk/drivers/dahdi/

findet sich der dahdi angepasste zaphfc. ich selbst hatte mir auch den vzaphfc (welchen ich bevorzuge) auf dahdi und kernel 2.6.29 angepasst. Lauft soweit super mit *1.6 (edlich ohne geBristuffel und mISDN krampft)

Aber ein großes Mako hat die Sache dann leider doch, NT-ptmp (Mehrgeräte intern) ist nicht implementiert

Ich bin z.Z. am überlegen wie man NT-ptmp überhaupt einbauen kann. Können ja mal ein Brainstorming starten. Ob man sich z.B. an der an der libisdnnet.so aus mISDNuser bedienen könnte. Obwohl naheliegender wäre es natürlich zu schauen, ob und welcher NT-ptmp Code aus dem Bristuff Patch entnehmbar wäre.

Wobei dass alles immer wieder den Nachteil hat, das alles ohne den obligatorischen Digium Disclaimer nie upstream geht. Daher müsste es eine Lösung sein, die man dann auch an Digium abtreten kann.

 

[wildzero]

ich hab jetzt einfachmal ganz naiv in der chan_dahdi.c/process_dahdi

bei signalling/bri_cpe_ptmp folgendes gesetzt:

confp->chan.sig = SIG_BRI_PTMP;
confp->pri.nodetype = PRI_NETWORK;

und tatsachlich "zuckt" es in der asterisk cli, wenn ich als ISDN-Endgerat einen anderen Rechner mit mISDN/LCR hernehme und von hier aus per "lcradmin testcall" einen ISDN call absetze.

Linux Call Router (mISDNv2 in TE-ptmp) --> asterisk(Dahdi in NT-ptmp)

Vieleicht wäre es tatsächlich möglich, zumindest ein Endgerät per NT-ptmp
zu betreiben. Also quasi ptp over ptmp Würde mir ertmal reichen, da ich NT-ptmp eh nur benötige um einen ISDN/Analog Adapter oder eine seperate
ISDN-Modem Karte zu betreiben. Der Fall, dass mal von dem Point to "Multi Point" Feature, also mehre Endgräte an einem NT, wirklich gebrauch gemacht wird, ist eher selten.

UPDATE:
Also mit meinem DeTeWe TA33 kann ich tatsächlich per Nt-ptmp Dahdi in den Asterisk reinrufen, dieser nimmt dann zwar direkt auf der s-Extension
ab sobald ich abheben am DeTeWe, aber es sind reale Anrufe möglich.

Bei dem umgekehreten weg passiert leider nichts. Aber sollte für alle hier Interessierten sicherlich Anregung sein hier auch zu basteln

 

[wildzero]

Patch im digium bugtracking: http://bugs.digium.com/view.php?id=15048

 

[wildzero]

hallo, wollte das hier mal pushen, da ich für für libpri einen ersten experimentellen patch oder auch "hack" fertige habe. Damit sind rufe von chan_dahdi über die libpri auf ein isdn Telefon/Adapter möglich sind.

Es funktioniert bisher noch sehr eingeschränkt. Das ISDN Endgerät bekommt zwar einen TEI, und es werden ALERTING, CONNECT und CONNECT ACKNOWLEDGE ausgetauscht, aber chan_dahdi verweigert dann auch audio zu übertragen, da der Status in der chan_dahdi nach CONNECT und CONNECT ACKNOWLEDGE, immer noch auf "dialing" ist (p->dialing)

chan_dahdi.c:7068 dahdi_write: Dropping frame since I'm still dialing on DAHDI/1-1...

Irgenwo setzt die libpri den Status im chan_dahdi nicht um, habe bisher die entscheide Stelle nicht gefunden. Vieleicht hat jemand ein besseres Auge als ich?

Patch hier:
https://issues.asterisk.org/view.php?id=15048

 

[mathiasrk]

hallo, unter
http://svn.debian.org/viewsvn/pkg-voip/dahdi-linux/trunk/drivers/dahdi/

findet sich der dahdi angepasste zaphfc. ich selbst hatte mir auch den vzaphfc (welchen ich bevorzuge) auf dahdi und kernel 2.6.29 angepasst. Lauft soweit super mit *1.6 (edlich ohne geBristuffel und mISDN krampft)

sind diese 2.6.29 anpassungen irgendwo als patch verfuegbar ?
ich moechte nur meinen isdn anschluss terminieren. intern laeuft alles via SIP.
Von daher waere NT-ptmp fuer mich nicht so wichtig.

 

[wildzero]

Dahdi vzaphfc
http://lists.elastix.org/pipermail/beta-testers/attachments/20090415/18257147/attachment-0001.bin

Patch für 2.6.28 und/oder 2.6.29

diff -u zaphfc/base.c /home/mylab/src/dahdi-linux-2.2.0-rc2/drivers/dahdi/vzaphfc/base.c
--- zaphfc/base.c	2009-04-15 02:00:10.000000000 +0200
+++ /home/mylab/src/dahdi-linux-2.2.0-rc2/drivers/dahdi/vzaphfc/base.c	2009-05-05 18:50:20.266641241 +0200
@@ -48,6 +48,10 @@
 #define B1 1
 #define B2 2
 
+#define FALSE 0
+#define TRUE (!FALSE)
+
+
 static int modes = 0; // all TE
 static int nt_modes[hfc_MAX_BOARDS];
 static int nt_modes_count;
@@ -1594,7 +1598,7 @@
 
 	memset(chan->netdev->dev_addr, 0x00, sizeof(chan->netdev->dev_addr));
 
-	SET_MODULE_OWNER(chan->netdev);
+	//SET_MODULE_OWNER(chan->netdev);
 }
 
 static int __devinit hfc_probe(struct pci_dev *pci_dev,
@@ -1691,7 +1695,7 @@
 	pci_write_config_dword(card->pcidev, hfc_PCI_MWBA, card->fifo_bus_mem);
 
 	if ((err = request_irq(card->pcidev->irq, &hfc_interrupt,
-		SA_SHIRQ, hfc_DRIVER_NAME, card))) {
+		IRQF_SHARED, hfc_DRIVER_NAME, card))) {
 		printk(KERN_CRIT hfc_DRIVER_PREFIX
 			"card %d: "
 			"unable to register irq\n",
@@ -1993,9 +1997,9 @@
 	printk(KERN_INFO hfc_DRIVER_PREFIX
 		hfc_DRIVER_STRING " loading\n");
 
-	hfc_proc_zaphfc_dir = proc_mkdir(hfc_DRIVER_NAME, proc_root_driver);
+	hfc_proc_zaphfc_dir = proc_mkdir("driver/vzaphfc", NULL);
 
-	ret = pci_module_init(&hfc_driver);
+	ret = pci_register_driver(&hfc_driver);
 	return ret;
 }
 
@@ -2005,7 +2009,7 @@
 {
 	pci_unregister_driver(&hfc_driver);
 
-	remove_proc_entry(hfc_DRIVER_NAME, proc_root_driver);
+	remove_proc_entry("driver/vzaphfc", NULL);
 
 	printk(KERN_INFO hfc_DRIVER_PREFIX
 		hfc_DRIVER_STRING " unloaded\n");
diff -u zaphfc/lapd.c /home/mylab/src/dahdi-linux-2.2.0-rc2/drivers/dahdi/vzaphfc/lapd.c
--- zaphfc/lapd.c	2009-04-14 12:36:26.000000000 +0200
+++ /home/mylab/src/dahdi-linux-2.2.0-rc2/drivers/dahdi/vzaphfc/lapd.c	2009-05-05 19:11:32.503479401 +0200
@@ -25,11 +25,7 @@
 {
 
 	netdev->change_mtu         = lapd_change_mtu;
-	netdev->hard_header        = NULL;
-	netdev->rebuild_header     = NULL;
 	netdev->set_mac_address    = lapd_mac_addr;
-	netdev->hard_header_cache  = NULL;
-	netdev->header_cache_update= NULL;
 
 	netdev->type               = ARPHRD_LAPD;
 	netdev->hard_header_len    = 0;

da Junghanns aber auch den florz patch nun im orginalen zaphfc integriert hatt, macht es eventuell doch sinn diesen zu verweden. Denn der org. zaphfc ist schlicht wesentlich öfter im Einsatz.

Hier noch die dahdi Version des florz Patch:
http://www.solidboot.com/~fabled/zaphfc-dahdi-flortz.diff

 

[Larry]

Eurem Thread folgend habe ich mich auch mal drangesetzt; das patchen ging leider nicht so ohne weiteres, da sich irgendwo im svn etwas geändert zu haben scheint. Nach mehreren Interviews mit Frau Google habe ich dann aber alles zusammengesammelt bekommen und endlich lief ein patch mit anschl. make prima durch.
Da das alles jetzt schon wieder ca. zwei Wochen her ist und ich einfach nicht die Zeit und Ruhe finde, alles in Ruhe durchzutesten, will ich Euch jetzt einfach mal den von mir fix-und-fertig gepatchen dahdi-Zweig unter die Nase reiben.

Die zusätzlich zu dahdi-svn verwendeten Files und Patches liegen nochmals gesondert unter 'drivers/dahdi/zaphfc/unpatched'.

Getestet habe ich eine Billig HFC-S Karte im TE-Modus (* 1.6.0.9 / 2.6.29) mit einem halben Doppeldutzend ein- und ausgehenden Rufen bei aktiviertem MG2-EC. Soweit keinerlei Gejammer in den Logs und die Qualität war einwandfrei.

Jetzt Ihr...

 

[Larry]

Digium hat gerade dahdi-linux-2.2.0 freigegeben. Die Patches für bri_dchan, florz und zaphfc klappen auch noch, daher habe ich das Zeug aus meinem vorigen Post neu verpackt.

Geändert habe ich folgendes:
- das Archiv enthält jetzt nur noch die notwendigen Files, um im Original-DAHDI ausgepackt und dagegen gepatcht zu werden
- drivers/dahdi/zaphfc enthält nur noch die originalen Daten
- die Patches liegen jetzt in der Root von dahdi-linux-2.2.0 (zaphfc-dahdi-flortz.diff mit angepassten Pfaden)
- One-Klick-Skript, welches die Patches anwendet und make/make install anschmeisst

Warnung: Ich habe noch keinerlei praxistaugliche Tests durchgeführt, mit der Ausnahme, die Patches anzuwenden und alles zu kompilieren - was scheinbar fehlerfrei klappt.

EDIT: Anhang gelöscht wg. fehlendem Patch - neues Archiv in MSG#16

 

[rentier-s]

Zwischenfrage: auch für SuSE?

Hallo Larry,

hab ich damit Chancen, Asterisk 1.4 oder 1.6 unter SuSE 11.1 mit zwei HFC-Karten zum Laufen zu bekommen?

Ich bin nicht so der Linux Profi, habs zwar geschafft was mit mISDN und chan_lcr zusammen zu basteln, aber das ist nicht der Hit (Brummen, DTMF, etc...).

 

[Larry]

hab ich damit Chancen, Asterisk 1.4 oder 1.6 unter SuSE 11.1 mit zwei HFC-Karten zum Laufen zu bekommen?

Davon gehe ich doch mal aus Wenn Du die entsprechenden Voraussetzungen (Kernel-Header/-Sourcen, gcc, etc.) hast, sollte das eigentlich kein großes Problem darstellen.

Ich bin es mittlerweile auch leid mit mISDN/lcr. Auch wenn es eigentlich ein vielversprechendes Projekt ist, ist es in der Vergangenheit aus meiner Sicht eher ständig irgendwo zwischen beta/unstable herumgeeiert.
Zwar läuft mISDN hier bei mir inzwischen lange Zeit sehr stabil im Produktiv-Betrieb, aber die Probleme mit den Kernel-Modulen, Echo-Canceller und anderen Faktoren sind und waren immer ein Thema für sich und für mich nie richtig zufriedenstellend.

zaphfc orientiert sich IMHO sehr schön an DAHDI, die Module lassen sich leicht (auch bei neuen Kerneln) neu bauen und auch Stressfrei entladen (!). Erste Tests mit zaphfc verliefen bei mir sehr vielversprechend.

Beachte nur, dass sich die configs und der dialplan bei zaphfc erheblich von mISDN unterscheiden. Siehe dazu auch die Themen zu DAHDI, chan_dahdi.conf hier und bei http://www.voip-info.org/ (z.B. http://www.voip-info.org/wiki/view/DAHDI )

 

[Larry]

...und hier das korrigierte Archiv; es fehlte noch der Patch für drivers/dahdi/Kbuild, damit das zaphfc-Modul überhaupt miterzeugt wird.
Besten Dank an rentier-s für den Hinweis!

 

[Larry]

damit hat das kompilieren schon mal geklappt.
Mit der "etwas anderen" Konfiguration hattest Du leider recht, ich krieg dahdi nicht konfiguriert.

Moin!

Na immerhin. Zumindest hast Du ja jetzt ein "prinzipiell lauffähiges System"

Geh doch zuerst einmal hin und übernehme meine Daten, damit Du schon mal eine Vorlage hast und zumindest der TE-Modus funktioniert.
Aus den Configs kannst Du dann auch ein bisschen ersehen, waswiewo konfigiert wurde und schaffst es vielleicht dann sogar, die zweite HFC-Karte anzuschmeissen...

Du weisst, dass Du für den NT-Modus der zweiten HFC einen extra NTBA mit gekreuztem Kabel brauchst?
Wirf mal ein Blick auf http://h4des.org/index.php?inhalt=asteriskserver , da ist ein entspr. Schema drin und geht sogar - welch Zufall - auf das Thema "2*HFC TE+NT" ein.

/etc/dahdi/system.conf (TE-Modus):

span=1,1,3,ccs,ami
bchan=1-2
dchan = 3
echocanceller=mg2,1-2
loadzone        = de
defaultzone     = de

/etc/asterisk/chan_dahdi.conf :

[trunkgroups]

[channels]
language=de
switchtype=euroisdn
pridialplan=dynamic
prilocaldialplan=unknown
internationalprefix = 00
nationalprefix = 0
localprefix = VORWAHL_MIT_NULL (z.B. 030)
privateprefix = KOMPLETTE_NUMMER (z.B. 030123456)
unknownprefix =
facilityenable = yes
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
;
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
;echotraining=800
;rxgain=2.0
;txgain=3.0
;
group=1
callgroup=1
pickupgroup=1
mohinterpret=default
mohsuggest=default
;
context=default
immediate=yes
channel => 1-2
callerid = asreceived

Abgehend gewählt wird dann wie folgt:

dial(DAHDI/g1/${EXTEN})

Mit diesen Configs konnte ich, wie bereits im Thread erwähnt, völlig problemlos eine kleine Anzahl von Rufen (rein und raus) durchführen.

 

[Larry]

...dachte mir, wenn ich doch schon mal dabei bin, kann ich ja mal fix den NT-Mode probieren. Ergebnis:

[Jun 29 09:06:05] WARNING[4256]: chan_dahdi.c:14282 process_dahdi: How cool would it be if someone implemented this mode! For now, sucks for you. (line 270)

Besagte line 270 bezieht sich auf den Eintrag signalling in chan_dahdi.conf und lautet signalling=bri_net_ptmp. Also offensichtlich noch nix mit NT-Mode

 

[DonTermi]

Danke für das Thema. Habe ich damit problemlos geschafft die dahdi Treiber inkl. zaphfc zu bauen. Allerdings läuft bei mir dahdi noch nicht rund. Mit der Beispiel Confg /etc/dahdi/system.conf erhalte ich mit

dahdi_cfg -vv

nur den Fehler

dahdi DAHDI_SPANCONFIG invalid argument 22

 

[Larry]

dahdi DAHDI_SPANCONFIG invalid argument 22

Hmmm...kannst Du mal mit lsmod nachschauen, ob dahdi_dummy geladen wurde, und wenn, ob vor oder nach zaphfc?
Sollte dahdi_dummy nämlich VOR zaphfc geladen sein, hast Du ZWEI SPANS - eben einen DUMMY als ersten und den von zaphfc als zweiten. Und den ersten (dummy) Span konfigurieren wird nicht funktionieren...