[gelöst] channel_senddata: next_skb exist ERROR (skb->len=8 next_skb->len=8)

Nachdem alles mehrere Tage nahezu bestens funktioniert hatte, habe ich *leider* mal wieder alles "noch besser" machen wollen
Dazu bekam ich am 22.06. nach Aufruf von install-misdn-mqueue aus der mqueue-misdn ein Update von dsp_cmx.c und dsp_core.c . Seitdem höre ich auf dem internen S0 mal gar nichts, mal heftiges knurpseln. Ein Gegenüber hört mich ganz normal, man hört auf dem internen S0 auch, dass der Gegenüber etwas sagt, was aber eben durch heftiges knurpseln übertönt wird - sofern man denn mal überhaupt etwas hört.
Dafür hagelt es jetzt im Syslog channel_senddata: next_skb exist ERROR (skb->len=8 next_skb->len=8 ). Diese Meldung samt leichten knurpseln gabs zwar vorher auch manchmal, wenn man sich internen S0 ein Amt (von Asterisk) genommen hat, was beides aber sofort verschwand, wenn eine Verbindung zum Gegenüber aufgebaut wurde.

Aufbau siehe Thread: http://www.ip-phone-forum.de/showthread.php?t=105817

Ergänzung: Gentoo-Linux 2.6.16-r9 PREEMPT, GCC 4.1.1

@crich: Würde mich gerne für weitere Tests zur Verfügung stellen, da parallel zur Arbeit noch genügend Zeit

Ja, genaugenommen die Richtung interner S0->Asterisk->irgendetwas. Alles andere funktioniert jetzt seit zwei Jahren bestens.
Ich habe vor und nach dem CVS-Update diverse chan-misdn Versionen ausprobiert (0.3.1-rc9, 0.3.1-rc14, 0.4.0-rc2), welche aber eigentlich alle recht gut liefen - bis zum CVS-Update...

Hallo chrich,

einstweilen schon mal danke für die Hilfestellung. Hat was länger gedauert mit meiner Antwort, da "out for business".

D.h. derjenige der am "irgendwas" hängt hört das krächzen ?

Zum Vergrößern anklicken....

Nein. Die akustische Störung liegt nur am intern S0 an, also am mISDN. Ein Gegenüber am SIP-Telefon (egal ob intern oder extern) oder Normal-Telefon (extern) hört mich völlig normal; am intern ISDN-Telefon höre ich gelegentlich gar nix, meist aber eben besagtes knurpseln/krächzen.

versuch mal "bridging=yes" in der misdn.conf zu setzen. Und probier den Fall: ISDN <--> Asterisk <--> ISDN

Zum Vergrößern anklicken....

Der Eintrag stand von Anfang an auf "yes", hatte ihn dann testhalber, nachdem der Fehler auftrat, aber auch mal auf "no" stehen gehabt. Jedenfalls egal wie "bridging" eingestellt ist, bleibt der Fehler der gleiche.
Auch wenn ich das ISDN-Telefon einfach auf eine VoiceMailbox auflaufen lasse, also quasi ISDN<->Asterisk only, höre ich nur krächzen im Telefon. Ich denke, damit man kann sagen, dass der Fehler im Bereich zwischen Telefon und Asterisk zu suchen ist, folglich X-Kabel, NTBA, mISDN, chan-misdn.

Anfangs hatte ich, wie im anderen Thread beschrieben, eine kleine TK-Anlage an der HFC-USB-Karte hängen, wo alles mehrere Tage lang bis zum CVS-Update recht stabil und meist störungsfrei lief. Da die Anlage aber zwei Räume weiter steht und mir die Lauferei zum Telefon zum austesten des Fehlers zu lästig wurde, habe ich (mein einziges) ISDN-Telefon direkt an die HFC-USB-Karte gehangen (ja, es hat eine eigene Stromversorgung, aber den internen NTBA habe ich vorsorglich auch mit Strom versorgt ).

LED am NTBA

Eine Frage am Rande...:
Was ist eigentlich mit der LED am "internen" NTBA? Sollte die nicht irgendwie leuchten, wie es die LED des Amts-NTBA auch macht?

Fragen über Fragen...

Nein die Led des NTBAs leuchtet nur wenn ein UK0 Anschluss dran ist.

Zum Vergrößern anklicken....

Ok, danke für die Info. Man lernt ja nie aus...

Mittlerweile habe ich mal rein vorsorglich den NTBA ausgetauscht: Keine Änderung.
Auserdem gabs am 27.06. eine neues CVS von mISDN, welches ich gestern dann direkt mit chan-misdn-0.3.1-rc15 und 0.4.0-rc3 gestest habe, aber leider auch ohne Verbesserung.
Habe aber gerade gesehen, dass es schon wieder Updates gibt... Mann, seid Ihr fleißig! Werde es gleich mal testen und berichten...

Das HFC-USB-Modul kann ich leider nicht so ohne weiteres tauschen, da es 70,- Euronen kostet, was mir den Aufwand/Kosten nicht lohnt, nur um es auf Verdacht zu tauschen.

*Erfolg* channel_senddata: next_skb exist ERROR (skb->len=

Wie angedroht, habe ich mal wieder upgedated, ohne Erfolg.
Also erst mal Kaffee geholt und Mails aufgearbeitet, da sehe ich doch eine Mail von gestern Abend aus der MailingList von isdn4linux, mit dem Thema hfcsusb and nasty audio, wo James just den gleichen Fehler mit seine HFC-USB hat, wie meiner einer. Jemand anderes gab zur Antwort, seinen jitterbuffer der misdn.conf auf 0 gesetzt zu haben, womit er zumindest einen B-Kanal wieder normal nutzen kann.
Flux meinen jittebuffer von (default) 4000 auf 0 gesetzt und HEY, ein B-Kanal geht wieder völliug normal!!!
Es hagelt in den ersten ein/zwei Sekunden bei Verbindungsaufbau zwar immer noch besagten channel_senddata: next_skb exist ERROR, dann schließt aber der echocancel seine Arbeit ab und der Fehler ist weg.

Die Mail hat leider grausige Zeilenumbrüche, was das lesen etwas schwierig gestaltet, aber soweit ich es bereits jetzt herauslesen kann, ist es ein echter Bug im hfcusb. Wird gerade gepatched und bei Erfolg ins CVS gepackt. Also quasi alles wieder gut!

hab das ganze jetzt mal ausprobiert und konnte den Fehler auch nachstellen. Der Patch von James Harper hat super funktioniert, ich hab ihn jetzt inst mISDN cvs eingechecked.

Also mal mISDN updaten und testen bitte.

Zum Vergrößern anklicken....

Wie per Mail mitgeteilt läuft jetzt wieder alles bestens! Merci!

:groesste: