Mam taky maly server na torrenty. Stiahnute subory prenasam do PC a notebooku. Tie sa ale obcas prenesu poskodene. Mam otestovane ze ci to prenasam pomocou tar | nc alebo NFS tak subory sa dokazu poskodit. Nema niekto napad v com moze byt problem? Testoval som aj prenos cez ethernet (~200GB) a vyzera to v poriadku.
Na serveru jsou ty soubory OK? A když použiješ něco jiného, než nc či nfs (například ssh, ftp, smb...), je to OK?
Fileserver na WiFi? Doma jsou všichni zdrávi?
A co? Já mám taky natažené kabely, ale málokdy se unavuju zapichováním notebooku... Stačí, že musím řešit napájení. Kabely ať jsou tam, kde se s tím nehýbe - desktop a spol.
Ale nic. Debuguj dál.
ano na servery su dobre. kontrolujem to cez crc32. pripojene cez kabel by som to chcel mat ale akosi nie je zatial moznost. jeden z tych poskodenych suborov som skusil rozdeli na 1MB useky a spravil diff hexdump. vysledkom bolo ze jedniny rozdiel v celom 600MB subore bolo asi 100 bajtov.vychadza mi teda ze UDP alebo TCP crc checksum v hlaivcke nie je dostatocna ochrana voci chybam v prenose. je nejaka moznost zapnut dodtatocny checksum pre NFS? prenos cez sambu vyzera byt v poriadku ale tomu by som sa chcel vyhnut kedze rychlost je polovicna.
Podobné problémy obvykle znamenají poškozenou RAM na některé ze stran
myslim ze vadna RAM by sposobila tiez nestabilitu servera. okrem toho prenos cez kabel je fajn a ziadne chyby som pri prenose 200GB nezaznamenal. pritom pri prenose 20GB cez wifi su 4 subory poskodene. ked uz by to mal byt HW problem tak skor v samotnej wifi karte.
Ano, měl jsem stejný problém. Doma jsem měl jako AP Asus 530. (jen AP, nedělal ani DHCP, ani NAT-router, ani DNS).
Při kopírování přes wifi občas poškozený soubor, nebo při práci s ssh se najednou odpojilo. Na tom ssh to bylo nejmarkantější - psal jsem příkaz a najednou to vypadlo. Pěkně mě to vytáčelo.
Při brouzdání na webu se to nijak neprojevovalo. Doma mám více nb, ale jen já dělám přes ssh - takže jsem to pozoroval jen já, ostatní jen brouzdají na webu, takže jim to nijak nevadilo.
Vyzkoušel kde co, změna šifry na wifi, bez šifrování a bylo to pořád stejné. Pomohla výměna AP. Jak jsem vyměnil AP za jiné, tak to okamžitě přestalo a vše je stabilní.
Zapik
Odhadoval bych také nabořenou WIFI kartu na jedné ze stran nebo něco kolem HW zodpovědného za přesun dat mezi wifi a RAM počítače. Vadná smaotná RAM by s epravděpodobně projevila i jinde.
Už jsem zažil 2x nabořenou síťovku, která takto úspěšně prznila data, to byl pak stav souborů na serveru hodně smutný...
V TCP a UDP se nepoužívá CRC, ale jen tupý checkum, spoléhá se dneska na detekci o úroveň výše, což už u toho wifi je CRC32 na ethernet rámcích. V případě použití protokolu NFS nad UDP se ten checksum i často vypíná pro zvýšení výkonu, takže pak se nemusí detekovat przněění dat (a tne checksum je sám o sobě detekčně celkem slabý).
tak zoberiem notebook, desktop, ten server a skusim prenosi medzi kazdym z nich. ak bude notebook -> desktop cez AP vadne tak je vadne AP. ak notebook -> server priamo cez wifi tak bude vadna karta v serveri.
ethernet bol vzdy v poriadku. ci uz notebook -> desktop alebo notebook -> server.
Citace od: Zapik kdy 25. 08. 2014, 10:16:39
Vyzkoušel kde co, změna šifry na wifi, bez šifrování a bylo to pořád stejné. Pomohla výměna AP. Jak jsem vyměnil AP za jiné, tak to okamžitě přestalo a vše je stabilní.
Historicky stejná zkušenost s AP od SMC (firmware v nejnovější verzi). Problém vyřešila výměna (za identický typ, s dodaným starším firmware).
Karta nieje chybna. Chybny moze byt ovladac k nej. Paradoxne moze pomoct v ovladaci wifi karty vypnut kontrolu chyb, pretoze tam moze byt chyba a posuva to chybne ramce vyssim vrstvam. Chyby potom kontroluje hardware. Ak je ramec chybny, tak to oznami v registri zvysenim citaca chyb a do eteru nedava Ack. To sposobi na druhej strane pokus o znova vyslanie ramca dufajuc, ze tentokrat sa to uz podari.
vyzera ze je vadne AP. skusil som Ad-Hoc prenos server -> notebook a bol v poriadku. tiez som to skusil s inym AP a tiez to vyzera byt v poriadku. ten ASUS DSL-N55-U dam asi na reklamaciu. len ci to uznaju.
Ak to bude robit aj v servise, tak ti to uznaju. Ak ma ten router Ralink chipset, tak je to jasne. Robi to aj wifi kartach od Ralinku. Maju chybu v ovladaci.
tak vyzera to ze update firmware na routery tento problem vyriesil.