| 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 |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
$ tshark -v
TShark (Wireshark) 2.0.1 (SVN Rev Unknown from unknown)
Copyright 1998-2015 Gerald Combs <[email protected]> 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.
