Re: [suse-isdn] C4, mtg-CAPRI Rufannahme
Hallo Karsten, Karsten Keil <kkeil@suse.de> wrote on 17.05.2006 20:20:55:
On Tue, May 16, 2006 at 06:52:15PM +0200, Christian Wittmer wrote:
Hallo Karsten,
hier das LOG im Anhang. Ich schicke es nur Dir, da ich die Daten nicht an die Liste schicken will.
OK.
1. Um was für einen Anschluss handelt es sich genau ? Es ist ein Anlagen-Anschluß. Der C4 hängt direkt am NTBA.
2. Auswertung: ... May 16 16:44:07 srv-ux-0001 kernel: kcapi: put [0x1] LISTEN_REQ ID=001 #0x0048 LEN=0026 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI =
May 16 16:44:07 srv-ux-0001 kernel: InfoMask = 0x40 May 16 16:44:07 srv-ux-0001 kernel: CIPmask = 0x1fff03ff May 16 16:44:07 srv-ux-0001 kernel: CIPmask2 = 0x0 May 16 16:44:07 srv-ux-0001 kernel: CallingPartyNumber = default May 16 16:44:07 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:44:07 srv-ux-0001 kernel: May 16 16:44:07 srv-ux-0001 kernel: kcapi: got [0x1] LISTEN_CONF ID=001 #0x0048 LEN=0014 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x1 May 16 16:44:07 srv-ux-0001 kernel: Info = 0x0 May 16 16:44:07 srv-ux-0001 kernel: May 16 16:44:07 srv-ux-0001 kernel: kcapi: put [0x2] LISTEN_REQ ID=001 #0x0048 LEN=0026 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x2 May 16 16:44:07 srv-ux-0001 kernel: InfoMask = 0x40 May 16 16:44:07 srv-ux-0001 kernel: CIPmask = 0x1fff03ff May 16 16:44:07 srv-ux-0001 kernel: CIPmask2 = 0x0 May 16 16:44:07 srv-ux-0001 kernel: CallingPartyNumber = default May 16 16:44:07 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:44:07 srv-ux-0001 kernel: May 16 16:44:07 srv-ux-0001 kernel: kcapi: put [0x3] LISTEN_REQ ID=001 #0x0048 LEN=0026 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x3 May 16 16:44:07 srv-ux-0001 kernel: InfoMask = 0x40 May 16 16:44:07 srv-ux-0001 kernel: CIPmask = 0x1fff03ff May 16 16:44:07 srv-ux-0001 kernel: CIPmask2 = 0x0 May 16 16:44:07 srv-ux-0001 kernel: CallingPartyNumber = default May 16 16:44:07 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:44:07 srv-ux-0001 kernel: May 16 16:44:07 srv-ux-0001 kernel: kcapi: put [0x4] LISTEN_REQ ID=001 #0x0048 LEN=0026 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x4 May 16 16:44:07 srv-ux-0001 kernel: InfoMask = 0x40 May 16 16:44:07 srv-ux-0001 kernel: CIPmask = 0x1fff03ff May 16 16:44:07 srv-ux-0001 kernel: CIPmask2 = 0x0 May 16 16:44:07 srv-ux-0001 kernel: CallingPartyNumber = default May 16 16:44:07 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:44:07 srv-ux-0001 kernel: May 16 16:44:07 srv-ux-0001 kernel: kcapi: got [0x2] LISTEN_CONF ID=001 #0x0048 LEN=0014 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x2 May 16 16:44:07 srv-ux-0001 kernel: Info = 0x0 May 16 16:44:07 srv-ux-0001 kernel: May 16 16:44:07 srv-ux-0001 kernel: kcapi: got [0x3] LISTEN_CONF ID=001 #0x0048 LEN=0014 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x3 May 16 16:44:07 srv-ux-0001 kernel: Info = 0x0 May 16 16:44:07 srv-ux-0001 kernel: May 16 16:44:07 srv-ux-0001 kernel: kcapi: got [0x4] LISTEN_CONF ID=001 #0x0048 LEN=0014 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x4 May 16 16:44:07 srv-ux-0001 kernel: Info = 0x0 May 16 16:44:07 srv-ux-0001 kernel:
Applikation 1 schickt an alle 4 Controller einen LISTEN REQ für
0x1 praktisch
alle Anrufe, das ist die capidrv Application für I4L. ...
May 16 16:45:21 srv-ux-0001 kernel: kcapi: put [0x4] LISTEN_REQ ID=002 #0x0001 LEN=0026 May 16 16:45:21 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x4 May 16 16:45:21 srv-ux-0001 kernel: InfoMask = 0x7ff May 16 16:45:21 srv-ux-0001 kernel: CIPmask = 0x10012 May 16 16:45:21 srv-ux-0001 kernel: CIPmask2 = 0x0 May 16 16:45:21 srv-ux-0001 kernel: CallingPartyNumber = default May 16 16:45:21 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:45:21 srv-ux-0001 kernel: May 16 16:45:21 srv-ux-0001 kernel: kcapi: got [0x4] LISTEN_CONF ID=002 #0x0001 LEN=0014 May 16 16:45:21 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x4 May 16 16:45:21 srv-ux-0001 kernel: Info = 0x0 May 16 16:45:21 srv-ux-0001 kernel:
Eine 2. Applikation (ich nehme an der CAPRI Server) schickt auch ein LISTEN, aber nur für Controller Nr. 4
Service: Voice,Audio,Telephonie Das ist so korrekt, denn der User ist laut capri.aut an Conroller 4 gebunden.
May 16 16:45:21 srv-ux-0001 kernel: kcapi: put [0x4] FACILITY_REQ ID=002 #0x0002 LEN=0018 May 16 16:45:21 srv-ux-0001 kernel: Controller/PLCI/NCCI =
0x4
May 16 16:45:21 srv-ux-0001 kernel: FacilitySelector = 0x3 May 16 16:45:21 srv-ux-0001 kernel: FacilityRequestParameter = <00 00 00> May 16 16:45:21 srv-ux-0001 kernel: May 16 16:45:21 srv-ux-0001 kernel: kcapi: got [0x4] FACILITY_CONF ID=002 #0x0002 LEN=0026 May 16 16:45:21 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x4 May 16 16:45:21 srv-ux-0001 kernel: Info = 0x0 May 16 16:45:21 srv-ux-0001 kernel: FacilitySelector = 0x3 May 16 16:45:21 srv-ux-0001 kernel: FacilityConfirmationParameter = <00 00 06 00 00>\377<03 00 00> May 16 16:45:21 srv-ux-0001 kernel:
Die Applikation 2 fragt die supporteten Supplementary Services ab. ... May 16 16:46:01 srv-ux-0001 kernel: kcapi: got [0x4] CONNECT_IND ID=001 #0x0023 LEN=0049 May 16 16:46:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x104 May 16 16:46:01 srv-ux-0001 kernel: CIPValue = 0x1 May 16 16:46:01 srv-ux-0001 kernel: CalledPartyNumber = ?6053911 May 16 16:46:01 srv-ux-0001 kernel: CallingPartyNumber = <21 81>6227385160 May 16 16:46:01 srv-ux-0001 kernel: CalledPartySubaddress = default May 16 16:46:01 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:46:01 srv-ux-0001 kernel: BC = <80 90 a3> May 16 16:46:01 srv-ux-0001 kernel: LLC = <80 90 a3> May 16 16:46:01 srv-ux-0001 kernel: HLC = default May 16 16:46:01 srv-ux-0001 kernel: AdditionalInfo = default May 16 16:46:01 srv-ux-0001 kernel: May 16 16:46:01 srv-ux-0001 kernel: kcapi: got [0x4] CONNECT_IND ID=002 #0x0024 LEN=0049 May 16 16:46:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x104 May 16 16:46:01 srv-ux-0001 kernel: CIPValue = 0x1 May 16 16:46:01 srv-ux-0001 kernel: CalledPartyNumber = ?6053911 May 16 16:46:01 srv-ux-0001 kernel: CallingPartyNumber = <21 81>6227385160 May 16 16:46:01 srv-ux-0001 kernel: CalledPartySubaddress = default May 16 16:46:01 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:46:01 srv-ux-0001 kernel: BC = <80 90 a3> May 16 16:46:01 srv-ux-0001 kernel: LLC = <80 90 a3> May 16 16:46:01 srv-ux-0001 kernel: HLC = default May 16 16:46:01 srv-ux-0001 kernel: AdditionalInfo = default May 16 16:46:01 srv-ux-0001 kernel:
Ein Voice CALL von Controller 4 wird an Appl. 01 und 02 gemeldet
May 16 16:46:01 srv-ux-0001 kernel: capidrv-4: incoming call 6227385160,1,0,6053911 May 16 16:46:01 srv-ux-0001 kernel: kcapi: got [0x4] INFO_IND ID=002 #0x0025 LEN=0023 May 16 16:46:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x104 May 16 16:46:01 srv-ux-0001 kernel: InfoNumber = 0x70 May 16 16:46:01 srv-ux-0001 kernel: InfoElement = ?6053911 May 16 16:46:01 srv-ux-0001 kernel: May 16 16:46:01 srv-ux-0001 kernel: isdn_net: call from 6227385160 -> 3 6053911 ignored May 16 16:46:01 srv-ux-0001 kernel: kcapi: got [0x4] INFO_IND ID=002 #0x0026 LEN=0016 May 16 16:46:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x104 May 16 16:46:01 srv-ux-0001 kernel: InfoNumber = 0x18 May 16 16:46:01 srv-ux-0001 kernel: InfoElement = <89> May 16 16:46:01 srv-ux-0001 kernel:
An Appl 2 gehen noch die Zusatzinfos ueber Nr. und Channel.
May 16 16:46:01 srv-ux-0001 kernel: kcapi: put [0x4] MANUFACTURER_IND ID=002 #0x0000 LEN=0031 May 16 16:46:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x4 May 16 16:46:01 srv-ux-0001 kernel: ManuID = 0x214d5641 May 16 16:46:01 srv-ux-0001 kernel: Class = 0x0 May 16 16:46:01 srv-ux-0001 kernel: Function = 0x1 May 16 16:46:01 srv-ux-0001 kernel: ManuData = <80 08 02 01 01 16>
Hier fehlt was im LOG, wahrscheinlich zuviele LogInfos auf einmal. Es war wahrscheinlich ein CONNECT_RESP der 1. Appl (capidrv) das sie den CALL nicht will.
May 16 16:46:01 srv-ux-0001 kernel: default May 16 16:46:01 srv-ux-0001 kernel: LLC = <80 90 a3> May 16 16:46:01 srv-ux-0001 kernel: AdditionalInfo = default May 16 16:46:01 srv-ux-0001 kernel: May 16 16:46:01 srv-ux-0001 kernel: capidrv-4: incoming call 6227385160,1,0,6053911 ignored May 16 16:46:01 srv-ux-0001 kernel: kcapi: got [0x4] DISCONNECT_IND ID=001 #0x0027 LEN=0014 May 16 16:46:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x104 May 16 16:46:01 srv-ux-0001 kernel: Reason = 0x0 May 16 16:46:01 srv-ux-0001 kernel: May 16 16:46:01 srv-ux-0001 kernel: kcapi: put [0x4] DISCONNECT_RESP ID=001 #0x0027 LEN=0012 May 16 16:46:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x104 May 16 16:46:01 srv-ux-0001 kernel:
Die erste Applikation wird disconnected. ...
May 16 16:46:11 srv-ux-0001 kernel: kcapi: got [0x4] DISCONNECT_IND ID=002 #0x0028 LEN=0014 May 16 16:46:11 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x104 May 16 16:46:11 srv-ux-0001 kernel: Reason = 0x0 May 16 16:46:11 srv-ux-0001 kernel:
Der Call wurde von der anderen Seite aufgelegt und Appl.2 wird disconnected. Andere Seite ist der Anrufer ? Ja, der hat aufgelegt, weil er "Dienst oder Dienstmerkmal nich verfügbar" gehört hat.
... May 16 16:48:01 srv-ux-0001 kernel: May 16 16:48:01 srv-ux-0001 kernel: kcapi: got [0x2] CONNECT_IND ID=001 #0x0029 LEN=0049 May 16 16:48:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x102 May 16 16:48:01 srv-ux-0001 kernel: CIPValue = 0x1 May 16 16:48:01 srv-ux-0001 kernel: CalledPartyNumber = ?6053911 May 16 16:48:01 srv-ux-0001 kernel: CallingPartyNumber = <21 81>6227385160 May 16 16:48:01 srv-ux-0001 kernel: CalledPartySubaddress = default May 16 16:48:01 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:48:01 srv-ux-0001 kernel: BC = <80 90 a3> May 16 16:48:01 srv-ux-0001 kernel: LLC = <80 90 a3> May 16 16:48:01 srv-ux-0001 kernel: HLC = default May 16 16:48:01 srv-ux-0001 kernel: AdditionalInfo = default May 16 16:48:01 srv-ux-0001 kernel:
Ein Voice CALL von Controller 2 wird an Appl. 01 gemeldet, Appliktion 2 nicht, da diese nur auf Controller 4 ein LISTEN abgesetzt hat. Schlecht, da die gerufene Nummer "6053911" ja wirklich auch nur an Controller 4 lauscht. (User ist laut capri.aut mit seiner Rufnummer an Controller 4 gebunden)
May 16 16:48:01 srv-ux-0001 kernel: capidrv-2: incoming call 6227385160,1,0,6053911 May 16 16:48:01 srv-ux-0001 kernel: isdn_net: call from 6227385160 -> 1 6053911 ignored May 16 16:48:01 srv-ux-0001 kernel: isdn_tty: call from 6227385160 -> 6053911 ignored May 16 16:48:01 srv-ux-0001 kernel: kcapi: put [0x2] CONNECT_RESP ID=001 #0x0029 LEN=0031 May 16 16:48:01 srv-ux-0001 kernel: Controller/PLCI/NCCI =
0x102
May 16 16:48:01 srv-ux-0001 kernel: Reject = 0x1 May 16 16:48:01 srv-ux-0001 kernel: BProtocol May 16 16:48:01 srv-ux-0001 kernel: B1protocol = 0x0 May 16 16:48:01 srv-ux-0001 kernel: B2protocol = 0x0 May 16 16:48:01 srv-ux-0001 kernel: B3protocol = 0x0 May 16 16:48:01 srv-ux-0001 kernel: B1configuration = default May 16 16:48:01 srv-ux-0001 kernel: B2configuration = default May 16 16:48:01 srv-ux-0001 kernel: B3configuration = default May 16 16:48:01 srv-ux-0001 kernel: ConnectedNumber = default May 16 16:48:01 srv-ux-0001 kernel: ConnectedSubaddress = default May 16 16:48:01 srv-ux-0001 kernel: LLC = <80 90 a3> May 16 16:48:01 srv-ux-0001 kernel: AdditionalInfo = default May 16 16:48:01 srv-ux-0001 kernel:
Appl. 01 (capidrv) REJECTED den CALL.
Das sieht erstmal so nicht verkehrt aus. Das sehe ich ein. Nach Deiner ausführlichen Erklärung komme ich zu dem Schluß, den Controller über eine TK-Anlage zu schalten. Dann kann ich, wenn ich alles richtig verstanden habe, den kommended Ruf an den richtigen Controller weiterleiten. Dann sollte es doch funktionieren, oder ?
Oder kann ich ein LISTEN der Applikation 1 an allen Controllern verhindern, denn ausreichend wäre doch ein LISTEN der Applikation 2 (CAPRI-Server), denn die setzt ja nur ein LISTEN an Controller 4 ab. Danke für die Hilfe. Gruß Christian
-- Karsten Keil SuSE Labs ISDN development
On Thu, May 18, 2006 at 10:46:31AM +0200, Christian Wittmer wrote:
Hallo Karsten,
Karsten Keil <kkeil@suse.de> wrote on 17.05.2006 20:20:55:
On Tue, May 16, 2006 at 06:52:15PM +0200, Christian Wittmer wrote:
Hallo Karsten,
hier das LOG im Anhang. Ich schicke es nur Dir, da ich die Daten nicht an die Liste schicken will.
OK.
1. Um was für einen Anschluss handelt es sich genau ? Es ist ein Anlagen-Anschluß. Der C4 hängt direkt am NTBA.
OK, dann erklärt das zumindest das Rufnummern Routing. Bei einem Anlagenanschlussbündel kann ein Ruf normalerweise auf jedem Controller mit jeder Nummer reinkommen. Wie sieht die /etc/capi.conf aus ? ... Kannst Du eventuell das Ganze nochmal ohne aktives I4L loggen, das sollte auch die Anzahl der Meldungen reduzieren und Verluste vermeiden: killall isdnlog rmmod capidrv Falls noch andere I4L Dienste aktiv sind muessen die vor dem rmmod auch runtergefahren werden. ...
Appl. 01 (capidrv) REJECTED den CALL.
Das sieht erstmal so nicht verkehrt aus.
Das sehe ich ein. Nach Deiner ausführlichen Erklärung komme ich zu dem Schluß, den Controller über eine TK-Anlage zu schalten. Dann kann ich, wenn ich alles richtig verstanden habe, den kommended Ruf an den richtigen Controller weiterleiten. Dann sollte es doch funktionieren, oder ?
Bei einem Anlagenbündel musst Du immer auf allen Controllern lauschen und spaeter in der Applikation entscheiden ob z.B. die Nummer korrekt ist.
Oder kann ich ein LISTEN der Applikation 1 an allen Controllern verhindern, denn ausreichend wäre doch ein LISTEN der Applikation 2 (CAPRI-Server), denn die setzt ja nur ein LISTEN an Controller 4 ab.
Die Frage ist, ob Du I4L brauchst oder nicht (also z.B: ISDN network devices ueber ipppd oder RAW ISDN, /dev/ttyI?). Wenn nicht, einfach das laden von capidrv verhindern. -- Karsten Keil SuSE Labs ISDN development
Hallo Karsten Karsten Keil <kkeil@suse.de> wrote on 18.05.2006 14:24:19:
On Thu, May 18, 2006 at 10:46:31AM +0200, Christian Wittmer wrote:
Hallo Karsten,
Karsten Keil <kkeil@suse.de> wrote on 17.05.2006 20:20:55:
On Tue, May 16, 2006 at 06:52:15PM +0200, Christian Wittmer wrote:
Hallo Karsten,
hier das LOG im Anhang. Ich schicke es nur Dir, da ich die Daten nicht an die Liste schicken will.
OK.
1. Um was für einen Anschluss handelt es sich genau ? Es ist ein Anlagen-Anschluß. Der C4 hängt direkt am NTBA.
OK, dann erklärt das zumindest das Rufnummern Routing. Bei einem Anlagenanschlussbündel kann ein Ruf normalerweise auf jedem Controller mit jeder Nummer reinkommen.
Wie sieht die /etc/capi.conf aus ?
so:(after adding DRIVER_OPTIONS="P2P" to /etc/sysconfig/isdn/cfg-contr0) #SuSEconfig.isdn generated # card file proto io irq mem cardnr options c4 c4.bin DSS1 - - - 1 P2P c4 - DSS1 - - - 2 P2P c4 - DSS1 - - - 3 P2P c4 - DSS1 - - - 4 P2P
...
Kannst Du eventuell das Ganze nochmal ohne aktives I4L loggen, das sollte auch die Anzahl der Meldungen reduzieren und Verluste vermeiden: killall isdnlog Das ist kein Problem
rmmod capidrv Das geht net, da capidrv verwendet wird.
DL380 srv-ux-0001:~ # lsmod Module Size Used by af_packet 39048 0 capi 35648 2 e1000 125188 0 ehci_hcd 46852 0 hw_random 21908 0 tpm_atmel 22784 0 tpm 27680 1 tpm_atmel uhci_hcd 48016 0 edd 26336 0 joydev 26688 0 sg 54176 0 st 57500 0 sr_mod 33316 0 ide_cd 54788 0 cdrom 55196 2 sr_mod,ide_cd nvram 25736 0 evdev 26240 0 cpufreq_userspace 42144 8 acpi 22016 0 speedstep_lib 20352 0 freq_table 21504 1 acpi thermal 28936 0 processor 35136 2 acpi,thermal fan 20484 0 button 22672 0 battery 25092 0 ac 21252 0 ipv6 327036 23 usbcore 130400 4 ehci_hcd,uhci_hcd tg3 113412 0 c4 36868 4 b1 41984 1 c4 capidrv 46004 4 isdn 159180 1 capidrv slhc 23680 1 isdn capifs 22280 2 capi kernelcapi 63744 4 capi,c4,b1,capidrv subfs 24448 2 dm_mod 73600 4 reiserfs 277072 4 cciss 73796 5 sd_mod 37888 0 scsi_mod 134852 5 sg,st,sr_mod,cciss,sd_mod toll dass bei einem rcisdn stop die Kiste einfriert, genau dann, wenn die Module entladen werden sollen. Da ist doch was faul, oder ?
Falls noch andere I4L Dienste aktiv sind muessen die vor dem rmmod auch runtergefahren werden.
Was verstehst du unter anderen I4L Diensten ? Meines Wissens hab ich da sonst nichts laufen, aber für einen Tip, was da sein könnte, wäre ich dankbar.
...
Appl. 01 (capidrv) REJECTED den CALL.
Das sieht erstmal so nicht verkehrt aus.
Das sehe ich ein. Nach Deiner ausführlichen Erklärung komme ich zu dem
Schluß, den Controller über eine TK-Anlage zu schalten. Dann kann ich, wenn ich alles richtig verstanden habe, den kommended Ruf an den richtigen Controller weiterleiten. Dann sollte es doch funktionieren, oder ?
Bei einem Anlagenbündel musst Du immer auf allen Controllern lauschen und spaeter in der Applikation entscheiden ob z.B. die Nummer korrekt ist.
Oder kann ich ein LISTEN der Applikation 1 an allen Controllern verhindern, denn ausreichend wäre doch ein LISTEN der Applikation 2 (CAPRI-Server), denn die setzt ja nur ein LISTEN an Controller 4 ab.
Die Frage ist, ob Du I4L brauchst oder nicht (also z.B: ISDN network devices ueber ipppd oder RAW ISDN, /dev/ttyI?). Wenn nicht, einfach das laden von capidrv verhindern. Mal sehen, ob ich da durchsteige. Ich denke mal, dass das im init-script gesteuert wird.
Danke und Gruß Chris
-- Karsten Keil SuSE Labs ISDN development
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-isdn-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-isdn-help@suse.com
On Fri, May 19, 2006 at 08:42:44AM +0200, Christian Wittmer wrote:
Hallo Karsten
Karsten Keil <kkeil@suse.de> wrote on 18.05.2006 14:24:19:
On Thu, May 18, 2006 at 10:46:31AM +0200, Christian Wittmer wrote:
Hallo Karsten,
Karsten Keil <kkeil@suse.de> wrote on 17.05.2006 20:20:55:
On Tue, May 16, 2006 at 06:52:15PM +0200, Christian Wittmer wrote:
Hallo Karsten,
hier das LOG im Anhang. Ich schicke es nur Dir, da ich die Daten nicht an die Liste schicken will.
OK.
1. Um was für einen Anschluss handelt es sich genau ? Es ist ein Anlagen-Anschluß. Der C4 hängt direkt am NTBA.
OK, dann erklärt das zumindest das Rufnummern Routing. Bei einem Anlagenanschlussbündel kann ein Ruf normalerweise auf jedem Controller mit jeder Nummer reinkommen.
Wie sieht die /etc/capi.conf aus ?
so:(after adding DRIVER_OPTIONS="P2P" to /etc/sysconfig/isdn/cfg-contr0) #SuSEconfig.isdn generated # card file proto io irq mem cardnr options c4 c4.bin DSS1 - - - 1 P2P c4 - DSS1 - - - 2 P2P c4 - DSS1 - - - 3 P2P c4 - DSS1 - - - 4 P2P
OK, das P2P wollte ich sehen.
...
Kannst Du eventuell das Ganze nochmal ohne aktives I4L loggen, das sollte auch die Anzahl der Meldungen reduzieren und Verluste vermeiden: killall isdnlog Das ist kein Problem
rmmod capidrv Das geht net, da capidrv verwendet wird.
...
b1 41984 1 c4 capidrv 46004 4 isdn 159180 1 capidrv toll dass bei einem rcisdn stop die Kiste einfriert, genau dann, wenn die Module entladen werden sollen. Da ist doch was faul, oder ?
Das ist ein bekanntes Problem, aber nicht so ohne weiteres fixbar. Der einfachste workaround ist, das entladen komplett zu vermeiden.
Falls noch andere I4L Dienste aktiv sind muessen die vor dem rmmod auch runtergefahren werden.
Was verstehst du unter anderen I4L Diensten ? Meines Wissens hab ich da sonst nichts laufen, aber für einen Tip, was da sein könnte, wäre ich dankbar.
fuser /dev/isdnctrl fuser /dev/isdninfo fuser /dev/ttyI* Kandidaten: kinternet kisdnwatch ...
Oder kann ich ein LISTEN der Applikation 1 an allen Controllern verhindern, denn ausreichend wäre doch ein LISTEN der Applikation 2 (CAPRI-Server), denn die setzt ja nur ein LISTEN an Controller 4 ab.
Die Frage ist, ob Du I4L brauchst oder nicht (also z.B: ISDN network devices ueber ipppd oder RAW ISDN, /dev/ttyI?). Wenn nicht, einfach das laden von capidrv verhindern. Mal sehen, ob ich da durchsteige. Ich denke mal, dass das im init-script gesteuert wird.
-- Karsten Keil SuSE Labs ISDN development
Hallo Karsten,
Das ist ein bekanntes Problem, aber nicht so ohne weiteres fixbar. Der einfachste workaround ist, das entladen komplett zu vermeiden. OK, hab das init-script angepasst (wie bei SuSE9.3)
Falls noch andere I4L Dienste aktiv sind muessen die vor dem rmmod
auch
runtergefahren werden. Was verstehst du unter anderen I4L Diensten ? Meines Wissens hab ich da sonst nichts laufen, aber für einen Tip, was da sein könnte, wäre ich dankbar.
fuser /dev/isdnctrl fuser /dev/isdninfo fuser /dev/ttyI*
Kandidaten: kinternet kisdnwatch nichts dergleichen am laufen, kein X, kein kde.
Laden des isdn-log/capidrv erfolgreich verhindert. neues LOG, wie gewünscht kommt später. Danke :) Christian
participants (2)
-
Christian Wittmer -
Karsten Keil