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