Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
uberbus [2011/01/22 23:06] – 2001:a60:10ff:c401::2 | uberbus [2011/01/24 19:17] – created schneider | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Intro ====== | + | ~~REDIRECT> |
- | The uberbus | + | |
- | + | ||
- | ===== Persons ===== | + | |
- | + | ||
- | * schneider | + | |
- | * fpletz | + | |
- | * bsx | + | |
- | * neunr | + | |
- | * andi | + | |
- | + | ||
- | ===== The RS485/ | + | |
- | + | ||
- | ==== Basics ==== | + | |
- | The idea is to run several small and cheap wired or wireless networks connected to a small, embedded and IPv6 | + | |
- | capable computer like a Fonera running OpenWRT or a Dockstar running Debian. These computers then provide an | + | |
- | IPv6 capable interface to the nodes attached to them. Every node gets at least one unique address in the sub net | + | |
- | associated with this master computer. | + | |
- | + | ||
- | ==== Wired Network ==== | + | |
- | The wired network is based on a RS485 bus. It is a single master bus. The node at the master acts as the bus | + | |
- | master which periodically polls other nodes for new messages. | + | |
- | Nodes can set a preferred polling interval which is submitted when they send their discovery packet. The bus master then | + | |
- | tries to poll the node at the given interval. This is useful to lower the load on the bus which is used to poll the nodes | + | |
- | for new messages. A node which handles user input like a light switch should request a lower polling interval than | + | |
- | nodes which just gather sensor data like temperature sensors or actuators like lamps or power outlets. | + | |
- | + | ||
- | The current implementation reserves 10% of the time for polling other nodes. The nodes can request a polling interval in | + | |
- | multiples of 30ms which is the minimum polling interval supported. | + | |
- | + | ||
- | ==== Wireless Network ==== | + | |
- | The wireless part is done using cheap RFM12 modules operating at 433MHz. The system uses a CSMA/CD approach using | + | |
- | random back offs when the medium is busy. In general the wireless network is less reliable than the wired network. | + | |
- | + | ||
- | ===== Current Implementation | + | |
- | The current implementation can be found in the svn repository in the uberbus project. | + | |
- | + | ||
- | svn co https:// | + | |
- | + | ||
- | === Firmware === | + | |
- | trunk/ | + | |
- | RS485 bus and a CSMA/CD wireless network. The firmware is capable of switching from a slave mode to a master mode to | + | |
- | pose as the bus master. The code can be compiled to include either one or both of these modes. | + | |
- | + | ||
- | trunk/ | + | |
- | switch to the master role to control the bus when attached to a host computer. | + | |
- | === Software === | + | |
- | trunk/ | + | |
- | and usage of this tool is described on [[ubd|this]] page. | + | |
- | + | ||
- | trunk/ | + | |
- | simple to set up compared to ubd and doesn' | + | |
- | computer and accepts the same packet format as ubd. | + | |
- | + | ||
- | trunk/ | + | |
- | Currently a second library is supplied to access moodlamps which are connected to the bus. | + | |
- | + | ||
- | ===== Internal specification | + | |
- | ==== Packet Description ==== | + | |
- | Packets are encapsulated in frames specific to the interface on which they are transmitted. This is transparently | + | |
- | encapsulated in the interface drivers in the firmware. | + | |
- | + | ||
- | The actual packets always have the following format: | + | |
- | ^Position^Length^Description^ | + | |
- | |0|1 Byte|Source| | + | |
- | |1|1 Byte|Destination| | + | |
- | |2|1 Byte|Flags| | + | |
- | |3|1 Byte|Length| | + | |
- | |4| |Data| | + | |
- | + | ||
- | Address format on the local segment: | + | |
- | ^Mask^Description^ | + | |
- | |0xxxxxx|Unicast| | + | |
- | |1xxxxxx|Multicast| | + | |
- | |1111111|Broadcast| | + | |
- | + | ||
- | Flags: | + | |
- | ^Value^Name^Description^ | + | |
- | |0x01|ACK|The packet contains a valid ack sequence| | + | |
- | |0x02|SEQ|The sequence number of the data transmitted| | + | |
- | |0x04|NOACK|This data doesn' | + | |
- | |0x08|MGT|This packet contains bus management data| | + | |
- | |0x10|UNSOLICITED|This packets is not part of a connection| | + | |
- | |0x20|ACKSEQ|The ack sequence transmitted with the ack| | + | |
- | + | ||
- | + | ||
- | + | ||
- | Idea: | + | |
- | Compare with implementation by jolly: | + | |
- | [[http:// | + | |
- | Jolly does not have source dest mac, as he thinks of a single master, which sets | + | |
- | a master-flag so the slave knows if he has to listen (master flag set) | + | |
- | Maybe, we can combine the ideas. | + | |
- | (luja) | + | |
- | + | ||
- | ==== IPv6 ==== | + | |
- | + | ||
- | Es werden hierbei globale IPv6-Adressen fuer jedes Device zugeordnet. Um Authentifizierung und zum Schutz vor Replay Attacks zu gewaehrleisten wird IPsec AH (alternativ ESP fuer Verschluesselung) eingesetzt. Jeder HSC3 kuemmert sich hierbei um die Authentifizierung/ | + | |
- | + | ||
- | Jeder HSC3 bekommt ein /112 Subnetz zugewiesen, wie z.B. 2001: | + | |
- | + | ||
- | ==== Authentifikation / Authorisierung ==== | + | |
- | + | ||
- | Die Authentifizierung der Keys sollte von einem weiteren Rechner (brezn) durchgefuehrt werden. Hierbei waere eine feingranulare Moeglichkeit der Rechtevergabe zu implementieren (z.B. Zugriff auf bestimmte Klassen von Devices). Die Daten zur Authentifikation sollten aus dem LDAP gezogen werden. Zur Authorisierung soll eine weitere Datenbank zu diesem Zweck erstellt werden. | + |