You need to try reading the documentation that comes with ntop before posting here... As I say in the "HOWTO ask for help", it's self-help - you're going to have to do most of the work (and that includes reading and thinking). If you can't/won't, then neither ntop nor any other Open Source tool is for you.
docs/BUILD-NTOP.txt explains how to generate the configure script -- when he built the .tgz, Dennis chose not to put a pre-build configure file in there because NOT including it eliminates an entire class of problems. Luca made the other choice in the cvs, so I follow his lead. The 2.1.3 .tgz I the one Dennis provided, so I followed his lead there. Either way, I have ALWAYS recommended running ./autogen.sh -1, no matter WHAT environment you're running in. gdb? You mean gdbm, right? ./configure --help will show you all the available parameters, including --with-gdbm-root= "Yes but there is a problem, the redirection specifically puts all the error output to /dev/null =) So kind of chicken egg problem ;)" What's the problem? You run it in an xterm and use the scroll back buffer to see the messages. In a normal ntop, even w/ trace level 3, there isn't much chatter when you're running, just during startup. This isn't a plan for normally running, it's to see the error messages. You could redirect to files, fer gosh's sake - we're trying to SEE the messages instead of just throwing them away. I don't care about the mechanism, it's the messages that are important. You say you ran "-i dc0 dc1 and then -i dc1 dc2" did you really type "-i dc0 dc1" or was it "-i dc0,dc1" (it makes a heck of a difference to getopt/getopt_long)? "Well this only happens when I redirect fd 2 to 1 so maybe there is something about it confusing pcap somehow?" Shouldn't that be equiv to > /dev/null 2> /dev/null ? There is only so much help we can provide w/ ntop. If it's a pcap problem, you'll need to be talking to the pcap people and if it's a FreeBSD redirection, then well, talk to FreeBSD... -----Original Message----- From: Evren Yurtesen [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 22, 2002 4:02 AM To: Burton M. Strauss III Cc: [EMAIL PROTECTED] Subject: RE: [Ntop] -M option (all info attached) On Sat, 21 Sep 2002, Burton M. Strauss III wrote: > OK, what can we pull out... understand that I'm groping here... > > 1. OS is i386-portbld-freebsd4.7 (4.6.2 is the latest, so this is a beta > OS) Well actually it is not a release but also not a beta os. I am following the FreeBSD stable branch with cvsup. The current branch can be thought as beta. The code which is assumed stable is moved from current to stable and then every 3-4 months this stable code is released as 'binary' release for people who use binary upgrade method instead of cvsup. > 2. 2.0.99-rc2 is obsolete. It wasn't quite the version that became 2.1, > which is, itself obsolete. The current versions are 2.1.51 (development) > and 2.1.3 (stable). Please try one of those. I have downloaded 2.1.3 from sourceforge but it seems that there is no configure script inside?! I downloaded 2.1.2 now but I have had problems compiling, I will try it again later next week. Actually the problem is that the configure script is not able to find gdblib. they are in /usr/local/lib and /usr/local/include in freebsd, when they are installed in freebsd ports. Evren > 2. > Without redirection... looks perfectly normal... > > Sep 21 14:07:33 joke /kernel: dc1: promiscuous mode enabled > ... > Sep 21 14:07:34 joke ntop[20796]: Started thread (138583040) for network > packet sniffing on dc1. > ... > Sep 21 14:10:10 joke ntop[20803]: Freeing device dc1 (idx=1)... > Sep 21 14:10:10 joke ntop[20803]: 87 packets received by filter on dc1 > Sep 21 14:10:10 joke ntop[20803]: 0 packets dropped by kernel > Sep 21 14:10:10 joke ntop[20803]: 0 packets dropped by ntop > Sep 21 14:10:10 joke ntop[20803]: 87 packets received by filter on dc1 > > With redirection... > Sep 21 14:04:25 joke /kernel: dc1: promiscuous mode enabled > ... > Sep 21 14:04:27 joke ntop[20777]: Started thread (138583040) for network > packet sniffing on dc1. > ... > Sep 21 14:05:31 joke ntop[20777]: Freeing device dc1 (idx=1)... > Sep 21 14:05:31 joke ntop[20777]: 590 packets received by filter on dc1 > Sep 21 14:05:31 joke ntop[20777]: 384 packets dropped by kernel > Sep 21 14:05:31 joke ntop[20777]: 0 packets dropped by ntop > > Interesting... why is the KERNEL dropping packets. That line comes DIRECTLY > out of libpcap: > > traceEvent(TRACE_INFO, "%s packets dropped by kernel\n", > formatPkts((Counter)pcapStat.ps_drop)); > > My guess is that there is something wrong with libpcap. > > The loop in ntop.c: > > > for(;myGlobals.capturePackets == 1;) { > FD_ZERO(&readMask); > FD_SET(pcap_fd, &readMask); > > /* timeout.tv_sec = 5, timeout.tv_usec = 0; */ > > if(select(pcap_fd+1, &readMask, NULL, NULL, NULL /* &timeout */ ) > 0) { > /* printf("dispatch myGlobals.device %s\n", > myGlobals.device[i].name);*/ > if(!myGlobals.capturePackets) return(NULL); > rc = pcap_dispatch(myGlobals.device[i].pcapPtr, 1, processPacket, > (u_char*)_i); > > if(rc == -1) { > traceEvent(TRACE_ERROR, "Error while reading packets: %s.\n", > pcap_geterr(myGlobals.device[i].pcapPtr)); > break; > } else if((rc == 0) && (myGlobals.rFileName != NULL)) { > traceEvent(TRACE_INFO, "pcap_dispatch returned %d " > "[No more packets to read]", rc); > break; /* No more packets to read */ > } > /* else > traceEvent(TRACE_INFO, "1) %d\n", numPkts++); > */ > } > } > > So once ntop has that error, it stops capturing on that interface... (note > the break). > > > TODO: > > Try 2.1.3 or 2.1.50/51. > > Try running ntop in the forground, i.e. with -K and without -d. That way > you should be able to see if there are other (printf) messages being > generated (maybe from libpcap). Yes but there is a problem, the redirection specificly puts all the error output to /dev/null =) So kind of chicken egg problem ;) > Try running with just -i dc1 and try running with all 4, but change the > order around (Let's see if it's the interface or the position in the list) Well I already tried running -i dc0 dc1 and then -i dc1 dc2 the latter one produced the error on dc2 interface. > Try changing the break to continue in the loop in ntop.c... I don't think > it's a good idea as a perm fix, but at least we'll know how many times it's > happening... (although if you read the man page on pcap: > > pcap_dispatch() is used to collect and process packets. > cnt specifies the maximum number of packets to process > before returning. This is not a minimum number; when > reading a live capture, only one bufferful of packets is > read at a time, so fewer than cnt packets may be pro- > cessed. A cnt of -1 processes all the packets received in > one buffer when reading a live capture, or all the packets > in the file when reading a ``savefile''. callback speci- > fies a routine to be called with three arguments: a u_char > pointer which is passed in from pcap_dispatch(), a pointer > to the pcap_pkthdr struct (which precede the actual net- > > NOTE: when reading a live capture, pcap_dispatch() will > not necessarily return when the read times out; on some > platforms, the read timeout isn't supported, and, on other > platforms, the timer doesn't start until at least one > packet arrives. This means that the read timeout should > NOT be used in, for example, an interactive application, > to allow the packet capture loop to ``poll'' for user > input periodically, as there's no guarantee that pcap_dis- > patch() will return after the timeout expires. > > pcap_loop() is similar to pcap_dispatch() except it keeps > reading packets until cnt packets are processed or an > error occurs. It does not return when live read timeouts > occur. Rather, specifying a non-zero read timeout to > pcap_open_live() and then calling pcap_dispatch() allows > the reception and processing of any packets that arrive > when the timeout occurs. A negative cnt causes > pcap_loop() to loop forever (or at least until an error > occurs). > > maybe it is a solution -- could this just be that FreeBSD is honoring the > timeout on a low usage interface??? Have to think about that... probably > not, since the timeout message should say "timeout" in it.) Well this only happens when I redirect fd 2 to 1 so maybe there is something about it confusing pcap somehow? > -----Burton > > -----Original Message----- > From: Evren Yurtesen [mailto:[EMAIL PROTECTED]] > Sent: Saturday, September 21, 2002 9:17 AM > To: Burton M. Strauss III > Cc: [EMAIL PROTECTED] > Subject: RE: [Ntop] -M option (all info attached) > > > Yes ok I include all the info. I am sure there is traffic in dc1 (the > problem was in dc1) because there is a web server behind it and I > connected it after starting ntop. When I don't have redirection the ntop > is showing the traffic between the server and my machine. > > Ntop is installed from the ports collection of FreeBSD, > Here is my uname -a output > FreeBSD joke.ispro.net.tr 4.7-PRERELEASE FreeBSD 4.7-PRERELEASE #0: Sat > Sep 14 22:39:03 EEST 2002 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/JOKE i386 > > The rest of the things like log messages etc is attached. The compilation > output, the sh script of FreeBSD and log copies from /var/log/messages > But the thing I realized is that when I put the redirection then I get > this error message in the logs > > Sep 21 14:12:03 joke ntop[20812]: Error while reading packets: read: Bad > file descriptor. > > The redirection was >/dev/null 2>&1 > > Plus I have realized the situation occurs when I only identify 2 ethernet > cards with -i option, only the second one is effected. It doesnt occur > when I identify one ethernet card with -i option. > > Thanks > Evren > > > > On Fri, 20 Sep 2002, Burton M. Strauss III wrote: > > > Again, see HOWTO ask for help at snapshot. You've still never given any > of > > the general information I ask for. Until you do so, I will not provide > any > > more assistance. > > > > I have no clue what redirection you keep harping on. As far as I know the > > only "script" for running ntop is for RedHat Linux in the rpm. Maybe you > > should post your script and tell us where you got it from. > > > > There are a lot of startup messages in the log, which are what I was > asking > > you to post. However, running ntop interactively, there are sometimes > other > > printf() messages which you don't see in the log. > > > > Off hand, there's nothing odd about dc2 -- silly ? but are you sure there > is > > traffic there? > > > > -----Burton > > > > -----Original Message----- > > From: Evren Yurtesen [mailto:[EMAIL PROTECTED]] > > Sent: Friday, September 20, 2002 1:37 AM > > To: Burton M. Strauss III > > Cc: [EMAIL PROTECTED] > > Subject: RE: [Ntop] -M option > > > > > > Hi, Here is the output of ifconfig. I changed some ip addresses with x,y > > variables. I think I can live with this error since there is a simple fix > > of removing the redirection. I just thought if this is a bug then it could > > be beneficial to fix it. > > > > Evren > > > > dc0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 > > inet x.x.x.58 netmask 0xffffffe0 broadcast x.x.x.63 > > ether 00:80:ad:88:c0:fc > > media: Ethernet autoselect (100baseTX <full-duplex>) > > status: active > > dc1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 > > inet x.x.y.30 netmask 0xfffffff8 broadcast x.x.y.31 > > ether 00:80:ad:88:ca:73 > > media: Ethernet autoselect (100baseTX <full-duplex>) > > status: active > > dc2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 > > inet 192.168.2.254 netmask 0xffffff00 broadcast 192.168.2.255 > > ether 00:80:ad:3c:38:49 > > media: Ethernet autoselect (100baseTX <full-duplex>) > > status: active > > dc3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 > > inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255 > > ether 00:80:ad:7b:6a:59 > > media: Ethernet autoselect (100baseTX <full-duplex>) > > status: active > > ed1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 > > inet x.x.x.y.22 netmask 0xfffffff8 broadcast x.x.y.23 > > ether 00:20:18:61:40:1f > > ed2: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 > > ether 00:20:18:61:40:33 > > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 > > inet 127.0.0.1 netmask 0xff000000 > > > > > > > > On Thu, 19 Sep 2002, Burton M. Strauss III wrote: > > > > > No clue ... post info ... see HOWTO ask for help @ > > http://snapshot.ntop.org > > > > > > I'd be especially interested in the ifconfig output... > > > > > > -----Burton > > > > > > -----Original Message----- > > > From: Evren Yurtesen [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, September 19, 2002 10:14 AM > > > To: Burton M. Strauss III > > > Cc: [EMAIL PROTECTED] > > > Subject: RE: [Ntop] -M option > > > > > > > > > Alright you were right. When I use -M option I am not able to use the > > > change NIC option from admin section of the web interface. Perhaps I > > > remembered wrong about it since I was testing it at 3am =) > > > > > > I have another problem though. when I start ntop like below > > > /usr/local/bin/ntop -d -L -i dc0,dc1,dc2,dc3,ed1 -w 3000 -W 0 -a \ > > > /var/log/ntop.access.log -u nobody -E -n -M /dev/null 2>&1 > > > > > > I have 5 ethernet cards dc0,dc1,dc2,dc3,ed1 and when I run ntop > > > there is no information about dc1 ever! > > > > > > I could solve the problem by removing the redirection in the ntop.sh > > > script. I used this redirection at prompt to prevent output from ntop. > > > > > > >/dev/null 2>&1 > > > > > > I can still check again when I put the redirection if I lose information > > > collection on dc1 > > > > > > Evren > > > > > > On Thu, 19 Sep 2002, Burton M. Strauss III wrote: > > > > > > > No. > > > > > > > > Normally ntop will merge all the data for the interfaces. With -M, > you > > > can > > > > select a single interface and that's what's then reported on. > > > > > > > > -----Burton > > > > > > > > -----Original Message----- > > > > From: Evren Yurtesen [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, September 19, 2002 7:43 AM > > > > To: Burton M. Strauss III > > > > Cc: [EMAIL PROTECTED] > > > > Subject: RE:(2) [Ntop] -M option and a another problem > > > > > > > > > > > > Yes but what kind of change should I expect? Because even though it > > merges > > > > the data I can still switch between network interfaces and see only > > their > > > > usage alone. > > > > > > > > > Sent: Wednesday, September 18, 2002 7:50 PM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: [Ntop] -M option > > > > > > > > > > > > > > > I tried ntop with -M option and without the option, > > > > > I couldnt see any difference, anybody can explain me what should I > > > expect > > > > > to see in the output web pages? > > > > > Thanks > > > > > Evren _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://lists.ntop.org/mailman/listinfo/ntop
