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.
