ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: [Ethereal-dev] Use of NO_PORT2 for dissecting conversations

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Dinesh G Dutt <ddutt@xxxxxxxxx>
Date: Mon, 28 Jun 2004 14:59:11 -0700
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