D channel frame with bad CRC

[*-tuxi]

Hallo Leute,

ich habe gerade meinen Asterisk von 1.0.9 (SUSE 10-Standard) auf v1.2.4 inkl. Florz-Patch upgedatet.
Das Ding startet soweit, und die Funktionen laufen grob gesagt noch ganz gut, trotz meines noch nicht überarbeiteten dialplans.

Nun ist mir aber im Syslog sofort nach Aktivierung folgendes aufgefallen:

Feb 11 11:34:02 sip kernel: zaphfc: jitterbuffer size: 1
Feb 11 11:34:02 sip kernel: ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 7
Feb 11 11:34:02 sip kernel: PCI: setting IRQ 7 as level-triggered
Feb 11 11:34:02 sip kernel: ACPI: PCI Interrupt 0000:02:07.0[A] -> Link [LNKA] -> GSI 7 (level, low) -> IRQ 7
Feb 11 11:34:02 sip kernel: zaphfc: CCD/Billion/Asuscom 2BD0 configured at mem 0xe1108c00 fifo 0xdc348000(0x1c348000) IRQ 7 HZ 250
Feb 11 11:34:02 sip kernel: zaphfc: Card 0 configured for TE mode
Feb 11 11:34:02 sip kernel: zaphfc: Card 0 configured for master mode
Feb 11 11:34:02 sip kernel: ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
Feb 11 11:34:02 sip kernel: PCI: setting IRQ 11 as level-triggered
Feb 11 11:34:02 sip kernel: ACPI: PCI Interrupt 0000:02:0a.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
Feb 11 11:34:02 sip kernel: zaphfc: CCD/Billion/Asuscom 2BD0 configured at mem 0xe1130800 fifo 0xdc378000(0x1c378000) IRQ 11 HZ 250
Feb 11 11:34:02 sip kernel: zaphfc: Card 1 configured for NT mode
Feb 11 11:34:02 sip kernel: zaphfc: Card 1 configured for master mode
Feb 11 11:34:02 sip kernel: zaphfc: 2 hfc-pci card(s) in this box.
Feb 11 11:34:13 sip kernel: Registered tone zone 29 (Germany)
Feb 11 11:34:46 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:35:02 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:35:19 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:35:35 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:35:35 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:35:36 sip sshd[4917]: Accepted keyboard-interactive/pam for root from 172.16.10.50 port 2503 ssh2
Feb 11 11:36:08 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:36:25 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:36:35 sip sshd[4973]: Accepted keyboard-interactive/pam for root from 172.16.10.50 port 2507 ssh2
Feb 11 11:36:41 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:36:58 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:37:14 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:37:31 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:37:38 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:38:10 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:38:26 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:38:43 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:38:59 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:39:16 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:39:33 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:40:06 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:40:22 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:40:39 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 11:40:55 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
[...]
Feb 11 13:00:47 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:01:03 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:01:20 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:01:36 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:01:36 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:02:09 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:02:26 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:02:42 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:02:59 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:03:15 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:03:15 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:03:48 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:04:04 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:04:21 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:04:37 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:04:54 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:05:10 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:05:27 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:05:43 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:06:00 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:06:16 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:06:32 sip kernel: zaphfc[0]: received d channel frame with bad CRC.
Feb 11 13:06:49 sip kernel: zaphfc[0]: received d channel frame with bad CRC.

Ich habe folgendes in dieser Reihenfolge kompiliert und installiert:

- zaptel-1.2.3
- libpri-1.2.2
- zaphfc aus /bristuff-0.3.0-PRE-1l mit florz-patch "zaphfc_0.3.0-PRE-1k_florz-11.diff" von asterisk.li
- asterisk-1.2.4

Dann mit insmod /lib/modules/2.6.13-15-default/misc/zaphfc.ko modes=2 zaptel und zaphfc-KO's geladen.

Dabei kam folgendes heraus (alles okay denke ich):

sip:~ #
sip:~ #
sip:~ #
sip:~ #
sip:~ # ztcfg -vv

Zaptel 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) (Slaves: 01)
Channel 02: Clear channel (Default) (Slaves: 02)
Channel 03: D-channel (Default) (Slaves: 03)
Channel 04: Clear channel (Default) (Slaves: 04)
Channel 05: Clear channel (Default) (Slaves: 05)
Channel 06: D-channel (Default) (Slaves: 06)

6 channels configured.

Changing signalling on channel 1 from Unused to Clear channel
Changing signalling on channel 2 from Unused to Clear channel
Changing signalling on channel 3 from Unused to HDLC with FCS check
Changing signalling on channel 4 from Unused to Clear channel
Changing signalling on channel 5 from Unused to Clear channel
Changing signalling on channel 6 from Unused to HDLC with FCS check
sip:~ #
sip:~ #
sip:~ #
sip:~ #
sip:~ #
sip:~ #
sip:~ # cat /proc/zaptel/
1  2
sip:~ # cat /proc/zaptel/1
Span 1: ZTHFC1 "HFC-S PCI A ISDN card 0 [TE] layer 1 ACTIVATED (F7)" AMI/CCS

           1 ZTHFC1/0/1 Clear
           2 ZTHFC1/0/2 Clear
           3 ZTHFC1/0/3 HDLCFCS
sip:~ #
sip:~ #
sip:~ #
sip:~ #
sip:~ # cat /proc/zaptel/2
Span 2: ZTHFC2 "HFC-S PCI A ISDN card 1 [NT] layer 1 ACTIVATED (G3)" AMI/CCS

           4 ZTHFC2/0/1 Clear
           5 ZTHFC2/0/2 Clear
           6 ZTHFC2/0/3 HDLCFCS
sip:~ #
sip:~ #
sip:~ #
sip:~ #
sip:~ #
sip:~ # rczaptel status
Checking for Zaptel                                                   running
sip:~ #
sip:~ #

FRAGE: Wodurch entstehen die Meldungem im syslog? Ist der florz-patch fehlerhaft (das patchen von zaphfc mit florz funktionierte tadellos!) oder eine meiner HFC-Karten im Eimer (sind beide erst vor max. 6 Monate gekauft worden)?

Diese Meldungen hatte ich bei SUSE-1.0.9-Paketen nicht... Allerdings war bei denen natürlich auch kein florz-patch drin...

Wieso steht in den CRC-Fehlermeldungen auch nicht mehr drin, auf welcher Karte ebensolche Fehler entstehen???

Fragen über Fragen, und dann auch noch am Wochenende... Ich hoffe trotzdem, dass jemand, der dazu etwas schreiben kann, dieses posting möglichst schnell findet... ;-)

Danke schon mal,

Michael

 

[lo4dro]

Diese Fehlermeldungf hab ich auch seit bristuff-0.3.0

Ich vermute es liegt an einer etwas schlechten (ungeschirmte) Telefonkabel zwischen Uk0 und Splitter, oder Splitter und NTBA.
Ich werde mal die Leitungen gegen geschirmte Kabeln tauschen.

 

[*-tuxi]

Hi, lo4dro,

Diese Fehlermeldungf hab ich auch seit bristuff-0.3.0

Ich vermute es liegt an einer etwas schlechten (ungeschirmte) Telefonkabel zwischen Uk0 und Splitter, oder Splitter und NTBA.
Ich werde mal die Leitungen gegen geschirmte Kabeln tauschen.

Wie kommst Du auf die Leitungen?

Michael

 

[lo4dro]

Na ja crc Fehler können durch schlechten Leitungen entstehen.

 

[*-tuxi]

Hey,

Na ja crc Fehler können durch schlechten Leitungen entstehen.

hmmm... denke, ich werde das dann mal checken...
Melde mich wieder, wenn ich was neues weiss...

Michael

 

[lumi]

Hallo,


ich habe genau denselben Fehler und auch eine ähnliche Konfiguration wie du.
Allerdings habe ich festgestellt das diese Meldungen nur bei einer Karte kommt. Ich bin mir zwar nicht ganz sicher welche meiner Karten nun welcher Nummer in zaphfc entspricht, aber ich schließe aus der Meldung zaphfc[0] das es die Karte ist die im NT Modus läuft ('mode' Parameter ist auf 1 gesetzt -> 1Karte NT , 2 Karte TE ).

Also meine Theorie ist nun folgende: wenn ich die T-Com an die Karte anschließe die im NT Mode läuft werden diese Einträge erzeugt. Schließe ich sie jedoch an die Karte im TE Modus an ist alles ruhig. Bedeutet also das ich diese Fehler kriege wenn ich ein nicht gekreuztes Kabel an die NT Karte anschließe.

Vielleicht liege ich vollkommen falsch hier. Vielleicht hat dazu ja jemand eine andere Erklärung.

Leider bin ich noch nicht soweit mit meiner restlichen Konfiguration um zu überprüfen ob ich mit dieser Verbindung tatsächlich wählen kann.

tschüss
Jürgen

 

[unclefu]

bei mir hat es geholfen einen NTBA ohne Stromversorgung dazwischen zu schakten und alles läuft fein

 

[kombjuder]

bei mir hat es geholfen einen NTBA ohne Stromversorgung dazwischen zu schakten und alles läuft fein

Warscheinlich hätte eine korrekte Terminierung auch gereicht.
Mit deinem NTBA hast du zumindest einseitig terminiert, das reicht oftmals schon aus.

 

[unclefu]

hmmm...
kurz nachdem ich das geschrieben hatte und ein wenig rumgefullet habe bekomme ich die Fehler wieder.

ich hab 2 Karten:
karte 1 NT
karte 2 TE

Karte 1 hängt an besagtem NTBA alles läuft toll.

wenn ich aber die karte2 mit dem Telekom NTBA fürs ISDN verbinde bekomme ich auf der karte 1 CRC Fehler und die Verbindung bricht ab.

wie geht denn eine ordentliche Terminierung, wenn ich mit dem NTBA nur einseitig Terminiere ?
und was bedeutet einseitig

 

[kombjuder]

wie geht denn eine ordentliche Terminierung, wenn ich mit dem NTBA nur einseitig Terminiere ?
und was bedeutet einseitig

Hallo unclefu,

beidseitig heisst, an jedem Ende mit 100 Ohm terminiert. Wenn du nicht weisst wie das geht, frag mal bei google nach, da gibt es bebilderte Erklärungen.

Einseitig ist nur das eine Ende terminiert.
Wobei bei ISDN kein sternförmiger Anschluss der Geräte zugelassen ist. Eine Anschlußleitung von 2 Metern geht noch durch, mehr kann es kritisch werden.

Wobei ein kaputter Stecker/Buchse oder ein fehlerhaftes Kabel die selben Störungen produzieren kann.

 

[unclefu]

aha, und wie soll ich an der seite der ISDN karte Terminieren,?
soll ich da irgendwo einen Widerstand auflöten?

 

[kombjuder]

aha, und wie soll ich an der seite der ISDN karte Terminieren,?
soll ich da irgendwo einen Widerstand auflöten?

Ich kann nichts für die elektrischen Grundregeln! Ein Bus ist an beiden Enden zu terminieren.

Wenn du deine Hfc-Karte nicht terminieren kannst, musst du halt in der Nähe der Hfc-Karte terminieren, mit einem NTBA zum Beispiel, oder du verwendest eine ISDN-Steckdose mit Terminierung.

 

[unclefu]

ne, war ja nur die frage ob man sowas machen soll...
also zwichen den Pinnen auf der Karte z.B.

 

[frankjung]

bad frame

hdparm -u 1 /dev/hd...
versuche das mal bitte und gucke dann in die messages!
damit stelle ich es ab. das problem taucht aber auch bei
TE auf. ist nicht begrenzt auf NT modus
gruss frank

p.s. http://www.belwue.de/belup.old/ulm/faq/misc/s0_bus12.htm

 

[unclefu]

das bringt bei mir nix, weil der PATA und SATA Controller andere interrupts verwenden...

 

[mha]

dieser crc fehler hat mich nun auch schon eine ganze weile lang ziemlich irre gemacht ... bei mir führte folgendes zur lösung dieses problems :

apt-get --purge remove modutils

Mit der Einführung von Kernel 2.6 hat sich das Format für Treiberoptionen geändert. Früher wurden diese in /etc/modutils/ gespeichert, und das Programm update-modules generierte daraus die Datei /etc/modules.conf. Das funktioniert für Kernel 2.4 auch weiterhin so, für Kernel 2.6 müssen Änderungen aber in /etc/modprobe.d/ vorgenommen werden. Die Informationen können direkt aus diesem Verzeichnis ausgelesen werden. Eine Datei /etc/modprobe.conf wird nicht benötigt und kann sogar zu Problemen führen, denn wenn sie existiert wird der Inhalt von /etc/modprobe.d/ ignoriert. Mehr über das neue Format für die Optionen und auszuführenden Aktionen beim Laden von Modulen verrät die Handbuchseite zu modprobe.conf.