phaag / nfdump

Netflow processing tools
Other
770 stars 202 forks source link

calculated traffic amount is totally wrong #65

Closed iddq closed 6 years ago

iddq commented 7 years ago

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

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

candlerb commented 6 years ago

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
iddq commented 6 years ago

Yes, it is a fortigate.

phaag commented 6 years ago

Can someone share a Fortigate pcap file to the collector in order to track this issue

phaag commented 6 years ago

See ticket #77