Created attachment 10477 [details]
pcapng file to test icmp.resp_in bug
Build Information:
tshark:
TShark 1.8.6 (SVN Rev 48142 from /trunk-1.8)
Compiled (64-bit) with GLib 2.34.1, with WinPcap (4_1_2), with libz 1.2.5,
without POSIX capabilities, with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1,
without Python, with GnuTLS 2.12.18, with Gcrypt 1.4.6, without Kerberos, with
GeoIP.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch
1_0_rel0b (20091008).
Built using Microsoft Visual C++ 10.0 build 40219
Wireshark:
Version 1.8.6 (SVN Rev 48142 from /trunk-1.8)
Compiled (64-bit) with GTK+ 2.24.14, with Cairo 1.10.2, with Pango 1.30.1, with
GLib 2.34.1, with WinPcap (4_1_2), with libz 1.2.5, without POSIX capabilities,
with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS
2.12.18, with Gcrypt 1.4.6, without Kerberos, with GeoIP, with PortAudio
V19-devel (built Mar 6 2013), with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.
Built using Microsoft Visual C++ 10.0 build 40219
--
tshark does not decode the field "icmp.resp_in" correctly, while Wireshark
does.
Reproduce:
Load the attached pcapng file to Wireshark.
Apply display filter "icmp.resp_in".
The display shows frames 1, 3, 5, 8, which is correct.
Adding the field "icmp.resp_in" to the columns displays the correct values.
Now do the same from tshark:
tshark -r bug_icmp_resp_in.pcapng -R "icmp.resp_in"
There is no output, which is incorrect. I expect the same output as with
Wireshark.
And:
tshark -r bug_icmp_resp_in.pcapng -T fields -e "icmp.resp_in"
also yields no output, which is incorrect. I expect the same output as with
Wireshark.
Request:
Please fix the decoding of "icmp.resp_in" field in tshark both for using it as
a filter as well as using it to print out the values.
Other observations:
The "icmp.resp_to" works correct for tshark both for filter and field
print-out. To me it looks like icmp.resp_to works as it looks in the past,
while icmp.resp_in has to look in the future, which seems to be implemented in
Wireshark decoding but not tshark decoding. To me this is strange, as I would
expect that Wireshark and tshark use the same decoding engine.
Adding "-2" option to tshark to enable it to look into future by running
2-step-analysis does not make a difference.
Testing with experimental TShark 1.9.1 (SVN Rev 48270 from /trunk) does not
make a difference.