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:
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.route add/del default
in ip-up/ip-down.
manual (siehe Frage
dialout_dialmode). Dann benutze isdnctrl dial
<device> zum Hinauswählen und isdnctrl hangup
<device> 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 $GATE-IP dev ippp0 /sbin/route add default ippp0
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.
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 '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
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.
Ein Proxy dürfte keine Anwahl auslösen, selbst wenn der komplette Name
eingegeben wird. Nur bei Angabe eines neuen Proxy fragt Netscape einen
DNS ab und löst dadurch einen Wählvorgang aus. Steffan Henke
henker@informatik.uni-bremen.de schrieb jedoch am 17. März
1997:
Unglücklicherweise hat uns die Wirklichkeit eingeholt. Ich hörte, daß Netscape jetzt in Version.4.02 tatsächlich eine Verbindung aufbaut...
netstat -nt fest, daß IP-Verbindungen noch offen sind. Wie kann ich diese manuell schließen? 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.
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.