Re: IEEE 802.15.4e support

[Alexis La Goutte <alexis.lagoutte () gmail com>]

Hi Devan,

i think, it is better solution 2, if the 2 patch are on the same branch,
Gerrit will be say, there is some related change

Cheers

On Wed, Oct 2, 2019 at 3:12 AM Devan Ming-Kin Lai <
DevanL () davisinstruments com> wrote:

> Hi,
>
>
>
> I’ve been working with a device that uses IEEE 802.15.4e1 and I’ve been
> using Wireshark to dissect the traffic.
>
>
>
> From looking around, I know that there are a couple of out-of-tree
> dissectors for 802.15.4e that are essentially forks of older versions of
> the standard 802.15.4 dissector:
>
>    - pdemil’s ieee802154e dissector -
>    https://github.com/pdemil/802154e-wireshark/wiki/IEEE-802.15.4e-wireshark-dissector
>    - TI’s Smart RF Packet Sniffer 2 -
>    http://www.ti.com/tool/download/PACKET-SNIFFER-2 - provides source for
>    their plugin, but the download is behind TI’s standard export-restriction
>    wall.
>
>
>
> From my own testing, the ieee802154 dissector with support for the IEEE
> 802.15.4-20152 standard is very close to being able to handle 802.15.4e
> packets, so extending the existing dissector to handle 802.15.4e seems
> preferable to having a very similar but slightly different out-of-tree copy.
>
>
>
> Right now I have two branches – one with just the IEEE 802.15.4-2015
> multipurpose frame support, which is purely an enhancement to the existing
> dissector.
>
> The other branch builds on the multipurpose frame support and adds special
> cases (read: compatibility hacks) to handle IEEE 802.15.4e, but only when a
> compatibility preference is enabled.
>
>
>
> I’d like to get feedback on how best to proceed. Should I:
>
>    1. Upload just the multipurpose frame enhancements for review on
>    Gerrit, and then the compatibility changes if the first changeset is merged
>    2. Upload a changeset with all of the changes for review
>    3. Upload two separate changesets at the same time
>
>
>
> For context, I’ve included my notes on the changes involved:
>
>
>
> 1. Add support for multipurpose frames.
>
>
>
> The existing dissector does not handle multipurpose frames correctly.
> Unlike all other frames, the FCF field for multipurpose frames follows a
> completely different layout, mostly because it has been defined such that
> the FCF can be either one or two bytes long3.
>
>
>
> 2. Handle the incompatible 802.15.4e PAN ID compression rules
>
>
>
> For frame version 2 (0b10), when both the source and destination address
> are present, 802.15.4e4 does not differentiate between short and extended
> addresses when determining which PAN ID compression combinations are legal,
> whereas 802.15.4-2015 does. When dealing with only extended addresses, the
> PAN ID compression rules are equivalent.
>
>
>
> However, if either of the addresses is short, the PAN ID compression rules
> for 802.15.4-2015 differ. When the destination PAN ID is present and the
> source PAN ID is absent, if either address is short, the PAN ID compression
> bit must be set to 1, otherwise it is set to 05. Since 802.15.4e doesn’t
> distinguish between short/extended, it always sets the PAN ID compression
> bit to 0, which only matches in the case that both addresses are extended.
>
>
>
> 3. Handle ambiguous / incompatible wake-up frames
>
>
>
> 802.15.4e explicitly defines a wake-up frame as a multipurpose frame with
> a 1 byte FCF, two header IEs, and no payload6.
>
> In a one-byte FCF, the IE present bit is missing, so under 802.15.4-2015
> rules, it is at best ambiguous and at worst not permitted for the frame to
> contain header IEs when the FCF field is only one byte long.
>
> For compatibility with 802.15.4e, it is necessary to check if the frame
> looks like an 802.15.4e wake-up frame and then override the header IE
> parsing rules if it is one.
>
>
>
> References:
>
>    1.
>    ftp://linux.mikroklima.cz/MIDAM-CD/MIDAM%20modbus%20-%20popis/Blizard/802.15.4e-2012.pdf
>    2.
>    
> https://www.silabs.com/content/usergenerated/asi/cloud/attachments/siliconlabs/en/community/wireless/proprietary/forum/jcr:content/content/primary/qna/802_15_4_promiscuous-tbzR/hivukadin_vukadi-iTXQ/802.15.4-2015.pdf
>    3. IEEE 802.15.4-2015, section 7.3.5, Multipurpose frame format
>    4. IEEE 802.15.4e-2012, section 5.2.1.1.5 PAN ID Compression field,
>    Table 2a – PAN ID Compression
>    5. IEEE 802.15.4-2015, section 7.2.1.5, PAN ID Compression field,
>    Table 7-2 – PAN ID Compression field value for frame version 0b10 [note:
>    table 7-2 puts destination on the left and source on the right, while table
>    2a has the opposite convention]
>    6. IEEE 802.15.4e-2012, section 5.2.2.8, LE-multipurpose Wake-up frame
>
>
>
> Thanks,
>
> -Devan.
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe