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
