From mark at inetu.net Mon Oct 6 16:48:03 2008 From: mark at inetu.net (Mark R.) Date: Mon Oct 6 16:48:08 2008 Subject: [Flow-tools] flow-tools on FreeBSD/amd64 Message-ID: <20081006163824.H71138@xmail01.inetu.net> Are there any known issues with flow-tools on 64-bit platforms? I'm trying to run 0.68 on FreeBSD 7.0/amd64 and running into some odd behavior with flow-capture and flow-fanout. Essentially, it seems as if the destination IP address coming from revcmesg() is garbage -- sometimes it's 0, other times it's a random value. I've checked ftnet.loc_addr.sin_addr.s_addr immediately after the recvmsg() call and it is not as expected. This is with both a pre-compiled package and a build from source. If this has been seen before or if anybody can suggest clue, I'd appreciate it. I've verified that the exports are correct on the wire with both tcpdump and nfcapd. Right now, I'm using a 32bit build without issue. Thanks, Mark From jloiacon at csc.com Mon Oct 6 17:02:41 2008 From: jloiacon at csc.com (Joe Loiacono) Date: Mon Oct 6 17:02:50 2008 Subject: [Flow-tools] flow-tools on FreeBSD/amd64 In-Reply-To: <20081006163824.H71138@xmail01.inetu.net> Message-ID: I believe this fork of flow-tools has the 64-bit patches in it. http://code.google.com/p/flow-tools/ "Mark R." Sent by: flow-tools-bounces@list.splintered.net 10/06/2008 04:48 PM To flow-tools@list.splintered.net cc Subject [Flow-tools] flow-tools on FreeBSD/amd64 Are there any known issues with flow-tools on 64-bit platforms? I'm trying to run 0.68 on FreeBSD 7.0/amd64 and running into some odd behavior with flow-capture and flow-fanout. Essentially, it seems as if the destination IP address coming from revcmesg() is garbage -- sometimes it's 0, other times it's a random value. I've checked ftnet.loc_addr.sin_addr.s_addr immediately after the recvmsg() call and it is not as expected. This is with both a pre-compiled package and a build from source. If this has been seen before or if anybody can suggest clue, I'd appreciate it. I've verified that the exports are correct on the wire with both tcpdump and nfcapd. Right now, I'm using a 32bit build without issue. Thanks, Mark _______________________________________________ Flow-tools mailing list flow-tools@splintered.net http://mailman.splintered.net/mailman/listinfo/flow-tools -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.splintered.net/pipermail/flow-tools/attachments/20081006/31911758/attachment.htm From plonka at doit.wisc.edu Mon Oct 6 17:08:00 2008 From: plonka at doit.wisc.edu (Dave Plonka) Date: Mon Oct 6 17:08:06 2008 Subject: [Flow-tools] flow-tools on FreeBSD/amd64 In-Reply-To: <20081006163824.H71138@xmail01.inetu.net> References: <20081006163824.H71138@xmail01.inetu.net> Message-ID: <20081006210800.GA20854@doit.wisc.edu> Hi Mark, On Mon, Oct 06, 2008 at 04:48:03PM -0400, Mark R. wrote: > > Are there any known issues with flow-tools on 64-bit platforms? I'm > trying to run 0.68 on FreeBSD 7.0/amd64 and running into some odd behavior > with flow-capture and flow-fanout. I believe one of the manin reasons for this development fork was to address 64-bit platform issues: http://code.google.com/p/flow-tools/ I'd give that a try. Dave -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka/ Madison, WI From mark at inetu.net Mon Oct 6 21:08:50 2008 From: mark at inetu.net (Mark R.) Date: Mon Oct 6 21:08:53 2008 Subject: [Flow-tools] flow-tools on FreeBSD/amd64 Message-ID: <20081006210827.H95433@xmail01.inetu.net> Dave, et al, I gave the forked copy a try, and I still see the problem. I'll include a short snippet from logs: Oct 7 00:48:26 server flow-capture[96376]: ftpdu_seq_check(): src_ip=192.168.248.14 dst_ip=0.0.0.0 d_version=5 expecting=1003054482 received=1003054512 lost=30 Oct 7 00:48:26 server flow-capture[96376]: ftpdu_seq_check(): src_ip=192.168.248.12 dst_ip=237.188.15.30 d_version=5 expecting=3747363059 received=3747365789 lost=2730 Oct 7 00:48:26 server flow-capture[96376]: ftpdu_seq_check(): src_ip=192.168.248.12 dst_ip=0.0.0.0 d_version=5 expecting=3747365729 received=3747365819 lost=90 Oct 7 00:48:26 server flow-capture[96376]: New exporter: time=1223340506 src_ip=192.168.248.12 dst_ip=48.193.208.156 d_version=5 Oct 7 00:48:26 server flow-capture[96376]: ftpdu_seq_check(): src_ip=192.168.248.12 dst_ip=0.0.0.0 d_version=5 expecting=3747366419 received=3747366449 lost=30 Oct 7 00:48:26 server flow-capture[96376]: New exporter: time=1223340506 src_ip=192.168.248.12 dst_ip=190.25.255.226 d_version=5 Oct 7 00:48:26 server flow-capture[96376]: ftpdu_seq_check(): src_ip=192.168.248.12 dst_ip=0.0.0.0 d_version=5 expecting=3747366539 received=3747366569 lost=30 Oct 7 00:48:26 server flow-capture[96376]: New exporter: time=1223340506 src_ip=192.168.248.14 dst_ip=241.15.201.236 d_version=5 Oct 7 00:48:26 server flow-capture[96376]: ftpdu_seq_check(): src_ip=192.168.248.14 dst_ip=0.0.0.0 d_version=5 expecting=1003054842 received=1003054872 lost=30 Oct 7 00:48:26 server flow-capture[96376]: ftpdu_seq_check(): src_ip=192.168.248.14 dst_ip=246.143.122.185 d_version=5 expecting=1003052982 received=1003055322 lost=2340 Oct 7 00:48:26 server flow-capture[96376]: ftpdu_seq_check(): src_ip=192.168.248.14 dst_ip=0.0.0.0 d_version=5 expecting=1003055322 received=1003055352 lost=30 There are two exporters at 192.168.248.1[24], but sending exporting to the same destination IP of 192.168.37.30. The real destination IP is never picked up -- It's either 0.0.0.0 or garbage. If I remove the #ifdef IP_RECVDSTADDR portion from flow-capture.c, I no longer get the garbage destination IPs, but instead get all 0.0.0.0 (as would be normally expected). This points to the setsockopt() as the culprit, but I'm past my point of experience already. Any suggestions as to what to try and change here? Thanks, Mark On Mon, 6 Oct 2008, Dave Plonka wrote: > > Hi Mark, > > On Mon, Oct 06, 2008 at 04:48:03PM -0400, Mark R. wrote: >> >> Are there any known issues with flow-tools on 64-bit platforms? I'm >> trying to run 0.68 on FreeBSD 7.0/amd64 and running into some odd behavior >> with flow-capture and flow-fanout. > > I believe one of the manin reasons for this development fork was to > address 64-bit platform issues: > > http://code.google.com/p/flow-tools/ > > I'd give that a try. > > Dave > > -- > plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka/ Madison, WI > From bghita at jack.see.plymouth.ac.uk Tue Oct 7 03:31:00 2008 From: bghita at jack.see.plymouth.ac.uk (Bogdan Ghita) Date: Tue Oct 7 03:31:37 2008 Subject: [Flow-tools] ftpdu_seq_check lost flows Message-ID: <001201c9284e$a5a51770$f0ef4650$@see.plymouth.ac.uk> Hello I'm running softflowd + flow-capture on a SuSE linux machine (Intel Celeron 3.2GHz CPU, 1GB RAM), with softflowd exporting to flow-capture locally via the loopback interface. Based on the /var/log/messages (see below), it seems that flow-capture drops (?) quite a few of the flows. The CPU and the memory are not maxed out and the machine is not running anything else. I've tried various fixes, including renice both flow-capture and softflowd. I also noticed that, for some reason, softflowd seems to be exporting data (most of the times) at one second past the minute - I'm not sure whether this is normal (or whether it can be changed), but it is likely to be putting some additional burden on the export process, as the activity is very bursty. Trying to capture the loopback traffic with tcpdump is even more worrying: at each one second past the minute tcpdump writes 32 packets than does nothing until the next minute, but it reports in the end thousands of lost packets (I've noticed that the interface type is reported EN10MB, but I'm not sure whether that is relevant or where I could change it) --- suse:/ # tcpdump -i lo -n -c 100 -w tmp.dump tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes 100 packets captured 10759 packets received by filter 10396 packets dropped by kernel --- So, any ideas why flow-capture seems to be dropping some/quite a bit of the data? Best regards Bogdan [.] 14:26:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406638931 received=1406644520 lost=5589 14:27:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406649084 received=1406663463 lost=14379 14:27:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406667986 received=1406676860 lost=8874 14:27:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406681381 received=1406690419 lost=9038 14:28:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406694939 received=1406697126 lost=2187 14:28:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406701639 received=1406704768 lost=3129 14:28:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406705742 received=1406732343 lost=26601 14:29:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406733293 received=1406745465 lost=12172 14:29:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406754215 received=1406776762 lost=22547 14:29:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406781291 received=1406792840 lost=11549 14:30:00 netflow flow-capture[27294]: STAT: now=1223299800 startup=1202406747 src_ip=127.0.0.1 dst_ip=127.0.0.1 d_ver=5 pkts=63516629 flows=1796718087 lost=4330166 reset=335275 filter_drops=0 14:30:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406802122 received=1406820941 lost=18819 14:31:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406823965 received=1406847591 lost=23626 14:31:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406852155 received=1406870846 lost=18691 14:31:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406875371 received=1406886191 lost=10820 14:31:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406890711 received=1406892804 lost=2093 14:32:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406897356 received=1406900343 lost=2987 14:32:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406904873 received=1406920897 lost=16024 14:32:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406925416 received=1406938234 lost=12818 14:33:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406944516 received=1406953467 lost=8951 14:33:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406957995 received=1406971996 lost=14001 14:34:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406976524 received=1406988011 lost=11487 14:34:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1406993540 received=1407018568 lost=25028 14:34:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1407019663 received=1407036331 lost=16668 14:35:00 netflow flow-capture[27294]: STAT: now=1223300100 startup=1202406747 src_ip=127.0.0.1 dst_ip=127.0.0.1 d_ver=5 pkts=63518578 flows=1796775650 lost=4330166 reset=335288 filter_drops=0 14:35:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1407040855 received=1407051221 lost=10366 14:35:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1407051929 received=1407078617 lost=26688 14:36:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1407079557 received=1407085158 lost=5601 14:36:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1407089689 received=1407109716 lost=20027 14:36:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1407110132 received=1407134873 lost=24741 14:37:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1407139405 received=1407145876 lost=6471 14:37:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1407146290 received=1407173718 lost=27428 14:38:01 netflow flow-capture[27294]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=127.0.0.1 d_version=5 expecting=1407174842 received=1407178461 lost=3619 [.] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.splintered.net/pipermail/flow-tools/attachments/20081007/2bc75928/attachment-0001.htm From i at stingr.net Tue Oct 7 10:35:51 2008 From: i at stingr.net (Paul P Komkoff Jr) Date: Tue Oct 7 10:36:02 2008 Subject: [Flow-tools] flow-tools on FreeBSD/amd64 In-Reply-To: <20081006163824.H71138@xmail01.inetu.net> References: <20081006163824.H71138@xmail01.inetu.net> Message-ID: <20081007143551.GA19187@stingr.net> Replying to Mark R.: > Are there any known issues with flow-tools on 64-bit platforms? I'm > trying to run 0.68 on FreeBSD 7.0/amd64 and running into some odd > behavior with flow-capture and flow-fanout. There is at least one known memory leak that only happens on 64-bit FreeBSD, that I still haven't fixed (mainly because it requires to set up FreeBSD somewhere). This one that you telling here is new. And it's serious, I wonder why nobody else seeing it. Maybe your kernel is broken? Or maybe it's ipv4-over-ipv6 issue? I don't have access to freebsd system to verify how recvmsg works there, sorry. -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From mark at inetu.net Tue Oct 7 11:29:18 2008 From: mark at inetu.net (Mark R.) Date: Tue Oct 7 11:29:21 2008 Subject: [Flow-tools] flow-tools on FreeBSD/amd64 In-Reply-To: <20081007143551.GA19187@stingr.net> References: <20081006163824.H71138@xmail01.inetu.net> <20081007143551.GA19187@stingr.net> Message-ID: <20081007111651.P39399@xmail01.inetu.net> Paul, This is where I'm picking up the garbage data: ftnet.loc_addr.sin_addr.s_addr = ftnet.msgip.ip.s_addr The kernel is GENERIC plus IPFW. Nothing terribly oddball. I'm wondering if this is a variable type issue somewhere. Running a 32bit build on amd64 and the same box doesn't exhibit this issue. If you care to look into this, I can provide access to the box in question. If not, I'll might eventually figure it out. I'm not at the point of caring about a memory leak. When I get there, I can run it through valgrind. Thanks, Mark On Tue, 7 Oct 2008, Paul P Komkoff Jr wrote: > Replying to Mark R.: >> Are there any known issues with flow-tools on 64-bit platforms? I'm >> trying to run 0.68 on FreeBSD 7.0/amd64 and running into some odd >> behavior with flow-capture and flow-fanout. > > There is at least one known memory leak that only happens on 64-bit > FreeBSD, that I still haven't fixed (mainly because it requires to set up > FreeBSD somewhere). > > This one that you telling here is new. And it's serious, I wonder why > nobody else seeing it. Maybe your kernel is broken? > Or maybe it's ipv4-over-ipv6 issue? > I don't have access to freebsd system to verify how recvmsg works > there, sorry. > > -- > Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key > This message represents the official view of the voices in my head > From mark at inetu.net Tue Oct 7 14:53:09 2008 From: mark at inetu.net (Mark R.) Date: Tue Oct 7 14:53:11 2008 Subject: [Flow-tools] flow-tools on FreeBSD/amd64 Message-ID: <20081007145244.I39399@xmail01.inetu.net> Paul, Upon further investigation, it appears as if there is an alignment issue in 'struct msgip' inside of 'struct ftnet'. I've looked at some other code, and there appear to be a handful of useful CMSG_* macros to help deal with this. RFC 2292 details them. The attached patch works cleanly on my system and fixes the issue at hand. Hopefully it doesn't break other platforms. It's there for anybody who is interested. Thanks, Mark On Tue, 7 Oct 2008, Mark R. wrote: > > Paul, > > This is where I'm picking up the garbage data: > > ftnet.loc_addr.sin_addr.s_addr = ftnet.msgip.ip.s_addr > > The kernel is GENERIC plus IPFW. Nothing terribly oddball. I'm wondering if > this is a variable type issue somewhere. Running a 32bit build on amd64 and > the same box doesn't exhibit this issue. > > If you care to look into this, I can provide access to the box in question. > If not, I'll might eventually figure it out. > > I'm not at the point of caring about a memory leak. When I get there, I can > run it through valgrind. > > Thanks, > Mark > > On Tue, 7 Oct 2008, Paul P Komkoff Jr wrote: > >> Replying to Mark R.: >>> Are there any known issues with flow-tools on 64-bit platforms? I'm >>> trying to run 0.68 on FreeBSD 7.0/amd64 and running into some odd >>> behavior with flow-capture and flow-fanout. >> >> There is at least one known memory leak that only happens on 64-bit >> FreeBSD, that I still haven't fixed (mainly because it requires to set up >> FreeBSD somewhere). >> >> This one that you telling here is new. And it's serious, I wonder why >> nobody else seeing it. Maybe your kernel is broken? >> Or maybe it's ipv4-over-ipv6 issue? >> I don't have access to freebsd system to verify how recvmsg works >> there, sorry. >> >> -- >> Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key >> This message represents the official view of the voices in my head >> > _______________________________________________ > Flow-tools mailing list > flow-tools@splintered.net > http://mailman.splintered.net/mailman/listinfo/flow-tools -------------- next part -------------- --- lib/ftlib.h-orig 2008-03-09 13:09:01.000000000 +0000 +++ lib/ftlib.h 2008-10-07 17:41:11.000000000 +0000 @@ -459,11 +459,16 @@ int fd; /* fd receiving flows on */ struct mymsghdr msg; /* recvmsg data */ struct { - struct cmsghdr hdr; #ifdef IP_RECVDSTADDR +#ifdef CMSG_DATA + char cbuf[CMSG_SPACE(sizeof(struct sockaddr_storage))]; +#else + struct cmsghdr hdr; struct in_addr ip; +#endif /* CMSG_DATA */ #else #ifdef IP_PKTINFO + struct cmsghdr hdr; struct in_pktinfo pktinfo; #endif /* else */ #endif /* IP RECVDSTADDR */ --- src/flow-fanout.c-orig 2008-01-27 20:48:55.000000000 +0000 +++ src/flow-fanout.c 2008-10-07 17:42:33.000000000 +0000 @@ -124,6 +124,11 @@ int i, n, detach, one, ret, offset, hdr_len; int npeers, tx_delay; int stat_interval, stat_next, src_ip_spoof; +#ifdef IP_RECVDSTADDR +#ifdef CMSG_DATA + struct cmsghdr *cmsg; +#endif +#endif time_startup = time((time_t)0L); @@ -625,12 +630,24 @@ #ifdef IP_RECVDSTADDR /* got destination IP back? */ +#ifdef CMSG_DATA + for (cmsg = CMSG_FIRSTHDR(&ftnet.msg); cmsg != NULL; + cmsg = CMSG_NXTHDR(&ftnet.msg, cmsg)) { + if (cmsg->cmsg_level == IPPROTO_IP && + cmsg->cmsg_type == IP_RECVDSTADDR) { + memcpy(&ftnet.loc_addr.sin_addr.s_addr, + CMSG_DATA(cmsg), sizeof(struct in_addr)); + break; + } + } +#else if ((ftnet.msgip.hdr.cmsg_level == IPPROTO_IP) && (ftnet.msgip.hdr.cmsg_type == IP_RECVDSTADDR)) { ftnet.loc_addr.sin_addr.s_addr = ftnet.msgip.ip.s_addr; } else { ftnet.loc_addr.sin_addr.s_addr = 0; } +#endif /* CMSG_DATA */ #else #ifdef IP_PKTINFO if ((ftnet.msgip.hdr.cmsg_level == IPPROTO_IP) && --- src/flow-receive.c-orig 2008-01-27 20:48:55.000000000 +0000 +++ src/flow-receive.c 2008-10-07 17:42:35.000000000 +0000 @@ -93,6 +93,11 @@ char fmt_src_ip[32], fmt_dst_ip[32], fmt_dst_port[32]; char xl_rec[FT_IO_MAXREC], *out_rec; int stat_interval, stat_next; +#ifdef IP_RECVDSTADDR +#ifdef CMSG_DATA + struct cmsghdr *cmsg; +#endif +#endif time_startup = time((time_t)0L); @@ -488,12 +493,24 @@ #ifdef IP_RECVDSTADDR /* got destination IP back? */ +#ifdef CMSG_DATA + for (cmsg = CMSG_FIRSTHDR(&ftnet.msg); cmsg != NULL; + cmsg = CMSG_NXTHDR(&ftnet.msg, cmsg)) { + if (cmsg->cmsg_level == IPPROTO_IP && + cmsg->cmsg_type == IP_RECVDSTADDR) { + memcpy(&ftnet.loc_addr.sin_addr.s_addr, + CMSG_DATA(cmsg), sizeof(struct in_addr)); + break; + } + } +#else if ((ftnet.msgip.hdr.cmsg_level == IPPROTO_IP) && (ftnet.msgip.hdr.cmsg_type == IP_RECVDSTADDR)) { ftnet.loc_addr.sin_addr.s_addr = ftnet.msgip.ip.s_addr; } else { ftnet.loc_addr.sin_addr.s_addr = 0; } +#endif /* CMSG_DATA */ #else #ifdef IP_PKTINFO if ((ftnet.msgip.hdr.cmsg_level == IPPROTO_IP) && --- src/flow-capture.c-orig 2008-01-27 20:48:55.000000000 +0000 +++ src/flow-capture.c 2008-10-07 17:42:30.000000000 +0000 @@ -170,6 +170,11 @@ int stat_interval, stat_next, child_status; int v_flag; int preserve_umask; +#ifdef IP_RECVDSTADDR +#ifdef CMSG_DATA + struct cmsghdr *cmsg; +#endif +#endif time_startup = time((time_t)0L); @@ -621,7 +626,12 @@ ftnet.msg.msg_name = &ftnet.rem_addr; ftnet.msg.msg_namelen = sizeof ftnet.rem_addr; ftnet.msg.msg_control = &ftnet.msgip; + +#ifdef CMSG_DATA + ftnet.msg.msg_controllen = CMSG_LEN(sizeof(struct sockaddr_storage)); +#else ftnet.msg.msg_controllen = sizeof ftnet.msgip; +#endif while (1) { @@ -853,12 +863,24 @@ #ifdef IP_RECVDSTADDR /* got destination IP back? */ +#ifdef CMSG_DATA + for (cmsg = CMSG_FIRSTHDR(&ftnet.msg); cmsg != NULL; + cmsg = CMSG_NXTHDR(&ftnet.msg, cmsg)) { + if (cmsg->cmsg_level == IPPROTO_IP && + cmsg->cmsg_type == IP_RECVDSTADDR) { + memcpy(&ftnet.loc_addr.sin_addr.s_addr, + CMSG_DATA(cmsg), sizeof(struct in_addr)); + break; + } + } +#else if ((ftnet.msgip.hdr.cmsg_level == IPPROTO_IP) && (ftnet.msgip.hdr.cmsg_type == IP_RECVDSTADDR)) { ftnet.loc_addr.sin_addr.s_addr = ftnet.msgip.ip.s_addr; } else { ftnet.loc_addr.sin_addr.s_addr = 0; } +#endif /* CMSG_DATA */ #else #ifdef IP_PKTINFO if ((ftnet.msgip.hdr.cmsg_level == IPPROTO_IP) && From kuleshov at org.vrn.ru Tue Oct 28 18:43:31 2008 From: kuleshov at org.vrn.ru (Maxim Kuleshov) Date: Tue Oct 28 18:43:46 2008 Subject: [Flow-tools] limit for number of filter elements Message-ID: <20081029014331.2cb23022@kme-laptop> Hello! Is there any limitation for number of 'permit' elements in filter-primitive or for number of filter primitives in filter definition? i.g. I want to run flow-capture with tens of thousands IPs to filter. What search algorithm used for find matching IP? Is performance degrades linear or logarithmic depending on number of IPs? From jloiacon at csc.com Wed Oct 29 13:51:19 2008 From: jloiacon at csc.com (Joe Loiacono) Date: Wed Oct 29 13:51:33 2008 Subject: [Flow-tools] limit for number of filter elements In-Reply-To: <20081029014331.2cb23022@kme-laptop> Message-ID: I know I've never had trouble with hundreds of port numbers. Joe Maxim Kuleshov Sent by: flow-tools-bounces@list.splintered.net 10/28/2008 06:43 PM To flow-tools@list.splintered.net cc Subject [Flow-tools] limit for number of filter elements Hello! Is there any limitation for number of 'permit' elements in filter-primitive or for number of filter primitives in filter definition? i.g. I want to run flow-capture with tens of thousands IPs to filter. What search algorithm used for find matching IP? Is performance degrades linear or logarithmic depending on number of IPs? _______________________________________________ Flow-tools mailing list flow-tools@splintered.net http://mailman.splintered.net/mailman/listinfo/flow-tools -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.splintered.net/pipermail/flow-tools/attachments/20081029/f333072b/attachment.htm