After more investigation, it appears that the records would be properly read if we simply opened another file handle (to a random text file) for the duration of the record-reading loop in the vendor.c file.
This hack was/is a bit weird. But it seemed to make things work. In the process of investigating our problem, we also downloaded recent versions of "oui.txt" and "etter.passive.os.fp" which were larger than the ones that came with Ntop 2.2. We accidentally noticed that some of the pages were broken, partial html code appeared in the display, and broken links to _some_ of the images. We then replaced the oui.txt and etter.passive.os.fp file back to the original from the Ntop 2.2 distribution and things went back to normal (as far as we could tell). This appears to be some kind of buffer overflow problem. Comments? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Lee Sent: July 16, 2003 1:29 PM To: [EMAIL PROTECTED] Subject: RE: [Ntop] sntop record loading problems (FreeBSD) Nope, not gzipped. Even if they were gzipped, I don't think the fgets() function should have failed. This is baffling... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Grewell Sent: July 16, 2003 12:22 PM To: [EMAIL PROTECTED] Subject: Re: [Ntop] sntop record loading problems (FreeBSD) Are the files gzipped? I had to un-gz them manually on my Linux box in order for the CVS version of NTop to accept them. That was during the build process, though. It wouldn't even 'make install'. On Tuesday 15 July 2003 05:02 pm, Andy Lee wrote: > We have been compiling ntop statically under FreeBSD because some of > the graphs were messed up otherwise. Then we noticed these syslog > messages upon sntop startup: > > Jul 15 18:22:48 x ntop[86899]: VENDOR: Loading MAC address table. > Jul 15 18:22:48 x ntop[86899]: VENDOR: Checking './specialMAC.txt' > Jul 15 18:22:48 x ntop[86899]: VENDOR: Checking > '/usr/local/etc/ntop/specialMAC.txt' > Jul 15 18:22:48 x ntop[86899]: VENDOR: ...found, 0 lines, loaded 0 > records! > Jul 15 18:22:48 x ntop[86899]: VENDOR: Checking './oui.txt' > Jul 15 18:22:48 x ntop[86899]: VENDOR: Checking > '/usr/local/etc/ntop/oui.txt' > Jul 15 18:22:48 x ntop[86899]: VENDOR: ...found, 0 lines, loaded 0 > records! > Jul 15 18:22:48 x ntop[86899]: I18N: This instance of ntop does not > support multiple languages > Jul 15 18:22:48 x ntop[86899]: IP2CC: Looking for IP address <-> Country > code mapping file > Jul 15 18:22:48 x ntop[86899]: **ERROR** IP2CC: reading file > '/usr/local/etc/ntop/p2c.opt.table' > Jul 15 18:22:48 x ntop[86899]: **ERROR** IP2CC: problem is Bad file > descriptor(9) > Jul 15 18:22:48 x ntop[86899]: IP2CC: ntop continues OK, but with no > data from file > Jul 15 18:22:48 x ntop[86899]: **WARNING** IP2CC: Unable to read IP > address <-> Country code mapping file (non-existant or no data). > Jul 15 18:22:48 x ntop[86899]: IP2CC: ntop will perform correctly but > without this minor feature. > > Another FreeBSD system that used the dynamic-linking ntop binary > reads these files in correctly (but some of the graphs were messed > up - mentioned above). Comparing the md5 sums of the files in > question (ie. oui.txt) shows that the files are not corrupted. > > Upon further investigation, it looks like line 461 of vendor.c: > > while (fgets(tmpLine, sizeof(tmpLine), fd)) { > > is failing. A quick test with ferror(fd) seems to confirm this. > > However, we're not sure what the problem is. The files are > world readable and they are located by ntop (the syslog messages > when the files are renamed confirms this). > > Any ideas? > _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
