Re: Netflow dissector bug-to-be

[Hadriel Kaplan <HKaplan () acmepacket com>]

On Nov 7, 2010, at 12:51 PM, Bill Meier wrote:

> 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);
>               ...
>               }

Yup, another bug.

> Is this a bug ? Are Enterprise Numbers greater that 16 bits allowed ? 
> (It would seem so).

Yup, enterprise numbers are 32 bits.

> In practical terms: Are there currently values > 16 bits ?

No, the current greatest high IANA has is 36840.  But it's been growing (they're free after all :)


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

Huh.  I tried that and you're right it does - why?  


> Maybe a slightly better fix might be to have a separate function  to 
> handle the pen_type for each different Enterprise Number (even if 
> there's some duplication).

That's what my code does right now - I would submit it, but it's only a temporary situation for showcasing an IETF 
draft at this week's IETF meeting, using a research Enterprise number because this is still a draft.  If the draft gets 
adopted then IANA will assign real ipfix IE numbers for the fields and it won't use an Enterprise Number.

I think the "right" thing to do (or at least "ambitious" thing) would be not to have vendor-specific Netflow fields 
using private enterprise numbers written in static code to begin with, but rather loaded from dictionary files like 
RADIUS and DIAMETER dissectors do.  Netflow's model for this is effectively the same concept as RADIUS VSAs, DIAMETER 
vendor AVPs, and SNMP OIDs.  There are already a bunch of vendor-specific Netflow v9 fields being used which aren't in 
the dissector code, and making code changes for each one as they're encountered will be annoying.  I'm hoping to make 
that change to Netflow's dissector as soon as I get some free time. :)

-hadriel

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe