# Frequently Asked Questions

1) Reptor can't open my configuration file.
2) Reptor can't open my log file.
3) Remotelog doesn't work.
4) Some columns in some tables overlap each other.
5) Reptor runs and generates an output file, but the tables are empty.
6) How do I properly define my interfaces in the configuration file?
7) How do I make Reptor run automatically?
8) The graph bars look like empty white boxes.
9) I've written a script to automatically figure out the date of the logfile and feed it to Reptor...
10) I've written a script to automatically name the output report with the date...
11) I've written a script to automatically transfer the logfiles to another machine for processing...
12) I've added alerts to some protocols, but they don't work.
13) What's this "Unidentified" interface?
14) Email output doesn't work.
15) I've disabled DNS resolution on the firewall, and Reptor's DNS resolution takes forever...
16) I'm getting an error "open_remotelogfile: error 22"...

Reptor can't open my configuration file.

  Reptor expects to find the configuration file in the current directory if not otherwise specified. If you're running Reptor from a directory other than the one it is installed it, it won't know where to look. So, either run Reptor from the install directory, specify the full path name of the configuration file with the --config option, or specify the install directory with either the --basedir command line option or the basedir configuration file option.

Reptor can't open my log file.

  If you're using remotelog, see the following question. If not, make sure that the directory option in the configuration file is set properly and that the user running Reptor has permission to read the logfiles there. Don't rename the logfiles -- Reptor expects them to have the names that the firewall assigned. Make sure the remotelog option in the configuration file is commented out or deleted. If your logfiles are compressed, make sure you've properly set the uncompress option in the configuration file. If your logfiles are not compressed, make sure the uncompress option in the configuration file is commented out or deleted. If you're not specifying a particular logfile with the --date or --log command line options, make sure that yesterday's logfile is available in your log directory.

Remotelog doesn't work.

  Verify that remotelog is installed and configured correctly by running the remotelogfile command from a command prompt. If you can't retrieve a logfile this way, Reptor won't be able to either. The remotelog option in the configuration file can take an optional argument indicating the full path to the remotelogfile executable. Try setting it. Otherwise, either make sure the directory that contains remotelogfile.exe is in your PATH, or copy remotelogfile.exe to the directory that Reptor is installed in.

Some columns in some tables overlap each other.

  You're using Netscape, and it doesn't correctly format tables that are wider than the window. You can try to maximize the window, decrease your font size, and/or increase your screen resolution, but some tables like the alert section will almost always be wider than the window. In this case, you'll have to use another browser. Internet Explorer, Opera, and Mozilla are known to work properly. Note: this issue has been resolved with Reptor version 0.99.

Reptor runs and generates an output file, but the tables are empty.

  You need to properly define your interfaces in the configuration file.

How do I properly define my interfaces in the configuration file?

  Browse through a logfile and look for lines that include the string "type 121: Statistics". These lines should have tags named srcif and dstif. The strings to the right of the equal signs are the names of your interfaces. In order to determine which is which, inspect the src and dst addresses. If you know your protected network is 192.168.1.0, and the logfile says "... srcif=Vpn1 src=192.168.1.17 ...", then Vpn1 is your "Inside" interface.

How do I make Reptor run automatically?

  Regardless of your OS, it is important to remember that scheduling Reptor to run automatically does not mean that the system will run it from the Reptor install directory. As a result, Reptor may have problems finding your configuration file, because it looks in the current directory by default. There are three ways to handle this problem. First, explicitly make the Reptor directory the current directory before running Reptor. Second, use the --config command line option to specify the exact location of your configuration file. Third, use either the --basedir command line option or the basedir configuration file option to specify the Reptor install directory. It is also important to note that the environment's PATH may not be the same as it is for an interactive shell. For this reason, make sure you specify full path names where possible.

  Unix

    Use cron. See the manpage for crontab for details. You might use something like this:

        0 2 * * * /usr/local/reptor/reptor.pl --basedir /usr/local/reptor --config reptor.cfg

    This will run Reptor every day at 2:00 am. This example assumes that you have reptor.pl and reptor.cfg installed in /usr/local/reptor.

  NT

    Use at. See the help page for at for details. You might use something like this:

        at 2:00 /every:Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday "c:\perl\bin\perl c:\reptor\reptor.pl --basedir c:\reptor --config reptor.cfg"

    This will run Reptor every day at 2:00 am. This example assumes that you have reptor.pl and reptor.cfg installed in c:\reptor and Perl installed in c:\perl\bin.

    If you're running Reptor right on the firewall, you must also configure it not to kill the Scheduler service. Add the string "Schedule" to the vulture.runtime file.

    Also, many people report having trouble with the GUI scheduler component of Internet Explorer 5. Microsoft TechNet article Q250039 may be of some help.

The graph bars look like empty white boxes.

  If the report is being served from a web server, you need to copy the pixel.gif file (and any other gif files) from the directory of the theme that you're using to the document directory on the web server. Otherwise, the pixel.gif file must exist on the client machine, in the same directory that the HTML report file resides in. If you're using email output, and viewing the report directly in an HTML capable email client, I haven't figured that one out yet.

I've written a script to automatically figure out the date of the logfile and feed it to Reptor...

  This functionality is already present in Reptor. Make sure that you are using logfiles from the oldlogs directory, not the sg directory. At midnight, Raptor automatically moves the current logfile to the oldlogs directory and changes the filename so that it includes the date. Reptor expects to see filenames in this format and already knows what date yesterday was, so using pre-midnight logfiles or changing the name of logfiles will actually cause some loss of functionality.

I've written a script to automatically name the output report with the date...

  This functionality is already present in Reptor. Instead of indicating a full filename in the configuration file, specify a path that ends with a slash. Reptor will automatically create an appropriate filename based on the date of the logfile processed.

I've written a script to automatically transfer the logfiles to another machine for processing...

  This functionality is already present in Reptor. If the machine that Reptor is installed on is supported by the remotelog utilities, Reptor can use them and automatically download logfiles from the server at the time the report is generated. The logfiles are pulled from the client instead of being pushed from the server, so there is no need for any additional scripting or scheduling services to run on the firewall server. In addition, the session is encrypted (unlike ftp) so that potential packet sniffers are deterred.

I've added alerts to some protocols, but they don't work.

  If you've made aliases for those protocols, make sure you use the alias in the alerts definition, and not the original protocol identifier.

What's this "Unidentified" interface?

  This is not a problem with Reptor -- it is a result of data missing from the logfile. Sometimes, logfile entries do not contain the "srcif" and/or "dstif" tags, which identify the source and destination interface of the connection. When this happens, there's no way for Reptor to know which interface is which, and the entry gets categorized as "Unidentified".

Email output doesn't work.

  The destination email server may think that Reptor's output is spam. As a result, you may have to configure it to accept mail relaying from the machine that Reptor is being run on. Also, make sure that the mail_server and mail_from options are properly set in your configuration file.

I've disabled DNS resolution on the firewall, and Reptor's DNS resolution takes forever...

  If you're using dns all in the configuration file, don't. Use dns print instead. You'll lose the ability to perform word searches on host names, though. Otherwise, consider using this version of jdresolve, a very high speed multi-threaded DNS resolver. It has been modified to handle Raptor logfiles. First run jdresolve-raptor on the logfile. This will generate a new logfile with the DNS information. Then, run Reptor on the new logfile.

I'm getting an error "open_remotelogfile: error 22"...

  This is not a Reptor error, it is an error from the remotelogfile program. Verify if your output was properly generated. If not, make sure that you can use the remotelogfile command from the command prompt as described previously. If your output was properly generated and you are not using split logfiles, then comment out the "split" option in your configuration file. Since Reptor has no way of knowing ahead of time how many split sections there may be, it continually attempts to open the "next" one until it receives an error from the remotelogfile program. So, if you are using remotelogfile and you have split logfiles, this error message is unavoidable and may be safely ignored. If you don't want to see it, you can redirect your error output to the null device.

  This error may also be caused by differing dates between the firewall and the remotelog client.