hostapd n00b wants to capture all traffic sent / received by BSS - use hostapd?

[Ben Greear]

Consider an AP radio that sends a frame requesting an ACK.  The radio's hardware attempts
to transmit the frame, but half way through transmission, an RF spike interferes.  The
AP radio cannot know for sure this spike happened (maybe only station can hear the RF spike).

Now, the receiver at best is going to receive some garbage it can't decode.

Did the AP radio actually send this frame as far as you are concerned?

What if the peer properly received the pkt, but the ACK was corrupted and the AP still
did not get an ACK?

The various new NICs with firmware in them often frame up and create packets
themselves for transmit, with no direct request from the host driver/stack.

So in general, you could probably improve the stack and drivers to get a bit
more precise idea of what a radio sent or not, but knowing exactly what was
properly put on the air or not for wifi is not a simple topic.

I think the best way is with different radio acting as sniffer in monitor mode.

Thanks,
Ben


On 10/12/2015 10:37 AM, Kennedy, Smith (Wireless Architect) wrote:
> Hi again,
>
> After considering this and reading a bit, a second interface won't meet my objectives.  What I'm really after is a tee to be inserted between hostapd and the 802.11 adapter so that I can capture all 802.11 frames (data, management, everything) passed into the AP (in this case, hostapd), as well as all traffic sent by hostapd to the radio adapter.
>
> I don't know how if hostapd has a built-in option or feature to dump this to a file or pipe, but I've not found one in the hostapd.conf documentation or the man pages yet.  Or maybe the mechanism hostapd uses to interface with the NIC(s) it is controlling provides a "tee" mechanism?
>
> I'll keep digging...
>
> Smith
>
>
>
>> On 2015-10-09, at 10:38 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>>
>> Thanks for the suggestion - I'll look into it!  But I'm not sure that a second virtual interface will actually report this.  And I have to assume that only certain adapters support multiple virtual interfaces operating on a single physical radio.
>>
>> Smith
>>
>>
>>
>>> On 2015-10-09, at 1:32 PM, hiro <23hiro at gmail.com> wrote:
>>>
>>> Is there anything preventing you to use tcpdump or airodump on a
>>> second virtual interface in monitor mode? look into airodump-ng
>>> project's man pages perhaps, cause they have nice tools to create such
>>> interfaces in monitor mode.
>>>
>>> On 10/9/15, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>>>> Hello,
>>>>
>>>> I am seeking a way to have an AP that can trace all 802.11 traffic sent &
>>>> received by its adapters.  Having an adjacent system running in monitor mode
>>>> isn't good enough - I want to track the traffic actually sent / received by
>>>> the AP as reported by the AP's radio adapters themselves.  And I was
>>>> wondering if such a thing could be done using hostapd (to provide the AP
>>>> function if not the monitoring function) perhaps running BSD or Linux.  I
>>>> don't know whether hostapd could be providing the 802.11 traffic or if
>>>> rather I would need to be getting that using something like Wireshark etc.?
>>>> Reading the Wireshark wiki for capturing Wi-Fi traffic, it seems that
>>>> non-monitor mode won't deliver the 802.11 headers on Linux, but some of the
>>>> BSDs provide 802.11 headers and all the management frames etc.  Or maybe
>>>> this will require getting traces directly from the drivers...?
>>>>
>>>> Any help or other thoughts / pointers would be very welcome.
>>>>
>>>> Cheers,
>>>> Smith
>>>>
>>>>
>>>>
>>>>
>>
>> _______________________________________________
>> HostAP mailing list
>> HostAP at lists.shmoo.com
>> http://lists.shmoo.com/mailman/listinfo/hostap
>
>
>
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>


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