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@xxxxxxxxx> 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@xxxxxxxxx> 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@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.)-