Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 8846] New: MUL_DPKTS decode for netflow needs 64 bit option

[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	8846
Summary	MUL_DPKTS decode for netflow needs 64 bit option
Classification	Unclassified
Product	Wireshark
Version	unspecified
Hardware	x86
OS	All
Status	UNCONFIRMED
Severity	Major
Priority	Low
Component	Dissection engine (libwireshark)
Assignee	bugzilla-admin@wireshark.org
Reporter	acferen@yahoo.com

Build Information:
wireshark 1.11.0 (SVN Rev 50139 from /trunk)

Copyright 1998-2013 Gerald Combs <gerald@wireshark.org> 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.17, with Cairo 1.12.14, with Pango 1.32.5,
with
GLib 2.36.0, with libpcap, with libz 1.2.7, without POSIX capabilities, without
libnl, without SMI, without c-ares, without ADNS, without Lua, without Python,
without GnuTLS, without Gcrypt, without Kerberos, without GeoIP, without
PortAudio, with AirPcap.

Running on Linux 3.8.0-25-generic, with locale en_US.UTF-8, with libpcap
version
1.3.0, with libz 1.2.7, without AirPcap.
       Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz

Built using gcc 4.7.3.

--
The problem is actually a bit more general than my summary, but it was a
capture with MUL_DPKTS that tripped me up today.

The problem is that in NetFlow v9 / IPFIX  values can be sent using "reduced
size encoding".  This means that the size specified for each element (see
http://www.iana.org/assignments/ipfix/ipfix.xml) is really just an upper bound. 

>From RFC5101:
6.2.  Reduced Size Encoding of Integer and Float Types

   Information Elements containing integer, string, float, and
   octetarray types in the information model MAY be encoded using fewer
   octets than those implied by their type in the information model
   definition [RFC5102], based on the assumption that the smaller size
   is sufficient to carry any value the Exporter may need to deliver.
   This reduces the network bandwidth requirement between the Exporter
   and the Collector.  Note that the Information Element definitions
   [RFC5102] will always define the maximum encoding size.

   For instance, the information model [RFC5102] defines byteCount as an
   unsigned64 type, which would require 64 bits.  However, if the
   Exporter will never locally encounter the need to send a value larger
   than 4294967295, it may chose to send the value instead as an
   unsigned32.  For example, a core router would require an unsigned64
   byteCount, while an unsigned32 might be sufficient for an access
   router.


MUL_DPKTS (aka postMCastPacketDeltaCount), for example, is specified as
unsigned64.  There for it can, however, be encoded as any  unsigned8,
unsigned16, unsigned24, ... unsigned64.

The way this has been handled in the decodes so far is to create 2 hf_ entries
(32 and 64) for each information element that someone trips over with a reduced
size encoding.

This results in code like the following scattered everywhere

        case 1: /* bytes */
            if (length == 4) {
                ti = proto_tree_add_item(pdutree, hf_cflow_octets,
                                         tvb, offset, length, ENC_BIG_ENDIAN);
            } else if (length == 8) {
                ti = proto_tree_add_item(pdutree, hf_cflow_octets64,
                                         tvb, offset, length, ENC_BIG_ENDIAN);
            } else {
                ti = proto_tree_add_text(pdutree,
                                         tvb, offset, length,
                                         "Octets: length %u", length);
            }
            break;

It seems there ought to be a way to more generally decode an integer for any
length 1 .. 8.  Probably there is.  Suggestions welcome.  Meanwhile I'm off to
read the documentation.

---

      You are receiving this mail because:

• You are watching all bug changes.