'cause 34' nach Ausfall der ISDN-Leitung

[speedy1980]

...
== Primary D-Channel on span 4 down
== Primary D-Channel on span 4 up
...

Das ist es bei mir definitiv nicht. Ist immer alles aktiv ohne up/down zwischendurch. Aber bei mir hängt der Asterisk auch direkt am Amtsanschluss.

 

[MicroPhone]

Nope, bei mir auch net - ebenfalls am Amtsanschluss.
Wenn ich debug/verbose auf 9 hab erzaehlt mir der Bristuff ab und an auch ne ganze Menge Bloedsinn, aber nen up/down is net dabei.

 

[speedy1980]

So nach dem Asterisk-Tag bin ich jetzt ein kleines Stück schlauer. Wer auf der Bristuff-Mailingliste mitliest hat es ja schon gesehen. Die neue Erkenntniss: Der qozap Treiber kann mit dem Energiesparmodus (Layer 1 nicht daueraktiv) umgehen bzw. sollte es laut Sourcecode zumindest. Wird providerseitig der Layer 1 deaktiviert sollte der qozap Treiber ihn wieder aktivieren. Es wäre gut wenn alle hier mit dem Problem mal eine Änderung in qozap.c machen (meine Zeilenangaben beziehen sich auf bristuff-0.3.0-PRE-1y-q, bitte anpassen für andere Versionen). Zeile 997 gibts ein "if (debug)" und in der nachfolgenden Zeile ein printk, welches den aktuellen Status ausgibt. Bitte das "if (debug)" auskommentieren. Dann in Zeile 1005 und 1010 jeweils "if (debug > 2)" ebenfalls auskommentieren. Dort wird ausgegeben ob der Layer 1 reaktiviert wurde oder ob das nicht geklappt hat. Dann qozap neu übersetzen und neu laden (logischerweise muss der Asterisk dazu kurz beendet werden). Falls das zu schwierig für jemanden ist kann ich auch nen Patch erstellen.
Dann kommt der schwierige Teil: Abwarten bis der Fehler wieder kommt. Wenn er da ist bitte ich um folgende Ausgaben:
- Asterisk-CLI bei auftreten des Fehlers: zap show channel x (bitte für alle Channels der Gruppe, also minimal 2)
- /var/log/kern.log: Da sind die Ausgaben vom qozap drin
- cat /proc/zaptel/*
Ich hoffe wir kommen damit etwas weiter und der fehlerhaften Stelle näher. Irgendwie muss es doch zu lösen sein.

 

[gentoo_user]

Hallo allerseits,
ich wollte einmal fragen ob es zu diesem Thema etwas neues gibt, vorallem ob das lbo=0 abhilfe geschaffen hat?

Grüsse,
gentoo_user

 

[speedy1980]

Hallo allerseits,
ich wollte einmal fragen ob es zu diesem Thema etwas neues gibt, vorallem ob das lbo=0 abhilfe geschaffen hat?

Grüsse,
gentoo_user

Ja und nein. LBO hilft nicht, zumindest bei mir. Rest siehe Bristuff-Mailingliste. Wäre nett wenn Du Dich dort mal äußerst (obs bei Dir auch so ist) und eventuell den Patch dort austestest.

 

[speedy1980]

So und jetzt frag ich mal die gleiche Frage: Gibts was neues? Wer hat denn mal auf der Bristuff-Mailingliste mitgelesen und den Patch dort ausprobiert? Damit jetzt keiner fragt "wo? was?" hier ein Link:
http://lists.three-dimensional.net/pipermail/bristuff-users/2008-September/000103.html

 

[TomS]

Hi Speedy,

es gibt m.E. wohl verschiedene Gründe für den cause 34-Fehler. Gunnar's Patch hilft für die Fälle, in denen ein B-Kanal mit dem Flag "Call" hängen bleibt. Dies ist z.B. bei meinem 0.4.0-RC3b System nicht der Fall. Bei mir sind alle Flags ordentlich gelöscht wenn ein "cause-34-Problem-Hänger" auftritt.
Ich konnte bisher nur eingrenzen, dass der Fehler (Rauswählen besetzt, reinwählen geht) im Asterisk und nicht im hfc-Modul liegen muß, da ein Neustart des Asterisk-Dienstes zum beheben des Fehlers reicht. Ein Neuladen der HFC-Treiber ist nicht nötig.
Das Changelog zu 0.4.0-RC3c erwähnt leider auch nichts was auf Besserung hindeutet.

Ich bin inzwischen an dem Punkt wieder von 0.4.0 auf die stabile 0.3.0 zurück zu wechseln, da ich das cause-34-Problem im Bristuff nach einem Monat herumsuchens nicht weiter eingrenzen konnte.

 

[DonTermi]

cause 34 - Circuit/channel congestion

Gibt es Neuigkeiten zu diesem Problem?

Ich kann das Problem nur lösen wenn ich einen Anruf von draußen auf meine MSN mache und dann kann ich auch wieder über mein SIP Phone nach draußen ...

Hardware: Junghanns duoBRI mit dahdi trunk Version (wcb4xxp)

 

[speedy1980]

...
Hardware: Junghanns duoBRI mit dahdi trunk Version (wcb4xxp)

Ich glaube Du bist hier falsch. Wir sind im Bristuff Forum und sprechen hauptsächlich über den qozap Treiber aus dem Bristuff Paket.