Subject: Re: [6tisch] Minimal: error in IE header examples

From: Tom Phinney <[email-masked]>
Date: Wed, 24 Jun 2015 21:12:13 +0000 (GMT)

Agreed. We've struggled with this Endianness issue since the early days 
of Ethernet and IEEE 802. Blame it on HDLC.

To eliminate the ambiguities, always list the bytes in transmission 
order, together with a prominent note that
a) the bytes are listed in transmission order, and
b) each bytes is transmitted lsb first.

-Tom
====
On Wed, Jun 24, 2015 at 9:54 PM, Simon Duquennoy wrote:

> Hello,
>
> I believe what we want is the frame content as a series of bytes (not 
> bits,
> symbols or 16-bit words) in the order in which they are sent and 
> received.
> Here the second byte, in binary form starting with least significant 
> bit,
> is: 11111100 (as mentioned in your mail). That's unambiguously 0x3f 
> (==
> 0b00111111, == 63).
>
> Best regards,
> Simon
>
>
> On Wed, Jun 24, 2015 at 5:55 PM, Xavier Vilajosana <
> [email-masked]> wrote:
>
>> Sorry option 2 was incorrect.. too fast copy&paste
>>
>> 2) Another option is to convert to hex by considering the MSb first 
>> within
>> the octet
>>                   MSb         LSb
>> 0000 0000 1111 1100
>>  0x0  0x0      0xF   0xC
>>
>>   0x00          0xFC
>>
>> regards,
>> X
>>
>> 2015-06-24 17:53 GMT+02:00 Xavier Vilajosana <
>> [email-masked]>:
>>
>>> Hi Tengfei,
>>> this is confusing. Lets make sure this is the right way.
>>>
>>> For me the problem is how do we transform an HEX WORD to 16bits
>>>
>>> for example can be interpreted from left to right as LSB and from 
>>> MSB
>>> being right to left when transforming the binary representation to 
>>> the Hex
>>> representation
>>>
>>> Taking this IE as example
>>>
>>> 1) Header IE: list termination:
>>> len = 0 as bits 0-6
>>> id = 0x7e as bits 7-14
>>> type = 0 as bit 15
>>> header = len + id << 7 which gives 0x3f00
>>>
>>> if we consider that E in 0x7E is the least significative 4bits and 
>>> least
>>> significative bits are placed first (most left) we have:
>>>
>>>  7 zeros   0x7e    type 0
>>> 0000000011111100
>>>
>>> 1) When transforming this to HEX we consider the least significative 
>>> bits to
>>> go first from left to right. So
>>> LSb                           MSb
>>> 0000 0000 1111 1100
>>>  0x0  0x0      0xF   0x3
>>>
>>>   0x00          0x3F
>>>
>>> 2) Another option is to convert to hex by considering the MSb first
>>> within the octet
>>>                   MSb         LSb
>>> 0000 0000 1111 1100
>>>  0x0  0x0      0xF   0x3
>>>
>>>   0x00          0xFC
>>>
>>>
>>> What is the right option? I am not sure but seems more reasonable to 
>>> be 1)
>>>
>>> Maybe those annexes in 15.4 can help to find the right answer.
>>>
>>> regards,
>>> Xavi
>>>
>>>
>>> 2015-06-23 17:33 GMT+02:00 Tengfei Chang <[email-masked]>:
>>>
>>>> Jonathan ,
>>>>
>>>> Could you pointed which annexes or a page I can refer to? Did it 
>>>> say
>>>> that is an example that transmitted by PHY?
>>>>
>>>> Tengfei
>>>>
>>>> On Tue, Jun 23, 2015 at 11:27 PM, Jonathan Hui 
>>>> <[email-masked]>
>>>> wrote:
>>>>
>>>>> As mentioned in my previous mail, the annexes in the IEEE 802.15.4
>>>>> specification use the convention I outlined.
>>>>>
>>>>> --
>>>>> Jonathan Hui
>>>>>
>>>>>
>>>>> On Tue, Jun 23, 2015 at 8:21 AM, Tengfei Chang 
>>>>> <[email-masked]
>>>>>> wrote:
>>>>>
>>>>>> The hex value is correct. But I don't think this is the way to we
>>>>>> should follow to order the data. IEEE802.15.4 said we should 
>>>>>> transmit the
>>>>>> first bit, so we should follow this order.
>>>>>>
>>>>>> Tengfei
>>>>>>
>>>>>> On Tue, Jun 23, 2015 at 10:56 PM, Jonathan Hui 
>>>>>> <[email-masked]>
>>>>>> wrote:
>>>>>>
>>>>>>> Tengfei,
>>>>>>>
>>>>>>> Hex values are typically written in MSB order - this is 
>>>>>>> different
>>>>>>> from IEEE 802.15.4 which writes bit strings out in LSB order.
>>>>>>>
>>>>>>> For example:
>>>>>>> IEEE 802.15.4: 10000000
>>>>>>> is equivalent to
>>>>>>> Hex: 0x01
>>>>>>>
>>>>>>> So, w.r.t. the bytes being discussed:
>>>>>>> IEEE 802.15.4: 00000000 11111100
>>>>>>> is equivalent to
>>>>>>> Hex: 0x00 0x3f
>>>>>>>
>>>>>>> See the Annexes in IEEE 802.15.4 to see many more examples of 
>>>>>>> hex
>>>>>>> representations of MAC frames.
>>>>>>>
>>>>>>> --
>>>>>>> Jonathan Hui
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jun 23, 2015 at 7:39 AM, Tengfei Chang <
>>>>>>> [email-masked]> wrote:
>>>>>>>
>>>>>>>> I don't think 0x00 0x3F is right.
>>>>>>>>
>>>>>>>> In section 5.2 of IEEE802.15.4 standard, the second paragraph 
>>>>>>>> said :
>>>>>>>>
>>>>>>>> The frames in the MAC sublayer are described as a sequence of 
>>>>>>>> fields
>>>>>>>> in a specific order. All frame formats
>>>>>>>> in this subclause are depicted in the order in which they are
>>>>>>>> transmitted by the PHY, from left to right, where
>>>>>>>> the leftmost bit is transmitted first in time. Bits within each
>>>>>>>> field are numbered from 0 (leftmost and least
>>>>>>>> significant) to k – 1 (rightmost and most significant), where 
>>>>>>>> the
>>>>>>>> length of the field is k bits. Fields that are
>>>>>>>> longer than a single octet are sent to the PHY in the order 
>>>>>>>> from the
>>>>>>>> octet containing the lowest numbered bits
>>>>>>>> to the octet containing the highest numbered bits.
>>>>>>>>
>>>>>>>> When transmitting the data, we should make sure b0 goest first.
>>>>>>>>
>>>>>>>>
>>>>>>>> *For termination header IE *
>>>>>>>> *1) Header IE: list termination:*
>>>>>>>> *len = 0 as bits 0-6*
>>>>>>>> *id = 0x7e as bits 7-14*
>>>>>>>> *type = 0 as bit 15*
>>>>>>>> *header = len + id << 7 which gives 0x3f00*
>>>>>>>>
>>>>>>>> When transmitting the 00 3F, the bit transmitted by PHT is bit 
>>>>>>>> 7,
>>>>>>>> not b0.
>>>>>>>>
>>>>>>>> => in the document, it is currently 00 FC: 0000000 01111110 0,
>>>>>>>>
>>>>>>>> The first 7 bits goes is  len field bit0-bit6: 0000000, then 
>>>>>>>> goes
>>>>>>>> ID: b7-b14 7E 01111110, then type bit 15 0.
>>>>>>>>
>>>>>>>> Which is Correct.
>>>>>>>>
>>>>>>>> Tengfei
>>>>>>>>
>>>>>>>> On Tue, Jun 23, 2015 at 12:14 AM, Xavier Vilajosana <
>>>>>>>> [email-masked]> wrote:
>>>>>>>>
>>>>>>>>> Dear Simon,
>>>>>>>>>
>>>>>>>>> thanks for your comments. I might have messed bits up with
>>>>>>>>> endianness. I will recheck again. Note that we read them from 
>>>>>>>>> left to right
>>>>>>>>> being the leftmost the least significative bit and the right 
>>>>>>>>> most the most
>>>>>>>>> significative bit.
>>>>>>>>>
>>>>>>>>> in this case and taking the first element you mention
>>>>>>>>>
>>>>>>>>>  7 zeros   0x7e    type 0
>>>>>>>>> 0000000011111100
>>>>>>>>>
>>>>>>>>> if I convert this to hex where the least significant bit is 
>>>>>>>>> the
>>>>>>>>> leftmost it leads to
>>>>>>>>> 0x00 0x3F
>>>>>>>>>
>>>>>>>>> as you indicate.
>>>>>>>>>
>>>>>>>>> thanks so much for your comment!
>>>>>>>>> X
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2015-06-22 17:48 GMT+02:00 Jonathan Hui <[email-masked]>:
>>>>>>>>>
>>>>>>>>>> As someone who has implemented and deployed product that use 
>>>>>>>>>> IEEE
>>>>>>>>>> 802.15.4e-2012 Information Elements, I agree with Simon's 
>>>>>>>>>> encodings.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jonathan Hui
>>>>>>>>>>
>>>>>>>>>> On Mon, Jun 22, 2015 at 4:21 AM, Simon Duquennoy 
>>>>>>>>>> <[email-masked]
>>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Dear all,
>>>>>>>>>>>
>>>>>>>>>>> I believe the example IE headers (for header/payload/MLME 
>>>>>>>>>>> IEs)
>>>>>>>>>>> are wrong in section 10.1 of the minimal draft. Some 
>>>>>>>>>>> endianness confusion I
>>>>>>>>>>> guess:
>>>>>>>>>>>
>>>>>>>>>>> 1) Header IE: list termination:
>>>>>>>>>>> len = 0 as bits 0-6
>>>>>>>>>>> id = 0x7e as bits 7-14
>>>>>>>>>>> type = 0 as bit 15
>>>>>>>>>>> header = len + id << 7 which gives 0x3f00
>>>>>>>>>>>
>>>>>>>>>>> => with little endian encoding we get: 00 3F
>>>>>>>>>>> => in the document, it is currently 00 FC
>>>>>>>>>>>
>>>>>>>>>>> 2) Payload IE Header (MLME): 1A 88 seems correct
>>>>>>>>>>>
>>>>>>>>>>> 3) MLME-SubIE TSCH Synchronization:
>>>>>>>>>>> len = 6 as bits 0-7
>>>>>>>>>>> id = 0x1a as bits 8-14
>>>>>>>>>>> type = 0 as bit 15
>>>>>>>>>>> header = len + id << 8 which gives 0x1a06
>>>>>>>>>>>
>>>>>>>>>>> => with little endian encoding we get: 06 1A
>>>>>>>>>>> => in the document, it is currently 06 34
>>>>>>>>>>>
>>>>>>>>>>> 4) MLME-SubIE TSCH Timeslot:
>>>>>>>>>>> len = 1 as bits 0-7
>>>>>>>>>>> id = 0x1c as bits 8-14
>>>>>>>>>>> type = 0 as bit 15
>>>>>>>>>>> header = len + id << 8 which gives 0x1c01
>>>>>>>>>>>
>>>>>>>>>>> => with little endian encoding we get: 01 1C
>>>>>>>>>>> => in the document, it is currently 01 38
>>>>>>>>>>>
>>>>>>>>>>> and so on..
>>>>>>>>>>>
>>>>>>>>>>> My apologies if it is me misreading something.
>>>>>>>>>>>
>>>>>>>>>>> One other minor remark: in section 10, when describing byte
>>>>>>>>>>> order, I would suggest referring to "little-endian ordering" 
>>>>>>>>>>> rather than
>>>>>>>>>>> "LSB format".
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Simon
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 6tisch mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 6tisch mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 6tisch mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
>      ------------------------------
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 25 Jun 2015 00:28:49 +0200

To make sure we're on the same page, below are two examples of the
bit-and-byte ordering in the IEEE802.15.4e-2011 and IEEE802.15.4e-2012
standard, as I read them.
Please indicate whether this is what you understood.
@JonathanHui, I have IEEE802.15.4-2011 and IEEE802,15,4e-2012 in front of
me. Which Annexes are your referring to that contain such examples?
Thomas

----

*Example 1*. Frame Control Field

Fig 36 "Format of the Frame Control field" of IEEE802.15.4e-2012 (p 59)
indicates it is composed of the following field. In *blue* example values
for an unencrypted ACK frame.

   - [bit 0-2] Frame Type *(value for unencrypted ACK: 0b010==2==ACK)*
   - [bit 3] Security Enabled *(value for unencrypted ACK: 0b0)*
   - [bit 4] Frame Pending *(value for unencrypted ACK: 0b0)*
   - [bit 5] ACK request *(value for unencrypted ACK: 0b0)*
   - [bit 6] PAN ID compression *(value for unencrypted ACK: 0b1)*
   - [bit 7] reserved *(value for unencrypted ACK: 0b0)*
   - [bit 8] Sequence Number Suppression *(value for unencrypted ACK: 0b0)*
   - [bit 9] IE list present *(value for unencrypted ACK: 0b1)*
   - [bits 10-11] Dest. Address Mode *(value for unencrypted
   ACK: 0b11==3==64-bit)*
   - [bits 12-13] Frame Version *(value for unencrypted ACK: 0b10==2)*
   - [bits 14-15] Source Address Mode *(value for unencrypted
   ACK: 0b11==3==64-bit)*

These fields are organized in the following 2-byte "structure":

xxxx xxxx xxxx xxxx
                010 = Frame Type                  (3 bits, value 0b010)
               0    = Security Enabled            (1 bit,  value 0b0)
             0      = Frame Pending               (1 bit,  value 0b0)
            0       = ACK request                 (1 bit,  value 0b0)
           1        = PAN ID compression          (1 bit,  value 0b1)
          0         = reserved                    (1 bit,  value 0b0)
        0           = Sequence Number Suppression (1 bit,  value 0b0)
       1            = IE list present             (1 bit,  value 0b1)
     11             = Dest. Address Mode`         (2 bits, value 0b11)
  10                = Frame Version               (2 bits, value 0b10)
11                  = Source Address Mode         (2 bits, value 0b11)
-------------------
1110 1110 0100 0010 = 0xee42

Because this 2-byte field is sent "little endian", what you will see in the
air is 0x42ee.

*Example 2*. header of a "ACK/NACK Time-Correction" IE

Format of a header IE (IEEE802.15.4-2012, p.57) is below. In *blue* example
values for a "ACK/NACK Time-Correction" IE.

   - [bits 0-6] Length *(value for "ACK/NACK Time-Correction" IE: 2)*
   - [bits 7-14] Element ID *(value for "ACK/NACK Time-Correction" IE:
   0x1e, see IEEE802.15.4-2012, Table 4b, p.81)*
   - [bit 15] type *(value for "ACK/NACK Time-Correction" IE: 0, as it's a
   header IE)*

These fields are organized in the following 2-byte "structure":

xxxx xxxx xxxx xxxx
           000 0010 = Length     (7 bits, value 2)
 000 1111 0         = Element ID (8 bits, value 0x1e)
0                   = Type       (1 bit,  value 0)
-------------------
0000 1111 0000 0010 = 0x0f02

Because this 2-byte field is sent "little endian", what you will see in the
air is 0x020f.

On Wed, Jun 24, 2015 at 11:12 PM, Tom Phinney <[email-masked]> wrote:

> Agreed. We've struggled with this Endianness issue since the early days of
> Ethernet and IEEE 802. Blame it on HDLC.
>
> To eliminate the ambiguities, always list the bytes in transmission order,
> together with a prominent note that
>> symbols or 16-bit words) in the order in which they are sent and received.
>> Here the second byte, in binary form starting with least significant bit,
>> is: 11111100 (as mentioned in your mail). That's unambiguously 0x3f (==
>> 0b00111111, == 63).
>>
>> Best regards,
>> Simon
>>
>>
>>>> for example can be interpreted from left to right as LSB and from MSB
>>>> being right to left when transforming the binary representation to the
>>>> Hex
>>>> representation
>>>>
>>>> if we consider that E in 0x7E is the least significative 4bits and least
>>>> What is the right option? I am not sure but seems more reasonable to be
>>>> 1)
>>>>
>>>>> Could you pointed which annexes or a page I can refer to? Did it say
>>>>> On Tue, Jun 23, 2015 at 11:27 PM, Jonathan Hui <[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> On Tue, Jun 23, 2015 at 8:21 AM, Tengfei Chang <
>>>>>> [email-masked]
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>
>>>>>>> On Tue, Jun 23, 2015 at 10:56 PM, Jonathan Hui <[email-masked]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>  Tengfei,
>>>>>>>>
>>>>>>>> Hex values are typically written in MSB order - this is different
>>>>>>>> See the Annexes in IEEE 802.15.4 to see many more examples of hex
>>>>>>>>> In section 5.2 of IEEE802.15.4 standard, the second paragraph said
>>>>>>>>> :
>>>>>>>>>
>>>>>>>>> significant) to k – 1 (rightmost and most significant), where the
>>>>>>>>> longer than a single octet are sent to the PHY in the order from
>>>>>>>>> the
>>>>>>>>> When transmitting the 00 3F, the bit transmitted by PHT is bit 7,
>>>>>>>>> not b0.
>>>>>>>>>
>>>>>>>>> The first 7 bits goes is  len field bit0-bit6: 0000000, then goes
>>>>>>>>>> being the leftmost the least significative bit and the right most
>>>>>>>>>> the most
>>>>>>>>>> significative bit.
>>>>>>>>>>
>>>>>>>>>> if I convert this to hex where the least significant bit is the
>>>>>>>>>> leftmost it leads to
>>>>>>>>>> 0x00 0x3F
>>>>>>>>>>
>>>>>>>>>> as you indicate.
>>>>>>>>>>
>>>>>>>>>>  As someone who has implemented and deployed product that use IEEE
>>>>>>>>>>> On Mon, Jun 22, 2015 at 4:21 AM, Simon Duquennoy <
>>>>>>>>>>> [email-masked]
>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  Dear all,
>>>>>>>>>>>>
>>>>>>>>>>>> I believe the example IE headers (for header/payload/MLME IEs)
>>>>>>>>>>>> are wrong in section 10.1 of the minimal draft. Some endianness
>>>>>>>>>>>> confusion I
>>>>>>>>>>>> guess:
>>>>>>>>>>>>

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 24 Jun 2015 15:40:18 -0700

There are a number of examples in Annex C in IEEE 802.15.4-2011 that
express IEEE 802.15.4 frames as a a sequence of hex bytes.  For example,
Section C.2.1.1 has the following text:

    Secured beacon frame:
    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.

It doesn't take much to figure out that:
1) The bytes are listed in little-endian order from left to right
2) Within each byte, the bits are such that 0x01 represents bit 0 being set
to 1 and 0x80 represents bit 7 being set to 1.

We should follow the convention already used in IEEE 802.15.4 specs.

--
Jonathan Hui

On Wed, Jun 24, 2015 at 3:28 PM, Thomas Watteyne <[email-masked]

> Because this 2-byte field is sent "little endian", what you will see in
> the air is 0x42ee.
>
>
>
>    - [bit 15] type *(value for "ACK/NACK Time-Correction" IE: 0, as it's
>    a header IE)*
>
> Because this 2-byte field is sent "little endian", what you will see in
> the air is 0x020f.
>
>
>>>>>>>> On Tue, Jun 23, 2015 at 10:56 PM, Jonathan Hui <[email-masked]
>>>>>>>> >
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>  Tengfei,
>>>>>>>>>

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 25 Jun 2015 00:41:23 +0200

+1
Thanks

On Thu, Jun 25, 2015 at 12:40 AM, Jonathan Hui <[email-masked]> wrote:

>     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.
>
> 2) Within each byte, the bits are such that 0x01 represents bit 0 being
> set to 1 and 0x80 represents bit 7 being set to 1.
>
> On Wed, Jun 24, 2015 at 3:28 PM, Thomas Watteyne <
> [email-masked]> wrote:
>
>> indicates it is composed of the following field. In *blue* example
>> values for an unencrypted ACK frame.
>>

---

From: Tengfei Chang <[email-masked]>
Date: Thu, 25 Jun 2015 13:40:00 +0800

Jonathan, Simon,

After the discussion on the format order of ieee802.15.4, I believe now the
format that proposed by Simon is right.

The text I copied from IEEE802.15.4 didn't cover the case of 2.4GHz O-QPSK
radio chip, which will transmit the data by bits group, not bit by bit.
Thanks Thomas for clarifying this!

Sorry if I made some trouble on this issue!

Tengfei

On Thu, Jun 25, 2015 at 6:41 AM, Thomas Watteyne <[email-masked]

>>> @JonathanHui, I have IEEE802.15.4-2011 and IEEE802,15,4e-2012 in front
>>> of me. Which Annexes are your referring to that contain such examples?
>>> Thomas
>>>
>>> ----
>>>
>>>    - [bit 15] type *(value for "ACK/NACK Time-Correction" IE: 0, as
>>>    it's a header IE)*
>>>
>>>>>>>> On Tue, Jun 23, 2015 at 11:27 PM, Jonathan Hui <[email-masked]
>>>>>>>> >
>>>>>>>> wrote:
>>>>>>>>

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 25 Jun 2015 08:42:36 +0200

Tengfei,
We are putting together different pieces of the stack contained in many
document written by different organizations. It's of course a bit
confusing, and it's great that so many eyes are looking so closely at it.
You're not "making trouble" in any way, please keep on doing exactly what
you are doing :-)
Thomas

On Thursday, June 25, 2015, Tengfei Chang <[email-masked]> wrote:

> Jonathan, Simon,
>
> After the discussion on the format order of ieee802.15.4, I believe now
> the format that proposed by Simon is right.
>
> The text I copied from IEEE802.15.4 didn't cover the case of 2.4GHz
> O-QPSK radio chip, which will transmit the data by bits group, not bit by
> bit. Thanks Thomas for clarifying this!
>
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> +1
>> Thanks
>>
>> On Thu, Jun 25, 2015 at 12:40 AM, Jonathan Hui <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>
>>> [email-masked]
>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>>
>>>> On Wed, Jun 24, 2015 at 11:12 PM, Tom Phinney <[email-masked]
>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>>>
>>>>> Agreed. We've struggled with this Endianness issue since the early
>>>>> days of Ethernet and IEEE 802. Blame it on HDLC.
>>>>>
>>>>>> [email-masked]
>>>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>>>>>> wrote:
>>>>>>
>>>>>>> [email-masked]
>>>>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>:
>>>>>>>
>>>>>>>  Hi Tengfei,
>>>>>>>> 1) When transforming this to HEX we consider the least
>>>>>>>> significative bits to
>>>>>>>> What is the right option? I am not sure but seems more reasonable
>>>>>>>> to be 1)
>>>>>>>>
>>>>>>>> 2015-06-23 17:33 GMT+02:00 Tengfei Chang <[email-masked]
>>>>>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>:
>>>>>>>>
>>>>>>>>  Jonathan ,
>>>>>>>>>
>>>>>>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>  Tengfei,
>>>>>>>>>>>>
>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Dear Simon,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2015-06-22 17:48 GMT+02:00 Jonathan Hui <[email-masked]
>>>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  Dear all,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> order, I would suggest referring to "little-endian
>>>>>>>>>>>>>>>> ordering" rather than
>>>>>>>>>>>>>>>> "LSB format".
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>> Simon
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>>>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>>>>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>>>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 25 Jun 2015 12:57:21 +0300

Jonathan Hui writes:
> There are a number of examples in Annex C in IEEE 802.15.4-2011 that express
> IEEE 802.15.4 frames as a a sequence of hex bytes.  For example, Section
> C.2.1.1 has the following text:

BTW, while working on the 802.15.4rev it was noticed, that we do not
have any examples of secured frames having any IEs in them (because 4e
did not update Appendix C). I think it would be useful to have example
frame having IEs in them, most likely both Header and Payload IEs.

On the other hand if someone tries to generate such examples manually
they most likely will be wrong because of all this Bit order / Byte
Order stuff.

Because of that, it would be really good if anybody who has
implementation supporting secured IEs would be able to print out
examples of real frames.

For example following ones would be really useful:

- MIC-32 protected Enhanched beacon frame (frame version 0b10)
  This could for example have TSCH related Nested MLME Payload IEs in
  it. 
- ENC-MIC-64 protected MAC Command frame with Command ID of 0x07
  Beacon Request having Enhanced Beacon Filter Nested MLME Payload IE
  in it (frame version 0b10) 
- MIC-32 protected Enh-Ack with Time Correction Header IE (frame
  version 0b10)

So if anybody have implementation which can generate such examples,
please contact me or Pat Kinney...
-- 
[email-masked]