Is that bridge implemented through netfilter on 2.6?  That's user space, so
it could be that the packets aren't being seen properly...  Or it could be
kernel bridging - I don't have 2.6 running, nor am I really set up for a
bridge.

Can you run a short tcpdump on both the br0 and the underlying interface ---
just to make sure that it's seeing the same packets in the same way???

-----Burton


> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sha
> Chancellor
> Sent: Thursday, March 11, 2004 11:03 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [Ntop] Yet another DNS question....
>
>
> It must have been seeing packets.  Because it all worked fine, the
> network graphs etc.  Except that it wasn't resolving ips on that one
> subnet till I switched interfaces, and specified it explicitly on the
> command line.   It would even show them as hosts, just not resolve their
> addresses. (Which i verified was possible on the command line.)  And I'm
> in bridging mode on 2.6.x.
>
> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-----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
> >>>>
> >>>>
> >>>traverse
> >>>
> >>>
> >>>>the firewall.  That is working fine.  What I'm having a problem with
> >>>>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
> >>>>
> >>>>
> >>>by
> >>>
> >>>
> >>>>any traffic I can sniff.
> >>>>
> >>>>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
> >>>>
> >>>>
> >>>-P
> >>>
> >>>
> >>>>/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
>

_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop

Reply via email to