Permission is granted to reproduce and distribute this
document with the included software under the terms of the
GNU General Public License. This manual and the software
that accompanies it come with absolutely no warranty, not
even the implied warranties of merchantability or fitness
for any particular purpose. See the included COPYING file
for details.
The TCP window is scrollable, and you can use the Up and Down arrow keys on
your keyboard to view more connections when the TCP window is marked Active.
Because this monitoring system relies solely on packet
information, it does not determine which endpoint initiated
the connection. In other words, it does not determine which
endpoint is the client, and which is the server. This is
necessary because it can operate in promiscuous mode, and as
such cannot determine the socket statuses for other machines
on the LAN.
The system therefore displays two entries for
each connection, one for each direction of the TCP
connection. To make it easier to determine the direction
pairs of each connection, a bracket is used to "join" both
together. This bracket appears at the leftmost part of each
entry.
Just because a host entry appears at the upper end of a connection bracket
doesn't mean it was the initiator of the connection.
Some other pieces of information can be viewed as well. The M key displays
more TCP information. Pressing M once displays the MAC addresses of the
LAN hosts that delivered the packets (if the Source MAC addrs in
traffic monitor option is enabled in the
Configure... menu).
N/A is displayed if no packets have been received from the source yet, or if
the interface doesn't support MAC addresses (such as PPP interfaces).
By default, only IP addresses are displayed, but if you have
access to a name server or host table, you may enable
reverse lookup for the IP addresses. Just enable reverse
lookup in the Configure... menu.
Entries not updated within a user-configurable amount of
time may get replaced with new connections. The default
time is 15 minutes. This is regardless of whether the
connection is closed or not. (Some unclosed connections may
be due to extremely slow links or crashes at either end of
the connection.) This figure can be changed at the Configure...
menu.
Direction entries also become available for reuse if an ICMP
Destination Unreachable message is received for the
connection.
The lower part of the screen contains a summary line showing the
IP, TCP, UDP, ICMP, and non-IP byte counts since the start of the monitor.
The IP, TCP, UDP, and ICMP counts include only the IP datagram header and
data, not the data-link headers. The non-IP count includes the data-link
headers.
IPTraf can be set to automatically remove all closed, reset, and idle
entries with the TCP closed/idle persistence... configuration option.
You can also press the F key to arbitrarily clear it at any time.
The sort operation compares the larger values in each connection entry pair
and sorts the counts in descending order.
Over time, the entries will go out of order as counts proceed at varying
rates. Sorting is not done automatically so as not to degrade performance.
For all packets in the lower window, only the first IP fragment is
indicated (since that contains the header of the IP-encapsulated
protocol) but with no further information from the encapsulated protocol.
UDP packets are also displayed in address:port format. ICMP
entries also contain the ICMP message type. For easier
location, each type of protocol is color-coded (text console
only).
The lower window can hold up to 512 entries. You can scroll
the lower window by using the W key to move the Active
indicator to it, and by using the Up and Down cursor keys.
The lower window automatically scrolls every time a new
entry is added, and either the first entry or last entry is
visible. Upon reaching 512 entries, old entries are thrown out
as new entries are added.
Some entries may be too long to completely fit in a screen line. You can
use the Left and Right cursor keys to vertically scroll the lower window
when it is marked Active.
Entries for packets received on LAN interfaces also include the source MAC
address of the LAN host which delivered it. This behavior is enabled by
turning on the Source MAC addrs in traffic monitor toggle in the
Configure... menu.
The destination unreachable message also includes information
on the type of error encountered. Here are the destination
unreachable codes:
Many times, the destination addresses for OSPF packets are
class D multicast addresses in standard dotted decimal
notation or (if reverse lookup is enabled), hosts under the
MCAST.NET domain. Such multicast addresses are defined as follows:
With logging enabled, the IP Traffic Monitor prompts you for a log file
name. The default name is ip_traffic-n.log (where
n
is what instance of the traffic monitor this is (1, 2, 3, and so on).
(e.g. if this is the first instance, the default file name will be
ip_traffic-1.log.)
At any time, you can press X or Q to return to the main
menu (or back to the shell if the monitor was started with
iptraf -i).
If you wish to start this facility directly from the command
line, you can specify the -d parameter and an interface to
monitor. For example,
starts the statistics for eth0. The interface must be
specified, or IPTraf will not start the facility.
The figures are logged at regular intervals if logging is
enabled. The default log file name at the prompt is
iface_stats_detailed-iface.log where iface
is the selected interface for this session (for example,
iface_stats_detailed-eth0.log).
Pressing X or Q takes you back to the main menu (if this facility
was started with the command-line option, X or Q drops you back
to the shell).
The Port fields should contain a port number of the service
you may be interested in. Leave it at 0 to let the filter
ignore it. You will most likely be interested in target
ports rather than source ports (which are usually
unpredictable anyway, perhaps with the exception of FTP
data).
Fill out the second set of fields with the parameters of the
opposite end of the connection. As previously mentioned,
you may place either set of parameters in either set of fields. By
default, the second set of parameters are preset to
0.0.0.0, 0.0.0.0, 0. Just Backspace or Delete over them and
replace them if needed.
The last field is marked Include/Exclude. This field allows you
to decide whether to include or exclude matching packets from the display.
Setting this field to I causes the filter to display matching
entries, while setting it to E causes the filter to suppress the
display of matching entries. This field is set to I by default.
Press Enter to accept all parameters when done. The
parameters will be accepted and you'll be presented with
another blank form. You can enter as many sets of parameters as you
wish. Press Ctrl+X at a blank form when done.
You can enter as many parameters as you wish. All of them
will be interpreted when the filter is processed.
The filters can also be edited in much the same way as the TCP and UDP
filters with the same keystrokes. After selecting the filter you want
to edit, you will see the IP addresses/hostnames and masks of the filter
rules. As you move the pointer to select a rule, the bottom of the
selection box displays the protocols that particular rule matches.
As with the TCP and UDP filter editing dialogs, you can press Enter to
edit the selected rule, I to insert at the current pointer position, A to
add to the list of rules, and D to delete the currently pointed rule. You can
move the rule selection pointer with the Up and Down cursor keys.
When this option is disabled, you'll only receive
information about packets coming from and entering your
machine.
The setting of this option affects all LAN (both Ethernet and FDDI)
interfaces on your machine, if you have more than one.
The interface's promiscuous flag is set only when a facility is started,
and turned of when it exits. However, if promiscuous mode was already set
when a facility was started, it remains set on exit.
If multiple instances of IPTraf are started, the promiscuous setting is
restored only upon exit of the last facility.
Color is on by default on consoles, off on non-color terminal
types like xterms and VT100s.
The other facilities generate a log file name based on the interface they're
listening on
Press Enter to accept the log file name, or Ctrl+X to cancel. Canceling
will turn logging off for that session.
The IP Traffic Monitor will write the following pieces of
information to its log file:
Each log entry includes the date and time the entry was
written. Logging is also affected by the defined filters.
Log files can grow very fast, so be prepared with plenty of
free space and delete unneeded logs. Log write errors are
not indicated.
Copies of the interface statistics, TCP/UDP statistics, packet size
statistics, and LAN host statistics are also written to the log
files at regular intervals. See Log Interval... below.
IPTraf closes and reopens the active log file when it receives a USR1
signal. This is useful in cases where a facility is run for long periods
of time but the log files have to be cleared or moved.
To clear or move an active log file, rename it first. IPTraf will
continue to write to the file despite the new name. Then use the UNIX
kill command to send the running IPTraf process a USR1 signal.
IPTraf will then close the log file and open another with the original
name. You can then safely remove or delete the renamed file.
Do not delete an open log file. Doing so will only result in a file just
as large but filled with null characters (ASCII code 0).
Logging comes disabled by default. The USR1 signal is caught only if
logging is enabled, it is ignored otherwise.
No such information is displayed if the network interface doesn't use MAC
addresses (such as PPP interfaces).
This can be used to determine the actual source of the packets on your local
LAN.
The traffic monitor also logs the MAC addresses with this option enabled.
The default setting is off.
This figure does not affect the rate of data capture. Only the
screen refresh is affected. The figures are still updated as
fast as possible, although the figure display will no longer be as
close to realtime.
The default setting is 0, which shouldn't be a problem on the
console. Set it to a slightly higher value on remote terminals or
slow links. The setting affects all monitoring facilities.
You will see two fields. If you have only one port to enter,
just fill up the first field. To specify a range, fill both fields, the
first port in the first field, the last port in the second field.
|
Technical note: This is actually a response to the segmentation fault
error (SIGSEGV).
|
This program can be run only by the system administrator
IPTraf normally does not allow anybody but uid 0 (root) to run it. This
measure is included for safety reasons. See the section on recompiling
the program below if you want to override this. This feature is built
in, and not part of the configuration
Your TERM variable is not set
The TERM (terminal type) environment variable must be set to a valid
terminal type so that the screen management routines can function
properly. Set it to the appropriate terminal type. Linux consoles
typically use a value called "linux".
Received TERM signal
Not related to the previous message. The TERM (terminate) signal is
normally used to
gracefully shut down a program. This message simply indicates that the
TERM signal was caught and IPTraf is attempting to shut down as gracefully
as possible.
Invalid option or missing parameter, use iptraf -h for help
The -i, -d, -s, -z or -l
options were specified but no interface was specified on the command line.
These parameters require a valid interface name (or all for
-i or -l).
This message also appears if an unknown option is passed to the iptraf
command.
Warning: unable to tag this process
IPTraf normally tags itself when it runs to prevent multiple instances of
the statistical facilities from running. This message means the program was
unable to create the necessary tag file. This may be due to a bad or improper
installation. Try running the "make install" procedure.
Warning: unable to tag facility
IPTraf was unable to create the tag file for the facility you started.
The facility will still run, but other instances of IPTraf that may be
running simultaneously will allow the same facility to run. This may cause
both instances of the facility to malfunction. This could be due to a bad
disk or bad installation.
facility already running/listening on iface
The facility you tried to start is currently running on the indicated interface
in another IPTraf process on the machine. This restriction is placed to
prevent conflicts involving internal sockets or the log files.
General interface statistics already active in another process
Only one instance of the general interface statistics can run at a time.
Duplicate port/range entry
You entered a port number or range that was already added to the list of
additional ports to be monitored by the TCP/UDP service monitor
No custom ports
There are no ports or port ranges earlier added. There's nothing to
delete.
Can't start rvnamed; lookups will block
IPTraf cannot start the rvnamed daemon; probably due to a bad installation.
IPTraf will fall back to blocking lookups.
Can't spawn new process; lookups will block
IPTraf cannot start a new process. This may be due to memory shortage.
IPTraf will fall back to blocking lookups.
Fork error, IPTraf cannot run in background
IPTraf cannot start a new process, and can go into the background. This
may be due to memory shortage. IPTraf aborts.
No memory for new filter entry
IPTraf was unable to allocate memory for a new filter entry. Most likely
due to memory shortage.
Memory Low
This indicator appears if memory runs low due to a lot of entries in a
facility. Should critical functions fail (window creation, internal
allocation), the program could terminate with a segmentation violation.
|
Warning Any message or indicator about low memory means that your
system does not have enough memory to handle the entries. It is almost
certain that sooner or later, IPTraf or other applications will abort
due to the failure of important system calls or library functions.
Memory must be added right away.
|
IPC Error
This indicator appears if an error occurs receiving data from the rvnamed
program (IPC stands for Interprocess Communication). This indication should
not occur under normal circumstances. Report instances of this condition
and the circumstances under which it happens. You may also include data
from the rvnamed.log file.
Error opening terminal: terminal
The screen management routines cannot find the terminfo entry for your
terminal. IPTraf expects the terminfo database located in
/usr/share/terminfo. This error could occur when your terminfo
database is located somewhere else.
See the section above on controlling the terminfo search path.
rvnamed Messages
Being a daemon, rvnamed does not send messages to the screen. It writes
its messages to the file rvnamed.log in the IPTraf working directory.
Unable to open child communication socket
rvnamed was unable to open the communication endpoint for data reception
from the children it creates. This is highly unusual, and should it occur,
report the circumstances.
Unable to open client communication socket
rvnamed was unable to open the communication endpoint for data exchange with
the IPTraf program. This is highly unusual, and should it occur, report
the circumstances.
Error binding client communication socket
Error binding child communication socket
rvnamed was unable to assign a name to the indicated communication socket.
This may be due to a bad, full, or corrupted filesystem.
Fatal error: no memory for descriptor monitoring
rvnamed ran out of memory. IPTraf will resort to blocking, and may freeze.
Error on fork, returning IP address
rvnamed had a problem spawning a copy of itself to resolve the IP address.
rvnamed will simply return the IP address in its literal, dotted-decimal
notation. IPTraf will still function normally. This may be due to lack
of memory or a process limit hit.
Maximum child process limit reached
rvnamed has reached its maximum number of child processes. This is intended
as a "brake" to prevent too many rvnamed children from hogging your computer's
resources and possibly crashing it.
Unless IPTraf is monitoring an extremely busy network without filters, this
shouldn't happen, at least, not that often. If you notice this message,
try applying filters or check your DNS server. Many times, this can happen
when the DNS server goes down for whatever reason, and you have rvnamed
children taking too long to resolve.
License and Copyright for IPTraf
IPTraf 2.5 Copyright © Gerard Paul Java, 1997-2001
The software and accompanying documentation are distributed
under the terms of the GNU General Public License, Version 2
or any later version, as published by the Free Software
Foundation, Inc. Permission is granted to distribute and/or
modify the software and the documentation under the terms of
the license.
The software and accompanying documentation are distributed WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR ANY PARTICULAR PURPOSE. For more details, see
the GNU General Public License, in the COPYING file included
in the distribution.
IPTraf uses header files that are part of the GNU C library and the Linux
kernel distribution.
Additional structures were extracted from software
copyrighted by the Regents of the University of California.
Linux is a registered trademark of Linus Torvalds
Pentium is a registered trademark of Intel Corporation.
IPTraf User's Manual, HTML Version 2.5.0
Copyright © Gerard Paul Java 1997-2001
