[mmann78@xxxxxxxxxxxx]

Certainly fine to move the discussion here IMO.  I get better "text formatting" in email form than I do from Gerrit anyway.

 

Some comments:

1. I'm of the opinion that no NEW development should have enum preferences for choosing subdissectors.  Dissectors that need to give user an option to change subdissection should do it through Decode As functionality.

 

2. I was unaware of all of the different PCLI headers.  Guy's review comments make a little more sense now.  I think I would take the route of creating 5 separate dissectors (all with unique "protocol names" to help distinguish in Decode As dialog)  The dissectors would dissect the fields you describe up to the payload and then the payload would be controlled by Decode As.  I'm taking the (uneducated) stance that the payload types are not fixed for any of the different header types and that you could see any protocol as a payload.  If you think there's a good chance the payload types are fixed, you can "hardcode" the dissectors as needed (for say header types 3-5) like for what is currently done in the dissector.

 

3. Not sure how you want to handle the UDP port registration if you do have the 5 protocols.  They don't appear "heuristically strong enough" to distinguish.  Perhaps the current preference of picking a UDP port (which defaults to 0 anyway) should just be removed in favor of complete Decode As functionality (with all 5 dissectors registered with dissector_add_for_decode_as).

 

Michael

 

 

-----Original Message-----
From: Luke Mewburn <luke@xxxxxxxxxxx>
To: wireshark-dev <wireshark-dev@xxxxxxxxxxxxx>
Sent: Sun, May 24, 2015 7:44 pm
Subject: [Wireshark-dev] Extending PCLI payload decoding

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.

___________________________________________________________________________
Sent
via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:   
https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
https://wireshark.org/mailman/options/wireshark-dev
            
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe