Wireshark-bugs: [Wireshark-bugs] [Bug 5121] Netflow parsing has a problem in sampler ID in case
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.
