The kernel allocates file handles dynamically, but as yet it doesn't free them again.

The value in file-max denotes the maximum number of file- handles that the Linux kernel will allocate. When you get lots of error messages about running out of file handles, you might want to increase this limit.

Historically, the three values in file-nr denoted the number of allocated file handles, the number of allocated but unused file handles, and the maximum number of file handles. Linux 2.6 always reports 0 as the number of free file handles – this is not an error, it just means that the number of allocated file handles exactly matches the number of used file handles.

Attempts to allocate more file descriptors than file-max are reported with printk, look for «VFS: file-max limit reached».

Connection tracking refers to the ability to maintain state information about a connection in memory tables, such as source and destination ip address and port number pairs (known as socket pairs), protocol types, connection state and timeouts. Firewalls that do this are known as stateful. Stateful firewalling is inherently more secure than its «stateless» counterpart …. simple packet filtering.

The state table for udp and tcp connections is maintained in /proc/net/ip_conntrack. We will discuss what its contents look below.

The maximum number of connections the state table can contain is stored in /proc/sys/net/ipv4/ip_conntrack_max. This value is determined initially by how much physical memory you have (on my 128Mb machine, ip_conntrack_max = 8184 by default).

Because UDP lacks sequence numbers, it is known as a «stateless» protocol . However, this does not mean we can't track udp connections. There is still other useful information we can utilize. Here is an example state table entry for a newly formed udp connection:

This state table entry can only be made if there is an iptables filter rule specifying NEW connections, something like the following ruleset, which allows NEW connections outbound only (as is often wise):

Source and destination addresses and ports of expected reply. The connection is marked UNREPLIED so this has not been received yet.

Udp timeouts are set in /usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_udp.c at compile time. A single request will enter into the state for 30*HZ (generally 30 seconds). In the example above, where we have 19 seconds left, 11 seconds have already elapsed without a reply being received. Once a reply is received, and allowed by a rule permitting ESTABLISHED connections, the timeout is reset to 30 seconds and the UNREPLIED mark is removed. Here we see the connection a couple of seconds after this has taken place:

If multiple requests and replies occur between the same socket pairs, the entry is considered to be a stream and the timeout changes to 180 seconds. At this point the entry is marked ASSURED (once connections become ASSURED they are not dropped under heavy load ). Here we see the connection a few of seconds after this has taken place: