7.1 Automatisierung

Nachdem für den ersten Zugang nun alles soweit funktioniert hat, soll das System nun dahingehend konfiguriert werden, dass der T-DSL via Satellit-Dienst auch im täglichen Gebrauch verwendet werden kann. Dabei ist zu beachten, dass die auf der vorherigen Seite beschriebenen Aktionen vom Laden der Treiber bis zum Starten des Proxy (Abschnitte 5.2 bis 5.6) bzw. dem Aufbau des VPN-Tunnels (siehe Kapitel 6)vor der Benutzung durchgeführt werden müssen. Der Verbindungstests aus Abschnitt 5.5 bzw. Abschnitt 6.7 kann dabei natürlich ausgelassen werden. Grundsätzlich gibt es zwei Möglichkeiten, wo diese Schritte ausgeführt werden können und es hängt stark von der persönlichen Handhabung des Systems und der Verwendung der DVB-Karte ab, welche der Alternativen nun bevorzugt werden sollte.

7.2 Zugang mit ISDN - Dial on Demand

Es ist grundsätzlich möglich, Linux so zu konfigurieren, dass die Einwahl in's Internet automatisch erfolgt, sobald ein externer Rechner angesprochen wird. Dieses Vorgehen nennt sich "Dial on Demand (DoD)" und ist vor allem für ISDN-Verbindungen geeignet, da hier der Verbindungsaufbau sehr schnell geht. Prinzipiell läuft DoD so ab, daß im Routing eine Defaultroute festgelegt wird, die auf das ISDN-Device zeigt und somit alle Requests an IP-Adressen, die nicht in eine der vorstehenden Routen passen, einen Verbindungsaufbau über das ISDN-Device generieren. Sollten über einen definierbaren Zeitraum dann keine Datenpakete mehr transferiert werden, wird die Verbindung auch automatisch wieder abgebaut. Ein solches Vorgehen hat natürlich einen hohen Bequemlichkeitslevel, weil man ja quasi eine virtuelle Standleitung zur Verfügung hat. Allerdings muß das System auch äußerst genau eingerichtet sein, damit nicht durch Hintergrundprozesse oder Ähnliches unnötige und kostenpflichtige Verbindungen aufgebaut werden. Nähere Infos zu diesem Thema gibt es im ISDN-HowTo von Klaus Franken. Leider stellt der Tellique-Proxy bei eingeschaltetem DoD in seiner Default-Einstellung alle paar Minuten eine Verbindung in's Internet her. Dies liegt an dem Announcement-Channel, auf dem Daten asyncron über den Satelliten übertragen werden können. Diese Funktionalität ist derzeit unter Linux jedoch nicht nutzbar, daher kann man diesen Dienst getrost abstellen. Am einfachsten umzusetzen ist dies durch eine Änderung der Datei license.ini, die sich im Verzeichnis des Tellique-Proxy befindet. Dazu öffnet man die besagte Datei mit dem persönlichen Lieblings-Editor und ändert die Zeile

Client/TelliCast=on

in

Client/TelliCast=off

Nach dem Neustart des Proxy werden keine eigenständigen Verbindungen mehr durch den Proxy aufgebaut. Ein weiterer Punkt im Zusammenspiel zwischen ISDN/DoD und T-DSL via Satellit wurde schon im vorhergehenden Abschnitt 7.1.2 angesprochen: Der Proxy muß permanent geladen sein, damit die HTTP- und FTP-Requests überhaupt zu einem Verbindungsaufbau führen. Ist der Proxy nicht geladen, erhält das Anwendungsprogramm eine Fehlermeldung. Für den VPN-Zugang treffen diese beiden proxy-spezifischen Punkte nicht zu, dafür gibt es dort aber andere DoD-relevanten Probleme. So dauert der Verbindungsaufbau etwas länger als gewohnt, weil neben der primären Wählverbindung ja noch die zweite ppp-Verbindung für den VPN-Tunnel etabliert werden muß. Dies kann sich vor allem dann negativ bemerkbar machen, wenn man einen relativ kurzen Timeout definiert hat, nachdem die Verbindung wieder abgebaut werden soll und somit innerhalb einer Surf-Session des öfteren die Verbindung aufgebaut und wieder gekappt wird. In diesem Falle hilft es nur, den Timeout heraufzusetzen oder aber die Verzögerungen in Kauf zu nehmen. Desweiteren werden die Pakete des Requests, der den Verbindungaufbau initiiert, gar nicht über den Satelliten geroutet und somit auch nicht beschleunigt. Grund hierfür ist, dass beim Versand des Requests die Default-Route noch auf das primäre ppp-Device zeigte und das Routing für die VPN-Verbindung erst im nachhinein verändert wurde. Der erste Request bekommt von dieser Änderung nichts mehr mit und wird über das primäre Device beantwortet. Sofern dieser erste Request lediglich der Aufruf einer Internet-Seiteoder ein DNS-Request war, ist die Sache noch zu verschmerzen. Wer jedoch sofort mit einem FTP-Download einer großen Datei die Verbindung aufbaut, wird über den gesamten Download-Vorgang nicht über die Geschwindigkeit der normalen Wählverbindung hinauskommen. Abhilfe schafft hier ein vorgeschalteter Ping, etwa in der Art:

Ich persönlich habe mein System mit ISDN/DoD konfiguriert und habe bis auf die geschilderten Kleinigkeiten weder mit dem Proxy noch mit dem VPN irgendwelche negative Erfahrungen damit gemacht.

7.3 Einsatz im Netzwerk

Viele Linux-Nutzer haben nicht nur einen Computer, sondern gleich ein kleines oder größeres Netzwerk aufgebaut, bei dem ein Rechner die Funktion eines Routers in's Internet übernimmt und für den Verbindungsaufbau sorgt. Für diese Konstellationen ist es natürlich wünschenswert, auch den Client-Rechnern im Netzwerk den Vorteil der Satellitenbeschleunigung zu gewähren. Unter Verwendung des Tellique-Proxies und solange die DVB-Karte und das Verbindungsgerät (ISDN-Karte, Modem o.ä.) für die herkömmliche Internet-Verbindung in einem Rechner stecken, ist dies relativ einfach möglich, indem man bei den Anwendungsprogrammen (Browser, FTP-Client, Filesharing-Clients) entsprechend der im Abschnitt 5.7 aufgezeigten Vorgehensweise die Proxy-Einstellungen einträgt. Dabei muß allerdings für alle Clients die Loopback-Adresse 127.0.0.1 durch die IP-Adresse des Routers ersetzt werden. Problematisch wird die Sache erst, wenn die DVB-Karte in einem anderen Rechner steckt, als demjenigen, über den die Internet-Verbindung aufgebaut wird - vor allem in Verbindung mit ISDN Dial-on-Demand und kurzen Timeouts. Über den Tellique-Proxy sieht der Verbindungsaufbau mit DoD und Satellitenzugriff normalerweise so aus, dass bei einer Anforderung von Daten eines externen Rechners das erste Datenpaket über den Proxy die ISDN-Verbindung herstellt, der Tellique-Proxy die Verbindung mit den Proxy-Servern aufnimmt und eine IP-Adresse aushandelt, anhand deren der Multicast-Filter gesetzt wird. Danach können die Daten mit Satellitenbeschleunigung empfangen werden. Der Multicast-Filter wird wieder entfernt, wenn entweder über einen längeren Zeitraum keine Datenpakete mehr empfangen werden oder die ISDN-Verbindung abgebaut wird. Wenn die ISDN-Verbindung über einen anderen Rechner aufgebaut wird, und diese aufgrund eines sehr kurzen Timeout-Wertes ( <= 30 Sekunden) vor dem automatischen Abbau des MC-Filters wegen Inaktivität wieder beendet wird, bleibt der gesetzte MC-Filter bestehen. Beim nächsten Internet-Zugriff verhindert der noch bestehende Filter dann, dass ein neuer MC-Filter gesetzt wird. Da sich aber die ausgehandelte IP-Adresse zwischenzeitlich geändert hat, gehen die angeforderten Daten in's Leere und nach einer gewissen Zeit meldet der Proxy-Client ein "Bad Gateway". "Glücklicherweise" wird dabei dann der falsche MC-Filter entfernt, weshalb der nächste Zugriff dann wieder erfolgreich ist. Der bevorzugte Workaround für dieses Problem wäre, beide Devices (DVB- und ISDN-Karte) in einen Rechner zu stecken. Wenn dieses aber aus räumlichen Gründen nicht möglich ist, bleibt noch die Möglichkeit, den Verbindungsaufbau manuell zu triggern und auch wieder abzubauen, allerdings darf letzteres erst geschehen, wenn der MC-Filter automatisch entfernt wurde. Denkbar wäre es auch, im /etc/ppp/ip-down Skript einen entsprechenden Aufruf einzubauen, der remote auf dem Rechner mit dem DVB-Device den Multicast-Filter entfernt. Dies ist allerdings eine Aufgabe für Scripting- und Netzwerk-Spezialisten und übersteigt meine Kenntnisse auf diesen Gebieten. Ich wollte hier nur auf die theoretische Möglichkeit hinweisen. Für den VPN-Zugang spielt es allerdings keine Rolle, ob DVB- und ppp-Device in einem oder mehreren Rechner stecken. Entscheidend für Auf- und Abbau der Verbindung ist einzig das ppp-Device. Allerdings dürfte das Routing etwas komplizierter Ausfallen, wenn der Verbindungsrechner nicht mit dem DVB-Rechner identisch ist. Für den Einsatz des VPN-Zugangs in einem Netzwerk empfiehlt es sich, zusätzlich einen Proxy auf dem Verbindungsrechner aufzusetzen, den man in ähnlicher Weise wie den Tellique-Proxy in den Browsern der Client-Maschinen angibt. Jeder beliebige Proxy ist dazu geeignet (z.B. squid). Theoretisch bestünde auch noch die Möglichkeit, ohne Proxy mit Masquerading die Verbindung der Clients in's Internet zu realisieren, allerdings bin ich mir nicht sicher, ob dies tatsächlich funktioniert. Ich habe den VPN-Zugang vom Client aus lediglich über squid ausprobiert und es funktionierte hervorragend.

7.4 Bugs und Einschränkungen

Während der Pilotphase des Dienstes haben sich einige Schwachstellen der momentanen Implementierung unter Linux gezeigt, die ganz unterschiedliche Gründe haben. Ich habe hier alle Probleme und Einschränkungen aufgelistet, von denen ich bis zum jetzigen Zeitpunkt Kenntnis erhalten habe und versucht, deren momentanen Status zu dokumentieren. Die Liste erhebt keinen Anspruch auf Vollständigkeit oder permanente Aktualität.

Systemstillstände oder Reboots bei DVB-s Karten

Es scheint noch ein Problem in den Treibern mit dem Multicast-Support für die vollwertigen DVB-s Karten mit MPEG2-Decoder on board zu geben. Mehrere Teilnehmer des Pilotprojekts haben berichtet, dass das System entweder einfach stehen bleibt oder selbstständig einen Reboot durchführt. Mit den budget-Karten (ohne MPEG-Decoder) ist dieses Verhalten noch nicht aufgetaucht. Außerdem beschränkt sich das Problem nur auf die Proxy-Lösung, der VPN-Zugang funktioniert einwandfrei.

Status: unklar. Soweit ich weiß, wird derzeit das Problem in Zusammenarbeit mit den Treiberentwicklern analysiert.

Lösung/Workaround: Statt des Tellique-Proxy den VPN-Zugang verwenden. Statt einer DVB-s Karte eine budget-Karte (TT Budget PCI oder WinTV nova) einsetzen. ;-) Aktuelle Entwicklung verfolgen und immer neueste Treiberversionen verwenden. Infos zu dem Thema gibts im Webforum von  www.ipviasky.net oder in der Linux-DVB-Mailingliste.

periodischer Verbindungsaufbau durch den Proxy

Dieses Problem ist schon im Abschnitt 7.2 beschrieben worden. Der Verbindungsaufbau wird bei aktiviertem Announcement-Channel durchgeführt.

Status: gelöst

Lösung/Workaround: siehe Abschnitt 7.2

"Bad Gateway"-Meldung bei jedem zweiten Verbindungsversuch

Dieses Problem ist ebenfalls schon im Abschnitt 7.3 beschrieben worden. Bei der Verwendung von ISDN/DoD und Einwahl in's Internet über einen anderen Rechner sowie sehr kurzer Timeout-Einstellung, wird der Mulitcast-Filter nicht wieder abgebaut und verhindert den Datenempfang beim nächsten Verbindungsversuch.

Status: gelöst

Lösung/Workaround: siehe Abschnitt 7.3

Probleme bei Nutzung von wget

Carsten Koch hat bei seinen Tests mit dem Tellique-Proxy festgestellt, dass dieser nicht 100% transparent ist. Bei der Nutzung von wget zum Download eines ganzen FTP-Verzeichnisses verändert der Proxy wohl das Verzeichnislisting so, dass wget damit nichts mehr anfangen kann. Nähere Infos dazu gibt's im Webforum von IPviaSky.net im Thread Tellique Proxy 1.0 funktioniert nicht zusammen mit wget. Ein weiteres Problem in diesem Zusammenhang scheint die Tatsache zu sein, dass der Tellique-Proxy die Timestamps der übertragenen Dateien nicht mitliefert. Dadurch ist kein echtes Mirroring möglich, bei dem nur veränderte Dateien übertragen werden sollen und die Timestamps auf Original und Mirror identisch sein sollten.

Status: das Problem wurde an die Entwickler von Tellique weitergeleitet. Bislang ist noch keine Stellungnahme dazu publik geworden.

Lösung/Workaround: Statt des Tellique-Proxy den VPN-Zugang verwenden. Warten auf neue Proxy-Version... ;-)

Fehlermeldung "unresolved symbol kmappagetabble" beim Laden der Treiber

Beim Laden der Treiber erscheint oben stehende Fehlermeldung. Vermutlich verwenden Sie einen erweiterten Kernel mit "User-highmem-Support".

Status: gelöst

Lösung/Workaround: Fügen Sie in die Datei saa7146core.c im DVB-Treiber-Verzeichnis die folgende Zeile unmittelbar unter der Anweisung "#include <linux/vmalloc.h>" ein: #include <linux/highmem.h> / fix for the unresolved symbol / Danke an Dirk Wellmann für den Hinweis.

Alles funktioniert, aber keine Beschleunigung

Sie haben alles korrekt konfiguriert und nach Anleitung durchgeführt. Sie erhalten keinerlei Fehlermeldungen und dennoch bleibt die Download-Geschwindigkeit sogar weit hinter ISDN-Niveau zurück. Dieses Problem hatte ich nach der Pilotphase auch, als der Regelbetrieb über neue Proxyserver lief (212.56.240.36 - .39). Über die alten Pilotserver mit anderen IP-Adressen funktionierte die Beschleunigung wunderbar, aber mit den neuen Servern wurde der Datentransfer sogar eher noch gebremst als beschleunigt. Der Grund dafür war bei mir die SuSE-personalFirewall aus der Distribution SuSE 7.3. In dieser Firewall muß irgendeine Regel enthalten sein, die dafür sorgte, daß die Datenpakete von den neuen Servern kommentarlos gedropt wurden. Nachdem ich das Problem lokalisiert hatte, stellte ich fest, dass es auch nicht ausreicht, die Firewall weiter zu öffnen, sondern mußte Sie komplett deinstallieren. Dirk Vornheder berichtete mir kürzlich auch davon, dass er die gleichen Erfahrungen auch mit der SuSEfirewall2 aus der SuSE 8.0-Distribution gemacht hat.

Status: gelöst

Lösung/Workaround: Vermeiden Sie die Benutzung der SuSE-personalFirewall und der SuSEfirewall2. Nutzen Sie statt dessen eigene iptables-Lösungen oder andere Firewalls, die Ihnen zumindest mitteilen, dass Pakete gedropt werden, damit man einen Anhaltspunkt zur Recherche hat.

Keine Beschleunigung beim EMail-Verkehrr

Wer darauf gehofft hat, nun auch beim Abholen seiner umfangreichen EMails eine schnellere Performance zu erhalten, wird zunächst enttäuscht sein. Die Beschleunigung über den Satelliten bezieht sich nur auf den HTTP- und FTP-Transfer. IMAP, POP3 unterstützen keine Proxy-Verbindungen und kommen daher für eine Beschleunigung ohne weiteres nicht in Frage. Implizit gilt diese Einschränkung für alle Programme/Dienste, die keine Proxy-Unterstützung haben.

Status: works as designed. Es gibt aber Umgehungsmöglichkeiten

Lösung/Workaround: - T-DSL via Satellit über alternative VPN-Verbindung nutzen

-Webmailer benutzen, der Übertragung per HTTP durchführt

- MUA/MTA entwickeln, der Proxy-Support hat. ;-)

- Port-Forwarding in der recv.ini des Tellique-Proxies angeben. In einem FAQ-Beitrag auf  www.ipviasky.com wird beschrieben, welche Einträge man dafür in der recv.ini des Proxy vornehmen muß. Ich selbst habe diese Alternative noch nicht getestet und kann daher nicht sagen, ob sie funktioniert. Sie haben den VPN-Zugang eingerichtet und nutzen Dial-on-Demand für Ihre Wählverbindung. Beim ersten Zugriff auf das Internet erhalten Sie keine Beschleunigung, obwohl der VPN- Tunnel korrekt aufgebaut wird. Nachfolgende Requests werden allerdings voll beschleunigt. Der Grund liegt im Routing zum Zeitpunkt des ersten Requests, der den Aufbau der Wählverbindung triggert. Zu diesem Zeitpunkt liegt die Default-Route noch auf dem primären ppp-Device und wird erst später auf den VPN-Tunnel verlegt. Der erste Request bekommt von dieser Änderung jedoch nichts mehr mit und erhält seine Antwort noch über das primäre ppp-Device, wodurch natürlich eine Beschleunigung nicht möglich ist. (siehe auch Abschnitt 7.1.3)

Status: works as designed

Lösung/Workaround: Solange der Trigger-Request kein ftp-Download einer großen Datei ist, sollte sich das Problem nicht allzusehr bemerkbar machen. Für den FTP-Fall hilft es, ein paar pings vor den Download zu schalten, damit der ftp erst startet, wenn der VPN-Tunnel und das Routing komplett aufgebaut sind. Der VPN-Tunnel wird wie gewünscht aufgebaut, allerdings bricht die Verbindung ab, sobald die ersten Pakete durch den Tunnel gehen sollen. In /var/log/messages findet sich eine Fehlermeldung in folgender Art:

     
Aug  4 22:49:34 athlon pptp[11434]: log[decapsgre:pptpgre.c:215]: short read (4294967295): Protocol not available
Aug  4 22:49:34 athlon pppd[11433]: Terminating on signal 15.
     
	 

Dieser Abbruch ist auf das Fehlen des Kernel-Moduls ipgre.o zurückzuführen. Laden Sie das Modul mit modprobe nach und das Problem tritt nicht mehr auf.

Status: gelöst

Lösung/Workaround: Laden sie das Modul ipgre.o vor dem Aufbau der VPN-Verbindung mit modprobe ipgre. Nähere Informationen dazu befinden sich im Abschnitt 6.2

Der VPN-Tunnel wird wie gewünscht aufgebaut, allerdings bekommen Sie keine Rückmeldung auf Anforderungen, die durch den Tunnel gehen. Eventuell kann es sogar so aussehen, dass einige Internetseiten erreichbar sind, während die Verbindung zu anderen Sites nicht funktioniert. Vermutlich ist die Angabe der MRU und MTU-Werte nicht vorhanden oder falsch gesetzt. Beide Parameter sollten auf den Wert 1452 gesetzt werden. Dies kann entweder direkt beim Aufruf von pptp geschehen oder aber unter /etc/ppp/options eingetragen werden.

Status: gelöst

Lösung/Workaround: Geben Sie den korrekten Wert von mru und mtu an (1452). Nähere Informationen hierzu unter Abschnitt 6.4

Werden USB-DDVB-Geräte unter Linux unterstützt

Die momentan aktuellen DVB-Treiber für Siemens unterstützen nur die internen PCI-DVB-Karten und keine externen USB-Geräte. Zwar wird in den Treibern am USB-Support gearbeitet, aber dieser steckt noch in einem sehr frühen Stadium und ist noch weit entfernt von der Routinetauglichkeit. Nähere Informationen erhält man in der Linux-DVB-Mailingliste. Leider scheint die Entwicklung der USB-Treiber nicht mehr voranzukommen, da es an Unterstützung der Hardware-Hersteller mangelt. Hier ein Statement eines Convergence-Mitarbeiters in der Linux-DVB-Mailingliste:

We don't have any documentation and no technical support neither from Hauppauge nor Technotrend (they made the initially design). Right now I don't have much motivation to continue reverse engineering. The protocol is basically completely known, except the {0x27, 2, ?, ?} sequence which is still missing. Contact me if anybody of you wants to continue working, then I'll try to explain anything you need to know and help wherever possibly.

Status: in Arbeit. Ob und wann der USB-Support in den DVB-Treibern serienreif sein wird, läßt sich derzeit nicht sagen.

Lösung/Workaround: - Linux-DVB-Mailingliste verfolgen und neueste Treiberversionen verwenden

- interne PCI-DVB-Karte verwenden

7.5 Ausblick

Sie sind am Ende meines HowTo angelangt und sollten jetzt soviele Informationen an der Hand haben, dass Sie den Zugang zu T-DSL via Satellit auf Ihrem Linux-System konfigurieren können. Ich würde mich freuen, Ihnen dabei tatsächlich geholfen zu haben und möchte Sie nochmals auffordern, mir Kritikpunkte und Verbesserungsvorschläge zu diesem Dokument zukommen zu lassen. Natürlich ist dieses Dokument noch nicht komplett, es gibt noch einige Punkte, die ich mir für die Zukunft vorgenommen habe. Dabei geht es allerdings schon mehr um die Expertenfragen und nicht mehr um die grundsätzliche Funktionsweise und Konfiguration. Für alle, die es interessiert, hier meine Ideen für weitere Abschnitte dieser Anleitung:

Sicherheitsaspeekte:

Firewalling und DVB

Hierzu gibt es bislang noch gar keine Informationen. Wie muß die Firewall auf dem Rechner konfiguriert werden? Welche Ports müssen offen bleiben? Können Hacker über den Satelliten an meinen Rechner?

Setup mit alter Treibergeneration

Die gesamte Dokumentation bezieht sich auf die Treibergeneration ab Version 0.9.x, die nur in Verbindung mit Kerneln ab 2.4.x funktioniert. Multicast-Networking war allerdings schon mit den älteren Treibern und Kerneln möglich, läuft aber etwas anders ab. Zwar gibt es die Anleitung, wie man die Treiber konfigurieren muß, schon in dem allgemeinen SAT-HowTo, allerdings nur in englisch und nicht explizit für den T-DSL via Sat-Zugang.

Übersetzung in's Englische

Englisch ist die Sprache für Dokumentationen unter Linux. Außerdem ist der Zugang zu T-DSL via Satellit nicht nur auf den deutschsprachigen Raum beschränkt, sondern kann europaweit empfangen werden. Daher halte ich eine Übersetzung dieses Dokumentes in's Englische für notwendig. Soweit meine Liste mit offenen Punkten, die ich je nach Lust, Laune und freier Zeit in der Zukunft verwirklichen will. Sollte jemand noch weitere interessante Themen im Bezug auf T-DSL via Satellit haben, kann er mir diese gerne zuschicken - vielleicht ja auch schon komplett ausformuliert. Ein Platz in der Danksagungsliste ist demjenigen sicher. ;-)

Internet-Zugang über T-DSL via Satellit unter Linux Version 0.4, 26. August 2002

Author: Wolfgang Wershofen, Systemberatung Wershofen

Auch wenn T-DSL via Satellit mittlerweile zum Regelangebot der Deutschen Telekom gehört, wird sich sicherlich im Laufe der Zeit noch einiges an diesem Dokument ändern. Schauen Sie öfters mal rein. ;-) Die jeweils aktuellste Fassung dieses Dokumentes finden Sie unter  http://www.wershofen.de/TDSLviaSAT-HowTo