| Bug ID |
8918
|
| Summary |
incorrect parsing of IPFIX *IpTotalLength elements
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.6.7
|
| Hardware |
All
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
$ wireshark -v
wireshark 1.6.7
Copyright 1998-2012 Gerald Combs <[email protected]> and contributors.
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 GTK+ 2.24.10, with GLib 2.32.0, with libpcap (version
unknown), with libz 1.2.3.4, with POSIX capabilities (Linux), without libpcre,
with SMI 0.4.8, with c-ares 1.7.5, with Lua 5.1, without Python, with GnuTLS
2.12.14, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP, with PortAudio
V19-devel (built Dec 10 2011 11:43:10), without AirPcap.
Running on Linux 3.2.0-26-generic, with libpcap version 1.1.1, with libz
1.2.3.4, GnuTLS 2.12.14, Gcrypt 1.5.0.
Built using gcc 4.6.3.
--
Wireshark parses IPFIX standard elements 25 and 26 (minimumIpTotalLength and
maximumIpTotalLength) like in Netflow 9 (MIN_PKT_LNGTH and MAX_PKT_LNGTH).
However, they are unsigned 64-bit in IPFIX and 16-bit in Netflow, so Wireshark
fails parsing them in IPFIX packets.
http://tools.ietf.org/html/rfc5102#section-5.8.1
You are receiving this mail because:
- You are watching all bug changes.
