Supportnet Computer
Planet of Tech

Supportnet / Forum / Linux

automatischer Rückruf funktioniert nicht





Frage

Hi @all! Ich habe folgendes Problem: Ich habe einen SuSE 8.1 Linux-Rechner als einwahlserver konfigurieren wollen. In diesem Rechner sind zwei passive AVM Fritz-Karten drin. Dann habe ich mit Yast2 alles soweit konfiguriert und die Einwahl mit CHAP-Authentifizierung funktioniert wunderbar. Allerdings nur solange, wie ich im Yast die Option "Rückruf aus" (oder Rückruf Client) aktiviert habe. Wenn ich jedoch auf "Rückruf Server" stelle, kann ich mich nicht mehr einwählen. Der Server scheint die Verbindung nicht zu trennen. Und darüber hinaus wählt er nicht die Nummer, die anruft. Er wählt zwar eine Nummer, aber das ist die, die ich der Schnittstelle ippp0 bzw. ippp1 als Provider zuweisen MUSSTE. Das mit den Providern kommt mir ohnehin etwas suspekt vor. Schließlich soll der Rechner selbst der Provider sozusagen sein. Wieso MUSS ich da einen Provider angeben...? Na ja, und wie gesagt. Er wählt immer die Nummer des Providers. Aber selbst, wenn ich als Provider die Nummer des anrufenden Client angebe, trennt der Server nicht die Verbindung. Ich kriege lediglich die aussagekräftigste Fehlermeldung von allen am (Windows 2000-)Client: "Das Gerät hat einen Fehler gemeldet." Woran kann das liegen und wie kann ich dem Server klar machen, dass er die Verbindung trennen soll und die anrufende Nummer zurückrufen soll? Künftig sollen von 11 verschiedenen Nummern die Clients einwählen, und da macht die Sache mit dem Provider ja ohnehin keinen Sinn. Ich habe auch schon alles mögliche ausprobiert: Versch. Treiber (AVM CAPI und HiSax), mit 0 und ohne 0 zur Amtsholung, Server mal an der Telefonanlage (elmeg) und mal am NTBA und sonstige Einstellungen. Immer das gleiche Resultat. Ich bin (in der Angelegenheit zumindest) noch nicht so fit in Linux. Ich danke schonmal im Vorraus für eure Antworten! Viele Grüße Leo Hier noch ein paar Auszüge aus der /var/log/messages Oct 15 14:21:53 chekov kernel: capidrv-1: incoming call 511434XXXX,7,0,270XXXX Oct 15 14:21:53 chekov kernel: ICALLslv: ippp2 Oct 15 14:21:53 chekov kernel: master=ippp0 Oct 15 14:21:53 chekov kernel: master offline Oct 15 14:21:53 chekov kernel: mlpf: 0 Oct 15 14:21:53 chekov kernel: ippp0: call from 511434XXXX -> 270XXXX, start callback Oct 15 14:21:53 chekov kernel: isdn: Rejecting Call Oct 15 14:21:53 chekov kernel: capidrv-1: incoming call 511434XXXX,7,0,270XXXX Oct 15 14:21:53 chekov kernel: ICALLslv: ippp2 Oct 15 14:21:53 chekov kernel: master=ippp0 Oct 15 14:21:53 chekov kernel: master online Oct 15 14:21:53 chekov kernel: mlpf: 1 Oct 15 14:21:53 chekov kernel: ippp2: call from 511434XXXX -> 270XXXX, start callback Oct 15 14:21:53 chekov kernel: isdn: Rejecting Call Oct 15 14:21:55 chekov kernel: ippp0: dialing 1 0511434XXXX... Oct 15 14:21:55 chekov isdnlog: Oct 15 14:21:55 * tei 66 calling +49 511/434XXXX, Hannover with +49 511/270XXXX, Hannover RING (Data) Oct 15 14:21:55 chekov kernel: capidrv-1: DISCONNECT_IND reason 0x34a2 (No circuit / channel available) for plci 0x101 Oct 15 14:21:55 chekov kernel: ippp2: dialing 1 0511434XXXX... Oct 15 14:21:55 chekov isdnlog: Oct 15 14:21:55 * tei 66 calling +49 511/434XXXX, Hannover with +49 511/270XXXX, Hannover RING (Data) Oct 15 14:21:55 chekov kernel: capidrv-1: DISCONNECT_IND reason 0x34a2 (No circuit / channel available) for plci 0x101 Oct 15 14:21:57 chekov isdnlog: Oct 15 14:21:57 * Call to tei 127 from +49 511/434XXXX, Hannover on +49 511/270XXXX, Hannover RING (Data) Oct 15 14:21:57 chekov kernel: capidrv-1: incoming call 511434XXXX,7,0,270XXXX Oct 15 14:21:57 chekov kernel: isdn_tty: call from 511434XXXX -> 270XXXX ignored Oct 15 14:21:57 chekov kernel: capidrv-1: incoming call 511434XXXX,7,0,270XXXX ignored Oct 15 14:22:01 chekov kernel: capidrv-1: incoming call 511434XXXX,7,0,270XXXX Oct 15 14:22:01 chekov kernel: isdn_tty: call from 511434XXXX -> 270XXXX ignored Oct 15 14:22:01 chekov kernel: capidrv-1: incoming call 511434XXXX,7,0,270XXXX ignored Oct 15 14:22:04 chekov kernel: isdn_net: hang up slave ippp2 before ippp0 Oct 15 14:22:04 chekov kernel: isdn_net: local hangup ippp2 Oct 15 14:22:04 chekov kernel: capidrv-1: chan 1 disconnect request on free channel Oct 15 14:22:04 chekov kernel: ippp2: Chargesum is 0 Oct 15 14:22:04 chekov kernel: isdn_net: local hangup ippp0 Oct 15 14:22:04 chekov kernel: capidrv-1: chan 0 disconnect request on free channel Oct 15 14:22:04 chekov kernel: ippp0: Chargesum is 0 Oct 15 14:22:21 chekov isdnlog: Oct 15 14:22:21 * Call to tei 127 from +49 511/434XXXX, Hannover on +49 511/270XXXX, Hannover RING (Data) Oct 15 14:22:21 chekov kernel: capidrv-1: incoming call 511434XXXX,7,0,270XXXX Oct 15 14:22:21 chekov kernel: ICALLslv: ippp2 Oct 15 14:22:21 chekov kernel: master=ippp0 Oct 15 14:22:21 chekov kernel: master offline Oct 15 14:22:21 chekov kernel: mlpf: 0 Oct 15 14:22:21 chekov kernel: ippp0: call from 511434XXXX -> 270XXXX, start callback Oct 15 14:22:21 chekov kernel: isdn: Rejecting Call Oct 15 14:22:21 chekov isdnlog: Oct 15 14:22:21 * Call to tei 127 from +49 511/434XXXX, Hannover on +49 511/270XXXX, Hannover RING (Data) Oct 15 14:22:21 chekov kernel: capidrv-1: incoming call 511434XXXX,7,0,270XXXX Oct 15 14:22:21 chekov kernel: isdn_tty: call from 511434XXXX -> 270XXXX ignored Oct 15 14:22:21 chekov kernel: capidrv-1: incoming call 511434XXXX,7,0,270XXXX ignored Oct 15 14:22:24 chekov kernel: ippp0: dialing 1 0511434XXXX... Oct 15 14:22:24 chekov isdnlog: Oct 15 14:22:24 * tei 66 calling +49 511/434XXXX, Hannover with +49 511/270XXXX, Hannover RING (Data) Oct 15 14:22:24 chekov kernel: capidrv-1: DISCONNECT_IND reason 0x34a2 (No circuit / channel available) for plci 0x101 Oct 15 14:22:25 chekov isdnlog: Oct 15 14:22:25 * Call to tei 127 from +49 511/434XXXX, Hannover on +49 511/270XXXX, Hannover RING (Data)

Antwort 1 von scranagar

Hat niemand eine Idee...?

Antwort 2 von scranagar

ich habe das problem inzwischen eingrenzen können:
die callback-routine (und damit sicherheitsmechanismen) von windows (200) sehen so aus (bzw. windows erwartet das so):
1. server anrufen
2. server nimmt ab
3. am server authentifizieren
4. server legt auf
5. server ruft zurück
6. erneute authentifizierung und verbindung herstellen

die callback-routine von linux ist da anders:
1. server wird angerufen
2. server lehnt den anruf ab
3. server ruft nach dem cb-delay zurück
4. authentifizierung und verbindung herstellen

und ich glaube, genau hier liegt das problem. denn windows erwartet, dass der server die verbindung annimmt, tut er aber nicht. und deswegen ist nach schritt 1 schluss....

wie kann man das problem lösen?

und nochwas: brauche ich für jede station von der aus angerufen werden soll eine eigene schnittstelle und/oder einen eigenen provider? das sind nämlich insgesamt 11 stück...

oder sehe ich das alles vollkommen falsch?

so long
gruß
scran

Ich möchte kostenlos eine Frage an die Mitglieder stellen:


Ähnliche Themen:


Suche in allen vorhandenen Beiträgen: