Re: [tcpdump-workers] regarding wireless data frames

[abhinav narain <abhinavnarain10 () gmail com>]

Hi,
 this is the packet dump of first  40 bytes,starting from mac header.

88 41 2c 00 c4 3d c7 9d e1 44 00 19 d2 85 d1 67 c4 3d c7 9d e1 42 30 f0 00
00 2b 4f 00 20 00 00 00 00 aa aa 03 00 00 00 08 00

first four bytes are control bits and duration.

next are the mac addresses.
c4 3d c7 9d e1 44
00 19 d2 85 d1 67
c4 3d c7 9d e1 42
seq control
30 f0

I don't understand what to get for 10 bytes following it before I can check
for aa aa, the llc header values.

tcpdump code, also increments by 26 bytes and calls llc print with packet
pointer at the byte which is 26th from the start of the mac header, but I
don't find it to work here as there are clearly unknown bytes before llc
header can be read, which I don't know how to get meaning of.

-Abhinav

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

> 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