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

Larry

Neuer User
Mitglied seit
30 Aug 2004
Beiträge
96
Punkte für Reaktionen
0
Punkte
0
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
 
Zuletzt bearbeitet:
D.h die richtung ISDN -> Asterisk -> Telefon (SIP?) ist kaputt ?
 
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...
 
D.h. derjenige der am "irgendwas" hängt hört das krächzen ? und du bist sicher, dass es egal ist ob irgendwas = SIP Phone oder igendwas=ISDN Phone ist ?
 
versuch mal "bridging=yes" in der misdn.conf zu setzen. Und probier den Fall:

ISDN <--> Asterisk <--> ISDN
 
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 ?
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
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. Jedenfalls gibts gerade einen thread in der i4l-liste wegen dieses Problems, evtl. wirds da bald ein weiteres update geben.
 
Nein die Led des NTBAs leuchtet nur wenn ein UK0 Anschluss dran ist.
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! :D
 
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.
 
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.

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

:groesste:
 
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.