[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	8392
Summary	Use of read filter (-R) with Wireshark (or tshark along with the -2 option) presents inconsistent frame number references
Classification	Unclassified
Product	Wireshark
Version	1.9.x (Experimental)
Hardware	All
OS	All
Status	UNCONFIRMED
Severity	Major
Priority	Low
Component	Wireshark
Assignee	bugzilla-admin@wireshark.org
Reporter	jyoung@gsu.edu

Build Information:
TShark 1.9.1-SVN-47814 (SVN Rev 47814 from /trunk)

Copyright 1998-2013 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GLib 2.32.3, with libpcap, with libz 1.2.3, without
POSIX
capabilities, without libnl, with SMI 0.4.8, without c-ares, without ADNS, with
Lua 5.1, without Python, with GnuTLS 2.12.19, with Gcrypt 1.5.0, with MIT
Kerberos, with GeoIP.

Running on Mac OS X 10.6.8, build 10K549 (Darwin 10.8.0), with locale
en_US.UTF-8, with libpcap version 1.0.0, with libz 1.2.3.
Intel(R) Core(TM)2 Duo CPU     T9600  @ 2.80GHz

Built using gcc 4.2.1 (Apple Inc. build 5666) (dot 3).

--
While working on Bug 8344 I stumbled into some unintuitive and inconsistent
behavior with regards to the use of read filters with both Wireshark and
tshark.  I believe related issues were discussed but never resolved in Bug 380.

This problem is probably easier to demonstrate with several examples than to
try to describe.

Starting with a simple trace file containing 10 packets, 5 ICMP Echo (ping)
requests and their associated 5 ICMP Echo (ping) replies.

Example 1:  Default tshark output no read filters in place...

>bash-3.2$ ./tshark -r ten-frames.pcap 
>  1   0.000000 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=5/1280, ttl=64
>  2   0.002673 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=5/1280, ttl=60 (request in 1)
>  3   1.000119 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=6/1536, ttl=64
>  4   1.003350 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=6/1536, ttl=60 (request in 3)
>  5   2.000183 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=7/1792, ttl=64
>  6   2.002912 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=7/1792, ttl=60 (request in 5)
>  7   3.000309 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=8/2048, ttl=64
>  8   3.002857 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=8/2048, ttl=60 (request in 7)
>  9   4.000429 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=9/2304, ttl=64
> 10   4.003032 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=9/2304, ttl=60 (request in 9)
>bash-3.2$ 

Note that tshark's default single-pass analysis augments the ICMP Echo (ping)
reply packets's info column text with the frame number from which the matching
request was found: " (request in $FRAME)".

Example 2: tshark output with the -2 (two-pass) option and no read filter:

> bash-3.2$ ./tshark -r ten-frames.pcap -2
>   1   0.000000 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=5/1280, ttl=64 (reply in 2)
>   2   0.002673 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=5/1280, ttl=60 (request in 1)
>   3   1.000119 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=6/1536, ttl=64 (reply in 4)
>   4   1.003350 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=6/1536, ttl=60 (request in 3)
>   5   2.000183 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=7/1792, ttl=64 (reply in 6)
>   6   2.002912 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=7/1792, ttl=60 (request in 5)
>   7   3.000309 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=8/2048, ttl=64 (reply in 8)
>   8   3.002857 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=8/2048, ttl=60 (request in 7)
>   9   4.000429 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=9/2304, ttl=64 (reply in 10)
>  10   4.003032 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=9/2304, ttl=60 (request in 9)
> bash-3.2$ 

With tshark's two-pass analysis enabled (the -2 option) the Info column text
for the ICMP Echo (ping) request packets are augmented to indicate the frame
number of the matching reply.   

NOTE: This augmented info column output is typical of the packet list Info
column text one would see when opening the sample trace file inside of
Wireshark.

> bash-3.2$ ./wireshark -r ten-frames.pcap

Example 3: Single-pass tshark with a read filter (-R) in place:

> bash-3.2$ ./tshark -r ten-frames.pcap -R 'ip.src=""
>   1   0.000000 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=5/1280, ttl=64
>   3   1.000119 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=6/1536, ttl=64
>   5   2.000183 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=7/1792, ttl=64
>   7   3.000309 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=8/2048, ttl=64
>   9   4.000429 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=9/2304, ttl=64
> bash-3.2$ 

Note that only the odd frame numbers passed the read filter (frames 1, 3, 5, 7
and 9).

Example 4: Single-pass tshark with a different read filter (-R) in place:

> bash-3.2$ ./tshark -r ten-frames.pcap -R 'ip.dst==192.168.0.10'
>   2   0.002673 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=5/1280, ttl=60 (request in 1)
>   4   1.003350 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=6/1536, ttl=60 (request in 3)
>   6   2.002912 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=7/1792, ttl=60 (request in 5)
>   8   3.002857 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=8/2048, ttl=60 (request in 7)
>  10   4.003032 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=9/2304, ttl=60 (request in 9)
> bash-3.2$ 

Note that in this example only the even frame numbers passed the read filter
(frames 2, 4, 6, 8 and 10).  The augmented Info column text " (request in
$FRAME)" refers to the correct undisplayed frame number.

Example 5: Two-pass (-2) tshark with a read filter (-R) in place:

> bash-3.2$ ./tshark -r ten-frames.pcap -R 'ip.src="" -2 
>   1   0.000000 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=5/1280, ttl=64 (reply in 2)
>   2   1.000119 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=6/1536, ttl=64 (reply in 3)
>   3   2.000183 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=7/1792, ttl=64 (reply in 4)
>   4   3.000309 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=8/2048, ttl=64 (reply in 5)
>   5   4.000429 192.168.0.10 -> 192.168.0.99 ICMP 98 Echo (ping) request  id=0xf61a, seq=9/2304, ttl=64 (reply in 6)
> bash-3.2$ 

With the two-pass option enabled and a concurrent read filter the frame numbers
are no longer consistent with the trace file nor is the augmented Info column
text correct (the "(reply in $FRAME)" refer to the wrong frame numbers) .

Wireshark launched with effectively the same parameters as tshark Example 5
results in identical packet list output:

> bash-3.2$ ./wireshark -r ten-frames.pcap -R 'ip.src="" & 

Example 6: Two-pass tshark with a different read filter (-R) in place:

> bash-3.2$ ./tshark -r ten-frames.pcap -R 'ip.dst==192.168.0.10' -2 
>   1   0.002673 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=5/1280, ttl=60 (request in 1)
>   2   1.003350 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=6/1536, ttl=60 (request in 2)
>   3   2.002912 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=7/1792, ttl=60 (request in 3)
>   4   3.002857 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=8/2048, ttl=60 (request in 4)
>   5   4.003032 192.168.0.99 -> 192.168.0.10 ICMP 98 Echo (ping) reply    id=0xf61a, seq=9/2304, ttl=60 (request in 5)
> bash-3.2$ 

Like in example 5 the frame numbers are not consistent with the original trace
file and more confusing the augmented Info comments indicate that the request
is in the same packet as the reply!

Wireshark when launched with effectively the same parameters as tshark Example
6 results in identical packet list display.

> bash-3.2$ ./wireshark -r ten-frames.pcap -R 'ip.dst==192.168.0.10' & 

In the Wireshark cases reloading the capture file with the the View | Reload
menu option (or the ^R key accelerator) will cause all 10 frames to be
displayed.

Wireshark's Open Capture File dialog also allows one to supply a Filter when
opening an existing capture file.  When a "Filter:" value is supplied in
Wireshark's Open Capture File then Wireshark behaves like the read filter
examples above with one difference; the supplied read filter is now displayed
in Wireshark's Main display filter field, but this new filter is not actually
applied as as the display filter.   This means that if one chooses to reload
the currently open capture file (File | Reload or ^R) the entire trace file
will be displayed and not the filtered one implied by the contents of the
display filter. 

More confusing is that if there was an active display filter in place before
using the Open Capture Filter with a read filter then the previously applied
display filter will still be active although the display filter field will be
updated to display the contents read filter.

Obviously there are a number of usability issues with the current behavior of
conflating read filters with display filters.  

Should Wireshark/tshark's read filter behavior be modified such when used it
would result in output and behavior that is consistent with first opening a
capture file and then applying a display filter?

Or should read filters behave as if the excluded packets do not even exist in
the supplied capture file and consequently all frame number references in
conversations be adjusted to reference virtual frame numbers consistent with
the applied read filter?

---

      You are receiving this mail because:

• You are watching all bug changes.