Yes No (Yes) dequeueAddress() calls resolveAddress() which uses the standard resolver interface, gethostbyaddr_r(). That's the same as nslookup etc. - it's going to generate a query which is a real tcp/ip udp conversation, etc. -- so that uses the host's interface. (No) If DNS address resolution isn't working (for whatever reason), then sniffing is the only way ntop can resolve address... Sniffing uses the monitoring interface. If ntop can sniff somebody else's query (DHCP or DNS request), then it stores that off and doesn't have to generate it's own, time-consuming query. For sniffing, position matters. * DNS requests are NOT broadcasts, so monitoring ports in different places on a switched network could very well see different packets. * DHCP? That depends - some DHCP stuff is broadcast, other is unicast - for the unicast stuff, position will again matter. Also - a new thought - I wonder if there is junk in the cache. To fix this, try deleting the .db file. The one with DNS in it's name (should be obvious). -----Burton
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ROBERSON, Brian Sent: Friday, June 24, 2005 12:56 PM To: [email protected] Subject: RE: [Ntop] NTOP latest Win32 Snapshot - DNS question Burton, It's also interesting to note that another NTOP that is in a different location closer to our core resolves the addresses fine. The one that works perfectly is only using one NIC. The only real difference between these two machines is that the one not working is using a secondary NIC to monitor the traffic. I don't know if this makes any difference whatsoever. Will the system that is currently running with two nics send dns queries out on the TCPIP enabled NIC?? Could it be trying to communicate via the NIC with just the port monitoring enabled? Brian _____ From: [EMAIL PROTECTED] on behalf of Burton Strauss Sent: Fri 6/24/2005 1:52 PM To: [email protected] Subject: RE: [Ntop] NTOP latest Win32 Snapshot - DNS question Nope ... With debug the flags are shown for the non-terminal resolution states. But [NetBIOS] flag is shown regardless of debug (code below) It's almost as if the address resolution thread has stopped, so all you are seeing is the cached and sniffed values. You would have to run from a command prompt (ntop /c -xxxxx) not the service to see the log, and look for THREADMGMT: entries for 'DNS address resolution'. But that's an area of code I'm re-writing for 3.2 and so I won't be doing much in there re 3.1 -----Burton if(el->hostResolvedNameType == FLAG_HOST_SYM_ADDR_TYPE_NETBIOS) { strncat(noteBuf, " [NetBIOS]", (sizeof(noteBuf) - strlen(noteBuf) - 1)); } ... switch (el->hostResolvedNameType) { case FLAG_HOST_SYM_ADDR_TYPE_FCID: case FLAG_HOST_SYM_ADDR_TYPE_FC_WWN: case FLAG_HOST_SYM_ADDR_TYPE_FC_ALIAS: strncat(noteBuf, " [FibreChannel]", (sizeof(noteBuf) - strlen(noteBuf) - 1)); break; case FLAG_HOST_SYM_ADDR_TYPE_MAC: strncat(noteBuf, " [MAC]", (sizeof(noteBuf) - strlen(noteBuf) - 1)); break; case FLAG_HOST_SYM_ADDR_TYPE_IPX: strncat(noteBuf, " [IPX]", (sizeof(noteBuf) - strlen(noteBuf) - 1)); break; case FLAG_HOST_SYM_ADDR_TYPE_IP: strncat(noteBuf, " [IP]", (sizeof(noteBuf) - strlen(noteBuf) - 1)); break; case FLAG_HOST_SYM_ADDR_TYPE_ATALK: strncat(noteBuf, " [Appletalk]", (sizeof(noteBuf) - strlen(noteBuf) - 1)); break; case FLAG_HOST_SYM_ADDR_TYPE_NETBIOS: /* Do nothing - handled in open code above */ break; case FLAG_HOST_SYM_ADDR_TYPE_NAME: break; } _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ROBERSON, Brian Sent: Friday, June 24, 2005 11:39 AM To: [email protected] Subject: RE: [Ntop] NTOP latest Win32 Snapshot - DNS question Burton, The IP's that should resolve and don't do show an [IP] flag. The ones that do resolve have no flag and are correctly named (netbios name shown?) Brian _____ From: [EMAIL PROTECTED] on behalf of Burton Strauss Sent: Fri 6/24/2005 12:27 PM To: [email protected] Subject: RE: [Ntop] NTOP latest Win32 Snapshot - DNS question Check - on the ntop host - that these names are really resolvable via nslookup. But first read the docs/FAQ stuff and the back traffic on DNS sniffing. You can turn on the debug flag and - in the host name windows - will be able to see the flags for the resolution state. That will tell you how far ntop has been able to take name res, e.g.: 216.148.226.29 <http://tigger.burtonstrauss.local:13000/216.148.226.29.html> [IP] ^^^ says that this is a numeric IP address Unless it's reached a terminal state, there should be a flag in []s. -----Burton _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ROBERSON, Brian Sent: Friday, June 24, 2005 11:07 AM To: [email protected] Subject: [Ntop] NTOP latest Win32 Snapshot - DNS question I'm noticing that NTOP is not resolving a lot of our internal addresses. This isn't a big problem but mildly irritating having to resolve the address manually. Is there a way to check the configuration to enhance discovery of DNS names? Our environment is Windows 2003 Active Directory. Brian
<<attachment: winmail.dat>>
_______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
