Wireshark-dev: Re: [Wireshark-dev] tshark: drop features "dump to stdout" and "read filter" - c
From: Ulf Lamping <[email protected]>
Date: Tue, 09 Oct 2007 22:17:17 +0200
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