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

endian

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

Prasanth
1 ●2

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

grahamb

flag of United Kingdom of Great Britain and Northern Ireland

23835 ●4 ●973 ●227 https://www.wireshark.org

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

add a comment

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

grahamb

23835 ●4 ●973 ●227 https://www.wireshark.org

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

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 ( 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 ( 2018-02-22 14:04:14 +0000 )edit

Thanks for the info.

Prasanth ( 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 ( 2018-02-22 18:19:02 +0000 )edit

add a comment

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

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

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

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

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