I agree that the hex decoding is a bit strange: I still didn't find the right way to do it.
So submitted the patch again, this time without the hex decoding stuff.
I also fixed the code so that it differs less from the original.
Now is it possible to apply the patch?
There are other fixes needed to packet-netflow.c (like IPFIX variable-length fields).
with regards,
Olivier Montanuy
>From: Jaap Keuter <jaap.keuter@xxxxxxxxx
><mailto:[email protected]> >
>Date: Fri, 27 Apr 2007 21:53:31 +0200 (CEST)
>Hi,
>Patch looks good, not too sure about the to_hexadecimal though.
>Thanx,
>Jaap
>On Fri, 27 Apr 2007, Olivier MONTANUY wrote:
>> Hello,
>>
>> I opened a a bug report #1579 to signal that
>> epan/dissectors/packet-netflow.c currently cannot decode Netflow options, because it does not take into account the option scope.
>>
>> Netflow options provide information that are needed to interpret the
>> Netflow records, like the ifName, ifDescr and sampling rate for an ifIndex, or the IP prefix for a MPLS label.
>>
>> So I added to the bug report a patch that:
>> - decodes the option scope, for Data FlowSet containing option.
>> - decodes of about 40 new Netflow types, some of which are undocumented but
>> used by Cisco Flexible Netflow.
>> - display the unknown netflow type in hexadecimal, so to help deal with
>> future Netflow v9 implementations, especially in tshark.
>> - display the header of the netflow packet even when the PDU count is zero,
>> as this does happen in practice.
>>
>> The patch was tested it using traces generated by Cisco IOS 12.0 and
>> 12.4, IOS-XR 3.3, Juniper JUNOS 7 and 8, and Huawei VRP 5.30.
>>
>> I hope someone can apply this patch, since I have no idea how it is supposed to be done.
>>
>> Thanks in advance,
>>
>> Olivier Montanuy
>>