CRC32 Checksumme überprüfen

Lars schrieb:
> Hi,
>
> wie funktioniert eigentlich die Verification von einem CRC32?
Du berechnest die die CRC von den Daten die du hast und vergleichst 
diese mit der Checksumme der Ursprungsdaten. Wenn diese ungleich sind 
hast du Fehler in deinen Daten.

Lars schrieb:

> Passiert allerdings auch nicht, wenn man bei dem Online-Calculator
> 0x6e6500000000 eingibt -> der CRC ist dann 0xD2EE37B4 und
> die empfangenen Daten 0x6e65D2EE37B4 ergeben dann einen CRC von
> 0xA1C46CAD

Ganz einfach. Der Kalkulator ist kaputt. Nimm den hier, der geht. Und 
ich hab dir sogar schon das CRC-32 Polynom eingetragen:

http://ghsi.de/CRC/index.php?Polynom=100000100110000010001110110110111


XL

yo, reflected. Du invertierst Dein Ergebnis 877FC101 zu 78803efe und 
steckst es bytegedreht rein, also

6e65fe3e8078 bei http://www.lammertbies.nl ergibt 0xffffffff

Kann einen an den Rand des Wahnsinns bringen, siehe hier meinen post 
samt Programm:

Beitrag "Yet another CRC32 Code"

>>Ganz einfach. Der Kalkulator ist kaputt.
Wenn man von einem Thema keinen Schimmer hat, einfach mal auf eine 
Äußerung verzichten.

Cheers
Detlef

Ich glaube, das hat was zu tun wie Du die Daten siehst, ob bei deinen 
Bytes also 6e oder 65 das 'Most significant Byte' ist. Bei meiner 
Berechnungsroutine muß man das Polynom ja auch 'umdrehen'. Invertieren 
hat damit zu tun, ob Du im LFSR mit 0x00 oder 0xffffffff startest.

Aber Genaueres weiß ich leider auch nicht, würde ich wohl gerne. 
Funktionieren tut's jedenfalls.


Cheers
Detlef

Lars schrieb:
> arum wird überhaupt
> invertiert und bytegedreht? Hat das eine tiefere bewandtnis?

Ja. Die benutzte Arithmetik der CRCs, Shift Register, kann in Hardware 
auf zwei Arten implementiert werden: 
http://en.wikipedia.org/wiki/Linear_feedback_shift_register

Je nach benutzter Methode, Galois oder Fibonacci, ändert sich dabei die 
Schieberichtung der LFSRs und somit die Reihenfolge der Taps die man 
nutzen muß. Jedes Polynom kann dabei in natürlicher oder invertierter 
Form überführt werden, je nachdem ob man das LFSR als Galois oder 
Fibonacci ausführt. Je nach Hardware ist dann die jeweilige 
Implementation, also als Galois oder Fibonacci, einfacher oder 
schwieriger zu bewerkstelligen. Auf FPGAs benutzt man gerne die 
Fibonacci Repräsentation, auf PCs häufiger die Galois.

Hat man sich für einen Typ der Impelmentierung entschieden so hat man 
sich auch für den richtigen Startwert des internen CRC Registers 
entschieden. Jedes LFSRs muß mit 1'en als Startwert arbeiten da der Wert 
Null als Startwert ungültig ist. Ein LFSR läuft, mit nicht reduzierbaren 
Polynom, alle Zustände durch, ausser dem Zustand Null.

>>>>>>
Jedes LFSRs muß mit 1'en als Startwert arbeiten da der Wert
Null als Startwert ungültig ist. Ein LFSR läuft, mit nicht reduzierbaren
Polynom, alle Zustände durch, ausser dem Zustand Null.
<<<<<<

Das hängt von der Art des LFSR ab. Xilinx
http://www.xilinx.com/support/documentation/application_notes/xapp210.pdf 
haben mal mit XNORs zurückgekoppelt, da ist alles 1 der verbotene 
Zustand.

Galois/Fibonacci unterscheiden sich durch die Anordnung der XORs, nicht 
durch die Schieberichtung.

Cheers
Detlef

Detlef _a schrieb:
> Das hängt von der Art des LFSR ab. Xilinx
> http://www.xilinx.com/support/documentation/application_notes/xapp210.pdf
> haben mal mit XNORs zurückgekoppelt, da ist alles 1 der verbotene
> Zustand.

Korrekt. Ändert aber nichts an der Sache das man mit XNOR eine 
Invertierung der mathm. Formel durchgeführt hat. Die "Basis-Formel" für 
LFSRs arbeitet mit XOR als mathem. definierte Addition für Galois Felder 
in GF(2). Es hängt letztendlich auch nicht vom LFSR Typus ab sondern von 
der gewählten Implementierung, invertiert oder nicht invertierter 
Betrieb. Das kann man sich so vorstellen das man eine additive Formel 
durch Vorzeichenwechsel in eine Formel überführen kann die mit 
Subtraktionen arbeitet statt Additionen.
Mathm. bleibt es also bei meiner Aussage, der Zustand 0 im Register ist 
illegal.