adsr / flow-tools Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/flow-tools
License: Other
Automatically exported from code.google.com/p/flow-tools
License: Other
flow-tools is a set of programs for processing and managing NetFlow exports from Cisco and Juniper routers. The software was originally written by Mark Fullmer while working at Ohio State University. Steve Romig and the OSU network security group have added documentation, functionality, and provided feedback. OARnet and the Ohio ITEC have recently funded my time to add version 8 PDU support and various other features. For installation notes and a quick start please see INSTALL. If you are using flow-tools please subscribe to the mailing list by sending a message to [email protected] flow-tools is currently available at http://www.splintered.net/sw/flow-tools Mark Fullmer [email protected]
Date: Thu, 20 Sep 2007 10:32:12 -0300
From: Fernando Garcia <[email protected]>
To: [email protected]
Subject: [Flow-tools] cflow-1.053 compile problem for flow-tools 0.68.1
X-Spam-Level:
Hello all ,
Sorry if this is not the corret list, but in think it's strongly related...
Have anyone tried (and managed) compile Cflow-1.053 with flow-tools-0.68.1 ?
As recommended on INSTALL, Cflow must be compiled from dir contrib on
flow-tools dir. It looks for libft.a on ../../lib (considering it is in
contrib dir) to figure out it has to be compiled for flow-tools.
I figured out libft.a changed to libft.la on flow-tools-0.68.1.
Changelog has this comment:
"Compiles libft with -fPIC to work ok with libcflow-perl"
Dow anyone know any fix for this ? As cflow doens't find libft.a it
doesn't figure out it should be compiled for flow-tool.
I tried a little tick, changind Makefile.PL to look for libft.la. At a
first glance, it did work but when I run flowscan I got a weird error:
(probably due this "smooth" change).
-------- flowscan error --------------
Wanted function created
/usr/bin/perl: symbol lookup error:
/usr/lib/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/Cflow/Cflow.so:
undefined symbol: fterr_setid
---------------------
I'm using 64bit arch, Suse 10.1.
Trying to use flow-tools-0.68 (with patchs, due 64bit problem) Cflow
doesn't compile.
Regards,
Fernando
Original issue reported on code.google.com by [email protected]
on 20 Sep 2007 at 2:02
Are there any plans to support Internet Protocol Flow Information Export
(IPFIX) ? I'm hoping for IPv6 capabilities, so I don't have to find something
different to use on my collectors. Thanks.
Original issue reported on code.google.com by [email protected]
on 15 Aug 2011 at 9:59
Can you, please, add some flow-tools documentation to the wiki? Manual
pages would suffice as a starting point.
Thanks!
Original issue reported on code.google.com by [email protected]
on 3 Apr 2009 at 1:38
Command:
svn checkout http://flow-tools.googlecode.com/svn/trunk/ flow-tools-read-only
Get empty revision 22 :(
Original issue reported on code.google.com by [email protected]
on 30 Jul 2010 at 9:12
What steps will reproduce the problem?
1. What's the flow rate supported per second in flow-tools
2. And what is the suggested hardware configuration for various flow rates
3.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Please provide any additional information below.
Thanks,
Ram
Original issue reported on code.google.com by [email protected]
on 10 May 2013 at 4:41
What steps will reproduce the problem?
No special steps: flow-tools data in my case is wrong all the time.
What version of the product are you using? On what operating system?
OS: 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009
flow-tools: 0.68.4.1
I have two different servers that collect netflow data coming from the same
Cisco 7507 router. First server runs on old RH linux with flow-tools 0.66.
Second one has got FreeBSD plus flow-tools 0.68, which I replaced with the
latest flow-tools-ng version.
The problem is that under FreeBSD flow-tools report different amount of
traffic per IP which is much more big than reported on another server under
Linux. I googled this but found no similar cases so it seems like I'm the
only one who faced this trouble.
I performed some test sending fixed number of packets to check what server
lies. And it is definetely about the new one under FreeBSD. Sometimes it
reports proper amount of traffic per IP-address, but ususally it reports
more than what was really sent. It could be just "more" or exactly twice
more etc. Practically saying, for now I can't rely on server's outcome and
I'm very confused about that as I completely failed to understand what is
the bug about.
Will appreciate any support.
Original issue reported on code.google.com by [email protected]
on 28 Sep 2009 at 7:56
What steps will reproduce the problem?
1. Enable flow for multiple routers, In my case 21 router to a same destination
server & same port (like, flow-capture runs on 2056 port and capture flow data
for all routers)
2. When i ran flow-header for the completed flow file, i could see lost flows.
Because of this the utilization reports are getting lot of discrepancies when
compare to real time utilization
3.
What is the expected output? What do you see instead?
I need to capture flow data from more then 100 devices on a same server with
same flow-capture port with out any loss. Please help me to implement this..
What version of the product are you using? On what operating system?
I am using flow-tools-0.68.5.1-1.el5 on Redhat 5.9 64 bit operating system..
Please provide any additional information below.
Thanks in Advance,
Ram
Original issue reported on code.google.com by [email protected]
on 25 Apr 2013 at 7:49
What steps will reproduce the problem?
1. Enable flow on a large production router having more than 10 Links with 50 -
100MBps terminated for remote location.
2. You would get flow files around 15 - 20 MB per minute.
3. CPU utilization is high when we start the flow-capture.
What is the expected output? What do you see instead?
I need to know how much flow rate was supported by flow-tools, and what is the
recommended server hardware platform to capture flow for nearly 50 routers on a
single server.
What version of the product are you using? On what operating system?
I am using flow-tools-0.68.5.1-1.el5 on Redhat enterprise linux 5 64 bit
Please provide any additional information below.
At present i am collecting flow data for one high utilization router with 10
Links on it, for this alone my server's load average is going to 3 - 5, i would
like to added more than 50 routers are the same server, can any one help me to
fine tune / suggest the hardware to handle the load..
My Server configuration :
CPU - 16 x 3.00GHz
MEMORY - 16 GB
HDD - 440 GB In RAID5 Array
Thanks in Advance,
Ram
Original issue reported on code.google.com by [email protected]
on 10 May 2013 at 4:37
What steps will reproduce the problem?
Find below.
What is the expected output? What do you see instead?
Works great on i386. Very big memory leak on 64bit.
What version of the product are you using? On what operating system?
FreeBSD 7.1 amd64 release. flow-tools 0.68.4.1
Please provide any additional information below.
All the BSD(amd64) people will appreciate the patch.
Thanks.
Original issue reported on code.google.com by [email protected]
on 9 Feb 2009 at 9:41
What steps will reproduce the problem?
1. run flow-cat * | flow-report -v TYPE=ip-source-address-destination-count
2. Note the fields at the top:
# fields: +key,+flows,+octets,+packets,+duration,+other
The field ip-destination-address-count (+key1) is missing.
This means that you cannot sort by the column you're trying to report on.
Every other flow-report except ip-destination-address-source-count lists
this type of field as a key1 or key2.
I'm running 0.68.4 on FreeBSD 8-current.
Original issue reported on code.google.com by [email protected]
on 18 Jan 2009 at 10:06
What steps will reproduce the problem?
1. run flow-stat on flow capture files that all hit one bucket in the summary.
For example, all packets are size 128.
What is the expected output? What do you see instead?
Should see 100% under 128 in IP packet size distribution. Instead, .000 is
displayed.
What version of the product are you using? On what operating system?
flow-tools-0.68.5.1, linux
Please provide any additional information below.
###the following has 12 packets, 10 with 106 bytes and 2 with 234 octets and
flow-stat -f0 correctly shows 'IP packet size distribution" percentage's.
[jwacase@nickel flow-tools]$ flow-print < ft-v05.2012-03-07.121228-0700
srcIP dstIP prot srcPort dstPort octets packets
10.156.1.2 10.156.8.202 6 42499 307 234 1
10.156.1.2 10.156.8.202 6 273 42528 106 1
10.156.1.2 10.156.8.202 6 546 547 106 1
10.156.1.2 10.156.8.202 6 23879 54468 106 1
10.156.1.2 10.156.8.202 6 34133 48553 106 1
10.156.1.2 10.156.8.202 6 613 614 234 1
10.156.1.2 10.156.8.202 6 35218 27234 106 1
10.156.1.2 10.156.8.202 6 26011 63973 106 1
10.156.1.2 10.156.8.202 6 42937 21264 106 1
10.156.1.2 10.156.8.202 6 17609 13617 106 1
10.156.1.2 10.156.8.202 6 62701 43400 106 1
10.156.1.2 10.156.8.202 6 5628 23491 106 1
jwacase@nickel flow-tools]$ flow-stat < ft-v05.2012-03-07.121228-0700 | grep -A
2 "IP packet size distribution"
IP packet size distribution:
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .000 .000 .833 .000 .000 .000 .167 .000 .000 .000 .000 .000 .000 .000
### the following has all flows as one size. and flow-stat -f0 is all 000's..
assume it is truncating to 3 decimal digits and losing the 1.
[jwacase@nickel flow-tools]$ flow-print < ft-v05.2012-03-07.121727-0700srcIP
dstIP prot srcPort dstPort octets packets
10.156.1.2 10.156.8.202 6 273 42528 106 1
10.156.1.2 10.156.8.202 6 546 547 106 1
10.156.1.2 10.156.8.202 6 23879 54468 106 1
10.156.1.2 10.156.8.202 6 34133 48553 106 1
10.156.1.2 10.156.8.202 6 35218 27234 106 1
10.156.1.2 10.156.8.202 6 26011 63973 106 1
10.156.1.2 10.156.8.202 6 42937 21264 106 1
10.156.1.2 10.156.8.202 6 17609 13617 106 1
10.156.1.2 10.156.8.202 6 62701 43400 106 1
10.156.1.2 10.156.8.202 6 5628 23491 106 1
10.156.1.2 10.156.8.202 6 2814 35536 106 1
[jwacase@nickel flow-tools]$ flow-stat < ft-v05.2012-03-07.121727-0700 | grep
-A 2 "IP packet size distribution"
IP packet size distribution:
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
### modifying ( a poor hack ) function print_3float lib/support.c to
void print_3float(float f)
{
printf("%#4.2f " , f);
/* char s[10], *c;
sprintf(s, "%-8.4f", f);
sprintf(s, "%#0-5.3", f);
c = s + 1;
printf("%s ", f);
*/
} /* print_3float */
# gives the following, which alters the output to be d.dd versus .ddd, and thus
shows the 100% case
[jwacase@fsa flow-tools-0.68.5.1]$ ./src/flow-stat <
ft-v05.2012-03-07.121727-0700 | grep -A 2 "IP packet size distribution"
IP packet size distribution:
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Original issue reported on code.google.com by [email protected]
on 7 Mar 2012 at 10:35
I am trying to get Cflow working with flow-tools from this site
http://flow-tools.googlecode.com/files/flow-tools-0.68.4.tar.bz2
Although flow-tools install I am unable to compile Cflow and get that
working which is really frustrating.
I keep reading everywhere that:
This assumes you have flow-tools installed on your system fully,
including headers
and development libraries. This is the only supported way to use Cflow.
I am stuck - please can anyone help me - how exactly do I install the
headers and development libraries?
Original issue reported on code.google.com by [email protected]
on 6 Nov 2008 at 7:49
Please add a new output format for the flow-print emulating output
flow-extract.
Original issue reported on code.google.com by [email protected]
on 14 Dec 2009 at 12:44
Attachments:
There is an example on data:
:unix_secs,sysuptime,dpkts,doctets,first,last,srcaddr,dstaddr,srcport,dstport,pr
ot
4699318,317952454,11,1767,317935544,317935544,172.16.0.40,109.205.246.211,49479,
8010,6
But problem is in unix_secs value. Documentation for netflow v5 says that
unix_secs is current count of seconds since 1970, but 4699318 is about 4 days
only.
Original issue reported on code.google.com by [email protected]
on 1 Mar 2013 at 12:45
NetFlow v9 support needed for IPv6 netflow handling.
Original issue reported on code.google.com by [email protected]
on 29 Mar 2010 at 10:49
What steps will reproduce the problem?
1. flow-export IP in VARCHAR (mysql).
2.
3.
What is the expected output? What do you see instead?
Please output IP in INT (mysql)
What version of the product are you using? On what operating system?
Freebsd 9.2
Please provide any additional information below.
Please. Write patch add option to flow-export so IP addresses will be output in
longint format rather than dotted quad (saves gobs of space in database).
Original issue reported on code.google.com by [email protected]
on 9 Feb 2014 at 3:36
Is this supported?.
If there is a set of steps i need to follow to get a 64 bit compiled version of
flow-export and flow-tools pkg in general on freebsd amd64.
Currently the exisiting flow-export takes a very long time...and hence i am
trying to see if 64 bit compiled version helps in some way
Original issue reported on code.google.com by [email protected]
on 2 Jul 2011 at 11:19
What steps will reproduce the problem?
see following
What is the expected output? What do you see instead?
some flows from 01-May are printed with a 20-Jun date
What version of the product are you using? On what operating system?
flow-tools-0.68.4, RHEL 5 on x86_64
Please provide any additional information below.
ftltime() hasn't changed since the ftio.c library file was created in 0.40,
but produces an incorrect result for maybe 10 minutes every 49.7 days
(unless your routers are rebooted at least this frequently).
This was noticed when I recently changed the code I use to process each
month's worth of flows to record the earliest and latest flow timestamp
seen. The earliest timestamp seen in the May flows was just before midnight
on Apr-30, as expected. However the latest flow seen was from Jun-20.
It was unlikely flow records/files had gotten mixed up since that date was
in the future. Now I was using a slightly modified version of ftltime()
that produced a result like struct fttime except there was a third field
for microseconds which I had a one-off interest in, but found they were
always zero from our routers.
I soon narrowed the problem down to flows occuring around 9:23PM on May-01.
I didn't think there was a problem with my code as the changes were so
small, and this was confirmed by grepping the output of flow-print -f 2
for '0620' with results like
00e0 203.100.24.26 0000 203.100.25.255 11 89 89 18 1404
0620.14:25:45.188 0620.14:25:55.160 9.972 78 00 10
004d 203.100.30.221 0000 203.100.30.255 11 8a 8a 2 458
0620.14:25:51.380 0501.21:23:08.080 3.996 229 00 10
From printing out the 4 values supplied to ftltime() when anomalous
results were produced, it was clear this happened just after sysUpTime
rolled-over from 4billion to a small number. ftltime() was producing
a difference close to 2^32 rather than the much smaller number it should
be. 2^32 milliseconds / 1000 / 86400 is about 49.7 days, which fits since
May-01 to Jun-20 is 49-50 days.
I believe I've fixed this problem in my version of ftltime(), but added
code to print out lines like the following whenever my result was diff-
erent to the ftltime() library version and these lines happen only when
the library version is producing Jun-20 dates, i.e. my version behaves
the same in all other cases.
sys 19200, secs 1209641007, msecs 184, First 4294952156, Last 19168
First lib_ftltime 0620.14:25:40.140, my_ftltime 0501.21:22:52.844
Last lib_ftltime 0501.21:23:27.152, my_ftltime 0501.21:23:27.152
As it turns out, I also checked the flow duration calculated directly
from Last-First against that of the ftt structs for First and Last for
both my version and the library version and both were always correct.
You wouldn't normally expect this from buggy code but it probably makes
perfect sense if you analysed the way way unsigned ints behave.
Here's my corrected code, and while I wouldn't expect all the comments
to make it into you repository, I think there needs to be something
indicating there was an issue in the past and that people should only
make changes with some care; in particular testing against cases when
sysUpTime has rolled-over while t hasn't.
/*
* [DMT 13-Jun-2008] corrected version of based on ftltime()
* ftltime returns a struct fttime = secs - sys + t
* But fails to handle the case when sys has recently rolled-over 2^32
* so sys is a small uint32_t value while t is close to 2^32 milliseconds.
* The result is about 47 days wrong.
*
* The approach used to fix this is to treat (sys - t) as a signed number
* which we expect to be quite small so we don't worry about corner cases
* like -2^31.
*
* I was guessing there would be a fixed relationship between sys and t,
* so either sys or t would roll-over first. I haven't really looked but
* suspect First is always behind sys. However while Last is normally
* behind sys:
* sysUpTime 17660, unix_secs 1209641005, First 1740, Last 1740
* here's a counter-example from the same 5 minute flow file
* sysUpTime 13660, unix_secs 1209641001, First 4294965144, Last 14716
*
* NB the case of Last>sys did not produce an error with the original code
* because the arithmetic was done in 2 stages, both involving the value
* divided by 1,000, and hence not subject to roll-over. The problem only
* happens when only one of sys and Last have rolled-over. Perhaps a correction
* factor of 2^32/1000 could have been applied to both the seconds and
* millisecond values.
*
* NB an alternative approach might be to use larger signed types, but the
* binary '%' operator behaves as a mathematical mod operation for positive
* values, i.e. for unsigned types. However "if either operand is negative,
* the behaviour will be machine-dependent":
* C: A Reference Manual 4th ed, p202.
* The best approach might well be to use doubles as they'll easily handle
* 32 seconds bits + 10 milliseconds bits.
*
*/
struct fttime my_ftltime(uint32_t sys, uint32_t secs, uint32_t nsecs, uint32_t
t)
{
uint32_t diff, diff_s, diff_m;
struct fttime ftt;
int diff_was_negative = 0;
/* unix seconds/nanoseconds to seconds/milliseconds */
ftt.secs = secs;
ftt.msecs = nsecs / 1000000L;
/* sys and t are in milliseconds */
diff = sys - t;
/* we don't expect the unsigned difference to be anywhere near 2^31 */
/* but allow +/- 2^31, approx 2 billion anyway */
if (diff > 2147483648) {
diff_was_negative = 1;
/* negate to have an absolute value before deriving secs/msecs */
diff = -diff;
}
diff_s = diff / 1000;
diff_m = diff % 1000;
/* calculate ftt -= diff */
if (diff_was_negative) {
/* subtracting a negative value means add */
ftt.secs += diff_s;
ftt.msecs += diff_m;
if (ftt.msecs >= 1000) {
/* handle overflow */
ftt.msecs -= 1000;
ftt.secs++;
}
} else {
/* simply subtract */
ftt.secs -= diff_s;
if (ftt.msecs < diff_m) {
/* handle underflow */
ftt.msecs += 1000;
ftt.secs--;
}
ftt.msecs -= diff_m;
}
return ftt;
} /* ftltime */
Original issue reported on code.google.com by [email protected]
on 17 Jun 2008 at 4:38
1. flow-export -f1
2.
3.
What is the expected output? What do you see instead?
Expected output is a valid libpcap file it would appear both the tcp dump
versions minor and major are out dated as well as the magic number.
What version of the product are you using? On what operating system?
Latest stable version, on opensuse 10.3
Please provide any additional information below.
If more infomation is required please let me know.
thanks
n keep up the amazing work.
Original issue reported on code.google.com by [email protected]
on 9 Feb 2008 at 11:32
What is the expected output? What do you see instead?
Fields "capture start" and "capture end" show date and time, but without
any timezone. This makes it hard to use their output for other purposes.
What version of the product are you using? On what operating system?
0.68.2-rc2, NetBSD 3.1.
Please provide any additional information below.
patch attached.
Original issue reported on code.google.com by [email protected]
on 25 Oct 2007 at 6:51
Attachments:
What steps will reproduce the problem?
1. Let a flow-capture or flow-fanout instance listen on a specific IP/port
2. Configure a Cisco router to send NetFlow v9 data to this IP/port
What is the expected output? What do you see instead?
- flow-capture: Nothing is captured and saved into the file
- flow-fanout: No NetFlow packets are sent to the defined targets
What version of the product are you using? On what operating system?
- flow-tools version 0.68
- Used on Ubuntu 10.04 32Bit
Logfile entries which occur repeatedly:
- flow-capture[27707]: ftpdu_verify(): src_ip=XX.XX.XX.XX failed.
- flow-fanout[2177]: ftpdu_verify(): src_ip=XX.XX.XX.XX failed.
Original issue reported on code.google.com by [email protected]
on 4 Oct 2010 at 10:23
What steps will reproduce the problem?
1. add -Werror=format-security to CFLAGS
2. build
3. watch it break:
DEBUG: fterr.c: In function 'fterr_info':
DEBUG: fterr.c:115:5: error: format not a string literal and no format
arguments [-Werror=format-security]
DEBUG: syslog(LOG_INFO, buf);
DEBUG: ^
DEBUG: fterr.c: In function 'fterr_err':
DEBUG: fterr.c:137:5: error: format not a string literal and no format
arguments [-Werror=format-security]
DEBUG: syslog(LOG_INFO, buf2);
DEBUG: ^
DEBUG: fterr.c: In function 'fterr_errx':
DEBUG: fterr.c:162:5: error: format not a string literal and no format
arguments [-Werror=format-security]
DEBUG: syslog(LOG_INFO, buf);
DEBUG: ^
DEBUG: fterr.c: In function 'fterr_warnx':
DEBUG: fterr.c:186:5: error: format not a string literal and no format
arguments [-Werror=format-security]
DEBUG: syslog(LOG_INFO, buf);
DEBUG: ^
DEBUG: fterr.c: In function 'fterr_warn':
DEBUG: fterr.c:208:5: error: format not a string literal and no format
arguments [-Werror=format-security]
DEBUG: syslog(LOG_INFO, buf2);
DEBUG: ^
DEBUG: cc1: some warnings being treated as errors
What is the expected output? What do you see instead?
Should just build.
What version of the product are you using? On what operating system?
0.68.5 on Fedora/rawhide
Please provide any additional information below.
Fedora is using -Werror=format-security in CFLAGS and flow-tools fails to
build. Attached patch fixes it.
Original issue reported on code.google.com by [email protected]
on 24 Jun 2014 at 6:30
Attachments:
flow-send Does not work on freebsd 7.0-STABLE
flow-tools-0.68_6
example:
# flow-gen -V5 | flow-send -d9 127.0.0.1/127.0.0.1/9990
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: processed 1000 flows
sys: seconds=0.002 flows/second=389863.547758
wall: seconds=0.002 flows/second=435540.069686
Original issue reported on code.google.com by [email protected]
on 11 Nov 2008 at 10:47
flow-tools release: flow-tools-0.66
What steps will reproduce the problem?
1. start flow-fanout or flow-capture
/md/binarios/bin/netflow/flow-fanout 0/0/2056 0/0/2055 0/212.31.32.163/2055
/md/binarios/bin/netflow/flow-capture -z0 -N0 -V5 -n295
-w/md/dumper/files/flow-capture 0/0/2055
2. the syslog shows:
May 20 12:20:55 dmdnet01 flow-fanout[4866]: ftpdu_seq_check():
src_ip=10.17.32.32 dst_ip=0.0.0.0 d_version=5 expecting=22030939
received=3648399742 lost=3626368803
May 20 12:20:55 dmdnet01 flow-fanout[4866]: ftpdu_seq_check():
src_ip=10.17.32.32 dst_ip=0.0.0.0 d_version=5 expecting=3648400432
received=3648400462 lost=30
What version of the product are you using? On what operating system?
HP-UX HP01 B.11.31 U ia64 4219704302 unlimited-user license
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 20 May 2011 at 10:17
[deleted issue]
What steps will reproduce the problem?
1. Use one instance of flow-fanout with a filter and one without a filter
2. Have each instance send data to a different instance of flow-capture.
For simplicity, flow-capture A gets the unfiltered data and flow-capture B
gets the filtered data.
2. View the filtered and unfiltered data captures with flow-cat
What is the expected output? What do you see instead?
I would expect to see the flows that match the filter in the data collected
by B, but they aren't. If I run flow-cat | flow-nfilter | flow-report on
the unfiltered data collected by A, using flow-nfilter with the same filter
as one of the instances of flow-fanout, I see the filtered data reported.
If I look at the data captured by flow-capture B, I see no data collected.
What version of the product are you using? On what operating system?
RHEL5, flow-tools 0.68.4.2
Please provide any additional information below.
This appears to have been a problem before with flow-tools 0.67:
http://mailman.splintered.net/pipermail/flow-tools/2004-January/001853.html
Maybe the fix was overwritten?
Original issue reported on code.google.com by [email protected]
on 15 Sep 2009 at 8:51
On large netflow flows (e.g. >800Mbit/sec) we constantly see following in logs:
Jan 3 12:12:00 radius-minsk2 flow-capture[98939]: STAT: now=1325581920
startup=1324649629 src_ip=172.16.2.23 dst_ip=172.16.2.50 d_ver=5 pkts=77674720
flows=2330241600 lost=22560 reset=3 filter_drops=0
In the same time udp dgrams dropped due to no socjet and due to full socket
constanly increases:
[gawriloff@radius-minsk2 /usr/home/gawriloff]$ netstat -s -p udp
udp:
1378886026 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
20888 with no checksum
71766750 dropped due to no socket
65910 broadcast/multicast datagrams undelivered
43841072 dropped due to full socket buffers
Recv-Q on flow-capture is always non-zero:
[gawriloff@radius-minsk2 /usr/home/gawriloff]$ sudo netstat -na | grep udp4
866304 0 *.2074 *.*
[gawriloff@radius-minsk2 /usr/home/gawriloff]$ ps ugaxww | grep 2074
root 98945 96.0 0.0 12428 1868 ?? Rs 23Dec11 6227:38.04
/usr/local/bin/flow-capture -w /var/netflow/flows/rtr10 -n 1439 -b big -z 9 -p
/var/run/flow-capture.pid -N 0 -V 5 -S 1 0/0/2074
So I propose to increase FT_SO_RCV_BUFSIZE from 4Mb to 8 in ftlib.h or better
make it configurable through addition parameter.
For example:
-sock 8Mb
Original issue reported on code.google.com by [email protected]
on 3 Jan 2012 at 9:17
Currently I maintain a small patch to flow tools at my site to silence the
ftpdu_seq_check() message, which freaks out if you have multiple flow sources
feeding into a single capture.
Currently we just hard compile it out, but if I clean this up to make it an cmd
line option, would you integrate it? We'd much rather stop hanging onto the
local patch.
Without it our logs get FLOODED with the messages due to the level of traffic
and duplicate sequence numbers.
fterr_warnx(
"ftpdu_seq_check(): src_ip=%s dst_ip=%s d_version=%d expecting=%lu received=%lu lost=%lu",
fmt_src_ip, fmt_dst_ip, (int)ftpdu.ftv.d_version,
(u_long)ftch_recexpp->ftseq.seq_exp,
(u_long)ftch_recexpp->ftseq.seq_rcv,
(u_long)ftch_recexpp->ftseq.seq_lost);
Alternatively, can you suggest any alternative means with flow-fanout to get
rid of the warnings? (If it really is an issue, I'd rather fix it properly if
possible.)
Original issue reported on code.google.com by [email protected]
on 28 Sep 2012 at 4:38
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.