This is in reality a followup of a thread from January 2018:
https://sourceforge.net/p/nfdump/mailman/message/36174318/
where I had IPFIX export from a Huawei router which was printed
with a start time of 1. January 1970 due to missing information
in the export from the router. Specifically, quoting from the
message above:
"To make a long story short: You need to open a ticket at the vendor
to fix this at the exporter side. Possible solutions:
1. If they want to stay with the tags #21, #22, they need to send also
a tag #160."
I now have a fix for this problem from Huawei, where they indeed
supply tag #160 (systemInitTimeMilliseconds). I have verified with
Wireshark that the template data specifies tag #160, and that the
flow data contains sensible values for systemInitTimeMilliseconds.
However, nfdump-1.6.22 still prints the records with a start time of
1. January 1970, e.g.:
% nfdump -r nfcapd.202012031325
Date first seen Duration Proto Src IP Addr:Port Dst IP
Addr:Port Packets Bytes Flows
1970-01-01 01:00:00.000 0.000 UDP 172.20.22.2:37626 ->
172.20.23.2:5201 3749 3.9 M 1
Looking at the nfdump-1.6.22 source I'm wondering if the problem now
is simply missing handling of tag #160 (systemInitTimeMilliseconds).
In bin/ipfix.h I see
#define IPFIX_flowEndDeltaMicroseconds 159
#define IPFIX_postOctetTotalCount 171
i.e. no tag 160 here, and in bin/ipfix.c the ipfix_element_map_s
ends at IPFIX_flowEndDeltaMicroseconds.
Is it simply the case that tag #160 currently isn't handled by
nfdump? If so, is there any possibility of adding such handling?
Pcap of the Huawei IPFIX export with the tag #160 information is
available at
http://www.nethelp.no/ipfix.pcap
Steinar Haug, AS 2116
_______________________________________________
Nfdump-discuss mailing list
Nfdump-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfdump-discuss
