Wireshark · Wireshark-dev: [Wireshark-dev] Extending PCLI payload decoding

[Luke Mewburn <luke@xxxxxxxxxxx>]

Hi.

tl;dr:

PCLI payload type selection needs enhancing.
I made a first attempt at addressing this in
	https://code.wireshark.org/review/#/c/8608
but that needs improving.  I'm trying to determine the preferred interface.

I decided to expand the scope of the discussion and move it here to the
mailing list, because I wasn't sure that the comment boxes on the
changeset are sufficient for an extended discussion.  My apologies if
this wasn't the correct thing to do; I'll move it back to gerrit if
that's preferred.


Details:

There's a couple of bugs relating to PCLI decoding:
	https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9266
	https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11220

I submitted a changeset to address bug 9266 by adding a preference
to select the inner payload type, changing from the default of
IP to also allow Ethernet.
	https://code.wireshark.org/review/#/c/8608

Michael Mann & Guy Harris both provided constructive feedback on the
improving the change to use the currently preferred mechanism to control
the payload decoding.

I intend to rework the change appropriately, pending the outcome of a
discussion of what is the best way to make the changes.


PCLI appears to be a bit more complex than it first appears.
The PCLI header format can be at least one of:

1. 4 byte CCCID. IP payload.
Existing dissector.

2. 4 byte CCCID. Ethernet payload.
Bug 9266.

3. 8 byte header. Ethernet payload.
Bug 11220.
Is there documentation describing this variation besides the
bug report?
Note: the packet capture in bug 11220 is not a 12 byte header,
it's an 8 byte header which looks like the string "abcf1234"
instead of a 4 byte CCCID, followed by a payload of:
Ethernet, with an 802.11q VLAN TAG, IP, TCP.

4. 4 byte CCCID, 8 byte timestamp. IP payload.
According to PKT-SP-ESP1.5-I02-070412 linked to in bug 11220.
No sample traffic in the bug database.

5. 4 byte CCCID, 8 byte timestamp, 8 byte case ID. IP payload.
According to PKT-SP-ES-DCI-C01-14031 linked to in bug 11220.
No sample traffic in the bug database.

(It's unfortunate that there's no encapsulation type available in the
PCLI header to differentiate.)


Suggested enhancements:

1) Allow explicit selection of PCLI format and PCLI payload decoding.

This is useful even if auto-detection (see below) is implemented.
I'll examine how the "Decode As" menu functions per Michael's suggestion.

This may need two separate controls:
- one to control the PCLI header variation
- another to control the PCLI payload variation


2) Attempted auto detection of PCLI payload.

Payload variations known about:
- Ethernet has a 16 bit ethertype at +12 octets with a relatively
well known value range.
- IPv4 starts with 0x4_, and 16 bit payload length at +2 octets
- IPv6 starts with 0x6_, and 16 bit payload length at +4 octets.

I don't know how robust this could be, or if there's existing
dissectors in wireshark that can be used as a reference.
This would need to try the various PCLI header format variations
as listed above (4 byte CCCID, 8 byte ID, 12 byte CCCID+time, 20 byte
CCCID+time+CaseID)


regards,
Luke.

Attachment: pgpOBCosmaJ17.pgp
Description: PGP signature