aboutsummaryrefslogtreecommitdiffstats log msg author committer range
path: root/doc/testing_tools.doxygen
blob: a2ae0c250fddaf0a239ab9556de8e6748df0958a (plain)
 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295  /** \page testing_tools Testing and development tools [ \ref eapol_test "eapol_test" | \ref preauth_test "preauth_test" | \ref driver_test "driver_test" | \ref unit_tests "Unit tests" ] %wpa_supplicant source tree includes number of testing and development tools that make it easier to test the programs without having to setup a full test setup with wireless cards. In addition, these tools can be used to implement automatic tests suites. \section eapol_test eapol_test - EAP peer and RADIUS client testing eapol_test is a program that links together the same EAP peer implementation that %wpa_supplicant is using and the RADIUS authentication client code from hostapd. In addition, it has minimal glue code to combine these two components in similar ways to IEEE 802.1X/EAPOL Authenticator state machines. In other words, it integrates IEEE 802.1X Authenticator (normally, an access point) and IEEE 802.1X Supplicant (normally, a wireless client) together to generate a single program that can be used to test EAP methods without having to setup an access point and a wireless client. The main uses for eapol_test are in interoperability testing of EAP methods against RADIUS servers and in development testing for new EAP methods. It can be easily used to automate EAP testing for interoperability and regression since the program can be run from shell scripts without require additional test components apart from a RADIUS server. For example, the automated EAP tests described in eap_testing.txt are implemented with eapol_test. Similarly, eapol_test could be used to implement an automated regression test suite for a RADIUS authentication server. eapol_test uses the same build time configuration file, .config, as %wpa_supplicant. This file is used to select which EAP methods are included in eapol_test. This program is not built with the default Makefile target, so a separate make command needs to be used to compile the tool: \verbatim make eapol_test \endverbatim The resulting eapol_test binary has following command like options: \verbatim usage: eapol_test [-nWS] -c [-a] [-p] [-s] \ [-r] [-t] [-C] \ [-M] eapol_test scard eapol_test sim [debug] options: -c = configuration file -a = IP address of the authentication server, default 127.0.0.1 -p = UDP port of the authentication server, default 1812 -s = shared secret with the authentication server, default 'radius' -r = number of re-authentications -W = wait for a control interface monitor before starting -S = save configuration after authentiation -n = no MPPE keys expected -t = sets timeout in seconds (default: 30 s) -C = RADIUS Connect-Info (default: CONNECT 11Mbps 802.11b) -M = Set own MAC address (Calling-Station-Id, default: 02:00:00:00:00:01) \endverbatim As an example, \verbatim eapol_test -ctest.conf -a127.0.0.1 -p1812 -ssecret -r1 \endverbatim tries to complete EAP authentication based on the network configuration from test.conf against the RADIUS server running on the local host. A re-authentication is triggered to test fast re-authentication. The configuration file uses the same format for network blocks as %wpa_supplicant. \section preauth_test preauth_test - WPA2 pre-authentication and EAP peer testing preauth_test is similar to eapol_test in the sense that in combines EAP peer implementation with something else, in this case, with WPA2 pre-authentication. This tool can be used to test pre-authentication based on the code that %wpa_supplicant is using. As such, it tests both the %wpa_supplicant implementation and the functionality of an access point. preauth_test is built with: \verbatim make preauth_test \endverbatim and it uses following command line arguments: \verbatim usage: preauth_test \endverbatim For example, \verbatim preauth_test test.conf 02:11:22:33:44:55 eth0 \endverbatim would use network configuration from test.conf to try to complete pre-authentication with AP using BSSID 02:11:22:33:44:55. The pre-authentication packets would be sent using the eth0 interface. \section driver_test driver_test - driver interface for testing wpa_supplicant %wpa_supplicant was designed to support number of different ways to communicate with a network device driver. This design uses \ref driver_wrapper "driver interface API" and number of driver interface implementations. One of these is driver_test.c, i.e., a test driver interface that is actually not using any drivers. Instead, it provides a mechanism for running %wpa_supplicant without having to have a device driver or wireless LAN hardware for that matter. driver_test can be used to talk directly with hostapd's driver_test component to create a test setup where one or more clients and access points can be tested within one test host and without having to have multiple wireless cards. This makes it easier to test the core code in %wpa_supplicant, and hostapd for that matter. Since driver_test uses the same driver API than any other driver interface implementation, the core code of %wpa_supplicant and hostapd can be tested with the same coverage as one would get when using real wireless cards. The only area that is not tested is the driver interface implementation (driver_*.c). Having the possibility to use simulated network components makes it much easier to do development testing while adding new features and to reproduce reported bugs. As such, it is often easiest to just do most of the development and bug fixing without using real hardware. Once the driver_test setup has been used to implement a new feature or fix a bug, the end result can be verified with wireless LAN cards. In many cases, this may even be unnecessary, depending on what area the feature/bug is relating to. Of course, changes to driver interfaces will still require use of real hardware. Since multiple components can be run within a single host, testing of complex network configuration, e.g., large number of clients association with an access point, becomes quite easy. All the tests can also be automated without having to resort to complex test setup using remote access to multiple computers. driver_test can be included in the %wpa_supplicant build in the same way as any other driver interface, i.e., by adding the following line into .config: \verbatim CONFIG_DRIVER_TEST=y \endverbatim When running %wpa_supplicant, the test interface is selected by using \a -Dtest command line argument. The interface name (\a -i argument) can be selected arbitrarily, i.e., it does not need to match with any existing network interface. The interface name is used to generate a MAC address, so when using multiple clients, each should use a different interface, e.g., \a sta1, \a sta2, and so on. %wpa_supplicant and hostapd are configured in the same way as they would be for normal use. Following example shows a simple test setup for WPA-PSK. hostapd is configured with following psk-test.conf configuration file: \verbatim driver=test interface=ap1 logger_stdout=-1 logger_stdout_level=0 debug=2 dump_file=/tmp/hostapd.dump test_socket=/tmp/Test/ap1 ssid=jkm-test-psk wpa=1 wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP wpa_passphrase=12345678 \endverbatim and started with following command: \verbatim hostapd psk-test.conf \endverbatim %wpa_supplicant uses following configuration file: \verbatim driver_param=test_socket=/tmp/Test/ap1 network={ ssid="jkm-test-psk" key_mgmt=WPA-PSK psk="12345678" } \endverbatim %wpa_supplicant can then be started with following command: \verbatim wpa_supplicant -Dtest -cpsk-test.conf -ista1 -ddK \endverbatim If run without debug information, i.e., with \verbatim wpa_supplicant -Dtest -cpsk-test.conf -ista1 \endverbatim %wpa_supplicant completes authentication and prints following events: \verbatim Trying to associate with 02:b8:a6:62:08:5a (SSID='jkm-test-psk' freq=0 MHz) Associated with 02:b8:a6:62:08:5a WPA: Key negotiation completed with 02:b8:a6:62:08:5a [PTK=TKIP GTK=TKIP] CTRL-EVENT-CONNECTED - Connection to 02:b8:a6:62:08:5a completed (auth) \endverbatim If test setup is using multiple clients, it is possible to run multiple %wpa_supplicant processes. Alternatively, the support for multiple interfaces can be used with just one process to save some resources on single-CPU systems. For example, following command runs two clients: \verbatim ./wpa_supplicant -Dtest -cpsk-test.conf -ista1 \ -N -Dtest -cpsk-test.conf -ista2 \endverbatim This shows following event log: \verbatim Trying to associate with 02:b8:a6:62:08:5a (SSID='jkm-test-psk' freq=0 MHz) Associated with 02:b8:a6:62:08:5a WPA: Key negotiation completed with 02:b8:a6:62:08:5a [PTK=TKIP GTK=TKIP] CTRL-EVENT-CONNECTED - Connection to 02:b8:a6:62:08:5a completed (auth) Trying to associate with 02:b8:a6:62:08:5a (SSID='jkm-test-psk' freq=0 MHz) Associated with 02:b8:a6:62:08:5a WPA: Key negotiation completed with 02:b8:a6:62:08:5a [PTK=TKIP GTK=TKIP] CTRL-EVENT-CONNECTED - Connection to 02:b8:a6:62:08:5a completed (auth) \endverbatim hostapd shows this with following events: \verbatim ap1: STA 02:b5:64:63:30:63 IEEE 802.11: associated ap1: STA 02:b5:64:63:30:63 WPA: pairwise key handshake completed (WPA) ap1: STA 02:b5:64:63:30:63 WPA: group key handshake completed (WPA) ap1: STA 02:2a:c4:18:5b:f3 IEEE 802.11: associated ap1: STA 02:2a:c4:18:5b:f3 WPA: pairwise key handshake completed (WPA) ap1: STA 02:2a:c4:18:5b:f3 WPA: group key handshake completed (WPA) \endverbatim By default, driver_param is simulating a driver that uses the WPA/RSN IE generated by %wpa_supplicant. Driver-generated IE and AssocInfo events can be tested by adding \a use_associnfo=1 to the \a driver_param line in the configuration file. For example: \verbatim driver_param=test_socket=/tmp/Test/ap1 use_associnfo=1 \endverbatim \section unit_tests Unit tests Number of the components (.c files) used in %wpa_supplicant define their own unit tests for automated validation of the basic functionality. Most of the tests for cryptographic algorithms are using standard test vectors to validate functionality. These tests can be useful especially when verifying port to a new CPU target. In most cases, these tests are implemented in the end of the same file with functions that are normally commented out, but ca be included by defining a pre-processor variable when building the file separately. The details of the needed build options are included in the Makefile (test-* targets). All automated unit tests can be run with \verbatim make tests \endverbatim This make target builds and runs each test and terminates with zero exit code if all tests were completed successfully. */