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

[Jouni Malinen]

On Thu, May 28, 2015 at 03:27:32PM +0000, Alfred Kenny wrote:
> 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?

Not really. It means the design you have won't work 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.

There is no real ACK frames with mac80211_hwsim. TX status is generated
internally without such frame ever existing. You happen to see an ACK
frame in the hwsim0 monitor interface since it is convenient to see that
for external analysis purposes, but that is just showing what TX status
value was determined based on internal information (i.e., that ACK frame
was not the reason for TX status to claim the frame to be ACK'ed).

> Our current setup isn't using wlan interfaces to directly communicate with stations, but rather looks something like this:
> 
> LAN<-->eth0<-->bridge<-->wlan0<-->ovs<-->eth1<-->AP<-->air
>                          hostapd-->hwism0-->libtins-->|
>                                 ^---mon.wlan0<--libtins<--'

I don't think that this design can work for TX status purposes with the
current mac80211_hwsim implementation.

> i.e. the wlan interface is used for frames whose source or destination is the LAN (e.g. data). Management frames (and ACKs at the moment) from STAs are forwarded by a libtins agent to mon.wlan0 and the management frames generated by hostapd are forwarded from hwsim0 to eth1 by another libtins agent. In essence, wlan0 is just an interface that we use for traffic-shaping purposes. Everything but ACKs seem to work fine with this setup, so what might you suggest in terms of routing/interfacing modifications such that the reception of ACK frames are recognized by hostapd?

hostapd never processes ACK frames; those are handled in hardware or
low-level firmware. The design you describe here is unlikely to work
without a significant redesign of mac80211_hwsim TX status mechanism.

It sounds like you would not really need to be concerned about ACK
frames in the first place, at least not as far as anything related to
hostapd is concerned. If you need the real TX status for some of the
management frames (and EAPOL frames, for that matter), that would likely
be simpler to implement with a completely separate mechanism for
delivering such indication to hostapd.

-- 
Jouni Malinen                                            PGP id EFC895FA