# SDToW: A Slowloris Detecting Tool for WMNs
## 5 Results  
Figure 7 presents our test scenario running on a network laboratory. All the APs in our scenario do not use Network Address Translation (NAT). The APs operate with two different interfaces, one providing client connection, and the other interface provides connections between the APs. For client connection, we use the IEEE 802.11 ac/n/a 5 GHz interface.  
Figure 7: Experimental scenario.  
The connection between the APs utilizes the IEEE 802.11b/g/n 2.4 GHz creating an ad-hoc WMN. The WMN uses the Optimized Link State Routing Protocol (OLSR) [48]. The parameters of OLSR used were the following: the interval between HELLO messages was equal to 1.5 s, and the Link state messages were sent every 5 s. The multipoint relays use these Link state messages to calculate the topology map. Hence, we installed two packages in the wireless routers: Openwrt_luci_app_olsr and Openwrt_luci_app_olsr_services. These packages permit the creation of ad-hoc routes using the OLSR protocol. We also use the Expected Transmission Count (ETX) metric to optimize the routing selection. The ETX metric can be defined as the expected number of transmissions required to deliver a packet over a given link [49]. This metric calculates the weight of a given route by using the sum of all ETX weights. Each ETX weight informs the value for every link on a path. This ETX weight guarantees the objective proposed by the metric of choosing routes that decrease the total number of retransmissions at the link level along the way. We also use the following hardware:  
* 5 TP-Link-Archer-C20.v4 wireless routers.
* 2 15-4590 computers with 8 GB RAM
* 5 AMD A8-4500M notebooks with 8 GB of RAM.  
Concerning the operating system, we use Ubuntu 18 for the Web server and the notebooks. We replace the original APs firmware with the Open-WRT [50]. Open-WRT is a Linux operating system targeting embedded devices. Performing this replacement allowed our module BM to run directly on the APs. Our Web application server uses the Apache2 version 2.4.7.  
We collect information regarding the required time to transfer the traffic list and the blacklist. Additionally, we measure the processing time of our modules. That information allowed us to obtain the total blocking time. The combination of the information collected is explained below.  
* Collection count (\(C_{C}\))--time in which the CM, running on the Web server, collects information regarding the network traffic and creates the traffic list.
* Transfer list time (\(TL_{T}\))--the required time to send the traffic list from CM to the Concentrator.
* Traffic list processing time (\(TL_{T}\))--the required time to analyze the traffic list using the AFM filters. If it finds malicious traffic, it creates the blacklist.
* Blacklist transfer time (\(BL_{T}\))--the time needed to transfer the blacklist from the AFM to the APs.
* Blocking time (\(B_{T}\))--the time required to process and block malicious IPs address from the blacklist by the BM.  
In our experiments, \(C_{C}\) uses 5 s to collect traffic information and generates the traffic list. The parameters described above define the total blocking time (\(TB_{T}\)) on the equation below:  
\[TB_{T}=C_{C}+TL_{T}+TL_{T}+BL_{T}+B_{T} \tag{1}\]  
Equation (1) presents the sum of all related time values that directly impacts the total blocking time \(TB_{T}\). Concerning the blacklist transfer, we observe that the number of hops produces jitter variation regarding the required time to transfer the list. This jitter variation motivates the second experiment to analyze it on multiple hops scenario. The transfer list time (\(TL_{T}\)) and traffic list processing time (\(TL_{T}\)) vary according to the traffic list size. The traffic list size and how it interferes with the blocking time motivated us to conduct experiments to analyze it. Below, we describe two experiments to analyze the blocking attack performance.