Evan Huus <eapache@...> writes:
> This is getting complicated. A few points in no particular order:
>
> === tshark default behaviour ===
>
> We can't make -2 the default for tshark doing live capture, as that
> would require us to buffer all output until the capture is finished,
> which isn't very helpful. We might want to make it default when
> reading from a file, but then the two cases will behave subtly
> differently and there's a possibility for people to become confused.
I was of course thinking of reading from a file and not a live capture. A live
capture is what it is.
> This raises the question of where we want our consistency - do we want
> tshark internally consistent by default (in which case we should keep
> -2 as an option) or do we want tshark to be as-consistent-as-possible
> with wireshark, even if we can't quite achieve all cases (in which
> case -2 should be the default except when doing a live capture).
To me, I think the 2-pass output is probably what is more useful to most people
when reading from a file, that's all. So do we want something that is likely to
be generally more useful at the expense of some inconsistency or is consistency
more important?
> === filtering ===
>
> I *really* do not like the renumbering of frames that the read filters
> currently do (-R in wireshark, -2R in tshark). I find it confusing and
> not useful entirely apart from the fact that there is no graceful way
> for it to handle reassembly dependencies (see my "frame 1 depends on
> frames 1 and 1" example earlier). Does anybody know why it was added
> in the first place? It seems to me that it adds very little that was
> not already available by using a regular display filter and saving the
> results to a new file.
I don't know why/when it was added and unfortunately the ethereal website is no
longer useful. But I suppose if you didn't want to save multiple pcap files, or
possibly couldn't save multiple pcap files for whatever reason (think small
embedded devices with limited space or available inodes, which is a real problem
I ran into once, not for pcap files specifically but for trying to store other
files). And of course, using a read filter will reduce the memory footprint, so
that is also a reason that might be important to some people.
I think of a file loaded into Wireshark with a read filter applied as being a
completely new file, which of course is just a subset of the original file, so
to me, the renumbering makes perfect sense. With that in mind, then for tshark,
I think the frames should actually be renumbered regardless of 1-pass or 2-pass.
The problem seems to be that tshark's -R doubles as both a read filter and as a
display filter. What tshark needs, and what would generally be more useful I
think, would be a display filter option. Then the problem of not being able to
reassemble packets because the frames aren't available goes away. I mean if the
user chooses a read filter, then only those frames that match the filter can be
used for reassembly and if there are frames missing, then it's up to the user to
specify a better read filter. Or just use a display filter instead, in which
case all frames from the original file are available and reassembly can be
performed. A read filter could still be applied though.
> === proposal ===
>
> - Scrap "-R" and read filters entirely, making the requisite changes
> to the GUI so that the file->open filter behaves as Hadriel suggested
> (basically just a proxy for the regular display filter field).
I have no special attachment to read filters, so I'm not against this per se,
but I'm not sure about eliminating it, at least not without some feedback from
some tshark power users.
> - Synchronize on -f for libpcap filters and -d for wireshark filters
> - Tshark only does one pass by default in all cases (so it's
> internally consistent). Keep -2 for two-pass analysis, but *never*
> renumber frames.
Personally, I think the most usable option should be the default behavior.
And if read filters are removed, then frames would not be renumbered. If read
filters are retained and applied, then frames should always be renumbered, in my
opinion.