HFC-Karte mit Dahdi und Asterisk 1.6

Hallo Alex,

Hallo H./V.,

Ich habe das bis auf chan_mobile, das hier nichtmal vorliegt - wozu braucht man das? - so ähnlich - und kriege seitdem keine Fehlermeldungen mehr...

VG, Alex.

chan_mobile ermöglicht das koppeln eines Handys via Bluetooth. Man kann dann über das Handy Gespräche in Asterisk empfangen und rauswählen. chan_mobile gaukelt dem Handy quasi eine Bluetooth-Freisprecheinrichtung vor (Hands-Free-Profile). So eine Art GSM-Gateway für Arme, was für mich ( ;-) ) aber hinreichend gut funktioniert.

chan_mobile ist (war?) Bestandteil der Asterisk-Addons.

Gruss,
H.
 
Ah, das ist bei Ubuntu im separaten Paket asterisk-mobile vorhanden! THX - es geht weiter mit Basteln! :)
 
@horatio: Für mich sind die tools, insbesondere dahdi_test sehr aufschlussreich, da mir dadurch erst möglich war festzustellen, dass bei mir einfach mal kein Timing ankommt. Hängt davon ab was Du noch dafür tun musst. Nur kompilieren oder portieren? Letzteres wäre es sicher nicht wert.

@alle:

Inzwischen habe ich festgestellt, dass dahdi_test tatsächlich Werte ausspuckt wenn es als erstes geladen wird.

dahdi_scan zeigt mir dann aber auch, dass keine zweite Karte geladen wurde.

Code:
[1]
active=yes
alarms=UNCONFIGURED
description=DAHDI_DUMMY/1 (source: HRtimer) 1
name=DAHDI_DUMMY/1
manufacturer=
devicetype=DAHDI Dummy Timing
location=
basechan=1
totchans=0
irq=0

Könnte mir jemand einen Tipp geben, wie ich die dahdi/system.conf umzukonfigurieren habe, dass dahdi_dummy auf 1 ist, meine hfc-s auf zwei und meine Karte dahdi_dummy als Timer nutzt? Ich glaube da liegt irgendwie noch mein Fehler.

So sieht es momentan aus:

Code:
loadzone<------>= de                                                            
defaultzone<--->= de                                                            
span=1,1,3,ccs,ami                                                              
bchan=1,2                                                                       
dchan=3

Ich habe jetzt schonmal alle Kombinationen von span ausprobiert, irgendwie muss ich gestehen verstehe ich den Hintergrund wohl nicht ganz und genconf erzeugt mir nur spanlose Dateien.

Stefan
 
Hallo Stefan,

dahdi_test tut es bei mir, python-skripte sind dahdi_genconf, dahdi_hardware und noch ein paar andere. Ich denke dass der Porting-Aufwand für python zumindest nicht gering sein dürfte... mal sehen.

Dass dahdi_scan bei Dir überhaupt keine dahdi-karte anzeigt ist eigenartig, bist Du sicher dass der zaphfc-treiber korrekt geladen wurde? dahdi_scan sollte eigentlich unabhängig von den dahdi-config-files sein, es such wohl direkt nach der Hardware... Bei mir spuckt dahdi_scan jedenfalls auch dann Infos über die vorhandene Hardware aus wenn dahdi_cfg die noch nicht konfiguriert hat.

Meine Experimente (siehe auch einige Posts zuvor) hatten ergeben dass die Reihenfolge die dahdi_scan ausgibt von der Reihenfolge der geladenen Kernel-Module abzuhängen scheint. Wenn Du also dahdi_dummy vor zaphfc lädst, ist dahdi_dummy [1] sonst eben andersrum. Die system.conf muss dann insoweit angepasst werden dass die erste Ziffer hinter "span=" auf die Nummer der Karte aus dahdi_scan gestetzt wird. Alles andere kannst Du so lassen, insbesondere die channels (dchan, bchan) da dahdi_dummy keine Channels anzulegen *scheint*.

Das alles ohne Gewähr, da ich die Sachen mehr oder weniger durch Versuch-und-Irrtum rausgefunden habe, vernünftige Doku dazu ist mir noch nicht untergekommen. Durchaus möglich dass es sich bei Dir anders verhält. Wie schon zuvor erwähnt sitze ich auf etwas spezieller Hardware...

Gruss,
H.
 
Hallo horatio,

Du hast recht (Ich werde alt :doof:), zaphfc war nicht geladen.
War wohl gestern doch etwas viel, und ich hab schon die ganzen Quellen debuggt. :blonk:

Also erstmal gute Nachricht, mit neuen gepatchten ebuilds dahdi 2.2.1 und dahdi tools 2.2.1 bekomme ich es hin wenn ich ein paar mal wie wild die module lade und entlade eine Antwort von dahdi_test zu bekommen. dahdi_dummy ist bei dahdi_scan dabei nun auf der ersten Stelle und die karte auf der zweiten.

Asterisk meckert nun auch nicht mehr über eine Fehlkonfiguration.

Ich werde nun testen ob es nun auch das Telefonieren geht und berichten.
Danach versuche ich es stabil zu machen.

Nochmal zusammengefasst, alles mit ebuilds unter Gentoo, neuester Kernel + 64 Bit! Das ist das erste mal, dass das Timing bei mir geht, aber noch nicht zu früh gefreut...

Stefan
 
Ich brauche doch noch einmal Eure Hilfe.

dahdi_scan zeigt mir nun:

Code:
[1]
active=yes
alarms=UNCONFIGURED
description=DAHDI_DUMMY/1 (source: HRtimer) 1
name=DAHDI_DUMMY/1
manufacturer=
devicetype=DAHDI Dummy Timing
location=
basechan=1
totchans=0
irq=0
type=digital-
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=
framing_opts=
coding=
framing=
[2]
active=yes
alarms=UNCONFIGURED
description=HFC-S PCI A ISDN card 1 [TE]
name=ZTHFC1
manufacturer=
devicetype=
location=
basechan=1
totchans=3
irq=0
type=digital-
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=AMI
framing_opts=CCS
coding=
framing=

Das sieht schonmal gut aus. Auch dahdi_test geht, dahdi_scan, dahdi_speed.

Nun möchte ich den dahdi Dienst neu starten bekomme aber immer nur:

Code:
* Stopping DAHDI...                                                                            [ ok ]
* Starting DAHDI...
DAHDI_SPANCONFIG failed on span 1: Invalid argument (22)

Ich werde das Gefühl nicht los, das liegt an der system.conf. Die ist unverändert:

Code:
loadzone        = de
defaultzone     = de
span=1,1,3,ccs,ami
bchan=1,2
dchan=3

Hat jemand da einen Tipp für mich. Im Grunde ist es nun doch wieder die gleiche Frage wie in meinem vorletzten Post.

Vielen Dank für Eure Hilfe
 
Hi Stefan,

probier in der system.conf mal:
Code:
...
span=2,1,3,ccs,ami
...

Wie schon erwähnt, musst die erste Ziffer des span mit der Nummer der Dahdi-Karte aus dem dahdi_scan übereinstimmen. Ist lt. Deinem dahdi_scan-output [2], dahdi_dummy liegt auf [1].

H.
 
Hallo horatio,

ich Danke Dir, das hat funktioniert. Ich bin jetzt sehr sehr nah am Ziel.
Wenn alles läuft werde ich dann mal alles zusammenschreiben.

Ich kann leider immer noch keine Anrufe annehmen oder absetzen.
Die asterisk logs sagen mir:

Code:
[Jan 24 13:56:34] WARNING[3232] chan_dahdi.c: Unable to specify channel 1: No such device or address
[Jan 24 13:56:34] ERROR[3232] chan_dahdi.c: Unable to open channel 1: No such device or address
here = 0, tmp->channel = 1, channel = 1
[Jan 24 13:56:34] ERROR[3232] chan_dahdi.c: Unable to register channel '1-2'

Ich vermute, dass das jetzt eventuell an meiner chan_dahdi.conf liegen könnte. Könnte eventuell jemand nochmal einen Blick darauf werfen?
Ich habe schon einiges ausprobiert aber bin nicht sicher ob ich noch etwas hinzufügen muss was den channel der Karte angibt.

Code:
[trunkgroups]                                                                                                                                
                                                                                                                                             
[channels]                                                                                                                                   
language=de                                                                                                                                  
switchtype=euroisdn                                                                                                                          
                                                                                                                                             
pridialplan=dynamic                                                                                                                          
prilocaldialplan=unknown                                                                                                                     
internationalprefix = 00                                                                                                                     
nationalprefix = 0                                                                                                                           
;localprefix = 030                                                                                                                           
;privateprefix =.                                                                                                                            
unknownprefix =.                                                                                                                             
                                                                                                                                             
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=default                                                                                                                              
channel => 1-2

Stefan
 
Hi Stefan,

hm, schwer zu sagen. Finde die chan_dahdi.conf generell etwas kryptisch, deshalb weiss ich nicht ob einige Einträge die in Deiner "fehlen" (im Gegensatz zu meiner, siehe Post #93) vielleicht wichtig sind. Im Zweifel mal copy-pasten...

Ansonsten: was spuckt dahdi_cfg -vvv bei Dir aus? Meldet dass Dir vielleicht schon Fehler beim Konfigurieren der Karte?

H.
 
Hallo Horatio,

ich habe jetzt Deine Config, aber gleiches Problem.

dahdi_cfg -vvv sagt:

Code:
DAHDI Tools Version - 2.2.1

DAHDI Version: 2.2.1
Echo Canceller(s): OSLEC
Configuration
======================

SPAN 1: CCS/ AMI Build-out: 399-533 feet (DSX-1)

Channel map:

Channel 01: Clear channel (Default) (Echo Canceler: none) (Slaves: 01)
Channel 02: Clear channel (Default) (Echo Canceler: none) (Slaves: 02)
Channel 03: D-channel (Default) (Echo Canceler: none) (Slaves: 03)

3 channels to configure.

Changing signalling on channel 1 from Unused to Clear channel
Setting echocan for channel 1 to none
Changing signalling on channel 2 from Unused to Clear channel
Setting echocan for channel 2 to none
Changing signalling on channel 3 from Unused to HDLC with FCS check
Setting echocan for channel 3 to none

module load chan_dahdi.so sagt mir:

Code:
Unable to load module chan_dahdi.so
Command 'module load chan_dahdi.so' failed.
[Jan 24 16:08:40] WARNING[3264]: pbx.c:5067 ast_register_application2: Already have an application 'DAHDISendKeypadFacility'
  == Parsing '/etc/asterisk/chan_dahdi.conf':   == Found
  == Parsing '/etc/asterisk/users.conf':   == Found
[Jan 24 16:08:40] WARNING[3264]: chan_dahdi.c:2121 dahdi_open: Unable to specify channel 1: No such device or address
[Jan 24 16:08:40] ERROR[3264]: chan_dahdi.c:10040 mkintf: Unable to open channel 1: No such device or address
here = 0, tmp->channel = 1, channel = 1
[Jan 24 16:08:40] ERROR[3264]: chan_dahdi.c:16002 build_channels: Unable to register channel '1-2'

Ich habe das Gefühl, der will channel 1-2 von meiner ersten Karte, aber das ist dahdi_dummy und geht nicht. Kann das sein?
 
Hallo Stefan,

diese Diskrepanz war mir auch schon einmal aufgefallen (dahdi_scan sagt das die karte auf span 2 liegt, dahdi_cfg behauptet aber es ist span 1), siehe auch mein Post mit den ganzen configs.
Meiner Erfahrung nach steigt dahdi_cfg aber komplett aus wenn man versehentlich versucht dahdi_dummy zu konfigurieren (vielleicht versuchst Du mal die Gegenprobe und setzt den span in der system.conf wieder auf 1 bevor Du dahdi_cfg aufrufst). Ich gehe also mal davon aus dass nur die Ausgabe in dahdi_cfg falsch ist und in Wirklichkeit span 2 gemeint ist. Ich konnte das bei mir verifizieren indem ich vor und nach dahdi_cfg ein dahdi_scan ausgeführt habe. Wenn man die vergleicht sieht man was dahdi_cfg wie konfiguriert hat.

Ansonsten bleibt nur alles nochmal durchzuturnen und zu kucken ob irgendwo was ungewöhnlich ist...
Steht vielleicht was im syslog (dmesg) wenn Du zaphfc lädst was auf ein Problem hindeuten könnte? Oder wenn Du dahdi_cfg aufrufst? Wie in meinem alten Posting schon mal geschrieben, tauchen da bei mir irgendwelche buffer over-/underruns auf, was schon auf ein Problem in den Treibern schließen lässt... und wenn das sowas wie eine Race-condition oder fehlendes locking ist, dann können die Effekte auf unterschiedlichen Maschinen natürlich recht verschieden sein... nur so'n Schuss ins blaue...
Falls Du Dir die Mühe machen willst kannst Du nochmal posten was Du genau für Schritte machst und wie die jeweiligen Ausgaben aussehen. Also vom Laden der Kernel-Treiber über dahdi_cfg bis zum Laden von chan_dahdi in Asterisk.

H.
 
Hallo Leute,

bin Neuling hier im Forum und auch nachdem ich tagelang gesucht (und teilweise gefunden) habe, komme ich kein Stück mehr weiter. Hoffe aber, es fehlt nicht viel!

Hier meine Konfiguration:
Asterisk 1.6.2.0, 2 x HFC Cologne Chip, mehrere SIP fones, etc.
HFC Karte #0 am ISDN-Privider (ehem Arcor)

Alles funzt soweit – kann ohne Störung stabil via ISDN von/nach „draussen“ telefonieren. SIP fones und andere Provider (SipGate) gehen auch wie gewünscht.

„Was will Sie denn noch?“ werdet ihr fragen.

Banal: ein ganz einfaches ISDN Fone an der HFC Karte #1 ans Laufen bringen.

NTBA inkl. Stromversorgung ist via Cross-over Strippe an der Karte #1. ISDN Fone am NTBA

Das ISDN Fone tut keinen Mucks. Asterisk zuckt nicht einmal, wenn ich am ISDN Fone irgendetwas (Amtsholung) mache.

Wenn ich die Group #2 per DIAL anwähle, erhalte ich vom Asterisk die Fehlermeldung

app_dial.c:1745 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 34 - Circuit/channel congestion)

Ich komme nicht weiter und kann mir aber nicht vorstellen, dass ich weitab vom Ziel bin.

Sicher, HFC#0 ist im TE, HFC#1 ist im NT Mode. Kernelmodul „zaphc modes=2“ geladen.

Hier ist, was ich noch nicht verstanden habe: Dem ISDN Fone muss ich eine MSN (oder mehrere) zuweisen. Woher weis der Asterisk, welche MSN's es gibt? Einfach über den DIAL Befehl??

Ich mag nicht aufgeben.

Hier einige Konfigurationsfiles bzw wichtige Info's:
charon:/etc/asterisk # dahdi_hardware
Code:
pci:0000:00:08.0     zaphfc-      1397:2bd0 HFC-S ISDN BRI card
pci:0000:00:09.0     zaphfc-      1397:2bd0 HFC-S ISDN BRI card
charon:/etc/asterisk # dahdi_cfg -vv
Code:
DAHDI Tools Version - 2.2.1

DAHDI Version: 2.2.1
Echo Canceller(s): OSLEC
Configuration
======================

SPAN 1: CCS/ AMI Build-out: 399-533 feet (DSX-1)
SPAN 2: CCS/ AMI Build-out: 399-533 feet (DSX-1)

Channel map:

Channel 01: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 01)
Channel 02: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 02)
Channel 03: D-channel (Default) (Echo Canceler: none) (Slaves: 03)
Channel 04: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 04)
Channel 05: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 05)
Channel 06: D-channel (Default) (Echo Canceler: none) (Slaves: 06)

6 channels to configure.

Setting echocan for channel 1 to oslec
Setting echocan for channel 2 to oslec
Setting echocan for channel 3 to none
Setting echocan for channel 4 to oslec
Setting echocan for channel 5 to oslec
Setting echocan for channel 6 to none

charon*CLI> dahdi show status
Code:
Description                              Alarms  IRQ    bpviol CRC4   Fra Codi Options  LBO
HFC-S PCI A ISDN card 0 [TE] layer 1 AC  OK      0      0      0      CCS AMI  YEL      399-533 feet (DSX-1)
HFC-S PCI A ISDN card 1 [NT] layer 1 AC  OK      0      0      0      CCS AMI  YEL      399-533 feet (DSX-1)
Wahrscheinlich liegt aber hier irgendetwas im Argen:
charon:/etc/asterisk # cat chan_dahdi.conf
Code:
[trunkgroups]
[channels]
language=de
switchtype=euroisdn
pridialplan=dynamic
;prilocaldialplan=unknown
internationalprefix = 00
nationalprefix = 0
localprefix = 0511
privateprefix = 0511123456
unknownprefix =
facilityenable = yes
signalling = bri_cpe
; 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
signalling = bri_cpe
immediate=yes
channel => 1-2
callerid = asreceived

group = 2
context=default
signalling = bri_net_ptmp
channel => 4-5



charon:/etc/asterisk # cat ../dahdi/system.conf
Code:
span=1,1,3,ccs,ami
bchan=1-2
dchan=3
span=2,1,3,ccs,ami
bchan=4-5
dchan=6
echocanceller=oslec,1-2,4-5
loadzone        = de
defaultzone     = de


In der extensions.conf steht u. a. ein
exten => 2002,1,Dial(DAHDI/g2/INT_MSN,30)
wobei INT_MSN die dem ISDN Fone zugewiesene MSN ist.

Über ein beliebiges, anderes SIP Fone wähle ich die 2002 an. Dann kommt die "Congestion" Fehlermeldung. Setze ich in o. g. DIAL Kommando den Channel auf "g1" und die Nummer auf meine (externe) MSN, wählt der brave Asterisk brav über meinen Provider 'raus - wie es sich gehört....

Sorry für dieses lange posting, aber ich weis mir sonst keinen Rat mehr – aber ich denke auch, dass meine Frage zum Thread-Thema passt.

Vielen Dank!!
Wilhelmine
 
Zuletzt bearbeitet:
@Wilhelmine:

Womit hast Du dahdi denn gepatcht um zaphfc zum Laufen zu bekommen und auf welcher Distribution läuft das alles. Und aus eigenem Interesse, was ist es für eine Maschine? (32 /64 Bit?)

Soweit ich weiss funktionieren die zaphfc patches die ich nutze garnicht im NT Modus, genau mit den Problemen, von denen Du sprichst.

Ich bekomme leider nur nicht einmal hin überhaupt rein/oder rauszuwählen.

Kleiner Tipp noch, ich finde es übersichtlicher wenn man Auszüge aus Configs in code blöcke stellt. ;)

@ horatio, ich bin dabei alles noch einmal zu überprüfen, jedoch sieht alles bei mir sehr sauber aus bis auf das bekannte problem bei chan_dahdi.

dmesg sagt auch nichts auffälliges:

Code:
dahdi: Telephony Interface Registered on major 196
dahdi: Version: 2.2.1
dahdi_transcode: Loaded.
dahdi_echocan_oslec: Registered echo canceler 'OSLEC'
dahdi_dummy: Trying to load High Resolution Timer
dahdi_dummy: Initialized High Resolution Timer
dahdi_dummy: Starting High Resolution Timer
dahdi_dummy: High Resolution Timer started, good to go
zaphfc: jitterbuffer size: 1
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 18
pci 0000:01:07.0: PCI INT A -> Link[LNKD] -> GSI 18 (level, low) -> IRQ 18
zaphfc: CCD/Billion/Asuscom 2BD0 configured at mem 0x110d4800 fifo 0x2e9b0000(0x2e9b0000) IRQ 18 HZ 1000
zaphfc: Card 0 configured for TE mode
zaphfc: Card 0 configured for master mode
zaphfc: 1 hfc-pci card(s) in this box.

Wenn ich in system.conf span=1,1,3,ccs,ami statt span=2,1,3,ccs,ami dann bekomme ich den Fehler in der letzten Zeilde der Ausgabe, alles andere bleibt gleich:

Code:
DAHDI Tools Version - 2.2.1

DAHDI Version: 2.2.1
Echo Canceller(s): OSLEC
Configuration
======================

SPAN 1: CCS/ AMI Build-out: 399-533 feet (DSX-1)

Channel map:

Channel 01: Clear channel (Default) (Echo Canceler: none) (Slaves: 01)
Channel 02: Clear channel (Default) (Echo Canceler: none) (Slaves: 02)
Channel 03: D-channel (Default) (Echo Canceler: none) (Slaves: 03)

3 channels to configure.

DAHDI_SPANCONFIG failed on span 1: Invalid argument (22)
 
Hallo sflemming,

hier die gewünschten Info's:

"Normaler" 32 bit intel (irgendein altes Billig-komplett-Teil fuer 200,- EUR) mit 2GB RAM

Neueste SuSE 11.2 32 bit drauf, inkl Kernel src und Compilerumgebung. Nun wurd's ja interessant.
- Neueste Asterisk 1.6.2 vom *.org
- Die DAHDI Linux
- DAHDI Tools (Achtung: den Komplett tarball habe ich ums Verrecken nicht sauber compiliert bekommen - beide einzeln liefen wie geölt)
- LibPRI

Den Patch "dahdi-linux-2.2.0.2_zaphfc.tar" aus diesem Thread hier auf den "linux" Teil appliziert -> Ohne Mucken
Asterisk configured mit --with-dahdi=path_to_patched_dahdi_linux

make, make install. usw.

Ja und das wars eigentlich. Bevor der Asterisk gestartet wird, muessen ja die kernelmodule dahdi, zaphfc modes=2 und ggfs ein echocanceller geladen werden. Modprobe war mein Freund.

Mehr war eigentlich nicht notwendig (sagt sich so schön, hat schon ein paar tage gedauert, weil ich in etliche Sachgassen gelaufen bin :) )

Ist hier jemand der bestätigen kann, dass das wie oben beschrieben gepatchte zaphfc den NT mode nicht unterstützt??

Dann kann ich das Basteln nämlich beenden.... :-( was schade wäre...

Danke fürs Lesen.

Ciao
Wilhelmine
 
Hallo alle,

unter http://www.gsurf.de/typo3temp/pics/582a67d8ea.jpg habe ich exakt das gefunden, was ich mit den 2 HFC Karten hier vorhabe. Dort http://www.gsurf.de/index.php?id=30 wird jedoch die Verwendung von mISDN vorausgesetzt.

Meine Frage: Hat dies jemand mit der hier beschriebenen Kombination bestehend aus dem Patch und den 2 HFC Karten geschafft? Falls "ja", dann wäre ich sehr an ein paar Tips interessiert, denn ich weis nicht mehr weiter... :confused:

Herzlichen Dank!
Wilhelmine
 
Ist hier jemand der bestätigen kann, dass das wie oben beschrieben gepatchte zaphfc den NT mode nicht unterstützt??
Ja, ICH kann es Dir bestätigen...geht mit den hier beschriebenen Patches für zaphfc definitiv nicht.

Dann kann ich das Basteln nämlich beenden.... :-( was schade wäre...
...kann ich nachvollziehen. Aber wenn Du Zeit und Lust hast, kannst Du gerne mal versuchen, die flammneuen Patches von http://code.google.com/p/zaphfc/ in Betrieb zu nehmen. Vielleicht können die schon den NT-Modus; jedenfalls sind sie gerademal ein paar Wochen alt. Die alten Patches haben nun ja bald schon 1 Jahr auf dem Buckel...
Ich selber habe sie mangels Zeit und freier Hardware noch nicht richtig zum laufen bekommen - heißt, sie kompilieren und laden prima, aber das wars dann auch schon.

-
Larry
 
Zuletzt bearbeitet:
Stefan und meiner einer konzentrieren uns derweil in zahlreichen Mails darauf, die alten Patches (ich nenne sie fürderhin nur noch "alte Patches" oder eben zaphfc - die gaaaanz neuen nennen sich dann vzaphfc) erst einmal *grundsätzlich* zum laufen zu bewegen.
Wobei ich sagen muss, dass sie bei mir auf allen Gentoo/x86-PCs *nie* Schwierigkeiten machen und tadellos laufen. Auspacken, patchen, kompilieren, läuft.
Anders sieht es bei Gentoo/x86_64 aus: Auf meinem "Desktop"-System rennen sie mittlerweile prima und stressfrei, hingegen auf ein und derselben Hardware/Kernel, nur mit einem kleinen und schlanken Gentoo, tun sie nur bei "Schönwetter"...ganz seltsam das.

Den anderen interessierten und fleißigen hier kann ich nur ans Herz legen, erst zaphfc und hiernach alles andere zu laden. Der erste Kartentreiber (auch dahdi_dummy zählt zu den Kartentreibern) legt wohl einen dahdi-Timer an, alle weiteren nicht (oder "huckepack" - man möge mich korrigieren).
dahdi_test prüft dann einen gültigen Timer und wenn dahdi_dummy der erste Kartentreiber ist, erhält man immer prima Werte, egal ob weitere/funktionierende Treiber/Timer vorhanden sind oder nicht.
Außerdem legt sich dahdi_dummy, wenn als erstes geladen, breit und faul auf Span1, was bei weiteren (dahdi-)Konfigurationen berücksichtigt werden muss, obwohl dahdi_dummy ja eigentlich nur für app_meetme benötigt wird (auch hier möge man mich ggf. korrigieren).

Für mich zum schnellen testen hat sich daher folgendes bewährt:
- dahdi/zaphfc bauen
- zaphfc als erstes (oder einziges) laden
- /etc/init.d/dahdi neu starten (ganz wichtig!)
- dahdi_test laufen lassen.

Kommen dann bei dahdi_test keine Werte, kann ich mir alle weiteren Mühen schenken. Werden allerdings Werte ausgegeben, Heureka, kann ich sicher sein, dass auch Asterisk dann tut.

-
Larry
 
Hey Larry,

die alten Patches (ich nenne sie fürderhin nur noch "alte Patches" oder eben zaphfc - die gaaaanz neuen nennen sich dann vzaphfc) erst einmal *grundsätzlich* zum laufen zu bewegen.

Das verstehe ich noch nicht. Die vzaphfc-Module gibt es doch schon ewig. Was ist daran neu? Gleichzeitig kann ich Deine Patches nicht auf die Ubuntu-dahdi-source-Package anwenden (siehe mein Posting #82). Die compilieren aber auch ohne Patches gut - sehen dann allerdings nur so aus als könnten sie funktionieren ;-)

Wodurch wird eigentlich nochmal der Oslec-Echocanceller gebaut? Ist der in den Patches enthalten?

Ich probiere das nochmal nach Deiner letzten Anleitung, sobald ich Zeit finde. Aber ich rechne auch mit einigem Aufwand: Vielleicht muss ich aber auch dahdi-Originalquellen benutzen und das dann vielleicht mit neuen Patches, wenn die alten nicht mehr auf den neuen Quellen funktionieren. Eine andere Idee hätte ich sonst nicht, warum nach dem Patchen das Compilieren nicht mehr funktioniert...

VG, Alex.
 
larry schrieb:
die alten Patches (ich nenne sie fürderhin nur noch "alte Patches" oder eben zaphfc - die gaaaanz neuen nennen sich dann vzaphfc) erst einmal *grundsätzlich* zum laufen zu bewegen.
Das verstehe ich noch nicht. Die vzaphfc-Module gibt es doch schon ewig. Was ist daran neu?
Jein, Du meinst wahrscheinlich das vzaphfc für bristuff. Ich meinte dieses hier.

Gleichzeitig kann ich Deine Patches nicht auf die Ubuntu-dahdi-source-Package anwenden (siehe mein Posting #82)
Da kann ich Dir nichts zu sagen; ich beziehe mich bei den von mir vorgestellten Patches immer nur auf die Original-Sources.

Wodurch wird eigentlich nochmal der Oslec-Echocanceller gebaut? Ist der in den Patches enthalten?
Ist in "meinen" Patches immer enthalten, bzw. mit eingebunden. Letztlich ein billiger Trick: Man nehme die Dateien aus /usr/src/linux/drivers/staging/echo und lege sie in /pfad/zu/dahdi-linux-2.2.0.2/drivers/staging/echo/ ab. Danach noch in /pfad/zu/dahdi-linux-2.2.0.2/drivers/dahdi/Kbuild die folgenden Zeilen entkommentieren/ergänzen:
Code:
obj-m += dahdi_echocan_oslec.o
obj-m += ../staging/echo/echo.o
...und fertig.

[...] Vielleicht muss ich aber auch dahdi-Originalquellen benutzen und das dann vielleicht mit neuen Patches, wenn die alten nicht mehr auf den neuen Quellen funktionieren. Eine andere Idee hätte ich sonst nicht, warum nach dem Patchen das Compilieren nicht mehr funktioniert...
Frag doch mal Frau Google. Ich meine mich erinnern zu können, dass es für Ubuntu bereits fertige dahdi-Pakete mit dem neuen vzaphfc gibt...

-
Larry
 
Hallo zusammen,

danke (besonders an Larry) für die detallierteren Beschreibungen Eurer Setups. Habe mal versucht mein Setup ohne dahdi_dummy zum Laufen zu bringen, da scheitert dann tatsächlich der dahdi_test wieder... ich habe nicht so ganz gerafft was dahdi_test eigentlich testet? Geht es da nicht um timing accuracy? Versucht der die ISDN-Zeit der Vermittlungsstelle auszulesen?

Komme also nicht wirklich weiter. Mein Verdacht ist - da ich als einziger diese buffer under-/overflows zu haben scheine - dass der gegenwärtige Patch nicht mit *zwei* HFC-"Karten" (in meinem Fall Chips) zurecht kommt, kann das sein? Irgendein Problem mit inkorrektem locking im zaphfc-Treiber?
Da der NT-Modus ja mit diesen Treibern nicht funktioniert, gehe ich mal nicht davon aus dass das jemand von Euch es schon mal mit zwei Karten probiert hat, oder?
Wie gesagt es handelt sich in meinem Fall *nicht* um einen dual-port chip, sondern tatsächlich um zwei separate hfc-s chips... warumauchimmer das so gelöst wurde... und deaktivieren liesse sich der zweite chip leider nur mit dem Lötkolben, fürchte ich... also nix was ich ausprobieren möchte...

Vielleicht versuche ich mich mal an den vzaphfc-treibern, danke für den Hinweis.

Danke & Gruss,
H.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,839
Beiträge
2,219,264
Mitglieder
371,543
Neuestes Mitglied
Brainbanger
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.