Wireshark-bugs: [Wireshark-bugs] [Bug 5121] Netflow parsing has a problem in sampler ID in case
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Wed, 10 Nov 2010 05:45:53 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5121

Andrew Feren <acferen@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |acferen@xxxxxxxxx

--- Comment #8 from Andrew Feren <acferen@xxxxxxxxx> 2010-11-10 05:45:36 PST ---
(In reply to comment #6)
> (In reply to comment #1)
> > In fact i just realized that length of sampler id is variable. it should be
> > taken care of accordingly.
> 
> RFC 3954 says "Sampler Id" is a fixed-length field of one byte for Netflow V9
> yet obviously the attachments show that for this capture the option template
> specifies a length of 2 for the SamplerID Option (48).
> 
> What type of device generated this capture ?
> 
> Do you have any documentation showing that 2 is a valid length for this field ?

I think wireshark should *always* use the length in the template for any field. 
This is part of rfc5101 at least for reducing the size of information elements.

"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."

The specific example in this bug gets larger, so maybe a warning should be
logged.  The problem is that if the data is actually encoded as 2 bytes
(despite what the standard says) any flows decoded using 1 byte will be
absolute junk.

The NetFlow collectors that I am familiar with are very forgiving about integer
sizes.  I believe some NetFlow exporters are looking at using the reduced
encoding with v9 too (haven't seen this in the wild yet).

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.