On Dec 18, 2013, at 4:46 AM, Matthias Lang <wiresh...@matthias.fastmail.fm>
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.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
