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.
