I'm please it worked - was it the code change or purging dnsCache.db that did it?
If you have specialized needs you can change the values in the globals-defines.h constants. Highest value wins. The block where a value is chosen if hostResolvedName isn't set is a little more difficult to change, but could be done - it's in webInterface.c As to why favor IP over NetBIOS, that's a simple piece of reality - most networks where people are using ntop have TCP/IP and most of them have some form of DNS. -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Markus Rehbach > Sent: Wednesday, February 25, 2004 3:16 PM > To: [EMAIL PROTECTED] > Subject: Re: [Ntop] New sorting routines in cvs - these are post 3.0pre1 > - TEST NOW OR HOLD YOUR WATER > > > Perfect. Working now with my pure TCP/IP network;-) > > <TR ><th align="left" nowrap width="250"> > <a href="/192.168.11.100.html" >192.168.11.100</a> > <img src="/clock.gif" border="0" alt="NTP Server"><td > align="center"> </td></th> > <TD ALIGN=RIGHT>192.168.11.100</TD><TD > ALIGN=RIGHT>00:10:5A:53:E6:A7</TD> > <TD ALIGN=RIGHT NOWRAP> </TD><TD ALIGN=LEFT><IMG > ALIGN=ABSMIDDLE SRC="/gaugeS.jpg" ALT="Sent 63%" WIDTH=189 > HEIGHT=12><IMG ALIGN=ABSMIDDLE SRC="/gaugeR.jpg" ALT="Received > 33%" WIDTH=99 HEIGHT=12> </TD> > <TD ALIGN=RIGHT NOWRAP>3COM CORPORATION</TD><TD > ALIGN=RIGHT> </TD><TD ALIGN=RIGHT>5</TD><TD ALIGN=RIGHT > NOWRAP>44:46</A></TD><TD ALIGN=RIGHT NOWRAP> </TD></TR> > > and the debug > > Wed Feb 25 21:38:09 2004 CMPFCTN_DEBUG: > setResolvedName(0x085d8980) 0 -> 6 192.168.11.100 - hash.c(1160) > > For me ist is working now without problems with and without -n. > But I'm not > really interested in the NetBIOS name resolution. See the debug of another > systems name resolution phases: > > Wed Feb 25 22:00:24 2004 CMPFCTN_DEBUG: > setResolvedName(0x085ded50) 0 -> 3 ETHER - pbuf.c(664) > Wed Feb 25 22:04:31 2004 CMPFCTN_DEBUG: > setResolvedName(0x085ded50) 3 aether -> 6 192.168.11.240 - pbuf.c(3216) > > The first is the entry of the NetBIOS name broadcast, the second entry is > an entry generate at the moment I pinged that host. Curious in > that way that > the first broadcast packet contained the MAC, the IP-Adress and the name > of the host. Why not a 6 at the first packet? And the NetBIOS name a 5? > And the IP-Address a 4 and for folks like me using the -n parameter > switching off both 5 and 6? > > Otherwise I fear there are folks around who will say something > like 'the NetBIOS > Name Service is a name service and of equal value as the DNS resolution'. > Think it is a valid argument (not for me, I'm interested in the > IPs only an can > live with NetBIOS prioritized at 3). > > Cheers > > Markus > > _____________________ > > > On Wednesday 25 February 2004 17:29, Burton M. Strauss III wrote: > > So it's a 6! FLAG_HOST_SYM_ADDR_TYPE_IP. So I'm looking for a > place where > > hRN transitions to 6, i.e. setResolvedName(... So it's a type 6! > > FLAG_HOST_SYM_ADDR_TYPE_IP but the underlying value isn't > set... There are > > only 4, shouldn't be that hard to nail down. Especially as the > debug line > > is in the log: > > > > setResolvedName(0x085dd730) 0 -> 6 192.168.11.100 - hash.c(1160) > > > > (Don't you just LOVE it when the debugging stuff works!) > > > > Let's see in your 1st message you said "Tried it using the -n Parameter" > > > > I think I've found something odd - no clue if it's your problem > - there's > > one case where hostResolvedName (was) set w/o going through the > function, > > and that didn't test for the -n flag, just updated the name > from the cache. > > With -n set, that cache might not be loaded and so it would be > updated to > > blank. > > > > > > I'll commit the patch in a few minutes, give it a try... > > > > For that to be the problem, however, you would have to also > have a messed > > up dns cache file. > > > > So please do the following. > > > > 1. Bring down the updated reportUtils.c, compile and test that > > 2. Run dumpgdbm against your dnsCache.db (ntop must be down) > > > > $ dumpgdbm /usr/share/ntop/dnsCache.db | grep "'3232[23]" > > > > (dumpgdbm is at http://article.gmane.org/gmane.linux.ntop.general/3557, I > should probably throw the current version up @ SourceForge). > > 3. Delete dnsCache.db and rerun ntop > > Let me know what you see. > > -----Burton > _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
