httpd-users-de mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph ballier <ball...@mail.schule.de>
Subject Re: Fehlerhafte Dateiübertragung
Date Sun, 01 Aug 2010 13:04:32 GMT
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
--------------------------------------------------------------------------


Mime
View raw message