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)
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.
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).
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)
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.)
-----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
