Wireshark-dev: Re: [Wireshark-dev] Netflow dissector bug-to-be
From: Gerald Combs <gerald@xxxxxxxxxxxxx>
Date: Sun, 07 Nov 2010 12:35:12 -0600
Bill Meier wrote:
> On 11/7/2010 10:46 AM, Hadriel Kaplan wrote:
>> Howdy, The current packet-netflow.c dissector has a big "switch
>> (pen_type) {...}" block in dissect_v9_v10_pdu_data(), which looks up
>> specific known netflow/ipfix fields as it walks netflow v9/10 PDUs.
>>
>> Unfortunately, it's a bit of a hack as pen_type is a guint64 and a
>> switch statement will silently cast it to an int.  I say
>> "unfortunately", because I discovered to my chagrin that it's a
>> *signed* int, so any case statement can't use a constant greater than
>> 0x7fffffff, which given how the current code works, means one can't
>> have a Private Enterprise Number greater than 0x7fff and use it to
>> define a known field in this code.  As it turns out, my Enterprise
>> number is higher than that. (Cace Technology's is just under it,
>> which is why the current code works for Cace's netflow fields)
>>
> 
> Looking at the code a bit I see that currently "pen"
> seems to be effectively limited to 16 bits even though 32 bits are 
> fetched from the tvbuff:
> 
> dissect_v9_v10_template_fields(...) {
>          ...
> 	guint16      pen;
> 	...
> 	if ((ver == 10) && (type & 0x8000)) {  /* IPFIX only */
> 		pen = tvb_get_ntohl(tvb,offset+4);
> 		...
> 		}
> 
> Is this a bug ? Are Enterprise Numbers greater that 16 bits allowed ? 
> (It would seem so).
>
> In practical terms: Are there currently values > 16 bits ?
> 
> If not, one hack might be to define pen_type in 
> dissect_v9_v10_pdu_data() as guint32 which gets around the "silent cast" 
> issue for the moment.

RFC 5101 section 3.2 says they're 32 bits. I've checked in a change to
reflect this.