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

[Alfred Kenny]

> 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.

Ah, ok. I'm getting closer to understanding. Is the process something like 
this in a normal setup with hostapd:

1) ACK frame generated by station and sent to air
2) Wireless card receives frame
3) TX status generated, ACK dies here (i.e. never passed up above PHY)
4) hostapd sees TX status signal and recognizes that it is related to the 
network for which it is providing management
5) Authentication/Association response effectively ACK'd

Am I missing anything? If this is the case, it sounds like we could simply
use our libtins-based sniffer to check eth1 for ACKs relayed by the external AP (WARP)
and then generate the corresponding TX status for hostapd to see. Is this what
you are suggesting?

Can you point me toward some documentation on TX status and how
we might go about generating the proper signal for hostapd to recognize
that an ACK frame has been produced by a station?

Thanks again for all your help, Jouni.

Cheers,
Al
________________________________________
De : hostap-bounces at lists.shmoo.com [hostap-bounces at lists.shmoo.com] de la part de Jouni Malinen [j at w1.fi]
Envoy? : 28 mai 2015 13:32
? : hostap at lists.shmoo.com
Objet : Re: RE : Hostapd recognizing ACKs from wpa_supplicant, but not  external stations nor a packet crafter immediately adjacent to  hostapd's interfaces

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
_______________________________________________
HostAP mailing list
HostAP at lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap