In certain protocols (such as iSNS), the client registers a port on which it
can receive notifications from a server at later times. The server can connect
using different ports when providing different notifications. Typically, the
server sets up a TCP connection to the registered port, provides the
notification and shuts down the connection. At a later time, it may reconnect
to the same registered port from a different source port to provide a different
notification.
This causes a problem with the way dissectors that hang off conversations are
setup. Consider the case where a dissector is associated with a conversation
with the option NO_PORT2. When the conversation is dissected the first time,
find_conversation() causes the source port (port2) to be set as
well. Subsequent connections originating from a different source port will now
fail to be dissected.
To fix this problem, I was thinking of providing an option during
conversation_new() called NO_PORT2_FORCE. If this option is specified,
find_conversation () or conversation_set_port2() will not remove the wildcard
for the second port. I have coded such a change and tested it.
1) Is this the right way to fix this problem ?
2) Should a NO_ADDR2_FORCE option be provided as well ?
On a separate note, I couldn't figure out why we have two sets of similar
#defines, NO_ADDR2/NO_PORT2 and NO_ADDR_B/NO_PORT_B.
Thanks,
Dinesh
--
Become the change you want to see in the world - Gandhi
