Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 12283] New: RPC/NFS incorrectly decodes when port <1024

[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	12283
Summary	RPC/NFS incorrectly decodes when port <1024
Product	Wireshark
Version	2.0.1
Hardware	x86
OS	All
Status	UNCONFIRMED
Severity	Major
Priority	Low
Component	Dissection engine (libwireshark)
Assignee	bugzilla-admin@wireshark.org
Reporter	jamie.bainbridge@gmail.com

Build Information:
$ tshark -v
TShark (Wireshark) 2.0.1 (SVN Rev Unknown from unknown)

Copyright 1998-2015 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
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 libpcap, with POSIX capabilities (Linux), without libnl,
with libz 1.2.7, with GLib 2.42.2, with SMI 0.4.8, with c-ares 1.10.0, without
Lua, with GnuTLS 3.3.8, with Gcrypt 1.5.3, with MIT Kerberos, without GeoIP.

Running on Linux 3.10.0-327.10.1.el7.x86_64, with locale en_AU.utf8, with
libpcap version 1.5.3, with libz 1.2.7, with GnuTLS 3.3.8, with Gcrypt 1.5.3.
Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz (with SSE4.2)

Built using gcc 4.8.5 20150623 (Red Hat 4.8.5-4).

--
We've got a packet capture of NFS where the NFS Client has used port 995
talking to port 2049, so Wireshark has incorrectly decided this is SSL traffic:

 $ tshark -n -r tcpdump.pcap -Y "frame.number == 35"
 35   1.001630 172.0.0.224 -> 10.0.0.198 SSL 4298 Continuation Data

 $ tshark -n -r tcpdump.pcap -d tcp.port==995,rpc -Y "frame.number == 35"
 35   1.001630 10.0.0.224 -> 10.0.0.198 NFS 4298 V3 WRITE Call, FH: 0x7d001ec8
Offset: 9279881216 Len: 4096 FILE_SYNC

 $ egrep " 995\/tcp" /etc/services
pop3s           995/tcp                         # POP-3 over SSL

This could be fixed in the SSL dissector, like the ACAP fix in Bug 12265,
however I'm concerned that this is the wrong way to go about this.

This never used to happen in Wireshark 1.x. The NFS Client intentionally uses
ports under 1024, and it seems some heuristic has changed in Wireshark 2.0 to
prevent traffic between (<1024) and 2049 from being recognised as RPC/NFS. We
could potentially be fixing 1024 small dissector bugs to ensure NFS is always
decoded correctly.

Has something changed in the RPC/NFS dissector to make it less likely to claim
traffic to port 2049? Or have dissector heuristic improvements in Wireshark 2
exposed dissector bugs which were not obvious in Wireshark 1?

If the latter, please consider this a bug report against the SSL dissector.

I apologise I cannot supply the packet capture file.

---

      You are receiving this mail because:

• You are watching all bug changes.