Stažené soubory s nesedícím md5

[--]

Zkusit jiný switch ?

[Reklama]

[Jan Fikar]

MD5 samozřejmě pro kontrolu integrity smysl dává, ale je pravdou, že BLAKE3 je výrazně rychlejší, blíží se rychlostí CRC32.

Rychlost při hashování 1 GB souboru:
Algoritmus  Čas (přibližně)
BLAKE3      ~0.3 s
CRC32       ~0.2 s
MD5         ~1.0 s
SHA-1       ~1.5 s
SHA-256     ~2.5 s
RIPEMD-160  ~3.0 s

Blake3 (b3sum) se navíc hodí i na crypto. Jestli je to jen kontrola proti HW chybě, tak je možné použít xxhash, který je ještě rychlejší:

https://github.com/Cyan4973/xxHash

Jinak bych si myslel, že může být problém s CPU, cache, přetaktováním, napětím CPU ...

[Martin Poljak]

Jinak bych si myslel, že může být problém s CPU, cache, přetaktováním, napětím CPU ...

Jednou se mi kdysi stalo, že jeden jediný konkrétní soubor na internetu měl při stažení přes naší linku (nějaké ADSL tehdy) vždy tuším třetí a čtvrtý bajt špatně. Když jsem ho stáhl kdekoliv jinde, byly vždy správně. A vše ostatní doráželo tak, jak mělo. Svět je holt malý a o náhody tu není nouze. A někdy se ději fakt divné věci.

[marder]

To by mě zajímalo jak by si s tím poradil rsync a v případě chyby jeho opakované použití s parametrem -c jako checksums.

[DrFreeze]

Pokusím se odpovědět na většinu otázek:
- memcheck puštěn přes Grub
- jedná se o instalační zip Nextcloudu (31.0.5) a porovnávám s md5 staženým z téhož serveru
- md5 jsem použil jako nejdostupnější metodu ověření (nebylo třeba nic instalovat) a myslím, že pro základní ověření stačí

Co jsem stihl vyzkoušet:
- stažení za použití live distro (konkrétně USB flash s Gparted) na shodném HW: md5 sedí(!)
- znovu stažení na ntb, ověření md5 (tady samozřejmě sedí) a v terminálu scp na server - md5 nesedí(!)
- diff použitý na zip stažený wgetem (na serveru) a souborem poslaným na server přes scp hlásí, že se liší

Večer nebo zítra zkusím rsync plus vytvoření a stažení kontrolního souboru.

EDIT: ještě jeden pokus o stažení wgetem na serveru, tentokrát na RAID1 (předtím na systémový SSD): asi 3x hlášena chyba při dešifrování. md5sum vypíše rozdílné hashe souborů na RAIDu, na SSD i toho poslaného přes scp. Všechny tři se liší od správného hashe.

[Reklama]

[RDa]

- diff použitý na zip stažený wgetem (na serveru) a souborem poslaným na server přes scp hlásí, že se liší

Pokud chcete pouzit diff na binarku, tak musite prvne prevest binarku na text - treba hexdump -Cv <a.zip >a.hex, pak diffujete ty hexy

Prvne ale overte delku souboru zda se nelisi (typicka sitova chyba je dropnuti spojeni, duvod zatim neresme).

[Jan Fikar]

a po kontrole délky, jestli jsou vždy stejné?

jaké jsou ty vadné md5? jsou všechny stejné, nebo je to pokaždé jiné?

[Filip Jirsák]

Zkoušel jste spočítat hash souborů opakovaně? Jak těch, které měly hash na první pokus správně, tak těch, které ho měly špatně. S nějakým časovým odstupem, a mezi tím nechat přečíst nějaké jiné velké soubory, aby se ty, jejichž hash počítáte, vytlačily z paměti a musely se znovu přečíst z disku.

[Jan Fikar]

vytlačit z paměti jde i jednoduše ručně

Kód: [Vybrat]

echo 3 | sudo tee /proc/sys/vm/drop_caches

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Je k dispozici  na serveru i jiné součty než md5?

Je 'which md5sum' a which wget něco nestandartního? Nebo alias .Jak je voláno. Pozor například na trailing mezery: echo ahoj |md5sum vs cat ahoj.txt I md5sum vs md5sum<ahoj.txt vs echo -ne ahoj|md5sum
Pokud se md5 liší, liší se se i soubory? Lze otestovat diffem  nebo sha256sum (oba soubory), nevadí že servr nenabízí sha256 soucet.asc.


Dochází k přerušení spojení? Je wget volá npodivně , třeba jako wget --progress -verbose -S &>/soubor.shlavickamiavsimmoznym.deb


Ps : existuje utilita hexdiff? Nebo parametr pro hexfriendly compare?
Nebo vysvetleni, nepravděpodobné: server posílá dynamický soubor, podle hlaviček,country,sec-uaplatform x86,arm nebo user agent (ubuntu :deb, fedora rpm,)ale to je divoká představa

[DrFreeze]

wget volám úplně obyčejně, ale k přerušování spojení dochází (na notebooku ne).

Soubory na serveru z různých pokusů mají shodnou velikost, ale rozdílné md5. Budu je ještě muset převést do podoby porovnatelné diffem.

Vytvořil jsem si 100MiB soubor vyplněný nulami a umístil na svůj web. Dva pokusy o stažení na domácí server dopadly normálně, tj. stažené soubory mají shodnou velikost a shodné md5.

[RDa]

wget volám úplně obyčejně, ale k přerušování spojení dochází (na notebooku ne).

Soubory na serveru z různých pokusů mají shodnou velikost, ale rozdílné md5. Budu je ještě muset převést do podoby porovnatelné diffem.

Dela to i vuci jinym serverum?

WGET muze zkusit retry na http, skrze "http range request", takze je mozne, i to, ze ten range se blbe interpretuje na strane serveru.

Pokud ale k preruseni dochazi - tak doporucuji paralelne pustit zaznam vcetne celych paketu - tcpdump -i eth0 -s 0 port 80 (nevim zda se zminovalo zde http nebo https). HTTPs muze padat, kdyz TLS pozna ze se sifrovani rozbilo.

Hlavne - poznacit si lokaci kde k padu doslo, a pak to porovnat s lokaci kde je diff. Je mozne, ze urcity sifrovaci blok (16 byte napr) bude zcela nahodny - tj. TLS propustilo neco co nemelo.

Ten prevod k diffovatelne podobne je fakt nejjednodussi skrze hexdump -Cv .. pak vidite jak hex data, tak ascii nahled.

[Vít Šesták (v6ak)]

Pro porovnání dvou binárních souborů stejné délky tu je vbindiff. (U různé délky tuším padal.)

[rennergy]

Na binární porovnání souborů je zde program cmp. Běžně s ním kontroluji, zda se iso obraz zapsal na flashdisk správně - pokud ano, zahlásí "EOF" na místě počtem bajtů shodném s velikostí iso obrazu.

[DrFreeze]

Dnes se mi podařilo vyzkoušet připojit server jiným kabelem k jinému switchi - výsledek stejný, tj. stahování wgetem z nextcloud.com přerušované.
Také jsem vyzkoušel apt-get update a i v tomto případě dostávám chyby kontrolních součtů.
K porovnávání stažených souborů z různých pokusů se teprve dostanu.