Re: [RFC] the problem of on-the-wire byte order in ieee802154

From: Simon Vincent <simon.vincent@xsilon.com>
To: Alexander Aring <alex.aring@gmail.com>,
	Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>,
	linux-wpan@vger.kernel.org
Subject: Re: [RFC] the problem of on-the-wire byte order in ieee802154
Date: Fri, 29 May 2015 09:53:40 +0100	[thread overview]
Message-ID: <55682914.6060109@xsilon.com> (raw)
In-Reply-To: <20150529083145.GA3709@omega>

I noticed the 802.15.4 spec has test vectors for the crypto that show 
the byte order of the address.
See 802.15.4-2011 spec [1]
Annex C, Section C.2.1.1

source address 0xacde480000000001 is represented in a packet as.
08 D0 84 21 43 01 00 00 00 00 48 DE AC || 02 05 00 00 00 || 55 CF 00 00 
51 52 53 54 22 3B C1 EC 84 1A
B5 53.

- Simon
[1] - https://standards.ieee.org/getieee802/download/802.15.4-2011.pdf

On 29/05/15 09:31, Alexander Aring wrote:
> On Fri, May 29, 2015 at 11:08:21AM +0300, Lennert Buytenhek wrote:
> ...
>>> That the PSDU should send in little endian is specified in section:
>>> 10.2.3 Bit-to-symbol mapping
>>>
>>> "Each octet of the PPDU is processed through the modulation and spreading
>>> functions, as illustrated in Figure 69, sequentially, beginning with the
>>> Preamble field and ending with the last octet of the PSDU. Within each octet,
>>> the least significant symbol (b0,b1,b2,b3) is processed first and the most
>>> significant symbol (b4,b5,b6,b7) is processed second."
>> This is about bit ordering, not byte ordering -- and it's consistent
>> with what I have been saying before -- it explains why the I/G bit
>> is transmitted first, even though it is the 0x01 bit in the first
>> address byte.
>>
> I need to lookup more information about this.
>
> I know this not an argument, but let us think about if we change the byte
> order there. This means that SAM/DAM decompression/compression BIT 11 is wrong [0].
> (The remaining 64 bits are computed from the encapsulating header (e.g.,
> 802.15.4 or IPv6 source address)...)
>
> That also means that wireshark, contiki, etc. will all do currently the wrong
> byte ordering at L2. I currently can't believe that and we should really
> clarifying this issue before we change this. Otherwise we are
> incompatible with the whole 802.15.4 IoT used software outside.
>
> - Alex
>
> [0] https://tools.ietf.org/html/rfc6282#section-3.1.1
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html