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.
