So this is a router then. You need to give some more details - the ifconfig info, etc. would be helpful. Blind the actual IPs if you need to. That will show packet counts, which should (roughly) correlate with what ntop is reporting.
It's really not a matter of 'where it's being accounted' for, it's where the libpcap is capturing it. As I've said before, libpcap doesn't differentiate between the virtual interfaces - it's purely physical. We need the virtuals (eth2:0) so we know what IP addresses are local and which are not. But libpcap just captures on the physical interface. "So there is something _special_ about this gateway setup :)". Could it be the difference in the Linux packet handling, things like Linux 2.2 vs. 2.4 vs. 2.6 issue -- netfilter, IP route 2, etc.?? Skulk around the web and there's a lot of stuff about interactions between the low level stuff such as libpcap and netfilter. There's the start of an interesting thread about this http://www.tcpdump.org/lists/workers/2003/08/msg00461.html... (unfortunately there's no resolution to his question). But it's relevant because of the way in which NAT and IP route 2 may be handling the packet before libpcap can see it. There are other interesting comments about interactions between libpcap based tools and kernel versions, etc. - for example http://www.linuxquestions.org/questions/archive/4/2002/05/4/20978 and http://public.lanl.gov/cpw/ The alarm() message is just that... in http.c, where we fork() a child to do the actual page construction: /* The URLs below are "read-only" hence I can fork a copy of ntop */ if((childpid = fork()) < 0) traceEvent(CONST_TRACE_ERROR, "An error occurred while forking ntop [errno=%d]..", errno); else { *usedFork = 1; if(childpid) { /* father process */ myGlobals.numChildren++; compressFile = 0; return(0); } else { /* This is zero in the parent copy of the structure, make it non-zero here so we can tell later on (BMS 2003-06) */ myGlobals.childntoppid = getpid(); ... detachFromTerminal(0); ... signal(SIGALRM, quitNow); alarm(15); /* Don't freeze */ } } So if the page creation takes more than 15s it will abort. In the abort routine, it sends a 408 (timeout) code - try disabling the so-called 'Friendly' error pages (Tools | Internet Options | Advanced). Note that while the page, hostsInfo.html, won't report more than max lines, it still has to scan, create and then sort the huge table. You could try putting a temp log message in http.c around 1918 to show how many entries there really are... traceEvent(CONST_TRACE_INFO, "TEMP: hostsInfo.html table built %d entries", numEntries); if(numEntries > 0) { You could also change the code around 1914, but then don't whine that the later entries aren't being sorted... if(numEntries >= maxHosts) break; to if(numEntries >= min(maxHosts, myGlobals.maxNumLines)) break; I asked for the dns counts from the log, you didn't include them, so I can't offer anything further on that. Still suspect name resolution problems. I had that problem on my firewall, where I was running dnsmasq for the LAN including DHCP and /etc/hosts entries, but the firewall itself was actually using the ISP and so had a totally different view of the world. It could also be that, same as you don't think you're seeing all the traffic, you may not be seeing the DNS responses to sniff them. Beyond that, I'm out of ideas. If you want me to dig into this further, contact me off-list regarding paid support. Otherwise I really can't justify spending any more time. -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf > Of James MacLean > Sent: Wednesday, March 10, 2004 10:43 AM > To: [EMAIL PROTECTED] > Subject: RE: [Ntop-dev] Wrong DNS name mapping, no remote sites, P2P not > where logged (PR KVJ6JYB) > > > On Thu, 4 Mar 2004, Burton M. Strauss III wrote: > > > It sounds like your network is running through devices > (typically switches > > and routers, proxies are also possible) that rewrite the packets so that > > they all appear to come from the same few hosts. Note in the > log how few > > hosts are shown... > > > Host/Session counts - Device 0 (eth2) > > > Stored hosts.....22 > > > Host/Session counts - Device 1 (eth2:0) > > > Stored hosts.....0 > > > Host/Session counts - Device 2 (eth0) > > > Stored hosts.....1 > > > Host/Session counts - Device 3 (eth0:0) > > > Stored hosts.....0 > > > Host/Session counts - Device 4 (eth1) > > > Stored hosts.....1 > > > Host/Session counts - Device 5 (eth1:0) > > > Stored hosts.....0 > > > Host/Session counts - Device 6 (lo) > > > Stored hosts.....1 > > The low count was caused from having run it for just a short period. > Compare it with one I was running for 5 minutes : > > Host/Session counts - Device 0 (eth2) > Stored hosts.....21874 > Host/Session counts - Device 1 (eth2:0) > Stored hosts.....0 > Host/Session counts - Device 2 (eth0) > Stored hosts.....1 > Host/Session counts - Device 3 (eth0:0) > Stored hosts.....0 > Host/Session counts - Device 4 (eth1) > Stored hosts.....1 > Host/Session counts - Device 5 (eth1:0) > Stored hosts.....0 > > Even though all the traffic is passed through this gateway box, > it is only > being accounted for on eth2. Okay by me if it's okay by you :). > > > There are write-ups on this in docs/FAQ - it has to do with the > hybrid layer > > 2/layer 3 nature of ntop. If the layer 2 data isn't valid, you > will see odd > > results. > > Try telling ntop to ignore the MAC addresses via this switch: > > -o | --no-mac > > The other thing that can confuse ntop is bogus data in an > /etc/hosts file - > > esp. if you have one which tries to fake out ad servers by > routing them to > > 127.0.0.1 - the OS call, gethostbyname() can return an unexpected value. > > But I'd bet on -o > > Tried it, but still no remote. Ran ntop on another host that was on > another network and it reported local<->remote correctly. So there is > something _special_ about this gateway setup :). > > Some background. This computer divides a class B address space from the > Internet. On the class B are over 160,000 clients spread over 600+ sites. > At any time thousands of users are going through this PC. This box is also > participating in an OSPF routing environment and houses over 8,000 routes. > > I've tried (on a whim) updating MAX_SUBNET_HOSTS to 65536 with no success. > > After it runs for a few minutes on this busy system I start > failing to get > to ntop's "summary->hosts" web pages with the following being logged : > > **ERROR** http generation failed, alarm() tripped. Please report > this to ntop-dev list! > > Some times this does not occur for quite a while. > > DNS entries are still coming up wrong on both boxen tested. > > The "summary->traffic" information always appears to be correct. > > This is all from today's CVS. > > Any other things I can try, please let me know, > JES > -- > James B. MacLean [EMAIL PROTECTED] > Department of Education > Nova Scotia, Canada > > > _______________________________________________ > Ntop-dev mailing list > [EMAIL PROTECTED] > http://listgateway.unipi.it/mailman/listinfo/ntop-dev > _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
