linux: loading modules causes problems in iptables

You may run into a few problems with loading modules. For example, you could get errors claiming that there is no module by such a name and so on. This may, for example look like the following.

insmod: iptable_filter: no module by that name found

This is no reason for concern yet. This or these modules may possibly have been statically compiled into your kernel. This is the first thing you should look at when trying to solve this problem. The simplest way to see if these modules have been loaded already or if they are statically compiled into the kernel, is to simply try and run a command that uses the specific functionality. In the above case, we could not load the filter table. If this functionality is not there, we should be unable to use the filter table at all. To check if the filter table is there, we do the following.

iptables -t filter -L
   

This should either output all of the chains in the filter table properly, or it should fail. If everything is o.k., then it should look something like this depending on if you have rules inserted or not.

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
    

If you do not have the filter table loaded, you would get an error that looks something like this instead.

iptables v1.2.5: can't initialize iptables table `filter': Table \
     does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
    

This is a bit more serious since it points out that first of all, we do not have the functionality compiled into the kernel, and second, that the module is not possible to find in our normal module paths. This may either mean that:

• you have forgotten to install your modules,
• you have forgotten to run depmod -a to update your module databases or
• you have not compiled the functionality as either module or statically into kernel.

There may of course be other reasons for the module not to be loaded, but these are the main reasons. Most of these problems are easily solved.

• The first problem would simply be solved by running make modules_install in the kernel source directory (if the source has already been compiled and the modules have already been built).
• The second problem is solved by simply running depmod -a once and see if it works afterward.
• The third problem is a bit out of the league for this explanation, and you are more or less left to your own wits here. You will most probably find more information about this on the Linux Documentation Project homepage.

Source

netperf design

Netperf Always Uses Two Separate Connections

One connection for control, one connection for data.

When you execute netperf, the first thing that will happen is the establishment of a control connection to the remote system. This connection will be used to pass test configuration information and results to and from the remote system. Regardless of the type of test being run, the control connection will be a TCP connection using BSD sockets.

Once the control connection is up and the configuration information has been passed, a separate connection will be opened for the measurement itself using the APIs and protocols appropriate for the test. The test will be performed, and the results will be displayed.

Netperf places no traffic on the control connection while a test is in progress. Certain TCP options, such as SO_KEEPALIVE, if set as your system's default, may put packets out on the control connection.

Source