Hallo zusammen, ich habe eine Frage. Ich habe eine CRC abgesicherte Kommunikation. Ich habe also mir vorher bekannte Datenpakete, die ich übertragen möchte. Kann ich nun auf der Empfängerseite einfach einen definierten Startwert der CRC Berechnung nehmen, damit sie am Ende er Übertragung 0 ist? Wie kann ich diesen Startwert berechnen? Ich habe jetzt die Übertragung einmal mit dem Startwert 0 laufen lassen und hatte am Ende eine Prüfsumme. Nun hatte ich gedacht, dass ich diese Prüfsumme als Startwert nehme und damit am Ende 0 erhalte, wenn sich die übertragenden Pakte nicht ändern. Leider ist das bei mir nicht der Fall... Habe ich einen Denkfehler und der Startwert kann nicht so einfach auf 0 gerechnet werden, oder liegt noch ein Fehler in meinem Design? Vielen Dank! Lars :)
Du solltest 0 bekommen, wenn: - Du auf Sende- und Empfangsseite den selben Startwert nimmst. - Die übertragung Fehlerfrei ist :-) - Du auf der Empfangsseite in die CRC-Berechnung auch den empfangenen CRC-Wert einbeziehst.
Hallo und vielen Dank! Ich habe die CRC Berechnung quasi nur auf der Empfangsseite. Klassisch ist es ja so, dass man auf der Senderseite die CRC Summe bildet, mit überträgt und diese dann mit der CRC Summe der Empfängerseite vergleicht. Korrekt? Ich habe aber Pakete bekannten Inhalts. Nun könnte ich jedes Paket auf der Empfängerseite mit dem erwarteten Wert vergleichen und zu überprüfen, ob meine Übertragung korrekt war. Das verbraucht aber viele Ressourcen und Platz im Design. Dazu habe ich den Nachteil, dass ich jeden Paket-Vergleicher quasi konfigurierbar machen muss, falls sich der Datenstream mal ändert und das wird er mit der Zeit immer mal wieder... Also habe ich mir gedacht, ich nehme statt 1000 Vergleichern einfach nur einen konfigurierbaren Startwert der CRC Berechnung, bei dem mit dem dazugehörigen Datenstream immer 0 als Ergebnis steht. Somit prüfe ich einfach am Ende der Übertragung auf 0 und kann sagen, ob alles (mit sehr hoher Wahrscheinlichkeit) korrekt war oder nicht. Nun ist die Frage, wie ich diesen Startwert berechnen kann. Reicht es einfach, die CRC Prüfsumme einmal mit Startwert 0 zu berechnen, oder ist das komplizierter? Also Startwert 0 => CRC Berechnung => Endwert XYZ Startwert XYZ => CRC Berechnung => Endwert 0? Haut das so hin? Wenn ja, habe ich einen Fehler in meinem Design... Wenn nein, wie berechne ich den passenden Startwert? Vielen Dank! Lars :)
> Klassisch ist es ja so, dass man auf der Senderseite die CRC Summe > bildet, mit überträgt und diese dann mit der CRC Summe der > Empfängerseite vergleicht. Korrekt? Ja > Startwert 0 => CRC Berechnung => Endwert XYZ > Startwert XYZ => CRC Berechnung => Endwert 0? > Haut das so hin? Ich denke nicht. Aber das kannst Du ja mal mit einem der vielen CRC-Onlinetools checken. Was ist so schlimm daran, senderseitig die CRC zui berechnen? Und wofür brauchst Du 1000 Vergleicher?
Hallo, pks schrieb: > Ich denke nicht. Aber das kannst Du ja mal mit einem der vielen > CRC-Onlinetools checken. Muss ich mich mal auf die Suche begeben. Habe bisher nur das Onlinetool http://www.easics.com/webtools/crctool verwendet, aber da kann ich keine CRC ausrechnen lassen, sondern nur ein Design erstellen. > Was ist so schlimm daran, senderseitig die CRC zui berechnen? Und wofür > brauchst Du 1000 Vergleicher? Ich habe senderseitig leider keine Chance der Einflussnahme, weil alles fest verdrahtet ist. Ich kenne nur das Protokoll und die Daten, die ich sende. Ich versuche quasi eine nicht sichere Kommunikation sicherer zu machen. Das geht aber nur, weil ich die Daten kenne, die ich schicke. Sonst wäre das natürlich Quark ;) Vielen Dank! Lars :)
Lang ist es her das ich mal CRC32 programiert habe ... Das was du vorhast geht nicht. Du kannst nicht nicht einmal so, das du deinen Startwert nimmt und mit einer "geheimen" Zahl verrechnest um das mut deiner CRC Routine auf 0 zu kommen. Du hast es mit linear rückgekoppelte Schieberegister zu tun siehe http://de.wikipedia.org/wiki/Linear_r%C3%BCckgekoppeltes_Schieberegister Das Polynom gibt dir an wo du dein XOR Gatter hast. In der Praxis wird das aber mit einer Tabelle von vorberechneten 32 Bit Werten für alle 8 Bit Zeichen gemacht.
Hans Ulli Kroll schrieb: > In der Praxis wird das aber mit einer Tabelle von vorberechneten 32 Bit > Werten für alle 8 Bit Zeichen gemacht. Nur in einer Softwarelösung. In Hardware ist das nicht nötig, auch dann nicht wenn man in einem Takt 8 bit verarbeiten möchte.
Lattice User schrieb: > Hans Ulli Kroll schrieb: > >> In der Praxis wird das aber mit einer Tabelle von vorberechneten 32 Bit >> Werten für alle 8 Bit Zeichen gemacht. > > Nur in einer Softwarelösung. > > In Hardware ist das nicht nötig, auch dann nicht wenn man in einem Takt > 8 bit verarbeiten möchte. Hoffentlich muß man sowas nicht von Hand routen oder wie es in der Fachsprache bei euch heißt. ;-) Das es dafür IPs gibt kann ich mir vorstellen.
Lars schrieb: > Ich versuche quasi eine nicht sichere Kommunikation sicherer zu machen. Was ist "sicher"? Meinst du eine "zuverlässige, fehlerfreie Übertragung" oder eine "vor Hackern gesicherte Übertragung"? Lars schrieb: > Ich habe also mir vorher bekannte Datenpakete, die ich übertragen > möchte. Welchen Einfluss kannst du auf diese Datenpakete nehmen? Zu welchem Zeitpunkt sind dir diese Datenpakete bekannt?
Musste mich da aktuell auch einarbeiten. Grundsätzlich kann ich zum Einarbeiten den englischen Wikipedia Artikel empfehlen, da er eine ausführliche Liste an weitergehender Literatur beinhaltet. https://en.wikipedia.org/wiki/Cyclic_redundancy_check Da habe ich auch dieses Buchkapitel zu CRC gefunden: Cyclic Redundancy Check: theory, practice, hardware, and software with emphasis on CRC-32. A sample chapter from Henry S. Warren, Jr. Hacker's Delight. http://www.hackersdelight.org/crc.pdf Lars schrieb: > Kann ich nun auf der Empfängerseite einfach einen definierten Startwert > der CRC Berechnung nehmen, damit sie am Ende er Übertragung 0 ist? Du musst einen definierten Startwert benutzen. > Wie kann ich diesen Startwert berechnen? Nichts berechnen. Der Startwert muss gleich sein wie beim Sender. > Ich habe jetzt die Übertragung einmal mit dem Startwert 0 laufen lassen > und hatte am Ende eine Prüfsumme. Nun hatte ich gedacht, dass ich diese > Prüfsumme als Startwert nehme und damit am Ende 0 erhalte, wenn sich die > übertragenden Pakte nicht ändern. Falsch gedacht. Grundlagen lesen. Währe in der Praxis auch ineffizient, da der CRC Wert ja in einer seriellen Übertragung immer als letztes gesendet wird. Dann müsst man nach deinem Schema ja bis zum letzten Bit warten, bis man überhaupt beginnen kann die Daten CRC zu prüfen. Der Empfänger macht das selbe wie der Sender. Startwert nehmen, alle Daten durch die CRC Prüfung lassen. Und dann entweder: - Resultierende Prüfsumme mit der soeben empfangenen Prüfsumme vergleichen - Empfangene Prüfsumme am Ende auch durch die CRC Prüfung lassen. Resultat beim Empfänger muss 0 sein. Das CRC Polynom ist schon fix vorgegeben oder kannst du das noch frei wählen?
Lars schrieb: > Hallo und vielen Dank! > > Ich habe die CRC Berechnung quasi nur auf der Empfangsseite. > > Klassisch ist es ja so, dass man auf der Senderseite die CRC Summe > bildet, mit überträgt und diese dann mit der CRC Summe der > Empfängerseite vergleicht. Korrekt? > Falsch Es gibt noch einen Trick Die Magic Number Es wird der CRC negiert übertragen und mit in den CRC verrechnet. Dann kommt als Erbebnis die Magic Numer raus. Warum frag mich nicht. Ich habe mal eine CRC Funktion in VHDL geschrieben zu finden in Beitrag "Ethernet GMII" >Kann ich nun auf der Empfängerseite einfach einen definierten Startwert >der CRC Berechnung nehmen, damit sie am Ende er Übertragung 0 ist? Dafür brauchst du die inverse CRC Engine. Wie die genau aus sieht kann ich dir nicht sagen.
Hans Ulli Kroll schrieb: > Lattice User schrieb: >> Hans Ulli Kroll schrieb: >> >>> In der Praxis wird das aber mit einer Tabelle von vorberechneten 32 Bit >>> Werten für alle 8 Bit Zeichen gemacht. >> >> Nur in einer Softwarelösung. >> >> In Hardware ist das nicht nötig, auch dann nicht wenn man in einem Takt >> 8 bit verarbeiten möchte. > > Hoffentlich muß man sowas nicht von Hand routen oder wie es in der > Fachsprache bei euch heißt. ;-) > > Das es dafür IPs gibt kann ich mir vorstellen. http://www.electronicdesignworks.com/utilities/crc_generator/crc_generator.htm Funktioniert einwandfrei.
Lars schrieb: > Ich versuche quasi eine nicht sichere Kommunikation sicherer zu machen. > Das geht aber nur, weil ich die Daten kenne, die ich schicke. Sonst wäre > das natürlich Quark ;) Wenn man die Daten kennt, braucht man sie gar nicht schicken! Irgendwo muss also eine Information stecken. Aber ich nehme an, Du meinst, dass es nur eine begrenzte Anzahl verschiedener Pakete gibt, und Du möchtest einen schnellen Weg um zu kontrollieren, ob das einzelne Paket richtig angekommen ist. CRC ist da meiner Meinung nach nicht der richtige Weg, weil CRC auf der Idee basiert, dass man zum Paket REDUNDANTE Information dazufügt, damit man am Ende zwischen (vielen) ungültigen und einem gültigen Paket unterscheiden kann. Was Du meiner Meinung nach brauchst, ist eine Methode, um aus einem möglicherweise gestört empfangenen Paket da "ähnlichste" herauszusuchen. Suche in Richtung Hamming Distanz.
Hallo zusammen und vielen Dank! Lothar Miller schrieb: > Was ist "sicher"? Meinst du eine "zuverlässige, fehlerfreie Übertragung" > oder eine "vor Hackern gesicherte Übertragung"? Sicher im Sinne von zuverlässig/fehlerfrei... > Welchen Einfluss kannst du auf diese Datenpakete nehmen? Zu welchem > Zeitpunkt sind dir diese Datenpakete bekannt? Die Datenpakete sind Registerwerte, die ich lese. Deren Inhalt möchte ich prüfen. Und zwar nicht jedes für sich, sondern irgendein Wert, der den Inhalt aller Register wiederspiegelt... daher bin ich auf die CRC gekommen. Christoph Z. schrieb: > Falsch gedacht. Grundlagen lesen. > Währe in der Praxis auch ineffizient, da der CRC Wert ja in einer > seriellen Übertragung immer als letztes gesendet wird. Dann müsst man > nach deinem Schema ja bis zum letzten Bit warten, bis man überhaupt > beginnen kann die Daten CRC zu prüfen. Ich will die CRC Summe gar nicht übertragen. Sie soll quasi schon im Voraus bekannt sein. Nur, dass ich eben am Ende auf 0 prüfen möchte und nicht auf die Summe. Daher dachte ich, ich kann von 0 ausgehend die komplette CRC Berechnung rückwärts ausführen und damit einen konkreten Startwert generieren. Wenn ich dann von diesem Startwert aus die CRC Berechnung ausführe, sollte doch am Ende 0 rauskommen, oder? Statt einem Startwert und der CRC Berechnung, die zu einer CRC Summe verrechnet werden, habe ich die CRC Summe und die CRC Berechnung und will den Startwert ausrechnen. Nun ist die Frage, wie rechne ich alles rückwärts aus? Klaus Falser schrieb: > Wenn man die Daten kennt, braucht man sie gar nicht schicken! > Irgendwo muss also eine Information stecken. Eigentlich schicke ich keine Information mit. Ich will den CRC nur dazu missbrauchen, um die Korrektheit der Daten zu ermitteln. Stell Dir vor, Du hast eine Tabelle mit 1000 Zeilen. Nun willst Du den Inhalt dieser Tabelle prüfen. Du vergleichst also Zeile 1 mit der Zeile 1 deiner Vergleichstabelle, Zeile 2 mit Zeile 2 usw. Du hast also die Tabelle und eine Vergleichstabelle - also zwei Tabellen. Ich will nun den Inhalt der Tabelle, also alle Zeilen nacheinander CRC verrechnen und dann mit einer einfachen Vergleichsoperation prüfen, ob der Inhalt plausibel ist oder nicht. Vielen Dank! Lars :)
Na das war aber eine schwere Geburt. Wenn ich das mal mit eigenen Worten zusammenfassen darf: 1. Du hast eine begrenzte Anzahl von Telegrammen die von einem Gerät zum anderen gesendet werden. 2. Der Absender ist bzgl. aller seiner Eigenschaften fest definiert und kann nicht verändert werden. 3. Du entwirfst den Empfänger 4. Du möchtest eine Sicherung der Übertragung gegen Übertragungsfehler einbauen. 5. Dein Ansatz ist: Eine CRC über die Telegramme zu erstellen und diesen CRC auf der Empfangsseite prüfen. 6. Die CRC-Vorschrift soll so zu "gestaltet" sein, das für jedes Telegramm 0 herauskommt. OK. 1. Du musst wissen (und möchtest bitte hier mal angeben) wieviele verschiedene Telegramme du übertragen möchtest. 2. Du musst wissen ob Dir ALLE möglichen Telegramme bekannt sind. D.h. ob Du jedes einzelne Telegramm bzw. seinen Inhalt angeben kannst. 3. Du musst von jedem Telegramm wissen wie lang es ist bzw. falls alle gleichlang sind, wie diese Länge ist. Daraus ergibt sich dann folgendes. Du musst für alle möglichen Telegramme zusammen eine Vorschrift "ermitteln" die dann und nur dann 0 ergibt falls das empfangene Telegramm genau eines der möglichen Telegramme ist. Das ist garnicht mal so trivial. Wie gross der Aufwand ist, hängt im wesentlichen von der Anzahl und Länge der Telegramme ab.
Das stimmt so eigentlich nicht mit Deinem Ansatz überein:
>6. Die CRC-Vorschrift soll so zu "gestaltet" sein, das für jedes
Telegramm 0 herauskommt.
sondern, Du willst bei einer feststehenden Vorschrift den Startwert so
berechnen, das sich am Ende 0 (oder ein anderer Wert ergibt) ergibt.
Als Lösungsansatz würde ich von der arithmetischen/diophantischen Beschreibung der CRC ausgehen. Die hättest dann eine Menge von Gleichungen zu lösen. Die Anzahl der Gleichungen entspricht der Anzahl der möglichen Telegramme. Die Anzahl der Variablen der Anzahl der Bits in den Telegrammen. (Bei variablen Anzahlen wird es ein wenig komplizierter).
Lars schrieb: > Stell Dir vor, Du hast eine Tabelle mit 1000 Zeilen. Nun willst Du den > Inhalt dieser Tabelle prüfen. Du vergleichst also Zeile 1 mit der Zeile > 1 deiner Vergleichstabelle, Zeile 2 mit Zeile 2 usw. Du hast also die > Tabelle und eine Vergleichstabelle - also zwei Tabellen. > Ich will nun den Inhalt der Tabelle, also alle Zeilen nacheinander CRC > verrechnen und dann mit einer einfachen Vergleichsoperation prüfen, ob > der Inhalt plausibel ist oder nicht. Mal sehen ob ich jetzt nachkomme. Die Tabelle und die Vergleichstabelle hast du zu diesem Zeitpunkt zur Hand? Du kannst im Vornhein schon die CRC Summe der Vergleichstabelle bilden. Dann würde es so laufen: Den CRC Wert der Vergleichstabelle hinten an die Tabelle anhängen. Die CRC Summe ausrechnen für die Tabelle inkl. dem zusätzlichen Wert. Das Ergebnis ist bei korrektheit 0.
Faultier schrieb: > Daraus ergibt sich dann folgendes. > Du musst für alle möglichen Telegramme zusammen eine Vorschrift > "ermitteln" die dann und nur dann 0 ergibt falls das empfangene > Telegramm genau eines der möglichen Telegramme ist. > > Das ist garnicht mal so trivial. Wie gross der Aufwand ist, hängt im > wesentlichen von der Anzahl und Länge der Telegramme ab. Dazu kommt noch, dass es vorraussetzt dass sich alle legalen Telegramme in vielen Bits unterscheiden müssen (Hamming Distanz). Das es es aber um Registerwerte geht, dürfte das nicht erfüllbar sein. Z.b. wenn ein Registerwert 8 oder 9 sein kann, kann ein Bit fehlerhaft übertragen werden ohne dass der Fehler erkannt werden kann. Gesicherte Übertragung ist das nicht. Selbst ein simple XOR Summe leistet mehr. Und CRC8 ist in HW auch nicht aufwendiger als die XOR Summe.
@ Christoph Ich glaube nicht, dass Lars Satz: > Ich will nun den Inhalt der Tabelle, also alle Zeilen nacheinander CRC > verrechnen und dann mit einer einfachen Vergleichsoperation prüfen, ob > der Inhalt plausibel ist oder nicht. so zu verstehen ist, das immer die gesamte Tabelle übertragen wird. Es scheint mir aber als wenn Du ihn so verstehst. Ich glaube er wollte nur klarstellen, das er anhand einer auf der Empfängerseite vorliegenden, aber nicht übertragenen Information! die Korrektheit feststellen will Nur meine Meinung.
@ Lattice User
> Dazu kommt noch, ... (Hamming Distanz).
Ich stimme Dir zu. Ich glaube nur nicht, das Lars schon soweit in die
Theorie eingestiegen ist.
Im übrigen setzt, meiner Meinung nach, auch das mit dem XOR voraus, das
die Sollsumme jedes einzelnen Telegramms im Empfänger gespeichert sein
muss.
Was er braucht ist vielmehr eine Vorschrift die aus der Menge aller
Telegramme auch eine individuelle Rechenvorschrift ermittelt.
Anstelle von CRC oder XOR oder was auch immer würde ich eher eine
logische Gleichung erstellen. Das ist wesentlich weniger aufwändig und
100%ig zuverlässig.
>Das ist wesentlich weniger aufwändig und 100%ig zuverlässig.
Diese Aussage ist natürlich auch von den Hamming-Distanzen abhängig.
Wie Rene oben schon mal geschrieben hat: > Startwert 0 => CRC Berechnung => Endwert XYZ > Startwert XYZ => CRC Berechnung => Endwert 0? > Haut das so hin? gilt NICHT!! Es gilt: > Startwert => CRC Berechnung => Endwert XYZ > Startwert => CRC Berechnung + XYZ => Endwert 0 oder magic Number (abhängig von: ob normaler oder invertierter Startwert!! )? Wichtig ist im Gegensatz zur einfachen Checksummenberechnung im Einerkompliment ist die CRC-Berechnung abhängig von der Reihenfolge der Daten!!
Faultier schrieb: > > Im übrigen setzt, meiner Meinung nach, auch das mit dem XOR voraus, das > die Sollsumme jedes einzelnen Telegramms im Empfänger gespeichert sein > muss. > Ich meinte er soll ein Prüfbyte mit übertragen am besten ein CRC8 und nicht das Rad neu erfinden. Alles andere ist ein Riesenaufwand und unzuverlässig.
@ Lattice User >Ich meinte er soll ein Prüfbyte mit übertragen... Das Problem ist nur, das er den Sender nicht verändern kann/will/darf. Beitrag "Re: CRC Prüfsumme mit bekanntem Startwert"
Hallo zusammen, vielleicht war es etwas unglücklich von mir formuliert. Aber gehen wir mal von der Sender-Empfänger Geschichte weg - ich bin nur auf der Empfängerseite. Vom Sender wird ein Register-Array gefüllt, dessen Inhalt ich selber definiere und damit kenne. Ich weiß also, welche Daten ich in diesem Array erwarte. Anstatt nun jedes einzelne Bit dieses Arrays separat zu prüfen, ob es denn auch korrekt ist, wollte ich eine CRC über das gesamte Array bilden, um dessen Korrektheit zu prüfen. Dabei geht es mir nicht um 100% Sicherheit. Mir ist bewusst, dass auch eine CRC Summe zumindest statistisch gesehen Fehler "übersehen" kann. Faultier schrieb: > 1. Du musst wissen (und möchtest bitte hier mal angeben) wieviele > verschiedene Telegramme du übertragen möchtest. Die Anzahl steht noch nicht fest. Wird aber vielleicht so um die 20-30 32Bit Werte gehen. > 2. Du musst wissen ob Dir ALLE möglichen Telegramme bekannt sind. D.h. > ob Du jedes einzelne Telegramm bzw. seinen Inhalt angeben kannst. Das kann ich! > 3. Du musst von jedem Telegramm wissen wie lang es ist bzw. falls alle > gleichlang sind, wie diese Länge ist. Alle Telegramme sind 32bit lang. > Daraus ergibt sich dann folgendes. > Du musst für alle möglichen Telegramme zusammen eine Vorschrift > "ermitteln" die dann und nur dann 0 ergibt falls das empfangene > Telegramm genau eines der möglichen Telegramme ist. Und genau das wollte ich, indem ich den Startwert so geschickt wähle, dass am Ende der CRC Berechnung 0 herauskommt. Oder ist es naturgemäß bei der CRC Berechnung unmöglich, dass auch mal 0 als Zwischenergebnis/Endergebnis steht? Der Weg zum Endergebnis sieht ja normalerweise so aus: Startwert + Telegramm 1 = Zwischenwert 1 Zwischenwert 1 + Telegramm 2 = Zwischenwert 2 usw. Zwischenwert 27 + Telegramm 28 = Endergebnis/CRC Prüfsumme Ich möchte nun folgendes tun, um meinen idealen Startwert zu ermitteln, bei dem am Ende 0 herauskommt: 0 + Telegramm 28 = Zwischenwert 27 Zwischenwert 27 + Telegramm 27 = Zwischenwert 26 usw. Zwischenwert 2 + Telegramm 2 = Zwischenwert 1 Zwischenwert 1 + Telegramm 1 = Startwert Wenn ich jetzt mit diesem Startwert die normale Berechnung durchführe (natürlich mit den gleichen Telegrammen!), sollte doch wieder 0 am Ende stehen, oder? Vielen Dank! Lars :)
Lars schrieb: > Und genau das wollte ich, indem ich den Startwert so geschickt wähle, > dass am Ende der CRC Berechnung 0 herauskommt. warum willst du dir unbedingt einen vorab berechneten Startwert merken und den Empfänger auf Null vergleichenlassen? Berechne doch vorab die CRC-Summe über das dir bekannte Datenpaket (nicht im Sender, sondern auf dem PC mit dem du den Code für den Empfänger erstellst). Merke dir das Ergebnis in der Konfiguration des Empfänger-FPGAs uns lass den Empfänger prüfen, ob das richtige Ergebnis rauskommt (das dann eben nicht gleich Null ist). Ob du den magischen Startwert oder das Ergebnis der CRC-Berechnung merkst, bleibt sich doch gleich (bis auf vielleicht einen Takt latenz bei der Auswertung).
>Aber gehen wir mal von der Sender-Empfänger Geschichte weg - ich bin nur >auf der Empfängerseite. Das ist nicht möglich. Das ist, als wenn Du vom gehen schreiben willst und den Untergrund ignorieren. Es frustriert mich ein wenig das Du (jedenfalls für mein Verständnis) die Situation veränderst (nun wird ein komplettes Array von Telegrammen übertragen und nicht einzelne Telegramme) und das Du auf deiner Lösung herumreitest, obwohl, wieder nach meiner Meinung, das Problem noch garnicht vollständig und (mir) verständlich beschrieben ist. Es scheint mir, als wenn Du die Bedeutung der Ausgangssituation völlig unterschätzt. Ich werde mich also heraushalten soweit die Vorbedingungen (siehe Beitrag "Re: CRC Prüfsumme mit bekanntem Startwert") nicht in zufriedenstellender Weise und Umfang definiert sind. Ansonsten rät man hier nur herum.
Aber um mal direkt auf Deine Frage nach der Berechnung eines Startwertes
zu antworten, folgendes:
Der Algorithmus für die Berechnung eines CRC ist wie folgt:
Schieberegister := 0000… (Startwert)
solange Bits im Datenstrom verbleiben:
falls das am weitesten links stehende Bit vom Schieberegister
ungleich dem nächsten Bit aus dem Datenstrom ist:
Schieberegister := (Schieberegister linksschieben um 1, rechtes Bit
0)
xor CRC-Polynom
andernfalls:
Schieberegister := Schieberegister linksschieben um 1, rechtes Bit 0
nächstes Bit im Datenstrom
Schieberegister enthält das Ergebnis.
(das ist eine Kopie aus dem Wikipedia-Artikel)
Den brauchst Du nur umzukehren. Dann hast Du den Startwert.
Ob Dir das was nutzt? Mal sehen.
>Ob Dir das was nutzt? Mal sehen.
Damit man mir nicht etwa Böswilligkeit unterstellen kann, noch
folgendes:
Du siehst einen Schritt genannt "links schieben". Wenn Du den umkehren
willst, musst Du Dich entscheiden ob Du eine 0 oder eine 1 rechts
hereinschiebst. Wie entscheidest Du Dich? Oder probierst Du alle
möglichen Kombinationen aus. Bei sagen wir mal 8 Byte, also 64 Bit sind
das so ungefähr 2^64 Kombinationen. Happy Probing, dann.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.