[bugzilla-daemon@xxxxxxxxxxxxx]

Hadriel Kaplan changed bug 8316

What	Removed	Added
CC		hadrielk@yahoo.com

Comment # 4 on bug 8316 from Hadriel Kaplan

Fixing this would change something else though that might be important: with a
two-pass analysis, tshark's output always shows frame numbers sequentially
starting at 1.  Even if there's a read filter that skips some number of initial
frames, the ones that pass the filter are numbered as 1,2,3, etc.  Wireshark
has that exact same behavior.

That might be what people expect, because this is a *read* filter not a display
filter technically.  So it's as if tshark/wireshark never saw the unmatched
frames to begin with, and thus the matching ones start as being frame #1,2,3,
etc.

But that's why the bug exists: it's impossible for a frame in the file to be
frame.number == 2 (or > 1), because there's never a frame #1 which matches such
a filter for there to be a frame #2 to match the filter.  It's like asking for
a filter of "frame.number == 0" (or < 1).

---

      You are receiving this mail because:

• You are watching all bug changes.