Hallo. Ich muß zwei Rechner miteinander verbinden. Das soll alles über ISDN geschehen, damit ich die Server, die nicht hier stehen auch administrieren kann. Dazu habe ich einen Testserver und einen Testclient aufgebaut. Der Server hat einen Fritz PCI und der Client eine Fritz Classic. Beide Karten laufen soweit. Beide Rechner sind an unser lokales Netz angeschlossen, sollen aber über unsere Telefonanlage miteinander kommunizieren. Die IP-Adressen sind die folgenden: Server: eth0 192.192.192.210 ippp0 192.192.191.1 Tel.: 355 Client: eth0 192.192.192.211 ippp0 192.192.191.2 Tel: 356 Ich habe alles mit Yast eingerichtet bekomme aber keine Verbindung hin, wenn ich nun vom Client aus die 192.192.191.1 anpinge. Was kann ich falsch gemacht haben? Vielen Dank für die Hilfe! Andre
On Thu, May 03, 2001 at 01:31:41PM +0200, Andre Klocke wrote:
Hallo.
Ich muß zwei Rechner miteinander verbinden. Das soll alles über ISDN geschehen, damit ich die Server, die nicht hier stehen auch administrieren kann. Dazu habe ich einen Testserver und einen Testclient aufgebaut. Der Server hat einen Fritz PCI und der Client eine Fritz Classic. Beide Karten laufen soweit. Beide Rechner sind an unser lokales Netz angeschlossen, sollen aber über unsere Telefonanlage miteinander kommunizieren. Die IP-Adressen sind die folgenden: Server: eth0 192.192.192.210 ippp0 192.192.191.1 Tel.: 355 Client: eth0 192.192.192.211 ippp0 192.192.191.2 Tel: 356
Ich habe alles mit Yast eingerichtet bekomme aber keine Verbindung hin, wenn ich nun vom Client aus die 192.192.191.1 anpinge.
Was kann ich falsch gemacht haben?
Fuer soetwas ist RAW-IP einfacher, bei syncppp must Du einen Rechner als Server configurieren, das geht nur per Hand (editieren der options.ipppX). Mit raw ip reicht es auf der server Seite die entsprechende anrufende Nummer zu erlauben (geht mit yast1). -- Karsten Keil SuSE Labs ISDN development
----- Original Message -----
From: "Karsten Keil"
On Thu, May 03, 2001 at 01:31:41PM +0200, Andre Klocke wrote:
Hallo.
Ich muß zwei Rechner miteinander verbinden. Das soll alles über ISDN geschehen, damit ich die Server, die nicht hier stehen auch administrieren kann. Dazu habe ich einen Testserver und einen Testclient aufgebaut. Der Server hat einen Fritz PCI und der Client eine Fritz Classic. Beide Karten laufen soweit. Beide Rechner sind an unser lokales Netz angeschlossen, sollen aber über unsere Telefonanlage miteinander kommunizieren. Die IP-Adressen sind die folgenden: Server: eth0 192.192.192.210 ippp0 192.192.191.1 Tel.: 355 Client: eth0 192.192.192.211 ippp0 192.192.191.2 Tel: 356
Ich habe alles mit Yast eingerichtet bekomme aber keine Verbindung hin, wenn ich nun vom Client aus die 192.192.191.1 anpinge.
Was kann ich falsch gemacht haben?
Fuer soetwas ist RAW-IP einfacher, bei syncppp must Du einen Rechner als Server configurieren, das geht nur per Hand (editieren der options.ipppX). Mit raw ip reicht es auf der server Seite die entsprechende anrufende Nummer zu erlauben (geht mit yast1).
Der Rechner nimmt den Anruf nicht entgegen. Der Ping funktioniert nicht und auch mit einem Notebook mit fritzCom unter Windows bekomme ich die Meldung: Teilnehmer antwortet nicht. Muß ich noch irgendeine einstellung machen? Andre
-- Karsten Keil SuSE Labs ISDN development
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-isdn-unsubscribe@suse.com For additional commands, e-mail: suse-isdn-help@suse.com
On Thu, May 03, 2001 at 03:58:09PM +0200, Andre Klocke wrote:
Was kann ich falsch gemacht haben?
Fuer soetwas ist RAW-IP einfacher, bei syncppp must Du einen Rechner als Server configurieren, das geht nur per Hand (editieren der options.ipppX). Mit raw ip reicht es auf der server Seite die entsprechende anrufende Nummer zu erlauben (geht mit yast1).
Der Rechner nimmt den Anruf nicht entgegen. Der Ping funktioniert nicht und auch mit einem Notebook mit fritzCom unter Windows bekomme ich die Meldung: Teilnehmer antwortet nicht. Muß ich noch irgendeine einstellung machen?
Was steht denn in der /var/log/messages ? Die incomming number muss genau so gesetzt werden, wie sie dort erscheint. z.B. isdn_net: call from 8942712345,7,0 -> 9123 Dann muss die incomming number auf 8942712345 stehen damit der call angenommen wird. -- Karsten Keil SuSE Labs ISDN development
Hallo Liste! ich möchte eine Verbindung von einem SuSE 7.0 zu einem BINTEC Router herstellen, der dann -möglichst nach einer reinen D-Kanalverbindung- den Linux-Recher zurückruft. Erster Schritt: Ohne callback Auf der Linux Seite habe ich mit YAST1 rawIP (isdn0) konfiguriert. Der Router verifiziert nur über die Rufnummer, encapsulation ist ppp, Authenfizierung per PAP (und/oder CHAP) ist deaktiviert. ...und die Verbindung wird korrekt aufgebaut. Zweiter Schritt: mit callback Auf der Bintec ist nun callback eingestellt, aber ich registriere leider keinen eingehenen Anruf (tail -f /var/log/messages). Folgende Hinweise konnte ich heute noch finden (aber noch nicht testen): -callback erfolgt zu schnell -> callbyk mit delay (Änderung an der Bintec) -syncPPP und login/pw manuell auf leer setzen (YAST will da definitiv was zu stehen haben) -encapsulation der Bintec auf HDLC setzen (aber wieso, ohne callback gehts ja?) Hat sonst jemand Erfahrung oder Tipps in der Umsetzung dieser Anforderung? Danke, Jochen --- Jochen Erfurt Hartung & Partner GmbH Wiesenweg 9 DE-12247 Berlin (Steglitz) Tel. : +49 (0)30 77130-223 Fax : +49 (0)30 77130-239 email: erfurt@vector.de
On Thu, May 03, 2001 at 05:37:13PM +0200, Erfurt, Jochen wrote:
Hallo Liste!
ich möchte eine Verbindung von einem SuSE 7.0 zu einem BINTEC Router herstellen, der dann -möglichst nach einer reinen D-Kanalverbindung- den Linux-Recher zurückruft.
Erster Schritt: Ohne callback Auf der Linux Seite habe ich mit YAST1 rawIP (isdn0) konfiguriert.
Der Router verifiziert nur über die Rufnummer, encapsulation ist ppp, Authenfizierung per PAP (und/oder CHAP) ist deaktiviert.
...und die Verbindung wird korrekt aufgebaut.
Seltsam, da RAW IP nichts mit ppp zu tun hat.
Zweiter Schritt: mit callback Auf der Bintec ist nun callback eingestellt, aber ich registriere leider keinen eingehenen Anruf (tail -f /var/log/messages).
Dann kommt auch keiner (egal wie schnell der kommt, in /var/log/messages steht er immer). BEi syncppp Callback kommt der Callback erst nach Aushandlung. Probier doch zuerst mal ohne Callback die Verbindung von der Bintec aus aufzubauen.
Folgende Hinweise konnte ich heute noch finden (aber noch nicht testen): -callback erfolgt zu schnell -> callbyk mit delay (Änderung an der Bintec)
sollten 2 sek sein und auf der i4l Seite 1 sek
-syncPPP und login/pw manuell auf leer setzen (YAST will da definitiv was zu stehen haben)
Dann hast Du ein sync-ppp eingerichtet, bei RAW-IP geht yast1 ueber die Eintraege hinweg. Wuerde auch zu der Einstellung der Bintec passen.
-encapsulation der Bintec auf HDLC setzen (aber wieso, ohne callback gehts ja?)
HDLC sollte fuer RAWIP richtig sein. Bei syncppp geht callback nicht (und ist auch nicht das was Du willst, da dort auch immer eine B-channel Verbindung aufgebaut wird). -- Karsten Keil SuSE Labs ISDN development
Hallo, On Thu, May 03, 2001 at 05:52:38PM +0200, Karsten Keil wrote:
On Thu, May 03, 2001 at 05:37:13PM +0200, Erfurt, Jochen wrote:
ich möchte eine Verbindung von einem SuSE 7.0 zu einem BINTEC Router herstellen, der dann -möglichst nach einer reinen D-Kanalverbindung- den Linux-Recher zurückruft.
Erster Schritt: Ohne callback Auf der Linux Seite habe ich mit YAST1 rawIP (isdn0) konfiguriert.
Mich wundert, dass da ueberhaupt etwas laeuft ... Sinnvollerweise nimmt man fuer encapsulation ppp auf dem Bintec fuer die Gegenseite auch (sync-)ppp (wuerde ich zumindest so erwarten ...).
Der Router verifiziert nur über die Rufnummer, encapsulation ist ppp, Authenfizierung per PAP (und/oder CHAP) ist deaktiviert.
...und die Verbindung wird korrekt aufgebaut.
Seltsam, da RAW IP nichts mit ppp zu tun hat.
Das wundert mich ehrlich gesagt auch. Fliegen da auch sicher keine Reste einer Konfiguration eines ippp* Devices auf dem Linux-Rechner herum?
Zweiter Schritt: mit callback Auf der Bintec ist nun callback eingestellt, aber ich registriere leider keinen eingehenen Anruf (tail -f /var/log/messages).
Ab hier hat das ganze eiegntlich nichts mehr mit linux zu tun, denn...
Dann kommt auch keiner (egal wie schnell der kommt, in /var/log/messages steht er immer).
..der Bintex ruft offenbar nicht raus. Auch wenn meine hellseherischen Faehigkeiten eher begrenzt sind, vermute ich mal, dass auf dem Interface auf dem Bintec keine Nummer zum rauswaehlen ("Wan Number") konfiguriert ist. Wenn er nicht weiss, wen er anrufen soll, ruft der nicht an.
BEi syncppp Callback kommt der Callback erst nach Aushandlung.
Nein. Die Bintecs beherrschen auch Problemlos D-Kanal Callback (unabhaengig von der Encapsulation), und bei Linux sollte das auch nicht unbedingt anders sein, wenn es dafuer passend konfiguriert ist (und ich denke, dass eine solche Konfiguration moeglich sein muesste, zumindest wenn linux rausruft und die Gegenseite ein Callback machen soll).
Probier doch zuerst mal ohne Callback die Verbindung von der Bintec aus aufzubauen.
Wenn meine Vermutung stimmt, geht auch das nicht, weil die anzurufende Nummer nicht korrekt konfiguriert ist (unter "Wan Numbers" eine Nummer mit "Direction outgoing" und eine mit "Direction incoming" konfigurieren, dabei beachten, dass bei reinkommenden Rufen die "0" der Vorwahl nicht mit uebermittelt wird ...).
Folgende Hinweise konnte ich heute noch finden (aber noch nicht testen): -callback erfolgt zu schnell -> callbyk mit delay (Änderung an der Bintec)
Duerfte IMHO nicht das Problem sein.
sollten 2 sek sein und auf der i4l Seite 1 sek
U.U sind eine Sekunde auf der Linux-Seite etwas knapp (je nachdem, von wo nach wo angerufen wird, wieviele Vermittlungsstellen dazwischen liegen, welche Technik, welche Firmware.Versionen, etc. in der Ver- mittlungsstelle verwendet werden, ...). Sieh dir das Log des Bintec an, ob der ueberhaupt einen reinkommenden Anruf registriert (und wenn ja, von welcher Rufnummer). Fuer D-Kanal-Callback muss zwingend eine korrekte "incoming Number" auf dem Bintec konfiguriert werden, sonst wird er vermutlich eher versuchen den Ruf anzunehmen oder ihn zu ignorieren (je nach sonstiger Konfiguration), vermute ich zumindest ... Ich habe allerdings noch keinen Bintec auf "Callback" betrieben (bei uns laeuft der Brick XL2 mit "awaiting Callback").
-syncPPP und login/pw manuell auf leer setzen (YAST will da definitiv was zu stehen haben) Dann hast Du ein sync-ppp eingerichtet, bei RAW-IP geht yast1 ueber die Eintraege hinweg. Wuerde auch zu der Einstellung der Bintec passen.
Das habe ich auch vermutet.
-encapsulation der Bintec auf HDLC setzen (aber wieso, ohne callback gehts ja?) HDLC sollte fuer RAWIP richtig sein.
Korrekt. Wenn der Bintec nicht rausruft, hast du IMHO ein voellig anderes Problem.
Bei syncppp geht callback nicht
Warum nicht? Es muesste doch (wenn auch ggfs. mit etwas Bastelei) gehen, dass man den Linux-Rechner zum "nur einmaligen rauswaehlen" bewegt. Der Bintec sollte bei Konfiguration auf "Callback" (nicht auf "Callback PPP Negotiation") den eingehenden ruf (wenn eine "incoming Number" zum reinkommenden Ruf passt) den Ruf ablehnen und selbst bei Linux-Rechner anrufen, der dann natuerlich (auch) als Dialin-Server fuer sync-PPP konfiguriert sein sollte.
(und ist auch nicht das was Du willst, da dort auch immer eine B-channel Verbindung aufgebaut wird).
Betrifft "Callback with PPP Negotiation" (auch "kooperatives Callback" genannt). Nahezu alle Router beherrschen auch D-Kanal-Callback (und das _auch_ aber nicht nur bei PPP-Encapsulation). Bei Bintec ist genau das der Unterschied zwischen "Callback" und "Callback (PPP Negotiation)", bei Cisco ist das IIRC der Unterschied zwischen "secure callback" (kooperativ) und "no secure callback" (D-Kanal-Callback). Bei Ciscos haben aber einige IOS-Versionen (besonders solche vor 11.2) so ihre Probleme mit Waehlverbindungen, insbesondere bei Callback ... Das ist nun aber restlos Off-Topic (entschuldigt die Ausschweifungen). Tschuess, Juergen Ilse (ilse@asys-h.de) -- Eingedeutschte Fehlermeldungen sind doch etwas | Juergen Ilse schoenes: "router:[/local]# rm -R var" | Internet POP Hannover "rm: im Verzeichnis >>var<< absteigen?" | Vahrenwalder Str. 205 -----------------------------------------------------| 30165 Hannover Neu in de.comp.os.unix.linux.*? Lies die infos-Gruppe| ilse@pop-hannover.net
Hallo Jochen! "Erfurt, Jochen" wrote:
Hallo Liste!
ich möchte eine Verbindung von einem SuSE 7.0 zu einem BINTEC Router herstellen, der dann -möglichst nach einer reinen D-Kanalverbindung- den Linux-Recher zurückruft.
Ich mache das hier mit einer BIANCA/BRI, funktioniert wunderbar.
Erster Schritt: Ohne callback Auf der Linux Seite habe ich mit YAST1 rawIP (isdn0) konfiguriert.
Parameter sollten so ähnlich heissen: encapsulation ist HDLC callback ist server callback timeout ist 1
Der Router verifiziert nur über die Rufnummer, encapsulation ist ppp, Authenfizierung per PAP (und/oder CHAP) ist deaktiviert.
kann ich hier bei encapsulation HDLC gar nicht Konfigurieren (ist disabled).
...und die Verbindung wird korrekt aufgebaut.
Vermutlich nur Glück.
Zweiter Schritt: mit callback Auf der Bintec ist nun callback eingestellt, aber ich registriere leider keinen eingehenen Anruf (tail -f /var/log/messages).
Folgende Hinweise konnte ich heute noch finden (aber noch nicht testen): -callback erfolgt zu schnell -> callbyk mit delay (Änderung an der Bintec) -syncPPP und login/pw manuell auf leer setzen (YAST will da definitiv was zu stehen haben) -encapsulation der Bintec auf HDLC setzen (aber wieso, ohne callback gehts ja?)
Mit folgenden Parameter in /etc/isdn/i4l.rc.config (oder über yast) rennts bei mir: X steht für das entsprechende Interface (bei mir 1, weil 0 eth0 ist). I4L_LOCALMSN_X="123456" (deine Rufnummer) I4L_REMOTE_OUT_X="01234987654" (die zu rufende Nummer) I4L_REMOTE_IN_X="1234987654" (die Nummer für den eingehenden Ruf, wie in /var/log/messages) I4L_CALLBACK_X="out" I4L_CBDELAY_X="3" auch wenn im Kommentar etwas anderes steht. "1" geht bei reproduzierbar definitiv nicht. I4L_ENCAP_X="rawip" I4L_SECURE_X="on" (nur die unter REMOTE_IN definierten Nummer werden angenommen, für Testzwecke kann man das besser ausschalten, wenns dann funktioniert wieder ein) I4L_PPPBIND_X="" I4L_L2_X="hdlc" I4L_L3_X="trans" Alle anderen Parameter nach den eigenen Wünschen.
Hat sonst jemand Erfahrung oder Tipps in der Umsetzung dieser Anforderung?
Danke, Jochen
Bis denne Jürgen -- DATALINE GmbH http://www.dataline-gmbh.de Jürgen Busse Postfach 1106 42904 Wermelskirchen --------------------------------------------------------------------- Spezialisten sind Leute, die nur eine Saite auf ihrer Fidel haben. (Henry Miller) --------------------------------------------------------------------- IMPORTANT NOTICE: This email is confidential, may be legally privileged, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone else is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender.
Vielen Dank für die Unterstützung! Ich traue mich gar nicht zu sagen, daß jemand den Anschluß der Bintec (mal eben schnell) umkonfiguriert hat und diesen dabei (ausversehen) für ausgehende Anrufe gesperrt hat ... Natürlich ohne Mitteilung. Jochen --- Jochen Erfurt Hartung & Partner GmbH Wiesenweg 9 DE-12247 Berlin (Steglitz) Tel. : +49 (0)30 77130-223 Fax : +49 (0)30 77130-239 email: erfurt@vector.de
participants (5)
-
Andre Klocke -
Erfurt, Jochen -
Juergen Ilse -
Jürgen Busse -
Karsten Keil