Guy Harris wrote:
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.)
OK, so this is by design then; fine.
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>.
This means that any
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.
Yes, in this case all future connections made to 192.168.169.2/2441
should be handled by the same protocol dissector.
Do you (or anyone else for that matter) have an idea of how to
accomplish the "template" conversation you had in mind?
I got the idea that one could add another option value which could be
used in conjunction with either NO_ADDR_B, NO_PORT_B or both, say
PERSISTENT (value should be 0x08 or perhaps 0xF0). The dissector could
then do:
c = conversation_new(addr1, addr1, PTYPE, port1, 0, NO_ADDR_B |
NO_PORT_B | PERSISTENT).
When find_conversation completes the conversation for a newly made
connection for c, it should instead of g_hash_table_remove do
g_hash_table_insert for the established connection when options specify
PERSISTENT in conjunction with either of (or both) NO_ADDR_B and NO_PORT_B..
If you approve of the idea (and nobody else is pursuing this yet) I am
willing to do this. What do you think?
/ Regards, Peter
