Wireshark-dev: Re: [Wireshark-dev] tshark: drop features "dump to stdout" and "read filter" - c
From: Richard van der Hoff <[email protected]>
Date: Wed, 10 Oct 2007 01:38:04 +0100
Ulf Lamping wrote:
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.
Of course; that's fair enough! I didn't mean to imply by anything I said 
that you should be responsible for any more work here - as I said, I 
think the work you've already done is excellent. I only wanted to 
understand if you thought there were intractable issues here.
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.
Yup; fair enough. A temporary file, with a ringbuffer for long-running 
captures, is a good solution.
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.
Yeah - the problem here is that of tshark passing the filename straight 
down: thus breaking both read filters and writing to stdout.
It's no vodoo magic to make it work again, but someone (but not me) has to made the changes.
Sure. I'll have a look at this in the next week or so if someone else 
doesn't beat me to it.
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".
Yup: it's fair that they are "gone forever" from dumpcap, but not so 
much that they are gone from tshark.
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.
Agreed.

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 ...
Basically, I think this is an important enough feature that it shouldn't 
be thrown away. I /hope/ to have the time to update it myself...
Cheers

Rich