Nachdem Du ein Netzwerk-Interface eingerichtet und eine Route
dafür definiert hast, werden alle IP-Pakete, für die eine
Route dorthin eingestellt wurde, zu diesem Interface geleitet. Wenn
autodial aktiviert wurde (siehe Frage
dialout_dialmode zu den Dialmodes), wird das Interface beim
Vorliegen von abzusendenden IP-Paketen automatisch eine Hinauswahl
durchführen. Das bedeutet, daß jeder Benutzer eine
Hinauswahl verursachen kann.
Beispiel: Du öffnest einen Browser mit leerer Startseite oder mit
einer lokalen Homepage. Es passiert nichts. Wenn Du nun einen URL
eingibst, werden dadurch IP-Pakete zum Netzwerk-Interface gesendet und
es wird eine Hinauswahl ausgelöst.
Der Gebrauch von dial-on-demand ist ein gefährliches (=
kostspieliges) Feature: siehe Frage
dod_disaster.
Der Gebühren-GAU kann aus verschiedenen Gründen eintreten
(Details unter
dod_causes). Das Resultat
ist jedoch gleich: Dein Computer wählt Deinen ISP öfter an
als Dir lieb ist und erhöht dadurch Deine Telefonrechnung um
einen großen Betrag (besonders dann, wenn Du nicht nur die
Online-Zeit sondern auch einen Mindestbetrag/Einheitsbetrag für
jede Einwahl bezahlen musst). Der Ausdruck 'großer Betrag' ist
recht dehnbar. Alles ist möglich:
"Billig": Jede DNS-Anfrage öffnet die Leitung und
verursacht mehrere Wählvorgänge pro Tag (ja nach Deinen
Programmen). Bei 10 Vorgängen pro Tag sind das etwa 300
unnötige Wählvorgänge pro Monat.
"Nicht ganz so billig": Irgendein Windows 95 Computer in Deinem
LAN löst alle 15 Minuten einen Wählvorgang für eine
seiner albernen Meldungen aus (siehe Frage
dod_win95). Das macht 96 Anwahlen pro Tag oder 2880 pro Monat.
"Mittelmaß": Dein Email-Programm ist so eingestellt,
daß es alle 5 Minuten prüft, ob neue Nachrichten bei Deinem
ISP bereit liegen. Das ergibt 288 Wählvorgänge pro Tag, 8640
pro Monat.
"Kostspielig": 'Keep alive'-Pakete verhindern, daß Deine
Verbindung je getrennt wird. Du bist dauernd online. Hinweis: DIES IST
NICHT DER SCHLIMMSTE FALL!
"Noch kostspieliger": Irgend etwas geht schief mit den
dynamischen Addressen und es bleiben beim Auflegen offene Sockets
übrig. Diese lösen beim Versuch, das Problem zu lösen,
eine neue Anwahl aus. Da Du jetzt aber eine neue IP-Addresse hast,
kann das Problem nicht aufgelöst werden. Die Verbindung wird
schließlich beendet (abhängig von Deiner
Timeout-Einstellung), wird aber sofort wieder hergestellt, da die
Sockets eine weitere Anwahl auslösen. Hast Du kein Glück, so
bekommst Du nie die gleiche IP-Addresse wieder und die Sache
wiederholt sich endlos. Du bist fast dauernd online, jedoch musst Du
zusätzlich noch für viele Wählvorgänge bezahlen:
Wenn Dein Timeout auf 30 Sekunden steht, werden daraus 2880
Wählvorgänge pro Tag, 86400 pro Monat.
"Am kostspieligsten - Schlimmster Fall": Du konfigurierst
dialout/callback falsch. Wenn Dein (der initiierende) Computer Deinen
ISP anwählt und dieser dann die Verbindung abbricht (weil
z.B. die Anmeldung fehlschlägt - vielleicht ist er auch falsch
konfiguriert), so wählt Dein Computer sofort neu. Dies wird nur
begrenzt durch die Zeit, die für das Wählen benötigt
wird. Wenn wir für jeden Versuch 2 Sekunden veranschlagen
(konservativ geschätzt), werden daraus 43200 Vorgänge pro
Tag oder 1296000 pro Monat!
Dies ist kein Scherz, all diese Dinge sind tatsächlich passiert,
sogar bei richtigen ISDN4LINUX-Experten! Schau bei Frage
dod_off nach, wie Du jedes Risiko, daß dies
Dir passiert, vermeiden kannst.
Da gibt es viele Möglichkeiten. Bei Frage
dod_strategy erfährst Du, wie Du herausfindest was gerade
passiert. Bei der Frage
dod_disaster
erfährst Du dann, wie teuer das sein kann. Es folgt eine nicht
vollständige Liste von Ursachen:
Du hast Deinen Kernel irrtümlich mit der Option Bridging
kompiliert.
ARP Anfragen oder Broadcasts? Du solltest ifconfig mit
den Optionen -arp und -broadcast aufrufen und
dadurch das Herstellen von Verbindungen aus diesen Gründen
vermeiden. Du erkennst diese Ursache daran, daß Du einen
Wählvorgang hast aber keine Daten übertragen werden.
Andere Broadcasts von den Interfaces werden von ISDN
weitergeleitet.
Wenn IP-Verbindungen noch geöffnet sind während die
Leitung geschlossen wird und die IP-Addressen dynamisch vergeben
werden, ist die Katastrophe unausweichlich. Es wird eine neue
Verbindung aufgebaut, um die offenen IP-Verbindungen zu
schließen. Das misslingt, da die neue IP-Addresse anders
lautet. Die Leitung wird aufgelegt aber die offenen IP-Verbindungen
sind immer noch vorhanden. Daher wird neu gewählt, und so
weiter...
Dies wird nur durch den RST-Revoking Patch vermieden, der in die
Kernel 2.0.x eingebunden ist, jedoch nicht in den Kerneln
2.1/2.2/2.3. Du kannst jedoch einen angepassten Patch für die
Kernel 2.2.x und etwas Hintergrundwissen dazu von
http://www.another.de/linux/router/ bekommen. Sieh Dir dazu
auch die Frage
syncppp_1stpacketan.
Beachte auch, daß Du die Option "defaultroute" des ipppd benutzt
statt route add/del default in ip-up/ip-down.
TCP-Wiederholversuche lösen Hinauswahlen aus: wenn der
Kernel versucht, TCP-Pakete zu senden und keine Antwort bekommt, wird
er versuchen, die Sendung zu wiederholen (normalerweise alle 120
Sekunden). Prüfe, ob Du die folgenden Parameter anpassen willst:
/proc/sys/net/ipv4/tcp_syn_retries
/proc/sys/net/ipv4/tcp_retries1
/proc/sys/net/ipv4/tcp_retries2
Dazu gehörende Dokumentation findest Du in
/usr/src/linux/Documentation/proc.txt.
Anfragen von Deinem lokalen DNS lösen einen
Wählvorgang aus: siehe Frage
dod_localdns.
Sendmail löst den Wählvorgang aus: siehe Frage
dod_sendmail.
Wenn Du immer manuell wählen willst, setze den Dialmode auf
manual (siehe Frage
dialout_dialmode). Dann benutze isdnctrl dial
<device> zum Hinauswählen und isdnctrl hangup
<device> zum Beenden der Verbindung.
Richte Deinen Dialmode korrekt ein (siehe Frage
dialout_dialmode). Setze z.B. den Dialmode
auf manual in ip-down. Dann findet eine automatische
Hinauswahl nur einmal statt, wenn Du den Dialmode auf auto setzt.
Entferne die Telefonnummer des Interfaces oder stelle eine
ungültige Nummer ein. Dann kannst Du an den Beschwerden im syslog
sehen, ob ein Prozess Pakete in die Welt hinaus schicken will.
Schalte das System ab.
Lösche die Route zum ISDN-Device.
Ein Beispiel, wie jedes automatische Wählen vermieden wird:
/sbin/route del default
/sbin/isdnctrl system off
/sbin/ifconfig ippp0 down
So läuft wieder alles normal:
/sbin/isdnctrl system on
/sbin/ifconfig ippp0 up
/sbin/route add $GATE-IP dev ippp0
/sbin/route add default ippp0
Diese Methode hat den Nachteil, daß überhaupt kein
Wählvorgang möglich ist.
Das Finden der Ursache von unerwarteten Wählvorgängen ist
der erste Schritt, sie zu stoppen.
Dieses Finden ist jedoch normalerweise schwieriger als die
Problemlösung. Hier sind Vorschläge, was Du tun kannst:
Zuerst trennst Du Deinen Dialout-Server von Deinem LAN, um
herauszufinden, wer für die Wählvorgänge verantwortlich
ist: der Dialout-Server selbst oder ein Client in Deinem LAN. Bei
Windows Clients siehe Frage
dod_winclient.
Versuche, mit 'isdnctrl verbose 3' herauszufinden, welches
TCP/IP-Paket die Verbindung auslöst. Es sollte in den
Kernelmeldungen (anzusehen mit dmesg) etwas in dieser Art
auftauchen: OPEN: 141.76.60.54 - 193.171.67.253 TCP, port: 1686 -
540. In diesem Beispiel versucht unser Computer, auf dem Port 540
Mail abzuholen (UUCP über TCP/IP über ISDN) - die Portnummer
kann man in /etc/services nachsehen. Beachte bitte, daß
nur das auslösende Paket gemeldet wird.
Wenn Du ipppd benutzt: erstelle ein tcpdump, das Dir die Daten
der syncPPP encapsulation zeigt (dazu benötigst Du eventuell
einen Patch - siehe Frage
trouble_tcpdump).
Versuche, einen Systemdienst nach dem anderen zu deaktivieren
und prüfe, ob sich die Sache beruhigt. named, sendmail und auch
smbd (Samba) sind gute Kandidaten für das Aufbauen von
Verbindungen (siehe Fragen
dod_localdns,
dod_sendmail,
dod_samba).
Wenn broadcasts das Problem sind, kannst Du auch die
Zieladdresse auf das dummy0-Interface legen. Das ist zwar nicht sauber
aber es funktioniert.
Ja. Beim Start von Windows 3.11/95 versucht dieses, sich mit dem
Nameserver Deines Providers zu unterhalten (falls bekannt) um einige
Domains aufzulösen (z.B. WORKGROUP.xxx). Hier folgen
Möglichkeiten, dieses zu vermeiden:
Schalte die Option Use DNS for Windows Names
Resolution auf allen Windows-Computern Deines LAN ab.
Setze einen lokalen DNS auf, der alle Anfragen
beantwortet. Siehe Frage
dod_localdns.
Schalte in named den Debug-Level 1 ein und schau Dir das Logfile in
/var/tmp an. Du findest da sehr oft normale DNS-Anfragen von
Windows-Maschinen. Das Problem ist, daß Namen wie
"WORKGROUP.domain.de" abgefragt werden, d.h., Namen, die der DNS nicht
kennen kann. Windows scheint nach seinem master browser oder einem
Domain-Controller zu suchen (deutschsprachige Leser finden in der ct
12/99, Seite 224: "Schnitzeljagd - Netzwerkumgebung und Browserdienst
im Windows-Netzwerk" weitere Details). Zur Umgehung dieses Problems
muss der Name der Workgroup per DNS aufgelöst werden
können. Oder setze einen Primary Domain Controller in Deinem LAN
ein.
Von Zeit zu Zeit wird der Nameserver eine Anfrage an seinen Forwarder
schicken. Das löst eine Anwahl aus. Da Dein ISP dynamische
IP-Adressen benutzt wird die Anfrage mit einer falschen IP-Adresse
hinaus geschickt (zum Zeitpunkt der Starts der Verbindung). Also wird
keine Antwort empfangen. Bind wartet eine Minute und wiederholt den
Vorgang. Wenn Deine Verbindung in dieser Zeit getrennt wurde,
löst das einen neuen Wählvorgang mit wiederum einer anderen
Adresse aus, usw.n...
Als Workaround kannst Du die Wartezeit zwischen den Sendeversuchen
verkürzen, wie es bei der Frage
dialout_bind beschrieben wird.
Alternativ kannst Du die Option "dialup yes;" in der
named.conf setzen. Dadurch wird named beim Start nur eine Interaktion
mit dem Verteiler durchführen (und dabei ein Auswählen
auslösen). Danach wird named ein sehr langes Intervall (24h?)
abwarten ehe er eine erneute Abfrage startet.
named wird nur bei direkten Anfragen mit dem Verteiler in Kontakt treten
und das passiert im Normalfall wenn Du sowieso verbunden bist.
Zuerst musst Du sendmail dazu bringen, keine DNS-Verbindungen zu
öffnen. Du musst die Optionen 'nodns' und 'nocanonify'
aktivieren.
Wenn Du einen smarthost hast, musst Du sicherstellen, daß wegen
ihm kein Nameserver abgefragt wird. Du kannst den smarthost direkt mit
seiner IP-Addresse angeben oder seinen Namen in /etc/hosts eintragen
(/etc/host.conf sollte dann die Zeile 'order hosts bind' enthalten).
Setze alle nicht lokalen Mailer auf 'expensive'
('define(SMTP_MAILER_FLAGS, e)') und verbiete dann sendmail,
automatisch über diese teueren Wege zu verbinden (mit
einem 'define('confCON_EXPENSIVE", 'True')'). Der Aufruf von sendmail sollte
keine Zeitangabe für die Option '-q' enthalten (d.h., nur '-bd
-os -q'). '-os' bewirkt, daß alle Mails in die Warteschlange
eingereiht werden (was nicht verhindert, daß lokale Mails sofort
ausgeliefert werden). Der einzige Haken ist, daß sendmail beim
Booten Mail, die noch in der Warteschlange liegt, ausliefern will,
obwohl das Netzwerk noch nicht läuft. Deshalb solltest Du beim
Booten alle Mails aus /var/mqueue entfernen bevor sendmail gestartet
wird und nach dem Start von sendmail wieder dort ablegen.
Mail an teuere Mailer wird nun nur durch den expliziten
Aufruf 'sendmail -q' abgeschickt.
Andreas Glahn andreas@tao.westfalen.de schrieb am 31 Januar 1997: Ich
hatte das gleiche Problem. Dann gab ich beim Start des Samba-Demons
diesem die interne IP-Addresse, die ich hier zuhause benutze. Seither
wird eine Anfrage von Samba nicht mehr an das default gateway
geschickt sondern bleibt intern.
Schau Dir die Konfiguration mit netstat und tcpdump an. Mit tcpdump
findest Du schnell heraus, zu welcher IP-Addresse Samba verbinden
will.
Mein interner Linux Computer hat z.B.: 192.168.99.99
und
mein Win95 Computer hat: 192.168.99.88
Auf dem Linux Computer starte ich Samba mit:
nmdb -S -B 192.168.99.255 -I 192.168.99.99
Schau Dir auch die vorherige Frage an: benutze -broadcast und
vielleicht -arp bei der Definition des Interfaces!
Durchsuche die Hilfeseiten der Samba-Konfigurationsdatei nach weiteren
Möglichkeiten des Vermeidens von Auswählvorgängen (mir
wurde gesagt, daß es einige spezielle Parameter dafür geben
soll).
Meistens ist in den Preferences eine nicht lokale Homepage
eingetragen. Nur eine Homepage, die Netscape sofort laden kann
(z.B. 'file://localhost/xxx'), löst keinen sofortigen
Wählvorgang aus. Alternativ kannst Du einen Cache Demon
einrichten, der oft benötigte Seiten speichert.
Des weiteren prüfe Deine Proxy-Einstellungen. Wenn Netscape einen
kompletten Namen anstatt einer IP-Adresse beim Start bekommt, kann es
versuchen, den Namen durch eine DNS-Anfrage aufzulösen. In dem
Fall gib Netscape eine IP-Adresse.
Auch kann es sein, daß Netscape versucht, seinen Newsserver zu
erreichen. Wenn Du dieses Feature nicht benötigst, kannst Du den
Newsserver, den Netscape sucht (vermutlich 'news') in Deinen lokalen
DNS oder in die /etc/hosts aufnehmen und auf 'localhost' verweisen.
Dies mag nur mit dem RST-Revoking-Patch (auf den in Frage
dod_causes hingewiesen wird) funktionieren:
Du kannst das Interface 'runterfahren' und dann wieder 'starten'. Dann
wird es versuchen, hinaus zu wählen. Wenn Du aber vorher die
anzuwählende Telefonnummer entfernt hast, erhältst Du die
Meldung 'no outgoing number...' im syslog und sobald das Interface
wieder gestartet ist werden alle offenen Verbindungen geschlossen.
Du kannst diese durch offene IP-Verbindungen ausgelösten
Wä,hlversuche vermeiden, indem Du eine spezielle
Firewall-Einstellung in /etc/ppp/ip-down einfügst und
sie in /etc/ppp/ip-up wieder deaktivierst. Diese
Firewall-Einstellung wehrt alle TCP-Pakete, die nicht den Status
SYNSENT haben, ab. Füge dies in Deine /etc/ppp/ip-down
ein (bei einem 2.2.x kernel):
Der ISAC Chipset, der auf vielen ISDN-Karten benutzt wird, kann im
auto Modus oder im non-auto Modus laufen. Im auto Modus kann die
Verbindung bei abgestürztem Computer bestehen bleiben (die Karte
hält sie am Leben). Da der HiSax Treiber den non-auto Modus
benutzt, sollte das mit ISDN4LINUX nicht passieren. Wenn einmal kein
Interrupt mehr auf Deiner Maschine verarbeitet wird, wird die
Verbindung spätestens nach einer halben Minute beendet. Ein
Weiterbestehen der Verbindung kann nur in dem unwahrscheinlichen Fall
passieren, wenn die Maschine abstürzt, jedoch Interrupts
weiterhin normal verarbeitet werden.