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

[Alfred Kenny]

> Are you effectively trying to use this WARP thing as the transport for
> the hwsim driver?

WARP (https://warpproject.org/trac/wiki/802.11) can be considered -- at least
for our purposes -- as the PHY layer as well as the DCF of MAC and a transport
for all frames applicable to our system. All management frames
intended for any of the networks running on the linux machine (the image in the
previous post shows two such networks operating simultaneously) are encap'd
in a WARP header of our own making and then an ethernet header before being
shipped over to ETH1 on the linux machine (also seen in the image). All data
frames are simply forwarded with an ethernet header to ETH1.

> Maybe you could back up a bit and explain the high level goals
> that you are trying to accomplish?

Sure thing. We have two primary goals: 

1) data frames arriving at ETH1 should be sent along their merry way through ovs, wlanX,
the bridge between wlanX and ETH0, ETH0 and then out to the LAN. This path
*should* be unrelated to hostapd and is effectively a bridge between WARP and
the LAN with traffic-controlling provisions.

2) 802.11 management frames and their corresponding ACKs should be
routed such that they (or at least the by-products of these frames) are
recognized by hostapd in the case of the uplink or forwarded to WARP in
the case of the downlink (downlink operates just fine at the moment, FYI). 
This is how we hope to provide authentication,association, disassociation, etc.

Cheers,
Al

________________________________________
De : Ben Greear [greearb at candelatech.com]
Envoy? : 28 mai 2015 13:46
? : Alfred Kenny
Cc : Jouni Malinen; hostap at lists.shmoo.com
Objet : Re: RE : RE : Hostapd recognizing ACKs from wpa_supplicant, but not external stations nor a packet crafter immediately adjacent to hostapd's interfaces

Are you effectively trying to use this WARP thing as the transport for
the hwsim driver?

Maybe you could back up a bit and explain the high level goals
that you are trying to accomplish?

Thanks,
Ben


On 05/28/2015 10:26 AM, Alfred Kenny wrote:
> I appreciate the replies thus far, but -- before this goes any further -- I should mention that I
> am really quite the amateur when it comes to working with hardware, firmware and drivers.
> I've been looking for documentation that spells things out in detail for hostapd, mac80211_hwsim,
> associated drivers and their interaction, but it seems like I need to have a bachelors in computer/software
> engineering (rather than my lowly electrical degree) to fully understand what's going on.
> So, I apologize if it'll be frustrating, but I'd be grateful if you could imagine that I'm a 15 year
> old who is interested in working with the open-source software and hardware components
> involved in 802.11 wireless communications.
>
> This is the setup for our system, with each component shown existing on a linux machine:
>
> http://i.imgur.com/X0jkUt3.png
>
> That is to say, at no point does a wireless card come into play. All wireless transmissions are
> handled by a WARP board which is listening for ethernet packets that have been placed on the
> PC's eth1 and forwarding all relevant packets from the air back to the eth1.
>
> There, now that that huge preamble is complete, let's get to the points you've made.
>
>> 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).
>
> Do you mean that I need to use a wireless card for the sole purpose of recognizing
> ACKs directed toward this network? We're attempting to operate several networks
> simultaneously with our setup, with each using a dedicated wlan interface. How would
> this work in such a configuration?
>
>> 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.
>
> Can these drivers somehow be operated independently of our system without
> additional hardware? Remember that our system functions without the use of a wireless
> card. In fact, you could strip every networking device from the linux machine except for
> the ethernet card (eth1) and motherboard (eth0) and everything would function exactly
> as it does now.
>
>> 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.
>
> Where would we be able to see this tx-status on the linux machine? Or is this only produced when
> a wireless card is in place for receiving frames from air? When we run our system exactly as is with
> hostapd and mac80211_hwsim and then use wpa_supplicant as a test station, its ACKs are only seen
> at hwsim0 and apparently hostapd has been notified that they were received. This seems incongruous
> with the above point.
>
> Thanks again for all the replies. This is still mostly greek to me at this point. If anyone has any
> comprehensive documentation with test examples for the components that have been mentioned
> thus far, I'd be more than happy to pore over them rather than bothering all of you.
>
> Cheers,
> Al
>


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