Versteht jemand die Aktion von Elektor und embedded-projects? http://www.iot-contest.com/ Ich bin gerade dabei, meine Hausautomatisierung mit NRF24L01+ Modulen zu machen. Natürlich werden die NRF24L01+ in einem Mesh-Netz untereinander verbunden und können damit quer durch das versorgte Gebiet funken. Natürlich werden die Daten verschlüsselt, damit auch Haustür- und Garagentüröffner möglich sind, siehe Beitrag "Re: Verschlüsselung einer Funkstrecke - Hat jemand einen Tipp?" Und natürlich wird es ein Gateway ins LAN geben, z.B. mit einer neuen Firmware auf Ebay-Artikel Nr. 231118158116. Der NRF24L01+ hat eine maximale Paket-Größe von 32 Bytes. Was ich z.B. nicht verstehe: > "Das Protokoll sollte daher ASCII-basiert und nicht binär sein." Warum diese Forderung? Bei einem HMAC mit SHA-256 habe ich 20 Byte für Nutzdaten frei. Warum darf man hier nicht binär sein? Ich denke, preiswertere Lösungen werden sich ggf. durchsetzen. Kommen werden sie eh: Wenn nicht aus Europa, dann aus China. > "Eine Verschlüsselung oder Sicherung soll als Erweiterung möglich > sein (Optional kann man HTTPS verwenden)." Aha! ???
:
Bearbeitet durch User
Torsten C. schrieb: >> "Das Protokoll sollte daher ASCII-basiert und nicht binär sein." Damit man überteuerten Scheiß an Idioten verkaufen kann. Schön das du auf NRF24L01+ umgestiegen bist.
Torsten C. schrieb: >> "Das Protokoll sollte daher ASCII-basiert und nicht binär sein." > > Warum diese Forderung? Das Wort "daher" legt nahe, daß die Begründung im Satz davor steht.
Davor ist folgender Punkt: "Zu Testzwecken soll man mit Teilnehmern per Standard-Browser kommunizieren können (Eingabe in der Adresszeile, Ausgabe im HTML-Fenster)." siehe http://www.iot-contest.com/index.php?content=infos
Na also, da hast Du die Antwort: Damit es leichter zu testen ist.
Kommt drauf an, wieviele Schichten man verwenden will und wo dann die Verschlüsselung hinkommt. Bei einem mesh-Netzwerk findet ja sowieso Routing statt, Nachrichten werden also mehrmals weitergereicht, bevor sie ihren Empfänger erreichen. Da stellt sich automatisch die (Vertrauens-)Frage, ob die Crypto end-to-end oder hop-by-hop arbeiten soll. Und wenn man sich für end-to-end entscheidet, kann man auch gleich so eine Art TCP einführen, so daß die Nachrichten zwischen den Endpunkten unabhängig von der Paketgröße im Netzwerk sind. Beispiele für beides gibt es in der Internet-Technik ja schon: - MACsec verschlüsselt Ethernetpakete einzeln, immer auf der Strecke von einem Switch zum nächsten - HTTPS baut erstmal eine TCP-Verbindung durchs (unsichere) Netz auf und überträgt dann damit seine Crypto-Token und Nutzdaten, ohne auf die Paketgröße im Netz dazwischen Rücksicht nehmen zu müssen - IPsec liegt irgendwo dazwischen: es werden einzelne IP-Pakte verschlüsselt; das kann end-to-end, aber auch auf einer Teilstrecke passieren "Das Protokoll sollte daher ASCII-basiert und nicht binär sein." Der Grund für diese Forderung steht doch genau darüber: es soll auch per Browser funktionieren. Damit ist schonmal viel festgelegt. Wenn man schon IP benutzt, hätte ich ja SNMP als angemessener für Sensoren, Schalter und einfache Steuerungen empfunden. Das kommt an den Geräten mit weniger Ressourcen aus (z.B.kein TCP nötig), weil es die ganzen Präsentationsaufgaben (MIB interpretieren und darstellen) auf den Rechner verlagert. Aber, ja, Browser können's nicht und wer das Netz nur durch die Brille des Browsers kennt kann damit entsprechend nichts anfangen. Naja, Sicherheit als allerletzten Punkt aufzuführen, mit den Worten "optional" und "Erweiterung" dabei, zeigt ja deutlich, wo die Prioritäten nicht liegen. Damit hat sich das Konzept für Tür- Tor- und Fensteröffner ja schon disqualifiziert. (Wobei: der Schließzylinder ist in jeder Tür doch eigentlich auch nur optional, oder?)
Nosnibor schrieb: > Bei einem mesh-Netzwerk findet ja sowieso > Routing statt, … Da stellt sich automatisch die … Frage, ob die > Crypto end-to-end oder hop-by-hop arbeiten soll. Hop-by-hop klingt nach mehr Rechenaufwand. Einen Vorteil kann ich gerade nicht erkennen, also end-to-end. Wenn man Broadcast benötigt (z.B. um im ganzen Haus die gleiche Musik zu hören), müsste man das nochmal überdenken. Aber vielleicht kann man dabei auch auf Crypto verzichten. > Und wenn man sich für end-to-end entscheidet, kann man auch gleich > so eine Art TCP einführen, so daß die Nachrichten zwischen den > Endpunkten unabhängig von der Paketgröße im Netzwerk sind. 20 Bytes Headerdaten für TCP wären für den NRF24L01+ m.E. zuviel, zumal es z.B. auf dem NRF24L01-Funkkanal auch schon ein CRC gibt. Und z.B. bei einem HMAC mit SHA-256 braucht man m.E. keinen zusätzlichen CRC mehr. Ein schlankeres Transmission Control Protocol wäre trotzdem nicht schlecht. Gibt's da was, oder müsste man sich was proprietäres überlegen? > "Das Protokoll sollte daher ASCII-basiert und nicht binär sein." > Der Grund für diese Forderung steht doch genau darüber: es soll auch per > Browser funktionieren. Damit ist schonmal viel festgelegt. Das könnte im Gatway ↔ NRF24L01 ja eventuell binär komprimiert werden. Mal schauen, was beim IoT-Contest heraus kommt. Ich finde das unnötig aufwendig und würde das gern vermeiden, zumal man ja beim komprimieren gar nicht genau weiss, welche Bezeichner in den JSON-Daten verwendet werden. Wenn man also ein "Protokoll für Internet of Things" erfinden will, dann sollte man z.B. die Bezeichner festlegen, um die JSON-Daten binär komprimieren zu können. Ich habe mal den Newsletter abonniert. Mal schauen, ob das was sinnvolles kommt. PS: Remote IRMP setzt ja z.B. auch schon eine LAN-Anbindung voraus. Ich finde das etwas übertrieben.
:
Bearbeitet durch User
Copacabana schrieb: > das IoT RFC Danke. :-) Also ein neues "Constrained Application Protocol (CoAP)" über dem "User Datagram Protocol (UDP)". Mal sehen, wie man das mit dem NRF24L01+ verheiratet. PS: > "CoAP itself does not provide protocol primitives for authentication > or authorization" Hmmm. Klingt nach viel Overhead.
:
Bearbeitet durch User
Torsten C. schrieb: > Hop-by-hop klingt nach mehr Rechenaufwand. Einen Vorteil kann ich gerade > nicht erkennen, also end-to-end. Der Vorteil bei hop-by-hop ist, daß alle höheren Protokolle es nur noch mit authentischen Paketen von offiziellen Netzteilnehmern zu tun haben. Die "Angriffsfläche" für irgendwelche trickreich gefälschten Pakete ist also geringer. Ein Beispiel aus der IP-Welt: SYN-flooding nutzt eine Eigenheit von TCP aus, um ohne Aufwand beim Angreifer Ressourcen beim Empfänger zu blockieren. SSL (end-to-end, oberhalb von TCP) hilft nicht dagegen. MACsec würde helfen. Aber TCP in voller Pracht und Schönheit hat in einem Netz mit 32 Byte Paketgröße sowieso nichts verloren. IPv4 kann zwar theoretisch fragmentieren, das ist aber bei weitem nicht robust genug (und bei so kleinen Paketen barbarisch ineffizient). Ich meinte nur, daß man von TCP einige Eigenschaften oder Tricks abgucken kann, z.B. das Aufteilen größerer Datenmengen in einzelne Pakete, das Bestätigen empfangener Pakete, das Wiederholen unbestätigter Pakete und die ganzen Timer, die man dafür braucht. Wobei mich bei TCP immer genervt hat, daß es nicht Pakete sondern Bytes verwaltet, was die Nummern länger macht. Vielleicht hat HDLC etwas passenderes zu bieten. Eines ist aber klar: 32 Bytes Paketgröße ist ungeeignet für IP (min. 20 Bytes Header), und wenn man das Internet Protocol nicht nutzen kann, wird es wohl auch nichts mit dem Internet of Things. Ist aber auch Quatsch, in jedem Lichtschalter TCP/IP zu rechnen. Es sei den, man wollte Hardware verkaufen (http://www.elektor.com/e-lock )…
Nosnibor schrieb: > und wenn man das Internet Protocol nicht nutzen kann, > wird es wohl auch nichts mit dem Internet of Things. Zum Thema "Internet of Things": Die Botschaft hör ich wohl (seit Jahren), allein mir fehlt der Glaube (zumindest in den nächsten Jahren). Daher ich schrieb: > Ich denke, preiswertere Lösungen werden sich ggf. durchsetzen. Kommen > werden sie eh: Wenn nicht aus Europa, dann aus China. Mir wär's nur ganz lieb, wenn man solche "preiswerteren Lösungen" trotzdem irgendwie kompatibel halten könnte, über ein Gateway. > Bis 2022 wird der durchschnittliche Haushalt mit zwei jugendlichen > Kindern rund 50 Geräte besitzen, die mit dem Internet verbunden sind. Aus: http://www.pressetext.com/news/20130424002 Wenn pro Funkknoten ein NRF24L01+ verwendet wird statt WLAN und man bei WLAN mit etwa 8€ Mehrpreis pro Knoten rechnet, dann sind das pro Haushalt 400€ mehr. Das bezahlt doch keiner!
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.