Re: Re[2]: [Flow-tools] port 0
This has been discussed before elsewhere so I don't want to belabor the
point (http://ipfix.doit.wisc.edu/archive/1078.html) but the router itself
has no way of knowing what the port is as the L4 port number was in a
previous packet. Since the IP ID field is not tracked in a v5 Netflow
record, the router has no way of matching a fragmented packet up with the
appropriate flow. The router has no alternative but to create a new flow
entry with a null port number. Since the fragmented packet does have the
next protocol field set, the new frag flow does have the protocol
field set to TCP but there is no port field. This results in a port 0
flow.
But you don't have to trust me, here's a more concrete example...
Run a packet capture to find actual fragmented packets:
[EMAIL PROTECTED] tcpdump -i eth0 -n ip[6] 0x1f != 0
07:21:25.398704 1.1.16.228 2.2.44.114: udp (frag 30051:[EMAIL PROTECTED])
07:21:25.492367 1.1.16.228 2.2.44.114: udp (frag 30058:[EMAIL PROTECTED])
07:21:25.695525 1.1.16.228 2.2.44.114: udp (frag 30071:[EMAIL PROTECTED])
07:21:25.992371 1.1.16.228 2.2.44.114: udp (frag 30088:[EMAIL PROTECTED])
07:21:26.492375 1.1.16.228 2.2.44.114: udp (frag 30122:[EMAIL PROTECTED])
07:21:26.929876 1.1.16.228 2.2.44.114: udp (frag 30156:[EMAIL PROTECTED])
07:21:27.226781 1.1.16.228 2.2.44.114: udp (frag 30174:[EMAIL PROTECTED])
Then check the resulting flows:
[EMAIL PROTECTED] flow-cat ft-v05.2005-02-03.072100-0500 | ../bin/flow-print -f
5 | awk '{if(($5==0 $8==0 $9==17)) print $0}' | grep 1.1.16.228
0203.07:21:26.938 0203.07:21:36.032 1 1.1.16.2280 255
2.2.44.114 0 17 0 7 4227
Without formatting the above is hard to read, so I'll clean it up...
startime srcip srcp dstip dstp pro pkts
07:21:26.938 1.1.16.228 0 2.2.44.114 0 17 7
So we clearly see that fragmented UDP datagrams are causing port 0 flows.
This is painful for many NetFlow technologies as it forces the technology to
guess. Such is the nature of IP. :(
On 2/2/05 10:12 PM, jing shen [EMAIL PROTECTED] wrote:
Hi Adam£¬
BTW: Here's an example frag causing port 0...
startime srcip srcp dstip dstp pro pkts
17:01:18.307 1.1.69.40 0 2.2.16.61 0 64
17:01:18.187 1.1.69.40 2969 2.2.16.61 25 618
17:01:18.188 2.2.16.61 25 1.1.69.40 2969 618
This is an SMTP flow that started a new flow at t.187 then a second frag
flow at t.307.
.40 was the client so I would suspect that a large email was sent caused the
need for larger packets and ultimately the need for fragmentation.
To my understanding the above record just shows there is something
wrong with traffic between 1.1.69.40 2.2.16.61. If the router
fragments packets fill port number with 0, this breaks the IP packet
forwarding requirement. If client host send packet with port 0, this
should means its OS has something buggy, as port 0 is reserved.
Look through your flow logs with something like:
flow-cat ft* | flow-print -f 5 | awk '{if(($5==0 $8==0 $9==6)) print
$0}'
Any output you get should be a fragged TCP packet else an actual TCP flow on
port 0 (which can happen, it's just rare).
On 2/2/05 12:21 PM, Dustin [EMAIL PROTECTED] wrote:
Hello,
This may have been discussed, but I don't find any results in the archives.
We are troubleshooting some performance issues, have Cisco routers, and just
started using flow-tools to capture data. I've issued flowstat with the
following args:
flow-stat -f5 -p -S2
# port flows octetspackets
#
0 425 68968722 51238
445 10886 51125320 372789
1494710 26667144 524757
31889 1800 21081243 50199
3905101 20985596 19102
As you can see, most of the traffic is generated with lower number of
sessions
packets, but w/ higher amount of data. We would like to know exactly what
this traffic is, why is the majority of traffic lumped into port 0?
TIA,
Dustin
___
Flow-tools mailing list
[EMAIL PROTECTED]
http://mailman.splintered.net/mailman/listinfo/flow-tools
--
Adam Powers
Senior Security Engineer
Advanced Technology Group
c. 678.725.1028
o. 770.225.6521
f. 770.225.6501
e. [EMAIL PROTECTED]
AOL IM: adampowers22
StealthWatch by Lancope - Security through network intelligence
___
Flow-tools mailing list
[EMAIL PROTECTED]
http://mailman.splintered.net/mailman/listinfo/flow-tools
[Flow-tools] Compilation problems / Gentoo AMD64
Hi List, I am attempting to compile flow-tools on an AMD64 in Gentoo 2.6.9-r14. The error I get is: else rm -f .deps/flow-cat.Tpo; exit 1; \ fi flow-cat.c: In function `main': flow-cat.c:555: error: label at end of compound statement make[1]: *** [flow-cat.o] Error 1 make[1]: Leaving directory `/usr/local/src/flow-tools-0.67/src' make: *** [all-recursive] Error 1 The source in question is: 550: if (done) 551: break; 552: 553: next_file: 554: 555: } /* FOREACH filename in dir */ 556: 557: } /* foreach dir bundle */ Anyone have any luck compiling in this scenario? Any help would be appreciated Cheers, Aaron --- Aaron Thomas Network Engineer Delta Cable Communications ___ Flow-tools mailing list [EMAIL PROTECTED] http://mailman.splintered.net/mailman/listinfo/flow-tools
RE: [Flow-tools] Compilation problems / Gentoo AMD64
This works for compiling, but tell me what you get when you try to run flow-capture. I've tested on x86_64 and i386, and 0.59-0.67 give the same error in syslog: Feb 3 13:03:02 cambia2 flow-capture[21683]: ftfile_mkpath(2005/tmp-v05.2005-02-03.130302-0500): Value too large for defined data type I'm at a loss. Jonathan Glass -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Thomas Sent: Thursday, February 03, 2005 2:48 PM To: flow-tools@list.splintered.net Subject: RE: [Flow-tools] Compilation problems / Gentoo AMD64 Hi List, I have solved my own problems it would appear. For the errors below; flow-cat.c:555: error: label at end of compound statement flow-dscan.c:565: error: label at end of compound statement flow-dscan.c:810: error: label at end of compound statement flow-receive.c:737: error: label at end of compound statement flow-fanout.c:844: error: label at end of compound statement I added a ; to the labels on the line proceeding it. Compilation now works. FYI gcc version info is x86_64-pc-linux-gnu-3.4.3 I used this page: http://tinyurl.com/6l3vo as reference. I have not tried running flow-stats at this time, and will report afterwards. Cheers, Aaron -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Thomas Sent: Thursday, February 03, 2005 11:30 AM To: flow-tools@list.splintered.net Subject: [Flow-tools] Compilation problems / Gentoo AMD64 Hi List, I am attempting to compile flow-tools on an AMD64 in Gentoo 2.6.9-r14. The error I get is: else rm -f .deps/flow-cat.Tpo; exit 1; \ fi flow-cat.c: In function `main': flow-cat.c:555: error: label at end of compound statement make[1]: *** [flow-cat.o] Error 1 make[1]: Leaving directory `/usr/local/src/flow-tools-0.67/src' make: *** [all-recursive] Error 1 The source in question is: 550: if (done) 551: break; 552: 553: next_file: 554: 555: } /* FOREACH filename in dir */ 556: 557: } /* foreach dir bundle */ Anyone have any luck compiling in this scenario? Any help would be appreciated Cheers, Aaron --- Aaron Thomas Network Engineer Delta Cable Communications ___ Flow-tools mailing list [EMAIL PROTECTED] http://mailman.splintered.net/mailman/listinfo/flow-tools ___ Flow-tools mailing list [EMAIL PROTECTED] http://mailman.splintered.net/mailman/listinfo/flow-tools ___ Flow-tools mailing list [EMAIL PROTECTED] http://mailman.splintered.net/mailman/listinfo/flow-tools
[Flow-tools] flow-capture amd64 problem (Was: Compilation problems / Gentoo AMD64)
On Feb 03, Jonathan Glass wrote: This works for compiling, but tell me what you get when you try to run flow-capture. I've tested on x86_64 and i386, and 0.59-0.67 give the same error in syslog: Feb 3 13:03:02 cambia2 flow-capture[21683]: ftfile_mkpath(2005/tmp-v05.2005-02-03.130302-0500): Value too large for defined data type I'm at a loss. I'm sorry that nobody's had time to look into it. I found a bug in flow-print that had to do with mistaking time_t for a 32 bit value instead of a 64 bit value (as it is on amd64), so I wouldn't be surprised if something like that is causing the problem with flow-capture. You can try the patch I posted for flow-print (actually for ftlib.h): http://mailman.splintered.net/pipermail/flow-tools/2004-December/002501.html But it hasn't been reviewed by the author yet. Mike ___ Flow-tools mailing list [EMAIL PROTECTED] http://mailman.splintered.net/mailman/listinfo/flow-tools
Re: [Flow-tools] Compilation problems / Gentoo AMD64
On Thu, Feb 03, 2005 at 03:42:57PM -0500, Jonathan Glass wrote:
This works for compiling, but tell me what you get when you try to run
flow-capture. I've tested on x86_64 and i386, and 0.59-0.67 give the same
error in syslog:
Feb 3 13:03:02 cambia2 flow-capture[21683]:
ftfile_mkpath(2005/tmp-v05.2005-02-03.130302-0500): Value too large for
defined data type
flow-tools erroneously assumes that 'unsigned int' == 'long' and that
'unsigned int' == 'unsigned 32 bit int'. the former is not true in 64
bit platforms and the latter is hazardous, but less likely to break much.
ftlib.h:#define u_int32 unsigned int
v-unsigned int
ftfile.c:int ftfile_mkpath(u_int32 ftime, int nest)
struct file {
[...]
time_t time; --- gentoo may define this as 'long' which is 64bit on 64bit
archs
[...]
}
I'm at a loss.
%%
#include sys/types.h
#include time.h
int
main(void)
{
printf(%u ?= %u\n, sizeof(time_t), sizeof(unsigned int));
}
%%
compile that:
$ cc -o foo foo.c
$ ./foo
i'd go on about posix and such, but there's plenty of docs available on
what the 'right way' of manipulating/displaying fixed sizes in C is.
--
- bill fumerola / [EMAIL PROTECTED]
___
Flow-tools mailing list
[EMAIL PROTECTED]
http://mailman.splintered.net/mailman/listinfo/flow-tools
