You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users-de@httpd.apache.org by Ralph ballier <ba...@mail.schule.de> on 2010/08/01 15:04:32 UTC
Re: Fehlerhafte Dateiübertragung
Hallo Peter,
vielen Dank für deine Hinweise.
Ich habe mit tcpdump von einem Testrechner aus über die ansonsten nicht
benutzte Schnittstelle eth1 mit
tcpdump -i eth1 -w proto
den Datenverkehr bei dem Befehl lynx anton/a65536.pdf mitgeschnitten. Jetzt
sollte in der Datei proto doch eigentlich Byte für Byte der Datenstrom zu
sehen sein, oder? Wenn ich die Datei mit dem vi öffne, ist aber kaum etwas
vernünftiges zu sehen (vi im Binärmodus, rechts werden die druckbaren
Zeichen ausgegeben. Die Zahlenfolgen werden immer wieder durch nicht
druckbare Zeichen unterbrochen). Daraus kann ich gar nichts ersehen.
Gruß
Ralph
----------------ursprüngliche Nachricht-----------------
Von: "Peter Pöml"
An: users-de@httpd.apache.org
Datum: Wed, 21 Jul 2010 19:23:45 +0200
-------------------------------------------------
> Hallo Ralph,
>
> Am 16.07.2010 um 11:51 schrieb Ralph Ballier:
>
>> Hallo,
>>
>> ich habe zum besseren Testen eine Modelldatei hergestellt, die aus 1024
>> Zeilen der Form
>>
>> 012345670123456701234567012345670123456701234567012345670123456
>>
>> besteht. Dadurch entsteht eine Datei mit genau 65536 Zeichen (die Zeilen
>> enden jedesmal bei 6 und nicht 7, weil der Zeilenwechsel \n als eigenes
>> Zeichen zählt).
>>
>> Rufe ich jetzt
>>
>> strace -f -s 200000 -o proto ./httpd
>>
>> auf und lade die genannte Datei herunter, so kann ich in proto
einigermaßen
>> nachvollziehen, was geschieht.
>>
>> Nach gut 3000 Zeilen beginnt der Download der Datei.
>> Es werden 8192 Zeichen gelesen:
>>
>> read(32, "0123...456\n", 8192) = 8192
>>
>> und wieder geschrieben:
>>
>> write(31, "0123...456\n", 8192) = 8192
>>
>> Das ganze vollzieht sich in dieser Form siebenmal. Beim achtenmal (dann
>> wären ja die 65536 Zeichen vollständig übertragen worden) sieht das
>> Ganze
>> ein wenig anders aus:
>>
>> read(32, "0123...456\n", 8192) = 8192
>>
>> write(31, "0123...456\n", 8192) = 1
>>
>> Hier scheint also nur 1 Zeichen geschrieben worden zu sein. Die
>> nachfolgende
>> Zeile lautet:
>>
>> poll([{fd=31, events=POLLOUT, revents=POLLOUT}], 1, 300000) = 1
>>
>> Dann folgen offenbar die noch fehlenden Zeichen:
>>
>> write(31, "0123...456\n", 8191) = 8191
>>
>> Von ASCII-Nullen ist nichts zu sehen. Aber die übertragene Datei ist
fast
>> doppelt so lang, weil an ihr reguläres Ende ASCII-Nullen angehängt
>> worden
>> sind. wc a65536.pdf liefert
>>
>> 1024 1025 122879 a65536.pdf
>>
>> Soll ich noch mehr Inhalte der Protokolldatei posten?
>>
>> Gruß
>>
>> Ralph
>
> Wenn ich Deine Beschreibung des strace-Logfiles richtig verstanden habe,
geht
> daraus hervor, dass der Apache zu keinem Zeitpunkt die Nullen schreibt.
Sprich,
> er kann dann nichts dafuer. Das Problem ist also an anderer Stelle zu
suchen.
>
> Der Apache schreibt korrekte Daten auf den Netzwerksocket, doch der
schickt am
> anderen Ende nicht nur das raus, was er vom Apache bekommen hat, sondern
mehr
> (eingestreute Nullen). Richtig?
>
> Waehrend strace nachweist, dass die Nullen nicht gesendet werden sollten,
> muesste tcpdump nachweisen koennen, dass sie aber tatsaechlich aus dem
anderen
> Ende des Netzwerkstacks rauskommen. (Muss ja. Wenn lynx/wget/curl nicht
alle
> kaputt sind.)
>
> Was ist es fuer ein Kernel, welche Version? Was ist sonst noch am
Netzwerkverkehr
> beteiligt - irgendwelche Paketfilter?
> (Nicht, dass ich auf diese Informationen hin notwendigerweise mit einer
> Antwort dienlich sein kann, aber das sind nun mal die Rahmenbedingungen
unter
> denen der Apache laeuft)
> Passiert es nur bei bestimmten Netzwerkinterfaces oder auch ueber
Localhost?
>
> Du schriebst, dass das Phaenomen von einem Tag auf den anderen auftrat,
und nur
> auf Port 80, nicht aber auf Port 81. Zwei Dinge wuerde ich mir als
moegliche
> Ursachen denken koennen. Entweder ein Paketfilter, der kaputt ist
> (moeglicherweise nach einer langen Zeit aufhoert korrekt zu arbeiten,
nachdem
> irgendein Zaehler uebergelaufen ist), oder ein Kernel, der auf aehnliche
Weise
> zu Bruch geht. In beiden Faellen koennte das Problem nach einem Reboot
> "behoben", oder vielmehr verschwunden sein. Und da ist es dann immer
schade,
> wenn's weg ist, bevor man es moeglichst genau lokalisiert hat - denn unter
> Umstaenden bekommt man nicht so oft die Chance dazu.
>
> Peter
>
>
>
> --------------------------------------------------------------------
> ------
> Apache HTTP Server Mailing List "users-de"
> unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
> sonstige Anfragen an users-de-help@httpd.apache.org
>
> --------------------------------------------------------------------
> ------
>
>
>
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
sonstige Anfragen an users-de-help@httpd.apache.org
--------------------------------------------------------------------------
Re: Fehlerhafte Dateiübertragung
Posted by Peter Pöml <pe...@poeml.de>.
Le 01.08.2010 à 15:04, Ralph ballier a écrit :
> Hallo Peter,
>
> vielen Dank für deine Hinweise.
>
> Ich habe mit tcpdump von einem Testrechner aus über die ansonsten nicht
> benutzte Schnittstelle eth1 mit
>
> tcpdump -i eth1 -w proto
>
> den Datenverkehr bei dem Befehl lynx anton/a65536.pdf mitgeschnitten. Jetzt
> sollte in der Datei proto doch eigentlich Byte für Byte der Datenstrom zu
> sehen sein, oder? Wenn ich die Datei mit dem vi öffne, ist aber kaum etwas
> vernünftiges zu sehen (vi im Binärmodus, rechts werden die druckbaren
> Zeichen ausgegeben. Die Zahlenfolgen werden immer wieder durch nicht
> druckbare Zeichen unterbrochen). Daraus kann ich gar nichts ersehen.
Der mit tcpdump -w mitgeschnittene Datenverkehr laesst sich am besten mit tcpdump -r auswerten. (Oder mit einem aehnlichen Tool wie ethereal/wireshark, welches mit den gleichen Dump-Dateien zurechtkommen sollte.)
Bei tcpdump -r kann man dann verschiedenste Optionen hinzufuegen oder weglassen, um den Datenstrom nach verschiedenen Gesichtspunkten zu ueberblicken oder auch im Detail zu betrachten. Da man den Dump bereits als Datei vorliegen hat, kann man ihn sozusagen so oft anschauen, wie man will, anstatt nur einmal live dabei zu sein und sich dabei vorher fuer eine bestimmte Betrachtungsweise entschieden haben zu muessen.
Allerdings kann es noetig sein, wie jedenfalls jemand erwaehnt hat, den "Capture size" Parameter auf einen grossen Wert zu setzen, weil sonst die eigentlichen transportierten Daten nur unvollstaendig in das Binaerdump-File geschrieben werden. Das weiss ich nicht mehr, kann aber gut sein.
Ich habe vor einiger Zeit einmal ein Beispiel aufgeschrieben, wie ich diese Technik verwendet habe, um einem merkwuerdigen Bug auf die Spur zu kommen. Es war ein richtig spannender Detektiv-Fall: http://lizards.opensuse.org/2008/12/15/longstanding-wiki-problem-fixed/
Der Detailblick auf den Inhalt der einzelnen Pakete des Netzwerkverkehrs fuehrte in dem Fall direkt zur Loesung. Am Ende zeigte sich, dass ein einfacher Programmierfehler vorlag. Er war halt nur schwer zu finden. Wenn er nicht so drastische Konsequenzen gehabt haette, haette sich vielleicht nie jemand auf die Suche nach ihm begeben.
Eine Art, den binaeren Dump anzuschauen, waere: tcpdump -X -r <dumpfile>
Peter
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
sonstige Anfragen an users-de-help@httpd.apache.org
--------------------------------------------------------------------------
Re: Fehlerhafte Dateiübertragung
Posted by Peter Pöml <pe...@poeml.de>.
Hi Ralph,
Le 04.08.2010 à 14:38, Ralph ballier a écrit :
> Ich denke auch, es liegt ein Rootkit vor und ich werde den Rechner völlig
> neu installieren. Interessant wäre es dennoch gewesen, herauszufinden was
> genau passiert. Es sind nur zwei Phänomene, die auffallen:
>
> 1.: Dateien ab einer Länge von ca 64 K werden scheinbar völlig planlos und
> im Umfang nicht reproduzierbar mit Folgen von ASCII-Nullen auf das Vielfache
> ihrer Länge aufgebläht, wenn sie mit einem Browser heruntergeladen werden.
>
> 2.: Es ist nicht möglich, Dateien oder Verzeichnisse anzulegen, deren Namen
> nur aus Ziffern bestehen.
Das zweite Phaenomen macht aber wirklich stutzig. Da ist also noch etwas, das sehr merkwuerdig ist. Die Maschine sollte vielleicht vom Netz genommen und gruendlich untersucht werden, bevor sie neu gestartet / abgeschaltet wird, und vermutlich muss eruiert werden, ob andere Teile der Infrastruktur betroffen sein koennten.
> Zum zweiten gab es schon in den Foren Diskussionen, die letztlich (ratlos)
> in der Vermutung eines Rootkits endeten.
Viel Glueck.
Peter
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
sonstige Anfragen an users-de-help@httpd.apache.org
--------------------------------------------------------------------------
Re: Fehlerhafte Dateiübertragung
Posted by Ralph ballier <ba...@mail.schule.de>.
Ich denke auch, es liegt ein Rootkit vor und ich werde den Rechner völlig
neu installieren. Interessant wäre es dennoch gewesen, herauszufinden was
genau passiert. Es sind nur zwei Phänomene, die auffallen:
1.: Dateien ab einer Länge von ca 64 K werden scheinbar völlig planlos und
im Umfang nicht reproduzierbar mit Folgen von ASCII-Nullen auf das Vielfache
ihrer Länge aufgebläht, wenn sie mit einem Browser heruntergeladen werden.
2.: Es ist nicht möglich, Dateien oder Verzeichnisse anzulegen, deren Namen
nur aus Ziffern bestehen.
Zum zweiten gab es schon in den Foren Diskussionen, die letztlich (ratlos)
in der Vermutung eines Rootkits endeten.
Gruß
Ralph
----------------ursprüngliche Nachricht-----------------
Von: "Rainer Sokoll" r.sokoll@intershop.de
An: users-de@httpd.apache.org
Datum: Wed, 04 Aug 2010 14:24:03 +0200
-------------------------------------------------
> On Wed, Aug 04, 2010 at 02:16:21PM +0200, Ralph ballier wrote:
>
>> ich habe es jetzt mal mit wireshark versucht, aber da ich nicht genau
weiß,
>> wonach ich eigentlich suche, hat mir das auch nicht viel gebracht.
>
> Rechte Maustaste auf ein Paket -> Follow TCP stream.
>
>> Vielen Dank für die Unterstützung, aber ich glaube, die Suche kostet
>> allmählich viel zu viel Zeit.
>
> Zugegebnermaßen ist die Verwendung eines Sniffers eher nicht Aufgabe
> eines Webmasters - andererseits besteht durchaus die Möglichkeit, daß Du
> eine wieauchimmer "gerootete" Maschine hast (wenn ich den Thread aus dem
> Kopf rekapituliere).
> Vielleicht solltest Du Dich mal mit dem Netzwerker Deines geringsten
> Mißtrauens zusammensetzen.
>
> Rainer
>
>
> --------------------------------------------------------------------
> ------
> Apache HTTP Server Mailing List "users-de"
> unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
> sonstige Anfragen an users-de-help@httpd.apache.org
>
> --------------------------------------------------------------------
> ------
>
>
>
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
sonstige Anfragen an users-de-help@httpd.apache.org
--------------------------------------------------------------------------
Re: Fehlerhafte Dateiübertragung
Posted by Rainer Sokoll <r....@intershop.de>.
On Wed, Aug 04, 2010 at 02:16:21PM +0200, Ralph ballier wrote:
> ich habe es jetzt mal mit wireshark versucht, aber da ich nicht genau weiß,
> wonach ich eigentlich suche, hat mir das auch nicht viel gebracht.
Rechte Maustaste auf ein Paket -> Follow TCP stream.
> Vielen Dank für die Unterstützung, aber ich glaube, die Suche kostet
> allmählich viel zu viel Zeit.
Zugegebnermaßen ist die Verwendung eines Sniffers eher nicht Aufgabe
eines Webmasters - andererseits besteht durchaus die Möglichkeit, daß Du
eine wieauchimmer "gerootete" Maschine hast (wenn ich den Thread aus dem
Kopf rekapituliere).
Vielleicht solltest Du Dich mal mit dem Netzwerker Deines geringsten
Mißtrauens zusammensetzen.
Rainer
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
sonstige Anfragen an users-de-help@httpd.apache.org
--------------------------------------------------------------------------
Re: Fehlerhafte Dateiübertragung
Posted by Ralph ballier <ba...@mail.schule.de>.
Hallo,
ich habe es jetzt mal mit wireshark versucht, aber da ich nicht genau weiß,
wonach ich eigentlich suche, hat mir das auch nicht viel gebracht.
Vielen Dank für die Unterstützung, aber ich glaube, die Suche kostet
allmählich viel zu viel Zeit.
Gruß
Ralph
----------------ursprüngliche Nachricht-----------------
Von: "Rainer Sokoll" r.sokoll@intershop.de
An: users-de@httpd.apache.org
Datum: Mon, 02 Aug 2010 09:40:16 +0200
-------------------------------------------------
> On 01.08.2010 15:04, Ralph ballier wrote:
>
> Moin,
>
>> tcpdump -i eth1 -w proto
>>
>> den Datenverkehr bei dem Befehl lynx anton/a65536.pdf mitgeschnitten.
>> Jetzt
>> sollte in der Datei proto doch eigentlich Byte für Byte der Datenstrom
zu
>> sehen sein, oder? Wenn ich die Datei mit dem vi öffne, ist aber kaum
etwas
>> vernünftiges zu sehen (vi im Binärmodus, rechts werden die druckbaren
>> Zeichen ausgegeben. Die Zahlenfolgen werden immer wieder durch nicht
>> druckbare Zeichen unterbrochen). Daraus kann ich gar nichts ersehen.
>
> vim im Binär-Mode ist auch eher was für pöhse Häxxorz ;-)
> Menschen wie Du und ich laden die Datei in wireshark.
> Tipp: dem tcpdump noch die snaplength (-s) mitgeben, ansonsten siehst Du
> nicht den payload.
> Wahrscheinlich, aber nicht zwingend, ist es bei Dir -s 1500.
>
> HTH,
> Rainer
>
>
> --------------------------------------------------------------------
> ------
> Apache HTTP Server Mailing List "users-de"
> unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
> sonstige Anfragen an users-de-help@httpd.apache.org
>
> --------------------------------------------------------------------
> ------
>
>
>
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
sonstige Anfragen an users-de-help@httpd.apache.org
--------------------------------------------------------------------------
Re: Fehlerhafte Dateiübertragung
Posted by Rainer Sokoll <r....@intershop.de>.
On 01.08.2010 15:04, Ralph ballier wrote:
Moin,
> tcpdump -i eth1 -w proto
>
> den Datenverkehr bei dem Befehl lynx anton/a65536.pdf mitgeschnitten. Jetzt
> sollte in der Datei proto doch eigentlich Byte für Byte der Datenstrom zu
> sehen sein, oder? Wenn ich die Datei mit dem vi öffne, ist aber kaum etwas
> vernünftiges zu sehen (vi im Binärmodus, rechts werden die druckbaren
> Zeichen ausgegeben. Die Zahlenfolgen werden immer wieder durch nicht
> druckbare Zeichen unterbrochen). Daraus kann ich gar nichts ersehen.
vim im Binär-Mode ist auch eher was für pöhse Häxxorz ;-)
Menschen wie Du und ich laden die Datei in wireshark.
Tipp: dem tcpdump noch die snaplength (-s) mitgeben, ansonsten siehst Du
nicht den payload.
Wahrscheinlich, aber nicht zwingend, ist es bei Dir -s 1500.
HTH,
Rainer
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
sonstige Anfragen an users-de-help@httpd.apache.org
--------------------------------------------------------------------------