Alex, thanks for the quick reply. After reading your email I
downloaded the 0.68 source tarball from splintered.net. FYI, md5sum
shows this is identical to the source tarball that the Fedora Core
Extras SRPM begins its build internally from.
Low and behold, simply stringing together ./configure and make
produced binaries that are working for me! Something w/ the Fedora
Core Extras SRPM is clearly broken. I've been investigating what the
issue is w/ the binary and SRPMS from Fedora Core Extras but don't
have anything solid yet. Presently, I suspect the problem lies in a
particular patch being applied during RPM build. I can reproduce
without using rpmbuild by untarring the vanilla source and applying
the SRPM patches, then proceeding w/ a build.
Compiling the problem source w/ your debug patch gives the following
upon receipt of 500 V5 test flows:
[EMAIL PROTECTED] flow-tools]# flow-receive 0/0/2550 | flow-print
flow-receive: setsockopt(size=4194304)
flow-receive: pdu received size was wrong. expected 1492 got 1464
flow-receive: ftpdu_verify(): src_ip=127.0.0.1 failed.
flow-receive: pdu received size was wrong. expected 1492 got 1464
flow-receive: ftpdu_verify(): src_ip=127.0.0.1 failed.
flow-receive: pdu received size was wrong. expected 1492 got 1464
flow-receive: ftpdu_verify(): src_ip=127.0.0.1 failed.
flow-receive: pdu received size was wrong. expected 1492 got 1464
flow-receive: ftpdu_verify(): src_ip=127.0.0.1 failed.
flow-receive: pdu received size was wrong. expected 1492 got 1464
flow-receive: ftpdu_verify(): src_ip=127.0.0.1 failed.
flow-receive: pdu received size was wrong. expected 1492 got 1464
flow-receive: ftpdu_verify(): src_ip=127.0.0.1 failed.
flow-receive: pdu received size was wrong. expected 1012 got 984
flow-receive: ftpdu_verify(): src_ip=127.0.0.1 failed.
So, for some reason flow-receive thinks it is receiving truncated
Netflow PDUs?
I've reproduced this between two different hosts on a LAN, so I don't
think the issue is the use of loopback / localhost connections.
To summarize, I've got the tools working after building from the
source tarball. I'm working on a fix for the Fedora Core RPMs and
will submit upstream to the package maintainer and post here when I
have something more.
Regards,
Ben Feinstein, CISSP
On Mar 23, 2006, at 11:35 PM, Alex Shepard wrote:
Ben,
I've got almost no experience with the RPM and SRPMs that you're
using, but what you're trying to do works on both of the boxes I
run flow-tools on (my test laptop running Mac OS X and flow-tools
0.68 and my collector running a moderately patched FC2 and flow-
tools 0.66, both built from splintered.net source). As for what
exactly is going wrong, you could try applying the attached patch,
which should give you more information about why ftpdu_verify() is
failing.
To apply, save off the attached patch somewhere, cd to your flow-
tools source directory and do "patch -p1 </path/to/ftdecode.patch",
then make clean and make. You can't skip the make clean step
because the patch is for a library function that flow-receive
calls, and make doesn't automagically know about that dependency.
You shouldn't need to do a make install, just call the patched flow-
receive and flow-print, they should be in the src/ directory unless
your SRPMs have specified an alternate build directory.
Once you've patched and remade sources, you should see an
additional line about why the netflow pdus aren't being decoded
correctly, such as:
xenith:~ alexs$ flow-receive 0/0/9800 | flow-print
flow-receive: setsockopt(size=231424)
flow-receive: ftpdu version not set.
flow-receive: ftpdu_verify(): src_ip=127.0.0.1 failed.
<ftdecode.patch>
That might help you figure out why it's actually failing. Or it
may not.
HTH,
alex
_______________________________________________
Flow-tools mailing list
[EMAIL PROTECTED]
http://mailman.splintered.net/mailman/listinfo/flow-tools
