IPTraf Technical Information
System Requirements
Supported Interfaces
IPTraf intercepts packets using the built-in raw socket interface of the Linux kernel. It will therefore work with any kernel-supported interface.
The following link protocols are supported by version 2.0.0:
The network interface is accessed through the kernel. For Ethernet interfaces, IPTraf uses ioctl() calls to set or unset the card's promiscuous mode.
Raw Socket Interface
Linux 2.0 The network data is captured in its raw form with a special socket mechanism. Linux supports a type of socket called SOCK_PACKET, which is similar to SOCK_RAW, except that the captured packet includes the data-link (e.g. Ethernet) header. (See the Ethernet-HOWTO for more information on Ethernet interfaces). Packets are captured with the recvfrom() library function. An appropriate sockaddr structure is also defined (sockaddr_pkt) which contains protocol and device information after the recvfrom().
Linux 2.2 The new 2.2 kernel has a better capture mechanism. It defines a new protocol family called PF_PACKET. The socket parameters IPTraf 2 uses are (PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)). The defined sockaddr structure for this type of socket is sockaddr_ll. It contains basically the same fields as sockaddr_pkt but has a few more new interesting fields.
The Packet Socket option must be included in any custom-compiled 2.2 kernel or IPTraf will not work. Neither will tcpdump and other packet capture software.
With Linux 2.2, the SOCK_PACKET type is still supported but is considered obsolete, and is indicated as such in the syslog.
Caveats
Synchronous PPP over ISDN had problems with earlier versions of IPTraf but reports came in saying the problems disappeared with kernel 2.0.34. Support has then been restored in 1.3.0, but users are advised to keep it under observation. If you're running a kernel version prior to 2.0.35, you are advised to upgrade for security reasons, as well as for the various ISDN bugfixes.
FDDI support is still in a fairly experimental stage. Users are advised to keep it under observation, and report any problems.
Internal Data Structures
The main data structures used by the various facilities are doubly-linked lists. This makes it easier to scroll forward and backward, and the maximum number of entries is limited only by available memory. Search operations on most facilities, are performed linearly, and have a mild hit, but is usually not noticeable. The IP Traffic Monitor, though uses a hash table for better search efficiency, due to its propensity to grow quite rapidly. (Search operations are performed every time the program needs to check whether the address [Ethernet or IP] or protocol/port combination is already in the list.)
The TCP traffic monitor has an additional doubly-linked stack that merely contains pointers to old entries that are available for reuse. Everytime a connection entry is completely closed or reset, the entries' memory is not freed, rather, an entry is added to this "closed list." When a new connection is detected, this list is checked. If it's not empty, the first available used entry found is reused, and the "closed list's" entry is removed.
All data structures are destroyed upon exit of the facility.
For More Information
See the included README file, and the user's manual in the Documentation directory in the source distribution.
Copyright Gerard Paul Java 1997