I would try svn, I can't say what's actually in the tar. Agree with you on ports. Makes me long for the day of static/monolythic exe's. Can't understand why some developers insist on using a library with two dozen other dependancies for one simple function! But I digress...
----- Original Message ----- From: [email protected] <[email protected]> To: [email protected] <[email protected]> Sent: Thu Apr 29 21:37:21 2010 Subject: Re: [Ntop] No data in Netflow on FreeBSD 7.0 Hmm, well, when would have been within the past two weeks, maybe Wednesday last, where - I'm 95% sure from ntop.org. Tar ball, not SVN. we generally stay away from ports because of the lack of control over dependencies. I was going to do the port, but it started pulling rrdtool, which I already have from source. I'll figure out how to convince the port to use my version of rrdtool tomorrow and give it a try. On 04/29/2010 10:20 PM, Gary Gatten wrote: > Where/when did you get your source? I wanna diff with mine. > > ----- Original Message ----- > From: [email protected]<[email protected]> > To: [email protected]<[email protected]> > Sent: Thu Apr 29 21:06:00 2010 > Subject: Re: [Ntop] No data in Netflow on FreeBSD 7.0 > > Recompiled with 3 DEBUG defines uncommented in netflowPlugin.c > > Restarting shows the Netflow device being initialized and mapped to an > ntop device, then after everything else is setup, I see my one packet, > than nothing else: > > Apr 29 21:45:53 netmon ntop[49722]: NETFLOW_DEBUG: Received NetFlow > packet(len=1272)(deviceId=1) > Apr 29 21:45:53 netmon ntop[49722]: NETFLOW: dissectFlow(len=1272, > device=1) [flow packet=1] > Apr 29 21:45:53 netmon ntop[49722]:>>>> NETFLOW: handleGenericFlow() called > Apr 29 21:45:53 netmon ntop[49722]: NETFLOW_DEBUG: a=3232235792 > Apr 29 21:45:53 netmon ntop[49722]: DEBUG: 192.168.1.16:0 -> > 192.168.100.23:771 [last=923276096][first=923276096][last-first=0] > Apr 29 21:46:01 netmon ntop[49722]: IDLE_PURGE: Device 0 [em0] > FINISHED selection, 0 [out of 4] hosts selected > Apr 29 21:46:01 netmon ntop[49722]: IDLE_PURGE: Device em0: no hosts > [out of 3] deleted > Apr 29 21:46:01 netmon ntop[49722]: IDLE_PURGE: Device 1 > [NetFlow-device.2] FINISHED selection, 0 [out of 4] hosts selected > > The sequence of RRD cycles and IDLE_PURGEs then continues, with no more > packets. > > I'm happy to post more logging, but I figure if anyone really wants > pages of logs, they'll let me know. > > And that's enough for me tonight. > > tim > > On 04/29/2010 09:30 PM, Tim Palmer wrote: > >> I'll give the debug recompile a shot. I'm no coder, but I suspect I >> can find the debug code. >> >> I should have mentioned - I had this same machine working last week >> with 3.3.10, also under FBSD 7.0, but p9 rather than p12 as now, >> although if I ran in daemon mode, I got the infamous "kevent: Bad file >> descriptor" messages. I really wanted daemon mode, so tried the >> "rfork" change from >> http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030105.html. >> That gave me the same results I'm getting now - nice screens, no >> errors, and no data. The box's RAID died a horrible death over the >> weekend, and I'm working on a rebuild. >> >> I hate that feeling when I'm having a problem no one else seems to >> have. Makes me think I'm missing something simple, but I just can't >> mail it. >> >> thanks again for your time, >> >> tim >> >> On 04/29/2010 08:22 PM, Gary Gatten wrote: >> >>> I used to run on FBSD 6, but now RHEL5 so don't know first hand of >>> issues with FBSD anymore. My understanding is it *works* fine. I >>> know there is some logic in the code to do somethings different if OS >>> is FBSD, maybe that is broken? If you like source, there are several >>> places in the code to enable DEBUG output, starting in >>> globals-defines.h, but also within the netflow plugin module code. >>> It will spew a $HITLOAD of messages, so maybe build it with a >>> different prefix and only run for a few seconds. I'll try to think >>> of something else.... MAYBE try the port just to see if it works and >>> if so diff the code? >>> >>> ----- Original Message ----- >>> From: >>> [email protected]<[email protected]> >>> To: [email protected]<[email protected]> >>> Sent: Thu Apr 29 18:55:34 2010 >>> Subject: Re: [Ntop] No data in Netflow on FreeBSD 7.0 >>> >>> Thanks for the quick reply(s) >>> >>> "Sounds like you tried most everything." >>> <sigh> yeah, that's what I thought. >>> >>> Interface is selected. Netflow statistics says 1 packet in, 1 out, 40 >>> bytes, 1 flow. Nothing in any of the v1/v5/v9 rows, nothing except "1 >>> flow processed" in the Discarded section. >>> >>> running as root, with -t 5 doesn't show me anything I can identify as a >>> problem - This is the log section that seems most relevant: >>> >>> Apr 29 19:40:30 netmon ntop[37164]: Now running as requested user >>> 'root' (0:0) >>> Apr 29 19:40:30 netmon ntop[37164]: Device 0. >>> em0 (active) >>> Apr 29 19:40:30 netmon ntop[37164]: Device 1. >>> NetFlow-device.2 (active) >>> Apr 29 19:40:30 netmon ntop[37164]: Note: Reporting device initally >>> set to 1 [NetFlow-device.2] >>> Apr 29 19:40:30 netmon ntop[37164]: MEMORY: Base interface structure >>> (no hashes loaded) is 0.33MB each >>> Apr 29 19:40:30 netmon ntop[37164]: MEMORY: or 0.65MB for 2 >>> interfaces >>> Apr 29 19:40:30 netmon ntop[37164]: MEMORY: ipTraffixMatrix structure >>> (no TrafficEntry loaded) is 0.36MB >>> Apr 29 19:40:30 netmon ntop[37164]: THREADMGMT[t34412171552]: ntop >>> RUNSTATE: RUN(4) >>> Apr 29 19:40:30 netmon ntop[37164]: THREADMGMT[t34412176704]: NPS(1): >>> Started thread for network packet sniffing [em0] >>> Apr 29 19:40:30 netmon ntop[37164]: THREADMGMT[t34412176704]: >>> NPS(em0): pcapDispatch thread starting [p37164] >>> Apr 29 19:40:30 netmon ntop[37164]: THREADMGMT[t34412175968]: NETFLOW: >>> (port 9990) thread running [p37164] >>> >>> and: >>> >>> Apr 29 19:40:55 netmon ntop[37164]: RRD: Cycle 0 ended, 38 RRDs >>> updated, 0.037 seconds >>> Apr 29 19:40:55 netmon ntop[37164]: RRD_DEBUG: Sleeping for 300 >>> seconds (interval 300, end at Thu Apr 29 19:45:55 2010) >>> Apr 29 19:43:04 netmon ntop[37164]: SECURITY: Loading items table >>> Apr 29 19:45:57 netmon ntop[37164]: RRD: Cycle 1 ended, 18 RRDs >>> updated, 0.006 seconds >>> >>> tim >>> >>> On 04/29/2010 06:32 PM, Gary Gatten wrote: >>> >>>> Also, try running as root to rule out perms and maybe start with -t >>>> 5 and hope to get some useful messages in the log. >>>> >>>> -----Original Message----- >>>> From: [email protected] >>>> [mailto:[email protected]] On Behalf Of Gary Gatten >>>> Sent: Thursday, April 29, 2010 4:58 PM >>>> To: '[email protected]' >>>> Subject: Re: [Ntop] No data in Netflow on FreeBSD 7.0 >>>> >>>> Sounds like you tried most everything. >>>> >>>> What does "Plugins> Netflow> Statistics" show? >>>> >>>> Also, have you "Selected" the interface? "Admin> Switch NIC" and >>>> actually choose your netflow interface? >>>> >>>> G >>>> >>>> >>>> -----Original Message----- >>>> From: [email protected] >>>> [mailto:[email protected]] On Behalf Of Tim Palmer >>>> Sent: Thursday, April 29, 2010 4:34 PM >>>> To: [email protected] >>>> Subject: [Ntop] No data in Netflow on FreeBSD 7.0 >>>> >>>> Good Day, >>>> >>>> I'm trying to get ntop working on a FreeBSD 7.0 amd64 box. I've had >>>> problems compiling 3.3.10, so tried 3.4pre3. >>>> >>>> I'm only interested in seeing data on a NetFlow interface. Nothing >>>> local >>>> is needed. However, I'm seeing similar behavior on eth0, only the >>>> Traffic Statistics table on the Summary Traffic page show very many >>>> packets dropped by libpcap. >>>> >>>> Compile and installation work fine. Ntop starts fine, web interface is >>>> fully functional. Netflow plugin is enabled and active. But there is >>>> only one packet shown for the NetFlow device, no packets dropped by >>>> ntop. I *believe* I've tried all ip address configuration options. Most >>>> other settings are default. Running in daemon mode does not produce any >>>> warnings on the console. Listen port is not default, and I've >>>> configured >>>> in the web UI, not spec >>>> >>>> started with {prefix}/bin/ntop -w 81 -u ntop -L -d >>>> >>>> tcpdump shows data coming in on the port I'm expecting it. Ethereal >>>> confirms they are legit netflow/cflow packets. >>>> >>>> sockstat shows ntop listening on the udp4 port expected. >>>> >>>> disabling ipfw doesn't help. >>>> >>>> Files are created in {prefix}/var/ntop/rrd/interfaces/NetFlow-device.2. >>>> They are being updated, but only with NANs or 0.000 entries. >>>> >>>> Netflow statistics page in the web UI shows just the one packet, >>>> 56bytes. No dropped flows or other problems. >>>> >>>> We prefer to compile from source, so haven't tried the port yet. >>>> >>>> rrdtool is 1.4, compiled from source. Cacti is also on this box, and >>>> has >>>> no problem w/ rrdtool. >>>> perl is 5.10.0 >>>> >>>> flow-capture is also in use on this box (for other devices, on other >>>> ports) and is working properly. >>>> >>>> I'm at a loss. If there's more information I can provide, I am most >>>> happy to do so. >>>> >>>> Kernel is custom. I have not yet tried with GENERIC, but try that next. >>>> >>>> FreeBSD xxx.xxx.xxx 7.0-RELEASE-p12 FreeBSD 7.0-RELEASE-p12 #0: Wed Apr >>>> 28 17:46:20 EDT 2010 >>>> [email protected]:/usr/obj/usr/src/sys/NETMON amd64 >>>> >>>> Thank you very much for your time. I'm sort of hoping this is just >>>> something stupid I'm missing. >>>> >>>> Tim Palmer >>>> _______________________________________________ >>>> Ntop mailing list >>>> [email protected] >>>> http://listgateway.unipi.it/mailman/listinfo/ntop >>>> _______________________________________________ >>>> Ntop mailing list >>>> [email protected] >>>> http://listgateway.unipi.it/mailman/listinfo/ntop >>>> _______________________________________________ >>>> Ntop mailing list >>>> [email protected] >>>> http://listgateway.unipi.it/mailman/listinfo/ntop >>>> >>>> >>>> >>> _______________________________________________ >>> Ntop mailing list >>> [email protected] >>> http://listgateway.unipi.it/mailman/listinfo/ntop >>> _______________________________________________ >>> Ntop mailing list >>> [email protected] >>> http://listgateway.unipi.it/mailman/listinfo/ntop >>> >>> >> _______________________________________________ >> Ntop mailing list >> [email protected] >> http://listgateway.unipi.it/mailman/listinfo/ntop >> >> > _______________________________________________ > Ntop mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop > _______________________________________________ > Ntop mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop > > _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
