Linux for Wireless Engineers: How to Read the EAP WPA Supplicant Logs

By October 16, 2019Linux

In a previous post I talked about the WiFi Protected Access (WPA) Supplicant logs for PreShared Key (PSK) authentication and how to make sense of them. The reality is that although the logs are useful, you will be intimidated if you don’t know what to look for.

This post builds on top of the previous one, covering some additional details around the Extensible Authentication Protocol (EAP) WPA Supplicant logs. The EAP logs include the PSK states of the authentication/association process as well as the EAP authentication method. 

WPA Supplicant Configuration

As an example, I connected my Linux client to my WPA-EAP network through my RADIUS server. For reference, here are the contents of the wpa_supplicant.conf configuration file:

Log Parser

If you follow the WPA Supplicant daemon from my previous post, you should have the logs saved in the file “/var/log/wpa_supplicant.log”. From this point forward we are working under the assumption that you have this file in your system.

In order to filter the contents of the logs we will use a grep command with the appropriate filters. The lines we want to see must include the WiFi interface name followed by colon (e.g. “wlan0:”) From these lines, we only want to keep the lines that include the tokens “State:” and “EAP”. “wlan0”, in this case, is the name of the WiFi interface on my machine. You can get a list of all available interfaces on your machine with the command “ip link.”

The logs also include some low level debugging information about the EAP Over LAN (EAPOL) that are not useful in this case. For that reason we’ll filter out lines that include the “EAPOL” token.

Here is the command that achieves this filtering together with its output:

You can see the scanning, followed by the association events; once the association is successful, the WPA Supplicant daemon moves on to the EAP authentication phase. Once that is successful it performs the 4-way handshake step, and then the whole process is completed. You can also see that along the way it prints information about the certificate used and its signing authority (GoDaddy in this case).

I simulated a case where the certificate was wrong and it couldn’t pass the EAP authentication phase. Here is what the logs look like:

WPA Supplicant prints the error “err=’self signed certificate in certificate chain’” which helps us identify the cause of the failed authentication. 

WPA Supplicant Timing 

A very useful piece of information you can extract from the WPA Supplicant logs is the time it takes for each step: scanning, association, authentication. 

Below is a script that it takes as input a log file, prints the steps for the connection and the timing for each step:

I saved the script in file “parse_wpa_logs.sh” and I made it executable with “chmod +x parse_wpa_logs.sh”. Here is a sample output:

The connection timing is broken down as follows: 

  • Scanning: 0.64 seconds
  • Association: 0.23 seconds
  • EAP Authentication: 3.53 seconds
  • 4 Way Handshake: 0.007+0.00082+0.0006=0.08 seconds

With this post I have completed the review of WPA supplicant logs! I hope you will find this information useful when troubleshooting failed or slow connections.