Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 8529] New: tshark does not decode field icmp.resp_in while Wireshark does

[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	8529
Summary	tshark does not decode field icmp.resp_in while Wireshark does
Classification	Unclassified
Product	Wireshark
Version	1.8.6
Hardware	x86-64
OS	Windows 7
Status	UNCONFIRMED
Severity	Normal
Priority	Low
Component	TShark
Assignee	bugzilla-admin@wireshark.org
Reporter	carsten.langer@gmx.de

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.

---

      You are receiving this mail because:

• You are watching all bug changes.