Closed iddq closed 6 years ago
I'm getting one step closer to identify this bug. if I convert a pcap file of netflow traffic to nfdump format by nfcapd and later dump it by nfdump then we can see the measured bytes for a flow is wrong.
If I carve out a small section of this pcap file and do the conversion for this smaller section of the pcap file then the measured bytes for that flow is ok.
So the problem is in the nfcapd.
What type of device?
I found a similar problem and reported here on the mailing list, with Fortigate firewall. I should open a ticket for it. See #77
I found that the value reported by nfdump was exactly 69 times larger than the real value. That's not the same as you see, but it could just be due to uninitialized data.
Do you see the tshark warning that I saw?
Expert Info (Warning/Malformed): Trying to fetch an unsigned integer with length 9
Yes, it is a fortigate.
Can someone share a Fortigate pcap file to the collector in order to track this issue
See ticket #77
tshark -n -r netflow-20170502-091404.cap -V | grep 'Post Octets:' | cut -d ':' -f2- | awk '{s+=$1} END {print s}' 4642488540
fdump -r netflow-20170502-091404.cap.nf -A outif Date first seen Duration Output Packets Bytes bps Bpp Flows 2017-05-02 11:05:55.210 1801.720 0 7.8 M 639.7 M 2.8 M 81 1 2017-05-01 22:42:35.730 48143.270 36 554.0 G 85.5 T 14.2 G 154 598567 2017-05-01 22:36:57.570 48481.420 48 652.9 M 57.6 G 9.5 M 88 1074981 2017-05-02 11:15:36.390 1.550 57 78920 4.3 M 22.0 M 54 1 Summary: total flows: 1673550, total bytes: 171214120575424, total packets: 554651127469, avg bps: 28252321860, avg pps: 11440486, avg bpp: 308
tshark -n -r netflow-20170502-091404.cap -V | grep -c 'Flow 1' 1673956
ps: netflow v9