regarding wireless data frames

Discussion:

abhinav narain

2012-03-09 00:47:42 UTC

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 the frame after
ieee80211_hdr (which comes after the radiotap header) ?
According to my knowledge, I assume if the control frame bit with
Is it an llc header with a general format :
struct llc_hdr {
uint8 dsap;
uint8 ssap;
struct {
uint8 ui;
uint8 org_code[3];
uint16 ether_type;
} snap;
};
so that i can jump it and get the ip header ?
If some one can correct me ? would be great

Abhinav

Guy Harris

2012-03-09 02:34:47 UTC

Permalink

Post by abhinav narain
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 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 or from your machine, they're probably decrypted.

Post by abhinav narain
Can someone tell me what should I expect in the the frame after
ieee80211_hdr (which comes after the radiotap header) ?

Yes.

First of all, if the Protected Frame field bit is set (and the adapter or driver hasn't decrypted the packet but left that bit set), what follows the 802.11 header is a bunch of encrypted data, which can only be decrypted if you have enough information to decrypt it (which, for the non-enterprise version of WPA, means you need the password for the network *and* the initial setup frames):

7.1.3.1.8 Protected Frame field
The Protected Frame field is 1 bit in length. The Protected Frame field is set to 1 if the Frame Body field contains information that has been processed by a cryptographic encapsulation algorithm. The Protected Frame field is set to 1 only within data frames and within management frames of subtype Authentication. The Protected Frame field is set to 0 in all other frames. When the Protected Frame field is set to 1, the Frame Body field is protected utilizing the cryptographic encapsulation algorithm and expanded as defined in Clause 8. The Protected Frame field is set to 0 in Data frames of subtype Null Function, CF-ACK (no data), CF-Poll (no data), and CF-ACK+CF-Poll (no data) (see 8.3.2.2 and 8.3.3.1, which show that the frame body must be 1 octet or longer to apply the encapsulation).

What the decrypted data (if the frame was encrypted) or the unencrypted data (if the frame wasn't encrypted) is then depends on the type and subtype fields.

Post by abhinav narain
According to my knowledge, I assume if the control frame bit with
struct llc_hdr {
uint8 dsap;
uint8 ssap;
struct {
uint8 ui;
uint8 org_code[3];
uint16 ether_type;
} snap;
};

Well, if the type is a data frame, then the payload, *once it's been decrypted if it was encrypted*, begins with an 802.2 LLC header. That's not determined by a single bit, but by a 2-byte type field (and a 4-byte subtype field, as some data frames have no data).

802.2 headers don't necessarily have an organization code or protocol ID field - that's the case only for SNAP frames, where the DSAP and SSAP are 0xAA - and, for SNAP frames, the protocol ID field is an Ethernet type only if the organization code is 00:00:00.

Guy Harris

2012-03-09 02:50:44 UTC

Permalink

Post by abhinav narain
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 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.

abhinav narain

2012-03-09 02:54:03 UTC

Permalink

Post by Guy Harris
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

abhinav narain

2012-03-09 02:53:10 UTC

Permalink

Post by Guy Harris
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 or from your
machine, they're probably decrypted.
Got you !
What the decrypted data (if the frame was encrypted) or the unencrypted
data (if the frame wasn't encrypted) is then depends on the type and
subtype fields.

Post by abhinav narain
According to my knowledge, I assume if the control frame bit with
struct llc_hdr {
uint8 dsap;
uint8 ssap;
struct {
uint8 ui;
uint8 org_code[3];
uint16 ether_type;
} snap;
};

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

// f is ieee80211_hdr
if( subtype== IEEE80211_STYPE_DATA ){
struct llc_hdr* llc = (struct llc_hdr*)(((uchar*)f) + hdrlen);
int llc_type = ntohs(llc->snap.ether_type);
if (llc_type == ETHERTYPE_ARP) {
printf("ethernet type \n");
} else if (llc_type == ETHERTYPE_IP) {
if (jh->caplen_ < hdrlen + sizeof(*llc) + sizeof(struct iphdr))
return;
struct iphdr* ih = (struct iphdr*)(llc+1);
if (ih->protocol == IPPROTO_TCP)
printf("tcp \n");
else if (ih->protocol == IPPROTO_UDP)
printf("udp \n");
else if (ih->protocol == IPPROTO_ICMP)
printf("icmp \n");

}else if(subtype == IEEE80211_STYPE_NULLFUNC ){
printf("no data\n");
}

Post by Guy Harris
Well, if the type is a data frame, then the payload, *once it's been
decrypted if it was encrypted*, begins with an 802.2 LLC header. That's
not determined by a single bit, but by a 2-byte type field (and a 4-byte
subtype field, as some data frames have no data).

As you can notice, I am using a 2 byte field to check the subtype field.

Post by Guy Harris
802.2 headers don't necessarily have an organization code or protocol ID
field - that's the case only for SNAP frames, where the DSAP and SSAP are
0xAA - and, for SNAP frames, the protocol ID field is an Ethernet type only
if the organization code is 00:00:00.
Shall i use some other llc struct to find out the data packet is of which

transport layer protocol

Abhinav Narain

Post by Guy Harris
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Guy Harris

2012-03-09 18:28:56 UTC

Permalink

Post by Guy Harris
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 you're capturing in monitor mode on a network using WEP or WPA/WPA2, the packets will be encrypted.

With an encrypted packet, what you capture "over the air" won't have something that looks as if it begins with an 802.2 LLC header, you'll have something that looks as if it begins with random data. You would have to decrypt the payload following the 802.11 header in order to see, for example, an 802.2 LLC header, followed by a SNAP header, followed by an IPv4 header, etc. for an IPv4 packet.

Post by Guy Harris

As you can notice, I am using a 2 byte field to check the subtype field.

Sorry, I meant "2-*bit* type field" and "4-*bit* subtype field", not "2-*byte* ..." and "4-*byte* ...". Presumably that's what you're checking for.

Post by Guy Harris

Shall i use some other llc struct to find out the data packet is of which transport layer protocol

No, what you need to do, *once you've decrypted the packet if it's encrypted* - you check the Protected Frame bit in the 802.11 header to check for encrypted packets - is to check whether the 802.2 header contains 0xAA 0xAA 0x03, so you're checking whether it's a SNAP packet and an Unnumbered Information packet, and then check the 5-byte SNAP header following the 3-byte 802.2 header to see whether the first 3 bytes, which are the OUI field in the SNAP header, are all zero. If so, then the protocol id field, in the remaining 2 bytes, is an Ethernet type; it's a big-endian field. Check it against ETHERTYPE_IP to look for an IPv4 packet, ETHERTYPE_ARP for an ARP packet, ETHERTYPE_IPv6 for an IPv6 packet, etc..-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Mike Kershaw

2012-03-09 01:12:11 UTC

Permalink

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 <abhinavnarain10-***@public.gmane.org> 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 the frame after
ieee80211_hdr (which comes after the radiotap header) ?
According to my knowledge, I assume if the control frame bit with
Is it an llc header with a general format :
struct llc_hdr {
uint8 dsap;
uint8 ssap;
struct {
uint8 ui;
uint8 org_code[3];
uint16 ether_type;
} snap;
};
so that i can jump it and get the ip header ?
If some one can correct me ? would be great

Abhinav
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Guy Harris

2012-03-10 00:09:35 UTC

Permalink

Post by abhinav narain
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 the frame after
ieee80211_hdr (which comes after the radiotap header) ?
According to my knowledge, I assume if the control frame bit with
struct llc_hdr {
uint8 dsap;
uint8 ssap;
struct {
uint8 ui;
uint8 org_code[3];
uint16 ether_type;
} snap;
};
so that i can jump it and get the ip header ?

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 (regardless of whether the payload is encrypted or not). The radiotap header includes a flag for that - it's the 0x20 flag bit in the Flags field:

http://www.radiotap.org/defined-fields/Flags

abhinav narain

2012-03-10 18:18:38 UTC

Permalink

Post by Guy Harris
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 (regardless of whether the payload is
encrypted or not). The radiotap header includes a flag for that - it's the
http://www.radiotap.org/defined-fields/Flags
I have two questions.

I believe, the data packets destined for my AP, will be decrypted by the
hardware itself
In any case, when I get them in userland, they should be unencrypted. right
?
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.
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

And then, if then jump this length to check for ether type, using the llc
frame .
I hope I am not missing any detail.
As on doing the above .. i get very low frequency of arp,udp packets, but I
never get tcp packets output on my screen , even though I am browsing.

Any comments ?

Abhinav

Guy Harris

2012-03-10 18:45:58 UTC

Permalink

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.

abhinav narain

2012-03-11 19:23:00 UTC

Permalink

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

Post by abhinav narain

Post by abhinav narain
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.

Post by abhinav narain
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.

Post by abhinav narain
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.

Post by abhinav narain
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.

Post by abhinav narain
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.

abhinav narain

2012-03-11 19:24:28 UTC

Permalink

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

Post by abhinav narain
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

Post by abhinav narain
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.

Post by abhinav narain
In any case, when I get them in userland, they should be unencrypted.

Post by abhinav narain
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.

Post by abhinav narain
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.

Post by abhinav narain
And then, if then jump this length to check for ether type, using the

llc

Post by abhinav narain
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.

abhinav narain

2012-03-13 17:33:40 UTC

Permalink

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

Post by abhinav narain
To add to information, I am using atheros chipset with ath9k device driver.
Abhinav

Post by abhinav narain
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.

Post by abhinav narain
In any case, when I get them in userland, they should be unencrypted.

Post by abhinav narain
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.

Post by abhinav narain
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.

Post by abhinav narain
And then, if then jump this length to check for ether type, using the

llc

Post by abhinav narain
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.