Inet verbindung langsam

[Psimon]

Ich möchte den Beitrag an dieser Stelle erweitern:

- IpTables und andere Firewalls auf der SuSE ausgeschaltet und das Testing von dieser Maschine aus weitergeführt (da ja das Masquerading nicht mehr is)
- resolv.conf die Nameservereinträge rausgenommen und im Zuge dessen, die Zuweisung durch DHCP sichergestellt

 

[DennisM]

Ich möchte den Beitrag an dieser Stelle erweitern:

Dann benutz doch bitte auch die Edit-Funktion. Danke

MFG

Dennis

 

[Goodspeed]

Nur ne Idee ... setz mal die MTU bei beiden ethX von 1492 auf 1500 ...

 

[Psimon]

Sehr guter Ansatz!

Stichwort "STFW" - Ich bin endlich fündig geworden! Da ich nämlich auch keine Emails mehr bekomme (sofern eine größere dabei ist) und meine Downloads abbrechen....... siehe wie folgt:

DSL: Keine Mail von GMX über POP3
Aus der Mailing-Liste:

Nach der Umstellung von ISDN auf T-DSL läuft alles prima, solange es um den Internet-Explorer geht. Leider funktioniert nun der Zugang zum pop3-Server von GMX unter MS-Outlook nicht mehr, der unter ISDN keine Problem bereitete. Ich erhalte nur die Information, wie viele Mails anliegen, dann passiert aber nichts mehr. Masquerading ist eingeschaltet.

Ein DSL-Problem, das u.U. auch auf andere Seiten zutrifft. Hinweise willkommen.

Die Lösung (Quelle: SuSE-Supportdatenbank):

Laden Sie das Modul mssclampfw.o vom SuSE-FTP-Server:
ftp://ftp.suse.com/pub/projects/T-DSL/mssclampfw.o

Verschieben Sie nun das Modul mssclampfw.o in das Module-Verzeichnis:
mv mssclampfw.o /lib/modules/2.2.16/misc/
(oder vom Client per FTP direkt dorthin kopieren)

Sie können das Modul nun sofort mit
insmod mssclampfw
laden

Damit das Modul beim Systemstart automatisch geladen wird, sollten Sie in die Datei
/etc/modules.conf die Einträge
post-install pppox insmod mssclampfw
pre-remove pppox rmmod mssclampfw

einfügen und danach den Befehl
depmod -a
ausführen (Man erhält dabei eine Fehlermeldung bezüglich PCMCIA : Bedeutungslos). Danach kann man wieder Mails von GMX empfangen.

Quelle: http://www.gesamtschule-eiserfeld.de/gee/faq/faq0102.html

Weiterhin hab ich zu diesem Thema gefunden (nicht ganz unwichtig):

Der Grund:
Wenn man sich bei CompuServe Pro 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 Pro 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.

Die Lösung:
Man installiert das Modul mssclampfw.o (dieses OPT-Paket) auf dem Router. Dieses stellt die MTU einer Verbindung fest und modifiziert bei allen ausgehenden Paketen die Maximalgröße für Antwortpakete entsprechend. Dies ist zwar irgendwie ein "Hack", da alle ausgehenden Pakete modifiziert werden müssen, hat aber den Vorteil, daß man alle Windows-Clients in Ruhe lassen kann und dadurch weniger Aufwand hat. [...]

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.

Quelle: http://www.pirmasoft.de/opt_mssclampfw/readme.htm


Auch noch interessant Seite 2 und 3 von:

http://www.tecchannel.de/netzwerk/management/429773/index2.html

 

[Psimon]

So und nun die Schritt für Schritt Anleitung was ich gemacht hab:

- Vom Provider wird automatisch der MTU Wert 1492 für pppoe zugewiesen (siehe ifconfig) -> also hab ich auch alle andern Netzwerkkarten (auch die auf der WinXP) auf 1492 gesetzt.

- Bei Seite 3 von www.tecchannel.de (Link siehe oben) hab ich gelesen das bei MTU Wert von 1492 ein MSS Wert von 1452 sein muss! Also muss man dafür Sorge tragen das es auch so ist! Das macht iptables für uns... Ich hab in meinem iptables Script diese Zeile als erstes eingetragen (das ist wichtig - vor allen anderen Regeln!):

# the important MSS management
/usr/sbin/iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

- Jetzt die iptables flushen und mit dem eigenen iptables script neu initialisieren

- B000000m!.... Jetzt tickt es endlich wie es soll und die Emails kommen alle an :>

Als Goodie noch mein komplettes iptables Script:

#!/bin/sh

# flush
/usr/sbin/iptables --flush

# evaluate command line options
DEV=eth2
# default deny action: DROP or REJECT
DROP=DROP

# some nice modules
/sbin/modprobe ipt_tcpmss
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_nat_ftp
modprobe iptable_nat

# the important MSS management
/usr/sbin/iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# masquerading
/usr/sbin/iptables -t nat -A POSTROUTING -o $DEV -j MASQUERADE

# create new table that logs and drops
/usr/sbin/iptables -N droplog
/usr/sbin/iptables -A droplog -j LOG
/usr/sbin/iptables -A droplog -j $DROP

# create my own filter queue
/usr/sbin/iptables -N myfilter

# allow SSH and FTP from everywhere
/usr/sbin/iptables -A myfilter -m state --state NEW -i $DEV -p tcp --dport 22 -j ACCEPT
/usr/sbin/iptables -A myfilter -m state --state NEW -i $DEV -p tcp --dport 21 -j ACCEPT
/usr/sbin/iptables -A myfilter -m state --state NEW -i $DEV -p tcp --dport 20 -j ACCEPT
#/usr/sbin/iptables -A myfilter -p tcp --sport 1024:65535 --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
#/usr/sbin/iptables -A myfilter -p tcp --sport 21 --dport 1024:65535 -m state --state RELATED,ESTABLISHED -j ACCEPT
#/usr/sbin/iptables -A myfilter -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state RELATED,ESTABLISHED -j ACCEPT

# REJECT ident requests - DROP causes long delays
/usr/sbin/iptables -A myfilter -m state --state NEW -i $DEV -p tcp --dport 113 -j REJECT

# by default: drop+log everything we don't want or know
/usr/sbin/iptables -A myfilter -m state --state NEW,INVALID -i $DEV -j droplog
# nessessary for sharing internetconnection and other devices of the local area network
/usr/sbin/iptables -A myfilter -m state --state NEW -i ! $DEV -j ACCEPT
/usr/sbin/iptables -A myfilter -m state --state ESTABLISHED,RELATED -j ACCEPT
/usr/sbin/iptables -A myfilter -j droplog

# send all packages from INPUT and FORWARD queue through my filter
/usr/sbin/iptables -A FORWARD -j myfilter
/usr/sbin/iptables -A INPUT -j myfilter

# FTP Server start
/etc/init.d/xinetd restart

Liebe Grüße und Danke an Alle!

 

[Psimon]

.............Oct 25 23:40:24 PsimonGate sshd[19092]: input_userauth_request: illegal user jude
Oct 25 23:40:24 PsimonGate sshd[19092]: Failed password for illegal user jude from ::ffff:195.146.82.145 port 40384 ssh2
Oct 25 23:40:25 PsimonGate sshd[19092]: Received disconnect from ::ffff:195.146.82.145: 11: Bye Bye
Oct 25 23:40:26 PsimonGate sshd[19093]: Illegal user judith from ::ffff:195.146.82.145
Oct 25 23:40:26 PsimonGate sshd[19093]: input_userauth_request: illegal user judith
Oct 25 23:40:26 PsimonGate sshd[19093]: Failed password for illegal user judith from ::ffff:195.146.82................

coool mich versucht einer zu hacken
wer hat die 195.146.82.145????

 

[synapse]

.............Oct 25 23:40:24 PsimonGate sshd[19092]: input_userauth_request: illegal user jude
Oct 25 23:40:24 PsimonGate sshd[19092]: Failed password for illegal user jude from ::ffff:195.146.82.145 port 40384 ssh2
Oct 25 23:40:25 PsimonGate sshd[19092]: Received disconnect from ::ffff:195.146.82.145: 11: Bye Bye
Oct 25 23:40:26 PsimonGate sshd[19093]: Illegal user judith from ::ffff:195.146.82.145
Oct 25 23:40:26 PsimonGate sshd[19093]: input_userauth_request: illegal user judith
Oct 25 23:40:26 PsimonGate sshd[19093]: Failed password for illegal user judith from ::ffff:195.146.82................coool mich versucht einer zu hacken

hi wie kann ich sowas sehen, bzw. welches prog muss ich installieren?

übrigens meine inet-verbindung unter linux ist auch langsam, meine konkret den seitenaufbau mit dem firefox. habe den firefox bereits getunt, mtu ist auf 1500 habe dsl, aber wenn ich neuen tab aufmache und eine inet-adresse eingebe dann dauert es immer ein weilchen und dieses ladesymbol im tab bleibt auch kurz ganz stehen.
benutze genau dieselbe verbindung unter windows und dort ist firefox sauschnell. irgendwas stimmt hier nicht. :-(

benutze kubuntu , conecte mit pptp und der alias ipv6 ist off bringt aber leider nicht mehr speed

 

[Psimon]

hi wie kann ich sowas sehen, bzw. welches prog muss ich installieren?

Unter SuSE Linux ist es "Strg + F10" drücken oder in /var/log/messages glotzen.
LG, Simon