Bad user - no problem report... (I'll add the pcap_stats counters to the PR
form).
You have to remember that there's multiple buffering going on, and just
because one program sees the packet doesn't mean the other will. It's
always a good first test, but it's not conclusive. It has to do with buffer
sizes and packet handling latencies. ntop's latency isn't as good as
tcpdump's.
(1) The RTL8139 chips have a rep for being cheap crud (small on-card
buffers), but the should be able to keep up with a lan that's not too loaded
(google for 8139 "drop packets" or 8139 "droping packets").
Those drops should be tracked by the ifconfig stats.
eth0 Link encap:Ethernet HWaddr 00:03:47:B1:62:26
inet addr:192.168.42.36 Bcast:192.168.42.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:81555 errors:0 dropped:0 overruns:0 frame:0
^^^^^^^^^
TX packets:58015 errors:0 dropped:0 overruns:0 carrier:0
^^^^^^^^^
collisions:361 txqueuelen:100
RX bytes:18444625 (17.5 Mb) TX bytes:7232558 (6.8 Mb)
Interrupt:5 Base address:0xf000
(2) Secondly, there's internal buffering in the OS's tcp/ip stack. When the
stack asks the card for the next packet, it's got to be able to put it
somewhere. This is usually async with the stack passing the packet on to
any threads which are registered for it (this is somewhat of a
publish/subscribe model).
(3) Then, there's internal buffering inside libpcap, when a particular
instance of libpcap registers with the tcp stack for the packets from an
interface. It has to have somewhere to stick the packets it's given until
the user program asks for it via pcap_dispatch.
(4) Finally, there's buffering inside the program - in ntop's case it's the
memory structure - see queuePacket() and dequeuePacket().
ifconfig should show (1)/(2) - and on those systems that support it (Linux
does not, no clue re FreeBSD), pcap_ifdrop in pcap_stats should report it to
the user program.
pcap_stats.pcap_drop should show (3) and ntop's internal counter
myGlobals.device[].droppedPkts should show (4).
Check the various counters and see if you can tell where it's getting
dropped.
Does trafficStats.html show anything for Dropped (by kernel or by ntop)?
Confirm you're not running with --diable-mt
-----Burton
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of The
Jetman
Sent: Friday, July 25, 2003 7:28 PM
To: NTOP Mail List
Subject: [Ntop] [FBSD 4.8-R]Making NTOP 2.2 See All Hosts In The LAN
I've just about got NTOP doing everything I want, but w/ an
essentially stock FreeBSD 4.8-RELEASE, I have occasions (like now) where
traffic from certain local hosts isn't reliably tracked by NTOP. That is,
if I invoke NTOP to monitor rl0 (a brand-new Realtek card) which hosts
IP a.b.c.48, NTOP will not "see" quite a few hosts, like a.b.c.31. I
know that a.b.c.31's traffic is passing thru rl0, bec I can see it via
tcpdump (tcpdump -i rl0 host a.b.c.31). BTW, it was behaving this way
when I had a different Ethernet card (a dc-based card.)
It's funny bec some hosts show up instantly (w/in 10s) upon booting
NTOP. a.b.c.31 and others just won't show up unless I repeatedly
restart NTOP until these special hosts appear (via the IP Traffic:L->R
link). It's not an odd-even thing, just certain hosts don't show up.
Here's the cmd-line I use:
/usr/local/bin/ntop -u nobody -d -P /data0/ntop -w 3000 -i rl0,dc0 \
-m a.b.c.0/26,192.168.1.0/24 -M -L
Here's the rl0 device:
rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet a.b.c.48 netmask 0xffffffc0 broadcast a.b.c.63
inet6 fe80::2e0:4cff:feea:c6d5%rl0 prefixlen 64 scopeid 0x1
ether 00:e0:4c:ea:c6:d5
media: Ethernet autoselect (10baseT/UTP)
status: active
It's not a speed issue, bec the host system is a 1GHz Dell P-III w/
128MB of RAM and the system's lightly loaded (NTOP, NAMED, MySQL, NTPD).
And NTOP has almost all of the CPU time.
Next, I'm going to try yet another Ethernet card, this time, an Intel
EtherExpress, altho I doubt that even the most recommended Ethernet card
is going to make a diff. Anyone else have any other suggestions ?
Later....Jet
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
