Netzwerkprotokoll für RFM12

[markusj]

Generell lauft es ja so ab, dass das RFM12 einen Interrupt verursacht in dem ich dann die Daten abholen kann. Wenn der Frame komplett ist, muss auf den Units natürlich entschlüsselt und geantwortet werden. Das würde ich auch noch in der ISR erledigen sodass dann das Frame im Reinformat im Buffer liegt um dann im normalen Programmablauf (nicht mehr zeitkritisch) abgearbeitet wird. (z.B.: LampeX in 3sec auf 10% dimmen)
Der Buffer soll die Schnittstelle zwischen Protokoll und Ausführung sein.

Kann man tun. Oder man parst die Daten schon während du sie bekommst. Ich fahre in der Regel ein hybrides Konzept, die ersten Protokollschichten arbeiten ohne Pufferung, und irgendwann beginnt dann der Bereich, in dem die Daten zwischengelagert werden. Momentan plane ich eine flexible Stack-Architektur, mit der man da relativ frei einzelne Schichten zusammenstöpseln kann, ohne allzugroßen Overhead.

mfG
Markus

[lokirobotics]

Tokenring zusammen mit Koordinator finde ich ein wenig "komisch". Tokenringe sind ja extra dafür da, dass man keinen zentralen Koordinator braucht. Je nach deiner gewünschten Systemarchitektur würde ich entweder einen Master einsetzen, der alle Slaves pollt (imho nich so schön), oder allen Knoten das Senden erlauben und CSMA/CD einsetzen.
Weiterhin würde ich mich ein wenig am OSI-Modell orientieren und die einzelnen Aspekte der Datenübertragung in entsprechende Layer verpacken. So kannst du dich immer um ein Problem alleine kümmern/adressieren. Falls du später noch andere Übertragungskanäle hinzu nimmst, ist deine Software auch besser wiederverwendbar.

Zum Thema AES:
-du bräuchtest dafür ja einen zentralen Schlüssel => wenn dir mal ein Knoten abhanden kommt (z.B. Aussenthermometer), dann ist das gesamte System komprommitiert und du musst an allen Knoten den Schlüssel ändern
-Schlüsselweitergabe: Wie? Per Hand an den Knoten, oder per Software über Funk (unsicher)

Wenn du verschlüsselst, dann besser Asymmetrisch. Broadcasts fallen dann allerdings aus . Alternativ natürlich Schlüsselübergabe asymmetrisch und dann gemeinsam symmetrisch. Ist aber ein riesen Aufwand. Vor allem, die Algorithmen sicher zu implementieren.
Deswegen solltest du überlegen, ob die Nachrichten wirklich geheim, oder "nur" gesichert sein müssen.
Viel einfacher ist es, die Nachrichten zu signieren und so die Integrität derselben sicherzustellen. So kann jeder Knoten überprüfen, ob eine Nachricht wirklich legitim, oder von außen in das System eingebracht worden ist (Stichwort Türöffner ;D).
Man könnte z.B. ein Challenge-System einsetzen, mit dem sich die Knoten untereinander authentifizieren können. Nur sone Idee, da gibt es noch tausend andere Möglichkeiten.

Auf jeden Fall hast du dir da ein interessantes Aufgabengebiet rausgesucht. Ich wünsche dir viel Spaß beim rumexperimentieren und lernen!

[wkrug]

Eventuell ist für dich ja auch das Keylock Sytem von Microchip für Dich geeignet?!
Dabei wird ein fester Schlüssel verwendet, aber mit einem Counter jede Nachricht mit einem anderen Code verschlüsselt.
Die Slaves haben wiederum einen jeder für sich einen eignenen Schlüssel, der vom Master eingelernt werden muß.
Erst nach 65636 Nachrichten kommt wieder der erste Code zur Anwendung.
Die letzten 32000 Schlüssel werden ignoriert.

[cd_brenner]

Tokenring zusammen mit Koordinator finde ich ein wenig "komisch". Tokenringe sind ja extra dafür da, dass man keinen zentralen Koordinator braucht. Je nach deiner gewünschten Systemarchitektur würde ich entweder einen Master einsetzen, der alle Slaves pollt (imho nich so schön), oder allen Knoten das Senden erlauben und CSMA/CD einsetzen.

Ich glaube, dass "Tokenring" hier einfach der falsche Ausdruck ist.
Im Endeffekt sitzt in der Mitte ein Master der nacheinander zu jedem Slave eine Verbindung aufbaut und so die Daten von einem Slave zum anderen durchroutet.
Beim echten Tokenring baut ja der Slave die Verbindung zum nächsten Slave in der Runde auf.

-du bräuchtest dafür ja einen zentralen Schlüssel => wenn dir mal ein Knoten abhanden kommt (z.B. Aussenthermometer), dann ist das gesamte System komprommitiert und du musst an allen Knoten den Schlüssel ändern

Du meinst jetzt, wenn das komplette Gerät entführt wird? Ist es denn so einfach den Sourcecode auf einem Microcontroller auszulesen und v.a. dort den Schlüssel auszulesen?

Wenn du verschlüsselst, dann besser Asymmetrisch. Broadcasts fallen dann allerdings aus

Wenn ich jetzt mal davon ausgehe, dass mir keine Einheit (physisch) abhanden kommen kann, verwende ich einfach ein gemeinsames Geheimnis mit dem alle Daten ver- und entschlüsselt werden. Das sollte ja eigentlich relativ easy funktionieren, oder?

Vielen Dank!

[markusj]

Du meinst jetzt, wenn das komplette Gerät entführt wird? Ist es denn so einfach den Sourcecode auf einem Microcontroller auszulesen und v.a. dort den Schlüssel auszulesen

Wenn du die entsprechenden Lockbits deines µC setzt, nein.

mfG
Markus

[lokirobotics]

Ich glaube, dass "Tokenring" hier einfach der falsche Ausdruck ist.
Im Endeffekt sitzt in der Mitte ein Master der nacheinander zu jedem Slave eine Verbindung aufbaut und so die Daten von einem Slave zum anderen durchroutet.
Beim echten Tokenring baut ja der Slave die Verbindung zum nächsten Slave in der Runde auf.

Deshalb ja TokenRING

Dass kein Gerät abhanden kommen kann, glaube ich nicht. Man denke nur an den Aussen-Temperatur-Sensor. Wie wichtig das Geheimnis ist und wie wahrscheinlich eine Komprommitierung ist, sei dahingestellt. Da du aber verschlüsseln willst, scheint es ja wichtig zu sein.

Lockbits sind übrigens keine Hilfe, wenn jemand wirklich an die Daten will.
Vergleiche dazu Schobert, Martin "All Chips Reversed" in "Die Datenschleuder" #94, 2010 Seite 17ff.

Wenn du allerdings sicherstellen kannst, dass nichts abhanden kommen kann (dieses Wissen solltest du dann an Tresorhersteller verkaufen ;D), spricht erstmal nichts gegen ein shared secret.
Was bleibt ist das, schon eingangs von mir erwähnte, Problem der Schlüsselweitergabe und, vor allem, Änderung.

Hast du schon über das Thema Nachrichtensicherung vs -verschlüsselung nachgedacht?

MfG

[cd_brenner]

Hey,
da jetzt mit dem ganzen Projekt einiges weitergegangen ist, möchte ich hier mal ein Dankeschön für die nette und kompetente Unterstützung bedanken. Ich neige dazu, ein Thema zuerst geistig ziemlich eng abzustecken bevor ich ans experimentieren gehe. Über die freien Weihnachtstage möchte ich aber auf jeden Fall versuchen eine Platine zu ätzen und mit 2 RFM12s auf den Pollin Boards herumzuspielen.

Hast du schon über das Thema Nachrichtensicherung vs -verschlüsselung nachgedacht?

Hier gefällt nach reichlicher Überlegung der Ansatz mit dem Signieren der Daten eigentlich am besten, v.a. weil sich das Erkennen von Übertragungsfehlern und die sichere Herkunft der Daten in einem Rutsch prüfen lässt. Da ich mit "Daemon" auch gewisse Standards für die Units festlegen will (zu dem eine ISP Buchse gehört) werde ich das gemeinsame Geheimnis einfach als Konstante im Code führen und beim Flashen mitübertragen.

Ich glaube du möchtest dich Mal ein wenig in Richtung Multitasking auf µCs informieren. Solche einfachen zeitgesteuerten Aufgaben kann man relativ einfach über eine Warteschlange lösen, die in regelmäßigen Abständen (Timer!) gepollt wird. (Stichwort: Delta-Queue). Im Wesentlichen musst du dich einfach darauf einstellen, dass deine Funktionen nicht mehr blockierend warten, sondern sich ihren Zustand merken und dann andere Funktionen weiterrechnen lassen. Das nennt man kooperatives Multitasking.

Mit dieser Aussage konnte ich zum Zeitpunkt an dem sie geschrieben wurde absolut nichts anfangen. Ich bin es nicht gewohnt, dass ein Programm/Skript quasi in einer Endlosschleife läuft und ich keine nativen Funktionen hab um mir die Zeit einzuteilen. Wird aber sicher noch hochinteressant und lehrreich.

Schon klar, aber: Du unternimmst damit noch nicht einmal den Versuch, eine stabile Kommunikation zu schaffen, weil du im Zweifelsfalle schon vor Kommunikationsbeginn aufgibst. Bei einer guten Funkverbindung sollte das eber weniger problematisch sein ...

Du meinst also, dass ich ähnlich wie bei einer fehlerhaften Datenübertragung auch auf fehlerhafte Tokenübertragung mit direkter Sendewiederholung reagieren soll?
Was bringt mir das für Vorteile wenn die Unit direkt nochmal das Token bekommt anstatt erst in der nächsten Runde?

Die Wolken um diese Thematik haben sich auch noch nicht ganz gelichtet, denn die Frage der Frequenz, mit der die einzelnen Units gepollt werden ist noch immer offen. Auf der einen Seite steht hier die kurze Latenzzeit dem Strom-Spar-Faktor und den gesetzlichen Gegebenheiten gegebüber. Um schnellstmöglich ein Datenpaket zu übertragen ist der Tower/Master ständig mit dem Routen der Pakete beschäftigt, empfängt oder sendet Frames, immer. Ich schätze, dass die Polling-Frequenz relativ hoch sein wird, weshalb so bremsen möchte, dass jede Unit ca. 5x pro Sekunde das Token erhält. Auch zu den rechtlichen Auflagen in Österreich finde ich kaum brauchbare Informationen, habe aber was von DutyCycle max. 10% oder so gelesen.

Ich bedanke mich schon im Voraus für die Mühe.
Die Projektübersicht gibts auch auf: http://neox.ws/clouds/daemonbio.html

[wkrug]

Für die Funk Vorgaben gibt es schon eine Seite.
Ist aber irgendwie "Beamtentypisch" aufgebaut. Da sind zwar alle benötigten Informationen enthalten, aber schwer zu finden.
Hauptseite:
http://www.cept.org/
Subclass Short Range devices:
http://www.cept.org/ecc/topics/srd-r...nt-sub-classes