The Upper Window

The upper window of the traffic monitor displays the currently detected TCP connections. Information about TCP packets are displayed here. The window contains these pieces of information:

• Source address and port

• Packet count

• Byte count

• Source MAC address

• Packet Size

• Window Size

• TCP flag statuses

• Interface

	Note
	Previous versions of IPTraf showed both the source and destination addresses on each line. IPTraf 2 and higher show only the source host:port combination to save on screen real estate. TCP connection endpoints are still indicated with the green brackets (on color terminals) along the left edge of the screen.

The Up and Down cursor keys move an indicator bar between entries in the TCP monitor, scrolling the window if necessary. The PgUp and PgDn keys display the previous and next screenfuls of entries respectively.

The IP traffic monitor computes the data flow rate of the currently highlighted TCP flow and displays it on the lower-right corner of the screen. The flow rate is in kilobits or kilobytes per second depending on the Activity mode switch in the Configure... menu.

Because this monitoring system relies solely on packet information, it does not determine which endpoint initiated the connection. In other words, it does not know which endpoints are the client and 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. However, a little knowledge of the well-known TCP port numbers can give a good idea about which address is that of the server.

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.

Each entry in the window contains these fields:

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).

If the Source MAC addrs in traffic monitor option is not enabled, pressing M simply toggles between the counts and the packet and window sizes.

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.

	Tip
	If you notice unusual SYN activity (too many initial (S---) but frozen SYN entries, or rapidly increasing initial SYN packets for a single connection), you may be under a SYN flooding attack or TCP port scan. Apply appropriate measures, or the targeted machines may begin denying network services.

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.

Some early entries may have a > symbol in front of its packet count. This means the connection was already established when the monitor started. In other words, the figures indicated do not reflect the counts since the start of the TCP connection, but rather, since the start of the traffic monitor. Eventually, these > entries will close (or time out) and disappear. TCP entries without the > were initiated after the traffic monitor started, and the counts indicate the totals of the connection itself. Just consider entries with > partial.

Some > entries may go idle if the traffic monitor was started when these connections were already half-closed (FIN sent by one host, but data still being sent by the other). This is because the traffic monitor cannot determine if a connection was already half-closed when it started. These entries will eventually time out. (To minimize these entries, an entry is not added by the monitor until a packet with data or a SYN packet is received.)

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.

Technical note: IP Forwarding and Masquerading

Previous versions of IPTraf issued a warning if the kernel had IP masquerading enabled due to the way the kernel masqueraded and translated the IP addresses. The new kernels no longer do it as before and IPTraf now gives output properly on masquerading machines. The -q parameter is no longer required to suppress the warning screen. On forwarding (non-masquerading) machines packets and TCP connections simply appear twice, one each for the incoming and outgoing interfaces if all interafaces are being monitored. On masquerading machines, packets and connections from the internal network to the external network also appear twice, one for the internal and external interface. Packets coming from the internal network will be indicated as coming from the internal IP address that sourced them, and also as coming from the IP address of the external interface on your masquerading machine. In much the same way, packets coming in from the external network will look like they're destined for the external interface's IP address, and again as destined for the final host on the internal network.

Closed/Idle/Timed Out Connections

A TCP connection entry that closes, gets reset, or stays idle too long normally gets replaced with new connections. However, if there are too many of these, active connections may become interspersed among closed, reset, or idle entries.

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 immediately clear them at any time.

	Note
	The TCP timeout... option only tells IPTraf how long it should take before a connection should be considered idle and open to replacement by new connections. This does not determine how long it remains on-screen. The TCP closed/idle persistence... parameter flushes entries that have been idle for the number of minutes defined by the TCP timeout... option.