0xFFFF als CRC-16 möglich?

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.

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.

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.