Difference between revisions of "Special Features"
| Line 4: | Line 4: | ||
In particular, D-Cube directly injects these input parameters into the firmware under test by exploiting a well-known data structure, as explained in [http://www.carloalbertoboano.com/documents/schuss18benchmark.pdf this paper] (Section IV). The developers add a new section to their firmware containing an instance of the well-known data structure assigning placeholder values for all its fields that will be automatically replaced by D-Cube's binary patching framework. The latter even allows developers to change user-defined protocol parameters, to check which protocol parameters actually deliver the best average performance. | In particular, D-Cube directly injects these input parameters into the firmware under test by exploiting a well-known data structure, as explained in [http://www.carloalbertoboano.com/documents/schuss18benchmark.pdf this paper] (Section IV). The developers add a new section to their firmware containing an instance of the well-known data structure assigning placeholder values for all its fields that will be automatically replaced by D-Cube's binary patching framework. The latter even allows developers to change user-defined protocol parameters, to check which protocol parameters actually deliver the best average performance. | ||
|[[File:empty.png|left|195px]] | |[[File:empty.png|left|195px]] | ||
| − | |[[File:Binary_patching.png| | + | |[[File:Binary_patching.png|1475px|right]] |
|} | |} | ||
Revision as of 13:27, 10 November 2019
| Binary patching. D-Cube embeds the ability to build and apply patches to binary files. This allows a large degree of freedom when testing protocol performance: binary patching allows indeed D-Cube to seamlessly benchmark the firmware under test for different sets of input parameters, such as the amount of data to be transmitted, traffic patterns and load, as well as node identity (i.e., address of the source and destination nodes).
In particular, D-Cube directly injects these input parameters into the firmware under test by exploiting a well-known data structure, as explained in this paper (Section IV). The developers add a new section to their firmware containing an instance of the well-known data structure assigning placeholder values for all its fields that will be automatically replaced by D-Cube's binary patching framework. The latter even allows developers to change user-defined protocol parameters, to check which protocol parameters actually deliver the best average performance. |
 |
 |
EEPROM mailbox. D-Cube signals Messages to be sent over the network are available in an EEPROM connected via I2C bus • CAT24M01 EEPROM (located at address 0x50 on the bus), datasheet: https://www.onsemi.com/pub/Collateral/CAT24M01-D.PDF • The I2C bus is shared between the testbed’s observer module (Raspberry Pi 3) and the target node (TelosB replica) • A pre-defined GPIO pin is used to signal that data is available For more information, please refer to the logistics information page.
Reproducible Wi-Fi interference generation.
D-Cube embeds JamLab-NG, an open-source framework allowing the generation of controllable Wi-Fi interference using the off-the-shelf devices such as the Raspberry Pi 3. JamLab-NG enables the fine-grained control of individual link-layer frames, avoiding the uncontrollable delays introduced by the network stack, operating system, and clear channel assessment procedure. JamLab-NG also allows generating repeatable Wi-Fi interference patterns by controlling radio settings such as the transmission speed and the packet length, which would otherwise be automatically adapted by the radio firmware at runtime. Each observer node in D-Cube can act as an interfering device using JamLab-NG in parallel to its measurement tasks. The JamLab-NG code is based on NexMon and is openly available to the community. An article describing JamLab-NG in detail is available as PDF here.