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:
pgpwuCpmvDLj1.pgp
Description: PGP signature
