Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 380] "wireshark -R" doesn't support 'frame.number' as a read filter

[bugzilla-daemon@xxxxxxxxxxxxx]

http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=380


jeff.morriss@xxxxxxxxxxx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX
            Summary|"wireshark -R" doesn't      |"wireshark -R" doesn't
                   |support 'frame.*' selectors |support 'frame.number' as a
                   |                            |read filter




------- Comment #5 from jeff.morriss@xxxxxxxxxxx  2007-03-17 06:36 GMT -------
My last attempt to fix this was to add a field in the 'capture_file' structure
named "read_count": this is a count of the number of frames in the file,
regardless of whether they pass the read filter (if any) or not.  Then we set
the frame number of all frames to be "read_count" (frames in file) rather
than "count" (frames that passed the read filter).

This fixes both (1) and (2) (the latter by showing you the real frame number in
the file).

Unfortunately it breaks some assumptions in the rest of Wireshark (the one I
found was the Save dialog) that if there's no display filter then the frame
numbers will be sequential.  In my opinion the rest of the code's assumption is
valid even though it makes this problem impossible to fix.  And, of course,
finding all the places where that assumption is made would be a challenge.

At this point I don't think it's worth spending more time to try to fix this
(quite limited) bug.  (I've also updated the Summary to show that it's only
"frame.number" that is affected by this.)


-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.