Das ist möglich, und zwar mit dem
TERM-Paket. TERM erlaubt es, Netzwerkverbindungen über eine normale
Terminal-Sitzung aufzubauen. Es verlangt allerdings diverse
Modifikationen an den Netzprogrammen, die man verwenden will. Für die
meisten Anwendungsprogramme gibt es aber bereits fertig kompilierte
Versionen mit TERM-Unterstützung. Näheres dazu findet sich im
TERM-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/Term-HOWTO.html
).
Der Name-Resolver ist nicht richtig konfiguriert, siehe den Abschnitt
über /etc/resolv.conf
. Es muß mindestens ein Nameserver
eingetragen sein.
RFC1597 reserviert einige Adressbereiche speziell für die private Nutzung. Sie sollten unbedingt verwendet werden damit keine größeren Probleme auftreten, wenn man doch einmal Verbindung mit dem Internet bekommt. Die reservierten Adressen sind:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
Es gibt reservierte Netzwerkadressen für die Klassen A, B und C. Man
ist also in der Wahl von Größe und Design des privaten Netzwerkes nicht
eingeschränkt. Da das Netzwerk nie mit dem Internet oder einem anderen
Netzwerk in Kontakt tritt ist es egal, ob jemand anders dieselben
Adressen verwendet. Lediglich innerhalb des eigenen lokalen Netzes
müssen sie eindeutig sein.
Hier gibt es drei Möglichkeiten:
http://sunsite.unc.edu/mdw/HOWTO/Firewall-HOWTO.html
) gibt
weitere Informationen zu diesem Thema. Voraussetzung ist allerdings,
daß die Anwendungsprogramme der lokalen Rechner SOCKS-fähig sind.
Alan's Archiv wird an verschiedenen Stellen gespiegelt, z.B.:
ftp.Uni-Mainz.de:/pub/Linux/packages/Net2Debugged
ftp.infomagic.com:/pub/mirrors/linux/sunacm
Netzwerkcode und Kernel verwenden inzwischen angepaßte Versionsnummern, die Kernelversion erfährt man entweder mit
% uname -a
oder
% cat /proc/version
Die normale System-Meldung steht in der Datei /etc/issue
.
Einige telnetd
Programme verwenden für Netzwerk-Logins eine
andere Datei, /etc/issue.net
.
Einige Distributionen (Slackware) erstellen /etc/issue
bei
jeden Bootvorgang neu. Dies geschieht in der Datei
/etc/rc.d/rc.S
. Wem die dort erzeugte Meldung nicht gefällt,
muß die entsprechenden Zeilen auskommentieren.
Normalerweise deutet es darauf hin daß das Ethernet-Kabel nicht korrekt
eingesteckt ist, oder daß die Setup-Parameter der Ethernet-Karte
(I/O-Adresse, IRQ usw.) falsch eingestellt sind. Man überprüfe (mit
dmesg
) die Bootmeldungen und stelle sicher, daß die Karte mit
der richtigen Ethernet-Adresse gefunden wird. Ist dies der Fall liegt
eventuell ein Konflikt mit einer anderen Karte im Rechner vor, z.B. eine
Soundblaster, die denselben IRQ oder I/O-Port verwendet.
Außer dem offensichtlichen Fall eines defekten Ethernet-Kabels kann
diese Meldung auch durch eine falsch konfigurierte Ethernet-Karte
hervorgerufen werden. Eventuell sollte man die Einstellungen in
/usr/src/linux/drivers/net/CONFIG
überprüfen.
route
verwenden will?Die verwendete Version von route
ist für den Kernel zu alt.
Im Abschnitt `Das Programmpaket zur Netzwerk-Konfiguration' ist
beschrieben, woher man die aktuelle Version bekommt.
Die Meldung bedeutet, daß der eigene oder ein anderer Rechner nicht weiß, wohin er die Datagramme routen soll, die man an den angestrebten Zielrechner abgeschickt hat. Wenn die Meldung für alle Rechner auftritt, mit denen man sich in Verbindung setzen möchte, ist vermutlich die Default Route nicht oder falsch gesetzt, vergleiche dazu den Abschnitt über `routing'.
Das Problem liegt vermutlich im Routing, die Konfiguration sollte
nochmals anhand des entsprechenden Abschnittes `routing' überprüft
werden. Ist sie in Ordnung überprüft man als nächstes, daß der Host,
mit dem man kommunizieren will, eine Route zum eigenen Rechner
konfiguriert hat. Bei Modem-Verbindungen ist dies eine häufige
Ursache. Es muß sichergestellt sein daß auf dem Server ein Router-Dämon
wie gated
oder routed
läuft, und daß er ein Proxy
ARP für die einwählenden Rechner durchführt, da sonst die
Gegenseite die Datagramme zwar empfängt aber nicht weiß, wohin sie die
Antworten senden soll.
Im IPX-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/IPX-HOWTO.html
) wird
Software beschrieben, mit der diese Verbindung ohne NFS verwirklicht
werden kann.
Einige Hersteller (vornehmlich Sun) haben Rechner ausgeliefert, auf denen NFS standardmäßig ohne eine UDP Prüfsumme läuft. Dies bringt zwar Vorteile in einem Ethernet-Netzwerk, grenzt aber sonst schon an Daten-Mord. UDP Prüfsummen können auf jedem Server bei Bedarf eingeschaltet werden, Linux hat sie seit pl13 standardmäßig aktiviert. Wichtig ist, daß sie auf beiden Seiten verwendet werden.
Dies ist unter Linux die Standard-Einstellung für NFS-Dateisysteme.
Näheres dazu steht in der man
Online-Hilfe zu
exports(5)
und nfsd(8)
.
dip
benötigt die Adresse des Servers nicht wirklich, um eine
funktionierende SLIP-Verbindung aufzubauen. Die remote
-Option
wurde eingeführt, damit dip
die ifconfig
und
route
Befehle automatisieren kann. Wer die Adresse des Servers
nicht kennt und partout nicht herausbekommt, dem hilft vielleicht ein
Tip von Peter D. Junger (Junger@samsara.law.cwru.edu
): Er gibt immer die eigene
Adresse an, wenn im dip-Script nach der remote
Adresse gefragt
wird. Dies führt zu keinen weiteren Komplikationen, da die
Server-Adresse nie in einem SLIP-Header auftaucht.
dip
funktioniert nur für root. Wie kann ich normalen
Benutzern seine Verwendung ermöglichen?dip
muß setuid root laufen um einige der notwendigen Dinge wie
z.B. die Modifikation der Routing-Tabelle, durchzuführen.
Versionen älter als dip337o enthalten aber eine Sicherheitslücke und
sollten deshalb nicht setuid root laufen! In jedem Fall empfiehlt
Uri Blumenthal folgendes Vorgehen:
dip
in der Datei
/etc/group
, in die alle diejenigen Benutzer aufgenommen werden,
die eine Modem-Verbindung mit dip
aufbauen dürfen.
% chown root.dip /usr/bin/dip
% chmod u=rx,g=x,o= /usr/bin/dip
% chmod u+s /usr/bin/dip
Normalerweise deutet es darauf hin, daß der Kernel ohne Unterstützung
für SLIP kompiliert wurde. Man überprüfe, ob /proc/net/dev
die
Devices sl0
, sl1
usw. aufzeigt. Eine andere
Möglichkeit ist, daß die verwendete Version von dip
bereits
sehr alt ist, in diesem Fall sollte man sich eine neuere besorgen.
In diesem Fall ist meist das Modem für das XON/XOFF Flow Protokoll konfiguriert. Für SLIP muß die Verbindung 8-bit-clean sein, XON/XOFF darf also nicht verwendet werden. Die andere Alternative, Hardware handshaking, funktioniert sowieso besser, man sollte also diese verwenden. Wie man sie einstellt wird im Handbuch zum Modem beschrieben.
Vermutlich liegt der Grund in einer uneinheitlichen Verwendung der Header-Kompression. Beide Seiten müssen in dieser Einstellung übereinstimmen.
Wer dip
benutzt, für den genügt ein einfaches dip -k
,
dann werden alle nötigen Schritte durchgeführt. Wenn dip
dennoch weiterläuft sollte man versuchen, es manuell mit kill
zu beenden. Wenn der dip
-Prozeß gestorben ist, sollte das
Modem in jedem Fall aufgehängt haben. Das sicherste Vorgehen beim
manuellen `abschießen' von dip
ist folgendes: kill
<pid>
, kill -hup <pid>
und, wenn dip
immernoch läuft, schließlich kill -9 <pid>
. Dies ist
übrigens nicht auf dip
beschränkt sondern gilt für alle
Unix-Prozesse.
Die älteren Network Tools haben fälschlicherweise die komprimierten Pakete als `Overrun' gemeldet. Dies wurde aber inzwischen behoben und sollte unter neueren Kernels und Netz-Software nicht mehr auftreten. Treten die Fehler trotz neuer Versionen auf so kann der Rechner eventuell die ankommenden Datenpakete nicht schnell genug in Empfang nehmen. Wer in seiner seriellen Schnittstelle noch keine 16550AFN UARTs hat sollte sich überlegen, aufzurüsten. 16450er, oder 8250er generieren für jedes eingehende Byte einen Interrupt und sind deshalb darauf angewiesen, daß der Prozessor seine momentane Beschäftigung unterbrechen kann um dieses Byte zu übernehmen, damit es nicht verlorengeht. Der 16550AFN dagegen hat einen 16-Byte FIFO (first in first out, ein linearer Zwischenspeicher) und generiert einen Interrupt erst kurz bevor der FIFO voll ist. Dadurch werden weniger Interrupts erzeugt und das System muß weniger Zeit für die Bedienung der seriellen Schnittstelle aufwenden. Wer sogar mehrere serielle Schnittstellen betreiben will sollte also in jedem Fall die 16550AFN UARTs verwenden.
Ja. Hat man zum Beispiel drei Rechner, die man verbinden will, kann man ohne weiteres auf einem der Rechner zwei SLIP-Verbindungen, je eine zu jedem der beiden anderen, konfigurieren. Die zweite Verbindung unterscheidet sich dabei in nichts von der ersten, jedoch benötigt das zweite Interface eine andere IP-Adresse als das erste. Eventuell muß man etwas mit dem Routing herumexperimentieren, aber es sollte funktionieren.
Der SLIP-Code im Kernel verwendet eine Standardeinstellung von maximal 4
SLIP Devices. Dies wird festgelegt in der Datei
/usr/src/linux/drivers/net/slip.h
. Um den Grenzwert zu erhöhen
muß er in der Definition #define SL_NRUNIT
anstelle der dort
angegebenen 4
eingesetzt werden. Weiterhin muß man die Datei
/usr/src/linux/drivers/net/Space.c
editieren und Abschnitte für
sl4
, sl5
usw. einfügen. Die bestehenden Definitionen
können dabei als Basis verwendet werden. Nach diesen Veränderungen muß
dann der Kernel neu kompiliert und installiert werden.
Diese werden ausführlich im PPP-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/PPP-HOWTO.html
) behandelt.