HFC-Karte mit Dahdi und Asterisk 1.6

[Larry]

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?

Fast richtig. Guckst Du.

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?

Du hast Dein Szenario doch mal beschrieben...ist das nicht die HorstBox (oder so)? Aber: Guter Einwand von Dir. Zwei gleichzeitge HFC-S Karten habe ich auch noch nie getestet. Da ich hier aber derzeit mit zaphfc/x86_64 auch nicht weiterkomme, werde ich das just-for-fun die Tage mal in meine Testkiste werfen...

Wie gesagt es handelt sich in meinem Fall *nicht* um einen dual-port chip, sondern tatsächlich um zwei separate hfc-s chips

Hmmm...kommst Du irgendwie an die PCI-IDs der Chips dran? Würde ich mir gerne mal anschauen...

Vielleicht versuche ich mich mal an den vzaphfc-treibern

Ja, gerne, mach das. Wir sind alle schon jetzt ganz Ohr

-
Larry

 

[horatio42]

Hallo Larry,

Fast richtig. Guckst Du.

Über diese Manpage war ich auch schon gestolpert, aber diese ganze DAHDI-Timing-Kiste ist mir alles andere als klar.
Was ich bis jetzt glaube verstanden zu haben: Asterisk benötigt für einige seiner Module Echtzeit-Timer (z.B. app-meetme). *Eine* Möglichkeit ist dahdi_dummy, der einen Channel vortäuscht aber letztlich nur eine solche Timing-Source zur Verfügung stellt. Theoretisch bietet auch zaphfc die Möglichkeit, da ja das ISDN-Netz auch ein Zeitsignal überträgt. Aber das ist schon die erste Stelle wo's bei mir hakt: Lt. dieser Doku zu dahdi's system.conf, kann man für jeden span einstellen ob und mit welcher Priorität er ein Zeitsignal der Vermittlungsstelle übernehmen soll. Wenn ich das richtig verstanden habe, ist mein TE-Span auf "1" einzustellen damit er sich als Slave auf das Zeitsignal des Telcos sync'd. Ist DAS dann der Timer den dahdi_test zu messen versucht? Oder verwechsle ich hier zwei völlig unterschiedliche Sachen? Außerdem: Ist der Timer für dahdi soo wichtig? Lt. obiger Doku dann man schlechte Verbindungsqualität haben wenn das mit dem Zeitsignal nicht klappt, aber was ist wenn gar nix geht (dahdi_test sich nicht muckt)? Oder kann man das dann als "weiteres Symptom" deuten wenn dahdi_test kein Zeitsignal bekommt? Also dass *zumindest* das Zeitsignal gehen muss wenn die Verbindung steht, auch wenn das Zeitsignal von zaphfc selbst nicht unbedingt gebraucht wird?

Asterisk weigert sich jedenfalls zu starten wenn der Timer nicht eingerichtet ist...

Du hast Dein Szenario doch mal beschrieben...ist das nicht die HorstBox (oder so)? Aber: Guter Einwand von Dir. Zwei gleichzeitge HFC-S Karten habe ich auch noch nie getestet. Da ich hier aber derzeit mit zaphfc/x86_64 auch nicht weiterkomme, werde ich das just-for-fun die Tage mal in meine Testkiste werfen...

Danke, vielleicht bringt das ja Licht ins Dunkel. Ja, ich hab in der Tat die Horstbox mit den zwei verlöteten HFC-Chips.

Hmmm...kommst Du irgendwie an die PCI-IDs der Chips dran? Würde ich mir gerne mal anschauen...

Ja, komme ich, hier ist die Info:

# lspci -v
00:0c.0 Network controller: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] (rev 02)
        Subsystem: Cologne Chip Designs GmbH ISDN Board
        Flags: bus master, medium devsel, latency 16, IRQ 24
        I/O ports at 1000 [disabled] [size=8]
        Memory at 48002000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 1
        Kernel driver in use: hfcpci

00:0d.0 Network controller: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] (rev 02)
        Subsystem: Cologne Chip Designs GmbH ISDN Board
        Flags: bus master, medium devsel, latency 16, IRQ 24
        I/O ports at 1008 [disabled] [size=8]
        Memory at 48002100 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 1
        Kernel driver in use: hfcpci

...

(Nicht an dem hfcpci stören, ich habe diesen dump gemacht als ich die mISDN-Treiber geladen hatte...)

Hier noch ein dmesg direkt nach dem Laden von zaphfc.ko:

<4>PCI: enabling device 0000:00:0c.0 (0000 -> 0003)
<6>zaphfc: CCD/Billion/Asuscom 2BD0 configured at mem 0xc4aa6000 fifo 0xc3bd8000(0x3bd8000) IRQ 24 HZ 100
<6>zaphfc: Card 0 configured for TE mode
<6>zaphfc: Card 0 configured for master mode
<4>PCI: enabling device 0000:00:0d.0 (0000 -> 0003)
<6>zaphfc: CCD/Billion/Asuscom 2BD0 configured at mem 0xc4ab0100 fifo 0xc3688000(0x3688000) IRQ 24 HZ 100
<6>zaphfc: Card 1 configured for TE mode
<6>zaphfc: Card 1 configured for master mode
<6>zaphfc: 2 hfc-pci card(s) in this box.

Ja, gerne, mach das. Wir sind alle schon jetzt ganz Ohr

Kein Fortschritt, nirgends. Kompilieren lief zwar einigermaßen glatt von der Hand, aber der Treiber stellt sich ähnlich tot wie Dein Patch. Geräte werden erkannt und sind konfigurierbar, aber dahdi_test schweigt wie ein Grab. Asterisk werde ich noch testen, hab da aber wenig Hoffnung.


Gruss,
H.

 

[Larry]

Über diese Manpage war ich auch schon gestolpert, aber diese ganze DAHDI-Timing-Kiste ist mir alles andere als klar. [...]

Yepp, das kann ich so unterschreiben.
Allerdings - sofern ich das richtig recherchiert und verstanden habe - sind die Timer der Kartentreiber nur vorhanden, wenn die Karte auch tatsächlich einen Timer mitbringt. HFC-S Karten zählen wohl nicht dazu, wohl aber HFC-Mehrport und T1/E1 Karten.

Aaaaaber (und jetzt kommts): :doktor:
Ich bin vorhin über folgende Sites gestolpert:
dahdi support for Collogne Chips PCI HFC-S cards, bzw. [patch] dahdi support for Collogne Chips PCI HFC-S cards (AKA zaphfc) und dazu passend dahdi-base: Add support for core timing.

Im Klartext:
In 'dahdi-linux-2.2.1/include/dahdi/dahdi_config.h' muss "#define
CONFIG_DAHDI_CORE_TIMER" aktiviert werden und schon bekommt vzaphfc auch einen Timer.
dahdi_test läuft jetzt (was auch zu erwarten war), aber Asterisk terminiert mit

[Feb  3 17:32:51] WARNING[2585]: app_dial.c:1745 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 34 - Circuit/channel congestion)

Ein pri show span 1 zeigt auch warum:

Status: Provisioned, Down, Active

L1 ist down und bekommt den Hintern nicht hoch. Warum, ist mir aber völlig unklar.

# lspci -v
00:0c.0 Network controller: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] (rev 02)

Merci, aber ein lspci -vnn wäre ein bisschen Auskunftsfreudiger
In Deiner Angabe fehlen nämlich die eigentlichen PCI-IDs...

Kein Fortschritt, nirgends. Kompilieren lief zwar einigermaßen glatt von der Hand, aber der Treiber stellt sich ähnlich tot wie Dein Patch. Geräte werden erkannt und sind konfigurierbar, aber dahdi_test schweigt wie ein Grab.

Ja, macht aber Sinn - es fehlt uns schlichtweg ein Timer...behaupte ich jetzt einfach mal
Aber probiere doch bitte einmal die Geschichte mit CONFIG_DAHDI_CORE_TIMER, wie oben beschrieben...

-
Larry

 

[horatio42]

Hallo Larry,

...
Im Klartext:
In 'dahdi-linux-2.2.1/include/dahdi/dahdi_config.h' muss "#define
CONFIG_DAHDI_CORE_TIMER" aktiviert werden und schon bekommt vzaphfc auch einen Timer.
dahdi_test läuft jetzt (was auch zu erwarten war), aber Asterisk terminiert mit

[Feb  3 17:32:51] WARNING[2585]: app_dial.c:1745 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 34 - Circuit/channel congestion)

Ein pri show span 1 zeigt auch warum:

Status: Provisioned, Down, Active

L1 ist down und bekommt den Hintern nicht hoch. Warum, ist mir aber völlig unklar.

Bei mir das gleiche Bild. Habe das CONFIG_DAHDI_CORE_TIMER -define gesetzt. Jetzt gibt es zwar auch ohne dahdi_dummy einen timer (dahdi_test gibt Werte zurück), aber das Bild in Asterisk hat sich nicht geändert. Die gleiche Fehlermeldung wie bei Dir (causa 34). Auch die Ausgabe von pri show span sieht bei mir genauso aus.

Merci, aber ein lspci -vnn wäre ein bisschen Auskunftsfreudiger
In Deiner Angabe fehlen nämlich die eigentlichen PCI-IDs...

Undwiederwasdabeigelernt Sorry, und hier der nächste Versuch:

# lspci -vnn
00:0c.0 Network controller [0280]: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] [1397:2bd0] (rev 02)
        Subsystem: Cologne Chip Designs GmbH ISDN Board [1397:2bd0]
        Flags: bus master, medium devsel, latency 16, IRQ 24
        I/O ports at 1000 [disabled] [size=8]
        Memory at 48002000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 1
        Kernel driver in use: vzaphfc

00:0d.0 Network controller [0280]: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] [1397:2bd0] (rev 02)
        Subsystem: Cologne Chip Designs GmbH ISDN Board [1397:2bd0]
        Flags: bus master, medium devsel, latency 16, IRQ 24
        I/O ports at 1008 [disabled] [size=8]
        Memory at 48002100 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 1
        Kernel driver in use: vzaphfc

Ja, macht aber Sinn - es fehlt uns schlichtweg ein Timer...behaupte ich jetzt einfach mal
Aber probiere doch bitte einmal die Geschichte mit CONFIG_DAHDI_CORE_TIMER, wie oben beschrieben...

S.o. Habe beide Modul-Varianten von zaphfc (Dein Patch und vzaphfc) mit dem define probiert, das Verhalten unter Asterisk ist identisch. Einziger Unterschied scheinen die Fehlermeldungen im Syslog zu sein ;-), statt der buffer over- und underruns erhalte ich stattdessen mit vzaphfc:

<6>vzaphfc: HFC-S PCI A ISDN (V1.42) loading                           
<4>PCI: enabling device 0000:00:0c.0 (0000 -> 0003)                    
<6>vzaphfc: card 0: registered ZTHFC1/0/1
<6>vzaphfc: card 0: registered ZTHFC1/0/2
<6>vzaphfc: card 0: registered ZTHFC1/0/3
<6>vzaphfc: card 0: resetting
<6>vzaphfc: card 0 configured for NT mode at mem 0x48002000 (0xc4ac6000) IRQ 24
<4>PCI: enabling device 0000:00:0d.0 (0000 -> 0003)
<6>vzaphfc: card 1: registered ZTHFC2/0/1
<6>vzaphfc: card 1: registered ZTHFC2/0/2
<6>vzaphfc: card 1: registered ZTHFC2/0/3
<6>vzaphfc: card 1: resetting
<6>vzaphfc: card 1 configured for TE mode at mem 0x48002100 (0xc4aca100) IRQ 24
<4>vzaphfc: card 0: chan B1: TX FIFO has become empty
<6>vzaphfc: card 0: chan B1 opened as ZTHFC1/0/1.
<6>vzaphfc: card 0: chan B1 closed as ZTHFC1/0/1.
<4>vzaphfc: card 0: chan B2: TX FIFO has become empty
<6>vzaphfc: card 0: chan B2 opened as ZTHFC1/0/2.
<6>vzaphfc: card 0: chan B2 closed as ZTHFC1/0/2.
<6>vzaphfc: card 0: chan D opened as ZTHFC1/0/3.
<6>vzaphfc: card 0: chan D closed as ZTHFC1/0/3.
<4>vzaphfc: card 1: chan B1: TX FIFO has become empty
<6>vzaphfc: card 1: chan B1 opened as ZTHFC2/0/1.
<6>vzaphfc: card 1: chan B1 closed as ZTHFC2/0/1.
<4>vzaphfc: card 1: chan B2: TX FIFO has become empty
<6>vzaphfc: card 1: chan B2 opened as ZTHFC2/0/2.
<6>vzaphfc: card 1: chan B2 closed as ZTHFC2/0/2.
<6>vzaphfc: card 1: chan D opened as ZTHFC2/0/3.
<6>vzaphfc: card 1: chan D closed as ZTHFC2/0/3.
<6>vzaphfc: card 1: chan B1 opened as ZTHFC2/0/1.
<6>vzaphfc: card 1: chan B2 opened as ZTHFC2/0/2.
<6>vzaphfc: card 1: chan D opened as ZTHFC2/0/3.

Wobei die Meldungen bzgl. leerer FIFOs natürlich auf ein ähnlich gelagertes Problem wie bei dem anderen Modul hindeuten können, muss mir mal die Sourcen genauer ansehen was diese Meldungen triggert...

Danke für Deine Hilfe,
H.

 

[Larry]

Moin!

Bei mir das gleiche Bild. Habe das CONFIG_DAHDI_CORE_TIMER -define gesetzt. Jetzt gibt es zwar auch ohne dahdi_dummy einen timer (dahdi_test gibt Werte zurück), aber das Bild in Asterisk hat sich nicht geändert. Die gleiche Fehlermeldung wie bei Dir (causa 34). Auch die Ausgabe von pri show span sieht bei mir genauso aus.

Aber immerhin scheint der Treiber jetzt schon mal stabil zu laufen, ein Timer ist nun vorhanden und Asterisk startet, ohne zu murren. Ich finde, wir sind nun einen guten Schritt weiter...

Undwiederwasdabeigelernt

Auch dafür sinnwa doch alle hier, nicht?

00:0c.0 Network controller [0280]: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] [1397:2bd0] (rev 02)

Fein. Ist der gleiche Chip, wie der, der hier seit Monaten stabil mit "meinem" alten zaphfc unter x86 läuft. Ich denke, das sind schon mal gute Voraussetzungen.

S.o. Habe beide Modul-Varianten von zaphfc (Dein Patch und vzaphfc) mit dem define probiert, das Verhalten unter Asterisk ist identisch. Einziger Unterschied scheinen die Fehlermeldungen im Syslog zu sein ;-), statt der buffer over- und underruns erhalte ich stattdessen mit vzaphfc:

<4>vzaphfc: card 0: chan B1: TX FIFO has become empty
<6>vzaphfc: card 0: chan B1 opened as ZTHFC1/0/1.
<6>vzaphfc: card 0: chan B1 closed as ZTHFC1/0/1.
<4>vzaphfc: card 0: chan B2: TX FIFO has become empty
<6>vzaphfc: card 0: chan B2 opened as ZTHFC1/0/2.
<6>vzaphfc: card 0: chan B2 closed as ZTHFC1/0/2.
<6>vzaphfc: card 0: chan D opened as ZTHFC1/0/3.
<6>vzaphfc: card 0: chan D closed as ZTHFC1/0/3.
<4>vzaphfc: card 1: chan B1: TX FIFO has become empty
<6>vzaphfc: card 1: chan B1 opened as ZTHFC2/0/1.
<6>vzaphfc: card 1: chan B1 closed as ZTHFC2/0/1.
<4>vzaphfc: card 1: chan B2: TX FIFO has become empty
<6>vzaphfc: card 1: chan B2 opened as ZTHFC2/0/2.
<6>vzaphfc: card 1: chan B2 closed as ZTHFC2/0/2.
<6>vzaphfc: card 1: chan D opened as ZTHFC2/0/3.
<6>vzaphfc: card 1: chan D closed as ZTHFC2/0/3.
<6>vzaphfc: card 1: chan B1 opened as ZTHFC2/0/1.
<6>vzaphfc: card 1: chan B2 opened as ZTHFC2/0/2.
<6>vzaphfc: card 1: chan D opened as ZTHFC2/0/3.

Wobei die Meldungen bzgl. leerer FIFOs natürlich auf ein ähnlich gelagertes Problem wie bei dem anderen Modul hindeuten können, muss mir mal die Sourcen genauer ansehen was diese Meldungen triggert...

Mangels Doku/FAQs können wir da alle nur raten und Vermutungen anstellen.
Ich kann mir auch vorstellen, dass die FIFOs vielleicht aber einfach nur geleert werden, damit nicht noch irgendwelcher Müll drin ist. Daher der Status TX FIFO has become empty... wer weiß?

-
Larry

 

[horatio42]

Hallo Larry und übriges Forum,

ich habe mir mal die sourcen zu vzaphfc angesehen (erscheint mir "sauberer" programmiert als der originale zaphfc source) und da mal die Debug-Ausgaben aktiviert und erweitert.
Habe da ein paar Beobachtungen gemacht die ich gerne teilen würde, vielleicht fällt ja jemandem dazu was ein:

- Wenn man die Debug-Ausgaben aktiviert, erhält man bei einem eingehenden Anruf auf der ISDN-Leitung Ausgaben das (v)zaphtv-kernel-moduls dass das die Leitung ihren state gewechselt hat:

<7>vzaphfc: card 1: layer 1 state = F6
<7>vzaphfc: card 1: layer 1 state = F7
<7>vzaphfc: card 1: layer 1 state = F3
<7>vzaphfc: card 1: FIFOs suspended

Das zaphfc-modul scheint also insoweit schon zu funktioniern. Asterisk reagiert aber selbst im Overkill-Debug-Allewarnungen-An-Modus nicht im geringsten darauf... meine "Theorie" ist, dass der Anruf nicht an Asterisk signalisiert wird, und irgendwo in den Schichten nach oben hängen bleibt (dahdi, chan_dahdi)... hat jemand ein grobes Verständnis dafür wie die Signalisierung funktioniert (funktionieren müsste)? Das dahdi-kernel-modul und asterisks source selbst werden recht schnell unübersichtlich wenn man so gar nicht weiss wonach man sucht...
So wie ich das sehe registriert das vzaphfc-modul seine spans bei dahdi, mir ist aber nicht klar wie es z.B. einen eingehenden Anruf "nach oben" signalisiert? Oder pollt dahdi dann die einmal registrierten spans regelmässig?

- Umgekehrt versucht asterisk schon irgendwelche Statusabfragen ins ISDN-Netz (den D-Channel) zu schicken, aber erhält anscheinend keine Antwort:

Asterisk*CLI> pri intensive debug span 2
Enabled EXTENSIVE debugging on span 2
Sending TEI management message 1, TEI=127

> [ fc ff 03 0f 82 ca 01 ff ]

> Unnumbered frame:
> SAPI: 63  C/R: 0 EA: 0
>  TEI: 127        EA: 1
>   M3: 0   P/F: 0 M2: 0 11: 3  [ UI (unnumbered information) ]
> 5 bytes of data
> MDL Message: TEI Identity Request (1)
> RI: 33482
> Ai: 127 E:1
Sending TEI management message 1, TEI=127

> [ fc ff 03 0f a2 ba 01 ff ]

> Unnumbered frame:
> SAPI: 63  C/R: 0 EA: 0
>  TEI: 127        EA: 1
>   M3: 0   P/F: 0 M2: 0 11: 3  [ UI (unnumbered information) ]
> 5 bytes of data
> MDL Message: TEI Identity Request (1)
> RI: 41658
> Ai: 127 E:1
> 
> ... usw. ...

Auch hier spricht meiner Meinung nach einiges dafür dass etwas in den mittleren Signalisierungsebenen nicht stimmt... aber ich lasse mich auch gerne korrigieren.

Danke & Gruss,
H.

 

[sflemming]

Sehr interessant,

ich habe auch schon einmal in den Source Code geguckt aber bin natürlich nicht auf die Idee gekommen, das mal so zu debuggen.

Interessant wäre jetzt mal zu gucken, was bei funktionierenden Systemen wie (Ubuntu) und Systemen wo es nicht geht (Gentoo) anders läuft.

Wenn sich der Stress etwas legt werde ich da wohl einmal ansetzen.

Stefan

 

[mb75]

gentoo x86_64 (amd64) dahdi zaphfc

Hallo Forum,
könnt ihr mir bitte sagen, ob dahdi zaphfc jetzt unter gentoo x86_64 (amd64 ) geht.
Den bei mir geht es nicht und es sieht so aus als ob die ISDN Leitung nicht hoch kommt ( layer 1 DEACTIVATED)


# cat /proc/dahdi/*

Span 1: DAHDI_DUMMY/1 "DAHDI_DUMMY/1 (source: HRtimer) 1" (MASTER)



Span 2: ZTHFC1 "HFC-S PCI A ISDN card 0 [TE] layer 1 DEACTIVATED (F5)" AMI/CCS



1 ZTHFC1/0/1 Clear (In use) (SWEC: MG2)

2 ZTHFC1/0/2 Clear (In use) (SWEC: MG2)

3 ZTHFC1/0/3 HDLCFCS (In use)

#

 

[sflemming]

Hallo mb75,

so weit ich weiss geht es mit zaphfc auf x86_64 noch nicht.
Wir sind gerade dabei es mit dem vzaphfc zum Laufen zu bekommen.
Die Aussichten sind besser aber es scheint bisher noch nicht neues zu geben.

Ich habe die gleichen Probleme, auch auf gentoo x86_64.

Stefan

 

[Larry]

vzaphfc läuft (Gentoo + Ubuntu)

Gute Nachrichten, Freunde!

Stefan und ich haben durch zahlreiche Tests nun endlich vzaphfc sowohl unter Gentoo-x86, als auch unter Gentoo-x86_64 zum laufen bekommen!

Ein Interim-Test unter Ubuntu-x86 im Februar zeigte, dass es dort bereits funktionierte, unter Gentoo also wohl noch etwas "zu fehlen" schien.
Zwischenzeitlich gab es in Gentoo aber zahlreiche Updates im stable, wie z.B. linux-headers-2.6.30-r1; hiernach und nach Neubau von glibc (wichtig!) lösten sich die Probleme mehr oder weniger alle von selbst.

Ein ganz wichtiger Punkt zeigte sich gestern bei Stefan: Ein Kernel-Modul (ohci1394) belegte den gleichen IRQ wie vzaphfc, was bei Stefan (wohl schon die ganze Zeit) zum berüchtigten "cause 34" führte. Ein entfernen des Kernel-Moduls ohci1394 brachte dann plötzlich den ersehnten Erfolg.

Mit "cause 34" hatte ich hier anfangs auch zu kämpfen, was aber ganz andere Gründe hatte. "cause 34" zeigt sich aber auch bei fehlender/falscher Verkabelung/Terminierung. Es lässt sich also festhalten:

• IRQ der HFC-Karte freihalten
• einwandfreie Verkabelung und ggf. Terminierung der ISDN-Leitung(en)

Die (derzeit) endgültigen vzaphfc-Patches stelle ich gleich gesondert zur Verfügung.

BTW: Spaßeshalber habe ich auch mal den NT-Modus getestet. Im Ein-Karten-Betrieb (NT) funktionierte er (!), nicht aber im Zwei-Karten-Betrieb (TE+NT). Die Karte im TE-Modus lief weiterhin, die Karte im NT-Modus bekam aber den L1 nicht mehr hoch.
Wiesowelshalbwarum habe ich noch nicht nachstellen können/wollen. War nur ein kurzer Test am Rande.

Ich rücke an dieser Stelle vom alten zaphfc Patch-Gedöns ab und arbeite fürderhin nur noch an/um/mit vzaphfc. Somit zähle ich zaphfc als deprecated.

 

[Larry]

vzaphfc Patches (Gentoo + "Solo")

Sodala, anbei die versprochenen Patches/Pakete.

• gentoo-local-portage.tar.bz2 ist für das lokale Gentoo-Portage bestimmt (Ready-to-run)
  ggf. siehe How to use custom ebuilds - digest braucht aber nicht mehr erzeugt zu werden. Habsch für Euch schon gemacht
  Das Asterisk Ebuild enthält noch den NT-PTMP Patch
• oslec-patch_dahdi221.tar.bz2 aktueller Oslec-EC aus Kernel-2.6.32 zum draufpatchen für dahdi-2.2.1 (Non-Gentoo - zum selberbauen/Patchen)
• vzaphfc-oslec-patch_dahdi221.tar.bz2 vzaphfc+Oslec-EC zum draufpatchen für dahdi-2.2.1 (Non-Gentoo - zum selberbauen/Patchen)

Ubuntu habe ich hier nicht berücksichtigt, da es hierfür bereits fertige Pakete in dessen Reposity gibt.

Happy testing, viel Erfolg und schööööönes Wochenende!

-
Larry

 

[sflemming]

Ich kann nach einem Jahr basteln nun wie schon von Larry angekündigt bestätigen, dass es wirklich funktioniert. :dance:

Ich habe jetzt schon die erste Stunde telefoniert und es gab bisher keinerlei Probleme.
Auch die Sprachqualität ist soweit ich es bisher beurteilen kann in Ordnung.

Ich habe mich heute Nacht noch einmal hingesetzt und eine neue extensions.lua geschrieben. Sobald ich fertig bin gibts dann in meinem Blog auch ein Howto dazu.

Wenn alles weiterhin stabil läuft sollten wir dann im nächsten Schritt mal angehen für die Integration der Patches im gentoo bugzilla zu voten.

 

[Larry]

Ich kann nach einem Jahr basteln nun wie schon von Larry angekündigt bestätigen, dass es wirklich funktioniert.
Ich habe jetzt schon die erste Stunde telefoniert und es gab bisher keinerlei Probleme. Auch die Sprachqualität ist soweit ich es bisher beurteilen kann in Ordnung.

Yohoooo! Geile Sache das!

Ich habe mich heute Nacht noch einmal hingesetzt und eine neue extensions.lua geschrieben. Sobald ich fertig bin gibts dann in meinem Blog auch ein Howto dazu.

Fein, da bin ich auch mal gespannt drauf; wieder mal was zum lernen

Wenn alles weiterhin stabil läuft sollten wir dann im nächsten Schritt mal angehen für die Integration der Patches im gentoo bugzilla zu voten.

Damit wir's dann nicht mehr heraussuchen müssen: die Bugs hierzu sind unter dahdi 2.2.0 released - version bump request und net-misc/dahdi - additional card support (tzafrir branch)

-
Larry

 

[sflemming]

Sehr gut, dann sollten wir die Sache noch 2-3 Tage austesten und schleunigst dafür sorgen dass das Werk offiziell wird

Ich hab schonmal angefangen in mein Blog zu posten. Wenn die Zeit da ist werde ich das noch einmal überarbeiten: http://blog.flemming.info/?p=43.

Willst Du auch noch ein Tutorial schreiben, Larry? Wir könnten uns die Arbeit etwas einteilen und Du machst es wieder auf Deutsch und ich auf Englisch? Dann kann man die gegeneinander verlinken.

Wo liegen eigentlich die Quellen genau, ich musste die jetzt gegen die Links im Forum verlinken?

Stefan

 

[sflemming]

Neue Howtos zu hfc-s mit vzaphfc in meinem Blog

Hallo allerseits,

nachdem wir es ja nun endlich hinbekommen haben hfc-s Karten mit dem vzaphfc dahdi setup auf asterisk laufen zu bekommen habe ich daran gesetzt zwei kleine Howtos zu schreiben.

Das erste lautet:

DAHDI hfc-s with vzaphfc Howto for Asterisk 1.6 (Tutorial)

Asterisk & HFC-Karten unter Gentoo (von Larry in Deutsch)

Hier beschreibe ich das gesamte Setup unter Gentoo. Ich habe mich mit Larry darauf geeinigt, dass er die Deutsche und ich die Englische Version schreibe. Es ist jedoch empfehlenswert mal in beide hineinzusehen, da es nicht nur eine einfache Übersetzung ist.

Das zweite Howto lautet:

Debugging a hfc-s dahdi vzaphfc setup

Sollte es Probleme mit dem Setup geben habe ich noch einmal zusammengefasst, wie sich Probleme finden lassen wenn man die mitgelieferten Tools zum Debuggen nutzt.

Ich hoffe, dass Euch die Howtos weiterhelfen. Falls ihr Verbesserungsvorschläge habt schreibt ruhig einen Kommentar.

Das System läuft bei mir nun einige Tage stabil im Dauereinsatz.

Da nun ja alles soweit funktioniert werde ich mich ab jetzt dem Schreiben meines Dialplans in lua widmen. Falls jemand Interesse hat kann er sich gerne anschließen. Meine Produktivlösung läuft derzeit schon unter lua. Howtos gibt es dann auch wieder in meinem Blog auf http://blog.flemming.info.

 

[sflemming]

Hallo,

ich bin es nochmal,
habe einen Request für ein neues dahdi ebuild gepostet:

http://bugs.gentoo.org/show_bug.cgi?id=308099

Falls jemand sic beteiligen oder voten möchte...

Stefan

 

[wildzero]

Wie sieht es copyright mässsig eigentlich mit den sourcen vom vzaphfc grundsätzlich aus? Weil, Ziel müsste sein, den irgenedwann mal in den Dahdi trunk zu bekommen. Sonst wird man den auf ewig immer selbst den kommenden dahdi/kernel Version anpassen müssen (Ich spreche von vielen anderen Asterisk Patches aus Erfahrung) was ein ziemliches PITA ist. Denke mal das größte Problem sind immer noch die Codezeilen von Junghanns? Sind die eigentlich immer noch so divenhaft drauf?

Hier hatte jemand es mal mit dem zaphfc versucht, und ist ganau daran gescheitert:
https://issues.asterisk.org/view.php?id=15736

 

[siluan]

Tolle Arbeit, Glückwunsch !

Mein *, der mir Jahre treue dienste geleistet hat ist von mir gegangen. Also habe ich eine neue Box, ausgerüstet mit je einer AVMFritzcard und einer Billig HFC Karte, aufgesetzt (opensuse 11.2, 2.6.31.12-0.1-default). Capi und Hylafax läuft und ich wollte mal so eben einen neuen * mit Bristuff installieren - Pustekuchen.

Hat jemand das unter den o.g. Bedingungen zum Laufen bekommen ?

Neben Asterisk, lipri und Dahdi-2.2.1 bräuchte ich wohl noch die beiden Non-Gentoo patches. Hab ich was vergessen ? Für jede Hilfe bin ich dankbar.

 

[droemel]

Hallo,

ich habe vzaphfc nun auch mal mit Astlinux trunk (Asterisk-Distribution für embedded Devices, www.astlinux.org) mit Asterisk 1.6.2.6 und Linux-Kernel 2.6.27.38 im TE-Mode getestet. Allerdings vorerst ohne oslec, da das noch für Astlinux angepasst werden muß (Crosscompilation). Die Karte wird erkannt und ich kann rein- und raus-telefonieren (ohne echocan zwar in bescheidener Qualität, aber immerhin).

Allerdings bekomme ich ca. alle 2 Sekunden diese Fehlermeldung:

ERROR[1800]: chan_dahdi.c:12280 dahdi_pri_error: Warning: unknown/inappropriate protocol discriminator received (aa/170)

Hat jemand von Euch diese Meldung schon mal gehabt?
Das Debugging-Tutorial von sflemming hab ich mir schon angesehen.

 

[sflemming]

Hallo droemel,

erst einmal herzlichen Glückwunsch, dass es bei Dir nun auch funktioniert.
Auf was für einer Machine läuft denn das System?

Ich kann Dir bei der Fehlermeldung leider nichts genaues sagen, da sie bei mir noch nie aufgetreten ist. Du könntest aber da Du die Quellen ja schon einmal parat hast gucken wo die Meldung im Quelltext generiert wird.

Wenn Du eine Lösung hast dann sag mal bescheid, ich kann das dann in meine Debugging Anleitung mit aufnehmen,

beste Grüße, Stefan