Hallo! Habe folgendes Problem: Mochte mich zwecks Fernwartung auf einem Linuxrechner (Suse 8.2) ohne Internetanbindung einwahlen. Habe schon diverse Tutorials durchgetestet und etliche Foren durchstobert, leider ohne Erfolg. Die einzigen Fehlermeldungen die ich bekomme sind von meinem Win-Rechner, unzwar dass der Remote nicht antwortet. Der Linux scheint gar keinen Incoming Call zu registrieren (zumindest wird kein eintrag in var/log/messages erstellt). mgetty ist installiert und nach anleitung konfiguriert ;). hoffe mir kann jmd helfen ;)
On Thu, Aug 21, 2003 at 11:54:43AM +0200, Jens Fischer wrote:
Hallo! Habe folgendes Problem: Mochte mich zwecks Fernwartung auf einem Linuxrechner (Suse 8.2) ohne Internetanbindung einwahlen. Habe schon diverse Tutorials durchgetestet und etliche Foren durchstobert, leider ohne Erfolg. Die einzigen Fehlermeldungen die ich bekomme sind von meinem Win-Rechner, unzwar dass der Remote nicht antwortet. Der Linux scheint gar keinen Incoming Call zu registrieren (zumindest wird kein eintrag in var/log/messages erstellt).
Dann wird die falsche Nummer angerufen, die Leitung ist nicht angeschlossen oder der ISDN Treiber funktioniert nicht.
mgetty ist installiert und nach anleitung konfiguriert ;). hoffe mir kann jmd helfen ;)
Was willst Du denn machen ? Einer Netzwerkverbindung herstellen oder nur ein terminal login ? Letzteres ist einfacher, es reicht mgetty aufzusetzen: 1. In /etc/mgetty+sendfax/mgetty.config hinzufügen port ttyI1 rings 1 init-chat "" ATS0=0 OK AT&E123 OK (Statt 123 Deine MSN eintragen) 2. In /etc/inittab I1:235:respawn:/usr/sbin/mgetty -s 38400 ttyI1 eintragen 3. telinit -q 4. Mit geeignetem Terminal Programm einwaehlen (Protocol ist X75 IFrames). Testen kann man das unter Linux mit minicom: Eine Datei /etc/minirc.i0 mit folgendem Inhalt erstellen: # Machine-generated file - use "minicom -s" to change parameters. pr port /dev/ttyI0 pu minit ~^M~AT&E0^M minicom i0 aufrufen, mit atd123 (Statt 123 Deine MSN eintragen) anrufen. -- Karsten Keil SuSE Labs ISDN development
ich bins wieder ;) vielen dank an karsten. mit der mgetty konfiguration kann ich jetzt auf dem linux anrufen. *freu* einzige problem bleibt dass der linuxrechner den ruf nicht annimmt obwohl in der dialin.config "all" auskommentiert ist =( bekomme zwar eine fehlermeldung kann aber damit nicht wirklich viel anfangen =/ Auszug aus der /var/log/messages \\ Aug 22 12:09:34 linux isdnlog: Aug 22 12:09:34 Call to tei 127 from +49 5251/34, Paderborn on +49 5251/1, Paderborn HANGUP (Timeout) Aug 22 12:09:34 linux isdnlog: Aug 22 12:09:34 * Call to tei 127 from +49 5251/34, Paderborn on +49 5251/1, Paderborn RING (Data) Aug 22 12:09:34 linux isdnlog: Aug 22 12:09:34 * Call to tei 127 from +49 5251/34, Paderborn on +49 5251/1, Paderborn UNKNOWN ELEMENT 32: 81 [ ], length=1 -- complete frame ignored! Aug 22 12:09:34 linux kernel: isdn_net: call from 34 -> 0 1 ignored Aug 22 12:09:34 linux kernel: isdn_tty: call from 34 -> 1 ignored Aug 22 12:09:38 linux kernel: isdn_net: call from 34 -> 0 1 ignored Aug 22 12:09:38 linux kernel: isdn_tty: call from 34 -> 1 ignored Aug 22 12:10:30 linux modprobe: modprobe: Can't locate module Default // ziel des ganzen soll sein, dass ich mich mit irgendnem rechner auf dem linuxrechner einwählen kann um ihn dann mit vnc zu administrieren.
Hi, Am 22.08.2003 10:19 schrieb Jens Fischer:
ich bins wieder ;) vielen dank an karsten. mit der mgetty konfiguration kann ich jetzt auf dem linux anrufen. *freu* einzige problem bleibt dass der linuxrechner den ruf nicht annimmt obwohl in der dialin.config "all" auskommentiert ist =(
bekomme zwar eine fehlermeldung kann aber damit nicht wirklich viel anfangen =/
Auszug aus der /var/log/messages \\ Aug 22 12:09:34 linux isdnlog: Aug 22 12:09:34 Call to tei 127 from +49 5251/34, Paderborn on +49 5251/1, Paderborn HANGUP (Timeout) Aug 22 12:09:34 linux isdnlog: Aug 22 12:09:34 * Call to tei 127 from +49 5251/34, Paderborn on +49 5251/1, Paderborn RING (Data) Aug 22 12:09:34 linux isdnlog: Aug 22 12:09:34 * Call to tei 127 from +49 5251/34, Paderborn on +49 5251/1, Paderborn UNKNOWN ELEMENT 32: 81 [ ], length=1 -- complete frame ignored! Aug 22 12:09:34 linux kernel: isdn_net: call from 34 -> 0 1 ignored Aug 22 12:09:34 linux kernel: isdn_tty: call from 34 -> 1 ignored Aug 22 12:09:38 linux kernel: isdn_net: call from 34 -> 0 1 ignored Aug 22 12:09:38 linux kernel: isdn_tty: call from 34 -> 1 ignored Aug 22 12:10:30 linux modprobe: modprobe: Can't locate module Default //
ziel des ganzen soll sein, dass ich mich mit irgendnem rechner auf dem linuxrechner einwählen kann um ihn dann mit vnc zu administrieren.
die Einwahl ueber mgetty (X75) bietet Dir eine console auf der Du
arbeiten kannst. Das reicht zur administration eindeutig aus. Falls
Du ueber VNC arbeiten moechtest, benoetigts Du ppp.
Mach mal folgendes:
-- /etc/mgetty.config --
port ttyI0
debug 6
# Init String alte SuSE
#init-chat "" \d\d\d+++\d\d\dATZ OK ATS14=0&E123456&B512 OK
init-chat "" \d\d\d\d\d\dATZ OK ATS14=0&E123456&B512 OK
modem-type data
--
Mit den init-Strings musste bei SuSE schon mal ein wenig rumspielen.
-- /etc/mgetty+sendfax/login.config --
/AutoPPP/ - a_ppp /usr/sbin/pppd auth
* - - /bin/login @
auth
login
chap
+pap
debug
--
-- /etc/inittab --
I0:23:respawn:/usr/sbin/mgetty -s 38400 /dev/ttyI0
--
-- /etc/ppp/options --
name
* Jörg Zimmermann schrieb:
vielen dank an karsten. mit der mgetty konfiguration kann ich jetzt auf dem
Darf ich mal in die Runde fragen, warum für eine Einwahl per ISDN eine getty-Variante favorisiert wird? Es ist doch nichts einfacher als die Einwahl in einen Linuxrechner per ppp wie es bei den Internet-Providern auch ist. Es muß nur ein ipppX-Device mit yast angelegt werden und in der /etc/sysconfig/isdn/cfg-netX ein paar Attribute verändert und ergänzt werden, damit das device "weiß", daß es Einwahldevice ist. Dann steht eine vollwertige (proxyarp) Netzwerkverbindung, die jedweden Netzwerkverkehr über IP zuläßt. Es steht dann sogar noch die Option eine zweite ISDN-Leitung dazuzuschalten, bei VNC durchaus empfehlenswert, bei tightvnc aber eigentlich nicht notwendig. Meine Standard cfg-net2 ist Einwahldevice: (die x'e kommen von mir, normal steht da die vollst. Tel-Nr) # /etc/sysconfig/isdn/templ_dialin (Einwahl) CALLBACK="off" CHARGEHUP="on" COMPRESSION="no" DEFAULTROUTE="no" DIALMODE="manual" DYNAMICIP="no" FIREWALL="no" IPADDR="192.168.0.199" PTPADDR="192.168.0.198" MSN="830xxxx" MULTILINK="no" PROTOCOL="syncppp" PROVIDER="pc-dialin_1" STARTMODE="onboot" #REMOTE_IN="721830xxx 76646xxx 76124xxx" IPPPD_OPTIONS="+pap -chap debug proxyarp" #IPPPD_OPTIONS="+pap -chap debug" #Wenn alle Nummern anrufen dürfen dann # SECURE="off" #REMOTE_IN weglassen Was in /etc/sysconfig/network/provider/pc-dialin_1 steht ist wurscht, weil ja nicht rausgewählt wird. Also: was für ein Vorteil hat die Variante mit mgetty? Ich glaube X.75 ist etwas schneller, stimmt das? Ekkard
On Sun, Aug 24, 2003 at 09:50:44PM +0200, Ekkard Gerlach wrote:
* Jörg Zimmermann schrieb:
vielen dank an karsten. mit der mgetty konfiguration kann ich jetzt auf dem
Darf ich mal in die Runde fragen, warum für eine Einwahl per ISDN eine getty-Variante favorisiert wird?
Weil nach mgetty gefragt wurde und ein reines Terminal Login ueber Mgetty immer einfacher und von Haus aus sicherer ist, auch für den Anrufer. Ich kenne genug Firmen bei denen der Aufbau einer (zusaetzlichen) Netzwerk- verbindung strengstens verboten ist, da bleibt einem manchmal nur das Terminal login.
Es ist doch nichts einfacher als die Einwahl in einen Linuxrechner per ppp wie es bei den Internet-Providern auch ist. Es muß nur ein ipppX-Device mit yast angelegt werden und in der /etc/sysconfig/isdn/cfg-netX ein paar Attribute verändert und ergänzt werden, damit das device "weiß", daß es Einwahldevice ist. Dann steht eine vollwertige (proxyarp) Netzwerkverbindung, die jedweden Netzwerkverkehr über IP zuläßt. Es steht dann sogar noch die Option eine zweite ISDN-Leitung dazuzuschalten, bei VNC durchaus empfehlenswert, bei tightvnc aber eigentlich nicht notwendig.
Richtig, wenn man eine Netzwerkverbindung möchte, ist das die richtige Variante und auch nicht schwerer aufzusetzen. PPP ueber X.75 macht dagegen keinen Sinn, ausser man will beides mit einer MSN benutzen. -- Karsten Keil SuSE Labs ISDN development
erstmal vielen dank für die auszüge. allerdings leider ohne erfolg. die fehlermeldung bleibt in der /var/log/messages bleibt, und der rechner mit dem ich mich einwählen will sagt mir dass der remotecomputer nicht antwortet. ich verzweifel langsam =/
hab den zugang noch einmal neu konfiguriert mit folgendem script: << INTERFACE=ippp0 # Interface MSN=16 # eigene Nummer LOCAL=192.168.99.1 # eigene IP REMOTE=192.168.99.2 # IP der Gegenstelle isdnctrl addif $INTERFACE isdnctrl ihup $INTERFACE off isdnctrl eaz $INTERFACE $MSN isdnctrl l2_prot $INTERFACE hdlc isdnctrl pppbind $INTERFACE 0 isdnctrl encap $INTERFACE syncppp isdnctrl huptimeout $INTERFACE 300 ifconfig $INTERFACE $LOCAL up ifconfig $INTERFACE dstaddr $REMOTE
/etc/ppp/options.ttyI0 : << lock connect '/usr/sbin/chat -v -t 1 "" "AT&F" "OK" "AT&E16&B1024&R9600S19=197S0=1" "OK"' idle 300 persist passive crtscts modem 192.168.1.1:192.168.1.2 nodefaultroute proxyarp noccp noipx auth require-pap remotename dialin_server_user
und in der pap-secrets halt username und passwort.
wenn ich nun den ppp daemon via " pppd /dev/ttyI0 nodetach -d" starte und
mich dann einwählen will bekomm ich immer noch folgende fehlermeldungen:
<<
Aug 25 16:38:56 linux pppd[1964]: pppd 2.4.1 started by root, uid 0
Aug 25 16:38:56 linux pppd[1964]: Perms of /dev/ttyI0 are ok, no 'mesg n'
neccesary.
Aug 25 16:38:57 linux chat[1970]: send (AT&F^M)
Aug 25 16:38:57 linux chat[1970]: expect (OK)
Aug 25 16:38:57 linux chat[1970]: AT&F^M^M
Aug 25 16:38:57 linux chat[1970]: OK
Aug 25 16:38:57 linux chat[1970]: -- got it
Aug 25 16:38:57 linux chat[1970]: send (AT&E16&B1024&R9600S19=197S0=1^M)
Aug 25 16:38:57 linux chat[1970]: expect (OK)
Aug 25 16:38:57 linux chat[1970]: ^M
Aug 25 16:38:57 linux chat[1970]: AT&E16&B1024&R9600S19=197S0=1^M^M
Aug 25 16:38:57 linux chat[1970]: OK
Aug 25 16:38:57 linux chat[1970]: -- got it
Aug 25 16:38:57 linux pppd[1964]: Serial connection established.
Aug 25 16:38:57 linux pppd[1964]: using channel 4
Aug 25 16:38:57 linux pppd[1964]: Using interface ppp0
Aug 25 16:38:57 linux pppd[1964]: Connect: ppp0 <--> /dev/ttyI0
Aug 25 16:38:58 linux pppd[1964]: sent [LCP ConfReq id=0x1
On Mon, Aug 25, 2003 at 02:45:50PM +0200, Jens Fischer wrote:
hab den zugang noch einmal neu konfiguriert mit folgendem script:
Das kann so nicht funktionieren, Du versuchst I4L syncppp zu verwenden startetst aber den pppd, der kann kein syncppp mit I4L device. Du hast eine 8.2, dann ist das Setup eines syncppp dialins ganz einfach: yast2 isdn -->Aendern Hinzufügen im untern Fenster Neue syncppp ... eigene nummer eintragen Firewall aktivieren... -> ausschalten Details Nur Nummern aus der Liste erlaubt -> ausschalten keine Nummern eintragen !!! Zusätzliche ipppd-Optionen ->eintragen: +pap +chap debug Ok Weiter Dynamische IP-Adresse -> ausschalten IP Adressen eintragen Standardroute -> ausschalten Weiter Neu Name des Providers mylogin Telefonnummer 1 (wird nicht verwendet) Benutzername EinName Passwort EinPasswort Passwortabfrage muss aus sein Weiter Dial-On-Demand -> ausschalten Während Verbindung DNS ändern -> ausschalten Weiter Beenden Nachdem das gespeicht wurde sollte ein syncppp Login mit den eingebenen Daten moeglich sein. Achtung mgetty darf nicht auf die selbe MSN lauschen, am besten ganz disablen. -- Karsten Keil SuSE Labs ISDN development
zum einen erstmal vielen dank für die hilfe. allerdings schlägt jeder lösungsweg fehl. es bleibt der bereits erwähnte log eintrag (...complete frame ignored...)kann es vielleicht an der hardware liegen? verbaut ist eine hst saphir III isdn karte. im vorraus vielen dank mfg
On Tue, Aug 26, 2003 at 09:15:53AM +0200, Jens Fischer wrote:
zum einen erstmal vielen dank für die hilfe. allerdings schlägt jeder lösungsweg fehl. es bleibt der bereits erwähnte log eintrag (...complete frame ignored...)kann es vielleicht an der hardware liegen? verbaut ist eine hst saphir III isdn karte. im vorraus vielen dank
Nein an der Hardware liegt das nicht, sondern an der TKAnlage die diesen Frame erzeugt, allerdings hat der Fehler nichts mit der Funktion zu tun sondern nur mit dem loggen der ISDN Daten. Trotzdem kann das natürlich ein Problem sein, das auch die Rufannahme verhindert. Mal folgendes tun (als root) killall isdnlog hisaxctrl contr0 1 0x33ff hisaxctrl contr0 11 0xf4f hisaxctrl contr0 13 0xff cat /dev/isdnctrl >/tmp/ilog Dann eine Einwahl probieren. 1 Minute warten, cat /dev/isdnctrl mit Strg-C abbrechen und mir schicken (nicht der Liste). -- Karsten Keil SuSE Labs ISDN development
participants (4)
-
Ekkard Gerlach -
Jens Fischer -
Jörg Zimmermann -
Karsten Keil