HFC-Karte mit Dahdi und Asterisk 1.6

robber437

Neuer User
Mitglied seit
12 Jun 2008
Beiträge
27
Punkte für Reaktionen
0
Punkte
0
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...:confused:

Gruß
robber
 
Uups ich hab vergessen zu erwähnen dass ich den HFC-S Chip auf den BilligISDN-Karten, die mit dem zaphfc Modul laufen meine.
 
... Es kursieren zwar diverse Patches aber nichts will so richtig funktionieren...:confused:

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.
 
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.
 
Zuletzt bearbeitet:
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.
 
Zuletzt bearbeitet:
ich hab jetzt einfachmal ganz naiv in der chan_dahdi.c/process_dahdi

bei signalling/bri_cpe_ptmp folgendes gesetzt:

Code:
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 :)
 
Zuletzt bearbeitet:
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
 
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.
 
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
Code:
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
 
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... ;)
 

Anhänge

  • dahdi-linux-svn_zaphfc.tar.bz2
    2.1 MB · Aufrufe: 100
Zuletzt bearbeitet:
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
 
Zuletzt bearbeitet:
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...).
 
Zuletzt bearbeitet von einem Moderator:
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 )
 
...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!
 

Anhänge

  • dahdi-linux-2.2.0_zaphfc.tar.bz2
    42.8 KB · Aufrufe: 223
rentier-s schrieb:
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):
Code:
span=1,1,3,ccs,ami
bchan=1-2
dchan = 3
echocanceller=mg2,1-2
loadzone        = de
defaultzone     = de

/etc/asterisk/chan_dahdi.conf :
Code:
[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:
Code:
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.
 
...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 :(
 
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
 
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... ;)
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.