Fehler bei der Updatesuche

[mammut]

Hallo zusammen

Ich habe einen ärgerlichen, wiederkehrenden Fehler im Log:
Datei: /usr/local/edomi/main/queuecmd/cmd1.php | Fehlercode: 2 | Zeile: 20 | file_get_contents(http://62.75.208.51/download/updates...200105183534): failed to open stream: HTTP request failed!
Irgendetwas stört die Kommunikation. Als absoluter Linux-Neuling bin ich am Ende der Fahnenstange. Besagte "Zeile" 20 ist leider ein Monstrum.
Was ich bisher herausgefunden habe:
- Die Antwort "NOUPDATE" kommt korrekt zurück. Dennoch stimmt etwas mit der Kommunikation nicht.
- Die Meldung tritt nicht auf, wenn ich in der Blacklist des Fritz überhaupt keinen Eintrag habe. Existiert nur ein einziger irrelevanter Eintrag, tritt besagter Fehler auf. Ebenso, wenn ich eine Whitelist aktiviere.
Ich habe vor, dem Edomi-Rechner im Internet nur so viele Rechte wie nötig zu geben. Aber schon die geringste Einschränkung führt zum Problem. Ziel wäre es, mit einer Whitelist zu arbeiten. Dies funktioniert auch fehlerfrei, wenn ich den Befehl direkt in einen Browser eingebe: "NOUPDATE".

Wer hat eine Idee und kann weiterhelfen?

Grüsse vom Bodensee
Csaba

[jonofe]

Das passiert um 0:00 Uhr, oder? Da ist der Server vermutlich so ausgelastet, dass die Updateanfrage fehlschlägt. Ist bei mir auch schon öfter passiert.

[mammut]

Hallo "jonofe"

Danke für die Idee. Es passiert bei jedem Serverstart tagsüber. Auch jeweils um Mitternacht.
Auffällig ist: Wenn ich im Fritz alles durchlasse, gibt es keine Fehlermeldung (wie oben beschrieben). Irgendwie ist es etwas suspekt. Ich habe mal mit Wireshark geschaut, aber das ist mir eine Nummer zu hoch. Es gibt aber einen Unterschied, den ich aber nicht interpretieren kann.

[gaert]

Wenn ich im Fritz alles durchlasse, gibt es keine Fehlermeldung

Dann liegt's wohl an der Fritzen-Konfiguration?! Ich mein...

EDOMI ruft lediglich eine URL auf, um nach Updates zu suchen - ganz normal per HTTP.

[mammut]

Ja, das dachte ich auch. Die HTTP-Kommunikation scheint auch ok.
Was ich gesehen habe, aber nicht interpretieren kann: Es geht 17ms nach dem HTTP-Ausruf eine "TCP Retransmission" raus, was immer das ist. Gleich darauf kommt die (korrekte) Antwort über HTTP rein. Dennoch kippt die Kommunikation um.