 |
Wireshark 4.5.0
The Wireshark network protocol analyzer
|
Loading...
Searching...
No Matches
|
Wireshark 4.5.0
The Wireshark network protocol analyzer
|
#include <conversation.h>
Public Attributes | ||
| conversation_element_type | type | |
| union { | ||
| conversation_type conversation_type_val | ||
| address addr_val | ||
| unsigned int port_val | ||
| const char * str_val | ||
| unsigned int uint_val | ||
| uint64_t uint64_val | ||
| int int_val | ||
| int64_t int64_val | ||
| struct { | ||
| const uint8_t * val | ||
| size_t len | ||
| } blob | ||
| }; | ||
Elements used to identify conversations for *_full routines and pinfo->conv_elements. Arrays must be terminated with an element .type set to CE_CONVERSATION_TYPE.
This is currently set only by conversation_set_elements_by_id(); it is not set for conversations identified by address/port endpoints.
In find_conversation_pinfo() and find_or_create_conversation(), if any dissector has set this, then, unless some dissector has set the pair of address/port endpoints (see below), the array of elements is used to look up or create the conversation. Otherwise, the current addresses and ports in the packet_info structure are used.
XXX - is there any reason why we shouldn't use an array of conversation elements, with the appropriate addresses and ports, and set it for all protocols that use conversations specified by a pair of address/port endpoints? That might simplify find_conversation_pinfo() by having them always use the array of elements if it's present, and just fail if it's not.
1.9.8