A fairly simple tcp flow demultiplexer.

Invoke it as ``cat file_list | demuxer <optional pcap filter>'', where
<optional pcap filter> is some libpcap format filter expression.  Note
that files are processed in the order in which they are presented.

e.g. ``echo * | demuxer'' will demux all of the files in the current
directory.  ``echo * | demuxer 'host 128.232.9.79''' will do the same,
but only consider stuff going to or from 128.232.9.79.

The main use for this is dividing up large runs into smaller ones
e.g. on the first run, you say
``demuxer '( source 0.0.0.0/1 and dest 0.0.0.0/1)' '', then
``demuxer '( source 128.0.0.0/1 and dest 128.0.0.0/1)' '', then
``demuxer '( source 128.0.0.0/1 and dest 0.0.0.0/1 ) or ( source 0.0.0.0/1 and dest 128.0.0.0/1 ) ' ''.
Rather than having one big demux run, which may tax the memory available
on the system doing it, you have three big ones.

Designing the filter expressions requires some care.  You need to
ensure that every packet matches precisely one filter, and that if one
packet in a tcp connection matches a particular filter then every
other one must match as well.  There is no error checking here,
either, so if you try to be clever it's easy to get completely bogus
results.

Output goes into the out directory, with one file for every flow.
Filenames have one of two formats:

protocol/hosta/porta/hostb/portb/start_timestamp

or

protocol/hosta/hostb/start_timestamp

depending on whether we know enough about the protocol to extract port
numbers.  Note that A and B are only loosely related to server and
client.

We also output a file ``senses'' in the current directory, which
specifies whether each flow is client/server or server/client, when
the protocol is TCP (6).  In a normal trace, most flows are likely to
be server/client because of the way A and B are assigned to the actual
endpoints, with the main exception being FTP data, which is usually
client/server.  In some cases, we'll fail to determine which direction
is which (e.g. if a flow starts before the trace does and we miss the
setup).  In that case, the sense is marked as unknown.

After a run, ``logfile'' contains everything which the program sent to
stdout.  ``file_log'' is primarily a debug aid; it describes what the
file descriptor managing code was doing throughout the run.
