> On 4May 2018, at 19:10, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
> That might *also* be useful, but the advantage of blocks that *aren't* tied to Wireshark is that *other* programs can use the data without having to track Wireshark.
I see, but to support multiple protocols in a capture, some authority that allocates protocol identifiers would be desirable
and I think Wireshark protocol names are very suited for this (after renaming SSL to TLS :-).
Maybe:
- Standardize some prefs_register_key_preference API for key supplement in Wireshark that wraps existing UAT/preference use and provides key preferences in a uniform format
- Agree on a specific format for those key preferences inside pcapng blocks
- Implement the new pcapng block and Wireshark preferences support, maybe a mergeprefcap(1) as well
I would like if both the Tibia and the EPL dissectors were able to utilize this as well. Currently their preferences are:
Tibia: symmetric key (frame number, key_hexstring)
Tibia: asymmetric key (ip_addr, port_num, key_file, password)
EPL: Device Profile (device_id, vendor_id, product_id, path)
This could be generalized as entries of (protocol_name, frame_number, key_string).
frame_number would be a packet that uniquely identifies what the key is for (handshake packet, IdentifyResponse..) or just some packet in a TCP conversation.
Downside of using "key" frames is that this could necessitate relocation when editing the capture. What do you think?
Cheers
Ahmad