Monday, October 19, 2009

My notes on TCP/IP stacks.

Please excuse, some if this is just stuff I grabed off of web sites for further investigation.

TCP/IP stacks

Mini TCP/IP stacks.


lwIP    lwIP is significantly more complex

uC/IP   uC/IP - TCP/IP for microcontrollers

Alpine - user space TCP/IP  (have source code somewhere)
UPDATE July 20, 2011:
I found my Alpine code, but it's only the Alpine4Linux. 

The file can be downloaded from :
I'd like to put these up on source forge or at least something like where the code can no longer get lost. 

Daytona ""


> i want to move tcp/ip stack(including routing and
> netfilter) to userspace, my goal is to trace all the
> instructions involved in a firewall and router since i
> don't know how to trace these instructions inside the
> kernel. i want to get something like:
> incoming ip packets(a file)-->fake ISR-->tcp/ip
> stack-->outgoing ip packets( to /dev/null).
> my question is: is it possible and relatively easy to
> move tcp/ip stack to user space?
This comes up fairly frequently, it might be a good addition to the FAQ.
Here's my attempt at an answer culled from prior messages.

Several people have user-mode network stacks at various levels of
development, but it is *highly* unlikely for them ever to get into
the kernel proper (see the monolithic versus microkernel debate at

Here are some URLs to which you can refer for more information:

However, for security purposes, you probably do not want a user-mode stack.
You want an extensible packet handling mechanism, and can be found with:
        iptables/ipchains -- the native Linux firewalling tools,
        tc -- the Traffic control program,
        libpcap -- packet capture library,
I've started a syncookie fw using a daemon process  ???

I do this using the REDIRECT ( ipchains ) / QUEUE ( ipfilter ) targets,
to get the packets to userspace. Once there, you can do what you want
using libpcap or syuscalls.


[10] C.A. Thekkath, T.D. Nguyen, E.Moy and E.D.
Lazowska, ‘Implementing Network Protocols at User
Level,’ in Proceedings SIGCOMM 1993,
San Francisco, pp. 64-73, September, 1993.

[13] C. Maeda and B.N. Bershad, ‘Protocol service
decomposition for high-performance networking,’ in
14th ACM Symposium on Operating Systems
, December 1993.

[15] G.L. Peterson, “Myths about the mutual exclusion
problem,’ in Information Processing Letters, Vol. 12,
No. 3, pp. 115-116, June 1981.
A Appendices
A.1 Peterson’s algorithm
Peterson’s algorithm for mutual exclusion between two
processes is as follows (also see [15]):
while (wantAccess[YOU] && nextAccess==YOU)
/* Add yield code here */

A.2 Edwards’ Algorithm
This algorithm for mutual exclusion exploits the fact that
the child process runs at real-time priority and so cannot be
pre-empted by the user process:
if (disable_child) {
/* If user process has disabled us
* then we block and wait for him to
* wake us up
/* We know child must be blocked at the
* moment (thus not holding lock) as it
* runs as a real-time priority so can
* not be pre-empted
if (wakeup_user_process) {
if (child_blocking) {


UPDATE July 20, 2011:
I found my Alpine code, but it's only the Alpine4Linux. 

The file can be downloaded from :


Date: Fri, 30 May 2003 11:53:23 -0700 (PDT)
To: or

Neelkanth Natu (

Hi all,

Alpine4Linux is a userlevel FreeBSD 4.8 networking stack running on top of a stock Linux kernel.  It is an implementation of an idea that I came across in a paper[1] by David Ely, Stefan Savage and David Wetherall.

Alpine4Linux consists of a userland server program that runs the FreeBSD kernel code as well as
the unmodified networking stack. Client programs use the Alpine stack by setting the LD_PRELOAD
environment variable to link to libraries, that intercept socket related system calls. These
intercepted system calls are routed to the Alpine server over a TCP connection established on the loopback interface.

Alpine4Linux goes great lengths to ensure that its behavior is identical to that of a FreeBSD
kernel as far as networking is concerned. Thus, in addition to the unmodified FreeBSD stack.
Alpine4Linux also has unmodified socket layer code, file descriptor code, tsleep and wakeup for
e.g. It also has a rich client-side library that supports almost all socket functions as well as
functions like fork() that are commonly used by server programs.

I have tested stock Linux programs like telnet, nmap, ifconfig, vsftpd-1.1.3 etc. against
the Alpine stack. I have only compiled it on a Redhat 8.x Linux box, so if someone manages to run it on another Linux distribution/kernel please let me know.

You can find more information at:

Hopefully someone finds use for this.


[1] Alpine: A user-level infrastructure for network protocol development
    David Ely, Stefan Savage, David Wetherall


Application-L evel Protocol Infrastructure for Network Experimentation


TCP Tahoe and Reno
TCP Vegas
TCP New Reno
TCP Hybla   high-latency terrestrial or satellite radio link
TCP BIC     In linux 2.6.8 through 2.6.18
TCP CUBIC  In linux  since version 2.6.19
Compound TCP (CTCP) is a Microsoft algorithm that is part of the Windows Vista and Window Server 2008 TCP
YeAH TCP - Yet Another Highspeed TCP - Linux

TCP Illinois congestion control. This is an implementation of TCP Illinois invented by Shao Liu at University of Illinois. It is a another variant of Reno which adapts the alpha and beta parameters based on RTT. The basic idea is to increase window less rapidly as delay approaches the maximum. See the papers and talks to get a more complete description

YeAH-TCP congestion control algorithm implementation. YeAH-TCP is a sender-side high-speed enabled TCP congestion control algorithm, which uses a mixed loss/delay approach to compute the congestion window. It's design goals target high efficiency, internal, RTT and Reno fairness, resilience to link loss while keeping network elements load as low as possible. For further details look here:

TCP cubic update for 2.6.22. The new version improves on its scalability, fairness and stability. So in all properties, we confirmed it shows better performance



web-enabled embedded systems

Many devices (printers, etc.) now use not just standard Internet Protocol but have a small web server embedded in them for input and to indicate status rather than using floppy disks or LCD panels or tiny little keyboards or other proprietary communication protocols.
[FIXME: Is there a better file for me to keep this category ?]
web appliances
[ Intelligent Instrumentation, Inc. data acquisition system ] is very similar ...


Fixing the Unfairness of TCP Congestion Control

"George Ou, Technical Director of ZDNet, has an analysis today of an engineering proposal to address congestion issues on the internet. It's an interesting read, with sections such as "The politicization of an engineering problem" and "Dismantling the dogma of flow rate fairness". Short and long term answers are suggested, along with some examples of what incentives it might take to get this to work. Whichever side of the neutrality debate you're on, this is worth consideration."

By 1999, the first P2P (peer-to-peer) application called Swarmcast began to blatantly exploit Jacobson’s TCP congestion control mechanism.  Using a technique called “parallel incremental downloading”, Swarmcast could grab a much larger share of the pie at the expense of others by exploiting the multi-stream and persistence loophole.  These two loopholes would be used by every P2P application since.


Anonymous said...

thanks for sharing this site. you can download lots of ebook from here

Unknown said...

Any suggestions on where I can lay my hands on the ALPINE src code and their documentation. The project is conspicuously missing on the web.

John Sokol said...

I had the Alpine code, I actually went to and tracked down the author and got a copy.

Unfortunalty that server the copy was on, died. This was many years back.

Yea, it's not on the Internet these days. I have noticed a lot of unmaintained code, just vanish. It really sucks.

Unknown said...

Thanks for responding John!

Yea - I sent an email to one of the authors (who is now a Professor). Ironically he pointed me to your blog ;) Please leave me a message if you happen to hear off the resurrection of the original Alpine.

John Sokol said...

I found my Alpine code, but it's only the Alpine4Linux.

The file can be downloaded from :
I'd like to put these up on source forge or at least something like where the code can no longer get lost.

Unknown said...

My lab is developing a new user-level transport framework -- it will have a basic implementation of TCP Tahoe, as well as an event-driven interface that will make it easier to create entirely new transport protocols or to mash-up protocols from existing pieces. We'll have code, documentation, and a paper released in the next couple months. If you send me an email around then, I'll point you to our resources.

Unknown said...

John - Thanks a lot for the pointers! I did manage to download the code.

It's sad though that there has been no community activity. If there was - it would be very interesting to participate and develop.

Daniel - I'm very much interested in learning (even participating in the activities if you will).

Just a couple of questions - Will IPv6 be a part of this framework - or is that something you folks are still working on? Also if there is a way to reach I'd send you an email instead of trolling John's page :)


John Sokol said...

Porting Kame to Alpine4linux shouldn't be very hard.

Also making Alpine4Linux be able to compile on BSD and Linux shouldn't be too hard (famous last words)

I have a low level IP stack that just does arp and ping,

Just posted it's code.