Wireshark-bugs: [Wireshark-bugs] [Bug 5121] Netflow parsing has a problem in sampler ID in case

Date: Wed, 10 Nov 2010 07:25:27 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5121

--- Comment #9 from Bill Meier <wmeier@xxxxxxxxxxx> 2010-11-10 10:25:24 EST ---
> 
> 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.
> 
> 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
>
> <...snip...>
> 
> 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).


OK: It's always nice to get input from someone with actual practical knowledge
of a protocol !    :)

My thoughts:

1. If any integer IE's are to be treated by Wireshark as potentially being of
   different lengths then a significant reworking of dissect_v9_v10_pdu_data()
   will be required.

   I could imagine some generic fcns to handle integer IEs (using
   proto_item_add_uint[64]) with a table-driven mechanism to provide info
   specific to each particular integer IE's (hf_... entry address,
   expected max length of field, etc).

   Also: presumably something similar for floats (altho I'd have to think about
   exactly what it means to represent a float in "fewer octets ...").

   Or: maybe a table-driven mechanism for all the IE's with generic fcns to
       handle the standard types (and with other fcns for the non-std types) ?

2. It would seem to me that IEs other than int, float, string, etc 
   (eg: IP addresses) should not allow any length in the template but should
   treat an unexpected length as an error.

In any case, this sounds like a nice project for someone.

As commented in a recent thread on Wireshark-dev

" ... is there work going on by someone already to re-do packet-netflow.c?  (it
could do with a re-write, starting with pulling v9/v10 out of it and into a
separate file) ..."

http://www.wireshark.org/lists/wireshark-dev/201011/msg00065.html

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