Nachdem Du ein Netzwerk-Interface eingerichtet und eine Route
daf{[uuml ]}r definiert hast, werden alle IP-Pakete, f{[uuml ]}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{[uuml ]}hren. Das bedeutet, da{[szlig ]} jeder Benutzer eine
Hinauswahl verursachen kann.
Beispiel: Du {[ouml ]}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{[ouml ]}st.
Der Gebrauch von dial-on-demand ist ein gef{[auml ]}hrliches (= kostspieliges) Feature: siehe Frage dod_disaster.
Der Geb{[uuml ]}hren-GAU kann aus verschiedenen Gr{[uuml ]}nden eintreten (Details unter dod_causes). Das Resultat ist jedoch gleich: Dein Computer w{[auml ]}hlt Deinen ISP {[ouml ]}fter an als Dir lieb ist und erh{[ouml ]}ht dadurch Deine Telefonrechnung um einen gro{[szlig ]}en Betrag (besonders dann, wenn Du nicht nur die Online-Zeit sondern auch einen Mindestbetrag/Einheitsbetrag f{[uuml ]}r jede Einwahl bezahlen musst). Der Ausdruck 'gro{[szlig ]}er Betrag' ist recht dehnbar. Alles ist m{[ouml ]}glich:
Dies ist kein Scherz, all diese Dinge sind tats{[auml ]}chlich passiert, sogar bei richtigen ISDN4LINUX-Experten! Schau bei Frage dod_off nach, wie Du jedes Risiko, da{[szlig ]} dies Dir passiert, vermeiden kannst.
Da gibt es viele M{[ouml ]}glichkeiten. Bei Frage dod_strategy erf{[auml ]}hrst Du, wie Du herausfindest was gerade passiert. Bei der Frage dod_disaster erf{[auml ]}hrst Du dann, wie teuer das sein kann. Es folgt eine nicht vollst{[auml ]}ndige Liste von Ursachen:
ifconfig
mit
den Optionen -arp
und -broadcast
aufrufen und
dadurch das Herstellen von Verbindungen aus diesen Gr{[uuml ]}nden
vermeiden. Du erkennst diese Ursache daran, da{[szlig ]} Du einen
W{[auml ]}hlvorgang hast aber keine Daten {[uuml ]}bertragen werden.route add/del default
in ip-up/ip-down./usr/src/linux/Documentation/proc.txt
.
manual
(siehe Frage
dialout_dialmode). Dann benutze isdnctrl dial
{[lt ]}device{[gt ]}
zum Hinausw{[auml ]}hlen und isdnctrl hangup
{[lt ]}device{[gt ]}
zum Beenden der Verbindung.manual
in ip-down
. Dann findet eine automatische
Hinauswahl nur einmal statt, wenn Du den Dialmode auf auto
setzt./sbin/route del default /sbin/isdnctrl system off /sbin/ifconfig ippp0 down
/sbin/isdnctrl system on /sbin/ifconfig ippp0 up /sbin/route add {[dollar]}GATE-IP dev ippp0 /sbin/route add default ippp0
Das Finden der Ursache von unerwarteten W{[auml ]}hlvorg{[auml ]}ngen ist der erste Schritt, sie zu stoppen. Dieses Finden ist jedoch normalerweise schwieriger als die Probleml{[ouml ]}sung. Hier sind Vorschl{[auml ]}ge, was Du tun kannst:
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 {[uuml ]}ber TCP/IP {[uuml ]}ber ISDN) - die Portnummer
kann man in /etc/services
nachsehen. Beachte bitte, da{[szlig ]}
nur das ausl{[ouml ]}sende Paket gemeldet wird.Ja. Beim Start von Windows 3.11/95 versucht dieses, sich mit dem Nameserver Deines Providers zu unterhalten (falls bekannt) um einige Domains aufzul{[ouml ]}sen (z.B. WORKGROUP.xxx). Hier folgen M{[ouml ]}glichkeiten, dieses zu vermeiden:
Use DNS for Windows Names
Resolution
auf allen Windows-Computern Deines LAN ab.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{[szlig ]} 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{[ouml ]}st werden
k{[ouml ]}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{[ouml ]}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{[ouml ]}st das einen neuen W{[auml ]}hlvorgang mit wiederum einer anderen Adresse aus, usw.n...
Als Workaround kannst Du die Wartezeit zwischen den Sendeversuchen verk{[uuml ]}rzen, wie es bei der Frage dialout_bind beschrieben wird.
Alternativ kannst Du die Option {[quot ]}dialup yes;{[quot ]} in der named.conf setzen. Dadurch wird named beim Start nur eine Interaktion mit dem Verteiler durchf{[uuml ]}hren (und dabei ein Ausw{[auml ]}hlen ausl{[ouml ]}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 {[ouml ]}ffnen. Du musst die Optionen 'nodns' und 'nocanonify' aktivieren.
Wenn Du einen smarthost hast, musst Du sicherstellen, da{[szlig ]} 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{[lowbar]}MAILER{[lowbar]}FLAGS, e)') und verbiete dann sendmail, automatisch {[uuml ]}ber diese teueren Wege zu verbinden (mit einem 'define('confCON{[lowbar]}EXPENSIVE", 'True')'). Der Aufruf von sendmail sollte keine Zeitangabe f{[uuml ]}r die Option '-q' enthalten (d.h., nur '-bd -os -q'). '-os' bewirkt, da{[szlig ]} alle Mails in die Warteschlange eingereiht werden (was nicht verhindert, da{[szlig ]} lokale Mails sofort ausgeliefert werden). Der einzige Haken ist, da{[szlig ]} sendmail beim Booten Mail, die noch in der Warteschlange liegt, ausliefern will, obwohl das Netzwerk noch nicht l{[auml ]}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
Durchsuche die Hilfeseiten der Samba-Konfigurationsdatei nach weiteren M{[ouml ]}glichkeiten des Vermeidens von Ausw{[auml ]}hlvorg{[auml ]}ngen (mir wurde gesagt, da{[szlig ]} es einige spezielle Parameter daf{[uuml ]}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{[ouml ]}st keinen sofortigen W{[auml ]}hlvorgang aus. Alternativ kannst Du einen Cache Demon einrichten, der oft ben{[ouml ]}tigte Seiten speichert.
Des weiteren pr{[uuml ]}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{[ouml ]}sen. In dem Fall gib Netscape eine IP-Adresse.
Auch kann es sein, da{[szlig ]} Netscape versucht, seinen Newsserver zu erreichen. Wenn Du dieses Feature nicht ben{[ouml ]}tigst, kannst Du den Newsserver, den Netscape sucht (vermutlich 'news') in Deinen lokalen DNS oder in die /etc/hosts aufnehmen und auf 'localhost' verweisen.
netstat -nt
fest, da{[szlig ]} IP-Verbindungen noch offen sind. Wie kann ich diese manuell schlie{[szlig ]}en?
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{[auml ]}hlen. Wenn Du aber vorher die anzuw{[auml ]}hlende Telefonnummer entfernt hast, erh{[auml ]}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{[ouml ]}sten
W{[auml ]},hlversuche vermeiden, indem Du eine spezielle
Firewall-Einstellung in /etc/ppp/ip-down
einf{[uuml ]}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{[uuml ]}ge dies in Deine /etc/ppp/ip-down
ein (bei einem 2.2.x kernel):
ipchains -A output -j DENY -p tcp -i 'interface' ! -y
/etc/ppp/ip-up
:
ipchains -A output -j DENY -p tcp -i 'interface' ! -y
Beachte, da{[szlig ]} diese Firewall-Regel nur ganze Pakete betrifft. Fragmente werden immer diese Firewall passieren und einen W{[auml ]}hlvorgang ausl{[ouml ]}sen.
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{[uuml ]}rztem Computer bestehen bleiben (die Karte h{[auml ]}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{[auml ]}testens nach einer halben Minute beendet. Ein Weiterbestehen der Verbindung kann nur in dem unwahrscheinlichen Fall passieren, wenn die Maschine abst{[uuml ]}rzt, jedoch Interrupts weiterhin normal verarbeitet werden.