Dieses Paket ist nur für die Versionen 2.0.1 bis 2.0.6 von Fli4L geeignet, Pakete für andere Versionen sind auf http://www.pirmasoft.de/opt_mssclampfw/ oder in der OPT-Datenbank von Fli4L unter http://www.fli4l.de/german/extern/opt/ zu finden.
Obwohl die Einwahl funktioniert und die meisten Internet-Seiten problemlos erreichbar sind, klappt die Verbindung mit einigen Seiten von Windows-Clients aus nicht. Es kommt zwar eine Verbindung zustande und der Browser fordert die Seite auch an, aber dann passiert nichts mehr, es kommt keinerlei Antwort zurück. Ein Beispiel für eine solche Seite ist www.chip.de.
Wenn man sich bei CompuServe Pro oder CompuServe Night&Day einwählt, werden alle Pakete zunächst durch einen Tunnel in die USA geleitet. Dieser Tunnel kann nur Datenpakete mit einer maximalen Größe von 1400 Bytes transportieren, d. h. die MTU (Maximum Transfer Unit) ist 1400.
Jedesmal, wenn man von einem Windows-Client eine TCP-Verbindung aufbaut, versucht dieser automatisch die MTU für die Verbindung zum gewählten Server festzustellen. Dabei schickt er Pakete mit verschiedenen Größen. Bei denen, die zu groß für die Verbindung sind, erhält er von einem Router per ICMP eine Fehlermeldung, daß das Paket zu groß war. Danach schickt er eben kleinere Pakete.
Das klappt nun soweit, daß der Windows-Client keine Pakete größer 1400 Bytes verschickt, so daß sie auch beim Server ankommen. Zum Problem wird aber, daß der Client als gewünschte Maximalgröße für Antwortpakete trotzdem 1500 angegeben hat (die Maximalgröße für Ethernet-Netzwerke), denn der Server schickt nun Antwortpakete mit 1500 Bytes zurück.
Bei anderen Providern geht das nun gut, bei CompuServe ist aber der Tunnel dazwischen. Dieser teilt dem Server per ICMP mit, daß die Pakete zu groß sind, woraufhin dieser normalerweise seine Paketgröße auf 1400 verringert. Es gibt jedoch einige Server, die hinter einer Firewall sitzen, die ICMP generell nicht durchläßt (warum auch immer jemand das verbrochen hat). In diesem Fall schmeißt die Firewall die Fehlermeldungen des Tunnels weg, und der Server sendet weiter fleißig zu große Pakete, die dann natürlich niemals durchkommen. Genau in diesem Fall kommt es dann zu obigem Problem.
Da ich nur Windows-Clients habe, ist mir nicht bekannt, inwieweit das oben gesagte auch andere Betriebssysteme betrifft. Wenn jemand das mal ohne und mit mssclampfw.o ausprobiert, kann er mir gerne seine Erfahrungen mitteilen. Ich werde das entsprechende Betriebssytem dann in diese Beschreibung aufnehmen.
Das Modul mssclampfw.o wurde ursprünglich für DSL verwendet, da PPPoE das gleiche Problem hat. Heute verwendete PPPoE-Treiber (auch die von Fli4L) haben allerdings eine entsprechende Funktion meist eingebaut, so daß die Verwendung dieses Moduls dafür überflüssig ist. Weitere Informationen finden sich auf http://sdb.suse.de/sdb/de/html/hoe_adsl_router.html, über diese Seite habe ich auch das fertige Modul von ftp://ftp.suse.com/pub/projects/T-DSL/mssclampfw.o heruntergeladen.
Alle Dateien aus dem ZIP-Archiv ins Fli4L-Verzeichnis kopieren und die Diskette neu erstellen bzw. mktgz.bat ausführen und den Router updaten.
Falls CompuServe weder mit noch ohne Modul funktioniert, könnte es an der Einstellung ISDN_CIRC_2_USEPEERDNS='yes' in der isdn.txt liegen. In diesem Fall mal ISDN_CIRC_2_USEPEERDNS='no' setzen und in der base.txt die Nameserver eintragen.
Ich habe dieses Modul bei mir im Einsatz und es verursacht keinerlei Probleme. Trotzdem übernehme ich keinerlei Funktionsgarantie oder Haftung für eventuell dadurch verursachte Probleme.
Kommentare, Wünsche, Anregungen und Verbesserungsvorschläge an mich:
Dieter Schmeer, dschmeer@pirmasoft.de
Letzte Änderung 2003-01-06