Bug 1836 - "undesired" behavior when using the -r flag
Summary: "undesired" behavior when using the -r flag
Status: CLOSED FIXED
Alias: None
Product: softflowd
Classification: Unclassified
Component: softflowd (show other bugs)
Version: -current
Hardware: All All
: P2 normal
Assignee: Damien Miller
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-09 04:14 AEDT by Daan van der Sanden
Modified: 2011-09-06 15:33 AEST (History)
1 user (show)

See Also:


Attachments
Patch to fix -r 'behavior' (2.79 KB, text/plain)
2010-11-09 21:59 AEDT, Daan van der Sanden
Details
Simple fix for times in the future (634 bytes, patch)
2011-07-27 22:18 AEST, Martin Vejmelka
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daan van der Sanden 2010-11-09 04:14:08 AEDT
When using the -r flag exported flows will always be in the future. Because the system uptime is set on line 118 (http://code.google.com/p/softflowd/source/browse/softflowd.c#1877) to the current time, all exported packtes will be 49 days in the future (2^32 milliseconds).

Solution: if flow records are created from a pcap file the system uptime should be before the first timestap, but not more then 49 days (2^32 - 1 milliseconds) in the past.

I will try to code this tomorrow and provide patch/new file.
Comment 1 Daan van der Sanden 2010-11-09 21:59:53 AEDT
Created attachment 1953 [details]
Patch to fix -r 'behavior'

The solution is a little different than I first thought.

This patch fixes the behavior when reading from pcap files. It set the boot time to 49,5 days in the past.

A note should be added to the documentation that it is not possible to import/convert a pcap file where the frames are more than 49.5 days in the past. This means that everything will works as expected/desired if softflowd manages to export all flows that are read from the file within 5 hours.
Comment 2 screw 2011-03-11 03:19:26 AEDT
I didn't notice there's already bug filed about this behavior, so I've made a possible fix(only for -v 5 version). You can find it here http://code.google.com/r/d0nald86-real-dates/

I didn't know where to put it to not mess up the original.

My only concern is about the sys_uptime. Is it used for anything else than just computing the start and end time of a flow (on the collector side)?

My solution in brief:
when exporting flows i check whether the system_boot_time is less than flow_start and/or the difference between system_boot_time and flow_start is not more than ~49 days (as mentioned in the above post). If so, set the system_boot_time to flow_start.
Comment 3 screw 2011-03-25 10:29:41 AEDT
(In reply to comment #2)
> I didn't notice there's already bug filed about this behavior, so I've
> made a possible fix(only for -v 5 version). You can find it here
> http://code.google.com/r/d0nald86-real-dates/
> 
> I didn't know where to put it to not mess up the original.
> 
> My only concern is about the sys_uptime. Is it used for anything else
> than just computing the start and end time of a flow (on the collector
> side)?
> 
> My solution in brief:
> when exporting flows i check whether the system_boot_time is less than
> flow_start and/or the difference between system_boot_time and
> flow_start is not more than ~49 days (as mentioned in the above post).
> If so, set the system_boot_time to flow_start.

i've updated my "fix". now i think it's really working. PLEASE test it.
(http://code.google.com/r/d0nald86-real-dates/)
Comment 4 Martin Vejmelka 2011-07-27 22:18:54 AEST
Created attachment 2070 [details]
Simple fix for times in the future

I haven't found these solutions and have created my own simple solution. Please find attached patch.
Comment 5 Damien Miller 2011-09-06 15:33:03 AEST
close resolved bugs now that openssh-5.9 has been released