Re: [tcpdump-workers] regarding wireless data frames

[abhinav narain <abhinavnarain10 () gmail com>]

To add to information, I am using atheros chipset with ath9k device driver.

Abhinav

On Sun, Mar 11, 2012 at 3:23 PM, abhinav narain
<abhinavnarain10 () gmail com>wrote:

> 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 () alum mit edu> 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.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe