Burton M. Strauss III wrote:
I wonder if ntop is even seeing the packets in bridge mode. IIRC this depends on the bridge code - there are different versions (some patches to the 2.2 kernel, some user space, native code in 2.4/2.6, etc.) (And that's just Linux).
Your specific situation sounds like ntop can't resolve those IPs. Remember, at the end of the day all it does is sniff other's responses or use the standard gethostbyaddr() call, which uses whatever's defined on the host ntop is running on.
The way to test this is to use nslookup (dig, host, etc.) on the ntop host and see what it can and can't resolve. ntop may do a little better because of the sniff, it shouldn't do worse.
-----Burton
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sha Chancellor Sent: Thursday, March 11, 2004 9:43 AM To: [EMAIL PROTECTED] Subject: Re: [Ntop] Yet another DNS question....
I also deleted addressQueue.db and dnsCache.db, restarted ntop. However.. I have two subnets, and linux is in bridging mode with an ip address assigned to the br0 interface. So i specify the other subnet not on the interface. When i looked at the hosts page again, the domain names for the local subnet NOT on the br0 interface( the one specified on the command line) were there. However, the domain names for the local subnet on the interface were not showing. Just ips instead.
With this in mind, since my bridge is only 2 ethernet cards i decided to try deleting those db files and trying to put it on one of the other interfaces. When I restarted, now it works. However, it also worked on br0 before i did --track-local-hosts
But I'm happy, it works, all is well :) But it seems to me there's some strange behavior there.
On Mar 11, 2004, at 7:22 AM, [EMAIL PROTECTED] wrote:
Burton, thanks for the reply. I did a couple of things this morning to try and pin this down:
- I deleted the addressQueue.db and the dnsCache.db files. - Built a bind server local to the Linux box and updated my /etc/resolv.conf to point at 127.0.0.1 - Configured the BIND server to be secondary for all reverse zones in my building, 15 of them.
This seems to have solved the problem. It apparently was related to the time it was taking to do the name lookups??
--
J. Eric Josephson Director of Network and System Operations 978-720-2159 mailto:[EMAIL PROTECTED]
"Burton M. Strauss III" To: <[EMAIL PROTECTED]> <[EMAIL PROTECTED] cc: rt.com> Subject: RE: [Ntop] Yet another DNS question.... Sent by: [EMAIL PROTECTED] it
03/10/2004 08:02 PM Please respond to ntop
No beating, just...
Remember DNS resolution is a three layer process... see resolveAddress() in address.c - This runs in an async thread, handling the queue.
1. If it's in the cache (dnsCache.db), that value is used. Cached entries have a TTL that is unique to ntop - CONST_DNSCACHE_LIFETIME in globals-defines.h. Default is 24*3600 seconds or 24 hours.
2. If it's not cached, ntop uses the host's gethostbyaddr() calls (these will hit the /etc/hosts file, DNS server, whatever - same as nslookup). That's it.
Now sniffing runs separately and loads the cache with data from the responses to other peoples queries.
So dnsCache.db becomes a pretty good cache over time.
However, a negative reply - even a transient one - will stick around for the LIFETIME period.
All of this is EXPLICITLY counted in the info.html and textinfo.html reports:
Address Resolution
DNS Sniffed:
DNS Packets sniffed.....0 less 'requests'.....0 less 'failed'.....0 less 'reverse dns' (in-addr.arpa).....0 DNS Packets processed.....0 Stored in cache (includes aliases).....0
IP to name - ipaddr2str():
Total calls.....48 ....OK.....0 ....Total not found.....48 ........Not found in cache.....44 ........Too old in cache.....3
Queued - dequeueAddress():
Total Queued.....14 Not queued (duplicate).....34 Maximum Queued.....7 Current Queue.....4
Resolved - resolveAddress():
Addresses to resolve.....11 ....less 'Error: No cache database'.....0 ....less 'Found in ntop cache'.....0 Gives: # gethost (DNS lookup) calls.....11
DNS Lookup Calls:
DNS resolution attempts.....11 ....Success: Resolved.....8 ....Failed.....2 ........HOST_NOT_FOUND.....2 ........NO_DATA.....0 ........NO_RECOVERY.....0 ........TRY_AGAIN (don't store).....0 ........Other error (don't store).....0 DNS lookups stored in cache.....10 Host addresses kept numeric.....2
That's the FIRST place you have to start to figure out what's going on.
But somehow, everytime I ask anyone for this information, they're never heard from again...
-----Burton
traverse-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 11:42 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [Ntop] Yet another DNS question....
OK, I'm ready to take my mailing list beating...
I looked through the old list postings and found similar questions and some answers, but could not spot the information I was looking for.
In my implementation of NTOP, I am watching all traffic going out of
our
corporate firewall. NTOP seems to capture most DNS requests that
the firewall. That is working fine. What I'm having a problem withby
is
that I have hundreds of internal machines that generate traffic to the
external world, but have no cause to have their own IP address
resolved
any traffic I can sniff.-P
I am starting NTOP with the following:
ntop -d -u ntop -i eth0,eth1 -M -o -m 10.0.0.0/8 -p
/etc/protocols.ntop
/tmp
and have all of my subnets broken down into 24 bit masks. i.e 10.12.54.x, 10.12.44.x etc...
I am using today's CVS pull, but have had this "problem" for a very long time.
I there a way I can specify what address to aggressively do reverse name resolution on or simply to have NTOP actively resolve all IP addresses, thus more completely populating my internal machine addresses with names?
_______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
