[Guy Harris <guy@xxxxxxxxxx>]

> I'm hacker hunting.

Hackers, or crackers? :-)

> I have some hackers playing around in my network
> and I'm observing their activity.  I use etheral to dig through my
> traffic for telnet sessions, then "Follow TCP Stream" to see what the
> bad guys are up to.  It's a pain to sift through many legitimate
> packets, filter a whole dump for one stream, then filter it again to
> get the "full" view.  I need to cut down the number of lines of
> output.
> 
> I'd like to list traffic by connections rather than individual
> packets.  One row per tcp connection with start and end times, who
> started it, total bytes (in/out), etc.  Connections like ftp should
> also group their ftp-data sub-requests.  I'd also like to search for
> strings within connections.  Eventually, all this should go into a
> database.
> 
> Anyone else working on this?

It sounds useful, but I don't know if anybody's working on it.

> I see that there is a "conversation" structure.  Looks like I want to
> track a conversation for each TCP connection.  I think I'll try adding
> conversation_new() and conversation_find() to packet-tcp.c.  Does that
> sound good or crazy?

It sounds quite reasonable; it's something we probably want to do at
some point - it's a start towards a future project of doing TCP stream
reassembly, handling of higher-level "packets" that require more than
one link-layer frame, etc..

> How does one terminate a conversation?  I can't find anything like
> conversation_close().

There's currently no way to do that.

Note that terminating a conversation doesn't mean getting rid of it. 
State constructed by Ethereal in its first pass through all the packets
in a capture, when initially reading it, may well have to remain around
as long as the given capture file is open; if you need some state
information to dissect a packet, you need to associate that state
information with that packet, because that packet can be revisited an
arbitrary number of times (the user can click on it until their finger
gets tired, for example), and the revisits can occur in an arbitrary
order, so there's no guarantee that frame N+1 will be revisited
immediately after frame N is revisited.

Therefore, adding support for closing connections requires that
the data structure for a closed connection *not* go away.

This then raises the question of what happens if, later in the
conversation, another conversation between the same two endpoints
starts.  You'd now have two different conversation structures for the
same endpoint, so looking up a conversation based on the endpoint
identifiers would no longer be guaranteed to give the right answer.

That would require that, for any packet for which information associated
with a conversation is required in order to dissect the packet (for
example, any packet dissected with a particular dissector because that
packet is part of a conversation to which a particular dissector has
been attached; a number of the multimedia protocols require this), the
first pass through the capture file associate with that packet
per-packet state with the information in question - or associate with it
a pointer to the conversation data structure, which, for various
reasons, would probably work better - and, if the packet is re-visited,
the conversation to which the packet belongs be found by getting that
information from the per-packet data rather than by attempting to look
up the conversation based on the endpoint identifiers (IP addresses and
port numbers).

That's doable - and we probably want to do it eventually - but it may be
a non-trivial undertaking.