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 <[email protected]>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 <[email protected]> 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 <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
