## 3 Platform for Real-Life Testing of Communication Protocols  
### Testbed Environment  
The primary objective of the testing platform that has been developed is to enable the testing and evaluation of communication protocols that have been implemented in GNU radio in real traffic scenarios. Conducting tests in such circumstances is vital for verification, validation, and acceptance testing. It is also helpful for dynamic white box testing that is carried out to assess the quality indicators of the implemented protocols. An environment was created to run and evaluate GNU radio applications in real traffic scenarios. This environment allows network traffic to be sent through the GNU radio application under test. Linux network namespaces isolate the environment, making managing multiple environments on the same or multiple machines easier. This is particularly useful when multiple SDR-based applications are running on a remote server, like in the case of the test platforms described in [37; 38]. The block diagram in Figure 1 shows that TUN/TAP interfaces [39] are used to channelize the data traffic to or from the GNU radio application under test. Depending on its characteristics, the application under test is connected to one or several TUN/TAP interfaces. The framework supports two types of environments: one that allows testing of GNU radio applications in simulated conditions and another that allows testing when SDR boards are connected in the transmission chain. In simulated conditions, both transceivers run in the same environment, while in a real transmission scenario involving real channels, they run in separate environments and possibly on different machines. For example, in a simplex simulated transmission, the transmitter application reads the data from one interface, and the receiver application writes the output data on the other interface. In a duplex scenario, the transmitter and receiver read and write data to their interface. In the concrete case presented in Figure 1, the tested application connects to bidirectional tun0/tap0 and tun1/tap1 interfaces (in the left-side positioned environment) or only to the tun0/tap0 interface (in the right-side positioned environment). In order to allow applications running in the environment to access the internet, all environments are connected to the host through a network bridge (i.e., dtl-br). The network bridge [40] is configured on the host machine, and for each environment, a pair of virtual interfaces (i.e., *-with and *-wpeer) are set up. One interface is attached to the environment, and the other is attached to the bridge. Since Layer 2 connectivity is established between the environments and the host, only network addressTranslation (NAT) of packets originating from the environments is required. This is illustrated in Figure 2.  
To confirm that traffic passes through the bridge to the host and beyond the internet, we run a traceroute command in our environment (refer to Figure 3) to a public IP address outside our network (i.e., 8.8.8). Figure 1: Schematic of the environment encapsulating the application under test. Figure 2: Applying netfilter rules for NAT at the gateway. To ensure that the test traffic passes through the application under test, the routing rules need to be manipulated as follows:  
1. It is important to ensure that the outgoing traffic through the TUN/TAP interfaces of the system is not routed through the loopback interface as the application is interacting with these interfaces. To do this, the default local routes associated with these interfaces should be removed. 2. The kernel uses the local routing table for incoming (ingress) traffic to decide if a packet is addressed to the local host. Therefore, it is necessary to create an alternative routing rule that is only used for ingress traffic.