Hi Jernej,
I got another report looking very similar. I need to check, if and how this can
be approached in nfdump.
Regards
- Peter
On 1/19/11 0:18, Jernej Porenta wrote:
> Heya,
>
> we are seeing strange time issues in netflow data and at first we believed it
> was nfdump fault, but now we are almost certain that the problem lies in
> netflow exporters on our Cisco boxes. As it seems the netflow packet (v5) has
> EndTime variable smaller than StartTime variable, which means that duration
> is negative.
>
> We tcpdumped the netflow file and analyzed it and wireshark shows this:
> SysUptime: 255500792
> Timestamp: Jan 17, 2011 11:15:00.953563968
> CurrentSecs: 1295259300
> CurrentNSecs: 953563968
> ...
> [Duration: 4294952.136000000 seconds]
> StartTime: 255489.068000000 seconds
> EndTime: 255473.908000000 seconds
> ...
>
> The same packets shows in nfdump like this:
> Date flow start Duration Proto Src IP Addr:Port Dst IP
> Addr:Port Packets Bytes Flows
> 2010-11-28 18:12:01.933 4294952.136 ICMP X.X.X.X:0 ->
> A.A.A.A:0.0 2 184 1
>
> Since the StartTime is larger than EndTime, nfdump and Wireshark both have
> problems showing the data. The problem in nfdump lies in netflow_v5_v7.c:
> ...
> if ( First > Last )
> /* First in msec, in case of msec overflow, between start and end */
> start_time = boot_time - 0x100000000LL + (uint64_t)First;
> else
> start_time = (uint64_t)First + boot_time;
> ...
>
> I know that this prevents overflow, but it makes problems with my case. (time
> difference is excatly 0x100000000; 49 days, 17 hours, 2 minutes and 47
> seconds, which makes sense with our results).
>
> So there are two questions:
> - is anyone of you experiencing the same issues with Cisco exporters and
> knows how to fix it?
> - do you think that nfdump should avoid this by not using this "overflow"
> method and setting a special case for that?
>
> I have checked other netflow software for that special case (flow-tools and
> flowd), but I cannot find any similar reference there how to address this
> issue. If you need any test pcap files, I can provide you with an example.
>
> PS: patch below fixes nfcapd build issues when --enable-readpcap is used on
> RHEL5 x86/x86_64, as Linux doesn't define a sin_len for the struct sockaddr
> --- nfdump-1.6.2/bin/pcap_reader.c 2009-11-25 09:11:15.000000000 +0100
> +++ nfdump-1.6.2.a/bin/pcap_reader.c 2011-01-18 22:35:54.000000000 +0100
> @@ -152,7 +152,7 @@ struct sockaddr_in *in_sock = (struct so
> ip = (struct ip *)&pkt[14];
> in_sock->sin_family = AF_INET;
> in_sock->sin_addr = ip->ip_src;
> - in_sock->sin_len = sizeof(struct sockaddr_in);
> + //in_sock->sin_len = sizeof(struct sockaddr_in);
> break;
> case 0x0806:
> /* ARP */
>
> regards,
> --
> Jernej Porenta <[email protected]>
> ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia
> tel: +386 1 479 8800, fax: +386 1 479 88 99
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Nfdump-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfdump-discuss
--
--
Be nice to your netflow data
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Nfdump-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nfdump-discuss
