Difference between revisions of "Special Features"

 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
<br />  
 
<br />  
 
{|
 
{|
|<strong>Binary patching.</strong> 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).  
+
|<strong>Reproducible Wi-Fi interference generation.</strong> D-Cube embeds <i>JamLab-NG</i>, 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 sent by the BCM43430A1 Wi-Fi module embedded in the Raspberry Pi 3, 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 [https://github.com/seemoo-lab/nexmon NexMon] and is [http://www.iti.tugraz.at/JamLab-NG openly available] to the community. An article describing JamLab-NG in detail is available as PDF [http://www.carloalbertoboano.com/documents/schuss19jamlabng.pdf here]. For a description of the jamming patterns currently available in D-Cube, please refer to [[Jamming patterns|this page]].
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). Essentially, the developers add a new section to their base 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 define user-defined protocol parameters, a useful feature to check which protocol parameters actually deliver the best performance.  
 
 
|[[File:empty.png|left|195px]]
 
|[[File:empty.png|left|195px]]
|[[File:Binary_patching.png|1475px|right]]
+
|[[File:jamlabng_architecture.png|2475px|right]]
 
|}
 
|}
  
 
{|
 
{|
|<strong>EEPROM mailbox. </strong> D-Cube makes use of an EEPROM acting as a mailbox between the benchmarking infrastructure and the target nodes running the firmware under test in order to schedule the transmission and timestamp the reception of data packets.  
+
|<strong>Binary patching.</strong> 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, an I2C bus is shared between each D-Cube's [[Observer Nodes|observer node]] and the target nodes (Tmote Sky, nRF52840) connected to it. D-Cube signals the availability of new data to be transmitted from a given node by loading the information onto the EEPROM and by toggling a pre-defined GPIO pin. Conversely, a target node can signal the reception of new data by writing it to the EEPROM and by raising a pre-defined GPIO pin accordingly. D-Cube then verifies the correctness of the information written in the EEPROM and uses the GPIO rising edge timestamp to compute the end-to-end latency of communications in the network. For more information, please refer to the [[Logistics Information|logistics information page]].
+
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). Essentially, the developers add a new section to their base 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 define user-defined protocol parameters, a useful feature to check which protocol parameters actually deliver the best performance.  
 
|[[File:empty.png|left|195px]]
 
|[[File:empty.png|left|195px]]
|[[File:jamlabng_architecture.png|2475px|right]]
+
|[[File:Binary_patching.png|1475px|right]]
 
|}
 
|}
  
 
{|
 
{|
|<strong>Reproducible Wi-Fi interference generation.</strong> D-Cube embeds <i>JamLab-NG</i>, 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 sent by the BCM43430A1 Wi-Fi module embedded in the Raspberry Pi 3, 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 [https://github.com/seemoo-lab/nexmon NexMon] and is [http://www.iti.tugraz.at/JamLab-NG openly available] to the community. An article describing JamLab-NG in detail is available as PDF [http://www.carloalbertoboano.com/documents/schuss19jamlab-ng.pdf here].
+
|<strong>EEPROM mailbox. </strong> D-Cube makes use of an EEPROM acting as a mailbox between the benchmarking infrastructure and the target nodes running the firmware under test in order to schedule the transmission and timestamp the reception of data packets. In particular, an I2C bus is shared between each D-Cube's [[Observer Nodes|observer node]] and the target nodes (Tmote Sky, nRF52840) connected to it. D-Cube signals the availability of new data to be transmitted from a given node by loading the information onto the EEPROM and by toggling a pre-defined GPIO pin. Conversely, a target node can signal the reception of new data by writing it to the EEPROM and by raising a pre-defined GPIO pin accordingly. D-Cube then verifies the correctness of the information written in the EEPROM and uses the GPIO rising edge timestamp to compute the end-to-end latency of communications in the network. For more information, please refer to [[How to Use|this page]].
 
|[[File:empty.png|left|195px]]
 
|[[File:empty.png|left|195px]]
|[[File:jamlabng_architecture.png|2475px|right]]
+
|[[File:dcube_eeprom.png|2775px|right]]
 
|}
 
|}

Latest revision as of 22:18, 2 June 2021


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 sent by the BCM43430A1 Wi-Fi module embedded in the Raspberry Pi 3, 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. For a description of the jamming patterns currently available in D-Cube, please refer to this page.
Empty.png
Jamlabng architecture.png
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). Essentially, the developers add a new section to their base 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 define user-defined protocol parameters, a useful feature to check which protocol parameters actually deliver the best performance.

Empty.png
Binary patching.png
EEPROM mailbox. D-Cube makes use of an EEPROM acting as a mailbox between the benchmarking infrastructure and the target nodes running the firmware under test in order to schedule the transmission and timestamp the reception of data packets. In particular, an I2C bus is shared between each D-Cube's observer node and the target nodes (Tmote Sky, nRF52840) connected to it. D-Cube signals the availability of new data to be transmitted from a given node by loading the information onto the EEPROM and by toggling a pre-defined GPIO pin. Conversely, a target node can signal the reception of new data by writing it to the EEPROM and by raising a pre-defined GPIO pin accordingly. D-Cube then verifies the correctness of the information written in the EEPROM and uses the GPIO rising edge timestamp to compute the end-to-end latency of communications in the network. For more information, please refer to this page.
Empty.png
Dcube eeprom.png