I'm trying to parse 802.11 frames myself and I've encountered two problems that I can't solve.
First of all, when does an LLC (Logical Link Control) header follow a IEEE 802.11 data frame ? I thought when there is data in a frame, there would always be an llc overhead preceding the data, but I have a wireshark with Ethernet II instead of LLC. But I have no idea how to actually know if it's gonna be an LLC or a Ethernet II header following my 802.11 data header. There's no field in the 802.11 header specifyin what's following.
Secondly, I have noticed something in wireshark when I open a capture file containing 802.11 QoS data frames. At the end of the header there's the QoS control field, which is normal, it's specified in the IEEE 802.11 documentation (i've read it over and over again to try to find an answer to my question) But then, there's 2 bytes that wireshark considers part of the 802.11 header (when you click on the raw bytes, wireshark points to the 802.11 header, but the signification of the bytes is not displayed in the fields of the header ! Does my question make any sense ?
Here are images to explain what I'm not understanding. On the first screen shot below, you see the 802.11 header selected and you see below the concerned bytes in hexadecimal.
Pay attention to the last bytes of this packet:00 00 10 aa
Now I expand the 802.11 header and click on the very last field of it (QoS control, as specified in the RFC). You can see that the corresponding bytes are 00 00. But those bytes are not the last bytes of the packet ! There still is 10 aa that's part of the wifi packet but I have no idea what those bytes represent !
Any one has an idea ?
First of all, when does an LLC (Logical Link Control) header follow a IEEE 802.11 data frame ?
There should always be one, although things might be odd for aggregate packets. If you capture on an 802.11 interface and you're not capturing in monitor mode, you might see the packet begin with an Ethernet header, but that's different - that's the adapter and/or the driver translating the 802.11 header + LLC header into an Ethernet header.
But then, there's 2 bytes that wireshark considers part of the 802.11 header
That might actually be the "Atheros padding", "helpfully" inserted, in monitor mode, between the 802.11 header and the frame body by some Atheros network adapters. Open up the Radiotap header and see if the "Data Pad" flag is set in the Flags field; if so, the packet has "Atheros padding".
Related
I try to parse WMV (ASF) files without any SDK, just by decoding raw bytes. Now I have problem with ASF_Data_Object, where I can't find length of data packet. More precise, Single payload data packet.
See image:
Here I have 9 packets, but unable to find size of individual packet. How I can determine border between packets?
I think, my problem at byte 0x411, where field "Length type flags". As you can see, here 0 value, so all flags are zero. Even Packet Length Type.
Yes, 0 value here allowed here. But how to read this type of content?
This is now compressed payload, as replication data is 8, not 1. So, this is single payload without additional fields of size.
Sample of WMV file: https://files.catbox.moe/b51l2j.wmv
You seem to be having fixed size packets with no explicit payload length included, meaning that payload data size is derived from top level data object structure.
Spec quote commented:
That is, the ASF data object carries 9 packets, 3200 bytes each, then internally the packets contain payload 3174 bytes of payload per packet except the last one which has less data and some padding.
I use Npcap's NULL/loopback capture with Wireshark v2.4.2 and I get complete nonsense stats because for some reason loopback "captures" way too much "on the wire":
As you can see, actual sent packet was 1476 bytes, but Wireshark "captured" 2948 bytes on the wire. This totally messes up with all kinds of statistics and IO graphs do not make any sense.
Is this a bug (in Wireshark or Npcap loopback capturer?) How can I make Wireshark ignore that bytes on wire metric and use bytes captured instead for all kinds of stuff (like io graphs, or to show it in "Length" column)
If "bytes captured" is less than "bytes on the wire", it's typically because a snaplen was set when capturing.
Check your capture options (Wireshark: Capture -> Options) and if a snaplen was set, you should either set it to the default value (typically 262144) or some other large value whereby you can ensure that all bytes will be captured.
This may be due to an Npcap bug; see Npcap issue #1524.
I was watching several wifi captures in wireshark and I bumped into two specimens I had never seen before. First of all, I thought that a IEEE 802.11 data frame would always be followed by a LLC header (802.2), provided that the frame actually contained data. Now I have a two wireshark captures showing otherwise !
First one, we can see an Ethernet II header following the wifi header :
Now that's the first thing I don't understand. How is an interface supposed to know, when reading the 802.11 Data header, that it is going to be an Ethernet II following ? There is no field in the 802.11 header specifying what's coming next.
Second is "raw data" directly following the wifi header.
Same question as before, how are we supposed to know that Data was following, and not LLC ?
First question:
To quote a comment in the Wireshark 802.11 dissector:
/* I guess some bridges take Netware Ethernet_802_3 frames,
which are 802.3 frames (with a length field rather than
a type field, but with no 802.2 header in the payload),
and just stick the payload into an 802.11 frame. I've seen
captures that show frames of that sort.
There is no field in the header that says "this is a bridged Netware Ethernet_802_3 frame", so Wireshark has to use a heuristic. The heuristic is "if the first two bytes of the payload are not both 0xAA, the first 6 bytes of the payload equal the destination MAC address, and the next 6 bytes of the payload equal the source MAC address, then this is a bridged Netware Ethernet_802_3 frame", in which case it calls the Ethernet dissector. Because this is a heuristic, it is, of course, not guaranteed to get the correct answer all the time.
IEEE Std 802.11-2012 says, in section 5.1.4 "MSDU format":
This standard is part of the IEEE 802 family of LAN standards, and as such all MSDUs are LLC PDUs as defined in ISO/IEC 8802-2: 1998. In order to achieve interoperability, implementers are recommended to apply the procedures described in ISO/IEC Technical Report 11802-5:1997(E) (previously known as IEEE Std 802.1H-1997 [B21]), along with a selective translation table (STT) that handles a few specific network protocols, with specific attention to the operations required when passing MSDUs to or from LANs or operating system components that use the Ethernet frame format. Note that such translations may be required in a STA.
"ISO/IEC 8802-2: 1998" is also ANSI/IEEE Std 802.2, 1998 Edition, so that says that the payload should begin with an 802.2 header. At least as I read IEEE Std 802.1H-1997, Ethernet frames without an 802.2 header should be translated to SNAP frames, using their Ethernet type value, when bridged to a LAN using 802.2, such as an 802.11 LAN. I guess, since Netware Ethernet_802_3 frames don't have a valid 802.2 LLC header and don't have a type field (they have a length field; I think that, as they don't have an 802.2 header following the Ethernet header, this means that they technically aren't valid Ethernet frames), they aren't covered by the specifications in question, so it's not technically a protocol error to just put the Ethernet packet, starting with the Ethernet header, into the data field. Presumably those packets are sent only to bridges, under the assumption that the bridge knows how to Do The Right Thing.
Second question:
The most common reason to see "Data" after an 802.11 header is that the packet in question is encrypted (WEP or WPA/WPA2) and Wireshark doesn't have the password for the network (and, for WPA/WPA2 Personal/Pre-shared key mode, doesn't have the initial EAPOL handshake in the capture; decrypting in Enterprise/802.1X mode is not supported).
Are you capturing on a "protected" (WEP or WPA/WPA2) network?
I have a Wi-Fi capture (.pcap) that I'm analysing and have run across what appear to me to be inconsistencies between the 802.11 spec and Wireshark's interpretation of the data. Specifically what I'm trying to pull apart is the 2-byte 802.11 Frame Control field.
Taken from http://www4.ncsu.edu/~aliu3/802.bmp, the format of the Frame Control field's subfields are as follows:
And below is a Wireshark screen cap of the packet that has me confused:
So as per the Wireshark screenshot, the flags portion (last 8 bits) of the Frame Control field is 0x22, which is fine. How the Version/Type/Subtype being 0x08 matches up with Wireshark's description of the frame is what has me confused.
0x08 = 0000 1000b, which I thought would translate to Version = 00, Type = 00 (which I thought meant management not data frame) and Subtype = 1000 (which I thought would be a beacon frame). So I would expect this frame to be a management frame and more specifically, a beacon frame. Wireshark however reports it as a Data frame. The second thing that is confusing me is where Wireshark is even pulling 0x20 from in the line Type/Subtype: Data (0x20).
Can anyone clarify my interpretation of the 802.11 spec/Wireshark capture for me and why the two aren't consistent?
The data frame in you example is 0x08 because of the layout of that byte of the frame control (FC). 0x08 = 00001000
- The first 4 bits (0000) are the subtype. 0000 is the subtype of this frame
- The next 2 bits (10) is the type, which is 2 decimal and thus a data type frame
- The last 2 bits (00) are the version, which is 0
The table below translates the hex value of the subtype-type-version byte of the FC for several frame types. A compare of the QoS data to the normal data frame might really help get this down pat. Mind you the table might have an error or two, as I just whipped it up.
You are right that 1000 is a beacon frame, you just were looking at the wrong bits.
You have a radiotap header, you can get the dec representation of the type like so from the pcap API:
int type = pkt_data[20] >> 2;
This is a common error, and has certainly bitten me several times.
It is down to the Byte Ordering.
When you have a multi-byte number to represent, the question arises as to Which byte do you put/send first ?
Natural (human) byte order is to put the big part first, then the smaller parts after it, Left-to-right, also called Big Endian. Note that the Bits in each byte are never the wrong way around from a programmers' point of view.
e.g. 1234 decimal requires 2 bytes, 04D2 hex.
Do you write/send 04 D2, or D2 04 ?
The first is Big-endian, the second is Little-endian.
To confuse it more, the mechanisms involved may use different byte-orders.
There is the Network Byte Order, in this case Little-endian, the Architecture byte order (can be different for each CPU architecture) and the data may be in a buffer, so it will vary depending on whether you read the buffer top-to-bottom, or bottom-to-top.
It doesn't help that the explanation of which bits do what can also be 'backwards', as in your original post.
I am using wireshark version-2.4.3 on windows. My capture file of dataframes is like below.
Frame control field = 0x0842 i.e., in binary format 0000 1000 0100 0010
Framecontrol flag field = 0x42.i.e., in binary format 0100 0010
So, as per my understanding the LSB 8bits in a framecontrol field will correspond to flags.
MSB 8bits will correspond to subtype, type, version i.e. in my case 0000-subtype & 10-type & 00-version.
Which is data frame of subtype 0.
It might be the error with wireshark in your case. It should dispaly frame control field as 0x0822 instead of 0x2208.
Flags field is properly displayed as 0x22.
In My case I am using wireshark-2.4.3 and display of frame control field is correct 0x0842 where flags is 0x42.
My_capture_file:
I need to calculate total data transfer while transferring a fixed size data from client to server in TCP/IP. It includes connecting to the server, sending request,header, receiving response, receiving data etc.
More precisely, how to get total data transfer while using POST and GET method?
Is there any formula for that? Even a theoretical one will do fine (not considering packet loss or connection retries etc)
FYI I tried RFC2616 and RFC1180. But those are going over my head.
Any suggestion?
Thanks in advance.
You can't know the total transfer size in advance, even ignoring retransmits. There are several things that will stop you:
TCP options are negotiated between the hosts when the connection is established. Some options (e.g., timestamp) add additional data to the TCP header
"total data transfer size" is not clear. Ethernet, for example, adds quite a few more bits on top of whatever IP used. 802.11 (wireless) will add even more. So do HDLC or PPP going over a T1. Don't even think about frame relay. Some links may use compression (which will reduce the total size). The total size depends on where you measure it, even for a single packet.
Assuming you're just interested in the total octet size at layer 2, and you know the TCP options that will be negotiated in advance, you still can't know the path MTU. Which may change, even while the connection is in progress. Or if you're not doing path MTU discovery (which would be wierd), then the packet may get fragmented somewhere, and the remote end will see a different amount of data transfer than you.
I'm not sure why you need to know this, but I suggest that:
If you just want an estimate, watch a typical connection in Wireshark. Calculate the percent overhead (vs. the size of data you gave to TCP, and received from TCP). Use that number to estimate: it will be close enough, except in pathological situations.
If you need to know for sure how much data your end saw transmitted and received, use libpcap to capture the packet stream and check.
i'd say on average that request and response have about 8 lines of headers each and about 30 chars per line. Then allow for the size increase of converting any uploaded binary to Base64.
You didn't say if you also want to count TCP packet headers, in which case you could assume an MTU of about 1500 so add 16 bytes (tcp header) per 1500 data bytes
Finally, you could always setup a packet sniffer and count actual bytes for a sample of data.
oh yeah, and you may need to allow for deflate/gzip encoding as well.