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

[Ben Greear]

On 05/28/2015 08:27 AM, Alfred Kenny wrote:
> Thanks for your response, Jouni.
> 
>> hostapd does not receive or process an ACK frame; the WLAN hardware,
>> firmware, and/or driver are the places where this is done and the result
>> (TX status) is reported to hostapd.
> 
> I think I understand this point. Does this mean that ACKs should be forwarded to the wlanX interface associated with mon.wlanX rather than mon.wlanX itself?
> 
>> The actual ACK frame has nothing to do with that, i.e., this is based on internal knowledge of
>> which radio(s) are awake on the channel on which a frame is transmitted.
>> This has little to do with how IEEE 802.11 works over real hardware and
>> as such, you cannot really do what you are describing here with
>> mac80211_hwsim.
> 
> I'm not sure I understand this, though. Would it be possible for you to describe a simple test setup for proper routing of ACK frames in the context of a system running mac80211_hwsim? Currently, we require hwsim0 to see the all management frames generated by hostapd, as mon.wlan0 appears to show everything but beacon frames, and obviously beacon frames are essential.

You will need to sniff with a second radio that is only acting as sniffer
if you want to see all frames on the air (from other radios).

And some drivers/firmware, such as ath10k, still has issues sniffing certain packets.

ath9k (a/b/g/n) is a very good sniffer, and definitely shows beacons and such.

As far as I know, no ACK frames are actually handed up the stack for any real driver.  The firmware and/or
hardware consumes them.  The tx-status often indicates whether ACK happened or not, however.

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com