> On 4May 2018, at 19:10, Guy Harris <g...@alum.mit.edu> 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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
