Heruntergeladene Dateien haben IMMER crc-Fehler

[reyjunior]

Hallo liebe Gemeinde,

ich habe das Problem, dass ich grundsätzlich keine gepackten Dateien herunterladen und entpacken kann. Ich habe grundsätzlich einen CRC - Fehler. Wenn ich das Entpacken mit 7-Zip erzwinge, funktionieren die Dateien nicht ordungsgemäß. WinRAR selbst entpackt die fehlerhafte Datei erst gar nicht.

Das Kuriose: Lade ich die allergleiche Dateien mithilfe meines Laptops herunter, so habe ich keinerlei Probleme.

Desktop PC, als auch der Laptop haben Windows 10.

- Ich habe den Download mit FireFox versucht, aber auch Manager a la Jdownloader getestet.
- Antivirus - Programm (AVG Free) wurde deinstalliert. Gleich danach schien das Problem für die nächsten Downloads gelöst, jedoch trat der Fehler erneut auf.
- Aktuell nutze ich den Windows 10 - eigenen Virenscanner, sowie die Firewall. Ich habe dort den Download - Ordner, sowie den Dateityp "rar" auf die Ausnahmeliste gesetzt.


So langsam bin ich ratlos. Ich weiß nicht mehr, wo ich nach dem Fehler suchen soll.

 

[mugam]

Kann z.B. auch ein RAM-Problem sein ....
Am Router kann es eigentlich nicht liegen, wenn es mit dem Laptop funktioniert ....

 

[reyjunior]

"witzig"... jetzt zeigt mir der Laptop auch einen CRC Fehler an... Muss jetzt mehrere Dateien probieren, ob das nur ein Zufall war.

Ergänzung (30. Januar 2018)

Wie könnte ich den RAM testen? Wie kann ich den Router testen? Bei Unitymedia anrufen notwendig oder geht das zu Hause?

 

[Smily]

Gilt das generell für alle Dateien? Vielleicht stimmt was mit deinen Quellen nicht. Hier bei Computerbase mal was laden.

 

[Wilhelm14]

RAM über Nacht testen. Dazu von einem Bootmedium : https://www.computerbase.de/downloads/systemtools/memtest86-plus/

Bei CRC-Fehlern mit CDI das Laufwerk angucken.
https://www.computerbase.de/downloads/systemtools/festplatten/crystaldiskinfo/

 

[Taigabaer]

Ich hatte das Problem vor Jahren mal mit einer veralteten Winrar-Version.

 

[IHeartWU]

.

 

[reyjunior]

RAM über Nacht testen. Dazu von einem Bootmedium : https://www.computerbase.de/downloads/systemtools/memtest86-plus/

Bei CRC-Fehlern mit CDI das Laufwerk angucken.
https://www.computerbase.de/downloads/systemtools/festplatten/crystaldiskinfo/

Nach über 14 Std. kein Fehler...

Ergänzung (31. Januar 2018)

Ich hatte das Problem vor Jahren mal mit einer veralteten Winrar-Version.

Ich nutze die Version 5.50. Also die aktuelle.

Ergänzung (31. Januar 2018)

Könnte am Router liegen! Wie alt ist dein Router? Ich besitze einen 9 Jahre alten Router. Bei mir sind heruntergeladene Dateien auch oft nicht entpackbar wegen CRC-Fehler. Wenn ich den Router dann ein oder zwei Male neu gestartet habe, funktionieren die heruntergeladenen Dateien wieder problemlos.

Woran es genau liegt weiß ich bis heute noch nicht. Habe das Problem schon seit ca. 3 Jahren. Das Problem tritt auch wie bei dir mit verschiedenen PCs auf.

Wir haben eine Fritzbox 6490 Cable, direkt von Unitymedia gemietet. Wir zahlen 5€ im Monat dafür. Eigentlich ist die Fritzbox sehr zuverlässig und ich denke nicht, dass wir einen veralteten Router haben... Gruß

 

[Bolko]

Stimmt der MTU-Wert?

Konsole (cmd) mit Adminrechten öffnen und eintippen:
netsh interface ipv4 show subinterface

Jetzt siehst du deinen aktuellen MTU-Wert für Windows-Netzwerkverbindungen.

eintippen:
ping www.google.com -f -l XXXX
(Statt XXXX den vorher angezeigten MTU-Wert nehmen, also zB 1500 oder 1492 oder oder 1472 oder was immer da in der ersten Ausgabe steht.)

Kommt es laut Anzeige zu Fragmentierungen oder zu Paketverlusten?
Falls ja, dann stimmt dein MTU-Wert nicht und du musst ihn selber neu messen und den korrekten Wert eintragen.
Bei mir war ebenfalls ein falscher MTU-Wert vorgegeben und es kam zu Fragmentierungen und Paketverlusten.

Das geht so:
https://www.computerbase.de/forum/t...ter-internetverbindung.1745111/#post-20892716

Ich weiß auch nicht, warum Windows da manchmal 1500 einträgt, obwohl der Wert falsch ist.

 

[reyjunior]

Stimmt der MTU-Wert?

Konsole (cmd) mit Adminrechten öffnen und eintippen:
netsh interface ipv4 show subinterface

Jetzt siehst du deinen aktuellen MTU-Wert für Windows-Netzwerkverbindungen.

eintippen:
ping www.google.com -f -l XXXX
(Statt XXXX den vorher angezeigten MTU-Wert nehmen, also zB 1500 oder 1492 oder oder 1472 oder was immer da in der ersten Ausgabe steht.)

Kommt es laut Anzeige zu Fragmentierungen oder zu Paketverlusten?
Falls ja, dann stimmt dein MTU-Wert nicht und du musst ihn selber neu messen und den korrekten Wert eintragen.
Bei mir war ebenfalls ein falscher MTU-Wert vorgegeben und es kam zu Fragmentierungen und Paketverlusten.

Das geht so:
https://www.computerbase.de/forum/t...ter-internetverbindung.1745111/#post-20892716

Ich weiß auch nicht, warum Windows da manchmal 1500 einträgt, obwohl der Wert falsch ist.

Du hast recht. MTU Wert scheint falsch zu sein (auch wenn ich überhaupt keine Ahnung habe was das ist).
Wenn das funktioniert, bist du mein persönlicher Held! Ich teste gleich das, was du per Link geschickt hast.

 

[Bolko]

MTU = Maximum Transmission Unit
https://de.wikipedia.org/wiki/Maximum_Transmission_Unit

Also MTU =
Größe der Nutzdaten (icmp-payload) pro Netzwerkpaket (= MSS = Maximum Segment Size)
+ Header
+ Checksumme
+ Protokolldaten


Das ist der Grund für den Standard "1500" beim MTU-Wert:

"The standard set by IEEE802.3 specifies the MTU of Ethernet is 1500 bytes."
https://supportforums.cisco.com/t5/other-network-infrastructure/why-the-mtu-size-is-1500/td-p/105418


Ok, steht so im Standard drin und deshalb macht das Windows und die Router so im Automatik-Modus.
In der Realität allerdings führt dieser Standardwert zu Fehlern.
Da sind bei mir exakt 8 Bytes zu viel, wenn man diesen Standard mit den selber gemessenen Werten vergleicht.



Ethernetframe: maximal 1518 Bytes
abzüglich "Header" (14 Bytes): 1504 Bytes
abzüglich "Prüfsumme, Frame Check Sequence, FCS" (4 Bytes): 1500 Bytes
http://www.nwlab.net/art/mtu/mtu.html

"Irgendwer" (Treiber, Provider) meint aber, dass es da noch eine Differenz von 8 Bytes gibt, also 1492 Bytes statt 1500 Bytes korrekt ist.

Und so ist es auch:

Beim Internetzugang via DSL kommt auf der Verbindung zum Internetprovider häufig das Protokoll PPPoE zum Einsatz. PPPoE beansprucht in jedem Frame 8 Byte zur Übertragung von Verbindungsinformationen. Die MTU reduziert sich daher bei der Verwendung von PPPoE auf 1492 Byte.

http://www.nwlab.net/art/mtu/mtu.html


PPPoE : 8 Bytes

1518-14-4-8 = 1492

Offenbar ist Windows bzw Microsoft schlicht zu *DOOF*, um die 8 Bytes für PPPoE (oder für sonstige Provider-Protokolle) mit einzubeziehen, also vom MTU-Wert abzuziehen.
Aua aua aua.

Durch den Einsatz weiterer Protokolle (z.B. L2TP) bei einigen Providern, kann sich die MTU noch weiter verringern. Den genauen Wert sollten man bei seinem Provider erfragen.
Provider MTU
1&1 1492
AOL 1400
Arcor 1488 oder 1492
Berlikomm 1492
DFN@home 1448
Freenet 1454
GMX 1492
Kamp 1460
meome 1454
NGI 1492
T-DSL/T-Online 1492
TLink 1456
VIA Net.works 1492/1460

http://www.nwlab.net/art/mtu/mtu.html

Ergänzung:
Vodafone VDSL: 1492
(eigene manuelle Messung)

Für VLAN (falls aktiv) werden nochmal 4 Bytes abgezogen, dann also 1492-4=1488 Bytes
(siehe Arcor)


Schickt man die Pakete in den zu großen Einheiten, dann muss fragmentiert werden und es kommt zu Paketverlusten, erhöhten Laufzeiten, TimeOuts. Die Automatik in Windows ist zu dumm, um das korrigieren zu können.


1464 (icmp-payload, eigene Nutzdaten , MSS, Maximum Segment Size)
+ 8 (icmp-header)
+ 20 (ipv4-header)
+ 8 (PPPoE)
=1500

Es gibt aber noch ein wichtiges Detail:
Die Paketgröße wurde im VDSL erhöht von 1518 auf 1522 Bytes, wegen der 4 VLAN-Bytes.
https://netmgmt.wordpress.com/2007/11/14/ethernet-frame-from-1518-to-1522-size/
https://de.wikipedia.org/wiki/Datenframe

Also :
Standard IEEE 802.3 : 1518 Bytes
Standard IEEE 802.3ac : 1522 Bytes
Standard IEEE 802.1Q : 1522 Bytes

1522 Bytes Paketgröße
- 4 Bytes (VLAN)
- 14 (Header)
- 4 (Checksumme)
- 8 (PPPoE)
= 1492 Bytes MTU

Es kommt darauf an, welchen Netzwerk-Standard man benutzt,
denn davon hängt die Paketgröße (1518 oder 1522) ab und der Abzug für die diversen Protokolle (VLAN, PPPoE).

Windows scheint nicht zu wissen, das ich größere Paketgrößen nach neuem Standard mit VLAN Abzug für VDSL benutze, denn sonst müsste Windows 1492 statt 1500 als MTU eintragen.

Berechnung von CISCO-Support:
https://learningnetwork.cisco.com/thread/62253
(Beitrag #3)

Das ist gar nicht mal so einfach wie es auf den ersten Blick aussieht.
Man muss sogar die 8 Byte Pause berücksichtigen zwischen den Paketen.

Zum testen der MTU kann man auch das kleine Tool "mtupath" benutzen:
http://www.iea-software.com/ftp/mtupath/windows/mtupath.exe
http://www.iea-software.com/products/mtupath/

in einer Konsole eintippen:
mtupath www.google.com -4

Bei mir steht dann nach ein paar Iterationen:
"estimated MTU 1492"

"TCP Optimizer 4.06"
https://www.speedguide.net/files/TCPOptimizer.exe
https://www.speedguide.net/downloads.php
Meldet ebenfalls MTU=1492


Also exakt so wie manuell gemessen und abweichend vom Windows-MTU-Wert.

Also entweder bin ich doof
UND das Tool "MTU-Path" ist doof
UND das Tool "TCP Optimizer 4.06" ist doof
UND der Telekom-Support ist doof
UND der Vodafone-Support ist doof
UND der CISCO-Support ist doof
(alle melden MTU=1492)

oder
Microsoft Windows ist doof.
(meint MTU=1500 ist korrekt)

Weg von der Theorie hin zur Praxis:
Mit MTU=1500 gibt es Netzwerkfehler, TimeOuts
Mit MTU=1492 funktioniert es

Aus technischer Sicht ist Microsoft Windows : Schrott

 

[omavoss]

Interessant. Wirklich fundierte Informationen, danke dafür.

 

[reyjunior]

MTU = Maximum Transmission Unit
https://de.wikipedia.org/wiki/Maximum_Transmission_Unit

Also MTU =
Größe der Nutzdaten (icmp-payload) pro Netzwerkpaket (= MSS = Maximum Segment Size)
+ Header
+ Checksumme
+ Protokolldaten


Das ist der Grund für den Standard "1500" beim MTU-Wert:

"The standard set by IEEE802.3 specifies the MTU of Ethernet is 1500 bytes."
https://supportforums.cisco.com/t5/other-network-infrastructure/why-the-mtu-size-is-1500/td-p/105418


Ok, steht so im Standard drin und deshalb macht das Windows und die Router so im Automatik-Modus.
In der Realität allerdings führt dieser Standardwert zu Fehlern.
Da sind bei mir exakt 8 Bytes zu viel, wenn man diesen Standard mit den selber gemessenen Werten vergleicht.



Ethernetframe: maximal 1518 Bytes
abzüglich "Header" (14 Bytes): 1504 Bytes
abzüglich "Prüfsumme, Frame Check Sequence, FCS" (4 Bytes): 1500 Bytes
http://www.nwlab.net/art/mtu/mtu.html

"Irgendwer" (Treiber, Provider) meint aber, dass es da noch eine Differenz von 8 Bytes gibt, also 1492 Bytes statt 1500 Bytes korrekt ist.

Und so ist es auch:

http://www.nwlab.net/art/mtu/mtu.html


PPPoE : 8 Bytes

1518-14-4-8 = 1492

Offenbar ist Windows bzw Microsoft schlicht zu *DOOF*, um die 8 Bytes für PPPoE (oder für sonstige Provider-Protokolle) mit einzubeziehen, also vom MTU-Wert abzuziehen.
Aua aua aua.


http://www.nwlab.net/art/mtu/mtu.html

Ergänzung:
Vodafone VDSL: 1492
(eigene manuelle Messung)

Für VLAN (falls aktiv) werden nochmal 4 Bytes abgezogen, dann also 1492-4=1488 Bytes
(siehe Arcor)


Schickt man die Pakete in den zu großen Einheiten, dann muss fragmentiert werden und es kommt zu Paketverlusten, erhöhten Laufzeiten, TimeOuts. Die Automatik in Windows ist zu dumm, um das korrigieren zu können.


1464 (icmp-payload, eigene Nutzdaten , MSS, Maximum Segment Size)
+ 8 (icmp-header)
+ 20 (ipv4-header)
+ 8 (PPPoE)
=1500

Es gibt aber noch ein wichtiges Detail:
Die Paketgröße wurde im VDSL erhöht von 1518 auf 1522 Bytes, wegen der 4 VLAN-Bytes.
https://netmgmt.wordpress.com/2007/11/14/ethernet-frame-from-1518-to-1522-size/
https://de.wikipedia.org/wiki/Datenframe

Also :
Standard IEEE 802.3 : 1518 Bytes
Standard IEEE 802.3ac : 1522 Bytes
Standard IEEE 802.1Q : 1522 Bytes

1522 Bytes Paketgröße
- 4 Bytes (VLAN)
- 14 (Header)
- 4 (Checksumme)
- 8 (PPPoE)
= 1492 Bytes MTU

Es kommt darauf an, welchen Netzwerk-Standard man benutzt,
denn davon hängt die Paketgröße (1518 oder 1522) ab und der Abzug für die diversen Protokolle (VLAN, PPPoE).

Windows scheint nicht zu wissen, das ich größere Paketgrößen nach neuem Standard mit VLAN Abzug für VDSL benutze, denn sonst müsste Windows 1492 statt 1500 als MTU eintragen.

Berechnung von CISCO-Support:
https://learningnetwork.cisco.com/thread/62253
(Beitrag #3)

Das ist gar nicht mal so einfach wie es auf den ersten Blick aussieht.
Man muss sogar die 8 Byte Pause berücksichtigen zwischen den Paketen.

Zum testen der MTU kann man auch das kleine Tool "mtupath" benutzen:
http://www.iea-software.com/ftp/mtupath/windows/mtupath.exe
http://www.iea-software.com/products/mtupath/

in einer Konsole eintippen:
mtupath www.google.com -4

Bei mir steht dann nach ein paar Iterationen:
"estimated MTU 1492"

"TCP Optimizer 4.06"
https://www.speedguide.net/files/TCPOptimizer.exe
https://www.speedguide.net/downloads.php
Meldet ebenfalls MTU=1492


Also exakt so wie manuell gemessen und abweichend vom Windows-MTU-Wert.

Also entweder bin ich doof
UND das Tool "MTU-Path" ist doof
UND das Tool "TCP Optimizer 4.06" ist doof
UND der Telekom-Support ist doof
UND der Vodafone-Support ist doof
UND der CISCO-Support ist doof
(alle melden MTU=1492)

oder
Microsoft Windows ist doof.
(meint MTU=1500 ist korrekt)

Weg von der Theorie hin zur Praxis:
Mit MTU=1500 gibt es Netzwerkfehler, TimeOuts
Mit MTU=1492 funktioniert es

Aus technischer Sicht ist Microsoft Windows : Schrott

Ich habe es wie weiter oben beschrieben getestet und hatte keine Fehler 1435 abwärts sehr weit runter bis knapp 1000.... ich habe jetzt den MTU Wert 1400 gewählt, aber nach Router-Neustart, PC-Neustart einen Download versucht und siehe da, immer noch der gleiche Fehler. MTU Wert 1400 ergibt allerdings keine Fehler.

Irgendeine Ahnung, welchen MTU-Wert ich genau bei Unitymedia Baden-Württemberg brauche? LG und Danke für die Antworten.

 

[Wilhelm14]

Schickt man die Pakete in den zu großen Einheiten, dann muss fragmentiert werden und es kommt zu Paketverlusten, erhöhten Laufzeiten, TimeOuts.

Kommt es wirklich zu solchen Phänomenen? Ich behaupte mal 999 von 1000 Windows-Rechner haben die MTU unverändert auf 1500 und niemand hat Probleme. Einer von 1000, der die MTU angepasst hat, hat vorher/nachher keinen Unterschied. Paketverlust, erhöhte Laufzeit, TimeOuts müsste man doch schlicht vorher/nachher messen können.

...ich habe jetzt den MTU Wert 1400 gewählt, aber nach Router-Neustart, PC-Neustart einen Download versucht und siehe da, immer noch der gleiche Fehler. MTU Wert 1400 ergibt allerdings keine Fehler.

Widersprechen sich die zwei Sätze? Oder meinst du mit dem ersten Satz, die CRC-Fehler beim Download hast du immer noch und mit dem zweiten Satz meinst du nur, dass die Pakete nicht mehr fragmentieren?

Hast du mit CrystalDiskInfo schon das Festplattenlaufwerk geprüft? Bekommst du sonst woanders Fehler, außer bei Downloads? Was macht https://www.heise.de/download/product/prime95-36233
Du kannst auch prüfen, ob ein Live-Linux herunterladen kann, also ob es an der Hardware liegt.
Was für Sicherheitssoftware hast du? Virenscanner, Firewall?

 

[reyjunior]

Kommt es wirklich zu solchen Phänomenen? Ich behaupte mal 999 von 1000 Windows-Rechner haben die MTU unverändert auf 1500 und niemand hat Probleme. Einer von 1000, der die MTU angepasst hat, hat vorher/nachher keinen Unterschied. Paketverlust, erhöhte Laufzeit, TimeOuts müsste man doch schlicht vorher/nachher messen können.


Widersprechen sich die zwei Sätze? Oder meinst du mit dem ersten Satz, die CRC-Fehler beim Download hast du immer noch und mit dem zweiten Satz meinst du nur, dass die Pakete nicht mehr fragmentieren?

Hast du mit CrystalDiskInfo schon das Festplattenlaufwerk geprüft? Bekommst du sonst woanders Fehler, außer bei Downloads? Was macht https://www.heise.de/download/product/prime95-36233
Du kannst auch prüfen, ob ein Live-Linux herunterladen kann, also ob es an der Hardware liegt.
Was für Sicherheitssoftware hast du? Virenscanner, Firewall?

Ich nutze nicht mehr AVG Free-Antivirus, sondern den Windows 10 Defender.
Die Sätze widersprechen sich nicht. MTU Wert 1400 ergibt beim Test in "cmd" keine Fehler. Wenn ich aber Dateien downloade, sind diese fehlerhaft.

 

[Wilhelm14]

Okay, dann habe ich es richtig verstanden, wollte nur nochmal nachfragen.
Dass Pakte fragmentieren ist übrignes kein Fehler. Das tun sie ja bei jedem Windows. (Bei deinem Laptop z.B., der ohne CRC-Fehler herunterladen kann.)
CrystalDiskInfo? Könnte eine defekte Festplatte erkennen oder Controller, Kabel.
Prime95? Könnte defektes Board, CPU, RAM oder deren Zusammenspiel erkennen.
Live-Linux? Könnte komplett Windows ausschließen, egal ob Updates, Treiber, Einstellungen.

 

[reyjunior]

Okay, dann habe ich es richtig verstanden, wollte nur nochmal nachfragen.
Dass Pakte fragmentieren ist übrignes kein Fehler. Das tun sie ja bei jedem Windows. (Bei deinem Laptop z.B., der ohne CRC-Fehler herunterladen kann.)
CrystalDiskInfo? Könnte eine defekte Festplatte erkennen oder Controller, Kabel.
Prime95? Könnte defektes Board, CPU, RAM oder deren Zusammenspiel erkennen.
Live-Linux? Könnte komplett Windows ausschließen, egal ob Updates, Treiber, Einstellungen.

Prime95 lief jetzt einige Stunden... Überall steht "passed", ansonsten nichts. Konnte damit nichts anfangen. Die anderen Programme muss ich noch testen.

Danke Wilhelm14: Würdest du dann sagen, dass ich den MTU Wert wieder auf 1500 stellen soll? Die Fritz-Box erlaubt keine manuelle Einstellung des MTU - Wertes

 

[omavoss]

@reyjunior:

Bei meiner7490 kann man den MTU-Wert einstellen: Internet -> Zugangdaten -> IPv6 -> ganz nach unten scrollen -> Weitere Einstellungen -> MTU manuell einstellen Haken rein und den MTU-Wert eintragen -> Übernehmen.

Ist halt nur unter IPv6 ein wenig versteckt ... und man muss die erweiterte Ansicht aktiviert haben.

Ich habe jetzt sowohl Windows als auch die Fritzbox auf 1492 eingestellt und habe den Eindruck, dass zumindest Edge und Opera runder läuft als bisher.

 

[Wilhelm14]

AVM selbst sagt, dass das nicht erforderlich ist, wenn auch einstellbar: https://avm.de/service/fritzbox/fri...-Size-fuer-DSL-Verbindungen-manuell-anpassen/

Zum Theme CRC noch: Live-Linux laufen lassen und dort nach Fehlern gucken. Wenn prime, memtest86+ nichts provozieren können, gehen mir die Ideen aus.

Edit: Na, wenn dass mit 1492 jetzt gefühlt runder läuft, wenn das man nicht Einbildung ist. Ich wäre skeptisch.

 

[Bolko]

Am PC würde ich mal das SATA-Kabel tauschen.
Am Laptop gibt es sowas aber nicht.

CrystalDiskInfo sagt dir, ob die Festplatten noch ok sind.