On Thu, Aug 23, 2012 at 4:52 PM, Markus Amend <[email protected]> wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: [email protected] [mailto:netsniff-
>> [email protected]] Im Auftrag von Emmanuel Roullit
>> Gesendet: Donnerstag, 23. August 2012 16:21
>> An: [email protected]
>> Betreff: Re: [netsniff-ng] 802.11 mac hdr
>>
>> On 08/23/2012 04:04 PM, Markus Amend wrote:
>> > Hi,
>> >
>> > currently I’m working on proto_80211_mac_hdr.c and have problems with
>> > getting infos to the construction of several subheader formats. For
>> > example the beacon frame:
>> >
>> > $ netsniff-ng -i examples/pcap/802.11/Network_Join_Nokia_Mobile.pcap
>> > -n1 (currently only works with https://github.com/markusa/netsniff-ng)
>> >
>> > The timestamp I get is 0x84211a6902000000 while in wireshark it is
>> > 0x00000002691a2184 and I don’t know why because of missing
>> > documentation. Furthermore there are a lot of more fields in a beacon
>> > frame where I don’t know how to evaluate them.
>>
>> The answer is byte-order. This info is captured in network-byte order
> (big-
>> endian).
>> In your implementation, this timestamp is saved in a uint8t [8] so the
> byte
>> order stays as is.
>> Wireshark very likely saves it as a uint64_t and converts it to
> little-endian (x86
>> natural endianness) before printing it to the user.
>>
>> More info with "man be64toh"
>
> But 802.11 frames should be little endian ?! Who is wrong, wireshark or I
> :-) ?

As far as I know, 802.11 headers are in little-endian.

>> > Has anybody the 802.11 standard where are detailed informations about
>> that?
>> >
>>
>> I did not have time to look for the specs but there should be RFC's for
> that
>
> RFCs? I haven't find anything.

Probably you won't find anything in RFC's since it was not proposed by
the IETF, but by IEEE.

-- 


Reply via email to