Torrent corrupt, hoe?

[Peetz0r]

Goeiemorgen!

Gisteravond wilde in ubuntu-mate downloaden via de officiele torrent. Zo gezegd, zo gedaan. Vervolgens usb device maken en installeren. Faalt. Tweede poging. Faalt opnieuw op dezelfde plek. Read errors, ik verdenk mijn oude versleten usb drive. Usb device opnieuw maken, nog es proberen, faalt alweer. Ik sta bijna op het punt een nieuwe usb stick te kopen (ook gedaan trouwens) terwijl ik me afvraag of er nog iets anders aan de hand kan zijn.

Ik check de sha256sum (md5 is voor mietjes en sha1 is voor watjes, right?) die op bovenstaande downloadpagina staat. Komt niet overeen. WAT?

Voor zover ik weet is een torrent opgedeeld in blokjes (van in dit geval 512 KiB) die als het goed is allemaal gehasht worden en als die hast niet klopt wordt zo'n blok afgewezen (en wellicht opnieuw gedownload, evt van een andere peer). Dus hoe is het mogelijk dat de uiteindelijke download niet perfect is?

Om problemen met de torrent zelf uit te sluiten heb ik de iso verplaatst, en hem opnieuw gedownload. Dezelfde torrent en voor de zekerheid ook via http. Deze keer komen beide sha256sums wel overeen met de website.

Ik heb een vbindiff gedaan tussen de stukke en goede iso, en ik kom erachter dat ergens halverwege de file een blok van 32KiB en verderop nog eens 16KiB vervangen zijn door nullbytes. Verder zijn de bestanden identiek.

Hoe kan een subset van een torrent-niveau blok ineens spontaan veranderen in nullbytes? Ik dacht dat het torrentprotocol dit absoluut niet toelaat via hashing per blok, maar blijkbaar kan het dus toch.

Het kan dat ik dit eerder heb meegemaakt, maar dan op een minder opvallende manier. Als een sub-blokje uit een videobestand spontaan onbreekt zal de video met eventueel een hikje gewoon afspelen. Een disk image met serieuzere data is volstrekt andere koek...

Het OS waar de download heeft plaatsgevonden is Linux Mint 17 (of Ubuntu 14.04) en de client is Transmission-gtk 2.82 maar ik vraag me af of dit een bug kan zijn. Als mijn begrip van het torrentprotocol (vooral de blokjes en de hashing) niet klopt zou hetzelfde bij elke client op elk os kunnen gebeuren, right?

Nouja, nu maar verder met Ubuntu-mate installeren op mijn nieuwe NUCje... (nee, ik weet nog niet of hij inmiddels wel voorbij dat punt gaat, kan dat mijn usb-stick alsnog spontaan stuk gaat. nouja, we zullen zien)

[ddv]

Dit kan door brak geheugen komen. Ik zou memtest een nachtje laten draaien.

[jan99999]

Lange verhaal en je verteld niet waarom je usb stick weigert?
Dus leg eens uit?
Hoe heb je de iso op de usb gezet?

De iso kun je checken met de cheksum dan weet je of het goed is, dus je torrent hoef je geen zorgen over te maken.
En je kunt denk ik toch ook op een andere plaats downloaden bijv een directe download/http.

Je kunt ook nog op een andere pc downloaden proberen.

[Peetz0r]

ddv schreef op zondag 31 juli 2016 @ 08:53:
Dit kan door brak geheugen komen. Ik zou memtest een nachtje laten draaien.

Zou inderdaad kunnen. Zal ik binnenkort eens proberen dan

jan99999 schreef op zondag 31 juli 2016 @ 08:55:
Lange verhaal en je verteld niet waarom je usb stick weigert?
Dus leg eens uit?
Hoe heb je de iso op de usb gezet?

De iso kun je checken met de checksum dan weet je of het goed is, dus je torrent hoef je geen zorgen over te maken.
En je kunt denk ik toch ook op een andere plaats downloaden bijv een directe download/http.

Je kunt ook nog op een andere pc downloaden proberen.

Hoe ik de iso op de usb gezet heb doet er niet heel veel toe als de iso stuk is. Stuk is stuk en garandeert read errors als je er later van wilt lezen (tenzij je geluk hebt en de stukke stukjes in een deel zitten dat je vervolgens nooit meer leest).

Maar om de vraag te beantwoorden:

sudo dd if=isos/_buntu/ubuntu-mate-16.04.1-desktop-amd64.iso of=/dev/sdd bs=16M

Volgens mij leg ik in mijn startpost weldegelijk uit dat ik (na een aantal keer dezelfde read-error te zien) een checksum (sha256sum) van de iso gedaan heb en dat die afwijkt van wat op de downloadpagina staat. Dus ik weet dat ie stuk is. Ik heb hem daarna dus overnieuw gedownload (zowel via de torrent als via http) en dat gaat gewoon goed. Ik ben nu mezelf aan het herhalen, maar je vraagt naar dingen die ik al verteld heb...

Ik weet zelfs precies wat er stuk is aan de eerste iso, omdat ik een bindiff met de tweede iso gedaan heb. Namelijk dat er twee aaneengesloten stukken van precies 32KiB en verderop 16KiB vervangen zijn door nullbytes.

Ik zou het inderdaad op een andere pc nogmaals kunnen proberen maar ik weet al wat er is gebeurd, dus daarvoor hoeft het niet. En inmiddels heb ik de iso al tweemaal zonder beschadiging, dus daarvoor hoeft het ook niet.

De vraag is dus, mocht je eroverheen gelezen hebben: hoe kan dit gebeuren, terwijl een torrentclient per 512KiB-blok hashes controleert.

[Fish]

je euh brak geheugen was een optie, mischien een hash collision

[hcQd]

dd controleert de checksum niet en als er problemen met de usb-stick zouden zijn dan krijg je schrijffouten. Leesfouten lijken me eerder te duiden op onleesbare sectoren op de schijf (of ssd) waarop je je ISO hebt gedownload.

[Peetz0r]

Alweer, dit heeft helemaal niks met iso's of dd of usb devices te maken. Enkel met de manier waarom een torrentclient voorkomt (of dus niet) dat en download corrupt raakt.

Dat ik het pas gemerkt heb nadat ik de iso gedd't heb en geboot heb in een andere machine en zelfs halverwege een ubuntu-mate-installatie was, is eigenlijk slechts een detail (en in mijn startpost slechts een introductie tot de eigenlijke vraag).

De relevante zaken zijn dit:

• Ik heb een bestand gedownload via een torrentclient.
• Ik kwam erachter dat er iets mis was.
• Ik heb daarna een sha256sum van dat bestand vergeleken met de website waar het bedstand vandaan kwam, deze kwamen niet overeen.
• Ik download hetzelfde bestand opnieuw via torrent, en ook via http. Hiervan check ik ook de sha256sum
• De tweede en derde komen wel overeen met de website. (de torrent zelf is dus okay en de website ook).
• Ik doe een diff tussen de eerste download en de tweede, en ik zie dat de verschillen bestaan uit twee blokken aan nullbytes in de kappotte versie.

Niet relevant is dit

• Het bestand in kwestie was een bootable iso
• ik heb deze met dd op een usb-stick gezet
• In eerste instantie boote deze prima, en toen ging ik ubuntu-mate installeren
• Ik kreeg tot drie keer toe dezelfde read error tijdens de installatie
• Omdat de usb-stick oud en versleten is dacht ik dat ie stuk was, ik heb zelfs een nieuwe besteld
• Inmiddels (uren later) heb ik een van de latere downloads op de usb stick gezet en opnieuw ubuntu-mate geinstalleerd en dat werkt nu allemaal prima

Het enige dat fout is gegaan, is dat mijn torrentclient ergens een berg nullbytes heeft neergekwakt zonder de betreffende blokken opnieuw te downloaden of andersinds iets te doen.

Mijn enige vraag is: hoe kan dit?

Ik heb geen vragen over iso's of checksums of usb sticks of hdd's of ssd's tenzij dit direct verband heeft met mijn torrent client. Gezien ik geen read of write errors gezien heb op de machine waar de torrent gedownload is, enkel de machine waarop ik de ubuntu-mate installatie deed, denk ik niet dat dat van toepassing is.

[Bigs]

Ik heb het ook wel eens meegemaakt, die torrent bleef heel lang op 99,5% hangen (bleef steeds een bepaald stuk opnieuw downloaden) en toen hij uiteindelijk 100% was was er toch een blok corrupt.

Software is nou eenmaal wel eens buggy

[Thralas]

Fish schreef op zondag 31 juli 2016 @ 09:27:
je euh brak geheugen was een optie, mischien een hash collision

Nee en nee.

In het eerste geval verwacht je een paar omgevallen bits, de kans dat het een serie nullbytes oplevert als moeilijke rube goldberg-constructie is extreem klein.

De kans op een (willekeurige) SHA1-collision is eveneens ~0.00.

Peetz0r schreef op zondag 31 juli 2016 @ 09:21:
De vraag is dus, mocht je eroverheen gelezen hebben: hoe kan dit gebeuren, terwijl een torrentclient per 512KiB-blok hashes controleert.

Hier ga je de mist in. De chunk size van een torrent is variabel, ik vermoed in geval van de ISO (1.7 GB, 40 kB torrent) ~1 MB.

Chunks worden echter onderverdeeld in blocks voor uitwisseling; dat zal dan een veelvoud zijn van 16 k, en verklaart je probleem icm. een bug in de torrentclient.

Wat gebeurt er uberhaupt als je de 'recheck'-functie van je torrentclient gebruikt?

[Peetz0r]

Thralas schreef op maandag 01 augustus 2016 @ 23:19:
[...]
Hier ga je de mist in. De chunk size van een torrent is variabel, ik vermoed in geval van de ISO (1.7 GB, 40 kB torrent) ~1 MB.

Ik zuig die 512k niet uit mijn duim

Thralas schreef op maandag 01 augustus 2016 @ 23:19:Chunks worden echter onderverdeeld in blocks voor uitwisseling; dat zal dan een veelvoud zijn van 16 k, en verklaart je probleem icm. een bug in de torrentclient.

Dus toch een bug in de client zelf, en niet een oorzaak ergens buitenaf?

Thralas schreef op maandag 01 augustus 2016 @ 23:19:
Wat gebeurt er uberhaupt als je de 'recheck'-functie van je torrentclient gebruikt?

Geen idee. Ik heb de torrent allang uit mijn client weggeknikkerd en de iso zelf verplaatst, dus nu kan dat niet meer... Screenshot hierboven komt van de tweede foutloze download.

[ Voor 10% gewijzigd door Peetz0r op 02-08-2016 00:59 ]

[boyette]

ben benieuwd naar de hash van de torrent..
en uhm.. die link die je post is .. down?

https://ubuntu-mate.org/download/

[ Voor 50% gewijzigd door boyette op 02-08-2016 01:39 ]

[Hero of Time]

Peetz0r schreef op dinsdag 02 augustus 2016 @ 00:58:

[...]

Geen idee. Ik heb de torrent allang uit mijn client weggeknikkerd en de iso zelf verplaatst, dus nu kan dat niet meer... Screenshot hierboven komt van de tweede foutloze download.

Het corrupte bestand heb je dus nog? Dan kan je de torrent opnieuw aan je client geven, niet laten starten en naar de map wijzen waar de ISO al staat. Dan een recheck en je weet het.

[borft]

Zou het kunnen dat ie gewoon nog niet klaar was met downloaden? Veel clients beginnen met een lege file, en schrijven de data erin, als het binnenkomt. Als je dan net te vroeg was met je DD, zou het kunnen dat nog niet alles naar disk geflushed is?

Of natuurlijk een bug in je torrent client Of een seeder die poep over de lijn stuurt!

[jeroen3]

Je torrent client zal enkel de hash van een block checken als hij dit blok download.
Wellicht ook als hij deze weer upload, maar als deze niet is opgevraagd dan kan het wegschrijven naar disk zijn mislukt (geen ecc geheugen?) en dan heeft je torrent client daar geen weet van. Immers, jij hebt niet aangegeven de file nogmaals te controleren, of wel?

[Wolfboy]

Een andere mogelijkheid is nog dat je torrent client het bestand nog niet volledig had weggeschreven en dat deel dus nog in het geheugen had zitten. Dan is het bestand al wel als null-bytes gealloceerd maar nog niet in sync met wat je zou verwachten.

Maar tenzij je de torrent client gekilled hebt of dat de client gecrasht is zou dit niet mogen gebeuren. Mijn gok is dus ook een bug in de client.

[Peetz0r]

De net-niet-klaar theorie kan niet, want vele minuten later (toen pas had ik em uit gezet om een tweede poging te doen) was hij nog steeds corrupt.

Sterker nog, in die tijd heeft ie ook nog staan seeden vanuit de corrupte versie

Een re-check met een (kopie van) de corrupte iso heb ik gedaan, en hij zegt niks bijzonders. Geen foutmelding en de iso is nog steeds corrupt. Als ik nu de torrent start, dan "repareert" hij hem wel, en zegt hij 1,43 MB gedownload te hebben. Ik neem aan dat dat drie 512k-blokken zijn.

[Wolfboy]

Peetz0r schreef op dinsdag 02 augustus 2016 @ 15:01:
De net-niet-klaar theorie kan niet, want vele minuten later (toen pas had ik em uit gezet om een tweede poging te doen) was hij nog steeds corrupt.

Dan blijft mijn gok gewoon een bug... de kans dat dit op deze manier fout gaat is zo extreem klein dat je het effectief wel kan verwaarlozen

Sterker nog, in die tijd heeft ie ook nog staan seeden vanuit de corrupte versie

Dat zegt helaas niets. Zolang jouw client denkt dat het bestand correct is en dat specifieke blokje niet geupload wordt is dat helemaal geen probleem.