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
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
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 un
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 Harri
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?
Wr
> Oh, and one more thing:
>
> Some network adapters, when running in a mode where they supply an 802.11
> header (such as monitor mode), put some padding in between the 802.11
> header and the payload, so the 802.2 LLC header in a data frame might not
> immediately follow the 802.11 header (regardl
On Mar 8, 2012, at 4:47 PM, abhinav narain wrote:
> hi,
> I have seen tcpdump,wireshark both just print packet contents till mac
> header in monitor mode.
> In case of normal wireless interfaces (wlan0), they follow a different
> execution path.
> Can someone tell me what should I expect in the t
On Mar 8, 2012, at 6:53 PM, abhinav narain wrote:
> Since I am capturing every frame in monitor mode, I would like to see the
> packet type : arp/ip ... and is it tcp/udp type.
> But when I do the following, I don't get any output
You *won't* get any output if the packets are encrypted, and, if
The ieee 802.11 headers can vary in length depending on the packets types, qos,
etc.
The ieee standard is available for free, that should be your best reference.
--
Sent from mobile, brevity, accuracy and security disclaimers.
abhinav narain wrote:
hi,
I have seen tcpdump,wireshark both ju
>
>
> By the way, note that the 802.11 header is *variable length*; the length
> depends on, for example, whether the frame has one, two, three, or four MAC
> addresses, and on whether it's a QoS frame.
Yes, I am taking care of that :)
Abhinav
_
>
>
> No, it's not based on the type of interface, or the mode of the interface.
> It's based on whether the 802.11 payload has been decrypted or not; if
> you're capturing in monitor mode most frames are probably encrypted, but if
> you're not capturing in monitor mode and seeing only frames to o
On Mar 8, 2012, at 6:34 PM, Guy Harris wrote:
>
> On Mar 8, 2012, at 4:47 PM, abhinav narain wrote:
>
>> Can someone tell me what should I expect in the the frame after
>> ieee80211_hdr (which comes after the radiotap header) ?
>
> Yes.
By the way, note that the 802.11 header is *variable le
On Mar 8, 2012, at 4:47 PM, abhinav narain wrote:
> I have seen tcpdump,wireshark both just print packet contents till mac
> header in monitor mode.
> In case of normal wireless interfaces (wlan0), they follow a different
> execution path.
No, it's not based on the type of interface, or the mode
12 matches
Mail list logo
