Hostapd recognizing ACKs from wpa_supplicant, but not external stations nor a packet crafter immediately adjacent to hostapd's interfaces

[Alfred Kenny]

My research group has been having trouble getting hostapd to recognize the 802.11 acknowledgement frames in response to the authentication and association responses that it is generating. In fact, we've become so frustrated that we've created a test agent using libtins solely for testing the ACKing authentication and association frames. Our setup is this:

All tests:
Linux 12.04
hostapd 1.1 (although 0.6.8 and 2.4 produce the same results)
wireshark 1.6.7

test 1:
wpa_supplicant 0.7.3

tests 2 and 3:
libtins 3.1


Procedure for test 1:

1) run a basic, open hostapd instance with the following config file

interface=wlan0
driver=nl80211

hw_mode=g
channel=1
ssid=mac80211 test
ignore_broadcast_ssid=0
preamble=1
supported_rates=60 90 120 180 240 360 480 540
basic_rates=60 120 240

This is started as a process by a python module in our system, and is in fact the standard config file for our system.

2) Run the wpa_supplicant counterpart to this network with the following config file

ctrl_interface=/var/run/wpa_supplicant

network={
    ssid="mac80211 test"
    key_mgmt=NONE
}

This is started with the terminal command
sudo wpa_supplicant -d -Dnl80211 -iwlan1 -c wpa_supplicant.conf -dd

3) Observe the outcome on hwsim0.

Here, we see that the time difference between the Auth reply from hostapd and the ACK for this frame from wpa_supplicant is 4 us (as observed on hwsim0, as it seems that this frame never arrives at mon.wlan0). The contents of the frame, including radiotap header, are (radiotap header contents in square brackets):

[00 00 0e 00 0a 00 00 00 00 00 71 09 80 00] d4 00 00 00 <BSSID>

The printout in the terminal in which hostapd is running shows that the ACK was received and processed just fine and that the association request, response and their corresponding ACKs are received and processed without error as well. Everything functions normally after this.

----------------------------------------------------------------------

Procedure for test 2:

1) Run the exact same configuration as above via the exact same method as above (i.e. as a process started by a python module in our system).

2) Using the packet sniffing/crafting software libtins, create an 802.11 Auth frame and send it to mon.wlan0.

3) Sniff on hwsim0 for the Auth reply from hostapd.

4) Send an ACK to mon.wlan0.

5) Observe outcome on hwsim0.

Here, we see that the delay between the Auth reply and the ACK for this frame is 105 us (i.e. ~25 times longer than wpa_supplicant's response time). The frame itself contains (radiotap header in square brackets:

[00 00 0e 00 0a 00 00 00 00 00 71 09 80 00] d4 00 00 00 <BSSID>,

that is to say that it is -- down to the bit -- the exact same ACK frame as that generated by wpa_supplicant.

The result here is that hostapd prints out that the station did not ACK the Auth response. We were thinking that maybe hostapd is really finicky about the time difference between the Auth response and its corresponding ACK, so on to test 3.

----------------------------------------------------------

Procedure for test 3:

1-2) Same as above.

3) IMMEDIATELY send an ACK to mon.wlan0 after sending the Auth frame to hostapd. Do not wait for a response, just send the ACK for the Auth response that we expect will be produced.

4) Observe outcome on hwsim0.

Testing showed that even if we send the ACK immediately after sending the Auth frame, this ACK will arrive after the Auth response from hostapd, likely due to processing delays in libtins. This is fine, in fact it is the best possible outcome because this time we see that our ACK frame was seen on hwsim0 5 us after the Auth response was sent out by hostapd. That's only 1 us longer than the ACK response time of wpa_supplicant.

Again though, hostapd fails to see this ACK frame, as it prints out a message saying that the station did not acknowledge the Auth response.

We repeated this test by sending the ACK to
a) hwsim0 followed by mon.wlan0
b) mon.wlan0 followed by hwsim0
c) solely mon.wlan0
d) solely hwsim0

In each of the above cases, the longest time difference between hostapd's Auth response and the ACK we inject to the interface is 8 us. Not milliseconds, mind you, but 8 microseconds. Still, hostapd refuses to notice this frame.


----------------------------------------------------------

Further observations:

If we add the line

ap_max_inactivity=2

to the hostapd config file to try and see the Null function frame generated by hostapd for inactivity, our setup with libtins does not show this frame on hwsim0, nor mon.wlan0. We assume this is likely because even though the Auth was not ACKed, the station succeeded in associating anyways.


Questions:

1) What on earth is going on? It seems illogical for hostapd to expect an 802.11 station to ACK in 4 us or less, especially considering that in all the forms of 802.11 running today, none of these have a short interfrace spacing (SIFS) less than 10 microseconds.

2) If hostapd is indeed this finicky about the time difference, is there anywhere in its code that we can modify it to force it to wait longer for an ACK?

3) Why is the Null data frame not sent out after this quasi-erroneous authentication/association procedure?  Is there something in hostapd's code that is waiting on the ACK in order to execute this functionality?

4) Why do we see the ACK from wpa_supplicant on hwsim0 rather than mon.wlan0? The documentation (on various sites) seems to imply that mon.wlan0 is the interface that hostapd is listening on, while hwsim0 is the interface for its output.

Regards,
Al
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20150527/4d4353b2/attachment.htm>