Hi!
As there were some almost identical mails about that topic, I'll respond
to all of them here.
While some things are technical not possible (or just not a good idea),
others simply require further development that I don't have the time /
motivation to do in the foreseeable future. Please keep in mind that I
don't use tshark myself! I made sure that the current limitations are a
result of the privilege seperation changes itself and not just of plain
implementation bugs. So tshark now works as *expected*, but probably not
as *desired* as the mail responses showed.
However, if noone is going to solve the current situation, tshark will
keep the limitations that it currently has - I don't plan to spend any
more effort on this topic ... if someone is seriously going to improve
the current situation, I'm really willing to explain devel things, but
not on the current level of discussion.
WHY NOT SIMPLY USE A PIPE BETWEEN DUMPCAP AND TSHARK?
Because it just won't work.
Sending everything through a pipe is not a portability issue, but has a
different problem: pipes are pretty limited in the amount of bytes they
can store. If there's a network burst coming in and dumpcap pushes the
packets into the pipe very fast, the receiving side of the pipe probably
can't process the packets in the required very, very short time (which
is *very* likely), packet loss is the result.
The "temporary file model" is working in Wiresharks "update list of
packets" mode for quite a while and is working ok.
So simply using a pipe is not an option here. Of course, there are other
possible solutions, like using a large amount of shared memory, but this
also has it's issues and someone has to implement it.
WHY IS STDOUT NOT POSSIBLE?
Well, it's possible but just not implemented.
The current implementation simply passes the filename from tshark to
dumpcap, which then will mess up it's own stdout with the event messages
and packet data.
It's no vodoo magic to make it work again, but someone (but not me) has
to made the changes.
BUT READ FILTERS SHOULDN'T BE A PROBLEM?
Not in the sense of a read filter - as before. The read filter "deletes"
the packets before they are written to disk. As dumpcap doesn't know
about read filters it will write all packets to disk, so this feature is
"gone forever".
However, if someone implements stdout for tshark (as mentioned above),
there is a workaround for this. For capturing, you'll use ringbuffer
files to keep the size of files to a reasonable size. Now you can use
tshark read filters (as before) to "stdout" only the packets you're
interested in.
Again, I'm not a tshark expert. To be honest, I'm tired to support stuff
that I'm not interested in. So if you want to see any improvements here,
you might need to do it yourself ...
Regards, ULFL
