#define FLAG_HOST_SYM_ADDR_TYPE_MAC 9 #define FLAG_HOST_SYM_ADDR_TYPE_IP 19
This goes back to our discussions over the 'best' name ntop has at the time. When the code is 9, the MAC is the best name. Unless it's an Ethernet level packet, right after the 9 is processed, it's updated to 19 because the IP is also known on a tcp/ip packet. So that becomes the 'best' name. Once the IP is resolved to a name, 19->29 means that the name is the best (and final) name. The problem I'm seeing is 0->29 directly, so that the MAC and IP aren't filled in. Happens when a host is 'resolved' out of the cache. Whatever you saw sounds different - I'd need to see the html capture (preferably w/ debug enabled so the <!-- --> tags are in there. -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf > Of Markus Rehbach > Sent: Tuesday, March 23, 2004 3:01 PM > To: [EMAIL PROTECTED] > Subject: Re: [Ntop-dev] Duplicated name entries in the eth0 host lists > (orig. from eth0 and NerFlow-Device) > > > (Un?)fortunately using the current cvs version I cannot reproduce > it anymore. > And I'm seeing the same pattern as you (0->9 9->19); we should > assume that it > is fixed, or? > > Btw. saw another thing concerning the name resolution: Clicking on a host > (e.g. in Summary/Hosts) which was communicating with the '0->9 > 9->19'-host I > saw the MAC address of this host in the 'packet statistics' > section although > the dns name should appear. Can you reproduce this? > > Markus > ________________________ > > On Tuesday 23 March 2004 19:55, Burton M. Strauss III wrote: > > Markus -- > > > > I think I'm on to something. > > > > Try deleting the cache (dnsCache.db) before the start of the > run. While it > > won't fix the problem it may hide it. Let me know. > > > > > > I think I know the pattern to look for. If you build with CMPFCTN_DEBUG > > (or better yet, just make the single case in _setResolvedName() active), > > you may see this in the log: > > > > > > CMPFCTN_DEBUG: setResolvedName(0x0836e5f8) 0 -> 29 > > c-67-166-195-111.client.comcast.net - address.c(69) > > ... > > CMPFCTN_DEBUG: setResolvedName(0x08442008) 0 -> 9 ADAPTEC > > INCORPORATED:EF:02:D0 - hash.c(1182) > > CMPFCTN_DEBUG: setResolvedName(0x08442008) 9 adaptec > > incorporated:ef:02:d0 -> 19 67.166.195.111 - pbuf.c(3241) > > > > It's seeing the IP and resolving it from the cache, then building a > > separate record when it sees the MAC address (fair enough, it > doesn't know > > the IP yet), followed by an IP record when it does learn the > IP. Now you > > have two records, not one. Eventually the 2nd gets name > resolved (29) and > > you have two hosts. > > > > > > For a real solution, either we need to add the MAC to the cache so the > > initial record is populated, or we need to figure out how to > merge them on > > the 9->19 transition. Neither is very clean - I'm still > looking into it. > > > > > > -----Burton > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf > > Of Burton M. Strauss III > > Sent: Sunday, February 29, 2004 2:52 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [Ntop-dev] Duplicated name entries in the eth0 host lists > > (orig. from eth0 and NerFlow-Device) > > <snip /> > > > _______________________________________________ > 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 _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
