1

I'm working with the 802.11 radiotap header making my own parser and it states the packet format is this where the length is 2 bytes long:

enter image description here

In wireshark the hex of the header is this where the 2 bytes 19 00 are the length field, but wireshark ignores the trailing 00 and interprets it as legnth 25 (decimal) instead of length 6400 (decimal):

enter image description here

How does wireshark (correctly) know to interpret the number correctly?

The link above says the length is stored in little endian and my system is little endian so I'm not sure what's happening on that front?

Crizly
  • 971
  • 1
  • 12
  • 33
  • does "network byte order" mean anything to you? `ntohs()` and all that – Jasen May 07 '19 at 20:29
  • It's not just wireshark. Standard network packets encode data in network byte order. Your interpretation of the specification is wrong. It is big edian (network byte order), not little endian – slebetman May 07 '19 at 20:52
  • 1
    @slebetman The linked specification page actually says "all data fields ... in the radiotap header are to be specified in little endian byte-order". (Maybe a strange design choice, but you have to follow the docs.) – aschepler May 07 '19 at 22:37
  • Do not post images. Always post everything in text. – Rob May 08 '19 at 01:58

4 Answers4

5

How Wireshark interpret the endianess is up to the dissector developers to decide. They choose to either read the buffer as little endian or big endian. There are different parsing functions for each type. The endianess to use is usually found in the protocol's documentation.

The protocol you are looking at is little endian. I'm not sure why the (original) accepted answer and the comments suggest otherwise. 19 00 is 25 in decimal, when using little endian. It might be a bit confusing, but the little end comes first. You can read about it here.

Mika Sundland
  • 18,120
  • 16
  • 38
  • 50
2

I'm afraid that the (original) accepted answer, which would normally be correct, is not correct for the Radiotap header.

Big-endian is the standard for network byte order, however the Radiotap documentation specifically states:

Data is specified in little endian byte-order, all data fields including the it_version, it_len and it_present fields in the radiotap header are to be specified in little endian byte-order.

David Hoelzer
  • 15,862
  • 4
  • 48
  • 67
1

From https://en.wikipedia.org/wiki/Endianness

"Big-endian is the most common format in data networking; fields in the protocols of the Internet protocol suite, such as IPv4, IPv6, TCP, and UDP, are transmitted in big-endian order. For this reason, big-endian byte order is also referred to as network byte order"

atanas
  • 43
  • 5
  • It's coming back to me now, doing this in java, forgot about the net byte order... what's the rule for when to apply it? MAC addresses are already in the correct order, aren't they? – Crizly May 07 '19 at 20:39
  • Sorry, can't help you with that, it's not my field, i just know some basis. Ask another queston if you can't figure it out on your own. Good luck ! – atanas May 07 '19 at 20:45
  • @Crizly The general rule is apply network byte order to everything. All IEEE and IETF standards use network byte order. The rare exceptions are proprietary protocols (usually developed by amateurs that don't know about network byte order or deliberately ignore network byte order in favour of premature "optimisation"). So if it's things like TCP, IP, ARP, MAC etc use network byte order. If it's things like bencoding (bittorrent), protobuf (google) refer to their respective documentation – slebetman May 07 '19 at 20:57
  • 1
    ... however this header is clearly stored in **little-endian**. – user253751 May 07 '19 at 23:18
  • The documentation for Radiotap tells us that this answer is incorrect, @atanas – David Hoelzer May 08 '19 at 01:58
0

"little-endian" means that the low byte is stored before the high byte.

The two bytes that are stored are 19 00 (hex). The low byte is 19 (hex) and the high byte is 00 (hex). So the overall number is 0019 (hex) or 25 (decimal).

If you are running this on a little-endian system, you do not need to do any endian conversion. If you are writing a program that you want to also work on big-endian systems, you will need to be careful with endian-ness.

user253751
  • 57,427
  • 7
  • 48
  • 90