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
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
