On Dec 18, 2013, at 4:46 AM, Matthias Lang <wireshark@xxxxxxxxxxxxxxxxxxxx> wrote:
> 1. The manpage (tshark.pod) for 'tshark' says reading from stdin isn't
> allowed. But it actually works fine. Manpage says:
>
> | =item -r E<lt>infileE<gt>
> |
> | Read packet data from I<infile>, can be any supported capture file format
> | (including gzipped files). It's B<not> possible to use named pipes
> | or stdin here!
>
> Here's what happens, i.e. it works just fine:
That text might have been historically correct; some changes have been made to libwiretap to attempt to make it work, at least with some capture file formats:
r43102 | guy | 2012-06-05 00:24:17 -0700 (Tue, 05 Jun 2012) | 9 lines
From Jakub Zawadzki: when seeking backwards, if the seek will put you at
a position that's in our data buffer, just reposition within the
buffer, don't do any seeks or I/O on the underlying file. This lets us
do some backwards seeking on a pipe, to allow the rewind-and-try scheme
we use to try to identify capture file types to work, at least for some
capture file formats (those that have magic numbers at the beginning or
have heuristics that don't require much data), on pipes, allowing, for
example, TShark to read those formats from a pipe.
but, as the comment suggests, if more data than fits in the data buffer is read by a file open routine that's called before the routine that recognizes the file's type, this will *not* work if the file is being read from a pipe.
Fortunately, both pcap and pcap-ng formats have magic numbers near the beginning, and their open routines are called before other ones (as they're the native formats for Wireshark), so reading pcap or pcap-ng files from a pipe will probably work (although the pcap file reader does some additional reading to try to handle some non-standard pcap formats, and if *that* reads more than will fit in a buffer, the pcap-ng reader won't get to read the file as the seek-to-the-beginning will fail on a pipe).
So it's more like "it might, or might not, be possible to read from a pipe here, depending on the file type and the contents of the file".
> 2. tshark.pod says
>
> | B<TShark>'s native capture file format is B<pcap> format
>
> It might help someone if it said "B<Pcap-NG>". I'm not sure if
> Pcap-NG is considered a separate format or a new version. It feels
> like a separate format to me since it's totally incompatible.
It's a separate format. TShark doesn't have the equivalent of dumpcap's -P flag to tell it to use pcap rather than pcap-ng, so (at least until such an option is added) it's probably best to say its native format is pcap-ng.
