Fehlermeldung im Forum

[xrated]

Recht häufig passiert es, sobald ich im Forum irgendwo hin klicke das sofort eine Fehlermeldung erscheint:

Keine Daten empfangen
Die Webseite kann nicht geladen werden, da der Server keine Daten gesendet hat.
Vorschläge:
Laden Sie diese Webseite später erneut.
Fehler 324 (net::ERR_EMPTY_RESPONSE): Server hat die Verbindung geschlossen. Es wurden keine Daten gesendet.

Also etwa 50% funktioniert und bei den anderen 50% kommt die Fehlermeldung. Das seltsame ist nur das die Meldung ohne Verzögerung innerhalb weniger ms kommt.

Wenn ich einen Dauerping mache, dann geht alles einwandfrei.
Als ob irgendwo ein Timeout zu kurz eingestellt wäre.

[dieterschneider]

ich habe solche Fehler auch noch nie gehabt.

[xrated]

Momentan gehts, aber manchmal muss ich 5x wo drauf klicken bis es ohne Fehler lädt. Vermutlich zu Stoßzeiten.

Ein Dauerping ist einfach ein Ping der kontinuierlich läuft, wobei ich da auch wenige Timeouts dabei hatte.

Als Browser verwende ich Chrome und in anderen Foren habe ich das Problem nicht.

[Gazza]

Moin,

ich hatte solche Meldungen auch noch nicht. Verschiedene Rechner mit verschiedenen BTs. Als Browser meist FireFox.

LG Gazza

[Marcus.S]

Moin Thomas,

das ist eine Chrometypische Meldung. Ein möglicher Lösungsansatz findet sich hier: http://www.redirect301.de/chrome-fehler-324.html

lg
Marcus

[Dosenfutter]

Das ist ein typischer Fehler vom Chrome, nicht der Webseite. Das kann man auch sehr gut nachvollziehen, indem man probeweise einen anderen Browser benutzt. Cache löschen und Chrome neu starten sollte helfen.

[xrated]

Warum tritt das dann ausschließlich auf dieser Seite auf? Und nein, mit Cache hat es nichts zu tun.

Ich vermute das auf dem Server wo das Forum läuft, dass dort einige ICMP Typen geblockt werden, vermutlich Type 3 oder 11 und nur Ping erlaubt ist (0 und 8).

[Dosenfutter]

Es gibt keine HTML Fehlermeldung 324. Such halt mal selber nach "error 324". Du wirst sehen, das ist ein Chrome-Problem.

[xrated]

Niemand sagt das es HTML wäre ...

Normalerweise teilt der Client dem Server die MTU size mit und der Server gibt eine Antwort darauf. Und ich vermute das dies geblockt wird am Server bzw. Firewall.

Um dies zu umgehen gibt es am (lokalen) Router ein sog. MSS Clamping was allerdings ein Hack ist und die Größe automatisch verkleinert so das es auch funktioniert wenn ICMP geblockt wird.

Wenn ich die MTU überall auf 1492 einstelle dann funktioniert es auch. Es wäre nun möglich das mein Router mit MSS Clamping Probleme hat aber wenn ICMP vernünftig funktionieren würde, wäre das gar nicht notwendig. Das hat also mit der Firewall auf diesem Server zu tun.

Ich denke nicht das Chrome die Ursache dafür ist sondern das Chrome einfach nur weniger tolerant gegenüber Fehlern ist. Andere Browser verkleinern die MTU vielleicht wohl selbstständig.

Da muss ich wohl mal einen Sniffer anwerfen und die Pakete genauer anschauen.

[Marcus.S]

Warum tritt das dann ausschließlich auf dieser Seite auf? Und nein, mit Cache hat es nichts zu tun.

Dosi hat vollkommen Recht und das würde ich unter "Zufall" abhaken. Ich arbeite ja nu im technischen Support u.A. für solche Endkundenthemen. Man kann sich nichtmal darauf verlassen, dass es bei jedem Nutzer in Chrome auftritt. Was manchmal hilft ist, die scheinbar bockende Seite in einem Inkognitotab zu öffnen.

Ich vermute das auf dem Server wo das Forum läuft, dass dort einige ICMP Typen geblockt werden, vermutlich Type 3 oder 11 und nur Ping erlaubt ist (0 und 8).

Das hier ist ein managed Server, ich kümmere mich also (nach Jahren, endlich!) nicht mehr selber um sowas. Allerdings würde ich (und habe es in der Vergangenheit getan) einen Webserver ähnlich zunageln. Bis vor einigen Versionsnummern haben solche Maßnahmen auch im Chrome keine Probleme verursacht. Keine Ahnung, was die Programmierer da verschlimmbessert haben :dont_know:
Ich schaue nachher @home mal nach wie das eingestellt ist. Von hier aus (Banknetz, zugenagelt wie sonstwas) komme ich an nix ´ran.

lg
Marcus

[Dosenfutter]

Edit: Wenn das mit der MTU wirklich der Fall wäre, müßte es hier im Forum dutzende Betroffene geben. Gibt es aber nicht. Dazu ist es ein Fehlercode, der - so - weder von HTML noch von TCP/IP (dem unerliegenden Protokoll) benutzt wird. Irgendwoher muß die Fehlermeldung ja kommen - oder?

[xrated]

Ja normalerweise ist auf so ziemlich allen Routern auch MSS Clamping aktiviert weil es eben viele Firewall Admins gibt, die meinen das ICMP böse sei.

Ich bin übrigens seit 15 Jahren im IT Geschäft dabei und habe Server in Umgebungen mit 1000+ Clients verwaltet

[Matthias.S]

Moin moin,

damit das Stochern im Nebel aufhört:
Poste doch bitte mal den Output von

Code:

mturoute -s www.diy-hifi-forum.eu

(für Windows) oder

Code:

tracepath

(für Linux)

Danke,

Mat

[xrated]

moin

das hatte ich schon probiert mit:
ping -f -l 1464 diy-hifi-forum.eu bzw.
ping -f -l 1465 diy-hifi-forum.eu (hier wird defragmentiert)
(ping selbst hat 28byte + 1464 was eine max size von 1492 ergibt bevor defragmentiert werden muss)

Und hier nochmal:
mturoute -s -m 1500 -f diy-hifi-forum.eu
* ICMP Fragmentation is permitted. *
* Speed optimization is disabled *
* Maximum payload is 1500 bytes. *
+ ICMP payload of 796 bytes succeeded.
.+ ICMP payload of 1148 bytes succeeded.
+ ICMP payload of 1324 bytes succeeded.
+ ICMP payload of 1412 bytes succeeded.
+ ICMP payload of 1456 bytes succeeded.
+ ICMP payload of 1478 bytes succeeded.
+ ICMP payload of 1489 bytes succeeded.
+ ICMP payload of 1494 bytes succeeded.
+ ICMP payload of 1497 bytes succeeded.
+ ICMP payload of 1498 bytes succeeded.
+ ICMP payload of 1499 bytes succeeded.
Estimated Max: 1500 bytes or higher.


mturoute -s -m 1500 diy-hifi-forum.eu
* ICMP Fragmentation is not permitted. *
* Speed optimization is disabled *
* Maximum payload is 1500 bytes. *
+ ICMP payload of 796 bytes succeeded.
+ ICMP payload of 1148 bytes succeeded.
+ ICMP payload of 1324 bytes succeeded.
+ ICMP payload of 1412 bytes succeeded.
+ ICMP payload of 1456 bytes succeeded.
- ICMP payload of 1478 bytes is too big.
- ICMP payload of 1467 bytes is too big.
+ ICMP payload of 1461 bytes succeeded.
+ ICMP payload of 1464 bytes succeeded.
- ICMP payload of 1465 bytes is too big.
Path MTU: 1492 bytes.

Aber ICMP Ping Reply ist eben ICMP Type0 und nicht 3

[dieterschneider]

traceroute to http://www.diy-hifi-forum.eu (178.77.82.14), 64 hops max, 52 byte packets
1 http://www.routerlogin.com (192.168.0.1) 3.855 ms 3.915 ms 3.665 ms
2 217.0.119.60 (217.0.119.60) 8.207 ms 8.881 ms 8.496 ms
3 217.0.75.134 (217.0.75.134) 9.997 ms 8.821 ms 8.472 ms
4 d-ed1-i.d.de.net.dtag.de (62.154.15.222) 24.618 ms
d-ed1-i.d.de.net.dtag.de (62.154.15.226) 15.965 ms
d-ed1-i.d.de.net.dtag.de (62.154.15.198) 15.821 ms
5 62.157.250.114 (62.157.250.114) 44.787 ms 15.464 ms 15.488 ms
6 xe-0-0-0.dr-master.r2.cgn3.he-core.de (176.28.4.42) 57.614 ms 16.161 ms 15.553 ms
7 vwp6564.webpack.hosteurope.de (178.77.82.14) 17.449 ms 17.779 ms 17.581 ms

------------------

„Ping“ wurde gestartet …

PING http://www.diy-hifi-forum.eu (178.77.82.14): 56 data bytes
64 bytes from 178.77.82.14: icmp_seq=0 ttl=54 time=18.063 ms
64 bytes from 178.77.82.14: icmp_seq=1 ttl=54 time=18.708 ms
64 bytes from 178.77.82.14: icmp_seq=2 ttl=54 time=20.362 ms
64 bytes from 178.77.82.14: icmp_seq=3 ttl=54 time=18.492 ms
64 bytes from 178.77.82.14: icmp_seq=4 ttl=54 time=17.891 ms
64 bytes from 178.77.82.14: icmp_seq=5 ttl=54 time=22.183 ms
64 bytes from 178.77.82.14: icmp_seq=6 ttl=54 time=18.458 ms
64 bytes from 178.77.82.14: icmp_seq=7 ttl=54 time=19.563 ms
64 bytes from 178.77.82.14: icmp_seq=8 ttl=54 time=18.180 ms
64 bytes from 178.77.82.14: icmp_seq=9 ttl=54 time=17.925 ms

--- http://www.diy-hifi-forum.eu ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 17.891/18.982/22.183/1.299 ms

[Marcus.S]

Du verdrehst da etwas.

ICMP Type3 ist eine Antwort, keine Anfrage und wird vom Zielsystem gesendet, wenn der angefragte Port nicht offen ist.
ICMP Type11 ist ebenso eine Antwort und bezieht sich auf eine Zeitüberschreitung.

Der Server hier antwortet also auf die Anfrage, es ist nichts geblockt.

Chrome funktioniert bei mir übrigens ohne Probleme. Den nutze ich nämlich auf dem Rechner für moderative Aufgaben (ich muss dann nicht immer auf meinen Mod-Account umloggen, sondern wechsel einfach den Browser) und auf den Mobilgeräten (iPad / iPhone) fast immer. Mit Standareinstellungen im lokalen Netz gibt es - mit Ausnahme des verbocken Cookiehandlings in Chrome - keine Probleme.

Da der Lösungsansatz aus meinem ersten Post oben u.A. auf die MTU zielt: bist du mit Standardeinstellungen unterwegs oder hast du die Einstellungen "optimiert"?

Hast du ggf. die TTL ´runtergesetzt?

@all: hat sonst noch jemand Probleme mit Chrome?

(Hinweis: das oben geschriebene gilt für IPv4, v6 müßte ich erst nachsehen)

[eltipo]

Bin auf S3 und mim Tablet auf Chrome unterwegs,

keine Probleme.

Wann kommt eigentlich Tapatalk?*g*

[Marcus.S]

Wann kommt eigentlich Tapatalk?*g*

Menno, erinner mich nicht daran

[Dosenfutter]

@all: hat sonst noch jemand Probleme mit Chrome?

Ich benutze meist den Opera, ich hatte hier im Forum aber mit dem Chrome noch nie Probleme.

[xrated]

Du verdrehst da etwas.

ICMP Type3 ist eine Antwort, keine Anfrage und wird vom Zielsystem gesendet, wenn der angefragte Port nicht offen ist.
ICMP Type11 ist ebenso eine Antwort und bezieht sich auf eine Zeitüberschreitung.

Der Server hier antwortet also auf die Anfrage, es ist nichts geblockt.

Ich habe nie behauptet Type 3 wäre ein Anfrage

IMHO ist das alles was oben steht (also der ICMP Ping response) nur eine ganz normale Ping Reply Type 0. Aber um Pings geht es nicht. Das sieht man auch ganz gut im Sniffer das da nur Type 0 und 8 läuft.

Worum es aber geht ist Path MTU Discovery. Hier sollte der Server eine Antwort senden wie groß die max. MTU sein darf und dies wird bei Type 3 destination unreachable code 4 Destination Unreachable Fragmentation Needed, DF Set mitgesendet. Mit der vom Server mitgeteilten MTU weiß der Client dann, aha ich kann keine 1500 verwenden, sondern nur 1492.

siehe: http://de.wikipedia.org/wiki/Path_MTU_Discovery

Das ist aber eben alles nur basiert auf Vermutung (also bezogen auf meine Chrome Probleme) und ist wahrscheinlich nicht mal der Grund für meine Fehlermeldungen.
Ich hab mal Wireshark angeworfen und mir ICMP angeschaut und von vielen Seiten war Reichelt die einzige die mir die MTU mitgeteilt hat (siehe Screen). Das MSS Clamping scheint an meinem Router also doch zu gehen.
Vielleicht wars auch nur Zufall das es ging als ich überall 1492 eingestellt hab. Bis jetzt hab ich komischerweise auch keine Fehlermeldungen mehr, ohne das ich was geändert hätte.