IEEE 802.15.4e support

[Devan Ming-Kin Lai <DevanL () davisinstruments com>]

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