Server sloopt .zip en .rar files?

[TommyGun]

Ik heb echt een vreemd probleem. Sinds enkele maanden worden .zip en .rar files die ik naar mijn server upload corrupt. Maakt niet uit of ik ze upload via HTTP, FTP of SFTP. Ik dacht dat dit voornamelijk gebeurde met archieven waarin .exe files zaten, maar dat is niet zo.

* Installer 1 die ik zelf rar en upload -> corrupt
* Installer 1 weer proberen maar nu in .zip formaat -> corrupt
* Installer 2 die ik zelf rar en upload -> niet corrupt
* Installer 3 die ik zelf rar en upload -> corrupt
* Map met images die ik zelf rar en upload -> niet corrupt

Deze problemen had ik met een oude WinRar versie, maar nu ook met een nieuwe genaamd WinRar Golden Edition of iets in die richting, dus daar lijkt het niet aan te liggen. Het vreemde is dat de archieven lokaal totaal geen problemen geven, het is pas nadat ik ze geupload en weer gedownload heb. WinRar zelf lijkt hier dus weinig mee te maken te hebben.

Ik heb iemand van msn ook al deze archieven van mijn server laten downloaden, en precies dezelfde resultaten als die ik heb. Dus ik denk; laat ik het eens op RapidShare en MegaUpload proberen, nou gedaan, zelf gedownload en ook diegene op MSN weer, en ze werken perfect. Upload ik ze vervolgens naar mijn server zijn ze weer corrupt.

Vervolgens eens enkele kant-en-klare archieven gedownload, en als ik die upload dan werken ze soms wel en soms niet, maar dan werken ze vaker dan als ik ze 'zelf maak' lijkt het, maar dat kan puur toeval zijn. SFV Checker zegt dat deze archieven gewoon juist zijn, maar ik krijg toch echt telkens deze (een en dezelfde) melding bij al die corrupte archieven; Unexpected end of archive.



Volgens mij zit er totaal geen logica in, ook niet qua grootte van het archief of de content ervan. Ik kan ook totaal niks vinden in de logs. In eerste instantie dacht ik dat snort of snortsam zaten te kloten maar die geven niks aan. Lijkt me sterk dat dit gebeurd omdat ik lokaal naar mijn server upload, aangezien deze thuis staat. .tar files die ik op de server gebruik voor het installeren van applicaties geven nooit problemen.

Ik ben niet van plan om software zoals 7zip en dergelijke te gaan testen, omdat ik er vrijwel zeker van ben dat dit aan de server ligt. OS = CentOS 4 (ClarkConnect), Kernel 2.6.9-27.ccsmp (SMP).

Ik wordt hier zwaak gek van, iemand tips of suggesties? B.v.d

[CyBeR]

Url en MD5sum?

[TommyGun]

CyBeR schreef op woensdag 28 maart 2007 @ 01:50:
Url en MD5sum?

[root@gateway ~]# md5sum -c rarfile.rar
md5sum: rarfile.rar: no properly formatted MD5 checksum lines found

Maar dat is logisch toch omdat ik ze zelf heb gemaakt en geen MD5 heb meegegeven? Of zit ik dan totaal fout.

[ Voor 18% gewijzigd door TommyGun op 28-03-2007 01:58 ]

[CyBeR]

Ik bedoel, wat is de url van zo'n file die corrupt raakt. En een MD5 checksum maak je zonder -c. Liefst een zip trouwens. Rar is zo kansloos

[ Voor 19% gewijzigd door CyBeR op 28-03-2007 02:01 ]

[TommyGun]

CyBeR schreef op woensdag 28 maart 2007 @ 01:58:
Ik bedoel, wat is de url van zo'n file die corrupt raakt. En een MD5 checksum maak je zonder -c.

Checksum van een corrupte file;

[root@gateway 1]# md5sum winrar.rar
41854f353a5b1b7c28becfdd9b03096f winrar.rar

Wat ik nou zeg klinkt waarschijnlijk heel vreemd, maar het lijkt alleen te gebeuren met archieven die niet geheel legale content (software) bezitten, want een archief van bijvoorbeeld uTorrent, trialversie van WinRar en nog wat freeware krijg ik met geen mogelijkheid kapot. Geprobeerd ze te combineren, er zooi bij te gooien maar zelfs dan nog niet.

De files in de rars die corrupt gaan zitten geen virussen ofzo, als ik ze scan zijn ze clean en nogmaals, op mijn pc lokaal doen ze het goed, maar zodra ik die upload en ze er weer af haal zijn ze corrupt. Ik ga hier natuurlijk geen illegale links plaatsen dus dit wordt lastig lijkt het wel . Ik begin er ook steeds minder van te snappen.

Edit; eenzelfde .exe maar nu als zip, ook corrupt natuurlijk;

md5sum zip.zip
432cb3da0eef8cb46cdfa5cb843bf891 zip.zip

Edit; ik rar een file, rename deze naar blaat.txt, upload, download, rename naar .rar en corrupt.
Ook geprobeerd met blaat.tommy en ook corrupt.

[ Voor 15% gewijzigd door TommyGun op 28-03-2007 02:14 ]

[CyBeR]

Mja, heen en weer getest en ik krijg er geen foute bit uit dus...

[TommyGun]

CyBeR schreef op woensdag 28 maart 2007 @ 03:25:
Mja, heen en weer getest en ik krijg er geen foute bit uit dus...

Heel vreemd idd, de rars die hier en bij 2 mensen die ik verder heb gevraagd te testen niet werken, werken bij CyBeR perfect. Ik snap er de *scheldwoorden* helemaal niks meer van. Vanaf andere schijven in mijn pc geprobeerd, logboeken van mijn pc en de server gechecked maar niks te vinden.

[ Voor 13% gewijzigd door TommyGun op 28-03-2007 03:29 ]

[Pim.]

Laat eens zien wat de MD5sum is van het bestand voor dat je het upload en nadat het op je server staat ??
Volgens jou ligt daar het probleem.

[TrailBlazer]

het lijkt er inderdaad op dat er ergens na de TCP laag fout gaat. Er zit op de TCP laag wel een errorcorrectie maar daarboven niet. Het kan overigens best zijn dat je plaatjes ook corrupt zijn maar dat het geen zichtbare schade oplevert. IK had hetzelfde met de wireless kaart van mijn Dell laptop. HTML en dergelijk ging allemaal prima zo op het eerste gezicht. Alleen alle zip/rar waren kapot omdat er in die files nog een interne CRC check zit.

[Pim.]

Zou kunnen maar dan zou Tommygun ook corrupte files moeten hebben.
hij zal het stap voor stap moeten uit zoeken, eerst kijken of er iets kapot gaan bij de upload, zo nee, kijken naar de HD en geheugen van de bak (zou het vaker voor moeten komen) zo nee, kijken naar de software die gebruikt wordt om de files te maken.. enz enz (wordt vast wel duidelijk)

[user109731]

Doet me erg denken aan deze post van dion_b: dion_b in "Welk filesystem voor een datapartitie in..."
Dit gaan dan wel over de Windows driver, en zo te zien ligt het probleem ergens anders, maar ik vond het wel opvallend... Probeer iig het probleem steeds verder te isoleren zoals Pim. al aangeeft.

[ Voor 39% gewijzigd door user109731 op 28-03-2007 10:24 ]

[TrailBlazer]

Pim. schreef op woensdag 28 maart 2007 @ 10:12:
Zou kunnen maar dan zou Tommygun ook corrupte files moeten hebben.
hij zal het stap voor stap moeten uit zoeken, eerst kijken of er iets kapot gaan bij de upload, zo nee, kijken naar de HD en geheugen van de bak (zou het vaker voor moeten komen) zo nee, kijken naar de software die gebruikt wordt om de files te maken.. enz enz (wordt vast wel duidelijk)

de vraag is natuurlijk hoe zie je of een file corrupt is. MD5 is daar de enige betrouwbare methode voor. Je kan ook even een bestand via het loopback adres naar jezelf ftp'en om te kijken of de nic het probleem is of de netwerkkaart.

[AirX]

Misschien brak geheugen in je PC/server? Heb ik ook een keer in mijn server gehad: één brak reepje en de server bleef gewoon lekker draaien, maar wel allemaal vreemde dingen met compilen en overkopieren van bestanden. Kapotte reepje vervangen en alle problemen opgelost .
Met Memtest86+ van www.memtest.org kun je je geheugen testen.

[HJR]

er is ook nog een probleem met de nvidia nforce4 chipset (amd64/opteron) en 4 gb memory of meer onder linux. dit is een bug in de nvidia chipset en ze zijn bezig met een update. dus als je 4 gb memory hebt en die chipset, kan dat dus ook het probleem zijn.

[TommyGun]

Nouja gisteren veel getest met CyBeR en telkens dezelfde md5 hashes, daar is totaal niks vreemds aan te zien. (Verschillende methodes geprobeerd). Tja als ik upload naar RapidShare / MegaUpload of wat dan ook is alles gewoon goed. Misschien inderdaad iets op de server wat betreft hdd / ram maar wel erg vreemd dat alleen archieven er last van hebben, en mp3's, images, documenten niet.

HJR; ik heb een Dell PowerEdge 6450 (8601F0J) met idd 4 GB maar lijkt me sterk dat die een nForce 4 chipset heeft. (Bak is van 2001 of 2002).

AirX; brak geheugen, tja, enige tijd geleden wel 4 extra reepjes geplaatst maar daarvoor had ik het ook al. Zitten nu totaal 8 reepjes in. Memtest ken ik ja, maar deze bak heb ik liever niet down tot ik ga verhuizen over enkele maanden.

Pim / TrailBlazer; er zitten 4 harde schijven in, van elk 37 GB en 10.000 RPM. Dit in een RAID 5 opstelling aan een 'echte' kaart, geen software RAID geneuzel dus. Maar dan zou ik toch iets moeten vinden in dmesg / messages en dergelijke? Staat echt niks in wat betreft dit probleem.

Indien gewenst kan ik hier wel enkele logs posten, zo ook de Protocol Statistics.

[ Voor 3% gewijzigd door TommyGun op 28-03-2007 11:01 ]

[killercow]

HJR schreef op woensdag 28 maart 2007 @ 10:45:
er is ook nog een probleem met de nvidia nforce4 chipset (amd64/opteron) en 4 gb memory of meer onder linux. dit is een bug in de nvidia chipset en ze zijn bezig met een update. dus als je 4 gb memory hebt en die chipset, kan dat dus ook het probleem zijn.

offtopic:
Heb je hier wat meer info over?
Als mijn k8we onbetrouwbare results terug kan geven wil ik graag meer info hebben.

[Olaf van der Spek]

TommyGun schreef op woensdag 28 maart 2007 @ 01:45:
Maakt niet uit of ik ze upload via HTTP, FTP of SFTP.

En downloaden, hoe doe je dat (app/protocol)?
Je zou eens met een binary diff tool of hex editor kunnen kijken hoeveel bytes er nou niet kloppen en of er iets 'speciaals' met die bytes aan de hand is.

[alx]

AirX schreef op woensdag 28 maart 2007 @ 10:23:
Misschien brak(ke) geheugen(timings) in je PC/server? Heb ik ook een keer in mijn server gehad: [...]

Dit kan ik bevestigen als mogelijke oorzaak. Ik had een keer de mem timings te strak aangetrokken aan de kant van het versturen over een lokaal net en toen zijn er ook enkele bestanden corrupt geraakt uit enkele GBs aan data transfer. Bij mij crashte het systeem ook af en toe. Zijn beide systemen volledig stabiel?

Ik zou voorzichtig zijn met conclusies te trekken uit tests als:

TommyGun schreef op woensdag 28 maart 2007 @ 01:45:
[...]
* Installer 1 die ik zelf rar en upload -> corrupt
* Installer 1 weer proberen maar nu in .zip formaat -> corrupt
* Installer 2 die ik zelf rar en upload -> niet corrupt
* Installer 3 die ik zelf rar en upload -> corrupt
* Map met images die ik zelf rar en upload -> niet corrupt
[...]

Als het een geheugen (of ander hardware) probleem is, kan je iedere keer weer andere resultaten krijgen uit een test als gequote. Heb je dat 1x getest of meerdere keren dezelfde resultaten gehad bij bestanden die in dezelfde orde van grootte zijn?

[TommyGun]

Najah het lijkt zo dat als eenmaal een rar corrupt raakt dat deze dan elke keer corrupt raakt. Eentje die niet corrupt raakt die blijft ook niet corrupt, hoe vaak ik die ook upload. Van dezelfde grootte heb ik ongeveer een beetje getest, maarja. Timings afstellen en al dat geneuzel doe ik niet, bak draait ook al 60 dagen stabiel dus hardware lijkt me sterk.

[Olaf van der Spek]

TommyGun schreef op woensdag 28 maart 2007 @ 18:11:
Najah het lijkt zo dat als eenmaal een rar corrupt raakt dat deze dan elke keer corrupt raakt. Eentje die niet corrupt raakt die blijft ook niet corrupt, hoe vaak ik die ook upload. Van dezelfde grootte heb ik ongeveer een beetje getest, maarja. Timings afstellen en al dat geneuzel doe ik niet, bak draait ook al 60 dagen stabiel dus hardware lijkt me sterk.

Maar raakt die nu tijdens het uploaden corrupt of tijdens het downloaden?

[TommyGun]

Olaf van der Spek schreef op woensdag 28 maart 2007 @ 20:20:
[...]

Maar raakt die nu tijdens het uploaden corrupt of tijdens het downloaden?

Hm hoe test ik dit? Uploaden via HTTP en daarna via FTP en SCP proberen terug te halen, kijken welke corrupt zijn en welke niet?

[Olaf van der Spek]

TommyGun schreef op woensdag 28 maart 2007 @ 20:55:
[...]


Hm hoe test ik dit? Uploaden via HTTP en daarna via FTP en SCP proberen terug te halen, kijken welke corrupt zijn en welke niet?

md5sum op de server draaien. Als dat niet kan kun je inderdaad een versleuteld protocol gebruiken om te downloaden en te uploaden en zien of dat iets uitmaakt.

[TommyGun]

Olaf van der Spek schreef op woensdag 28 maart 2007 @ 20:58:
[...]

md5sum op de server draaien. Als dat niet kan kun je inderdaad een versleuteld protocol gebruiken om te downloaden en te uploaden en zien of dat iets uitmaakt.

Zie CyBeR in "Server sloopt .zip en .rar files?" en de eerste paar regels van TommyGun in "Server sloopt .zip en .rar files?"

[ Voor 8% gewijzigd door TommyGun op 28-03-2007 21:07 ]

[Olaf van der Spek]

TommyGun schreef op woensdag 28 maart 2007 @ 21:07:
[...]


Zie CyBeR in "Server sloopt .zip en .rar files?" en de eerste paar regels van TommyGun in "Server sloopt .zip en .rar files?"

Ok. Dan blijft Olaf van der Spek in "Server sloopt .zip en .rar files?" staan.

[TommyGun]

Olaf van der Spek schreef op woensdag 28 maart 2007 @ 22:07:
[...]

Ok. Dan blijft Olaf van der Spek in "Server sloopt .zip en .rar files?" staan.

Goed ik zal eens een archief uploaden die altijd corrupt raakt als ik hem weer via HTTP download. Zal hem nu eens proberen te downloaden via FTP en SCP. Geef me een momentje.

Edit;

File geupload via mijn uploader (HTTP), vervolgens weer gedownload vanaf m'n uploader = damaged.
Gedownload via SCP = niet damaged.
Gedownload via FTP = niet damaged.

Nogmaals proberen via HTTP = damaged.
Nogmaals proberen via SCP = niet damaged.
Nogmaals proberen via FTP = niet damaged.

Edit 2;

Het begint er dus op te lijken dat er idd iets fout gaat bij de transport / TCP / whatever laag, en de archieven niet corrupt raken.

Nogmaals, 2 andere personen die deze rar downloaden krijgen ook de Unexpected end of archive melding. CyBeR kreeg dat telkens niet, maar misschien handig om te weten; mijn testpersonen () draaien Windows en gebruiken WinRar, CyBeR niet.

Volgens CyBeR is zijn applicatie en/of OS juist gevoeliger voor corrupte archieven, maar de resultaten lijken het tegenovergestelde te concluderen.

[ Voor 53% gewijzigd door TommyGun op 28-03-2007 22:37 ]

[Olaf van der Spek]

TommyGun schreef op woensdag 28 maart 2007 @ 22:29:
Het begint er dus op te lijken dat er idd iets fout gaat bij de transport / TCP / whatever laag, en de archieven niet corrupt raken.

Nogmaals, 2 andere personen die deze rar downloaden krijgen ook de Unexpected end of archive melding. CyBeR kreeg dat telkens niet, maar misschien handig om te weten; mijn testpersonen () draaien Windows en gebruiken WinRar, CyBeR niet.

Volgens CyBeR is zijn applicatie en/of OS juist gevoeliger voor corrupte archieven, maar de resultaten lijken het tegenovergestelde te concluderen.

Unexpected end of archive klinkt bijna als een te korte file. Klopt de file size wel na het downloaden?

Je zou eens met een binary diff tool of hex editor kunnen kijken hoeveel bytes er nou niet kloppen en of er iets 'speciaals' met die bytes aan de hand is.

[TommyGun]

Olaf van der Spek schreef op woensdag 28 maart 2007 @ 22:43:
[...]

Unexpected end of archive klinkt bijna als een te korte file. Klopt de file size wel na het downloaden?

[...]

Als ik 'm rar is deze 2,98mb. Eenmaal geupload geeft de uploader 3mb aan, maar geen idee of dat ding nauwkeurig is. Download ik hem dan is deze 2,97mb. Dus scheelt maar heel erg weinig, maar dat zou het kunnen zijn ja. Zal even tooltje runnen, moment.

Edit; zoiets als http://www.chmaas.handsha.../xvi32/xvi32.htm#download? En dan? Een hoop mooie tekentjes, maar hoe doe ik dat verder.

[ Voor 13% gewijzigd door TommyGun op 28-03-2007 22:51 ]

[lordsnow]

Er is ook een probleem met de nVidia firewall die in sommige nVidia chipsets ingebakken zit - daar raken soms grote bestanden corrupt tijdens up- of download. Dus als je server een nVidia chipset heeft zou ik eens daar naar kijken. De nVidia firewall kan je disablen door de software/driver/whatever (nvidia Force Ware Network Access Manager) daarvoor te deinstalleren via je Add or Remove Programs (NL: Software).

Zie ook:
Downloads corrupt
Waarom kan ik niks downloaden en installeren
[Asus A8N-E] Internet verbinding niet stabiel?

[ Voor 23% gewijzigd door lordsnow op 28-03-2007 23:06 ]

[TommyGun]

lordsnow schreef op woensdag 28 maart 2007 @ 22:57:
Er is ook een probleem met de nVidia firewall die in sommige nVidia chipsets ingebakken zit - daar raken soms grote bestanden corrupt tijdens up- of download. Dus als je server een nVidia chipset heeft zou ik eens daar naar kijken. De nVidia firewall kan je disablen door de software/driver/whatever daarvoor te deinstalleren via je Add or Remove Programs (NL: Software).

Grote bestanden.... tja 3mb is best pittig natuurlijk . Nee zonder gein, ik download zonder problemen files van honderden zo niet duizenden mb's, zonder problemen. Het is echt iets tussen 'mij' en mijn server. (Mijn werkstation heeft overigens geen nVidia chipset, maar een Intel. Mobo is een P4P800 Deluxe).

[Daos]

Misschien is het overbodig: Ftp kent een onderscheid tussen ascii en binary. binary doet niets en ascii verandert de regeleinden indien nodig (zoals bij tekstbestand van unix naar windows).

[Olaf van der Spek]

TommyGun schreef op woensdag 28 maart 2007 @ 22:48:
Als ik 'm rar is deze 2,98mb. Eenmaal geupload geeft de uploader 3mb aan, maar geen idee of dat ding nauwkeurig is. Download ik hem dan is deze 2,97mb. Dus scheelt maar heel erg weinig, maar dat zou het kunnen zijn ja. Zal even tooltje runnen, moment.

Zou kunnen? Kom op zeg.
Als de grootte al niet klopt, weet je zeker dat het corrupt is.
De exacte grootte in bytes moet je ook makkelijk kunnen achterhalen, zeker op je eigen systeem.

[ Voor 9% gewijzigd door Olaf van der Spek op 29-03-2007 13:41 ]

[TommyGun]

Olaf van der Spek schreef op donderdag 29 maart 2007 @ 13:37:
[...]

Zou kunnen? Kom op zeg.
Als de grootte al niet klopt, weet je zeker dat het corrupt is.
De exacte grootte in bytes moet je ook makkelijk kunnen achterhalen, zeker op je eigen systeem.

Zou kunnen ja, ik ontkracht dus niks.

De exacte grootte op de server is 3.125.665mb. Vreemd? Op mijn werkstation was deze nog 2,98mb.

[Olaf van der Spek]

TommyGun schreef op donderdag 29 maart 2007 @ 14:29:
De exacte grootte op de server is 3.125.665mb. Vreemd? Op mijn werkstation was deze nog 2,98mb.

Dat werkstation heeft toch ook wel een manier om de exacte grootte weer te geven?

[TommyGun]

Olaf van der Spek schreef op donderdag 29 maart 2007 @ 15:24:
[...]

Dat werkstation heeft toch ook wel een manier om de exacte grootte weer te geven?

Hoe? Ik ken alleen rechtermuisknop -> eigenschappen en kijken wat er in FlashFXP onder de kolom size staat. En die geven beide aan 2,98mb. De .exe de ik rar is 3,02mb.

[Olaf van der Spek]

TommyGun schreef op donderdag 29 maart 2007 @ 15:29:
[...]


Hoe? Ik ken alleen rechtermuisknop -> eigenschappen en kijken wat er in FlashFXP onder de kolom size staat. En die geven beide aan 2,98mb. De .exe de ik rar is 3,02mb.

In Windows Explorer gewoon Eigenschappen.
Gisteren was er nog een 2,97 mb ("Download ik hem dan is deze 2,97mb.").

[TommyGun]

Olaf van der Spek schreef op donderdag 29 maart 2007 @ 15:33:
[...]

In Windows Explorer gewoon Eigenschappen.
Gisteren was er nog een 2,97 mb ("Download ik hem dan is deze 2,97mb.").

Nope, lokaal na het archiveren is deze 2,98mb. Na het downloaden van de server is deze plots 2,97mb.

Edit; Windows Explorer geeft aan 3.053 KB aan, dus lokaal na het archiveren.

Na het opnieuw downloaden is dit 3.052 KB volgens Windows Explorer.

Op de server dus nogmaals 3.125.665 MB volgens WinSCP.

[ Voor 25% gewijzigd door TommyGun op 29-03-2007 15:39 ]

[Olaf van der Spek]

TommyGun schreef op donderdag 29 maart 2007 @ 15:37:
Edit; Windows Explorer geeft aan 3.053 KB aan, dus lokaal na het archiveren.

Tussen haakjes staat toch de exacte waarde?

[TommyGun]

Olaf van der Spek schreef op donderdag 29 maart 2007 @ 15:42:
[...]

Tussen haakjes staat toch de exacte waarde?

Ik vat je even niet. Even samenvatten;

Rechtermuis knop @ file -> eigenschappen -> 2,98MB direct na het archieveren op WinXP machine.
Vervolgens upload en download ik hem terug naar mijn WinXP machine en dan geeft ie aan 2,97MB.

Windows Verkenner geeft de file van 2,98mb aan als 3.053 KB.
Windows Verkenner geeft de file van 2,97mb aan als 3.052 KB.

[justmental]

Heb je gevalideerd dat je de ftp's echt binary doet?
Het klinkt wellicht lullig, maar de symptomen lijken die kant op te wijzen.

[Madshark]

HJR; ik heb een Dell PowerEdge 6450 (8601F0J) met idd 4 GB maar lijkt me sterk dat die een nForce 4 chipset heeft. (Bak is van 2001 of 2002).

Ahh, de good old PE 6400
Ik denk dat je probleem misschien wel in je PERC SCSI controller driver zit. Doe daar maar eens een google op, latere PERC drivers die backwardcompatible zouden moeten zijn geven wel eens corruptie problemen ivm verkeerde/slechte cache timings. Probeer eens een andere driver?

[TommyGun]

justmental schreef op donderdag 29 maart 2007 @ 15:56:
Heb je gevalideerd dat je de ftp's echt binary doet?
Het klinkt wellicht lullig, maar de symptomen lijken die kant op te wijzen.

Euh hoe bedoel je dit? Bij WinSCP heb ik filetransfer altijd standaard op Automatic staan. Zie image.



FlashFXP zegt in de log;

code:

[R] RETR file.rar
[R] 150 Opening BINARY mode data connection for file.rar (3125665 bytes)
[R] 226 Transfer complete.
Transferred: file.rar 2,98 MB in 0,53 seconds (5.748,4 KB/s)
Transfer queue completed
Transferred 1 file totaling 2,98 MB in 2,56 seconds (5.748,4 KB/s)

[TrailBlazer]

je zou ook met dd eens een paar hele grote files kunnen maken met alleen maar 1 of 0 erin. Kijken of dat ook gekke dingen oplevert.

[TommyGun]

Madshark schreef op donderdag 29 maart 2007 @ 16:03:
[...]

Ahh, de good old PE 6400
Ik denk dat je probleem misschien wel in je PERC SCSI controller driver zit. Doe daar maar eens een google op, latere PERC drivers die backwardcompatible zouden moeten zijn geven wel eens corruptie problemen ivm verkeerde/slechte cache timings. Probeer eens een andere driver?

De PE 6400 is heel anders dan de PE 6450 hoor

De onboard controller gebruik ik niet, zit een losse kaart 64bits kaart in met 256mb ram erop geprikt.

code:

scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs

code:

-   RAID bus controller: American Megatrends Inc. MegaRAID
-   (2x) SCSI storage controller: Adaptec AIC-7899P U160/m
-   SCSI storage controller: QLogic Corp. ISP12160 Dual Channel Ultra3 SCSI Processor

SCSI Devices    
-   DELL 1x4 U2W SCSI BP (Processor)
-   MegaRAID LD 0 RAID5 104G (Direct-Access)

[ Voor 13% gewijzigd door TommyGun op 29-03-2007 16:09 ]

[2xdehelft]

Ik heb dit probleem een tijd terug ook gehad. Dit gebeurde bij alle rar's die ik van internet downloade (via FTP) Destijds bleek het probleem in Norton Antivirus te zitten (ik weet nu wel beter dan Norton troep te installeren)

Probeer eens alle eventuele antivirus of antispywaretools uit te schakelen. Bij mij was trouwens het uitschakelen van de virusscanner niet voldoende. Ik moest deze echt deinstalleren voordat het probleem weg was.

[ Voor 18% gewijzigd door 2xdehelft op 29-03-2007 16:11 ]

[TommyGun]

2xdehelft schreef op donderdag 29 maart 2007 @ 16:10:
Ik heb dit probleem een tijd terug ook gehad. Dit gebeurde bij alle rar's die ik van internet downloade (via FTP) Destijds bleek het probleem in Norton Antivirus te zitten (ik weet nu wel beter dan Norton troep te installeren)

Probeer eens alle eventuele antivirus of antispywaretools uit te schakelen. Bij mij was trouwens het uitschakelen van de virusscanner niet voldoende. Ik moest deze echt deinstalleren voordat het probleem weg was.

Nogmaals, denk inmiddels voor de 5e keer, dit gebeurd ook bij een klasgenoot van me en iemand anders die ik op MSN heb. Virusscanner / anti-spyware whatever lijkt me dus sterk. Ik draai overigens McAfee 8 en Ad-Aware. Daarbij geven die logs niks aan van blokkerende rotzooi. Deinstalleren doe ik sowieso niet, omdat me dit echt te ver zoeken lijkt.

[ Voor 16% gewijzigd door TommyGun op 29-03-2007 16:12 ]

[SA007]

Hheb je https op je webserver? Daar kan het ook aan liggen...
Misschien is je webserver gaar, dan zou het op https namelijk ook fout gaan.

Dat het ftp goed gaat en met http niet is juist in strijd met dat het tcp zou zijn, http en ftp zijn nl beide non-encryped, ofwel, je hele data gaat er onversleuteld overheen, terwijl bij scp het juist wel extra versleutels overheen gaat.

Misschien kan je anders eens rcp proberen, is een niet-versleutelde versie van scp.

[TommyGun]

TrailBlazer schreef op donderdag 29 maart 2007 @ 16:08:
je zou ook met dd eens een paar hele grote files kunnen maken met alleen maar 1 of 0 erin. Kijken of dat ook gekke dingen oplevert.

Grote files transfer ik al genoeg. ISO, AVI, VOB, TAR etc. Werken allemaal goed, wel met FTP / SCP though.

[TommyGun]

SA007 schreef op donderdag 29 maart 2007 @ 16:13:
Hheb je https op je webserver? Daar kan het ook aan liggen...
Misschien is je webserver gaar, dan zou het op https namelijk ook fout gaan.

Nopes, die uploader is gewoon HTTP met een simpel SQL user database systeempje.

Dat het ftp goed gaat en met http niet is juist in strijd met dat het tcp zou zijn, http en ftp zijn nl beide non-encryped, ofwel, je hele data gaat er onversleuteld overheen, terwijl bij scp het juist wel extra versleutels overheen gaat.

Hier ben ik sinds kort bekend mee ja, daarom vindt ik het ook zo vreemd.

Misschien kan je anders eens rcp proberen, is een niet-versleutelde versie van scp.

Ik zal kijken of ik hier later vanavond tijd / zin voor kan maken.

[masq]

TommyGun schreef op woensdag 28 maart 2007 @ 22:29:
[...]
File geupload via mijn uploader (HTTP), vervolgens weer gedownload vanaf m'n uploader = damaged.
Gedownload via SCP = niet damaged.
Gedownload via FTP = niet damaged.

Nogmaals proberen via HTTP = damaged.
Nogmaals proberen via SCP = niet damaged.
Nogmaals proberen via FTP = niet damaged.

Als het via SCP en FTP wel goed gaat maar via HTTP niet, dan zou ik ook eens onderzoeken of je webserver niet op of andere manier de schuldige is.

Als je download via een script (dus niet direct url/naar/bestand.zip) dan zou ik dat al helemaal eens goed bekijken.

[TommyGun]

masq schreef op donderdag 29 maart 2007 @ 16:18:
[...]


Als het via SCP en FTP wel goed gaat maar via HTTP niet, dan zou ik ook eens onderzoeken of je webserver niet op of andere manier de schuldige is.

Als je download via een script (dus niet direct url/naar/bestand.zip) dan zou ik dat al helemaal eens goed bekijken.

Geprobeerd zowel via http://url.com/files/1/file.rar als via de "My Files" list de file aan te klikken. Maakt geen verschil. Tja hoe check ik of de webserver de schuldige is? In de httpd error logs kan ik niks vinden die dit probleem zou aanduiden.

[Verwijderd]

asjeblieft zeg, mag het nivo iets hoger hier?

als de filesize in bytes al niet klopt dan is de file al corrupt. md5sums en dergelijke doen er dan al niet toe. ook mag ik hopen dat de TS weet wat een md5sum is en daarom stel ik het volgende voor:

stap 1: maak een zip/rar archief.
stap 2: maak van dit bestand een md5sum
stap 3: noteer de groote van dit bestand in BYTES, dus niet kb of mb nee het exacte aantal bytes. dit kun je vinden als je rechts klikt op het bestand en dan properties kiest. achter 'size' waar de groote in MB's of KB's staat, staat tussen haakjes het aantal bytes. noteer dit.

stap 4: upload het bestand naar je server via FTP/HTTP/whatever.
stap 5: login op je server via bijvoorbeeld PuttySSH en ga naar de directory waar je dit bestand hebt opgeslagen op je server.
stap 6: type in je bash het command 'ls -als'. in de 6e kolom, tussen de groupnaam en de datum van de laaste wijziging staat het aantal bytes. dit nummer moet exact kloppen met dat wat je eerder hebt genoteerd bij stap 3. klopt dit niet dan is het bestand corrupt geraakt tijdens het uploaden.
stap 7: type nu in de bash het command 'md5sum [naam van bestand]'. er verschijnt nu een md5sum met daarachter de naam van het bestand wat je hebt ge-sum'd. als dit niet klopt met bij stap 2 genoteerde md5sum dan is het bestand ook corrupt geraakt tijdens de upload.

stap 8: download het bestand van de server via dezelfde weg als dat je bij stap 4 deed. dus download met FTP als je bij stap 4 FTP gebruikte om het bestand te uploaden. door het zelfde programma te gebruiken voor de upload als de download sluit je corruptie door andere programma's uit.
stap 9: ga in de Windows Verkenner naar het ge-downloade bestand en noteer de grote in bytes. klopt deze met de bij stap 3 genoteerde groote. zo niet dan is het bestand in de download corrupt geraakt want in stap 6 hebben we gecontrolleerd dat het bestand even groot op de server is aangekomen.
stap 10: maak een md5sum van het ge-downloade bestand. klopt de md5sum met dat wat je in stap 2 hebt genoteerd? zo niet dan is het bestand corrupt geraakt in de download omdat we bij stap 7 hebben gecontroleerd dat elke byte goed op de server is aangekomen.

als je deze 10 stappen nou herhaalt voor elk van de methodes om te uploaden en downloaden en e.v.t. daarna bijvoorbeeld via FTP uploaden en dan met HTTP downloaden combineerd dan moet je de oorzaak wel kunnen vinden en post die dan weer hier dan kunnen we kijken wat we er aan kunnen doen.

ik zelf gebruike md5summer om onder windows md5sums te maken, te vinden op: http://www.md5summer.org/md5v12005.zip

veel success met "basic troubleshooting for file transfer corruption issue's".

[Olaf van der Spek]

TommyGun schreef op donderdag 29 maart 2007 @ 15:47:
[...]


Ik vat je even niet. Even samenvatten;

Rechtermuis knop @ file -> eigenschappen -> 2,98MB direct na het archieveren op WinXP machine.

Dan toch maar een screenshot:


Zie je die eerste 8.589.934.592 bytes staan?

[TommyGun]

Olaf van der Spek schreef op donderdag 29 maart 2007 @ 16:41:
[...]

Dan toch maar een screenshot:
[afbeelding]

Zie je die eerste 8.589.934.592 bytes staan?

Ja zag het net inderdaad, maar ik ga zo ff je eerdere post opvolgen.

[TommyGun]

stap 1: archief.rar
stap 2: done, md5 gemaakt en hash is 2bbbc984a5ebaa97b191ba025f65b113
stap 3: 3.125.665 bytes

stap 4: geupload via HTTP
stap 5: Putty -> cd /var/www/html/files/1
stap 6: done, 3125665 bytes (correct)
stap 7: 2bbbc984a5ebaa97b191ba025f65b113 archief.rar (correct)

stap 8: gedownload via HTTP
stap 9: 3.124.635 bytes, dus weer een fractie kleiner
stap 10: done, md5 gemaakt en hash is 41854f353a5b1b7c28becfdd9b03096f (volledig anders)

Probleem treed alleen nog maar op via HTTP. Via FTP en SCP heb ik al uitgesloten, want dan raken ze nooit corrupt, alleen als ik ze via HTTP download.

[ Voor 13% gewijzigd door TommyGun op 29-03-2007 17:00 ]

[Verwijderd]

het gaat dus fout bij het downloaden via HTTP vanaf de server.

welke browser gebruik je? firefox? IE? Opera?
welke webserver gebruik je? Apache waarschijnlijk?
Gebruik je een download script wat het bestand eerst inleest? of gewoon via een directe link naar het bestand in de webroot?

zou kunnen dat een mod voor Apache iets met het bestand uitvreet. we kunnen nu in iedergeval de upload en storage uitsluiten.

[barfieldmv]

Mijn oude pc gaf ook altijd rare problemen bij het rondsturen van bestanden. Na het weg gooien van de kast en het verwijderen van de HD lagen er allemaal weerstandjes/transistortjes in de kast, afgebroken/geroest van het moederbord en netwerk kaart... het kan dus ook een technisch probleem zijn in de kast.


(en damn, je wil niet weten hoeveel tijd het heeft gekost voordat ik dat zag, echt gek werd ik er van)

[TommyGun]

Verwijderd schreef op donderdag 29 maart 2007 @ 17:02:
het gaat dus fout bij het downloaden via HTTP vanaf de server.

welke browser gebruik je? firefox? IE? Opera?
welke webserver gebruik je? Apache waarschijnlijk?
Gebruik je een download script wat het bestand eerst inleest? of gewoon via een directe link naar het bestand in de webroot?

zou kunnen dat een mod voor Apache iets met het bestand uitvreet. we kunnen nu in iedergeval de upload en storage uitsluiten.

Browser is de allernieuwste Firefox, heb wel IE7 dus kan ik nog wel testen. // Edit; zelfde probleem.
Webserver is Apache ja, 2.0 met PHP 4.3.11.
Manier van downloaden; TommyGun in "Server sloopt .zip en .rar files?"

@ hierboven; ik heb 3 disks in mijn werkstation, maakt niet uit naar welke disk ik download. En nogmaals, het is alleen vanaf mijn server, RapidShare / MegaUpload enzo werken wel goed. Dus dat lijkt me allang niet relevant meer.

[ Voor 14% gewijzigd door TommyGun op 29-03-2007 17:07 ]

[user109731]

Niets relevants in /var/log/apache2/*? Wat word daar voor grootte aangegeven in access.log?

[Olaf van der Spek]

TommyGun schreef op donderdag 29 maart 2007 @ 16:11:
@ hierboven; ik heb 3 disks in mijn werkstation, maakt niet uit naar welke disk ik download. En nogmaals, het is alleen vanaf mijn server, RapidShare / MegaUpload enzo werken wel goed. Dus dat lijkt me allang niet relevant meer.

Misschien is het dan een bepaalde header die je server stuurt.
Wat is de URL van het bestand op je server?

Probeer ook eens http://xcc.demon.nl/temp/TommyGun.rar (28 bytes, geen geldige RAR) of http://xcc.demon.nl/temp/TommyGun.zip (zelfde ongeldige RAR, maar nu in een ZIP).

[Verwijderd]

welke modules draait Apache mee, ik vermoed dat 1 van die roet in het eten gooit. check eens in je apache configuratie.

wat je ook kan doen is gzip compressie bij Apache uitzetten al heb ik nog nooit meegemaakt dat daardoor bestanden corrupt raakte maar toch. feitelijk her-compress je een al gecompressed bestand.

[GoTman]

mischien kan je met een netwerk sniffer ook wel wat raars zien. whireshark bijvoorbeeld.

[TommyGun]

Olaf van der Spek schreef op donderdag 29 maart 2007 @ 17:19:
[...]

Misschien is het dan een bepaalde header die je server stuurt.
Wat is de URL van het bestand op je server?

Probeer ook eens http://xcc.demon.nl/temp/TommyGun.rar (28 bytes, geen geldige RAR) of http://xcc.demon.nl/temp/TommyGun.zip (zelfde ongeldige RAR, maar nu in een ZIP).

Eerste is 28 bytes en de tweede 186 bytes.

URL van het bestand is http://www.gamergun.com/files/1/archief.rar
Die 1 is omdat ik user 1 ben op de uploader. (Inmiddels verwijderd, vanwege content).

Verwijderd schreef op donderdag 29 maart 2007 @ 17:21:
welke modules draait Apache mee, ik vermoed dat 1 van die roet in het eten gooit. check eens in je apache configuratie.

wat je ook kan doen is gzip compressie bij Apache uitzetten al heb ik nog nooit meegemaakt dat daardoor bestanden corrupt raakte maar toch. feitelijk her-compress je een al gecompressed bestand.

Zie http://www.gamergun.com/server-info en http://www.gamergun.com/version

Grote prutser schreef op donderdag 29 maart 2007 @ 17:18:
Niets relevants in /var/log/apache2/*? Wat word daar voor grootte aangegeven in access.log?

/var/log/httpd/access_log:

192.168.3.2 - - [29/Mar/2007:16:55:15 +0200] "GET /files/1/archief.rar HTTP/1.1" 200 3127215 "http://www.gamergun.com/myfiles/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3"

[ Voor 55% gewijzigd door TommyGun op 29-03-2007 17:32 ]

[Olaf van der Spek]

TommyGun schreef op donderdag 29 maart 2007 @ 17:27:
[...]


Eerste is 28 bytes en de tweede 186 bytes.

URL van het bestand is http://www.gamergun.com/files/1/archief.rar
Die 1 is omdat ik user 1 ben op de uploader. (Inmiddels verwijderd, vanwege content).

404
Upload anders eens een legale RAR (bijvoorbeeld die van mij) en kijk of het dan wel werkt.
Kijk ook welke headers er verstuurd worden.

En zit er op McAfee geen optie om hem tijdelijk uit te schakelen?

[TommyGun]

Olaf van der Spek schreef op donderdag 29 maart 2007 @ 17:34:
[...]

404
Upload anders eens een legale RAR (bijvoorbeeld die van mij) en kijk of het dan wel werkt.
Kijk ook welke headers er verstuurd worden.

Wow, eindelijk heb ik iets legaals corrupt gekregen http://www.gamergun.com/files/1/PwrMxEn.rar

En zit er op McAfee geen optie om hem tijdelijk uit te schakelen?

Disabled: Access Protection en Buffer Overflow Protction. On Access scanner krijg ik niet uit.

Edit; en plots werkt de file wel. Zal nu eens proberen met bovenstaande ingeschakeld
Edit 2; ingeschakeld en werkt nog steeds.... right

Wat doet die file bij jou?

[ Voor 21% gewijzigd door TommyGun op 29-03-2007 17:39 ]

[user109731]

Hier ook corrupt: unexpected end of archive.

md5sum:
0c8acb11511d3daa0e2e35faf66a50e2 /home/jan/Desktop/PwrMxEn.rar

[TommyGun]

Grote prutser schreef op donderdag 29 maart 2007 @ 17:41:
Hier ook corrupt: unexpected end of archive.

md5sum:
0c8acb11511d3daa0e2e35faf66a50e2 /home/jan/Desktop/PwrMxEn.rar

Hier nu ook weer. Eerste keer corrupt, 2e keer met virusscan uit niet, 3e keer met virusscan aan ook niet, en nu wel weer corrupt met virusscan ook aan. Dus die kan ik uitsluiten, wat ik dus al eerder dacht en zei.

470f14772b265100010eaec716cd274d *PwrMxEn.rar = op mijn WinXP machine

1fea0c20dab8503b6432d026d7da7005 PwrMxEn.rar = op mijn server

[ Voor 13% gewijzigd door TommyGun op 29-03-2007 17:44 ]

[Madshark]

TommyGun schreef op donderdag 29 maart 2007 @ 16:08:
[...]


De PE 6400 is heel anders dan de PE 6450 hoor

Jah, same server, andere case

De onboard controller gebruik ik niet, zit een losse kaart 64bits kaart in met 256mb ram erop geprikt.

code:

scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs

code:

-   RAID bus controller: American Megatrends Inc. MegaRAID
-   (2x) SCSI storage controller: Adaptec AIC-7899P U160/m
-   SCSI storage controller: QLogic Corp. ISP12160 Dual Channel Ultra3 SCSI Processor

SCSI Devices    
-   DELL 1x4 U2W SCSI BP (Processor)
-   MegaRAID LD 0 RAID5 104G (Direct-Access)

Daar was ik ook vanuit gegaan, die losse 64bits kaart is de PERC (PoweredgeExpandableRaidController) waar ik op doelde.

Overiges, om het in heel andere sferen te kijken, wat zit er tussen jouw WS en je server aan firewalls en content checkers ? (op network nivo)

Toevallig geen antivirusfirewall ofzo draaien ? (nee niet op je WS, maar bij je provider of colo van je server)
Ik heb ooit wel eens een halve dag hoofdpijn gehad dat het me niet lukte om GIF bestandjes binnen te krijgen, na uren gezocht te hebben bleek het een update bug geweest te zijn van mijn contentchecking firewall.

[Olaf van der Spek]

Hier niet corrupt. Grootte: 834.152 bytes.
Ik heb hem net nog tien keer gedownload en elke keer dezelfde niet corrupte file.

Maar wat zijn jullie exacte file groottes nou? Daar kun je nog wat aan zien, aan een md5sum niet als er iets mis is.

[ Voor 81% gewijzigd door Olaf van der Spek op 29-03-2007 17:50 ]

[Verwijderd]

core
prefork
http_core
mod_so
mod_access
mod_auth
mod_auth_anon ?maak je gebruik van http logins?
mod_auth_dbm ?met een database backend?
mod_auth_digest
mod_include
mod_log_config
mod_env
mod_mime_magic
mod_cern_meta
mod_expires
mod_deflate ?kan de schuldige zijn?
mod_headers
mod_usertrack ?gebruik je apache based usertracking? waarom niet php sessie's?
mod_setenvif
mod_mime
mod_dav ?gebruik je webDav voor http uploaden? dacht dat je php gebruikte.
mod_status
mod_autoindex
mod_asis
mod_info
mod_dav_fs ? zie opmerking bij mod_dav.
mod_vhost_alias
mod_negotiation
mod_dir
mod_imap ?is je apache ook mail server?
mod_actions
mod_speling
mod_userdir
mod_alias
mod_rewrite ?mod_rewrite weet toch wel dat die van rar's en zip's moet afblijven toch?
mod_proxy ?maak je gebruik van een http proxy via je apache server?
proxy_ftp
proxy_http
proxy_connect
mod_cache ?serveert je server wel de laaste accurate versie van je archief?
mod_suexec
mod_disk_cache ?zie opmerking bij mod_cache.
mod_file_cache
mod_mem_cache
mod_cgi
sapi_apache2
mod_ssl

je gaat met toch niet vertellen dat je al deze modules nodig hebt of niet, schakel alle vet gedrukte modules maar eens uit en kijk of je dan nog problemen hebt. een aantal modules ben ik niet helemaal zeker van maar ik denk dat 1 van deze modules een bewerking doet op de zip of rar file.

[TommyGun]

@ Olaf; het verschilt dus per download en persoon lijkt het wel.

@ Madshark; okay okay

Nee de server staat dus thuis, en hangt direct aan de modem. Daarachter zit pas een switch en ik dus. Er draait verder geen AV op de server, wel Snort en Snortsam. Tenminste, voor zover ik weet, veel zit al standaard in de CC installatie ingebakken. Maniertje om dat te checken?

[ Voor 18% gewijzigd door TommyGun op 29-03-2007 17:57 ]

[Verwijderd]

wat me even te binnen schiet, waarom download je file niet eens op de server? via wget ofzo. connect dan via je loopback dus, 127.0.0.1:80 en kijk of dat wel corrupt raakt.

[TommyGun]

Verwijderd schreef op donderdag 29 maart 2007 @ 17:45:

mod_auth_anon ?maak je gebruik van http logins?
mod_auth_dbm ?met een database backend?
mod_auth_digest
mod_deflate ?kan de schuldige zijn?
mod_usertrack ?gebruik je apache based usertracking? waarom niet php sessie's?
mod_dav ?gebruik je webDav voor http uploaden? dacht dat je php gebruikte.
mod_dav_fs ? zie opmerking bij mod_dav.
mod_imap ?is je apache ook mail server?
mod_rewrite ?mod_rewrite weet toch wel dat die van rar's en zip's moet afblijven toch?
mod_proxy ?maak je gebruik van een http proxy via je apache server?
proxy_ftp
proxy_http
proxy_connect
mod_cache ?serveert je server wel de laaste accurate versie van je archief?
mod_disk_cache ?zie opmerking bij mod_cache.
mod_file_cache
mod_mem_cache

je gaat met toch niet vertellen dat je al deze modules nodig hebt of niet, schakel alle vet gedrukte modules maar eens uit en kijk of je dan nog problemen hebt. een aantal modules ben ik niet helemaal zeker van maar ik denk dat 1 van deze modules een bewerking doet op de zip of rar file.

Naast die uploader draait nog een Invision Power Board forum, en inderdaad die moet ook mail versturen, dus ook een mailservertje. Dat zal denk ik wel het een en ander verklaren. De uploader maakt wel gebruik van mod_rewrite, om dingen zoals upload.php in domein.com/upload te veranderen.

Verder is deze httpd verder niet aangepast door mij wat betreft modules, daar heb ik ook geen verstand van. Die dingen zo uitschakelen doe ik liever niet, ik kan je daar ook weinig toelichting op geven dus.

[Olaf van der Spek]

TommyGun schreef op donderdag 29 maart 2007 @ 17:47:
Nee de server staat dus, en hangt direct aan de modem. Daarachter zit pas een switch en ik dus. Er draait verder geen AV op de server, wel Snort en Snortsam. Tenminste, voor zover ik weet, veel zit al standaard in de CC installatie ingebakken. Maniertje om dat te checken?

Server, dan modem (DSL/kabel?) en dan switch? Hoe kan dat nou?

[TommyGun]

Olaf van der Spek schreef op donderdag 29 maart 2007 @ 17:51:
[...]

Server, dan modem (DSL/kabel?) en dan switch? Hoe kan dat nou?

Tuurlijk niet;
Inkomend signaal -> server -> 3 nics, eth0, 1 en 2.

Op eth1 komt het internet vanuit de modem binnen, waarna eth2 een switch aanstuurt, en eth0 een WLAN router.

Aan die switch zitten dus de werkstations, en aan de WLAN router mijn laptop. Modem is een Chello ding, dus gewoon een modem, geen firewall en al dat geneuk. Verbinding is verder okay, rete stabiel en aardig snel. (Kabel, Extreme abo btw).

[ Voor 13% gewijzigd door TommyGun op 29-03-2007 17:57 ]

[user109731]

Ik heb het goede bestand met een hex-editor ingekort tot de lengte van de corrupte, en dan zijn de md5sums gelijk. Het lijkt er dus op dat er 'gewoon' te weinig data word gestuurd. wget download het bestand wel goed, firefox niet,

[Verwijderd]

downloaden via Loopback al gelukt? als dat ook corrupte bestanden download dan weet je bijna 100% zeker dat 1 van die apache modules je zip/rar file sloopt.

[TommyGun]

Verwijderd schreef op donderdag 29 maart 2007 @ 18:04:
downloaden via Loopback al gelukt? als dat ook corrupte bestanden download dan weet je bijna 100% zeker dat 1 van die apache modules je zip/rar file sloopt.

Je bedoelt, gewoon lokaal inloggen met putty, wget http://www.gamergun.com/files/1/PwrMxEn.rar en kijken of alles nog juist is? (Dus de grootte, md5hash).

File in /var/www/html/files/1 is 834152 bytes, hash is 1fea0c20dab8503b6432d026d7da7005

wget uitgevoerd in /root/test;

Hash = 1fea0c20dab8503b6432d026d7da7005 PwrMxEn.rar
Size = 834152 bytes

Dat klopt dus, maar ik weet niet of je dit bedoeld

@ Grote prutser; bedankt voor het uitzoeken. Het probleem wordt gelukkig al wat duidelijker

[ Voor 21% gewijzigd door TommyGun op 29-03-2007 18:11 ]

[user109731]

Firebug geeft aan dat er een gzip header word teruggestuurd door de server. Schakel eerst gzip compleet uit, zoals Docey al eerder zei?

code:

X-Powered-By    PHP/4.3.11
Cache-Control   max-age=2592000
Expires Sat, 28 Apr 2007 15:50:09 GMT
content-disposition filename="PwrMxEn.rar";
Content-Length  834152
Content-Encoding    gzip
Vary    Accept-Encoding

[ Voor 45% gewijzigd door user109731 op 29-03-2007 18:13 ]

[TommyGun]

Grote prutser; ik heb meer gedeeltes in mijn httpd wat betreft gzip;

code:

#
# AddIcon* directives tell the server which icon to show for different
# files or filename extensions.  These are only displayed for
# FancyIndexed directories.
#
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip

#
# AddDescription allows you to place a short description after a file in
# server-generated indexes.  These are only displayed for FancyIndexed
# directories.
# Format: AddDescription "description" filename
#
#AddDescription "GZIP compressed document" .gz
#AddDescription "tar archive" .tar
#AddDescription "GZIP compressed tar archive" .tgz

#
# AddEncoding allows you to have certain browsers uncompress
# information on the fly. Note: Not all browsers support this.
# Despite the name similarity, the following Add* directives have nothing
# to do with the FancyIndexing customization directives above.
#
#AddEncoding x-compress .Z
#AddEncoding x-gzip .gz .tgz

# If the AddEncoding directives above are commented-out, then you
# probably should define those extensions to indicate media types:
#
AddType application/x-compress .Z
AddType application/x-gzip .gz .tgz

Die laatste 2 een # voor gooien?

// http://www.gamergun.com/files/1/httpd.conf

[Verwijderd]

yep, dat was wat ik bedoelde. vreemd dat het via wget wel werkt maar via firefox of IE niet.

om gzip compressie uit te schakelen moet je inderdaad een # er voor zetten. maar voor de zekerheid zou ik ook mod_deflate uit zetten. vergeet niet je apache te herstarten voordat de config actief wordt.

ik vermoed dat er dus een of een verkeerde header wordt gestuurd of er gaat iets aan de client kan fout maar dat kan bijna niet omdat meerdere mensen met verschillende configuratie's allemaal het zelfde ervaren. kun je eens kijken wat voor headers er worden gestuurd. en dan vooral de 'length' header. die geeft aan hoeveel bytes er worden verstuurd en moet dus evengroot zijn als het bestand mits natuurlijk gzip compressie uitstaat anders geeft 'length' de groote van het ge-hercomprimeerde rar/zip archiev aan.

post die headers eens hier.

[TommyGun]

#LoadModule deflate_module modules/mod_deflate.so
#AddType application/x-compress .Z
#AddType application/x-gzip .gz .tgz

Apache is nu gerestart

[Thu Mar 29 18:32:41 2007] [notice] SIGHUP received. Attempting to restart
[Thu Mar 29 18:32:41 2007] [notice] Digest: generating secret for digest authentication ...
[Thu Mar 29 18:32:41 2007] [notice] Digest: done
[Thu Mar 29 18:32:42 2007] [notice] Apache configured -- resuming normal operations

Van headers bij downloads heb ik niet veel kaas gegeten, wat ik wel weet is dat het archief nog steeds fout gaat hier. http://www.gamergun.com/files/1/PwrMxEn.rar

Edit; tweede keer werkt ie wel, maar dat kan de derde keer zo weer anders zijn
Edit 2; jep, weer damaged

[ Voor 87% gewijzigd door TommyGun op 29-03-2007 18:33 ]

[Olaf van der Spek]

TommyGun schreef op donderdag 29 maart 2007 @ 18:28:
Apache is nu gerestart

Nog steeds content encoding gzip, dat klopt echt niet.
/files/1/PwrMxEn.rar, is dat een PHP script (het lijkt er niet op, maar voor de zekerheid)?

GET /files/1/PwrMxEn.rar HTTP/1.1
Host: www.gamergun.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: Server sloopt .zip en .rar files?

HTTP/1.1 200 OK
Date: Thu, 29 Mar 2007 16:32:49 GMT
Server: Apache
X-Powered-By: PHP/4.3.11
Cache-control: max-age=2592000
Expires: Sat, 28 Apr 2007 16:32:49 GMT
Content-disposition: filename="PwrMxEn.rar";
Content-length: 834152
Content-Encoding: gzip
Vary: Accept-Encoding
Connection: close
Content-Type: application/x-rar

[ Voor 4% gewijzigd door Olaf van der Spek op 29-03-2007 18:37 ]

[TommyGun]

Wat zie ik over het hoofd dan? http://www.gamergun.com/files/1/httpd2.conf

[Olaf van der Spek]

TommyGun schreef op donderdag 29 maart 2007 @ 18:36:
Wat zie ik over het hoofd dan? http://www.gamergun.com/files/1/httpd2.conf

Staat er in conf.d/*.vhost nog iets interessants?
Hoe ziet de PHP configuratie eruit?

/files/1/PwrMxEn.rar, is dat een PHP script (het lijkt er niet op, maar voor de zekerheid)?

[ Voor 15% gewijzigd door Olaf van der Spek op 29-03-2007 18:39 ]

[TommyGun]

Olaf van der Spek schreef op donderdag 29 maart 2007 @ 18:39:
[...]

Staat er in conf.d/*.vhost nog iets interessants?
Hoe ziet de PHP configuratie eruit?

Zal even zoeken.
Edit; hm hier krijg ik weinig van gevonden. Ik heb /etc/httpd met daarin de dirs conf en conf.d

In de dir conf.d zitten default.conf mrtg.conf mvreloaded.com.vhost php.conf squirrelmail.conf ssl.conf welcome.conf

In de dir conf zitten httpd.conf magic en een Makefile die ergens anders naar toe linkt. Plus nog een aantal ssl.*** mappen.

Mijn php.ini is http://www.gamergun.com/files/1/php.ini

/files/1/PwrMxEn.rar, is dat een PHP script (het lijkt er niet op, maar voor de zekerheid)?

Is een file van Maxtor, kun je van booten om je disks te checken

[ Voor 32% gewijzigd door TommyGun op 29-03-2007 18:47 ]

[Olaf van der Spek]

TommyGun schreef op donderdag 29 maart 2007 @ 18:40:
Is een file van Maxtor, kun je van booten om je disks te checken

Dat is de inhoud van die RAR.
Wat ik bedoelde, als je die URL request, wordt die dan geserveerd door een PHP script of direct door Apache zelf?

Edit: PHP dus. Dan gok ik gewoon op bugs in dat script zelf. Is de source ervan beschikbaar?

[ Voor 12% gewijzigd door Olaf van der Spek op 29-03-2007 18:44 ]

[TommyGun]

Olaf van der Spek schreef op donderdag 29 maart 2007 @ 18:42:
[...]

Dat is de inhoud van die RAR.
Wat ik bedoelde, als je die URL request, wordt die dan geserveerd door een PHP script of direct door Apache zelf?

Edit: PHP dus. Dan gok ik gewoon op bugs in dat script zelf. Is de source ervan beschikbaar?

PHP script ja. Uploader is van www.celerondude.com maar deze versie (6.2) is betaald / niet meer te krijgen. 6.1 staat nog wel op de site. Kan wel van een bepaalde file eventueel de content laten zien. Zie btw nog even TommyGun in "Server sloopt .zip en .rar files?"

// En ik ben weer te haastig, print ik m'n php.ini

Edit; foutje gemaakt met versies

[ Voor 12% gewijzigd door TommyGun op 29-03-2007 19:27 ]

[masq]

Ik heb net even geprobeerd te enforcen geen gzip te gebruiken, dat lijkt te werken. Geen Content-Encoding: gzip meer in de response header, en 6 keer achter elkaar klopte de bestandsgrootte na downloaden.

[ Voor 10% gewijzigd door masq op 29-03-2007 18:58 ]

[TommyGun]

Okay, nu is dus de vraag of het probleem bij een config file of bij het upload script ligt. Configs lijken mij juist (zie hoger, httpd2 en php downloads).

Bedankt voor de info masq

[ Voor 21% gewijzigd door TommyGun op 29-03-2007 19:00 ]

[Olaf van der Spek]

TommyGun schreef op donderdag 29 maart 2007 @ 18:48:
PHP script ja. Uploader is van www.celerondude.com maar deze versie (6.3) is betaald / niet meer te krijgen.

Leveren zij geen support dan?

[Verwijderd]

ik heb zelf ook even naar de headers gekeken en wat mij opvalt is dat er geen lenght header wordt meegestuurd. dat zou kunnen kloppen omdat veel php-scripts streamen i.p.v senden. en dat betekent dat de browser moet gokken waneer het bestand compleet is.

wat ook weer verklaart wat Grote Prutser al was opgevallen is dat het bestand vrijwel geheel identiek is maar dat gewoon net dat laaste stukje er is afgekapt waarmee winrar zegt 'Unexpected end of archive' oftewel 'onverwacht einde van het archief. dat laaste stukje wordt gewoon niet verstuurd/ontvangen.

[TommyGun]

Olaf van der Spek schreef op donderdag 29 maart 2007 @ 19:13:
[...]

Leveren zij geen support dan?

Neh is gewoon 1 gast die dat maakt maar er onlangs mee is gestopt. Hij is wel weer bezig met een nieuwe versie meen ik maar dat kan ook weer maanden duren. Support stelt niks voor daar, dus dat is lastig.

Maar aan de config files (php/httpd) is niks te zien verder? Of een manier om dit te disablen met behulp van .htaccess? Heb ook even in de config files gekeken wat betreft die length header, maar dat zal idd wel in dat php script zitten helaas.

Edit; dit hebben we zo getest toch? Als ik gewoon een file upload via FTP, en deze weer via HTTP download maar zonder dat dit upload script er mee in aanraking komt. Dus gewoon ergens in een lege dir in /var/www/html gooien.

[ Voor 53% gewijzigd door TommyGun op 29-03-2007 20:55 ]

[TommyGun]

Ik zag wel het volgende topic; http://www.celerondude.co....php?t=681&highlight=gzip
Het is mij alleen niet duidelijk wat er met die regel moet gebeuren, zoals je ziet is daar weer geen antwoord op.

Gewoon heel die regel weghalen? Begin van mijn file ziet er zo uit;

PHP:

<?php
$UPL=array();
function timer($st=0,$d=8){list($m,$s)=explode(' ',microtime());$t=round((float)$s+(float)$m-$st,$d);if($t<1)return$t*1000 . ' ms';return$t.' s';}
$UPL['RUNTIME']=timer();
@error_reporting(E_ALL);
@ignore_user_abort(true);
@set_magic_quotes_runtime(0);
@ob_start('ob_gzhandler');
@set_time_limit(0);
#if(is_file('install.php'))exit('Please run install.php');
#if(is_file('update.php'))exit('Site update in progress, please try again in a few hours.');

[Olaf van der Spek]

Verwijderd schreef op donderdag 29 maart 2007 @ 19:14:
ik heb zelf ook even naar de headers gekeken en wat mij opvalt is dat er geen lenght header wordt meegestuurd. dat zou kunnen kloppen omdat veel php-scripts streamen i.p.v senden. en dat betekent dat de browser moet gokken waneer het bestand compleet is.

Ik zie in mijn respons (zie boven) toch zowel een content-length als connection: close, beide goed om het einde te detecteren.

[TommyGun]

Nou ik heb de regel @ob_start('ob_gzhandler'); weggehaald en Apache ge-restart, maar ik heb het probleem nog steeds. Archieven die ik via HTTP download zijn nog steeds een fractie kleiner en geven dus een Unexpected end of archive.

Edit; gzip schijnt nog steeds aan te staan. Ik ga wat verder uitzoeken dus.

[ Voor 28% gewijzigd door TommyGun op 29-03-2007 21:19 ]

[TommyGun]

Okay het lijkt goed te werken allemaal nu. Volgens Olaf geen headers meer te zien van gzip, maar ik was wel iets vergeten; namelijk zlib.output_compression = On in php.ini. Deze dus op Off gezet en Apache een restart gegeven.

Voor de zekerheid nog even een linkje maar alles wat voorheen corrupt was hier werkt nu; http://www.gamergun.com/files/1/PwrMxEn.rar

Helaas nu geen gzip meer op m'n forum, maar scheelt dat nou zoveel qua data verbruik? Qua snelheid merk ik er nog niks van. Maar ik ben allang blij dat het opgelost is, tenminste, zo lijkt het. Heel erg bedankt allemaal

[ Voor 27% gewijzigd door TommyGun op 29-03-2007 22:06 ]

[DukeBox]

Hangt natuurlijk van je content af.. html/plain text zal het zeker helpen in page load mits je cpu de snelheid van het compressen kan bijhouden.

[SA007]

Hier doen wget, links (naar 2 pc's), lynx, opera, firefox en zelfs IE6 onder wine het prima, overal zelfde md5 die overeenkomt met jouw md5.

Edit: dit topic gaat veel te snel

[ Voor 15% gewijzigd door SA007 op 29-03-2007 22:16 ]

[DukeBox]

Of jij te langzaam ;P

[TommyGun]

DukeBox schreef op donderdag 29 maart 2007 @ 22:14:
Hangt natuurlijk van je content af.. html/plain text zal het zeker helpen in page load mits je cpu de snelheid van het compressen kan bijhouden.

Mja content uploader is van alles en nog wat. Wat daar allemaal voorbij komt aan uploads . Forum is voornamelijk afbeeldingen, .php en .html. (Ook nog wat .swf van een arcade sectie maar goed).

Nou is dat forum toch niet zo heel snel (0.5 sec nodig om een pagina te genereren) maar ik heb al zoveel geoptimaliseerd dat ik het maar opgegeven heb. Zal wel komen door modificaties zoals een shoutbox. (Vreten best wel CPU power, bagger Ajax ).

[ Voor 21% gewijzigd door TommyGun op 29-03-2007 22:23 ]