Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] [tcpdump-workers] regarding wireless data frames

From: abhinav narain <abhinavnarain10@xxxxxxxxx>
Date: Sun, 11 Mar 2012 15:23:00 -0400
I have a doubt, when I am running a virtual interface on my AP in monitor mode, will it be capturing the traffic between my laptop and itself ?
I am unable to see any data packet with mac address same as that of my AP ?
Or is my code not correct.

Abhinav 

On Sat, Mar 10, 2012 at 1:45 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On Mar 10, 2012, at 10:18 AM, abhinav narain wrote:

> I believe, the data packets destined for my AP, will be decrypted by the hardware itself

I *don't* believe that if the hardware is running in monitor mode.

> In any case, when I get them in userland, they should be unencrypted. right?

Wrong.  If the hardware doesn't decrypt packets in monitor mode - which, as far as I know, it doesn't do - then I would not expect the driver to decrypt them for you.

With some hardware and operating systems, if you run in monitor mode you get disassociated from the network, in which case the hardware and driver may well forget the password for the network and be unable to decrypt packets.

Even if you remain associated to the network, you may, in monitor mode, receive packets from other networks, in which case the password for the network to which you're associated is irrelevant.

And, in monitor mode, you might capture packets that would otherwise be discarded because the FCS was bad.

So, no, you're not going to get decrypted packets in monitor mode.

> If I look at tpdump code, for each data frame, I need to check
> FC_WEP(fc), if only its false, I should check further.

Correct.

> then get the header length.
>  int hdrlen  = (FC_TO_DS(fc) && FC_FROM_DS(fc)) ? 30 : 24;
>   if (DATA_FRAME_IS_QOS(FC_SUBTYPE(fc)))
>   hdrlen += 2

Yes.

> And then, if then jump this length to check for ether type, using the llc
> frame .

Well, you should probably also check for padding between the 802.11 header and the payload - see

       if (flags & IEEE80211_RADIOTAP_F_DATAPAD)
               pad = 1;        /* Atheros padding */

in ieee802_11_radio_print() and

       hdrlen = extract_header_length(fc);
       if (pad)
               hdrlen = roundup2(hdrlen, 4);

in ieee802_11_print().  (It's called "Atheros padding" because it was first introduced to handle some Atheros adapters that added that padding, but don't assume that you're not going to see it just because you don't think your adapter is one of those adapters.)-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.