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
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