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
