- Was ist isdn4linux?
isdn4linux ist ein Satz von Kernel-Modulen, um dem Linux-Kernel ISDN
"beizubringen". Es besteht aus einem Hauptmodul ("isdn") und den
eigentlichen Hardwaretreibern, die die spezielle Hardware einzelner
Karten ansteuern.
- Was kann isdn4linux?
ISDN4linux steuert ISDN-PC-Steckkarten an und kann dabei ein Modem mit
Hayes-Befehlssatz ("AT"-Befehle) emulieren. Die Möglichkeiten sind
sehr vielfältig, sie reichen von einer einfachen Anwendung von
Terminalprogrammen, über HDLC (die Verwendung eigener ISDN-Devices), bis
zur Vollanbindung an's Internet mit PPP - und sogar Audio-Anwendungen sind
möglich.
- Was kann isdn4linux noch nicht?
Noch sind keine Vollduplex-Audio-Verbindungen machbar.
Es fehlt noch das eine oder andere Protokoll (V.110, amerikanische
Protokolle).
- Kann ich isdn4linux in Nordamerika einsetzen?
Siehe dazu die entsprechende Frage im Kapitel "Nationale Besonderheiten".
- Was benötige ich für isdn4linux?
Seit Kernel 1.2.59 ist isdn4linux fester Bestandteil des Linux-Kernel.
Zusätzlich benötigt wird das Paket isdn4k-utils-2.0.tar.gz und ggf.
der HiSax-Treiber.
- Wo gibt es isdn4linux?
Via FTP:
Das Paket liegt auf ftp://ftp.franken.de/pub/isdn4linux und
diversen Spiegeln.
Via Modem/ISDN:
Vom Linux-Server der Incubus-BBS (Login gast,
Verzeichnis /pub/linux/isdn4linux, ZModem senden mit 'sz filname') gesaugt
werden. Der Server ist unter folgenden Nummern erreichbar:
+49 931 781464 Zyxel U-1496E V.32(bis), V.42(bis), Zyxel 19200
+49 931 781465 Atrie 1914A V.32(bis), V.42(bis), V32terbo
+49 931 781467 Atrie 1914A V.32(bis), V.42(bis), V32terbo
+49 931 781468 Atrie 1914A V.32(bis), V.42(bis), V32terbo
Neuer Ringdown (16 Lines. Hier zuerst als 'bbs' einloggen):
+49 931 79002055 Motorola 3400 V.32(bis), V.42(bis), V.34
ISDN (ebenfalls zuerst als 'bbs' einloggen):
+49 931 7840724 ICN X.75 2 B-Kanäle
+49 931 7841020 ICN X.75 2 B-Kanäle
+49 931 7841060 ICN X.75 2 B-Kanäle
+49 931 7841070 ICN X.75 2 B-Kanäle
+49 931 7841080 ICN X.75 2 B-Kanäle
Hier eine Liste von Mirrors, deren Grundstock dankenswerterweise von Herbert
Rosmanith <herp@wildsau.idv-edu.uni-linz.ac.at> zusammengestellt wurde. Wer
weitere Mirrors kennt, möge sie uns mitteilen!
ftp://freja.frontier.dk/linux/isdn4linux/
ftp://ftp.cs.tu-berlin.de/pub/net/isdn/isdn4linux/
ftp://ftp.fokus.gmd.de/.mount2/pub/Linux/isdn/isdn4linux/
ftp://ftp.franken.de/pub/isdn4linux/
ftp://ftp.germany.eu.net/pub/os/Linux/Local.EUnet/ISDN/isdn4linux/
ftp://ftp.kiss.de/pub/linux/isdn4linux/
ftp://ftp.leo.org/pub/comp/os/linux/isdn/isdn4linux/
ftp://ftp.lame.org/mirrors/isdn/
ftp://ftp.mathematik.th-darmstadt.de/pub/linux/mirrors/misc/isdn4linux/
ftp://ftp.nvg.unit.no/pub/linux/isdn/
ftp://ftp.pop.de/pub/local/linux/isdn/
ftp://ftp.rz.fh-hannover.de/pub/linux/local/isdn4linux/
ftp://ftp.rz.hu-berlin.de:/pub/linux/isdn4linux/
ftp://ftp.tu-dresden.de/pub/soft/isdn/isdn4linux/
ftp://ftp.uni-mainz.de/pub/internet/starter-kit/isdn/isdn4linux/
ftp://ftp.uni-wuppertal.de/pub/linux/isdn4linux/
ftp://ftp.xlink.net/pub/mirror.ftp.franken.de/isdn4linux/
ftp://fvkma.tu-graz.ac.at/pub/isdn4linux/
ftp://wildsau.idv.uni-linz.ac.at/pub/isdn4linux/
- Was sollte ich unbedingt lesen?
ISDN-Kernelsubsystem: /usr/src/linux/Documentation/isdn/README
ISDN-Steckkarte: /usr/src/linux/Documentation/isdn/README.<Karte>
Synchrones PPP: /usr/src/linux/Documentation/isdn/README.syncppp
/usr/src/linux/Documentation/isdn/README.syncPPP.FAQ
Voice capability: /usr/src/linux/Documentation/isdn/README.audio
ISDN Utilities: /usr/src/isdn4k-utils-<version>/README(.*)
Des weiteren existieren zu vielen Hilfsprogrammen Man-Pages!
In einer Suse-Distribution könnten u.U. noch folgende Informationen
hilfreich sein:
Synchrones PPP: /usr/doc/faq/faq/PPP-FAQ
Konfiguration Email: /usr/doc/howto/mini/Mail-Queue.gz
- Welche hilfreiche Links gibt es rund um isdn4linux?
Scripte und Installationstips von vielen Leuten:
http://www.rosat.mpe-garching.mpg.de/~web/ISDN.html
I4l, syncPPP, email, Usenet, Voicebox, diese FAQ und mehr:
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
Michael Hipp's page (ipppd):
http://www.sfs.nphil.uni-tuebingen.de/~hipp/isdn/
Chargeint-Anleitung:
http://www.provi.de/~gvz/chargeint.html
Stefan Nehlsen's Anleitung für sync-ppp:
http://www.techfak.uni-kiel.de/~stn/i4l/
xled (früher xvboxled) gibt es auf:
fb4-1112.uni-muenster.de/pub/ffwd/
Beispielkonfigurationen zu isdn4linux soll es auch geben auf:
http://www.datenhighway.com/isdn4linux.html
Diese FAQ sowie isdn4linux gibt es auf:
ftp://ftp.franken.de/pub/isdn4linux/
Die FAQ gibt es auch auf:
ftp://ftp.pop.de/pub2/linux/isdn4linux/FAQ
- Gibt es eine Mailinglist zu isdn4linux?
Ja, die gibt es. Um daran teilzunehmen, schickt man eine Mail an
"majordomo@hub-wue.franken.de". Der Betreff der Nachricht ist egal. Im
Nachrichtentext gibt man an: "subscribe isdn4linux <emailadresse>".
Im Feld <emailadresse> gibt man die Adresse an, an die die Mails aus der
Liste geschickt werden sollen. Z.Zt. kommen etwa 20-50 Mails pro Tag.
- Wie kann ich die Mailingliste zu isdn4linux wieder abbestellen?
Um die Mailingliste wieder abzubestellen, schickt man wieder eine Mail
an majordomo@hub-wue.franken.de - Betreff der Nachricht ist egal.
Im Nachrichtentext: unsubscribe isdn4linux <emailadresse>. Man gibt im
Feld <emailadresse> die Adresse an, an die die Mails aus der Liste
bisher geschickt wurden.
- Gibt es die Mailingliste auch als Newsgruppe?
Ja, auf die Mailingliste kann man auch über de.alt.comm.isdn4linux
zugreifen - ein bidirektionales Gateway sorgt dafür, daß man auch antworten
kann.
- Gibt es ein Archiv der Mailingliste isdn4linux?
Ja, auf dem Rechner hub-wue.franken.de werden alle Mails zu der
Mailingliste gesammelt (unsortiert). Die Mails werden in Files nach Monaten
getrennt gesammelt. Um an die Archive zu kommen, schreibt man eine Mail an
majordomo@hub-wue.franken.de, Betreff ist egal. Folgende Befehle sind
möglich:
index isdn4linux - zeigt, welche Archive vorhanden sind
get isdn4linux <archivname> - holt das File <archivname>
Die Archive heißen "archiv.<jahr><monat>", also z.B. "archiv.9610"
für den Oktober 1996.
Ein Archiv der Mailinglist ist außerdem über FTP verfügbar:
ftp://ftp.uni-oldenburg.de/pub/unix/linux/isdn/isdn4linux/Mailing-List
Ein weiteres Archiv findet sich laut Sascha Ottolski
<sascha@alzhimer.isdn.cs.tu-berlin.de> unter:
http://wws.mathematik.hu-berlin.de/ldr/ISDN/isdn4linux/
- In welchen Ländern funktioniert isdn4linux?
Wir wissen derzeit von folgenden Ländern:
Deutschland
Finnland
Frankreich
Italien
Niederlande
Norwegen
Österreich
Peru
Portugal
Schweden
Schweiz
Spanien
USA
- Ist isdn4linux postzugelassen?
Deutschland:
Das kommt auf den verwendeten Treiber an. Bei aktiven Karten besitzt die
Karte mitsamt der Firmware eine Zulassung. Diese Karten sind auch beim
Betrieb mit isdn4linux zugelassen. Der Telestreiber besitzt in
Deutschland keine Zulassung (obwohl er hervorragend funktioniert!).
Er darf deshalb nur an einer postzugelassenen Telekommunikationsanlage
am internen S0-Bus betrieben werden.
Andere Länder:
Hier verfügen wir noch nicht über irgendwelche Informationen.
Wer weiß mehr?
- Welche Version ist aktuell?
Derzeit ist die Version isdn4k-utils-2.0 als Zusatz zu der im Kernel
enthaltenen Software erforderlich. Wer Kernel 2.0.0 (und nur der!) benutzt,
muß zwei Patches einspielen (isdn4kernel-2.0-patch1+2). Kernel 2.0.2 ist
wegen eines Bugs unbrauchbar. Kernel zwischen 2.0.15 und 2.0.24 arbeiten
mit syncPPP nicht immer ganz korrekt. In 2.0.26 kamen viele i4l-Bugfixes
hinein, allerdings wurde dafür eine Includedatei (proto.h) verschluckt.
Einen erneuten "Jumbo-Patch" gab es auf Version 2.0.30. Kernel 2.0.27+
laufen sehr stabil.
In den Kernels ab 2.1.0 wurde viel verändert - sie sind deshalb nur für
mutige Leute zu empfehlen. In Zusammenarbeit mit HiSax 1.4 läuft es aber
bis 2.1.14. Kernels ab 2.1.15 laufen erst ab HiSax 2.0 und dem zugehörigen
Kernelpatch.
Es wird empfohlen, i4l-Versionen ab 2.0 zu benutzen - in Zusammenhang
mit einem Kernel ab 2.0.3 (kein Patch mehr notwendig!). Kernel >2.0.27
ist der Stand der Dinge.
- Welche Hardware wird NICHT unterstützt?
Z.Zt. werden (mit Ausnahme der ICN) keine einzige aktiven ISDN-Karten
unterstützt. Lediglich noch für die AVM B1 gibt es einen Alpha-Treiber auf
Binary-Only Basis.
- Unterstützt isdn4linux externe Terminaladapter?
Nein, aber das braucht es auch nicht. Schließlich sind Terminaladapter so
gebaut, daß sie sich entweder wie ein Modem oder wie eine Netzwerkkarte
verhalten. Linux unterstützt aber auch schon ohne isdn4linux Modems und
Netzwerkkarten - daher ist kein spezieller ISDN-Treiber erforderlich
(womit sich die Konfiguration meist deutlich vereinfacht).
- Welche interne ISDN-Karten wird unterstützt?
Im Moment gibt es einen Treiber für alle Karten mit einem bestimmten
Siemens-Chipsatz (HiSax-Treiber), der auch Plug&Play-Karten unterstützt.
Zu den Details siehe die nächste Frage.
Der HiSax-Treiber hat den alten Telestreiber überflügelt, der entsprechend
nicht mehr weiterentwickelt wird. Dementsprechend hat der Telestreiber
mittlerweile wesentlich mehr Bugs und sollte nicht mehr verwendet werden.
Weitere Treiber gibt es für die (aktive) ICN-Karte (ICN-Treiber),
sowie für die PCbit-Karte (Octal, Portugal).
Für die "itk ix1 micro" gab es einen (speziellen) Treiber von Frank Mohr
<mohr@fhdacom2.fhrz.fh-darmstadt.de>, der jedoch mittlerweile im HiSax 2.0
enthalten ist. Er unterstützte die folgenden Karten:
* ITK ix1 micro V2.0 und V2.1
* Cisco 200
* ITK Columbus
Schließlich gibt es noch einen (Alpha-) Treiber für die aktive AVM B1,
mit einigen Besonderheiten. Siehe dazu die Frage "Wie sieht es aus mit
der aktiven AVM B1?".
- Was hat es mit dem HiSax-Treiber auf sich?
Das ist ein Treiber, der alle passiven Karten unterstützen soll,
die mit einem bestimmten Siemens-Chipsatz ausgestattet sind.
Unterstützt werden zum jetzigen Zeitpunkt:
* Teles S0-8
* Teles S0-16 und S0-16.2
(baugleich: Dr. Neuhaus Niccy 1016, Creatix 16/S0)
* Teles S0-16.3
* Teles S0-16.3 PNP
* Teles PCMCIA
* Creatix S0 PNP
* AVM A1 (Fritz!)
* ELSA Microlink PCC-16
* ELSA Microlink PCF
* ELSA Microlink PCF/pro (nur ISDN-Teil, nicht der V34 Modem Chip)
* ELSA Quickstep 1000
* ITK ix1-micro Rev.2
Die ELSA PCC-8 sollte eigentlich auch unterstützt werden, mangels
Debuggingmöglichkeit hält sich jedoch noch einen Bug, der dies verhindert.
Karsten Keil <keil@temic-ech.spacenet.de> schreibt weiterhin am 14. Okt
1996:
Erstes Ziel des HiSax Treibers war es mehr ISDN Karten unter i4l
verfügbar zu machen, dieses Ziel bleibt auch bestehen.
Zweitens soll er möglichst einfach konfiguriert werden können und dem
User keine funktionierende Karte vorgaukeln wenn es Hardware Probleme
gibt (IRQ, Reset Problem Teles). An den Hardwareproblemen selbst (PCI
IRQ, Int 12/15 usw.) kann ich auch nichts ändern, aber der Treiber
wird nicht geladen wenn sowas auftritt.
Drittens und dieser Teil ist erst angefangen, vollstendige
Überarbeitung der Statemaschinen um einen komplett DSS1 bzw. 1TR6
konformen Treiber zu bekommen, der eine Zulassung bestehen würde (das
heißt nicht, das ich ihn zulassen will oder kann).
Desweitern möchte ich,wenn möglich auch die US ISDN Protokolle
unterstützen, damit i4l mal aus Europa rauskommt.
Auch weitere l2/l3 Protokolle sollen rein (V110 ...), Standleitungs-
Unterstützung ..., eine Menge Arbeit, die ich nicht unbedingt allein
machen möchte.
Deshalb an alle die ein wenig von Programmierung und ISDN verstehen
(ich selbst hab im Januar das erste mal was von ISDN gehört und
beruflich auch nichts damit zu tun, d.h alles nebenbei gelernt), wer
Lust hat (was dabei glaube ich immer noch das wichtigste ist) melde
sich für die weitere Entwicklung.
Wer Interesse an dem Treiber hat, muß ihn sich hier besorgen:
ftp://ftp.franken.de/pub/isdn4linux/HiSax/
(und hoffentlich bald auf allen isdn4linux-Mirrors!)
Seit HiSax 1.5/2.0 werden auch D64-Verbindungen unterstützt. HiSax 2.0 wird
ins Kernel 2.0.30 wandern, und braucht ab dann nicht mehr gesondert in den
Kernel gepatcht werden.
- Wie sieht es aus mit der aktiven AVM B1?
Andreas Schultz <aschultz@hppool.cs.Uni-Magdeburg.de> hat dafür einen
Treiber geschrieben, den es (als Alpha-Version) unter folgendem Link gibt:
http://www.cs.uni-magdeburg.de/~aschultz/avmb1-1.2-alpha.tar.gz
Da er ein NDA mit AVM unterzeichnen mußte, gibt es den Treiber jedoch nur
als Binary.
- Nachdem meine AVM ja so viele Interrupts erzeugt mit dem HiSax-Treiber,
welches ist die beste passive Karte in Verbindung mit HiSax?
Karsten Keil <keil@temic-ech.spacenet.de> schrieb dazu am 12. Nov 1996:
Das sollte sich fast nichts nehmen. Von der Belastung des Rechners ist die
Fritz! wahrscheinlich auf Dauer die Schlechteste [siehe dazu die Frage
"Meine AVM-Karte erzeugt extrem viele Interrupts" im Abschnitt HiSax im
Kapitel Troubleshooting], aber vielleicht bekomm ich das mit dem Timer
noch raus, wie gesagt macht sich nur bemerkbar wenn der Rechner z.B die
ganze Nacht rendering betreibt.
Karsten Keil <keil@temic-ech.spacenet.de> schrieb weiterhin am 2. Dez 1996
hinsichtlich Stabilität und Bug-Freiheit:
1. Wahl ELSA
ELSA stellt im Gegensatz zu AVM die Spezifikation zur Verfügung.
2. Wahl Creatix PNP
Auch Creatix Mitarbeiter stehen Linux nicht vollkommen negativ
gegenueber ;-). Ist uebrigens eine Creatix Eigenentwicklung und
nicht mit der Teles 16.3 PNP identisch.
- Unterstützt isdn4linux externe ISDN-Adapter?
Nein, isdn4linux unterstützt nur interne Steckkarten. Externe ISDN-Adapter
sind entweder wie analoge Modems oder wie Netzwerkkarten ansprechbar und
benötigen daher kein ISDN4Linux.
- Welche ISDN-Modi werden unterstützt?
Die folgenden:
56k asynchron : nein
64k synchron : ja
128k synchron : ja (channel bundling - siehe nächste Frage)
- Unterstützt isdn4linux Kanal-Bündelung (channel bundling)?
Isdn4Linux unterstützt in der aktuellen Version channel bundling mit
2 verschiedenen Verfahren:
- MPPP (basiert auf syncPPP)
- Raw Bundling (Konfiguration von sogenannten Slave-Kanälen)
Beide Varianten haben z.Zt. eigene Vor- und Nachteile. Siehe dazu "Wie
benutzt man Channel Bundling?" im Abschnitt "Channel-Bundling" weiter
unten.
Achtung: Channel bundling bringt nur eine Zeit-, nicht aber eine
Gebührenersparnis mit sich. Nur wenn tatsächlich die höhere Bandweite
benötigt wird, ist der Einsatz sinnvoll.
- Was ist der Unterschied zwischen einer aktiven und einer passiven
ISDN-Karte?
Bei einer aktiven ISDN-Karte wird ein Großteil des ISDN-Verbindungs-
protokolls (Wählen, Ruf annehmen, usw.) von der Karte selbst erledigt.
Auf der Karte ist dazu ein eigener kleiner Computer mit Software
(Firmware) untergebracht Eine passive Karte muß all diese Dinge von dem
Computer erledigen lassen, in dem sie steckt.
- Gibt es Rechner, die einen Gastzugang bieten, wo ich mein isdn4linux
testen kann?
Ja, folgende Rechner bieten Gastzugänge für Modememulation oder IP an:
- Eberhard Moenkeberg <emoenke@gwdg.de>:
* Welcome to Linux at eberhard.moenkeberg.de (LAN, 192.168.99.1).
Under ++49-551-7704103, ISDN NetCalls (HDLC-trans-rawip)
for 192.168.99.1 get accepted. You should come as 192.168.*.*
because sometimes my "default" route is not your way.
/ftp is exported for NFS; try "showmount -e".
You can login as "guest" without password.
FTP as "gast" with password "gast" avoids the restricted shell.
* Under ++49-551-7704102, a 28800 bps modem and a Creatix ISDN
card (HDLC only, not X.75) are listening for Logins.
Mit dem Net-Setup aus
ftp://ftp.gwdg.de/pub/linux/isdn/isdn4linux-gwdg/rc.isdn-Beispiel
kann man sofort unter 551-7704103 den NetCall testen (geht ohne
Anpassung aus ganz Deutschland; das Ausland muß nur die Nummern
anpassen).
- Gernot Zander <hifi@scorpio.in-berlin.de>:
There's a "gast" at +49 30 67 19 81 01 (X.75, mgetty). There's the
stones-html-page with pics in postscript to test downloading. Who
needs a target to call could use it.
Es gibt den Gast auf der +49 30 67198101 mit X.75, sofern nicht einer
der Tester mein ttyI erhängt hat, und auf der ...103 ein getty mit
HDLC.
Als Gast kommt man in eine Art Mailbox. Das Enterprise-gif gibt's
da nicht mehr, dafür kann man sogar ein bißchen News lesen.
- Kann ich i4l mit dem diald kombinieren?
Ja, siehe dazu den Abschnitt "Diald" im Kapitel "Konfiguration".
- Kann ich isdn4linux als Anrufbeantworter benutzen?
Ja, Voice-Support ist in der aktuellen Version von isdn4linux möglich.
Man kann sich dabei entweder des "vgetty"-Teils von Gert Doerings
"mgetty+sendfax" bedienen, oder man benutzt das Programm "vboxgetty"
von Michael Herold, welches speziell für ISDN4Linux hergestellt wurde.
Letzteres findet sich unter:
ftp://ftp.franken.de/pub/isdn4linux/contributions
- Kann ich isdn4linux zum Faxen benutzen?
Zwar sind immer mal wieder einige Gruppen mit der Entwicklung einer solchen
Software beschäftigt, die mit i4l zusammenarbeiten soll. So wie es im
Moment aussieht, wird es aber wohl nie funktionieren, weil Faxen sehr
timing-kritisch ist, und Linux keine Echtzeit-Umgebung bietet.
Wer faxen will, muß sich deshalb neben der ISDN-Karte leider auch noch ein
analoges Fax-Modem anschaffen.
- Ist Btx/Datex-J mit isdn4linux möglich?
Ja, das ist einfach über die Modememulation der ttyI*-Devices möglich.
Es sind die für BTX speziell vorgesehenen Register zu setzen (ATSx=y -
siehe Readme's). Auch der Internetzugang über T-Online ist möglich.
ACHTUNG: XCept (früher Xbtx) kennt eine Konfigurations-Option ISDN.
Diese ist NICHT zu verwenden! Vielmehr ist XCept so zu konfigurieren
als würde ein normales Modem verwendet.
Siehe auch die Fragen zu T-Online im Abschnitt Konfiguration|Gegenstellen.
- Kann ich mit isdn4linux eine Verbindung zu Compuserve aufbauen?
Nein, da Compuserve's ISDN-Zugänge nur mit dem veralteten V.110-Protokoll
funktionieren. V.110 ist in isdn4linux (noch?) nicht implementiert.
Inzwischen bietet Compuserve aber auch viele X.75-Einstiege an.
- Welche ISDN-Features wird isdn4linux nicht bieten können?
Einige ISDN-Features sind gerätespezifisch und können daher nicht von
isdn4linux für andere Geräte aktiviert werden, es sei denn, isdn4linux
würde deren TEI fälschen (was die Geräte jedoch ziemlich verwirren dürfte).
Solche gerätespezifischen ISDN-Features sind u.a.: Ablehnen eines
anklopfenden Anrufes, Rufnummernübermittlung aus/ein, Makeln, Konferenz,
Vermitteln im Amt, diverse COLP/CLRP.
- Ich möchte einen neuen Hardware-Treiber schreiben. Wo gibt es die
Schnittstellen-Beschreibung zum Link-Level-Modul?
Beim Linux-Quellcode (in /usr/src/linux/Documentation/isdn) befindet sich
die Datei INTERFACE - das ist eine Beschreibung der Schnittstelle zum
Link-Level-Modul.
- Wie habe ich Zugriff auf den Source der aktuellen Entwicklung/was hat
es mit dem CVS-Tree auf sich?
CVS - Concurent Version System
Ist eine Multiuser/Server Erweiterung von RCS (Revision Control System).
Die I4L Treiber werden unter CVS entwickelt, dazu existiert auf einem
Rechner (oldhades.think.de) ein CVS-tree auf den alle Entwickler Zugriff
haben. Zusätzlich hat Fritz einen anonymen Readonly Zugriff gebastelt, wer
also unbedingt das Neuste haben will kann sich das dort holen, in den
Sourcen sind eventuell mehr bugs drin, als in den releasten !!!
Hier die entsprechende Nachricht von Fritz Elfert <fritz@wuemaus.franken.de>
zu diesem Thema:
Ich bekomme oft Patches - gegen die aktuell offizielle Release des
Quellcodes - bei denen ich Probleme bekomme, sie einzubinden.
Mein lokaler Quellcode hier ist manchmal zwei oder drei Versionen
weiter, wobei ich sie allerdings nicht releasen kann, weil er
unvollständig oder völlig ungeprüft ist etc.
Deshalb habe ich jetzt beschlossen, das CVS-Repository von
isdn4linux öffentlich zugänglich zu machen. Jetzt können Programmierer,
die einen Blick auf den Fortgang der Entwicklung werfen wollen, oder
Leute, die immer den allerneuesten Stand haben wollen, folgendermaßen
auf das CVS-Repository zugreifen:
1.) Man installiere GNU CVS (irgendeine Version >= 1.6 tut's).
2.) Man schreibe ein kleines Shellscript .cvsrsh im Homedir:
#!/bin/sh
exec rsh -l guest $*
3.) Man setze CVS_RSH auf dieses Script (z.B. CVS_RSH=~/.cvsrsh)
4.) Man setze CVSROOT auf oldhades.think.de:/i4ldev
(z.B. export CVSROOT=oldhades.think.de:/i4ldev)
5.) Man führe aus: "cvs -z9 checkout isdn"
-> Dies läßt einen Verzeichnisbaum im aktuellen Verzeichnis
entstehen. Unterhalb von isdn/ findet man die gleiche
Hierarchie wie im Linux-Source nebst einigen Scripten, um
den Inhalt in den Linux-Quellcodezweig zu kopieren/diffen.
Ähnlicher Zugang ist auch auf das Utility-Paket möglich, mit dem
Kommando:
cvs -z9 checkout isdn4k-utils
ABER VORSICHT! DAS NEUESTE MATERIAL IST MANCHMAL ZIEMLICH INSTABIL ODER
WENIGSTENS NICHT OHNE GUTE PROGRAMMIERKENNTNISSE COMPILIERBAR -
bitte keine Newbie-Fragen zu diesem Thema! Use the source, Luke!
Hinweis:
Natürlich ist der Zugriff Read-Only. Der Zugriff ist auf die
folgenden Kommandos beschränkt:
checkout
diff
export
status
update
Zur Benutzung dieser Befehle sehe sich die Dokumentation zu CVS an.
Leute, die das Entwicklerteam _ständig_ unterstützen wollen
(z.B. neue Treiber schreiben [oder FAQ-Mitarbeit! Die Red.]),
können einen echten Account zum vollständigen Zugriff erhalten.
Man schreibe mir in diesem Falle eine Mail.
- Kann man ISDN4linux auch unter dem dosemu ansprechen?
Ja, das geht tatsächlich! Steffan Henke <henker@informatik.uni-bremen.de>
schrieb dazu am 25. Okt 1996:
In der dosemu.conf genügt z.B. der folgende Eintrag für einen
virtuellen com2-Port, der z.B. unter Telix oder Terminate läuft:
serial { com 2 device /dev/ttyI3 }
Auch der Zugriff über Fossil ist möglich, wenn fossil.com (beim dosemu
dabei) gestartet wird.
Getestet in den folgenden Konfigurationen:
- Kernel 2.0.21, Telestreiber inkl. Karstens patches
- Kernel 2.0.21, HiSax
- Gibt es eine funktionierende ISDN Karte für einen DEC Alpha mit Linux?
Thomas Bogendoerfer <tsbogend@alpha.franken.de> schrieb am 17. Dez 1996:
Ich verwende eine ICN ISDN Karte in meinem Alpha Noname für den
Internetzugang und mail/news via uucp.
Ich habe keine passive ISDN Karte um HiSax mit Linux/Alpha zu testen. Es
gibt jedoch Probleme mit den Timern (HZ ist 1024 auf Alphas). Selbst im
icn Treiber ist der "falsche" Timer, was ein wenig zu viel Polling der Karte
verursacht (aber es führt zu besseren ping Zeiten:-)). Ich vermute, es ist
an der Zeit das zu beheben.
- Läuft isdn4linux parallel zu UISDN?
Nils Rennebarth <nils@nus.de> schrieb dazu am 10. Dez 1996:
Es läuft parallel. Und es läuft unter 2.0.X.
Beide ISDN-Pakete laden jedoch das Modul isdn.o, ansonsten ist der
Namensraum verschieden. Abhilfe: Urlichs isdn.o in uisdn.o umbenennen,
entsprechend /lib/modules/modules.isdn (oder wie immer das Ding heißt,
wo die Module drinstehen, und das das Skript ausliest) anpassen.
Freundlicherweise sind auch die Default-Namen der ISDN-devices
verschieden.
- Was heisst eigentlich AOC-x, CLIR, COLP, CVS, HDLC, HSCX, ISAC, TEI...?
Hier ein kleines Glossar:
AOC-D
AOC-D ist die "Gebühreninformation während der Verbindung".
AOC-E
AOC-D ist die "Gebühreninformation nach der Verbindung". Dieses
Dienstemerkmal ist in Deutschland im "Komfort-Anschluß" enthalten.
CLIR
CLIR ist ein Angebot des ISDN-Anbieters: man kann fallweise
die Übermittlung der eigenen Rufnummer an den Gesprächspartner
unterdrücken lassen. CLIR muß man beantragen, es ist (in Deutschland)
jedoch kostenlos. Hingegen kostet die fallweise Übermittlung
der Rufnummer Geld.
COLP
Auch COLP ist ein Angebot des ISDN-Anbieters. Man muß es beantragen,
aber es kostet (in Deutschland) 10.-- DM pro Monat extra. Wer COLP
beantragt hat, bekommt ein erweitertes Wählprotokoll über die
Leitung, welches man dann z.B. in der Tk-Anlage auswerten kann.
Derzeit wird an einer Möglichkeit gebastelt, das mit Hilfe einer
"verkehrtherum" angeschlossenen zweiten Teleskarte zu umgehen. Man
bekommt dann ganz ohne Gebühren mehr Informationen als mit laufendem
COLP. Das rechnet sich bald...
CVS-Tree
Die i4l-Entwickler haben sich zu einem Team zusammengeschlossen. Das
Tool "cvs" erlaubt es den Mitgliedern, relativ problemlos Patches
einfließen zu lassen. Der Werdegang des Projektes wird damit
ausgezeichnet dokumentiert, und es ist auch nicht schwierig, eine
ältere Version wieder herzustellen.
HDLC
Ein sehr verbreitetes Low-Level-Protokoll.
HSCX
Ein Siemens-Chip, der ähnlich ->ISAC auf vielen passiven ISDN-Karten
sitzt. Er übernimmt den seriellen Bus vom ISAC und demultiplext beim
Empfangen bzw. multiplext (d.h. fügt die Bits an der richtigen Stelle
ein) die B-Kanäle.
ISAC
Ein Siemens-Chip, der ähnlich ->HSCX auf vielen passiven ISDN-Karten
sitzt. Er ist für "Level 1" zustaendig, sitzt also (beinahe) direkt an
der Leitung. Er kann das D-Kanalprotokoll handhaben und setzt die
S0-Daten auf einen speziellen seriellen Bus (IOM) um. Beim Senden
geht es umgekehrt.
TEI (Terminal End Identifier)
Die lokale Vermittlungsstelle oder bei internen S0 die Anlage weist
jedem Endgerät automatisch oder fest eine TEI zu. Diese dient ganz
einfach zur Addressierung des D-Kanals. TEIs haben folgende Werte:
0- 63 feste TEIs (z.B wird 0 bei Anlagenanschlüssen verwendet)
64-126 automatisch zugewiesen
127 Rundruf an alle (z.B. bei hereinkommendem Anruf)
TK-Anlage (Telekommunikationsanlage)
Eine TK-Anlage dient dazu, verschiedene interne Geräte an das
ISDN-Netz anzuschließen. Meist handelt es sich dabei um analoge
Geräte, die nicht direkt ans ISDN-Netz angeschlossen werden können.
Die TK-Anlage kann jedoch auch einen internen digitalen S0-Bus zur
Verfügung stellen, an dem dann ISDN-Geräte angeschlossen werden können.
- Wo kann ich Skripte und andere Information für die Konfiguration von i4l
finden?
Konfigurationsbeispiele und Scripten:
http://www.rosat.mpe-garching.mpg.de/~web/ISDN.html
Viele HowTo's zum Thema Grundinstallation, syncPPP, Einrichten von Email,
Usenet News, Anrufbeantworter und mehr:
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
Weitere FAQ mit Beispielscripten:
http://www.fzi.de/sim/people/trautw/i4l/index.html
- Wieviele ISDN-Karten kann ich maximal gleichzeitig in meinen Rechner
stopfen?
Soviele, wie ISA-Slots da sind bzw. Interrupts/IO-Adressen.
Die Teles 16.3 kann (offiziell) nur auf 3 verschiedenen IO-Adressen liegen,
daher können nur maximal 3 verwendet werden. Außerdem wird für jede Karte
ein eigener Interrupt benötigt.
Peter Strunk <webadmin@mail.bicos.de> hatte am 8. Nov 1996 folgenden Tip
für die Installation einer vierten Teles-Karte:
Probiere doch mal Port 0x080h, DIP-SW in die nicht dokumentierte
Position!
Ähnlich die AVM.
Die ICN's haben keine Interrupts, flexiblere Port-Konfigurationen, und
der Treiber legt den shared-memory Bereich aller ICN-Karten auf die
selbe Adresse. Eingeblendet wird das Karten-Memory jeweils bei Bedarf.
In Kombination können daher tatsächlich so viele ISDN-Karten wie Slots
eingesetzt werden. Notfalls kann man die Anzahl der ISA-Slots durch einen
ISA-Bus-Extender vergrößern.
- Brauche ich ein DOS Setup-Programm, um meine Teleskarte zu initialisieren?
Karsten Keil <keil@temic-ech.spacenet.de> schrieb dazu am 21. Feb 1997:
Du brauchst aber kein DOS Setup fuer Linux, mit einer Ausnahme:
Es gab von Teles eine Charge PnP Karten die kein echtes PnP gemacht haben.
Zu erkennen sind diese Karten daran, das sie KEINEN Jumper/Dip haben aber
von isapnp nicht erkannt werden.
Alle anderen Karten werden mit den Linuxtreibern bzw. die PnP mit isapnp
konfiguriert.
- Unterstützt isdn4linux "dial on demand"?
Ja. Wenn ein Netzwerk-Interface (z.B. "isdn0") eingerichtet ist, wählt
der Treiber die Gegenstelle an. Wurde außerdem ein Hangup-Timeout (Idle-
Timeout) eingestellt, isdnctrl huptimeout <interface> zeit dann legt der
Treiber automatisch auf, wenn "zeit" Sekunden keine Daten über das
Interface übertragen wurden. Siehe dazu die Fragen im Abschnitt über
Chargeint in Konfiguration. Im Zusammenhang mit syncPPP gibt es Probleme
(siehe syncPPP-Abschnitt!).
Für den Einsatz von "dial on demand" mit asyncPPP kann der diald eingesetzt
werden.
- Unterstützt isdn4linux PNP (Plug and Play)?
Ja. Allerdings nur in Verbindung mit dem HiSax-Treiber. Mit "Plug" alleine
ist's leider noch nicht getan, es fällt noch etwas mehr Arbeit an:
(von Karsten Keil <keil@temic-ech.spacenet.de>)
1. HiSax muß in den Kernel gepatcht werden
(Achtung: den "-pn" Parameter verwenden!)
2. Mit "make menuconfig" (oder "make config") werden folgende Kernel-
Optionen eingestellt:
* ISDN = "M" (als Modul - PNP funktioniert sonst nicht!)
* HiSax = "M" (als Modul - PNP funktioniert sonst nicht!)
* 16.3/PNP support
* EURO support
3. Kernel und Module kompilieren & installieren, depmod. (Reboot!)
4. Die Konfiguration der PNP-Karte auslesen mit:
"pnpdump > /etc/isapnp.conf".
5. Die Konfigurationsdatei "/etc/isapnp.conf" muß von Hand angepaßt
werden. Folgende Werte sind zu setzen:
INT0 - der von der Karte verwendete Interrupt
(Default bei Teles 16.3 PNP: 10)
IO0, IO1 - die von der Karte verwendeten IO-Ports
(Default bei Teles 16.3 PNP: 0x580 bzw. 0x180)
(Achtung: diese Werte müssen 64bit aligned sein! Frühe
Versionen der PNP-Karten schlagen evtl. falsche Werte vor!)
6. Aktivieren der Konfiguration per:
"isapnp /etc/isapnp.conf"
(muß bei jedem Booten gestartet werden)
7. Nun kann das HiSax-Modul gestartet werden mit:
"modprobe hisax io=4,<P>,<INT>,<IO0>,<IO1>"
4 - PNP-Karte
<P> - Protokoll:
2 - für Euro-ISDN (normalerweise)
1 - für 1TR6-ISDN (deutscher Vorgänger von Euro-ISDN)
<INT> - der in /etc/isapnp.conf bei INT0 eingetragene Wert
<IO0> - der in /etc/isapnp.conf bei IO0 eingetragene Wert
<IO1> - der in /etc/isapnp.conf bei IO1 eingetragene Wert
- Gibt es einen Trick, Linux mal mit, mal ohne ISDN-Subsystem zu booten?
Ja, dafür gibt es ja die Runlevel (unter SysVinit).
Emil Stephan <ste@esqhen.su.eunet.de> hat dazu Scripten erstellt:
Ich habe bei meinem Rechner 2 Runlevel definiert (3 und 4), 3 läuft
ohne isdn, 4 mit. Wenn ich ISDN mitsamt den dazugehörigen Prozessen
wie ipppd, isdnlog und mgetty stoppen will, gebe ich als root "init 3"
ein, zum Starten dann "init 4". Init sorgt dann dafür, daß über
"/sbin/init.d/i4l start" bzw. "... stop" die notwendigen Dinge
angestoßen werden.
- Gibt es die Möglichkeit, eine Rufumleitung mittels i4l zu initiieren?
Karsten Keil <keil@temic-ech.spacenet.de> schrieb dazu, daß es später
mal geplant sei, das im HiSax-Treiber zu implementieren.
- Hat schon mal jemand mit linux ipx/spx über Isdn geroutet?
Andreas Kool <akool@Kool.f.EUnet.de> schrieb am 14. Okt 1996:
Das ist kein Problem - machen wir schon lange.
- Einfach ein isdn-Interface anlegen
- wichtig dabei: encap isdnX ethernet
Den Rest macht "mars_nwe" (incl. Routing), ein vollständiger
Novell-Netware-Emulator. Den gibt es z.B. auf:
ftp://ftp.gwdg.de/pub/linux/misc/ncpfs/mars_nwe-0.98.pl7.tgz
- Kann ich den kerneld einsetzen, um die ISDN-Module bei Bedarf in den Kernel
zu binden?
Emil Stephan <ste@esqhen.su.eunet.de> schrieb dazu am 15. Oktober 1996:
Das Entladen der Module, wenn sie eine Minute lang nicht mehr
gebraucht wurden, macht der kerneld defaultmäßig. Das ist bei Modulen
wie Gerätetreibern ala Floppy etc. kein Problem; bei Treibern aber,
die irgendwelche Einstellungen über einen längeren Zeitraum behalten
müssen, aber doch. Z.Bsp. sind die Einstellung des Mixers bei einer
Soundkarte oder die Konfiguration von Dialin- und Dialout-Parametern
beim ISDN-Treiber solche.
Das Entladen des ISDN-Treibers zerstört z.B. auch das IP-Interface
ippp0 oder isdn0. Die Einträge in der IP-Layer des Kernels gehen dann
ins Leere. Wenn man mal in die Start-Up-Skripten von i4l reinschaut,
wird man eine ganze Menge Dinge finden, die mit isdnctrl etc.
eingestellt werden; die müßte der kerneld bei jedem erneuten Laden
wieder einstellen lassen. Auch der Status des D-Kanals auf ISDN könnte
zu den Dingen gehören, die durch das Entladen verloren gehen.
Also mein Tip ist, nicht vom kerneld laden und entladen lassen,
sondern beim Systemstart laden und nur entladen, wenn es aus
technischen Gründen nötig ist.
Siehe dazu auch die Frage "Gibt es einen Trick, Linux mal mit, mal ohne
ISDN-Subsystem zu booten?".
Markus Gutschke <gutschk@uni-muenster.de> setzte hinzu:
Genau für diesen Zweck gibt es seit geraumer Zeit in dem Modules
Paket eine Erweiterung, die es erlaubt, eine Datenbank mit
Zustandsinformationen über die Treiber zu installieren. Leider wird
dieses Feature bisher kaum oder gar nicht von den Modulen
unterstützt.
Als Alternative bieten sich auch solche Optionen wie der
"post-install" Hook in der "/etc/conf.modules" an. Es ist dann zwar
erforderlich, daß man von Hand die passenden Skripts schreibt, aber
im Prinzip funktioniert das dann genauso gut wie, wenn das Modul eine
automatische Initialisierung über eine Datenbank durchführen würde.
- Wie komme ich zu einem für ISDN gepatchten tcpdump?
Michael Stiller <michael@toyland.ping.de> schrieb dazu am 23. Okt 1996:
Tip zum ftp'en:
ftp://ftp.gwdg.de/pub/misc/isdn/linux/isdn4linux-gwdg
Da gibts den patch: "tcpdump-3.0.4-1-isdn.dif.gz"
und den Rest unter:
/pub/linux/mirrors/funet/PEOPLE/Linus/net-source/tools/tcpdump-3.0.4-1.tar.gz
Evtl muß man im Patch je nach Namen seines ISDN Interfaces (bei mir bri0)
noch weitere Möglichkeiten dazu hacken. Defaultmäßig kennt das Teil nur
isdn* und isdnY* als Interfacenamen.
Weiterhin schrieb Henning Schmiedehausen <henning@pong.iconsult.com> zu
diesem Thema am 30. Okt 1996:
Nachdem auch der Patch vom Eberhard Moenkeberg auf ftp.gwdg.de kein
cisco-hdlc ausdumpen kann, habe ich hier mal einen isdn-patch fuer
tcpdump-3.0.4 gemacht, der das Interface fragt, was fuer eine
Encapsulation es benutzt und sich entsprechend einstellt. Das Teil ist
gegen eine tcpdump-3.0.4-1.tar.gz Distribution, wie sie z.B. auf
ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/tools liegt,
gemacht. Dieser Patch erkennt RAW-IP, ISDN-IP und CISCO-HDLC und kann
die Pakete entspr. dumpen.
[An seiner Mail hing der Patch - er sollte sich einfach im Archiv der
Mailingliste wiederfinden lassen - die Red.]
Sascha Ottolski <sascha@alzhimer.isdn.cs.tu-berlin.de> hatte noch folgenden
Tip am 5. Nov 1996:
Es gibt doch isdn4k-utils-2.0/tcpdump-3.0.3-isdn.diff ! Damit klappts,
sofern man noch selbst Hand anlegt:
In der Datei tcpdump-3.0.3-isdn/libpcap-0.0/pcap-linux.c steht nach
dem Patch irgendwo folgendes:
else if (strncmp("ppp", device, 3) == 0)
Entweder man nennt seine ppp-devices irgendwie pppX statt ipppX, oder
ändert die Zeile z.B. in
else if (strncmp("ippp", device, 4) == 0)
^^^^ ^^
Dann erkennt tcpdump auch sync-ppp. Jedenfalls bei mir.
- Wie kann ich Benutzerrechte für die Verwendung von ISDN einrichten?
Henner Eisen <eis@baty.hanse.de> schrieb dazu am 13. Feb 1997:
Den Zugang über isdn-ttys kann man (ganz nach Unix-Philosophie)
beschränken, indem man in /etc/group eine Group (z.B. 'isdn') einrichtet,
und dann
chgrp isdn /dev/ttyI* /dev/cui*
chmod o-rw /dev/ttyI* /dev/cui*
allen Usern außer denen in der Gruppe 'isdn' die Lese/Schreibrechte für
die ISDN-ttys entzieht. Diejenigen, die ISDN benutzen dürfen, muß man dann
explizit zum Mitglied der Gruppe 'isdn' machen.
- Ich benutze SETUP.EXE unter DOS, um meine Teles/Creatix mit Memory xxxxx
und IRQ yy zu konfigurieren. Wie stelle ich das unter isdn4linux ein?
Die Einstellungen kann man als Kernelparameter bzw. als Modulparameter
übergeben. Eine feste Eincompilierung ist nicht erforderlich.
Manchmal allerdings macht man es doch, nämlich wenn Software-
unverträglichkeiten auftreten oder wenn mehrere Teles-Karten in einem
Rechner betrieben werden sollen. In diesem Falle editiert man die
Datei /usr/src/linux/drivers/isdn/teles/config.c und trägt die
Parameter direkt ein. Siehe Kommentar in dieser Datei.
- Ich bin verwirrt: laut Dokumentation ist meine Teles-Karte auf die
IO-Adresse 0x180 eingestellt. In Linux (und auch manchen Windowsprogrammen
wird jedoch angezeigt, daß sie auf 0xd80 liegt?
Die Karte belegt beide IO-Adressen! Karsten Keil
<keil@temic-ech.spacenet.de> schrieb hierzu am 3. Jan 1997:
Die eigentlich benutzten Adressen sind:
isac 980
hscx 180/580
cfg d80
Zur Verwirrung kommt es aufgrund eines Mißverständnisses: Teles
gibt die HSCX0-Adresse als Referenz an, während der alte Teles-Treiber
die cfg-Adresse benötigt. Da die Benutzer dadurch verwirrt waren,
können die beiden Treiber nun beide Adressen handhaben (und die
Benutzer sind dadurch erneut verwirrt ;-))
- Beim Compilieren des Telestreibers bekomme ich eine Fehlermeldung der
Art: too many arguments to function `__get_free_pages_R5243d78b'
Ab einer bestimmten Version der 1.3.x Kernels wurde für die Kernel-
Funktion get_free_pages der Aufruf geändert. Wenn die Meldung erscheint,
wird ein älterer Kernel eingesetzt. In diesem Falle ist in der Datei
teles/teles.h die Zeile
#define NEW_GET_FREE_PAGES
auszukommentieren:
/* #define NEW_GET_FREE_PAGES */
- Ich benutze Kernel 1.3.x, der Telestreiber compiliert ohne Fehler durch,
in config.c sind alle Daten richtig eingetragen, trotzdem funktioniert
der Treiber nicht.
Ab einer bestimmten Version der 1.3.x Kernels wurden die Timer im Kernel
geändert. Möglicherweise wird hier ein älterer Kernel eingesetzt. Man
kommentiere in der Datei teles/teles.h die Zeile #define NEW_TIMERS aus:
/* #define NEW_TIMERS */
- Ist es möglich, mehrere Teles-Karten in einem Rechner zu betreiben?
Ja, das ist möglich. In der Datei teles/config.c müssen die Daten der
anderen Teles-Karten eingetragen werden:
struct IsdnCard cards[]={
{ (byte *)0xd0000,11,0xd00,NULL } ,
/* 1. Karte */ { (byte *)0xd8000,10,0xe80,NULL } ,
/* 2. Karte */ ...
/* u.s.w. */
};
Am 6. Okt 1996 schlug Christian Kratzer <ck@toplink.net> vor (Zeilen, die
mit "io=" anfangen, müssen mit der vorherstehenden zusammengefaßt werden):
# load modules
/sbin/modprobe isdn.o
echo "teles0 - Teles S0/16.2"
/sbin/insmod $MODPATH/misc/teles.o -o teles0 teles_id=teles0
io=0xd0000,5,0xd80,2
echo "teles1 - Teles S0/16.2"
/sbin/insmod $MODPATH/misc/teles.o -o teles1 teles_id=teles1
io=0xd2000,9,0xe80,2
echo "teles2 - Teles S0/16.2"
/sbin/insmod $MODPATH/misc/teles.o -o teles2 teles_id=teles2
io=0xd4000,12,0xf80,2
/sbin/lsmod | grep teles > /dev/null
- Woran erkenne ich, daß meine Teles-Karte (oder eine kompatible Karte)
korrekt erkannt wurde?
Beim Booten muß eine Meldung wie "kernel: HSCX version A:5 B:5" sowie
"kernel: channels 2" in /var/log/messages eingetragen werden. Auch
"A:4 B:4" ist o.k. Alle anderen Werten (insbesondere A:0 B:0 oder A:f B:f)
zeigen an, daß die Karte nicht richtig erkannt wurde.
Siehe auch unter im Abschnitt "Teles" im Kapitel "Troubleshooting".
- Wo kann ich mich bei Teles beschweren?
Unter der Emailadresse "vertrieb@teles.de". Die haben dort auch eine
WWW-Seite: http://www.teles.de/
Karl Heinz Kremer <khk@specht.stuttgart.netsurf.de> ergänzte
am 2. Jan 1997:
Wenn Du was über Teles's Geschäftspraktiken lesen willst, schau dir
http://www.inx.de/~chris/isdn.htm an.
- Wo gibt es den HiSax-Treiber?
Bei ftp://ftp.franken.de/pub/isdn4linux/HiSax.
- Welche Version ist aktuell?
Version 1.4.
- Was kann der HiSax besser als der Original-Telestreiber?
Karsten schrieb dem FAQ-Team am 14. Okt 1996:
Bei HiSax wird die Hardware und das IRQ-Verhalten gecheckt, so daß der
Treiber nur dann geladen wird, wenn er Zugriff auf die Register hat und
Interrupts generiert werden. ALSO:
2*Laden erledigt
HSCX version 0 oder F erledigt
BUSY bei minicom u.ä. nur noch :
* REAL BUSY
* keine MSN/EAZ
* Kabel/Leitungs Probleme
Na - das ist doch was, oder?
- Wie baut man den HiSax ein?
Karsten Keil <keil@temic-ech.spacenet.de> beschreibt das so:
Es kann nie schaden, die orginal Kernel-Sources erst mal zu sichern.
Dann ins /usr/src/linux (da sollte sich der aktuelle Source befinden)
gehen. Jetzt der Patch selbst:
zcat HiSax_1.1.patch.gz |patch -p1 >& /tmp/HiSax.log
Das -p1 ist sehr wichtig, da sonst alle files aus neuen directories in
/usr/src/linux landen.
Dann /tmp/HiSax.log nach errors/warnings/rejects durchsuchen, wenn
welche auftreten die entsprechenden files anschauen und gegebenfalls
von Hand korrigieren.
Uwe Bonnes <bon@elektron.ikp.physik.th-darmstadt.de> fügte hinzu:
Wer Gnu Patch besitzt, kann auch "... |patch -s -p1 " verwenden. Dann
werden nur die Fehler berichtet. Und wer ein log will, kann auch
"... |patch -s -p1 | tee /tmp/HiSax.log" machen. Damit bekommt man
zusätzlich zur Bildschirmausgabe ein Logfile.
Hinweis: Inzwischen gibt es neuere Versionen des HiSax.
- Gibt es Patches zum HiSax-Treiber?
Ja. Karsten <keil@temic-ech.spacenet.de> schrieb dazu am 15. Okt 1996:
Die Patches werde ich bis zur nächsten Version mit Buchstaben
"numerieren" und auch auf ftp ablegen.
Mit ftp ist ftp://ftp.franken.de/pub/isdn4linux/HiSax gemeint.
- Was hat es mit dem Vermerk: "Known Bugs: incoming calls are only
delivered, if channel == B-channel (same on teles)" auf sich?
Karsten Keil <keil@temic-ech.spacenet.de> schrieb am 14. Okt 1996:
1. Die o.g. Aussage ist nicht ganz korrekt:
if ((channel &1)+1 == B-channel )
2. Ich beschreib den Bug mal anders rum: Wenn gerade B-channel 1 von
einem anderen ISDN Gerät belegt ist und i4l wählt raus bekommt der
logische channel 0 von der VST den B-channel 2 zugewiesen.
---> geht
Das andere ISDN Gerät hängt auf.
Es kommt zusätzlich ein Ruf für i4l rein,natürlich für B-channel 1.
Da aber channel 0 belegt ist und es eine feste Zuordnung
B1->chan 0,2,4...
B2->chan 1,3,5... gibt wird der call nicht angenommen.
(chan 2,3 gibt es bei 2 Karten usw.)
Das ist zwar relativ selten kommt aber vor und wird demnächst gefixed
(wenn mir was Geniales einfällt).
Daß dieser Fall eintritt, kann anhand der modehscx-Meldungen (z.B.
"modehscx hscx 0 mode 2 ichan 1") mitverfolgt werden. hscx 0,1 bedeutet
welcher HSCX kanal benutzt wird. Mode ist mode (2). ichan 1 ist welcher
B Kanal - 1.
[Der Bug wurde mittlerweile in HiSax 1.2 gefixt - die Red.]
- Meine ELSA-Karte hat 2 LEDs, die Lichtorgel spielen. Was hat das zu
bedeuten?
Karsten Keil <keil@temic-ech.spacenet.de> schrieb am 14. Okt 1996:
Leerlauf l1 ist down
=> beide LED blinken ca. 1s an 1s aus.
l1 ist aktiviert (auch durch Telefon oder ä.)
=> Wechselblinken 0.5 gelb 0.5 grün
Betrieb
=> 1.5 an 0.5 aus
grün HSCX A aktiv
gelb HSCX B aktiv
Daß die ständig blinken hat die Ursache, das ich so bei der
Entwicklung sofort gesehen habe, daß die Karte hängt.
- Welche Einstellungen brauchen ISPA und Konsorten (DOS, Windows), um mit
isdn4linux in der Standardeinstellung zusammenzuarbeiten?
Folgende Konfigurationen sind möglich (diese gelten auch für die
anderen Treiber von H. Hanewinkel, also CINDI, CANDI, WISPA -
die findest Du via http://www.informatik.uni-bremen.de/~henker/dank):
Auf i4l-Seite Auf ISPA-Seite
====================================================
isdnctrl l2_prot isdn0 hdlc \
isdnctrl l3_prot isdn0 trans > -h0
isdnctrl encap isdn0 rawip /
----------------------------------------------------
isdnctrl l2_prot isdn0 hdlc \
isdnctrl l3_prot isdn0 trans > -h1
isdnctrl encap isdn0 uihdlc /
----------------------------------------------------
isdnctrl l2_prot isdn0 x75i \
isdnctrl l3_prot isdn0 trans > -l0
isdnctrl encap isdn0 rawip /
----------------------------------------------------
isdnctrl l2_prot isdn0 x75i \
isdnctrl l3_prot isdn0 trans > -l1
isdnctrl encap isdn0 uihdlc /
----------------------------------------------------
Am wenigsten Probleme bereitet meist -h0.
- Was muß ich beachten, um mit Windows95 eine Verbindung aufzubauen?
Torsten Krueger <torsten@nrw-online.de> schrieb am 5. Okt 1996, daß auf
beiden Seiten die VJ-(bzw. "Header"-)Komprimierung ausgeschaltet sein muß.
Windows95 reagiert äußerst empfindlich, wenn diese Option von
isdn4linux zurückgewiesen wird.
- Kann ich mit Windows95 nur mit syncPPP eine Verbindung zu isdn4linux
aufbauen?
Frank-Christian Kruegel <fchk@gigabyte.ohz.north.de> schrieb am 13. Okt
1996:
DFÜ-Netzwerk: ja. Es könnte noch eine andere Möglichkeit mit CINDI,
WISPA u.ä. von Herbert Hahnewinkel (Kosten ca 80 DM pro Lizenz, und
jeder User braucht dann eine) geben, aber das Geld habe ich nicht
ausgegeben.
- Ein Windows95-Nutzer mit einer Fritz!-Card hat nur sehr schlechte
Transferraten beim Connect mit isdn4linux - was kann man da tun?
Sven Engelhardt <sven@sik.de> schrieb am 13. Okt 1996:
AVMPort (Capi-Modememulation für Win' 95 verwenden, wichtig: auf der
Win 0.95 "Anmelden am Netzwerk" einschalten.
- Wo finde ich in Windows95 die Einstellung, damit ich ein Terminalfenster
beim Einloggen bekomme?
Sven Engelhardt <sven@sik.de> schrieb am 13. Okt 1996:
Systemsteuerung/Software/Diskette CD-ROM Admin/Apptools/Dscript
- Scriptverwaltung für DFÜ-Netzwerke (siehe nach der Installation
Start/Programme/Zubehör)
Damit das Script was empfängt, bei ISDN Echo einschalten. Bei AVMPort
geht das mit E1 im Initstring.
[Achtung: bei der Verwendung von ipppd muß das Terminalfenster
ausgeschaltet sein - die Red.]
- Ich möchte gern Daten mit einem Macintosh (Leonardokarte) austauschen,
was muß ich bzw. der Macbetreiber beachten?
Markus Reicher <a9003436@unet.univie.ac.at>:
Wenn Du den Mac anrufst, stellt er sich auf das Protokoll (X.75 oder
HDLC) ein. Wenn er Dich anruft, muß er das Protokoll explizit angeben
(z.B. durch Anfügen eines "X" für X.75) an die Rufnummer - sonst ruft
der Mac womöglich mit dem Leonardo-Protokoll an.
- Ein Macintosh mit Leonardokarte versucht anzurufen, und will chap md5
aushandeln. Wie kann ich ihn auf CHAP/PAP umschalten?
Axel Jindra <jindra@uni-koblenz.de> schrieb hierzu am 10. Jan 1997:
Gar nicht. Er soll LeoPort nehmen (ist bei der Karte immer dabei) und den
CTB-Port umlegen auf die ISDN-Karte. Dann mit FreePPP 2.5v2
<http://www.rockstar.com> die Leo als Modem einstellen und FreePPP ganz
normal konfigurieren. Da kann dann auch PAP/CHAP eingestellt werden.
- Wie arbeitet isdn4linux mit einer Cisco (HDLC) auf der Gegenstelle
zusammen?
Auf dem Cisco-Router müssen die "keep alive" Pakete abgeschaltet werden.
isdn4linux muß auf HDLC, transparent mit Cisco-Encapsulation konfiguriert
werden:
isdnctrl l2_prot <interface> hdlc
isdnctrl l3_prot <interface> trans
isdnctrl encap <interface> cisco-h
<interface> ist der Name des IP-Interfaces, das zuvor mit
isdnctrl addif <interface>
angelegt werden muß (z.B. isdn0).
[Alternativ kann man natürlich auch PPP als Protokoll verwenden - die Red.]
- Meine Cisco hat einen Bug - welche IOS ist zu empfehlen?
Jochen Wiedmann <Jochen.Wiedmann@Neckar-Alb.de> schrieb hierzu in 1996:
Seit Cisco-IOS 11.0.x (x = 7 ist das einzige, was ich kenne) habe ich
keine Probleme mehr mit Cisco <-> HDLC <-> Nicht-Cisco. Das gilt
sowohl für netgw als auch i4l als auch Banzai! an der Gegenstelle,
wobei allerdings die jeweiligen speziellen Cisco-HDLC-Optionen wichtig
sind.
- Beim Einwählen bei einer ASCEND kostet es auch dann eine Einheit, wenn
ich ein "BUSY" erhalte?
Winfried Haug <haug@seicom.net> schrieb dazu am 12. Okt 1996:
Wir hatten bis gestern hier Probleme mit AVM+W95 und Mini-Port-Treiber
(PPP m. PAP). Der Ascend hat abgenommen und 3-4 sec später aufgelegt.
Im Ascend Log stand nur Call refused, was aber nicht stimmte, da der
Ascend abgehoben hat...
Durch eine neue Firmware auf dem Ascend (4.6C+) statt der 4.6B+p2 ist
das Problem wohl weg.
Da wir davor ein anderes RACK hatten (von ITK) welches dieses Verhalten
beim Kunden nicht zeigte, gehe ich mal davon aus, daß es der
Ascend war. Neue Firmware für den Ascend gibts unter
ftp://ftp.ascend.com/
oder
ftp://ftp.ascend.de/
wobei man hier höllisch aufpassen muß, daß man das richtige Image
nimmt :-)
- Gibt es eine Mailingliste zur Ascend?
Es gibt eine entsprechende Mailingliste an der Uni Hannover.
Sie lautet: ascend-users-de@uni-hannover.de
Verwaltet wird die Liste per LISTSERV, d.h. Anmeldungen gehen an
LISTSERV@uni-hannover.de mit folgender Zeile im Mail-Body:
subscribe [meine mail-alias-adresse] ascend-users-de
oder einfach:
subscribe ascend-users-de
Thomas Stinner <Thomas.Stinner@pop-siegen.de> schrieb uns zusaetzlich:
Es gibt auch eine weitaus besser besuchte Mailingliste zum Ascend.
Diese ist allerdings in englisch (dafuer schreiben und lesen dort
auch Ascend-Techniker mit).
Anmelden kann man sich unter
majordomo@bungi.com
Im Body dann:
subscribe ascend-users
- Wie schalte ich Raw-IP auf der Ascend Max mit Radius ein?
"Framed-Protocol" muß auf "EURAW" eingestellt werden. Für die Autorisierung
per Caller Id muß "authentication-type = ascend-clid" eingestellt werden.
Thomas Stinner <Thomas.Stinner@pop-siegen.de> schrieb uns dazu am 9.Mar.97:
Kann sein, dass das mit dem Authentication Type so funktioniert, ich
nehme für sowas jedoch als Password "Ascend-CLID".
Ein Eintrag im users-file muß folgendermaßen aufgebaut sein:
69123456 Password="Ascend-CLID"
User-Name = "Username_fuer_Abrechnung"
User-Service = Framed-User
Also als Username die Caller-ID, als Password "Ascend-CLID".
- Wie schalte ich die Encapsulation "uihdlc" auf dem Max (eine Ascend) mit
Radius ein?
"Framed-Protocol" muß auf "EUUI" eingestellt werden.
- Welche Einstellungen braucht ein ELink, um mit isdn4linux
zusammenzuarbeiten?
In der Mailingliste gab Daniel Moeller (danny@rsun.lfn.unterland.de)
dazu folgenden Hinweis:
[...] Ich hab hier mehrmals täglich saubere Verbindungen zu einem
EL310, ich polle per ifcico FIDO darüber. Hier mal die Config des
Elink: ati Elink 310 Version 1.36 OK ati4
Baudrate: 115k2,N
SIN unbekannt: Ruf annehmen
Anschaltung: EDSS1
SIN ungleich &B: Ruf annehmen
Betriebsart: X.75
SIN gesendet: neutral
Mehrfachrufnummer: 980031
E1 M1 Q0 V1 X2 &B049 &C1 &D2 &R0 &S1
\A3 \J0 \N3 \Q3 \V1 %A013 %C1 %F1 FCLASS=000
S00=000 S01=000 S02=043 S03=013
S04=010 S05=008 S06=002 S07=040
S08=003 S09=000 S10=007 S11=000
S12=050 S13=01010000B S14=10011010B S15=00001110B
S16=10110011B S17=049 S18=013 S19=003
S20=000 S21=00000100B S22=000 S23=006
S24=120 S25=128 S26=016 S27=002
S28=003 S29=128 S30=000 S31=000
OK
- Wie kann ich Internet über T-Online mit i4l machen?
Rainer May <r_may@kahvi.desaster.heide.de> beschrieb das so:
(dasselbe funktioniert natürlich auch per Modem. Nur sieht da die
Initialisierungs-Sequenz natürlich anders aus.)
Ad 1: Man besorge sich diald. Keine Ahnung, wo man das Paket
findet - Archie fragen (diald ist dazu gedacht, eine
Defaultroute auf eine noch garnicht physikalisch be-
stehende SLIP oder CSLIP-Verbindung zu legen; werden
dann Pakete an dieses Pseudo-Interface geschickt, stellt
diald die (C)SLIP-Verbindung her; welche Pakete einen
Verbindungsaufbau auslösen, und wann/wie die Verbindung
wieder abgebaut wird, ist alles konfigurierbar.) Dann
installiere man das Binary und die Config-Files (man
kann die im Paket enthaltenen Muster so übernehmen;
nur, wenn z.B. ein PING einen Verbindungsaufbau bewirken
soll, muß man minimal ändern; ggf. kann man auch Timeouts
anpassen - halt etwas herumprobieren).
Ad 2: Man nehme einen Kernel mit integriertem SLIP/CSLIP oder
SLIP/CSLIP als Module (die natürlich geladen sein müssen)
Ad 3: Isdn4Linux muß natürlich auch installiert sein; wichtig
ist die Modem-Emulation (ttyIx).
Ad 4: Man starte den diald, z.B. mit folgendem Script (heißt bei
mir /etc/rc.d/rc.diald.t-online):
/usr/sbin/diald /dev/ttyI2 -m aslip local 192.168.90.9
remote 192.168.90.1 defaultroute dynamic modem crtscts
lock speed 38400 connect "chat -v -f /etc/diald/t-online"
mtu 1500 dslip-mode local-remote
(sinnvollerweise schreibt man das in eine Zeile :-)
Ad 5: Man erzeuge das Script, das bei mir "etc/diald/t-online"
heißt. Sieht ungefähr so aus:
TIMEOUT 30
ABORT "NO CARRIER"
ABORT ERROR
ABORT "NO DIALTONE"
ABORT BUSY
ABORT "NO ANSWER"
ABORT "NO MSN/EAZ"
"" ATZ
OK AT&B2000&E<MyMSN>&X1
OK ATD01910
CONNECT .
"[?25h" <ZugangsKennung>\c
"[?25h" ""
"[?25h" ""
"[?25h" <passwort>
"[?25h" *53#\c
"[?25h" *190144100#\c
"[?25h" 19\c
"STATUS OK" LIN
"" "OK"
Darin müssen natürlich einige "Platzhalter" ersetzt werden:
<MyMSN> ist die MSN, mit der man in die weite Welt hinauswill.
<Zugangskennung>: Das meist mit "000..." beginnende Zahlenmonster,
welches die Telekom einem genannt hat.
<passwort>: Das Zugangspasswort eben
In obigem Musterscript wird davon ausgegangen, daß Anschluß-
und Mitbenutzernummer dem auf der Login-Seite vorgegebenem
Default entsprechen. Ist das nicht der Fall, muß man halt
die beiden Zeilen vor "[?25h" <passwort> entsprechend anpassen
(gibt man eine Mitbenutzernummer der Art "0003" an, sollte z.B.
die Zeile vor "[?25h" <passwort> lauten:
"[?25h" 0003\c
(denn das Eingabefeld ist nach "0003" voll, es darf kein CR mehr
folgen))
Wenn der diald läuft, sollte man urplötzlich über ein Interface
"sl0" verfügen (ifconfig fragen), und die Defaultroute sollte genau
darauf zeigen (route -n gibt Aufschluß; ohne "-n" würde "route"
versuchen, die Phantasie-IP-Adressen, die man anfangs angegeben hat
(und die später von "echten" überschrieben werden) aufzulösen - muß
ja nicht sein).
Oh, wer nicht nur mit IP-Adressen arbeitet, sondern erfolgreich auch
z.B. "ftp stp.sunsite.edu" probieren will, sollte natürlich in
/etc/resolv.conf einen Nameserver eingetragen haben (der/einer der
Telekom hat die IP-Nummer 194.25.2.129).
So, und nun Ftp, Telnet, Netscape, wasweißich starten. Das war's
Übrigens: Der Diald schreibt Romane ins Syslog. Man kann den gesamten
Login-Vorgang da nachlesen, auch wenn's chaotisch aussieht. Klappt ein
Request nicht, sollte man den diald mit "kill" erwürgen (Routen werden
automatisch gelöscht) und im Syslog nachschauen. Da können Sachen
stehen wie "Zur Zeit keine verbindung möglich" - dann ist das Internet-
Gateway der Telekom down. Oder man stellt fest, daß irgendwas mit dem
Login nicht klappte - Vorsicht: Nach drei Fehl- Logins muß der Zugang
von der Telekom "entsperrt" werden; das kann man per Telefon oder
direkt von BTX aus erbitten (einfach per Terminalprogramm, z.B. seyon
oder minicom, 01910 wählen, langsam per Hand durch den Login-Screen
gehen und die Anweisungen befolgen)
Eine weitere Anleitung mit dip statt diald gibt's unter:
http://www.rosat.mpe-garching.mpg.de/~web/ISDN.html
Achtung: der dip, der mit der Suse 4.2 mitgeliefert wurde, ist defekt!
- Ich habe mir den Internetzugang über T-Online wie in einigen Newsgruppen
beschrieben zurechtgebaut, aber leider funktioniert das chat-Skript nicht
("Connect script failed").
Gerhard Träger <gerhard@gt-priv.m.eunet.de>: schrieb hierzu:
In der geschwätzigen chat-Version gibt es einen kleinen Fehler in
logf(): es wird solange in einen 256 Byte Puffer geschrieben, bis ein
Zeilenumbruch kommt. t-offline sendet aber deutlich mehr Bytes für die
Anmeldeseite ... Also entweder chat ohne -v aufrufen oder den Puffer
vergrößern (am besten mit Füllstandsüberprüfung).
- Ich möchte mit meinem Linux-System via ISDN4Linux ins Internet. Das klappt
auch. Nun möchte ich noch zusätzlich meine Rechner am Ethernetstrang mit
vom Internet profitieren lassen, aber wie?
Thomas Pfeiffer <pfeiffer@pds.de> schrieb dazu folgendes am 5. Nov 1996:
Es gibt verschiedene Möglichkeiten, je nachdem, was du denn so alles aus
deinem LAN heraus im Internet machen möchtest. Grundsätzlich gibt es drei
Möglichkeiten:
1. dein LAN ist ein offizielles Class C Netz mit im Internet gültigen
IP adressen.
Der Fall ist am einfachsten zu konfigurieren, du gibst jeder
Netzwerkkarte in dem Netz eine dieser IP adressen und legst eine
Default Route auf deine ISDN Karte, die ins Internet zu deinem
Provider führt.
2. Du möchtest aus deinem LAN heraus nur http ins Internet machen.
In dem fall kannst du dir für dein LAN IP adressen ausdenken,
die einzige offizielle IP Adresse ist die, die der ISDN Karte
zugewiesen wird. auf deinem linux isdn router mußt du einen
Proxy Server installieren, der bei deinen Browsern auch
eingetragen wird. Du brauchst in dem Fall keine Default Routen.
3. Du möchtest dich immer nur aus dem LAN auf deinem Linux ISDN
Router einloggen und VON DORT deine Arbeit im Internet verrichten.
Das ist noch einfacher, denn dann mußt du nicht einmal einen
Proxy Server.
Eike Stepper <isdn@esc-net.de> ergänzt am 6. Nov 1996:
Den drei Möglichkeiten würde ich noch eine vierte hinzufügen. Selber
hab ich es zwar noch nicht ausprobiert (da ich die erwähnte 1.
Möglichkeit bevorzuge und ein Class-C-Subnetz habe, hehe ;) aber ich
weiß von einem Freund, daß er nach einigem Tüfteln am Linux-Kernel
dann tatsächlich das IP-Masquerading hinbekommen hat.
Das funzt irgendwie soähnlich wie ein proxy (wenn man den
ip-versteck-effekt betrachtet). Bietet natürlich kein Caching,
maskeriert aber nach aussen hin alle internen Klau-IPs ;) mit der
einen offiziellen des ISDN-Interface. Frag mich nicht, wie da
irgendein Routing hinhaut, aber es geht...
Wenn ich mich nicht irre, hat mein Freund sogar mit einer dynamischen
IP maskeriert ?!
- Wie funktioniert denn nun die vierte Möglichkeit, Linux + Masquerading?
Rainer May <r_may@khavi.desaster.heide.de> hat hierzu eine tolle Anleitung
zusammengestellt (siehe nachfolgende Frage).
Die nachfolgende Anleitung wurde von Rainer May
<r_may@khavi.desaster.heide.de> zusammengestellt.
- Ich habe ein lokales Netzwerk (LAN), in dem Rechner der verschiedensten
Plattformen - Win95, Win311, NT, Amiga (AmiTCP) und MacIntosh (MacTCP) -
über einen Linux-Router mit der Außenwelt verbunden werden sollen. In der
Linux-Maschine steckt eine ISDN-Karte. Von meinem Provider bekomme ich
dynamisch eine IP-Adresse zugewiesen, wenn die Verbindung aufgebaut wird.
Nun möchte ich aber nicht nur vom Linux-Router direkt, sondern von jedem
Rechner im LAN ins Internet kommen. Wie macht man das?
Die meiste Arbeit ist auf Linux-Seite zu erledigen. Zunächst einmal
braucht man einen Kernel mit eingebautem IP-Forwarding und Masquerading.
D.h., bei "make config" müssen folgende Fragen wie folgt beantwortet
werden:
Prompt for development and/or incomplete code/drivers Y
Enable loadable module support Y
Networking support Y
Network firewalls Y
TCP/IP networking Y
IP: forwarding/gatewaying Y
IP: firewalling Y
IP: masquerading Y
PPP (point-to-point) support (wenn PPP zum Provider) Y
SLIP (serial line) support Y
Ethernet (10 or 100Mbit) (oder Arcnet oder ...) Y
ISDN support [1] M
Support synchronous PPP (wenn ipppd benutzt wird) Y
HiSax SiemensChipSet driver support M
(dann den HiSax für die ISDN Karte wählen)
([1] Wer mag, kann die ISDN-Treiber natürlich auch direkt in den
Kernel einbauen, anstatt sie als Module zu verwenden.)
Anschließend den Kernel wie üblich mit "make dep", "make clean", "make
zImage", "make modules" und "make modules_install" bauen.
Auf das Installieren von PPP und der ISDN-Treiber wird an anderer Stelle
ausführlich eingegangen.
Hier geht es weiter, wenn folgende Voraussetzungen erfüllt sind:
* Das ISDN-Subsystem läuft, d.h., von Linux aus kann eine Verbindung
zum Provider hergestellt werden.
* Das lokale Netzwerk (Ethernet usw.) läuft auch, vorzugsweise unter
Verwendung "freier" IP-Adressen (z.B. 192.168.xx.xx), und der Linux-
Host kann von allen anderen Rechnern im LAN erreicht werden (z.B.
per ping).
Nun gilt es, zweierlei zu erreichen:
* Zugriffe von einem beliebigen Rechner im LAN auf eine nicht-lokale
IP-Adresse sollen den Linux-Router veranlassen, eine Verbindung zum
Provider aufzubauen; und
* Der Linux-Router soll zwar die Rechner im LAN mit dem Provider
verbinden, diesem gegenüber aber verheimlichen, daß nicht der Router
selbst Empfänger/Absender der entsprechenden IP-Pakete ist.
Beginnen wir mit dem zweiten Punkt. Dieses "Verheimlichen" hat nichts damit
zu tun, daß man seinen Provider hintergehen will (obwohl man auf diese
Weise auch selbst Provider spielen und seine Kunden klammheimlich über
einen billigen "Privat-Zugang" ins Internet bringen kann), sondern
mit technischen Notwendigkeiten. Denn nur das Interface des Linux-Rechners,
das die Verbindung zum Provider herstellt, bekommt von diesem eine
IP-Adresse verpaßt, die der Provider auch kennt. Trägt z.B. der Router im
LAN die lokale IP-Adresse 192.168.1.1, und ein anderer Rechner die
192.168.1.2, dann kennt der Provider diese Adressen ja nicht. Er weist z.B.
dem PPP-Interface des Routers die Adresse 123.234.345.99 zu - und nur bei
Paketen aus dem Internet, die an diese Nummer adressiert sind, weiß er
auch, an wen er die Pakete schicken soll. Daher muß der Router Pakete von
anderen Rechnern im LAN "maskieren" - mit seiner eigenen, dynamisch
zugewiesenen Adresse (und dabei natürlich Buch darüber führen, was an
wen von wem kam, um die Antwort-Pakete richtig zuzustellen).
Zum Glück ist diese Funktion in den Linux-Kernel =>2.0.0 schon eingebaut
(s.o.) - sie nennt sich "IP-Masquerading". Vereinfacht ausgedrückt geht
das so:
Ein LAN-Rechner schickt ein Paket ab, das neben IP-Nummer und Ziel-Port des
Empfängers auch die "Absender-Adresse" in Form einer IP-Nummer und eines
Antwort-Ports trägt. Der maskierende Router nun ersetzt die Absender-IP
durch seine eigene und den Rücksende-Port durch einen freien aus seinem
Fundus. Unter dieser "freien" Portnummer werden die originalen Absender-
Daten gespeichert. Kommt nun ein Antwort-Paket aus dem Internet an diesen
Port, werden dessen Empfänger-Adresse und -Port mit der gespeicherten
Rücksende-Adresse überschrieben und an den LAN-Rechner weitergeleitet.
Paket für Paket.
Leicht einsehbar ist übrigens, daß dieses Verfahren nur mit Diensten
funktioniert, bei denen auch eine Rücksende-Adresse angegeben wird. Dazu
gehören u.a. telnet, http, ftp, irc (eingeschränkt), nicht aber Echo
(ping).
Zurück zur Praxis. Damit das Masquerading auch bei FTP und IRC
funktioniert, werden zunächst zwei Module geladen:
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
Dann werden die Forward-Rules des Kernel zum Masquerading gezwungen:
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b
Das Programm ipfwadm gibt es per Anonymous FTP unter:
ftp://ftp.xos.nl/pub/linux/ipfwadm/ipfwadm-2.3.0.tar.gz
In diesem Beispiel werden im LAN die IP-Adressen 192.168.123.1 bis
192.168.123.254 benutzt. Legen wir zur Vereinfachung fest, der Linux-Router
habe dabei die Adresse 192.168.123.1.
Obige Zeile bewirkt, daß IP-Pakete, die von 192.168.123.x ausgehen und
an wenauchimmer gerichtet sind, maskiert werden. Das hat den Nachteil, daß
auch innerhalb des LAN fleißig drauflosmaskiert wird, was man aber durch
Einfügen weiterer Rules vermeiden kann. "man ipfwadm" sei hier zur Lektüre
empfohlen.
(Hinweis von Ralf Rudolph <ralf@artifex.de> hierzu:
Hmm. So wie ich das sehe, passiert da gar nichts. Grund: Die Rechner im
lokalen Netz unterhalten sich ja direkt über die fake-Adressen im
192.168.123.xxx-Netz. Zum Beweis kannst Du Deine Linux-Kiste einfach
abschalten (naja OK, shutdown...), und die lokalen Rechner werden sich
weiter unterhalten können. Also wird da auch nix masqueraded.
Der Hintergrund: Masquerading ist eine FORWARD Rule im Firewall und
wird daher auch nur beim FORWARDEN (wörtlich zu nehmen: WEITERleiten)
verwendet.
Netz-intern wird nichts geforwarded und deshalb auch nichts
masqueraded, solange Du nur eine Netzwerkkarte hast. Bei mehreren
Karten hast Du jedoch recht: Hier sollte man entsprechende Routing-
und auch ipfwadm-Einträge vornehmen.
Antwort: Ist tatsächlich etwas ungenau; schaden tut es aber nix, es sei
denn, man will unbedingt nicht maskierbare Services benutzen.)
Das "Verstecken" des LAN vor dem Provider haben wir nun erreicht. Jetzt
gilt es, bei Bedarf einen automatischen Verbindungsaufbau zu erzwingen.
Dafür ist es zunächst nötig, die anderen Rechner im LAN dazu zu bringen,
alle für "Außerhalb" bestimmten IP-Pakete an den Linux-Router zu
übergeben und diesem die Weiterleitung zu überlassen. Nichts leichter als
das: Sowohl bei den verschiedenen Windows-Versionen, als auch beim AmiTCP
und beim MacTCP gibt es in der Konfiguration den Stichwort "Default-
Gateway" oder nur "Gateway". Hier ist die lokale IP-Adresse des
Routers einzutragen (denn die spätere Adresse, die vom Provider kommt, ist
ja erstens noch nicht bekannt und ändert sich zweitens bei jedem Anruf).
Letzter Schritt ist dann, das "dial-on-demand" einzurichten. In
Verbindung mit isdn4linux gibt es dafür zwei Möglichkeiten:
* Man verwendet synchrones PPP für die Verbindung zum Provider, also
den "ipppd". Dann ist nichts weiter zu tun als dafür zu sorgen, daß
immer die Default-Route des Routers auf das entsprechende ipppx-
Interface weist. Vorsicht: Beim Verbindungsabbau löscht der Kernel
diese Route!
Sie muß also z.B. in der Datei /etc/ppp/ip-down neu gesetzt werden.
Das Risiko bei diesem Verfahren sind Programme auf den LAN-Rechnern,
die mehr oder weniger regelmäßig Nameserver-Requests, Keepalive-
Pakete oder ARP-Broadcastings erzeugen - dann stellt nämlich der
Router jedesmal eine Verbindung zum Provider her. Die Telekom wird's
danken.
Übrigens kann es passieren, daß manche aus dem LAN initiierte
Verbindungen recht lange auf Antwort warten. Ich weiß nicht, ob
Kernel oder ipppd das "auslösende" Paket verschlucken, oder die
Antwort darauf unterschlagen; ich weiß aber, daß es hilft, z.B. bei
Netscape wenige Sekunden nach Anforderung der ersten Seite auf den
"roten Knopf" zu drücken und die Seite nochmals anzufordern.
Wie bereits erwähnt: Die Konfiguration des ipppd wird an anderer
Stelle ausführlich erklärt - siehe entsprechende Fragen sowie
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
* Benutzt man asynchrones ppp oder gar SLIP/CSLIP für die Verbindung
zum Provider, kann man das Programm "diald" [4] verwenden. Es bietet
zudem den Vorteil, extrem stark konfigurierbar zu sein; so kann man
z.B. festlegen, daß zwischen 0900 und 1200 grundsätzlich keine
Verbindung aufgebaut wird, daß Nameserver-Anfragen eine Verbindung
zwar nicht aufbauen, aber offenhalten können u.v.m. Wer sich mit
diesen Konfigurationsmöglichkeiten nicht herumschlagen mag, braucht
das indes auch nicht - die Default-Konfiguration kann man ohne
Gefahr für Leib und Geldbörse übernehmen :-)
So.
Wenn jetzt das Masquerading eingerichtet wurde,
wenn der Linux-Router auf allen LAN-Rechnern als Gateway eingetragen
wurde,
wenn ein "ping abc.edu", eingetippt auf der Console des Routers, eine
Verbindung zum Provider aufbaut,
dann sollte damit auch für alle Rechner im LAN der Weg ins Internet
frei sein.
- Wie kann ich den Teilnehmern meines lokalen Netzes mit Linux-Host
ermöglichen, die ISDN Karte(n) im Linux PC mitzunutzen?
Rainer May <r_may@khavi.desaster.heide.de> schrieb dazu am 10. Dez 1996:
öh ... "modemd" auf Linux-Seite, zusammen mit der entsprechenden
Software z.B. fuer W95 (emuliert halt auf einer telnet-Verbindung
einen Comport) macht sowas doch recht schön...
- Wo gibt's den "modemd", und für welche Plattformen gibt es "Clients"?
Rainer May <r_may@khavi.desaster.heide.de> schrieb dazu am 10. Dez 1996:
Theoretisch (und praktisch auch) tut es jeder etwas komfortablere
telnet-Client, den man dann wie ein Terminalprogramm benutzen kann.
Auch uucicos sollte es dafür geben (unter DOS fxuucico in Verbindung
mit fxwtcp, zum Bleistift).
Will man generell für beliebige Anwendungen eine Art "remote COMport"
haben, gibt es (wie erwähnt) COMT für Windows (95), für Amigas
das "telser.device". Für Mac soll es auch Entsprechendes geben
(die Systemarchitektur des MacIntosh lädt ja auch dazu ein), Namen
kenne ich allerdings nicht.
modemd (eigentlich nur ein PERL-Einzeiler, wenn ich mich recht entsinne)
arbeitet hier jedenfalls problemlos mit COMt und telser.device
zusammen.
- Wo finde ich COMt?
Oliver Hahn <oliver@bbtt.de> schrieb dazu am 15. Dez 1996:
Versuch's mal auf einem Simtel-Mirror (z.B. ftp.funet.fi) im Verzeichnis
pub/simtelnet/win3/inet. Das Ding heißt comt200.zip.
ftp://ftp.funet.fi/pub/simtelnet/win3/inet/comt200.zip
- Wie sieht der "PERL-Einzeiler" "modemd" nun genau aus?
Marc Neitzner <marc@zeus.han.de> schrieb dazu am 15. Dez 1996:
#!/usr/bin/perl
select((select(STDOUT), $| = 1)[$[]);
select((select(STDIN), $| = 1)[$[]);
exec "cu","-E","''", "-l", "$ARGV[0]";
die "$0: Cant exec cu: $!\n";
Und dann muss das Ding per inetd gestartet werden:
modem 20006/tcp modemd # Modem service via TCP
isdn 20007/tcp modemd # ISDN service via TCP
Nachteil: comt-2.0 ist nur für 16Bit Anwendungen "sichtbar". Der
Einsatz unter win95 und Windows NT bleibt also auch dort auf 16Bit Kram
beschränkt!
2.13 Isdn der Provider auch kennt. Trägt z.B. der Router im
LAN die lokale IP-Adresse 192.168.1.1, und ein anderer Rechner die
192.168.1.2, dann kennt der Provider diese Adressen ja nicht. Er weist z.B.
dem PPP-Interface des Routers die Adresse 123.234.345.99 zu - und nur bei
Paketen aus dem Internet, die an diese Nummer adressiert sind, weiß er
auch, an wen er die Pakete schicken soll. Daher muß der Router Pakete von
anderen Rechnern im LAN "maskieren" - mit seiner eigenen, dynamisch
zugewiesenen Adresse (und dabei natürlich Buch darüber führen, was an
wen von wem kam, um die Antwort-Pakete richtig zuzustellen).
Zum Glück ist diese Funktion in den Linux-Kernel =>2.0.0 schon eingebaut
(s.o.) - sie nennt sich "IP-Masquerading". Vereinfacht ausgedrückt geht
das so:
Ein LAN-Rechner schickt ein Paket ab, das neben IP-Nummer und Ziel-Port des
Empfängers auch die "Absender-Adresse" in Form einer IP-Nummer und eines
Antwort-Ports trägt. Der maskierende Router nun ersetzt die Absender-IP
durch seine eigene und den Rücksende-Port durch einen freien aus seinem
Fundus. Unter dieser "freien" Portnummer werden die originalen Absender-
Daten gespeichert. Kommt nun ein Antwort-Paket aus dem Internet an diesen
Port, werden dessen Empfänger-Adresse und -Port mit der gespeicherten
Rücksende-Adresse überschrieben und an den LAN-Rechner weitergeleitet.
Paket für Paket.
Leicht einsehbar ist übrigens, daß dieses Verfahren nur mit Diensten
funktioniert, bei denen auch eine Rücksende-Adresse angegeben wird. Dazu
gehören u.a. telnet, http, ftp, irc (eingeschränkt), nicht aber Echo
(ping).
Zurück zur Praxis. Damit das Masquerading auch bei FTP und IRC
funktioniert, werden zunächst zwei Module geladen:
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
Dann werden die Forward-Rules des Kernel zum Masquerading gezwungen:
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b
Das Programm ipfwadm gibt es per Anonymous FTP unter:
ftp://ftp.xos.nl/pub/linux/ipfwadm/ipfwadm-2.3.0.tar.gz
In diesem Beispiel werden im LAN die IP-Adressen 192.168.123.1 bis
192.168.123.254 benutzt. Legen wir zur Vereinfachung fest, der Linux-Router
habe dabei die Adresse 192.168.123.1.
Obige Zeile bewirkt, daß IP-Pakete, die von 192.168.123.x ausgehen und
an wenauchimmer gerichtet sind, maskiert werden. Das hat den Nachteil, daß
auch innerhalb des LAN fleißig drauflosmaskiert wird, was man aber durch
Einfügen weiterer Rules vermeiden kann. "man ipfwadm" sei hier zur Lektüre
empfohlen.
(Hinweis von Ralf Rudolph <ralf@artifex.de> hierzu:
Hmm. So wie ich das sehe, passiert da gar nichts. Grund: Die Rechner im
lokalen Netz unterhalten sich ja direkt über die fake-Adressen im
192.168.123.xxx-Netz. Zum Beweis kannst Du Deine Linux-Kiste einfach
abschalten (naja OK, shutdown...), und die lokalen Rechner werden sich
weiter unterhalten können. Also wird da auch nix masqueraded.
Der Hintergrund: Masquerading ist eine FORWARD Rule im Firewall und
wird daher auch nur beim FORWARDEN (wörtlich zu nehmen: WEITERleiten)
verwendet.
Netz-intern wird nichts geforwarded und deshalb auch nichts
masqueraded, solange Du nur eine Netzwerkkarte hast. Bei mehreren
Karten hast Du jedoch recht: Hier sollte man entsprechende Routing-
und auch ipfwadm-Einträge vornehmen.
Antwort: Ist tatsächlich etwas ungenau; schaden tut es aber nix, es sei
denn, man will unbedingt nicht maskierbare Services benutzen.)
Das "Verstecken" des LAN vor dem Provider haben wir nun erreicht. Jetzt
gilt es, bei Bedarf einen automatischen Verbindungsaufbau zu erzwingen.
Dafür ist es zunächst nötig, die anderen Rechner im LAN dazu zu bringen,
alle für "Außerhalb" bestimmten IP-Pakete an den Linux-Router zu
übergeben und diesem die Weiterleitung zu überlassen. Nichts leichter als
das: Sowohl bei den verschiedenen Windows-Versionen, als auch beim AmiTCP
und beim MacTCP gibt es in der Konfiguration den Stichwort "Default-
Gateway" oder nur "Gateway". Hier ist die lokale IP-Adresse des
Routers einzutragen (denn die spätere Adresse, die vom Provider kommt, ist
ja erstens noch nicht bekannt und ändert sich zweitens bei jedem Anruf).
Letzter Schritt ist dann, das "dial-on-demand" einzurichten. In
Verbindung mit isdn4linux gibt es dafür zwei Möglichkeiten:
* Man verwendet synchrones PPP für die Verbindung zum Provider, also
den "ipppd". Dann ist nichts weiter zu tun als dafür zu sorgen, daß
immer die Default-Route des Routers auf das entsprechende ipppx-
Interface weist. Vorsicht: Beim Verbindungsabbau löscht der Kernel
diese Route!
Sie muß also z.B. in der Datei /etc/ppp/ip-down neu gesetzt werden.
Das Risiko bei diesem Verfahren sind Programme auf den LAN-Rechnern,
die mehr oder weniger regelmäßig Nameserver-Requests, Keepalive-
Pakete oder ARP-Broadcastings erzeugen - dann stellt nämlich der
Router jedesmal eine Verbindung zum Provider her. Die Telekom wird's
danken.
Übrigens kann es passieren, daß manche aus dem LAN initiierte
Verbindungen recht lange auf Antwort warten. Ich weiß nicht, ob
Kernel oder ipppd das "auslösende" Paket verschlucken, oder die
Antwort darauf unterschlagen; ich weiß aber, daß es hilft, z.B. bei
Netscape wenige Sekunden nach Anforderung der ersten Seite auf den
"roten Knopf" zu drücken und die Seite nochmals anzufordern.
Wie bereits erwähnt: Die Konfiguration des ipppd wird an anderer
Stelle ausführlich erklärt - siehe entsprechende Fragen sowie
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
* Benutzt man asynchrones ppp oder gar SLIP/CSLIP für die Verbindung
zum Provider, kann man das Programm "diald" [4] verwenden. Es bietet
zudem den Vorteil, extrem stark konfigurierbar zu sein; so kann man
z.B. festlegen, daß zwischen 0900 und 1200 grundsätzlich keine
Verbindung aufgebaut wird, daß Nameserver-Anfragen eine Verbindung
zwar nicht aufbauen, aber offenhalten können u.v.m. Wer sich mit
diesen Konfigurationsmöglichkeiten nicht herumschlagen mag, braucht
das indes auch nicht - die Default-Konfiguration kann man ohne
Gefahr für Leib und Geldbörse übernehmen :-)
So.
Wenn jetzt das Masquerading eingerichtet wurde,
wenn der Linux-Router auf allen LAN-Rechnern als Gateway eingetragen
wurde,
wenn ein "ping abc.edu", eingetippt auf der Console des Routers, eine
Verbindung zum Provider aufbaut,
dann sollte damit auch für alle Rechner im LAN der Weg ins Internet
frei sein.
Wie sieht der "PERL-Einzeiler" "modemd" nun genau aus?
Marc Neitzner <marc@zeus.han.de> schrieb dazu am 15. Dez 1996:
#!/usr/bin/perl
select((select(STDOUT), $| = 1)[$[]);
select((select(STDIN), $| = 1)[$[]);
exec "cu","-E","''", "-l", "$ARGV[0]";
die "$0: Cant exec cu: $!\n";
Und dann muss das Ding per inetd gestartet werden:
modem 20006/tcp modemd # Modem service via TCP
isdn 20007/tcp modemd # ISDN service via TCP
Nachteil: comt-2.0 ist nur für 16Bit Anwendungen "sichtbar". Der
Einsatz unter win95 und Windows NT bleibt also auch dort auf 16Bit Kram
beschränkt!
2.12 Isdnlog
- Wie kann ich isdnlog dazu bringen, mir die High Layer Compatibility
(Speech, Video,...) so anzuzeigen, wie ich es gerne hätte?
Gernot Zander <hifi@scorpio.in-berlin.de> postete am 6. Okt 1996 einen ent-
sprechenden Patch in der Mailingliste, der isdnlog besser anpaßt.
- Kann man in der Ausgabe von isdnrep die Dienstekennung eines eingehenden
Anrufes sehen?
Andreas Kool <akool@Kool.f.EUnet.de> schrieb hierzu am 3. Dez 1996:
Im isdnrep indirekt schon -- sofern du alle von isdnlog ausdekodierten
Dienstkennungen in deiner "isdnlog.conf" als Alias eingetragen hast ...
- Warum erfaßt isdnlog neben den Gebühren nicht auch die Telefonnummer, die
meine anderen ISDN-Geräte (z.B. ISDN-Telefon) anrufen?
Weil die ISDN-Karte wie alle ISDN-Geräte getrennte Sende- und
Empfangsleitungen (RX bzw. TX Leitung) hat. Isdnlog müßte die auf der
Sendeleitung übermittelten Daten belauschen, um die Telefonnummer zu
erfahren. Zumindestens bei der Teleskarte ist das jedoch nicht möglich, wie
Karsten Keil <keil@temic-ech.spacenet.de> am 12. Feb 1997 schrieb:
Das ist bei allen Karten mit 1 Siemens ISAC so, der hat (und braucht)
nur 1 Empfaenger und 1 Sender.
Theoretisch besteht eine Moeglichkeit, mit nur einem Empfaenger den
kompletten D-Kanal zu belauschen (das macht der ISAC sogar) und zwar
werden die auf der RX Leitung empfangenden D-Bits auf sogenannte Echo
Bits zeitversetzt auf die TX Leitung kopiert, darueber erfolgt die
Access Kontrolle (Kollisionserkennung) des S0 Busses.
Leider gibt es im ISAC im TA Mode keine Moeglichkeit die ECHO Bits aus
einem Register zu lesen.
Zu möglichen Lösungen siehe nächste Frage.
- Wie kann ich trotzdem isdnlog dazu bringen, die Telefonnummer auch von
anderen ISDN-Geräten mitzubekommen?
Es gibt zwei Möglichkeiten. Zum einen gibt es von der Deutschen Telekom die
kostenpflichtige Möglichkeit, alle Daten nochmal zurückschicken zu lassen
(COLP = Connected Line Identification Presentation, ca. DM 10,- pro Monat
je Basisanschluß). Diese kann isdnlog (>=2.52) dann wieder auf der TX
Leitung lesen.
Alternativ dazu wird isdnlog ab der nächsten Version (aktuell ist 2.52)
die Möglichkeit bieten, mit einer zweiten, "verpolten" Teles-Karte zu
arbeiten, bei der die RX Leitung an den TX Anschluß der Karte geführt wird.
Die RX Leitung der Karte darf an keine der Leitungen angeschlossen werden!
Aufgrund der Schaltung kann die Teles-Karte für keinen anderen Zweck mehr
eingesetzt werden. Das ganze sieht dann so aus:
B 3 -- RX+ 2a ---------------\
U 4 -- TX+ 1a -- offen ------------
S 5 -- TX- 1b -- offen ------------ Karte
6 -- RX- 2b ---------------/
Eine theoretische dritte Möglichkeit gibt es noch für alle, die eine
eigene TK-Anlage haben, über die sämtliche weiteren Geräte angeschlossen
sind. Falls diese Telefonanlage ebenfalls alle ausgehenden Telefonnummern
protokollieren kann, könnten diese ausgelesen werden (üblicherweise über
eine serielle Schnittstelle).
Es gibt jedoch einen Grund, warum isdnlog das nicht schon längst
unterstützt. Um die Daten zu verwerten, müßte isdnlog diese sofort beim
RELEASE COMPLETE zur Verfügung gestellt bekommen, bevor auf dem D-Kanal
neue Informationen übermittelt werden. Leider sind die bisher getesteten
Telefonanlagen dafür zu langsam (insbesondere die weit verbreitete ISTEC).
Als einzige Möglichkeit bleibt, die Daten nachträglich zu kombinieren.
Dabei kommt es aber zur Schwierigkeit, die unterschiedlichen Uhrzeiten
zu synchronisieren. Wer das realisieren möchte, ist dazu herzlich gerne
eingeladen (ich stelle auch gerne entsprechende Logs von meiner Ackermann
Euracom zur Verfügung - Matthias Heßler <hessler@wi-inf.uni-essen.de>).
- Erfaßt isdnlog auch die neuen Tarife der deutschen Telekom (City Weekend,
City Plus)?
Da die Vermittlungsstellen der Telekom das nicht hinbekommen, werden die
Gebühreninformationen nicht korrekt übermittelt. Die nächste Version von
isdnlog (>2.52) wird das jedoch können.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
niederländischen Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_NL" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
schweizer Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_CH" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich mir den Datendurchsatz grafisch anzeigen lassen?
Dazu gibt's "xisdnload". Clemens Perz <listperz@gwsnet.ttt.de> wußte am
6. Feb 1997 noch eine weitere Möglichkeit:
Ich hab auf der Sunsite ein kleines Tool Namens netload für die Console
gefunden und es auf ISDN-Interfaces angepasst. Damit kann man recht
einfach den momentanen Traffic auf der Leitung in Augenschein nehmen.
Zu finden auf:
ftp://ftp.region.trier.de/pub/unix/linux/sources/network/isdn/netload-0.92.isdn.tar.gz
Einfach starten mit netload isdnxx
2.13 Isdn der Provider auch kennt. Trägt z.B. der Router im
LAN die lokale IP-Adresse 192.168.1.1, und ein anderer Rechner die
192.168.1.2, dann kennt der Provider diese Adressen ja nicht. Er weist z.B.
dem PPP-Interface des Routers die Adresse 123.234.345.99 zu - und nur bei
Paketen aus dem Internet, die an diese Nummer adressiert sind, weiß er
auch, an wen er die Pakete schicken soll. Daher muß der Router Pakete von
anderen Rechnern im LAN "maskieren" - mit seiner eigenen, dynamisch
zugewiesenen Adresse (und dabei natürlich Buch darüber führen, was an
wen von wem kam, um die Antwort-Pakete richtig zuzustellen).
Zum Glück ist diese Funktion in den Linux-Kernel =>2.0.0 schon eingebaut
(s.o.) - sie nennt sich "IP-Masquerading". Vereinfacht ausgedrückt geht
das so:
Ein LAN-Rechner schickt ein Paket ab, das neben IP-Nummer und Ziel-Port des
Empfängers auch die "Absender-Adresse" in Form einer IP-Nummer und eines
Antwort-Ports trägt. Der maskierende Router nun ersetzt die Absender-IP
durch seine eigene und den Rücksende-Port durch einen freien aus seinem
Fundus. Unter dieser "freien" Portnummer werden die originalen Absender-
Daten gespeichert. Kommt nun ein Antwort-Paket aus dem Internet an diesen
Port, werden dessen Empfänger-Adresse und -Port mit der gespeicherten
Rücksende-Adresse überschrieben und an den LAN-Rechner weitergeleitet.
Paket für Paket.
Leicht einsehbar ist übrigens, daß dieses Verfahren nur mit Diensten
funktioniert, bei denen auch eine Rücksende-Adresse angegeben wird. Dazu
gehören u.a. telnet, http, ftp, irc (eingeschränkt), nicht aber Echo
(ping).
Zurück zur Praxis. Damit das Masquerading auch bei FTP und IRC
funktioniert, werden zunächst zwei Module geladen:
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
Dann werden die Forward-Rules des Kernel zum Masquerading gezwungen:
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b
Das Programm ipfwadm gibt es per Anonymous FTP unter:
ftp://ftp.xos.nl/pub/linux/ipfwadm/ipfwadm-2.3.0.tar.gz
In diesem Beispiel werden im LAN die IP-Adressen 192.168.123.1 bis
192.168.123.254 benutzt. Legen wir zur Vereinfachung fest, der Linux-Router
habe dabei die Adresse 192.168.123.1.
Obige Zeile bewirkt, daß IP-Pakete, die von 192.168.123.x ausgehen und
an wenauchimmer gerichtet sind, maskiert werden. Das hat den Nachteil, daß
auch innerhalb des LAN fleißig drauflosmaskiert wird, was man aber durch
Einfügen weiterer Rules vermeiden kann. "man ipfwadm" sei hier zur Lektüre
empfohlen.
(Hinweis von Ralf Rudolph <ralf@artifex.de> hierzu:
Hmm. So wie ich das sehe, passiert da gar nichts. Grund: Die Rechner im
lokalen Netz unterhalten sich ja direkt über die fake-Adressen im
192.168.123.xxx-Netz. Zum Beweis kannst Du Deine Linux-Kiste einfach
abschalten (naja OK, shutdown...), und die lokalen Rechner werden sich
weiter unterhalten können. Also wird da auch nix masqueraded.
Der Hintergrund: Masquerading ist eine FORWARD Rule im Firewall und
wird daher auch nur beim FORWARDEN (wörtlich zu nehmen: WEITERleiten)
verwendet.
Netz-intern wird nichts geforwarded und deshalb auch nichts
masqueraded, solange Du nur eine Netzwerkkarte hast. Bei mehreren
Karten hast Du jedoch recht: Hier sollte man entsprechende Routing-
und auch ipfwadm-Einträge vornehmen.
Antwort: Ist tatsächlich etwas ungenau; schaden tut es aber nix, es sei
denn, man will unbedingt nicht maskierbare Services benutzen.)
Das "Verstecken" des LAN vor dem Provider haben wir nun erreicht. Jetzt
gilt es, bei Bedarf einen automatischen Verbindungsaufbau zu erzwingen.
Dafür ist es zunächst nötig, die anderen Rechner im LAN dazu zu bringen,
alle für "Außerhalb" bestimmten IP-Pakete an den Linux-Router zu
übergeben und diesem die Weiterleitung zu überlassen. Nichts leichter als
das: Sowohl bei den verschiedenen Windows-Versionen, als auch beim AmiTCP
und beim MacTCP gibt es in der Konfiguration den Stichwort "Default-
Gateway" oder nur "Gateway". Hier ist die lokale IP-Adresse des
Routers einzutragen (denn die spätere Adresse, die vom Provider kommt, ist
ja erstens noch nicht bekannt und ändert sich zweitens bei jedem Anruf).
Letzter Schritt ist dann, das "dial-on-demand" einzurichten. In
Verbindung mit isdn4linux gibt es dafür zwei Möglichkeiten:
* Man verwendet synchrones PPP für die Verbindung zum Provider, also
den "ipppd". Dann ist nichts weiter zu tun als dafür zu sorgen, daß
immer die Default-Route des Routers auf das entsprechende ipppx-
Interface weist. Vorsicht: Beim Verbindungsabbau löscht der Kernel
diese Route!
Sie muß also z.B. in der Datei /etc/ppp/ip-down neu gesetzt werden.
Das Risiko bei diesem Verfahren sind Programme auf den LAN-Rechnern,
die mehr oder weniger regelmäßig Nameserver-Requests, Keepalive-
Pakete oder ARP-Broadcastings erzeugen - dann stellt nämlich der
Router jedesmal eine Verbindung zum Provider her. Die Telekom wird's
danken.
Übrigens kann es passieren, daß manche aus dem LAN initiierte
Verbindungen recht lange auf Antwort warten. Ich weiß nicht, ob
Kernel oder ipppd das "auslösende" Paket verschlucken, oder die
Antwort darauf unterschlagen; ich weiß aber, daß es hilft, z.B. bei
Netscape wenige Sekunden nach Anforderung der ersten Seite auf den
"roten Knopf" zu drücken und die Seite nochmals anzufordern.
Wie bereits erwähnt: Die Konfiguration des ipppd wird an anderer
Stelle ausführlich erklärt - siehe entsprechende Fragen sowie
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
* Benutzt man asynchrones ppp oder gar SLIP/CSLIP für die Verbindung
zum Provider, kann man das Programm "diald" [4] verwenden. Es bietet
zudem den Vorteil, extrem stark konfigurierbar zu sein; so kann man
z.B. festlegen, daß zwischen 0900 und 1200 grundsätzlich keine
Verbindung aufgebaut wird, daß Nameserver-Anfragen eine Verbindung
zwar nicht aufbauen, aber offenhalten können u.v.m. Wer sich mit
diesen Konfigurationsmöglichkeiten nicht herumschlagen mag, braucht
das indes auch nicht - die Default-Konfiguration kann man ohne
Gefahr für Leib und Geldbörse übernehmen :-)
So.
Wenn jetzt das Masquerading eingerichtet wurde,
wenn der Linux-Router auf allen LAN-Rechnern als Gateway eingetragen
wurde,
wenn ein "ping abc.edu", eingetippt auf der Console des Routers, eine
Verbindung zum Provider aufbaut,
dann sollte damit auch für alle Rechner im LAN der Weg ins Internet
frei sein.
Wie sieht der "PERL-Einzeiler" "modemd" nun genau aus?
Marc Neitzner <marc@zeus.han.de> schrieb dazu am 15. Dez 1996:
#!/usr/bin/perl
select((select(STDOUT), $| = 1)[$[]);
select((select(STDIN), $| = 1)[$[]);
exec "cu","-E","''", "-l", "$ARGV[0]";
die "$0: Cant exec cu: $!\n";
Und dann muss das Ding per inetd gestartet werden:
modem 20006/tcp modemd # Modem service via TCP
isdn 20007/tcp modemd # ISDN service via TCP
Nachteil: comt-2.0 ist nur für 16Bit Anwendungen "sichtbar". Der
Einsatz unter win95 und Windows NT bleibt also auch dort auf 16Bit Kram
beschränkt!
2.12 Isdnlog
- Wie kann ich isdnlog dazu bringen, mir die High Layer Compatibility
(Speech, Video,...) so anzuzeigen, wie ich es gerne hätte?
Gernot Zander <hifi@scorpio.in-berlin.de> postete am 6. Okt 1996 einen ent-
sprechenden Patch in der Mailingliste, der isdnlog besser anpaßt.
- Kann man in der Ausgabe von isdnrep die Dienstekennung eines eingehenden
Anrufes sehen?
Andreas Kool <akool@Kool.f.EUnet.de> schrieb hierzu am 3. Dez 1996:
Im isdnrep indirekt schon -- sofern du alle von isdnlog ausdekodierten
Dienstkennungen in deiner "isdnlog.conf" als Alias eingetragen hast ...
- Warum erfaßt isdnlog neben den Gebühren nicht auch die Telefonnummer, die
meine anderen ISDN-Geräte (z.B. ISDN-Telefon) anrufen?
Weil die ISDN-Karte wie alle ISDN-Geräte getrennte Sende- und
Empfangsleitungen (RX bzw. TX Leitung) hat. Isdnlog müßte die auf der
Sendeleitung übermittelten Daten belauschen, um die Telefonnummer zu
erfahren. Zumindestens bei der Teleskarte ist das jedoch nicht möglich, wie
Karsten Keil <keil@temic-ech.spacenet.de> am 12. Feb 1997 schrieb:
Das ist bei allen Karten mit 1 Siemens ISAC so, der hat (und braucht)
nur 1 Empfaenger und 1 Sender.
Theoretisch besteht eine Moeglichkeit, mit nur einem Empfaenger den
kompletten D-Kanal zu belauschen (das macht der ISAC sogar) und zwar
werden die auf der RX Leitung empfangenden D-Bits auf sogenannte Echo
Bits zeitversetzt auf die TX Leitung kopiert, darueber erfolgt die
Access Kontrolle (Kollisionserkennung) des S0 Busses.
Leider gibt es im ISAC im TA Mode keine Moeglichkeit die ECHO Bits aus
einem Register zu lesen.
Zu möglichen Lösungen siehe nächste Frage.
- Wie kann ich trotzdem isdnlog dazu bringen, die Telefonnummer auch von
anderen ISDN-Geräten mitzubekommen?
Es gibt zwei Möglichkeiten. Zum einen gibt es von der Deutschen Telekom die
kostenpflichtige Möglichkeit, alle Daten nochmal zurückschicken zu lassen
(COLP = Connected Line Identification Presentation, ca. DM 10,- pro Monat
je Basisanschluß). Diese kann isdnlog (>=2.52) dann wieder auf der TX
Leitung lesen.
Alternativ dazu wird isdnlog ab der nächsten Version (aktuell ist 2.52)
die Möglichkeit bieten, mit einer zweiten, "verpolten" Teles-Karte zu
arbeiten, bei der die RX Leitung an den TX Anschluß der Karte geführt wird.
Die RX Leitung der Karte darf an keine der Leitungen angeschlossen werden!
Aufgrund der Schaltung kann die Teles-Karte für keinen anderen Zweck mehr
eingesetzt werden. Das ganze sieht dann so aus:
B 3 -- RX+ 2a ---------------\
U 4 -- TX+ 1a -- offen ------------
S 5 -- TX- 1b -- offen ------------ Karte
6 -- RX- 2b ---------------/
Eine theoretische dritte Möglichkeit gibt es noch für alle, die eine
eigene TK-Anlage haben, über die sämtliche weiteren Geräte angeschlossen
sind. Falls diese Telefonanlage ebenfalls alle ausgehenden Telefonnummern
protokollieren kann, könnten diese ausgelesen werden (üblicherweise über
eine serielle Schnittstelle).
Es gibt jedoch einen Grund, warum isdnlog das nicht schon längst
unterstützt. Um die Daten zu verwerten, müßte isdnlog diese sofort beim
RELEASE COMPLETE zur Verfügung gestellt bekommen, bevor auf dem D-Kanal
neue Informationen übermittelt werden. Leider sind die bisher getesteten
Telefonanlagen dafür zu langsam (insbesondere die weit verbreitete ISTEC).
Als einzige Möglichkeit bleibt, die Daten nachträglich zu kombinieren.
Dabei kommt es aber zur Schwierigkeit, die unterschiedlichen Uhrzeiten
zu synchronisieren. Wer das realisieren möchte, ist dazu herzlich gerne
eingeladen (ich stelle auch gerne entsprechende Logs von meiner Ackermann
Euracom zur Verfügung - Matthias Heßler <hessler@wi-inf.uni-essen.de>).
- Erfaßt isdnlog auch die neuen Tarife der deutschen Telekom (City Weekend,
City Plus)?
Da die Vermittlungsstellen der Telekom das nicht hinbekommen, werden die
Gebühreninformationen nicht korrekt übermittelt. Die nächste Version von
isdnlog (>2.52) wird das jedoch können.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
niederländischen Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_NL" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
schweizer Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_CH" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich mir den Datendurchsatz grafisch anzeigen lassen?
Dazu gibt's "xisdnload". Clemens Perz <listperz@gwsnet.ttt.de> wußte am
6. Feb 1997 noch eine weitere Möglichkeit:
Ich hab auf der Sunsite ein kleines Tool Namens netload für die Console
gefunden und es auf ISDN-Interfaces angepasst. Damit kann man recht
einfach den momentanen Traffic auf der Leitung in Augenschein nehmen.
Zu finden auf:
ftp://ftp.region.trier.de/pub/unix/linux/sources/network/isdn/netload-0.92.isdn.tar.gz
Einfach starten mit netload isdnxx
2.13 Isdn der Provider auch kennt. Trägt z.B. der Router im
LAN die lokale IP-Adresse 192.168.1.1, und ein anderer Rechner die
192.168.1.2, dann kennt der Provider diese Adressen ja nicht. Er weist z.B.
dem PPP-Interface des Routers die Adresse 123.234.345.99 zu - und nur bei
Paketen aus dem Internet, die an diese Nummer adressiert sind, weiß er
auch, an wen er die Pakete schicken soll. Daher muß der Router Pakete von
anderen Rechnern im LAN "maskieren" - mit seiner eigenen, dynamisch
zugewiesenen Adresse (und dabei natürlich Buch darüber führen, was an
wen von wem kam, um die Antwort-Pakete richtig zuzustellen).
Zum Glück ist diese Funktion in den Linux-Kernel =>2.0.0 schon eingebaut
(s.o.) - sie nennt sich "IP-Masquerading". Vereinfacht ausgedrückt geht
das so:
Ein LAN-Rechner schickt ein Paket ab, das neben IP-Nummer und Ziel-Port des
Empfängers auch die "Absender-Adresse" in Form einer IP-Nummer und eines
Antwort-Ports trägt. Der maskierende Router nun ersetzt die Absender-IP
durch seine eigene und den Rücksende-Port durch einen freien aus seinem
Fundus. Unter dieser "freien" Portnummer werden die originalen Absender-
Daten gespeichert. Kommt nun ein Antwort-Paket aus dem Internet an diesen
Port, werden dessen Empfänger-Adresse und -Port mit der gespeicherten
Rücksende-Adresse überschrieben und an den LAN-Rechner weitergeleitet.
Paket für Paket.
Leicht einsehbar ist übrigens, daß dieses Verfahren nur mit Diensten
funktioniert, bei denen auch eine Rücksende-Adresse angegeben wird. Dazu
gehören u.a. telnet, http, ftp, irc (eingeschränkt), nicht aber Echo
(ping).
Zurück zur Praxis. Damit das Masquerading auch bei FTP und IRC
funktioniert, werden zunächst zwei Module geladen:
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
Dann werden die Forward-Rules des Kernel zum Masquerading gezwungen:
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b
Das Programm ipfwadm gibt es per Anonymous FTP unter:
ftp://ftp.xos.nl/pub/linux/ipfwadm/ipfwadm-2.3.0.tar.gz
In diesem Beispiel werden im LAN die IP-Adressen 192.168.123.1 bis
192.168.123.254 benutzt. Legen wir zur Vereinfachung fest, der Linux-Router
habe dabei die Adresse 192.168.123.1.
Obige Zeile bewirkt, daß IP-Pakete, die von 192.168.123.x ausgehen und
an wenauchimmer gerichtet sind, maskiert werden. Das hat den Nachteil, daß
auch innerhalb des LAN fleißig drauflosmaskiert wird, was man aber durch
Einfügen weiterer Rules vermeiden kann. "man ipfwadm" sei hier zur Lektüre
empfohlen.
(Hinweis von Ralf Rudolph <ralf@artifex.de> hierzu:
Hmm. So wie ich das sehe, passiert da gar nichts. Grund: Die Rechner im
lokalen Netz unterhalten sich ja direkt über die fake-Adressen im
192.168.123.xxx-Netz. Zum Beweis kannst Du Deine Linux-Kiste einfach
abschalten (naja OK, shutdown...), und die lokalen Rechner werden sich
weiter unterhalten können. Also wird da auch nix masqueraded.
Der Hintergrund: Masquerading ist eine FORWARD Rule im Firewall und
wird daher auch nur beim FORWARDEN (wörtlich zu nehmen: WEITERleiten)
verwendet.
Netz-intern wird nichts geforwarded und deshalb auch nichts
masqueraded, solange Du nur eine Netzwerkkarte hast. Bei mehreren
Karten hast Du jedoch recht: Hier sollte man entsprechende Routing-
und auch ipfwadm-Einträge vornehmen.
Antwort: Ist tatsächlich etwas ungenau; schaden tut es aber nix, es sei
denn, man will unbedingt nicht maskierbare Services benutzen.)
Das "Verstecken" des LAN vor dem Provider haben wir nun erreicht. Jetzt
gilt es, bei Bedarf einen automatischen Verbindungsaufbau zu erzwingen.
Dafür ist es zunächst nötig, die anderen Rechner im LAN dazu zu bringen,
alle für "Außerhalb" bestimmten IP-Pakete an den Linux-Router zu
übergeben und diesem die Weiterleitung zu überlassen. Nichts leichter als
das: Sowohl bei den verschiedenen Windows-Versionen, als auch beim AmiTCP
und beim MacTCP gibt es in der Konfiguration den Stichwort "Default-
Gateway" oder nur "Gateway". Hier ist die lokale IP-Adresse des
Routers einzutragen (denn die spätere Adresse, die vom Provider kommt, ist
ja erstens noch nicht bekannt und ändert sich zweitens bei jedem Anruf).
Letzter Schritt ist dann, das "dial-on-demand" einzurichten. In
Verbindung mit isdn4linux gibt es dafür zwei Möglichkeiten:
* Man verwendet synchrones PPP für die Verbindung zum Provider, also
den "ipppd". Dann ist nichts weiter zu tun als dafür zu sorgen, daß
immer die Default-Route des Routers auf das entsprechende ipppx-
Interface weist. Vorsicht: Beim Verbindungsabbau löscht der Kernel
diese Route!
Sie muß also z.B. in der Datei /etc/ppp/ip-down neu gesetzt werden.
Das Risiko bei diesem Verfahren sind Programme auf den LAN-Rechnern,
die mehr oder weniger regelmäßig Nameserver-Requests, Keepalive-
Pakete oder ARP-Broadcastings erzeugen - dann stellt nämlich der
Router jedesmal eine Verbindung zum Provider her. Die Telekom wird's
danken.
Übrigens kann es passieren, daß manche aus dem LAN initiierte
Verbindungen recht lange auf Antwort warten. Ich weiß nicht, ob
Kernel oder ipppd das "auslösende" Paket verschlucken, oder die
Antwort darauf unterschlagen; ich weiß aber, daß es hilft, z.B. bei
Netscape wenige Sekunden nach Anforderung der ersten Seite auf den
"roten Knopf" zu drücken und die Seite nochmals anzufordern.
Wie bereits erwähnt: Die Konfiguration des ipppd wird an anderer
Stelle ausführlich erklärt - siehe entsprechende Fragen sowie
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
* Benutzt man asynchrones ppp oder gar SLIP/CSLIP für die Verbindung
zum Provider, kann man das Programm "diald" [4] verwenden. Es bietet
zudem den Vorteil, extrem stark konfigurierbar zu sein; so kann man
z.B. festlegen, daß zwischen 0900 und 1200 grundsätzlich keine
Verbindung aufgebaut wird, daß Nameserver-Anfragen eine Verbindung
zwar nicht aufbauen, aber offenhalten können u.v.m. Wer sich mit
diesen Konfigurationsmöglichkeiten nicht herumschlagen mag, braucht
das indes auch nicht - die Default-Konfiguration kann man ohne
Gefahr für Leib und Geldbörse übernehmen :-)
So.
Wenn jetzt das Masquerading eingerichtet wurde,
wenn der Linux-Router auf allen LAN-Rechnern als Gateway eingetragen
wurde,
wenn ein "ping abc.edu", eingetippt auf der Console des Routers, eine
Verbindung zum Provider aufbaut,
dann sollte damit auch für alle Rechner im LAN der Weg ins Internet
frei sein.
Wie sieht der "PERL-Einzeiler" "modemd" nun genau aus?
Marc Neitzner <marc@zeus.han.de> schrieb dazu am 15. Dez 1996:
#!/usr/bin/perl
select((select(STDOUT), $| = 1)[$[]);
select((select(STDIN), $| = 1)[$[]);
exec "cu","-E","''", "-l", "$ARGV[0]";
die "$0: Cant exec cu: $!\n";
Und dann muss das Ding per inetd gestartet werden:
modem 20006/tcp modemd # Modem service via TCP
isdn 20007/tcp modemd # ISDN service via TCP
Nachteil: comt-2.0 ist nur für 16Bit Anwendungen "sichtbar". Der
Einsatz unter win95 und Windows NT bleibt also auch dort auf 16Bit Kram
beschränkt!
2.12 Isdnlog
- Wie kann ich isdnlog dazu bringen, mir die High Layer Compatibility
(Speech, Video,...) so anzuzeigen, wie ich es gerne hätte?
Gernot Zander <hifi@scorpio.in-berlin.de> postete am 6. Okt 1996 einen ent-
sprechenden Patch in der Mailingliste, der isdnlog besser anpaßt.
- Kann man in der Ausgabe von isdnrep die Dienstekennung eines eingehenden
Anrufes sehen?
Andreas Kool <akool@Kool.f.EUnet.de> schrieb hierzu am 3. Dez 1996:
Im isdnrep indirekt schon -- sofern du alle von isdnlog ausdekodierten
Dienstkennungen in deiner "isdnlog.conf" als Alias eingetragen hast ...
- Warum erfaßt isdnlog neben den Gebühren nicht auch die Telefonnummer, die
meine anderen ISDN-Geräte (z.B. ISDN-Telefon) anrufen?
Weil die ISDN-Karte wie alle ISDN-Geräte getrennte Sende- und
Empfangsleitungen (RX bzw. TX Leitung) hat. Isdnlog müßte die auf der
Sendeleitung übermittelten Daten belauschen, um die Telefonnummer zu
erfahren. Zumindestens bei der Teleskarte ist das jedoch nicht möglich, wie
Karsten Keil <keil@temic-ech.spacenet.de> am 12. Feb 1997 schrieb:
Das ist bei allen Karten mit 1 Siemens ISAC so, der hat (und braucht)
nur 1 Empfaenger und 1 Sender.
Theoretisch besteht eine Moeglichkeit, mit nur einem Empfaenger den
kompletten D-Kanal zu belauschen (das macht der ISAC sogar) und zwar
werden die auf der RX Leitung empfangenden D-Bits auf sogenannte Echo
Bits zeitversetzt auf die TX Leitung kopiert, darueber erfolgt die
Access Kontrolle (Kollisionserkennung) des S0 Busses.
Leider gibt es im ISAC im TA Mode keine Moeglichkeit die ECHO Bits aus
einem Register zu lesen.
Zu möglichen Lösungen siehe nächste Frage.
- Wie kann ich trotzdem isdnlog dazu bringen, die Telefonnummer auch von
anderen ISDN-Geräten mitzubekommen?
Es gibt zwei Möglichkeiten. Zum einen gibt es von der Deutschen Telekom die
kostenpflichtige Möglichkeit, alle Daten nochmal zurückschicken zu lassen
(COLP = Connected Line Identification Presentation, ca. DM 10,- pro Monat
je Basisanschluß). Diese kann isdnlog (>=2.52) dann wieder auf der TX
Leitung lesen.
Alternativ dazu wird isdnlog ab der nächsten Version (aktuell ist 2.52)
die Möglichkeit bieten, mit einer zweiten, "verpolten" Teles-Karte zu
arbeiten, bei der die RX Leitung an den TX Anschluß der Karte geführt wird.
Die RX Leitung der Karte darf an keine der Leitungen angeschlossen werden!
Aufgrund der Schaltung kann die Teles-Karte für keinen anderen Zweck mehr
eingesetzt werden. Das ganze sieht dann so aus:
B 3 -- RX+ 2a ---------------\
U 4 -- TX+ 1a -- offen ------------
S 5 -- TX- 1b -- offen ------------ Karte
6 -- RX- 2b ---------------/
Eine theoretische dritte Möglichkeit gibt es noch für alle, die eine
eigene TK-Anlage haben, über die sämtliche weiteren Geräte angeschlossen
sind. Falls diese Telefonanlage ebenfalls alle ausgehenden Telefonnummern
protokollieren kann, könnten diese ausgelesen werden (üblicherweise über
eine serielle Schnittstelle).
Es gibt jedoch einen Grund, warum isdnlog das nicht schon längst
unterstützt. Um die Daten zu verwerten, müßte isdnlog diese sofort beim
RELEASE COMPLETE zur Verfügung gestellt bekommen, bevor auf dem D-Kanal
neue Informationen übermittelt werden. Leider sind die bisher getesteten
Telefonanlagen dafür zu langsam (insbesondere die weit verbreitete ISTEC).
Als einzige Möglichkeit bleibt, die Daten nachträglich zu kombinieren.
Dabei kommt es aber zur Schwierigkeit, die unterschiedlichen Uhrzeiten
zu synchronisieren. Wer das realisieren möchte, ist dazu herzlich gerne
eingeladen (ich stelle auch gerne entsprechende Logs von meiner Ackermann
Euracom zur Verfügung - Matthias Heßler <hessler@wi-inf.uni-essen.de>).
- Erfaßt isdnlog auch die neuen Tarife der deutschen Telekom (City Weekend,
City Plus)?
Da die Vermittlungsstellen der Telekom das nicht hinbekommen, werden die
Gebühreninformationen nicht korrekt übermittelt. Die nächste Version von
isdnlog (>2.52) wird das jedoch können.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
niederländischen Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_NL" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
schweizer Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_CH" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich mir den Datendurchsatz grafisch anzeigen lassen?
Dazu gibt's "xisdnload". Clemens Perz <listperz@gwsnet.ttt.de> wußte am
6. Feb 1997 noch eine weitere Möglichkeit:
Ich hab auf der Sunsite ein kleines Tool Namens netload für die Console
gefunden und es auf ISDN-Interfaces angepasst. Damit kann man recht
einfach den momentanen Traffic auf der Leitung in Augenschein nehmen.
Zu finden auf:
ftp://ftp.region.trier.de/pub/unix/linux/sources/network/isdn/netload-0.92.isdn.tar.gz
Einfach starten mit netload isdnxx
2.13 Isdn der Provider auch kennt. Trägt z.B. der Router im
LAN die lokale IP-Adresse 192.168.1.1, und ein anderer Rechner die
192.168.1.2, dann kennt der Provider diese Adressen ja nicht. Er weist z.B.
dem PPP-Interface des Routers die Adresse 123.234.345.99 zu - und nur bei
Paketen aus dem Internet, die an diese Nummer adressiert sind, weiß er
auch, an wen er die Pakete schicken soll. Daher muß der Router Pakete von
anderen Rechnern im LAN "maskieren" - mit seiner eigenen, dynamisch
zugewiesenen Adresse (und dabei natürlich Buch darüber führen, was an
wen von wem kam, um die Antwort-Pakete richtig zuzustellen).
Zum Glück ist diese Funktion in den Linux-Kernel =>2.0.0 schon eingebaut
(s.o.) - sie nennt sich "IP-Masquerading". Vereinfacht ausgedrückt geht
das so:
Ein LAN-Rechner schickt ein Paket ab, das neben IP-Nummer und Ziel-Port des
Empfängers auch die "Absender-Adresse" in Form einer IP-Nummer und eines
Antwort-Ports trägt. Der maskierende Router nun ersetzt die Absender-IP
durch seine eigene und den Rücksende-Port durch einen freien aus seinem
Fundus. Unter dieser "freien" Portnummer werden die originalen Absender-
Daten gespeichert. Kommt nun ein Antwort-Paket aus dem Internet an diesen
Port, werden dessen Empfänger-Adresse und -Port mit der gespeicherten
Rücksende-Adresse überschrieben und an den LAN-Rechner weitergeleitet.
Paket für Paket.
Leicht einsehbar ist übrigens, daß dieses Verfahren nur mit Diensten
funktioniert, bei denen auch eine Rücksende-Adresse angegeben wird. Dazu
gehören u.a. telnet, http, ftp, irc (eingeschränkt), nicht aber Echo
(ping).
Zurück zur Praxis. Damit das Masquerading auch bei FTP und IRC
funktioniert, werden zunächst zwei Module geladen:
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
Dann werden die Forward-Rules des Kernel zum Masquerading gezwungen:
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b
Das Programm ipfwadm gibt es per Anonymous FTP unter:
ftp://ftp.xos.nl/pub/linux/ipfwadm/ipfwadm-2.3.0.tar.gz
In diesem Beispiel werden im LAN die IP-Adressen 192.168.123.1 bis
192.168.123.254 benutzt. Legen wir zur Vereinfachung fest, der Linux-Router
habe dabei die Adresse 192.168.123.1.
Obige Zeile bewirkt, daß IP-Pakete, die von 192.168.123.x ausgehen und
an wenauchimmer gerichtet sind, maskiert werden. Das hat den Nachteil, daß
auch innerhalb des LAN fleißig drauflosmaskiert wird, was man aber durch
Einfügen weiterer Rules vermeiden kann. "man ipfwadm" sei hier zur Lektüre
empfohlen.
(Hinweis von Ralf Rudolph <ralf@artifex.de> hierzu:
Hmm. So wie ich das sehe, passiert da gar nichts. Grund: Die Rechner im
lokalen Netz unterhalten sich ja direkt über die fake-Adressen im
192.168.123.xxx-Netz. Zum Beweis kannst Du Deine Linux-Kiste einfach
abschalten (naja OK, shutdown...), und die lokalen Rechner werden sich
weiter unterhalten können. Also wird da auch nix masqueraded.
Der Hintergrund: Masquerading ist eine FORWARD Rule im Firewall und
wird daher auch nur beim FORWARDEN (wörtlich zu nehmen: WEITERleiten)
verwendet.
Netz-intern wird nichts geforwarded und deshalb auch nichts
masqueraded, solange Du nur eine Netzwerkkarte hast. Bei mehreren
Karten hast Du jedoch recht: Hier sollte man entsprechende Routing-
und auch ipfwadm-Einträge vornehmen.
Antwort: Ist tatsächlich etwas ungenau; schaden tut es aber nix, es sei
denn, man will unbedingt nicht maskierbare Services benutzen.)
Das "Verstecken" des LAN vor dem Provider haben wir nun erreicht. Jetzt
gilt es, bei Bedarf einen automatischen Verbindungsaufbau zu erzwingen.
Dafür ist es zunächst nötig, die anderen Rechner im LAN dazu zu bringen,
alle für "Außerhalb" bestimmten IP-Pakete an den Linux-Router zu
übergeben und diesem die Weiterleitung zu überlassen. Nichts leichter als
das: Sowohl bei den verschiedenen Windows-Versionen, als auch beim AmiTCP
und beim MacTCP gibt es in der Konfiguration den Stichwort "Default-
Gateway" oder nur "Gateway". Hier ist die lokale IP-Adresse des
Routers einzutragen (denn die spätere Adresse, die vom Provider kommt, ist
ja erstens noch nicht bekannt und ändert sich zweitens bei jedem Anruf).
Letzter Schritt ist dann, das "dial-on-demand" einzurichten. In
Verbindung mit isdn4linux gibt es dafür zwei Möglichkeiten:
* Man verwendet synchrones PPP für die Verbindung zum Provider, also
den "ipppd". Dann ist nichts weiter zu tun als dafür zu sorgen, daß
immer die Default-Route des Routers auf das entsprechende ipppx-
Interface weist. Vorsicht: Beim Verbindungsabbau löscht der Kernel
diese Route!
Sie muß also z.B. in der Datei /etc/ppp/ip-down neu gesetzt werden.
Das Risiko bei diesem Verfahren sind Programme auf den LAN-Rechnern,
die mehr oder weniger regelmäßig Nameserver-Requests, Keepalive-
Pakete oder ARP-Broadcastings erzeugen - dann stellt nämlich der
Router jedesmal eine Verbindung zum Provider her. Die Telekom wird's
danken.
Übrigens kann es passieren, daß manche aus dem LAN initiierte
Verbindungen recht lange auf Antwort warten. Ich weiß nicht, ob
Kernel oder ipppd das "auslösende" Paket verschlucken, oder die
Antwort darauf unterschlagen; ich weiß aber, daß es hilft, z.B. bei
Netscape wenige Sekunden nach Anforderung der ersten Seite auf den
"roten Knopf" zu drücken und die Seite nochmals anzufordern.
Wie bereits erwähnt: Die Konfiguration des ipppd wird an anderer
Stelle ausführlich erklärt - siehe entsprechende Fragen sowie
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
* Benutzt man asynchrones ppp oder gar SLIP/CSLIP für die Verbindung
zum Provider, kann man das Programm "diald" [4] verwenden. Es bietet
zudem den Vorteil, extrem stark konfigurierbar zu sein; so kann man
z.B. festlegen, daß zwischen 0900 und 1200 grundsätzlich keine
Verbindung aufgebaut wird, daß Nameserver-Anfragen eine Verbindung
zwar nicht aufbauen, aber offenhalten können u.v.m. Wer sich mit
diesen Konfigurationsmöglichkeiten nicht herumschlagen mag, braucht
das indes auch nicht - die Default-Konfiguration kann man ohne
Gefahr für Leib und Geldbörse übernehmen :-)
So.
Wenn jetzt das Masquerading eingerichtet wurde,
wenn der Linux-Router auf allen LAN-Rechnern als Gateway eingetragen
wurde,
wenn ein "ping abc.edu", eingetippt auf der Console des Routers, eine
Verbindung zum Provider aufbaut,
dann sollte damit auch für alle Rechner im LAN der Weg ins Internet
frei sein.
Wie sieht der "PERL-Einzeiler" "modemd" nun genau aus?
Marc Neitzner <marc@zeus.han.de> schrieb dazu am 15. Dez 1996:
#!/usr/bin/perl
select((select(STDOUT), $| = 1)[$[]);
select((select(STDIN), $| = 1)[$[]);
exec "cu","-E","''", "-l", "$ARGV[0]";
die "$0: Cant exec cu: $!\n";
Und dann muss das Ding per inetd gestartet werden:
modem 20006/tcp modemd # Modem service via TCP
isdn 20007/tcp modemd # ISDN service via TCP
Nachteil: comt-2.0 ist nur für 16Bit Anwendungen "sichtbar". Der
Einsatz unter win95 und Windows NT bleibt also auch dort auf 16Bit Kram
beschränkt!
2.12 Isdnlog
- Wie kann ich isdnlog dazu bringen, mir die High Layer Compatibility
(Speech, Video,...) so anzuzeigen, wie ich es gerne hätte?
Gernot Zander <hifi@scorpio.in-berlin.de> postete am 6. Okt 1996 einen ent-
sprechenden Patch in der Mailingliste, der isdnlog besser anpaßt.
- Kann man in der Ausgabe von isdnrep die Dienstekennung eines eingehenden
Anrufes sehen?
Andreas Kool <akool@Kool.f.EUnet.de> schrieb hierzu am 3. Dez 1996:
Im isdnrep indirekt schon -- sofern du alle von isdnlog ausdekodierten
Dienstkennungen in deiner "isdnlog.conf" als Alias eingetragen hast ...
- Warum erfaßt isdnlog neben den Gebühren nicht auch die Telefonnummer, die
meine anderen ISDN-Geräte (z.B. ISDN-Telefon) anrufen?
Weil die ISDN-Karte wie alle ISDN-Geräte getrennte Sende- und
Empfangsleitungen (RX bzw. TX Leitung) hat. Isdnlog müßte die auf der
Sendeleitung übermittelten Daten belauschen, um die Telefonnummer zu
erfahren. Zumindestens bei der Teleskarte ist das jedoch nicht möglich, wie
Karsten Keil <keil@temic-ech.spacenet.de> am 12. Feb 1997 schrieb:
Das ist bei allen Karten mit 1 Siemens ISAC so, der hat (und braucht)
nur 1 Empfaenger und 1 Sender.
Theoretisch besteht eine Moeglichkeit, mit nur einem Empfaenger den
kompletten D-Kanal zu belauschen (das macht der ISAC sogar) und zwar
werden die auf der RX Leitung empfangenden D-Bits auf sogenannte Echo
Bits zeitversetzt auf die TX Leitung kopiert, darueber erfolgt die
Access Kontrolle (Kollisionserkennung) des S0 Busses.
Leider gibt es im ISAC im TA Mode keine Moeglichkeit die ECHO Bits aus
einem Register zu lesen.
Zu möglichen Lösungen siehe nächste Frage.
- Wie kann ich trotzdem isdnlog dazu bringen, die Telefonnummer auch von
anderen ISDN-Geräten mitzubekommen?
Es gibt zwei Möglichkeiten. Zum einen gibt es von der Deutschen Telekom die
kostenpflichtige Möglichkeit, alle Daten nochmal zurückschicken zu lassen
(COLP = Connected Line Identification Presentation, ca. DM 10,- pro Monat
je Basisanschluß). Diese kann isdnlog (>=2.52) dann wieder auf der TX
Leitung lesen.
Alternativ dazu wird isdnlog ab der nächsten Version (aktuell ist 2.52)
die Möglichkeit bieten, mit einer zweiten, "verpolten" Teles-Karte zu
arbeiten, bei der die RX Leitung an den TX Anschluß der Karte geführt wird.
Die RX Leitung der Karte darf an keine der Leitungen angeschlossen werden!
Aufgrund der Schaltung kann die Teles-Karte für keinen anderen Zweck mehr
eingesetzt werden. Das ganze sieht dann so aus:
B 3 -- RX+ 2a ---------------\
U 4 -- TX+ 1a -- offen ------------
S 5 -- TX- 1b -- offen ------------ Karte
6 -- RX- 2b ---------------/
Eine theoretische dritte Möglichkeit gibt es noch für alle, die eine
eigene TK-Anlage haben, über die sämtliche weiteren Geräte angeschlossen
sind. Falls diese Telefonanlage ebenfalls alle ausgehenden Telefonnummern
protokollieren kann, könnten diese ausgelesen werden (üblicherweise über
eine serielle Schnittstelle).
Es gibt jedoch einen Grund, warum isdnlog das nicht schon längst
unterstützt. Um die Daten zu verwerten, müßte isdnlog diese sofort beim
RELEASE COMPLETE zur Verfügung gestellt bekommen, bevor auf dem D-Kanal
neue Informationen übermittelt werden. Leider sind die bisher getesteten
Telefonanlagen dafür zu langsam (insbesondere die weit verbreitete ISTEC).
Als einzige Möglichkeit bleibt, die Daten nachträglich zu kombinieren.
Dabei kommt es aber zur Schwierigkeit, die unterschiedlichen Uhrzeiten
zu synchronisieren. Wer das realisieren möchte, ist dazu herzlich gerne
eingeladen (ich stelle auch gerne entsprechende Logs von meiner Ackermann
Euracom zur Verfügung - Matthias Heßler <hessler@wi-inf.uni-essen.de>).
- Erfaßt isdnlog auch die neuen Tarife der deutschen Telekom (City Weekend,
City Plus)?
Da die Vermittlungsstellen der Telekom das nicht hinbekommen, werden die
Gebühreninformationen nicht korrekt übermittelt. Die nächste Version von
isdnlog (>2.52) wird das jedoch können.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
niederländischen Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_NL" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
schweizer Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_CH" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich mir den Datendurchsatz grafisch anzeigen lassen?
Dazu gibt's "xisdnload". Clemens Perz <listperz@gwsnet.ttt.de> wußte am
6. Feb 1997 noch eine weitere Möglichkeit:
Ich hab auf der Sunsite ein kleines Tool Namens netload für die Console
gefunden und es auf ISDN-Interfaces angepasst. Damit kann man recht
einfach den momentanen Traffic auf der Leitung in Augenschein nehmen.
Zu finden auf:
ftp://ftp.region.trier.de/pub/unix/linux/sources/network/isdn/netload-0.92.isdn.tar.gz
Einfach starten mit netload isdnxx
2.13 Isdn der Provider auch kennt. Trägt z.B. der Router im
LAN die lokale IP-Adresse 192.168.1.1, und ein anderer Rechner die
192.168.1.2, dann kennt der Provider diese Adressen ja nicht. Er weist z.B.
dem PPP-Interface des Routers die Adresse 123.234.345.99 zu - und nur bei
Paketen aus dem Internet, die an diese Nummer adressiert sind, weiß er
auch, an wen er die Pakete schicken soll. Daher muß der Router Pakete von
anderen Rechnern im LAN "maskieren" - mit seiner eigenen, dynamisch
zugewiesenen Adresse (und dabei natürlich Buch darüber führen, was an
wen von wem kam, um die Antwort-Pakete richtig zuzustellen).
Zum Glück ist diese Funktion in den Linux-Kernel =>2.0.0 schon eingebaut
(s.o.) - sie nennt sich "IP-Masquerading". Vereinfacht ausgedrückt geht
das so:
Ein LAN-Rechner schickt ein Paket ab, das neben IP-Nummer und Ziel-Port des
Empfängers auch die "Absender-Adresse" in Form einer IP-Nummer und eines
Antwort-Ports trägt. Der maskierende Router nun ersetzt die Absender-IP
durch seine eigene und den Rücksende-Port durch einen freien aus seinem
Fundus. Unter dieser "freien" Portnummer werden die originalen Absender-
Daten gespeichert. Kommt nun ein Antwort-Paket aus dem Internet an diesen
Port, werden dessen Empfänger-Adresse und -Port mit der gespeicherten
Rücksende-Adresse überschrieben und an den LAN-Rechner weitergeleitet.
Paket für Paket.
Leicht einsehbar ist übrigens, daß dieses Verfahren nur mit Diensten
funktioniert, bei denen auch eine Rücksende-Adresse angegeben wird. Dazu
gehören u.a. telnet, http, ftp, irc (eingeschränkt), nicht aber Echo
(ping).
Zurück zur Praxis. Damit das Masquerading auch bei FTP und IRC
funktioniert, werden zunächst zwei Module geladen:
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
Dann werden die Forward-Rules des Kernel zum Masquerading gezwungen:
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b
Das Programm ipfwadm gibt es per Anonymous FTP unter:
ftp://ftp.xos.nl/pub/linux/ipfwadm/ipfwadm-2.3.0.tar.gz
In diesem Beispiel werden im LAN die IP-Adressen 192.168.123.1 bis
192.168.123.254 benutzt. Legen wir zur Vereinfachung fest, der Linux-Router
habe dabei die Adresse 192.168.123.1.
Obige Zeile bewirkt, daß IP-Pakete, die von 192.168.123.x ausgehen und
an wenauchimmer gerichtet sind, maskiert werden. Das hat den Nachteil, daß
auch innerhalb des LAN fleißig drauflosmaskiert wird, was man aber durch
Einfügen weiterer Rules vermeiden kann. "man ipfwadm" sei hier zur Lektüre
empfohlen.
(Hinweis von Ralf Rudolph <ralf@artifex.de> hierzu:
Hmm. So wie ich das sehe, passiert da gar nichts. Grund: Die Rechner im
lokalen Netz unterhalten sich ja direkt über die fake-Adressen im
192.168.123.xxx-Netz. Zum Beweis kannst Du Deine Linux-Kiste einfach
abschalten (naja OK, shutdown...), und die lokalen Rechner werden sich
weiter unterhalten können. Also wird da auch nix masqueraded.
Der Hintergrund: Masquerading ist eine FORWARD Rule im Firewall und
wird daher auch nur beim FORWARDEN (wörtlich zu nehmen: WEITERleiten)
verwendet.
Netz-intern wird nichts geforwarded und deshalb auch nichts
masqueraded, solange Du nur eine Netzwerkkarte hast. Bei mehreren
Karten hast Du jedoch recht: Hier sollte man entsprechende Routing-
und auch ipfwadm-Einträge vornehmen.
Antwort: Ist tatsächlich etwas ungenau; schaden tut es aber nix, es sei
denn, man will unbedingt nicht maskierbare Services benutzen.)
Das "Verstecken" des LAN vor dem Provider haben wir nun erreicht. Jetzt
gilt es, bei Bedarf einen automatischen Verbindungsaufbau zu erzwingen.
Dafür ist es zunächst nötig, die anderen Rechner im LAN dazu zu bringen,
alle für "Außerhalb" bestimmten IP-Pakete an den Linux-Router zu
übergeben und diesem die Weiterleitung zu überlassen. Nichts leichter als
das: Sowohl bei den verschiedenen Windows-Versionen, als auch beim AmiTCP
und beim MacTCP gibt es in der Konfiguration den Stichwort "Default-
Gateway" oder nur "Gateway". Hier ist die lokale IP-Adresse des
Routers einzutragen (denn die spätere Adresse, die vom Provider kommt, ist
ja erstens noch nicht bekannt und ändert sich zweitens bei jedem Anruf).
Letzter Schritt ist dann, das "dial-on-demand" einzurichten. In
Verbindung mit isdn4linux gibt es dafür zwei Möglichkeiten:
* Man verwendet synchrones PPP für die Verbindung zum Provider, also
den "ipppd". Dann ist nichts weiter zu tun als dafür zu sorgen, daß
immer die Default-Route des Routers auf das entsprechende ipppx-
Interface weist. Vorsicht: Beim Verbindungsabbau löscht der Kernel
diese Route!
Sie muß also z.B. in der Datei /etc/ppp/ip-down neu gesetzt werden.
Das Risiko bei diesem Verfahren sind Programme auf den LAN-Rechnern,
die mehr oder weniger regelmäßig Nameserver-Requests, Keepalive-
Pakete oder ARP-Broadcastings erzeugen - dann stellt nämlich der
Router jedesmal eine Verbindung zum Provider her. Die Telekom wird's
danken.
Übrigens kann es passieren, daß manche aus dem LAN initiierte
Verbindungen recht lange auf Antwort warten. Ich weiß nicht, ob
Kernel oder ipppd das "auslösende" Paket verschlucken, oder die
Antwort darauf unterschlagen; ich weiß aber, daß es hilft, z.B. bei
Netscape wenige Sekunden nach Anforderung der ersten Seite auf den
"roten Knopf" zu drücken und die Seite nochmals anzufordern.
Wie bereits erwähnt: Die Konfiguration des ipppd wird an anderer
Stelle ausführlich erklärt - siehe entsprechende Fragen sowie
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
* Benutzt man asynchrones ppp oder gar SLIP/CSLIP für die Verbindung
zum Provider, kann man das Programm "diald" [4] verwenden. Es bietet
zudem den Vorteil, extrem stark konfigurierbar zu sein; so kann man
z.B. festlegen, daß zwischen 0900 und 1200 grundsätzlich keine
Verbindung aufgebaut wird, daß Nameserver-Anfragen eine Verbindung
zwar nicht aufbauen, aber offenhalten können u.v.m. Wer sich mit
diesen Konfigurationsmöglichkeiten nicht herumschlagen mag, braucht
das indes auch nicht - die Default-Konfiguration kann man ohne
Gefahr für Leib und Geldbörse übernehmen :-)
So.
Wenn jetzt das Masquerading eingerichtet wurde,
wenn der Linux-Router auf allen LAN-Rechnern als Gateway eingetragen
wurde,
wenn ein "ping abc.edu", eingetippt auf der Console des Routers, eine
Verbindung zum Provider aufbaut,
dann sollte damit auch für alle Rechner im LAN der Weg ins Internet
frei sein.
Wie sieht der "PERL-Einzeiler" "modemd" nun genau aus?
Marc Neitzner <marc@zeus.han.de> schrieb dazu am 15. Dez 1996:
#!/usr/bin/perl
select((select(STDOUT), $| = 1)[$[]);
select((select(STDIN), $| = 1)[$[]);
exec "cu","-E","''", "-l", "$ARGV[0]";
die "$0: Cant exec cu: $!\n";
Und dann muss das Ding per inetd gestartet werden:
modem 20006/tcp modemd # Modem service via TCP
isdn 20007/tcp modemd # ISDN service via TCP
Nachteil: comt-2.0 ist nur für 16Bit Anwendungen "sichtbar". Der
Einsatz unter win95 und Windows NT bleibt also auch dort auf 16Bit Kram
beschränkt!
2.12 Isdnlog
- Wie kann ich isdnlog dazu bringen, mir die High Layer Compatibility
(Speech, Video,...) so anzuzeigen, wie ich es gerne hätte?
Gernot Zander <hifi@scorpio.in-berlin.de> postete am 6. Okt 1996 einen ent-
sprechenden Patch in der Mailingliste, der isdnlog besser anpaßt.
- Kann man in der Ausgabe von isdnrep die Dienstekennung eines eingehenden
Anrufes sehen?
Andreas Kool <akool@Kool.f.EUnet.de> schrieb hierzu am 3. Dez 1996:
Im isdnrep indirekt schon -- sofern du alle von isdnlog ausdekodierten
Dienstkennungen in deiner "isdnlog.conf" als Alias eingetragen hast ...
- Warum erfaßt isdnlog neben den Gebühren nicht auch die Telefonnummer, die
meine anderen ISDN-Geräte (z.B. ISDN-Telefon) anrufen?
Weil die ISDN-Karte wie alle ISDN-Geräte getrennte Sende- und
Empfangsleitungen (RX bzw. TX Leitung) hat. Isdnlog müßte die auf der
Sendeleitung übermittelten Daten belauschen, um die Telefonnummer zu
erfahren. Zumindestens bei der Teleskarte ist das jedoch nicht möglich, wie
Karsten Keil <keil@temic-ech.spacenet.de> am 12. Feb 1997 schrieb:
Das ist bei allen Karten mit 1 Siemens ISAC so, der hat (und braucht)
nur 1 Empfaenger und 1 Sender.
Theoretisch besteht eine Moeglichkeit, mit nur einem Empfaenger den
kompletten D-Kanal zu belauschen (das macht der ISAC sogar) und zwar
werden die auf der RX Leitung empfangenden D-Bits auf sogenannte Echo
Bits zeitversetzt auf die TX Leitung kopiert, darueber erfolgt die
Access Kontrolle (Kollisionserkennung) des S0 Busses.
Leider gibt es im ISAC im TA Mode keine Moeglichkeit die ECHO Bits aus
einem Register zu lesen.
Zu möglichen Lösungen siehe nächste Frage.
- Wie kann ich trotzdem isdnlog dazu bringen, die Telefonnummer auch von
anderen ISDN-Geräten mitzubekommen?
Es gibt zwei Möglichkeiten. Zum einen gibt es von der Deutschen Telekom die
kostenpflichtige Möglichkeit, alle Daten nochmal zurückschicken zu lassen
(COLP = Connected Line Identification Presentation, ca. DM 10,- pro Monat
je Basisanschluß). Diese kann isdnlog (>=2.52) dann wieder auf der TX
Leitung lesen.
Alternativ dazu wird isdnlog ab der nächsten Version (aktuell ist 2.52)
die Möglichkeit bieten, mit einer zweiten, "verpolten" Teles-Karte zu
arbeiten, bei der die RX Leitung an den TX Anschluß der Karte geführt wird.
Die RX Leitung der Karte darf an keine der Leitungen angeschlossen werden!
Aufgrund der Schaltung kann die Teles-Karte für keinen anderen Zweck mehr
eingesetzt werden. Das ganze sieht dann so aus:
B 3 -- RX+ 2a ---------------\
U 4 -- TX+ 1a -- offen ------------
S 5 -- TX- 1b -- offen ------------ Karte
6 -- RX- 2b ---------------/
Eine theoretische dritte Möglichkeit gibt es noch für alle, die eine
eigene TK-Anlage haben, über die sämtliche weiteren Geräte angeschlossen
sind. Falls diese Telefonanlage ebenfalls alle ausgehenden Telefonnummern
protokollieren kann, könnten diese ausgelesen werden (üblicherweise über
eine serielle Schnittstelle).
Es gibt jedoch einen Grund, warum isdnlog das nicht schon längst
unterstützt. Um die Daten zu verwerten, müßte isdnlog diese sofort beim
RELEASE COMPLETE zur Verfügung gestellt bekommen, bevor auf dem D-Kanal
neue Informationen übermittelt werden. Leider sind die bisher getesteten
Telefonanlagen dafür zu langsam (insbesondere die weit verbreitete ISTEC).
Als einzige Möglichkeit bleibt, die Daten nachträglich zu kombinieren.
Dabei kommt es aber zur Schwierigkeit, die unterschiedlichen Uhrzeiten
zu synchronisieren. Wer das realisieren möchte, ist dazu herzlich gerne
eingeladen (ich stelle auch gerne entsprechende Logs von meiner Ackermann
Euracom zur Verfügung - Matthias Heßler <hessler@wi-inf.uni-essen.de>).
- Erfaßt isdnlog auch die neuen Tarife der deutschen Telekom (City Weekend,
City Plus)?
Da die Vermittlungsstellen der Telekom das nicht hinbekommen, werden die
Gebühreninformationen nicht korrekt übermittelt. Die nächste Version von
isdnlog (>2.52) wird das jedoch können.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
niederländischen Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_NL" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
schweizer Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_CH" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich mir den Datendurchsatz grafisch anzeigen lassen?
Dazu gibt's "xisdnload". Clemens Perz <listperz@gwsnet.ttt.de> wußte am
6. Feb 1997 noch eine weitere Möglichkeit:
Ich hab auf der Sunsite ein kleines Tool Namens netload für die Console
gefunden und es auf ISDN-Interfaces angepasst. Damit kann man recht
einfach den momentanen Traffic auf der Leitung in Augenschein nehmen.
Zu finden auf:
ftp://ftp.region.trier.de/pub/unix/linux/sources/network/isdn/netload-0.92.isdn.tar.gz
Einfach starten mit netload isdnxx
2.13 Isdn der Provider auch kennt. Trägt z.B. der Router im
LAN die lokale IP-Adresse 192.168.1.1, und ein anderer Rechner die
192.168.1.2, dann kennt der Provider diese Adressen ja nicht. Er weist z.B.
dem PPP-Interface des Routers die Adresse 123.234.345.99 zu - und nur bei
Paketen aus dem Internet, die an diese Nummer adressiert sind, weiß er
auch, an wen er die Pakete schicken soll. Daher muß der Router Pakete von
anderen Rechnern im LAN "maskieren" - mit seiner eigenen, dynamisch
zugewiesenen Adresse (und dabei natürlich Buch darüber führen, was an
wen von wem kam, um die Antwort-Pakete richtig zuzustellen).
Zum Glück ist diese Funktion in den Linux-Kernel =>2.0.0 schon eingebaut
(s.o.) - sie nennt sich "IP-Masquerading". Vereinfacht ausgedrückt geht
das so:
Ein LAN-Rechner schickt ein Paket ab, das neben IP-Nummer und Ziel-Port des
Empfängers auch die "Absender-Adresse" in Form einer IP-Nummer und eines
Antwort-Ports trägt. Der maskierende Router nun ersetzt die Absender-IP
durch seine eigene und den Rücksende-Port durch einen freien aus seinem
Fundus. Unter dieser "freien" Portnummer werden die originalen Absender-
Daten gespeichert. Kommt nun ein Antwort-Paket aus dem Internet an diesen
Port, werden dessen Empfänger-Adresse und -Port mit der gespeicherten
Rücksende-Adresse überschrieben und an den LAN-Rechner weitergeleitet.
Paket für Paket.
Leicht einsehbar ist übrigens, daß dieses Verfahren nur mit Diensten
funktioniert, bei denen auch eine Rücksende-Adresse angegeben wird. Dazu
gehören u.a. telnet, http, ftp, irc (eingeschränkt), nicht aber Echo
(ping).
Zurück zur Praxis. Damit das Masquerading auch bei FTP und IRC
funktioniert, werden zunächst zwei Module geladen:
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
Dann werden die Forward-Rules des Kernel zum Masquerading gezwungen:
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b
Das Programm ipfwadm gibt es per Anonymous FTP unter:
ftp://ftp.xos.nl/pub/linux/ipfwadm/ipfwadm-2.3.0.tar.gz
In diesem Beispiel werden im LAN die IP-Adressen 192.168.123.1 bis
192.168.123.254 benutzt. Legen wir zur Vereinfachung fest, der Linux-Router
habe dabei die Adresse 192.168.123.1.
Obige Zeile bewirkt, daß IP-Pakete, die von 192.168.123.x ausgehen und
an wenauchimmer gerichtet sind, maskiert werden. Das hat den Nachteil, daß
auch innerhalb des LAN fleißig drauflosmaskiert wird, was man aber durch
Einfügen weiterer Rules vermeiden kann. "man ipfwadm" sei hier zur Lektüre
empfohlen.
(Hinweis von Ralf Rudolph <ralf@artifex.de> hierzu:
Hmm. So wie ich das sehe, passiert da gar nichts. Grund: Die Rechner im
lokalen Netz unterhalten sich ja direkt über die fake-Adressen im
192.168.123.xxx-Netz. Zum Beweis kannst Du Deine Linux-Kiste einfach
abschalten (naja OK, shutdown...), und die lokalen Rechner werden sich
weiter unterhalten können. Also wird da auch nix masqueraded.
Der Hintergrund: Masquerading ist eine FORWARD Rule im Firewall und
wird daher auch nur beim FORWARDEN (wörtlich zu nehmen: WEITERleiten)
verwendet.
Netz-intern wird nichts geforwarded und deshalb auch nichts
masqueraded, solange Du nur eine Netzwerkkarte hast. Bei mehreren
Karten hast Du jedoch recht: Hier sollte man entsprechende Routing-
und auch ipfwadm-Einträge vornehmen.
Antwort: Ist tatsächlich etwas ungenau; schaden tut es aber nix, es sei
denn, man will unbedingt nicht maskierbare Services benutzen.)
Das "Verstecken" des LAN vor dem Provider haben wir nun erreicht. Jetzt
gilt es, bei Bedarf einen automatischen Verbindungsaufbau zu erzwingen.
Dafür ist es zunächst nötig, die anderen Rechner im LAN dazu zu bringen,
alle für "Außerhalb" bestimmten IP-Pakete an den Linux-Router zu
übergeben und diesem die Weiterleitung zu überlassen. Nichts leichter als
das: Sowohl bei den verschiedenen Windows-Versionen, als auch beim AmiTCP
und beim MacTCP gibt es in der Konfiguration den Stichwort "Default-
Gateway" oder nur "Gateway". Hier ist die lokale IP-Adresse des
Routers einzutragen (denn die spätere Adresse, die vom Provider kommt, ist
ja erstens noch nicht bekannt und ändert sich zweitens bei jedem Anruf).
Letzter Schritt ist dann, das "dial-on-demand" einzurichten. In
Verbindung mit isdn4linux gibt es dafür zwei Möglichkeiten:
* Man verwendet synchrones PPP für die Verbindung zum Provider, also
den "ipppd". Dann ist nichts weiter zu tun als dafür zu sorgen, daß
immer die Default-Route des Routers auf das entsprechende ipppx-
Interface weist. Vorsicht: Beim Verbindungsabbau löscht der Kernel
diese Route!
Sie muß also z.B. in der Datei /etc/ppp/ip-down neu gesetzt werden.
Das Risiko bei diesem Verfahren sind Programme auf den LAN-Rechnern,
die mehr oder weniger regelmäßig Nameserver-Requests, Keepalive-
Pakete oder ARP-Broadcastings erzeugen - dann stellt nämlich der
Router jedesmal eine Verbindung zum Provider her. Die Telekom wird's
danken.
Übrigens kann es passieren, daß manche aus dem LAN initiierte
Verbindungen recht lange auf Antwort warten. Ich weiß nicht, ob
Kernel oder ipppd das "auslösende" Paket verschlucken, oder die
Antwort darauf unterschlagen; ich weiß aber, daß es hilft, z.B. bei
Netscape wenige Sekunden nach Anforderung der ersten Seite auf den
"roten Knopf" zu drücken und die Seite nochmals anzufordern.
Wie bereits erwähnt: Die Konfiguration des ipppd wird an anderer
Stelle ausführlich erklärt - siehe entsprechende Fragen sowie
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
* Benutzt man asynchrones ppp oder gar SLIP/CSLIP für die Verbindung
zum Provider, kann man das Programm "diald" [4] verwenden. Es bietet
zudem den Vorteil, extrem stark konfigurierbar zu sein; so kann man
z.B. festlegen, daß zwischen 0900 und 1200 grundsätzlich keine
Verbindung aufgebaut wird, daß Nameserver-Anfragen eine Verbindung
zwar nicht aufbauen, aber offenhalten können u.v.m. Wer sich mit
diesen Konfigurationsmöglichkeiten nicht herumschlagen mag, braucht
das indes auch nicht - die Default-Konfiguration kann man ohne
Gefahr für Leib und Geldbörse übernehmen :-)
So.
Wenn jetzt das Masquerading eingerichtet wurde,
wenn der Linux-Router auf allen LAN-Rechnern als Gateway eingetragen
wurde,
wenn ein "ping abc.edu", eingetippt auf der Console des Routers, eine
Verbindung zum Provider aufbaut,
dann sollte damit auch für alle Rechner im LAN der Weg ins Internet
frei sein.
Wie sieht der "PERL-Einzeiler" "modemd" nun genau aus?
Marc Neitzner <marc@zeus.han.de> schrieb dazu am 15. Dez 1996:
#!/usr/bin/perl
select((select(STDOUT), $| = 1)[$[]);
select((select(STDIN), $| = 1)[$[]);
exec "cu","-E","''", "-l", "$ARGV[0]";
die "$0: Cant exec cu: $!\n";
Und dann muss das Ding per inetd gestartet werden:
modem 20006/tcp modemd # Modem service via TCP
isdn 20007/tcp modemd # ISDN service via TCP
Nachteil: comt-2.0 ist nur für 16Bit Anwendungen "sichtbar". Der
Einsatz unter win95 und Windows NT bleibt also auch dort auf 16Bit Kram
beschränkt!
2.12 Isdnlog
- Wie kann ich isdnlog dazu bringen, mir die High Layer Compatibility
(Speech, Video,...) so anzuzeigen, wie ich es gerne hätte?
Gernot Zander <hifi@scorpio.in-berlin.de> postete am 6. Okt 1996 einen ent-
sprechenden Patch in der Mailingliste, der isdnlog besser anpaßt.
- Kann man in der Ausgabe von isdnrep die Dienstekennung eines eingehenden
Anrufes sehen?
Andreas Kool <akool@Kool.f.EUnet.de> schrieb hierzu am 3. Dez 1996:
Im isdnrep indirekt schon -- sofern du alle von isdnlog ausdekodierten
Dienstkennungen in deiner "isdnlog.conf" als Alias eingetragen hast ...
- Warum erfaßt isdnlog neben den Gebühren nicht auch die Telefonnummer, die
meine anderen ISDN-Geräte (z.B. ISDN-Telefon) anrufen?
Weil die ISDN-Karte wie alle ISDN-Geräte getrennte Sende- und
Empfangsleitungen (RX bzw. TX Leitung) hat. Isdnlog müßte die auf der
Sendeleitung übermittelten Daten belauschen, um die Telefonnummer zu
erfahren. Zumindestens bei der Teleskarte ist das jedoch nicht möglich, wie
Karsten Keil <keil@temic-ech.spacenet.de> am 12. Feb 1997 schrieb:
Das ist bei allen Karten mit 1 Siemens ISAC so, der hat (und braucht)
nur 1 Empfaenger und 1 Sender.
Theoretisch besteht eine Moeglichkeit, mit nur einem Empfaenger den
kompletten D-Kanal zu belauschen (das macht der ISAC sogar) und zwar
werden die auf der RX Leitung empfangenden D-Bits auf sogenannte Echo
Bits zeitversetzt auf die TX Leitung kopiert, darueber erfolgt die
Access Kontrolle (Kollisionserkennung) des S0 Busses.
Leider gibt es im ISAC im TA Mode keine Moeglichkeit die ECHO Bits aus
einem Register zu lesen.
Zu möglichen Lösungen siehe nächste Frage.
- Wie kann ich trotzdem isdnlog dazu bringen, die Telefonnummer auch von
anderen ISDN-Geräten mitzubekommen?
Es gibt zwei Möglichkeiten. Zum einen gibt es von der Deutschen Telekom die
kostenpflichtige Möglichkeit, alle Daten nochmal zurückschicken zu lassen
(COLP = Connected Line Identification Presentation, ca. DM 10,- pro Monat
je Basisanschluß). Diese kann isdnlog (>=2.52) dann wieder auf der TX
Leitung lesen.
Alternativ dazu wird isdnlog ab der nächsten Version (aktuell ist 2.52)
die Möglichkeit bieten, mit einer zweiten, "verpolten" Teles-Karte zu
arbeiten, bei der die RX Leitung an den TX Anschluß der Karte geführt wird.
Die RX Leitung der Karte darf an keine der Leitungen angeschlossen werden!
Aufgrund der Schaltung kann die Teles-Karte für keinen anderen Zweck mehr
eingesetzt werden. Das ganze sieht dann so aus:
B 3 -- RX+ 2a ---------------\
U 4 -- TX+ 1a -- offen ------------
S 5 -- TX- 1b -- offen ------------ Karte
6 -- RX- 2b ---------------/
Eine theoretische dritte Möglichkeit gibt es noch für alle, die eine
eigene TK-Anlage haben, über die sämtliche weiteren Geräte angeschlossen
sind. Falls diese Telefonanlage ebenfalls alle ausgehenden Telefonnummern
protokollieren kann, könnten diese ausgelesen werden (üblicherweise über
eine serielle Schnittstelle).
Es gibt jedoch einen Grund, warum isdnlog das nicht schon längst
unterstützt. Um die Daten zu verwerten, müßte isdnlog diese sofort beim
RELEASE COMPLETE zur Verfügung gestellt bekommen, bevor auf dem D-Kanal
neue Informationen übermittelt werden. Leider sind die bisher getesteten
Telefonanlagen dafür zu langsam (insbesondere die weit verbreitete ISTEC).
Als einzige Möglichkeit bleibt, die Daten nachträglich zu kombinieren.
Dabei kommt es aber zur Schwierigkeit, die unterschiedlichen Uhrzeiten
zu synchronisieren. Wer das realisieren möchte, ist dazu herzlich gerne
eingeladen (ich stelle auch gerne entsprechende Logs von meiner Ackermann
Euracom zur Verfügung - Matthias Heßler <hessler@wi-inf.uni-essen.de>).
- Erfaßt isdnlog auch die neuen Tarife der deutschen Telekom (City Weekend,
City Plus)?
Da die Vermittlungsstellen der Telekom das nicht hinbekommen, werden die
Gebühreninformationen nicht korrekt übermittelt. Die nächste Version von
isdnlog (>2.52) wird das jedoch können.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
niederländischen Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_NL" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
schweizer Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_CH" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich mir den Datendurchsatz grafisch anzeigen lassen?
Dazu gibt's "xisdnload". Clemens Perz <listperz@gwsnet.ttt.de> wußte am
6. Feb 1997 noch eine weitere Möglichkeit:
Ich hab auf der Sunsite ein kleines Tool Namens netload für die Console
gefunden und es auf ISDN-Interfaces angepasst. Damit kann man recht
einfach den momentanen Traffic auf der Leitung in Augenschein nehmen.
Zu finden auf:
ftp://ftp.region.trier.de/pub/unix/linux/sources/network/isdn/netload-0.92.isdn.tar.gz
Einfach starten mit netload isdnxx
2.13 Isdn der Provider auch kennt. Trägt z.B. der Router im
LAN die lokale IP-Adresse 192.168.1.1, und ein anderer Rechner die
192.168.1.2, dann kennt der Provider diese Adressen ja nicht. Er weist z.B.
dem PPP-Interface des Routers die Adresse 123.234.345.99 zu - und nur bei
Paketen aus dem Internet, die an diese Nummer adressiert sind, weiß er
auch, an wen er die Pakete schicken soll. Daher muß der Router Pakete von
anderen Rechnern im LAN "maskieren" - mit seiner eigenen, dynamisch
zugewiesenen Adresse (und dabei natürlich Buch darüber führen, was an
wen von wem kam, um die Antwort-Pakete richtig zuzustellen).
Zum Glück ist diese Funktion in den Linux-Kernel =>2.0.0 schon eingebaut
(s.o.) - sie nennt sich "IP-Masquerading". Vereinfacht ausgedrückt geht
das so:
Ein LAN-Rechner schickt ein Paket ab, das neben IP-Nummer und Ziel-Port des
Empfängers auch die "Absender-Adresse" in Form einer IP-Nummer und eines
Antwort-Ports trägt. Der maskierende Router nun ersetzt die Absender-IP
durch seine eigene und den Rücksende-Port durch einen freien aus seinem
Fundus. Unter dieser "freien" Portnummer werden die originalen Absender-
Daten gespeichert. Kommt nun ein Antwort-Paket aus dem Internet an diesen
Port, werden dessen Empfänger-Adresse und -Port mit der gespeicherten
Rücksende-Adresse überschrieben und an den LAN-Rechner weitergeleitet.
Paket für Paket.
Leicht einsehbar ist übrigens, daß dieses Verfahren nur mit Diensten
funktioniert, bei denen auch eine Rücksende-Adresse angegeben wird. Dazu
gehören u.a. telnet, http, ftp, irc (eingeschränkt), nicht aber Echo
(ping).
Zurück zur Praxis. Damit das Masquerading auch bei FTP und IRC
funktioniert, werden zunächst zwei Module geladen:
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
Dann werden die Forward-Rules des Kernel zum Masquerading gezwungen:
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b
Das Programm ipfwadm gibt es per Anonymous FTP unter:
ftp://ftp.xos.nl/pub/linux/ipfwadm/ipfwadm-2.3.0.tar.gz
In diesem Beispiel werden im LAN die IP-Adressen 192.168.123.1 bis
192.168.123.254 benutzt. Legen wir zur Vereinfachung fest, der Linux-Router
habe dabei die Adresse 192.168.123.1.
Obige Zeile bewirkt, daß IP-Pakete, die von 192.168.123.x ausgehen und
an wenauchimmer gerichtet sind, maskiert werden. Das hat den Nachteil, daß
auch innerhalb des LAN fleißig drauflosmaskiert wird, was man aber durch
Einfügen weiterer Rules vermeiden kann. "man ipfwadm" sei hier zur Lektüre
empfohlen.
(Hinweis von Ralf Rudolph <ralf@artifex.de> hierzu:
Hmm. So wie ich das sehe, passiert da gar nichts. Grund: Die Rechner im
lokalen Netz unterhalten sich ja direkt über die fake-Adressen im
192.168.123.xxx-Netz. Zum Beweis kannst Du Deine Linux-Kiste einfach
abschalten (naja OK, shutdown...), und die lokalen Rechner werden sich
weiter unterhalten können. Also wird da auch nix masqueraded.
Der Hintergrund: Masquerading ist eine FORWARD Rule im Firewall und
wird daher auch nur beim FORWARDEN (wörtlich zu nehmen: WEITERleiten)
verwendet.
Netz-intern wird nichts geforwarded und deshalb auch nichts
masqueraded, solange Du nur eine Netzwerkkarte hast. Bei mehreren
Karten hast Du jedoch recht: Hier sollte man entsprechende Routing-
und auch ipfwadm-Einträge vornehmen.
Antwort: Ist tatsächlich etwas ungenau; schaden tut es aber nix, es sei
denn, man will unbedingt nicht maskierbare Services benutzen.)
Das "Verstecken" des LAN vor dem Provider haben wir nun erreicht. Jetzt
gilt es, bei Bedarf einen automatischen Verbindungsaufbau zu erzwingen.
Dafür ist es zunächst nötig, die anderen Rechner im LAN dazu zu bringen,
alle für "Außerhalb" bestimmten IP-Pakete an den Linux-Router zu
übergeben und diesem die Weiterleitung zu überlassen. Nichts leichter als
das: Sowohl bei den verschiedenen Windows-Versionen, als auch beim AmiTCP
und beim MacTCP gibt es in der Konfiguration den Stichwort "Default-
Gateway" oder nur "Gateway". Hier ist die lokale IP-Adresse des
Routers einzutragen (denn die spätere Adresse, die vom Provider kommt, ist
ja erstens noch nicht bekannt und ändert sich zweitens bei jedem Anruf).
Letzter Schritt ist dann, das "dial-on-demand" einzurichten. In
Verbindung mit isdn4linux gibt es dafür zwei Möglichkeiten:
* Man verwendet synchrones PPP für die Verbindung zum Provider, also
den "ipppd". Dann ist nichts weiter zu tun als dafür zu sorgen, daß
immer die Default-Route des Routers auf das entsprechende ipppx-
Interface weist. Vorsicht: Beim Verbindungsabbau löscht der Kernel
diese Route!
Sie muß also z.B. in der Datei /etc/ppp/ip-down neu gesetzt werden.
Das Risiko bei diesem Verfahren sind Programme auf den LAN-Rechnern,
die mehr oder weniger regelmäßig Nameserver-Requests, Keepalive-
Pakete oder ARP-Broadcastings erzeugen - dann stellt nämlich der
Router jedesmal eine Verbindung zum Provider her. Die Telekom wird's
danken.
Übrigens kann es passieren, daß manche aus dem LAN initiierte
Verbindungen recht lange auf Antwort warten. Ich weiß nicht, ob
Kernel oder ipppd das "auslösende" Paket verschlucken, oder die
Antwort darauf unterschlagen; ich weiß aber, daß es hilft, z.B. bei
Netscape wenige Sekunden nach Anforderung der ersten Seite auf den
"roten Knopf" zu drücken und die Seite nochmals anzufordern.
Wie bereits erwähnt: Die Konfiguration des ipppd wird an anderer
Stelle ausführlich erklärt - siehe entsprechende Fragen sowie
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
* Benutzt man asynchrones ppp oder gar SLIP/CSLIP für die Verbindung
zum Provider, kann man das Programm "diald" [4] verwenden. Es bietet
zudem den Vorteil, extrem stark konfigurierbar zu sein; so kann man
z.B. festlegen, daß zwischen 0900 und 1200 grundsätzlich keine
Verbindung aufgebaut wird, daß Nameserver-Anfragen eine Verbindung
zwar nicht aufbauen, aber offenhalten können u.v.m. Wer sich mit
diesen Konfigurationsmöglichkeiten nicht herumschlagen mag, braucht
das indes auch nicht - die Default-Konfiguration kann man ohne
Gefahr für Leib und Geldbörse übernehmen :-)
So.
Wenn jetzt das Masquerading eingerichtet wurde,
wenn der Linux-Router auf allen LAN-Rechnern als Gateway eingetragen
wurde,
wenn ein "ping abc.edu", eingetippt auf der Console des Routers, eine
Verbindung zum Provider aufbaut,
dann sollte damit auch für alle Rechner im LAN der Weg ins Internet
frei sein.
Wie sieht der "PERL-Einzeiler" "modemd" nun genau aus?
Marc Neitzner <marc@zeus.han.de> schrieb dazu am 15. Dez 1996:
#!/usr/bin/perl
select((select(STDOUT), $| = 1)[$[]);
select((select(STDIN), $| = 1)[$[]);
exec "cu","-E","''", "-l", "$ARGV[0]";
die "$0: Cant exec cu: $!\n";
Und dann muss das Ding per inetd gestartet werden:
modem 20006/tcp modemd # Modem service via TCP
isdn 20007/tcp modemd # ISDN service via TCP
Nachteil: comt-2.0 ist nur für 16Bit Anwendungen "sichtbar". Der
Einsatz unter win95 und Windows NT bleibt also auch dort auf 16Bit Kram
beschränkt!
2.12 Isdnlog
- Wie kann ich isdnlog dazu bringen, mir die High Layer Compatibility
(Speech, Video,...) so anzuzeigen, wie ich es gerne hätte?
Gernot Zander <hifi@scorpio.in-berlin.de> postete am 6. Okt 1996 einen ent-
sprechenden Patch in der Mailingliste, der isdnlog besser anpaßt.
- Kann man in der Ausgabe von isdnrep die Dienstekennung eines eingehenden
Anrufes sehen?
Andreas Kool <akool@Kool.f.EUnet.de> schrieb hierzu am 3. Dez 1996:
Im isdnrep indirekt schon -- sofern du alle von isdnlog ausdekodierten
Dienstkennungen in deiner "isdnlog.conf" als Alias eingetragen hast ...
- Warum erfaßt isdnlog neben den Gebühren nicht auch die Telefonnummer, die
meine anderen ISDN-Geräte (z.B. ISDN-Telefon) anrufen?
Weil die ISDN-Karte wie alle ISDN-Geräte getrennte Sende- und
Empfangsleitungen (RX bzw. TX Leitung) hat. Isdnlog müßte die auf der
Sendeleitung übermittelten Daten belauschen, um die Telefonnummer zu
erfahren. Zumindestens bei der Teleskarte ist das jedoch nicht möglich, wie
Karsten Keil <keil@temic-ech.spacenet.de> am 12. Feb 1997 schrieb:
Das ist bei allen Karten mit 1 Siemens ISAC so, der hat (und braucht)
nur 1 Empfaenger und 1 Sender.
Theoretisch besteht eine Moeglichkeit, mit nur einem Empfaenger den
kompletten D-Kanal zu belauschen (das macht der ISAC sogar) und zwar
werden die auf der RX Leitung empfangenden D-Bits auf sogenannte Echo
Bits zeitversetzt auf die TX Leitung kopiert, darueber erfolgt die
Access Kontrolle (Kollisionserkennung) des S0 Busses.
Leider gibt es im ISAC im TA Mode keine Moeglichkeit die ECHO Bits aus
einem Register zu lesen.
Zu möglichen Lösungen siehe nächste Frage.
- Wie kann ich trotzdem isdnlog dazu bringen, die Telefonnummer auch von
anderen ISDN-Geräten mitzubekommen?
Es gibt zwei Möglichkeiten. Zum einen gibt es von der Deutschen Telekom die
kostenpflichtige Möglichkeit, alle Daten nochmal zurückschicken zu lassen
(COLP = Connected Line Identification Presentation, ca. DM 10,- pro Monat
je Basisanschluß). Diese kann isdnlog (>=2.52) dann wieder auf der TX
Leitung lesen.
Alternativ dazu wird isdnlog ab der nächsten Version (aktuell ist 2.52)
die Möglichkeit bieten, mit einer zweiten, "verpolten" Teles-Karte zu
arbeiten, bei der die RX Leitung an den TX Anschluß der Karte geführt wird.
Die RX Leitung der Karte darf an keine der Leitungen angeschlossen werden!
Aufgrund der Schaltung kann die Teles-Karte für keinen anderen Zweck mehr
eingesetzt werden. Das ganze sieht dann so aus:
B 3 -- RX+ 2a ---------------\
U 4 -- TX+ 1a -- offen ------------
S 5 -- TX- 1b -- offen ------------ Karte
6 -- RX- 2b ---------------/
Eine theoretische dritte Möglichkeit gibt es noch für alle, die eine
eigene TK-Anlage haben, über die sämtliche weiteren Geräte angeschlossen
sind. Falls diese Telefonanlage ebenfalls alle ausgehenden Telefonnummern
protokollieren kann, könnten diese ausgelesen werden (üblicherweise über
eine serielle Schnittstelle).
Es gibt jedoch einen Grund, warum isdnlog das nicht schon längst
unterstützt. Um die Daten zu verwerten, müßte isdnlog diese sofort beim
RELEASE COMPLETE zur Verfügung gestellt bekommen, bevor auf dem D-Kanal
neue Informationen übermittelt werden. Leider sind die bisher getesteten
Telefonanlagen dafür zu langsam (insbesondere die weit verbreitete ISTEC).
Als einzige Möglichkeit bleibt, die Daten nachträglich zu kombinieren.
Dabei kommt es aber zur Schwierigkeit, die unterschiedlichen Uhrzeiten
zu synchronisieren. Wer das realisieren möchte, ist dazu herzlich gerne
eingeladen (ich stelle auch gerne entsprechende Logs von meiner Ackermann
Euracom zur Verfügung - Matthias Heßler <hessler@wi-inf.uni-essen.de>).
- Erfaßt isdnlog auch die neuen Tarife der deutschen Telekom (City Weekend,
City Plus)?
Da die Vermittlungsstellen der Telekom das nicht hinbekommen, werden die
Gebühreninformationen nicht korrekt übermittelt. Die nächste Version von
isdnlog (>2.52) wird das jedoch können.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
niederländischen Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_NL" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
schweizer Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_CH" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich mir den Datendurchsatz grafisch anzeigen lassen?
Dazu gibt's "xisdnload". Clemens Perz <listperz@gwsnet.ttt.de> wußte am
6. Feb 1997 noch eine weitere Möglichkeit:
Ich hab auf der Sunsite ein kleines Tool Namens netload für die Console
gefunden und es auf ISDN-Interfaces angepasst. Damit kann man recht
einfach den momentanen Traffic auf der Leitung in Augenschein nehmen.
Zu finden auf:
ftp://ftp.region.trier.de/pub/unix/linux/sources/network/isdn/netload-0.92.isdn.tar.gz
Einfach starten mit netload isdnxx
2.13 Isdn der Provider auch kennt. Trägt z.B. der Router im
LAN die lokale IP-Adresse 192.168.1.1, und ein anderer Rechner die
192.168.1.2, dann kennt der Provider diese Adressen ja nicht. Er weist z.B.
dem PPP-Interface des Routers die Adresse 123.234.345.99 zu - und nur bei
Paketen aus dem Internet, die an diese Nummer adressiert sind, weiß er
auch, an wen er die Pakete schicken soll. Daher muß der Router Pakete von
anderen Rechnern im LAN "maskieren" - mit seiner eigenen, dynamisch
zugewiesenen Adresse (und dabei natürlich Buch darüber führen, was an
wen von wem kam, um die Antwort-Pakete richtig zuzustellen).
Zum Glück ist diese Funktion in den Linux-Kernel =>2.0.0 schon eingebaut
(s.o.) - sie nennt sich "IP-Masquerading". Vereinfacht ausgedrückt geht
das so:
Ein LAN-Rechner schickt ein Paket ab, das neben IP-Nummer und Ziel-Port des
Empfängers auch die "Absender-Adresse" in Form einer IP-Nummer und eines
Antwort-Ports trägt. Der maskierende Router nun ersetzt die Absender-IP
durch seine eigene und den Rücksende-Port durch einen freien aus seinem
Fundus. Unter dieser "freien" Portnummer werden die originalen Absender-
Daten gespeichert. Kommt nun ein Antwort-Paket aus dem Internet an diesen
Port, werden dessen Empfänger-Adresse und -Port mit der gespeicherten
Rücksende-Adresse überschrieben und an den LAN-Rechner weitergeleitet.
Paket für Paket.
Leicht einsehbar ist übrigens, daß dieses Verfahren nur mit Diensten
funktioniert, bei denen auch eine Rücksende-Adresse angegeben wird. Dazu
gehören u.a. telnet, http, ftp, irc (eingeschränkt), nicht aber Echo
(ping).
Zurück zur Praxis. Damit das Masquerading auch bei FTP und IRC
funktioniert, werden zunächst zwei Module geladen:
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
Dann werden die Forward-Rules des Kernel zum Masquerading gezwungen:
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b
Das Programm ipfwadm gibt es per Anonymous FTP unter:
ftp://ftp.xos.nl/pub/linux/ipfwadm/ipfwadm-2.3.0.tar.gz
In diesem Beispiel werden im LAN die IP-Adressen 192.168.123.1 bis
192.168.123.254 benutzt. Legen wir zur Vereinfachung fest, der Linux-Router
habe dabei die Adresse 192.168.123.1.
Obige Zeile bewirkt, daß IP-Pakete, die von 192.168.123.x ausgehen und
an wenauchimmer gerichtet sind, maskiert werden. Das hat den Nachteil, daß
auch innerhalb des LAN fleißig drauflosmaskiert wird, was man aber durch
Einfügen weiterer Rules vermeiden kann. "man ipfwadm" sei hier zur Lektüre
empfohlen.
(Hinweis von Ralf Rudolph <ralf@artifex.de> hierzu:
Hmm. So wie ich das sehe, passiert da gar nichts. Grund: Die Rechner im
lokalen Netz unterhalten sich ja direkt über die fake-Adressen im
192.168.123.xxx-Netz. Zum Beweis kannst Du Deine Linux-Kiste einfach
abschalten (naja OK, shutdown...), und die lokalen Rechner werden sich
weiter unterhalten können. Also wird da auch nix masqueraded.
Der Hintergrund: Masquerading ist eine FORWARD Rule im Firewall und
wird daher auch nur beim FORWARDEN (wörtlich zu nehmen: WEITERleiten)
verwendet.
Netz-intern wird nichts geforwarded und deshalb auch nichts
masqueraded, solange Du nur eine Netzwerkkarte hast. Bei mehreren
Karten hast Du jedoch recht: Hier sollte man entsprechende Routing-
und auch ipfwadm-Einträge vornehmen.
Antwort: Ist tatsächlich etwas ungenau; schaden tut es aber nix, es sei
denn, man will unbedingt nicht maskierbare Services benutzen.)
Das "Verstecken" des LAN vor dem Provider haben wir nun erreicht. Jetzt
gilt es, bei Bedarf einen automatischen Verbindungsaufbau zu erzwingen.
Dafür ist es zunächst nötig, die anderen Rechner im LAN dazu zu bringen,
alle für "Außerhalb" bestimmten IP-Pakete an den Linux-Router zu
übergeben und diesem die Weiterleitung zu überlassen. Nichts leichter als
das: Sowohl bei den verschiedenen Windows-Versionen, als auch beim AmiTCP
und beim MacTCP gibt es in der Konfiguration den Stichwort "Default-
Gateway" oder nur "Gateway". Hier ist die lokale IP-Adresse des
Routers einzutragen (denn die spätere Adresse, die vom Provider kommt, ist
ja erstens noch nicht bekannt und ändert sich zweitens bei jedem Anruf).
Letzter Schritt ist dann, das "dial-on-demand" einzurichten. In
Verbindung mit isdn4linux gibt es dafür zwei Möglichkeiten:
* Man verwendet synchrones PPP für die Verbindung zum Provider, also
den "ipppd". Dann ist nichts weiter zu tun als dafür zu sorgen, daß
immer die Default-Route des Routers auf das entsprechende ipppx-
Interface weist. Vorsicht: Beim Verbindungsabbau löscht der Kernel
diese Route!
Sie muß also z.B. in der Datei /etc/ppp/ip-down neu gesetzt werden.
Das Risiko bei diesem Verfahren sind Programme auf den LAN-Rechnern,
die mehr oder weniger regelmäßig Nameserver-Requests, Keepalive-
Pakete oder ARP-Broadcastings erzeugen - dann stellt nämlich der
Router jedesmal eine Verbindung zum Provider her. Die Telekom wird's
danken.
Übrigens kann es passieren, daß manche aus dem LAN initiierte
Verbindungen recht lange auf Antwort warten. Ich weiß nicht, ob
Kernel oder ipppd das "auslösende" Paket verschlucken, oder die
Antwort darauf unterschlagen; ich weiß aber, daß es hilft, z.B. bei
Netscape wenige Sekunden nach Anforderung der ersten Seite auf den
"roten Knopf" zu drücken und die Seite nochmals anzufordern.
Wie bereits erwähnt: Die Konfiguration des ipppd wird an anderer
Stelle ausführlich erklärt - siehe entsprechende Fragen sowie
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
* Benutzt man asynchrones ppp oder gar SLIP/CSLIP für die Verbindung
zum Provider, kann man das Programm "diald" [4] verwenden. Es bietet
zudem den Vorteil, extrem stark konfigurierbar zu sein; so kann man
z.B. festlegen, daß zwischen 0900 und 1200 grundsätzlich keine
Verbindung aufgebaut wird, daß Nameserver-Anfragen eine Verbindung
zwar nicht aufbauen, aber offenhalten können u.v.m. Wer sich mit
diesen Konfigurationsmöglichkeiten nicht herumschlagen mag, braucht
das indes auch nicht - die Default-Konfiguration kann man ohne
Gefahr für Leib und Geldbörse übernehmen :-)
So.
Wenn jetzt das Masquerading eingerichtet wurde,
wenn der Linux-Router auf allen LAN-Rechnern als Gateway eingetragen
wurde,
wenn ein "ping abc.edu", eingetippt auf der Console des Routers, eine
Verbindung zum Provider aufbaut,
dann sollte damit auch für alle Rechner im LAN der Weg ins Internet
frei sein.
Wie sieht der "PERL-Einzeiler" "modemd" nun genau aus?
Marc Neitzner <marc@zeus.han.de> schrieb dazu am 15. Dez 1996:
#!/usr/bin/perl
select((select(STDOUT), $| = 1)[$[]);
select((select(STDIN), $| = 1)[$[]);
exec "cu","-E","''", "-l", "$ARGV[0]";
die "$0: Cant exec cu: $!\n";
Und dann muss das Ding per inetd gestartet werden:
modem 20006/tcp modemd # Modem service via TCP
isdn 20007/tcp modemd # ISDN service via TCP
Nachteil: comt-2.0 ist nur für 16Bit Anwendungen "sichtbar". Der
Einsatz unter win95 und Windows NT bleibt also auch dort auf 16Bit Kram
beschränkt!
2.12 Isdnlog
- Wie kann ich isdnlog dazu bringen, mir die High Layer Compatibility
(Speech, Video,...) so anzuzeigen, wie ich es gerne hätte?
Gernot Zander <hifi@scorpio.in-berlin.de> postete am 6. Okt 1996 einen ent-
sprechenden Patch in der Mailingliste, der isdnlog besser anpaßt.
- Kann man in der Ausgabe von isdnrep die Dienstekennung eines eingehenden
Anrufes sehen?
Andreas Kool <akool@Kool.f.EUnet.de> schrieb hierzu am 3. Dez 1996:
Im isdnrep indirekt schon -- sofern du alle von isdnlog ausdekodierten
Dienstkennungen in deiner "isdnlog.conf" als Alias eingetragen hast ...
- Warum erfaßt isdnlog neben den Gebühren nicht auch die Telefonnummer, die
meine anderen ISDN-Geräte (z.B. ISDN-Telefon) anrufen?
Weil die ISDN-Karte wie alle ISDN-Geräte getrennte Sende- und
Empfangsleitungen (RX bzw. TX Leitung) hat. Isdnlog müßte die auf der
Sendeleitung übermittelten Daten belauschen, um die Telefonnummer zu
erfahren. Zumindestens bei der Teleskarte ist das jedoch nicht möglich, wie
Karsten Keil <keil@temic-ech.spacenet.de> am 12. Feb 1997 schrieb:
Das ist bei allen Karten mit 1 Siemens ISAC so, der hat (und braucht)
nur 1 Empfaenger und 1 Sender.
Theoretisch besteht eine Moeglichkeit, mit nur einem Empfaenger den
kompletten D-Kanal zu belauschen (das macht der ISAC sogar) und zwar
werden die auf der RX Leitung empfangenden D-Bits auf sogenannte Echo
Bits zeitversetzt auf die TX Leitung kopiert, darueber erfolgt die
Access Kontrolle (Kollisionserkennung) des S0 Busses.
Leider gibt es im ISAC im TA Mode keine Moeglichkeit die ECHO Bits aus
einem Register zu lesen.
Zu möglichen Lösungen siehe nächste Frage.
- Wie kann ich trotzdem isdnlog dazu bringen, die Telefonnummer auch von
anderen ISDN-Geräten mitzubekommen?
Es gibt zwei Möglichkeiten. Zum einen gibt es von der Deutschen Telekom die
kostenpflichtige Möglichkeit, alle Daten nochmal zurückschicken zu lassen
(COLP = Connected Line Identification Presentation, ca. DM 10,- pro Monat
je Basisanschluß). Diese kann isdnlog (>=2.52) dann wieder auf der TX
Leitung lesen.
Alternativ dazu wird isdnlog ab der nächsten Version (aktuell ist 2.52)
die Möglichkeit bieten, mit einer zweiten, "verpolten" Teles-Karte zu
arbeiten, bei der die RX Leitung an den TX Anschluß der Karte geführt wird.
Die RX Leitung der Karte darf an keine der Leitungen angeschlossen werden!
Aufgrund der Schaltung kann die Teles-Karte für keinen anderen Zweck mehr
eingesetzt werden. Das ganze sieht dann so aus:
B 3 -- RX+ 2a ---------------\
U 4 -- TX+ 1a -- offen ------------
S 5 -- TX- 1b -- offen ------------ Karte
6 -- RX- 2b ---------------/
Eine theoretische dritte Möglichkeit gibt es noch für alle, die eine
eigene TK-Anlage haben, über die sämtliche weiteren Geräte angeschlossen
sind. Falls diese Telefonanlage ebenfalls alle ausgehenden Telefonnummern
protokollieren kann, könnten diese ausgelesen werden (üblicherweise über
eine serielle Schnittstelle).
Es gibt jedoch einen Grund, warum isdnlog das nicht schon längst
unterstützt. Um die Daten zu verwerten, müßte isdnlog diese sofort beim
RELEASE COMPLETE zur Verfügung gestellt bekommen, bevor auf dem D-Kanal
neue Informationen übermittelt werden. Leider sind die bisher getesteten
Telefonanlagen dafür zu langsam (insbesondere die weit verbreitete ISTEC).
Als einzige Möglichkeit bleibt, die Daten nachträglich zu kombinieren.
Dabei kommt es aber zur Schwierigkeit, die unterschiedlichen Uhrzeiten
zu synchronisieren. Wer das realisieren möchte, ist dazu herzlich gerne
eingeladen (ich stelle auch gerne entsprechende Logs von meiner Ackermann
Euracom zur Verfügung - Matthias Heßler <hessler@wi-inf.uni-essen.de>).
- Erfaßt isdnlog auch die neuen Tarife der deutschen Telekom (City Weekend,
City Plus)?
Da die Vermittlungsstellen der Telekom das nicht hinbekommen, werden die
Gebühreninformationen nicht korrekt übermittelt. Die nächste Version von
isdnlog (>2.52) wird das jedoch können.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
niederländischen Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_NL" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
schweizer Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_CH" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich mir den Datendurchsatz grafisch anzeigen lassen?
Dazu gibt's "xisdnload". Clemens Perz <listperz@gwsnet.ttt.de> wußte am
6. Feb 1997 noch eine weitere Möglichkeit:
Ich hab auf der Sunsite ein kleines Tool Namens netload für die Console
gefunden und es auf ISDN-Interfaces angepasst. Damit kann man recht
einfach den momentanen Traffic auf der Leitung in Augenschein nehmen.
Zu finden auf:
ftp://ftp.region.trier.de/pub/unix/linux/sources/network/isdn/netload-0.92.isdn.tar.gz
Einfach starten mit netload isdnxx
2.13 Isdn der Provider auch kennt. Trägt z.B. der Router im
LAN die lokale IP-Adresse 192.168.1.1, und ein anderer Rechner die
192.168.1.2, dann kennt der Provider diese Adressen ja nicht. Er weist z.B.
dem PPP-Interface des Routers die Adresse 123.234.345.99 zu - und nur bei
Paketen aus dem Internet, die an diese Nummer adressiert sind, weiß er
auch, an wen er die Pakete schicken soll. Daher muß der Router Pakete von
anderen Rechnern im LAN "maskieren" - mit seiner eigenen, dynamisch
zugewiesenen Adresse (und dabei natürlich Buch darüber führen, was an
wen von wem kam, um die Antwort-Pakete richtig zuzustellen).
Zum Glück ist diese Funktion in den Linux-Kernel =>2.0.0 schon eingebaut
(s.o.) - sie nennt sich "IP-Masquerading". Vereinfacht ausgedrückt geht
das so:
Ein LAN-Rechner schickt ein Paket ab, das neben IP-Nummer und Ziel-Port des
Empfängers auch die "Absender-Adresse" in Form einer IP-Nummer und eines
Antwort-Ports trägt. Der maskierende Router nun ersetzt die Absender-IP
durch seine eigene und den Rücksende-Port durch einen freien aus seinem
Fundus. Unter dieser "freien" Portnummer werden die originalen Absender-
Daten gespeichert. Kommt nun ein Antwort-Paket aus dem Internet an diesen
Port, werden dessen Empfänger-Adresse und -Port mit der gespeicherten
Rücksende-Adresse überschrieben und an den LAN-Rechner weitergeleitet.
Paket für Paket.
Leicht einsehbar ist übrigens, daß dieses Verfahren nur mit Diensten
funktioniert, bei denen auch eine Rücksende-Adresse angegeben wird. Dazu
gehören u.a. telnet, http, ftp, irc (eingeschränkt), nicht aber Echo
(ping).
Zurück zur Praxis. Damit das Masquerading auch bei FTP und IRC
funktioniert, werden zunächst zwei Module geladen:
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
Dann werden die Forward-Rules des Kernel zum Masquerading gezwungen:
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b
Das Programm ipfwadm gibt es per Anonymous FTP unter:
ftp://ftp.xos.nl/pub/linux/ipfwadm/ipfwadm-2.3.0.tar.gz
In diesem Beispiel werden im LAN die IP-Adressen 192.168.123.1 bis
192.168.123.254 benutzt. Legen wir zur Vereinfachung fest, der Linux-Router
habe dabei die Adresse 192.168.123.1.
Obige Zeile bewirkt, daß IP-Pakete, die von 192.168.123.x ausgehen und
an wenauchimmer gerichtet sind, maskiert werden. Das hat den Nachteil, daß
auch innerhalb des LAN fleißig drauflosmaskiert wird, was man aber durch
Einfügen weiterer Rules vermeiden kann. "man ipfwadm" sei hier zur Lektüre
empfohlen.
(Hinweis von Ralf Rudolph <ralf@artifex.de> hierzu:
Hmm. So wie ich das sehe, passiert da gar nichts. Grund: Die Rechner im
lokalen Netz unterhalten sich ja direkt über die fake-Adressen im
192.168.123.xxx-Netz. Zum Beweis kannst Du Deine Linux-Kiste einfach
abschalten (naja OK, shutdown...), und die lokalen Rechner werden sich
weiter unterhalten können. Also wird da auch nix masqueraded.
Der Hintergrund: Masquerading ist eine FORWARD Rule im Firewall und
wird daher auch nur beim FORWARDEN (wörtlich zu nehmen: WEITERleiten)
verwendet.
Netz-intern wird nichts geforwarded und deshalb auch nichts
masqueraded, solange Du nur eine Netzwerkkarte hast. Bei mehreren
Karten hast Du jedoch recht: Hier sollte man entsprechende Routing-
und auch ipfwadm-Einträge vornehmen.
Antwort: Ist tatsächlich etwas ungenau; schaden tut es aber nix, es sei
denn, man will unbedingt nicht maskierbare Services benutzen.)
Das "Verstecken" des LAN vor dem Provider haben wir nun erreicht. Jetzt
gilt es, bei Bedarf einen automatischen Verbindungsaufbau zu erzwingen.
Dafür ist es zunächst nötig, die anderen Rechner im LAN dazu zu bringen,
alle für "Außerhalb" bestimmten IP-Pakete an den Linux-Router zu
übergeben und diesem die Weiterleitung zu überlassen. Nichts leichter als
das: Sowohl bei den verschiedenen Windows-Versionen, als auch beim AmiTCP
und beim MacTCP gibt es in der Konfiguration den Stichwort "Default-
Gateway" oder nur "Gateway". Hier ist die lokale IP-Adresse des
Routers einzutragen (denn die spätere Adresse, die vom Provider kommt, ist
ja erstens noch nicht bekannt und ändert sich zweitens bei jedem Anruf).
Letzter Schritt ist dann, das "dial-on-demand" einzurichten. In
Verbindung mit isdn4linux gibt es dafür zwei Möglichkeiten:
* Man verwendet synchrones PPP für die Verbindung zum Provider, also
den "ipppd". Dann ist nichts weiter zu tun als dafür zu sorgen, daß
immer die Default-Route des Routers auf das entsprechende ipppx-
Interface weist. Vorsicht: Beim Verbindungsabbau löscht der Kernel
diese Route!
Sie muß also z.B. in der Datei /etc/ppp/ip-down neu gesetzt werden.
Das Risiko bei diesem Verfahren sind Programme auf den LAN-Rechnern,
die mehr oder weniger regelmäßig Nameserver-Requests, Keepalive-
Pakete oder ARP-Broadcastings erzeugen - dann stellt nämlich der
Router jedesmal eine Verbindung zum Provider her. Die Telekom wird's
danken.
Übrigens kann es passieren, daß manche aus dem LAN initiierte
Verbindungen recht lange auf Antwort warten. Ich weiß nicht, ob
Kernel oder ipppd das "auslösende" Paket verschlucken, oder die
Antwort darauf unterschlagen; ich weiß aber, daß es hilft, z.B. bei
Netscape wenige Sekunden nach Anforderung der ersten Seite auf den
"roten Knopf" zu drücken und die Seite nochmals anzufordern.
Wie bereits erwähnt: Die Konfiguration des ipppd wird an anderer
Stelle ausführlich erklärt - siehe entsprechende Fragen sowie
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
* Benutzt man asynchrones ppp oder gar SLIP/CSLIP für die Verbindung
zum Provider, kann man das Programm "diald" [4] verwenden. Es bietet
zudem den Vorteil, extrem stark konfigurierbar zu sein; so kann man
z.B. festlegen, daß zwischen 0900 und 1200 grundsätzlich keine
Verbindung aufgebaut wird, daß Nameserver-Anfragen eine Verbindung
zwar nicht aufbauen, aber offenhalten können u.v.m. Wer sich mit
diesen Konfigurationsmöglichkeiten nicht herumschlagen mag, braucht
das indes auch nicht - die Default-Konfiguration kann man ohne
Gefahr für Leib und Geldbörse übernehmen :-)
So.
Wenn jetzt das Masquerading eingerichtet wurde,
wenn der Linux-Router auf allen LAN-Rechnern als Gateway eingetragen
wurde,
wenn ein "ping abc.edu", eingetippt auf der Console des Routers, eine
Verbindung zum Provider aufbaut,
dann sollte damit auch für alle Rechner im LAN der Weg ins Internet
frei sein.
Wie sieht der "PERL-Einzeiler" "modemd" nun genau aus?
Marc Neitzner <marc@zeus.han.de> schrieb dazu am 15. Dez 1996:
#!/usr/bin/perl
select((select(STDOUT), $| = 1)[$[]);
select((select(STDIN), $| = 1)[$[]);
exec "cu","-E","''", "-l", "$ARGV[0]";
die "$0: Cant exec cu: $!\n";
Und dann muss das Ding per inetd gestartet werden:
modem 20006/tcp modemd # Modem service via TCP
isdn 20007/tcp modemd # ISDN service via TCP
Nachteil: comt-2.0 ist nur für 16Bit Anwendungen "sichtbar". Der
Einsatz unter win95 und Windows NT bleibt also auch dort auf 16Bit Kram
beschränkt!
2.12 Isdnlog
- Wie kann ich isdnlog dazu bringen, mir die High Layer Compatibility
(Speech, Video,...) so anzuzeigen, wie ich es gerne hätte?
Gernot Zander <hifi@scorpio.in-berlin.de> postete am 6. Okt 1996 einen ent-
sprechenden Patch in der Mailingliste, der isdnlog besser anpaßt.
- Kann man in der Ausgabe von isdnrep die Dienstekennung eines eingehenden
Anrufes sehen?
Andreas Kool <akool@Kool.f.EUnet.de> schrieb hierzu am 3. Dez 1996:
Im isdnrep indirekt schon -- sofern du alle von isdnlog ausdekodierten
Dienstkennungen in deiner "isdnlog.conf" als Alias eingetragen hast ...
- Warum erfaßt isdnlog neben den Gebühren nicht auch die Telefonnummer, die
meine anderen ISDN-Geräte (z.B. ISDN-Telefon) anrufen?
Weil die ISDN-Karte wie alle ISDN-Geräte getrennte Sende- und
Empfangsleitungen (RX bzw. TX Leitung) hat. Isdnlog müßte die auf der
Sendeleitung übermittelten Daten belauschen, um die Telefonnummer zu
erfahren. Zumindestens bei der Teleskarte ist das jedoch nicht möglich, wie
Karsten Keil <keil@temic-ech.spacenet.de> am 12. Feb 1997 schrieb:
Das ist bei allen Karten mit 1 Siemens ISAC so, der hat (und braucht)
nur 1 Empfaenger und 1 Sender.
Theoretisch besteht eine Moeglichkeit, mit nur einem Empfaenger den
kompletten D-Kanal zu belauschen (das macht der ISAC sogar) und zwar
werden die auf der RX Leitung empfangenden D-Bits auf sogenannte Echo
Bits zeitversetzt auf die TX Leitung kopiert, darueber erfolgt die
Access Kontrolle (Kollisionserkennung) des S0 Busses.
Leider gibt es im ISAC im TA Mode keine Moeglichkeit die ECHO Bits aus
einem Register zu lesen.
Zu möglichen Lösungen siehe nächste Frage.
- Wie kann ich trotzdem isdnlog dazu bringen, die Telefonnummer auch von
anderen ISDN-Geräten mitzubekommen?
Es gibt zwei Möglichkeiten. Zum einen gibt es von der Deutschen Telekom die
kostenpflichtige Möglichkeit, alle Daten nochmal zurückschicken zu lassen
(COLP = Connected Line Identification Presentation, ca. DM 10,- pro Monat
je Basisanschluß). Diese kann isdnlog (>=2.52) dann wieder auf der TX
Leitung lesen.
Alternativ dazu wird isdnlog ab der nächsten Version (aktuell ist 2.52)
die Möglichkeit bieten, mit einer zweiten, "verpolten" Teles-Karte zu
arbeiten, bei der die RX Leitung an den TX Anschluß der Karte geführt wird.
Die RX Leitung der Karte darf an keine der Leitungen angeschlossen werden!
Aufgrund der Schaltung kann die Teles-Karte für keinen anderen Zweck mehr
eingesetzt werden. Das ganze sieht dann so aus:
B 3 -- RX+ 2a ---------------\
U 4 -- TX+ 1a -- offen ------------
S 5 -- TX- 1b -- offen ------------ Karte
6 -- RX- 2b ---------------/
Eine theoretische dritte Möglichkeit gibt es noch für alle, die eine
eigene TK-Anlage haben, über die sämtliche weiteren Geräte angeschlossen
sind. Falls diese Telefonanlage ebenfalls alle ausgehenden Telefonnummern
protokollieren kann, könnten diese ausgelesen werden (üblicherweise über
eine serielle Schnittstelle).
Es gibt jedoch einen Grund, warum isdnlog das nicht schon längst
unterstützt. Um die Daten zu verwerten, müßte isdnlog diese sofort beim
RELEASE COMPLETE zur Verfügung gestellt bekommen, bevor auf dem D-Kanal
neue Informationen übermittelt werden. Leider sind die bisher getesteten
Telefonanlagen dafür zu langsam (insbesondere die weit verbreitete ISTEC).
Als einzige Möglichkeit bleibt, die Daten nachträglich zu kombinieren.
Dabei kommt es aber zur Schwierigkeit, die unterschiedlichen Uhrzeiten
zu synchronisieren. Wer das realisieren möchte, ist dazu herzlich gerne
eingeladen (ich stelle auch gerne entsprechende Logs von meiner Ackermann
Euracom zur Verfügung - Matthias Heßler <hessler@wi-inf.uni-essen.de>).
- Erfaßt isdnlog auch die neuen Tarife der deutschen Telekom (City Weekend,
City Plus)?
Da die Vermittlungsstellen der Telekom das nicht hinbekommen, werden die
Gebühreninformationen nicht korrekt übermittelt. Die nächste Version von
isdnlog (>2.52) wird das jedoch können.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
niederländischen Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_NL" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
schweizer Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_CH" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich mir den Datendurchsatz grafisch anzeigen lassen?
Dazu gibt's "xisdnload". Clemens Perz <listperz@gwsnet.ttt.de> wußte am
6. Feb 1997 noch eine weitere Möglichkeit:
Ich hab auf der Sunsite ein kleines Tool Namens netload für die Console
gefunden und es auf ISDN-Interfaces angepasst. Damit kann man recht
einfach den momentanen Traffic auf der Leitung in Augenschein nehmen.
Zu finden auf:
ftp://ftp.region.trier.de/pub/unix/linux/sources/network/isdn/netload-0.92.isdn.tar.gz
Einfach starten mit netload isdnxx
2.13 Isdn der Provider auch kennt. Trägt z.B. der Router im
LAN die lokale IP-Adresse 192.168.1.1, und ein anderer Rechner die
192.168.1.2, dann kennt der Provider diese Adressen ja nicht. Er weist z.B.
dem PPP-Interface des Routers die Adresse 123.234.345.99 zu - und nur bei
Paketen aus dem Internet, die an diese Nummer adressiert sind, weiß er
auch, an wen er die Pakete schicken soll. Daher muß der Router Pakete von
anderen Rechnern im LAN "maskieren" - mit seiner eigenen, dynamisch
zugewiesenen Adresse (und dabei natürlich Buch darüber führen, was an
wen von wem kam, um die Antwort-Pakete richtig zuzustellen).
Zum Glück ist diese Funktion in den Linux-Kernel =>2.0.0 schon eingebaut
(s.o.) - sie nennt sich "IP-Masquerading". Vereinfacht ausgedrückt geht
das so:
Ein LAN-Rechner schickt ein Paket ab, das neben IP-Nummer und Ziel-Port des
Empfängers auch die "Absender-Adresse" in Form einer IP-Nummer und eines
Antwort-Ports trägt. Der maskierende Router nun ersetzt die Absender-IP
durch seine eigene und den Rücksende-Port durch einen freien aus seinem
Fundus. Unter dieser "freien" Portnummer werden die originalen Absender-
Daten gespeichert. Kommt nun ein Antwort-Paket aus dem Internet an diesen
Port, werden dessen Empfänger-Adresse und -Port mit der gespeicherten
Rücksende-Adresse überschrieben und an den LAN-Rechner weitergeleitet.
Paket für Paket.
Leicht einsehbar ist übrigens, daß dieses Verfahren nur mit Diensten
funktioniert, bei denen auch eine Rücksende-Adresse angegeben wird. Dazu
gehören u.a. telnet, http, ftp, irc (eingeschränkt), nicht aber Echo
(ping).
Zurück zur Praxis. Damit das Masquerading auch bei FTP und IRC
funktioniert, werden zunächst zwei Module geladen:
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
Dann werden die Forward-Rules des Kernel zum Masquerading gezwungen:
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b
Das Programm ipfwadm gibt es per Anonymous FTP unter:
ftp://ftp.xos.nl/pub/linux/ipfwadm/ipfwadm-2.3.0.tar.gz
In diesem Beispiel werden im LAN die IP-Adressen 192.168.123.1 bis
192.168.123.254 benutzt. Legen wir zur Vereinfachung fest, der Linux-Router
habe dabei die Adresse 192.168.123.1.
Obige Zeile bewirkt, daß IP-Pakete, die von 192.168.123.x ausgehen und
an wenauchimmer gerichtet sind, maskiert werden. Das hat den Nachteil, daß
auch innerhalb des LAN fleißig drauflosmaskiert wird, was man aber durch
Einfügen weiterer Rules vermeiden kann. "man ipfwadm" sei hier zur Lektüre
empfohlen.
(Hinweis von Ralf Rudolph <ralf@artifex.de> hierzu:
Hmm. So wie ich das sehe, passiert da gar nichts. Grund: Die Rechner im
lokalen Netz unterhalten sich ja direkt über die fake-Adressen im
192.168.123.xxx-Netz. Zum Beweis kannst Du Deine Linux-Kiste einfach
abschalten (naja OK, shutdown...), und die lokalen Rechner werden sich
weiter unterhalten können. Also wird da auch nix masqueraded.
Der Hintergrund: Masquerading ist eine FORWARD Rule im Firewall und
wird daher auch nur beim FORWARDEN (wörtlich zu nehmen: WEITERleiten)
verwendet.
Netz-intern wird nichts geforwarded und deshalb auch nichts
masqueraded, solange Du nur eine Netzwerkkarte hast. Bei mehreren
Karten hast Du jedoch recht: Hier sollte man entsprechende Routing-
und auch ipfwadm-Einträge vornehmen.
Antwort: Ist tatsächlich etwas ungenau; schaden tut es aber nix, es sei
denn, man will unbedingt nicht maskierbare Services benutzen.)
Das "Verstecken" des LAN vor dem Provider haben wir nun erreicht. Jetzt
gilt es, bei Bedarf einen automatischen Verbindungsaufbau zu erzwingen.
Dafür ist es zunächst nötig, die anderen Rechner im LAN dazu zu bringen,
alle für "Außerhalb" bestimmten IP-Pakete an den Linux-Router zu
übergeben und diesem die Weiterleitung zu überlassen. Nichts leichter als
das: Sowohl bei den verschiedenen Windows-Versionen, als auch beim AmiTCP
und beim MacTCP gibt es in der Konfiguration den Stichwort "Default-
Gateway" oder nur "Gateway". Hier ist die lokale IP-Adresse des
Routers einzutragen (denn die spätere Adresse, die vom Provider kommt, ist
ja erstens noch nicht bekannt und ändert sich zweitens bei jedem Anruf).
Letzter Schritt ist dann, das "dial-on-demand" einzurichten. In
Verbindung mit isdn4linux gibt es dafür zwei Möglichkeiten:
* Man verwendet synchrones PPP für die Verbindung zum Provider, also
den "ipppd". Dann ist nichts weiter zu tun als dafür zu sorgen, daß
immer die Default-Route des Routers auf das entsprechende ipppx-
Interface weist. Vorsicht: Beim Verbindungsabbau löscht der Kernel
diese Route!
Sie muß also z.B. in der Datei /etc/ppp/ip-down neu gesetzt werden.
Das Risiko bei diesem Verfahren sind Programme auf den LAN-Rechnern,
die mehr oder weniger regelmäßig Nameserver-Requests, Keepalive-
Pakete oder ARP-Broadcastings erzeugen - dann stellt nämlich der
Router jedesmal eine Verbindung zum Provider her. Die Telekom wird's
danken.
Übrigens kann es passieren, daß manche aus dem LAN initiierte
Verbindungen recht lange auf Antwort warten. Ich weiß nicht, ob
Kernel oder ipppd das "auslösende" Paket verschlucken, oder die
Antwort darauf unterschlagen; ich weiß aber, daß es hilft, z.B. bei
Netscape wenige Sekunden nach Anforderung der ersten Seite auf den
"roten Knopf" zu drücken und die Seite nochmals anzufordern.
Wie bereits erwähnt: Die Konfiguration des ipppd wird an anderer
Stelle ausführlich erklärt - siehe entsprechende Fragen sowie
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
* Benutzt man asynchrones ppp oder gar SLIP/CSLIP für die Verbindung
zum Provider, kann man das Programm "diald" [4] verwenden. Es bietet
zudem den Vorteil, extrem stark konfigurierbar zu sein; so kann man
z.B. festlegen, daß zwischen 0900 und 1200 grundsätzlich keine
Verbindung aufgebaut wird, daß Nameserver-Anfragen eine Verbindung
zwar nicht aufbauen, aber offenhalten können u.v.m. Wer sich mit
diesen Konfigurationsmöglichkeiten nicht herumschlagen mag, braucht
das indes auch nicht - die Default-Konfiguration kann man ohne
Gefahr für Leib und Geldbörse übernehmen :-)
So.
Wenn jetzt das Masquerading eingerichtet wurde,
wenn der Linux-Router auf allen LAN-Rechnern als Gateway eingetragen
wurde,
wenn ein "ping abc.edu", eingetippt auf der Console des Routers, eine
Verbindung zum Provider aufbaut,
dann sollte damit auch für alle Rechner im LAN der Weg ins Internet
frei sein.
Wie sieht der "PERL-Einzeiler" "modemd" nun genau aus?
Marc Neitzner <marc@zeus.han.de> schrieb dazu am 15. Dez 1996:
#!/usr/bin/perl
select((select(STDOUT), $| = 1)[$[]);
select((select(STDIN), $| = 1)[$[]);
exec "cu","-E","''", "-l", "$ARGV[0]";
die "$0: Cant exec cu: $!\n";
Und dann muss das Ding per inetd gestartet werden:
modem 20006/tcp modemd # Modem service via TCP
isdn 20007/tcp modemd # ISDN service via TCP
Nachteil: comt-2.0 ist nur für 16Bit Anwendungen "sichtbar". Der
Einsatz unter win95 und Windows NT bleibt also auch dort auf 16Bit Kram
beschränkt!
2.12 Isdnlog
- Wie kann ich isdnlog dazu bringen, mir die High Layer Compatibility
(Speech, Video,...) so anzuzeigen, wie ich es gerne hätte?
Gernot Zander <hifi@scorpio.in-berlin.de> postete am 6. Okt 1996 einen ent-
sprechenden Patch in der Mailingliste, der isdnlog besser anpaßt.
- Kann man in der Ausgabe von isdnrep die Dienstekennung eines eingehenden
Anrufes sehen?
Andreas Kool <akool@Kool.f.EUnet.de> schrieb hierzu am 3. Dez 1996:
Im isdnrep indirekt schon -- sofern du alle von isdnlog ausdekodierten
Dienstkennungen in deiner "isdnlog.conf" als Alias eingetragen hast ...
- Warum erfaßt isdnlog neben den Gebühren nicht auch die Telefonnummer, die
meine anderen ISDN-Geräte (z.B. ISDN-Telefon) anrufen?
Weil die ISDN-Karte wie alle ISDN-Geräte getrennte Sende- und
Empfangsleitungen (RX bzw. TX Leitung) hat. Isdnlog müßte die auf der
Sendeleitung übermittelten Daten belauschen, um die Telefonnummer zu
erfahren. Zumindestens bei der Teleskarte ist das jedoch nicht möglich, wie
Karsten Keil <keil@temic-ech.spacenet.de> am 12. Feb 1997 schrieb:
Das ist bei allen Karten mit 1 Siemens ISAC so, der hat (und braucht)
nur 1 Empfaenger und 1 Sender.
Theoretisch besteht eine Moeglichkeit, mit nur einem Empfaenger den
kompletten D-Kanal zu belauschen (das macht der ISAC sogar) und zwar
werden die auf der RX Leitung empfangenden D-Bits auf sogenannte Echo
Bits zeitversetzt auf die TX Leitung kopiert, darueber erfolgt die
Access Kontrolle (Kollisionserkennung) des S0 Busses.
Leider gibt es im ISAC im TA Mode keine Moeglichkeit die ECHO Bits aus
einem Register zu lesen.
Zu möglichen Lösungen siehe nächste Frage.
- Wie kann ich trotzdem isdnlog dazu bringen, die Telefonnummer auch von
anderen ISDN-Geräten mitzubekommen?
Es gibt zwei Möglichkeiten. Zum einen gibt es von der Deutschen Telekom die
kostenpflichtige Möglichkeit, alle Daten nochmal zurückschicken zu lassen
(COLP = Connected Line Identification Presentation, ca. DM 10,- pro Monat
je Basisanschluß). Diese kann isdnlog (>=2.52) dann wieder auf der TX
Leitung lesen.
Alternativ dazu wird isdnlog ab der nächsten Version (aktuell ist 2.52)
die Möglichkeit bieten, mit einer zweiten, "verpolten" Teles-Karte zu
arbeiten, bei der die RX Leitung an den TX Anschluß der Karte geführt wird.
Die RX Leitung der Karte darf an keine der Leitungen angeschlossen werden!
Aufgrund der Schaltung kann die Teles-Karte für keinen anderen Zweck mehr
eingesetzt werden. Das ganze sieht dann so aus:
B 3 -- RX+ 2a ---------------\
U 4 -- TX+ 1a -- offen ------------
S 5 -- TX- 1b -- offen ------------ Karte
6 -- RX- 2b ---------------/
Eine theoretische dritte Möglichkeit gibt es noch für alle, die eine
eigene TK-Anlage haben, über die sämtliche weiteren Geräte angeschlossen
sind. Falls diese Telefonanlage ebenfalls alle ausgehenden Telefonnummern
protokollieren kann, könnten diese ausgelesen werden (üblicherweise über
eine serielle Schnittstelle).
Es gibt jedoch einen Grund, warum isdnlog das nicht schon längst
unterstützt. Um die Daten zu verwerten, müßte isdnlog diese sofort beim
RELEASE COMPLETE zur Verfügung gestellt bekommen, bevor auf dem D-Kanal
neue Informationen übermittelt werden. Leider sind die bisher getesteten
Telefonanlagen dafür zu langsam (insbesondere die weit verbreitete ISTEC).
Als einzige Möglichkeit bleibt, die Daten nachträglich zu kombinieren.
Dabei kommt es aber zur Schwierigkeit, die unterschiedlichen Uhrzeiten
zu synchronisieren. Wer das realisieren möchte, ist dazu herzlich gerne
eingeladen (ich stelle auch gerne entsprechende Logs von meiner Ackermann
Euracom zur Verfügung - Matthias Heßler <hessler@wi-inf.uni-essen.de>).
- Erfaßt isdnlog auch die neuen Tarife der deutschen Telekom (City Weekend,
City Plus)?
Da die Vermittlungsstellen der Telekom das nicht hinbekommen, werden die
Gebühreninformationen nicht korrekt übermittelt. Die nächste Version von
isdnlog (>2.52) wird das jedoch können.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
niederländischen Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_NL" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich isdnlog dazu bringen, die Gebühren nach den Regeln der
schweizer Telefongesellschaft zu berechnen?
Dazu muß nur im Makefile von isdnlog "COPTS=-DISDN_CH" gesetzt und isdnlog
neu kompiliert werden.
- Wie kann ich mir den Datendurchsatz grafisch anzeigen lassen?
Dazu gibt's "xisdnload". Clemens Perz <listperz@gwsnet.ttt.de> wußte am
6. Feb 1997 noch eine weitere Möglichkeit:
Ich hab auf der Sunsite ein kleines Tool Namens netload für die Console
gefunden und es auf ISDN-Interfaces angepasst. Damit kann man recht
einfach den momentanen Traffic auf der Leitung in Augenschein nehmen.
Zu finden auf:
ftp://ftp.region.trier.de/pub/unix/linux/sources/network/isdn/netload-0.92.isdn.tar.gz
Einfach starten mit netload isdnxx
2.13 Isdn der Provider auch kennt. Trägt z.B. der Router im
LAN die lokale IP-Adresse 192.168.1.1, und ein anderer Rechner die
192.168.1.2, dann kennt der Provider diese Adressen ja nicht. Er weist z.B.
dem PPP-Interface des Routers die Adresse 123.234.345.99 zu - und nur bei
Paketen aus dem Internet, die an diese Nummer adressiert sind, weiß er
auch, an wen er die Pakete schicken soll. Daher muß der Router Pakete von
anderen Rechnern im LAN "maskieren" - mit seiner eigenen, dynamisch
zugewiesenen Adresse (und dabei natürlich Buch darüber führen, was an
wen von wem kam, um die Antwort-Pakete richtig zuzustellen).
Zum Glück ist diese Funktion in den Linux-Kernel =>2.0.0 schon eingebaut
(s.o.) - sie nennt sich "IP-Masquerading". Vereinfacht ausgedrückt geht
das so:
Ein LAN-Rechner schickt ein Paket ab, das neben IP-Nummer und Ziel-Port des
Empfängers auch die "Absender-Adresse" in Form einer IP-Nummer und eines
Antwort-Ports trägt. Der maskierende Router nun ersetzt die Absender-IP
durch seine eigene und den Rücksende-Port durch einen freien aus seinem
Fundus. Unter dieser "freien" Portnummer werden die originalen Absender-
Daten gespeichert. Kommt nun ein Antwort-Paket aus dem Internet an diesen
Port, werden dessen Empfänger-Adresse und -Port mit der gespeicherten
Rücksende-Adresse überschrieben und an den LAN-Rechner weitergeleitet.
Paket für Paket.
Leicht einsehbar ist übrigens, daß dieses Verfahren nur mit Diensten
funktioniert, bei denen auch eine Rücksende-Adresse angegeben wird. Dazu
gehören u.a. telnet, http, ftp, irc (eingeschränkt), nicht aber Echo
(ping).
Zurück zur Praxis. Damit das Masquerading auch bei FTP und IRC
funktioniert, werden zunächst zwei Module geladen:
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
Dann werden die Forward-Rules des Kernel zum Masquerading gezwungen:
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b
Das Programm ipfwadm gibt es per Anonymous FTP unter:
ftp://ftp.xos.nl/pub/linux/ipfwadm/ipfwadm-2.3.0.tar.gz
In diesem Beispiel werden im LAN die IP-Adressen 192.168.123.1 bis
192.168.123.254 benutzt. Legen wir zur Vereinfachung fest, der Linux-Router
habe dabei die Adresse 192.168.123.1.
Obige Zeile bewirkt, daß IP-Pakete, die von 192.168.123.x ausgehen und
an wenauchimmer gerichtet sind, maskiert werden. Das hat den Nachteil, daß
auch innerhalb des LAN fleißig drauflosmaskiert wird, was man aber durch
Einfügen weiterer Rules vermeiden kann. "man ipfwadm" sei hier zur Lektüre
empfohlen.
(Hinweis von Ralf Rudolph <ralf@artifex.de> hierzu:
Hmm. So wie ich das sehe, passiert da gar nichts. Grund: Die Rechner im
lokalen Netz unterhalten sich ja direkt über die fake-Adressen im
192.168.123.xxx-Netz. Zum Beweis kannst Du Deine Linux-Kiste einfach
abschalten (naja OK, shutdown...), und die lokalen Rechner werden sich
weiter unterhalten können. Also wird da auch nix masqueraded.
Der Hintergrund: Masquerading ist eine FORWARD Rule im Firewall und
wird daher auch nur beim FORWARDEN (wörtlich zu nehmen: WEITERleiten)
verwendet.
Netz-intern wird nichts geforwarded und deshalb auch nichts
masqueraded, solange Du nur eine Netzwerkkarte hast. Bei mehreren
Karten hast Du jedoch recht: Hier sollte man entsprechende Routing-
und auch ipfwadm-Einträge vornehmen.
Antwort: Ist tatsächlich etwas ungenau; schaden tut es aber nix, es sei
denn, man will unbedingt nicht maskierbare Services benutzen.)
Das "Verstecken" des LAN vor dem Provider haben wir nun erreicht. Jetzt
gilt es, bei Bedarf einen automatischen Verbindungsaufbau zu erzwingen.
Dafür ist es zunächst nötig, die anderen Rechner im LAN dazu zu bringen,
alle für "Außerhalb" bestimmten IP-Pakete an den Linux-Router zu
übergeben und diesem die Weiterleitung zu überlassen. Nichts leichter als
das: Sowohl bei den verschiedenen Windows-Versionen, als auch beim AmiTCP
und beim MacTCP gibt es in der Konfiguration den Stichwort "Default-
Gateway" oder nur "Gateway". Hier ist die lokale IP-Adresse des
Routers einzutragen (denn die spätere Adresse, die vom Provider kommt, ist
ja erstens noch nicht bekannt und ändert sich zweitens bei jedem Anruf).
Letzter Schritt ist dann, das "dial-on-demand" einzurichten. In
Verbindung mit isdn4linux gibt es dafür zwei Möglichkeiten:
* Man verwendet synchrones PPP für die Verbindung zum Provider, also
den "ipppd". Dann ist nichts weiter zu tun als dafür zu sorgen, daß
immer die Default-Route des Routers auf das entsprechende ipppx-
Interface weist. Vorsicht: Beim Verbindungsabbau löscht der Kernel
diese Route!
Sie muß also z.B. in der Datei /etc/ppp/ip-down neu gesetzt werden.
Das Risiko bei diesem Verfahren sind Programme auf den LAN-Rechnern,
die mehr oder weniger regelmäßig Nameserver-Requests, Keepalive-
Pakete oder ARP-Broadcastings erzeugen - dann stellt nämlich der
Router jedesmal eine Verbindung zum Provider her. Die Telekom wird's
danken.
Übrigens kann es passieren, daß manche aus dem LAN initiierte
Verbindungen recht lange auf Antwort warten. Ich weiß nicht, ob
Kernel oder ipppd das "auslösende" Paket verschlucken, oder die
Antwort darauf unterschlagen; ich weiß aber, daß es hilft, z.B. bei
Netscape wenige Sekunden nach Anforderung der ersten Seite auf den
"roten Knopf" zu drücken und die Seite nochmals anzufordern.
Wie bereits erwähnt: Die Konfiguration des ipppd wird an anderer
Stelle ausführlich erklärt - siehe entsprechende Fragen sowie
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
* Benutzt man asynchrones ppp oder gar SLIP/CSLIP für die Verbindung
zum Provider, kann man das Programm "diald" [4] verwenden. Es bietet
zudem den Vorteil, extrem stark konfigurierbar zu sein; so kann man
z.B. festlegen, daß zwischen 0900 und 1200 grundsätzlich keine
Verbindung aufgebaut wird, daß Nameserver-Anfragen eine Verbindung
zwar nicht aufbauen, aber offenhalten können u.v.m. Wer sich mit
diesen Konfigurationsmöglichkeiten nicht herumschlagen mag, braucht
das indes auch nicht - die Default-Konfiguration kann man ohne
Gefahr für Leib und Geldbörse übernehmen :-)
So.
Wenn jetzt das Masquerading eingerichtet wurde,
wenn der Linux-Router auf allen LAN-Rechnern als Gateway eingetragen
wurde,
wenn ein "ping abc.edu", eingetippt auf der Console des Routers, eine
Verbindung zum Provider aufbaut,
dann sollte damit auch für alle Rechner im LAN der Weg ins Internet
frei sein.