Webserver zeigt nur "kleine" Dateien an....

[renew]

Ich hab einen Webserver bei mir in der Schule stehen, der an der Schulstandleitung hängt.

Jedoch seit Freitag ist er nicht bzw. sehr eingeschränkt erreichbar.
Was ich hier mit eingeschränkt meine ist, dass nur ganz kleine Dateien angezeigt werden. Sprich kurze HTML Dokumente, sobald diese jedoch länger werden, bzw. auch Bilder dazu kommen ist es vorbei.

Die Seite kommt einfach nicht mehr durch.

Hab mich jetzt gespielt: von meiner Aon Verbindung zum Server ist genau bei 1172bytes schluss - ist die Seite 1173bytes groß, gehts nicht mehr.

Allerdings kann ich ohne Probleme via Terminal-Server den Server administrieren.

Paket-Loss von mir zum Server(mit Ping getestet) = 0%!!

Rufe ich das ganze aber über einen anderen Webserver auf (mittels Perl-Script), damit ich von einer anderen Connection dort hin komm, funktionierts größten teils.
Ein Freund von mir mit einer Chello Leitung hat das gleiche Ergebnis.

Server funktioniert auch 1A in lokalen Schulnetz - es muss also an der Verbindung nach außen liegen (nur wo ist die Frage)

Ich bin aber absolut ratlos was dort schuld sein könnte.

Server is Win2k mit SP3 mit einer ISA-Server Firewall und MS SQL 2000 drauf.

Habs auch schon ohne Firewall probiert - selbes Ergebnis

[spunz]

ping mal den server mit "ping -l 1500 -f www.server.at" wobe der wert 1500 für deine aktuelle mtu size steht.

[renew]

Original geschrieben von spunz
ping mal den server mit "ping -l 1500 -f www.server.at" wobe der wert 1500 für deine aktuelle mtu size steht.

hab doch gewusst man kann die MTU beim Ping angeben - nur hat mich das Kommentar daneben irritiert: "send buffer size"

Naja, wie auch immer - ist kein Problem. Bin bis zu einer MTU von 5000 gegangen - da warens dann noch 800ms, aber ich hab eine Antwort bekommen.

Was mir nicht eingeht ist, dass ich über mein Perl-Script auch größere Seiten bekomme.
Und dass ich via Terminal-Server ohne Probleme arbeiten kann.
Ich kann programmieren, konfigurieren, was ich will, ohne dass es Probleme gibt.

PS: "no fragment flag" (-f) geht nur bis zu einer MTU von 1000 - da funktioniert aber auch noch alles ohne Probleme

[flinx]

PS: "no fragment flag" (-f) geht nur bis zu einer MTU von 1000 - da funktioniert aber auch noch alles ohne Probleme

Des ist aber IMHO der Sinn der Sache, dass das -f setzt und schaust, welche packets noch gesendet werden.
http://www.your-connect.ch/news-detail.asp?newsid=91
http://www.dslreports.com/sitesearch

[spunz]

stell mal deinen client eine mtu size von unter 1000 ein.

[renew]

Original geschrieben von spunz
stell mal deinen client eine mtu size von unter 1000 ein.

und wo...

@flinx
danke für die Links, werd ich mir mal durchlesen.
Was ich damit meine is, dass Ping kein no-fragment will bei einer MTU von 1500.

Jedoch gehts noch bis 1400 - und da bekomm ich keine Antwort mehr.
Bei 1350 bekomm ich noch eine.

Gehe ich richtig der Annahme, dass ihr meints, dass die Pakete die an mich gesendet werden sollten, nicht gesendet werden können weil die MTU die ich verlange zu hoch ist?

Ist von der Überlegung nicht unlogisch... (stellt sich nur die Frage, wieso, dass seit Freitag nicht mehr geht, und dass bei verschiedenen Providern - bis jetzt UTA, Aon und Chello getestet)

Genausowenig funktioniert der HTML-Validator (validator.w3.org - und das auch erst seit Freitag)

edit: hab grad auf der Site von flinx gefunden wie man die MTU (Dr.TCP) umstellt - ich nehm an, das setzt er in der Registry - oder?
Und die Frage wär natürlich, ob das ganze auch bei RRAS funktioniert - da ich über diesen mittels NAT ins Netz gehe.

[spunz]

Original geschrieben von LLR

Und die Frage wär natürlich, ob das ganze auch bei RRAS funktioniert - da ich über diesen mittels NAT ins Netz gehe.

über unsere linux fw gings ohne probleme, einfach mal probieren würd ich sagen

[renew]

Original geschrieben von spunz


über unsere linux fw gings ohne probleme, einfach mal probieren würd ich sagen

aso, du meinst auf meinem Client.

Ich dachte mir, direkt am NAT, ändert der die MTU gar nicht?

Ähhm, ich kommt grad auf was "peinliches" drauf.
Wenn ich auf meinem Server(=NAT) auf die Seite geh, funktioniert alles normal!?

Das heißt, dass das ganze Problem nur bei den Clients liegt??? Na Hölle, das gibts ja nicht.

Das erklärt auch, warum ich mitn Terminal Server so gut verbunden werde - weil das mach ich direkt vom "Router" aus.

[renew]

folgende Frage: kann man dieses Problem auch serverseitig beheben?
Außer Destination Unreachable Messages zu erlauben? (weil die sind sicher dicht - der ISA lasst nur ICMP Echo Requests rein)

Theoretisch müsste es ja funktionieren, wenn ich die MTU am Server niedriger setzte - oder?

Nur was mich wundert ist, dass die Clients hinter dem NAT die MTU bestimmen und nicht der NAT Router, der das Paket ja dann eigentlich erst ins Internet setzt.

Weil wenn mich nicht alles täuscht is die MTU ja auf OSI-Layer 2, und das Protokoll auf der Ebene wird sicher nicht mehr Ethernet (802.3) sein, wenn das Paket seine Reise ins Inetz beginnt.

Naja, wie auch immer, jetzt geht der ganze Kübel wieder.
Bin grad heim gekommen, getestet und ohne, dass ich was geändert habe gehts wieder.

[Quattro_os]

... kann mir das wer erklären?

LG Quattro_os