No Znx!

Every so often you see messages in your logs regarding ip_conntrack like the following:

ip_conntrack: table full, dropping packet

So my first thought it that it might relate to memory usage. Fortunately enough the kernel provides all the information we need to work it out. The kernel will allocate a “slab” when ever conntrack requires more memory, equally it will retain these slabs for a period of time and reuse if required. Each “slab” represents a number of pages of kernel memory, we can retrieve the current page size by using the following command:

# getconf PAGESIZE
4096

So each page is 4096 bytes. Next lets see how many slabs conntrack is using:

# grep conntrack /proc/slabinfo
ip_conntrack        6537  16620    384  984 1662    1 :  496  124

So that represents the following:

• ip_conntrack; a human readable name
• 6537; total number of objects in use.
• 16620; total available objects (including unused)
• 384; size of each object.
• 984; the number of slabs that are active
• 1662; the total number of slabs
• 1; the number of pages required to make a slab (normally 1)

The two other columns after the colon relate to SMP CPU information; we don’t need to discuss them.

So 6537 objects each of size 384 bytes, which means that we can fix around 10 per slab (4096/384=10.66). That means that the objects represent 2510208 bytes (~2.4Mb), but because of the overhead we are actually using 654 (6537/10=653.7) slabs or 2.6Mb (654*4096=2678784). So we are wasting around 256 bytes per slab (4096-384*10).

In other words an extremely small amount of memory. So it is very unlikely that is the cause. Further investigation reveal that it is normally due to the conntrack hitting the maximum count which can be viewed by looking at:

# cat /proc/sys/net/ipv4/ip_conntrack_max
65536

Comparing this to the current count:

#  wc -l ./proc/sys/net/ip_conntrack
   5602 /proc/net/ip_conntrack

We now know that it doesn’t use any great deal of memory at all, so we can easily double the count by doing the following:

# echo 131072 >/proc/sys/net/ipv4/ip_conntrack_max

Obviously in this example the memory usage was minor and there was little need to double the count but you can review your own system and increase as you wish now we know that it has a very small memory footprint.

A friend of mine just recently posted a trick with long hostnames when using SSH. I have commented before many times when I see people making aliases or shorthand’s like this that they just don’t know about the magic that is possible in the SSH configuration file.

Take for example this, imagine having a long hostname, with an odd port and a different user. Typing that would be a pain, most people would do something like:

alias ssh-short="ssh -p 12345 someotheruser@somelong.hostname.com"

In their ~/.bashrc, however the same can be filled into the configuration file. Edit the file ~/.ssh/config (or make it!):

Host short
  HostName somelong.hostname.com
  User someotheruser
  Port 12345

After doing this you can simply do:

$ ssh short

How much easier do you need it to be?!

I was further discussing C ideas and this time we came across bit flags (also called bit fields). The idea behind them is conservation of memory, a boolean data type consumes 1 byte of memory but all that is really needed is a single bit. Therefore you can store several booleans in a single byte.

Here is a simple example, note that each has a specific value to ensure that each matches a single bit in the 8-bit variable:

enum options {
  option_a = 0x01,  /*   1 == 00000001 */
  option_b = 0x02,  /*   2 == 00000010 */
  option_c = 0x04,  /*   4 == 00000100 */
  option_d = 0x08,  /*   8 == 00001000 */
  option_e = 0x10,  /*  16 == 00010000 */
  option_f = 0x20,  /*  32 == 00100000 */
  option_g = 0x40,  /*  64 == 01000000 */
  option_h = 0x80,  /* 128 == 10000000 */
};

So basically we have 8 boolean flags (0 off/false, 1 on/true). We can use these by utilising bitwise operations. There is really only 3 operations that you will use regularly on bit flags so lets see them.

Switching individual/multiple options “on” (or setting value true):

options |= option_a;
/* Translates to:
  options = options | option_a;
  options = 00000000 | 00000001;
  options = 00000001;
*/
 
options = option_a | option_c | option_h;
/* Translates to:
  options = 00000001 | 00000100 | 10000000;
  options = 10000101;
*/

Equally switching options “off” (or setting false) can be done as follows (note we are using the options from above, thus a, c and h are on):

options &= ~option_a;
/* Translates to:
  options = options & ~option_a;
  options = 10000101 & ~00000001;
  options = 10000101 & 11111110;
  options = 10000100;
*/

Obviously you need a basic grasp of boolean mathematics to be able to handle this but learning the basics shouldn’t be too hard. Finally the last thing to do is check to see if a flag is “on” or “off” (again using the options from before, so c and h are “on”:

if( options & option_b ) printf("B is ON\n");
/* 10000100 & 00000010 = 00000000 .. i.e. false, so no output */
if( options & option_c ) printf("C is ON\n");
/* 10000100 & 00000100 = 00000100 .. i.e. true, so "C is ON" is outputting */

As with most things in C, once you start using and abusing it should start to fall into place. I hope that this serves as a basic introduction to bit fields.

With C++ there is ways of handling optional function parameters or overloading functions to handle different amounts of parameters, obviously within C these abilities do not exist. However if we wanted to handle a variable list of parameters then C and C++ would work the same.

Let’s see how we’d do that:

#include <stdarg.h>
#include <stdio.h>
 
int Adding(int cnt, ...) {  /* the three ... indicate a variable list */
    int add, tmp, i;
    va_list args;            /* make a va_list */
    va_start(args, cnt);     /* variable list starts after 'cnt' */
    for(i = 0; i < cnt; i++) {
        tmp = va_arg(args, int); /* grab the next */
        add = add + tmp;         /* add to the sum */
    }
    va_end(args);    /* finished using variable list */
    return add;
}
 
int main( ) {
    int a;
    a = Adding(2, 1, 2);
    printf("%u\n", a);     /* Outputs 3 */
    a = Adding(3, 1, 2, 3);
    printf("%u\n", a);     /* Outputs 6 */
    return 0;
}

So the first argument indicates how many variables we are going to pass and the rest are summed together. The function Adding() would be identical in C++.

Sometimes when people are using Linux they will find that they come across a simple security check that confirms the authenticity of the RPM/Deb files that they are installing. Every so often the key is missing but that is easy to remedy. Here I will use an example with the YUM install of Adobe Flash:

[root@marine]# ls
adobe-release-i386-1.0-1.noarch.rpm
[root@marine]# yum localinstall adobe-release-i386-1.0-1.noarch.rpm
Loaded plugins: fastestmirror, priorities
Setting up Local Package Process
Examining adobe-release-i386-1.0-1.noarch.rpm: adobe-release-i386-1.0-1.noarch
Marking adobe-release-i386-1.0-1.noarch.rpm to be installed
Loading mirror speeds from cached hostfile
* addons: anorien.csc.warwick.ac.uk
* base: anorien.csc.warwick.ac.uk
* centosplus: anorien.csc.warwick.ac.uk
* contrib: anorien.csc.warwick.ac.uk
* extras: anorien.csc.warwick.ac.uk
* rpmforge: fr2.rpmfind.net
* updates: anorien.csc.warwick.ac.uk
588 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package adobe-release-i386.noarch 0:1.0-1 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package              Arch     Version Repository                          Size
================================================================================
Installing:
adobe-release-i386   noarch   1.0-1   /adobe-release-i386-1.0-1.noarch   1.9 k

Transaction Summary
================================================================================
Install      1 Package(s)
Update       0 Package(s)
Remove       0 Package(s)

Total size: 1.9 k
Is this ok [y/N]: y
Downloading Packages:
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID f6777c67

Public key for adobe-release-i386-1.0-1.noarch.rpm is not installed

As you can see it attempted to install but because the key was missing it refused to install. So what do we do to find that key? First we must download the key from somewhere, there is various key servers around the world, some of the most popular are (note hkp is the HTTP keyserver protocol):

• hkp://subkeys.pgp.net
• hkp://pgp.mit.edu
• hkp://keys.gnupg.net
• hkp://wwwkeys.uk.pgp.net (where UK can be replaced by any country code)

So lets search for the missing key:

[root@marine]# gpg --keyserver hkp://wwwkeys.uk.pgp.net --recv-keys f6777c67
gpg: requesting key F6777C67 from hkp server wwwkeys.uk.pgp.net
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key F6777C67: public key "Adobe Systems Incorporated (Linux RPM
  Signing Key) " imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1

So now we have the key and see that it is indeed Adobe’s key. Now all we need to do is add into RPM:

[root@marine]# gpg --armor --export f6777c67 >tmp-gpg.key
[root@marine]# rpm --import tmp-gpg.key

Simple as that, the install will work now!

This post is a refreshed look at a previous post on the same matter.