Hallo zusammen, Wenn ich über sagen wir mal 20 Byte eine CRC-16 (CCITT, Polynom 0x1021, Startwert 0xFFFF) rechne, ist es dann überhaupt möglich, dass als CRC 0xFFFF herauskommt? Ich vermute "nein", aber warum wäre das so? Und falls "nein" falsch ist - welche 20 Byte wären das? Zu dieser Frage habe ich leider keine Antwort bei google gefunden. Vielleicht weiß hier jemand was darüber... Danke, Andario
Und weshalb nicht ? Eigentlich muesste irgend eine Zahl moeglich sein. Ich denke, schon nach 2 bytes muesste irgend eine Zahl als CRC moeglich sein.
Ändere einfach mal ein Bit ab, dann muss was anderes bei rauskommen
Hi, dass was anderes rauskommt, wenn ich ein bit ändere ist schon klar. Das ist ja der Sinn hinter der CRC. Vielleicht nochmal zur Erklärung, worauf ich hinaus will: Wir haben ein System mit 2 Teilnehmern. A sendet Parameter (ca. 20 Byte) an B. B macht damit etwas und rechnet zur Kontrolle über die tatsächlich verwendeten Parameter eine CRC. Diese soll zur Gegenprüfung wieder an A gesendet werden. Falls B einen Fehler bei seiner Aktion festgestellt hat, soll stattdessen 0xFFFF übermittelt werden, damit A weiß, dass etwas schief gegangen ist. Deshalb die Frage, ob es eine Kombination von 20 Byte gibt, deren CRC mit dem gegebenen Polynom und Startwert 0xFFFF geben kann. Wie würde ich diese Kombination finden? Grüße, Andario
Warum sollte B die CRC zurücksenden? Sinnvoller wäre es, wenn A diese berechnet und gleich mit sendet, dann weiß B, ob die Parameter richtig angekommen sind. Sollte er dabei einen Fehler feststellen, sendet er einen eigenen Status zurück, der auch beinhalten kann "Parameter noch mal senden"
Hi, dieses Ping-Pong-Spiel ist Teil eines Sicherheitskonzepts, ich hab mir das nicht ausgedacht. Es geht nicht nur darum, zu prüfen, ob die Parameter richtig übertragen wurden (dann wäre dein Ansatz ausreichend), sondern es soll auch geprüft werden ob B die Parameter auch wirklich verwendet hat, und nicht vielleicht noch die vorherigen. Also nicht nur CRC über den RX Buffer. Also zurück zur Frage: Ist es rein mathematisch möglich, dass 0xFFFF rauskommt?
Ja. In hex: 000099C0 -> 0xFFFF AFFE9A51 -> 0xFFFF CAFE6E8E -> 0xFFFF https://crccalc.com/ Euer Sicherheitskonzept müsste mal durch nen Review, so ergibt das wenig Sinn. Ich kann dir da innerhalb von wenigen Sekunden nahezu beliebige Outputs generieren.
Gast
#6192669
Eine (gute) 16bit CRC findet beliebige bitfehler innerhalb von 16 Bit. Im einfachsten Fall: sende jeweils nur 2 Byte, von 0 bis 65535, dann muss jede Telegramm eine andere CRC ergeben. Und genau eine davon ist 0xffff. Nehmt also lieber ein zusätzliches Byte oder Bit, um "Fehler" zu signalisieren. und wenn es im 7ten Byte ist, weil dessen Wert nur bis 42 geht.
A. S. schrieb: > Eine (gute) 16bit CRC findet beliebige bitfehler innerhalb von 16 Bit. > Im einfachsten Fall: sende jeweils nur 2 Byte, von 0 bis 65535, dann > muss jede Telegramm eine andere CRC ergeben. Und genau eine davon ist > 0xffff. Dann kann man gleich alle Daten immer doppelt senden und sich CRC sparen.
Cyblord -. schrieb: > A. S. schrieb: >> Eine (gute) 16bit CRC findet beliebige bitfehler innerhalb von 16 Bit. >> Im einfachsten Fall: sende jeweils nur 2 Byte, von 0 bis 65535, dann >> muss jede Telegramm eine andere CRC ergeben. Und genau eine davon ist >> 0xffff. > > Dann kann man gleich alle Daten immer doppelt senden und sich CRC > sparen. Sehe ich auch so. Ein CRC bietet keine 100% Sicherheit, dass die Daten korrekt sind, nur eine hohe Wahrscheinlichkeit.
Cyblord -. schrieb: > Dann kann man gleich alle Daten immer doppelt senden und sich CRC > sparen. Wenn du sie sogar 3 mal sendest kannst du nachher demokratisch entscheiden, wer vermutlich korrekt ist. Das 3 Übertragungen gestört sind kann vorkommen, dass alle 3 an der selben Stelle gestört sind ist indes sehr unwahrscheinlich
Wenn Du es sicher willst bau zwei "gelbe Container" bestehend aus
1. - Nutzdaten
Zähler oder Zeit des Absendens
CRC über Container 1
2. - Nutzdaten invers
Zähler oder Zeit des Absendens
CRC über Container 2
Füge Container 1 + 2 zusammen und bilde über diese Daten eine weitere
CRC.
Das ist schon ziemlich sicher.
Merke bei den CRCs können die gleichen CRCs für unterschiedliche Daten
vorkommen (Hamming Distanz)
Gruß
Erich24
Christian B. schrieb: > Wenn du sie sogar 3 mal sendest kannst du nachher demokratisch > entscheiden, wer vermutlich korrekt ist. Das 3 Übertragungen gestört > sind kann vorkommen, dass alle 3 an der selben Stelle gestört sind ist > indes sehr unwahrscheinlich Kommt aufs Fehlermodell an. Es kann schon Bitfolgen geben die anfälliger sind als andere. Kommt auf den Übertragungskanal an. Bevor wir hier groß spekulieren: @andario: Gib uns doch bitte ein paar Infos mehr zu deiner Anwendung. Dann lässt sich das was sinnvolles überlegen. Aktuell ist es nur Stochern im Nebel. - Wieviel Daten? - Welche Daten? - Wie übertragen? - Welche Bandbreite hast du zur Verfügung? - Wie groß ist die geschätzte Fehlerwahrscheinlichkeit? - Wie gefährlich ist das Auftreten eines Fehlers? (Tod, Sachschäden, genervter Benutzer, ?)
Ein guten Protokol ansat ist zB :
A) Cmd + CRC --> B) CRC ok, mach was
<-- B) Antwort + Data + neuer CRC
B) CRC falsch, mach nichts
A) timeout.
Gast
#6198226
Johnny B. schrieb: > Cyblord -. schrieb: >> A. S. schrieb: >>> Eine (gute) 16bit CRC findet beliebige bitfehler innerhalb von 16 Bit. >>> Im einfachsten Fall: sende jeweils nur 2 Byte, von 0 bis 65535, dann >>> muss jede Telegramm eine andere CRC ergeben. Und genau eine davon ist >>> 0xffff. >> >> Dann kann man gleich alle Daten immer doppelt senden und sich CRC >> sparen. > > Sehe ich auch so. > Ein CRC bietet keine 100% Sicherheit, dass die Daten korrekt sind, nur > eine hohe Wahrscheinlichkeit. Es geht doch nicht darum, eine CRC auf 2 Bytes zu setzen. Und die Daten doppelt ist dann noch weniger sicher wegen common cause. Es ging darum, dass der TO wissen wollte, ob es eine bestimmte CRC gibt. Und ich habe dargelegt, dass jeder beliebige Datenstrom durch 2 weitere Bytes zu jeder gewünschten CRC führt. Selbst ohne vorherige Daten.
Hallo! Der Sender selbst kann doch verhindern, dass seine eigene CRC 0xFFFF ist. Durch setzen eines ungenutzten Bits in einem Datenbyte kann er selbst sicherstellen, dass das Datentelegramm nie den Wert 0xFFFF als CRC ergibt. Das war jetzt einfach.
Hallo zusamen, danke für die rege Beteiligung! Wir haben uns jetzt auch überlegt, dass man ja einfach beim Erstellen der Parameter schon pfüfen kann, dass 0xFFFF nicht vorkommt, und falls doch einfach ein ungenutztes Bit (wir haben sogar in einem Kontrollbyte noch reservierte bits!) verwenden kann um das zu verhindern. Grüße, Andario
Andreas H. schrieb: > wir haben sogar in einem Kontrollbyte noch reservierte bits Dann verstehe ich das ganze Gebastel nicht; dann kannst Du ja gleich so eines nehmen um besagten Fehler zu signalisieren und nicht die CRC dafür zu missbrauchen.