This is tested in the Bakpia mod kernel (2.6.32.9), module compiled from the rmcc github kernel 2.6.32.9 branch located here.

Compiled in a CentOS 5.3 environment with android ndk and sdk installed.

Anyways, copy the module to /system/lib/modules do an insmod tun.ko to run the module and tunneling is all set. You can now use Openvpn downloaded from the Market.

Download here.

For those who want to compile a tun.ko kernel for Android (a commtiva z71 variant), here are the general steps. You need a linux environment to compile this module.

1. Download the kernel and supporting files for commtiva z71 devices here: https://opensource.motorola.com/sf/frs/do/viewRelease/projects.quenchxt/frs.xt5.xt502 and extract it to a directory of your choice.
2. Download the SDK and NDK for android: http://developer.android.com/sdk/ndk/index.html and http://developer.android.com/sdk/index.html
3. Copy config.gz from your phone and place it into your kernel source folder. To get it from your phone, type:
adb pull /proc/config.gz .
gunzip config.gz
mv config .config
4. Edit .config so as TUN module will be included into the kernel:
CONFIG_TUN=m
5. Run uname to get running kernel version of your phone:
uname -a
Linux localhost 2.6.32.9 #7 PREEMPT Tue Jan 4 16:51:45 CST 2011 arv61 GNU/Linux
6. If there was some extra characters in your kernel version, like 2.6.32.9-063c4d24, you’d have to edit the Makefile to use the corresponding version:
EXTRAVERSION = -063c4d24
7. Set your environment variables:
export ARCH=arm
export CROSS_COMPILE=arm-eabi-
export PATH=$PATH:~[path of your arm-eabi compile toolkit binary in android ndk]
8. cd to your kernel folder and make modules
cd ~[path of your kernel source]
make modules

Resulting tun.ko should be in the drivers/net folder of your kernel source.

Just beware, it is not for the fainthearted.

Further information:
http://android-dls.com/wiki/index.php?title=Build_a_custom_kernel
http://forum.androidcentral.com/htc-hero-rooting-roms-hacks/8072-how-build-your-own-kernel-package-source.html

Why was it deleted? Greg Kroah-Hartman in his blog stated in a nutshell that:

In short, no one cared about the code, so it was removed. As I’ve stated before, code in the staging tree needs to be worked on to be merged to the main kernel tree, or it will be deleted.

There was a more serious problem though, as stated by Greg:

Now branches in the Linux kernel source tree are fine and they happen with every distro release. But this is much worse. Because Google doesn’t have their code merged into the mainline, these companies creating drivers and platform code are locked out from ever contributing it back to the kernel community. The kernel community has for years been telling these companies to get their code merged, so that they can take advantage of the security fixes, and handle the rapid API churn automatically. And these companies have listened, as is shown by the larger number of companies contributing to the kernel every release.

But now they are stuck. Companies with Android-specific platform and drivers can not contribute upstream, which causes these companies a much larger maintenance and development cycle.

On the lwn comments section, Greg further stated that a number of hardware companies approached the kernel development community for help due to this problem.

Apparently part of the problem is the problem is that Google created a new kernel core infrastructure which in order for it to be placed into the mainline kernel, numerous changes in kernel and userspace have to be done. Google has essentially created a fork of the kernel.

Cris DiBona stated:

To sum up: I think that Android is an unusual use of Linux that doesn’t match up with what is normally done, and I think that a fork isn’t unwarranted in these cases. I should point out we didn’t use glibc , either, or a ‘standard’ VM. We built android.

The aforementioned fork was mostly in the implemention of wakelocks, a process of bringing a system out of various low power states.

Google found the current implementation inefficient, and due to time constraints and pressure to produce a product, made their own API implementation.

The downside of this is that in order for linux drivers new and current ones to work on Android, one has to hook up to the new wakelock mechanism. This causes lots of distress in maintaining current userspace and kernelspace development.

It was generally agreed that the problems of power management was an issue that needed to be solved. However, a number disagreed on the way that Google handled the solution, including the kernel developers.

The reason mainline hasn’t accepted the wakelock infrastructure is that Google has still failed to demonstrate why it’s necessary. Almost identical benefits can be obtained using the kernel’s existing range timer functonality, which has the added bonus of removing the need for the strong userspace/kernel tying that Android requires right now.

Interestingly enough, Nokia handled the problem more maturely than Google. Whereareas, Google basically sent a large number of patches and left it hanging, one user noted:

I can’t remember significant interaction between Google Android developers and mainline kernel developers before early 2009. Contrast that to Nokia who have been *all over* the kernel upstreaming their OMAP patches for the N8xx and N900.

It was further noted that:

But they both have to solve the same problems (power management) and the fact that Nokia seems to get good battery life out of their devices appears at first glance to be a counterpoint to the necessity of wakelocks.

The discussion went on, without resolution. Time will tell if the Android code will be resubmitted back to the kernel, and the issues that hamper it being in the mainline kernel tree will be resolved and taken care of.