peter@xxxxxxxxxxxx wrote:
My dissector detects that a data connection will be established to IP
192.168.169.2, port 2441 (similar to FTP data connections). I therefor add
a conversation with no 2nd address nor 2nd port (NO_ADDR2 | NO_PORT2). The
first new connection made to IP 192.168.169.2, port 2441 is established
from, say, 192.168.169.128, port 1234. When dissecting more frames, the
call to find_conversation from packet-tcp's try_conversation_dissector
will change the conversation <192.168.169.2, 2441, 0, 0> to
<192.168.169.2, 2441, 192.168.169.128, 1234> (why does find_conversation
change a conversation at all, what have I missed?).
Because the data connection has been established. You said "my
dissector detects that *a* data connection will be established", not
"...that data connection*s* will be established". Just because one
particular connection happens to be of the type that the dissector says
will appear in the future, that doesn't mean that *all* connections with
the one address and port in question will be of that type.
(And, yes, I think I had to do that to fix a bug. I did it about 3
years ago, so I no longer remember the details, but I could try doing a
regression test between the current code and the code with your patch to
see what breaks - there's no guarantee that I have a capture that will
test the change, though.)
This means that any
additional connections made to <192.168.169.2, 2441> will not be decoded
by the dissector for which the conversation was initially created since
they will not match the second part of the conversation which has changed
to <192.168.169.128, 1234>.
If it *is* the case, for your dissector, that 192.168.169.2/2441 will
always be the recipient of connections for the same protocol, we should
add something I mentioned a while ago, namely the ability to establish a
"template" conversation - when a matching packet is found, a new
conversation is created, with the wildcards filled in, but the original
"template" conversation remains.
