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 _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
