Ask Your Question
0

Decoding of Tx attenuation field in the Radiotap Header of the data link type 'IEEE802_11_RADIOTAP'?

asked 2018-02-22 13:18:36 +0000

Prasanth gravatar image

updated 2018-02-22 13:28:41 +0000

grahamb gravatar image

I have gone through the source code of Wireshark 2.4.1. In this i found that, decoding of the 'Tx Attenuation' and 'Tx Attenuation dB' fields are of ENC_BIG_ENDIAN. But, in the official link of radio tap header http://www.radiotap.org/, i didn't find anything specified about the byte ordering.

Note: Except these two and FHSS fields, rest of the fields are using ENC_LITTLE_ENDIAN encoding. Which one is correct? LITTLE or BIG? can you provide the reference for that information?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2018-02-22 13:39:34 +0000

grahamb gravatar image

That code hasn't changed since 2012 (git commit daa1818d39c), if you believe it's wrong, create an entry on the Wireshark Bugzilla, noting any references that state those fields should be little endian.

edit flag offensive delete link more

Comments

I was unable to find any reference towards this. But i don't understand why only these two fields are using BIG_ENDIAN? As the rest of the fields are using LITTLE_ENDIAN?

Prasanth gravatar imagePrasanth ( 2018-02-22 13:44:35 +0000 )edit

Up to Linux 4.10.17, the radiotap header noted that they were le:

 * IEEE80211_RADIOTAP_TX_ATTENUATION    __le16       unitless
 *
 *      Transmit power expressed as unitless distance from max
 *      power set at factory calibration.  0 is max power.
 *      Monotonically nondecreasing with lower power levels.
 *
 * IEEE80211_RADIOTAP_DB_TX_ATTENUATION __le16       decibels (dB)
 *
 *      Transmit power expressed as decibel distance from max power
 *      set at factory calibration.  0 is max power.  Monotonically
 *      nondecreasing with lower power levels.
 *

For 4.11 onwards, the header says to refer to the radiotap.org site.

So it does look like they should be le.

grahamb gravatar imagegrahamb ( 2018-02-22 14:04:14 +0000 )edit

Thanks for the info.

Prasanth gravatar imagePrasanth ( 2018-02-22 14:29:02 +0000 )edit

Prior to the commit 59562378e410f8f27e1c1978eda52f6d6a193614, in 2006 (when the file was named epan/dissectors/packet-radiotap.c; you need to use --follow when doing a git log on epan/dissectors/packet-ieee80211-radiotap.c, to catch pre-rename changes), there was an #if 0-ed out tvb_get_letohs(tvb, offset); call.

In that commit, there was a call proto_tree_add_item(radiotap_tree, hf_radiotap_tx_attenuation, tvb, offset, 2, FALSE);, which means it was made big-endian. This was probably a copy-and-pasteo.

The radiotap.org site says

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. This wiki has adopted the Linux convention of using __le64, __le32 and __le16 for 64-, 32- and 16-bit little endian quantities.

but doesn't use that convention for individual fields - that convention isn't sufficient for fields, given that most are unsigned, but some are ...(more)

Guy Harris gravatar imageGuy Harris ( 2018-02-22 18:19:02 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-02-22 13:18:36 +0000

Seen: 37 times

Last updated: Feb 22