Understanding two pass analysis with tshark

Question

I am trying to understand 2 pass analysis with tshark using the latest 1.10.2 (TShark 1.10.2 (SVN Rev 51377 from /trunk-1.10))

The first example starts with a single pass. I use the "-c 1" option to only display a single packet. I am also using a display filter to see packets with frame numbers > 1. The result makes sense. I see frame #2.

[email protected]:~/lab2/wireshark-1.10-trunk$ ./tshark -r dns.cap -c 1 -Y "frame.number>1"
  2   0.000269   172.16.1.1 -> 172.16.1.198 DNS 84 Standard query response 0xc576  A 10.0.0.101

However, once I switch this to a two pass using "-2", I don't see any packets displayed.

[email protected]:~/lab2/wireshark-1.10-trunk$ ./tshark -r dns.cap -2 -c 1 -Y "frame.number>1"
[email protected]:~/lab2/wireshark-1.10-trunk$

I would not expect the results to change when I switch to a two pass decode. I suspect this is a bug, but I want to confirm the expected behavior.

Accepted Answer

AFAICT (without looking at the source code), both '-c' and '-R' work on the first pass. During the first pass all packets are read and full dissection is done to calculate all the fields. Only frames that pass the filter in the '-R' option will be kept for the second pass. When the amount of packets that pass the filter in the '-R' option reach the number in the '-c' option, reading of the capture file is stopped.

Then on the second pass, only packets that matched the first pass are examined (with their full dissection intact) and matched against the filter in the '-Y' option. Matching packets will be printed.

It looks like frame numbers are re-calculated on the second run:

[email protected]:~$ tshark -r ~/Wireshark/pcap/http.cap -c 2 -Y 'tcp.len>0'
  4   0.056589 192.168.1.43 -> 66.102.13.103 HTTP 715 GET / HTTP/1.1 
  6   0.122335 66.102.13.103 -> 192.168.1.43 TCP 1278 [TCP segment of a reassembled PDU]
[email protected]:~$ tshark -r ~/Wireshark/pcap/http.cap -c 2 -2 -Y 'tcp.len>0'
[email protected]:~$ tshark -r ~/Wireshark/pcap/http.cap -c 2 -2 -R 'tcp.len>0' -Y 'tcp.len>0'
  1   0.056589 192.168.1.43 -> 66.102.13.103 HTTP 715 GET / HTTP/1.1 
  2   0.122335 66.102.13.103 -> 192.168.1.43 TCP 1278 [TCP segment of a reassembled PDU]
[email protected]:~$

Which I would consider a bug. Could you file a bug report on https://bugs.wireshark.org with a link to this question?