Netzwerkprotokoll für RFM12

[cd_brenner]

Hallo Community,

seit einigen Monaten - nach einer C-Vorlesung in der Uni - habe ich mich mit dem Thema "Microcontroller" zu beschäftigen begonnen und einiges darüber gelesen. Ich finde diese Dinger genial, vor allem die Vielfältigkeit reizt mich besonders.
Da ich zur Zeit am Bauen eines Terrariums bin möchte ich dieses natürlich mit einem AVR Microcontroller steuern. Grundsätzlich will ich allerdings mehrere Units in meiner Wohnung haben die unterschiedliche Aufgaben übernehmen und vor allem miteinander über RFM12 Module kommunizieren können.
Als Beispiel soll das Terrarium die Uhrzeit von der Digitaluhr ablesen können.

Ich habe deshalb auch begonnen ein Netzwerkprotokoll zu entwerfen - vorerst nur theoretisch auf Papier. Ich würde auf ein zentral gesteuertes System setzen in dem ein "Tower" alle Units nacheinander fragt ob sie Daten zu senden haben (Token Ring) und die Datenframes vom Sender zum Empfänger leitet.
Um Sendefehler zu erkennen verwende ich eine CRC Checksumme im Datenframe.

Hier das Schema:
23370

Ad 1)
Der Tower wählt die nächste UnitID aus seinem Speicher und versucht dieser das Sendetoken zu schicken.

Ad 2)
Die Unit bestätigt den Tokenerhalt oder reagiert nicht nach einer bestimmten Zeit.

Ad 3)
Der Tower versucht einen Datenframe* zu senden oder sendet ein READY, wenn keine Daten zum Senden vorhanden sind.
Falls ein Timeout passiert wird das Token an die nächste Unit weitergegeben.

Ad 4)
Falls ein Datenframe ankommt wird dieser auf Gültigkeit** untersucht und im FIFO gespeichert, damit er später weiterverarbeitet werden kann.
Wenn ein Fehler auftritt wird der Frame (NAK) nocheinmal angefordert. (max. 3x)
Wenn Daten zum Senden vorhanden sind werden diese an den Tower zurückgesendet, ansonsten: READY.

Ad 5)
Der Frame wird wieder auf Gültigkeit** überprüft und ggf. gespeichert, wenn die Daten ungültig sind werden sie erneut angefordert.
Wenn ein NAK ankommt (= Datenfehler Unit) wird das Datenpaket erneut gesendet.
Falls READY ankommt (= Unit hatte keine Daten) wird das Token weitergegeben.

Ad 6)
Sobald das Token weitergegeben wurde hat die Unit keine Sendeerlaubnis mehr.
Wenn ein NAK ankommt werden die Daten erneut gesendet.

* ein Datenframe könnte wie folgt aussehen:

ID | TIME | sender | empfänger | DATA | CRC

** Gültigkeit:

Jede Unit speichert empfangene IDs für eine Zeit von X Sekunden in einer Blocklist und verwift Datenframes mit dieser ID.
Jede Nachricht hat eine Lebensdauer von X Sekunden, wenn diese abgelaufen ist werden Frames auch verworfen. Damit will ich erneutes einsenden vom mitgeschnittenen Frames verhindern.

Weiters möchte ich die Datenpakete mittels AES verschlüsseln um dem ganzen System mehr Sicherheit zu verleihen. Jede Unit soll dabei einfach einen geheimen Key gespeichert haben und damit die Datenframes verschlüsseln.

Mich würde interessieren ob dieses Projekt in der Praxis umsetzbar ist, wo es scheitern könnte, und wie man es verbessern kann.

Vielen Dank,
Markus

[markusj]

Eigentlich ist das kein Token-Passing sondern eher ein Polling-Verfahren bei dem der pollende Master in "Tower" umbenannt wurde.
Zwei Dinge:
1. Du möchtest die Sendeaufforderung evtl. auch wiederholen ("Token-Verlust")
2. AES erfordert einiges an Rechenleistung und außerdem hast du dann für jedes Gerät einen Public-Key. Der Sender verschlüsselt die Daten mit dem Public-Key des Empfängers. Dieser Entschlüsselt dann mit seinem Private-Key.

Normalerweise verwendet man als Medienzugriffsverfahren CSMA (im Falle der RFM-Familie ist keine CD/CA möglich). Der Polling-Ansatz ermöglicht aber prinzipiell gewisse Echtzeitgarantien, wobei das durch die Unzuverlässigkeit des Mediums eingeschränkt wird.

mfG
Markus

[cd_brenner]

1. Du möchtest die Sendeaufforderung evtl. auch wiederholen ("Token-Verlust")
Da ja der Tower die Tokens vergibt und nicht die Unit das Token weitergibt bekommt UnitX nach einer Runde ja sowiso das Token wieder, oder?


2. AES erfordert einiges an Rechenleistung und außerdem hast du dann für jedes Gerät einen Public-Key. Der Sender verschlüsselt die Daten mit dem Public-Key des Empfängers. Dieser Entschlüsselt dann mit seinem Private-Key.

Kann die geforderte Rechenleistung für die Verschlüsselung auf einem AtMega644 bei 20Mhz zum Probem werden?
Ich dachte AES ist ein symmetrisches Kryptosystem bei dem ich einen geheimen Schlüssel zum Ver- & Entschlüsseln habe.


Der Advanced Encryption Standard (AES) ist ein symmetrisches Kryptosystem
Quelle: http://de.wikipedia.org/wiki/Advanced_Encryption_Standard

Eignen sich andere Algorithmen wie XTEA oder Blowfish besser für diesen Anwendungsfall?

Vielen Dank,
Markus

[markusj]

Da ja der Tower die Tokens vergibt und nicht die Unit das Token weitergibt bekommt UnitX nach einer Runde ja sowiso das Token wieder, oder?
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 ...


Kann die geforderte Rechenleistung für die Verschlüsselung auf einem AtMega644 bei 20Mhz zum Probem werden?
Ich dachte AES ist ein symmetrisches Kryptosystem bei dem ich einen geheimen Schlüssel zum Ver- & Entschlüsseln habe.
Mein Fehler. Ich habe AES mit Public-Key-Krypto in einen Topf geworfen (und bin damit eher bei SSL rausgekommen). Davon abgesehen: Es hängt immer davon ab, wieviel Zeit du hast. Der langsamste Kryptoalgo ist kein Problem, wenn du keinen engen Zeitrahmen hast.


Vielen Dank,
Markus
Haha ;)

mfG
Markus

[cd_brenner]

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?


Es hängt immer davon ab, wieviel Zeit du hast. Der langsamste Kryptoalgo ist kein Problem, wenn du keinen engen Zeitrahmen hast.
Ganz hab ich's sowiso noch nicht heraussen wie ich mein Programm schreiben muss, damit ich den kompletten Controller nicht sperre, wenn ich z.B. 3h FadeIn bei einer Halogenlampe machen will.

Vielen Dank.

[markusj]

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?
Nehmen wir Mal an, du brauchst jede Sekunde neue Daten. Wenn das "Token" bei einem Knoten nicht ankommt, wird er im besten Fall eine Sekunde später (bei der nächsten Iteration) regieren. Oder wenn irgendetwas die Verbindung stark verschlechtert, erst noch viel später. Dieser Aussetzer kann unter Umständen zu lange für deinen Anwendungszweck sein.


Ganz hab ich's sowiso noch nicht heraussen wie ich mein Programm schreiben muss, damit ich den kompletten Controller nicht sperre, wenn ich z.B. 3h FadeIn bei einer Halogenlampe machen will.
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.

mfG
Markus

[cd_brenner]

Nehmen wir Mal an, du brauchst jede Sekunde neue Daten. Wenn das "Token" bei einem Knoten nicht ankommt, wird er im besten Fall eine Sekunde später (bei der nächsten Iteration) regieren. Oder wenn irgendetwas die Verbindung stark verschlechtert, erst noch viel später. Dieser Aussetzer kann unter Umständen zu lange für deinen Anwendungszweck sein.
Okay - jetzt hab ichs. Ich bin zu optimistisch an die Sache rangegangen und hab gedacht, dass Sendefehler eh recht selten ist. Wenn eine von 20 Tokennachrichten schief geht wärs nicht so tragisch, wenn das Ergebnis erst 1sec später kommt. Aber offenbar ist Funk doch fehleranfälliger.


Das nennt man kooperatives Multitasking.
An sowas hab ich schon gedacht: Quasi immer ein Stückerl abarbeiten sodass die Main-While nicht zu lange unterbrochen ist. Ich denke, ich werde hier relativ oft Flags einsetzen müssen um eine längere Aufgabe wie "fade über 3h ein" zu koordinieren. So wird halt der PWM-Wert alle 20ms (50hz) erhöht - pro Schleifendurchlauf 1x.

http://stefanfrings.de/avr_io/protosockets.html

LG Markus

[markusj]

Okay - jetzt hab ichs. Ich bin zu optimistisch an die Sache rangegangen und hab gedacht, dass Sendefehler eh recht selten ist. Wenn eine von 20 Tokennachrichten schief geht wärs nicht so tragisch, wenn das Ergebnis erst 1sec später kommt. Aber offenbar ist Funk doch fehleranfälliger.
Muss nicht. Kann aber. Das hängt von deinem Funkmodul, dem Rauschen was sonst noch so in der Umgebung unterwegs ist, sowie der Umgebung selbst, ab. Wenn du einen der Knoten hinter eine Blechwand steckst, kommt halt wenig Pegel beim Empfänger an.
Worauf ich hinaus wollte: Es gibt eine (dir momentan unbekannte) Verlustwahrscheinlichkeit, du solltest das also berücksichtigen und Gegenmaßnahmen einplanen.


An sowas hab ich schon gedacht: Quasi immer ein Stückerl abarbeiten sodass die Main-While nicht zu lange unterbrochen ist. Ich denke, ich werde hier relativ oft Flags einsetzen müssen um eine längere Aufgabe wie "fade über 3h ein" zu koordinieren. So wird halt der PWM-Wert alle 20ms (50hz) erhöht - pro Schleifendurchlauf 1x.
Mal rein aus Neugierde: 3h alle 20ms ein Inkrement entspricht 19-Bit PWM. Mit welchem Mikrocontroller hast du so eine hohe PWM-Auflösung?! Mir ist kein 8-Bit AVR bekannt, der das bietet.
Und Flags ... naja, ich hätte eher an Zähler gedacht. Wie gesagt, sieh dir Mal die Delta-Queue an, das eignet sich perfekt für zeitgesteuertes Task-Management.

mfG
Markus

[cd_brenner]

Muss nicht. Kann aber. Das hängt von deinem Funkmodul, dem Rauschen was sonst noch so in der Umgebung unterwegs ist, sowie der Umgebung selbst, ab. Wenn du einen der Knoten hinter eine Blechwand steckst, kommt halt wenig Pegel beim Empfänger an.
Worauf ich hinaus wollte: Es gibt eine (dir momentan unbekannte) Verlustwahrscheinlichkeit, du solltest das also berücksichtigen und Gegenmaßnahmen einplanen.
Okay - danke für deine ausführliche Erklärung!


Mal rein aus Neugierde: 3h alle 20ms ein Inkrement entspricht 19-Bit PWM. Mit welchem Mikrocontroller hast du so eine hohe PWM-Auflösung?! Mir ist kein 8-Bit AVR bekannt, der das bietet.

Bei dieser Aussage hab ich das natürlich nicht bedacht - ist aber klar, dass die Auflösung bei so vielen Werten nicht mitspielt. Ich denke die PWM Frequenz muss sowiso an den entsprechenden Anwendungsfall angepasst werden. Bei LEDs würde ich diese höher wählen als bei recht trägen Halogenspots.

Frage am Rande: Welchen MOSFET kann ich für einen 20W Halogenspot mit 12V verwenden?

Ist es klug auf einem Microcontroller den Speicher für den FrameBuffer (Nachricht empfangen -> Buffer schreiben -> Tokenweitergabe -> Buffer lesen -> Nachricht senden) dynamisch zu allokieren (malloc) - denn es ist effektiver wenn der Buffer nicht wie ein FIFO funktioniert, sondern auch Frames "in der Mitte" aus dem Buffer lesen kann, oder?

Vielen Dank.

[markusj]

Frage am Rande: Welchen MOSFET kann ich für einen 20W Halogenspot mit 12V verwenden?
So ziemlich jeder Leistungs-MOSTFET wird sich da langweilen. Nimm den günstigsten n-MOS der 2,5A oder mehr ab kann und einen niedrigen RDS_on bei Logikpegeln (5V) hat. Günstig zu haben ist zum Beispiel der IRLZ24, mit einem RDS_on von 0,1Ohm macht das eine Verlustleistung von nur 0,17W bei den 20W/12V=1,7V die da fließen.
Ach ja: Die Lampe wird mit Gleichspannung betrieben, oder? Normale MOSFETs können keine Wechselspannung schalten.


Ist es klug auf einem Microcontroller den Speicher für den FrameBuffer (Nachricht empfangen -> Buffer schreiben -> Tokenweitergabe -> Buffer lesen -> Nachricht senden) dynamisch zu allokieren (malloc) - denn es ist effektiver wenn der Buffer nicht wie ein FIFO funktioniert, sondern auch Frames "in der Mitte" aus dem Buffer lesen kann, oder?
Dynamische Speicherallokation auf Mikrocontrollern ist normalerweise eine schlechte Idee. Langsam, benötigt größere Mengen Flash für die Speicherverwaltung und ist anfällig für Speicherfragmentierung.

Was du mit dem zweiten Teil der Frage meinst, erschließt sich mir leider nicht.

mfG
Markus

[cd_brenner]

Dynamische Speicherallokation auf Mikrocontrollern ist normalerweise eine schlechte Idee. Langsam, benötigt größere Mengen Flash für die Speicherverwaltung und ist anfällig für Speicherfragmentierung.
Also besser schon beim Compillieren den max. benötigten Speicher einplanen. Verstehe.


Was du mit dem zweiten Teil der Frage meinst, erschließt sich mir leider nicht.
Nun ja - aus einem FIFO kann ich ja nur den aktuell ältesten Datensatz (First Out) lesen. Ich möchte aber Frames nicht im Buffer lassen, nur weil es zur Zeit nicht an erster Position verfügbar ist, sondern möchte an beliebigen Stellen im Buffer zugreifen können. Das sollte aber mit einer verketteten Liste kein Problem sein, oder?

LG aus Graz.

[markusj]

Nun ja - aus einem FIFO kann ich ja nur den aktuell ältesten Datensatz (First Out) lesen. Ich möchte aber Frames nicht im Buffer lassen, nur weil es zur Zeit nicht an erster Position verfügbar ist, sondern möchte an beliebigen Stellen im Buffer zugreifen können. Das sollte aber mit einer verketteten Liste kein Problem sein, oder?

FIFOs sind dafür nicht geeignet, da liegst du richtig. Normalerweise parst man die Daten aus empfangenen Paketen raus und legt sie dann in geeigneten Datenstrukturen ab, wenn man sie für länger braucht. Insbesondere trennt man eigentlich den Netzwerkstack von der weiteren Datenverarbeitung, einfach der Modularisierung/Flexibilisierung wegen.

mfG
Markus

[wkrug]

Thema FET:

Meine "Waffe" für solche Fälle ist der IRF3708.
Hat schon bei 5V sehr geringen RDS On ( 12mOhm ).
Genügend Reserven ( 63A ) - Bis 10A ohne Kühlkörper.
Leicht erhältlich, Preislich OK.

U-DS darf dabei allerdings 30V nicht überschreiten.

Wenn's was im SO8 Gehäuse sein soll - Wie wär's mit dem IRF7455.
Den verbau ich in kleineren Brushless Reglern. Ist aber etwas schwerer zu bekommen.

Da eine Halogen Lampe einen sehr geringen Kalt Widerstand hat, würde ich den FET 10fach überdimensionieren - Deshalb solche Oschis von FET Typen.

Die RFM12 Funk Module sind etwas Tricky, hast Du schon etwas Erfahrung mit den Bausteinen?

Thema Puffer:
Ich nehm für die Eingangs - Rohdaten gerne einen fixen Ringpuffer mit Schreib- und Lesezeigern.
Das schafft für den empfangenden Controller etwas Zeit für die Abarbeitung und es sollten keine Bytes verloren gehen.
Aus diesem Puffer kann man sich dann die Daten rausparsen und wieder Puffern oder in String Variablen oder struct's zur weiteren Verarbeitung ablegen.

Wenn Du die Daten schon verschlüsseln willst, würde ich versuchen ein Protokoll zu nehmen, das auch zumindest eine Einzelbit- Fehlerkorrektur erlaubt.
Wobei ich den Sinn einer Verschlüsselung für Deinen Zweck eigentlich nicht so richtig erkennen kann - Ausser als Lerneffekt, oder Kopierschutz für eventuelle Nachbauer.

[cd_brenner]

FIFOs sind dafür nicht geeignet, da liegst du richtig. Normalerweise parst man die Daten aus empfangenen Paketen raus und legt sie dann in geeigneten Datenstrukturen ab, wenn man sie für länger braucht. Insbesondere trennt man eigentlich den Netzwerkstack von der weiteren Datenverarbeitung, einfach der Modularisierung/Flexibilisierung wegen.


Thema Puffer:
Ich nehm für die Eingangs - Rohdaten gerne einen fixen Ringpuffer mit Schreib- und Lesezeigern.
Das schafft für den empfangenden Controller etwas Zeit für die Abarbeitung und es sollten keine Bytes verloren gehen.
Aus diesem Puffer kann man sich dann die Daten rausparsen und wieder Puffern oder in String Variablen oder struct's zur weiteren Verarbeitung ablegen.

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.


Meine "Waffe" für solche Fälle ist der IRF3708.
Hat schon bei 5V sehr geringen RDS On ( 12mOhm ).
Genügend Reserven ( 63A ) - Bis 10A ohne Kühlkörper.
Leicht erhältlich, Preislich OK.

Das klingt schon mal gut - vielen Dank!


Die RFM12 Funk Module sind etwas Tricky, hast Du schon etwas Erfahrung mit den Bausteinen?
Ich hab schon gelesen, dass die Dinger recht trickreich sind - allerdings ist der Preis natürlich TOP.
Erfahrung habe ich leider noch keine - aber die fehlt generell auf dem gesamten Microcontroller- und Elektronikbereich.
Ich denke die Umsetzung dieses Projekts kann im schlechtesten Fall noch Jahre in Anspruch nehmen.
Aber ich habe großes Interesse mir Fähigkeiten im Herstellen und Programmieren von Platinen in Kombination mit Microcontrollern anzueignen - insbesondere weil ich einen großen Mehrwert für mein Informatik-Studium daraus ziehen kann.


Wenn Du die Daten schon verschlüsseln willst, würde ich versuchen ein Protokoll zu nehmen, das auch zumindest eine Einzelbit- Fehlerkorrektur erlaubt.
Wobei ich den Sinn einer Verschlüsselung für Deinen Zweck eigentlich nicht so richtig erkennen kann - Ausser als Lerneffekt, oder Kopierschutz für eventuelle Nachbauer.

Also ist es ratsam einen Hamming Code in das Datenframe einzuarbeiten?
Verschlüsselung deshalb, weil ja auch recht sensible Daten über die Funkstrecke übertragen werden sollen (irgendwann mal zu mindest).
Zum Beispiel der Befehl zum Öffnen der Haustür kann - mitgehorcht und erneut eingesendet - kritisch werden. Um die Authentizität der übertragenen Daten zu wahren muss ich verschlüsseln. Mit der ID und der Sendezeit können Frames dann quasi nur 1x verwendet werden.

[wkrug]

Generell lauft es ja so ab, dass das RFM12 (http://www.shop.robotikhardware.de/shop/catalog/product_info.php?cPath=76&products_id=249&osCsid=848589e14b5e4f3621a55540af093dad) einen Interrupt verursacht
Stimmt, kann man so proggen.
Du kriegst aber pro Interrupt nur ein Byte.
Damit kannst Du erstmal gar nichts anfangen.
Ausserdem kann es ja sein, das Dir ein Byte durch die Lappen geht. Wenn das gerade ein Sync Byte war hast Du ein Problem.
In meinen unverschlüsselten ASCII Übertragungen hab ich deshalb immer ein eindeutiges Startbyte, z.B. $ und eine feste Endsequenz <CR><LF>.
Die Auswertung einen Strings erfolgt dann immer erst, wenn <CR><LF> empfangen wurde. Dann setz ich im Interrupt ein Flag und das Hauptprogramm weiss, das es etwas tun muß.
Ein $ Byte setzt bei mir den Zeiger des Auswertepuffers immer auf 0.
Verbunden mit einer CRC Checksumme kann dann eigentlich nicht mehr viel passieren, was die Datenübertragung aus dem Tritt bringen könnte.

Tritt in einem String ein Bitfehler auf der zufällig ein $ ergibt, stimmt die Checksumme nicht und der String wird verworfen.
Kommt ein <CR><LF> nicht, wird beim näcsten String wieder alles gut, weil das $ ja den Auswertestringzeiger wieder auf 0 setzt.

Den Ringpuffer muss man allerdings dann so groß machen, das mindestens 2 komplette Strings rein passen, da ja wie gesagt das <CR><LF> ja auch mal nicht kommen kann.

[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-regulations-and-indicative-list-of-equipment-sub-classes

[cd_brenner]

Hier noch was aus Österreich:
http://de.scribd.com/doc/118175993/fsbgb